Serverless Function

What is a serverless function?

A serverless function is a small piece of code that a cloud provider runs on demand in response to an event, such as an HTTP request, a file upload or a queue message. You deploy the code; the provider provisions, scales and patches the servers, and you pay for execution rather than for idle machines. AWS Lambda is the example used on this page.

How a serverless function works

You write a handler and connect it to a trigger. When an event arrives, the platform needs an execution environment. If a ready one is free, it reuses it (a warm start). If not, it creates a new one: it downloads the code, starts the runtime and runs your initialization code, and only then calls the handler (a cold start). Each environment handles one request at a time by default, so more simultaneous requests mean more environments.

AWS defines concurrency as requests in flight at once and gives a simple formula: concurrency = average requests per second x average duration in seconds. At 100 requests per second and 500 ms per request, that is 50 environments.

Example

A shop stores product photos in a bucket. Each upload triggers a function that creates a thumbnail and writes it back. There is no server to keep running: during a bulk import hundreds of functions run in parallel, and overnight none run at all. A second function behind an API endpoint might serve the product catalogue to the website.

Limits that matter (AWS Lambda)

• Timeout: up to 900 seconds (15 minutes) per invocation. Longer jobs must be split or moved elsewhere.
• Memory: 128 MB to 10,240 MB, with CPU allocated in proportion.
• Concurrency: 1,000 concurrent executions per Region by default (an adjustable quota), shared by all functions in the account.
• Scaling rate: each function can add at most 1,000 execution environments every 10 seconds, so a very sudden burst can be throttled.
• Payload: 6 MB for a synchronous request or response.
• Cold starts: AWS says they typically affect under 1% of invocations and add from under 100 ms to over 1 second. Provisioned concurrency pre-initializes environments to reduce them.

Limits and defaults change, so check the current AWS Lambda quotas page before you size anything.

Common mistakes

• Assuming it scales without limits. The function may scale, but the database, third-party API or microservice behind it often cannot. A burst of functions can exhaust database connections.
• Judging speed by the average. Cold starts live in the tail. Look at p95 and p99 response times, see latency.
• Putting long jobs in a function. Anything near the timeout needs a queue or a different service.
• Never testing a burst. A function that is fine at 10 requests per second may throttle when traffic jumps; a spike test finds that.
• Configuring by hand. Memory, timeout and concurrency settings belong in code, see infrastructure as code.

Testing and monitoring serverless functions

Load test the public endpoint in front of the function, usually an API gateway, with a profile that ramps past your expected peak, and compare percentiles, error rates and throttling. LoadFocus load testing can send that traffic from 25 cloud regions with JMeter or k6; the Free plan covers 10 virtual users for 60 seconds. Remember that every test invocation is billed by your cloud provider. For the full method see performance testing serverless architectures. In production, API monitoring such as LoadFocus API monitoring (Free checks run every 5 minutes) shows how those endpoints behave over time, including the occasional slow first call.

FAQ

Are serverless functions really serverless?

No. Servers still run your code. The term means you do not provision, patch or scale them yourself.

What is a cold start?

The extra time taken when the platform has to create a new execution environment before it can run your handler. Later requests that reuse the environment skip it.

How is a serverless function billed?

Per request plus the execution time multiplied by the configured memory (GB-seconds) for AWS Lambda event functions. When no requests arrive, you pay nothing for compute.

When should I not use a serverless function?

For jobs longer than the timeout, for workloads that need steady very low latency on every request, or for traffic so constant and heavy that always-on servers cost less. Measure before deciding.