The DevOps theme has become very popular over the past few years. Many dream of joining it, but, as practice shows, often only because of the level of salaries.
Some indicate DevOps in their resume, although they do not always know and understand the essence of the term. Someone thinks that having studied Ansible, GitLab, Jenkins, Terraform and the like (the list can be continued to your taste), he will immediately become a “devops”. This, of course, is not true.
Over the past few years, I have been mainly involved in the implementation of DevOps in various companies. Prior to that, for more than 20 years he worked in positions from a system administrator to an IT director. Currently DevOps Lead Engineer at Playgendary.
Who is DevOps
The idea to write an article arose after another question: “who is DevOps?”. There is still no established term for what or who it is. Some of the answers are already in this . First, I will highlight the main theses from it, and then I will share my observations and thoughts.
DevOps is not a specialist to hire, not a set of utilities, and not a development department with engineers.
DevOps is a philosophy and methodology.
In other words, it 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 have remained the same (there are developers, there are engineers), but the rules of interaction have changed. Boundaries between departments have blurred.
DevOps goals can be summarized in three points:
- The software must be updated regularly.
- Software must be made quickly.
- Software should be deployed conveniently and in a short time.
DevOps does not have a single tool. Setting up, delivering, and learning about multiple products doesn't mean DevOps is in the company. There are a lot of tools and all are involved at different stages, but serve one common goal.
And that's just part of the DevOps tools
For more than 2 years I have been interviewing people for the position of a DevOps engineer, and I realized how important it is to clearly understand the essence of the term. I have accumulated specific experience, observations and thoughts that I want to share.
From the experience of interviews, I see this picture: professionals who consider DevOps a position usually have misunderstandings with colleagues.
There was a prime example. A young man came to the interview with a bunch of buzzwords in his resume. At the last three places of work, he had an experience of 5-6 months. He left two startups because they "didn't take off". But about the third company, he said that no one understands him there: the developers write the code for Windows, and the director makes this code “wrap” in the usual Docker and embed into the CI / CD pipeline. The guy said a lot of negative things about his current place of work and his colleagues - I just wanted to answer: “So you won’t sell an elephant.”
Then I asked him a question that is one of the first on my list for every candidate.
What does DevOps mean to you personally?
- In general, or how do I perceive it?
I was interested in his personal opinion. He knew the theory and the origin of the term, but he strongly disagreed with them. He believed that DevOps was a position. This is where the root of his problems lies. As well as other experts with the same opinion.
Employers, having heard a lot about the "magic of DevOps", want to find a person who will come and create this "magic". What “DevOps is a job” job seekers don’t realize is that they won’t be able to meet expectations with this approach. And, in general, they wrote DevOps in their resume, because this is a trend and they pay a lot for it.
DevOps Methodology and Philosophy
The methodology is theoretical and practical. In our case, the second one. 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. That doesn't make it better or worse.
The DevOps methodology is just a means to achieve 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 capacious 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. Moreover, directly related to engineering activities. There is even a specialized field of knowledge - .
There was no such subject at my university, I had to study everything on my own using the 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 company processes.
Based on my own experience, I tried to formalize some of the “postulates” of this philosophy. It turned out the following:
- DevOps is not something independent that can be separated into a separate area of knowledge or activity.
- DevOps methodology should guide all company employees when planning their activities.
- DevOps affects all processes within a company.
- DevOps exists to reduce the time spent on any processes within the company to ensure the development of its services and the maximum comfort of the client.
- DevOps, in modern terms, is the proactive position of each employee of the company, aimed at reducing time costs and improving the quality of the IT products around us.
I think that my "postulates" is a separate topic for discussion. But now there is something to build on.
What does DevOps do?
The key word here is communication. There are a lot of communications, the initiator of which should be just the same DevOps engineer. Why is that? Because it is philosophy and methodology, and only then engineering knowledge.
I cannot speak with 100% certainty about the Western labor market. 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 have participated in hundreds of technical pre-sales on the DevOps Implementation service for large Russian companies and banks.
In Russia, DevOps is still very young, but already a trending topic. As far as I know, in Moscow alone, 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. The adherents of this tool are ready to use it even where it is not needed and is not economically profitable. The employer does not always understand in what cases what is more appropriate to use, and with proper deployment, maintaining a Kubernetes cluster costs 2-3 times more than deploying an application using a conventional cluster scheme. Use it where you really need it.
Implementing DevOps is costly in terms of money. And it is justified only where it brings economic benefits in other areas, and not by itself.
DevOps engineers are, in fact, the 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 DevOps implementation process: from the cleaner to the 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 successful implementation will not work.
Also, a DevOps engineer needs to use an administrative resource from time to time. For example, to overcome "environmental resistance" - when the team is not ready to accept DevOps tools and methodology.
A developer should only write code and tests. To do this, he does not need a super-powerful laptop on which he will deploy and maintain the entire infrastructure of the project locally. For example, the front-ender keeps all the elements of the application on its laptop, including the database, the S3 (minio) emulator, and so on. That is, he spends a lot of time maintaining this local infrastructure and single-handedly struggles 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 with the introduction of new tools and methods, and actively participate in this process. Although even in this case, no one canceled the communication between the DevOps engineer and the team.
When DevOps Isn't 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 directly depend 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 availability of these information services for interaction with the client, their quality and targeting depends on the satisfaction of your client and his desire to return to you again.
A well-known bank is a prime example. The company does not have the usual client offices, the document flow is carried out through mail or couriers, and many employees work from home. The company has ceased to be just a bank and, in my opinion, has turned into an IT company with developed DevOps technologies.
Many other examples and lectures can be found in the records of thematic meetups and conferences. I visited some of them personally - this is a very useful experience for those who want to develop in this direction. Here are links to YouTube channels with good lectures and materials on DevOps:
Now look at your business and think about this: How much does your company and its profits depend on IT products to deliver customer experience?
If your company sells fish in a small shop 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 trading and manufacturing enterprise (for example, you produce hunting rifles), then you should think about it. You can take the initiative and bring the vision of DevOps implementation to your management. Well, at the same time, to lead this process. A proactive stance is one of the important postulates of the DevOps philosophy.
The size and volume of 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 automakers and automotive companies. I'm not sure now, but from my past experience, for many years, all interaction with customers was done by email and phone.
Their clients are a limited list of car dealers. And a specialist from the manufacturer is attached to each. All internal document flow occurs through SAP ERP. Internal employees, in fact, are clients of the information system. But the management of this IS 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 critical, if we recall the goals of the methodology from the beginning of the article. But I do not rule out that some DevOps tools are used by them today.
On the other hand, there are many small companies that develop software using DevOps methodology, philosophy, practices and tools. And they believe that the cost of implementing DevOps is a cost that allows them to compete effectively in the software market. Examples of such companies can be seen .
The main criterion for understanding whether DevOps is needed: what value your IT products have for the company and customers.
If the main profitable product of the company is software, you need DevOps. And it is not so important if you earn real money with the help of other goods. This can also include online stores or mobile applications with games.
Any games exist due to funding: direct or indirect from the players. At Playgendary, we develop free mobile games with over 200 people directly involved in the creation. How do we use DevOps?
Yes, exactly as described above. I constantly communicate with developers and testers, conduct internal training of DevOps methodology and tools for employees.
Now we are actively using Jenkins as a CI / CD pipelines tool for performing all assembly pipelines with Unity and subsequent deployment to the App Store and Play Market. More from the classic set of tools:
- Asana - for project management. Set up integration with Jenkins.
- Google Meet - for video meetings.
- Slack - for communications and various notifications, including notifications from Jenkins.
- Atlassian Confluence - for documentation and group work.
In the near future, we plan to implement static code analysis using SonarQube and conduct automated UI testing using Selenium at the Continuous Integration stage.
Instead of a conclusion
I want to finish with the following thought: to become a highly qualified DevOps engineer, it is vital to learn how to communicate with people live.
DevOps engineer is a team player. And nothing else. The initiative in communicating with colleagues should come from him, and not under the influence of any circumstances. The DevOps specialist needs to see and suggest 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. Self-development, offering and implementing his 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.
Source: habr.com