12 DevOps Anti Patterns that need urgent destruction

article

"What is done, can't be undone" is not about business and workflow

danger

You can always stop for a while and think about why I can't achieve my goals, step back and redo something that went wrong. BUT! You can also learn from the mistakes of others and prevent some painfully typical blunders.
In the case of the DevOps concept, the problem roots deeply in the misunderstanding of the idea and its further misleading distribution. This term is overgrown with false connotations and specialists just can't clear out what it is and what it is NOT.

You probably heard a lot from industry leaders about DevOps patterns and best cases, and if you want to eliminate the mistakes made by someone else - you need to uncover main anti-patterns in DevOps. Surely, there is no "cookie-cutter" solution that fits all companies but these same old pitfalls can be found under the hood of each company.

In this article, we talk about TOP-12 anti-patterns of DevOps methodology you should take heed of.

Common anti-patterns for DevOps

So if you find yourself on this blog post, you probably want to enhance the workflow operations and services. Perhaps, you want to speed up the delivery process or achieve the maximum stability and zero-downtime deployments. In any case, you want to follow DevOps principles. Here is a list of common traps on your way. Forewarned, forearmed.

Anti-pattern #1: DevOps means dev team + sys admins

Despite the evident hint from the abbreviation, where Dev stands for development, and Ops stands for operations, DevOps principles cover all departments involved in the delivery process and goes out of the frames breaking silos.

Jennifer Davis and Ryn Daniels in their book "DevOps defined" admitted that this concept and ideas are applied to each member within the organization. Thus, for example, DevOps patterns can be applied to the legal and sales departments through automated contract creation.

devops team

Anti-pattern #2: Team members don't know their scopes of responsibility

This problem seems to be familiar for almost all companies of any size, though for the IT segment it is a crucial blunder. It's commonplace when team members don't fully understand what part of the system unit they are responsible for.

For example, some team members may interfere with the work of others or make decisions not compatible with the general workflow or technologies. Simplest example сan be a platform with microservices architecture.

devops team

The mistake almost everyone is doing when going into microservices is that several teams responsible for several microservices, but they don't interact with each other a lot.

Yes, I understand your concern, that parts of the microservice architecture shouldn't be dependent on each other, but this independency comes from active internal communication between teams and understanding levels of responsibility and ways to ensure that independency.

In this case, a goodDevOps team patternwould be like:

  • team members work according to the plan and overall strategy;
  • the communication chain is properly set up and each team member knows to whom he or she can refer with the questions.
  • only a CTO or other Lead-level person can make the final decisions; Why is this needed - if you are not a giant with perfect IT infrastructure like Netflix or Amazon you most likely don't have that robust processes that allow developers to publish changes into the production several times per day. So you must have someone who will be responsible for overall architecture.

Anti-pattern #3 : DevOps is only a team or a job title

Creating a DevOps team or renaming the same old Dev and Ops teams into DevOps wouldn't bring your organization to the next level. Though, hiring a DevOps engineer wouldn't also help.

As it was mentioned in the anti-pattern #1, DevOps as its core is a culture embracing all the departments within the company. So, first of all, you have to break the silos between teams and make them cooperate together instead of hiding behind the walls of each department and blaming other teams in all the issues.

So the main DevOps design pattern, in this case, is to find the root cause of silos that you have in the culture. Is it organizational level? Or is it technical separation ? Maybe it's some legacy approach that you were delaying to review and afraid to change because everything in your company is decided on the high level, but ideally all the initiative should go through the very bottom.

devops team

Anti-pattern #4 : Specialists focus only on their tasks and don't get into the entire ecosystem.

solo man

This one is a common problem with either communication or low motivation to work efficiently. The typical representative of this anti-pattern in DevOps is an individual always sitting with the dome on his head and working only on his / her part of the system, not willing to integrate into the general workflow.

Usually, such individuals have an approach like "it works on my machine, so it's your problem that it doesn't work on yours" or "I don't need to care about what will be with my piece of code then".

In this case, managers should take care of such unmotivated team members and find out the reasons for this.

happy business man

DevOps patterns: create a team of T-shaped specialists and develop the interchangeability of the team members. I.e. they should take the tasks not from their specialization in order to get deeper into the workflow and understand the full cycle of the system development and its functions.

At the same time, managers have to be responsible for proper communication and task distribution. Interesting example of real-world scenario is that a few big car manufacturing companies introduced similar approach when they started switching TOP-managers between divisions.

In simple words - one manager who was responsible for creating engines will lead division responsible for car aerodynamics and ergonomics. By this changes TOP-managers are more involved into each others problems and have deeper understanding about the overall situation in the company, rather than their own area.

Anti-pattern #5 : DevOps is all about tech stack

There are thousands of DevOps tools available on the market today and having them implemented doesn't mean you have a proper culture in your company. Tools help create a favorable eco-system for further its adoption and successful utilization.

In this instance, a good DevOps deployment pattern would be:

  • refuse from excessive tools and revision of the existing toolchain.
  • don't chase the newest and most hyped technologies.
  • establish a final goal and use the technologies as a means to achieve this goal.

