Answers: <p>While technologically, containers and virtual machines are very different, there is no apparent difference from the perspective of your software. It seems like the argument in your question is that data is special and will always be a unique snowflake, so your question basically boils down to what to do about it in terms of DevOps, CI and Automation.</p>
  
  <p>This is the perpetual challenge of the DevOps model. Ultimately, what you are asking is, either A) your data will be in a database or B) a datastore , so how do you manage that?</p>
  
  <p>The answer is that yes, your database servers can and should also be treated as cattle - and <a href="https://devops.stackexchange.com/a/1220/2845">I recently detailed several techniques and technologies for doing so</a> in house. If you don't treat your data storage (databases, storage filers) as cattle you will find you have a single points of failure within your data(base) infrastructure and a lack of scalability and redundancy. These techniques I discuss in my linked answer basically allow you to distribute and cluster your relational database in a manner similar to Cassandra.</p>
  
  <p>Managing your data(bases) and making data(bases) redundant is probably the most difficult challenge facing DevOps. The easiest way to solve the problem: outsource the headache to a cloud provider.</p>
  
  <p>So in short, yes the "cattle not pets" distinction apply as equally to machine instances as to containers.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-01T23:21:33.533Z
Answers: I think it's useful to mention that in addition to avoiding scalability issues, a cattle-not-pets approach to databases and other datastores will greatly improve your disaster-recovery story. A large part of treating hosts as cattle is having a high level of automation so that the hosts always come up the same. And in the case of a database, this will hopefully include an automated restore-from-backup so that deploying from scratch and recovering from disaster are just two different use cases of the same automation.
Answers: Jesusaur
Answers: CC BY-SA 4.0
Answers: 2021-02-04T08:44:13.333Z
Answers: There are more subtleties to this whole area driven by the data structure. Most DBA's are very keen on fully modelling data inside the database (creating as full a model using relationships etc). This essentially maintains the monolithic nature of your system both from a "pet" vs "cattle" production point of view and from a change flexibility point of view. If you design a data structure where relationships are either absent or very carefully contained, the data ceases to need the "pet" treatment and containerisation is possible top to bottom.
Answers: Tomm P
Answers: CC BY-SA 3.0
Answers: 2017-05-30T17:28:54.013Z
Answers: 2017-06-02T03:53:10.860Z
Answers: 2017-06-02T03:53:10.860Z
Answers: James Shewey
Body: <p>There is a great discussion of the Cattle vs Pets distinction from <a href="http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/" rel="noreferrer">Randy Bias</a> <a href="https://devops.stackexchange.com/a/654/465">here</a>. <a href="https://martinfowler.com/aboutMe.html" rel="noreferrer">Martin Fowler</a> talks about a <a href="https://martinfowler.com/bliki/SnowflakeServer.html" rel="noreferrer">SnowFlakeServer</a>. </p>
  
  <p>In a <a href="https://www.youtube.com/watch?v=pwpxq9-uw_0" rel="noreferrer">series of talks</a>, <a href="https://twitter.com/adrianco?lang=en" rel="noreferrer">Adrian Cockcroft</a> talks about how they moved toward Cattle Servers for solving a scalability problem at <a href="https://www.quora.com/What-technology-stack-is-Netflix-built-on" rel="noreferrer">Netflix</a>. </p>
  
  <p>The challenge with this distinction is always <a href="https://www.hostworks.com.au/pets-versus-cattle-thinking-infrastructure-isnt-enough/" rel="noreferrer">managing persistent state</a>. Does it make sense to treat your database servers as Cattle? It does if you (a) manage the state outside of your cattle model (external volumes for your docker containers), or (b) use a distributed database like <a href="https://en.wikipedia.org/wiki/Cassandra" rel="noreferrer">Cassandra</a> that allows for individual nodes to fail, but still maintain state in the cluster. </p>
  
  <p>I get that you can get very close to the 'disposability with persistent state' of Docker containers mounting a shared volume, with launching AMIs to machine instances mounting a shared drive. You can get closer this this idea of scheduled cluster management by having an autoscaling group that recreates machines that you've blown away. </p>
  
  <p>To me - the machine instances lack the granularity of a docker container. They gravitate more towards the 'pets' end of the spectrum. </p>
  
  <p>My question is: <strong>Does the "cattle not pets" distinction apply as equally to machine instances as to containers?</strong></p>
  
