Microservices are cattle not pets

Shed no tears when quickly culling services.

I tweeted a few years ago that microservices are cattle. It is an advice I give to developers to not be precious about any microservices that they may have been involved with.

With clouds servers are cattle not pets. With microservices the services are cattle not pets. Shed no tears when quickly culling services

— Ivar Abrahamsen (@flurdy) April 17, 2016

Cattle or pets

Servers are cattle, not pets - Randy Bias

It is thought the server cattle analogy was first mentioned around 2012 by Randy Bias. Whom in turn was influenced by Bill Baker’s “Scale out not up”. Randy elaborated in 2016 a bit about the analogy’s background and history.

Pet servers

In essence in earlier times with co-located servers you knew each of the servers’ names, maybe even had a charming naming policy, and you would be upset if something happened to them. You maintained and fixed each server over a long period of time.

I.e. a pet.

Photo by Katlene Niven. CC by

Cattle servers

However if in a modern cloud virtual environment where you scale out horizontally, massively, you would not really care if mail-server-238 had an issue. You would simple mercy kill it and instead add a few more instance nodes in seconds. And not be upset by it at all, it is just work.

I.e. cattle.

And this would possibly be automatic so to you it may merely be a minor datapoint in your monthly cloud usage report.

Photo by AFP

Monolithic pets

As with servers, larges applications and services, often described as monoliths, are treated as pets.

Teams defend it and tinker with it for years. They polish it, they care for it and do not ever want to give it up. They extend it, morph it, modernise it, and add more and more features to it. They fix bugs, they even acknowledge problems with and work around it so the application stays alive.

I.e. a pet.

Photo by George E. Koronaios. CC by-sa

Precious microservices

Unfortunately that attitude also transcends to applications in a microservices architecture. Even more if they are not pure microservices but more mini-monoliths.

But developers still have affinity to what they create, so they may treat microservices as pets as well.

Don’t.

Photo by Jon Pinder. CC by-nc-nd

Microservices are cattle

Treat microservices as cattle. Microservices are meant to be small, easily rewritable and replaceable. And therefor easily deletable.

Do not try to resist deleting them because you put a lot of effort into it. Do not be precious about tiny bits of code. Be cold.

If not needed, do not shed a tear. Cull it, move on and iterate onwards.

Be cold to others

And treat code and microservices written by others with the same ruthlessness. Sure, talk and ask others before deleting it, but do not save any gunpowder. Kill any services that are superfluous.

And if others delete a service you worked on a lot, be magnanimous and supportive.

License unknown

Not clones

A difference however between microservices and cloud based servers is that servers are numerous horizontal clones, whilst microservices are numerous but individual services.

So there is not a order-48 service, but perhaps a receive-order, retrieve-order, cancel_order service or however you split and define, and name your services and context.

Photo by University of Nottingham

Don’t morph, kill & replace

If suddenly your team realised that they no longer need to get an order directly but they instead need to search for orders, don’t hesitate to delete retrieve_order and launch a new search-for-orders service.

No need to make it temporarily do two things, and 2 years down the line, after lots of iterations, retrieve_order now also makes coffee.

And no need to keep retrieve_order around just in case. Sure, the source code may exist as e.g. an archived Github project for instance, but get rid of all infrastructure immediately.

Great herder & gardner

If you keep trimming, deleting and keeping only the bare essential microservices, your project, architecture and infrastructure has a much better chance of being a solid, evolving and successful product for years.

Photo by Malcolm Morley. Public domain