Pets vs cattle

In a number of articles on Habré , the separation of servers into "pets" and "cattle" was mentioned . This terminology came from an interesting article by Noah Slater, an open source activist and co-author of CouchDB. I was not able to craft a good translation of the English “cattle”, “animals raised in industrial animal husbandry,” so under the cut you will find a translation with a cattle farm. Very large.



I was one of the developers who created Orchestra: PHP PaaS, which Engine Yard acquired in 2011. Many of our customers used PaaS for the first time, before that they worked with traditional hosting. They had a habit of uploading files via FTP and editing remote configs. These practices are still common, despite the popularity of git and sites like The Twelve-Factor App . The prevalence of such approaches was also supported by the fact that many commercial PHP projects are quite old and imply such a deployment scenario.

No matter how ridiculous it is, traditional system administration focuses on working with physical servers. When a new machine is added to the cluster, it is first purchased, then configured in the office, and only then transported to the data center for installation. Such an operation with the unfavorable position of the stars may take several weeks. And if in the future something happens to this machine, then you will have to make every effort to fix it using SSH. If the location of the stars is not lucky again, you will have to go to the data center personally and deal with the piece of iron in place.
')
This is how I worked with my servers. I still remember these times when I just tried system administration for a tooth and all my servers had cool names like pets. I called them after the characters of the book “Douglas Hofstadter“ Godel, Escher, Bach: This Endless Festoon ”. Turtle was my main Apache server with httpd, Achilles twisted Squid in reverse proxy mode, Crab held MySQL, and Djinn was my SMTP gate. Each machine contained a modified motd with multi-colored ASCII-art and a quote from the book.

I was very proud of how I divided my project into parts. I cherished every car with love. I installed updates on them, set up, tested, and many other things needed in the admin case. In case of problems, I nursed them, returning them to working condition, and carefully wrote down all the steps that I performed. In the event of a fatal breakdown, I could restore them from scratch using these records. When installing a new server takes weeks, you treat them with very, VERY great attention.

In cloud systems, this is not the case at all.

Analog Search

With the advent of virtualization, you no longer need to work with "iron" and go somewhere. In fact, often the simplest solution is to simply nail down the failed server from the administrative console. To then restart it from the server image catalog. Now it takes not weeks, but minutes.
To make this possible, most cloud provider solutions are based on the concepts of “share-nothing” architecture, stateless file systems, automatic repeatable deployments, and so on and so forth. But if you used to use the traditional approach to hosting, then all of these concepts may seem too restrictive to you. For a long time I suffered, trying to figure out how to better explain to my clients the difference in approaches. From a practical point of view, the most difficult thing was to justify why the new method is better.

But at one point, Massimo introduced me to this:


The slide is cut from the Gavin McCance presentation at the CERN conference in 2012. Although, The Register indicates that the original author of the analogy is Bill Baker from Microsoft.

The difference between deploem before and after the advent of virtualization can be compared with the difference between domestic animals and cattle. Pets are given lovingly chosen names, such as “catfish” (in my case “Turtle”, “Achilles”, etc.). They are grown and cared for. They are scaled vertically, becoming larger. And when they get sick, you treat them. With cattle it's not like that. Instead of names, they have functional identifiers like “vm0042”. They are practically identical to each other. They are scaled horizontally by increasing their number. And when one of them gets sick, you simply replace it with another one.

As shown by Massimo, relying on this analogy is very easy to determine - you are dealing with servers such as “pets” or “cattle”. Just ask yourself: what happens if several of your servers become unavailable right now? If this does not affect your users, then congratulations - at your disposal is a herd of cattle. If this leads to a failure in the service - then you are working with pets.

The same principle underlies the template for evaluating your architecture. You look at the server and ask yourself: what will I do if this server is “sick”? The correct answer is: immediately destroy it and replace it with exactly the same. If you're worried about backups, data dumps, scheduled downtimes, or tedious manual configuration, this is a “bell” about the architecture.

However, the post-virtualization deployment model is still relatively young, and many applications will still be needed for a long time. With a complex architecture, you can even live pets and cattle on one server farm at the same time (sorry, I could not resist). It is good that Engine Yard supports both those and those.

about the author

Noah Slater is an Englishman living in Berlin who has been involved in open source since 1999. He has participated in the Debian, GNU and Free Software Foundation. At the time of this writing, he is a member of the Apache Software Foundation. The main project he is working on is Apache CouchDB, a document-oriented database that marked the beginning of the NoSQL movement. He also helps Apache Incubator, teaching participants of new projects how to work with open source.

A picture of a cow taken from here