BYD TechThe short answer
Serverless means running your code without managing servers yourself. You upload functions or an application, the cloud provider runs them when requests arrive, scales them automatically, and bills for what is used rather than for machines sitting idle. There are still servers, you just do not operate them. It suits spiky or low traffic and event-driven jobs well, and suits long-running or very steady heavy workloads less well.
Key points
- You write the code. The provider runs, scales and patches the servers.
- Billing follows use, so quiet periods cost little.
- Good for websites, APIs with uneven traffic, and event-driven jobs.
- Watch for cold starts, time limits and costs at very high, steady volume.
- Lock-in grows with the number of provider-specific services you use.
How serverless works
- You write a function or an application and deploy it to the provider.
- A request or event arrives: a page view, an upload, a message.
- The provider starts your code, runs it, and returns the result.
- With more traffic it runs more copies at once. With none, it runs nothing.
- You are billed for the requests and the time your code ran.
The idea extends beyond functions. Databases, queues, storage and authentication are offered the same way, which is why a small team can run a real product without anyone looking after servers.
Where it fits well
- Websites and static pages, served from a global network.
- APIs with uneven traffic, quiet at night and busy in the day.
- Event-driven work: resizing an upload, sending an email, processing a webhook.
- Scheduled jobs that run for a few minutes.
- Early products, where traffic is low and unpredictable.
The trade-offs
| Trade-off | What it means |
|---|---|
| Cold starts | A function that has been idle can take longer to answer its first request |
| Time and memory limits | Long-running jobs may need a different setup |
| Cost at steady high volume | Paying per request can cost more than a server that is always busy |
| Debugging | Logs and traces are spread across services |
| Lock-in | Each provider-specific service makes moving harder |
| Connections | Many short-lived functions can overwhelm a traditional database without pooling |
How to decide
- Describe the traffic: steady, or spiky and quiet in between?
- List the jobs: short requests and events, or long-running work?
- Estimate cost at today’s volume and at ten times it.
- Decide how much provider lock-in you accept, and keep the core logic portable.
Many products mix both: a serverless front end and functions, with a regular database and perhaps one long-running worker. The overall shape is in Monolith vs microservices and What is a tech stack?. In web app development the cloud account is in your name, whichever model fits.
Sources
Checked when this guide was written.
