The cases for DevOps

To understand the impact of DevOps you need to think about how software was traditionally built and run. By Andrew Davis, Senior Director Product Marketing, Copado.

  • 4 years ago Posted in

Organisations continually hold in tension innovation and stability.  Every business needs to innovate and develop new functionality for their customers and employees. To do this, they build and customise applications. This is the role of the Development team (Dev).

Those same organisations also need existing systems to be stable, reliable, and secure. This is the role of the Operations team (Ops), which might consist of system, database and website admins. Their main job is to make sure servers are up and running, service level agreements are being met, the application is performing as expected and so on.

Working with a cloud platform like Salesforce makes it a lot simpler to build applications. Instead of needing an ‘Operations’ team to keep production systems running, the platform takes care of this aspect.

However, there’s a natural tension. Developers want and need to keep changing the system, while Operations wants and needs the system to remain as stable as possible so they can optimize performance and reduce risk. 

Compounding the issue, in large organisations, Dev and Ops teams historically work in silos. The end goal for both teams is customer satisfaction, but specific goals for ‘Devs’ include quickly delivering features and bug fixes. Whereas for ‘Ops’ the goal might be to maintain 99.99% server up-times. 

These goals can often be in conflict, leading to inefficiency and finger pointing when things go wrong.

 

Breaking Down Silos

DevOps was born to alleviate conflict between the Dev and Ops teams. It focuses on using tools and techniques that enable everyone to work together more smoothly. It’s about collaboration, working towards the shared goal of benefitting end users.

It is born out of a recognition that the whole team needs to work together to build trust while delivering innovation. Because delivering an application is only the beginning. Once it’s running in production, businesses need a way to ensure it’s working, and to gather feedback to make improvements.

Historically, development was thought of as an assembly line, beginning with development and ending in production. But DevOps teams prefer to use a circle or an infinity loop to indicate that this is an ongoing process.

In The DevOps Handbook Gene Kim and co-authors describe “three ways” of DevOps: Flow, Feedback, and Continuous Improvement. Flow refers to the “left-to-right” movement of changes from development to production. The goal of this flow is early and continuous delivery of value to end users. Developers can then monitor how the app is running in production, and get input from end users, leading to the “right-to-left” movement of Feedback back to development. 

However, just like learning, DevOps is not a journey you ever finish, thus the third way is Continuous Improvement, striving to always improve both our work and the way we work.

 

Focusing on the customer - DevOps in practice

 

The purpose of every task in business is to deliver value. That might be a person who pays for a service or someone in the same organisation.  Although that might sound obvious, it’s important to understand the value that a given team delivers, so that the business can focus on activities that bring value and avoid things that don’t. 

One great example of this is waiting time. Imagine that it takes one hour to build a great new feature for an application. Clearly, that’s an action that brings value. But imagine that the team only releases once per week, so that feature needs to wait for a week before it can be released. That waiting time does not bring any value to the customer. If there is a way to reduce that waiting time, it’s beneficial for the customer.

The modern world has gotten a lot faster compared to previous generations. Many of the changes we have seen are designed to bring benefit to customers more quickly and more efficiently. For example, manufacturing has been transformed over the last century to reduce the amount of non-value adding steps in a process, and to optimize for quick delivery.

DevOps aims to bring similar benefits to the process of developing IT applications. DevOps focuses on closing the gap between creative people like developers and those who can benefit from the end result.

 

The Research on DevOps

There is increasing research to back up these claims. The Accelerate State of DevOps Report is the largest and longest-running research of its kind, and provides independent scientific evidence of the effectiveness of the practices that fall under the DevOps heading. 

The State of DevOps Report points to four key metrics that can be used to measure the effectiveness of a development process:

  1. Lead time (the time to deliver completed work to end users)
  2. Deployment Frequency (how often a business updates production)
  3. Change Fail Percentage (how often those updates negatively impact end users)
  4. Time to Restore (how quickly a business can recover from those negative impacts)

The first two measure the speed of innovation, and the last two measure the degree of reliability provided. Measuring both innovation and reliability allows a business to assess these dual goals of DevOps.

The research discerned that some organisations performed far better than others on all four of these metrics. Based on these metrics, they categorized respondents into Elite, High, Medium, and Low performers. They found that Elite performers had 106x faster lead time than Low performers, deployed 208x more frequently, had 7x lower change failure rate, and 2,605x faster time to restore!

Importantly, Elite and High performers were both faster and more stable, and low performers suffered from both low rates of innovation and high rates of failures. That indicates that an ability to innovate quickly and the ability to do so safely are related, just as better brakes enable a racecar to go faster.

Performance on these four key metrics is called “software delivery performance”. This performance doesn’t just impact the development team, it has an impact on the whole business. Organisations with elite software delivery performance are twice as likely to meet their overall goals, both commercial and non-commercial.

Copado conducted a similar survey called the State of Salesforce DevOps Report. For organisations that had more than 25 admins or developers contributing to Salesforce customizations, the same trend appeared: teams that were able to release innovation more quickly and reliably to Salesforce performed better as a company! 

Why doDevOps practices have such a big impact? It is because a development team may be only a small part of the overall organisation, but they have an outsized impact. By building the systems a company uses,  they enable the whole organisation to succeed. 

DevOps is - like all new terminology - a little shrouded in mystery, but by bringing these teams together and making collaboration the cornerstone of ALL activity, it is set to delvier huge benefits to enterprises.

 

Bernd Greifeneder, founder and CTO of Dynatrace., looks ahead to 2022, predicting some key trends...
By Nick Heudecker, Senior Director at Cribl.
Every increment in understanding and collaboration around the stack, delivery, governance and...
In December, IDC predicted that global digital transformation investments will total $6.8 trillion...
Only with a flexible integration layer built on the principles of API-led connectivity and reuse...
The need for value stream visibility is not a nice-to-have, it is a business necessity whether you...
What precisely are the requirements of a DevOps practitioner, as opposed to an SRE, legacy...
For those in the ever-changing DevOps world, here are some best practices to reconnect with that...