How can DevOps improve software delivery?

John Allspaw, SVP Operations at Flicker, and Paul Hammond, Director of Engineering at Flicker, presented a unique perspective for demonstrating increased cooperation between Development and Operations at the 2009 O’Reilly Velocity conference. This new collaboration enabled Flickr to deliver “10+ Deploys per Day.” Later in 2009, this groundbreaking concept was formalized into the term DevOps by Patrick Debois. Eventually, he organized a DevOps conference to join forces with others struggling to make infrastructure more agile.

What are the best practices of DevOps?

DevOps as a concept is pliable and doesn’t have a strict definition, but companies like Microsoft and Amazon have attempted to formalize and focus it around several core practices. These practices define the methods that businesses should use to improve the efficiency of their operations. However, by their very nature, best practices are frequently context-sensitive and dependent on individual application requirements.

IBM created a DevOps Maturity Model that highlighted a framework of best practices (Figure 1). Other developers have proposed a simpler view of potential best practices (Figure 2)

Our team envisions the best practices of DevOps to encompass the following components.

Agile software development

Introduced in 2001 through the Agile Manifesto, agile development is a collection of software development approaches that promote:

• Adaptability and collaboration between teams.
• Frequent software updates.
• Feedback loops and continuous improvement.

DevOps can be viewed as an extension of agile development. While DevOps heavily uses the principles of agile, it extends them beyond software development and applies them to IT operations, QA, and security. Additionally, DevOps enhances agile development with a number of other methods, as described below.

Continuous integration (CI)

Continuous integration, or CI, is the practice of frequently merging code changes to a central repository. CI promotes the integration of code several times per day. Frequent commits minimize the amount of work that needs to be done to combine code from different developers. As a result, smaller pieces of code are easier to adapt and make work together.

Continuous delivery (CD)

Continuous delivery, or CD, is built on top of continuous integration and intends to accelerate the testing and deployment of code to production. Continuous delivery is related to continuous deployment – a similar approach that is more automated. Continuous deployment is typically viewed as an extension of continuous delivery. With a combination of continuous delivery and deployment, businesses can deliver minor improvements to their products quicker and more efficiently.

Microservices

Microservices is an approach that breaks applications down into small components or services. Typically, each service has one specific purpose.

Microservices can be freely combined to build complex functionality. This allows businesses to make applications of varying complexity and quickly scale them as required. Microservices can also be reused across different applications, allowing developers to avoid reinventing the wheel with every new product.

Infrastructure as code

Infrastructure as code (IaC) allows teams to manage and provision computer systems through code rather than through configuration files. With IaC, businesses can standardize and modularize their infrastructures, accelerating the deployment and the scaling of computer hardware. Additionally, IaC makes the process of deploying and modifying infrastructure repeatable, which reduces the risk of bugs and errors as teams grow.

Continuous monitoring

Continuous monitoring incorporates collecting and analyzing logs and performance metrics from a deployed application. Businesses can collect data through monitoring, including error logs, alerts, metadata, and telemetry.

Teams get fine-grained insight into how application updates impact the end-user experience with continuous monitoring. Not only that, but continuous monitoring allows teams to detect issues quicker and understand their root causes better.

What are the benefits of DevOps?

“One of the core benefits of having an integrated delivery pipeline is end-to-end traceability, across artifacts, across the delivery pipeline. This end-to-end traceability enables the existence of a single source of truth for all practitioners and stakeholders, across functional areas. The most significant benefit of end-to-end traceability is that it gives the practitioners and stakeholders the ability to have visibility into the relationships between the artifacts and access to the right version of the right artifact that they need for the task they are working on.”

— Sharma (2017, p. 119)

A range of benefits become self-evident once DevOps is applied in the workplace (Sharma, 2017, p. 99-100):

• Reducing cycle time,
• Reducing delivery risk,
• Reducing integration risk,
• Reducing architectural complexity,
• Improving testing and quality,
• Reducing waste,
• Improving processes,
• Improving documentation, and
• Achieving continuous improvement.

Let’s examine DevOps benefits to teams and businesses from a different perspective (Mathew and Varia, 2014):

1. Speed.
2. Reliability.
3. Scalability.
4. Security.

We will take a deeper dive into each of these benefits.

Speed

“One of the biggest benefits, if not the biggest benefit, of DevOps is the promise of speed; DevOps enables more and faster code deployments, which means a decreased time to market and more opportunities to capture revenue from customers”

– C. Null (2015)

DevOps allows businesses to:

• Bring their software products to market in a shorter time.
• Adapt to changes in their industries faster.
• More quickly respond to feedback from customers.
• Release updates and fixes more frequently.

