In the infrastructure management space, the “pets vs. cattle” analogy is a popular one. It’s likely something you’ve heard before: Servers in on-prem data centers are typically treated like assets (“pets”), but your cloud servers are essentially nameless resources that you rent on-demand (“cattle”).
We Name (and “Save”) Pets
How about this as a common scenario: if you’ve got three servers in a data center, they could be named Larry, Moe, and Curly. A colleague of mine remembered a debate about a naming convention for their on-prem server closet. The winner? Simpsons characters. (There are probably folks reading this who worked for at least one company where a sys admin was heard yelling “Marge is down.”)
In the on-prem world, you have no choice but to go figure out what’s broken. We typically try to “nurse” servers back to health. What other choice do we have? In the cloud, though, we don’t individuate resources.
The “herd” mentality is a bit different. We take “pets” to the vet. A herd of cattle? Not so much. In the cloud, we bring resources up and down all the time. If I have a problem on an individual server, I’m not going to log in and spend hours troubleshooting while production is down.
Instead, I’m going to kill that server and start up a new one. If I’ve architected and preconfigured everything properly, I don’t have to go in and start from scratch.
I click a button and boom. It’s up. I can still go back and figure out what’s going on with the other server if I need to. But this way, I don’t get attached intellectually to a resource, because all of my infrastructure is, in a sense, ephemeral.
Cloud resources can also scale almost instantly. If I’ve got three servers running for normal traffic, but I suddenly have a spike, I can spin up two more if and when I need them.
Here’s the key: As soon as I don’t need those resources anymore, I can spin back down, and my resources won’t be negatively impacted. Bonus: I don’t have to spend the money to run those resources 24/7 on the off chance that I may need them again.
But, what better way to explain the pets vs. cattle analogy than with an actual pet?
Meet Sophia, The DevOps Cat
Right when COVID hit, we did our first remote/virtual DevOps Bootcamp. It’s one that my colleague Ryan and I have done many times together in person.
During the section of the class where we talk about pets vs. cattle, Ryan’s cat Sophia happened to be sitting by his feet. He literally held her up in front of the camera and used her as the IRL example of this concept.
It went something like this: “This is Sophia. If she gets sick, we take her to the vet. She’s been with us for a long time. Obviously, she has a name. We’ll always take care of her.”
It’s probably the only time a cat interrupting a virtual meeting was perfectly timed.
What’s poignant about Sophia’s presence in the class is that moment informed how I personally think (and talk) about architecting solutions in the cloud.
We still see quite a few companies utilize a “lift and shift” strategy when they move to the cloud. They replicate the exact same set-up, and leave those resources running 24/7. It’s a lot more convenient to let an on-prem server run rather than reinstall everything after you shut it down for any reason.
When you build and utilize resources on a one-to-one basis in the cloud, as you do in the on-prem world, you still develop a mentality of being dependent upon the limitations of a single machine (Sophia). When you treat resources like cattle (nameless, faceless resources with nothing more personal than a tag on the ear), you can improve speed and reliability.
In the cloud, we use templates to automate the set-up process. If you set everything up correctly from the beginning, you can hit a couple of buttons and the same environment is ready to go without having to reinstall everything. You don’t have to spend hours configuring necessary firewalls, permissions, etc.
Lift and shifts don’t necessarily adversely affect you, but you lose out on these innovations, cost savings, and benefits. Taking complete advantage of this new form of architecture often requires an entirely different mindset.
If you want to see us in action and watch us spin up a live environment in real time, and then take it down, check out our free webinar, “How To Improve Security, Speed, and Savings with Infrastructure-as-Code.” You never know. Sophia may make an actual appearance.
Tag(s):
Matt House
Matt is a recovering developer that still gets excited when hears the "Ribbit" of someone starting up Toad. After spending some time in the world of project management, Matt was convinced there had to be a better way to develop software. Once he attended his first agile boot camp he discovered that flowers smelled...
Connect with the author
Other posts you might be interested in
Infrastructure-as-Code
7 min read
| June 21, 2022
How Does Using IaC and its Associated Benefits Fit Into a Traditional Data Center?
Read More
Development
24 min read
| July 16, 2018
Set Up An SFTP Server Backed By S3 On AWS
Read More
Development
9 min read
| August 21, 2018