As I hear stories about teams using a microservices architecture, I’ve noticed a common pattern.
Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.
This is an article that I should email to a lot of people. Martin Fowler is one of the influential people on advocating microservice architecture, and he also wrote the more formal definition of “microservice” that everyone is using now.
But, as he clearly mentions in this article, the best approach to microservice is to first create a monolith, and then (if the product is successful and there are some scalability problems) you can rewrite your product into a microservice architecture, or you can split some parts into microservices if required.
This is something I have discussed multiple times with friends, and I agree 100% with Martin, and actually I have never found this article, otherwise, I would have already shown them this before having the discussion on monilith vs microservices.