This content is part of the Essential Guide: Simplify the production deployment process with these tips
News Stay informed about the latest enterprise technology news and product updates.

CloudBees Jenkins Enterprise snags raise roadmap questions

CloudBees' Jenkins software is slated for major updates after strong revenue growth in 2017, but customers and partners report struggles with upgrades, pricing and support.

CloudBees enjoyed healthy growth in 2017 and has big plans for 2018, but it must resolve some lingering issues before its customers and partners can look ahead.

Based in San Jose, Calif., the vendor sells CloudBees Jenkins Enterprise software, as well as technical support for big companies that want help running the open source Jenkins CI/CD tool in production. The open source version of Jenkins has monolithic master servers that manage the CI/CD pipeline. Part of the CloudBees Jenkins Enterprise value proposition is to add high availability and scalability features with managed masters, which are centralized Jenkins master servers that oversee a workload delegated to client masters and worker nodes.

CloudBees has clearly made some inroads in DevOps shops with its approach. In February 2018, the privately held company disclosed strong growth for 2017: a 60% increase in overall revenues, 77% higher subscription revenues and a 67% increase in staffing, although it did not specify the raw numbers behind those percentages. But while open source Jenkins is among the most popular DevOps tools, CloudBees' "master of masters" approach to high availability for the tool doesn't appeal to everybody.

"I didn't really like that design," said Richard Fong, software engineering manager at Mitchell International, an auto insurance software company in San Diego. He previously helped manage one of the and largest production Jenkins environments at Yahoo in 2013.* "They should've put more effort into making the master clusterable so it can horizontally scale, instead scaling it by spinning up different clusters for different teams."

Fong evaluated older versions CloudBees Jenkins Solutions -- the umbrella term for all versions CloudBees' Jenkins software, which have been renamed several times in recent years -- but decided to stick with the open source version, rather than pay for CloudBees' software.

CloudBees will ambitiously update its architecture when it integrates CloudBees Jenkins Enterprise with the Kubernetes container orchestration platform, as the company revealed this month. This integration will help CloudBees move away from the "master of masters" approach to scalability and high availability upon which CloudBees Jenkins Enterprise previously relied, and it will lead to a more sophisticated distributed system design for masters in future versions of CloudBees Jenkins Enterprise.

CloudBees CEO Sacha LaboureySacha Labourey

"Kubernetes opens the door to lots of optimization down the road," CloudBees CEO Sacha Labourey said in an interview this month. To boost this effort, the company has hired three Kubernetes open source contributors.

Enterprise IT pros who have embraced CloudBees' software said they would welcome a Kubernetes integration, as well as a scale-out architecture for masters. But these customers and CloudBees' consulting partners have some apprehension about the upcoming changes to the product, given the struggles with the existing container integration in CloudBees Jenkins Enterprise, as well as more general confusion about pricing and tech support.

One enterprise customer remains stymied by an upgrade from a previous iteration of CloudBees Jenkins Platform to the existing version of CloudBees' container support using the Apache Mesos container scheduler in CloudBees Jenkins Enterprise.

"Our two monolithic masters are still there," said Jason Shawn, senior director of DevOps and cloud for Ellucian Co., a Reston, Va., software company that specializes in ERP systems for colleges and universities.

Ellucian has used CloudBees Jenkins Solutions since 2016, and it found valuable advantages in the pipeline-as-code features that came with Jenkins 2.0 support in CloudBees Jenkins Platform. But Shawn has also been eager to add a distributed high-availability architecture for Jenkins masters based on containers. He has worked with CloudBees support engineers to move to managed masters in CloudBees Jenkins Enterprise in recent months, but hasn't yet been able to make the upgrade.

"Perhaps some [other customers] have gotten it to work, but that hasn't been our experience yet," he said.

Shawn said he also asked CloudBees to support container-based deployment of masters on Amazon's Elastic Container Service for Kubernetes (EKS). Labourey said in an emailed statement through a spokesperson this week that CloudBees engineers have beta access to EKS and are working on support for it, but he did not comment on the issues Shawn reported with upgrading to managed masters.

CloudBees Jenkins Enterprise pricing, support deepen concerns

At , their definition 'user' was nebulous -- basically, 'anyone in the environment who benefits from Jenkins' -- and we would prefer a consumption-based pricing model similar to Amazon's.
Jason Shawnsenior director DevOps and cloud, Ellucian Co.

CloudBees' record revenue growth reflects market demand for its software, but customers and partners said they've been frustrated at times by confusion around CloudBees' pricing and support. For example, a change in CloudBees' pricing structure last year, from resource- to user-based, was meant to offer a more predictable licensing scheme than pricing by the number of masters and resources used, Labourey said in the interview earlier this month. But customers and partners said the definition of a user under the new pricing scheme was vaguely worded at and difficult to understand.

