There's quite a bit of variability in what people mean when they say "microservice" I've read quite a few articles over the last few years that describe things

There's quite a bit of variability in what people mean when they say "microservice" I've read quite a few articles over the last few years that describe things as I just did. However, you are correct. Most people are unable to get the cruft out of their head, so when they talk about microservices, they mean something like "exactly the way we used to do things, only with a few differences" I was talking to a team last year that wanted to do microservices. They had a framework, a lot of tools, and were busy doing research, most of which consisted of reading fanboy posts and walking through happy-path tutorials. When I started listening to what they were talking about in terms of an architecture? Wow! Too much to go into here, but one of the things was a "microservice" that at the beginning of the pipeline cleaned all the data. Think about that. One "service" which was responsible for knowing every data type, performing all safety checks, and ensuring that all of the other services could run correctly. All in one place. You screw that one up? The whole thing is broken. You couldn't ask for tighter coupling. And this, they thought, was better than a monolithic app. I'm a big fan, but micoservices are going to make a huge mess in the industry that it will take decades to clean up. That's because most people doing them will think of them just as you suggested. (Having said that, the ones who don't are going to run over everybody else in terms of productivity. Good for them and the orgs they work for)