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...

Switching to a more grounded topic, one of the driving principles of DevOps is logging and monitoring instances, endpoints, services, and whatever else you can track and trace. This is necessary because regardless of whatever you do, how clean your code is, or how good your server configuration is, something will fail, go wrong, or just inexplicably stop working altogether. This will happen. It’s a fact of life. It is in fact, Murphy’s law:

Anything that can go wrong will go wrong at the worst possible time.

Familiarizing yourself with this truth is important for a DevOps engineer. Once you have acknowledged it, then you can deal with it. Logging and monitoring come in because when something does go wrong, you need the appropriate data to respond to that event, sometimes automatically.

The rest of this section has been laid out in terms of logging, monitoring, and alerts. Each one of these aspects plays an important role in...

I’m going to put Murphy’s Law here again because I cannot state this enough:

Anything that can go wrong will go wrong at the worst possible time.

Dealing with incident and event response involves either a lot of work or zero work. It depends on how prepared you are and how unique the incident or event is. Incident and event response covers a lot of ground from automation and cost control, to cybersecurity.

How a DevOps engineer responds to an event depends on a great number of things. In terms of dealing with clients and customers, a Service Level Objective (SLO) is used when a response is necessary. However, this is largely on production environments and requires the definition of a Service Level Indicator (SLI). It also involves the creation of an error budget to determine the right time to add new features and what the right time is to work on the maintenance of a system. Lower-priority development environments are used to stress...

I’m not going to state Murphy’s Law a third time, but understand that it applies here as well. Things will go wrong and they will fall apart. Never forget that. One of the reasons DevOps as a concept and culture became so popular was that its techniques delivered a highly available product with very little downtime, maintenance time, and vulnerability to app-breaking errors.

One of the reasons DevOps succeeds in its mission for high availability is the ability to understand failure, react to failure, and recover from failure. Here’s a famous quote from Werner Vogel, the CTO of Amazon:

Everything fails, all the time.

This is, in fact, the foundation of the best practice guides, tutorials, and documentation that AWS makes for DevOps operations, and it’s true. Sometimes, things fail because of a mistake that has been made. Sometimes, they fail because of circumstances that are completely out of our control, and sometimes...

Finally, in a book about Python, we get to a section about code. So far, I’ve given you a lot of information about what needs to be accomplished but to accomplish the things we want especially in this book, we must have a method, a tool, a weapon, i.e., code.

Now the word “code” scares a lot of people in the tech industry, even developers. It’s weird being afraid of the thing that is under everything you work with. But that’s the reality sometimes. If you, dear reader, are such a person, first off, it’s a brave thing to purchase this book, and secondly, all you are doing is denying yourself the opportunity to solve all the problems you have in the world. Seriously.

Now, the reason is that code is the weapon of choice in almost every situation. It is the solution to all your automation problems, monitoring problems, response problems, contract problems, and maybe other problems that you may have that...

The concept of DevOps is exciting, vast, and has room to get creative. It is a discipline where the world is essentially at your command. Effective DevOps requires effective structure and adaptation of that structure to a challenge as we learned in our Exploring automation section.

But remember, anything that can go wrong will go wrong, so plan for success but prepare for the fact that failure is a common occurrence. In such cases of failure – as we learned in the sections about monitoring and event response – the ability to recover is what matters, and the speed of that recovery also matters quite often. If an incident to be recovered from is new, it must be reported and understood so that such incidents can be mitigated in the future.

And lastly, as we covered in Delving into infrastructure as a code, code is your friend. Be nice to your friends and play with them. You’ll learn how to in this book.