�ֲ���ýapp���°汾

Originally published by New Context.

‍

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. It’s important because of the way infrastructures have changed since the early days of the internet, and it encompasses the critical nature of automation, orchestration, and flexibility.

Putting the idea to practical use requires rethinking traditional infrastructures. Organizations need to eliminate their tendency to rely on one large, monolithic entity—this strategy forces technology leaders to go against their instincts, and culture often will act as one of the most significant barriers. However, if they can overcome that, they can enjoy the increased security and flexibility of modern infrastructures. Here’s how to put pets vs cattle to practical use.

Pets vs. Cattle: An Abridged History

Pets vs. Cattle is not the original analogy; the actual 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. Management styles would depend on the grouping:

‍

‍

While the treatment of pets sounds more positive, it’s the cattle approach developers need to target. After all, cattle are essential; pets are less so. That’s not to say the cattle approach will work all the time. Not everything is disposable, and when an asset isn’t, it requires pet treatment. The goal is to minimize the number of pets and maximize cattle to create an easy to protect and manage infrastructure.

Additions to the “Cattle, not Pets” Analogy

We need to add another important analogy to the mix, and it involves chickens. In 2015, Bernard Golden 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 minimizing 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’s 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. All of this comes together with could-native providers to enable the organization to scale rapidly in both directions (up and down) to meet the demands of the consumer of the application.

Over time, other industry experts 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.

‍

Putting Cattle, not Pets to Practical Use

The practical application of pets vs. cattle centers on minimizing the systems which require individual attention. Automation is a crucial component, as the sheer number of cattle is unsustainable without it. Another is the deployment of an immutable infrastructure.

At first glance, the immutable infrastructure—which cannot be changed—seems counterintuitive to the cattle approach. However, it’s immutable because the server is disposable. If there’s something wrong with it, it’s not reconfigured or patched. It’s replaced with a new server built from a standard image, with necessary changes incorporated.

Patches and updates are an unavoidable reality of operations at scale; they ensure the ongoing security and compliance of the infrastructure. Legacy operations apply these patches in-place, often in a non-consistent fashion, which can result in further issues. Immutable systems move this responsibility to the image creation process, and optimize for replacing the running image quickly, reducing the scope of change to a single, well developed and well tested image that can be deployed repeatedly, and often without interruption to ongoing operations. These systems also cut configuration drift cases, where changes aren’t mapped effectively, making reproduction into a backup or secondary source near impossible.

Infrastructure as code is a crucial component of building these immutable systems. Establishing the IaC code base ensures rapidly configured replacement servers. 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.

Container orchestration is another vital component of the 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.

Essentially, the cattle philosophy minimizes changes to the configuration, breaks programs down to their smallest possible components, and leverages automation to control all these moving parts. The result is an infrastructure that is scalable, secure, and flexible.

Herding Cattle in Your Organization

Organizations shouldn’t eliminate pets in the pets vs cattle analogy entirely. Instead, they can be isolated to instances of absolute need. This strategy ensures administrators can concentrate their efforts on irreplaceable pets while taking a more turn-key approach to disposable assets. Working with a team of infrastructure experts who leverage decades of experience can help you keep your cattle grazing on green pastures.

��

��