01 Definition of DevOps, What Issues Exactly Does DevOps Aim to Solve #

Hello, I’m Shi Xuefeng. Today let’s talk about the “definition” of DevOps.

In recent years, DevOps has been appearing more and more frequently around us. DevOps sessions often appear in various conferences, companies in the industry are actively hiring DevOps engineers, the transformation to DevOps within companies seems imminent, and there is a need to design and develop DevOps platforms within companies… It seems like DevOps is everywhere.

But if we think about it, have we really clarified many questions about DevOps? Does the so-called DevOps platform equate to an automated operations platform or a continuous delivery platform? What skills are required for a DevOps engineer position? Furthermore, how can we prove that a company has achieved a DevOps transformation? These questions have really stumped many heroes. After all, despite hearing about DevOps for so long, no one seems to be able to clearly explain its “definition”.

Now, let’s take a look at Wikipedia’s definition of DevOps. However, I doubt anyone can really understand what it’s trying to say.

DevOps (a combination of “development” and “operations”) is a culture, movement, or practice that emphasizes the collaboration and communication between software developers and other information technology (IT) professionals in the automation of software delivery processes and infrastructure changes. It aims to establish a culture and environment where building, testing, and software release can occur rapidly, frequently, and more reliably.

So, whenever DevOps is mentioned, the most common metaphor that pops up is “blind men touching an elephant”. Interestingly, Patrick, one of the fathers of DevOps, also used this metaphor when he attended the first DevOpsDays event in China. It seems that on this point, Chinese and Western cultures are the same. After all, everyone has a different perspective, so naturally, the understanding of DevOps varies greatly.

As the DevOps movement surges forward, many people are carried along to explore and practice DevOps. There is even an extreme view that believes that all good practices belong to DevOps, while all bad practices are anti-patterns of DevOps.

The same argument seemed to occur when Agile became popular, but this broad definition did not really help us to clarify our thinking. It even brought about a lot of negative voices, such as DevOps is about developers replacing operations, or DevOps is about operations abandoning their old expertise and making a full transition to development. This made many IT professionals anxious.

Objectively speaking, since the birth of the DevOps movement, those pioneers have never tried to give an official definition of DevOps. Of course, the benefits of doing so are obvious. As there are no limitations on the audience and scope, everyone can contribute to DevOps from their own standpoint, making the range of topics covered by DevOps increasingly broad.

However, the downsides are also evident. As DevOps continues to develop, those who are new to it often struggle and fail to see the bigger picture, and the deviation in understanding makes DevOps appear even more mysterious.

Instead of getting hung up on the definition of DevOps, it’s better for us to return to basics and see what problems DevOps actually solves.

The secret of DevOps lies in the two roles it represents in its name: development and operations. So what are the problems between these two roles? Let’s start from the three important stages of software engineering since its inception.

Waterfall Development Model #

The waterfall development model divides the software delivery process into several stages, from requirements to development, testing, and maintenance. Its concept is that as the scale of software development increases, it is necessary to define each stage in an engineering management manner, as well as the corresponding deliverables and delivery standards. This is in order to advance the entire project delivery process step by step through a process-heavy, control-heavy approach according to the plan.

However, with the accelerating changes in the market environment and user needs, this methodical approach has a serious potential problem.

Software development activities require determining project goals, scope, and implementation methods at the beginning of the project. However, this time point often has the least amount of information about users and the market environment. Making decisions at this stage often carries a lot of uncertainty, easily leading to constantly changing project scope, constantly delayed schedules, and repeatedly postponed delivery dates. The end result is that even if we invest a lot of resources, it is difficult to achieve the expected results.

According to statistics from industry giant IBM, 34% of new IT projects are delivered late, and nearly half of application systems have to be rolled back due to defects. This can be a very frustrating situation.

Agile Development #

In response to this problem, the agile movement began to flourish. Its core idea is that since we cannot fully understand what the true needs of the users are, it’s better to break down a big goal into smaller deliverable objectives and continuously develop them through iterative and incremental steps.

At the same time, testing is injected into the entire development process, shifting it from being an independent phase at the end of the development cycle. This continuous validation of the deliverables ensures that each deliverable is a usable set of features, and due to the quality being built-in during the development process, the quality of the delivered features is also guaranteed.

Clearly, agile is a more flexible development model. People often ask, does agile directly increase the development speed of a team? The answer is no. Just think about it, does adopting agile methods double or triple the coding speed of the development team? If we recall the widely known “The Mythical Man-Month” in the IT industry many years ago, we can understand how important it is to have the correct perception.

