CloudBees made its name with an integrated software delivery platform built on Jenkins. The managed service focused on taking away the heavy lifting from those running the powerful but unruly automation server, which is used to continuously build and test software at scale, and built a well regarded integrated software delivery platform around it. That took it to over $100 million in revenues and a customer base that includes logos like Accenture, Bosch, the IRS, and HSBC.
Many of its customers are building more software and deploying more software natively in the cloud however; something that for those wanting a true all-in-one CI/CD ecosystem comes with compliance, standardisation and visibility risks as DevOps teams spin up an archipelago of different projects across different cloud environments.
CloudBees hasn’t played strongly in the cloud yet; moving slowly to get a cloud-native SaaS live to handle software delivery and as Forrester recently noted its “platform cohesion needs work.” The company co-created and explored Jenkins X as a possible cloud-native CI/CD solution that lets users create a Kubernetes cluster, install all the tools they need to manage an application, then create build and deployment pipelines; but it was not an easy lift for many users and arguably just translated some Jenkins issues into Jenkins-in-the-cloud issues.
The company – after a string of acquisitions and CEOs – is now inching closer to delivering the full-fat CI/CD platform for the cloud it has been threatening to build for a few years; as well as innovating around its existing on-premises proposition and ironing out some of the long-standing issues with Jenkins in a series of recent updates.
CloudBees has made some interesting choices about how it builds that proposition – a beta release is with a handful of customers and lands more widely in November, the company says. The Stack explored…
"An appreciation for Tekton..."
As CloudBees co-founder Sacha Labourey puts it to The Stack on a call: “Jenkins X was a useful exercise, but it never proved to be something that would be the foundation we needed for our SaaS” adding “we took a lot of learnings out of it though including appreciation for Tekton…”
Tekton, born at Google, is an open-source framework for creating CI/CD systems for the cloud and lives under the Linux Foundation’s CD Foundation. (Jenkins X had used Tekton to handle the execution and management of Jenkins X pipelines natively within Kubernetes.)
Tekton + GitHub Actions =
Laboury, a stalwart of the open source scene with a practitioners’ curiosity and openness to deeply exploring how software delivery is evolving, winds back the conversation for a moment to set the scene.
“I think you have a bunch of vendors out there providing not CI/CD, but DevOps solutions: GitHub and GitLab and so on. But many of those don’t have a fully integrated offering – or it tends to suffer from the same kind of issues that bother enterprises in that it is ‘everything out of the box!’ That’s fine for an SME; much less for an organisation with existing workloads and existing choices being made in cybersecurity etc.
“The ability to plug everything you want in is very important for enterprises. This notion of openness also extends to where you want to run things. If you are using GitHub Actions, it's going to run on Azure, but maybe you're working on AWS, so that doesn't really make sense.
“Being able to work on multiple clouds, work with multiple technologies of your choice is very important – and enterprises want to configure things. If you want to enable thousands, potentially tens of thousands of developers to develop efficiently at scale, you cannot just say, ‘well go online and start a project.’ You need to manage security keys, you need to manage clusters, you need to manage infrastructure…”
CloudBees has pulled this off pretty tidily, for on-premises. But as its customers start to build more for the cloud, it ran both the risk of death by a thousand applications departing for the cloud and saw a market gap for a genuinely holistic CI/CD platform that pulls together everything a customer at multinational bank-scale might need, from feature management to analytics to orchestration across clouds.
At DevOps World in New Jersey recently it unveiled this new platform (which does not have a discrete product name: CPO Shawn Ahmed confirms to The Stack that it is “simply CloudBees Platform. I recognize the implication of the name… but the long term strategy is simply for it to be ‘I’m using the CloudBees platform for DevSecOps’”) but less detail about what is happening under the hood to make it work.
CI/CD in the Cloud: Start your engines
Laboury explains: “We're using Tekton as a technology. To sequence steps, to achieve a pipeline, to achieve builds and so on, Tekton is great.
“It’s very efficient resource-wise, when it comes to executing those pipe lines. Where it is not ideal is in the language that you're using to express what you want to achieve with those pipelines. It's very verbose, very complicated. We decided to use Tecton as a back-end technology so we can use the strength of its ecosystem – you have security products that hook directly into Tekton itself for example. However, from an expression standpoint of your pipeline, we decided not to use Tecton.
“Instead of delivering yet another markup language, we decided to leverage GitHub Actions [essentially an API for cause and effect on GitHub]. We made extensions, wherever it made sense, then we're dynamically translating this into whatever is required to operate on Tekton or in the future, any other engine. We're really trying to have the best user experience from the front-end standpoint, but then focus on what’s best at the back-end” Labourey explains on a September 28 call.
“For example GitHub Actions only works on Azure; on virtual machines. Sure you can run your own VMs on a Mac, or on a PC or whatever you want to do and connect them to the mothership, but then you're not really SaaS anymore; and imagine that you're a company deploying on AWS, you might not want to do your development, build, staging everything but production on Azure, and then just do a jump to AWS for production. It just doesn't give peace of mind” he says…
The aim is to offer up a cloud-native “DevSecOps” platform that features a GitHub Actions-style language at the front-end with an “extensive actions library for powerful composability and reuse; graphical workflow composer and editor; native Tekton-based automation for mass scalability and ephemeral execution; built-in orchestration of popular CI and CD tools, including Jenkins and GitHub Actions; feature management and automated experimentation to support progressive delivery methods; VSM and software delivery performance analytics” as the marketing folks put it.
Then make it available in single-tenant SaaS, multi-tenant SaaS, and virtual private cloud as a “platform for your platform.”
Existing Jenkins users won’t get left behind, says Labourey: “Our goal is not to have a Blue Pill/Red Pill kind of offering. We're going to increasingly merge those two worlds, because that's actually what most of our existing customers are asking for…”
And he’s enthusiastic about Tekton too: “It's very modern, very extensible. If I need to encrypt any input or any output going into a step, add security signatures, SBOM-building and so on this type of extensibility is really well done, which really enables an ecosystem that highly efficient from a resources standpoint. Building on top of such blocks is really elegant and powerful” he concludes, adding that CloudBees has “a few people” working on it as an open source project.
“A planned SaaS offering should address its platform cohesion weakness and will help CloudBees serve clients that want a more integrated and maintenance-free ISDP (integrated software delivery platform) said Forrester in a May 2023 report. Can CloudBees finally deliver?
Watch this space. The building blocks are certainly intriguing.
