What is DevOps

1. The Cause

I am a “DevOps engineer”, so I always get asked: “What is DevOps?”

This question seems very basic, so basic that many people don’t bother to answer. But in fact, calm down for a second and ask yourself “What is DevOps?” and every DevOps engineer probably knows “what is DevOps”, but they give different answers.

So how would I answer this? Let’s talk about it below.

2. Memories

I first saw the term DevOps around the fall of 2016. At that time, I was working on cloud computing R&D related work at H3C. I remember the first task I got was to study a CICD-related component of OpenStack called Solum, and that was the first time I knew what CICD was and the first time I saw the word DevOps. Yes, I just saw DevOps, but I couldn’t remember the definition of DevOps. Or rather, I didn’t even find a clear and understandable definition of DevOps at that time. Probably many people, like me back then, have the same image of DevOps as Dev + Ops.

In the summer of 2018, I started to work as a CMO (Configuration Management Officer) and head of the PaaS group of Cloud Platform. CMO, simply put, is responsible for the platform’s source code management, R&D collaboration process, versioning, CICD, product management, release process and so on. At this time, I was already working on some DevOps-related tools, such as GitLab, Jenkins, Zendo, Artifactory, Nexus, etc. I was also leading some DevOps culture building, such as what patterns or behaviors are encouraged and what things are prohibited in the team. …… But I was just making the rules, not realizing it was “culture”. Anyway, during those years, I was involved in DevOps, working on improving the efficiency, delivery efficiency and quality of the team’s R&D, but at the same time I didn’t think hard about the question “What is DevOps?”, and I didn’t deliberately think about whether I was playing DevOps.

At the end of last year (2021), I joined my current company and for the first time, my title changed from “xxx Cloud Platform R&D Engineer” to “xxx DevOps Engineer” (xxx means junior, intermediate, senior, etc.). I joked the other day, “before, I was playing DevOps part-time in cloud-native; after, I’m playing cloud-native part-time in DevOps”.

Well, now that I’m a legitimate “xxx DevOps engineer”, I should know “what is DevOps”, right?

3. Listen to see what others say

Let’s take a look at how a few typical companies define DevOps in their eyes, including.

• Atlassian (representative products: Jira, Trello, etc.)
• Microsoft
• AWS

3.1. Atlassian answers the question “What is DevOps?”

Atlassian has an article titled DevOps, which includes the following quote.

DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.

You can see that the equation given by Atlassian is: DevOps = Tools + Practices + Culture

Atlassian also mentions a DevOps team that includes development and IT operations, working together to improve software quality and accelerate the software development process by collaborating on the entire product lifecycle. The DevOps model is one in which development and operations are no longer separate silos, but are almost integrated into one team, with a technology stack of engineers covering development, testing, and operations. At the same time, DevOps teams leverage a range of DevOps toolchains to achieve things like continuous integration, continuous release, process automation, efficient collaboration, and more.

The “infinity loop” given by Atlassion looks like this.

The “infinite loop” is used to represent the DevOps lifecycle because the underlying philosophy of DevOps is “continuous”, which means “no end in sight”. divides the entire DevOps lifecycle into six phases, which are

• Plan
• Build
• Continuous Integration and Deployment or Delivery
• Monitoring and Alert (Monitor and Alert)
• Operations
• Continuous Feedback

Also from this loop we can see that Atlassian wants to emphasize Communication and Collaboration is a lifecycle process throughout DevOps.

3.2, Microsoft answers the question “What is DevOps?”

This Microsoft article Introduce the foundation pillars of DevOps: Culture and Lean Product is my favorite! The title means “Introduce the foundation pillars of DevOps: Culture and Lean Product”.

The first sentence of the article reads.

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

DevOps is the combination of people, process and product that enables the continuous delivery of value to end users.

Microsoft also mentions.

Typically, the goal for Development is to deliver more features faster, and the goal of Operations is to achieve better system stability. DevOps aligns these disciplines by using a framework of best practices proven to increase speed to market while improving system stability.

Here Microsoft can see the first equation given by Microsoft: DevOps = People + Process + Product

Then Microsoft further distills the 4 pillars of DevOps from “People + Process + Product”: Culture, Lean Product, Architecture and Technology.

That is: People + Process + Product -> Culture, Lean Product, Architecture + Technology.

Microsoft’s “infinity loop” looks like this.

The DevOps lifecycle depicted in the diagram is still divided into 6 phases, which are.

• Plan
• Build
• Continuous Integration
• Deploy
• Operation
• Continuous Feedback

Plus “Collaboration” throughout the DevOps lifecycle.

