While DevOps principles have been around for above a decade now, the term itself was coined in 2009 only and is now surrounded with a plethora of myths. We try to burst them out today.
The main reason for so many misconceptions floating around is the fact there is no clear definition of the process, just several general explanations. This leads to the situation when different people get different impressions and make different conclusions regarding the same ideas, practices or tools. This, in its turn, leads to a variety of myths, mostly being spread by pushy sales specialists of the companies offering DevOps as a service.
We are not such a company and our customers trust us to deliver an integrated approach to transition to DevOps. This involves in-depth analysis of the infrastructure, software ecosystem and business workflow in place, developing the most suitable solution, implementing it (with moving the infrastructure to the cloud if need be) and training the customer’s IT team to help them embrace the DevOps methodology and culture across the product & service delivery pipeline.
As we put it, DevOps is a set of approaches, practices and tools, leading to implementing the culture of collaboration between teams and team members, building an immutable infrastructure as code (IAC), continuous integration (CI) of new software features and continuous delivery (CD) of software and services.
However, many businesses are still wary of beginning their DevOps adventure, mostly because of the aforementioned myths and misconceptions. We list and demystify them below:
We will explain what actually stands behind these myths, so you can see for yourself what DevOps actually is — and what it is not.
As we said above, DevOps is actually an integral approach to software delivery processes, as well as a shift in business workflow and culture, emphasizing communication and collaboration between the team members. This cannot be achieved by simply training developers to use IT operations team’s tools and vice versa. It is a slow and all-embracing process of building all-around capable teams of highly-skilled and motivated professionals.
DevOps should not be perceived as a limited set of solutions or practices that can be mastered in a relatively short period of time. As there is no limit to perfection, DevOps is rather a continuous movement, aimed at automating the routine, increasing the infrastructure reliability and resilience, ensuring any team member can deal with any task at hand. This task cannot ever be completed but must be taken as an ideal situation the team strives to achieve.
Automation is indeed essential for implementing the cornerstones of the DevOps paradigm: IAC, CI and CD. However, automation is merely a solution to reduce the routine and should never be considered as a goal on its own. Automated unit testing helps deliver predictable, clean code, released at regular intervals.
The other part of automation goes for deploying the infrastructure with several commands. When servers are provisioned with a single command and the needed environments are deployed using preconfigured Docker containers, the software delivery pipeline becomes much more efficient, ensuring the process predictability and great user experience. The team can actually come to a point of 5 deployments a day, but it is a result of a great collaboration, not the goal of the process.
This cannot be farther from the truth, as the DevOps culture blossoms atop the Agile methodology principles, shares common values and utilizes the same imperatives. It is all about preferably small, all-around capable teams of professionals delivering the code in rather small chunks, ensuring stable functioning of the software product or service and uninterrupted end-user experience.
The main difference between working under DevOps and InfoSec/ITIL doctrines is the “shift to the left.” This means all compliance and security checks should be taken into consideration from the very beginning of the software development process, thus shifting to the left along the software delivery pipeline, to the earliest terms possible. This is yet another reason for producing clean and efficient code, fixing the bugs early and delivering the software and new features in a timely and reliable manner.
DevOps engineers are definitely not wizards and while many of their tools, responsibilities and skills are aimed at infrastructure maintenance and improvement, they heavily rely on the wholehearted support from other departments in order to be efficient. Actually, a successful DevOps buy-in must come from the C-suite and all the way down to the grassroots, transforming the whole business workflow into a more predictable process, ensuring deep customer satisfaction and improved ROI.
We hope we were able to dispel some of the most popular myths of DevOps, though there are a plenty more. The point is, DevOps is not a panacea, not a magic wand and not the superweapon. It’s merely a tool, quite a complicated, yet a really useful one. It is a mix of attitude towards the colleagues, the workflow and the business processes in the company as a whole.
When used right, DevOps methodology allows reaching astonishing results, but it is a double-edged sword: falling for the fallacies and myths of DevOps can cost the businesses dearly. This is why working with a reliable contractor to establish or polish DevOps processes in your business is the way to get great results while staying on the safe side.
Previously posted this hint on my company’s blog.