Serverless deployment
Deploy services as functions: what serverless gives, what it limits, and how to map functions to services.
key idea / coordinatorservice / good pathin progress / watch outproblem / failureneutral
Serverless
Upload functions and let the cloud run and scale them.
Function as a Service
Serverless means servers still exist but you stop managing them. FaaS is the most talked-about kind (AWS Lambda started the excitement in 2014), but serverless also covers managed databases, queues and storage. With FaaS you deploy a function, it sleeps until a trigger fires, runs, then stops.
| Benefit | Why |
|---|---|
| Pay for use | Idle code costs nothing; good for low or unpredictable load |
| Less operations | The platform handles scaling up and down |
| Implicit resilience | Some high availability without you building it |
From Building Microservices, ch. 8, "Function as a Service (FaaS)".
Limits and challenges
FaaS runs on containers you cannot see, which gives you less control. Check each limit against your workload.
| Limit | What it means |
|---|---|
| Runtime support | The provider must support your language (Azure widest at the time; custom runtimes on AWS add upkeep) |
| Resources | You mostly choose memory only; CPU and I/O follow. You may buy memory just to get CPU |
| Execution time | Capped: about 9 minutes on Google, 15 on Lambda at the time; long jobs are a poor fit |
| Statelessness | A call cannot see the last one's memory; store state elsewhere. Chaining functions is hard |
| Cold start | New instance startup is slow on JVM and .NET, though platforms keep runtimes warm; Go, Python, Node and Ruby start fast |
| Concurrency caps | Hard limits on parallel runs; scaling functions can overwhelm things that do not scale |
Tooling for chains: Azure Durable Functions suspends and resumes a function so it can orchestrate others. Newman finds it friendlier than AWS Step Functions, which wire functions together with JSON configuration.
From Building Microservices, ch. 8, "Function as a Service (FaaS)": limitations and challenges.
Mapping functions to microservices
With FaaS the link between a microservice and a deployable unit gets fuzzy. Start with the simple mapping; split only for a reason.
- Function per microservice: a good start. One entry point dispatches by path.
- Function per aggregate: keeps each aggregate's life cycle in one function. Keep the external interface coarse so you can regroup later.
- Shared database: fine while one team owns the functions. Separate data once their needs diverge; then they are really microservices.
- Finer than an aggregate: Newman is wary. Many functions to manage, and the aggregate's integrity gets harder to protect.
From Building Microservices, ch. 8, "Mapping to microservices".
PaaS, FaaS or containers?
A PaaS (Heroku is the benchmark) runs your technology-specific artifact and often hides scaling and databases. It works well until you need to get under the hood, and the smarter its autoscaling tries to be, the more it can go wrong for unusual apps. Public cloud serverless products now fill much of the same need by offering managed pieces (brokers, databases, storage) you assemble yourself.
| PaaS | FaaS | Containers (Kubernetes) | |
|---|---|---|---|
| You supply | Language artifact | A function | Container image |
| Scaling | Platform, sometimes tunable | Automatic, with concurrency caps | You configure it |
| Watch out | Little control when it misbehaves | Time, state and cold-start limits | Real operational complexity |
| Good fit | Standard web apps | Spiky or low load; event reactions | Broad workloads needing control |
Newman's rules of thumb for where to deploy:
- If it is not broken, do not fix it. Do not follow fashion.
- Give up as much control as you are happy with, then a bit more. Prefer a good PaaS or FaaS if your app fits.
- Containers are a good compromise on isolation and cost, and Kubernetes is probably in your future if you need them.
- On a public cloud, if the problem fits FaaS, try it before Kubernetes. Do not let fear of lock-in trap you in a mess of your own making.
From Building Microservices, ch. 8, "Platform as a Service", "Which Deployment Option Is Right for You?" and "And Knative".
Recap
- Serverless removes servers but suits short, event-driven work.
- FaaS: pay for use and little ops, but language, resource, time, state, cold-start and concurrency limits.
- Start with a function per microservice; consider a function per aggregate; avoid going finer.
- Use the highest-level platform that fits; mixing FaaS and containers is normal.
Quick check
Show answer
A concurrency mismatch: functions scale out faster than the database can. Cap concurrency, buffer with a queue, or scale the downstream system too.
Show answer
It multiplies functions and weakens the aggregate as the unit of integrity. A function per aggregate is the finer limit he is comfortable with.