DevOps Myths
DevOps is a marketing word for which there is nothing! Or is there? Maybe DevOps is a collection of “right” tools, or it’s such a special culture. And who should do this at all, what is a DevOps engineer? In a word, there are some discrepancies in concepts , and a lot of myths . Some are quite trivial, and few people believe in them, and some take root in the minds of respected experts. We will understand together with experienced DevOps'erami Alexander Titov and Ivan Evtukhovich ( evtuhovich ). Although they believe that DevOps is the solution to the problem of producing digital products, and to call it so an individual is in the style of Russian business.
About speakers : Alexander Titov and Ivan Evtukhovich represent the Express 42 company, which deals with consulting in the field of DevOps. Among her clients are many well-known companies, for example, MTS, Raiffeisenbank Bank, Alfa-Bank and others.
For 5 years of work, a bunch of myths about DevOps that exist in society have gathered. In their report on RIT ++ 2017, Alexander and Ivan talked about this topic. Ivan, in a peremptory tone, declared the conventional wisdom, and Alexander tried to convince the audience that this was just a myth.
')
Apparently, people do not fully believe the arguments that are presented in articles and reports. I will try to tell about it again. This is my personal opinion, which is supported by personal experience.
I often see this situation. An ordinary company, nothing happens in it until the general director or the board of directors becomes ill with a digital transformation . This is a very contagious disease that usually spreads to conferences for CEOs or top management. After that, the words Agile, DevOps, digital, product, etc. appear in his head. A person collects subordinates and says: “Guys, we need Agile, DevOps, digital, look for it and make it”.
In fact, it’s not the director’s task to figure it all out. For himself, he derived, for example, how to increase revenue, value streams and realized that this correlates with each other.
Then the guys get together and start thinking what to do with it. Esteemed in Wikipedia about DevOps : "Methodology that unites developers, operation, testing for continuous software delivery . "
In their company, the delivery of software is continuous , once every 3 months. Developers and system administrators constantly visit bars together - there is no interaction problem . You need to make a strong-willed decision and rename any department to DevOps.
In the end, either the quality department is renamed DevOps, or the operation department, depending on the experience of the people who do it. But what to do with it with this department, if there are quality / issue engineers there? This is wrong, you need to rename them to DevOps engineers.
Employees are renamed, new vacancies are posted . I regularly look at DevOps jobs because we and our clients are looking for engineers. You can also go to hh.ru, My circle and see the jobs of DevOps engineers. They are all so different!
No strict standardization or typification can be distinguished: from people setting up the pipeline for Jenkins, to testers who write auto-tests; from specialists on deploy to Amazon, to those who set up monitoring, rolls out software, etc. All possible professions that exist in IT are marked with a DevOps engineer.
Exceptions are small companies that actually make digital products that have real, continuous software delivery. They are looking for people who are all in one, because it is difficult to single out a separate qualification . Then the job is just laid out DevOps-engineer, which is written in general, all that is - Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus. I like the fact that people often write with the mistakes of technology names.
In general, I am not against the name DevOps-engineer or DevOps-department. But the most important thing for which DevOps is needed is to create a stream of value entirely in the company . DevOps should cover everything - from analytics to specific exploitation. This is not a separate profession or a dedicated role, but just a thing that solves the problem of fast production of digital products.
The first mention of this word dates back to 2009, when Patrick Debois said at the conference:
If you are looking for a DevOps engineer, think about why you need one. It is better to single out a specific competence and look for it in the market than an incomprehensible specialist.
I'll tell you my interpretation of where this problem came from. When the whole story with DevOps was just beginning, all the work was really done by multi-channel specialists. For example, one person built the delivery pipeline, set up monitoring, etc. I myself started with the same thing and did everything myself, because I didn’t know who to charge this to: I need to research here, screw it up, do it there. In the end, I was a multi-channel specialist who set up Linux, wrote both to Chef, and screwed APIs for Zabbix, etc. I had to do everything.
But actually it does not work .
This is a famous example of production growth in a pin factory from the book of Adam Smith. In fact, he did not invent the story about these pins, but only honestly stole it from the British encyclopedia.
In fact, this logic has not gone away. When I hear that specialists should be cross-functional, in fact, I think that teams should be cross-functional , but by no means experts. Otherwise, we come to the story when we need to produce 48,000 pins, and there are simply not enough people.
In the book "Project" Phoenix ". A novel about how DevOps is changing business for the better ”describes the story about Brandon, who does everything in the company, and everything shuts up in him, like in a bottle neck. This is just a story about a cool multi-specialist.
But then the question arises - if you hire a multilanger, then whom to hire? There is no clear answer to this question, the problem is that we in our Russian community speak little about it. We love to throw problems, but no one likes to solve them. We do not allocate specific specializations for people who are involved in DevOps.
I will try to highlight these roles in large strokes and invite you to this work, because without separating the roles, we will always talk about multi-channel specialists.
What distinguishes this developer from a graduate of a typical Russian university? A developer from a typical Russian university knows how to write algorithms — and that’s all. DevOps developer not only knows how to write descriptions, but also knows how this description is brought to life .
I came to IT from radio electronics and for me it was amazing what is happening here: people think that the concept is the working product. The radio engineer has no such myth in his head, but in IT he does.
We need developers who know that the concept is not a working product . They are few, they come from adjacent areas - for example, from radio electronics. People who are trained by Russian universities do not know this. They think that we have written the code - and all right.
If you are going to implement DevOps in your company, this competency is most often easier to increase inside : identify the problem, if you can’t do it yourself, hire a person who will train people, give them the right categories for how to work with software in production.
In fact, this role is so rich that it can be split further. In fact, it includes the manager-owner of the product, who owns the product of the continuous delivery platform, and the individual competencies of the people who build this delivery platform. But this is for large companies.
For smaller companies, everything is easier. This is an engineer who is familiar with the configuration management system, knows Docker, Kubernetes, can make on their basis a continuous software delivery process and give it to the developer.
These are services that are provided to the developer as a product. Notice, you can come to Amazon and buy these separate services. Amazon can be considered as a model of the roles of DevOps, that is, what they have for sale, you can grow in yourself.
This is not the person building build. It manages dependencies , versions, facilitates agreement teams on integration environments, monitors the operation of a continuous delivery pipeline, etc.
Often it’s a man, but it’s a fairy who gives your team magic so that she can continuously deliver software.
Where did this myth come from?
The fact is that people are trying to measure continuous software delivery by releases per unit of time . They ask: “If we roll out once a week, is it DevOps?” Generally speaking, this is a good result. But in fact, they have different release cycles — even within the same team — the individual components are fitch. In this case, the release cycle takes three months, and they delivirut really once a week - in different release cycles. It turns out the hack, which is called DevOps. In fact, there was a substitution of concepts.
The main point of DevOps is to provide a time-to-market . This is not the number of rollouts per unit of time, but the time that passes from writing the first line of code to rolling out in production . Here, the indicator week is already really cool, and three months is really not cool. This is not DevOps anymore.
Time-to-market is needed for companies that make digital products in order to do their customers well. A digital company is a business people, product-owner and others, and engineers who write software. Usually in these companies a huge amount of feedback, because they do not work with clients personally.
Uber personally does not communicate with the client until he is not satisfied with their services. In this case, the person opens the phone, and there he has Get, Yandex-taxi, Maxim. He can make a decision and quickly move on to another player. Therefore, we must very quickly work out the feedback from the market, in addition the market (customers) is constantly changing.
Therefore, the main parameter driving DevOps in an organization is the real time-to-market. If you have a company that does not make digital software for large markets, then DevOps is most likely not needed. This is just a buzzword that flew into the head of the CEO, and he did not fully understand him.
From the outside it looks like this.
Amazon really deplots once every 11 seconds - that is, it can take 11 seconds from writing a code to rolling out. In fact, behind this is a lot of work and the use of a huge number of DevOps practices.
I have sketched out basic DevOps practices that focus exclusively on the time-to-market, without which it is impossible to achieve continuous feedback from your customers and from the market.
It sounds good and quite simple - let's roll it out to 0.1% of users. But for this you need to do a tremendous job, for example, move from monolithic architecture to microservice.
This monitoring as testing, when the developer in the form of a code describes what needs to be monitored in production. After that, the artifact is fired along with a description of what needs to be monitored, and immediately at all stages of the continuous delivery pipeline everything is added to the monitoring. You can really see what happens with the application.
When you rolled out by 0.1%, you can understand whether the software works as it should, or something is wrong with it. It is useless to roll out at 0.1% if you do not know what is happening with the software.
This is when by ID you can see in the system how the client data was changing: here he came to the frontend, from there to the backend, then to the queue, he got into the queue asynchronous worker, the asynchronous worker went to the database, changed the cache state - all this is logged. Without this, it is impossible to find what happened in the system, and rolling out at 0.1% also.
Imagine, you decided to roll out some new software to all 2,000 visitors of the Russian Internet Technologies festival, but you don’t have end-to-end logging. These 2,000 people write that they are not working. You ask them what is not working, because from your point of view some poltergeist is happening. Useless topic.
Automated testing has long been known, has existed for many years and has been used to improve the quality of software. Here, autotests should be treated somewhat differently - as a form of agreement between the teams. Commands, instead of solving a bunch of small problems in software during integration, agree that each team writes autotests and solves these problems at the development stage of a separate module, element, etc. Writing autotests is a separate story.
All the described bricks - DevOps practices for TTM are a lot of time and work, unless you start from scratch, but, for example, rewrite a monolith. But without them, high time-to-market is not possible.
In general, this is the usual engineering view, but it often happens like this:
I have already described how much to do in order to move to continuous delivery. Plus, we still have to agree within the team. If we write autotests, this is exactly about the agreement within the team, except that we must have the skill of writing autotests.
Often, when they want to implement DevOps, Kubernetes is installed, used for a while, and then it turns out that it would be easier with hands, there are a lot of components, they sometimes get buggy, and so far all this is not necessary.
With powerful tools, nails are simply hammered. Of course, DevOps is not just about the right tools . But at the same time, there really is a class of tools that are directly related to DevOps and created just by the community that was born by Patrick Debois.
For each of these tools, there are also instructions for use: not just a description of how to install it or how it is arranged inside, but also a manual on how to use it.
For example, when you install Git, you do not understand thoroughly how the hashing inside is arranged. Someone knows, someone does not, but in general this knowledge is useless. The same with Kubernetes - this knowledge is only needed by the engineers who accompany him. And the engineers around need to know how to work with him. This knowledge is important, you should not forget about it.
At the dawn of our company, we had a couple of Chef deployments that managed the configuration only while we were at that company.As soon as we left, Chef remained separate, and the process returned to the old course. These were our, so to speak, test stones. But, nevertheless, we had such stories.
Because when you work with a complex ecosystem, almost with your eyes closed, that is, you have a black box and a lot of people who use it, you really need to think a lot.
But at the same time, philosophy is not the most important thing. There are more knowledge and specific skills, there are tools and approaches that are also included in DevOps. The presence of culture does not generate the necessary processes . The appearance of a certain culture during two days of training by specially trained coaches will lead to nothing.
Moreover, if after the training you don’t start doing something right away, everything that was put on the training at the head disappears and passes without a trace. We, as people who conducted many trainings, know this for sure. We ourselves went to trainings. This does not work.
It’s not enough to learn a new way of thinking , you should immediately try to do something with it with your hands - with the tools that are used, and preferably on a real task.
Therefore, DevOps is not only a philosophy, but a philosophy is part of DevOps. I profess the opinion that DevOps is part of a large Agile philosophy . There are Agile values, and DevOps is included in them, as a set of engineering practices and tools that help realize these values.
Yes indeed it is. But I can say even cooler. All disciplines used in ITIL are in a chemical plant, including:
These are general engineering disciplines . Project management is already 100 years old, it’s about the same - how many factories work, so many of these disciplines exist. Just existing disciplines at the time were shifted to IT, which at that time was.
This IT is fundamentally different from IT, which makes digital products. This is a separate topic for conversation. The point is that the disciplines are the same, but the content and content are different : standards, approaches, methods, tools.
Generally ITIL made for another. Therefore, on the one hand, yes, they are really similar, but, on the other hand, they are inapplicable, they cannot be used.
This is about the same story as with ITIL.
But there is a real community that started after the words of Patrick Debois. The event is regularly held, which is called DevOps Days and in 2017 was held in Moscow. There are about 150 such events in the world every year. I think it will be even more.
These people talk about something, normal hardcore dudes solve normal problems, including engineering problems, and not just managerial ones. That is, it makes sense, and if it makes sense, then it is not just a marketing word.
My advice for people who think that this is a marketing word, pay attention to the content that produces DevOps Days, there is no vendor raid and hyip. In Russia, too, there are a lot of resources:
DevOps problems are discussed here - you can come, listen and understand that there is no marketing in this. People do DevOps because they really need it.
About speakers : Alexander Titov and Ivan Evtukhovich represent the Express 42 company, which deals with consulting in the field of DevOps. Among her clients are many well-known companies, for example, MTS, Raiffeisenbank Bank, Alfa-Bank and others.
For 5 years of work, a bunch of myths about DevOps that exist in society have gathered. In their report on RIT ++ 2017, Alexander and Ivan talked about this topic. Ivan, in a peremptory tone, declared the conventional wisdom, and Alexander tried to convince the audience that this was just a myth.
Myth number 1. DevOps can do DevOps-department or DevOps-engineer
In order to make normal DevOps, we hire DevOps engineers or create a DevOps department, and that’s all - we have full DevOps in our company!This is a very interesting statement that we constantly hear. There is a huge amount of materials explaining why there are no DevOps engineers , why not create a DevOps department , etc. But all the same, DevOps departments arise, DevOps engineers are recruited there, and there are more and more job opportunities for DevOps specialists.
')
Apparently, people do not fully believe the arguments that are presented in articles and reports. I will try to tell about it again. This is my personal opinion, which is supported by personal experience.
I often see this situation. An ordinary company, nothing happens in it until the general director or the board of directors becomes ill with a digital transformation . This is a very contagious disease that usually spreads to conferences for CEOs or top management. After that, the words Agile, DevOps, digital, product, etc. appear in his head. A person collects subordinates and says: “Guys, we need Agile, DevOps, digital, look for it and make it”.
In fact, it’s not the director’s task to figure it all out. For himself, he derived, for example, how to increase revenue, value streams and realized that this correlates with each other.
Then the guys get together and start thinking what to do with it. Esteemed in Wikipedia about DevOps : "Methodology that unites developers, operation, testing for continuous software delivery . "
In their company, the delivery of software is continuous , once every 3 months. Developers and system administrators constantly visit bars together - there is no interaction problem . You need to make a strong-willed decision and rename any department to DevOps.
In the end, either the quality department is renamed DevOps, or the operation department, depending on the experience of the people who do it. But what to do with it with this department, if there are quality / issue engineers there? This is wrong, you need to rename them to DevOps engineers.
Employees are renamed, new vacancies are posted . I regularly look at DevOps jobs because we and our clients are looking for engineers. You can also go to hh.ru, My circle and see the jobs of DevOps engineers. They are all so different!
No strict standardization or typification can be distinguished: from people setting up the pipeline for Jenkins, to testers who write auto-tests; from specialists on deploy to Amazon, to those who set up monitoring, rolls out software, etc. All possible professions that exist in IT are marked with a DevOps engineer.
Exceptions are small companies that actually make digital products that have real, continuous software delivery. They are looking for people who are all in one, because it is difficult to single out a separate qualification . Then the job is just laid out DevOps-engineer, which is written in general, all that is - Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus. I like the fact that people often write with the mistakes of technology names.
In general, I am not against the name DevOps-engineer or DevOps-department. But the most important thing for which DevOps is needed is to create a stream of value entirely in the company . DevOps should cover everything - from analytics to specific exploitation. This is not a separate profession or a dedicated role, but just a thing that solves the problem of fast production of digital products.
The first mention of this word dates back to 2009, when Patrick Debois said at the conference:
- We started using a new approach. We now produce digital products and we have a problem - nothing works as before. I can't solve it alone. I invite everyone to the community to find out how to live with it. Let's call this problem DevOps.DevOps is a solution to the problem of producing digital products. To call this individual person in the style of our Russian business: there is no person - there is no problem, there is a person - there is a solution . Reverse logic.
If you are looking for a DevOps engineer, think about why you need one. It is better to single out a specific competence and look for it in the market than an incomprehensible specialist.
Help for thrifty people: usually a system administrator with a Docker knowledge from a DevOps engineer with a Docker knowledge differs not with knowledge, but with a price tag: the first is conditionally 90,000, the second is 150,000. You can save.Previously, the phrase “throw a sheet over the wall” was popular, when the development was thrown into operation - “Put it!”, They were thrown back - “It does not rise!”. With the advent of the DevOps department, we throw over the wall two times: first, the development in the DevOps department, and those in the Ops department.
Myth number 2. DevOps - this is about the fact that we need to hire multi-practitioners who can do everything
I'll tell you my interpretation of where this problem came from. When the whole story with DevOps was just beginning, all the work was really done by multi-channel specialists. For example, one person built the delivery pipeline, set up monitoring, etc. I myself started with the same thing and did everything myself, because I didn’t know who to charge this to: I need to research here, screw it up, do it there. In the end, I was a multi-channel specialist who set up Linux, wrote both to Chef, and screwed APIs for Zabbix, etc. I had to do everything.
But actually it does not work .
Performance
- 18 craftsmen who can make a pin themselves make 360 pins per day
- 18 artisans, divided into 18 specializations, make 48,000 pins.
This is a famous example of production growth in a pin factory from the book of Adam Smith. In fact, he did not invent the story about these pins, but only honestly stole it from the British encyclopedia.
In fact, this logic has not gone away. When I hear that specialists should be cross-functional, in fact, I think that teams should be cross-functional , but by no means experts. Otherwise, we come to the story when we need to produce 48,000 pins, and there are simply not enough people.
In the book "Project" Phoenix ". A novel about how DevOps is changing business for the better ”describes the story about Brandon, who does everything in the company, and everything shuts up in him, like in a bottle neck. This is just a story about a cool multi-specialist.
But then the question arises - if you hire a multilanger, then whom to hire? There is no clear answer to this question, the problem is that we in our Russian community speak little about it. We love to throw problems, but no one likes to solve them. We do not allocate specific specializations for people who are involved in DevOps.
I will try to highlight these roles in large strokes and invite you to this work, because without separating the roles, we will always talk about multi-channel specialists.
DevOps, other roles:
- Developer with an idea of the architecture and software operation in production (writes tests and infrastructure code)
What distinguishes this developer from a graduate of a typical Russian university? A developer from a typical Russian university knows how to write algorithms — and that’s all. DevOps developer not only knows how to write descriptions, but also knows how this description is brought to life .
I came to IT from radio electronics and for me it was amazing what is happening here: people think that the concept is the working product. The radio engineer has no such myth in his head, but in IT he does.
We need developers who know that the concept is not a working product . They are few, they come from adjacent areas - for example, from radio electronics. People who are trained by Russian universities do not know this. They think that we have written the code - and all right.
If you are going to implement DevOps in your company, this competency is most often easier to increase inside : identify the problem, if you can’t do it yourself, hire a person who will train people, give them the right categories for how to work with software in production.
- Infrastructure engineer (writes binding for infrastructure, provides the developer with a platform)
In fact, this role is so rich that it can be split further. In fact, it includes the manager-owner of the product, who owns the product of the continuous delivery platform, and the individual competencies of the people who build this delivery platform. But this is for large companies.
For smaller companies, everything is easier. This is an engineer who is familiar with the configuration management system, knows Docker, Kubernetes, can make on their basis a continuous software delivery process and give it to the developer.
- Infrastructure services developer (DBaS, Monitoring as Service, Logging as Service)
These are services that are provided to the developer as a product. Notice, you can come to Amazon and buy these separate services. Amazon can be considered as a model of the roles of DevOps, that is, what they have for sale, you can grow in yourself.
- Release Manager (manages the process and dependencies)
This is not the person building build. It manages dependencies , versions, facilitates agreement teams on integration environments, monitors the operation of a continuous delivery pipeline, etc.
Often it’s a man, but it’s a fairy who gives your team magic so that she can continuously deliver software.
Myth 3. We are developing a corporate IT-system, and we have DevOps since 1995
We have been developing its corporate IT system for many years, we are releasing every week. All your DevOps - it's just guys in jeans with doorways came and re-called what we can do for many years.By the way, it is rather interesting that usually in such teams the DevOps process is actually activated when incidents occur. In such situations, the boundaries are blurred dramatically between the individual teams of developers, testers, etc. They have their own process, which has been developed over the years. It is not formalized at all, but really similar to DevOps.
Where did this myth come from?
The fact is that people are trying to measure continuous software delivery by releases per unit of time . They ask: “If we roll out once a week, is it DevOps?” Generally speaking, this is a good result. But in fact, they have different release cycles — even within the same team — the individual components are fitch. In this case, the release cycle takes three months, and they delivirut really once a week - in different release cycles. It turns out the hack, which is called DevOps. In fact, there was a substitution of concepts.
The main point of DevOps is to provide a time-to-market . This is not the number of rollouts per unit of time, but the time that passes from writing the first line of code to rolling out in production . Here, the indicator week is already really cool, and three months is really not cool. This is not DevOps anymore.
Time-to-market is needed for companies that make digital products in order to do their customers well. A digital company is a business people, product-owner and others, and engineers who write software. Usually in these companies a huge amount of feedback, because they do not work with clients personally.
Uber personally does not communicate with the client until he is not satisfied with their services. In this case, the person opens the phone, and there he has Get, Yandex-taxi, Maxim. He can make a decision and quickly move on to another player. Therefore, we must very quickly work out the feedback from the market, in addition the market (customers) is constantly changing.
Therefore, the main parameter driving DevOps in an organization is the real time-to-market. If you have a company that does not make digital software for large markets, then DevOps is most likely not needed. This is just a buzzword that flew into the head of the CEO, and he did not fully understand him.
From the outside it looks like this.
Amazon really deplots once every 11 seconds - that is, it can take 11 seconds from writing a code to rolling out. In fact, behind this is a lot of work and the use of a huge number of DevOps practices.
DevOps practices for TTM
I have sketched out basic DevOps practices that focus exclusively on the time-to-market, without which it is impossible to achieve continuous feedback from your customers and from the market.
- Rollout strategies (blue-green rollouts, canary releases, a / b testing)
It sounds good and quite simple - let's roll it out to 0.1% of users. But for this you need to do a tremendous job, for example, move from monolithic architecture to microservice.
- Continuous monitoring
This monitoring as testing, when the developer in the form of a code describes what needs to be monitored in production. After that, the artifact is fired along with a description of what needs to be monitored, and immediately at all stages of the continuous delivery pipeline everything is added to the monitoring. You can really see what happens with the application.
When you rolled out by 0.1%, you can understand whether the software works as it should, or something is wrong with it. It is useless to roll out at 0.1% if you do not know what is happening with the software.
- End-to-end logging
This is when by ID you can see in the system how the client data was changing: here he came to the frontend, from there to the backend, then to the queue, he got into the queue asynchronous worker, the asynchronous worker went to the database, changed the cache state - all this is logged. Without this, it is impossible to find what happened in the system, and rolling out at 0.1% also.
Imagine, you decided to roll out some new software to all 2,000 visitors of the Russian Internet Technologies festival, but you don’t have end-to-end logging. These 2,000 people write that they are not working. You ask them what is not working, because from your point of view some poltergeist is happening. Useless topic.
- Autotest (as a form of agreement between the teams)
Automated testing has long been known, has existed for many years and has been used to improve the quality of software. Here, autotests should be treated somewhat differently - as a form of agreement between the teams. Commands, instead of solving a bunch of small problems in software during integration, agree that each team writes autotests and solves these problems at the development stage of a separate module, element, etc. Writing autotests is a separate story.
All the described bricks - DevOps practices for TTM are a lot of time and work, unless you start from scratch, but, for example, rewrite a monolith. But without them, high time-to-market is not possible.
Myth 4. DevOps are the “right” tools.
You can do DevOps using the “right” tools: take Kubernetes, coat it with Ansible, put Prometheus, screw Mesosphere from the side, and wrap all this with Docker - and immediately DevOps comes to the organization!
In general, this is the usual engineering view, but it often happens like this:
I have already described how much to do in order to move to continuous delivery. Plus, we still have to agree within the team. If we write autotests, this is exactly about the agreement within the team, except that we must have the skill of writing autotests.
Often, when they want to implement DevOps, Kubernetes is installed, used for a while, and then it turns out that it would be easier with hands, there are a lot of components, they sometimes get buggy, and so far all this is not necessary.
With powerful tools, nails are simply hammered. Of course, DevOps is not just about the right tools . But at the same time, there really is a class of tools that are directly related to DevOps and created just by the community that was born by Patrick Debois.
For each of these tools, there are also instructions for use: not just a description of how to install it or how it is arranged inside, but also a manual on how to use it.
For example, when you install Git, you do not understand thoroughly how the hashing inside is arranged. Someone knows, someone does not, but in general this knowledge is useless. The same with Kubernetes - this knowledge is only needed by the engineers who accompany him. And the engineers around need to know how to work with him. This knowledge is important, you should not forget about it.
At the dawn of our company, we had a couple of Chef deployments that managed the configuration only while we were at that company.As soon as we left, Chef remained separate, and the process returned to the old course. These were our, so to speak, test stones. But, nevertheless, we had such stories.
Myth 5. DevOps is a “philosophy”, a special culture that was born in the West and cannot be transferred to Russian realities.
Many people believe that there is a mythical west, where mythical unicorns make mythic DevOps, and we are rude to each other and here DevOps will not be born.That's a very difficult question. Indeed, digital technologies are born in groups in which a very open mind, critical thinking works, etc.
Because when you work with a complex ecosystem, almost with your eyes closed, that is, you have a black box and a lot of people who use it, you really need to think a lot.
But at the same time, philosophy is not the most important thing. There are more knowledge and specific skills, there are tools and approaches that are also included in DevOps. The presence of culture does not generate the necessary processes . The appearance of a certain culture during two days of training by specially trained coaches will lead to nothing.
Moreover, if after the training you don’t start doing something right away, everything that was put on the training at the head disappears and passes without a trace. We, as people who conducted many trainings, know this for sure. We ourselves went to trainings. This does not work.
It’s not enough to learn a new way of thinking , you should immediately try to do something with it with your hands - with the tools that are used, and preferably on a real task.
Therefore, DevOps is not only a philosophy, but a philosophy is part of DevOps. I profess the opinion that DevOps is part of a large Agile philosophy . There are Agile values, and DevOps is included in them, as a set of engineering practices and tools that help realize these values.
Myth # 6. In ITIL, DevOps is already laid, and you don’t have to give up the old for the new. DevOps uses the same practices.
Yes indeed it is. But I can say even cooler. All disciplines used in ITIL are in a chemical plant, including:
- incident management;
- configuration management;
- change management;
- capacity management;
- availability management.
These are general engineering disciplines . Project management is already 100 years old, it’s about the same - how many factories work, so many of these disciplines exist. Just existing disciplines at the time were shifted to IT, which at that time was.
This IT is fundamentally different from IT, which makes digital products. This is a separate topic for conversation. The point is that the disciplines are the same, but the content and content are different : standards, approaches, methods, tools.
Generally ITIL made for another. Therefore, on the one hand, yes, they are really similar, but, on the other hand, they are inapplicable, they cannot be used.
Myth 7. DevOps is a marketing word for which there is nothing
, DevOps', . , Agile Java , .Now I will touch on a very polemical topic. Our gentlemen integrators and large vendors listened to what the brilliant directors are talking about, and renamed their products to DevOps products. Those products that were made for the old corporate IT, and not for the production of a digital product, they simply renamed - it was HP OpenView, it became DevOps HP OpenView - and that was all.
This is about the same story as with ITIL.
But there is a real community that started after the words of Patrick Debois. The event is regularly held, which is called DevOps Days and in 2017 was held in Moscow. There are about 150 such events in the world every year. I think it will be even more.
These people talk about something, normal hardcore dudes solve normal problems, including engineering problems, and not just managerial ones. That is, it makes sense, and if it makes sense, then it is not just a marketing word.
My advice for people who think that this is a marketing word, pay attention to the content that produces DevOps Days, there is no vendor raid and hyip. In Russia, too, there are a lot of resources:
- https://www.meetup.com/DevOps-Moscow-in-Russian/
- http://devopsdeflope.ru
- https://www.2d1o.ru
- http://hangops.ru
DevOps problems are discussed here - you can come, listen and understand that there is no marketing in this. People do DevOps because they really need it.
Questions and Answers
, DevOps — . , . , DevOps , , .
, - , KPI , .
, :
, -, . , , , . , , , , , , . , , , ..
ChatOps — .
- You said that there was a file when implementing DevOps practices. People worked with Chef with you, and then came back. What is your practice statistics such kickbacks to previous work methodologies?— - , , 50%. , , . , , DevOps. , . , , , ..
, DevOps — . , . , DevOps , , .
— ?— — time-to-market. , , KPI . , time-to-market, , KPI . DevOps — .
, - , KPI , .
— , « », DevOps RUP ? , , ?— RUP, , . .
, :
- , , . , , , , - . , , , . , .
- , , , Rup , . . , Rup , : «, , ! !» — . , , , , , .
— ChatOps. , , DevOps?ChatOps — . , , , . ChatOps .
, -, . , , , . , , , , , , . , , , ..
ChatOps — .
— RootConf 2017, DevOps ++ . , :
Look at the full list of RootConf applications or for the whole RIT ++ , choose the most significant ones for yourself, and this is a link to booking tickets , the price of which will still increase.
Source: https://habr.com/ru/post/358480/
All Articles