> If your software solves a tightly connected business problem, microservices probably aren't the right fit.

If your software solves a single business problem, it probably belongs in a single (still micro!) service under the theory underlying microservices, in which the "micro" is defined in business terms.

If you are building services at a lower level than that, they aren't microservices (they may be nanoservices.)

How do people usually slice a single business problem?