What is serverless computing? How serverless and FaaS work

Serverless computing is a cloud service category where you provide application code or data, and you do not provision, deploy, or manage the underlying hardware or software resources. Instead of renting a server you maintain, you upload a function and the platform runs it, scales it automatically, and bills you only for the actual execution. This guide explains how serverless works, the Function-as-a-Service model, its benefits and trade-offs, the anti-patterns to avoid, and when it is the right choice for your workload.

What is serverless computing?

The term "serverless" comes from the fact that, as a developer, you never touch a server. According to the ISO/IEC 22123-2 cloud-computing standard, serverless computing is "a cloud service category where the customer can use different cloud capability types without the customer having to provision, deploy and manage either hardware or software resources, other than providing customer application code or providing customer data." It is a form of virtualized computing.

Despite the name, servers absolutely still exist — the cloud provider runs your code on them. "Serverless" is a misnomer in the sense that servers are still used to execute code; the difference is that you, the customer, never provision or maintain them. The provider handles capacity, patching, and availability.

Serverless is a broad ecosystem. It includes the cloud provider, Functions as a Service (FaaS), managed services, tools, and frameworks. It does not remove complexity so much as shift it: much operational work moves from an operations team to the development team, though operations still manages identity and access, networking, security policies, and cost optimization.

How Functions as a Service (FaaS) works

The core execution model behind most serverless applications is Functions as a Service. You write a single unit of business logic — a function — and deploy it to a FaaS platform such as AWS Lambda, Azure Functions, Google Cloud Functions, or Cloudflare Workers. The platform takes care of running it.

A typical mental model:

• You write and upload a function — just application code, no web server, no container orchestration.
• The platform handles invocation — an event (an HTTP request, a file upload, a message in a queue, a scheduled timer) triggers the function.
• The platform scales it automatically — from zero to millions of invocations, spinning instances up and down as demand changes. There is no capacity planning and no load balancer to configure.
• You pay per execution — billed on the actual time your code runs (CPU time), not for idle machines waiting around.

This is why serverless suits event-driven and bursty workloads: you only pay for the compute you actually use, and scale is handled for you.

Key benefits

• No infrastructure management. No servers to patch, no capacity to plan, no regional configuration. The provider owns availability and scaling.
• Automatic scaling. Functions scale from zero to millions of requests automatically, matching demand in real time.
• Pay-per-use pricing. You are billed for execution time, not for idle provisioned capacity. Quiet periods cost almost nothing.
• Faster delivery. Because deployment is just uploading code and wiring an event, teams can ship small units quickly.

Challenges and trade-offs

Serverless is not free of cost — it trades infrastructure concerns for a different set of problems.

• Monitoring and debugging are harder. Serverless applications are distributed and event-driven, and run in proprietary environments. Tracking an execution flow across many function invocations is harder than reading a single server's logs. Distributed tracing (for example AWS X-Ray), centralized logging, and OpenTelemetry are typical mitigations.
• Security has its own shape. OWASP notes that serverless applications are vulnerable to variations of traditional attacks plus serverless-specific ones, including "denial of wallet" — an attacker triggering many executions to inflate your bill. Insecure code and over-permissive permissions are common risks.
• Vendor lock-in. Applications are locked to a specific provider by default. Because of the high level of abstraction, you cannot configure the underlying environment, and a provider's managed services often only trigger that same provider's functions. Migrating a serverless workload to another cloud is difficult; designing from the start with multi-cloud in mind helps.
• Limits for sustained or heavy compute. High-performance or long-running workloads can hit resource limits (maximum memory, CPU, runtime). For sustained, predictable resource usage, bulk-provisioned servers are often more cost-effective than a per-execution model.

Anti-patterns to avoid

• Grain of sand. Making functions excessively small increases complexity, operational overhead, and performance inefficiency. There is an optimal level of modularization — split functions along real, stable boundaries, not into the smallest possible pieces.
• Lambda pinball / distributed monolith. When functions invoke each other in long fragmented chains, you get added latency, harder debugging, and reduced observability — effectively a distributed monolith. Prefer clear boundaries between functions and native service integrations over long chains of inter-function calls.

When should you use serverless?

Serverless is a good fit when:

• Your workload is event-driven — webhooks, queue messages, scheduled jobs, image or file processing.
• Your traffic is bursty or unpredictable — spikes that would wastefully idle always-on servers.
• You want to ship small units quickly without managing infrastructure.
• You can tolerate provider lock-in or design for portability from the start.

It is a weaker fit when:

• You need sustained, predictable, high-volume compute where a fixed server is cheaper.
• You run long-running or resource-heavy workloads close to platform limits.
• You have strict multi-cloud or portability requirements and cannot accept lock-in.

As a rule of thumb, reach for serverless when the platform's automatic scale and pay-per-use model align with an event-driven workload — and prefer fixed servers when you have steady load that would run 24/7 anyway.

FAQ

What does "serverless" actually mean?

Serverless means you, the developer, never provision or manage servers. The cloud provider runs your application code and handles capacity, scaling, and availability. The name is a slight misnomer — servers still exist — but they are entirely managed by the provider on your behalf.

What is Function as a Service (FaaS)?

FaaS is the core execution model of serverless. You deploy a single function to a platform (such as AWS Lambda, Azure Functions, Google Cloud Functions, or Cloudflare Workers), the platform invokes it on events, scales it automatically, and bills you for actual execution time rather than idle capacity.

Is serverless cheaper than traditional servers?

Not always. For event-driven or bursty workloads, pay-per-use is often cheaper because you stop paying for idle capacity. But for sustained, predictable, high-volume compute, a traditional provisioned server or VM can be more cost-effective.

What are the main downsides of serverless?

The main trade-offs are harder monitoring and debugging in distributed environments, a different security surface (including denial-of-wallet attacks), strong vendor lock-in that makes migration difficult, and resource limits that can hurt long-running or heavy compute workloads.