What Is Serverless Computing? Benefits and Use Cases

Is Serverless Really Serverless?

During a night shift, I was looking after a small webhook service that ran for only a few minutes each day. It had its own VPS, web server, monitoring, patching schedule, log rotation and backup routine. The service was idle most of the time. The operational work was not.

That was when what is serverless computing stopped being an abstract cloud term for me. Serverless is a way to run application code while a cloud provider handles much of the underlying infrastructure. The servers do not vanish. Your code still runs on machines; you simply do not manage their operating systems, physical capacity or much of the network and runtime layer.

My short definition is this: serverless runs application code as small units triggered by HTTP requests or events, instead of as a service that stays running all the time. The provider starts those units when needed, allocates resources and, depending on the pricing model, reduces or stops charges when they are idle.

Two different services often share the same label

When people say serverless, they often mean two related but different service categories. Separating them makes architecture decisions less foggy.

Function as a Service: FaaS

With FaaS, you upload application code as a function. An HTTP request, queue message, file upload or scheduled event can trigger it. AWS Lambda, Google Cloud Functions and Azure Functions are familiar examples.

A function does not have the same lifecycle as a service on a traditional VPS. It may run for a few seconds and exit. As traffic increases, the provider may start parallel execution environments; as traffic falls, unused environments can be removed.

Short-lived code. That is the central idea.

Backend as a Service: BaaS

Managed backend components such as authentication, object storage, databases, message queues and notification services are also commonly used in serverless architectures. Firebase, Amazon DynamoDB, Amazon S3 and managed identity services fit this broader category, even though providers do not all use the term in exactly the same way.

Choosing serverless does not mean buying every component from one provider. The more tightly your application depends on provider-specific services, the harder migration becomes. That trade-off is not automatically wrong, but I want to see it written down before building around it.

How it differs from a traditional VPS

When you rent a VPS, the operating system and services are your responsibility. You install Nginx, create an application user, apply security updates, watch disk usage and restart services when necessary. With serverless, much of that work moves to the provider. Your attention shifts to function code, data flow, permissions and application behavior.

This table does not mean serverless is always cheaper or better. A predictable, continuously running application may be simpler and less expensive on a modest VPS. For an API with irregular traffic, avoiding payment for idle capacity can be a real advantage.

When I compare these models, I also look at the resource and control trade-offs described in Cloud Server vs VPS: Pick the Right Hosting Model. The workload decides.

From request to function

A basic HTTP function usually follows this path:

1. A user or another service sends an HTTP request.
2. An API gateway or equivalent entry point routes the request to the appropriate function.
3. The provider prepares an execution environment or reuses a warm one.
4. The function runs and accesses a database, queue or another service.
5. A response is returned, and the execution environment may be shut down later.

The time between the first and last step affects the performance your user experiences. If the function has not been called for a while, a new execution environment may need to be prepared. That is a cold start. If an existing environment is reused, it is a warm start, and startup is usually quicker.

Cold-start behavior depends on the language, dependency size, memory setting and provider runtime. There is no honest single latency number for serverless. I do not make performance claims before measuring; I start with the traffic pattern in front of me, not somebody else’s benchmark.

Measure first.

Where serverless earns its keep

Less server maintenance

You do not have to handle operating system updates, physical disk failures, virtual machine capacity planning or basic network components. Operations do not disappear, though. Permissions, application releases, secrets, logs and cost monitoring remain your responsibility.

On the hosting side, small services often consume more time through maintenance than through application development. Moving one of them to a function service can remove the need to operate an entire VPS for a single endpoint.

That is a useful reduction in work, not magic.

Uneven traffic

A campaign, news post or periodic reporting service can receive radically different traffic throughout the day. Serverless functions can respond to these changes through managed scaling. Instead of reserving workers in advance, new execution environments are created as demand appears.

Automatic scaling is not infinite. Concurrency limits, API gateway quotas, database connection limits and queue capacity need to be considered together. If you increase the number of function instances but forget the MySQL connection pool behind them, scaling can hit the database with a hammer. I cover the basic connection and permission concerns in How to Install and Secure MySQL on a VPS.

Paying for actual use

Serverless pricing commonly depends on request count, execution time, allocated memory and additional services. That can work well for low or irregular traffic.

The function invocations are not the whole bill. Log storage, outbound data transfer, the API gateway, database reads and writes, and NAT can all add to the total. A small experiment can produce a surprisingly large invoice if you leave it running without monitoring or budget alerts.

I check the billing page before I check the dashboard.

Workloads that fit the model

Webhooks and small API endpoints

Payment notifications, Git repository events, form submissions and third-party webhooks are often good candidates. The handler receives a request, validates it, places data on a queue and returns a quick response.

Do not fill a webhook handler with long-running work. Image conversion, PDF generation and large reports are safer when the request writes a message to a queue and a separate worker function processes it.

File uploads and media processing

When a user uploads a file to object storage, a function can create a thumbnail, read metadata or start a virus scan. Since the workload appears when files are uploaded, an event-driven design may make more sense than a permanently running worker.

For large files and long video jobs, check the provider’s function duration limit, temporary disk space and memory limit. Not every media workload fits comfortably into serverless. Sometimes a queue-consuming VPS or container is the better choice.

Video is where simple diagrams tend to become expensive invoices.

Scheduled tasks

You can use scheduler services for nightly reports, old-record cleanup or pulling data from an external API. Instead of editing crontab on a server, the provider’s scheduler triggers the function.

Design these jobs to be idempotent. If the same event is delivered twice, records should not be corrupted and two copies of an email should not be sent. Assuming that a distributed system will execute a task exactly once is an expensive assumption (I have seen it more than once).

