3 ms·

Sounds like you might be understaffed.

pavel_lishin 3y ago
It's microservice land! Most of those services are no longer in active development, and nearly all of them support a single actual product. In my opinion, we split them to aggressively at the start - expecting some of them to be used by other people in the company, as a service type of situation - but that never happened. I argued for combining several of them - they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. But it was never particularly urgent.
- vlovich123 3y ago
  Yup. Those “no longer actively developed” services should probably be rethought. Your carrying too much dead weight for the team size if updating the dependencies is “too much”. You’re just papering over the issue if you’re relying on automated tools to do basic book keeping for you.
- zer00eyz 3y ago
  >> they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. Make that step 4 or 5. Mono repo them first! Yes you will have to build some tooling to do this but it gives you a way to test the concept. The moment that you have to change 2 of them with any degree of coordination you will get a 10x pay back.
- devjab 3y ago
  Why wouldn’t you just bundle your shared dependencies in libraries so you would only have to update them in one location anyway? We put all our shared utilities into service libraries which are injected into our microservices when they are build. Since the APIs they consume are build to be non-breaking on changes, any external packages that get updated will only need to have their breaking changes solved in one location. 95% of our changes are done by renovate. We rarely have to deal with breaking changes on anything backend related, though the frontend is a different story. But our frontends aren’t exactly “microservices” anyway, and they are always very much in active development. I build a couple of services which collects a gazillion tonnes of solar inverter data from various plants over the world, and then does some fancy ML magic to figure out which solar cells need cleaning, and it has run for years with automated dependency updates with nothing breaking because of how it was build from the start. I get that if your microservices are really just a bunch of tiny monoliths then it’s hell, but then you should probably prioritise your suggestion of merging it together somehow.

It's microservice land! Most of those services are no longer in active development, and nearly all of them support a single actual product. In my opinion, we split them to aggressively at the start - expecting some of them to be used by other people in the company, as a service type of situation - but that never happened. I argued for combining several of them - they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. But it was never particularly urgent.

vlovich123 3y ago
Yup. Those “no longer actively developed” services should probably be rethought. Your carrying too much dead weight for the team size if updating the dependencies is “too much”. You’re just papering over the issue if you’re relying on automated tools to do basic book keeping for you.
zer00eyz 3y ago
>> they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. Make that step 4 or 5. Mono repo them first! Yes you will have to build some tooling to do this but it gives you a way to test the concept. The moment that you have to change 2 of them with any degree of coordination you will get a 10x pay back.
devjab 3y ago
Why wouldn’t you just bundle your shared dependencies in libraries so you would only have to update them in one location anyway? We put all our shared utilities into service libraries which are injected into our microservices when they are build. Since the APIs they consume are build to be non-breaking on changes, any external packages that get updated will only need to have their breaking changes solved in one location. 95% of our changes are done by renovate. We rarely have to deal with breaking changes on anything backend related, though the frontend is a different story. But our frontends aren’t exactly “microservices” anyway, and they are always very much in active development. I build a couple of services which collects a gazillion tonnes of solar inverter data from various plants over the world, and then does some fancy ML magic to figure out which solar cells need cleaning, and it has run for years with automated dependency updates with nothing breaking because of how it was build from the start. I get that if your microservices are really just a bunch of tiny monoliths then it’s hell, but then you should probably prioritise your suggestion of merging it together somehow.