11 Important Things You Need to Know About DevOps - Part One

From translator

In 2009, a movement arose abroad that called itself DevOps. At first glance, these are developers with the skills of system administrators and system administrators with the skills of developers. But in reality this is by no means the case. This approach has clear goals, philosophy, tools and methods that only some Russian-speaking companies are starting to use. It seems to me that this approach is undeservedly ignored by us and I would like to talk about 11 things you need to know about DevOps, in particular:

• What is DevOps
• what are its values
• how is it introduced
• whom does he benefit

I hope you enjoy this text.

1. What is DevOps and where did it come from?

The term "DevOps" is usually referred to as the emerged professional movement that advocates for a joint working relationship between developers and the IT department, resulting in faster execution of planned work (for example, high deployment rates), while increasing reliability, stability, stability and production security- Wednesday. Why developers and IT departments (hereinafter for the sake of brevity, admins)? Because, as a rule, the value stream is located between the business (where requirements are defined) and the customer (where the result is delivered).

It is believed that the DevOps movement originated in 2009 as a union of numerous related and complementary communities: the Velocity Conference, which was especially highlighted by the speech of “10 Deploys A Day” by John Allspaw and Paul Hammond, the “infrastructure as code” approach (Mark Burgess and Luke Kanies), "Agile infrastructure" (Andrew Shafer) and system administration at Agile (Patrick DeBois), Eric Rice's Lean Startup approach with its continuous integration, as well as the wide availability of cloud and PaaS technologies.

One of the co-authors of DevOps Cookbook, John Willis, wrote a fantastic post about this event.

2. How are DevOps different from Agile?

One of the principles of Agile is to provide working software with smaller and more frequent releases, in contrast to the Big Bang approach, which is inherent in the waterfall methodology. So Agile strives to have a potentially finished product at the end of each sprint (usually once every two weeks).

The high pace of deployment leads to the fact that administrators accumulate a large mountain of tasks. Clyde Logue, the founder of StreamStep, puts it this way: “Agile played an important role in developing to restore confidence in the business, but he inadvertently left IT Operations behind. DevOps is a way to restore trust in the entire IT organization as a whole. ”

DevOps is especially good at complementing Agile, as it extends and complements the processes of continuous integration and release of the product, giving confidence that the code is ready for release and carries value for the client.

DevOps allows you to create a much more continuous stream of work in the IT division. If the code is not sold in the form in the form in which it was developed (for example, developers deliver the code every two weeks, but it is deployed only once every two months), installation operations will accumulate in front of administrators, clients will not receive important functionality for themselves and the installation process itself in this case leads to chaos and disorganization.

DevOps, among other things, is changing the culture, as well as changing the processes and metrics of developers and admins. John Willis and Damon Edwards (co-authors of Cookbook DevOps) have written more about this here .

3. How is DevOps different from ITIL and ITSM?

Although many people think DevOps is a reaction to ITIL (IT Infrastructure Library) and ITSM (IT Service Management), I have a different point of view. ITIL and ITSM are still the best codification of the business processes that underlie the IT department, as they actually describe many things necessary for the IT team to be able to work in the DevOps format.

Continuous integration and releases are the result of the work of developers, which in turn is the material for the work of admins. In order to keep up with the faster release rhythm that exists in DevOps, many ITIL processes require automation, in particular, associated with a change in configuration and releases in general.

The purpose of DevOps is not so much to increase the speed of issuing new functionality, but to deploy this functionality in production, without chaos and disruption of an already running application, as well as quickly detect and fix problems if they do occur. This adds to ITIL items such as service configuration, incident and problem management.

4. How is DevOps similar to VisibleOps?

In collaboration with Kevin Behr and George Spafford, I wrote “Visible Ops Handbook” in 2004. Visible Ops provides guidance on how to transform to high-performance IT departments on the path “from good to great,” and one of the key concepts is to limit and reduce unplanned work.

DevOps, in turn, focuses primarily on how to create a fast and stable stream of planned work on development and administration. However, DevOps also has a more holistic approach to the systematic eradication of unplanned work, addressing the principles of responsible management and reducing technical debt.

5. What are the principles of DevOps?

In the DevOps Cookbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, we describe the underlying principles by which all DevOps patterns can be obtained using the Three Way approach. They describe values ​​and philosophy, which are the basis of processes, procedures, practices, as well as mandatory steps.

The First Way emphasizes the performance of the entire system as a whole, in contrast to the performance of an individual link or department - it can be either a large unit (for example, development or IT department) or individuals (for example, developer, system administrator).

The focus is on all the value stream business flows that are included in IT. In other words, it begins when the basic requirements are determined (for example, for business or IT), they are completed in development, and then transferred to the IT department, in which the value of the service is then delivered to the customer as a service.

The results of following the First Way in practice are that known bugs are never passed to the next stage of work, local optimization never develops, leading to the creation of global degradation, there is continuous improvement and the desire to achieve a deep understanding of the system (in accordance with Deming).

The second way is to create a feedback loop going from right to left. The goal of almost any process improvement initiative is to reduce and strengthen feedback so that necessary amendments can be implemented continuously.

The results of the Second Way: understanding and reaction to all customers, both internal and external, reducing and strengthening all feedback loops, and deepening knowledge about the environment where it is needed.

