<p>To add to Richards answer, generally the analogy is helpful in terms of considering the impact of the loss of a server.</p>

<p>If you would feel some sort of distress over the loss of any individual piece of infrastructure, then consider it a pet (read antipattern).</p>

<p>If you would feel pretty comfortable knowing that if any of the fleet stopped functioning there would be no real impact to operations, then you are talking about cattle.</p>

<p>It's often tempting to use the analogy to simply classify your servers, ie "our workload nodes are cattle but our load balancers are pets" but falling into that trap is exactly the problem. There is no place for pets in a modern computing environment (ie. In the cloud, on commodity hardware etc.) If all of your servers are considered cattle, and are easily replaceable, then you can start looking at things like chaos monkey to help build assurance that your infrastructure truly is resilient.</p>

CC BY-SA 4.0
2020-05-13T16:43:49.927Z
"If you would feel some sort of distress over the loss of any individual piece of infrastructure, then consider it a pet (read antipattern)." TIL databases are an antipattern.
Beefster
CC BY-SA 4.0
2020-06-20T02:44:15.493Z
@Beefster I still stand by my 2017 answer, if you have designed a database such that you would feel distress over the loss of a piece of infrastructure then you have just designed either a very expensive (ie. Paying lots of money for extremely reliable specialised hardware) or an extremely brittle database system (ie. If a node goes down then better wake up the support teams and revive that thing and get it healthy again).
hvindin
CC BY-SA 3.0
2017-03-27T09:28:48.657Z
2017-03-27T09:28:48.657Z
hvindin
<p>Randy Bias <a href="http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/" rel="noreferrer">chronicles the history</a> of the term stating that it probably originated in 2011 or 2012 when Bill Baker used the analogy when describing "scale-up" vs. "scale-out" architectural strategies. Bias adopted this into his presentations about cloud architectural patterns:</p>

<blockquote>
  <p>In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.</p>
</blockquote>

<p>Bias continues to define Pets as</p>

<blockquote>
  <p>Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.</p>
</blockquote>

<p>and cattle as</p>

<blockquote>
  <p>Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.</p>
</blockquote>

<p>Fundamentally, what Bias and Baker are trying to convey is there has to be a transition from how we treat servers from being <a href="https://dzone.com/articles/martin-fowler-snowflake" rel="noreferrer">"Unique Snowflakes"</a> with names and emotional attachments, to a model whereby if we have a problem with the server we create a replacement and destroy the problematic server.</p>

<p>Finally, it is probably worth mentioning that in regulated environments taking a server out the back and shooting it may not be optimal.  In these cases it is often advantageous to "freeze" the server, for example using <a href="https://docs.docker.com/engine/reference/commandline/pause/" rel="noreferrer"><code>docker pause</code></a> to freeze a container.  This can then be used to perform a <a href="https://en.wikipedia.org/wiki/Root_cause_analysis" rel="noreferrer">Root Cause Analysis</a> as part of the Incident or Problem Management Process.</p>

CC BY-SA 3.0
2017-03-25T13:23:01.333Z
2017-03-25T13:23:01.333Z
Richard Slater
<p>The term "treat your servers like cattle not pets" has proliferated in recent years, particularly when applied to Docker containers and Virtual Machines</p>

<p><a href="https://i.sstatic.net/Lm3Td.jpg" rel="noreferrer"><img src="https://i.sstatic.net/Lm3Td.jpg" alt="Pets vs. Cattle"></a></p>

<p>What does it actually mean?</p>

<terminology><snowflake-server><cattle-vs-pet>
What is the definition of "cattle not pets"?
Richard Slater
# What is the definition of "cattle not pets"?

(Asked by: username_0 on 2017-03-25)

The term "treat your servers like cattle not pets" has proliferated in recent years, particularly when applied to Docker containers and Virtual Machines

[![Pets vs. Cattle](https://i.sstatic.net/Lm3Td.jpg)](https://i.sstatic.net/Lm3Td.jpg)

What does it actually mean?

**Tags:** terminology, snowflake-server, cattle-vs-pet


---

## 2 answers

### Answer by username_0 on 2017-03-25. Score: 94 | Accepted answer

Randy Bias [chronicles the history](http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) of the term stating that it probably originated in 2011 or 2012 when Bill Baker used the analogy when describing "scale-up" vs. "scale-out" architectural strategies. Bias adopted this into his presentations about cloud architectural patterns:

> In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.

Bias continues to define Pets as

> Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.

and cattle as

> Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.

Fundamentally, what Bias and Baker are trying to convey is there has to be a transition from how we treat servers from being ["Unique Snowflakes"](https://dzone.com/articles/martin-fowler-snowflake) with names and emotional attachments, to a model whereby if we have a problem with the server we create a replacement and destroy the problematic server.

Finally, it is probably worth mentioning that in regulated environments taking a server out the back and shooting it may not be optimal. In these cases it is often advantageous to "freeze" the server, for example using [`docker pause`](https://docs.docker.com/engine/reference/commandline/pause/) to freeze a container. This can then be used to perform a [Root Cause Analysis](https://en.wikipedia.org/wiki/Root_cause_analysis) as part of the Incident or Problem Management Process.


---

### Answer by username_1 on 2017-03-27. Score: 32

To add to Richards answer, generally the analogy is helpful in terms of considering the impact of the loss of a server.

If you would feel some sort of distress over the loss of any individual piece of infrastructure, then consider it a pet (read antipattern).

If you would feel pretty comfortable knowing that if any of the fleet stopped functioning there would be no real impact to operations, then you are talking about cattle.

It's often tempting to use the analogy to simply classify your servers, ie "our workload nodes are cattle but our load balancers are pets" but falling into that trap is exactly the problem. There is no place for pets in a modern computing environment (ie. In the cloud, on commodity hardware etc.) If all of your servers are considered cattle, and are easily replaceable, then you can start looking at things like chaos monkey to help build assurance that your infrastructure truly is resilient.

> **Comments:**
> **username_2**: "If you would feel some sort of distress over the loss of any individual piece of infrastructure, then consider it a pet (read antipattern)." TIL databases are an antipattern.  
> **username_1**: @username_2 I still stand by my 2017 answer, if you have designed a database such that you would feel distress over the loss of a piece of infrastructure then you have just designed either a very expensive (ie. Paying lots of money for extremely reliable specialised hardware) or an extremely brittle database system (ie. If a node goes down then better wake up the support teams and revive that thing and get it healthy again).  

---

