What If a Farmer Wants To Do DevOps?

A farmer who owns and breeds animals in his farm doesn’t treat them all the same way! There are Pets that live with the family. The dogs and cats have their names, They are unique, lovingly hard raised and cared for. If they get sick, He will bring them to the veterinarian.

On the other hand, cattle in the pasture are almost identical to other cattle. They are given numbers. When they get ill or the business grows, he will get some more.

The same analogy applied to IT infrastructure. The “Pets vs Cattle” concept was first introduced by Bill Baker (Microsoft) and later by Gavin McCance (CERN).

Pets Service Model

In the pets service model, each pet server is given a loving names like (Greek gods, planets or beer if you work in Germany ;). They are “unique, lovingly hand-raised, and cared for, and when they get sick, you nurse them back to health”. You scale these up by making them bigger (more CPU, memory, storage…), and when they are unavailable, everyone notices.

Here is some funny server naming schemas If you are looking to have some more pets in your datacenter.

Cattle Service Model

In the cattle service model, the servers are given identification numbers like (web1, web2…), much the same way cattle are given numbers tagged to their ear. Each server is “almost identical to each other” and “when one gets sick, you replace it with another one”. You scale these by creating more of them, and when one is unavailable, no one notices.

A Farmer In The Datacenter

Once you have that analogy in mind, it’s easy to determine whether you’re dealing with pets or cattle. Pets servers are mainframes, load balancers, firewalls, database servers … that we need to take care of (resource scaling, software update, security batches…) and if they go offline, the end user will notice it!

Even when we have server virtualization, we tend to treat the virtual machines as pets. We deploy applications on VMs and suppose to keep them online forever!

The DevOps Framer

The farmer in the post-virtualization model will treat the infrastructure resources differently. One important principle of DevOps is automation.

Automation as practices of automating and integrating the processes between software development and IT teams, so they can build, test, and release software faster and more reliably, can be applied on the infrastructure as well.

Let’s present the evolution of cattle service model chronologically

(1) Bare-metal

In the age of bare metal racked-mounted servers, admins used to create virtual machines on top of the physical infrastructure. Beside Bash and PowerShell, change configuration tools like Puppet (2005) and Chef (2009) allowed operations to configure fleets of systems using automation.

(2) IaaS

The cattle service model has evolved from bare metal servers age to the Infrastructure as a service model. Both public cloud (like AWS or Azure) and private cloud like OpenStack expose the compute, storage and networking resources via API.

Ansible (2012), and Terraform (2014) are examples of tools allowed you to coordinate state between the cloud provider and your application, and essentially allow you to program infrastructure, a pattern called Infrastructure as Code.

(3) PaaS

After infrastructure virtualization via automation, we started to virtualize operating systems (processes, network, memory, file system). This allows applications to be segregated into their own isolated environment without the need to virtualize hardware, which in turn duplicates the operating system per application. Linux Containers or LXC (2008), and Docker (2015) are implementations of the PaaS concept.

(4) Immutable Production

The introduction of containers became explosive with Docker becoming an ecosystem by itself. A new set of technologies evolved to allocate resources for containers and schedule these containers across a cluster of servers: Apache Mesos (2009), Kubernetes (2014), Nomad (2015), Swarm (2015).

Conclusion

We developed gradually from mainframes to Kubernetes Pods. The cattle service model is solution to deal with thousands of services running within your cluster. You define the deployment in a declarative language like YAML and tell the orchestrator what is your desired state. You define strategies to deal with failing services and replace them with new ones. You see they are now all cattle. Each service is “almost identical to each other” and “when one gets sick, you replace it with another one”.