Serve and deliver

Former Tripwire CTO Jin Kim in The Three Ways: The Principles Underpinning DevOps (illustrations below are taken from the original article) writes about the so-called "Three Ways" (or three principles) that can achieve the elimination of missing links between Dev and Ops.

Later, Kim co-authored the business novels The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Project Phoenix, Eksmo, 2015) and The Unicorn Project (IT Revolution Press, 2019), whose heroes go precisely along these three paths. The first book was foundational to immersion and understanding of the process of implementing DevOps in a company.

As a result, the "three ways" in the DevOps context appear regularly: for example, at our DevOops 2020 conference, Vitaly Dmitriev from Liptsoft also tried to get back to basics and talked about his experience of using the "Three ways".

So what are these three paths?

The first way: systems thinking

The first way is to look at the performance of the entire system as a whole and focus on creating value. We formulate requirements that go through development and are transferred to operation. There the customer is provided with new value in the form of service.

The second way: amplifying feedback

The second way is to create a feedback loop. In fact, the goal of any process improvement initiative is to shorten and strengthen feedback loops so that the necessary corrections can be made consistently.

The third way: a culture of experimentation and learning

The third way is to create a culture that is conducive to two things: constant experimentation and learning from failure. People need to understand that repetition and practice are prerequisites for mastery.

The heroes of the book "Project Phoenix" "cope with this task like this:

“Very good,” he says. – You have combined tools – visual management of work and control of work through the system. This is an important part of the first path, that is, you have created a fast flow of work between the developers and the IT support department. Chalkboard cards are one of the best ways to do this because everyone can clearly see the workflow. Now you have to constantly reduce the amount of unplanned work, this is the second way. "

With the growing popularity of the idea, a whole cargo cult can grow around it. And DevOps did not escape this fate either, becoming a victim of its own success. There are many stories on the web of how companies, in pursuit of efficiency, made mistakes and everything ended in failure.

So is it culture?

According to Gartner, 90% of DevOps initiatives will fall short of expectations by 2023. Why? Due to a misunderstanding of the essence of the concept and the wrong approach to implementation. Rajesh Sethu, Director of DevOps at Replicon said in 2018: “The main reason DevOps is harder to implement than other methodologies is because it combines cultural change with operations and development. Changing the business culture – especially in large companies with established processes – is not something that can be instantly transformed at the level of people, processes and information. ”

All of this creates wrong expectations, which then turn into disappointment. The real effectiveness is lost behind external attributes, as the tools are put in the first place, not the culture of the process.

By 2015, DevOps ideas are becoming more popular – they promise success in the delivery of software, but due to the lack of a clear fixed definition, different companies begin to understand these ideas in their own way.

Is this DevOps?

Imagine a world where Product Owners, Development, QA, IT Operations, and Infosec work together not only to help each other, but to ensure the success of the entire organization. Working towards a common goal, they ensure that planned activities can be quickly deployed into production while ensuring world-class stability, reliability, availability and safety.

DevOps Guide

During the existence of this concept, it was interpreted in different ways by companies and people, everyone tried it on themselves and tested it for strength. In this part, we have collected and shared common beliefs about DevOps. And how much to agree with them – decide for yourself.

Instruments

Twitter account "DevOps Borat", tells us that it's human nature to just make a mistake, but you can't do without #devops to automatically propagate an error to all servers.

Despite the humorous message, there is a stereotypical perception of DevOps practices as a set of tools. Oftentimes, when people say they are using DevOps, they mean that they use Puppet for server configuration management, Ansible for deploying application versions, Cloudify for orchestration, and so on.

But Patrick Debois himself said in 2012 that DevOps is a human problem. And according to this view, what matters is not what tool is used for what. DevOps is not a tool, but a situation where:

Development and operation work in close collaboration.

Everyone understands each other's work: developers know the system for which they code (and adapt to it), and administrators know the code that they deploy (and understand how it affects the system).

Everything is developed in short iterations and can be quickly deployed (both infrastructure and applications) so that bugs can be fixed right away.

Damon Edwards lamented that enough was said about the importance of culture (“It all starts with culture,” “DevOps is a cultural and professional movement,” “Culture is more important than tools,” etc.). But as soon as everyone agrees that culture is above all else, the conversation turns to tools and … again to tools.

