Serverless architecture

Pattern · Chapter 8

The idea in brief

Serverless means compute is provided without you managing or administering servers; code runs on demand, using as much or as little capacity as needed (analogous to cloud storage).
Maturing and increasingly common. Offered by Amazon, Microsoft, Google, IBM.
Good fits: web apps, event-driven data processing, event workflows, scheduled/CRON tasks, mobile apps, chatbots, IoT, and data-transformation tasks (image/video compression, voice packets, PDF generation).
Backend logic is provided through two models used together: FaaS and BaaS.

A small piece of code (a function) runs on an ephemeral compute service: a container spun up on invocation and torn down when done.
Invoked by events or HTTP requests; can return a value or pass its result to another function in a workflow. Output can be structured (HTTP response) or unstructured (string/int).
Each function should follow the single responsibility principle — one well-defined purpose (see SOLID design principles).
Functions should be idempotent — repeated executions of the same request yield the same result with no adverse effects. Needed because at-least-once delivery means a function may be invoked more than once.
Can be synchronous or asynchronous (async returns a unique id to poll status).
An API gateway is the system’s entry point, routing HTTP requests to the right stateless function container and returning the result to the client.
Implementations: AWS Lambda, Azure Functions, Google Cloud Functions, IBM Cloud Functions.

Rooted in Mobile Backend as a Service (MBaaS); lets teams use existing third-party service applications instead of writing them in-house — reducing time and cost.
In contrast to FaaS (you write the code), BaaS offers ready-made services: database, push notifications, file storage, authentication.

Cost savings — utility billing; pay only for compute actually used; no server/network hardware or support staff; reduced development costs (BaaS) and scaling costs (FaaS).
Scalable & flexible — no under- or over-provisioning; capacity scales up/down with demand, minimizing waste (see Availability).
Focus on core products — no servers to manage → higher productivity, faster time to market; even small teams can ship to production quickly.
Polyglot development — pick best-of-breed languages/runtimes per function (subject to provider-supported languages).

Hard to debug & monitor — distributed; when chained functions fail it’s hard to see when/why; tooling still immature.
Multitenancy issues — different customers on the same machine risk cross-customer security or performance impact.
Vendor lock-in — provider-specific formats, deployment methods, and tools; switching needs refactoring. Mitigate with a portable packaging framework (e.g. the Serverless Framework).
Complexity of many functions — balancing granularity is hard; chaining functions for complex transactions needs compensating logic to handle mid-chain failures.
Fewer runtime optimizations — little control over memory/CPU/disk/network (though the provider can assist).
Still immature — standards and best practices less established than other architectures.

Serverless need not be all-or-nothing. You can build part of a system serverless and use other patterns elsewhere — e.g. add new features of an existing app in a serverless environment.

Functions move through a deployment pipeline (varies by provider):
1. Upload the function definition — specs/metadata (unique id, name, description, version id, runtime language, resource requirements, execution timeout, created/modified timestamps) plus the code and dependencies (ZIP or Dockerfile; or a repo path + credentials).
2. Build compiles the definition into an artifact (binary, package, or container image).
Invocation start can be a warm start (an instance already deployed and ready) or a slower cold start (starts from an undeployed state).

Method	Pattern	Notes / examples
Synchronous request	request-reply	Client waits; via API gateway + client-/server-side discovery. HTTP, gRPC
Asynchronous request	publish-subscribe	Publish to an exchange → bindings route to queues → functions consume. RabbitMQ, AWS SNS, MQTT, CRON
Message stream	streaming	Real-time; stream partitioned into shards, each to one worker. AWS Kinesis, DynamoDB Streams, Apache Kafka
Batch job	master/worker	Master splits a job into parallel tasks, launches worker functions, gathers results. On-demand or scheduled

Software Architect’s Handbook (Packt, 2018), Ch.8 “Serverless architecture”, pp. 638-662.