DORA, the DevOps Research and Assessment team, have recently released their 2018 State of DevOps report. An intensive collection and analysis of data on the usage and application of DevOps across organisations, including containers, orchestration, and cloud native practices. In this series of blog posts we will take a look the some interesting findings within the report and how they relate to what we at Container Solutions have seen in the wild.
Backing up Intuition with Data
At CS we speak a lot about the benefits of DevOps, and Cloud Native. We have seen the benefits ourselves first hand, again and again. Anecdotal evidence however is not always sufficient to convince those more skeptical of adopting large changes. And any serious endeavour to migrate to cloud native is a significant project which will, when done right, have wide reaching consequences across your organisation. The skepticism is warranted.
This is why large, long running reports such as the “2018 State of DevOps” recently released by DORA are extremely useful, both to industry insiders, such as ourselves, as well as organisations who are looking at adopting or improving their DevOps practices. This report takes a look at the data collected from over 30 000 technical professionals and highlights the major insights.
Source: DORA Accelerate State of DevOps 2018
The Findings
Unsurprisingly, the numbers in this case confirm what we have seen ourselves in the field. The benefits of embracing DevOps, and cloud native practices can (when done properly) have significant benefits to your team’s productivity as well as the wider business goals of your organization. The DORA report takes the data and provides a measurable look at the benefits of properly adopting these practices. Companies are split out into groups ranging from Low Performers up to Elite Performers, based on their software delivery performance.
Comparing those two extreme groups the report state that the Elite Performers deploy code 46 times more frequent, have a lead time which is 2555 times faster (commit to deploy), are seven times less likely to have changes cause failures, and can recover from incidents 2604 times quicker.
These are staggering numbers. While, this is not saying that moving to DevOps will improve your incident recovery time by 2604 times, it does show the wide discrepancy that exists between software teams. Also, it should be enough of a motivation for any organisation to look at how they can improve their own numbers in these fields. The State of DevOps report allows you to compare your organisation or your team against the industry to see in which group you fall. And subsequently to look at how you can improve and move towards the Elite Performers.
Key Practices
The report, which is well worth a read in its entirety, also looks at some of the reasons why certain teams outperform others. It outlines several “key technical practices” which distinguish the elite teams. You can find the complete list in the report, but I want to call out a few specific ones here:
- Deployment Automation
- Continuous Integration
- Monitoring and Observability
- “Shifting Left” on Security
Deployment Automation
One of the most crucial points which must be at the heart of any DevOps or cloud native transformation. There are two main reasons why this is the case. The first, is that as you move towards a distributed, microservice architecture, the number of pieces you are dealing with grows exponentially. While you may have been able to get away with doing things manually with your previous architecture, any manual steps required, especially in your deployment pipeline, will quickly render your brilliant new architecture all but useless. Second, automation, must become part of your culture. As engineers, you should constantly be looking to automate away any task that is done more than twice. This culture of constantly automating and improving your processes goes hand in hand with cloud native.
Continuous Integration
Often the most important pre-requirement before starting a cloud native migration. This is one of the first things we investigate when evaluating the cloud native maturity of an organization. While continuous integration has started to mean different things to different people, it is fact a well defined process. Your CI pipeline will be one of the most important pieces in your cloud native architecture.
Monitoring and Observability
Historically this has received less attention from software teams, and in the past has tended to be an add-on rather than a critical part of the initial design. More recently however, this trend has been changing. The exponential growth in the number of pieces of your applications, and as a result the complexity of those systems, requires comprehensive monitoring solutions and intelligent observability. For a deeper dive on Monitoring and Observability check out the chapter Monitoring in the Cloud Native Era (written by my colleagues) in The New Stack’s E-Book CI/CD with Kubernetes.
Security
Another aspect which tends to get overlooked by most of the organisation. Typically a single team is responsible for ensuring security across all applications. In the cloud native world security must become a responsibility of everyone involved, from design to implementation. The integration and automation of security into our regular pipeline, sometimes called DevSecOps, allows us to continually mitigate risks and resolve potential threats early on.
These four key technical practices are some of the most common missing pieces we see in working with new organisations looking to go cloud native. Our Cloud Native Maturity Matrix is a tool we created to help analyze the different parts of an organisation and find out which pieces are missing and where are the next steps.
What's Next?
In a follow up blog post we’ll take a look some ways to get started with a cloud native migration. We’ll take a more in depth look the maturity matrix as well as a paradigm known as the Theory of Constraints to understand where to focus your efforts and where to begin when embarking on a cloud native transformation. Then, in a future post, we’ll take a look at how to approach adopting some of these changes to move towards that Elite Performers group. We’ll also list some of the common mistakes, which we have ourselves seen as companies go through these cloud native transformations.
Previous article
