At the Jenkins World conference in San Jose, 14 leading DevOps vendors have come together to create DevOps Express. The list of members is impressive and includes many of the leading open source DevOps providers. There is also a new DevOps Express website (www.devopsexpress.com).
The press briefing to introduce DevOps Express was interesting. Those vendors who were in the room seemed surprised when faced by some hostile questions. Many of the press were unimpressed at the lack of substantive announcements. There were also concerns as to what metrics were in place to judge whether this would be a success or failure.
What is DevOps Express?
It’s simple. Driving greater adoption of DevOps by removing the complexity and making it easy for companies to get started. There are three main pillars:
- Connectivity Assurance: DevOps is about collaboration. What the founding members are promising is that they will improve the interoperability of the DevOps toolchain. They also want greater integration between products and more collaboration across solutions. It sounds like good news for customers.
- Integrated Support: A customer experiencing problems with the interoperability between solutions will not be bounced between vendors. The goal is that one vendor will take control of the support call and work with the customer. They will help diagnose and resolve the issues between products. They will also provide a streamlined support ticket exchange to ensure a coordinated response to the problem. According to Sacha Labourey, CEO, CloudBees: “This is a variation on the Red Hat model that it offers to customers.”
- Best Practices: This is to provide customers with a way to get started. Each company has its own view on best practices. What is to happen is that the best of these will be published on the DevOps Express website as part of a best practice repository. Customers can then choose from the various ways of doing things.
It all sounds like good news and the sort of thing that industry groups have been doing for some time. What is different here is that the main point of commonality for each of these companies is Jenkins. They all interface to it at the moment and that makes this look like a coalition of the willing.
So what got the press all hot under the collar?
There was concern that this was about “pay to play”. How would the members prevent this being a closed club that would lock out competitors and even lock-in some members. The whole idea of “pay to play” was denied by the vendors. There is no money or membership fee required and it is open for others to join if they want to.
Another concern was around who was part of DevOps Express. The membership is initially made up of only vendors. There are no System Integrators or even practitioners mentioned in the announcement. It was suggested that this would put off a lot of practitioners who would see this as vendors imposing an approach to DevOps.
The idea of best practices also raised a lot of questions and some heated discussion and differences between the press and the vendors. Some of the press felt that best practices were overrated and irrelevant. While some vendors disagreed and felt that best practice provided customers with a start point others did not. The DevOps Institute said the market was tired of talk about the elusive best practice. What was needed was more discussion about emerging or practical practice. CA Technologies disagreed. They said that the gap between conceptual and real world implementation was significant. Customers want a way to get started so the solution is to provide best practice and share with new insights from different vendors.
Where are the reference architectures?
All of this led to the question of; where were the reference architectures? During the initial stages of setting the DevOps Express group up, there were conversations with SI’s and partners of various vendors. All of them asked for reference architectures that they could use. Customers also wanted reference architectures that they could use to build their own DevOps environments on. One of the advantages of a reference architecture that the vendors agreed on was that it will make it easier to interoperate. It will also help those customers with multiple DevOps solutions in place today as they look to integrate them to improve automation and share information.
Currently there are no published reference architectures from DevOps Express. This is because all of the vendors involved have their own architectures. The challenge will be deciding whose reference architectures are published or whether there is a common architecture. This will be discussed at the first technical meeting in October.
Integration is the key
One of the biggest challenges here is the integration matrix. The only thing that the vendors have in common here is their integration with Jenkins. They all agreed that they were not interested in building their own large set of integrations to all of the other members of DevOps Express. So what is the solution? CA Technologies said they would open source their integration code. The idea being that the community would then provide all the integration.
The problem with this is that it doesn’t provide the connectivity assurance that is promised. If the community has to create all these integrations, who will then maintain them? Every time a vendor releases a new version of code, will they test the integration with all the other vendors and those plugins written by the community? The answer is no. The only concession seemed to be that if Jenkins released a new version the vendors would all validate against that.
Part of the problem here is that all of the vendors have their own RESTful API’s. They are unlikely to agree to a common set of API’s for integration. In fact, it appears that they haven’t even discussed this issue and won’t until their first technical meeting in October. One solution might be for someone, perhaps the DevOps Institute to take on the role of managing the integration testing between vendors. This was something on which nobody chose to comment.
Will it be possible to move part or all of a DevOps process between vendors?
This is about taking a DevOps job from one vendor and importing it into another vendors product. It could be as simple as exporting as an XML file and then importing it. The job is then mapped into the new vendors system. If not XML then there are other options here. What this offers is a faster way for standardising how the DevOps processes are implemented.
What does this mean in practice? A customer decides to change the tests that any new application must pass before going into production. It has four different DevOps products used throughout the organisation. Rather than rework the process for each product, it develops and approves it once and then imports it into all the other DevOps products. This ability to duplicate something that is successful is key to speeding up deployment.
Atlassian is interested in this approach. To really make it work they think it would rely on machine learning to understand the difference between DevOps products. CA Technologies also felt that this could help companies move forward quickly and improve the take-up of DevOps.
Will there be a common plugin store?
This question was also not answered during the press conference. After the conference several vendors said that they couldn’t see this happening at all. This is because the goal here is to create interoperability between the vendors not to homogenise their solutions.
For developers this is disappointing. It means that they will continue to develop plugins for each DevOps vendor separately. Ironically this goes against the whole idea of DevOps which is to reduce the waste and improve the automation. There is a possible solution though. Jenkins Pipelines already makes it possible to design an automated flow where code is tested against multiple browsers. Perhaps the solution here would be to create tests that run against the various APIs from different DevOps vendors. This would reduce the number of jobs that each development team would have to create in order to test their code.
Conclusion
This is an interesting announcement from a group of DevOps providers with a common cause. They are adamant that this is not about a “pay to play” but more a coalition of the willing who want to make DevOps easier. This sounds great but the devil, as always, is in the detail. In this case the detail is sadly lacking. The first technical meeting of the vendors won’t take place until sometime in October. It is hoped that a roadmap will emerge from this meeting so that other interested parties and end user customers can see what DevOps Express is planning.
Anything that can improve the penetration of DevOps is good news. The big question is can DevOps Express deliver a simpler world for customers looking at DevOps. Or in a years time will it end up as another great idea that failed to deliver?
Disclaimer: Enterprise Times is attending the Jenkins World conference courtesy of CloudBees who have paid for hotel and flights.
