Serverless Computing Explained: Stop Managing Servers, Start Shipping

by Souy Soeng /October 04, 2026

Diagram of an event triggering a serverless function that scales automatically, with servers hidden behind the cloud

Serverless computing is a way to run code in the cloud without owning, patching or scaling the servers underneath it. You write a function, connect it to an event, and the provider runs it only when that event happens. The servers still exist. They just stop being your problem.

That sounds like a small change, but it changes a lot about how you build software. This guide covers why serverless exists, what happens when a function runs, how scaling and billing work, and where the model hurts: cold starts, time limits and lock-in. It ends with the mistakes teams make most often and a safe way to ship your first function.

TL;DR

Serverless means the cloud provider manages the machines. You manage only your code and its settings.
An event wakes a function. The function does one job, then its resources are released.
The platform scales automatically, often down to zero, and bills per request and compute time.
The trade-offs are cold starts, maximum run times and vendor lock-in. Plan for them early.
Start with one small background task, not a full rewrite.

Why does serverless exist? The 3 AM server problem

Picture a small startup with one production server. At three in the morning, the pager goes off. Checkout is timing out, and customers are already complaining in public. Every minute of downtime costs money. Someone half asleep opens a laptop, connects to the machine over SSH and starts reading logs. Nobody debugs well at that hour, and that is when mistakes happen.

The cause turns out to be dull. The disk filled up with old log files because nobody was watching it. It was not a clever bug or an attack. It was routine housekeeping that got missed. By morning the app is back, but the team has lost a night of sleep and a day of feature work.

That full disk is only one of the jobs that come with owning a server. Running your own machines means doing the same work over and over, and the list never gets shorter.

Buy and provision: guess capacity before you write a single feature. Guess too low and you crash on launch day. Guess too high and you pay for empty machines.
Patch and update: operating systems and runtimes get security fixes all the time. Every skipped update leaves a door unlocked.
Monitor everything: CPU, memory, disk and network all need dashboards, alerts and a person awake to respond.
Scale by hand: when traffic grows, you add machines and load balancers and hope they hold.

What is serverless computing, really?

In 2014, Amazon launched AWS Lambda and made serverless computing mainstream. The question behind it was simple: what if developers handed over only their code, and the cloud handled everything else? You no longer rent a whole machine. You upload one function and walk away. Today every major cloud has a version, including Google Cloud Functions and Azure Functions. The model is often called Functions as a Service, or FaaS.

The name causes confusion. Serverless does not mean there are no servers. Real data centers, hardware and operating systems still run underneath your code. A better name might be servers you never touch. A request still passes through your code, then a runtime, then an operating system, then physical hardware. Only the top layer belongs to you.

You own your business logic and settings such as memory and permissions. The provider owns patching, spare capacity, failover and replacing failed hardware. A taxi is a good comparison. You choose where to go, and someone else owns, fuels and repairs the car. You still need to write good code. You just aren't the one replacing a broken disk at midnight.

How do serverless functions work?

A traditional server runs all day, waiting for requests. A serverless function works the other way. It sleeps until an event arrives, does one job and then goes away. Each cycle looks the same: an event arrives, the platform starts an instance of your function, your handler runs, and the resources are released. Then the platform waits for the next event.

Events can be many things. One might be an HTTP request when a user clicks a button. Others include a file landing in storage, a message arriving on a queue, or a timer that fires every night. Each of these can trigger your code without any process running in between.

Instances come and go, so treat every run as a fresh start. Anything you need to keep, such as a user's shopping cart, belongs in a database or cache, not in a local variable. Functions also work best when each one does a single job. Small, focused functions are easier to test, scale and replace.

Triggers: HTTP requests, file uploads, queue messages, scheduled timers
Stateless: never rely on memory between runs
Focused: one function, one job

What does a serverless function look like?

A traditional app needs a web framework, a port to listen on and a process manager to keep it alive. A serverless function needs none of that. You write one handler and export it. The example below is a complete serverless endpoint. The platform calls your handler with an event object. You read what you need, return a response, and the cloud handles the rest.

The event is your input, and its contents depend on the trigger. For an HTTP request, it holds the path, headers and body. For a file upload, it holds the bucket and file name. The pattern stays the same while the data changes. Whatever you return goes back to the caller. For a web request, that is a status code and a body. A background job might return nothing and simply write to a database.

Deployment is just as simple. You upload the code, attach a trigger, and the function is live. There are no servers to configure.

# handler.js — runs once per event
export const handler = async (event) => {
  const name = event.name ?? 'world';
  return { statusCode: 200,
    body: `Hello, ${name}!` };
};

How does serverless scale and how is it billed?

Remember scaling by hand? Serverless removes that job in both directions. The platform watches incoming events and runs as many copies of your function as it needs, without any scaling rules from you. If your product gets shared and requests flood in, it runs more copies in parallel with no load balancer to configure. When traffic stops at night, many services scale all the way to zero.

That makes a viral moment much less risky, but two limits still apply. Your account has concurrency limits, so learn them and raise them before a big launch. Your database also has to survive the burst. Scaling the functions often just moves the bottleneck further down the stack.

Billing follows the same idea. A traditional server is billed by the hour whether it is busy or idle. Serverless platforms usually charge per request plus the compute time your function uses. Take one API call that runs for 200 milliseconds with 512 MB of memory. That is 0.2 seconds times 0.5 GB, or 0.1 gigabyte-seconds billed.

