The DevOps theme has become very popular over the past few years. Many people dream of joining it, but, as practice shows, often only because of the level of salaries.

Some indicate DevOps in their CVs, although they do not always know and understand the essence of the term. Someone believes that having studied Ansible, GitLab, Jenkins, Terraform and so on (the list can be continued), you will immediately become a “devops”. This, of course, is not so.

For the past few years, I have been mainly involved in implementing DevOps in various companies. Before that, I worked for more than 20 years in positions from a system administrator to an IT director. Now – DevOps Lead Engineer.

Who is DevOps

The idea to write an article came up after another question: “who is DevOps?”. There is still no established term of what or who it is.  First, I will single out the main points from it, and then I will share my observations and thoughts.

DevOps is not a specialist you can hire, not a set of utilities, and not a development department with engineers.

DevOps is a philosophy and methodology.

In other words, this is a set of practices that helps developers actively interact with system administrators. That is, to connect and integrate work processes into each other.

With the advent of DevOps, the structure and roles of specialists remained the same (there are developers, there are engineers), but the rules of interaction have changed. Blurred the boundaries between departments.

The goals of DevOps can be described in three ways:

• Software should be updated regularly.
• Software should be done quickly.
• Software should be deployed conveniently and in a short time.

DevOps does not have a single tool. Configuring, delivering and exploring several products does not mean that DevOps has appeared in the company. There are a lot of tools and everyone is involved at different stages, but they serve one common goal.

And this is only part of DevOps tools

For more than 2 years I have been interviewing people for the position of DevOps engineer and I realized that it is important to clearly understand the essence of the term. I have accumulated specific experiences, observations, and thoughts that I want to share.

From the interview experience, I see the following picture: specialists who consider DevOps a job usually have misunderstandings with colleagues.

There was a vivid example. A young man came to the interview with a bunch of smart words in the resume. In the last three places of work, he had 5-6 months of experience. He left two startups because they “didn’t go on”. But as for the third company, he said that nobody understands it: developers write code on Windows, and the director forces this code to be “wrapped” in a regular Docker and embedded in a CI / CD pipeline. The guy told a lot of negative things about his current job and his colleagues – I wanted to answer: “Like that you won’t sell an elephant.”

Then I asked him a question, which is one of the first on my list for each candidate.

– What does DevOps mean to you personally?
– Generally or how do I perceive it?

I was interested in his personal opinion. He knew the theory and origin of the term, but strongly disagreed with them. He thought DevOps was a position. Here lies the root of his problems. Like other professionals with the same opinion.

Employers, having heard about the “magic of DevOps”, want to find a person who will come and create this “magic”. And the applicants from the category “DevOps – is is a position” do not understand that with this approach they will not be able to live up to expectations. And, in general, DevOps is written in their resume, because this is a trend and companies pay a lot for it.

Methodology and Philosophy DevOps

The methodology is theoretical and practical. In our case, the second. As I mentioned above, DevOps is a set of practices and strategies used to achieve stated goals. And in each case, depending on the business processes of the company, it can differ significantly. Which does not make it better or worse.

The DevOps methodology is just a means of achieving your goals.

Now about what is the philosophy of DevOps. And this is probably the most difficult question.

It is quite difficult to formulate a short and succinct answer, because it has not yet been formalized. And since adherents of the DevOps philosophy are more engaged in practice, there is simply no time for philosophizing. However, this is a very important process. And directly related to engineering activities. There is even a specialized field of knowledge – the philosophy of technology.

In my university there was no such subject, I had to study everything myself on the basis of materials that I could find in the 90s. The topic is optional for engineering education, hence the lack of formalization of the answer. But those people who are seriously immersed in DevOps, begin to feel a certain “spirit” or “unconscious comprehensiveness” of all the processes of the company.

I tried to formalize some of the “postulates” of this philosophy. It turned out the following:

• DevOps is not something independent, which can be distinguished into a separate area of ​​knowledge or activity.
• DevOps-methodology should be guided by all employees of the company planning their activities.
• DevOps affects all processes within the company
• DevOps exists to reduce the time spent on any processes within the company to ensure the development of its services and maximum customer comfort.
• DevOps, in modern language, is the proactive position of each employee of the company, aimed at reducing time costs and improving the quality of IT products surrounding us.

I think that my “postulates” are a separate topic for discussion. But now there is something to build on.

What does DevOps do

The keyword here is communication. There are a lot of communications, the initiator of which should be the very DevOps engineer. Why is it like that? Because it is philosophy and methodology, and only then engineering knowledge.

I can’t speak about the Western labor market with 100% certainty. But I know quite a lot about the DevOps market in Russia. In addition to hundreds of interviews, over the past year and a half I participated in hundreds of technical presales for the service “Implementation of DevOps” for large Russian companies and banks.

