Talking about DevOps in a friendly language
Is it hard to get the point when talking about DevOps? We have gathered for you vivid analogies, percussion formulations and expert advice that will help even non-specialists to get to the point. In the end, the bonus is Red Hat’s own DevOps.
The term DevOps arose 10 years ago and went from a hashtag on Twitter to a powerful cultural movement in the IT world, a true philosophy that encourages developers to achieve results faster, experiment and move forward using the iteration method. DevOps has become inextricably linked with the concept of digital transformation. But as is often the case with IT terminology, over a decade, DevOps has managed to acquire many definitions, interpretations, and misconceptions about it.
Therefore, about DevOps you can often hear questions like, is it the same as agile? Or is it some kind of special methodology? Or is it just another synonym for the word “collaboration”?
DevOps includes many different concepts (continuous delivery, continuous integration, automation, etc.), so isolating the main thing can be difficult, especially when you are partial to the subject. However, this skill is very useful, it does not matter if you are trying to convey your ideas to your bosses or just telling someone from your family or friends about your work. Therefore, for now, put aside the terminological nuances of DevOps and focus on the big picture.
We asked experts to explain the essence of DevOps as simply and briefly as possible so that its value becomes clear to the reader with any level of technical training. Based on the results of these conversations, we selected the most striking analogies and percussion formulations that will help you build your story about DevOps.
“DevOps is a cultural movement in which both parties (software developers and IT systems operation specialists) recognize that software does not bring real benefits until someone starts using it: customers, customers, employees, not the point, says Eveline Oehrlich, senior research analyst at the DevOps Institute. “Therefore, both of these parties together provide fast and high-quality software delivery.”
“DevOps gives developers the authority to own applications, launch them and manage delivery from start to finish”
“DevOps is usually talked about as a way to speed delivery of applications to production by building and applying automated processes,” said Jai Schniepp, director of DevOps platform at Liberty Mutual. “But for me it is a much more fundamental thing.” DevOps gives developers the authority to own applications or certain parts of the software, to launch them and manage delivery from start to finish. DevOps eliminates the confusion of responsibility and leads all participants in the process to create an automated and developer-driven infrastructure. ”
“Simply put, DevOps is such an approach to the production and delivery of software when everyone works together,” said Gur Staf, president and head of digital business automation at BMC.
“Conveyor assembly is only possible if all the parts fit together.”
“I would compare DevOps with a car assembly line,” continues Gur Staf. “The idea is to pre-design and make all the details so that later they can be assembled without an individual fit.” Conveyor assembly is possible only if all the parts fit together. Those who design and make the engine should consider how to mount it to the body or frame. Those who make brakes should think about wheels, and so on. It should be the same with software.
A developer creating a business logic or user interface should think about a database that stores information about customers, about security measures to protect user data, and how it will work when the service starts serving a large, possibly even multi-million user audience. "
“To make people collaborate and think about those parts of the work that are done by others, rather than concentrating solely on their own tasks - this is the greatest obstacle that must be overcome. If it succeeds, you have excellent chances for digital transformation, ”adds Gur Staf.
Jayne Groll, Executive Director of the DevOps Institute, offered a great analogy to explain DevOps. According to her, “DevOps is like a culinary recipe in which there are three main categories of ingredients: people, processes and automation. Most of these ingredients can be taken from other areas and sources: Lean, Agile, SRE, CI / CD, ITIL, leadership, culture, tools. The secret of DevOps, as well as any good recipe, is how to choose the right proportions and mix these ingredients to increase the speed and effectiveness of work when creating and releasing applications. ”
"The race is planned not from start to finish, but rather, from finish to start."
“Talking about what to expect from the DevOps initiative, I’ll cite the NASCAR or Formula 1 racing team as an example,” says Chris Short, general manager of cloud marketing for Red Hat and publisher of the DevOps'ish mailing list. - The head of such a team has one goal: to take the maximum possible place according to the results of the race, taking into account the resources available to the team and the trials that fell to its share. In this case, the race is planned not from start to finish, but rather, from finish to start. An ambitious goal is set first, and then ways to achieve it are determined. Then they are divided into subtasks and delegated to team members. ”
“The whole week before the race, the team hones the pit stop. He is engaged in power and cardio training to be in shape on a grueling day of racing. He works out joint actions to solve any problems that may arise in the race. Similarly, the development team must train the skills of frequently releasing new versions. With such skills and a well-functioning security system, launching new versions in production also occurs more often. Within this worldview, an increase in speed means an increase in security, ”Short says.
“The point is not to do the“ right thing, ”Short adds,“ but to eliminate as many things as possible that stand in the way of the desired result. Collaborate and adapt based on the feedback you receive in real time. Be prepared for anomalies and work on improving quality to minimize their impact on movement toward the goal. That is what awaits us in the world of DevOps. ”
Just DevOps and massive DevOps are two completely different things. We will tell you how to overcome the barriers from the first to the second.
For many organizations, the path to DevOps begins easily and nicely. Small passionate teams are created, old processes are replaced by new ones and the first successes are not long in coming.
Alas, this is just a fake shine, an illusion of progress, according to Ben Grinnell, managing director and head of digital technology at the consulting firm North Highland. Early victories are certainly encouraging, but do not help achieve the ultimate goal, namely, the massive use of DevOps in the organization.
It is easy to see that as a result, a culture of separation into “we” and “they” is formed.
“Often, organizations launch such pioneering projects, believing that they will pave the way for mass DevOps, without hesitation, they can and will others want to go this way,” explains Ben Grinnel. - Teams for the implementation of such projects are usually recruited from self-confident “Vikings” who have already done something similar in other places, but are new to your organization. At the same time, they are encouraged to break and destroy the rules that remain binding on everyone else. It is easy to see that, as a result, a culture of separation into “we” and “they” is formed, which impedes the transfer of knowledge and skills.
“And this cultural issue is just one of the reasons DevOps is hard to scale. DevOps teams are confronted with the growth of purely technical difficulties characteristic of fast-growing companies that have relied on IT technology, ”said Steve Newman, founder and chairman of the board at Scalyr.
“In the modern world, services change as soon as such a need arises. Continuing to implement and implement new features is, of course, great, but coordinating this process and fixing problems is a real headache, ”adds Steve Newman. - In very fast-growing organizations, engineers as part of cross-functional teams struggle to retain the ability to track changes and the cascading effects they generate at the dependency level. Moreover, engineers are by no means happy when they are deprived of such an opportunity and as a result it becomes more difficult for them to understand the essence of the problems that arise. ”
How to overcome these difficulties described above and move on to the massive use of DevOps in a large organization? Experts urge you to be patient, even if your ultimate goal is to speed up the software development cycle and business processes.
Jayne Groll, Executive Director of the DevOps Institute: “In my opinion, the DevOps extension should be as gradual and iterative as agile development (and equally affect the culture). Agile and DevOps focus on small teams. But as the number and integration of such teams grows, we get more and more people applying new methods of work, and as a result, a large-scale cultural transformation arises. ”
Eran Kinsbruner, Lead Technical Evangelist, Perfecto: “For scaling to work, DevOps teams first need to learn how to combine traditional processes, tools and skills, and then slowly grow each individual DevOps phase and stabilize it. It all starts with careful planning of user stories and value streams (valuestream), followed by the stage of writing software and version control using trunk-based development or other approaches that are most suitable for branching and code merging. ”
“Then comes the integration and testing phase, where a scalable automation platform is already required. And here it is important for DevOps teams to choose the right platform that meets their skill level and the ultimate goals of the project.
The next phase is deployment in a production environment, and it should be fully automated using orchestration tools and containers. At the same time, it is important to have virtualized environments at all stages of DevOps (a production environment simulator, a quality control environment and, in fact, a production environment) and always use only the latest data for tests in order to get relevant conclusions. Analytics must be smart and capable of processing big data with fast and efficient feedback. ”
Gordon Haff, RedHat evangelist: “Creating a system and atmosphere that allows and encourages experimentation allows for the implementation of so-called successful failures in agile software development. This does not mean that no one else is responsible for the failures. In fact, it’s even easier to establish a responsible person, since “being responsible” no longer means “becoming the culprit of the accident.” That is, the essence of responsibility is changing qualitatively. In this case, four factors become extremely important: the scale of the failure, approaches, production processes and incentives. ” (For more on these factors, see Gordon Huff's DevOps lessons: 4 aspects of healthy experiments.)
Ben Grinnell, Managing Director and Head of Digital Technology, North Highland Consulting: “To scale up, I recommend that the Pathfinder program be launched along with pioneering projects. The goal of this program is to clean up the trash that is left to the pioneers of DevOps, such as rules that have lost relevance and other similar things, so that the path forward remains clear. ”
“Give people organizational support and give impetus through communication that goes far beyond a pioneer group, widely celebrating the success of new working methods. Train people who are involved in the next wave of DevOps projects and are nervous about using DevOps for the first time. And remember that these people are very different from the pioneers. ”
Steve Newman, founder and chairman of Scalyr: “Tools should not be hidden from people, and they should be relatively easy to learn for anyone who is willing to spend time on this. If the ability to request logs is provided only to three people who are “certified” to work with some kind of tool, you will always have a maximum of three people who can deal with the corresponding problem, even if you have a very large computing environment. In other words, a bottleneck arises here that can lead to serious (for business) consequences. ”
Tom Clark, Head of Common Platform at ITV: “You can do anything, but not all at once. Therefore, set big goals, start small and move forward with fast iterations. Over time, you will gain a reputation as a team that succeeds, so others will also want to use your methods. And do not chase building a highly effective team. Instead, provide people with ideal working conditions and efficiency will come by itself. ”
Logan Daigle, CollabNetVersionOne DevOps Software Delivery and Strategy Director: “It’s important to understand the consequences of Conway’s law. In my free paraphrase, this law states that the products we create and the processes we use, including DevOps, turn out to be the same as our organization. ”
“If the organization is highly fragmented, and when planning, creating and releasing software, management passes from hand to hand many times, the effect of scaling will be zero or short-lived. If the organization forms cross-functional teams around products that are funded with a market orientation, then the chances of success increase dramatically. ”
“Another important aspect of scaling is to display on the kanban boards all the work in progress (WIP, workinprogress). When an organization appears in a place where people can see such things, it greatly stimulates cooperation, which has a positive effect on scaling. ”
Manuel Pais, DevOps Consultant, and co-author of Team Topologies: “Taking DevOps practices beyond Devi Ops itself and trying to apply them to other functions is hardly an optimal approach. This will undoubtedly give a certain effect (for example, due to the automation of manual control), but much more can be achieved if we start with an understanding of delivery processes and feedback. ”
“If there are old scars in the organization’s IT system - procedures and management mechanisms that were implemented as a result of past incidents, but have lost their relevance (due to a change in products, technologies or processes), then they certainly need to be removed or smoothed, and not automate inefficient or unnecessary processes. ”
Anthony Edwards, Eggplant Production Director: “DevOps is a very vague term, so each team has its own version of DevOps. And there is nothing worse when 20 varieties of DevOps immediately appear in the organization, which do not get along very well. Each of the three development teams cannot have its own, special interface between development and product management. As it is impossible for the products to have their own, unique expectations regarding the processing of feedback when transferring the production environment to the simulator. Otherwise, you will never be able to scale DevOps. "
Steve Newman, Founder and Chairman, Scalyr: “Work on recognizing the value of DevOps. Learn and feel free to talk about the benefits of what you do. DevOps incredibly saves time and money (just think: less downtime, shorter average recovery time), and DevOps teams must relentlessly emphasize (and preach) the importance of these initiatives for business success. So you can expand the circle of adherents and strengthen the influence of DevOps in the organization. "
Our own DevOps will arrive at the Red Hat Forum Russia on September 13 - yes, Red Hat, as a software manufacturer, has its own DevOps teams and practices.
Our engineer Mark Birger, who is developing internal automation services for other groups throughout the organization, will tell his story in pure Russian - how the Red Hat DevOps team migrated applications from Hat Virtualization managed by Ansible into a full container format on the OpenShift platform.
But that's not all:
After organizations have transferred workloads to containers, traditional application monitoring methods may not work. In the second report, we will explain our motivation to change the registration method and show the continuation of the path that led us to modern methods of journaling and monitoring.
The term DevOps arose 10 years ago and went from a hashtag on Twitter to a powerful cultural movement in the IT world, a true philosophy that encourages developers to achieve results faster, experiment and move forward using the iteration method. DevOps has become inextricably linked with the concept of digital transformation. But as is often the case with IT terminology, over a decade, DevOps has managed to acquire many definitions, interpretations, and misconceptions about it.
Therefore, about DevOps you can often hear questions like, is it the same as agile? Or is it some kind of special methodology? Or is it just another synonym for the word “collaboration”?
DevOps includes many different concepts (continuous delivery, continuous integration, automation, etc.), so isolating the main thing can be difficult, especially when you are partial to the subject. However, this skill is very useful, it does not matter if you are trying to convey your ideas to your bosses or just telling someone from your family or friends about your work. Therefore, for now, put aside the terminological nuances of DevOps and focus on the big picture.
What is DevOps: 6 definitions and analogies
We asked experts to explain the essence of DevOps as simply and briefly as possible so that its value becomes clear to the reader with any level of technical training. Based on the results of these conversations, we selected the most striking analogies and percussion formulations that will help you build your story about DevOps.
1. DevOps is a cultural movement
“DevOps is a cultural movement in which both parties (software developers and IT systems operation specialists) recognize that software does not bring real benefits until someone starts using it: customers, customers, employees, not the point, says Eveline Oehrlich, senior research analyst at the DevOps Institute. “Therefore, both of these parties together provide fast and high-quality software delivery.”
2. DevOps is what empowers developers
“DevOps gives developers the authority to own applications, launch them and manage delivery from start to finish”
“DevOps is usually talked about as a way to speed delivery of applications to production by building and applying automated processes,” said Jai Schniepp, director of DevOps platform at Liberty Mutual. “But for me it is a much more fundamental thing.” DevOps gives developers the authority to own applications or certain parts of the software, to launch them and manage delivery from start to finish. DevOps eliminates the confusion of responsibility and leads all participants in the process to create an automated and developer-driven infrastructure. ”
3. DevOps is a collaboration in the creation and delivery of applications
“Simply put, DevOps is such an approach to the production and delivery of software when everyone works together,” said Gur Staf, president and head of digital business automation at BMC.
4. DevOps is a pipeline
“Conveyor assembly is only possible if all the parts fit together.”
“I would compare DevOps with a car assembly line,” continues Gur Staf. “The idea is to pre-design and make all the details so that later they can be assembled without an individual fit.” Conveyor assembly is possible only if all the parts fit together. Those who design and make the engine should consider how to mount it to the body or frame. Those who make brakes should think about wheels, and so on. It should be the same with software.
A developer creating a business logic or user interface should think about a database that stores information about customers, about security measures to protect user data, and how it will work when the service starts serving a large, possibly even multi-million user audience. "
“To make people collaborate and think about those parts of the work that are done by others, rather than concentrating solely on their own tasks - this is the greatest obstacle that must be overcome. If it succeeds, you have excellent chances for digital transformation, ”adds Gur Staf.
5. DevOps is the right combination of people, processes and automation
Jayne Groll, Executive Director of the DevOps Institute, offered a great analogy to explain DevOps. According to her, “DevOps is like a culinary recipe in which there are three main categories of ingredients: people, processes and automation. Most of these ingredients can be taken from other areas and sources: Lean, Agile, SRE, CI / CD, ITIL, leadership, culture, tools. The secret of DevOps, as well as any good recipe, is how to choose the right proportions and mix these ingredients to increase the speed and effectiveness of work when creating and releasing applications. ”
6. DevOps - this is when programmers work as a Formula 1 team
"The race is planned not from start to finish, but rather, from finish to start."
“Talking about what to expect from the DevOps initiative, I’ll cite the NASCAR or Formula 1 racing team as an example,” says Chris Short, general manager of cloud marketing for Red Hat and publisher of the DevOps'ish mailing list. - The head of such a team has one goal: to take the maximum possible place according to the results of the race, taking into account the resources available to the team and the trials that fell to its share. In this case, the race is planned not from start to finish, but rather, from finish to start. An ambitious goal is set first, and then ways to achieve it are determined. Then they are divided into subtasks and delegated to team members. ”
“The whole week before the race, the team hones the pit stop. He is engaged in power and cardio training to be in shape on a grueling day of racing. He works out joint actions to solve any problems that may arise in the race. Similarly, the development team must train the skills of frequently releasing new versions. With such skills and a well-functioning security system, launching new versions in production also occurs more often. Within this worldview, an increase in speed means an increase in security, ”Short says.
“The point is not to do the“ right thing, ”Short adds,“ but to eliminate as many things as possible that stand in the way of the desired result. Collaborate and adapt based on the feedback you receive in real time. Be prepared for anomalies and work on improving quality to minimize their impact on movement toward the goal. That is what awaits us in the world of DevOps. ”
How to scale DevOps: 10 expert tips
Just DevOps and massive DevOps are two completely different things. We will tell you how to overcome the barriers from the first to the second.
For many organizations, the path to DevOps begins easily and nicely. Small passionate teams are created, old processes are replaced by new ones and the first successes are not long in coming.
Alas, this is just a fake shine, an illusion of progress, according to Ben Grinnell, managing director and head of digital technology at the consulting firm North Highland. Early victories are certainly encouraging, but do not help achieve the ultimate goal, namely, the massive use of DevOps in the organization.
It is easy to see that as a result, a culture of separation into “we” and “they” is formed.
“Often, organizations launch such pioneering projects, believing that they will pave the way for mass DevOps, without hesitation, they can and will others want to go this way,” explains Ben Grinnel. - Teams for the implementation of such projects are usually recruited from self-confident “Vikings” who have already done something similar in other places, but are new to your organization. At the same time, they are encouraged to break and destroy the rules that remain binding on everyone else. It is easy to see that, as a result, a culture of separation into “we” and “they” is formed, which impedes the transfer of knowledge and skills.
“And this cultural issue is just one of the reasons DevOps is hard to scale. DevOps teams are confronted with the growth of purely technical difficulties characteristic of fast-growing companies that have relied on IT technology, ”said Steve Newman, founder and chairman of the board at Scalyr.
“In the modern world, services change as soon as such a need arises. Continuing to implement and implement new features is, of course, great, but coordinating this process and fixing problems is a real headache, ”adds Steve Newman. - In very fast-growing organizations, engineers as part of cross-functional teams struggle to retain the ability to track changes and the cascading effects they generate at the dependency level. Moreover, engineers are by no means happy when they are deprived of such an opportunity and as a result it becomes more difficult for them to understand the essence of the problems that arise. ”
How to overcome these difficulties described above and move on to the massive use of DevOps in a large organization? Experts urge you to be patient, even if your ultimate goal is to speed up the software development cycle and business processes.
1. Remember that cultural change takes time
Jayne Groll, Executive Director of the DevOps Institute: “In my opinion, the DevOps extension should be as gradual and iterative as agile development (and equally affect the culture). Agile and DevOps focus on small teams. But as the number and integration of such teams grows, we get more and more people applying new methods of work, and as a result, a large-scale cultural transformation arises. ”
2. Allow enough time for planning and platform selection
Eran Kinsbruner, Lead Technical Evangelist, Perfecto: “For scaling to work, DevOps teams first need to learn how to combine traditional processes, tools and skills, and then slowly grow each individual DevOps phase and stabilize it. It all starts with careful planning of user stories and value streams (valuestream), followed by the stage of writing software and version control using trunk-based development or other approaches that are most suitable for branching and code merging. ”
“Then comes the integration and testing phase, where a scalable automation platform is already required. And here it is important for DevOps teams to choose the right platform that meets their skill level and the ultimate goals of the project.
The next phase is deployment in a production environment, and it should be fully automated using orchestration tools and containers. At the same time, it is important to have virtualized environments at all stages of DevOps (a production environment simulator, a quality control environment and, in fact, a production environment) and always use only the latest data for tests in order to get relevant conclusions. Analytics must be smart and capable of processing big data with fast and efficient feedback. ”
3. Get rid of the guilty taste
Gordon Haff, RedHat evangelist: “Creating a system and atmosphere that allows and encourages experimentation allows for the implementation of so-called successful failures in agile software development. This does not mean that no one else is responsible for the failures. In fact, it’s even easier to establish a responsible person, since “being responsible” no longer means “becoming the culprit of the accident.” That is, the essence of responsibility is changing qualitatively. In this case, four factors become extremely important: the scale of the failure, approaches, production processes and incentives. ” (For more on these factors, see Gordon Huff's DevOps lessons: 4 aspects of healthy experiments.)
4. Clear the way forward
Ben Grinnell, Managing Director and Head of Digital Technology, North Highland Consulting: “To scale up, I recommend that the Pathfinder program be launched along with pioneering projects. The goal of this program is to clean up the trash that is left to the pioneers of DevOps, such as rules that have lost relevance and other similar things, so that the path forward remains clear. ”
“Give people organizational support and give impetus through communication that goes far beyond a pioneer group, widely celebrating the success of new working methods. Train people who are involved in the next wave of DevOps projects and are nervous about using DevOps for the first time. And remember that these people are very different from the pioneers. ”
5. Make tools more democratic
Steve Newman, founder and chairman of Scalyr: “Tools should not be hidden from people, and they should be relatively easy to learn for anyone who is willing to spend time on this. If the ability to request logs is provided only to three people who are “certified” to work with some kind of tool, you will always have a maximum of three people who can deal with the corresponding problem, even if you have a very large computing environment. In other words, a bottleneck arises here that can lead to serious (for business) consequences. ”
6. Create ideal conditions for team work
Tom Clark, Head of Common Platform at ITV: “You can do anything, but not all at once. Therefore, set big goals, start small and move forward with fast iterations. Over time, you will gain a reputation as a team that succeeds, so others will also want to use your methods. And do not chase building a highly effective team. Instead, provide people with ideal working conditions and efficiency will come by itself. ”
7. Do Not Forget Conway Law and Kanban Boards
Logan Daigle, CollabNetVersionOne DevOps Software Delivery and Strategy Director: “It’s important to understand the consequences of Conway’s law. In my free paraphrase, this law states that the products we create and the processes we use, including DevOps, turn out to be the same as our organization. ”
“If the organization is highly fragmented, and when planning, creating and releasing software, management passes from hand to hand many times, the effect of scaling will be zero or short-lived. If the organization forms cross-functional teams around products that are funded with a market orientation, then the chances of success increase dramatically. ”
“Another important aspect of scaling is to display on the kanban boards all the work in progress (WIP, workinprogress). When an organization appears in a place where people can see such things, it greatly stimulates cooperation, which has a positive effect on scaling. ”
8. Look for old scars
Manuel Pais, DevOps Consultant, and co-author of Team Topologies: “Taking DevOps practices beyond Devi Ops itself and trying to apply them to other functions is hardly an optimal approach. This will undoubtedly give a certain effect (for example, due to the automation of manual control), but much more can be achieved if we start with an understanding of delivery processes and feedback. ”
“If there are old scars in the organization’s IT system - procedures and management mechanisms that were implemented as a result of past incidents, but have lost their relevance (due to a change in products, technologies or processes), then they certainly need to be removed or smoothed, and not automate inefficient or unnecessary processes. ”
9. Do Not Spawn DevOps Options
Anthony Edwards, Eggplant Production Director: “DevOps is a very vague term, so each team has its own version of DevOps. And there is nothing worse when 20 varieties of DevOps immediately appear in the organization, which do not get along very well. Each of the three development teams cannot have its own, special interface between development and product management. As it is impossible for the products to have their own, unique expectations regarding the processing of feedback when transferring the production environment to the simulator. Otherwise, you will never be able to scale DevOps. "
10. Preach the value of DevOps for business
Steve Newman, Founder and Chairman, Scalyr: “Work on recognizing the value of DevOps. Learn and feel free to talk about the benefits of what you do. DevOps incredibly saves time and money (just think: less downtime, shorter average recovery time), and DevOps teams must relentlessly emphasize (and preach) the importance of these initiatives for business success. So you can expand the circle of adherents and strengthen the influence of DevOps in the organization. "
BONUS
Our own DevOps will arrive at the Red Hat Forum Russia on September 13 - yes, Red Hat, as a software manufacturer, has its own DevOps teams and practices.
Our engineer Mark Birger, who is developing internal automation services for other groups throughout the organization, will tell his story in pure Russian - how the Red Hat DevOps team migrated applications from Hat Virtualization managed by Ansible into a full container format on the OpenShift platform.
But that's not all:
After organizations have transferred workloads to containers, traditional application monitoring methods may not work. In the second report, we will explain our motivation to change the registration method and show the continuation of the path that led us to modern methods of journaling and monitoring.
All Articles