Ultimately, with the DevOps model, businesses can deliver value quicker, better react to changing market conditions, and build and maintain their competitiveness.

Reliability

DevOps can substantially improve the reliability of applications and IT infrastructures. First of all, the small and standardized application changes allow teams to catch and fix issues early.

But even when accidents do happen, teams that adhere to DevOps practices can minimize downtime and recover service fast. These benefits can continue to occur thanks to automation and tighter communication between different teams.

Scalability

DevOps is highly scalable thanks to its emphasis on standardization and automation. With tools like Docker, teams can break down their operations and tools into repeatable building blocks that can be combined and deployed at will. As for automation, platforms like Kubernetes can be used to facilitate and streamline the use of prepackaged solutions.

Security

DevOps can help teams produce secure code. The tight communication between developers and security teams enables the integration of security testing into software development. This minimizes back and forth motions between teams and allows code to be built with security in mind from the beginning.

How to start adopting DevOps?

DevOps, to some extent, relies on software tools such as Docker, Kubernetes, GitHub, or Jenkins. However, the adoption of DevOps isn’t just a matter of using the right tools – it also requires shifts in corporate culture and employee mindset.

“In theory there is no difference between theory and practice. In practice there is.”

— Yogi Berra

For most businesses, the biggest obstacle to DevOps adoption is siloed teams. Isolated, siloed teams are not used to performing functions outside of their duties and may not know how to communicate with each other efficiently. With that, to start the adoption of DevOps, businesses need to shatter old mindsets and break their employees out of the confines of siloed teams.

However, breaking old habits can be extremely challenging, especially in large organizations. Because of that, one possible approach to DevOps adoption is the deployment of DevOps at a small scale. Businesses can try DevOps to develop separate features or restrict DevOps to an individual stage like deployment.

Businesses should first define KPIs (key performance indicators) for the test run to start adoption. The KPIs can include deployment speed, deployment frequency, or bug quantity. Throughout the trial, teams can learn to communicate, respond to feedback, analyze their KPIs, and use DevOps tools. KPIs need to be (Sharma, 2017, p. 62):

1. identified before the transformation starts (measures of success),
2. taken as a baseline to know the current state, and
3. set as goals for what the productivity KPIs should be post-transformation (end state).

The following tables present a range of examples of DevOps KPIs (Sharma, 2017, p. 107-113):

Based on the trial results, businesses can start scaling DevOps operations up, expanding them to more teams and workflows. At the same time, businesses can continue monitoring KPIs to make adjustments to their DevOps pipelines on the fly. Step-by-step, they can then make gradual improvements and optimizations to their DevOps strategies, eventually leading to full adoption.

How can software delivery simulation help with DevOps adoption?

The primary purpose of software delivery simulation is to help businesses test changes to their delivery workflows before implementing them. With software delivery, businesses can try different software delivery parameters in a safe environment without making changes in the real world.

Software delivery simulation tools allow teams to define virtual delivery pipelines. These pipelines can incorporate different stages of software delivery, such as code development, merging, quality assurance, or deployment. Teams can model their software delivery pipelines either in their entirety or in parts.

How can this help businesses? With software delivery simulation, businesses can assess how long a workflow would take to fully execute. Not only that, but simulation also allows businesses to identify inefficient stages in their software delivery processes. Based on these insights, businesses can tweak their virtual pipelines and observe how the changes affect performance.

Within the context of DevOps, businesses can use software delivery simulation for two purposes:

1. Building prototype software delivery pipelines that follow DevOps practices. Prototype pipelines can then be compared to existing workflows, helping businesses quantify DevOps’s benefits.
2. Making improvements to existing delivery pipelines that already follow the DevOps model. In this sense, simulation can help businesses make improvements to existing workflows.

The beauty of simulation is in its simplicity and efficiency. With simulation, businesses can test many different delivery configurations in a virtual, isolated environment without restructuring or disturbing existing processes.

Next steps

Before undertaking any major changes, it is important to understand what software delivery is and why it is valuable. The practices of DevOps are also worth attention because they underly modern software delivery. Once the basics are covered, businesses can plan their transition to DevOps. At the same time, businesses can start considering using software delivery simulation to accelerate and facilitate the adoption of DevOps greatly.

If the team needs to exercise its wings even more, then why not have fun and embark upon serious games and online simulations that will help familiarize your team with DevOps:

1. Build-Run-Improve-Repeat: DevOps Simulation,
2. DevOps Culture Simulation (with Lego, Chocolate and Scrum Game),
3. DevOps Expansion Pack for Agile Self-assessment Game,
4. DevOps Simulations – The Phoenix Project,
5. Find the Bug! – Project,
6. ToolStackers: A Boardgame for SE Education, and
7. YATA - A DevOps Game.