Serverless Computing Explained: When It Fits

Serverless computing means you upload your code and the cloud provider runs it only when it is needed. You don't manage servers, and you pay for the time your code actually runs, not for machines sitting idle. It suits short, bursty tasks well, and suits long, steady workloads less well.

There are still servers, of course. You just don't see, patch or size them.

How serverless computing works

The most common form is "functions as a service". You write a small function, such as "resize this photo" or "send this invoice email", and connect it to a trigger.

A trigger is the event that starts the function. Examples:

• A web request arrives.
• A file is uploaded to cloud storage.
• A message lands in a queue.
• A timer fires, like "every night at 2am".

The provider starts a copy of your function, runs it, and shuts it down. If 1,000 requests arrive at once, it starts many copies. If none arrive, nothing runs.

The big three services are AWS Lambda, Azure Functions and Google Cloud Run functions. For Malaysian businesses, AWS opened its Asia Pacific (Malaysia) Region in August 2024, so you can keep workloads in-country if that matters to you.

How you pay

Serverless billing is based on how many times your code runs and for how long. AWS Lambda, for example, bills compute time in 1-millisecond steps, weighted by how much memory you give the function.

There is also a free tier. Lambda's includes one million requests and 400,000 GB-seconds of compute per month. A GB-second is one gigabyte of memory used for one second.

That is why serverless can be very cheap for small or irregular workloads. A clinic's appointment reminder system that runs a few hundred times a day may cost very little.

Where serverless fits well

Serverless is a good match when work comes in bursts or on events:

• Background jobs: resizing images, generating PDFs, processing uploaded files.
• Simple APIs: a booking form or a small mobile app back end with uneven traffic.
• Scheduled tasks: nightly reports, data clean-up, sending reminders.
• Glue between systems: when an order is paid in your shop, update stock and notify the warehouse.
• Spiky traffic: a campaign or 11.11 sale where traffic jumps for a few hours.

The main business benefit is less operations work. Nobody has to patch operating systems or guess server sizes for a peak.

Where it doesn't fit

Serverless has real limits. Using AWS Lambda as the example, from its published quotas:

• Time limit: a standard function can run for at most 15 minutes per call. Long jobs need to be split up, run elsewhere, or use newer AWS options such as Lambda Managed Instances (up to 90 minutes for some invocation types) or durable functions.
• Memory limit: 128 MB to 10,240 MB per function.
• Concurrency: the default quota is 1,000 copies running at once per region, which can be raised. As of October 2026, AWS says brand-new accounts start with a lower limit that it raises automatically as you use the service.

Other trade-offs to know:

• Cold starts: when a function hasn't run for a while, the first request can be slower while the provider starts it up. For most back-office tasks this doesn't matter. For a payment page, test it.
• Steady heavy load can cost more: if your code runs flat out all day, a reserved server or container is often cheaper than paying per millisecond.
• Lock-in: triggers, permissions and tooling differ between providers, so moving later takes work.
• Harder debugging: work is spread across many short-lived functions. You need good logging and tracing; see observability vs monitoring.
• No long-lived state: Lambda is designed for short tasks that don't keep state between calls, so data must live in a database or storage.

Serverless vs servers vs containers

	Your own servers / VMs	Containers	Serverless functions
You manage	OS, patching, scaling	Images, cluster (or use a managed service)	Just your code
You pay for	Machines, running or not	Cluster capacity	Each run and its duration
Best for	Steady, long-running work	Mixed apps, portability	Short, event-driven tasks

Many businesses end up mixing them: a main app in containers, with serverless functions for background jobs.

Security basics

Serverless doesn't remove security work; it shifts it. The provider secures the servers. You still own your code, permissions and data.

• Give each function only the permissions it needs.
• Keep secrets in the provider's secret manager, not in code.
• Check your third-party libraries for known vulnerabilities.
• If you handle personal data, remember Malaysia's PDPA still applies, wherever the code runs.

Our guide to cloud-native security best practices goes deeper.

How to start

1. Pick one low-risk, event-driven task, such as nightly report generation.
2. Build it as a function, with logging and alerts from day one.
3. Watch the bill and the performance for a month.
4. Compare the cost against running it on a small server.
5. Expand only where the numbers and the fit make sense.

The bottom line

Serverless computing is a strong choice for short, bursty, event-driven work, and it removes a lot of server admin. It is a weaker choice for long, heavy, steady workloads. Treat it as one tool in the toolbox, not a rule for everything.

Quick answers

Is serverless really free of servers?

No. The servers exist, but the cloud provider runs, patches and scales them. You only deploy code.

Is serverless cheaper than a normal server?

For low or irregular traffic, usually yes, because you pay only when code runs. For heavy, constant workloads, a reserved server or container is often cheaper.

What is a cold start?

It is the extra delay on the first request after a function has been idle, while the provider starts a fresh copy. Later requests are faster.

Can I run serverless in Malaysia?

Yes. AWS has a Malaysia region, launched in August 2024, and other major providers also offer regions nearby. Check which services are available in the region you pick.