IoT and event processing

Sensor readings, queue messages and application logs can be passed to a function as events. The function can filter data, create an alert or write to a time-series database. With very high-volume, continuous streams, calculate queue, stream and storage costs together rather than looking only at the function price.

A small scheduler mistake I still remember

I pay particular attention to scheduled workloads because of a mistake I made several years ago. I added an extra asterisk to a cron expression. I thought a backup script would run hourly, but the incorrect expression triggered it every minute. Before long, roughly 40,000 notification messages had accumulated in the mail queue.

My first instinct was to restart the service. Fortunately, I looked at the logs and used journalctl to confirm that the script was running every minute. I stopped the script, separated the queued messages instead of deleting everything blindly, corrected the cron expression and watched it in staging for several hours.

A serverless scheduler removes the crontab typo, but not the class of problem. A wrong interval, a redelivered event, an automatic retry or two jobs running in parallel can still create unexpected costs and duplicate data. Setting up a scheduler is easy. Testing its behavior is the real work.

I still read the schedule twice.

The parts that can hurt

Cold starts and latency

If users expect consistently low latency on every request, cold starts may be unacceptable. Options such as provisioned concurrency can reduce the impact, but keeping capacity warm costs money.

Smaller function packages, fewer dependencies and less work during initialization are more basic improvements. Adding a large framework to one small endpoint simply out of habit can create unnecessary startup work.

State and database connections

Do not treat a function’s execution environment as a permanent disk. Temporary files may disappear when the environment is removed. Keep durable data in object storage, a managed database or another explicit storage layer.

Every new function instance opening new database connections can also become dangerous. Without a connection pool, queue or cache strategy, scaling can overwhelm the database. Behind a serverless application, there is still a data layer that needs careful design.

The database has not heard that your function is serverless.

Provider dependence

The more you use a provider’s event format, identity service, proprietary database queries or deployment tools, the more expensive migration becomes. That dependence is not always the wrong decision. For a small team, the speed gained from managed services may be worth the future migration cost.

Separate core business logic from provider-specific code, know how to export your data and test functions locally. When I adopt a new service, I ask myself, How would I move this back tomorrow?

Monitoring and debugging

An incident that you might trace on a VPS with journalctl, Nginx access logs and a process list can be spread across several services in a serverless system. Request IDs, correlation IDs, structured logs and distributed tracing become much more valuable.

A successful function response does not always mean the job finished successfully. A queue message may have failed, a database write may have rolled back or a third-party API may have timed out. Do not define success as HTTP 200 alone.

One green request is not a monitoring strategy.

Security checks I make

Not having SSH access to a server does not remove the attack surface. Define exactly which resources each function can access. An image-processing function should not have permission to write to an entire database when it only needs one bucket and one table.

• Do not put secrets in source code or plain-text configuration files.
• Apply least privilege separately to each function.
• Verify incoming webhook signatures and account for replay attacks.
• Set limits for request bodies, file sizes and execution time.
• Alert on failed invocations and unusual cost increases.
• Update dependencies regularly and remove unnecessary files from production packages.

Leaving serverless security entirely to the provider is not correct. The provider protects the physical infrastructure and platform; application permissions, data confidentiality and code security remain your responsibility.

Serverless, containers or a VPS?

I choose based on workload behavior, not technology fashion. A short-lived, event-triggered and stateless task is a strong serverless candidate. A service that keeps long-lived connections, needs custom system packages or runs for extended periods may be more comfortable in a container or on a VPS.

Containers do not remove all server administration, but they make applications easier to package and move. If you are running Docker on your own VPS, How to Install Docker on a VPS and Run Your First Container covers the basic security steps I start with.

If you need full control of the host, a predictable monthly cost, custom network configuration or a continuously running database, a VPS remains a strong option. Serverless is not a newer version of a server that is always better. It is an execution model for particular workflows.

The boring option is often the one I can operate at 3 a.m.

Before I run the first experiment

1. Write down the trigger: HTTP, queue, file event or scheduler.
2. Measure the longest expected execution time and memory requirement.
3. Design for retries, timeouts and partial failures.
4. Decide where durable data will live and define connection limits.
5. Estimate request, log, storage and network costs together.
6. Keep local testing, staging and production separate.
7. Test alerting, log search and the rollback procedure.

A small webhook or image-metadata handler is a sensible first experiment. Instead of testing in a production account with unlimited permissions, create a separate project, a budget alert and a narrowly scoped service account. After my cron mistake, I do not merely create schedulers and walk away; I monitor how often they run and what happens when a job fails.

Start small, and make failure visible.

Frequently asked questions

Is serverless free?

Usually not completely. Some providers offer free quotas for low usage, but you still need to check requests, execution time, logs, data transfer and database charges separately.

Do I need a VPS for a serverless application?

You do not need to rent a VPS for the function itself. If you need a private database, VPN, continuously running worker or a component your provider does not offer, part of the architecture can still use a VPS or container.

Can serverless handle high traffic?

It can, and automatic scaling is one of its strengths. Do not move a high-traffic workload to production until you have tested quotas, concurrency, database connections, queue capacity and cost limits together.

How can I reduce cold starts?

Start by shrinking the function package, removing unnecessary dependencies, reducing initialization work and choosing an appropriate runtime. Provider options for permanently warm instances can reduce cold starts further, but they add cost.

For my next small webhook, I will still compare the function estimate with the price of a modest VPS. Serverless may be the cleaner answer, but the numbers and the workload get the final vote.