What is serverless computing?

Serverless computing is a way of running software in the cloud where the provider looks after the servers completely and you pay for the computing you actually use. The servers still exist. You never see, size or patch them.

What the provider takes on

Each of the large providers defines the term in much the same way. Google Cloud says serverless does not eliminate servers: the provider is responsible for setting up, managing and scaling the infrastructure that runs your code. AWS describes its Lambda service as running code without provisioning or managing servers, with server maintenance, capacity, scaling and patching handled for you. Microsoft calls the model functions as a service: you deploy your code and the service runs it automatically.

How it works

A developer writes a small piece of code, called a function, that does one job. The function is tied to a trigger, such as a file being uploaded, a web request arriving or a time on a schedule. When the trigger fires, the provider starts the function, runs it and shuts it down.

If many triggers fire at once, the provider runs more copies without anyone asking. When nothing is happening, Google notes that the service scales back down to zero. Billing follows the same pattern: you are typically charged for the resources used while the code runs, and not for idle capacity.

Google compares it to mains water. You could dig a well and maintain the plumbing yourself, or you can turn on the tap, take what you need and pay for what you used.

How it differs from renting a server

A rented cloud server stays switched on, and allocated to you, whether or not it is doing anything. Adding capacity when things get busy is your job, or your IT provider’s. With serverless, both of those move to the cloud provider.

Where it fits, and where it does not

Google’s examples of good uses are jobs that run briefly and now and then: producing a report on a schedule, passing new customer records from one business system to another, or resizing an image when it is uploaded.

The same page lists the drawbacks:

• It is a poor fit for long-running processes and for work that needs a very fast response every time.
• A function that has not run for a while can be slow to start. This is called a cold start.
• Providers do things differently, so moving a serverless application from one to another can be complex.
• Developers see less of the underlying system, which makes some faults harder to trace.

What it means for your business

You are most likely to meet the word when a developer proposes it for an automation or for joining two systems together. Worth asking: what will it cost at the volume we expect, what happens if that volume grows tenfold, and how much work would it be to move elsewhere?

Handing over the servers does not hand over everything. AWS states that customers remain responsible for managing their data, and the Australian Signals Directorate says the same of any cloud service: who has access, and how they sign in, stays with you.

For the kind of work serverless is often used for, see automation and system integrations.