Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dism

Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dismantle it ASAP". I think it's a case-by-case thing, and you're ignoring the significant complexity costs of a microservices approach. > Deployment times will be longer Not necessarily. I'd say that when you have multiple changes across boundaries that need to go out together, monolith deployments can actually be faster as you only need to do a rolling update of 1 container instead of N. But if by "deployment time" you mean the time between deploys, I agree. But also...so what? As long as your deployment times are good enough, it doesn't really need to be faster. > requirements for hosts where you deploy it will be bigger True > you will end up with _huge_ instances Not necessarily. Depends on the tech stack, framework, etc. I've seen .NET (and even Rails) monoliths that are huge and only use hundreds of MB/a GB or two of RAM. But I've also seen Java monoliths using 12GB+ to handle small amounts of traffic, so YMMV. > You'll have to scale more than you really need to because some parts of your monolith are more scalable than another A problem often easily fixed with throwing a bit of $$$ at the problem, depending on your scale and per-request profitability.