A Note On Microservice and Shared Library Complexity

As I have alluded before; for me, the objective behind using Microservices is not actually scalability. That is just an additional benefit. I use this approach to keep my application code concise, decoupled and easier to debug and maintain.

But, there is one area which can get out of hand if managed improperly (or not refactored over time). And that is the shared library or libraries.

By splitting your codebase into multiple services you are more likely to have code which would be duplicated if not stored in a common location and THAT code is one of the biggest threats to a Microservices architecture in my opinion. 

Just because we are splitting things out does not mean that we want to start duplicating code in each of those new services. The simple solution (and it can work if the overall project is, and remains, "small enough") is to simply throw everything into a single "Common" library. 

As the project grows though, this common library will as well. At which point it can become a monolith in its own right.

I would typically recommend the following instead: Create a set of common libraries split by domain. Things like auth classes don't need to be mixed with base classes for your services. And those don't need to be mixed with base classes for localization, etc... Push those to NuGet (or an equivalent service based on your needs) and create a meta-package.

Similar to my advice on creating a common set of docker compose files to use as a meta-package for your services, you will want a meta-package for your internal dependencies. A topic I'm on the fence on would be including 3rd party dependencies in this meta-package. The advantage is that updates can be managed in one place then. And individual microservices can, in theory, decide when they take an upgrade and run the risk of breaking changes.

On the other hand, in the real world, a change in a core library can sometimes be a required update even if it contains no breaking changes. It also increase the bloat in the final image. A better approach might be a separate meta-package for 3rd party libraries broken up by team or microservice. This can introduce conflicts though. So, I think an all or nothing approach is better on the 3rd party library front.