Special Delivery Three, the Classic Resources You Must Understand to Learn Dev Ops

Special Delivery Three, The Classic Resources You Must Understand to Learn DevOps #

Hello, I am Shi Xuefeng.

Today, it’s time for another special broadcast. During the process of learning and exchanging ideas about DevOps, people often ask these questions:

  • I want to learn DevOps, can you recommend some good books and resources?
  • Where can I find the latest industry cases related to DevOps?
  • How do you know so many interesting stories?

These questions have a high frequency of appearance, so today I will specifically talk about DevOps learning materials with you.

You may have also noticed that in this age of information explosion, when we want to understand something new, the problem is not that there is too little information but rather too much. For a hot topic like DevOps, there are plenty of related materials available online. New books are also being published at an increasing frequency, just like “adopting DevOps practices”. With so much information, we easily become anxious about when we can finish reading it all.

Moreover, if we only focus on selecting useful materials, it will take a lot of time. According to lean theory, this is not a value-added activity. In this age of time scarcity, wanting to spend a lot of time on one thing and find reliable and valuable information has become the first step for many people to start learning.

Therefore, in order to allow you to continue learning more effectively while reading this column, I have specially organized a list of materials that I believe DevOps practitioners need to know and pay attention to. You can refer to it.

It should be emphasized that it is more rewarding to thoroughly read a part of a good book with targeting instead of reading several books in a vague manner. That is to say, “quality over quantity”. Set a small goal first, then concentrate and repeatedly learn and practice. This principle applies to most fields.

A Report #

If there is an industry-recognized authoritative reference in the field of DevOps, the DevOps State of DevOps Report is the top choice.

Starting in 2014, this report has been published annually and has undergone several changes in its main authors, from the initial Puppet Lab and IT Revolution to the addition of DORA (DevOps Research & Assessment), and then last year, DORA and Puppet split, with each of them releasing their own DevOps State of DevOps Report.

However, in terms of influence, I would recommend DORA’s report. Starting last year, this report was officially renamed “Accelerate: State of DevOps Report”.

You may not be familiar with DORA, but if I mention the two core founders of DORA, Dr. Nicole Forsgren and Jez Humble, I believe you will have heard of them. They are also the authors of some books I recommend today.

Interestingly, last year DORA announced its joining of Google, and its key members were also assimilated into Google Cloud, such as Jez Humble, who is currently a technology evangelist for Google Cloud.

Regarding the report itself, I have been localizing the report since 2017. Looking at the past two years, the size of the report has been continuously expanding. For example, this year’s report is a whopping 80 pages long, and it is entirely in English.

So, what should we focus on in regards to this report? Looking at the patterns of the past few years, let me highlight the key points for you: the trend, the model, and the practice.

First, the trend.

Every year’s report will have some key findings that represent the development trends of the DevOps industry. For example, this year’s report points out that the use of cloud computing capabilities continues to be the dividing line between high-performing and low-performing organizations in terms of efficiency. So, if your company is still hesitating about whether to move to the cloud, it might be worth considering from the perspective of DevOps how much improvement in delivery capabilities can be achieved by utilizing cloud computing.

In addition, the proportion of DevOps organizations within companies has increased from 14% in 2014 to 27% this year. This indicates that more and more companies are embracing DevOps. At least from an organizational level, we can see an increasing number of teams with DevOps responsibilities, or teams named after DevOps. This has a certain guiding significance for the delineation of internal responsibilities and the evolution of team structures within companies.

And of course, we cannot forget the four core metrics used to measure the effectiveness of DevOps implementation: lead time for changes, deployment frequency, change failure rate, and mean time to restore service.

Since the first report in 2014, each year’s report has been comparing these four core metrics and their variations and differences among teams with different levels of performance. In fact, based on my observation, many DevOps measurement systems in China are deeply influenced by these metrics to a greater or lesser extent.

It can be said that these four metrics have become the de facto standard for measuring the effectiveness of DevOps and some people even directly present these metrics to their bosses, saying, “Look, the mean time to restore service for high-performing organizations is 2000 times faster than that for low-performing organizations. This proves that DevOps is a must.”

Personally, I don’t think it’s necessary to fixate on the numbers themselves. Just take a look at them. What’s more important is to look at the trends through the data.

For example, last year’s data showed that while the gap between different organizations in terms of delivery capability was narrowing, the differences in quality dimensions were expanding. This indicates that teams can quickly improve their delivery levels through initial automation capability building. However, due to the lack of supporting quality capabilities, more issues are likely to arise. This brings a warning: while rapidly improving delivery capabilities, we should not neglect quality development.

Regarding reports, the next thing to consider is the model.

