> I wonder if this a factor in making onboarding of new hires difficult?

Surely it's because they focused on making onboarding easy?

New hires just make a new microservice for every task they get, don't need to know the broader scope just the specs for the service.

It's hard to make code changes without understanding the broader scope.

For example, a developer asked to change the payments processor from the Stripe API to the Adyen API needs to know about:

1) credential scoping across microservices and test environments 2) impacts on billing, tax management and customer support 3) the organisation's approach to external dependencies (e.g do they use some kind of internal registry)

Microservices don't inherently make this kind of change more difficult. A well isolated payments microservice might even help. But having hundreds or thousands of microservices spread across several code repos makes it quite difficult to figure out how your change will affect other services.

I acknowledge I've picked an extreme example that wouldn't be asked of a new hire. However, smaller versions of the same challenges will happen in the smaller API upgrades & migrations that make up a big part of what the average CRUD developer does.

My point is with microservices you can, in theory, write all that stuff in a spec, and hand it to some new kid on the block. They then don't need to know about billing or what not, you've taken care of that in the spec.

Not saying it's a good way, but it's one way to end up with an inordinate amount of microservices per dev.

> > There's over 30 microservices in our org to every 1 engineer

> I wonder if this a factor in making onboarding of new hires difficult?

Not so much that but a culture of rapidly reconfiguring the whole organization around new product work every three sprints and no ownership/responsibility for maintaining prior work.

It almost seems obvious what would happen.