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.
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.
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.
And this would possibly be automatic so to you it may merely be a minor datapoint in your monthly cloud usage report.
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.
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.
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.
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.
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.
Unless otherwise specified, all content is licensed under Creative Commons by Attribution 3.0 (CC-BY).
Externally linked images and content are not included and are licensed and copyrighted separately.