Four dimensions to instantiate DevOps principles (Part II) Source

Translated

Image Source: SystemsValley

In this article, we aim to outline the principles of DevOps in four dimensions: people, product, process, and tools. The reason for choosing these four dimensions lies in their significance in today's knowledge-based economy, as opposed to the industrial economy that dominated over a century ago. In the past, the scarcity of materials led to the prioritization of standardized "processes" over "product" and "people," who were expected to repeat work without thinking. However, in the knowledge economy, "people" are the most important dimension as they possess the creativity to respond to changing business needs. "Product" remains second, followed by "process," which can be tailored to "people" and "product" requirements. DevOps, with its emphasis on automation, requires good "tools," which can be customized according to the process.

The principles of DevOps, which we will describe below, are based on Agile, Lean, and DevOps practices. While they may not cover all DevOps practices, they represent the essential elements learned through years of DevOps practice and will be continuously refined in the future. Unlike other abstract frameworks, such as CALMS and The Three Ways, we will use concrete examples and the syntax of "above" and "Instead of" to compare two specific practices, such as "deployment pipeline," to represent corresponding principles. This approach, called "Instantiation," makes the description of DevOps principles more specific and accessible even to those unfamiliar with Agile, Lean, and DevOps.

1. People

Leadership should be actively involved in continuous improvement and prioritize tools and infrastructure.

In order for DevOps to thrive within an enterprise, a positive corporate culture must be established and maintained, which is shaped by the leadership of the company. As DevOps is a relatively new concept for most Chinese enterprises, experimentation is crucial for its continuous improvement. However, engineers may struggle to find time to learn new tools and methods due to project schedules. Therefore, leaders should lead by example, conduct their own experiments, and prioritize giving engineers sufficient time to experiment and improve to create a conducive environment for the effective use of automation tools and infrastructure within the enterprise.

1.1 Testing and improving processes rather than blaming individuals for failures

Toyota's slogan, "Harsh to the process, gentle to the people," emphasizes that employees will try their best to do a good job and that problems that occur in the workplace are often process-related. Therefore, it is essential to adjust the process rather than blame individuals when failures occur during experimentation, as DevOps is still a relatively new concept for most domestic enterprises. Failure to do so could discourage individuals from continuing to try DevOps.

1.2 Product thinking is more important than project thinking

Adopting a product-oriented organizational structure, in which a team is formed based on a product rather than a project, can help foster a product-focused mindset. This product team comprises various roles, including Dev, Ops, BA, Tester, PO, and Architect, who work together autonomously to deliver the software product throughout its entire lifecycle without relying on other roles outside the team. As long as the product remains in place, this product team is responsible for its full lifecycle and is not disbanded. This approach encourages collaboration among team members, as they share the same goals, unlike temporary project teams formed from various functional teams with inconsistent goals (e.g., Dev team, Tester team, and BA team).

2. Products

2.1 Prioritizing Quality and Safety over Late-stage Metrics and Inspections

To ensure value, products need to prioritize quality and safety. Many people assume that high quality equals high cost since maintaining high quality requires extensive product testing and disposal of inferior products, which is costly. However, Toyota disagrees and asserts that "high quality is free." This is due to Toyota's "harsh process" approach, where they continuously improve the process to guarantee high quality without large-scale inspections at later stages. Consequently, the cost is close to zero.

2.2 Prioritizing Customer Feedback over On-time Delivery

The product's value is determined by customer feedback, so customer feedback should take priority. Many teams prioritize delivery deadlines and overlook customer feedback. This leads to products being delivered on schedule but failing to meet customer expectations, resulting in rework or project failure.

2.3 Emphasizing Immutable Container-based Microservices over Single Block Applications

Products should be developed, tested, and deployed effectively to deliver value. For complex products, multiple microservices can be combined, with each microservice developed, tested, deployed, and launched independently. This approach facilitates parallel development of individual microservices, shortening the feedback loop for each microservice's development, which in turn accelerates the project schedule, allowing value to be delivered faster.

An immutable container is a software product packaged into a container, like Docker, with an unchangeable configuration by humans. Any changes require repackaging into a new immutable container via the deployment pipeline. This approach enables deployment and release automation, improves version control, and eliminates the risk of unauditable online manual configuration. Immutable container-based microservices are the recommended practice for this writing period and will continue to evolve in the future.

