Function as a Service (FaaS)

FaaS full form and where it fits

FaaS stands for Function as a Service. It is the core of what is usually called serverless computing. There are still servers, but the cloud provider runs, patches and scales them. You upload a function, tell the platform what should trigger it, and pay mainly for the time it actually runs.

How function as a service works: an example

Say users upload profile photos to your app, and each photo needs to be resized into three sizes.

1. A user uploads a photo to cloud storage.
2. The upload event triggers a function.
3. The platform starts an instance of the function, which resizes the image and saves the three versions.
4. The function finishes, and the instance is shut down or kept warm briefly for the next request.

If one photo arrives, one function runs. If a thousand arrive at once, the platform runs many copies in parallel. Nobody had to size a server for the peak.

Common triggers include HTTP requests, file uploads, messages on a queue, database changes, and schedules, such as a report generated every night.

FaaS vs containers vs virtual machines

• Function as a Service: you manage only your function code. It runs only when triggered and is billed per invocation and run time. It can have cold starts. Best for short, event-driven tasks.
• Containers: you manage your code, its runtime and the container image. They usually run continuously, though some platforms can scale them to zero. Billed for running capacity. Best for long-running services and APIs.
• Virtual machines: you manage the operating system, patches and scaling as well as your code. They run continuously and are billed per running server. Best for legacy applications or when you need full control of the operating system.

When FaaS is a good choice

• Spiky or unpredictable traffic, where paying for idle servers is wasteful.
• Background jobs: image processing, sending emails, generating PDFs, syncing data.
• Glue between services, such as reacting to a payment provider's webhook.
• Scheduled tasks that run for a few seconds several times a day.

Trade-offs and pitfalls

• Cold starts. A function that has not run recently can take noticeably longer to respond the first time. This matters for user-facing requests.
• Time and memory limits. Functions have a maximum run time. Long video processing or heavy data jobs may not fit.
• No local state. Each run starts fresh, so state has to live in a database, cache or storage.
• Vendor lock-in. Triggers, permissions and deployment are provider-specific, so moving to another cloud takes real work.
• Cost at steady high load. Pay-per-use is cheap for bursts, but a function that runs constantly can cost more than a server.
• Debugging and monitoring. Tracing a problem across many small functions needs good logging from the start.

What to ask your development team

• Which parts of our system are event-driven and short-lived enough for FaaS?
• How much do cold starts affect response times, and does that matter here?

If you are weighing serverless functions against containers or servers for a new system, our custom software development team can help you choose.