Serverless

Serverless is a cloud computing model where code runs inside functions fully managed by a provider, with no server to provision, patch or scale manually. Servers still exist somewhere, the name refers to the fact that a developer never has to think about them: code is deployed, the provider runs it on demand, and capacity scales up or down automatically with traffic, down to zero when nothing is happening.

‍

What is serverless?

In a serverless architecture, an application is broken into small, independent functions that each run in response to an event, an HTTP request, a database change, a scheduled trigger, rather than running continuously on a server waiting for traffic. The provider allocates the compute needed for each invocation, runs the function, then tears the environment down. Billing follows the same logic: instead of paying for a server to stay on 24 hours a day, a team pays only for the milliseconds of actual execution.

The model shifts responsibility: a team no longer manages an operating system, security patches or capacity planning, and focuses purely on the business logic inside each function.

‍

How a serverless function works

A function is written to handle a single event and deployed to a provider, which wires it to a trigger. A minimal example on Supabase Edge Functions:

Deno.serve((req) => {
    return new Response("Hello, world");
});

No server configuration accompanies this code: deploying it is enough for the provider to expose an endpoint, invoke the function on each request, and scale the number of concurrent executions automatically as traffic grows.

‍

Types of serverless services

• FaaS (Function as a Service): individual functions triggered by events, such as AWS Lambda or Supabase Edge Functions.
• BaaS (Backend as a Service): managed backend building blocks, database, authentication, storage, exposed through an API, such as Supabase or Firebase.
• Serverless databases: databases that scale storage and compute automatically and bill by usage rather than a fixed instance size.
• Edge functions: serverless functions deployed to run physically close to the visitor, reducing latency for global audiences.

‍

Serverless vs a traditional server

‍

Best practices and common pitfalls

Serverless favours workloads that spike unpredictably or sit idle most of the time, since a traditional server paid for around the clock would waste money in those conditions. The main technical pitfall is cold start latency: a function that has not run recently can take longer to respond on its first invocation, which matters for latency-sensitive requests. Vendor lock-in is also a real risk, since serverless functions are often written against a specific provider's triggers and APIs, making a later migration non-trivial. Keeping functions small and stateless, with any persistent data stored in a proper database rather than in the function itself, avoids most design mistakes.

‍

Serverless and application performance

Because serverless functions can be deployed at the edge, close to visitors around the world, they often reduce latency compared to a single traditional server in one region, which benefits both user experience and metrics like Time to First Byte. The trade-off is that cold starts can introduce occasional latency spikes, so latency-critical paths sometimes still warrant a persistently running service instead.

‍

Serverless at BeBranded

We reach for serverless functions and managed backends, Supabase, Firebase, Cloudflare Workers, when a project's workload genuinely fits that model, so clients avoid paying for idle server capacity or managing infrastructure they do not need. It is one of the foundations we consider for every web application we design.