The Wikipedia article isn’t too bad: https://en.wikipedia.org/wiki/Microservices

One aspect where I think it is accurate is that “microservices” is an architectural approach of how to modularize an application into services, as opposed to a clear-cut definition of whether a given single service qualifies as a “microservice”.

It hinges on "loosely coupled", which is also a problematic definition. Almost nobody with experience intentionally makes something "tightly coupled" without cause, and coupling often depends on one's view or estimation of likely future changes, because if one tries hard enough they can conceive potential future changes that will "break" any interface or abstraction. I've done it many times in debates where somebody claims their interface is "loosely coupled". Coupling scores are often based on untested presumptions. I've even tried to categorize the kinds of assumptions found in such discussions to narrow down the conversation, but my categories didn't catch on. However, objectively remains elusive either way.

I don't intend to "be a jerk" in such debates, it's just that way too many software engineer terms are ill-defined or tied to subjective assumptions. The Emperor has ambiguous clothes.

As far as microservices, explicit examples of what is and what isn't would help. About the only mutual agreement is the problems of creating "one big executable" when it should be split into multiple. But that issue has been around since the dawn of executables. It's older than me, and that's friggen old. It also wouldn't apply to many dynamic languages such as Php, where a script file can be swapped out or updated without any recompiling. Does that make a Php app with 100 files have "100 microservices"?