I have a different view of what microserves are and how they can be used without the overhead everyone is right to point out and hate. In my project we do util

I have a different view of what microserves are and how they can be used without the overhead everyone is right to point out and hate. In my project we do utilise microserve architecture through the serverless paradigm (i.e. bunch of lambdas) but those services are exposed directly to the client via API gateways (many of them). In essence there is very little service-to-service communication. Each service has its own data storage (s3, dynomo, etc), its own queues and topics and there is very little service inter-dependencies of any sort. Each "micro Service" is kind of its own "micro API" if you like. The reason I believe this is a good approach for pretty much any problem is because each component is 100% swapable, it builds on its own and frankly has little to do with the rest of the system and such erros do not have a cascading effect. These services can be moved and reused in other systems too. The responsability for using these services in some sort or orchestrated manner lies with the client and yes the client/s is heavy. Now it is true that I cannot simply union select bunch of data. You need to except that each "micro service/API" is much like all other 3rd-party APIs and so you need to come up with your own way of pulling analytics, data consistency checks, etc. The fact that service-to-service comms are sort of banned have forced us to come up with interesting algorithms that rely heavily on solid computer science (math) principles. Just saying