"It was really quite a slog," said Shawn, who negotiated a CloudBees Jenkins Enterprise licensing deal with the company last year to account for Ellucian's growth. "They're not the only vendor struggling with the right pricing model. But, at , their definition 'user' was nebulous -- basically, 'anyone in the environment who benefits from Jenkins' -- and we would prefer a consumption-based pricing model similar to Amazon's."

The pricing page on the CloudBees website defines a user as "anyone with a login to the CloudBees Jenkins Solutions and/or anyone who commits code to the source code repositories integrated with the CloudBees environment." An older version its pricing information defines a user as "every member your team who builds, commits, tests, deploys or manages software with the help of CloudBees Jenkins Solutions."

"While this was fine for some customers, others were not at ease, so we clarified it in a subsequent iteration," Labourey added in the more recent statement, through a spokesperson. "This is not an issue anymore in our customer discussions."

In the meantime, partners said CloudBees Jenkins Enterprise has become a tougher sell, as competitors such as version-control platform GitHub and project and software management tools vendor Atlassian offer integrations of open source Jenkins into CI/CD pipeline software and services. Because Jenkins is based on plug-ins that support third-party services, the support enterprises get from CloudBees isn't always consistent. CloudBees has a tiered plug-in support policy structure that sometimes means users have to seek out third-party support on their own.

"It's not exactly like the Red Hat business model, where customers have to weigh the cost of support against the cost of maintaining operating system stability and patches," said a West Coast-based CloudBees partner, speaking on the condition of anonymity. "Jenkins has so many third-party plug-ins and is so flexible that you can get into trouble very quickly with support."

As a result, enterprises are more challenged to justify CloudBees Jenkins Enterprise licensing costs than support from companies such as Red Hat, the partner said. Jenkins users will also soon have the option of Kubernetes integration with open source Jenkins thanks to a project the community launched this week, dubbed Jenkins X.

CloudBees Jenkins Enterprise still offers enough value for its cost at Ellucian, Shawn said. He has also evaluated other CI/CD options, such as Travis CI, GoCD and Amazon's native CI/CD services, but he doesn't have any plans to switch providers, he said.

Another bright spot for CloudBees lies in the success of its hybrid consulting business in the last year. Hybrid consulting means CloudBees engineers install and do initial management for CloudBees Jenkins Enterprise while training enterprise DevOps teams to operate it, and they eventually hand over control of the environment to those teams. The partner predicted more of an emphasis on this subscription support model for CloudBees in 2018.

* Information changed after publication

Next Steps

Looking to master DevOps? Here are some resources and tutorials to you to the most important DevOps tools and technologies being used in the industry today.

Dig Deeper on Application Rollout Planning and Problems

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What has your experience been like with CloudBees Jenkins Enterprise?


Thanks for your interest in CloudBees and the time you’ve spent talking to people in our ecosystem. Note that I normally try not to extensively comment on articles, but here I felt there were enough inconsistencies with reality that I should.

First of all, there are things that you got right, but where I’d like to give additional context:

· We definitely had some complexities associated to moving to user-based pricing from a resource-based pricing plan last year. However, in the good spirit of DevOps, we listened to our customers’ input and quickly made a course correction to simplify the new pricing and define it more clearly. Today, it is well-baked and, customers appreciate that they now pay only for active users on CloudBees Jenkins Enterprise. This pricing also enables our customers to use Jenkins “in the right way,” an architecture that’s core to CloudBees Jenkins Enterprise and makes it possible to scale Jenkins-based environments to tens of thousands of users. More on that later.

· We have changed our product names – several times. I understand this might have created confusion to our customers, but we have done so to reflect substantive changes we made in architecture. Today, our products are CloudBees Jenkins Platform (raw hardware or virtualized environments), CloudBees Jenkins Enterprise (Kubernetes/IaaS clouds), CloudBees DevOptics and Codeship by CloudBees (the later two are SaaS).

· The article is correct in its description of the Jenkins architecture – a single master approach limits scalability, but only for very, very large implementations. However, this same limitation does NOT apply to CloudBees Jenkins Enterprise (more on this below).

