Currently I am reading the the Practice of System and Network Administration, by Thomas Limoncelli. In this book, I came across the concept of pets vs. cattle when it comes to managing your IT infrastructure. It's one of those ideas that changes the way you look at your servers. In a nutshell, pets are the highly customized machines and cattle are the generic machines.
Cattle-like systems give us the ability to grow and shrink our system’s scale. In cloud computing a typical architecture pattern has many web server replicas behind a load balancer. Suppose each machine can handle 500 simultaneous users. More replicas are added as more capacity is needed.
Another way of describing pets is to note that they contain a lot of irreproducible state. Cattle are stateless, or contain only reproducible state. State is, essentially, data or information. That information may be data files, configuration, or status. In a web-based application, there is the application itself plus the database that is used to store the user’s data. That database is state.
The more state a machine holds, the more irreplaceable it is—that is, the more pet-like it is. Cattle are generic because we can rebuild one easily thanks to the fact that cattle contain no state, or only state that can be copied from elsewhere.
We can turn pets into cattle by isolating the state. Imagine a typical web application running entirely on a single machine. The machine includes the Apache HTTP server, the application software, a MySQL database server, and the data that the database is storing. This is the architecture used by many small web-based applications.
The problem with this architecture is that the single machine stores both the software and the state. It is a pet. If the server goes down, our application goes down and the data is lost.
We can improve the situation by separating out the database. We can move the MariaDB database software and the data it stores to another machine. The web server is now cattle-like because it can be reproduced easily by simply installing the software and configuring it to point to the database on the other machine. This process is also called decoupling state. The all-in-one design tightly couples the application to the data. The last design decouples the data from the software entirely. This decoupling permits us to scale the service better. For example, the web server can be replicated to add more capacity.
In such systems we no longer are concerned with the uptime of a particular machine, if it contains only the application code, which is stateless. If one machine fails, the autoscaler will build a new one. If a machine gets sick, we delete it and let the autoscaler do its job.