There’s no easy way to model DevOps ROI

Think you can show DevOps ROI? Think again

“What is the ROI for DevOps?” is a question that has been tossed my way frequently of late. There are numerous reasons why this is at the same time an absurd but also important question.

Modeling DevOps ROI is absurd because predicting the gains and costs of a process, let alone one as new as DevOps, is difficult and dependent on all sorts of unique variables per organization.

However, thinking through DevOps ROI is an important step for adoption because the promises of DevOps are so grandiose and the changes needed sound large and almost impossible to achieve for “normal” people.

That is, DevOps is an unmeasurable process with respect to ROI (it has value, to be sure, but is nearly impossible to measure independently and precisely) and, yet, because “doing DevOps” seems to be such a big change, organizations need assurances that transformation will be “worth it.”

So, if you’re asked to help show the ROI for DevOps, what can you do? Let’s cover three ways to approach the problem. I don’t think any of them are a real answer, but they get closer to satisfying some possible motivations for asking for ROI in the first place.

What is ROI?

First, what is ROI? I misuse economic and accounting terms all the time, but I think of “ROI” as showing the profit you achieve after a given period of time, for our purposes, by doing something new and different with IT: you might buy some new software (running on a cloud platform like Pivotal Cloud Foundry instead of just IaaS), do your software development and delivery differently (like, “doing DevOps”), and so forth.

With ROI, you’re not only interested in the question “does it work,” you’re interested in the question “did this make me money?” Oftentimes, you’re also interested in comparing the costs of competing approaches, or just inflicting vendors with the thrill of “bake offs” and ROI spreadsheet fights.

To figure that basic ROI, you use a brutally simple formula:

(Gain — Cost)/Cost = ROI

You can convert the end result to a percentage if you’re not into the whole decimal thing.

As a simple example, let’s say you sell an app that allows people to track how many apples they eat each day, so they can keep those ravenous doctors out of the way. After it’s shipped for a month, you’ve made $20,000 in sales for the app. To get to that point, it costs them $5,000 in paying for developer time and $5,000 in infrastructure charges (the back-end that analyzes the data, mashes it up with Facebook and Twitter profiles, and then sells that data to the Apple Sellers Association of Tomorrow takes some horse-power and storage!).

So, the ROI for the apple muncher app is:

($20,000 — $10,000)/$10,000 = 100%

A pretty good return on your investment! It’s certainly better than the rate I get on any of my personal investments.

So, what would be the ROI of introducing DevOps to that process? More importantly, how could you predict it? There are many ways to answer the ROI question, including the favorite “that’s a bad question, you shouldn’t want that” which can take on all sorts of subtle and helpful forms. Let’s look at three possible approaches.

1. Bottoms-up ROI: We know everything and have put it in this spreadsheet

If you have clear inputs and outputs — your gains and costs — then things can be realistically simple. This is the favorite approach of ROI spreadsheets: they’ll cost out software license costs, hardware/IaaS costs, and people costs (employees and consultants).

Once you’ve figured out costs, you need to estimate what your gains will be: either based on historic run rates, or, more likely, on a mixture of a prediction and hope for how much you’ll make in the future. Tracking the demand for software can be hard and this estimate is one of the most dangerous parts of this simple method. If all you want to do is track the ROI for saving money, perhaps things are a little easier. And while this implies that you’re not looking to DevOps to support a revenue growth strategy, perhaps that’s good input: if you’re not looking to grow your business, maybe it’s not right for you and will have negative ROI.

You then have to pick a period of time to snap-shot and you just run the math.

Of course, few, if any, of the things you’re costing out here are “DevOps.” You might spend money on a commercial continuous integration tool, on a cloud platform or a DevOps consultant. You’ll certainly spend money on people…but you didn’t really spend money on “doing DevOps.”

You might be tempted to simply ascribe gains to DevOps. “For this release, we were doing DevOps, and we made $30,000 with apple muncher! DevOps brought us $10,000 in new revenue.” But that doesn’t feel right.

Still, if you have a good handle on the costs during some period of time where you were doing DevOps and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it’ll be somewhat dicey since it’s so hard to attribute costs and gains directly to DevOps but, hey, it’s better than either telling people they’re asking the wrong question or its mute cousin: nothing.