· Our support policy ( does not cover all 1,500 community plugins for Jenkins. There are tiers of support for the community plugins, starting with the top 100 most commonly used plugins. This group of plugins CloudBees has curated, tested and verified. If we were to fully support all 1,500, we would not be able to commit to an SLA. We will still answer questions about the unverified plugins we don’t fully support, though, and provide guidance on how to use them. This is not too different from what Red Hat provides for Red Hat Enterprise Linux.

Now the things that I want to correct:

·         The “master of masters” architecture and the supposed impact it has on scalability is not quite exact and doesn’t apply at all to CloudBees Jenkins Enterprise. Let me explain why. What makes Jenkins so successful is its extensive plugin ecosystem and its customizability: by enabling plugins, you can adapt Jenkins to your specific needs. What typically happens in organizations is that one team starts using Jenkins and configures a set of plugins to match their specific objective; - say a Java back-end application. Then, another team comes up, wants to start a new project; say, a mobile application. What happens in most cases is that the second team piggybacks on top of the already running Jenkins instance, and starts configuring their own plugins on the same master. Rinse and repeat several times, and you end up with a “mega-master,” - a server with lots of different uses cases, with an overload of unrelated plugins and a huge load associated to those numerous teams. This makes the overall Jenkins instance less stable (you need to get a lot of plugins to work together to play nicely) and upgrading it represents a big risk, so your Jenkins instance starts running behind lots of fixes and new features. This was the life before CloudBees Jenkins Enterprise. With CloudBees Jenkins Enterprise, we completely changed that and did two things. First, we created a stable distribution of Jenkins where we certify the most-frequently used plugins. This means that upgrading a Jenkins instance becomes a no-brainer (this is our CloudBees Assurance Program (CAP) program, which is automatically a part of every CloudBees subscription). And second, we developed an architecture called the “Distributed Pipeline Architecture,” where we make it possible to create and manage at scale a high number of very nimble Jenkins masters. This means that any new team coming onboard gets allocated their own Jenkins master. This makes this master very robust (because it serves a specific use case, it only loads the very specific plugins it needs, nothing more), very responsive (because it is dedicated to that single team) and upgrading that master is not only smooth (because of CAP), but in case something goes wrong it only impacts that single team. Obviously, none of that is visible to Jenkins admins: CloudBees Jenkins Enterprise automatically handles the resourcing, monitoring and management of those masters (we demoed a cluster with more than 2,000 masters and 10,000 executors, live, at Jenkins World in 2016). Furthermore, Jenkins users can easily navigate from project to project (i.e. from master to master) without having to be aware of it. This brings the best of all worlds.

·         Alright, so now that you can end up with lots of different nimble masters (one per team), you can see why a per-master pricing scheme doesn’t make sense as it would essentially motivate CloudBees Jenkins Enterprise customers to NOT create new masters as required, in order to minimize costs. It would essentially motivate them to build unstable skyscrapers hosting dozen of teams, so as to not migrate to lots of more nimble masters. This is why we moved to a per-user pricing. A lot of what I’ve described above is available in my Jenkins World 2016 keynote, it is available here:

·         So, is all easy then? Well, for new teams and new projects, yes, it is; they can directly create new teams on CloudBees Jenkins Enterprise and benefit from what I’ve described above. Issues exist when companies *already* have a number of “skyscrapers masters”: it takes work and planning to split them into teams and, unless they do so, they won’t fully benefit from our architecture. They’ll benefit from a more stable Jenkins environment (thanks to CAP), but the scalability, for example, won’t be solved; not until they migrate their teams to the right architecture. We do offer professional services to help with those migrations but ultimately, the timing and decision of such migration is not in our hands.

·         A former Yahoo! IT manager is quoted in the article as saying that the “master of masters” Jenkins architecture didn’t work for him during his time at Yahoo!. Yahoo! is a significant user of Jenkins and, most likely, one of the scaled-up enterprises that ended up with a bloated Jenkins master and performance issues. However, back in 2003, when the user was cited as having used Jenkins, Jenkins did not exist. Nor did its precursor, Hudson. I am guessing this was most likely 2013, not 2003. Regardless, this was not the CloudBees Jenkins Enterprise of today – but was open source, several years ago. The user was specifically identified as not having used CloudBees Jenkins Enterprise.

·         The Kubernetes support we announced last month has nothing to do with our Distributed Pipeline Architecture and scalability enhancements announced 13 months ago. What is now true with Kubernetes support, though, is that CloudBees Jenkins Enterprise is now built from the ground up natively on Kubernetes. What that means is that in addition to the scalability and team-collaboration advantages we already have, our customers can leverage their investment in cloud technology and offer this elastic runtime to their CI/CD users, through our platform.

·         In the article, you quote me as making mention of future work to have Jenkins more natively leverage Kubernetes. This work was announced this week by the Jenkins community under the project name “Jenkins X.” You can find more information about it here:

·         This may seem like a nit, but it’s not. The name of our product is CloudBees Jenkins Enterprise. It is not “Jenkins Enterprise.” We have to use the exact product names approved by the Jenkins project, if we are to be allowed to use the Jenkins trademark in our product names.

Beth, I hope the above will clarify a number of points for you and your readers. If not, feel free to reach out to me at sacha at cloudbees dot com.