The third way is to create a culture that affects two things: constant experimentation, which requires taking risks and learning from successes and failures, and understanding that repetition and practice are prerequisites for mastery.

We need both of these principles equally. Experimenting and accepting risks is what ensures that we continue to improve, even if it means that we can go into too dangerous wilds. And we need to learn skills that can help us get out of the danger zone when we go too far.

The outcomes of the Third Way include taking time to improve day-to-day work, creating rituals that encourage the team to take risks and possibly create system malfunctions in order to increase sustainability in the long run.

6. Areas of implementation of DevOps

In the book “DevOps Cookbook”, we highlighted 4 DevOps implementation models:

Model 1 : Deepening development processes into delivery: this includes expanding continuous integration and release to battle servers, integration of testing and information protection into workflows, which gives ready-to-deliver code configured environment, and so on.

Model 2 : Creating feedback from sales to development: includes creating a complete chronology of events in development and administration in order to help solve problems, as well as providing access to the development team to analyze problems on the prod, while creating developers self-service services, wherever it is possible, and the creation of information radiators, showing a change in the behavior of the system when making changes.

Model 3: Combining development and administration: consists of including the development team in the problem-solving chain, appointing developers to solve problems at the prod, and also mutual trainings between developers and administrators to reduce the number of escalations.

Model 4 : Inclusion of an IT team in development: consists in the inclusion or close relationship between IT and development, the creation of multi-stage user stories (including deployment, code management in production, etc.), and the determination of non-functional requirements that can be used in all projects.

7. What is the value of DevOps?

I believe that there are three business benefits that organizations get from switching to DevOps: faster market entry (e.g., faster cycle times and faster deployment), better quality (e.g. increased availability, fewer crashes, etc.) , and an increase in organizational effectiveness (for example, more time is spent on activities related to increasing the value of the product compared to losses, increasing the amount of functionality transferred to the customer).

Fast time to market

In 2007, at the IT Process Institute, we tested more than 1,500 IT organizations and came to the conclusion that high-performance IT organizations were on average 5-7x orders of magnitude more productive than their low-performance peers. They made 14 times more changes, receiving problems in only half of the cases, while having the speed of fixing problems the first time 4 times higher, and also had 10 times shorter periods of downtime. They had 4 times less than the results of the re-audit, they were 5 times more likely to find violations due to the automated system of internal control, and 8 times better fit the project deadlines.

One of the characteristics of high-performance teams is that they go far ahead of the crowd. In other words, the best is getting better. This happens in the application deployment pace. Accenture recently conducted a study on what Internet companies are doing, and Amazon has set a record by saying that they are doing more than 1,000 deployments a day, maintaining a 99.999% successful change rate!

The ability to maintain high deployment rates (for example, fast cycle times) is transformed into business value in two main ways: how quickly the organization can move from an idea to something that can be transferred to the customer and how many experiments the organization can carry out simultaneously.

Without a doubt, if I work in an organization where I can only do one deployment every nine months, and my competitor can do 10 installations per day, I have significant, structural competitive weaknesses.

High deployment rates allow the experiment to be carried out quickly and almost continuously. Scott Cook, the founder of Intuit, was one of the most ardent supporters of the “rampant innovation culture” at all levels of the organization. One of my favorite examples is below :

»Each employee [should be able to] conduct fast, high-speed experiments ... Dan Maurer runs our customer department, including launching the TurboTax website. When he began work on this project, we did about seven experiments in a year. Through the introduction of an innovative culture, they are now doing 165 experiments over the three months of the tax season. Business result? Website conversion rate is up to 50 percent. Result for employees? People just love him because now their ideas can hit the market. "

For me, the most shocking part of Scott Cook's story is that they did all these experiments at the peak of the tax filing season! Most organizations stop change during the peak season. But if you can increase the conversion rate, and therefore sales, at the peak of the season when your competitor cannot, then this is a real competitive advantage.

Prerequisites for this include being able to make many small changes quickly, without interruption in customer service.

Reduce IT department losses

Mike Orzen and I once talked about the huge losses in the IT stream caused by long downtimes, slow transfer of work, unplanned work and alterations. For Michael Krigsman's article, we estimated how much useful activity we could return by applying the principles of DevOps.

We calculated that if we could just halve the amount of IT losses, and also redistribute these days in such a way that we can return five times more than what was invested, we would produce $ 3 trillion dollars of useful activity per year. This is a staggering amount of money and opportunities that we allow us to slip out of our hands. This is 4.7 percent of annual global GDP, or more than Germany’s total output.

I think this is important, especially when I think of a world in which my three children will live. The potential economic impact on labor productivity, living standards and prosperity puts this first.

However, there is another type of loss. People in most IT organizations often feel left out and frustrated. People feel as if they are trapped in an ever-repeating horror film and helpless to change the ending. Management renounces its responsibility for IT, which often leads to endless wars between the development, IT and information security departments. And it only gets worse when the auditors reveal it all. The life of IT professionals is often demoralized and full of disappointments, which, as a rule, leads to a feeling of powerlessness and fills with stresses that penetrate into every aspect of life.

As humans, we strive to create and feel that we are part of something big. However, all too often, when IT professionals ask their organization for support, they hear “You don’t understand,” or worse, barely covert, “You are nobody.”