2. Were the efforts to change worth it? That is, DevOps is all cost

As you might be teasing out, one of the problems with ROI is that it doesn’t really take time into account. You need to draw clear lines around the time period in which you’re including the factors that create your gains and costs. (If you’re interested in an approach that does take time into account, check out Rex Morrow’s suggestion to use IRR instead of ROI.)

Using this lack of time problem as a generative constraint, you could instead study the ROI of changing to DevOps. What did switching over to DevOps cost us? What did it cost us compared to maintaining our current process state?

Here, you’re taking whatever your regular ROI calculation is and just adding the one-time cost of time and money it took to change to DevOps. Figuring out what your gain is will be problematic. Again, what you’ll be gaining are new capabilities (to deliver software faster and increase your uptime in production); how those contribute to gains is still left as a mysterious exercise to the reader.

Still, if you want to run the numbers on something like “they tell me it will take three months and $50,000 in training and consultants to ‘do the DevOps’” this might satisfy your ROI craving. Again, you’ll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.

3. Pain avoidance and remediation

In the “DevOps is all cost” ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime (that is, “it works”). How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.

It’s fun to model-out placing value on the first part, “knowing,” but most people asking for ROI will likely look at that as a “soft” metric and, therefore, not really useful to their “hard”-centric minds. Including money saved (or generated?) by avoiding downtime could be interesting in a point in time (if a trading system goes down, money is lost when no one can trade), but how do you account for it ongoing?

The issue with including DevOps in this “easy” type of ROI calculation is figuring out how much gain and cost to attribute to DevOps.

As with uptime, sometimes it can be easy: before we did DevOps, the system was down two hours a day, now it’s only down five –10 minutes a day, if at all. If there’s a pain you’re seeking to remove, then perhaps this model will work.

Your pain might also be “it takes us too long to deliver software,” which is a common problem for DevOps adopters. If you know how to measure the gain of time to market, for example, then you can do one of these bottoms-up ROI cases: “We were able to deliver a third release of apple muncher in two weeks instead of the six it had been taking. This means we could start charging for the new in-app purchases sooner, gaining us $5,000 more over that two week period.”

If you like this kind of figuring, check out Zend’s suggestion for how to do continuous delivery ROI for some inspiration. Like all “good” ROI calculations, it requires changing ROI around slightly to fit what’s measurable…and some good estimating.

So, can you send me a spreadsheet with all this in it?

I’ve deftly avoided actually giving you anything actionable here. Calculating ROI is a very numbers-, spreadsheet-friendly exercise and any answer should really include at least a starter spreadsheet to get you calculating things. However, as the above hopefully shows, it is indeed the case that asking for “DevOps ROI” is the wrong question. The “ROI” is getting the process and tools in place to create a better product. Obviously, as you rack up the costs associated with DevOps (both in money and time spent), you can start to model the overall ROI of the project versus the revenue and profit you generate, but there’s little DevOps specific about that.

Beyond such obvious answers, when I see people asking for “DevOps ROI,” what we can offer them is over-thinking like the above and examples of it working at organizations. Examples like Allstate and Humana are good mainstream cases, and you can listen in to more on the excellent Goat Farm podcast.

Additionally, I would suggest focusing on looking at DevOps as a continual improvement initiative rather than trying to predict ROI. Much of the problem with figuring out ROI is in having to predict costs and gains. Instead I would try to focus on tracking and trying to improve how you’re doing things in short intervals. In my experience, most organizations devalue the idea of continuously learning and trying to improve their process. Focusing on that might be a better use of time than summoning up a solid case for DevOps ROI.

I’d love to see examples of how you did an DevOps ROI case…or avoided it all together. If we can accumulate enough after-the-fact studies, then at least we could make a “rule of thumb” collection. Leave a comment below!

(I originally wrote this July 2015 for FierceDevOps, a site which has made it either impossible or impossibly tedious to find these articles. Hence, it’s now here.)

Coté Memo #073: If you like tater-tots, go to Minneapolis

I’m in transit between Minneapolis and San Francisco right now. The MSP airport is delightful, with a long mall at the base and concourses reaching out, it seems civilized.


  • I had lunch with one of you today who said, “looks like you started up the newsletter,” to which I replied, “well, if I can send one more out and then not do it the third time, then yes.” So, here’s number two. Almost to fail-o-victory!

