From the Bees to You
What does it feel like to have a company pivot its entire direction around a technology that you invented? And how much of an impact has Docker had on traditional PaaS providers? Jenkins creator Kohsuke Kawaguchi, current CTO of CloudBees, gives Voxxed the low-down.
Voxxed: CloudBees has undergone a significant strategy shift this year, switching from its primary position of PaaS provision to become the world’s foremost provider of open source continuous integration (CI) tool Jenkins. Were you aware that this move was coming before your role change to CTO of the company earlier this year?
Kohsuke: I think the shift was more gradual than perhaps it appeared. My CTO appointment reflected the growing importance of Jenkins for CloudBees, which was a steady shift over a year or so. It then took another half a year or so for that trend to continue to the point that we made the decision to focus entirely on Jenkins. We moved relatively quickly once we made the hard decision.
Does CloudBees see PaaS as ‘dead’, or might the company revisit the technology when market conditions are more mature?
I believe in the elastic runtime environment, where you can programmatically spin up and tear down a running application, and doing so at the higher level (think PaaS) is better than doing so at the lower layer (think IaaS.)
But what we traditionally consider PaaS a few years ago has been getting squeezed from all sides. When I look at what Amazon, Google, Microsoft does, their plethora of services easily accessible to apps running on their IaaS, you see that the boundary between PaaS and IaaS is far more blurry today than before. For more complete treatment on this topic, I encourage readers to take a look at the reflection post from Steve Harris, senior vice president at CloudBees.
Our DEV@cloud shares some of the same technology that run our PaaS service, and it is very much alive today. But given the pace in which this market is evolving, I doubt that we will revive PaaS technology in the future.
I won’t say never though, because some of the code in Jenkins products we sell, we hibernated for a while, too!
Was the explosion of popularity for Docker a factor in this decision?
I think it did have some indirect impact. If Docker becomes the packaging mechanism for deployment (and it’s looking more and more like it’s going that way), then how you insert your WAR file into an existing “Tomcat stack” will look very different, and how you wire them together will look very different. Suddenly you don’t have to do Chef/Puppet to “properly” deploy applications, which was to me one of the key values of PaaS. So one can’t help but feel that we were competing with something that’s rapidly getting commoditized.
Why do you think Continuous Integration is becoming such a priority in the enterprise?
One way to think of this is that computing continues to become cheaper and more abundant, and that makes developer time incredibly more precious and expensive. So just about any technology that helps push more workload from humans to machines is important, and CI is one such technology. The same with CD, which is a natural extension for Jenkins.
In the case of Jenkins, in addition to that, there’s great extensibility in the platform and a large community of plugins, and information readily available to help people write new ones. In the world where every company has its own idiosyncratic tools and processes, the ability to adapt is very important. And we got that.
What aspects of Jenkins are people most curious about?
One of the key efforts we are working on right now is called Workflow, which provides a more flexible means to allow people to orchestrate complex activities (think delivery pipelines), in ways that addresses a number of long-standing pain points in Jenkins. I see a great enthusiasm in this feature, and I am very excited about this.
But when it comes to questions from people at JavaOne, they tend to be very specific issues about specific plugins. Those people already use Jenkins, know Jenkins pretty well, and are just trying to solve a specific issue they have at hand while they can grab the developers of the project. I think it shows the degree of adoption we have achieved!
How has the community reacted to the news that CloudBees will be focusing on Jenkins going forward?
People who I interact with in the community regularly already know what CloudBees does and our deep involvement in Jenkins, so I don’t think this news came as a surprise to them. Many of them are close friends of mine, and I’d like to think that there’s a bit of “rooting for the home team” feeling.
For the broader community, I think the increased investment in the Jenkins project is a good thing, and many of us come from a deep open-source background, so I’m confident that we can play nicely and respect the independent open-source project that is Jenkins.
You said earlier this year that you were working to rally the Jenkins community around a single acceptance test harness that you’ve been building, so that the community could amass more test cases. How is work on this going?
I think the project has achieved a degree of success. We have amassed 450+ tests that cover 50+ major plugins. Those are often tests that exercise Jenkins interacting with real external systems. It has a lot of pieces that are independently reusable, and it has encouraged new participations into the community from people who previously weren’t engaging.
We still have a lot of work to do, though. There’s a flakiness in many tests, the kind you see often when using WebDriver. We want to run them more regularly on a lot more platforms and with different browsers. There are new modules to add to the harness, such as an ability to provision a large Jenkins cluster in one shot more quickly, etc.
What was the focus of your JavaOne talk, and do you have any key takeaways for our readers?
My talk at JavaOne was around the idea of having elasticity in your Jenkins build environment. That is, instead of having a static pool of carefully curated build slave machines, it makes a lot more sense to have an environment where you can dynamically spin up a new slave and tear it down. Jenkins makes it very easy to do this, and people have used this successfully in many different ways.
Finally, what’s on the roadmap for CloudBees in the next year?
Once we deliver the foundation of Workflow in this year, there’ll be a lot of work next year to enrich that new subsystem, ranging from updating plugins to work nicely with it, providing higher-level features around reuse and sharing, or visualizing what’s going on in your workflow.
Then there’s Jenkins Operations Center by CloudBees, where we are making it easy for people to manage and connect multiple Jenkins masters. We are adding such capabilities like remotely installing/upgrading plugins/core en masse, or monitor Jenkins-level statistics and aggregate them, an API for a master to communicate with another, and the list goes on and on.
Beyond that, I’d really want to bring some of the technologies we’ve built to run our DEV@cloud, where we maintains thousands of masters running hundreds of builds all the time. But this space is much too small to talk about all that, so if you are interested in our geeking out on these gory details, I’d encourage you to check out our developer blog.
Image by 邪恶的正太