Micro-services and DRY (Don't repeat yourself)
DRY is one of the basic principles of software which not only programmers but the DBA, technical writers and everyone who is involved in the software building should be aware of. It's proven that when same code is duplicated over various places then it becomes a nightmare to fix all the places where it was duplicated.
DRY can be applied at various places starting from code to database schemas, documentation and more. In this can be even applied to the libraries which are included in the projects, using BOM to avoid not only version collisions but to keep track of all the dependencies at one place.
This was easy when applications were monolithic and changes done in one library was not starting chain of builds and releases. With Micro-service architecture where project is built using various small services and are independent of each other. But what if some code is ported as a library and is included in all the services? A small change in this library will now start the builds and will create release for all the services.
In some organizations this can be a problem if the micro-services are,
- Not covered with Unit test cases and Integration test cases.
- Not deployed using Blue-green or similar deployment
So it's very important to using TDD/BDD approach to make sure that code is well covered with the test cases and deployment allows you to push updates easily without taking any down time.
This can be a major problem as well if Micro-services are using BOM type architecture where all the services are dependent on a core module which defines the libraries those can be used in the project. Now the question is why would someone do this? well, someone can say to avoid mess of libraries and versions used in different micro-services!
But important thing to remember here is that Micro-services are meant to be independent of each other and if these type of restrictions are added on them, you are not leaving the monolithic way of working.