Great, we are going to DevOps-scoot. It turns out, 15 years of planning processes - down the drain?

In large companies, the question “ What are these newfangled techniques and technologies? "Rather," How can we apply them in ourselves? ".

DevOps has existed for almost 10 years , and in the last two to three years, large, normal organizations have already mastered the wisdom of DevOps. (“But what is this your DevOps ?!” - you probably thought. We’ll agree that this is “ improving the quality of your software by speeding up the release cycle using cloud-based techniques and automation, as well as using the additional benefits of software that remains in production ".)

When Matt Curry, the Agile transformation manager at Allstate, was asked about using DevOps, he replied:"I think when IT experts try it out, they will never work differently . ” You probably hear that again and again when it comes to implementing DevOps.

Although making improvements and changes often seems like something that cannot happen in your organization, the results are too tempting to ignore, and the business expects IT to consistently increase its capabilities and effectiveness. As John Mitchell, director of digital strategy and supply at Duke Energy said, “ Our business results have made it 10 times better .”

Less analytic paralysis, more continuous planning

A focus on improving software using DevOps requires a change in the way you think about your organization. Even after 20 years of allegedly practicing Agile, software development is traditionally considered a long-term project that is carried out to meet many requirements and is focused on a specific release date. Slow and cautious Agile Release Trains and planning processes also make it difficult to increase the annual number of releases, becoming a barrier to feedback loops that help improve applications as part of small-scale development .

At the same time, many organizations switched to a project-oriented approach in software development. This means that IT staff and contractors are forced to carry out huge analytical work in advance and take on a lot of obligations, which are then used to manage them in order to maintain a work schedule.

So that IT specialists could demonstrate a responsible approach to work, and so that the business could be sure of it, the scope of each task had to be precisely determined, limited and agreed in advance. All activities have to be combined into projects that have turned into units of work with a specific set of results, beginning and end.

Now the very savvy Agile fans are pointing a finger: “ Yes, but how do you know if the software you create is really useful?“This is precisely the purpose of all the control methods mentioned above.

A more modern look at creating an application implies that the face of future software should be formed on the basis of a systematic study of the needs and desires of users, studying which solutions work (and which aren’t!), Building the application and observing how people use it, and then the whole the process starts anew.

Usually, developers have only a vague idea of ​​what a future application should do before they start working on it. Many fall into the traditional trap: they think that they deeply understand the problem being solved and absolutely accurately imagine what they are going to. But often it turns out that the team considers it necessary to go south, and as a result it turns out that it was necessary to go north.

This means that much less time is spent not only on preliminary planning, but also on subsequent checks on how closely the developers follow the plan. Instead of checking the status of projects, you should check whether something valuable to the business has been delivered in the form of useful software.

Project management

With all this talk about “products, not projects,” you probably hope that all of these project managers from the project management can be driven by a filthy broom. To a certain extent, this is true. But, as many have noted, a project management department is still needed, especially for fairly complex applications.

Recently, after a long internal monologue on the topic of DevOps in big digging, the astute project manager was faced with the need to upgrade a critical software solution, implemented as a “rat's nest”, but he was prevented by outdated services. It was a strange composition from a long list of interservice dependencies, instructions, COTS uses, data features and integrations. I remember how my stinging character said: "Yeah. It seems like project management is needed here. Good luck. The next question! “

Not so catchy, Matt Curry outlined his vision of heuristics for using enterprise-level project management. “ The project management department is extremely useful in the case of large volumes of development and a long feedback cycle. When volumes become much smaller and the feedback cycle shortens, the need for project management also decreases. Project management is also useful when you have a lot of external coordination . ”

Finance

Working with financing in DevOps-oriented companies requires some accuracy. As it was before: since the IT department itself acquired development tools, QA and Staging environments required capital investments (CAPEX). The required servers were a drop in the bucket compared to the amount of equipment needed for production, its cost even exceeded CAPEX. And thanks to the DevOps approach, which is usually based on the use of public cloud services, these costs are transferred to operating expenses (OPEX).

Of course, development teams like to work on the OPEX model, because it speeds up financial planning and the creation of a working infrastructure, which allows you to quickly create and release software. But if bookkeeping does not closely monitor expenses, it can end in disastrous condition.

Let me explain: operating costs for environments for preparing software for production may look less than the previously spent capital investments, however, when the application goes into production, operating costs can begin to multiply, like algae in a standing pond. This is especially true for successful applications that digest funds allocated for operating expenses with unpredictable speed. If you can effectively manage 10,000 servers in production, then from a financial point of view it is more advisable to build your own data center. The amount of savings in this case will always be the subject of controversy (given that server manufacturers are constantly feeding our fears, uncertainties and doubts), but from a financial point of view it is better to carefully monitor exactly where the calculations should be performed and how this will affect planning.

Get rid of tickets

Given the promise to streamline release management and IT resource acquisition processes, it is not surprising that change is also coming to traditional IT service management. The share and role of tickets in the development process is reduced. John Mitchell: “ It is so nice when you do not need to ask, plan and wait for the appearance of infrastructure. A team of “cloud” engineers sitting with developers can solve problems in real time, rather than wait for their tickets to be closed. It’s so great to watch one of our mobile hipster developers communicate in a friendly way with a hefty brutal ops engineer . ”

Such a clear and measurable metric is a good way to motivate all of these BOFHs.. "At first it was difficult to appease them, but when they saw that the usual 35-40 applications per week turned into almost 0, it convinced them."

But think of all these miserable cabs!

The following are attempts to cram the unapproachable: “ If I make 8-15 releases a week, then how do I go through all these change committees (CAB, Change Advisory Board)? ". Regardless of the benefits they bring, it is necessary to accelerate the work of CABs, which are more likely to “advise” so much that sooner or later you will have to confess to sabotage regarding the software architecture development policy adopted by the company. Most of the companies I talked with focus on automation, the construction of conveyors, and platforms. It is also obvious that usually you also need to replace from 9 to 5 Enterprise architects (how exactly - it is not yet clear).

Tools like Chef's InSpec can provide some help in verifying software deployment in production .. At the same time, native cloud platforms, such as various distributions of Cloud Foundry, Red Hat OpenShif and Istio, contain components that help turn CAB into robots.

Start

So, instead of all these preliminary planning and reflection, we have a way to select and organize your first applications according to DevOps. Great advice from those who have already done this - or realized that it was time to do it: start small. John Mitchell: “ We started a little bit, and then noticed that more and more business is getting into it .”

Sources close to Home Depot widely talk about how they started there with small projects, gradually moving to larger ones. These initial projects were called “scientific”, but had real value for the business (for example, the organization of places for painting and using rented tools). The success of such projects means creating business value (read: less sludge, more money). On the other hand, as you learn more about using DevOps, related errors will play a lesser role than, for example, dropping a .com site.

True, sometimes you have to immediately make big bets. In general, it all depends on the cash flow in the company. Starting small is not so risky, but the operating / financial situation can make you go all-in.

As soon as you decide which application you will work on, the process of thinking through a good design begins. But instead of only doing preliminary analysis and drawing up specifications (as you expected!), Designers participate throughout the development process. This implies a change in the thinking and organization of both the designers themselves and other units: they will interact every day, and not be watched from the side of their cozy cabinets.

The easiest day is yesterday

As soon as we start the engine, it needs to be serviced, which usually changes the idea of ​​control. The company needs to constantly reduce the time it takes to execute tickets and the queue for code review, constantly improving efficiency wherever possible. The most important and useful part of DevOps is the principle borrowed directly from the concept of “lean manufacturing” - continuous improvement. DevOps itself also changes as technologies automate some “manual” operations, and large companies gain more and more knowledge, possibly even “killing” DevOps later and introducing something new to replace it.

At a senior level, this emphasis on continuing education involves creating and maintaining a company that is constantly improving and even changing completely. MBA nerds call this the “Sense of Urgency”. And, as it has long been known, if the company does not have this desire for change, then nothing will happen. In recent years, I have watched more than once: until there is some kind of external threat to the company - ghm-ghm, Amazon, ghm - little will change, regardless of any orders from the leadership or the efforts of the young DevOps expert. But, as my darker colleagues like to quote : “It is not necessary to change. Survival is not mandatory. " ("There is no need to change. Survival is not necessary.")