It’s a common discussion when implementing a new set of features whether to have it as part of an existing application or to split it in another process/codebase. So in this post I’ll record the benefits of microservices that I think of when this conversation is brought up.
First when I have to say what the term “Microservices” means to me to make sure we’re talking about the same thing.
What I mean by microservices is organizing a system in :
Having said that the benefits of this approach over any other is as follows:
Facing a bug will be easier to fix. as spotting the service responsible for the error can be discovered from the logs of each service and having each service responsible for a clear small scope will make it easier to spot the service that needs to be fixed.
Fixing a small project that has 10 to 20 files of code and built over a week is way easier than fixing a project that has hundreds of files and dozen modules.
As the turn over of startups is high. there is always a time where new developers reject the old code out of complexity. Having the service built by one or two people over a week makes it easier to re-implement by any new developers if they wish. lowering the cost of renewing parts of the system with a new programming language or a new algorithm is easier as the service scope is fixed.
As the service takes one or two people a week that means they can use any programming language they want. as in the future if new developers doesn’t know this language or doesn’t like it means they can easily re-implement it in a short period of time.
As the organization restructure and evolve and expand we need to redefine teams boundaries and responsibilities. having the code split to smaller services as described makes it easier to move services ownership between teams. that’s nearly impossible to do when maintaining monoliths without significant restructuring.
Having the code in one monolithic codebase makes it tempting to reach for any module and use it ignoring the structure or the project for the uninformed developer. Having codebases separate means using another part of the codebase an explicit decisions with realized consequences.
As the system evolve some services loses its benefit and is doomed to be retired. it’s easier to shutdown a service that’s not needed anymore. just turn off the process and archive the codebase. in monolithic implementations that is way too complicated. it involved untangling parts of the code and deleting modules and making sure no other module is assuming the existence of that part of the code. it’s a mess.
As each codebase is separate. two teams can develop two different parts of the system without stepping on each other toes. just agree on a contract/API/Interface and each of the teams can go and develop their services.