DevOps now - like version control ten years ago, everyone will be there soon
One can endlessly argue about the concept of “DevOps” - there are vacancies, posts, instructions, and KPIs ... But I still constantly see completely different perceptions of this concept between business, admins and developers. The first perceive DevOps as a methodology, the second - as a set of tools for automation of routine, and the third - as a set of tools for deployment. In some way everyone is right.
We decided to take a look at these practices from each of the listed positions and asked those who have been cooking this for a long time. What happened? Look under the cut.
')
Baruch jbaruch Sadogursky is one of the most prominent DevOps gurus who speak Russian. In recent days he has been doing basically three things in his life: hanging out with developers, users and clients, writing code for them and talking about impressions on blogs and at conferences. Developer advocate from JFrog, a regular debriefing podcast "Debriefing". One of the main organizers of swampUP , a cool DevOps conference taking place in the Valley.
Alexander Titov is a managing partner in Express 42 who grows DevOps in technology companies. At one time he was the technical director of the first cloud hosting in Russia, Skalaxi. Organizer of the DevOps Moscow community, DevOpsDays Moscow conference.
- DevOps solves the problem of interaction between the team engaged in the development and delivery of the same product. What are the principles for such interaction among people of various specializations? How to define clear boundaries of responsibility?
Alexander Titov: The question is both simple and complex. I will try to answer both this and that.
“Responsibility” is a pretty simple word. It means to be responsible for something, the opportunity to explain, to understand the business that you are doing. In no case is it equivalent to the fear of depriving a premium or the failure of any KPI.
So, a person can be responsible if he possesses knowledge in a certain sphere, including his knowledge, helps him to identify and admit to himself that he does not know anything, this is his boundary. At the same time, a person can also go beyond the boundaries of his knowledge responsibly and knowingly and thus receive knowledge.
This is a simple answer to the question of responsibility - it’s enough for a person, team and company to know the limits of their knowledge. Then you can always understand where we go on shaky ice, and where we are on solid ground. Roughly speaking, if a person or team knows how Kubernetes works in their environment, then they can perfectly take responsibility for Kubernetes. Or, for example, the person wrote the application and knows how it works, he is responsible for it.
The difficult answer is that it is very difficult to determine knowledge in a company - people lie, are afraid and do not admit that they actually know and what they don’t. It often happens that people themselves do not realize that they do not understand something - this is also called unconscious incompetence. And here only cultivation of a culture of trust and continuous dialogue in a team can help. Anyone can point the other at a mistake: at the same time, the second one cannot ignore this indication, he needs to think and discuss it with other members of the team, respond to them. And this culture is the basis of interaction in teams practicing DevOps.
- If the company has long adhered to the standard approach to development, how difficult is it to “rebuild” people into DevOps-methodology? What problems can you encounter with this?
Alexander Titov: It's hard to rebuild people. The idea of restructuring a man generally smacks of fascism, these guys also thought that it was possible to "build" a superman. People need to form and solve a number of very difficult tasks:
The big problem is a lack of understanding of the basic principle: one should not rebuild people, as many do, but create an environment in which these people could master the skills I have listed. The manager can create such an environment only when he changes himself, and this is the biggest problem here.
My recipe for changing yourself is to work in a community. It is the community that helps painlessly in trust mode to see how to create an environment. It’s very hard for a manager to think about the environment when deadlines and bonuses are being pressed on him.
Baruh Sadogursky: The biggest problem is that technical people find it difficult to correctly assess cultural changes. Techies believe that now they will take Jenkins, polish with Docker and they will have DevOps. But DevOps is not only about tools, it is about changing the approach. The fact that there are no more system administrators and developers. There are those who write the code - and they are responsible for ensuring that the code gets into production.
Everyone wants to set up the right tools so that those who write the code deploy everything to production, and then announce that DevOps is implemented. And on the very next debriefing, when it turns out that something was not in production, developers discourage them: “We did everything, as we were told, clicked on the button, now this is not our problem. Let those who set it up go and fix it. ” And then it turns out that setting up the pipeline does not mean getting DevOps. As long as those who write the code do not understand that, in principle, they cannot use the phrase “this is not our problem”, there can be no talk of DevOps.
We will now have a great conference with technical topics, created by technical people. There will be a lot of Jenkins, Ansible, Docker, Puppet and other various great tools. There will be a lot of reports on how to get DevOps through their proper configuration. This is what we understand, what we love to talk about. What we can do right. We will have reports on how to change the culture, but it is very difficult for us to do this. In general, this is not a question for techies, but for psychologists, sociologists or behavioral specialists.
- DevOps-methodology involves all sorts of automation. Does this mean that for a business launch and product support becomes cheaper? How to determine the border, after which it is advisable to run DevOps?
Baruch Sadogursky: DevOps was created to ensure that products get into production faster, that releases are more frequent, and development is faster. If you look at the results of surveys of companies that have implemented or are planning to implement DevOps, 80% of them highlight quick releases as the main, most important driver.
In terms of implementation boundaries: in fact, DevOps will be useful for teams of any size. To ask a question about the applicability of this methodology to one or another scale of a team is the same as asking 10 years ago what size it makes sense to use version control. Today we are no longer asking this question, because it is clear that even two of them already need some tools for a technical collaboration. DevOps is also a toolkit. And if today we take for granted - to write the code and send it to the version control, then in 10 years we will write the code in the same way and send it to the production. These are things of the same level. We just have not reached this point yet.
The result will probably be less noticeable when there are 3 people in the project. And they do not need all the tools that a team of 100 people use. But the DevOps paradigm itself (you need not only to write code, but also take responsibility for seeing it in production as working, ensuring that everything you need is delivered there, and it is deployed as it should, and the quality is proper) works for one person, and for three, and for a team of 100 people. Changing only the set of tools.
- Is it possible to give examples of when DevOps did not help the project (or even prevented it)?
Baruch Sadogursky: From this point of view, DevOps is similar to Agile. There are many teams that implemented Scrum, but they didn’t work. And the answer to this is simple: you need to distinguish between culture and tools. Tools may or may not be suitable, they may be well implemented or poorly. If they are introduced poorly, this will certainly not end well. But the culture of greater collaboration itself, the concept itself proposing to remove another barrier cannot be bad.
All cultural changes in the industry in the last 20-25 years lead to more collaboration. At first we had continuous integration. It is about more collaboration - we want developers to think about integration at an early stage, instead of doing it once a year before release. Now we do the integration after each commit (or every night). Agile - too. We break teams so that the collaboration is better, people communicate more. We have daily meetings, information exchange has improved. Now came DevOps. He is absolutely about the same - we remove another barrier. The effectiveness of this approach is already justified by many years of experience - the exclusion of barriers guarantees faster releases, better quality and all the other advantages. The only question is how this is implemented.
- How difficult is it in our time to organize an effective DevOps team? What competencies should engineers have? And do we need "separate DevOps engineers"?
Baruh Sadogursky: We return to the issue of culture. We are techies and know how to work with various tools. But to organize a team that will function exactly as a team - the most difficult. From a technical point of view, if you have a couple of people from the development and a couple of people from IT (from system administration), while they want to work together, nothing more is needed. They themselves will be able to raise and adjust the necessary tools, learn from each other. But finding people who understand what this means from a cultural point of view is the biggest challenge.
Alexander Titov: I will talk about this in my report. But in short, DevOps-engineer is, of course, an approach from misunderstanding, some attempt to escape from the inevitable reality. The company chooses its own way to create a technology product, reads about technology and decides to hire a DevOps engineer or team to close the DevOps direction, and an Agile-coach team to close the Agile direction. And in the end it turns out how it turns out.
In fact, in DevOps now you can count several separate competencies:
And this is only the beginning of the selection of competencies.
- Tell us about the tooling, necessary for the development and support of the product, according to the canons of DevOps. In what direction are modern tools developing?
Alexander Titov: Tuling is focused on building a convenient technological environment for creating products and testing hypotheses for these products. There are already ready-made ecosystems, such as Amazon, GCP, Azure. There are tools that can be the basis for its customizable ecosystem - Kubernetes, Ansible, Jenkins can be its component parts. Docker now played a special role - it could become a tool for packaging and standardizing knowledge on configuring and configuring an application.
Tools will evolve toward greater stability and the creation of services and services for engineers. An example is using machine learning to integrate applications and identify problems or to test.
- Are there currently unresolved problems in the toolkit?
Baruh Sadogursky: There are many tools. Over time, they are more and more, they themselves - all the better. It seems to me that now there is nothing special to look for. DevOps has reached the early majority stage - everyone understands everything more or less.
Of course, each individual instrument can still be developed and improved, but there are no longer any dark spots (“how we do this, no one knows”). There are other markets where there are their own, specific problems. And there are still “dark spots”, interesting for us - as for providers of tools.
- Is it possible to call the necessary minimum of tools for all teams?
Baruch Sadogursky: DevOps can be implemented on a minimum of products. We need some kind of issue tracker, for example, issue on GitHub; naturally, GitHub itself is needed for code and version control. We need a continuous integration server - some elementary Jenkins or even a cloud solution - there are plenty of them, and some kind of platform to run all this, most likely also in the cloud. To get started, that's enough.
Are the simplest tools sufficient for complex systems in which there are many commands that interact with each other? Of course not. But this basic set is enough to configure fully automatic continuous integration or continuous delivery, getting a full-fledged DevOps stack. Does this mean DevOps turned out? Not. The question, as already mentioned, is in culture.
- A little about the technical component. QA is considered to be one of the components of DevOps. How complicated / simplified is the life of a QA engineer?
Alexander Titov: The life of a QA-engineer is not complicated and not simplified, it changes, he begins to write code that is responsible for determining the reliability of the application and the possibility of its integration with other applications - this is a slightly different task compared to scripting the site. In general, I would advise all QA-engineers who cannot program, to enroll in programming courses, it is not too late to start.
- What are the advantages of a business after implementing the DevOps methodology?
Baruh Sadogursky: As I have already said, a business wants two things: release faster, because its success and competitiveness depend on it, and release with higher quality. 80% of companies say they want DevOps because of these two features.
- Does DevOps really allow a business to respond faster to external changes? What makes this happen? Or is it a fallacy?
Alexander Titov: DevOps is being created for this (it has not been created yet, we are at the beginning of the journey) - this is an approach to software development that allows you to quickly study the market and test business hypotheses. This is due to the fact that all approaches and tools are created based on this idea (those approaches and tools that are created on other ideas are not DevOps).
At the DevOops conference, which will be held in St. Petersburg in two weeks, Baruch and Alexander will hold a round table “How to“ sell ”DevOps to colleagues, superiors, and other indifferent people . ”
Alexander Titov separately in the report “From sysadmin to man” will tell about DevOps as a system. How it helps the business, what competencies on the part of engineers should appear for DevOps, what business problems can be solved by the DevOps method of software production, and what mistakes are possible on the way to DevOps production and how to avoid or stop them.
Baruch Sadogursky (along with Leonid Igolnik from CA Technologies) will talk about DevOps in the context of business growth. The report is called “DevOps in scale: the Greek tragedy in three acts . ” Experts will talk about the technological and methodological difficulties that arise at each stage of the company's maturity (with an increase in the number of employees from 3 to 100 people), and proven methods and solutions to these problems with the help of the correct personnel, methodological and technical means.
The full conference program and conditions for participation are available on the event website .
We decided to take a look at these practices from each of the listed positions and asked those who have been cooking this for a long time. What happened? Look under the cut.
')
Baruch jbaruch Sadogursky is one of the most prominent DevOps gurus who speak Russian. In recent days he has been doing basically three things in his life: hanging out with developers, users and clients, writing code for them and talking about impressions on blogs and at conferences. Developer advocate from JFrog, a regular debriefing podcast "Debriefing". One of the main organizers of swampUP , a cool DevOps conference taking place in the Valley. Alexander Titov is a managing partner in Express 42 who grows DevOps in technology companies. At one time he was the technical director of the first cloud hosting in Russia, Skalaxi. Organizer of the DevOps Moscow community, DevOpsDays Moscow conference.- DevOps solves the problem of interaction between the team engaged in the development and delivery of the same product. What are the principles for such interaction among people of various specializations? How to define clear boundaries of responsibility?
Alexander Titov: The question is both simple and complex. I will try to answer both this and that.
“Responsibility” is a pretty simple word. It means to be responsible for something, the opportunity to explain, to understand the business that you are doing. In no case is it equivalent to the fear of depriving a premium or the failure of any KPI.
So, a person can be responsible if he possesses knowledge in a certain sphere, including his knowledge, helps him to identify and admit to himself that he does not know anything, this is his boundary. At the same time, a person can also go beyond the boundaries of his knowledge responsibly and knowingly and thus receive knowledge.
This is a simple answer to the question of responsibility - it’s enough for a person, team and company to know the limits of their knowledge. Then you can always understand where we go on shaky ice, and where we are on solid ground. Roughly speaking, if a person or team knows how Kubernetes works in their environment, then they can perfectly take responsibility for Kubernetes. Or, for example, the person wrote the application and knows how it works, he is responsible for it.
The difficult answer is that it is very difficult to determine knowledge in a company - people lie, are afraid and do not admit that they actually know and what they don’t. It often happens that people themselves do not realize that they do not understand something - this is also called unconscious incompetence. And here only cultivation of a culture of trust and continuous dialogue in a team can help. Anyone can point the other at a mistake: at the same time, the second one cannot ignore this indication, he needs to think and discuss it with other members of the team, respond to them. And this culture is the basis of interaction in teams practicing DevOps.
- If the company has long adhered to the standard approach to development, how difficult is it to “rebuild” people into DevOps-methodology? What problems can you encounter with this?
Alexander Titov: It's hard to rebuild people. The idea of restructuring a man generally smacks of fascism, these guys also thought that it was possible to "build" a superman. People need to form and solve a number of very difficult tasks:
- people need to be shown that thinking really helps to solve problems;
- people need to learn how to conduct a dialogue, not a monologue (look at regular meetings - there are solid monologues);
- people need to be open and sincere;
- people need to be shown that diverse experiences are great, and knowledge from painting helps in software development.
The big problem is a lack of understanding of the basic principle: one should not rebuild people, as many do, but create an environment in which these people could master the skills I have listed. The manager can create such an environment only when he changes himself, and this is the biggest problem here.
My recipe for changing yourself is to work in a community. It is the community that helps painlessly in trust mode to see how to create an environment. It’s very hard for a manager to think about the environment when deadlines and bonuses are being pressed on him.
Baruh Sadogursky: The biggest problem is that technical people find it difficult to correctly assess cultural changes. Techies believe that now they will take Jenkins, polish with Docker and they will have DevOps. But DevOps is not only about tools, it is about changing the approach. The fact that there are no more system administrators and developers. There are those who write the code - and they are responsible for ensuring that the code gets into production.
Everyone wants to set up the right tools so that those who write the code deploy everything to production, and then announce that DevOps is implemented. And on the very next debriefing, when it turns out that something was not in production, developers discourage them: “We did everything, as we were told, clicked on the button, now this is not our problem. Let those who set it up go and fix it. ” And then it turns out that setting up the pipeline does not mean getting DevOps. As long as those who write the code do not understand that, in principle, they cannot use the phrase “this is not our problem”, there can be no talk of DevOps.
We will now have a great conference with technical topics, created by technical people. There will be a lot of Jenkins, Ansible, Docker, Puppet and other various great tools. There will be a lot of reports on how to get DevOps through their proper configuration. This is what we understand, what we love to talk about. What we can do right. We will have reports on how to change the culture, but it is very difficult for us to do this. In general, this is not a question for techies, but for psychologists, sociologists or behavioral specialists.
- DevOps-methodology involves all sorts of automation. Does this mean that for a business launch and product support becomes cheaper? How to determine the border, after which it is advisable to run DevOps?
Baruch Sadogursky: DevOps was created to ensure that products get into production faster, that releases are more frequent, and development is faster. If you look at the results of surveys of companies that have implemented or are planning to implement DevOps, 80% of them highlight quick releases as the main, most important driver.
In terms of implementation boundaries: in fact, DevOps will be useful for teams of any size. To ask a question about the applicability of this methodology to one or another scale of a team is the same as asking 10 years ago what size it makes sense to use version control. Today we are no longer asking this question, because it is clear that even two of them already need some tools for a technical collaboration. DevOps is also a toolkit. And if today we take for granted - to write the code and send it to the version control, then in 10 years we will write the code in the same way and send it to the production. These are things of the same level. We just have not reached this point yet.
The result will probably be less noticeable when there are 3 people in the project. And they do not need all the tools that a team of 100 people use. But the DevOps paradigm itself (you need not only to write code, but also take responsibility for seeing it in production as working, ensuring that everything you need is delivered there, and it is deployed as it should, and the quality is proper) works for one person, and for three, and for a team of 100 people. Changing only the set of tools.
- Is it possible to give examples of when DevOps did not help the project (or even prevented it)?
Baruch Sadogursky: From this point of view, DevOps is similar to Agile. There are many teams that implemented Scrum, but they didn’t work. And the answer to this is simple: you need to distinguish between culture and tools. Tools may or may not be suitable, they may be well implemented or poorly. If they are introduced poorly, this will certainly not end well. But the culture of greater collaboration itself, the concept itself proposing to remove another barrier cannot be bad.
All cultural changes in the industry in the last 20-25 years lead to more collaboration. At first we had continuous integration. It is about more collaboration - we want developers to think about integration at an early stage, instead of doing it once a year before release. Now we do the integration after each commit (or every night). Agile - too. We break teams so that the collaboration is better, people communicate more. We have daily meetings, information exchange has improved. Now came DevOps. He is absolutely about the same - we remove another barrier. The effectiveness of this approach is already justified by many years of experience - the exclusion of barriers guarantees faster releases, better quality and all the other advantages. The only question is how this is implemented.
- How difficult is it in our time to organize an effective DevOps team? What competencies should engineers have? And do we need "separate DevOps engineers"?
Baruh Sadogursky: We return to the issue of culture. We are techies and know how to work with various tools. But to organize a team that will function exactly as a team - the most difficult. From a technical point of view, if you have a couple of people from the development and a couple of people from IT (from system administration), while they want to work together, nothing more is needed. They themselves will be able to raise and adjust the necessary tools, learn from each other. But finding people who understand what this means from a cultural point of view is the biggest challenge.
Alexander Titov: I will talk about this in my report. But in short, DevOps-engineer is, of course, an approach from misunderstanding, some attempt to escape from the inevitable reality. The company chooses its own way to create a technology product, reads about technology and decides to hire a DevOps engineer or team to close the DevOps direction, and an Agile-coach team to close the Agile direction. And in the end it turns out how it turns out.
In fact, in DevOps now you can count several separate competencies:
- infrastructure engineer (engineer who provides a low-level platform — resources, networks, building machines);
- general services engineer (engineers who create monitoring, logging, database as a service);
- product development engineer (directly application developer and configuration for them);
- CI engineer;
- release manager or release producer (the manager or engineer who produces the release of versions and manages the entire product as a set of components, now the technical director often plays this role).
And this is only the beginning of the selection of competencies.
- Tell us about the tooling, necessary for the development and support of the product, according to the canons of DevOps. In what direction are modern tools developing?
Alexander Titov: Tuling is focused on building a convenient technological environment for creating products and testing hypotheses for these products. There are already ready-made ecosystems, such as Amazon, GCP, Azure. There are tools that can be the basis for its customizable ecosystem - Kubernetes, Ansible, Jenkins can be its component parts. Docker now played a special role - it could become a tool for packaging and standardizing knowledge on configuring and configuring an application.
Tools will evolve toward greater stability and the creation of services and services for engineers. An example is using machine learning to integrate applications and identify problems or to test.
- Are there currently unresolved problems in the toolkit?
Baruh Sadogursky: There are many tools. Over time, they are more and more, they themselves - all the better. It seems to me that now there is nothing special to look for. DevOps has reached the early majority stage - everyone understands everything more or less.
Of course, each individual instrument can still be developed and improved, but there are no longer any dark spots (“how we do this, no one knows”). There are other markets where there are their own, specific problems. And there are still “dark spots”, interesting for us - as for providers of tools.
- Is it possible to call the necessary minimum of tools for all teams?
Baruch Sadogursky: DevOps can be implemented on a minimum of products. We need some kind of issue tracker, for example, issue on GitHub; naturally, GitHub itself is needed for code and version control. We need a continuous integration server - some elementary Jenkins or even a cloud solution - there are plenty of them, and some kind of platform to run all this, most likely also in the cloud. To get started, that's enough.
Are the simplest tools sufficient for complex systems in which there are many commands that interact with each other? Of course not. But this basic set is enough to configure fully automatic continuous integration or continuous delivery, getting a full-fledged DevOps stack. Does this mean DevOps turned out? Not. The question, as already mentioned, is in culture.
- A little about the technical component. QA is considered to be one of the components of DevOps. How complicated / simplified is the life of a QA engineer?
Alexander Titov: The life of a QA-engineer is not complicated and not simplified, it changes, he begins to write code that is responsible for determining the reliability of the application and the possibility of its integration with other applications - this is a slightly different task compared to scripting the site. In general, I would advise all QA-engineers who cannot program, to enroll in programming courses, it is not too late to start.
- What are the advantages of a business after implementing the DevOps methodology?
Baruh Sadogursky: As I have already said, a business wants two things: release faster, because its success and competitiveness depend on it, and release with higher quality. 80% of companies say they want DevOps because of these two features.
- Does DevOps really allow a business to respond faster to external changes? What makes this happen? Or is it a fallacy?
Alexander Titov: DevOps is being created for this (it has not been created yet, we are at the beginning of the journey) - this is an approach to software development that allows you to quickly study the market and test business hypotheses. This is due to the fact that all approaches and tools are created based on this idea (those approaches and tools that are created on other ideas are not DevOps).
At the DevOops conference, which will be held in St. Petersburg in two weeks, Baruch and Alexander will hold a round table “How to“ sell ”DevOps to colleagues, superiors, and other indifferent people . ”
Alexander Titov separately in the report “From sysadmin to man” will tell about DevOps as a system. How it helps the business, what competencies on the part of engineers should appear for DevOps, what business problems can be solved by the DevOps method of software production, and what mistakes are possible on the way to DevOps production and how to avoid or stop them.
Baruch Sadogursky (along with Leonid Igolnik from CA Technologies) will talk about DevOps in the context of business growth. The report is called “DevOps in scale: the Greek tragedy in three acts . ” Experts will talk about the technological and methodological difficulties that arise at each stage of the company's maturity (with an increase in the number of employees from 3 to 100 people), and proven methods and solutions to these problems with the help of the correct personnel, methodological and technical means.
The full conference program and conditions for participation are available on the event website .
Source: https://habr.com/ru/post/339762/
All Articles