Microservices are not always the answer
Microservices have become the defacto architectural pattern most most organisations both large and small, But is this a good thing?
Updated 6 months ago Published 10 months ago
Before we start, what is the official definition of 'mircoservices'.
Micro-services - also known as the Microservices architecture - is an architectural style that structures an application as a collection of services that are:
- Independently deployable
- Loosely coupled
- Organized around business capabilitiesMicro-services
- Owned by a small team
The micro-service architecture enables an organisation to deliver large, complex applications rapidly, frequently, reliably and sustainably - a necessity for competing and winning in today’s world.
As developer's we always want to build the best solution possible, and to the end we often take inspiration from others and stand on the shoulders of giants.
The concept of Microservices is nothing new and has become a hugely popular architectural pattern for most companies (2023) large and small alike, however throughout my tenure as a developer i've often wondered why the design choice is so prevalent across all organisations.
If your a large multi-national organisation with 20+ engineering teams spread across multiple functions then the idea of decoupled and isolated services is a sound one.
But if your a smaller organisation with a smaller set of multi-functional teams I questions the value of having potentially hundreds of Microservices.
From an design perspective the idea seem's very tempting and rightly so, Teams can iterate independently and have small releases that can be tested in isolation.
But when you look at this longer term the benefits start to become less apparent, when you can many more services than teams most of the services start to become unloved and orphaned leading to operation problems.
You start to loose the domain knowledge around the services and it's function which is often far more important that the actual code within the service. Reading code is easy but understanding it's context often takes a lot more time. Especially if that services is being called by multiple other services that your not aware of.
Now this isn't to say that Miroservices are bad, quite the opposite they are a fundamental design pattern that allow teams to move quickly at scale.
But I think for smaller organisations they are often not the best choice.
Monoliths have become a thing of hatred and in some situations this is more than valid. However they often would service an organisation better than Microservices.
But when I refer to monoliths I'm actually referring more to domain based services where related entities with a related context are grouped together in a singular service.
A lot of the design decisions that I've seen taken over the last 5 years have been geared towards the shiny new technologies and design patterns offered by cloud providers such as AWS Lambda and GCP cloud functions. I love these services just as much as the next engineer but I feel like teams have started to wedge them into every application under sun just so they can get exposure to the services.
Anyway TLDR if your a large organisation with loads of teams then Microservices are the way to go, but if your a smaller organisation then your likely not going to benefit from most of the advantages offered by micro-services and you should pick a more domain based architecture that matches your organisational structure.