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.
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.