When nobody calls the function, it has no compute charges. Storage, databases and data transfer still cost money, but you no longer pay for an idle machine all night. Speed and cost are also linked. Cut the runtime in half and the compute charge drops by about half. Choosing the right memory size lowers the bill too.

Traffic spike: the platform runs more copies in parallel
Zero traffic: no running instances and no idle compute cost
Faster code and right-sized memory both lower the bill

Real example: a serverless photo upload pipeline

Making thumbnails for a photo-sharing app is one of the most common serverless patterns. Users upload profile pictures from their phones, and you need small versions for feeds and lists. The old approach was a worker server that checked for new files all day and all night.

Here is the serverless version. A user uploads a photo, and storage saves the original. That save fires an event. The event wakes a function, which resizes the image and writes the thumbnail back to storage. Nothing checks for new files every few seconds. The upload itself is the trigger, so work starts right away, and nothing runs when nobody is uploading.

Volume stops being a worry. If a celebrity joins and thousands of followers upload photos at once, each photo gets its own function run in parallel. The code is the same, and there is no capacity planning. Adding features is easy too. You can attach another function to the same upload event for content moderation or virus scanning.

Serverless downsides: cold starts, time limits, lock-in

Serverless gives you convenience in exchange for control, and you should know what you are giving up. None of these trade-offs rules serverless out on its own. Teams that ignore them get surprised in production. Teams that plan for them barely notice.

A cold start happens when a request arrives and no instance is ready. The platform has to create one, loading the runtime and your code before your handler starts. Later requests reuse that instance. The delay is often small, but it hurts endpoints that need fast responses. Keep dependencies lean, and consider provisioned or pre-warmed capacity for critical paths.

Every platform also limits how long a single run can last. Video encoding or large batch jobs may not fit, so split them into steps or use containers instead. Finally, triggers, permissions and managed services tie you to one cloud's ecosystem, which makes switching providers harder later.

So when does serverless fit? It suits spiky, unpredictable traffic and needs very little operations work. Your own servers suit steady load and jobs that run for a long time. A good rule of thumb: if your work is event-driven or bursty, serverless is usually a strong default. If you have heavy load around the clock, compare the costs, because always-on machines can be cheaper.

Cold starts: keep packages small and pre-warm critical paths
Time limits: split long jobs or use containers
Vendor lock-in: triggers and services tie you to one provider
Constant heavy load: compare costs before you commit

Common serverless mistakes and how to avoid them

Most serverless problems come from treating functions like tiny servers. Teams bring habits from running servers, and the platform punishes them. The good news is that each mistake has a simple fix.

The first mistake is the giant function: a whole app packed into one function. It causes slow cold starts and painful deploys, so split functions by job and remove dependencies you don't need. The second is relying on local state. Code works in testing because the same instance stayed warm, then breaks in production when a new instance starts. Keep state in a database, cache or storage.

The third is having no cost limits. Pay-per-use cuts both ways. A function that accidentally triggers itself can loop endlessly and run up a large bill, so set budget alerts and concurrency caps early. The fourth is flying blind. When work is spread across many functions, problems are hard to trace without structured logs and tracing, so add both from the start.

Giant functions: split by job and keep packages lean
Local state: use a database or cache
No cost limits: set budgets, alerts and concurrency caps
No visibility: add structured logs and tracing early

How to get started with serverless

You don't need to rewrite everything at once. Move one small job first. Background tasks are good first candidates, because if something goes wrong, users never see an error page.

First, pick a small, isolated task, such as a nightly cleanup job, a webhook receiver or image resizing. Second, write the handler. Keep it focused, store state outside the function and avoid heavy libraries, since small functions start faster and cost less. Third, connect the trigger, whether that is an API route, a schedule, a queue or a storage upload. Use infrastructure as code from day one so the setup is repeatable rather than clicked together by hand. Fourth, add logs, alerts and budgets, then move the next task.

The bottom line

Servers still exist in serverless computing. The provider manages them.
Functions wake on events, run, and then disappear, so keep them stateless.
Scaling is automatic and often reaches zero, but downstream systems still have limits.
You pay for requests and compute time, not idle machines, so faster code costs less.
Plan for cold starts, time limits and lock-in from day one.
Start with one small background task and grow from there.

Quick-fire questions

Does serverless mean there are no servers?

No. Real servers, operating systems and hardware still run your code. Serverless means the cloud provider manages them, so you don't patch, scale or repair them.

What is a cold start in serverless?

A cold start is the extra delay when a request arrives and no instance is ready. The platform must load the runtime and your code first. Lean dependencies and pre-warmed capacity reduce the impact.

Is serverless cheaper than running my own servers?

It often is for spiky or low traffic, because you pay per request and compute time and nothing for idle compute. For heavy, constant load around the clock, always-on machines can be cheaper, so compare the costs.

What is the difference between serverless and FaaS?

Functions as a Service, or FaaS, is the model where you upload individual functions that run in response to events, as with AWS Lambda. It is the most common form of serverless computing, and the two terms are often used to mean the same thing.

When should I not use serverless?

Be careful with long-running jobs that exceed platform time limits, endpoints that need consistently fast responses, and heavy steady workloads. Containers or your own servers may suit those better.

What is a good first project for serverless?

Choose a small, isolated background task such as a nightly cleanup job, a webhook receiver or image resizing. If it fails, users never see an error page.

Watch the full video on YouTube →

Tag

Ad