In the 4th lecture, I mentioned a viewpoint: the maturity of any technology is marked by the stability of its models and frameworks. Because when a technology crosses the early gap and faces a large audience, it is difficult to promote and develop on a large scale without a set of models and frameworks to help people keep up with the pace and find the right direction.

This is true in the field of software development, as well as in other industries. Otherwise, why would there be so many national standards? Therefore, the establishment of models and frameworks is a watershed from disorder to order.

In this year’s status report, the R&D efficiency model has been further refined into the software delivery and operation model and the productivity model. Today, I will not delve into the model itself, but I will explain it in detail in the later contents of the column, combined with practical cases, to help you better understand.

However, from past reports, it can be seen that the evolution of models is the core content of the entire report each year. The report also continues to cover new areas, attempting to comprehensively reveal the core elements that affect software development efficiency. When practicing DevOps, you can refer to this capability model to identify current bottlenecks and consider the impact of the model’s elements when encountering uncertain decisions.

For example, internal debates in companies often revolve around whether stricter approval processes are needed to promote orderly and reliable software delivery. Many systems and requirements are guided by this thinking. I have always been skeptical of the effectiveness of such processes, as adding more leadership approval steps only brings joint responsibility when something goes wrong without any added value.

In this year’s model, this viewpoint has been confirmed. Heavy process control does not contribute to the improvement of software delivery efficiency, while light process control does not affect the quality of software delivery. The key is whether the company chooses a “better” approach to achieve control purposes.

Finally, we need to focus on practice.

When implementing DevOps, there is often the dilemma of understanding the principles but still failing to do DevOps well. Therefore, the core of DevOps implementation lies in practice and culture, which are tangible and worthy of attention. The status report dedicates a significant amount of content to introducing the practice section, which is summarized and verified in most companies and has strong reference value.

For example, this year’s report focuses on the practice of technical debt, disaster recovery testing, and change management processes, all of which are essential aspects of implementing DevOps in enterprises.

For example, disaster recovery testing. Many companies have very detailed documentation, but when asked for operation records, they find it difficult to provide them.

I have previously encountered a top domestic company that claimed to be backing up critical data, but when I actually checked, I found that this backup task had been in a failed state for a long time.

If there were regular disaster recovery tests, such issues would definitely be discovered. And often, a company’s engineering capabilities can only be reflected when a disaster occurs.

For example, Netflix was able to remain unaffected by the failure of AWS cloud services precisely because of their chaos engineering, which is closely related to daily drills.

I have already collected and organized the Chinese and English versions of the DevOps Status Report from 2014 to the present. You can click the shared drive link to access it. The extraction code is mgl1.

Some Good Books #

After finishing the presentation, next, I will recommend several good books to you.

1. Continuous Delivery & Continuous Delivery 2.0

When it comes to engineering practices in DevOps, continuous delivery can be said to be the ultimate goal of software engineering practices. For those who are promoting DevOps engineering capability building within organizations, these two books are essential references that are worth reading regularly.

For myself, because I happened to obtain the first edition, first printing of Continuous Delivery in 2011, my career changed completely. It was the first time I discovered that there were so many ways in the field of software delivery. Helping organizations improve their delivery efficiency can indeed achieve great results.

Continuous Delivery provides a series of thoughts, methods, and practices centered around software delivery principles, with the core concept being: Deliver your changes (features, configurations, defects, experiments) to the production environment in a sustainable, safe, and fast manner for users to use. You can refer to the 8 principles of software delivery.

  • Create a repeatable and reliable process for software delivery
  • Automate almost everything
  • Put everything under version control
  • Do painful things frequently
  • Build in quality
  • DONE means released
  • Delivery process is the responsibility of every team member
  • Continuously improve

Many people have Continuous Delivery, but I dare bet that there aren’t many who truly understand the book thoroughly because it is filled with text and can be difficult to understand. Without relevant practical experience, it is almost like reading a foreign language.

Therefore, fully reading Continuous Delivery is not a good option. I suggest that you read it selectively with specific questions in mind.

In Continuous Delivery 2.0, Qiao Liang creatively combines the Lean Startup concept with Continuous Delivery, emphasizing the fast closed-loop between IT and business and adapting to the current development trend of DevOps.

Furthermore, Qiao Liang’s writing is more fluent and easier to read. He provides examples for explanation, offering stronger guidance for practical operations. Without a doubt, he is a leading figure in the field of software engineering in China.

If you are not familiar with engineering practices in the software development process, you can read these two books.

Of course, these books are also suitable for developers, testers, operations personnel, and other roles that are essential in the software delivery process, as they can broaden their knowledge in these areas.

2. The Lean Startup, The Essence of Scrum, Lean Product Development, Lean Development and Kanban Method

Regarding management practices and Lean, I recommend four books to you.

