Often we wonder when we should break monolithic service into micro-service or small services. When is it time to make this change and what will it will take to accomplish.
We all know services should be more cohesive and loosely coupled. While we may have started with that in mind, over time we look back and wonder if it really is the case. Sometimes we end up adding code or functionality that was never meant to be part of particular service. This can happen because of business timelines or because we are in a hurry to launch functionality sooner than other companies.
Are we taking too much time for a small change?
Large services require more risk. We need to be cautious and complete a thorough analysis to ensure a backup plan is ready. With large services, if something goes wrong, it could impact a large quantity of users. These considerations can lead to a slower release cycle.
Are we impacting other functionality every time we release something?
As services have more functionality, making one small change could lead to unexpected changes in other functions that you weren’t anticipating.
Not Enough time to run full test suites?
Building more functionality into a single service could result in hundreds of test cases. Depending on the complexity of your service, running test suites can be fast or they may take hours or days if more complex data setup is required or if not all systems are automated.
Multiple teams making change to same codebase?
Over time we keep adding functionality in existing services and those functionalities may be owned or maintained by separate teams. Every time we need to make a change, one team might not be available, which could delay the functionality release. All teams need to run a regression and make sure the new functionality doesn’t break existing functionalities.
If you run into these issues repeatedly, then it’s time to break them into smaller services.
