Pets, Cattle and Now…Insects?

The first time I heard the term “pets vs. cattle” in relation to anything technical, I was completely baffled. I mean really, what does animal husbandry have to do with how I take care of my computer equipment?

If you saw my laptop, you would instantly know that it is more than cattle, more than a pet — my laptop is basically another child of mine. In fact, my children would tell you it’s my favorite child. I’m not proud of that, but there it is. However, as I began to think of these terms in light of cloud computing, I realized it was a great analogy for the paradigm shift in the way we approach computing on premise vs. how it “should” be done in the cloud.


Many years ago, I rescued a pitbull-boxer puppy. It was a gift to my newlywed wife. This dog was a scrawny little thing with a head so oversized he could barely keep it off the ground. We immediately fell in love with the little guy, we named him Rascal and brought him home.

Two days later, we found out he had parvo and giardia and had become very sick. It was heartbreaking, and we were stuck with the tough decision of putting him down or paying an absurd amount of money and hoping he’d get better. Needless to say, we paid the money. Yep, we paid the money and nursed him back to health because he was our pet and that’s what you do with pets.

This same logic is found throughout IT departments worldwide, in regards to their computing power. We affectionately name our servers. I once worked in an IT department where all the servers were named after the IT director’s ex-girlfriends.

Furthermore, if one gets sick, we spend money and resources to get it back into shape. In a capital expenditure, on-premise world, this makes sense. Considering the CapEx and time required to provision a server, we generally plan to keep that server running for as long as possible.

However, what happens when you move your infrastructure to an operating expense, cloudy environment? In a cloud environment where all computing is virtual and priced on-demand, there is no longer a mix of CapEx and OpEx. Instead, you deal primarily in OpEx. This not-so-subtle shift lowers the barrier of entry and drastically changes how we should be approaching compute management. 


A week before I got married, my soon to be father-in-law took me out on his ranch and pointed to one of five cattle pens with about 100 head of cattle in it. As he pointed he said, “This group of cattle will belong to you and your wife after you get married.”

I’m not going to lie, I was floored. I am as city as it gets. I remember thinking, “I have cows?!” As a joke, I started pointing at them and naming them: Bessie, Ethel, T-Bone, etc. At this, my father-in-law cautioned me to never name the cows and to not get attached to any of them. He explained that the single purpose of these cows was to grow fat and sell for slaughter. If a cow could not do that, then it was disposed of and replaced. Harsh words, but a good lesson.

As we look at compute management in the cloud, there is a paradigm shift to treating servers as cattle rather than pets. This means, when a server gets sick, we spend minimal or no time trying to fix it. Instead, we throw it away and bring up a new one.

In this world, we do not get attached to servers and we never, ever, under any circumstance, name them something cute. Now, I understand what you’re thinking, “That’s easier said than done,” and you’re right. Treating compute resources as cattle requires planning. A server that we can throw away must be stateless. It must run in such a way that if we were to lose it, we wouldn’t lose any customer data along with it.

While creating a stateless machine is outside the scope of this blog post, let me drop a few concepts to get you started.

  • No local storage: S3 is the first choice for object level storage and it is cheaper.
  • No local sessions: customer sessions should live in a database or cache.
  • Redundancy: if a server goes down, another should be there to take over immediately. Think Autoscale, ALB or ELB, and multi-region.

And now there are insects

Until recently, this is where the compute-as-animals analogy ended. However, a new concept has recently emerged. Did you know that there is an insect called a Mayfly, which lives in its winged state for generally one night at the longest?

This creature’s short-term lifespan lends an analogy to the third concept of computing, called the insect. Like cattle did to pets, insects introduce yet another way of approaching computing that vastly differs from the paradigm of cattle.

Insect-style computing represents computing that only exists for the length of time it is needed. Another name for this is event-driven computing. A great example of this is AWS Lambda. A lambda generally has a lifecycle of one to five seconds. When the event that triggers the lambda occurs, the lambda initiates, executes and then goes away. The cycle happens so fast, it’s billed in the milliseconds.

This kind of single instant computing is great for API backends, one-off processing and so many other applications. Another example of insect-style computing is containers. Containers, when done right, work on a very granular level and can be introduced and disposed of as needed. A great example of a container short lifespan usage is that of AWS CodeBuild.

CodeBuild is used to build and test code in a DevOps pipeline. When the testing and building phase of a pipeline occurs, a container is spun up long enough to run the required processes, then it is disposed of.

While insect-type computing may not be achievable for every story, it’s easy to see its advantage. First of all, cost: in a pets or cattle model of computing, even if you have no activity on your instances, you pay for their uptime. When employing an insect approach, you only pay when there is activity.

Second of all, maintenance: insect-level computing generally lends itself to being managed as code. Since the infrastructure of these services is managed by AWS, all you really have to worry about is application and code.

The bottom line

As AWS solutions architects for Rackspace, we spend a great deal of time helping customers migrate their workloads to AWS or helping them improve a current workload. When doing this, we work through a three-phased approach.

  1. Transition: start with getting your workload on AWS and take advantage of basic services like EC2, RDS and others. In this phase, while we encourage the cattle mentality, we often see customers getting stuck in the pets mentality.
  2. Optimize: we then start helping the customer re-architect to incorporate higher level services like S3, ElastiCache, ElasticSearch and others. By this time, many customers have embraced the cattle mentality and are looking toward the next level.
  3. Transform: in this level, we help customers transform their workloads to use insect-style computing like Lambda, SNS, SES, SQS, DynamoDB and others. In this phase, the client gets the most out of each dollar spent on AWS and is the most flexible and ready for change.

So, the bottom line for you: where are you in this process? Many times, I see people migrate to the cloud and stop. The feeling is, “We’re there, and that’s good enough.” But the reality is, if you want to take full advantage of the cloud and all it has to offer, you need to explore your approach to computing and how you can take advantage of cattle and insects to mature your workflow and improve your economics.

Let’s face it, cloud is not a one-time event.

Have questions about your AWS workloads? Visit Rackspace for more information about our AWS-certified experts and the ways they’re helping businesses get the most out of AWS.


Please enter your comment!
Please enter your name here