happy devops engineer

Anti-pattern #6 : Absence of documentation and manual undocumented changes

Constant manual undocumented changes in the infrastructure configurations wouldn't bring any fruits. It's a typical case when the team members may be replaced (swapped or new hires), so a new-comer wouldn't bring the things together.

The documentation must be in a good state with detailed descriptions of what was configured/deployed, when it was done, why this or that decisions were made. Having good documentation overall - allows teams to reduce amount of technical debt.

Anti-pattern #7 : DevOps is only automation

For sure DevOps and automation come together and they complement each other. But don't dive deep into the automation unless you understand manual processes your team is doing day by day. If you don't understand how to do manual steps properly, it is very bad idea to start using Ansibe, Terraform or any other Infrastructure as Code tool. Definitely - when IaC is implemented you will benefit a lot from it, but the problem that you need to step back at first, and make sure you understand all the processes inside the team/company, so you are sure on what you will be automating and what challenges you will be dealing with.

Anti-pattern #8 : Define X days for implementation.

It is impossible to establish a deadline to implement a DevOps culture. In this case, you have only a starting point and point of no return:) It also doesn't have any precise measurable or definable states.

The best practice is to define possible KPIs for each stage of the implementation plan. A step-by-step transformation plan would be much efficient because you will be able to see which stage of the project is completed and which stage is a constraint. For example, you can define the processes like setting up the configuration management systems or implementation of X, Y, Z technologies to ensure automation of the CI/CD pipeline.

happy devops engineer

devops circle

What is most important to keep in mind is 3 key principles of DevOps: Flow, Feedback and Continuous experimentation and learning.

  • By flow we mean optimization of business and dev processes in general and understanding the overall flow of how work is being done.
  • Feedback principle means that we understand and respond to needs of our customers and understand how we can shorten/speed up so called `feedback loops` to make sure we can quickly change whatever we need in the very early stage. This is the main principle where most companies stop implementing DevOps.
  • 3rd principle and the hardest one is Continuous experimentation, because you need to dedicate time for new experiments, you need to try reward teams for taking risks, and so on.

Learn more about these principles in Gene Kim's book "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win".

Anti-pattern #9 : Implement the most hyped technologies for no reason

"I talked with my friend and he told me to use Kubernetes, it will boost our productivity!" or "oh! everybody is talking about this X tool and I want to implement it on Friday" - seems familiar, yeah?

Rational decision making is a key concept in the DevOps deployment patterns. In this case, rationalism should always take place for solving the problems of all levels. Surely, you have to take into consideration modern practices and tools and implement them whenever the need arises. But think first of all - "do I really need this?". This will save time and money on refactoring and eliminates the need for inventing the "bicycle"?

Anti-pattern #10 : Bail on testing and monitoring.

The best example of this anti-pattern is a startup trying to implement DevOps. Always in a hurry, always no time for testing and monitoring tools implementation since "we need to focus on the development of the main product". This is a very very very bad idea and failure approach.

404 page

That's why

  • Testing pyramid (unit, integration, system tests) is as important as the development. No release or even small updates without tests!
  • Monitoring tools must be implemented from day ONE. With their help, you will be able to quickly recover from incidents and find the pitfalls of the system.

Two bonus mistakes in DevOps adoption

  • Blaming culture 

Blaming or punishing when mistakes are made is apriori a disastrous approach. This culture of pointing out a guilty person produces hostility among the coworkers and they will be focused more on shifting the blame away from themselves rather than on doing their jobs well. Another problem in this approach is the opinion that human beings can't make a mistake, especially if it is a senior specialist.

Moreover, search for "black sheep in the family" will lead to Anti-pattern #4: the individuals will be concentrated only on their piece of job, without dipping into the business. What, in its turn, will consequently lead to building silos between teams.

  • Walls between teams 

Same old silos, meaning the acquired mentality when team members don't want or can't share information, their knowledge. Role segregation and blameful culture are a consequence of the silos, which, in its turn, lead to decrease in efficiency.
For instance, an average siloed climate within the teams: they use absolutely incompatible tools to complete similar tasks, the team members don't have a straight access to the decision makers or those possessing the needed information. Thus, the lack of information leads to endless downtimes and technical debt.

To avoid this, each DevOps adoption pattern begins with breaking the silos and establishment of the normal communication between ALL teams, not only between Devs and Ops. That's why, when hiring the companies providing DevOps as a Service, it's worthwhile to begin with business processes analysis and estimation of how teams communicate between each other.

To summarize

In this article we uncovered the question "what are the anti patterns of DevOps culture?" and provided the most common examples of these anti patterns and how to avoid them.
Indeed, effective DevOps as a cultural process within the organization stands on 4 core pillars:

  • Proper collaboration between ALL teams. 
  • Building interteam relationships and defining overall goals. 
  • Successful tools choices. 
  • Gradual scaling and changeability.

Taken all these 4 main pillars together, you will be able to solve difficult cultural, operational, and technical problems that may explicitly influence application development process.

Let's arrange a free consultation

Just fill the form below and we will contaсt you via email to arrange a free call to discuss your project and estimates.