The reason why agile is faster is that continuous iteration and validation save a lot of unnecessary waste and rework. I will provide more detailed explanations on this point in the context of agile and lean-related content.

Ultimately, agile is derived from practical development. The application of agile allows the development and testing teams to work together. However, there is another problem. The development and testing teams find that no matter how fast the development speed becomes, at the other end of software delivery, there is always a group of people looking at them coldly. A simple phrase like “it’s not yet time for release” causes many newly developed features to fail at the threshold of going live.

After all, no matter how many “genius” features are developed, if they haven’t gone through the deployment and release process in the operations phase, and ultimately been delivered to real users, then these features are actually of no use.

DevOps Mode #

As a result, the operations team on the other side of the wall became the target of persuasion. These teams at the end of software delivery were always in a state of taking the blame. They also had the desire for change, so DevOps emerged. In other words, DevOps initially aimed to break the opposition and estrangement between development and operations.

In the traditional mode, the way to measure the efficiency of the development team is to see how many requirements have been completed by the development team. Therefore, in order to achieve performance goals and meet business requirements, the development team constantly piles up new functions, but rarely takes the time to seriously consider the maintainability and testability of these functions. As long as the requirements are passed to development, everything is fine.

On the other hand, the assessment indicators for the operations team are the stability, availability, and security of the system. However, modern IT systems are so complex that every release is a battle. The entire team is on guard against failure during deployment.

Many times, we don’t know what will happen after the release, and can only follow the deployment manual step by step and leave it to fate after completion. Therefore, during major promotional activities, there are often photos of various “praying to the server” widely circulated.

On the other hand, after being ravaged by development’s unreliable functional defects countless times, the operations team realizes that change is the biggest enemy affecting their performance goals. Therefore, the pre-set release window has become a safe haven for the operations team. The constantly increasing deployment threshold has also made it impossible for the development team to complete delivery. In the end, “mutual harm” has become the inevitable ending of this story.

Even today, deployment and release is still a sacred thing in most companies. Let me tell you an interesting story.

When I visited the father of DevOps, Patrick, in Europe last year, I visited his company. It was a snowy day and Ghent, Belgium looked very quiet. After we parked the car, we happened to meet Patrick and one of his colleagues smoking downstairs.

After a brief greeting, we learned that one of the systems managed by Patrick’s company was going to be released in 15 minutes. They took this opportunity to clear their minds, and then went back to work. So you see, even the father of DevOps is so serious when facing a release. It can be seen that the road to the development of DevOps is still long and arduous.

Since the beginning, the team gradually discovered that not only development and operations, but also the business is an important part of the entire software delivery process.

For example, if the business formulates an unreliable requirement, then no matter how well-developed and well-operated the collaboration is, the end result will be unreliable. This also leads to wasted manpower. However, the business is not clear about the real situation of the users. Therefore, the operations team gradually turned to the operations team, which needs to continuously and promptly provide feedback on real-time data and user behavior to the requirements team to help objectively evaluate the value of the requirements and make timely adjustments beneficial to product development. In this way, the business has also been involved in DevOps and even gave birth to a term called BizDevOps.

Since communication and collaboration are universal, security has also become actively involved. Security is no longer a “time bomb” after system release, but is involved in the entire software development process, injecting security feedback mechanisms into each process to help teams respond to security risks in a timely manner. For the security team, DevSecOps has become the focus of their DevOps.

Such examples are numerous, including functional departments and strategic departments, which have joined one after another, making DevOps expand from a point to a line, and then to a surface, continuously growing and developing. Everyone participates, making DevOps a knowledge and skill system that every IT practitioner needs to learn and understand.

In the end, based on my understanding of DevOps, I would like to give my own “definition”:

DevOps is an organic integration of platform, process, and people, guided by the CALMS (Culture, Automation, Lean, Measurement, and Sharing) culture. The ultimate goal is to establish a modern IT organization that can deliver value quickly and has continuous improvement capability.

Summary #

Today, I have taken you through the development process of DevOps and the evolution of software development models. Some say that DevOps is the third revolution in software engineering, indicating its profound impact on the industry as a whole. Merely echoing others’ opinions will not help us understand DevOps better. The first step to systematic learning is to establish the correct understanding. I hope that through today’s lesson, you can develop your unique understanding of DevOps.

Thought-provoking question #

Finally, I would like to pose a question to you: Does the definition I provided align with your expectations of DevOps? DevOps inherently embraces openness. Could you please share your understanding and definition of DevOps?

Feel free to leave your thoughts and answers in the comments section for further discussion and mutual learning. If you found this article helpful, please consider sharing it with your friends.