The Lean Startup, with its Minimum Viable Product (MVP) concept, has been regarded as a guideline by many companies. Its core idea is that ideas are only truly effective after being validated by the real market and users. Products need to continuously learn and iterate through validation and feedback processes, rather than trying to accomplish everything at once, exhausting all resources and losing room for maneuver.

The Essence of Scrum is suitable for agile teams using the Scrum framework to learn and practice and to avoid problems that may arise during Scrum implementation. Additionally, it is a must-read for students aspiring to become Scrum Masters.

Lean Product Development is a work by He Mian, published in 2017, based on Lean thinking and the Lean Kanban Method. In the field of Lean software development, this book and Li Zhihua’s Lean Kanban Method can be considered sufficient references.

These books are suitable for those who want to understand agile or practice the agile development method in their practical work. Furthermore, Lean thinking can be said to be the theoretical source of DevOps, with close relevance to cultural orientation and continuous improvement work.

3. The DevOps Handbook & Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

If you want to understand the complete view and core theoretical framework and practices of DevOps, The DevOps Handbook and Accelerate: The Science of Lean Software and DevOps are the best choices. The authors of these two books are thought leaders in the DevOps industry and are continuously advancing the DevOps system.

The DevOps Handbook, also known as the “Handbook,” focuses on introducing the three-step methodology of DevOps practice and includes numerous reference cases from DevOps implementation. Accelerate: The Science of Lean Software and DevOps is written by the author of the DevOps State of the Industry Report. In this book, he reveals the scientific methods behind the report and proposes the DevOps capability growth model to help you enhance overall software delivery capability.

4. The Phoenix Project, The Mythical Man-Month, The Goal

Finally, I would like to recommend three novels to you. These are also a few books that I have read and are very enjoyable.

Among them, The Phoenix Project follows the three-step methodology of DevOps work and is connected to The DevOps Handbook. The Mythical Man-Month is a classic book in the IT industry that has been a best-seller for over 40 years. The Goal is a classic work by Eliyahu M. Goldratt, the creator of the Theory of Constraints. The improvement five-step method proposed in this book forms the foundation of modern continuous improvement.

Conferences, Websites, and Blogs #

Of course, reports and books are just a small part of the DevOps resources, there is also a lot of information available from conferences, websites, and blogs. I have selected some high-quality resources to share with you.

  • DEOS: The DevOps Enterprise Summit is well-known for its case studies.
  • DevOpsDays: The renowned DevOpsDays community.
  • TheNewStack: A comprehensive website that produces high-quality ebooks.
  • DevOps.com: A comprehensive website.
  • DZone: A comprehensive website that produces high-quality ebooks.
  • Azure DevOps: A comprehensive website that produces high-quality ebooks.
  • Martin Fowler: Martin Fowler’s blog.
  • CloudBees Devops: The blog of the company behind Jenkins.

Among these resources, there are a few that you should pay special attention to.

For example, the DevOps Enterprise Summit (DOES), initiated by Gene Kim, is an excellent venue for obtaining practical case studies. DZone and TheNewStack often release free ebooks and reports, so it is worth subscribing to them. Martin Fowler’s blog is a collection of high-quality content, and it serves as a definitive source for many technical details. It is definitely worth savoring.

After talking about all this, I would like to spend a little more time discussing the process of learning with you. I want to share with you an image of the “Learning Pyramid” model proposed by American scholar Edgar Dale. This model is one of the most referenced models at present.

Image Source: https://www.businessdirect.bt.com/

In this model, learning methods are divided into two categories: active learning and passive learning. In fact, whether it is reading books, watching videos, or listening to podcasts, they are all passive ways of learning. Ultimately, the knowledge gained may only be half of the input information, and that is assuming one has good memory. Most of the time, the more you read, the more you forget. This is not a particularly effective way of learning.

In reality, for content like DevOps, which combines concepts, practices, technological culture, hard skills, and soft skills, active learning is indispensable. For example, case discussions, offline exchanges, and learning through practice.

So, I hope you can think and summarize more, combine practical problems at work, explore answers, and actively share and discuss with others. Only through active thinking can you digest and absorb knowledge, and ultimately, develop your own understanding of the DevOps system.

Summary and Discussion #

Alright, today I discussed with you the learning resources for DevOps, including status reports, books, conferences, websites, and blogs. However, for DevOps, these are just the tip of the iceberg.

I would like to talk to you about any hidden gems and channels that you have personally discovered and used in your process of learning and practicing DevOps. If you have any, I hope you can share them, so that we can build a repository of DevOps-related resources together and maintain it as an open-source project on GitHub. This will help more people understand and learn DevOps.

Feel free to share your thoughts and answers in the comments section. Let’s discuss and learn together to make progress. If you find this article helpful, please share it with your friends.