By the end of the lesson, you can explain what serverless means, how it differs from architecture styles, and what trade-offs it means for the quality attributes.
Why discuss it separately?
Serverless often appears among architectures, yet it primarily describes who operates the execution, not how the system is split. The same system can run in a serverless environment both as a monolith and split into services. The concept has to be understood because it is often confused with microservices.
What is serverless?
According to Mike Roberts' article (published on Martin Fowler's site), serverless architecture means using third-party BaaS (Backend as a Service: ready-made backend services, for example authentication or a database) and/or custom code running on a FaaS (Functions as a Service) platform, which reduces the need for always-on servers. In FaaS the code runs in stateless, event-triggered, ephemeral execution environments managed by the provider.
The AWS (Amazon Web Services) Lambda documentation describes this model like this: code runs without provisioning or managing servers; the provider handles capacity, scaling and patching; the code starts on an event (for example an API call or a message); every invocation runs independently; and payment is usage based.
flowchart LR
E["Event:<br/>request, message, timer"] --> F["Function<br/>(started by the provider)"]
F --> S[("External store")]
F --> R["Result"]
By aspect
Aspect
Serverless (FaaS)
Coupling
Functions connect through events and services; the tie to the platform can be strong
Deployability
Releasing function by function is easy
Scaling
Automatic, handled by the platform
Data management
The function is stateless; state lives in an external store
Failure handling
The platform handles execution failures; timeouts and retries are part of the design
Cost
Usage based; advantageous for rare or fluctuating load
Roberts mentions the following drawbacks: dependence on the provider, statelessness (state must be stored outside), the execution time limit, cold-start latency and harder integration testing, because the cloud cannot be fully simulated locally. The article gave the execution time limit with the value valid at the time of writing (five minutes on AWS Lambda); provider limits change (according to the current AWS Lambda documentation an invocation can last up to 15 minutes), so a concrete value must always be taken from the provider's current documentation.
How does it relate to the other styles?
Serverless is an execution model: the responsibility for deployment and scaling moves to the provider.
The question of structure remains open: a serverless system can be well or badly bounded, and it can become a distributed monolith too, if the functions depend tightly on each other.
The questions of network calls, eventual consistency and failure handling appear in the same way as with microservices.
Common misconceptions
Statement
Clarification
"Serverless equals microservices."
Serverless is an execution model; microservices is a decomposition style.
"There is no server in serverless."
There is, but the provider operates it.
"Serverless is always cheaper."
Usage-based pricing is advantageous for rare load; not necessarily for constant heavy load.
"Splitting into functions solves the boundaries."
Good boundaries still have to be designed.
In short
Serverless is an execution model: the provider manages servers and scaling.
With FaaS the code is event-driven, stateless and short-lived.
Serverless: An Execution Model, Not a Structure
Objectives
By the end of the lesson, you can explain what serverless means, how it differs from architecture styles, and what trade-offs it means for the quality attributes.
Why discuss it separately?
Serverless often appears among architectures, yet it primarily describes who operates the execution, not how the system is split. The same system can run in a serverless environment both as a monolith and split into services. The concept has to be understood because it is often confused with microservices.
What is serverless?
According to Mike Roberts' article (published on Martin Fowler's site), serverless architecture means using third-party BaaS (Backend as a Service: ready-made backend services, for example authentication or a database) and/or custom code running on a FaaS (Functions as a Service) platform, which reduces the need for always-on servers. In FaaS the code runs in stateless, event-triggered, ephemeral execution environments managed by the provider.
The AWS (Amazon Web Services) Lambda documentation describes this model like this: code runs without provisioning or managing servers; the provider handles capacity, scaling and patching; the code starts on an event (for example an API call or a message); every invocation runs independently; and payment is usage based.
flowchart LR E["Event:<br/>request, message, timer"] --> F["Function<br/>(started by the provider)"] F --> S[("External store")] F --> R["Result"]By aspect
Roberts mentions the following drawbacks: dependence on the provider, statelessness (state must be stored outside), the execution time limit, cold-start latency and harder integration testing, because the cloud cannot be fully simulated locally. The article gave the execution time limit with the value valid at the time of writing (five minutes on AWS Lambda); provider limits change (according to the current AWS Lambda documentation an invocation can last up to 15 minutes), so a concrete value must always be taken from the provider's current documentation.
How does it relate to the other styles?
Common misconceptions
In short
Review questions
Learning resources