>As a simple example, imagine a small team of, say, 6 developers:
>
>The team has created and now supports a mobile app, an Alexa skill, three separate web apps, fifteen microservices, and a partridge in a pear tree.
If a team of 6 developers created 15 microservices, I'm afraid that they don't understand the pros nor the cons of microservices and they should be fired instantly.
Too be fair I did the same thing 2 years ago and I'm sure I'm not the only one. Drank to much microservice koolaid and ended up with 12 services. Consolidated it down to 7 once initial micro high wore off
How does "number of microservices" correlate to "complexity of your infrastructure"?
I'd also note that the OP had no concept of time in it - it didn't include a timeframe, so we aren't capped by developer man/work-hours.
If we are talking instantaneous support, there is no telling how this correlates - one complex microservice may be too complex for many devs, or many microservices simple enough o be supported by just one.
If we are talking about about either development hours, or code-familiarity, then I'm not sure how we are capped - are we going to limit the number of LoC a dev can write, repos they commit too etc, as well?
Six full time developers who wrote 15 microservices that each do one thing well should not be fired. The burden of microservices lies in the underlying infrastructure required to host them. So, assuming we have a competent infrastructure engineer, devops engineer, security engineer, site-reliability engineer, and a handful of other hats being done well... your six developers can write and maintain far more than 15 microservices assuming that each service has a clearly defined single-objective scope.
Because infrastructure complexity <> Software development complexity.
If a team of 6 developers created 15 microservices, I'm afraid that they don't understand the pros nor the cons of microservices and they should be fired instantly.