> 1. You just move your conflicts outside your git repo (or other VCS). The reason you get conflicts is because multiple people are changing the same bit of cod

> 1. You just move your conflicts outside your git repo (or other VCS). The reason you get conflicts is because multiple people are changing the same bit of code. If that's happening over multiple repos/services, it still happens, but now it's harder to detect and deal with. Integration tests cover this. > 2. Again, if your change causes an interface change, then that's going to be easier to deal with in a monolith than in a microservice. This point was more about upgrading dependencies. A lot of code bases never upgrade dependencies because it is too much work. (I've seen some really old versions of OpenSSL in code repos...). In a monolith the task is "we have to freeze the entire code base and upgrade this library in hundreds of places". In a microservice based system, the work is "farm out the work to a dozen teams and add upgrading the dependency to their sprint backlog." That is a huge difference. The first time I saw this in action I was blown away by how incredibly different this was vs what I'd experienced before. It means keeping up to date with security changes, or just not letting dependencies get too stale, is no longer a huge burden on a code base. > 3. This is only true if you're not running integration tests across multiple microservices. Which you need to be. Yup, of course you need to be! But monoliths also need tests, and ideally the monolith is broken up into black box modules that don't know each other's insides and the code is tested accordingly. Microservices force that test approach, but ideally there is not much difference. (Placing the entire system under test may be easier/harder, depending on business logic being tested) Also I have experience where build/test pipelines can take hours. With microservices you can only run the integration tests that directly impact that microservice. In theory with a monolith you can use tools that intelligently detect what code was changed and only run a subset of tests accordingly, but I've not seen those tools used, only discussed on HN. > 4. This is plain untrue. If one of your microservices is crashing all the time, then the other services that depend on it are also fubar'd. The only different is that you only detect this at run-time. It is an edge case benefit, but I'd argue it is still a benefit. Degraded performance in one use case is better than an entire service going down. There are differences between "Everything Xbox is down", "Xbox Live match making is down" and "You can't redeem gift cards". (No comment on actual Xbox Live functionality or stability!) > 5. This is a management problem, not an architecture problem. And the fact that several successful monolith deployments have scaled to the point where I'd have used them without needing formal deployment plans is a positive point for monoliths, surely? Sure, but most things I mentioned can be solved by management! Better test strategies, giving enough time to planning to avoid brittle interfaces, etc etc. To be clear, outside of running my own startup (which was mostly serverless), the backends I've seen or worked on have been part of large systems. For a team of 5? Microservices are probably the wrong solution.