Learn Cloud Computing - Serverless & Function as a Service (FaaS)

#Introduction

In episode 10 we learned to store non-relational data and accelerate it with caches. But all of that still runs on servers whose capacity you must calculate, whose uptime you must maintain, and which you must patch. What if all that work was removed — you just write code, and the cloud handles the rest?

Episode 11 opens up the serverless paradigm: architecture in which a server is no longer a unit you think about. We'll discuss the scale-to-zero and pay-per-execution principles, event-driven architecture, types of event triggers, an example Lambda function in Node.js, how to deploy it via the CLI, and the FaaS service map on AWS, GCP, and Azure.

#Serverless: The Invisible Server

The name "serverless" is misleading — servers still exist, they're just no longer your responsibility. The provider supplies an execution environment hidden behind the scenes, and you only interact with two things: the function code and the events that trigger it.

Three properties set serverless apart from everything we've discussed before:

• Scale-to-zero: when there's no event, no function runs, and nothing is paid. The VM instances in episode 6 are always on and always billed; a serverless function can be "completely off" and wake up in milliseconds.
• Event-driven: functions never run on their own. They're always triggered by something — an HTTP request, a new file, a database change, or a message in a queue.
• Pay-per-execution: billing is per execution and per duration in milliseconds. There's no idle cost like a VM.

#FaaS Characteristics

FaaS is the purest form of serverless: one function, one response, no visible server. There are two technical properties you must understand from the start:

• Stateless: a function must not hold state in memory between one execution and the next — function instances can be destroyed at any time. State that needs to survive must be stored outside: in a database, object storage, or cache.
• Cold start: when a function hasn't been called for a while, the provider must prepare a new environment before executing it. This warm-up adds a little latency to the first call. For applications that are very latency-sensitive, you can use provisioned concurrency — a few instances kept warm at an extra cost.

#Event Triggers: What Wakes Up Functions

A serverless function has no on button — it wakes only when an event arrives. The four most common trigger patterns:

Imagine a photo management system: a user uploads an image (file event), a function is triggered to create a thumbnail and store it, then sends a message to a queue, which triggers another function to send a notification. No server runs continuously — the whole pipeline wakes up only when needed.

#Example Lambda Function in Node.js

A Lambda function exports a handler. The following example receives an HTTP request, reads the name parameter, and returns JSON:

export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? "dunia";
 
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: `Halo, ${name}!`
    })
  };
};

Notice the structure of the incoming event: for an HTTP trigger, it carries the method, path, headers, query string, and body. Different triggers form different events — an event from a file upload contains the bucket name and object, an event from a queue contains a list of messages. The same function can be attached to various triggers.

Once the handler is ready, the function is created via aws lambda create-function:

aws lambda create-function \
  --function-name hello-cloud \
  --runtime nodejs20.x \
  --role arn:aws:iam::123456789012:role/lambda-basic-execution \
  --handler index.handler \
  --zip-file fileb://handler.zip

The important flags: --runtime determines the language version, --handler index.handler points to the file index.js with a function named handler, --role is the IAM role giving the function permission to run (for example, to read a DynamoDB table), and --zip-file sends the packaged code.

#Comparing the Big 3 FaaS Services

The concept is identical across providers: one function, event triggers, automatic scaling, and per-execution billing. GCP and Azure also offer an interesting variant: Cloud Run and Azure Container Apps run containers that can scale to zero — a kind of bridge toward episode 12's topic — still billing per usage but not constrained to a function shape.

#When Serverless, When Not

Serverless isn't the answer to everything. Consider when it's the right time to use it:

• Right: pulsating workloads (scheduled reports, upload processing), lightweight event integration, simple APIs, and quick prototypes.
• Less right: applications with constant high traffic (VMs or containers tend to be cheaper), long-running workloads like machine learning training, and systems very sensitive to cold starts.

Serverless shifts complexity from operations to architecture. You no longer think about patching and scaling, but you must think in terms of events, external state, and execution duration limits.

#Conclusion

In this episode 11 you understood the serverless foundations: scale-to-zero, which stops execution and billing when there's no event, event-driven architecture with four main trigger patterns — HTTP API, file upload, database changes, and queue messages — and pay-per-execution, which bills per millisecond. You also saw an example Node.js Lambda function and how to deploy it via aws lambda create-function, plus the service map of Lambda, Cloud Functions, and Azure Functions.

The keys to take away:

• Serverless functions are stateless — all state is stored outside.
• Event triggers shape the architecture — each function does one thing.
• Serverless saves money for pulsating traffic, not for constant load.

Serverless functions are ideal for small pieces of logic. What if you need full flexibility over your application — any dependency, long-running processes, its own port — yet still want to run it in a portable, scalable way? Episode 12 answers that: Managed Container & Kubernetes Services — the modern standard for packaging, shipping, and orchestrating applications.