James Governor's Monkchips

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

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.



  1. Looking forward to the talk. We are working on transforming our SaaS application into microservices so really relevant. Will be great to catch up.

  2. Great article: TL;DR: “Disposability is definitional to microservices.”
    It’s a little provocative but I like it. And IMHO it’s true.

    Something I would like to point out though that didn’t came across for me: The frequency of disposability can be rather high.

    You wrote:
    > If a microservice fails or is superseded a better service, then simply dispose of the old one.

    This sounds like an exception to the norm e.g. there is a bug or you are deploying a new version into production. I would like to add that you could think of a setup where every commit triggers a new build. Which triggers a new deployment to a staging system. Which does a rolling update to the running staging environment. Which kills and deploys new microservices. In this world your microservices would be disposed in a matter of minutes.

    1. @mattias awesome comments well put. i very much agree with you. i have been struggling a bit with dimensions of disposability and immutability, and the interplay between containers and microservices – partly because there is disposability for scaling out, but also functional disposability.

  3. >i have been struggling a bit with dimensions of disposability and immutability, and the interplay between containers and microservices

    As everyone else. 😉

    The great thing about containers is that it is making microservices concrete. BTW: We are start collecting some concrete petterns here: http://bit.ly/container-patterns

    Would love to hear your thoughts.

  4. […] James Governor analyses the very reason Micro Services should be created (and killed) from the perspective of disposability. […]

  5. […] map a volume from the VM into the container. That convenience typically turns the VM into a “pet” and forces you to track what files were written to what VMs. It also makes it impossible to […]

Leave a Reply

Your email address will not be published. Required fields are marked *