3 ms·

A lot of Microservices advocates talk about abandoning DRY to reduce code coupling. I think that's completely impractical and that we should still make heavy u

A lot of Microservices advocates talk about abandoning DRY to reduce code coupling. I think that's completely impractical and that we should still make heavy use of shared abstractions in modules and libraries. If I have a routine in two application services, e.g. a currency converter, and that code has to be changed, I have a few options: With code duplication (Abandon DRY): 1. If the domain demands, I have to change the routine in multiple services and build, test and deploy both of those services in lockstep. 2. If the domain allows, I can change it in one service and build, test and deploy that one service in the short term. The other service will likely need to be updated at some point in the future. This is hard to manage and brings duplication of effort. Without code duplication (DRY): 3. If the domain demands, I have to change it in one shared library and then test and deploy both of the dependent services in lockstep. 4. If the domain allows, I can change one shared library and build test and deploy only the one service that I need to change in the short term. The other service will likely need to be deployed at some point in the the future. Shared libraries are orthogonal to the question of loose or tight coupling. We can have no shared libraries but still have two services which are tightly coupled and chatty. That is the situation we need to get away from, and it is acheived through good DDD and service boundaries, but really doesn't seem to have much to do with shared libraries.

pm90 11y ago
I think the problem comes in when the shared library is used to provide some kind of baseline service, so that if changes are made to the library and 2 services using them are out of sync, then chaos will result. The solution you advocate is correct. Service boundaries need to be well defined and well separated.
- ahallock 11y ago
  > so that if changes are made to the library and 2 services using them are out of sync Wouldn't versioning help with this?
  - pm90 11y ago
    In what way? Versioning helps pin shared libraries so they are not inadvertently updated. However, when you have 2 services A and B using the same library, changes to the library, if they are not updated in both services, may lead to the services being unable to talk to one another. e.g. Suppose service A and B use library L. But the authors of library L decided to rename a certain field in the JSON of HTTP calls that are crafted by the library. Now, unless both A and B update to the new version, they may not be able to talk to one another, so each has to coordinate their efforts to either hold off using the new version, or deploy the new version at the same time.
    - ahallock 11y ago
      > But the authors of library L decided to rename a certain field in the JSON of HTTP calls The API endpoints should be versioned as well. Once all services have been upgraded to use the next version of the API, the previous endpoint can be deprecated.

pm90 11y ago

I think the problem comes in when the shared library is used to provide some kind of baseline service, so that if changes are made to the library and 2 services using them are out of sync, then chaos will result. The solution you advocate is correct. Service boundaries need to be well defined and well separated.

ahallock 11y ago
> so that if changes are made to the library and 2 services using them are out of sync Wouldn't versioning help with this?
- pm90 11y ago
  In what way? Versioning helps pin shared libraries so they are not inadvertently updated. However, when you have 2 services A and B using the same library, changes to the library, if they are not updated in both services, may lead to the services being unable to talk to one another. e.g. Suppose service A and B use library L. But the authors of library L decided to rename a certain field in the JSON of HTTP calls that are crafted by the library. Now, unless both A and B update to the new version, they may not be able to talk to one another, so each has to coordinate their efforts to either hold off using the new version, or deploy the new version at the same time.
  - ahallock 11y ago
    > But the authors of library L decided to rename a certain field in the JSON of HTTP calls The API endpoints should be versioned as well. Once all services have been upgraded to use the next version of the API, the previous endpoint can be deprecated.