Monolithic vs Microservices systems is now a hot topic that a product manager will probably encounter when they tune their interface with the development team.

What is a monolithic system?

In a nutshell, your system is called a monolith when you have all components like authentication, authorization, product catalogue.. etc in the same codebase.

What is a microservices system?

Instead of having a single codebase that has all your components, you have a web of individual codebases and individual services that work together to deliver the application.

Usually, when you move to microservices, the importance of testing goes up dramatically because instead of having a single codebase when you do a change and you want to validate that change, you can do it manually fairly easily. Now you have a web of services that need to work together and coordinate themselves to be able to deliver the service to customers, and that becomes incredibly difficult to test as you have to run a lot of different integration tests to be able to guarantee the service stays up and running.
So with a microservices architecture, your need for automation and for a greater and greater amount of test coverage go up exponentially.

When to go for a monolithic vs microservices architecture?

It all depends on the maturity of your product, codebase, development team and your market fit.
So if you are just getting started out and you have a greenfield application that you don’t really know if it is going to work and you don’t have a product market fit then 99% you are best off building a monolith!
And the reason for that is that you are making changes only to one place and you don’t have to worry about the overhead related to testing or the overhead related to logistics and orchestration. You can just make the change and push it, observe and see your customer reaction and then keep moving.

As your product grows, these are the main points that you need to watch out for to decide whether to move your monolith into a service oriented architecture:

1. You find a product market fit and your product starts to mature
2. Your codebase gets bigger and your test volume get bigger and slower
3. When you change something in your codebase and something in a completely unrelated part breaks as the result of your change

At this point, you need to start thinking how to pull your product pieces apart so you can pick up speed again. You can start with pulling out your authentication service, and once you start to get some of speed and agility back into your process, you can go from one service to ten of services quite quickly. If you can do that, it means you are mature enough to be able to deal with the increased architectural and testing complexity of a microservices architecture.