3. Process

3.1 Process improvement through Improvements Kata and Coaching Kata is more important than results-oriented management

According to a Buddhist saying, "Bodhisattvas fear the cause, but all beings fear the result." Traditional results-based management can lead team members to focus solely on achieving results rather than the process of how to attain them. This can cause team members to concentrate on making reports look good, rather than building the continuous improvement capabilities of the team to achieve the desired results.

To generate a culture of continuous improvement, management can adopt Improvement Kata and Coaching Kata, as outlined in the book "Toyota Kata." Improvement Kata involves using a feedback loop of "Determine the goal -> Examine the current situation -> Identify the difficulties -> Develop a plan -> Observe the effectiveness" to encourage continuous improvement. Coaching Kata, on the other hand, is a "one-to-one apprenticeship" method that enables all employees to master the continuous improvement method through their mentor.

3.2 Global optimization instead of local optimization

Companies that organize their teams by function often suffer from departmental fragmentation, with each function optimizing locally, leading to a lack of global interdepartmental optimization. This fragmentation can lead to inter-departmental debates that can last for months and severely affect product delivery. To improve global competitiveness, departments must focus on global optimization.

3.3 One-piece flow is more important than inventory

One-piece flow refers to the process where individual modules of a product move directly from one value-added processing step to another, with no waiting or queuing between the steps. Any waiting or queuing between processing steps creates inventory.

In software development, common inventories include queued requirements for development, queued code for testing, queued defects for fixing, and queued product features for release. Hidden inventories can also arise due to a set duration for user acceptance testing, resulting in features developed and tested at the beginning of a month being stored for almost a month until the end of the month. These inventories can cause significant project delays. Achieving one-piece flow eliminates inventory and enables the fastest flow of value between different steps, resulting in global optimization.

4. Tools

4.1 Automation is preferred over manual work

Tasks that follow a fixed process, such as manual regression testing and manual deployment, can be slow, uninteresting, and difficult to audit. By automating such tasks through coding and managing them with a version control system, organizations can save a significant amount of time and enable employees to enjoy working with development testing and deployment scripts.

4.2 Infrastructure and code take precedence over manual configuration

Traditional Ops deployment work can be inefficient, requiring constant switching between interfaces. Although automation scripts can improve efficiency, they often lack version control and automated testing. If infrastructure maintenance could be entirely done through code writing and version control, it would offer numerous benefits, such as enabling Ops staff to learn about production environment configuration without accessing it. Non-Ops personnel such as Devs could learn Ops configuration codes and modify them to enhance the DevOps capabilities of the entire team. Additionally, reading these codes via tools would make the maintenance of the base facilities more efficient.

4.3 Deploy using pipelined builds instead of daily builds

Code submission is how programmers add value to a software system. However, how can organizations effectively ensure code quality for each submission without affecting the existing system's value? A code build system is necessary to automatically verify code quality during compilation, testing, and packaging.

Some teams still perform nightly builds, which used to be a "best" practice but are no longer recommended. With many code submissions each day, it can be challenging to determine who caused a bug found in a nightly build. It is recommended that each code submission automatically triggers the deployment pipeline to check whether it passes automation unit, acceptance, and performance tests. This way, any issues can be quickly identified and resolved.

Conclusion

The principles of DevOps are derived from the practical experiences of Agile and Lean practitioners in their daily work. These principles can be categorized into four dimensions: people, product, process, and tools. The objective of these principles and practices is to realize the DevOps vision of providing online access to the necessary business changes at all times.

The above diagram provides a condensed representation of the DevOps principles that have been discussed in this paper.

Need more help? Check out the Zentao blog. They have more articles on project management, software management, building cross-functional teams, and so much more.

--

Author bio :

Wu Bin, a software development consultant at ThoughtWorks, is renowned for his expertise in software development technology practice. He's often referred to as the "Taoist Master" because of his frequent technical practice sessions. With over 20 years of experience in the industry, he's worked in various roles such as programmer, test engineer, project manager, and software development consultant. In April 2013, he founded bjdp.org, a Beijing-based programming practice community for full-stack developers.

Read more:

• Four dimensions to instantiate DevOps principles (Part I)