It’s a sunny morning on the New Jersey banks of the Hudson River, with a view of the New York City skyline ahead of me. Behind me, croissants, banners, and a lot of developers gathering for DevOps World.
There’s a semantic association here: 18 years ago, a community of developers voted to assert their governance of the Oracle-backed Hudson Project and rename it “Jenkins.” Presumably Jenkins, Kentucky, population ~1,800, lacked the necessary conference facilities that New Jersey has, so a Hyatt by the Hudson river it was for this leg of the event's tour.
Jenkins went on to become one of the most widely used open source automation servers. By letting developers continuously integrate changes into software products it has become central to many DevOps environments and with over 1,800 plugins, is highly flexible and ubiquitous, with 75 million jobs defined between June '21 and June '23.
"Jenkins is now a core part of critical infrastructure," says Shawn Ahmed, Chief Product Officer at CloudBees at the event. "The finest software is at some point, somewhere going through a Jenkins pipeline.”
But open source Jenkins can also be a pain to manage and maintain; adding a new stage in the pipeline or upgrading the Jenkins server to add new features all require finessing and the plugins, poorly managed, can pose a security risk. It can also suffer performance issues at scale.
DevOps World organiser CloudBees, a key contributor to open source Jenkins, also offers its own CI/CD SaaS version with more enterprise features wrapped around the broader “one-two punch” of CI/CD.
(Continuous integration, or CI, involves integrating code changes from multiple devs into a shared repository as often as possible before subjecting them to automated building and testing processes. Continuous delivery, or CD, uses automation to usher changes through quality assurance, staging, approvals, and ultimately into production.)
And Ahmed was speaking at DevOps World as his company unveiled several updates to its enterprise version of Jenkins to make scale better at enterprise level – as well as a new cloud-native DevSecOps platform built on the open source Tekton framework that it described as placing "platform engineers and developer experience front and center."
The latter is for those looking to build and deploy completely in the cloud. It uses a GitHub Actions style domain-specific language (DSL) with "feature flagging, security, compliance, pipeline orchestration, analytics and value stream management (VSM)" available via your flavour of fully-managed single-tenant SaaS, multi-tenant SaaS or on-premise virtual private cloud instance.
With the releases, CloudBees aims to offer deeper CI/CD capabilities both for those remaining on premises and those in the cloud.
Biggest boost to Jenkins performance in a decade?
The updates to the CloudBees CI software were touted by the firm as "the most significant performance and scalability functionality for Jenkins in a decade” (albeit they are available through the CloudBees platform, not open source Jenkins). Ahmed explains the context for the updates.
"As software became the large differentiator for most traditional companies, a whole bunch of companies started to become software companies," he tells The Stack: "Take financial services as an example.
“Most financial services companies today will probably say they are effectively a technology company that happens to have a banking licence. That wasn't the case fifty years ago...So these companies that may have started with little projects a decade ago, are now a full fledged software company rivalling the size of traditional tech giants.
“That's when scale becomes an issue [for software delivery]."
"When you have to become a technology company at scale, and you used to be a traditional banking company it becomes an issue of how do you create robust systems, as you have a whole different set of regulatory compliance needs or requirements for scale and security and so on [but your developers still want] the ability to run Jenkins at massive scale with active-active high availability – yet are often running multiple thousands or hundreds of thousands of jobs across a small set of monolithic, overloaded controllers,” adds CloudBees’ Shawn Ahmed at the event.
It is this issue that CloudBees says it has tackled decisively by letting Jenkins workloads be load balanced to replica controllers, making Jenkins always available and able to scale as required, he says. (Among other updates are a new caching system which according to Product Manager Runxia Ye has cut build time by a third and "Baseline your repository" without causing build storms; i.e, gridlock on startup.)
"Enterprises and developers have been long complaining about monolithic controllers, and how easily they overload," backgrounds Ye.
These controller bottlenecks have been the biggest bane in horizontally scaling Jenkins CI/CD jobs: "Think about a controller as sort of a Jenkins sort of control unit, where all jobs go to execute, and it then goes and tells agents you're gonna all execute this job and then take all the steps in here, execute them and so on." Ahmed explains to The Stack .
"Essentially, our HA/HS feature creates a copy of your original controller into a secondary one. Then it puts a controller on the front-end of that, then it says, just don't tell the developers or anybody else about how many of these replicas we've got running, turn them on and off as you need them..."
"Let the developer just have one address to send their job to so now it's almost like if you were the main controller, but you had like five helpers behind you..and I'm not speaking to the five helpers behind you. I'm just speaking to you saying, 'hey, I have this job that needs to execute. Can you execute?'
"And that's essentially the replicant. It's that copy of you that can do all the jobs that you do, just as well as you do them."
Not only will this prevent the controllers being overloaded by clients: the replica controllers will also allow DevOps to go on, even if systems are down, upgrading or having simply crashed. (The rest of the perks of the CloudBees platform overhaul - visually appealing debugging updates and workspace caching for speedy build times – will just be the cherry on top for Jenkins users.
The new DevSecOps platform meanwhile (currently in beta and set to be GA later this September) represents an interesting pivot to Tekton for cloud-native CI/CD. Tekton grew out of the Knative project and has been backed by Red Hat, among others. Its pipelines are built from containers that are sequenced via internal Kubernetes events on the Kubernetes API server.
For those looking to build cloud-native CI/CD pipelines but put off by the complexity of grappling with Kubernetes and reluctant to go to a hyperscaler PaaS CloudBees bundling another, significantly more modern CI/CD framework than Jenkins as a tidy managed service may yet prove attractive.
