Intermission: the who, what, and why of Automation

If you've read any of my How to DevOp series (part 1 and part 2 available here), you've probably learned things about how IT careers progress; first slowly, then faster, and then slow again. What I did not address is exactly what you change into when you leave your home behind and enter the datacenter itself. Of course there are levels of increased responsibility, patterns of communication between departments, and professional courtesy at work. But this is ignoring one core element: determining agency.

Now that brings me to my next question: what is agency in this context? It is underlined and italicized for a reason. The goal of computers (and abaci, and math in general) is to let us do things that we otherwise would not be able to: if you were like me when you first started out, computers provided a great way to write word documents (or blogs!) and, of course, playing music and games. These three goals used the machine as a vector to achieve them: I didn't need cassette tapes or CDs to store my music collection anymore, that was all on a hard drive.

As is the goal with this extremely basic level of automation, I no longer had to parse through a physical collection to find my favorite tracks. I just had to search for them with basic text mapping. I don't think anyone gains long-term value from looking through a book of compact disks. This removes one layer of inconvenient, toilsome labor and makes it so that you never have to do it again. Of course, this requires the somewhat arduous task of going through a stack of jewel boxes and ripping each of them one-by-one. This took place in 2003. We're all getting old here.

Let's pull back and extrapolate that to a more complicated stack; say, a LAMP bundle. For the uninitiated, this consists a generic package of free, open-source, and interchangeable components:

• Linux, the operating system that runs everything.
• Apache, the web server that provides it to the network.
• MySQL or MariaDB, the database that stores values for rapid retrieval.
• Python (or PHP, or Perl), the programming language that defines the application.

Each of these things individually could take a year on their own to really master. But you don't need to understand every component to get some degree of use out of any of them. My somewhat humble home lab utilizes all of them in a different fashion, sometimes several times over. The trouble, toil, and loss of agency comes with the friction inherent in learning about each of these components: the information is widely available for anyone who wants to learn more about it, but that documentation can be dense and intimidating.

Furthermore, each element of this stack can be finicky. Databases can operate as shared points of failure, an anti-pattern that we should aim to avoid if we can. Programming languages may or may not have features depending on which version you've installed. Linux is typically dead simple, but every program that runs in it has configuration files that can grow complicated over time. And code is ... well, the very idea informs that it's messy, complicated, and even experts sometimes stumble over troubleshooting it.

The aim of automation is to play to the strengths of the computer. Machines are typically very bullheaded and uncreative: they can copy your grandmother's apple pie recipe and print out a thousand copies of it, but they can't differentiate between salt and sugar by taste (and boy, you do not want unsalted pie crust). The upside of this is if you take those language versions, proven functional code, linux and server configurations and reproduce it perfectly again and again, you play to the strength of automation. Database falling over and knocking down multiple services? Copy it as a container or virtual machine. We live in an era of cheap computing abundance (for now), the time is nigh to make use of it.

Note that this is an ingredient in, not the fix for, genuine business solutions. Lots of brilliantly architected computer-enhanced organizations fill the dustbin of corporate history. The problem you're ultimately looking to solved can be lubricated by automation and devops, but they won't be able to tell you where to pivot or what the market is doing. This goes doubly for what you actually want the machines to do. Given their druthers, I'm sure your desktop or laptop would be happy to sit there in sleep mode until its diodes rusted into obsolescence. But that's not what we built it for.

To bring the conversation full circle: devOps, automation, and heck, even AI is about increasing the amount of time we have to pursue these human solutions. To increase agency. My goal in this industry was never to spend weeks poring over manuals about how to master tools like regex and sed; one doesn't typically get into carpentry to find out how to make a hammer. These things are tools that are typically useful a couple of times a week or year. They're phenomenally powerful and the former has been working flawlessly since the Eisenhower administration; they're also complicated and a bit arcane, and I'd rather spend my time working on higher-level architecture.

Why? Because it's fun. That's the level where you can challenge yourself, get that feedback, work through the issues and sometimes impress yourself. I've spent my years in server racks and support desks, and while they're fine ways to make a living, I'm on a new adventure now. I don't expect it to last forever. But my hope is that when I finally work my way back home, I find that all this changing I've done has changed my own perspective as well.