Comment by jacob019

I love my service based architecture. It's about 10 years old and I can't imagine a better way of separating concerns and keeping a clean, maintainable, and resilient e-commerce operation up and running. I don't have hundreds of services, there are maybe 30. Each service is responsible for a particular domain, and if another service wants access to that domain it must go through the appropriate service. I can't imagine having a single process "monolith" being responsible for so many things, it would be a nightmare. I also can't imagine not enforcing separation of concerns via services, code would be duplicated everywhere. I was thinking the other day about the cost of serialization, which isn't too bad. If it is too bad then you're probably sending too much data over the wire, and should do more processing on the remote end of the wire. I think some people go overboard with the micro part of microservices. If there isn't a clear separation of domain, then there should probably just be one service. You can still modularize the code as much as you want within the service.