When does serverless fit?
Serverless fits when work arrives in bursts, runs for seconds and can be written as a function that takes an event and returns a result. You pay for execution, the platform scales instances for you, and nobody patches servers. That suits webhooks, form handlers, image and file processing, scheduled jobs and APIs with uneven traffic.
It is a poor match for long jobs, steady heavy load, large in-memory workloads and anything that needs a persistent connection. For those, a container on an app platform or a small cluster is simpler and often cheaper. We tell you which side your workload falls on before writing code.
Which runtime should you pick?
| Runtime | Best for | Watch out for |
|---|---|---|
| AWS Lambda | Event-driven backends tied to other AWS services, queues, scheduled work | Cold starts, per-request gateway fees, deep AWS coupling |
| Cloudflare Workers | Low-latency logic at the edge, middleware, redirects, light APIs | Runtime limits, an API surface that differs from Node.js, storage choices |
| Vercel functions | API routes and server rendering next to a Next.js or Astro frontend | Execution limits, platform pricing at scale, tight tie to the framework |
| Azure Functions, Cloud Run | Teams already on Azure or Google Cloud, containers that scale to zero | Provider-specific triggers and configuration |
Platform limits and prices change often, so we check current documentation before committing to a design. Our pages on AWS, Cloudflare Workers and Vercel describe how we run each one.
What are the limits of serverless?
Long jobs: Functions have execution time limits. Work that runs for minutes or hours belongs in a queue-fed worker, a container job or a workflow service.
Cold starts: A new instance takes time to start, and heavy dependencies make it worse. Edge runtimes start faster, and smaller bundles help on Lambda.
Vendor lock-in: The functions are portable. The queues, event buses, auth and storage around them are not. We keep business logic in provider-neutral modules behind a thin handler and describe infrastructure in code, so switching is a contained job.
Database connections: Many short-lived instances can exhaust a relational database. Pooling, HTTP-based drivers or a managed proxy solve it, and we plan for it from the start.
Debugging: Distributed functions are harder to trace. We set up local emulation, structured logs and tracing early.
How do queues and cron fit in?
Most useful serverless systems are small functions joined by queues and schedules. A request writes a message and returns fast. A worker function reads the queue, retries on failure and moves poison messages to a dead-letter queue. Scheduled functions replace cron servers for reports, cleanups and syncs. We write idempotent handlers, because a queue can deliver the same message more than once.
How does cost behave?
Cost follows usage. A quiet internal tool can run for almost nothing. A busy public API often costs more per request than the same code on a reserved container once traffic is steady. The drivers to model are invocation count, duration and memory, gateway or edge request fees, data transfer, logs and the database behind the functions. We build a cost model from your traffic before you commit, and review real bills after launch. If cost is the main worry, our DevOps support services cover spend reviews.
How do we work?
We start with a short discovery on traffic shape, latency needs and what already runs. Then we deliver the first function path end to end, with deployment in code, alerts and a rollback, and extend from there. Serverless is one option inside our wider backend development services, so we pair it with containers or a classic service where that fits better. If you need someone to own the infrastructure side, you can hire a DevOps engineer.
