Where did the author get those fallacies to refute? They're more like straw men. There is no infrastructure panacea for crappy software engineering practices o

Where did the author get those fallacies to refute? They're more like straw men. There is no infrastructure panacea for crappy software engineering practices or bad unscalable designs. We've been running microservices in production for years. It is more difficult to partition behavior into little chunks than to make a monolithic app. It can be slower if you don't handle inter-service RPC properly, and as your servers evolve, you have to stay on top of merging or splitting services as needed to maintain clean internal RPC's. It's a whole lot of work actually. Why do it? Because there are also benefits. In a large system, microservices which are tested at the RPC boundary can be deployed independently of each other, which is HUGE. If you have a bunch of people building a monolithic app, you can only rev it as fast as the slowest of your teams can build and qualify it - this has been the biggest win for us! It's easier to test these things, because you can mock at RPC boundaries, versus mocking code, which is a more realistic scenario which helps you find issues like inter-RPC auth problems, which you wouldn't find in code-mocked unit tests. I think of it this way - it's a whole lot of extra work which you have to do, which buys you flexibility in deployment and testing. That's a big deal.