Tech & Work World

Coté Content

Quick Hits

Fun & IRL

“Nothing in particular”++

Suggested sound-track for reading this chart.

Trends in religious affiliationn

(Via @bruces)

That looks like relaxing chaos

I like the Power Ranger show too much. I don’t like the content too much, but the relaxation of what it looks like to be the show runner. The show has a predictability and stability to it, and an audience of adoring kids. And it looks like, if you get the whole Power Rangers idea and mythos, it’s hard to screw-up.



Coté Memo #072: Since last time…

It’s been forever since a memo! Here’s this week’s. I’ve tried to craft a work-flow that will allow me to collect links I want to share, in addition to shameless self-promotion and the occasional commentary in here…and actually send these out weekly. We’ll see what happens.


DevOpsDays Amsterdam - Thursday June 25th

I’ve been traveling a lot recently and have more coming up. The main thing is going to lots of DevOpsDays. Sometimes I’m lucky enough to speak at them, but the main part I like is talking with old friends and meeting people who are trying to sort out what exactly DevOps is and if/how it applies to them.

I’ll be at DevOpsDays in Minneapolis next week, and I may be at the Pittsburg and Chicago one.

If you’ve missed them, you can see recordings of my talks from Austin and Amsterdam (you have to go 40:30 in to find mine).

Tech & Work World

All about me…

Quick Hits



Enterprise DevOps interview with iThome Weekly

A little while back I did an email interview with Ray Wang from iThome Weekly, in Taiwan. It’s a little piece about DevOps getting more and more into the enterprise. To read the Google, robot translation, it looks like I did some things “single-handedly,” where in fact I was one of many hands.

As always, here’s the original email exchange we had:

Q. You mention about software-defined business in your article, can you tell more details about what is software-defined business? Why CEO have to think about the software-defined business? Why DevOps is so important for software defined business?

“Software defined businesses” are companies that are using custom written software to dramatically change and enhance how they run their business. Uber is a good example. Instead of just being a taxi or car service, they use software they wrote to change how their business runs: calling and paying for a taxi on your sell phone is much different than hailing a cab and paying in cash. Insurance and banking companies that are moving more and more of their daily business and interaction with customers to run over mobile apps and other custom written applications are another good example; we see this happening at Pivotal customers lie Allstate, Humana, and banks that use Pivotal Cloud Foundry.

Q: What’s your definition of DevOps? Does DevOps equal to Continuous Delivery?
Which definition of DevOps you don’t like most and why?

In general, I think of DevOps as the process and “culture” you wrap around continuous delivery to get the full effect of CD. I tend to speak about them interchangeably at this point; I suppose you don’t need DevOps to get the full benefits of continuous delivery, but they seem to go together well (you could always have just a jelly or just a peanut butter sandwich, but they seem to show up together a lot). CD is always looking to automate as much as possible, delivery to production frequently, and use the feedback loop this rapid cycle gives you (you an observe what your users does each week or day instead of each six months) which are many of the things DevOps seeks to enable as well.

It’s easy to get caught up in DevOps conversations that spend all of them time talking about “culture” and the need to change. I’m interested in that, but I always want to hear about actual, tactical things companies can do to get the benefits of DevOps. We all know how businesses use IT needs to change to be better, and that it’s hard to do so. I want to make sure the overall community is giving advice that’s helpful and, dare I say it, “actionable.”

Q: Should companies have to implement agile development before implement DevOps? Why?

It certainly helps to know what agile development is as a school of thought and to have done some form of agile to trust that way of thinking. If you’ve never done agile before, it just becomes part of trying to do DevOps. It’s certainly hard to think of being successful at DevOps without also doing agile software development.

Q: If CIO want to tell his CEO boss about what’s the value for non-technology companies , what’s your suggestion?

