Very often you can find “DevOps Engineer” in jobs vacancies titles. But what is this role? And is it a role actually? What is DevOps in general? Which practices does it include? Why does the position name DevOps engineer sound incorrect? Our article is devoted exactly to these questions.

Every company associated with the development or implementation of software seeks to move faster and be as flexible as possible. This requires maximum involvement of developers in all stages of the software development process life cycle. Let’s think about where this software cycle begins and how it ends. It starts with planning – almost everyone knows it. But how does it end? Deployment? Where and how are we deploying? When does the developer’s involvement in the process end? Should he actually be involved in general? Well, is it important on which platform the software, what you wrote, will be hosted. Are the resources that you allocate for it important? How fast will you update it? Let’s check the evolution of the process.

How it was before

When an industry of the software development began, each developer was his own business analyst, architect, layout designer, developer, tester, DevOps and 24/7 support in one package. Which disadvantages did it have? Sometimes, were made products that are quite clumsy and incomprehensible to a third-party user. It was hard to imagine what was happening in the head of this or that individual. And one more minus is the concentration of all sacred knowledge in one bright head, which could get sick, go to competitors, or just fly for a vacation to Goa. However, there were pluses in this. The engineer immediately thought about the full life cycle of his product. There was no hope for an admin who would come and decide everything for you.

Then happened that, what always happens during the transition to mass production – industry division. Started to appear admins, who were managing the application infrastructure and developers who actually made it. We are not talking about layout designers, quality engineers, business analysts, and others, which were also involved in the development process. So, after separation for many developers, the software life cycle began to end with the “git push” command when closing the last bug. The specifics of the business also influenced the situation – outsourcing began to dominate. Many delivered the code as raw materials, without thinking about the final result, about how and where all this will be placed. This could go on forever, if not several factors.

Why the DevOps culture started to take its place

The first factor was a new way of products creation in software offices, when you think not only about how to locally solve a particular problem (in other words, somehow and to production), but about global solutions. Here will not work a local ready part of the product – and then let others deal with it. You must be aware that you will continue to have to live with this part, and therefore you need to solve something at the infrastructure level. So you have to start developing, relying on where the final product will be located.

If the first factor may still seem quite controversial, then the second is more clear. This is the broad development of cloud services, the rejection of hosting on own servers and support of own infrastructure. The chosen infrastructure began to determine the architecture of the application. AWS, Azure, Heroku, DigitalOcean began to do your work for you. Now you don’t need to create 1001 variants of a balancer or sharding – this is all available out of the box. This reduced the number specialists in companies per square meter, but this approach, in return, required knowledge of the service infrastructure and the adaptation of products to it.

In addition, microservice architecture has contributed to the rethinking of application infrastructure by developers. Now it’s not enough to make the next module and upload it to the repository, leaving the deployment engineers to guess the config variables. No, now you have to think about how it all will interact with each other, because this configuration may not even „fly up in your sandbox” and sending unverified code is as well a bit too much.

Platforms began to determine the implementation of applications, so a developer cannot write a good application without knowledge of platforms. Developers began to be involved in operational work. There is a culture of DevOps. Yes, it is culture. Why not a role? – you may ask. Because DevOps practices, which will be discussed in our future article, should be implemented at the company level, and not at the department or group level. People in the company should know about software development and the subtleties of using infrastructure.

The DevOps culture is the next stage in the evolution of the FullStack paradigm, in which teams do not implement individual parts of the application, but solve the whole problem. It is quite difficult for one person to cover these tasks, and such a process must be conducted throughout the company or group. And the first thing to do is to remove the „role of the DevOps engineer” at all.