These comments are in response to the article published by TechTarget. They were written by CloudBees CEO and co-founder, Sacha Labourey:
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 latter 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; let’s 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.
- 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: http://jenkins-x.io/
- 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.
Sacha Labourey is the CEO and co-founder of CloudBees.