Pets vs. cattle is an analogy with modest beginnings that has grown into an industry staple. A simple Google search will spawn more than four million results and a myriad of developer memes.  Although origin stories are a little hazy, the actual, original quote was ‘cattle, not pets.’ Microsoft engineer Bill Baker used it during a discussion about SQL deployments to explain how server treatment changed over time. 

At its heart, the illustration is simple: it is based on considering how much bandwidth a farmer puts into caring for a cute pet like a puppy or kitten, versus how much care goes into maintaining a herd of cows on a farm. 

The puppy will get all the trappings of individualised attention, like a name, toys, tasty food and treats, and specialised medical care when they are sick or injured. 

On the other hand, cattle typically do not have names and they do not require the same level of nurturing and attention as the puppy. 

The two sets of animals are equally essential to the farmer, but for different reasons. There are different levels of emotional attachment, financial return, and senses of purpose for the two categories. And most critically, for the purposes of this analogy, the level of maintenance differs wildly.

Applying this idea, management styles of servers would depend on the grouping:

Pets: Servers get unique names and special treatment – when they are ‘sick’ they are carefully nursed back to health, often with a substantial financial investment and allocated resource. There is an undoubted preference for keeping the server as it is, or at least in the healthiest version.

Cattle: Servers are part of an identical group and numbered, not named.  They receive no special treatment and when they go wrong, they are replaced rather than repaired in place. They are inherently a commodity and treated as such.

The analogy has received a lot of recent attention because of the way infrastructures and management have changed since the early days of the internet. 

The dominant force in this change has been the issue of scale – as businesses have grown, as well as more complex consumer demands taking hold, the need for cloud infrastructure has increased massively. This has led to a huge jump in the management burden of those resources and a need for streamlined processes to handle this technological estate.

At the same time, organisations have realised the need to eliminate their tendency to rely on one large, monolithic entity. Aside from forcing technology leaders to go against their instincts and overcome significant cultural barriers and ideas of ‘this is how it has always been done’, this move away from one core technological entity has meant even more server requirements. 

This has been driven by the desire to enjoy the increased security and flexibility of modern infrastructures. Thus, in the case of the business drivers behind revisiting pets vs. cattle, we can see there is a lot at stake – scaling for growth, better processes, and lower cost profiles for new revenue streams – if technology leadership can figure out how to handle the server farmyard.

Making the decision

Developers have had to realise that while the treatment of pets sounds more positive, it is the cattle approach that they need to target. The cold, somewhat harsh truth of business is that cattle are essential; pets are less so. The good news is that a cattle-centric view yields substantial results, quickly.

This is not to say the cattle approach will work all the time. Not everything is disposable, and when an asset is not, it requires pet treatment – and the methodology for assessing such assets is reasonably straight forward, borrowing heavily from cyber security best practice. However, for any enterprise, the goal is to minimise the number of pets and maximise cattle to create an easy way to protect and manage infrastructure.

The practical application of pets vs. cattle centres on minimising the systems which require individual attention. Establishing the right business rules and then employing automation is a crucial component, as the sheer number of cattle that will result from a company undergoing rapid growth, is unsustainable without these tools.  

These rules are based on the DIE principles of ensuring the infrastructure is distributed, immutable, and ephemeral.

Why cattle need (to) DIE

Long lived cattle are dangerous because a business does not and should not support them like pets. The role of the DIE strategy is to ensure that even at scale, with large numbers of cattle servers, a business has not increased the attack surface of the infrastructure.

Obviously, large numbers of servers need to be distributed to improve the management of scale. From a scalability perspective, distributed architectures help to meet fluctuating demand for services, while also decreasing downtime.

But from a security standpoint, distributing software and infrastructure across large environments can make things much trickier. In a distributed environment, a business has more moving pieces. 

This is where immutable containers in infrastructure can help provide trust. They cannot be changed in production, and if they change later, a business can delete them immediately and redeploy with a known good state. Consequently, the attack surface shrinks, and an adversary has less ability to infiltrate a given system.

