CircleCI CEO: We’ll spread the data in nut-free expansion strategy

Source:-devclass.com

When CI/CD tools vendors get an influx of cash, they tend to do three things. Firstly, expand geographically, typically to London/Europe if they’re US-based. Secondly, they up their focus on enterprise customers as opposed to fellow startups. Third, they expand across the software delivery pipeline, building out additional functionality or sucking up other companies which – theoretically at least – complement their original product.

CircleCI secured $56m of investment back in June, and has certainly thrown itself into the first two, setting up an office in the heart of London’s financial district, alongside its San Francisco base and a Tokyo outpost. But CircleCI CEO Jim Rose says the company will steer clear of the all-in one, “peanut butter strategy” it sees its rivals taking.

We caught up with Rose in November, in the firm’s new WeWork digs in London’s Moorgate, which puts it close to both the sort of VC-backed organisations it built its original success on, and the sort of larger, often finance-based, enterprises it is increasingly looking to capture as they move to the cloud, consolidating their software assets.

Many of these will already be using some sort of development automation tooling, but in Rose’s view “the legacy solutions reach a tipping point and they need something new”. He adds that “we affectionately call those customers Jenkins refugees.”

But when it comes to expanding its own technology offering, Rose is adamant the company will maintain its focus on CI/CD, rather than taking a similar path to GitLab and Jenkins backer CloudBees both of which are expanding or buying their way along the tool chain. He describes this as a “peanut butter strategy, where you go end to end, all the way from idea to post release monitoring and sort of operational monitoring.”

This is the dawning of the age of the API

“The bet from Microsoft, or a GitLab or others, is the reason you want to go to a single vendor is that the cost is in integration,” he says. “The cost is in trying to pass information from system to system. But honestly, in the age of the API, that isn’t a challenge, right?”

Larger organisations, looking for common platforms might be assumed to favour all-in-one suppliers. But Rose argues. “The problem specifically in CI/CD is that as you get bigger, and as you try and move faster, even within the context of a single company, your development process differs by team. Everyone’s development process is different. Everyone is unique. Everyone is a snowflake, and everyone’s process is right for them.”

It would be presumptuous for a vendor to tell all these different teams, with their different tooling, that they’re doing it all wrong, he says. “There’s probably a ton of good reasons for the way that you’ve structured your delivery and release process. “

That doesn’t mean CircleCI can’t be “opinionated” he argues. “We basically say,’we’ve seen this pattern before. And this seems to be best practice, but we’re happy to support you, however you want to do that.’ But to do that, and to be able to deal with that amount of complexity means that you have to focus and you have to make sure that you’re focused in one area, and going deep within that area.”

Unlike GitLab, with its open core approach and CloudBees with its backing for the open source Jenkins and Jenkins X projects, CircleCI’s offering is essentially proprietary. At the same time, while it offers a server product, the bulk of its user base is doing builds on CircleCI’s own multi-tenant platform. And it’s the insight it gleans from running “a couple of million builds a day” – much of it using open source components – that CircleCI is banking on as its key USP.

More significantly, Rose argues, “The nature of software development has changed over the last 10 to 15 years as more and more companies are adopting open source and adopting third party API’s to support core services. The amount of custom code being written today is de minimis.”

Say a company was looking to build an ecommerce operation, he asks. Ten or fifteen years ago, the first step would have been pulling together a couple of dozen engineers. Now, “step number one is you download a framework, the framework would download hundreds of libraries, those libraries would be calling out to dozens of third party services, like Stripe for payment authorization.”

“The code that you write that’s custom to you, is either around a small component of that service, as well as all the integration glue that holds those pieces together. So when we look at code today, 70 to 90 per cent of the code inside of a project is shared, is third party.”

It’s a time for sharing

“The benefit we have is we see all of those same components,” he continues. “All of the same services being built tens of thousands, hundreds of thousands and millions of times a day.” And, therefore, they see, and can predict, where things are going to break.

“We’re in the process of basically aggregating all of this understanding of how the software supply chain works, and beginning to expose that to our customers, so that customers can learn from the experience of the crowd, how to make a better, more stable, more efficient software delivery process.”

“So right now, we had a service that we called Insights, which is basically the data service that goes back to a customer, we’re in the process of revamping that, and we’re revamping at multiple levels,” he explains. “So first at the individual tasks then the jobs. Then the pipelines and the workflows and the organisation, then the network and so we’re kind of climbing that ladder…And the benefit for that for the customer obviously is, well, wouldn’t it be great if I didn’t have to fail my build?”

“The second step of that, of course, is can we steer you around that and so instead of automatically updating you to the latest version, what if we were aware that that was unstable, it could basically keep you on the most recent stable version.”

This all relies on an intimate knowledge of what customers are doing – and customers’ being comfortable with that info being shared. When GitLab recently tried to apply more telemetry to its platform, there was a user revolt.

In CircleCI’s case, says Rose, the telemetry has always been part of the platform. “We don’t call it telemetry, we basically just call it like ongoing analytics. Because, a, it’s the only way we can make sure that the system stays up for everyone. And b, it also tells us the stuff to get out of your way. It’s an area you have to be super careful and you have to be really, really clear and concise about what it is you’re doing.”

But it’s this approach which it says enables it to keep its system up, and get super deep on CI/CD, he says. And it’s CI/CD after all that is CircleCI’s bread and butter. Presumably the full fat kind – not the high protein, nutty variety.