Time to market is the main, measurable, benefit. What that means, to me, is that software is being given to customers more frequently. New features and fixes come out weekly instead of once every 6 to 12 months. The business (the CEO) has to figure out what to do with time to market. If you can put a new features in production each week, how will that help the business? In the consumer space (where much of this mentality comes from) you can add more and more features to out-compete competitors. In the business space, the actual business has to change and evolve at a fast pace to fully take advantage of time to market. All that said, I don’t think any CEO is satisfied with the pace of change in IT. They’d all like it to move not just “faster,” but to get more meaningful features in production more often. Humana provides an interesting example: because they had been honing their software delivery process they were able to launch an Apple Watch app in just five weeks. That timeline is pretty amazing for most enterprise IT projects, let along being in the App Store on the first day of the Apple Watch’s release.

Q: Gartner say 2016 will be the year of DevOps. Do you agree with that? why or why not?

Sure, but I think you’ll see the next 3 or so years be the year of DevOps. I don’t think there’s any one year in particular that will stand out. I don’t think there was “a year of Agile Software Development” in the 2000s, it just took over slowly. What important is for companies to understand what DevOps can help give them – faster time to market for their software-driven products and services – and figure out what they’d do with that new ability. “Doing DevOps” is not easy, so you really need to value the end result or you’ll likely loose interest in the transformation process and let it unhelpfully fizzle out.

And, check out the recording of the DevOpsDays Austin talk referenced in the article if you’re interested.

What does IT need to start doing to become a software defined business?

I was asked to talk to do an internal, “brown-bag” style talk at a company this week. I chose to do a slightly more technical-oriented version of the talk I tend to give, commentary and pointers on moving your orginization over to relying on more and more custom written software to run your business. Here, I give a brief business context and then throw out three areas to start focusing on if you’re interested in cloud, DevOps, and all this nonsense. The recommendations are to look into contious delivery and DevOps, figure out cloud-native applications (and microservices), and then plan out your cloud platform strategy.

As ever, I’m trying to make actionable a few things that are often fuzzy. I don’t acomplish that too well – a seperate hour long talk on each topic would be better – but I at least hope to explaing the thing, say why it’s useful, and give some pointers for further study.

I put the slides up previously, but because people often ask me for the talk track, I thought I’d record a rehersal run and post it here. So, check out the video if you’re into this kind of thing.

DevOps Success Metrics, Nationwide

From an IBM article:

Since adopting [DevOps], Nationwide has achieved a 90 percent on-time software delivery rate (up from 60 percent previously) and a 70 percent increase in users’ system availability. But what’s truly impressive is that, in concert with the increased pace of software delivery, Nationwide reduced critical defects 80 percent and high-level defects by 86 percent, which means the company is delivering higher-quality software faster. Nationwide says it can now “invest more into playing offense” to help the company drive innovation and build new offerings.

See the full-court case study as well.

The Coming Donkey Apocalypse, DevOpsDays Austin recording

My talk from DevOpsDays Austin is up. Check it out if you’ve been curious about the talk track to the mute slides.

As a reminder, there’s a prose version of the talk available as well in one of my FierceDevOps columns, and here’s the slides.

Check out my love affair with “uh” in the begining, I think it clears up a bit at the end.

Deepening the hole metaphor

“Remember that if you want to sell technology, don’t talk about technology but rather about what it achieves and delivers,” he explained. “As an analogy, when selling power drills, focus on the outcome – the scenic picture you will be able to hang on your wall that reminds you of your favorite place – not the length of the drill bits, not the hole it makes, not the picture hanger – but the feeling (outcome) you will ultimately enjoy.”

You can’t eat eight hours a day

There were many things I could do for two or three days and earn enough money to live on for the rest of the month. By temperament I’m a vagabond and a tramp. I don’t want money badly enough to work for it. In my opinion it’s a shame that there is so much work in the world. One of the saddest things is that the only thing a man can do for eight hours a day, day after day, is work. You can’t eat eight hours a day nor drink for eight hours a day nor make love for eight hours—all you can do for eight hours is work. Which is the reason why man makes himself and everybody else so miserable and unhappy.

The Three P’s

I always like a good three p’s explanation:

We found three key elements that consistently drive innovation: people, processes and philosophies (what we call the 3Ps). We found that highly innovative organisations built their people, processes and philosophies around five fundamental “discovery skills”. Innovators ask provocative questions that challenge the status quo. They observe the world like anthropologists to detect new ways of doing things. They network with people who don’t think like them to gain radically different perspectives. They experiment to test new ideas and experiences. Finally, these behaviours trigger new associations which lead them to connect the unconnected, thereby producing disruptive ideas. An organisation’s investment in and ability to leverage these three facets of innovation sets it apart.

