There are also a distinct lack of tools for debugging co-ordination and scheduling problems in a micro-service (or as they used to call it in my day, Service Or

There are also a distinct lack of tools for debugging co-ordination and scheduling problems in a micro-service (or as they used to call it in my day, Service Oriented Architecture) system. In an asynchronous RPC scenario, does Microservice A listen for the appropriate response message from Microservice B before continuing work on Request X99? Does it respond to all messages in the appropriate order? What happens in a cascading failure scenario when the back-end system Microservice B relies on is taking too long due to bad hardware/burst traffic/DDOS/resource contention? Do you have tools that can analyze your program for critical sections where you need explicit locking and ordering mechanisms? Do you have analysis tools that provide guarantees that your fancy distributed architecture is complete/correct? These are just a sample of the things OpenStack has to think about -- a micro-service architecture for managing, orchestrating, and authenticating access to data-center resources. It's a hard, hard problem and an on-going effort by thousands of well-paid engineers across the globe to get right. I have no doubt that a small team of talented developers could stand up a system of APIs around their core services to get a system running. However I can guarantee that they will be making huge trade-offs in terms of correctness and reliability. At least with a monolith (is that a pejorative?) application you do have tools to analyze and debug your code that work well and have been battle-tested for a couple of decades. I suspect you would produce fewer bugs if you were constrained for developer talent and time.