DevOps is a marketing buzzword with nothing behind it! Or is there? Maybe DevOps is a set of “right” tools, or it’s such a special culture. And who should be doing this, what is a DevOps engineer? In short, there are some discrepancies in the concepts, and there are a lot of myths. Some are completely trivial, and few will believe in them, and some take root in the minds of respected specialists. We will figure it out together with experienced DevOps’ers. Although they believe that DevOps is a solution to the problem of producing digital products and calling an individual that is in the style of business.

Over 5 years of work, a bunch of myths about DevOps that exist in society have been collected. In report at RIT ++ 2017, discussed this topic. In a peremptory tone announced the conventional wisdom, and tried to convince the audience that this was just a myth.

Myth # 1. DevOps can be done by a DevOps department or DevOps engineer.

In order to do normal DevOps, we hire DevOps engineers or create a DevOps department, and that’s it – we have full DevOps in our company!
This is a very challenging statement that we constantly hear. There is a huge amount of materials that tell why there are no DevOps engineers, why there is no need to create a DevOps department, etc. But all the same, DevOps departments appear, DevOps engineers are hired there, and there are more and more vacancies for DevOps specialists.

Apparently, people do not fully believe the arguments given in articles and reports. I’ll try to tell you about it again. This is my personal opinion, which is supported by personal experience.

I often see this situation. An ordinary company, nothing happens in it until the CEO or board of directors gets sick with digital transformation. It is a highly contagious disease that usually spreads at conferences for CEOs or top management. After that, the words Agile, DevOps, digital, product, etc. appear in his head. The person gathers subordinates and says: “Guys, we need Agile, DevOps, digital, look and do it.”

In fact, it’s not the director’s job to figure it out. He figured out for himself, for example, how to increase revenue, value streams and realized that this correlates with each other.

Then the guys get together and start thinking what to do with it. Read about DevOps on Wikipedia: “A methodology that brings together developers, operations, testing for continuous software delivery.”

In their company, software delivery is continuous, deployed once every 3 months. Developers and sysadmins visit bars together all the time – there is no problem with interaction. We need to make a strong-willed decision and rename some department to DevOps.

Ultimately, either the quality department is renamed DevOps or the operations department, depending on the experience of the people who do it. But what to do with this department if there are quality / issue engineers? This is wrong, and they must be renamed DevOps engineers.

Employees are renamed, new vacancies are posted. I regularly review DevOps jobs because we and our clients are looking for engineers. You can also go to, My Circle and see vacancies for DevOps engineers. They are all so different!

It is impossible to single out any strict standardization or typing at all: from people setting up a pipeline for Jenkins, to testers who write autotests; from experts in deploying to Amazon, to those who set up monitoring, roll out software, etc. All possible professions that exist in IT are marked as DevOps engineer.

The exception is small companies that actually make digital products that have a real continuous supply of software. They are looking for people who are all in one, because it is difficult to single out a separate qualification. Then a DevOps engineer vacancy is simply posted, in which everything that is in general is written – Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus. I like that people often misspelled the names of technologies.

In general, I am not opposed to the name DevOps engineer or DevOps department. But the most important thing for which DevOps is needed is to create the whole value stream in the company. DevOps should cover everything from analytics to specific operations. This is not a separate profession or a dedicated role, but simply a piece that solves the problem of rapidly producing digital products.

Myth No. 2. DevOps is about hiring multi-site specialists who can do everything

I’ll tell you my interpretation of where this problem came from. When this whole DevOps story began, it was really multi-site specialists who did all the work. For example, one person was building a delivery pipeline, setting up monitoring, etc. I myself started with the same thing and did everything myself, because I did not know who to entrust this: I need to research here, screw it up here, do it there. As a result, I was a multi-machine specialist who configured Linux, wrote in Chef, and screwed the API for Zabbix, etc. I had to do everything.

But it doesn’t really work.


18 artisans who can make a pin themselves make 360 ​​pins a day
18 artisans, divided into 18 specialties, make 48,000 pins.

This is a famous example of the growth of production in a pin mill from the book of Adam Smith. In fact, the story about these pins was not invented by him, but only honestly stolen from the British Encyclopedia.

In fact, this logic has not gone anywhere. When I hear that specialists should be cross-functional, I really think teams should be cross-functional, but by no means specialists. Otherwise, we come to a story when we need to produce 48,000 pins, and there are simply not enough people.

In the book “Project“ Phoenix ”. A novel about how DevOps is changing business for the better ”describes the story of Brandon, who does everything in the company, and everything is shut up in him, like a bottleneck. This is just a story about a cool multi-tool specialist.

But the question immediately arises – if you do not hire a multi-machine operator, then whom to hire? There is no clear answer to this question, the problem is that we in our Russian community say little about it. We love to sketch problems, but no one likes to solve them. We don’t focus on specific specializations for DevOps people.

I will try to highlight these roles in large strokes and invite you to this work, because without dividing roles, we will talk about multi-tool specialists all the time.

DevOps, other roles:

A developer with an understanding of the architecture and work of software in production (writes tests and infrastructure code)

How does this developer differ from a graduate of a typical Russian university? A developer from a typical Russian university knows how to write algorithms – and that’s all. A DevOps developer not only knows how to write descriptions, but also knows how this description is brought to life.

I came to IT from electronics and it was amazing to me what was happening here: people think that a schematic diagram is a working product. An electronic engineer does not have such a myth in his head, but in IT he does.

We need developers who know a circuit diagram is not a working product. There are few of them, they come from adjacent areas – for example, from electronics. People who are trained by Russian universities do not know this. They think we wrote the code – okay.

If you are going to implement DevOps in your company, this competence is often easier to build up internally: identify the problem if you cannot yourself, hire a person who will train people, give them the necessary categories, how to work with software in production.

Infrastructure engineer (writes infrastructure bindings, provides a platform for the developer)

In fact, this role is so rich that it can be split further. Essentially, it includes the product owner manager who owns the continuous delivery platform product and the individual competencies of the people who build the continuous delivery platform. But this is for large companies.

It’s easier for small companies. This is an engineer who is well familiar with the configuration management system, knows Docker, Kubernetes, can make on their basis a continuous software delivery process and give it to the developer.

Infrastructure services developer (DBaS, Monitoring as Service, Logging as Service)

These are services that are provided to the developer as a product. Note, you can go to Amazon and buy these separate services. Amazon can be thought of as a DevOps role model, meaning that what they sell can be grown internally.

Release manager (manages process and dependencies)

This is not the person who builds build. He manages dependencies, versioning, facilitates teams to negotiate on integration environments, oversee the continuous delivery pipeline, and more.

It is often a man, but it is a fairy who empowers your team with magic so that it can continuously deliver software.

Leave a Reply

Your email address will not be published. Required fields are marked *