What Are Serverless Functions and How Do They Work

Takeaways

• A serverless function is a small, stateless piece of code that a cloud provider runs on demand in response to an event, then shuts down when the work is finished.
• You pay only for the milliseconds your code runs. The provider handles servers, scaling, and capacity planning.
• Cold starts are the main performance penalty. The first request into a new environment waits while the provider builds it.
• Serverless functions fit spiky, event-driven workloads. Microservices fit persistent connections and steady-state throughput.
• Telnyx Edge Compute runs serverless functions inside the telephony network, cutting cross-provider hops for webhook-driven voice and messaging apps.

How serverless functions work

Every serverless invocation follows the same five steps.

1. An event fires. An HTTP request hits an endpoint, a message lands in a queue, a file is uploaded to object storage, a webhook arrives from a voice or messaging API, or a timer reaches its scheduled minute.
2. The provider allocates compute. The platform finds capacity, pulls your code and runtime into a container or isolate, and initializes the execution environment.
3. Your function executes. The runtime passes the event payload to your handler. Your code runs, calls whatever APIs or databases it needs, and produces a result.
4. The result returns. The platform sends your response back to the caller or passes it downstream to the next service.
5. Resources are released. The environment is frozen or torn down. Billing stops.

Step two is where cold starts come from. If no warm environment is available, the provider has to build one from scratch, and the request waits. That wait can be a couple hundred milliseconds for a small Python function or several seconds for a heavy Java function loading large dependencies. A systematic review of cold start latency in serverless computing catalogs how much this varies across providers, runtimes, and package sizes.

When a second request arrives while the environment is still alive, the platform skips steps two and five entirely. That is a warm invocation, and it typically returns in single-digit milliseconds of platform overhead. Most production traffic is warm. The problem is that the requests most likely to be cold are the ones on the edges of your traffic pattern, which are often the ones a real user is waiting on.

A serverless function is a small, stateless piece of code that a cloud provider runs on demand in response to an event, then shuts down when the work is finished. You write the function. The provider handles the servers, the scaling, and the capacity planning. You pay only for the milliseconds your code actually runs.

Servers still exist. You just never touch them.

This model is called function-as-a-service, or FaaS. AWS Lambda is the most widely used example, which is why "Lambda function" and "serverless function" are often used interchangeably. Azure Functions, Google Cloud Run functions, Cloudflare Workers, Vercel Functions, and Telnyx Edge Compute all offer the same core idea with different tradeoffs.

Serverless is no longer a niche. According to Datadog's serverless research, more than 70% of its AWS customers, 60% of its Google Cloud customers, and close to 50% of its Azure customers run at least one serverless service.

Serverless functions vs microservices

Serverless functions and microservices both break an application into smaller pieces, but they sit at different levels of granularity and carry different operational costs. Microservices are independently deployable services that own a business capability and usually run continuously. Serverless functions are single units of work that exist only while they execute.

The practical rule: choose serverless functions for spiky, event-driven work with short execution times. Choose microservices when a component needs persistent connections, long-running processes, or predictable steady-state throughput. Most real systems use both.

Benefits of serverless functions

No infrastructure management. You do not provision instances, patch operating systems, or size clusters. The provider absorbs that work, which is why small teams can ship production services without a platform engineering function.

Pay-per-use pricing. Billing is tied to invocations and execution time rather than provisioned capacity. A function that runs a few thousand times a day costs a few thousand invocations, not a month of reserved hardware.

Automatic scaling. A function goes from zero to thousands of concurrent executions without anyone touching a console. Traffic spikes that would require capacity planning on a fixed fleet are handled by the platform.

Language flexibility. Every major platform supports several runtimes, so teams can pick the right language per function instead of standardizing on one stack for the whole system.

Faster time to market. Deployment is a single command against a single artifact. There is no cluster to configure, no load balancer to attach, and no autoscaling policy to tune before the first request.

Challenges and limitations

Cold starts. The first request into a new execution environment pays an initialization penalty. Runtime choice, package size, and dependency loading all affect how large that penalty is. For batch jobs it does not matter. For a voice application where a caller is on the line, it does.

Vendor lock-in. Functions themselves are portable. The triggers, bindings, IAM policies, and event schemas around them usually are not. Rewriting a Lambda-based system for another cloud is mostly a rewrite of everything except the handler bodies. Mike Roberts' serverless architectures guide covers this tradeoff in detail.

