Cloud Parts

Monolith, microservices or serverless?

DimensionMonolithsMicroservicesServerless architecture
In one lineOne application, deployed as one unitMany small services, each deployed on its own and owning its dataManaged services plus functions the platform runs only when an event arrives
Unit of deploymentThe whole app; every change ships everythingOne service; teams ship on their own schedulesOne function (or a small group); the platform handles servers
How it scalesRun more identical copies behind a load balancer; the shared database is the limitScale each service separately, only where load isThe platform starts instances per event and scales to zero when idle (Lambda: 1,000 concurrent executions per Region by default, raisable)
Calls between partsFunction calls in one process: nanoseconds, no failure modes of their ownNetwork calls (HTTP, gRPC) or messages: milliseconds, and they can fail or time outEvents, queues and workflow services; every hop is a network call, and some are billed per call
DataOne database; one transaction can cover several featuresA database per service; cross-service changes need sagas and eventual consistencyKept in managed services; a function shouldn’t rely on state between invocations
Built-in limitsBuild and test time grow with the codebaseLatency adds up along chains of synchronous callsLambda runs at most 15 minutes per invocation; cold starts hit under 1% of invocations and take from under 100 ms to over a second
Cost shapeA few always-on instances; cheap to run and to understandInstances per service plus the platform (pipelines, monitoring, tracing) every service needsPer request and per millisecond; idle costs nothing, but steady high load can cost more than always-on containers
DebuggingOne process, one log stream, one profilerDistributed tracing to follow a request across servicesDistributed tracing, plus local emulators or deploys to test the wiring
FitsNew products, and one to a few teams; modular monoliths stretch much furtherMany teams with stable domain boundaries and mature automationEvent-driven glue, spiky or low traffic, scheduled jobs and small APIs
Known examplesBasecamp; Shopify’s modular Rails monolith (2.8 million lines in 2020)Amazon.com (100+ services per page in 2006); Netflix (hundreds of microservices by 2016)Prime Video’s stream monitor started serverless, then moved to one process and cut cost by over 90%

Rule of thumb

These are not stages you must pass through. Most systems should start as a well-structured monolith and split off a service only when a team or a part of the load clearly needs its own lifecycle; Fowler’s rule of thumb is not to consider microservices unless the system is too complex to manage as a monolith. Serverless functions fit around either style, for jobs triggered by events. Mixes are normal: a monolith with a few functions for image resizing and webhooks is a common, healthy shape.

Sources