6

There is a great discussion of the Cattle vs Pets distinction from Randy Bias here. Martin Fowler talks about a SnowFlakeServer.

In a series of talks, Adrian Cockcroft talks about how they moved toward Cattle Servers for solving a scalability problem at Netflix.

The challenge with this distinction is always managing persistent state. 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 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?

Improve this question
9
  • 3
    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.
    – Michael - sqlbot
    Commented May 28, 2017 at 5:09
  • 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.
    – Tensibai
    Commented May 28, 2017 at 7:18
  • @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!)
    – Michael B
    Commented May 29, 2017 at 1:18
  • @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?
    – Michael - sqlbot
    Commented May 29, 2017 at 3:19
  • @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.
    – James Shewey
    Commented May 30, 2017 at 17:34

1 Answer 1

Reset to default
9

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 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.

Improve this answer
2
  • 1
    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.
    – Jesusaur
    Commented Jun 1, 2017 at 23:21
  • 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.
    – Tomm P
    Commented Feb 4, 2021 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.