What does pets vs cattle mean in server management?

Pets vs cattle is the analogy that separates two ways of running servers. A pet is a unique server with its own name, configured by hand: when it gets sick, someone nurses it back to health, because nothing else can take its place. Cattle are a herd of identical servers, built by automated procedures and numbered rather than named: when one fails, nobody repairs it. It is shut down and replaced with a fresh copy while the service keeps running on the others. The difference is not about hardware but about mindset. A server is cattle if it can be destroyed and recreated at any time without anyone noticing, and it is a pet if it is irreplaceable and must never go down. The analogy has become a quick way to explain to decision makers what changes with the cloud, and to ask which of a company's systems still depend on hands-on care.

See also: Infrastructure as Code (IaC) · Describing servers, networks and cloud services in versioned code files instead of configuring them by hand, so infrastructure is created and recreated reproducibly.

Where the analogy comes from

The image did not originate in the cloud. Randy Bias of Cloudscaling wrote in his 2016 account of its history that in 2011 or 2012 he found it in a presentation by Microsoft engineer Bill Baker on scaling SQL Server, where Baker used it to contrast many servers side by side with a single, ever-bigger one. Bias applied it to the cloud and put the emphasis on disposability. In his February 2012 slides, which credit Baker, the pet is called garfield.company.com and the cattle web001.company.com. The automation chapter of Google's 2016 Site Reliability Engineering book cites it in a footnote.

What it takes to move to cattle

It takes two things. The first is automation: a server that can only be rebuilt from memory cannot be replaced, so the shift goes hand in hand with infrastructure as code and often with containers. The second is a stateless design: the server keeps nothing irreplaceable, because data and user sessions live elsewhere. The Twelve-Factor App manifesto codifies both as factors: stateless processes and disposability, meaning processes that start or stop at a moment's notice and survive an abrupt shutdown. Systems that hold data remain the hard case. Bias points out that a datastore designed for failure, such as a Cassandra cluster running multi-master (several nodes accept writes) on more than two nodes, can be cattle, while the classic primary database with a passive standby is still a pet. In that case, you need backups and restore drills.

An enterprise example

A distributor with three hundred employees runs its customer portal on four identical servers and its ERP on a single physical machine, with a license tied to that hardware and a configuration only the administrator who set it up understands. When a portal server fails, the automated process builds a new one and customers never notice. When the ERP fails, the company stands still until that person gets it running again. The sensible path is not to turn everything into cattle. It is to acknowledge the ERP as a pet, document how to rebuild it, ask the vendor whether the license allows moving it and rehearse the restore, as a disaster recovery plan requires.

Why it matters for decision makers

The useful question is which machines are still pets: usually legacy systems, single servers bound to a license, hand-configured databases and machines that are "best left alone". Each carries two hidden costs: a recovery time that rests on a manual repair, and key-person risk, because only one person knows the configuration. Moving to cattle means investing in automation and sometimes redesigning the application, so it pays to start where a failure hurts most. For whatever stays a pet, the honest choice is to say so and actually measure how long it takes to restore.