Smaller code base

When working on any code base, its size is a detrimental factor in forming an understanding of the application. Given the principle of having a separate team that owns the microservice and its build, test, and deploy cycles, it is logical to maintain a separate repository (Git or any VCS). A separate code repository allows for a smaller code base, leading to reduced code complexity, and also avoids merge conflicts, which pester larger code bases with multiple collaborators.

The small code base brings with it compelling advantages for the developers. Imagine having chosen a tech stack only to realize that it isn't the right stack to use. Sounds familiar, right? Mistakes will be made, and our only hope is to use an architecture that allows us to dispose of the code and redo it using another choice. If your code base is small, then a rewrite is no longer a distant dream. It's easier to squeeze performance out of this code base than try to speed up a larger bundle of code modules put together.

The term micro in microservices doesn't mean less lines of code. Lines of code is a very misleading measure and cannot be relied upon to keep your services small. As discussed in the coding practices and single responsibility sections that follow, there are a few design guidelines that should be followed to keep your services small.