Microservices and Disposability: On Cattle, Pets, Prize Bulls, Wildebeests and Crocodiles

Treat this post as a preview for my session at Dreamforce next week – Composability, Adaptability, and Disposability: RedMonk on Microservices. If you’re there you should come!

A few months back Darren Shepherd, one of the cofounders of Rancher Labs, was visiting my coworking space to hang out with Weaveworks, another Docker ecosystem startup. We were talking about containers and microservices, when I had an epiphany – while improved infrastructure disposability is a significant reason for adopting containers, it is actually definitional to microservices. So a Shepherd from a company called Rancher helped me better understand the now commonly used Cattle vs Pets distinction. You really can’t make this stuff up.

Like many others I had already been introduced to the Cattle vs Pets distinction by Adrian Cockcroft. See this excellent presentation by Randy Bias if you haven’t previously got the memo)  or if you prefer words Bernard Golden sums things up well (with added chickens!)

Traditional infrastructure is expensive and individuated — we give servers names, we lavish attention on them, and when they suffer problems we do evaluation, diagnosis, and nurse them back to health via hands-on administration. In other words, we treat them as part of a family. This is true whether the server is physical or virtual; they are long-lived and stable, and therefore deserve personal attention and emotional attachment — just like a pet.

By contrast, cloud infrastructure is treated as transitory and disposable; due to the highly erratic workloads typical of cloud applications, virtual machines come and go, with lifespans measured in hours, if not minutes. Because of the temporary nature of cloud infrastructure, it’s pointless to get attached to specific resources; therefore, cloud servers more nearly resemble cattle rather than pets. In other words, instead of getting attached to a cloud server, it’s better to view it as a disposable resource, temporarily used and then discarded. And, unlike a pet, one does not think of a steer as part of the family and nursed to keep healthy.

Disposability has been a long time coming – I remember the aha when I first heard how Google dealt with hardware failures – by simply throwing out the offending boxes every once in a while, with no need to do anything immediate. At Google the software architecture meant that hardware became disposable. Today that architectural idea(l) is becoming a core design principle for Cloud Native software – 12 Factor Apps. Everything should be disposable. Except of course the data… Apps are like fish, but data is like wine. Stateless apps still require a persistence layer.

One of the current industry terms we’re using for this approach is “immutable infrastructure”. One of the biggest problems in managing infrastructure is dealing with configuration sprawl – “old systems grow warts”. So instead how about never changing the image. When it doesn’t work throw it out and create a new image, rinse and repeat. Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components.

With microservices we’re dealing with disposability at a different layer of the stack, but the pattern is the same. As Stephen argues the key to the current container frenzy is that the Atomic Unit of computing is now the app.

The explosion of Docker’s popularity begs a more fundamental question: what is the atomic unit of infrastructure moving forward? At one point in time, this was a server: applications were conceived of, and deployed to, a given physical machine. More recently, the base element of an infrastructure was a virtual recreation of that physical machine. Whether you defined that as Amazon did or VMware might was less important than the idea that an image resembling a server, from virtualized hardware and networking interfaces to a full instance of an operating system, was the base unit from which everything else was composed.

Containers generally and Docker specifically challenge that notion, treating the operating system and everything beneath as a shared substrate, a universal foundation that’s not much more interesting the raised floor of a datacenter. For containers, the base unit of construction is the application. That’s the only real unique element.

So microservices must to be disposable. If a microservice fails or is superseded a better service, then simply dispose of the old one. With Cloud Native apps there is safety in numbers, rather than “high availability” failover across two nodes – the crocodile may take out out one wildebeest, but the rest of the herd keeps running.

If you’re interested in digging into these concepts please join us at Dreamforce next week.