The monolith was fine

Every few years a company announces, with the tone of a confession, that it consolidated a constellation of services back into one deployable and things got better. The industry reacts as if a law of physics has been repealed. Then everyone returns to decomposing things, and the cycle rests until the next confession.

The 2023 iteration was the most famous because of where it came from: a Prime Video team published that collapsing a serverless, step-function pipeline into a monolithic service cut their infrastructure cost by 90%. The ensuing discourse generated more heat than the original post, and the calmest reading came from Adrian Cockcroft, of Netflix microservices fame, in a piece patiently noting that the team had refactored an over-decomposed pipeline, not renounced an ideology. Both facts were instructive: the correction, and how badly people wanted it to be a conversion story.

The same season, 37signals left the cloud entirely, and their argument was likewise less radical than its coverage: a stable, well-understood workload with predictable growth did not need the premium paid for elasticity. Substitute "network hops" for "cloud premium" and it is the monolith argument. You pay for flexibility. Flexibility you do not use is just the bill.

Define the term, since it arrives pre-insulted: a monolith is one deployable with internal module boundaries. It is not the absence of architecture. The absence of architecture is a big ball of mud, which can be built with equal success in one repository or across forty microservices, the latter being harder to fix. The boundary criterion does not care whether a module answers over a function call or a network call; it cares what the boundary hides.

What the single deployable buys is easy to enumerate and easy to forget: transactions that are actually transactions, refactors that cross module lines in one reviewable change, a test suite that means something, one thing to observe, one thing to roll back. What it costs is equally real: one blast radius, one release cadence for everyone, and a scaling unit the size of the whole. The engineering question is which side of that ledger your organization currently bleeds on. It is an accounting question, and accounting questions have situational answers.

The rediscovery cycle persists because the industry's incentive structure rewards decomposition asymmetrically. Nobody has ever given a conference talk titled "We kept it in one process and nothing happened." Promotion packets list services launched, not services declined. Meanwhile the costs of premature distribution arrive later, distributed across on-call rotations, where they are booked as operational immaturity rather than architectural choice.

So the monolith was fine, is fine, and will be rediscovered as fine on schedule, roughly every time a generation of engineers first meets a distributed transaction in production. The systems that age best seem bored by the whole debate: they stay in one piece until a boundary earns its network hop, and then they pay for exactly that hop. Architecture as bookkeeping. It will never headline a keynote, which may be the strongest available endorsement.