Ken --I had a quick look at the first ref. It offers 2 ways of maintaining consistency. I followed the link to the first method (every time a MS changes its copy of data, it generates an event to notify the other services that use that data so they can update their copies.) That link led to this (emphasis added):
" The event store also behaves like a message broker. It provides an API that enables services to subscribe to events. When a service saves an event in the event store, it is delivered to all interested subscribers. "
So now my MS ecosystem has to include a message broker service!
I am getting the impression that the "simplicity" of MSA depends on a LOT of infrastructure--containers, logging services, orchestration services , health check services, reverse proxies, cache services, dynamic discovery services (this list from the NGINX MSA), and now a message broker.
Now I know that AWS (for example) can provide containers, message brokers, an API gateway, and loggers (at least) but: (1) using these services requires familiarity with a lot of tools/services; (2) in some cases, like the health check and event notifications to maintain data consistency, the approach requires code in each MS; and (3) one begins to wonder if all this interaction--e.g., generating and reacting to all the data-update events--doesn't create a lot of transaction overhead. Maybe it's all worth while to get horizontal scalability, and maybe although it looks like a lot of activity it's still more efficient than the dreaded monolith.
And another thing: AWS and other Public Cloud providers may have implemented all these supporting services/tools, but how would that be done in Private Cloud??
My 2c.
Martin