So far, the IT community does not have an agreed-upon definition of what DevOps is. There is however clarity about its goal. Put simply, DevOps accelerates IT service delivery enabled by agile and lean practices. That’s it? Yes. It’s easy to understand but very hard to execute.
With the widespread adoption of cloud technologies, it’s not a secret that today’s IT world is ruled by software-defined solutions. But the software must run on hardware that needs 24x7x365 support. So, how can businesses use these two apparently opposite concepts to create a new way of working that ensures an endless loop responding to high-frequency releases? The starting key is combining communication at the team and technology level.
However, in this process of developing this new way of working, we’ve seen the emergence of numerous myths and common errors. I want to share my thoughts on what I see as the five most prevalent.
The 5 most common myths of DevOps
- DevOps is a standard strategy. As I mentioned at the start, there is no universal agreement on the definition of DevOps. The DevOps Cookbook, for example, defines “DevOps as the result of applying efficient principles to the IT value stream”. Others have described it as “a movement of people who care about developing and operating reliable, secure, high-performance systems at scale.” It is generally defined as a new form of organization, a culture, or even a new way of thinking. But the important point to make here is that every organizational DevOps journey is unique – there is not, and there should not be a standard strategy for every business.
- DevOps is a single tool-based solution. There is no single DevOps tool that can bring together everything into one solution. In particular, it’s not possible to combine, into one solution, the collaboration and integration of teams of developers, testers, and operations, linking both business and IT processes. Every organization and its needs are unique, and will usually require a multitude of tools depending on your circumstances.
- DevOps is not a strategy for everyone. When establishing the adoption strategy for DevOps, executives need to consider a diversity of business technologies and drivers. To find or build a landscape that covers your needs is always possible – and it may well be the case that the ideal solution means adopting elements of DevOps, rather than pushing your foot on the accelerator and going for a wholesale transformation. For example, for your specific business, it may be fine to release software monthly, not daily. Put simply, your ideal strategy depends on your business goals.
- DevOps is just automation. While DevOps involves automation, it is also much more. The acronym “Keep CALMS and DevOps”, gives a sense of what is really required. According to the CALMS framework, by using Lean (L) we must eliminate any waste to promote at least the right Measurement (M) and create a Culture (C) of team cooperation (automation and sharing are the other elements of the framework). To do so, we have to shift the paradigm to point development & operations towards the same north. Most importantly, CALMS emphasizes how DevOps is so much more than just automation.
- DevOps means creating a new team which is separate from other IT areas. Having a separate DevOps team defeats the purpose of avoiding possible friction. It also defeats the objective of creating more communication between developers and IT operators, as it creates one more silo. Going back to the CALMS framework, never forget the “s” at the end which stands for sharing. Sharing experiences is one of the most important elements in every organizational DevOps journey.
In my next article I will explore how businesses can start to build a DevOps operational model – with insights based on Globant’s work with hundreds of organizations going through their DevOps journey.
