5 ms·

The biggest difficulty I've experienced is "librification", where some common code ends up in a little library, and soon that library is not so little any more,

The biggest difficulty I've experienced is "librification", where some common code ends up in a little library, and soon that library is not so little any more, and not long after starts to look like half of every service. I can maintain discipline when working on small systems alone, but on a team there will always be one lazy person or urgent need which means eventually some shared component gains enough gravity to start sucking code out of their nice isolated homes Giving up and dumping everything into a monorepo, that's not going to help at all. At that point probably better off just giving up any hope of carefully split up and individually managed services

mewpmewp2 5y ago
I don't get the first paragraph you are saying. This lazy person puts some random code into a shared component, or... ? Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?
- deleted 5y ago
  [deleted]
bhouston 5y ago
These libraries already exist whether you write them or you use someone else's. In our case most of our micro services are node.js based so Koa is in every microservice and we use middleware for authentication -- and thus if the authentication system evolves (moving to JWT or a microservice gateway) we have to evolve that middleware everywhere. Same with our consistent logging system. Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.
- rgoulter 5y ago
  The problem isn't "some code which different services use is in a library". The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it. Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.
slifin 5y ago
This video was interesting to me https://youtu.be/pebwHmibla4 https://youtu.be/pebwHmibla4

mewpmewp2 5y ago

I don't get the first paragraph you are saying. This lazy person puts some random code into a shared component, or... ? Wouldn't this urgent need mean that they put this code into the microservice that needs this urgent update as opposed to going through the effort to make it available for everyone to use?

deleted 5y ago
[deleted]

bhouston 5y ago

These libraries already exist whether you write them or you use someone else's. In our case most of our micro services are node.js based so Koa is in every microservice and we use middleware for authentication -- and thus if the authentication system evolves (moving to JWT or a microservice gateway) we have to evolve that middleware everywhere. Same with our consistent logging system. Libraries are better than unique code everywhere for the same task - allows you to fix a bug once and to do consistency checking.

rgoulter 5y ago
The problem isn't "some code which different services use is in a library". The problem is an not-ideal "the code which is in libraries shared by different services is tightly-coupled to particular services". e.g. changing the shared library might break some service which depends on it. Obviously, you don't want code like that. But it's easy to write code which is slightly coupled; and then when you're in a hurry, to increase the coupling.

slifin 5y ago

This video was interesting to me https://youtu.be/pebwHmibla4 https://youtu.be/pebwHmibla4