Many myths circulate around the DevOps movement. This is no surprise, considering how popular and also inflationary the term has become in recent years and is thus also used at almost every opportunity. So today we want to take a closer look at a few of the most critical "narratives" so you know what DevOps is all about and how to properly implement it. In this blog post, we'll take a closer look.
Myth 1: DevOps is only for Dev and Ops
Although the term originally started out as “only” for Dev and Ops, this was due to the background that the biggest problems were seen there at the time. The so-called Wall of Confusion had the greatest effect on the two disciplines at the time DevOps was created. Nevertheless, we are in a constantly changing and more extensive world. Where once one developer was responsible for the entire product lifecycle, today there needs to be dedicated experts for each of the disciplines (Dev, Ops, QA, Sec, Agile, etc.). This increasing complexity requires extraordinary communication to continue to productively deliver secure and high quality software. Accordingly, it quickly becomes apparent that DevOps must not be applied to just two of the now myriad areas. Otherwise, we run the risk of creating the very things we actually wanted to break down with DevOps: poor communication, silos, an “us and them” mentality, etc.
At the heart of the issue is often the naming of the process. DevOps as a portmanteau word implies that it is just Dev and Ops. Thus, myths like this are bound to happen. This is one of the reasons why we want to migrate the term DevOps within Novatec more and more to “perfect Flow”. Last but not least, this helps us to establish and continuously improve the holistic transformation process not only for us internally, but also for our customers.
Myth 2: DevOps is just a tool
The market around DevOps is growing steadily. This is not least due to the fact that the term has been strongly popularized in recent years. Tools like Azure DevOps specifically try to address the needs of completing a DevOps transformation. The focus of Azure DevOps here tends to be to make all the necessary individual tools, which are required for the development of the entire product lifecycle, usable centrally in one place. The common assumption now is “if I use Azure DevOps, I do DevOps”. Unfortunately, this is not correct, as the process towards a DevOps organized company is much more difficult and complex.
While Azure DevOps is enormously helpful, it only covers a large part of the technical aspects in that context. Equally important in this context are the cultural conditions that must be met in order to ensure a transformation. Without an adaptation of the internal processes and structures to match the new technical conditions, various positive opportunities will be disregarded. Within Novatec, we view DevOps under the three pillars: Business, Culture and Technology. If we act purely on the tool or technical level, we lose the trinity and thus two thirds of the topic.
Myth 3: DevOps Engineer
The eternal search for the egg-laying willy-nilly also exists in the DevOps context, of course. Historically, the basic approach behind the DevOps Engineer was a good one. It was to fill a newly created gap around the field of automation. DevOps Engineers are therefore developers who have put their focus on automation or Ops’ers who have a stronger focus on development. Due to the ever-increasing complexity, the field of activity of a DevOps Engineer is therefore also growing.
The core of the problem is therefore on the one hand the very inflated DevOps term, which cannot be fully understood in its entirety, and on the other hand the desire to fill the aforementioned gaps as broadly as possible. Unfortunately, this problem also extends to recruiting. How do I find exactly the one DevOps engineer I need specifically for pipelines, for example?
Job descriptions such as “DevOps Engineer with a focus on pipelines” are helpful here in order to narrow down the market accordingly. It is therefore important to structure the overloaded term neatly into categories, to cut it and thus provide space for a precise job description.
Myth 4: I can create a DevOps team and then “run” DevOps
Similar to the DevOps Engineer myth listed earlier, simply launching a DevOps team causes silos to build up, which we originally wanted to reduce and prevent. By having a dedicated DevOps team, we deliberately compartmentalize the benefits around DevOps, encapsulating them in one team and, exaggeratedly speaking, “locking it away.” Not only does this help us block the transparency, collaboration and knowledge sharing we want, but it also puts another bar on inter-team communication. Where before there was an operations team and a development team that could not adequately communicate with each other, now there are three teams that can do so even less. Thus, nothing was gained except a semblance of DevOps.
Myth 5: DevOps is a finite process
DevOps, or the so-called “DevOps transformation,” is a constantly changing, iterative process. There will always be the opportunity for new improvements and new ideas. Processes can be further streamlined, silos further broken down, and communication channels further improved. A simpler way to imagine it is to think of DevOps as a freight train that first needs to be refueled, starts its journey, but never fully reaches its destination. The DevOps train has many stops along the way where it delivers its goods for the respective locations where they will (hopefully) hit fertile ground. At each stop, the train must be refueled so that it doesn’t come to a stop halfway through its journey. This fertile ground often simply means having an openness within a team to new changes.
The continued refueling of our DevOps train ensures that the transformation receives the necessary backing. The interesting and exciting thing about this analogy is that no two DevOps trains look the same or even exclusively travel the same routes. For every company that wants to establish DevOps, the starting point and all the stops in between look different. Each company has its own personal characteristics and problems, which need to be solved in a differentiated manner in a process that is always moving forward. Once again, the journey is the destination!
Myth 6: I can integrate the same processes as Amazon, Google, Netflix and Co.
As already started under “Myth 5”, every company has to find its own way. It would be wonderful if there was only this one process to follow to successfully establish a DevOps transformation. That would make our day-to-day work as DevOps consultants much easier. But unfortunately, this is not the case. Unique structures, processes, problems, communication channels, company policies, etc. ensure that every transformation must be rethought, carefully planned and ultimately tailored precisely to the needs. Where does the shoe currently pinch the most? For example, to ensure the necessary management buy-in, it makes sense to solve the greatest pain and at the same time generate the greatest added value. Such decisions set a clear direction that is unique to each company.
Myth 7: DevOps vs Agile
Both DevOps and Agile are mindsets that can be used for software development. DevOps builds on and leverages Agile concepts in many ways. Nevertheless, you don’t have to be Agile to be able to establish DevOps. Of course, it helps enormously and follows the natural flow of processes. However, there has to be the space within a company to apply agile methodologies. In some industries, it is still not possible due to external circumstances to cut work packages into individual parts and process them in defined cycles. Therefore, the reality here is still that the waterfall methodology in project management has its raison d’être for just such companies.
Nevertheless, we advise it: If external circumstances permit, Agile and DevOps should be used together. DevOps works particularly well with Agile because the basic principles of small teams delivering software iteratively can be used as a foundation to not only prototype DevOps at the start of a transformation, but also to align it for long-term scalability.
Conclusion:
We hope we’ve been able to dispel a few of the myths surrounding DevOps. Our concern is that our readers familiarize themselves exactly with the possible myths before starting a transformation and hopefully avoid them completely. Studies such as those conducted by DORA or Puppet clearly show that the above-mentioned stumbling blocks are not only enormously time-consuming, but also very expensive. In the worst case scenario, the pitfalls highlighted will burn the concept to the ground, unfortunately bringing the DevOps train to a longer-term or even final halt.
Feel free to let us know which DevOps myths you’ve stumbled across so far.
By the way, there will be more blog posts about DevOps topics here in the future. So: Stay tuned!
Top comments (0)