Containers and orchestration
Three kinds of serverless
Functions, containers and managed platforms all count as serverless, but they hand you different things to ship and hide different amounts of the server.
Serverless means you deploy code or a container, and the platform handles the servers, patching and scaling. Usually you also pay per request. You still design for failure, timeouts, concurrency and cost. You just do not log in to a machine. The word covers three different products, and they trade control for convenience in different ways.
The big idea
Think of three ways to stay somewhere. A hotel room (FaaS) is booked by the night, and you bring nothing but your bags. A serviced flat (CaaS) has your own furniture, but the building runs the plumbing. A house you run yourself is a virtual machine.
Where the analogy breaks: a hotel room has no kitchen. You cannot keep anything between nights, so state goes to a database. Serverless functions are the same. Warm environments may reuse memory, but you cannot rely on it.
The three layers
| Style | Examples | You ship | Scaling unit |
|---|---|---|---|
| Function as a service (FaaS) | AWS Lambda, Google Cloud Functions, Azure Functions | A zip, an image, or a language artifact with one handler | Concurrent invocations |
| Container as a service (CaaS) | Cloud Run, AWS Fargate, App Runner | An OCI container that listens on a port | Container instances or tasks |
| Platform as a service (PaaS) | Heroku, Render, Elastic Beanstalk | A git push or a buildpack | Instances you size |
FaaS hides the most. You pay per use, and you think about one handler. CaaS keeps your Dockerfile and HTTP server, but the nodes stay hidden. PaaS is the simplest to use, but it lacks the extreme scale-to-zero economics of FaaS.
Teams often mix them. Lambda handles events and cron jobs, while Cloud Run or Kubernetes runs the main API.
Choosing one
| Your workload | Usually fits |
|---|---|
| Event handlers, webhooks, cron | FaaS |
| An HTTP API with a Dockerfile and bursts of traffic | CaaS |
| A simple web app with a small team that wants no infra work | PaaS |
Under the hood, major FaaS platforms isolate each tenant in a lightweight microVM, such as Firecracker on AWS. That is stronger than a plain container, and it is why a new environment has a startup cost. Treat multi-tenant isolation as the platform's job. Keep package size and your own code as yours.
Common mistakes
- Assuming FaaS is always cheapest. The crossover depends on how busy the service is. See the cost crossover.
- Keeping state in memory between calls. Store it in a database or object storage.
- Putting a busy API on FaaS without checking connection limits. See concurrency and connections.
Check yourself
- What does CaaS keep that FaaS drops? Answer: your container and HTTP server. You still ship a container, but the machines stay hidden.
- Why do cold starts exist at all? Answer: each new environment is created on demand with strong isolation, so it must boot before it can serve the first request.
Key takeaways
- FaaS, CaaS and PaaS trade control for less work.
- Mix them by workload: event handlers on FaaS, and the main API on containers.
- Plan for timeouts, concurrency and cost, even without servers.
- Next, cold starts explains the first-request delay.
Further learning
Serverless Architectures (Mike Roberts on martinfowler.com)Serverless Architecturesmartinfowler.com Cloud Programming Simplified: A Berkeley View on Serverless ComputingServerless cloud computing handles virtually all the system administration operations needed to make it easier for programmers to use the cloud. It provides an interface that greatly simplifies cloud programming, and …arXiv.org
What is Cloud Run (Google Cloud docs)What is Cloud Run | Google Cloud DocumentationGoogle Cloud Documentation
Related
Serverless and managed runtimes
Lambda, Cloud Run and friends - what you give up, what you gain and the cost crossover versus always-on containers.
Containers from the inside
Namespaces, cgroups and layered images - what a container really is, how images are built and shipped, and how to write small, fast, secure Dockerfiles.
Kubernetes core concepts
The control loop at the heart of Kubernetes, the objects you use every day, and how a request reaches a pod. Start here for the map of Kubernetes pages.