Jenkins World and DevOps World took place last week in San Francisco. There was a lot to digest at the end of the conference but was it pure gold or fools gold? To get a better perspective I went in search of abandoned mines in the Nevada badlands. After all, where better to understand the real from the fake.
A company and its community in sync
CloudBees and the Jenkins open source community are tightly bound. This is key to the success of Jenkins. Kohsuke Kawaguchi, the creator of Jenkins is the CTO of CloudBees. His opinion is much sought after by contributors and he has always made sure they are listened to.
Two years ago, Kawaguchi launched the Adopt A Plug-In programme. In a podcast with Enterprise Times he said this is about celebrating the effort that the contributors have made. The programme has been successful and many older plug-ins are now updated regularly. It is a move that the community has embraced positively.
Kawaguchi also believes that recruiting contributors is, in the long run, counter productive. For everyone employed, that is a resource potentially lost to the community. He wants to see a greater relationship between CloudBees and the Jenkins community.
To achieve that he is pushing contributors to change their approach. He is challenging them to change the way they create plug-ins. Don’t create something that is updated occasionally. Embrace continuous integration and continuous delivery (CI/CD) and deliver regular updates.
This is a major step change for open source software. There are few, if any, communities that deliver on the promise of CI/CD. If Kawaguchi can engage the community and deliver this it will be pure gold for Jenkins. Importantly, it will galvanise other open source software projects, especially those in DevOps to follow suit.
Another example of the relationship between CloudBees and the Jenkins community is that the first day of the conference was given over to a contributor summit. This allows all those contributors to come together and contribute to the future of Jenkins. It also allows CloudBees to give its version of the future for Jenkins and garner support from the grass roots over the direction it wants to move in.
Products galore but when?
No conference would be complete without a raft of new product announcements and this one did not disappoint. Kawaguchi kicked it off by announcing five new products or super powers:
- Jenkins Pipeline
- Jenkins Evergreen
- Configuration as Code
- Cloud Native Jenkins
- Jenkins X
Some of these are updated versions of old products, others are new. All were talked about in the contributor summit. Importantly, these are not discrete offerings. They all come together in what CloudBees Chief Product Manager, Christina Noren calls CloudBees Suite. This is the new name for Jenkins Enterprise.
They were not the only products that were talked about on stage. DevOptics, introduced last year is to become a free product. Blue Ocean is to become the Jenkins UX and become part of the core product.
CloudBees Core v2 is the successor product to Jenkins Platform and Enterprise. It allows customers to run where they want – VMs, bare metal, servers, Kubernetes. It’s successor, Core v3 will be a new software delivery engine unlike the existing Core products. It has been built from the ground up for governance and software delivery processes.
CloudBees CodeShip is a fast and easy SaaS solution that has come from the acquisition that CloudBees made earlier this year. It is the first acquisition that CloudBees has made to expand the Jenkins universe. Will it be the last? Can CloudBees acquire projects from the community without impacting the community? Will it look at its partner base to see where it can accelerate its long-term goals with a strategic acquisition
Are roadmaps a thing of the past?
There is a big question here for all of these. When? That’s a difficult one. Noren is not one for product roadmaps. In fact, CloudBees believes that it is time it delivered on DevOps in the way it ships products. The loose coupling of these components will come sometime this year. Beyond that, there will be a continuous drop of new features and updates. This is what we are seeing from a number of cloud-based vendors but for CloudBees this comes with some risk.
The first of those risks are that it is supporting multiple platforms both on-premises and cloud. That means multiple code bases which creates a challenge in keeping software up-to-date. For the cloud-based versions it can update the software continuously. On-premises installations will be at the choice of the customer.
Another challenge is that continuously adding new features sounds great. Inside enterprise IT departments it creates a challenge. They want a roadmap, something that they can plan around. At some point there will need to be major releases. Look at Core. From Core v2 to Core v3 there has been a major rewrite that changes how the product works. Customers will want to know this and Noren need to talk about how that will be done.
Here, therefore, are the two nuggets that could be either our gold or fools gold. How it turns out we will only really know by next years conference.
From DevOps software to CRM for software development?
Sacha Labourey, CEO, CloudBees likes to drop surprises at the conference. This year it was Jenkins as a CRM. It’s an interesting concept. Labourey talked about how CRM was unpopular and complex until cloud came along. He likened that to how many view release processes for software. He says that both are key repositories of core data inside an organisation.
Labourey wants DevOps to be a repository that allows managers a total view of what is going on with software inside their organisation. They can see what developers are doing, the state of software projects and deliver quality, efficiency and release insights. This is not new. Attempts to create a 3D view of software projects have been going on for two decades. All have struggled to widespread adoption as it is hard to gather the right metrics and analytics.
What the past projects didn’t have was DevOps and Labourey sees this as the game changer. The use of pipelines, shift left to bring security and testing into the development process and a better choice of metrics make it possible to gather all the data into a single repository. Importantly, all of this is done through automation that doesn’t impact the way that DevOps teams work. The result is better governance.
There is a big but here. CRM is no longer the misbegotten child of IT. Cloud and continuous delivery have seen to that. What they have also done is vastly increase the scope and reach of CRM. Accounting, stock control, supply chain management and a wide range of other roles are now part of CRM. The question is can DevOps deliver that same increased scope? If not, should be consider that a failure of DevOps or a failure of the enterprise to adapt?
Can DevOps deliver wider enterprise benefits?
The answer is yes but only if there is a change of thinking about what DevOps is. DevOps has to appeal to the business outside of IT. Here are three examples of that.
Compliance: Organisations have to deal with compliance which can be incredibly complex. To implement it they create steering committees, examine the legislation and create an action plan. That is reinterpreted by IT who delivers something close to the plan. It is never really audited and any change means repeating that process all over again.
DevOps breaks complex requirements into simple and automatable steps. Changes to legislation can then be easily applied and pipelines updated. Pipelines are transparent and can be run in parallel, it makes it easier to understand and then audit compliance requirements. Sound a little fanciful? No! What it sounds like is a product idea either for CloudBees or a partner.
Process Re-engineering: As software development and delivery speeds it create an issue with business processes. The latter change slowly, glacially even. They are certainly at odds with the most views of CI/CD. But are they both so diametrically opposed in terms of time and space? No.
Teams that are delivering well on CI/CD now use the software to define the new business processes. As the software changes, so does the business process. DevOps, pipelines and CI/CD are the new Business Process Re-engineering that is intrinsically bound to the software.
Incident Response: This is an inherently complex problem for many businesses. They have large, complex and rarely tested playbooks. A few weeks ago, Atlassian launched Jira for Ops. It also purchased OpsGenie to deliver an incident response solution.
Atlassian is already looking at to apply DevOps principles and pipelines to incident response. It allows for multiple pipelines to control different responses from IT, legal, HR, marketing, the C-Suite, external PR agencies and even regulators.
Can Labourey turn CloudBees into the Salesforce of CI/CD?
Labourey didn’t go this far. He drew parallels with developers and sales teams. Both benefit from automation, neither likes to be micromanaged and a DevOps approach delivers governance, transparency and improves productivity without being intrusive.
The question is can CloudBees be the company that leads CI/CD and, by extension, DevOps into a wider engagement with the enterprise? It has the capacity to deliver the three examples above. In addition, Labourey has the vision. He has already secured US$68 million in funding to help define the vision but can CloudBees deliver? Importantly, can it deliver before anyone else, such as Atlassian?
What did conference delegates and partners think?
The success of any conference is in how well it is received by those attending it. Some conferences rely on whipping audiences into a “hell yeah” frenzy fed by staff members scattered throughout the room. Jenkins World didn’t need that. It was clear that those who turned up early for training sessions, certification and the contributors summit were wholly engaged with what was announced.
Talking to partners in the showcase the story was just as positive. The new announcements were well received. The approach to deliver new features, updates and fixes in a CI/CD approach was seen to be challenging but exciting. Oddly, not a single vendor spoken to was willing to commit to when they would do the same thing.
It seems there is a separation between contributors and partners. This could mean that partners are still trying to think what it all meant for them. It could also mean that they are a more conservative bunch and want to see proof points before they jump in.
Despite this more conservative approach from partners, the energy was high. The one question nobody wanted to answer however was: Who should CloudBees acquire to strengthen the product line?
What does this mean?
Overall the conference was more like mining and prospecting that you might think. There are clear indications of gold strikes with some of the product announcements. These will pay off and there is an army of contributors willing to turn miners to make it work.
CloudBees is also willing to invest in some prospecting. The big picture that Labourey threw out with CRM could turn out to be the mother of all strikes. It could also turn out to be little more than a seam that is quickly worked out. It needs to do more to define this CRM approach and deliver tools that can not only manage the delivery processes but also deliver on the wider vision of DevOps across the enterprise.
Having doubled the number of staff (bees) to over 400, Labourey and Kawaguchi have a growing army of prospectors. Some of them are producing big finds such as Jenkins X. What is needed is a steady stream of these and not just from CloudBees itself. Kawaguchi has already engaged the contributors in the idea of CI/CD rather than traditional plug-in development. How long before they deliver?
Over the next year we will get a better view as to whether Labourey, Kawaguchi, Noren and the rest of the marketing team have the golden touch. There is always the risk of a pitfall but if CloudBees really can do CI/CD around the products it can always fall back on the adage: If you are going to fail, fail fast and fail often.
