Most Efficient And Modern DevOps Benefits

At the moment, this is almost the most expensive position on the market. The fuss around "DevOps" engineers is beyond all imaginable, and even worse with Senior DevOps engineers.
I work as the head of the integration and automation department, guess the English transcript - DevOps Manager. Whether it reflects the English transcript of our daily activities is unlikely, but the Russian version in this case is more accurate. By the nature of my activity, it is natural that I need to interview future members of my team and, over the past year, 50 people passed through me, and the same number were cut off on the screen with my employees. We are still looking for colleagues, because behind the DevOps label there is a very large layer of various kinds of engineers. Everything written below is my personal opinion, you are not obliged to agree with it, and however, I admit that it will add a shade to your attitude to the topic. Despite the risk of falling out of favor, I am posting my opinion because I think it has a place. Companies have different understandings of what DevOps engineers are, and for the sake of quickly hiring a resource, they hang this label on everyone. The situation is rather strange, since companies are ready to pay unrealistic rewards to these people, receiving, in most cases, an admin-toolsets for them.

So who are DevOps engineers?

Let's start with the history of the emergence - Development Operations appeared as another step towards optimizing the interaction in small teams to increase the speed of product production, as an expected consequence. The idea was to strengthen the development team with knowledge of the procedures and approaches in managing the product environment. In other words, the developer must understand and know how his product works in certain conditions, must understand how to deploy his product, what characteristics of the environment to tweak in order to increase performance. So, for some time, there have been developers with a DevOps approach. DevOps developers wrote assembly and packaging scripts to simplify their activities and the performance of a productive environment. But, the complexity of the solution architecture and the mutual influence of the infrastructure components over time began to worsen the performance of the environments, with each iteration, an ever deeper understanding of certain components was required, reducing the productivity of the developer himself due to the additional costs of understanding the components and tuning systems for a specific task. The developer’s own value grew, the cost of the product along with it, the requirements for new developers in the team jumped sharply, because they also had to cover the duties of the development “star” and, naturally, the “stars” became less and less available. It is also worth noting that, in my experience, few developers are interested in the specifics of packet processing by the operating system kernel, packet routing rules, and host security aspects. It was a logical step to involve an administrator who is familiar with this particular format and assign duties of this format to him, which, thanks to his experience, made it possible to achieve the same indicators at a lower cost compared to the cost of a development “star”. Such administrators were placed in a team and their main task was to manage test and production environments, on the rules of a particular team, with resources allocated to this particular team. So, in fact, DevOps appeared in the view of the majority. on the rules of a particular team, with resources allocated to this particular team. So, in fact, DevOps appeared in the view of the majority. on the rules of a particular team, with resources allocated to this particular team. So, in fact, DevOps appeared in the view of the majority.

Partially or completely, over time, these system administrators began to understand the needs of this particular team in the field of development, how to make life easier for developers and testers, how to roll out an update and not stay overnight at the office on Friday, fixing deployment errors. Time passed, now the "stars" were system administrators who understood what the developers wanted. In order to minimize the impact, management utilities began to pull up, everyone remembered the old and reliable methods of isolating the OS level, which made it possible to minimize the requirements for security, management of the network part, and the host configuration as a whole and, as a result, reduce the requirements for new “stars”.

A “wonderful” thing appeared - docker. Why wonderful? Yes, only because the creation of isolation in a chroot or jail, as well as OpenVZ, required non-trivial knowledge of the OS, in a counter utility that allows you to simply create an isolated application environment on a certain host with everything you need inside and transfer the reins of control to development again, and the system administrator can only manage only one host, ensuring its security and high availability - a logical simplification. But progress does not stand still and the systems are again becoming more and more complex, there are more and more components, one host no longer meets the needs of the system and it is necessary to build clusters, we are again returning to system administrators who are able to build these systems.