It's a case by case scenario. I built my project in a microservice architecture, so when the author states that microservices were built so that teams can enjo

It's a case by case scenario. I built my project in a microservice architecture, so when the author states that microservices were built so that teams can enjoy their independence, it doesn't apply to me as I am currently a 1 man team. I split my services up for many reasons, but primarily two, the ease of migrating from python to go as the ease of rebuilding one service at a time differs as opposed to a full blown rebuild, and also for performance and scaling as parts of my application will be hit harder by outside requests than others. >Web requests can be managed by one type of instance, that results in one EC2 image or whatever. Anything that can be handled within the lifecycle of one request can be handled there, and these instances are horizontally scaled behind a load balancer. The author gave an extremely simple and generic system design, and while this can work for a sizable amount of applications, there are still a significant amount of applications that require and demand a more complicated structure. One of the services that I have split, almost exclusively deals with real time connectivity with websockets which requires a towering amount of performance as opposed to the other services that I have - to place these in a monolithic structure, scaling would be incredibly awkward - imagine adding 10 more load balanced boxes just so you can handle your websocket requests, but now the part of your app that deals with all your http requests is now also horizontally scaled when it didn't need to be. >On the communications front, internal web services are often doubly inefficient by using REST rather than binary transmissions. There’s no reason for any of this, and if multiple microservices hops are used, this all adds up and slows down the system. Even just a conversion to JSON and back is a wasted effort, more so if done dozens of times. This is true - while initially developing internal communication with GRPC, I've reverted back to http despite the 30-50ms TLS/SSL handshake simply because its a tired and true technology. GRPC is still relatively new, with seemingly insubstantial development, and I was afraid to proceed further as roadblocks and technical debt may be accumulated in the future. However, in a smaller mesh, in my opinion, anything shorter than ~150ms is insubstantial in my opinion - A blink of an eye is just about 150ms, and if it is the case that the internal requests are hitting multiple endpoints before resolving the original request, then it's more of an architectural problem, not that "microservices" are a problem. Not everything has to be finely chopped, but breaking some portions down can make it more digestible