Composable Cloud At HP

“It’s not a microservice-built application; it’s not moving to a true CI/CD model; but it gets them incrementally on that path, and they start to get some value more short-term from that.”

“That’s where we focus: hit ’em where their problems are today,” he says. “‘Skate to where the puck is going,’ to use the Gretzky saying, but at the same time don’t skate out of the rink. Don’t come at them and say, ‘Hey, we have the microservices platform for you.’ ‘Awesome. What am I going to do with my SAP system?’ Getting that balance right is what we’ve been focused on.”

Bill Hilf on HP’s cloud approach.

Over communicating with change management

What I found is that this change management was really valuable. It was valuable in a number of regards. The first part of change management, which was interesting, was developing the case for change. Not to presume—even though it would be very easy to presume—that the organization would understand why it was important to do this but really to sit down and drive a compelling case for change that explained why people should go out of their comfort zone and actually go along with us in what was going to be an important but very challenging journey. We did that. We sold that all the time. We had town hall after town hall to continue to remind people why we were going through this.

And then the broad concept of constantly touching in with people and communicating and, frankly, over-communicating and sometimes even communicating when you had very little, if anything, to communicate just so that people could see you and not begin to develop views that were inconsistent with where you were heading, was really valuable.

Private cloud, still a thing

Round up of some recent private cloud surveys:

A comprehensive 451 Research report recently identified that hosted private clouds today accounted 25 per cent of budget for off-premises infrastructure spending and growing to 29 per cent in two years. Public cloud accounted for 17 per cent today and growing to 18 per cent in two years.

Private cloud has come to include “public private cloud,” hosted/dedicated gear.

Give me less of what I want, and more of what I need

Enterprises don’t need a more modern data center. I repeat, enterprises don’t need a more modern data center. They need to to be able to leverage a variety of data centers that support a variety of services, and they need the I&O team to provide support in order to ensure efficient and effective service delivery. The I&O team cannot be defined by the hardware they own and operate.

Public IaaS sort of a big deal – $16.5bn in 2015

Some new market sizing for public IaaS is out from Gartner. $16.5bn in 2015, out of a $3.5t pie of global IT spend.


For the first time this year growth of public cloud IaaS workloads outpaced that of on-premises workloads. One in 10 CIOs surveyed by Gartner say they have adopted a cloud-first strategy, while 83% consider IaaS a viable option to use

Here’s how we can help push DevOps into the mainstream

Can DevOps declare victory yet? Not quite, but soon.

Figuring out when a technology inflection point happens is always hard, if not impossible, in real-time. It’s easy to point backwards and say when ERP, agile software development, the Web, business intelligence, mobile or cloud suddenly became “normal.” I think DevOps is right at the door of that point, and as some recent Gartner predictions have proffered, we could see something like a quarter of all large enterprises using DevOps next year.

But it won’t be easy. The same house of industry sages also threw some cold water on that exuberance by predicting a 90% failure among organizations attempting to do DevOps if they fail to properly address process and culture.

As DevOps spreads to more and more IT shops, what can we in the DevOps community do to help? Clearly, we need to keep up the overall conversation about what DevOps is and the process/cultural changes needed to be successful. Another critical element is to start telling more and more stories of how non-technology companies are succeeding with cloud and DevOps. I think the recent Humana profile provides an interesting template here, as does Standard Bank’s forays into DevOps.

In addition to keeping up the good work, there are four key areas that will be helpful.

1. Define the goal properly

In one of my favorite straw-polls, groups who focus on the wrong outcomes and goals with private cloud have similar failure rates as those Gartner describes for organizations attempting to do DevOps.

What exactly those right goals are, for both DevOps and cloud adoption, is a new theory of mine I wanted to road-test with the DevOpsDays Austin crowd. As far as I can tell, the best goal of both a “cloud project” and “doing DevOps” is to do continuous delivery. So, cloud and DevOps let businesses set up the process and technologies needed to deliver custom written software on weekly, if not shorter turns, and actively study, learn and adapt software from the feedback of actual people using their software. This is the path of becoming a software defined business and DevOps is the definitive “how” of how that’s done.

Making DevOps and continuous delivery synonymous

