Start Monolith, Then Scale
- Senior practitioners advised starting with a monolith for small teams and moving to microservices as domains and teams grow. - Puneet Patwari cautioned against chasing buzzwords and urged mastering fundamentals, tradeoffs, and failure postmortems instead. - The guidance emphasizes learning real failure modes before introducing complex infra like gRPC, Kafka, or CQRS. (x.com 1) (x.com 2)
For small software teams, the advice surfacing again in 2026 is simple: start with one deployable application, then split it only after the codebase and org actually outgrow it. (martinfowler.com) A monolith is one application deployed as one unit. Microservices break that application into smaller services that talk over application programming interfaces, or APIs, and can be deployed and scaled separately. (aws.amazon.com) Martin Fowler wrote on June 3, 2015 that most successful microservice stories he had heard started with a monolith, while systems built as microservices from scratch often ran into trouble. He said microservices carry a “premium,” the added cost of running many services instead of one. (martinfowler.com) That cost shows up in places a small team feels immediately: service boundaries, deployments, monitoring, and incident response. Fowler’s August 28, 2014 checklist said teams need rapid provisioning, basic monitoring, fast deployment pipelines, and close developer-operations collaboration before they should consider microservices. (martinfowler.com) Amazon Web Services makes the same distinction in its current guidance. Its modernization docs say most applications begin as monoliths and that a monolith can remain a valid choice when responsibilities are not yet clearly defined. (docs.aws.amazon.com) The case for splitting software grows when the business and the org split first. AWS says microservices work best when services map to business capabilities and are owned by individual teams that can develop, test, deploy, and scale them independently. (docs.aws.amazon.com) That is why senior engineers keep warning against adopting gRPC, Kafka, or Command Query Responsibility Segregation as status markers. The hard part is not picking tools; it is learning where requests fail, where data gets coupled, and where teams need to release code without waiting on each other. (martinfowler.com 1) (martinfowler.com 2) Microservices still solve real problems. AWS says they let teams scale only the hot parts of an application, roll back individual services, and let small teams own narrower pieces of code. (aws.amazon.com) But that payoff comes later, after a team has stable boundaries and the operational muscle to run distributed software in production. The thread running through the guidance is not “never use microservices”; it is “earn them.” (martinfowler.com) (docs.aws.amazon.com)