Monitoring difficulty. There is no host to SSH into and no persistent process to attach a profiler to. Useful serverless observability means tracking invocation counts, error rates, throttles, compute duration, and cold start rate as first-class metrics, then stitching traces across functions that never share a process.

Execution time limits. Every platform caps how long a single invocation can run. AWS Lambda allows a maximum of 900 seconds, or 15 minutes. Limits differ across providers and plans, so check current documentation before designing anything long-running.

Security surface. More functions means more entry points, more secrets to inject, and more IAM policies to keep least-privilege. Payload validation and request signing belong at the function boundary, not deeper in your stack.

Distance. This one gets overlooked. A function is only as fast as the round trips it makes. If your compute lives in one provider's region and the event originated on another provider's network, you pay for that geography on every single invocation, cold or warm.

Common use cases for serverless functions

• Web and API backends. HTTP-triggered functions behind an API gateway, one function per route or resource.
• Webhook handling. Receiving, validating, and forwarding callbacks from third-party platforms. Voice and messaging webhooks are a strong fit because they are bursty and latency-sensitive.
• Image and media processing. Resize, transcode, or watermark on upload, triggered by an object storage event.
• IoT event handling. Fleets of IoT devices emit small, frequent, independent events, which maps almost exactly onto the function execution model.
• Data ETL. Reshape records as they land, fan out across a queue, and write to a warehouse without maintaining a job cluster.
• Scheduled tasks. Cron replacements for cleanup, reconciliation, and report generation.
• AI inference endpoints. Wrapping a model behind an on-demand endpoint. See serverless AI for where this model helps and where GPU cold starts and memory ceilings get in the way.

Many of these overlap with broader edge computing use cases, where the deciding factor is not whether code can run on demand but how far it sits from the data it processes.

Serverless function providers compared

Seven platforms cover most of what teams actually deploy. Free tiers exist across all of them, though limits change often, so confirm current allowances in each provider's own pricing documentation before you budget.

AWS Lambda

The default answer for most teams and the reason "Lambda" became shorthand for the whole category. Lambda runs Node.js, Python, Java, Go, Ruby, and .NET, plus custom runtimes through Lambda layers. It supports synchronous invocation, asynchronous invocation, and event source mappings from queues and streams. Cold starts are its most-discussed weakness, particularly on Java and .NET, which is why AWS built SnapStart. Maximum execution time is 15 minutes. The ecosystem around it is the deepest of any FaaS platform, and so is the lock-in.

Azure Functions

Azure Functions is built around triggers and bindings, a declarative model where you attach input and output connections to a function without writing client code for each service. That makes wiring a function to Blob Storage, Cosmos DB, Service Bus, or Event Hubs unusually short. The Flex Consumption plan is the current serverless hosting option, and the .NET tooling is the strongest of any provider. Azure serverless functions are the natural choice if your organization already runs on Microsoft infrastructure.

Google Cloud Run functions

Formerly Google Cloud Functions, now Cloud Run functions after Google folded the product under the Cloud Run umbrella. It deploys as a Cloud Run service and uses Eventarc for event delivery, which means a function and a container service share one runtime and one scaling model. Go support is first-class, Firebase integration makes it the path of least resistance for mobile backends, and the Cloud Run overlap gives you an escape hatch when a function outgrows the function shape.

Cloudflare Workers

Workers took a different architectural route. Instead of containers, it runs V8 isolates, the same lightweight sandboxes Chrome uses to separate browser tabs. Thousands of isolates share one runtime process, and Cloudflare states that a Worker loads in roughly five milliseconds, which it triggers eagerly during the TLS handshake so the function is warm before the request arrives. That is the basis of the zero cold start claim. The tradeoff is the runtime itself. You get a Web API surface rather than full Node.js, so some libraries will not run.

Vercel

Vercel is the shortest path from a Next.js application to production. Next.js serverless functions deploy from the same repository as the frontend with no separate pipeline, which is most of the appeal. Worth knowing before you architect around it: Vercel's own documentation states that "Edge Functions are deprecated. Use Vercel Functions with the Node.js runtime instead". Both runtimes now run on Fluid compute, which keeps warm instances serving concurrent requests the way a long-running server would. That cuts cold starts and cost, but it is a meaningfully different execution model than the edge runtime it replaced. Note that the deprecation applies to standalone Edge Functions, not to Routing Middleware, which still uses the edge runtime by default.

