DevOps can sound perfect: shorter paths to deployment, simpler processes, more communication, better handling of errors. Of course everyone wants these things for their organization; nobody would disagree here.
But this list of virtues and good ideas is not enough; the theory must be put into practice, meaning that these virtues and ideas must be lived and become part of the DNA of your team and the organization. In fact, this is much easier said than done, because, naturally, things often go wrong when implementing DevOps.
Typically, things go wrong when a company does not understand DevOps as a whole or incorporates only partial aspects of DevOps: No, a joint Slack channel for the development and operations teams is not enough to implement DevOps.
In this blog post, we’ll discuss the common mistakes and misunderstandings of DevOps that you should be aware of.
Too Strong a Focus on Automation
Every now and then companies and teams introduce DevOps into their workflows but focus too much on automation, either ignoring the other aspects of DevOps or focusing far too little on them. In the end, these companies and teams have often only achieved the A in CALMS, have not established the right culture, and have ended up with a lot of waste. They do not track metrics, and sharing is still a foreign concept. The figure below shows that they have not erected a solid building in this way.
In these scenarios, the companies hire DevOps engineers, who write and maintain a CI/ CD pipeline, and that’s it. Although a CI/CD pipeline is an elementary component of the technical part of DevOps, it does little to change the other aspects; the teams continue to work in exactly the same way as they did before.
Often, CI/CD pipelines can be run fully automatically in theory but only after a senior manager who may not have been involved in the technical implementation or who cannot assess the quality of the project has approved the deployment. This means that an important aspect is missing—namely, the assumption of responsibility by the team.
The result is the worst of both worlds: cumbersome manual processes and additional technical overhead due to the tools of a CI/CD pipeline, which now has to be maintained in addition to the actual product.
With DevOps, but without Tests!
One prejudice that is often heard is that DevOps produces much worse code, as the changes are rolled out far too quickly. And the assumption is that if something is produced quickly, then it must be of low quality. Proponents of this view assume that DevOps means poorer QA, as new code is simply thrown directly onto production environments, according to the motto “users can test whether everything works.”
That is, such a program is seen as typical banana software: The program develops with the customer.
That’s not true, of course. If a DevOps workflow is done correctly, the opposite is the case—namely, that testing is much more structured and targeted in teams that work according to DevOps principles, as a great deal is automated.
At the end of a development line following DevOps, many more tests will have been carried out than in traditional development cycles. So the point here is that all levers are set in motion in order to have a secure parachute, giving you the confidence to jump (or, roll out the changes).
Incorrect Understanding of Team Structuring
A classic misunderstanding about DevOps concerns team structuring. Some see DevOps as simply a combined development and operations team. This is almost correct, but with various restrictions.
Others see DevOps as a development team that has taken over the operations team’s responsibilities; in this view, admins are no longer needed! That’s not DevOps, either. Admins are still necessary in a DevOps workflow. However, the tasks and responsibilities of all the people involved change in a DevOps environment; they no longer work in the traditional way.
In some cases, companies put in place separate DevOps teams that sit between the development and operations teams, and on a permanent basis. During a company’s transition to DevOps, such a team could be good idea, but certainly not in the long term because that is not the purpose of DevOps!
In essence, a proper approach to team structuring is basically about bringing the development team and the operations team together and improving the strengths and eliminating the weaknesses of the respective roles. But the question is, how can these teams be combined? Which other teams or roles should be included? For example, the QA team, the security team, the business team (i.e., the people who ultimately make the business decisions), and even the finance team could be involved.
Not Tearing Down All the Walls
Working according to DevOps principles does not mean that all old processes and habits have to be thrown out the window. This is precisely the next problem that often becomes apparent. In the DevOps context, people often talk about breaking down the wall, tearing down the fences, or removing the silos.
It is therefore a question of breaking down the barriers between the different teams. A typical mistake is that, as shown in the figure below, the walls between the development team and the operations team are torn down, but not between the other teams outside of engineering.
Cultural change can be achieved only when everyone changes together, and this applies to all roles and areas of responsibility in the organization. Managers should also implement business decisions based on feedback from the development and operations teams, as they are best positioned to assess what works and what causes problems.
This idea applies to finances and budgeting as well: The lower the barrier between the decision-making level, which decides on budgets, and the technology level, the better that informed decisions can be made. For example, consider a team that is working on migrating a data center to a public cloud. Details of such a project need to be considered by both the technicians and managers; the project would result in a different billing model, so the pros and cons making the migration need to be discussed. No department can make this decision alone.
Therefore, introducing DevOps involves bringing together not only the technical roles but also all the other areas of responsibility. A DevOps culture that is practiced only in the machine room is doomed to fail.
Tools over Processes over People
The next problem is that many companies introducing DevOps start with purchasing tools, then adapt their processes to DevOps principles, and then finally start selecting people. You need everything—tools, technology, processes, and people—but you need to approach the implementation of these things in exactly the opposite way.
The principle is always people over processes over tools. This means that people come before processes and processes before tools, as mentioned at the beginning of this chapter. This guiding principle comes from Scrum and has an important meaning in DevOps.
The tools you select are important and will help you and your team implement DevOps principles, but they are useless if your processes are poor. And even if your processes are world-leading, they won’t help if the mentality of the people on the team or in the organization is still wrong.
So the first step is to select the people in your organization’s teams. Only then should you work on adapting your processes to DevOps, and only then should you select the tools. While it’s great if a company has a CI/CD pipeline to integrate and roll out changes, it doesn’t help much if every intermediate step has to be approved by a number of managers. Obtaining several approvals for a deployment not only takes quite a long time, but it also shows that you don’t trust the team and, therefore, the people running it, even though they do the main work and are best positioned to assess the progress and quality of the project. Autonomous and independent teams are a core characteristic of DevOps!
But this trust also has to be built up slowly. And that is neither very easy nor can it be done overnight. Trust can be developed only with support from the very top. If there is a lack of understanding and trust, a well-functioning organization that works according to DevOps principles can almost be ruined.
One to One Copies of Working Methods from Other Companies
In the spirit of DevOps—as mutual learning is one of its core principles—many companies and organizations share their experiences of adapting DevOps at conferences and in blog posts. This information is useful for companies looking to make their own transitions to DevOps.
However, it is not useful to copy the working methods, structures, or tools of other companies without adjusting them to your own needs and environment. Every organization is different. Each has its own challenges that need to be overcome. And many have their own compliance guidelines, some of which are prescribed by law.
It is important to learn many aspects from other companies without copying their approach one to one. You’ll often hear in conversations that people take certain actions simply because, after all, Google, Amazon, Netflix, or some American start-up do it that way.
However, very few companies are in any way comparable with such big companies. Many factors are involved, such as company size, company age (and, therefore, the age of the codebase), the company culture and willingness to change, and, above all, the industry. A company like Google must and can work differently than a German car manufacturer, a Swiss bank, or a US public sector organization, and this is not only due to legal regulations. Several industries with their own challenges collide here.
Don’t get it wrong: We can and should learn a lot from the big tech companies! However, you shouldn’t try to copy their approaches, as your company’s needs and culture are likely very different; instead, you should adapt these companies’ approaches wisely to your own context.
Editor’s note: This post has been adapted from a section of the book DevOps: Frameworks, Techniques, and Tools by Sujeevan Vijayakumaran.
Comments