Every Monday I update dependencies. Review breaking changes, get to know what CVEs are out there, glance over changelogs
It takes less than an hour a week. It keeps me up to date on our dependencies
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.
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.
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.
Ideally if there's multiple repos maintenance can be divided amongst those repo's owners, & once you've divided work between multiple people it becomes more valuable to have a tool help maintain process. These tools need buy in, I've found sometimes they'll go ignored & then the list of PRs becomes mixed up with random dependency PRs
It's downright excellent.