DevOps Tool-Chains - Are We There Yet ?

In many ways, in spite of international standards and protocols put in place, technology products continue to be limited by the constraints of the “ecosystem” established by key technology firms, forcing users to adhere to a specific set of tools and products. One such example is the Bluetooth technology, which, in spite of having established international standards, does not work between devices of different stables ( I would refrain from taking names here, but you know the usual suspects ). Eventually, it all comes down to making customers forcefully loyal rather than giving them the choice of preference.

The DevOps world is no different. Big players in the game continue to create a suite of tools and products for the entire SDLC, and create their own “ecosystems” which function perfectly well, until all of them are from the same stable. However, when organizations want to adopt tools from different offering vendors based on true merit and capabilities, hell does break loose. Ranging from simple licensing to interactions, data exchange, compatibility and upgrades, every aspect becomes nothing less than challenging, calling for customizations, specific contractual agreements with vendors on support and a myriad other aspects that eventually make the consumers nothing less than slaves. The paradox here is that this is the state when the industry is moving towards everything “As A Service”.

In today’s world wherein automation and tooling are supposed to make our processes and operations more efficient and productive, the need for collaborative offerings in the market that fulfil the consumer’s needs without added clauses is more important than ever, based on the following criteria :

1. Platform Independence – DevOps does not limit who should and should not talk to each other. Collaboration has to happen not only between people, but between tools as well. We should have tools that can e integrated with each without the need for additional emulators, and make tool-chaining seamless and easy.
2. Scalability – As organizational business grows, the technology should remain at par, so it essential that tooling and automation investments are easy to scale, without having the need to have alternate solutions. While moving from on premise to cloud solves a part of this problem, the performance aspect  should not be ignored.
3. Data Exchange – Pipelines and tool chains in DevOps are not intended to be siloed implementation of tools across the SDLC phases, but a “connected system” that can pass key information downstream to trigger outcome-based actions. Tools and products should exchange data, even if it just happens to be plain XML.
4. Integration APIs based on global standards – If tools begin to offer integration APIs based on standards, especially given that technology is no longer an impediment, DevOps implementations and tool-chains will be more easier to implement and configure than ever before.