‘Continuous Operations’ a great idea — but details of execution still matter

Mike Kavis advertises “Continuous Operations” as the new “way of delivering software” we need in today’s “elastic cloud”-based computing environment where “… Zero Downtime Deployments” are required. The ideas here are so vital that it’s worth our time to clear up a few of his imprecisions in presenting them.

Start with the “March of Progress” illustration prepared for Kavis’ article, and reproduced below under Fair Use doctrine. It has virtues: it’s attention-grabbing and memorable, and makes the point that the results of different DevOps practices differ widely. Rudolph Zallinger‘s original, now almost a half-century old, was misleading when first published as anthropology, and even less reliable as a classification of what goes on in datacenters. Fossil bones, for example, can more-or-less reliably be assigned to specific species, but when a front-line DevOps practitioner tells you she’s working on Nagios scripts for a collection of Windows servers, you know no more than before meeting her whether she’s practicing “Waterfall”, “Continuous Operations”, or something in-between. Pictures are usefully suggestive, and help communicate important ideas; they’re only the beginning of analysis, though.

It’s pedantic legalism to come down so hard on what Kavis surely intends as just a suggestive cartoon, of course–except that too much of information technology (IT) decision-making muddles metaphor and meaning. Kavis is right to think about the proper place of “Agile”, “Lean”, “Continuous Integration”, and so on; he’s right that many of us work in environments where downtime must be kept below a minute or even a second at a time; concepts like “rollback” and “A/B testing” are indeed crucial; and Humble and Farley’s book on Continuous Delivery … remains timely and important more than three years after its publication. It’s out-of-balance, however, to teach that “[t]he trick to pulling this off is to separate database changes from software changes.” While the database-software distinction is paramount for many operations, it’s insignificant for others. In some operations, important planes for management of zero-defect deployment have to do with software-vs.-network, or database-vs.-storage, or even more arcane divides.

Everything to know about DevOps, or even just continuous operations in a DevOps context, doesn’t fit in the few hundred words of Kavis’ posting or this follow-up. I don’t fault Kavis for highlighting the tips he’s found pay off biggest. Weighty books like Continuous Delivery … have plenty of gaps (where are the concrete implementations with specific tools to prove that the testing concepts are feasible?). The conclusion for today: we’re still early in understanding the labels in the picture above, there’s a lot more to learn, and, as with so many IT matters, the details matter.