Outside of the diagram, Microsoft also defines the top 8 capabilities of DevOps for them.

• Continuous Planning
• Continuous Integration
• Continuous Delivery
• Continuous Operations
• Continuous Quality
• Continuous Security
• Continuous Collaboration
• Continuous Improvement

Every time I see this I always feel that Microsoft’s diagram should be updated in a version.

In addition, Microsoft has a particularly in-depth summary of.

What is new? Continuous Everything. The process is a journey and requires a growth mindset to continually evolve and improve.

3.3. AWS answers the question “What is DevOps?”

Not surprisingly, AWS also has an article answering the question “What is DevOps?”

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.

Here AWS gives an equation. DevOps = Culture + Practice + Tools

But instead of drawing an “infinity loop” of its own, AWS gives this diagram in this article

Mentioned here.

• Build
• Test
• Release
• Monitor
• Plan

You can also see that this “delivery pipeline” and “feedback loop” connects the “enterprise” to the “customer”. It is clear that AWS wants to emphasize that “the purpose of DevOps is to deliver faster to customers”.

4. DevOps Culture

I once one-sidedly thought that DevOps was only about tools, that is, how to choose or develop a good DevOps tool or platform to improve the operational efficiency of the whole R&D lifecycle within the enterprise. I don’t remember which day, I suddenly had a strong idea: tools are just tools, culture building is the key to success or failure!

Culture determines how we do things, tools determine, determine what? Probably nothing can be decided. Because I think the tools are also determined by the culture.

4.1. What is culture?

Simply put, culture is an organization’s social heritage, that is, an organization’s pattern of response to the various behaviors of its members.

For example, when we say a company has an “overtime culture”, we are actually saying that in this company, employees will be rewarded for working overtime and punished for not working overtime. Or when we say that an enterprise has a “wolf culture” or a “struggler culture” …… the different cultures correspond to the different response patterns of the enterprise to the different behaviors of its employees The culture of an enterprise determines the behavior of its employees.

The culture of an enterprise determines what is right in the enterprise.

1. what things are right and what things are wrong.
2. what is important and what is not important.
3. what things are worth doing and what things are not worth doing.

So culture determines which people a company will go to recruit, which people it will fire and which people it will promote.

See here may be you are already thinking about what you have stayed in the company what requirements for employees, in what to encourage, in what to punish …… Yes, at this moment in your mind flashes a scene is the corporate culture.

4.2. What is a DevOps culture?

This picture is certainly not new to anyone.

What is a DevOps culture?

In fact, we can see the culture in this diagram. We all know that DevOps emphasizes bridging the gap between development and operations teams, requiring the two teams to align their perceptions and responsibilities, to stop working separately, and to work together to deliver higher quality products faster. Yes, this is the basic DevOps culture.

So how do you pull together perception and responsibility?

The first thing you can confirm is that we have a direct blend of Dev and Ops teams in our organizational structure, and this is not a DevOps team. People are not sitting together, all that changes is the efficiency of communication. Here I would like to emphasize two points.

1. shared responsibility, where everyone in a DevOps model team needs to be held accountable for the entire lifecycle of software development delivery.
2. skills sharing, through continuous learning, learning from each other, so that engineers who are traditional Devs learn Ops skills, while traditional Ops engineers also need to learn Dev skills.

Dev and Ops learn from each other’s domain skills, everyone knows development and Ops, with a “growth mindset” and continuous learning, not satisfied with the current technology stack they have mastered.

But we also need to realize that we can’t ask every engineer to be proficient in development and Ops, it’s impossible. Here the Dev mastering Ops ability, more is the Dev can use the perfect tool chain to master the ability of “application operation and maintenance”, to be able to complete their own development, have the ability and authority to deploy the application online, and at the same time online application problems, can be directly responsible for it, positioning, repair, update and upgrade, etc.. Some infrastructure operations and maintenance capabilities need to be considered independently, such as the configuration of the LAN in the server room, virtual machines hanging NAS disk and other traditional operations and maintenance capabilities.

Similarly, Ops needs to understand the application development lifecycle and know the pain points of Dev, especially in the process, such as how to improve the build speed of the application, how to optimize the cd process of the application, etc. Ops should focus on the “production process” of the application, and then make efforts to optimize this process or the corresponding tools, so that the application can be more The Ops should focus on the “production process” of the application, and then focus on optimizing this process or the corresponding tools, so that the application can complete the cicd process more reliably and quickly, and be deployed online or delivered to the public more easily. In other words, we are not asking Ops to write business code, but to help Dev to solve the pain points beyond business code, so that Dev can focus more on business function implementation.

