How to switch to devops from development

We decided to figure out what the work of a devops engineer is all about, and asked Viktor Popov, a devops at NLMK IT, about it. Victor told me what ways they come to devops and what they do there, why everyone needs middles and what to do if you are June. Word to Victor.

About the term

I think that many Habr readers can’t stand the term “devops engineer”, because there are no devops engineers, and in general devops is a methodology, not a person. But the industry has not come up with a better term, so I will continue to call the word devops a set of tools, tasks and methodologies, well, a devops engineer is a person working in this field.

Three types of devops

It seems to me that there are no two companies in which the position of “DevOps engineer” would mean the same set of tasks and tools. To summarize everything I’ve seen, there may be three different types of tasks hidden inside the word devops.

In the first case, devops are platform engineers. People who provide something as a service, for example, k8s cluster. In general, this is what I am doing now. These are the good old sysadmins who just renamed themselves, because sysadmins are paid little, and devops are paid a lot.  We are spinning servers, some services, they are just not on virtual machines anymore, but in containers. Well, users began to love a little more. The tools and the name have changed, the essence – as if not.

The second option is a “grocery” devops, people who are inside the development team. They can write pipelines, manifestos for developers, assemble containers, and configure monitoring. This is quite common, but, in my opinion, not the best practice. It is much better when all these things are automated systematically at the company level.

In this case, sometimes it happens like this: if the developer doesn’t know something, then it’s for devops. It can be anything: some database is unavailable, the electricity is turned off in the data center, coffee is cold in the coffee machine – all to the devops. This is a sad example of the lack of agreements on who is responsible for what.

The third option is when the development team does about the same thing as in the second case, but on a more global scale, at the company level. Somewhere it’s called a release engineer, somewhere it’s called a devops engineer. That is, engineers create a single toolkit, which is then used to build, test and deliver code.

In general, it seems to me that a devops engineer is a person who cares. If we recall the origin of the term DevOps, it turns out that we have Dev, there are Ops, they historically did not know how to talk to each other. Then a devops appeared, made friends with everyone, and people just started talking, interacting. So how does it fit into a job description with limited functionality?

Why everyone needs middles and what employers want from Junes

Now many companies need devops engineers, and from the vacancy it will most likely be clear to you what kind of story there is – the first, second or third. Although sometimes vacancies are written in such a way that you read and think: “Guys, you need a department of 20 people or a large contractor here.” Therefore, if you are interested in a vacancy, you just need to ask what they want from you, what exactly you need to do, ask for examples of tasks for a day, a month, six months.

Most companies want to hire a middle man or a senior, there are few vacancies for junos now, and the competition is great. It has become much more difficult for a novice developer to find a job. From experience, I can say that if middle + or senior now want to change the company, they will definitely receive some kind of offer in a week. For a month — an offer that satisfies them. And this is in the “lazy” mode.

For June, it’s much more complicated. So it turns out such a vicious circle: companies do not take juniors because they do not want to invest in development, juniors cannot become middles, so there are not enough middles and seniors. There are a lot of middle and middle+ vacancies.

When I interviewed Junov, I had literally three basic requirements: burning eyes and the ability to read and Google. It is clear that I exaggerate a little and need some kind of engineering background. But the main thing is the ability to learn quickly.

Set up an error notification system.

Postmortem analysis

Errors and failures will always occur — regardless of whether you use an intermediate environment or not. The best way to reduce their number is the introduction of post—mortems, the practice of fixing errors. It is better to organize it as follows:

Analyze the cause of the bug after it was eliminated;

Report the results to the team: tell us what you have learned and how you plan to use this knowledge;

Discuss how to avoid repeating the mistake in the future. This is the most difficult part — most likely, it will consist of a combination of new code, infrastructure and processes.

Where to start?

The easiest way to abandon the intermediate environment is if you have a web application. There are several reasons for this:

Platforms for statistical sites (for example, Vercel) are well integrated with git and allow you to quickly update the application and roll back changes if something went wrong;

Front-end web applications fit perfectly into the concept of feature flags: first of all, they are designed to display and hide user interface elements;

As a rule, interfaces have no state — if you deploy them immediately in a production environment, you save time on the time-consuming task of migrating databases.

Another option is to select a few of the least significant functions and branches that do not necessarily have to be deployed in an intermediate environment. For example, functions that are responsible for updating the backup or changing the style of the application are suitable for this role.

Conclusion

Is it worth abandoning the intermediate environment? It depends on the amount of work you are willing to do. In addition, it is important at what stage of development the project is — the sooner you make this decision, the easier it will be to change the approach to the release of updates.

P.S: here you can see how the deployment of updates in Booking works, which works without an intermediate environment.