I receive a lot of requests from companies and individuals for DevOps job openings, and what I usually see in the job descriptions sometimes really upsets me. It seems that many people just don’t get what DevOps is and use this term as a buzzword to attract attention or to look cool. So, let me try to clear the air of what DevOps is and isn’t.
DevOps is not a person
Many people and organizations perceive the term ‘DevOps’ as an engineering position to be fulfilled by a candidate with a specific skill set. This point of view can be seriously misleading for those who don’t know its origin and don’t understand its concepts.
If you are familiar with ITIL, you might find the term ‘ITIL engineer’ a bit frustrating. ITIL is a set of practices that proved useful in solving some common challenges in IT service design, operation, transition, etc. These practices define multiple roles for different processes, and no single person can efficiently perform all of them at once.
The same is true for DevOps, which is also a set of guides and principles, a methodology for solving common challenges in organizations employing developers (Devs), IT Operations (Ops) and many other kinds of specialists in security, quality assurance, testing, etc. This set of practices is already quite extensive to be implemented by a lone warrior.
I don’t know why and how exactly the methodology name was forged into a job title, and I can only assume that multiple misconceptions about the term ‘DevOps’ might have happened due to the lack of an official definition for it and a mature organization that would structure and organize DevOps practices for consistency. Maybe, in the future, the IT Revolution might become the same for DevOps as AXELOS for ITIL and introduce some standardization into that area. However, currently, the reign of ‘DevOps Engineer’ positions continues, and, from my experience, such simplification leads to the distortions of core DevOps values and to misunderstanding of what problems DevOps is intended to solve.
Jack of all trades
As I’ve already mentioned, the DevOps methodology addresses many problems in different technical and organizational knowledge domains. The sad tendency to simplify the adoption of DevOps to “Hey, let’s hire a DevOps engineer so we can also call ourselves a DevOps organization…” created job descriptions with such exaggerated lists of requirements I hardly believe they can be fulfilled to the full extent. According to some such descriptions, a candidate should know so many things that, if you translate them into a common language, he or she must know accounting, genetics, how to operate a crane tower, pilot an air balloon, be able to build a space ship from scratch and bake cakes. Sounds weird, don’t you think?
Another caveat is that an average person simply cannot be an expert in so many different areas. Sure, there are generalists skilled in many technologies and tools, but their knowledge is usually shallow and covers only the basics. Unfortunately for them, DevOps is about solving quite complex cross-technology problems, which often require a high level of expertise and considerable experience.
Of course, few pros on Earth are strong experts in tens of areas, but the majority of developers, system administrators and other professionals tend to be experts only in one or a few fields with basic knowledge of relative ones—to have a so-called T-shaped professional profile. The reason for that is simple: the speed of technology development is so fast that it requires a lot of time and effort to keep up with recent changes.
DevOps department
Another huge misunderstanding of DevOps ideas that really blows my mind is when I hear that an organization created or wants you to create a DevOps department.
The origin of DevOps is the problem with communication between Developers and IT Operations, who work in different organizational units. So, let’s create a third team to solve the issue with the first two. A wise strategy! Are you serious?! This is one of the worst possible decisions you can make.
Until there is a single team, there always will be “us and them(outsiders)” and not “we.” If you are unfamiliar with organizational theory and don’t understand how people communicate, at least go and study Conway’s law.
CI/CD, containers and other stuff
I also meet a lot of people who honestly believe that DevOps is about configuring pipelines in Jenkins and having all application components run on containers in Kubernetes or knowing how to administer Linux servers and run microservices in AWS, or, holy grail, automating everything with scripting to “…rule them all.” Yes, technical practices of DevOps are essential, but without a clear understanding of the underlying ideas, they could bring more harm than value.
Let me repeat once more: DevOps is not about tools. Forget about them. DevOps is about three core principles:
Reducing the lead time and increasing the overall speed of the delivery process.
Shortening the time needed to get feedback on changes you introduce.
Encouraging you to learn from the received feedback and to adapt your processes to obtain the desired outcomes from them.
Yes, it sounds somewhat simplified, but this is the backbone of DevOps. The tools might change, and the technologies might evolve, but they are only the helpers in implementing the mentioned ideas. Continuing the analogy with human biology, putting the tools first is like trying to create a body from organs and tissues without a firm skeleton.
Organizational vs. technical problems
I’m deeply convinced that DevOps, as a methodology, is more intended to solve organizational issues rather than technical ones. Such issues just cannot be solved by injecting DevOps engineers into your existing organizational structure and thinking: “That’s it. Done. We now have DevOps.” This mindset reminds me of the joke about lipstick and a pig. Just putting a ‘DevOps’ label on your organization or having job positions with ‘DevOps’ in their title doesn’t make your team work according to the DevOps principles.
Implementing DevOps in your organization requires equal involvement from the management as well as from the engineers: a willingness to change, to overcome obstacles, and to understand the benefits each party will have from this transformation. In my opinion, the hardest part of this transformational process is exposing those benefits to each member of the team and translating them into the language they can understand with their current level of expertise so they become the ones who will start implementing the changes.
Also, from my experience, if you, as an in-house engineer or external consultant, just implement some technical aspects of DevOps, such as CI/CD or deployment automation on your own, it won’t make any significant difference for the organization’s overall performance. These changes likely won’t last long and will be abandoned as soon as you leave to pursue new endeavors.
If you are interested in a better understanding of what DevOps is and what it is not, I strongly encourage you to study the origins of this methodology and to read the classics such as “The DevOps Handbook,” which I reviewed in one of my blog posts. If you would like to have more proof and supporting data, you might consider studying the analysis of DevOps' impact on organizations performed by Nicole Forsgren, Ph.D., in her book “Accelerate: Building and Scaling High Performing Technology Organizations.”
