Say NO to a shared “custom” library in Microservices
The life of a software developer is already difficult. Why would you make it even harder by tight-coupling MicroServices 😛 ?
We were building a project (MicroServices) from scratch and we had the requirement to implement an authentication/authorization mechanism for all REST APIs. We had total 5 MicroServices when a proposal was made to support authentication using a shared custom library and this proposal was accepted! 😮
Before looking at the consequences of this decision, let us first understand, what a shared custom library means, and what is its impact on Microservices based projects.
A Shared Custom Library is a collection of project-specific code serving multiple features, needed by multiple microservices, and is injected into different microservices to support shared custom features; (like in my case, it was authentication, code snippet generation, etc)
Microservices is an architectural style that structures an application as a collection of services that are
1. Highly maintainable and testable
2. Loosely coupled
3. Independently deployable
4. Organized around business capabilities
5. Owned by a small team
Now, considering the above 2 definitions,
1. Can we say that the above Microservices are loosely coupled ?
[Loose coupling is an approach to interconnecting the components in a system so that those components depend on each other to the least extent practicable]
- Not really! Any changes made to the custom library to support the needs of 1 of the microservice will directly impact other microservices as it is the same module that gets injected into all the components
2. Can we say that each microservice is independently deployable?
Not really! Build failure of the custom library will lead to the build failure of all other microservices thus becoming a Single Point of Failure! Also, if custom library is updated to support a feature in 1 microservice, then it becomes a mandate to ensure other microservices also support and consumes the latest version of the custom library. Only then, it can be deployed.
So are we defeating the purpose of microservices by tightly coupling them using a shared custom library? Probably YES!!
Let us consider another aspect…
Microservices are loosely coupled and only communicate via language-agnostic way with each other.
In MicroService architecture, it is allowed to develop microservices using different technology stacks as per the project needs.
In my case, all 5 microservices were developed using TypeScript and the authentication mechanism in the custom library was also implemented using TypeScript. Everything was working fine until we developed the 6th Microservice using Python! This is when we could no longer use the authentication mechanism developed in TS to support REST APIs developed in Python! 💥💥
Hence, we had to rework the authentication mechanism by extracting it into a different microservice instead of a shared custom library thus breaking tight coupling between all the Microservices.
Apart from the above-mentioned cons, with the shared custom library, it also becomes difficult to test and detect regressions introduced due to any changes in the custom library. It also unnecessarily adds to the size of the microservice as it may contain few features which may not be needed by other microservices.
Based on the observations, I think, we should refrain from using any custom project-specific library across multiple microservices thus eliminating tight coupling and single point of failure.
