Those are well articulated problems that people working with Microservices are very concerned with solving. I agree that there is a technology hype-cycle but I

Those are well articulated problems that people working with Microservices are very concerned with solving. I agree that there is a technology hype-cycle but I think what actually tends to happen is that the best parts of existing solutions (eg in this instance "SOA") get re-thought from the ground up. Each time we keep more and I think Microservices are a step forward in many ways. Taking your individual points in turn, 1) A Microservice should wrap a business problem not a technical problem. So "A Key-Value store" should never be a microservice. They should aim to be swan-like - making the difficult look easy. ie they promote encapsulation of difficult business problems. 2) It's a fundamental tenet of distributed systems design that the parts of the system which need to be fast should be identified and their development treated accordingly. Microservices optimise other constraints. (You can still get blindingly fast speed where you can suffer eventual consistency - which is about 90% of the time for most businesses.) 3) Continuous Delivery says, "When your deployments are difficult and slow it means you should do more of them." Most Monoliths handle all of the problems you described very badly. If your business can scale the processes for handling them (which it needs to) then it doesn't matter if you have one service providing them or many microservices - you can still handle it. 4) I don't understand what you are saying (particularly the OO bit). I think you're implying that microservices require a utopian ideal that isn't possible inside large enterprises. There is nothing wrong with evolving towards the ideal. DDD gives you "anti-corruption layers" to handle interfaces that cannot evolve fast enough for systems that depend on them. 5 i) This is a big challenge and I think that best practices are still evolving in this area. Contract testing (see Pact for one implementation) helps a lot. In general the challenges here drive businesses towards fully automatable IaaS - and this is also a good thing. Once you can spin up an entire environment on demand you can do (a limited number of) full end-to-end tests to smoke test your system. In general this is a problem for everyone, though, regardless. It's just most multi-monolith businesses don't deal with the limited number of problems introduced across system boundaries and either fix them post-deploy or spend weeks in UAT system configuration hell. Also it's something we're increasingly going to have to learn how to handle better as developers as we employ more SaaS in what we use. The problems are very similar. 5 ii) If a data change requires changes to 30 microservices then something has gone very very wrong. There shouldn't be 30 microservices that need to be aware of the existence of a driving licence. It sounds like you're used to doing very explicit marshalling. Coast-to-Coast marshalling can help here. Most microservices should look at the data they are interested in and have strategies for ignoring the rest. W/regard to new data / historical data - the elephant in the room that hasn't quite reached the broad industry acceptance of say Functional Programming is Event Sourcing. This is a great introduction to the concept by (naturally) Greg Young: https://www.youtube.com/watch?v=KXqrBySgX-s https://www.youtube.com/watch?v=KXqrBySgX-s