FIT5225 · Cloud Computing And Security
Serverless Computing
Serverless is the top rung of the abstraction ladder: you give up the last of the infrastructure and ship only functions. There are still servers — you just never manage them; the provider runs, scales and bills your code per request. FIT5225 teaches the evolution (bare metal → VM → container → function), the event-driven model (a trigger from an event source invokes a short-lived, stateless and ephemeral execution), and the flagship service AWS Lambda — its execution model, the cold-start latency on a fresh container, its limits and its pay-per-invocation pricing. The canonical pattern the unit drills is the serverless triangle API Gateway + Lambda + DynamoDB: a request hits the gateway, invokes a function, which reads/writes a managed database. You also learn the trade-off table — when serverless wins (spiky, event-driven, low-ops) and when it does not (long-running, latency-critical, stateful). Quizzes test the distinctions and reading the event flow.
What this chapter covers
- 01The evolution to serverless — bare metal → VM → container → function
- 02Serverless vs FaaS — don't conflate the two terms
- 03The event-driven model — triggers, event sources, ephemeral execution
- 04AWS Lambda — execution model, cold start, limits, pricing
- 05The canonical pattern: API Gateway + Lambda + DynamoDB
- 06Pros, cons & when NOT to use serverless
Worked example: should this workload be serverless?
- +2(a) W1 (thumbnailer) fits Lambda: it is event-driven, short, stateless and spiky (zero to thousands/hr) — exactly serverless's sweet spot; it scales to zero and you pay only per invocation.
- +1(b) W2 (25-min transcode) is a poor fit: it exceeds Lambda's execution-time limit and runs steadily at high CPU, so a always-on EC2 / container is cheaper and not cut off — long-running, steady, compute-heavy jobs are the classic 'don't use serverless' case.
- +1(c) The trigger for W1 is the S3 object-created event — the upload itself invokes the Lambda (an event source → trigger → ephemeral execution).
- +1Note the trade-off: Lambda's first call after idle pays a cold start; fine for W1's background resize, but a reason to think twice for hard latency-critical paths.
Key terms
- Serverless
- A cloud model where you deploy code without managing any servers — the provider provisions, scales and bills the underlying infrastructure automatically, scaling to zero when idle. 'Serverless' is the broad category (it also covers managed databases, queues, etc.); FaaS is the compute part of it.
- FaaS (Function-as-a-Service)
- The compute flavour of serverless: you deploy individual functions that run in response to events, each short-lived, stateless and ephemeral, with the provider handling all scaling. AWS Lambda is the canonical FaaS. The quiz warns: serverless and FaaS are related but not identical — FaaS is a subset of serverless.
- Event-driven model
- Serverless functions are invoked by triggers from event sources — an HTTP request via API Gateway, an S3 upload, a queue message, a schedule. Each invocation is independent and short-lived; there is no long-running process waiting. 'Stateless and ephemeral' is the load-bearing phrase: a function keeps no state between calls.
- Cold start
- The extra latency on a function's first invocation after it has been idle, while the provider spins up a fresh execution environment (container) and loads your code. Subsequent 'warm' invocations reuse it and are fast. Cold start is the headline serverless trade-off and the reason to be cautious for hard latency-critical paths.
- API Gateway + Lambda + DynamoDB
- The canonical serverless pattern FIT5225 drills: an HTTP request hits API Gateway, which invokes a Lambda function, which reads or writes the managed DynamoDB key/value store. The whole path is fully managed, scales automatically and bills per use — no servers to run.
Serverless Computing FAQ
If it's 'serverless', are there really no servers?
There are servers — you just never see or manage them. The provider runs the infrastructure, scales it up and down (including to zero) and bills you per request or per millisecond of execution. 'Serverless' describes your operational experience (no server management), not the absence of hardware. Conflating the term with 'no servers exist' is a common quiz trap.
What's the difference between serverless and FaaS?
Serverless is the broad category — any model where the provider manages the servers, including managed databases, queues and storage. FaaS (Function-as-a-Service), such as AWS Lambda, is specifically the compute part: running your individual functions on events. So FaaS is a subset of serverless; the unit explicitly tells you not to use the two terms interchangeably.
When should I NOT use serverless?
When the workload is long-running, steady and compute-heavy, latency-critical on every request, or heavily stateful. Functions have execution-time and resource limits and pay a cold-start penalty, so a 25-minute steady job, a low-latency real-time service, or a workload needing persistent in-memory state is usually cheaper and better on an always-on container or VM. Serverless shines for spiky, event-driven, short, stateless work.
What causes a cold start and does it matter for my project?
A cold start happens when a function is invoked after being idle and the provider must create a fresh execution environment and load your code, adding latency to that first call; warm reuses are fast. It matters for user-facing, latency-sensitive paths but is usually negligible for background, event-driven work. Knowing when cold start is and isn't a problem is exactly the trade-off reasoning the quiz rewards.
Exam move
Pin the position first: serverless is the top of the abstraction ladder — you ship functions, the provider handles everything else. Keep two terms distinct (serverless = broad category; FaaS = its compute part) because the unit explicitly tests that. Learn the event-driven vocabulary — trigger, event source, stateless, ephemeral — and be able to read the canonical API Gateway + Lambda + DynamoDB flow and say what each box does. The highest-value reasoning question is the trade-off table: state when serverless wins (spiky, event-driven, short, stateless, low-ops) and when it loses (long-running, steady-high-CPU, latency-critical, stateful), with cold start and the execution-time limit as the concrete reasons. Practise classifying a described workload as fit or unfit.