OpenFaaS

The answer for open source serverless functions. OpenFaaS runs on your own Kubernetes cluster, packages functions as OCI-compatible container images, and gives you an API gateway that handles invocation, autoscaling, and metrics. You get no vendor lock-in, full control over the runtime, and the ability to run functions anywhere Kubernetes runs. You also inherit the entire operational burden that managed FaaS was invented to remove. Check the licensing before you plan around Community Edition. Per OpenFaaS plans and pricing, personal use is free, commercial use carries a 60-day limit, and production use is scoped to a 60-day evaluation. CE also caps you at 15 functions, one namespace, and five replicas per function. Production workloads need OpenFaaS Standard or Enterprise.

Telnyx Edge Compute

Telnyx Edge Compute runs functions on edge nodes inside the Telnyx global network, the same network that carries Voice, Messaging, AI, IoT, and Cloud Storage traffic. It supports JavaScript, TypeScript, Python, Go, and Java on Quarkus, deploys through a single CLI command, and scales automatically with no region or capacity configuration. The runtime is built for fast initialization to keep cold starts minimal.

Billing is based on function requests and CPU time. As of July 2026, the published rates are 3.6 million requests and 36 million CPU milliseconds free per month, then $0.21 per million requests and $0.014 per million CPU milliseconds. Pricing is subject to change, so see the Edge Compute pricing documentation for current rates. As of July 2026, Edge Compute is available in North America with global expansion in progress.

Serverless functions in practice

The webhook proxy is the pattern that shows why placement matters. Telnyx publishes a working Python example, edge-compute-webhook-proxy-python, that receives Voice and Messaging webhooks at the edge and does four things before your backend ever sees the request.

1. Validate the payload. Reject malformed or unauthenticated events at the edge instead of paying to move them across the network.
2. Enrich with a timestamp. Record when the event was received, not when your backend got around to it.
3. HMAC-sign the request. Your backend can verify the payload came from your proxy and was not modified in transit.
4. Forward to your backend. Send the enriched, signed event on to wherever your business logic lives.

Telnyx Edge Compute functions use a straightforward async handler signature. Simplified, the shape looks like this:

import json

async def handler(request):
  try:
    event = await request.json()
    # 1. validate, 2. enrich, 3. sign, 4. forward
    return Response(
      json.dumps({"status": "accepted"}),
      headers={"Content-Type": "application/json"},
    )
  except Exception as error:
    print(f"Webhook error: {error}")
    return Response(
      json.dumps({"error": "Invalid webhook"}),
      status=400,
      headers={"Content-Type": "application/json"},
    )

Three serverless properties are doing the work here. The function is event-driven, so nothing runs until a webhook arrives. It is stateless, so every invocation is independent and any two can run concurrently. And it auto-scales, so a burst of a thousand simultaneous calls needs no capacity change. Clone the full example from the repository to run it end to end.

How Telnyx runs serverless functions at the edge

Physics is the real constraint. Every millisecond your event spends crossing a network is a millisecond your application cannot get back, and no amount of runtime optimization recovers distance.

That is the problem with running webhook handlers for real-time voice and messaging on a general-purpose cloud. An inbound call arrives on your telephony provider's network. The webhook crosses the public internet to a function in a cloud region. The function calls back to the telephony API to answer, play audio, or transfer. You have paid for two cross-provider trips before any business logic executes, and you are managing two vendors, two billing relationships, and two sets of failure modes to do it.

Telnyx Edge Compute removes the hop by putting the execution layer inside the network where the events originate. Functions run on Telnyx edge nodes on the same infrastructure that carries Voice API and SMS API traffic, with direct access to those APIs from inside the function. Provision numbers, route calls, handle webhooks, and run your logic on one platform, under one contract, with one support path.

The same argument applies to AI inference. Wrapping a model behind an on-demand endpoint is a standard serverless use case, but a voice agent that transcribes audio, calls a model, and speaks a response pays network cost on every leg. Edge Compute functions run on the network that already carries that AI traffic, with direct access to the Telnyx AI APIs from inside the function, so the inference call is not another vendor hop.

The economics follow the same logic. You are not paying a cloud provider for compute and a CPaaS for connectivity, then paying again in egress every time the two talk to each other.

For teams building real-time voice and messaging applications, that consolidation is the difference between an architecture you can reason about and a stack you are constantly translating between.

FAQ