Comments: CC BY-SA 3.0
Comments: 2017-05-28T05:09:30.873Z
Comments: Anyone who thinks for a minute that production databases should be cattle rather than pets does not understand production databases... but other than databases, it's not clear what class of instances you have in mind.
Comments: Michael - sqlbot
Comments: CC BY-SA 3.0
Comments: 2017-05-28T07:18:11.733Z
Comments: With on premise infrastructures using san or nas  volumes you can do exactly the same,  cattle Vs pet is applicable whatever the background infrastructure is.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-05-29T01:18:07.270Z
Comments: @Michael-sqlbot it would be a great to expand on that a little and create an answer... (at the very least, I'd be curious to read it!)
Comments: Michael B
Comments: CC BY-SA 3.0
Comments: 2017-05-29T03:19:28.257Z
Comments: @MichaelB thanks, but I'm not sure it's on topic. The point of my comment is to acknowledge that, yes, databases are a clear exception -- they they are the ultimate state-keepers, the nobility, the fixed fortresses/bastions/edifices of fact and truth, in a place where scaling is not trivial, and as such, master (but not necessarily replica) databases are quite rightfully immune from the disposability paradigms that are applicable to the "working class" VMs & containers... that, to me, isn't be debatable, so my intention is to ask: what cases besides databases are contemplated in the question?
Comments: Michael - sqlbot
Comments: CC BY-SA 3.0
Comments: 2017-05-30T17:34:35.710Z
Comments: @Michael-sqlbot: I think you are confusing your database **server** with your **data**. Your database servers are 100% disposable. Your data is not. If you think otherwise, I would suggest you think about what you feel would not work for treating databases server instances with a disposable mentality - what specific challenges would be faced - and ask those as questions. You might be surprised at the answers you get for overcoming these challenges.
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-05-30T20:04:15.043Z
Comments: @JamesShewey yes and no. I've actually been one to make the point that I, as the DBA, am primarily charged with care of the database, defined as the collection of information.  The servers are just where the databases live. The point -- which you've also addressed quite well in your other answer you cited -- is that database availability/resilience is not trivial. Outsourcing to a cloud provider primarily gives you warm and fuzzy feelings and someone else to blame until it falls apart, at which point, it's an outage, and one that you don't necessarily have the visibility to fix expeditiously.
Comments: Michael - sqlbot
Comments: CC BY-SA 3.0
Comments: 2017-06-02T15:07:24.223Z
Comments: "Cattle, not pets" *way* predates the use of containers in industry (other than Google).
Comments: Xiong Chiamiov
Comments: CC BY-SA 3.0
Comments: 2017-06-03T01:00:42.797Z
Comments: Thanks @Xiong, could you expand on that?
Comments: hawkeye
Comments: CC BY-SA 3.0
Comments: 2017-06-03T01:05:09.467Z
Comments: It was a common way of thinking about servers a few years ago, when ec2 was first gaining a lot of ground - manage all your VMs with the same configuration script, and kill any of them that exhibit strange behavior.  I don't have personal professional experience from the time before then, but from what I've seen the idea was present in datacenters long before then, as well.
Comments: Xiong Chiamiov
Tags: <docker><containers><autoscaling><amazon-ami><cattle-vs-pet>
Title: Does the "cattle not pets" distinction apply as equally to machine instances as to containers?
UserDisplayName: hawkeye
ThreadText: # Does the "cattle not pets" distinction apply as equally to machine instances as to containers?
  
  (Asked by: username_0 on 2017-05-28)
  
  There is a great discussion of the Cattle vs Pets distinction from [Randy Bias](http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) [here](https://devops.stackexchange.com/a/654/465). [Martin Fowler](https://martinfowler.com/aboutMe.html) talks about a [SnowFlakeServer](https://martinfowler.com/bliki/SnowflakeServer.html).
  
  In a [series of talks](https://www.youtube.com/watch?v=pwpxq9-uw_0), [Adrian Cockcroft](https://twitter.com/adrianco?lang=en) talks about how they moved toward Cattle Servers for solving a scalability problem at [Netflix](https://www.quora.com/What-technology-stack-is-Netflix-built-on).
  
  The challenge with this distinction is always [managing persistent state](https://www.hostworks.com.au/pets-versus-cattle-thinking-infrastructure-isnt-enough/). Does it make sense to treat your database servers as Cattle? It does if you (a) manage the state outside of your cattle model (external volumes for your docker containers), or (b) use a distributed database like [Cassandra](https://en.wikipedia.org/wiki/Cassandra) that allows for individual nodes to fail, but still maintain state in the cluster.
  
  I get that you can get very close to the 'disposability with persistent state' of Docker containers mounting a shared volume, with launching AMIs to machine instances mounting a shared drive. You can get closer this this idea of scheduled cluster management by having an autoscaling group that recreates machines that you've blown away.
  
  To me - the machine instances lack the granularity of a docker container. They gravitate more towards the 'pets' end of the spectrum.
  
  My question is: **Does the "cattle not pets" distinction apply as equally to machine instances as to containers?**
  
  **Tags:** docker, containers, autoscaling, amazon-ami, cattle-vs-pet
  
  > **Comments:**
  > **username_1**: Anyone who thinks for a minute that production databases should be cattle rather than pets does not understand production databases... but other than databases, it's not clear what class of instances you have in mind.  
  > **username_2**: With on premise infrastructures using san or nas  volumes you can do exactly the same,  cattle Vs pet is applicable whatever the background infrastructure is.  
  > **username_3**: @username_1 it would be a great to expand on that a little and create an answer... (at the very least, I'd be curious to read it!)  
  > **username_1**: @username_3 thanks, but I'm not sure it's on topic. The point of my comment is to acknowledge that, yes, databases are a clear exception -- they they are the ultimate state-keepers, the nobility, the fixed fortresses/bastions/edifices of fact and truth, in a place where scaling is not trivial, and as such, master (but not necessarily replica) databases are quite rightfully immune from the disposability paradigms that are applicable to the "working class" VMs & containers... that, to me, isn't be debatable, so my intention is to ask: what cases besides databases are contemplated in the question?  
  > **username_4**: @username_1: I think you are confusing your database **server** with your **data**. Your database servers are 100% disposable. Your data is not. If you think otherwise, I would suggest you think about what you feel would not work for treating databases server instances with a disposable mentality - what specific challenges would be faced - and ask those as questions. You might be surprised at the answers you get for overcoming these challenges.  
  > **username_1**: @username_4 yes and no. I've actually been one to make the point that I, as the DBA, am primarily charged with care of the database, defined as the collection of information.  The servers are just where the databases live. The point -- which you've also addressed quite well in your other answer you cited -- is that database availability/resilience is not trivial. Outsourcing to a cloud provider primarily gives you warm and fuzzy feelings and someone else to blame until it falls apart, at which point, it's an outage, and one that you don't necessarily have the visibility to fix expeditiously.  
  > **username_5**: "Cattle, not pets" *way* predates the use of containers in industry (other than Google).  
  > **username_0**: Thanks @username_5, could you expand on that?  
  > **username_5**: It was a common way of thinking about servers a few years ago, when ec2 was first gaining a lot of ground - manage all your VMs with the same configuration script, and kill any of them that exhibit strange behavior.  I don't have personal professional experience from the time before then, but from what I've seen the idea was present in datacenters long before then, as well.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2017-05-30. Score: 9 | Accepted answer
  
  While technologically, containers and virtual machines are very different, there is no apparent difference from the perspective of your software. It seems like the argument in your question is that data is special and will always be a unique snowflake, so your question basically boils down to what to do about it in terms of DevOps, CI and Automation.
  
  This is the perpetual challenge of the DevOps model. Ultimately, what you are asking is, either A) your data will be in a database or B) a datastore , so how do you manage that?
  
  The answer is that yes, your database servers can and should also be treated as cattle - and [I recently detailed several techniques and technologies for doing so](https://devops.stackexchange.com/a/1220/2845) in house. If you don't treat your data storage (databases, storage filers) as cattle you will find you have a single points of failure within your data(base) infrastructure and a lack of scalability and redundancy. These techniques I discuss in my linked answer basically allow you to distribute and cluster your relational database in a manner similar to Cassandra.
  
  Managing your data(bases) and making data(bases) redundant is probably the most difficult challenge facing DevOps. The easiest way to solve the problem: outsource the headache to a cloud provider.
  
  So in short, yes the "cattle not pets" distinction apply as equally to machine instances as to containers.
  
  > **Comments:**
  > **username_6**: I think it's useful to mention that in addition to avoiding scalability issues, a cattle-not-pets approach to databases and other datastores will greatly improve your disaster-recovery story. A large part of treating hosts as cattle is having a high level of automation so that the hosts always come up the same. And in the case of a database, this will hopefully include an automated restore-from-backup so that deploying from scratch and recovering from disaster are just two different use cases of the same automation.  
  > **username_7**: There are more subtleties to this whole area driven by the data structure. Most DBA's are very keen on fully modelling data inside the database (creating as full a model using relationships etc). This essentially maintains the monolithic nature of your system both from a "pet" vs "cattle" production point of view and from a change flexibility point of view. If you design a data structure where relationships are either absent or very carefully contained, the data ceases to need the "pet" treatment and containerisation is possible top to bottom.  
  
  ---
  
  