Software developers love their super heroes but its time for a changing of the guard. Out go Batman, Superman, the X-Men and The Avengers. In comes an all new Jenkins Suite with five super powers. Each of these will help shape the future of Jenkins and DevOps.
The five super powers were unveiled at Jenkins World and DevOps World by Kohsuke Kawaguchi, CTO, CloudBees and the creator of Jenkins. They are:
- Jenkins Pipeline
- Jenkins Evergreen
- Configuration as Code
- Cloud Native Jenkins
- Jenkins X
Kawaguchi spent the majority of his keynote positioning and talking about each of these products and what they are and will deliver.
Jenkins Pipeline
This has been around for over four years now. As DevOps matures, it continues to gain traction. It is a suite of plugins to support continuous delivery (CD). Despite being one of the oldest Jenkins products, Kawaguchi says it will continue to be developed.
The current plan is to continue to develop it to make it easier for customers to create and deploy their pipelines. The next version will see a fundamental change to the way Pipeline works. This is to allow it to address new classes of problems. To achieve that, the product will be rewritten from the ground up. Kawaguchi told the audience this would not only improve it but would reduce the amount of code in the product. This will make it easier to maintain over the long-term.
Last year, CloudBees introduced Blue Ocean and redefined the UI. Now Kawaguchi wants to go further. He likened the product to the Space Shuttle with just one booster engine running. He wants to ignite the second booster by adding extensibility to Blue Ocean. This will allow the rest of the Jenkins community to build on it.
It will also no longer be called Blue Ocean. It will cease to be seen as a separate product and simply become a core part of Jenkins.
Jenkins Evergreen
At the beginning of 2018, CloudBees started Jenkins Evergreen as a whole new product. The goal is a radical simplification of Jenkins. As CD becomes more mainstream, the administrative load is rising rapidly. Kawaguchi believes that this will become an inhibitor to adoption so it is time for change.
Evergreen will be a preassembled Jenkins distribution described by Kawaguchi as having “batteries included” and requiring “no constant babysitting.” He wants to see new users able to pick up Evergreen and get started with just five clicks. There should be no need for them to read manuals or deal with any management overhead.
To achieve this, the project team has taken a different approach to Jenkins. They have had to revisit what is inside the core and how the add-ons are integrated. One of the challenges was to think about what CI/CD needed going forward such as GitHub and Docker. These will be delivered as plugins.
To help users get productive faster there will be a more guided path to success. The product will come with more defaults and less need for manual configuration. Among those steps will be things such as auto configuration of Evergreen itself. Upgrades will be automatic and while some users will worry, the product will have built-in self-healing and rollback features.
Listening to Kawaguchi describe all of this it was easy to draw parallels with Larry Ellison and the Autonomous Oracle Database. The question is, how autonomous can a DevOps tool be? Developers like to do things themselves and keep control of their environment. This is not necessarily targeted at the traditional Jenkins developer but new and less experienced users who are beginning to adopt DevOps.
Configuration as Code
It is 18 months since Configuration as Code appeared. One of the big benefits it introduced was the ability to have a consistent, repeatable experience with Jenkins. Developers write their config files in YAML and store them in Git along with any plugins and other components. When then want to spin up an instance in Docker they do so by using this config file.
The product has now reached v1.0. Kawaguchi said that in the Contributor Summit, held on Monday, there was a lot of interest in what this could deliver. What has helped drive this forward is the collaboration between the Jenkins community and Praqma.
For customers who are beginning to orchestrate the deployment of DevOps, Configuration as Code gives them a repeatable experience.
Cloud Native Jenkins
Scalability; no single point of failure; disaster recovery by launching another Jenkins container; automated and optimised storage provisioning. All of these are pain points for different groups of users. The goal of Cloud Native Jenkins is to get rid of the problems that require manual intervention by administrators. Kawaguchi even talked about getting rid of the file system and becoming a single process master.
CloudBees has been working on this project for a while. Users can already archive artefacts with Amazon S3. The goal is to extend that out to support the storage architecture of other cloud platforms. Another feature that is being tested is the ability to move all the build logs into Amazon CloudWatch.
Kawaguchi outlined other features that are also under development. They include:
- A distributed, highly available Jenkins on Kubernetes
- Build engine running as a serverless/function as a service
- Continuous deliver in the same way as is planned for Evergreen
This is not yet ready for widespread adoption. Kawaguchi said that the development team are focused on a number of specific use cases. Once they have delivered those then they will review where the product goes next.
Jenkins X
At KubeCon in Denmark, James Strachan talked to Enterprise Times about this solution. Kawaguchi told the keynote audience that a new cloud OS is emerging around Kubernetes. Jenkins X is a Kubernetes-native CI/CD platform. It will allow developers to build their own cloud native applications. What sets it apart from other tools is that those applications and the Jenkins X instances can be deployed across multiple clouds without any need for additional tuning.
This is important to a lot of organisations. A recent Forrester survey showed that large organisations are adopting multi-cloud for their deployment. They no longer want to deal with just one cloud provider. However, the more cloud providers they use the more issues they have had to resolve. What Jenkins X is doing is taking advantage of the support for Kubernetes from a number of cloud providers.
What does this mean
These are heady times for CloudBees and the Jenkins community. There are more products appearing now than at any other time in the company’s history. The challenge for CloudBees will be in delivering all of these and making sure that they are stable and work together.
It is a challenge that Kawaguchi is already dealing with. He told the audience that code and features would be shared across the five super powers. This would extend to the sharing of user privileges and security. Importantly, CloudBees has also announced that it is to move everything into the CloudBees Suite. This will help speed up the integration and sharing of these five products.
In the last year, CloudBees has attracted $62 million in funding in order to build new products and extend its reach. The super powers introduced by Kawaguchi is just part of what it planning. The company now has a Chief Product Officer, Christina Noren, who is already reshaping product delivery. On top of this, Sacha Labourey, CEO, has said he wants to see Jenkins become the CRM of DevOps.
There is much to do in the year ahead for CloudBees and it will be interesting to see how it gets there and the lessons it learns on the way.
