When we stop treating servers as pets and more like cattle it becomes the essence of DevOps. Transitioning to a mindset where all servers and resources are as disposable as a candy wrapper is fundamental to building workloads that will solve modern day problems.

I love the story of Agile. In short, it was discovered that over time problems became harder and more complex to solve and to compensate how we solved those problems, we also had to shift. As such DevOps and Agile were developed to help solve problems in new and efficient ways.

It is treating servers or other computing resources, as pets – as long-lived, members of the family becomes problematic over time. Resources that have been around so long you remember their names and IPs. You know them so well that you know the raid card of ‘vader-prod-02’ acts up every so often but a reboot makes it nice and shiny again. The issue with this pet mentality is that now technical debt and one-time/one-off changes are only captured in one place of record – that server. How it is built or modified is lost as there is no place to easily record those details. The push for documentation was originally the answer – document everything with strong tyrannical-like Configuration Management (CM). CM then felt like it was run by a former nun with a ruler that would reach straight across the office. It became the promise to solve the problem of long-lived pet servers. The only issue with this is documentation, and production would drift. That drift would be hard to capture since business needs moved faster than the need to update documents. More so, the ability to do both was not easily achievable back in the day – a least without angry nun-like CM people running around, yelling at you to update documentation.

In comes the need to bring up a resource, have it perform a function and then to destroy it instantly. To enable this, the way we built and documented resources had to change fundamentally.  DevOps links the creation of resources to a defined documented procedure (in AWS this is CloudFormation for example). If I want to build a server with 3 NICs, I could define it. Also, the software installation procedures are all baked into that server’s CloudFormation so every time it starts, it’s in a known/documented state.  This is the power of DevOps – you know more about your resources than you ever did before and the knowledge gives you the capability to build massive systems and compute farms while always knowing how those resources are built – since you can always look at its definition in CloudFormation.

This mindset is freeing. You know so much about your resources and now aren’t afraid of rebooting a server since it been too long and the original team is no longer around. With DevOps, you know what it takes to build your environments and how to change them in manageable and traceable ways. DevOps also now introduces programmatic controls over resources – which aids in other useful ways, but that discussion is better left for a future blog post.

DevOps is the ability to no longer care about individual servers or other IT-related services/infrastructure. You are building resources to serve a distinct function and throw them away the moment they are no longer needed. So enjoy your pets, just don’t treat your servers as one.

By: Gabriel Alix