In Russia, DevOps is still a very young, but already trending topic. As far as I know, only in Moscow the shortage of such specialists in 2019 amounted to more than 1000 people. And the word Kubernetes for employers is almost like a red rag for a bull. Adherents of this tool are ready to use it even where it is not necessary and not economically viable. An employer does not always understand in what cases it is more appropriate to use it, and with proper deployment, the maintenance of a Kubernetes cluster is 2-3 times more expensive than deploying an application using a conventional cluster scheme. Use it where you really need it.

Implementing DevOps in terms of money is expensive. And it is justified only where it brings economic benefits in other areas, and not by itself.

DevOps engineers are, in fact, pioneers – they are the first to implement this methodology in the company and build processes. For this to be successful, the specialist must constantly interact with employees and colleagues at all levels. As I usually say, all employees of the company should be involved in the process of implementing DevOps: from a cleaning lady to a CEO. And this is a prerequisite. If the youngest member of the team does not know and understand what DevOps is and why certain organizational actions are performed, then a successful implementation will fail.

Also, the DevOps engineer needs to use an administrative resource from time to time. For example, to overcome the “resistance of the environment” – when the team is not ready to accept the tools and methodology of DevOps.

The developer should write only code and tests. To do this, he does not need a super-powerful laptop on which he will deploy and support locally the entire infrastructure of the project. For example, the front-end keeps on your laptop all the elements of the application, including the database, the S3 emulator (minio) and more. That is, he spends a lot of time maintaining this local infrastructure and is struggling alone with all the problems of such a solution. Instead of developing code for the front. Such people can strongly resist any changes.

But there are teams that, on the contrary, are happy to introduce new tools and methods, and are actively involved in this process. Although even in this case, the communication between the DevOps engineer and the team has not been canceled.

When DevOps is not needed

There are situations when DevOps is not needed. This is a fact – it must be understood and accepted.

First of all, this applies to any companies (especially small businesses), when their profit does not depend directly on the presence or absence of IT products that provide information services to customers. And here we are not talking about the company’s website, whether it is a static “business card” or with dynamic news blocks, etc.

DevOps is required when the satisfaction of your client and his desire to come back to you again depend on the availability of these information services for interacting with the client, their quality and targeting.

A striking example is one well-known bank. The company does not have the usual client offices, the workflow is carried out through mail or couriers, and many employees work from home. The company ceased to be just a bank and, in my opinion, turned into an IT company with developed DevOps technologies.

Many other examples and lectures can be found in the recordings of thematic meetings and conferences. I personally visited some of them – this is a very useful experience for those who want to develop in this direction.

Now look at your business and think about this: how much your company and its profit depend on IT-products that provide interaction with the client?

If your company sells fish in a small store and the only IT product is two 1C configurations: Enterprise (Accounting and UNF), then it hardly makes sense to talk about DevOps.

If you work at a large commercial and industrial enterprise (for example, produce hunting rifles), then it is worth considering.

You can take the initiative and convey to your management the prospects for implementing DevOps. And, at the same time, lead this process. A proactive attitude is one of the important postulates of the DevOps philosophy.

The size and volume of the annual financial turnover is not the main criterion for determining whether your company needs DevOps.

Imagine a large industrial enterprise that does not interact directly with customers. For example, some carmakers and automotive companies. Now I’m not sure, but, from my past experience, for many years all interaction with clients was carried out by e-mail and phone.

Their customers are a limited list of car dealers. And a specialist from the manufacturer is attached to each. All internal workflow occurs through SAP ERP. Internal employees, in fact, are customers of the information system. But the management of this company is carried out by classical means of managing cluster systems. Which excludes the possibility of using DevOps practices.

Hence the conclusion: for such enterprises, the implementation of DevOps is not something critically important, if we recall the goals of the methodology from the beginning of the article. But I do not exclude that some DevOps tools are used by them today.

On the other hand, there are many small companies that develop software using the DevOps methodology, philosophy, practices, and tools. And they believe that the costs of implementing DevOps are costs that allow them to compete effectively in the software market. Examples of such companies can be seen here.

The main criterion for understanding whether DevOps is needed: how important your IT products are for the company and customers.

If the company’s main profitable product is software, you need DevOps. And it is not so important if you earn real money with the help of other goods. This also includes online stores or mobile applications with games.

Any games exist thanks to financing: direct or indirect from the players.

Instead of a conclusion

I want to end with the following thought: in order to become a DevOps engineer of high qualification, it is vital to learn how to lively communicate with people.

DevOps engineer is a team player. And no other way. The initiative in communicating with colleagues should come from himself, and not under the influence of any circumstances. DevOps specialist should see and offer the best solution for the team.

And yes, the implementation of any solution will require a lot of discussion, and by the end it may even change. By independently developing, offering and implementing their ideas, such a person is of increasing value both for the team and for the employer. Which, ultimately, is reflected in the amount of his monthly remuneration or in the form of additional bonuses.