In 2012, when DevOps was already quite popular, one of the founders of the CAMS framework, John Willis, posted a gloomy tweet with the hashtag #devopsdead, where he announced that he was removing the letter C (culture) from the CAMS acronym. In response, Patrick Debois advised him not to despair.

Culture is still the hardest part of DevOps.

DevOps Teams

In order to implement DevOps, companies can start building new “DevOps teams” instead of bridging existing silos. But if we go back to the basics, then we understand that DevOps is not a person or some kind of thing, it is a process and a culture. If the company has a DevOps team of DevOps engineers, then the whole point is lost, since DevOps must be implemented in cross-functional teams.

The ultimate goal should be to move away from the old way of thinking, simplify the development process, and focus on people and processes. Yes, and old Frederick Brooks also noticed that simply adding new people to the system does not help it work faster or better.

DevOps and Agile

It's also important to remember that DevOps! = Agile, but without Agile, it's almost impossible to get the most out of building cross-functional teams. Achieving DevOps goals requires agile methodologies.

For example, Michael Hüttermann, a Java Champion, Delivery Engineer, and Agile and DevOps expert, has talked about this many times. In his book DevOps for Developers, he writes that Agile must be implemented in the operations department and this will eliminate the conflict between DevOps and Ops.

DevOps engineers

It is logical to assume that if DevOps is a culture and a process, and not an engineering specialty, then there should not be DevOps engineers, we have already written about this. Proponents of this position say that this phrase appeared from the desire of managers and HR-s to simplify their lives: if there is some need (in this case, in DevOps), then you can simply enter a role that will cover this need!

Others object to this: there are many tasks “at the junction”, someone has to perform them, and if the company has allocated a separate role for such people, why not call them “devops engineers”?

Regardless of whether you think this phrase is meaningful, it is pointless to argue with the fact that people actively use it.

Then the question is different: what do people mean to them in reality? It seems like completely different things depending on the situation. And if you monitor the vacancies of a "DevOps engineer", then the list of requirements can turn out to be colossal. Almost everything at once – a developer, a sysadmin, and a security specialist!

And here's how one Russian DevOps engineer talks about his role in 2021:

The programmer writes the code, and DevOps implements it. Naturally, there are a lot of nuances in the work of both. It's not enough just to inject the code, for this you need the appropriate tools, and there are many of them, and DevOps is also involved in setting up these tools. He is also a bit of an admin, developer, and tester. The tasks can vary greatly from company to company. I would say that there is no single definition of who a DevOps is and what he should do. This is not a problem of a specific profession – it's just that the IT-sphere has become more complex and a lot of abstractions have appeared.

DevOps engineers are developers who are interested in deployment and network operations or system administrators who are interested in scripting and code and move to development, where they can improve test and deployment planning. In any case, these are people who have gone beyond certain areas of their competence and have a more holistic view of their technical environment.

In itself, this is not bad, but in order not to upset Damon Edwards and John Willis, we note again that in their opinion DevOps is not something specific, expressed in tools or specific roles, but culture.

DevOps now

So what is DevOps in 2021? Tools, people, processes? Ability to write Bash scripts for a coffee machine?

Like many Agile frameworks, DevOps is not clearly defined, and each company will explain it differently. But his main idea behind DevOps is a culture of collaboration, and this idea has always remained the same. Patrick Debois and Andrew Clay Schafer, Paul Hammond, and John Allspaw talked about it, and now people like Baruch Sadogursky are talking about it.

And what then has changed in the 12 years of the existence of the concept? First, DevOps practices have gradually changed the overall approach to software delivery. From a newfangled word, everything turned into a generally accepted norm. Just as Agile has become a standard in development, so DevOps is becoming a standard in delivery.

And secondly, like Agile in its time, the idea is being further developed. For example, in 2020, Patrick Debois spoke at our DevOops conference with a talk DevSecOps: More of the same – back to the roots, and in particular, talked about how important it is to go back to the basics and see what is behind the buzzword “DevOps”. And now, almost from a mature methodology, a new one is growing – DevSecOps. Time and practice will show its viability, but for now, let us remind you that the most important thing in DevOps is people and culture.