Finally, each person in a DevOps model team is responsible for the speed and quality of the entire software development lifecycle, and each specific role is like a big head nail, with a wide bottom, representing a wide range of technical aspects, focusing on all aspects of the entire software development lifecycle; at the same time, the top is very high, focusing on a certain part and doing a good job.

What is the key to successful DevOps implementation?

In the “happy together” scenario we talked about earlier, we want Devs and Ops to learn from each other, share responsibility, and work together to deliver products faster and better. But why do engineers want to do this? What motivates them?

4.3. Leadership and Motivation

Gartner had an analysis report that showed that in 2023, 90% of DevOps changes will fail (compared to expectations). The main reason for this failure is the limitations of the leadership approach to management.

It is clear that DevOps can be called a “change” and that many people are resistant to “change” and “new things”. For example, DevOps encourages accepting failure, failing fast, learning from failure, and then striving for greater success in a longer time dimension. But if you have a “failure punishing” leader, then your team will fear failure and give up creating and trying new technologies, choosing to settle for the status quo.

The leader of a technical team needs to be technically savvy and experienced, which is a basic requirement. But in addition, it is more important that the team leader can motivate the whole team, to play the initiative of the whole team, so that all team members can be motivated to continue to learn, learn quickly, but also dare to fail, fail quickly and not afraid of failure, the failure as an opportunity to learn, and then continue to grow, so that the whole team can be stronger and stronger.

So how do leaders motivate engineers?

Benefits? For example, free snacks or regular afternoon tea provided by some big factories? Free coffee or lunch?

Yes, as an engineer, all these benefits will make him/her happy, but actually cannot motivate him/her to work harder and more seriously. The salary level of engineers is generally not low, and all these snacks or coffee are not likely to be a fraction of their monthly salary. By the same token, when engineers look for jobs, they will never look at whether a company provides free lunch and afternoon tea.

So what do engineers look for?

When choosing a company, the first thing an engineer may consider is the salary, and the rest may be the room for growth, whether the work content is interesting and so on. But after entering a company, what do engineers look for when they really start working? I think it may be.

• Proficiency
• self-driven
• Goal

Let’s explain each one in turn.

1. Proficiency

   We do a good job in a certain direction, we are good at a certain technical direction, and then we can do the corresponding work well, then we will have a sense of achievement, satisfaction, we will feel comfortable with it, and at the same time will probably be recognized, praise, so the next time we will be more willing to continue to work in this direction, do better. That is to say, an engineer can have the opportunity to focus on his proficient technology, then he will probably feel motivated.

   What is the opposite example? Let’s say you’re a Java engineer, but your leader is good at PHP and thinks it’s the best language in the world, so he asks the whole team to switch to PHP, would you give up the Java technology stack you’ve been working on for years to learn PHP and be determined to make something happen?

2. Self-driven

   We want to assemble a learning, creative team where everyone can continue to grow, be open to innovation, and be self-driven. This requires leaders who can allow the team to take the time to learn and input, rather than just output and report back every now and then on how many lines of code they have written. It also requires the leader to be open to new things and embrace change, rather than “not trying to get something done, but trying to get nothing done”. For example, if your leader is most worried about accidents in online applications, and he believes that the first element of stability is not to introduce new technologies and tools, then your leader will not care if you have time to learn and will not allow you to spend time on new technologies, because all this will only bring instability. If the leader is afraid of losing control and thus refuses to innovate, then such team members will have to be satisfied with achieving day-to-day iterations of routine requirements development, rather than enjoying technology, being self-driven, and embracing innovation.

3. Goal

   Obviously, each member of the team needs to know why they are doing it? What is the purpose? What is the goal? Instead of the leader hiding a goal in his mind and then simply directing team members to complete a specific piece of fragmented work items. If the team members only know that they need to complete task A today and task B tomorrow, but do not know why they are doing it and what they want to do in the end, then they will only be satisfied with completing the task mechanically and will not be motivated to pursue “how to do better”.

5. Summary

So what is DevOps?

I’ll try to give my answer.

DevOps is a combination of cultural philosophy, tools and practices aimed at delivering value to users faster and more reliably on a consistent basis. The most important of these is Culture, a culture that requires Dev and Ops teams to share responsibilities and goals, and also requires the entire team to continuously learn, have a growth mindset, and Continuously Everything. secondly DevOps cannot be separated from an efficient Tools set, and tools are the foundation for automation. Finally, we need to pursue best practices in all aspects, whether it is the use of tools, or the team’s collaboration model, communication methods above.