Great, we are going to devOps-ping. So, 15 years of planning?

In large companies, the question “ What are these modern methods and technologies?” "Rather" How can we apply them? ".

DevOps has been around for almost 10 years , and in the last two or three years, large normal organizations have already become familiar with the tricks of DevOps. (“But what is this your DevOps ?!”, you probably thought. Let us agree that this is “ improving the quality of your software by speeding up the release cycle using cloud techniques and automation, as well as using additional benefits of software that remains in production ".)
')
When Matt Curry, the Agile transformation manager at Allstate, was asked about the use of DevOps, he replied: “ I think that when IT professionals try it out, they will never work differently .” You probably hear it again and again when it comes to implementing DevOps.

While making improvements and changes often seems to be 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 efficiency. As John Mitchell, director of digital strategy and delivery for Duke Energy, said: “ According to our business results, it’s 10 times better .”

Less analytic paralysis, more continuous planning

Focusing on improving software using DevOps techniques requires changing the way of thinking in an organization. Even after 20 years of supposedly practicing Agile, software development has traditionally been considered a long-term project, which is performed in order to meet a variety of 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 cycles that help improve applications as part of small-scale development .

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

In order for IT professionals to demonstrate a responsible approach to work, and in order for a business to be sure of this, the scope of each task must be precisely defined, limited and agreed upon in advance. All activities have to be combined into projects that have become units of work with a specific set of results, the beginning and the end.

Now Agile's very savvy fans are stuck with their fingers: “ Yes, but how do you know that the software being created is really useful? "This is precisely the goal of all the above mentioned methods of control.

A more modern view of creating an application implies that the future of software should be shaped based on a systematic study of users ’needs and desires, studying what solutions work (and which do not!), Building applications and observing how people use it, and then all The process begins again.

Usually, developers have only a vague idea of ​​what the 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 represent what they are headed for. But it often 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 accurately the developers follow the plan. Instead of checking the status of projects, you should check whether something valuable for business is delivered in the form of useful software.

Project management

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

Recently, after a long internal monologue on the topic of DevOps in a large digging, an astute project manager faced with the need to upgrade a critical software solution implemented as a “rat's nest”, but outdated services prevented him. It was a strange composition from a long list of inter-service dependencies, instructions, COTS uses, data features, and integrations. I remember my stinging character saying, “ Yeah. Looks like you need project management. Good luck. Next question! "

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

Finance

Dealing with financing in DevOps-oriented companies requires some care. As it was before: since the IT department itself acquired funds for development, the QA and Staging environments required capital investments (CAPEX). Required servers were a drop in the ocean 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 love 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 doesn’t keep track of expenses carefully, it can end badly.

Let me explain: operating expenses for production software environments may look less than the capital investments previously spent, however, when the application enters production, operating expenses may 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 efficiently manage 10,000 servers in production, then from a financial point of view, it is better to build your own data center. The size of the savings in this case will always be the subject of controversy (given that server manufacturers are constantly fueling our fears, uncertainty and doubts), but from a financial point of view it is better to keep a close eye on exactly where the calculations should be performed and how this will affect planning.

Get rid of tickets

Given the promise to put in order the processes of release management and the acquisition of IT resources, it is not surprising that changes are also taking place in the traditional management of IT services. The share and role of tickets in the development process decreases. John Mitchell: “ It's so nice when you don’t 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, and not wait for the closure of their tickets. It’s so nice to watch one of our mobile hipster developers chat 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 cajole them, but when they saw that the usual 35-40 applications per week turn almost to 0, this convinced them."

But think of all these unfortunate cabs!

Next, attempts are made to shove non-punching: “ If I make 8-15 releases per week, how can I get through all these change committees (CAB, Change Advisory Board)? ". Regardless of the benefits they bring, you need to speed up the work of the CAB, which, rather, “advise” so much that you will sooner or later have to confess to sabotage about the company's software development policy. In most companies with which I spoke, the emphasis is on automation, building conveyors, platforms. It is also obvious that usually you also need to replace from 9 to 5 Enterprise architects (how exactly - it is still unclear).

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

Start

So, instead of all these preliminary plans and reflections, we have a way to select and organize your first applications according to DevOps. A lot of advice from those who have already done it - or understood what it is time to do: start small. John Mitchell: “ We started little by little, and then we noticed that more and more business was being drawn into it .”

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

However, 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 operational / financial situation may force you to move all in.

Once you have decided which application you will be working on, the process of thinking through a good design begins. But instead of only doing preliminary analysis and drafting specifications (as you assumed!), Designers are involved throughout the development process. This implies changes in the thinking and organization of both the designers themselves and other divisions: 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 must be serviced, which usually changes the idea of ​​control. Companies need to constantly reduce the time spent on execution of tickets and the queue for code review, tirelessly increasing 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 is also changing as technologies automate some “manual” operations, and large companies are gaining more and more knowledge, perhaps even “killing” DevOps later and introducing something new to it.

At the leadership level, this emphasis on continuous learning implies the creation and maintenance of a company that is constantly improving, and even completely changing. MBA-nerds call it the “sense of urgency” (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 observed more than once: until some external threat to the company arises - ghm-ghm, Amazon, ghm - little will change, despite any orders from the management or the efforts of the young DevOps expert. But, as my more dismal colleagues like to quote : “It is not necessary to change. Survival is not mandatory. ” (“There is no need to change. Survival is not necessary”).