Sustainable Automation

When you automate technology (at a meaningful scale, anyway), you invariably wind up writing code. I've yet to see some automation technology that was all point-and-click. Chef, Puppet, Bash, Python, Powershell.... all of them languages.

Since we're writing code for our automation, we might as well write sustainable code. I can sum up the entire point like this:

Writing code has

1. An initial cost. The cost, in time, dollars, or other measurement to write the code and 
2. A maintenance cost. The cost you incur to keep the code relevant.

If you're lucky, your code will survive long enough to accrue a maintenance cost. If that is the case, it is nearly certain that the maintenance cost will be overwhelmingly larger than the initial cost. Therefore, we always seek to reduce the maintenance cost.

Or, in more interesting terms (and I cannot take credit for this version), write your software as if it will be maintained by a homicidal maniac who knows where you sleep.

Now that we know what to do (reduce maintenance cost), we need some direction on how to do it. The answer, as is most often the case, is simplicity. How do we keep things simple?

I like to borrow a few notes from the Unix Philosophy, specifically 'keep things modular' (Small is Beautiful). Regardless of technology, you'll be modularizing your work, whether they be in functions, recipes, manifests, whatever. Think of these as your atomic work units, where the keyword here is atomic. Your units should do one thing, and they should do it well. If you want to add functionality to a unit, make another unit and have your first one call it.

Why? Why not just add functionality to the existing work units? It's easier, there are fewer units to juggle, and, yes, it takes less time.

Less time?

Less inital time, yes. But we're not working to minimize initial time. We accrue the initial time only once. The maintenance time (i.e. cost), however, we accrue every time we need to update our code. Every. Time. And god save us if we have to refactor our codebase. Forget progress, you'll be doing well just to get back to normal.

This is a quick (albeit contrived) example of my bigger point: Always strive to make things easier for the guy in the future. After all, it just may be you.

Every Job is a Custom Job

No matter how much we standardize, how repeatable or automated our processes are, we will never be able to deliver the exact same product/datacenter/service twice.

This isn't a problem experienced by many other domains (not to such a degree, anyway). I can order a pair of speakers from a manufacturer and they will be the exact same speakers that my neighbor orders. Likewise with most food at the store, even at restaurants. Sure, you can ask them to hold the onions on your burger but that level of customization is not what's experienced by developers/deployers/devops/what-have-you.

The customer will always have some indigenous nuance about their particular system - legacy software/hardware, limited budget, upper management has already decided on a particular product before you arrived - that will preclude you from delivering the *exact* same product every time.

The challenge, then (and what makes the work interesting), is working this reality into your automation processes.