> A service with its own data store This is the only valid definition. If you don't have separate data stores, you don't have a microservice. You have a mess

> A service with its own data store This is the only valid definition. If you don't have separate data stores, you don't have a microservice. You have a mess that will break. > Problem Three: Microservices Without Organizational Change Is Pointless Also 100% correct. Microservices only work if the only necessary coordination between teams is an API. If you have to coordinate deployments or other work with another team, you've broken the model. Now, that's not to say that you can't help another team add an API call to their service to make your own service easier to run. Or that you can't coordinate feature development across teams. But at the end of the day, each team needs to be able to deploy or roll back independently of what any other team is doing. It needs to work as if every team is another company who they can only loosely coordinate with (hence the term loosely coupled). OP is certainly right here, microservices are a means to an end, not an end.