DevOps-as-a-Service…Is it Tool or Process?
There are many books and blogs are written on DevOps. Some popular definitions are “DevOps is a process enhancement”, “it is a way organizations can implement cultural change”, “collaboration between IT and Operations” etc. In the world of everything as a service, “DevOps-as-a-Service” is the new jargon that is thrown into mix, what does it mean? Can we really have “cultural change” as-a-service?
We implemented DevOps solutions at multiple customers including some Fortune 50 companies. Depending on the size and scope of the solution, DevOps implementation approach varies. There are customers that would like to define the process and tools at enterprise level and leave the implementation to individual organizations, there are some that implement (host) the tools at enterprise level and mandate the usage of only those tools across enterprise. There are few customers where DevOps implementation is only at individual group level but this number is shrinking fast. None of these approaches alone fit the classic definition of “as-a-service” (on-demand availability)
In our experience, one part of DevOps is to put tools around agile methodology to fail-fast, fail-early for better code delivery. The other part is defining and enforcing processes/policies around these tools (ex: code must always pass code quality test). While process can never be enforced on-demand basis (who wants more process?), but this can be implemented using on-demand DevOps tools (ex: Invoking SonarQube in build pipeline is not optional).
The challenge with above approach is, how you enforce such process (how are you going to catch me for not using SonarQube?). In our experience, solution for this type of process enforcement is best implemented when Enterprise DevOps is offered as a Service, but it is not just hosting bunch of tools that development groups can use as on-demand, but end-to-end tool chain is hosted as a service. Enterprise architecture team prescribes tool chain for type of applications (ex. Java vs .Net vs. ERP etc.) and enterprise implementation team implement the tool chain and offer as a service.
Now, how do you sell such hosted offering for individual application groups? In today’s world, every application group has some sort of build automation, the hosted offering takes away the pain of doing your own automation but it comes with price of following defined process. There should be enough flexibility in the process, you decide threshold of checks to complete build and deploy steps (ex: Using SonarQube is not optional but what is checked and imposed is defined by you).
In summary, DevOps-as-a-Service becomes a reality when process and tools are combined in offering as-a-service not just hosting set of tools and expecting to achieve cultural change.
About the Author
Director – DevOps and Cloud