In preparation for Jenkins User Conference West, we interviewed Kohsuke Kawaguchi. Kohsuke is the creator of the Jenkins continuous integration server and CTO of CloudBees. I asked him about the growth of Jenkins, Kubernetes, and trends in the DevOps space.
This is the second Jenkins User Conference this year. How has the growth of the Jenkins community surprised you?
This is actually the 5th Jenkins User Conference this year (ed. Note: I meant to say “in the US.” Oops!) --- we've done Tokyo, Washington DC, London, Tel Aviv, and now the Bay Area. When you do the same event every year in the same place, it starts to take on its own life, and there are definitely some people I'm looking forward to seeing in JUC Bay Area every year.
The growth of the community has been actually surprisingly consistent. We have anonymous usage statistics reporting built into Jenkins, and according to that, installation count has been increasing about 30% year-over-year for the past few years, the number of build slaves increase 50%, and so on.
What aspect of Jenkins are users most interested in?
I'd actually love to really know that myself! The sense I get is that people are trying to learn from each other. I think everyone has this feeling that "I cannot be the only one facing this problem, someone else must have solved this problem," and so we are all trying to learn from each other what we've done and if it can be reused.
The thing about Jenkins is that it's got the huge ecosystem of the plugins going, and if you think about it, a plugin is really a reusable expression of how someone solved some problem they had. So it naturally allows people to share their experiences and reuse the solutions to problems they ran into.
What does CloudBees do that makes their services appealing to those in the Jenkins community?
In small companies or when the use of Jenkins is at a level of individuals and teams, heroes and champions in organizations can promote and support Jenkins. But as the usage grows, or when you try to adopt CI/CD across a sizable organization, being able to lean on CloudBees for our support, expertise and the additional features in our CloudBees Jenkins Platform is actually an advantage. So that's one way CloudBees adds value to the Jenkins community, by allowing Jenkins to reach places that an open source project cannot reach by itself.
Now, if you are one of those heroes and champions, I'd still like to encourage you to take a look at our Team Edition of CloudBees Jenkins Platform (CJP). This is a version of CJP that has a lot of features geared toward smaller more agile teams.
What do you think are some rising trends in DevOps and continuous integration? How will Jenkins/Cloudbees be adapting to these trends?
Docker is the obvious answer, and it has several impacts on Jenkins that are still playing out.
One is that people are using Docker as a means to simplify/codify the build environment. We have people in the community who have developed a number of plugins like the Docker plugin, Docker Custom Build Environment plugin, Kubernetes plugin or the Mesos plugin that uses Docker to simplify the operation of a large Jenkins cluster, or make it more flexible.
Then there are those who are using Docker containers as the unit of deployment. For them, the fact that you can launch and destroy instances very rapidly and easily is opening up a lot of opportunities to do more sophisticated continuous delivery pipelines. For example, today it is common in most places to have a fixed set of named environments in which you can deploy and run apps. But with containers, suddenly it becomes really practical to create and destroy environments on demand. Just like servers can now be managed like cattle instead of pets, now environments can, too. So we have been building Jenkins Workflow and its Docker extensions to cater to this kind of needs.
Last year you were named the CTO of CloudBees. It’s been over a year since then. What are some of the greater challenges you’ve had to face in that new role?
CloudBees is growing quite rapidly, which means the biggest challenge is how we work is changing rapidly too. To keep up with the growth of the team and technology I’m always striving to improve the way I work. It’s important as a leader to adopt a different approach when change happens, just because it’s comfortable doesn’t mean the same tactics will work in every situation.
The second challenge with growth, aside from rapid change, is building out the team. To keep up with the pace of Jenkins and CloudBees technology adoption I’m working on finding more engineers to work in San Jose, near me. (So if you are reading this, are in the Bay Area and are interested in working with us, we should talk. CloudBees is hiring!)
What, if any, was CloudBees’ involvement in the Kubernetes plugin?
The Kubernetes plugin was originally started by Carlos Sanchez, who I have known for a long time and I have a lot of respect for. Since then he has come onboard and now works for CloudBees. I think CloudBees' contribution to the Kubernetes plugin occurred when we talked to Google and got this project going. We worked with their engineers in the Jenkins community. Our own Nicolas de Loof and Matt Moore from Google deserve a special mention for building on top.
I'm hoping that there is enough code out there to illustrate some convincing use cases that show how container-based development is the future. As more people adopt what we are advocating, I hope these plugins will gain more traction.