The benefits of being ephemeral – that is to say, temporary, and dynamic – are that the servers allocate resources from a pool and when those instances are terminated, those resources are freed and go back into that pool until they are needed again. This is not just an operational benefit – the enterprise can avoid the investment and depreciation schedule that comes with establishing new applications on expensive, new hardware.

Drilling into the immutable

At first glance, the immutable infrastructure – which cannot be changed – seems counterintuitive to the cattle approach that sees rapid swapping out of old assets. The key is standardisation. If there is something wrong with a server, it is not reconfigured or patched. It is replaced with a new server built from a standard image  – a core template  – with necessary changes incorporated. It can be thought of as cloning the cattle but making improvements with each iteration.

Just as a side note, patches and updates are an unavoidable reality of operations at scale; they ensure the ongoing security and compliance of the infrastructure. However, legacy operations apply these patches in-place, often inconsistently, which can result in further issues. It is ‘pet’ behaviour when the far better outcome (for the business) may well be simple recognition of the commodity function of the asset that would be patched and opting for replacement.

Immutable systems move the responsibility for this ‘standardised evolution’ to the image creation process and optimize it for replacing the running image quickly. This reduces the scope of change to a single, well developed and well tested image that can be deployed repeatedly. Critically, this is often without interruption to ongoing operations. These systems also cut configuration drift cases, where changes are not mapped effectively, making reproduction into a backup or secondary source near impossible.

IaC

Infrastructure as code (IaC) is a crucial component of building these immutable systems. Establishing the IaC base ensures rapidly configured replacement servers and accessible IaC repositories are essential. 

Users should be able to understand the code provisioning to troubleshoot problems and run applications. IaC also helps eliminate the need for extensive documentation. Changes are visible within the code itself. Excessive or dated documentation increases error risk, so this is a definite benefit.

Essentially, however it is manifest that the cattle philosophy minimises changes to the configuration, breaks programmes down to their smallest possible components, and leverages standardisation and automation to control all these moving parts. The result is an infrastructure that is scalable, secure, and flexible without needing lavish amounts of attention on specific assets that also create likely points of failure.

Expanding the farmyard – additions to the analogy

We need to add another important analogy to the mix, and it involves chickens. In 2015, Bernard Golden, software guru and founder of the Emerging Tech Academy, used this concept to describe the containers necessary in such a flexible environment. 

Chickens, unlike cattle, are small and require little space. That means you can use a lot more of them while minimising the resources they consume. On top of that, chickens have much shorter lives than cattle. Cluster (cattle) instances have lifespans of days. The longevity of containers (chickens) is measured in minutes.

There is also a speed element involved. Physical servers take the longest amount of time to provision and configure, followed by VMs (with appropriate automation in place) and then Containers. The closer you move to a well-architected container model, the faster it is to remove and replace one of the components. And speed will typically equate to agility and time to market.

Container orchestration is another vital component of the practical cattle environment, as microservice architectures require the deployment of granular level services. This process allows teams to automate tasks related to provisioning and deploying containers, allocating resources between them, and monitoring their health. It is – almost – entirely hands off farming or management.

All of this comes together with cloud-native providers to enable the organisation to scale rapidly in both directions (up and down) to meet the demands of the consumer of the application.

Chickens, unlike cattle, are small and require little space. That means you can use a lot more of them while minimising the resources they consume. On top of that, chickens have much shorter lives than cattle.

Herding cattle in the organisation

Over time, other industry experts have added their own entities to the cattle, not pets analogy. Insects may be used to refer to a serverless environment that makes use of ephemeral applications and services. Snowflakes was a term coined to describe highly delicate, detailed servers that developers try to avoid. All these additions serve a single purpose: to help developers put the analogy to practical use.

Organisations should not eliminate pets in the pets vs cattle analogy entirely. Instead, they can be isolated to instances of absolute need – and technology is still awash with many examples of where such assets exist. 

However, the above strategy also ensures that where administrators must concentrate their efforts on irreplaceable pets, they can take a more turn-key approach to disposable assets.  It also forms a natural point of outsourcing – working with a team of infrastructure experts who leverage decades of experience can help a business keep its cattle grazing on technologically and economically green pastures, while the in-house team keeps the pets in the best of health.   

Daniel Riedel, SVP, strategic services, Copado