In
my previous post, we talked about the CALMS framework as an introduction to DevOps, and how it's more than just “DevOps tooling.” Yes, some of it is about automation and what automation tools bring to the table, but it's what teams do
with automation to quickly create more great releases with fewer and shorter incidents. Choosing a one-size-fits-all solution won't work with a true DevOps approach. For this, I'll briefly go into CALMS (but you can read more in my previous post) and the four key metrics to measure a team's performance. From there, we'll look at choosing the right tooling.
CALMS
Let's quickly reiterate CALMS:
- Culture
- Automation
- Lean
- Measurements
- Sharing
These five core values are an integral part of high-performing teams. Successful teams tend to focus on these areas to improve their performance. What makes teams successful in the context of DevOps tooling, you ask? I'll explain.
Key Performance Metrics for a Successful DevOps Approach
Measuring a team's performance can be hard. You want to measure the metrics they can directly influence, but avoid being overly vague in measuring success. For instance, measuring the customer NPS involves much more than a single team's efforts, so that one team's efforts can get lost in translation. A good methodology of measuring DevOps performance comes from
DevOps Research and Assessment, a company that publishes a yearly report on the state of DevOps, “Accelerate: State of DevOps 2018: Strategies for a New Economy.” They recommend using these four performance metrics:
- Deployment frequency: how often does the team deploy code?
- Lead time for changes: how long does it take to go from code commit to code successfully running in production?
- Time to restore service: how long does it take to restore service after an incident (like an unplanned outage or security incident)?
- Change failure rate: what percentage of changes results in an outage?
These metrics measure the output, like changes to software or infrastructure, as well as the quality of the output. It's vague enough to be broadly applicable, but concrete enough to be of value for many IT teams. Also, these metrics clearly embrace the core values from the CALMS framework. Without good post-mortems (or sprint reviews), how do you bring down the change failure rate or time to restore service? Without automation, how do you increase deployment frequency?
Choosing the right support infrastructure for your automation efforts is key to increasing performance, though, and a one-size-fits-all solution will almost certainly be counter-productive.
Why The Right Tool Is Vital
Each team is unique. Team members each have their own skills. The product or service they work on is built around a specific technology stack. The maturity of the team and the tech is different for everyone. The circumstances in which they operate their product or service and their dependencies are incomparable.
So what part of that mix makes a one-size-fits-all solution fit? You guessed it: none.
Add in the fact that successful teams tend to be nimble and quick to react to changing circumstances, and you'll likely conclude that most “big” enterprise solutions are incompatible with the DevOps approach. Every problem needs a specific solution.
I'm not saying you need to create a complex and unmanageable toolchain, which would be the other extreme. I’m saying there's a tendency for companies to buy in to big enterprise solutions because it looks good on paper, it’s an easier sell (as opposed to buying dozens of smaller tools), and nobody ever got fired for buying $insert-big-vendor-name-here.
And I'm here to tell you that you need to resist that tendency. Build out your toolchain the way you and your team sees fit. Make sure it does exactly what you need it to do, and make sure it doesn't do anything you don't need. Simplify the toolchain.
Use free and open-source components that are easier to swap out, so you can change when needed without creating technical debt or being limited by the big solution that won't let you use the software as you want it (a major upside of “libre” software, which many open-source is: you’re free to use it in a way that you intend, not in just the way the original creator intended).
Next Up
So there you have it. Build your automation toolchain, infrastructure, software service, or product using the tools you need, and nothing more. Make components easy to swap out when circumstances change. Don't buy into the temptation that any vendor can be your one-size-fits-all solution. Put in the work to create your own chain of tools that work for you.
In the next post in this series, I'll dive into an overview and categorization of a DevOps toolchain, so you'll know what to look out for, what tools solve what problems, and more. We'll use the Periodic Table of DevOps tools, look at value streams to identify which tools you need, and look at how to choose for different technology stacks, ecosystems, and popularity to solve specific problems in the value stream.
