Microservices are bad (for some cases as well)!
One of the most trickiest things to have when dealing with Microservices is that sometimes there are chances to have problems during the communication between services, maybe one of the services is down at the moment, one solution for that is having some replicas for that service (like having PaaS tools like Kubernetes or Docker Swarm to orchestrate your services).
Having said that, it may become difficult to manage large amount of services, especially when some services are dependent to other ones.
One of the hardest things as well is that the testing may become complex over a distributed environment. Sometimes you may create some fake APIs for your testing to unit test your single service, it’s not ideal but it can do the job.
So keep in mind, not all solutions are the ideal ones, there are always drawbacks and challenges to deal with them. Sometimes your problem can be solved in a Monolithic architecture instead of Microservices, maybe you want vertical scale instead of horizontal scale? It’s always about choosing the path and design your system that suits your problem..
Top comments (3)
A nice summary of the design trade-offs to be made when considering the software architecture for a product. For those who may not have discovered it yet, Martin Fowler's excellent website on how to create good software architecture has a section dedicated to microservices, where much detail is available 😄
The way I see it is a complexity/advantage trade off.
Microservices are far more complex than a monolith.
They have advantages too.
Just make sure that you care enough about the advantages they give to justify the price of that complexity.
For Netflix that's clearly the case.
But are you like Netflix?
Basecamp is doing just fine with a monolith.
But are you Basecamp?
Only you can decide.
At Tignum we evaluated the complexity-benefits ratio and decided that a modular monolith was the sweet spot for us.
Exactly, there are always tradeoffs