Stable service boundaries usually require knowledge a new product does not yet have

Microservices impose coordination costs before their benefits arrive. Deployments, network failures, and changes spanning services all require machinery that a small application can initially avoid.

Fowler’s more subtle objection concerns boundaries. Early in a product’s life, even experienced architects may not know which functions belong together. Moving functionality between modules is easier before those modules become independently deployed services with contracts and data ownership.

He therefore favors beginning with a modular monolith, or a few coarse services, and separating components as the domain becomes clearer. That does not promise an effortless future split: tangled dependencies can make a monolith just as hard to dismantle.

The article explicitly describes its evidence as sparse and anecdotal. It is a conditional design argument, with exceptions for experienced teams and better-understood replacement systems. Its value lies in treating architectural commitment as something that can follow learning.