Exploring automation

We’re going to start with why automation is needed in life in general and then we’ll move toward a more specific definition that relates to DevOps and other tech team activities. Automation is for the lazy, but many do not realize how hard you must work and how much you must study to truly be lazy. To achieve automation, it requires a mindset, an attitude, a frustration with present circumstances.

Automation and how it relates to the world

In Tim Ferris’s book The 4-Hour Workweek, he has an entire section dedicated to automating the workflow which emphasizes the fact that the principle of automation helps you clean up your life and remove or automate any unnecessary tasks or distractions. DevOps hopes to do something similar but in your professional life. Automation is the primary basis that frees up our time to do other things we want.

One of the things mankind has always tried to automate even further is transportation. We have evolved from walking to horses to cars to planes to self-driving versions of those things. The reason for that is the same reason DevOps became a prominent culture: to save time.

How automation evolves from the perspective of an operations engineer

You may have heard the famous story of the build engineer who automated his entire job down to the second (if you haven’t looked it up, it’s a great read). What he did was he automated any task within the server environment that required his attention for more than 90 seconds (solid DevOps principles from this guy if you ask me). This included automatically texting his wife if he was late, automated rollback of database servers based on a specific e-mail sent by a client’s database administrator, and Secure Shelling into the coffee machine to automatically serve him coffee, further proving my point that most things can be automated.

You don’t need to automate your workspace or your life to this extent if you don’t want to, but here’s the lesson you should take away from this: use automation to save time and prevent yourself from being hassled, because a) your time is precious and b) an automated task does the job perfectly every time if you set it correctly just once.

Let’s take ourselves through the life of a young software engineer named John. Let’s say John is a Flask developer. John has just joined his first big-boy software team and they are producing something already in production with a development and testing environment. John has only worked on localhost:5000 his entire programming journey and knows nothing past that (a lot of entry-level coders don’t). John knows you use Git for version control and that the source code you push up there goes… somewhere. Then it shows up in the application. Here’s John’s journey figuring it out (and then being bored by it):

• John gets access to the repository and sets up the code locally. While it’s nothing he’s never done before, he starts contributing code.
• A month later, an Operations guy who was managing the deployment of the specific service John was working on leaves. John is asked if he can take over the deployments while they hire a replacement. John, being young and naïve, agrees.
• Two months later, with no replacement yet, John has figured out how deployment servers such as Nginx or Apache work and how to copy his code onto a server environment and deploy it in a way that it can reach the public internet (it turns out it was essentially just localhost in disguise. Who knew?). He may have even been allowed to modify the DNS records all by himself.
• Four months later, John is tired, he spends half his time pulling code into the server, solving merge conflicts, restarting the server, and debugging the server. The server is a herd of goats, and he is but one hand with many mouths to feed. It becomes difficult for him to push new features and finish his pre-assigned tasks. This is when he starts wondering if there is a better way.
• He learns about bash scripting and runbooks. He learns that you can add triggers to both the repository and the server to perform certain tasks when the code has been updated. He also learns about playbooks that can be run when a common error starts popping up.
• Six months later, John has automated practically every part of the deployment and maintenance procedures for the application. It runs itself. The process has made John a better coder as well as he now writes his code with the challenges of deployment and automation in mind.
• Eight months later, John has nothing to do. He’s automated all relevant tasks, and he doesn’t need that Ops guy that HR never got back to him about. He is now a DevOps engineer.
• His manager asks him why his worklog seems empty. John tells him that DevOps tasks are measured by difficulty and complexity and not work hours. The manager is confused.
• Now, at this point, one of two things happens: either the manager listens and John pushes his enterprise toward a DevOps philosophy that will transform it into a modern IT company (there are antiquated IT companies, weird as that may seem), or he leaves for a place that appreciates his talents, which would be pretty easy to do if he markets them correctly.

This may seem like a fantasy, but it’s how many DevOps engineers are forged: in the fires of incompetence. This tale is, however, meant to be more analogous to companies as a whole and whether they transform to use DevOps principles or not. The ones that do become more agile and capable of delivering new features and using resources toward something as opposed to using them just to maintain something.

Automation is born out of a desire to not do the same things differently (usually for the worse) over and over again. This concept is at the heart of DevOps, since the people who automate realize how important it is to have consistency in repetitive tasks and why it is a time and potentially a lifesaver.

But for a task to be reliably done in the same way over and over again, it must be observed so that it can be kept on the correct path. That is where logging and monitoring come in.