To that end, I suggested to the audience in Austin that we should start, more or less, thinking of continuous delivery and DevOps as synonymous. Once you frame what DevOps is — what DevOps enables — as that, the conversation becomes crisper and, I believe, easier for everyone to understand and do something about. As I discussed last time, becoming a software defined business entails (a.) starting to think in a product-oriented manner (greatly facilitated by continuous delivery), and, (b.) ensuring that you have the overall cloud platform in place that provides the feathered, infrastructure bed for everything.

And, to add to the tracking of DevOps’ ascension to the mainstream, if you think of it as continuous delivery, some recent studies have shown that while overall CD use is low, growth has been ramping up year over year, just like DevOps.

2. Clearly explain the DevOps stack(s)

While even the best tools without the proper process (or “culture”) are ineffective, most people think in terms of stacks and tool-chains. So many of the DevOps conversations I’ve been involved in over recent years start by talking about tools and technologies. We’re in IT: it’s what we know.

I’d really like to see us start discussing common tool-chains and patterns of use (“cookbooks” to use an older, common programming documentation metaphor) for doing DevOps. Reference implementations even! Vendors do well telling you what they think the toolchain should be — please, oh please, feel free to ask me! ;). In fact, I’d say there’s almost an unhelpful amount of fragmentation in the infrastructure management layer at the moment: there are so many options that one can be left confused and overwhelmed.

Instead of letting us vendors define those stacks, I’d like to see the overall community get even more involved. Don’t be afraid to talk about tools in the face of all this culture talk! And don’t let us vendors steal the show.

3. Work with legacy code

Almost by definition, the IT shop at a non-technology company will be chock full of existing IT and “legacy code.” That’s the very IT that was once the growth-engine darling of the company and laid the foundation for where they are now.

As we all know but try to shy away from admitting too loudly, the new cycle of code and tech rarely works with the previous cycle’s code. I talk with companies almost weekly that are very interested in the question of how to integrate new cloud-native and mobile applications with five, 10, even 15+ year old centralized IT services. They want all the power of cloud and continuous delivery, but need help rationalizing and working with what they already have.

In my view, this is a conversation that doesn’t happen often enough in the DevOps community. It first starts with a — wait for it! — seemingly dottering old term: “IT portfolio management.” That is, taking the time to assess what IT you have and understand the business priorities around it. Without that kind of big picture, systems-based understanding of what you have, any whiz-bang awesomeness you get with DevOps will pale in comparison to the rumbling rebar-festooned concrete ball of legacy IT you have to deal with. (Damon Edwards gave a great talk right before mine introducing one method of getting down and dirty with portfolio management.)

There are many thought-technologies of how to approach this, from Gartner’s bi-modal IT approach, to some interesting work going on over at the Cutter Consortium. The point is to have the discipline and maturity to actually do portfolio management so you can start to improve everything and better prioritize your time and projects.

And, to point out the obvious: we need to start documenting how the application being written and supported by DevOps teams is integrating and co-existing with non-DevOps (or “legacy”) applications and services.

4. Keep up the Land-grab

As its name implies, DevOps has been on a land-grab mission that started back in the Agile days. If agile had gone the portmanteau route in naming itself, we might have seen DevQA, or even ProductDevQA. Agile development very consciously crossed silos and unified product management and QA with development, so much so that by the time we came up with DevOps, “Dev” represented all of those traditional roles.

Now, as companies are looking to IT and custom written software to help them become software defined businesses, DevOps-minded folks need to start thinking about how they can get more involved with “the business.” Do you know who these mythical business people are, what they’re worried about, how they think? Can you speak their language and help them learn yours?

To pick one very specific item that’s always a punji pit of IT despair: what KPIs and metrics should you use to communicate “up the chain”? (Ernest Mueller and Karthik Gaekwad have a great presentation on just this topic from last year.)

Think of it this way: what is the “API” for your business, and how can you start programming it…if not designing the API? Once DevOps is tightly integrated with the business side, and most companies are activity thinking about how custom written software can help run, grow, and innovate their business…then we’ll be able to declare DevOps success in the mainstream.

(I originally wrote this May 2015 for FierceDevOps, a site which has made it either impossible or impossibly tedious to find these articles. Hence, it’s now here.)