Mirco Cloud Primer
Photo by Erik Mclean on Pexels
Imagine a vending machine sitting quietly in a hallway. It doesn't run constantly, doesn't use electricity to do anything useful while no one is around, and doesn't need a person standing next to it waiting for a customer. The moment someone presses a button and inserts payment, it wakes up, dispenses exactly one item, and returns to sitting quietly. A cloud function behaves almost exactly the same way, except what it "dispenses" is a small piece of computer code running in response to something that just happened.
This article explains what a cloud function is, what the related term Function as a Service (FaaS) means, and when this event-driven style of computing is the right choice.
What a cloud function actually does
A cloud function is a small, self-contained piece of code that a cloud provider runs automatically whenever a specific event occurs — someone uploading a file, a message arriving in a queue, a scheduled time being reached, or a request hitting a particular web address. You don't keep a computer running and waiting for that event; the provider only starts up the environment needed to run your code at the exact moment it's needed, then shuts it back down afterward.
Where the term 'Function as a Service' comes from
Function as a Service, or FaaS, is the formal name for this pattern: the cloud provider offers individual functions as a ready-to-use service, handling everything around your code — the server, the operating system, the scaling — so you only have to think about the function itself. FaaS is one specific, popular form of the broader idea of serverless computing, which covers several kinds of services that free you from managing servers directly.
Why this is considered 'serverless'
Servers are still very much involved behind the scenes — someone's physical hardware always runs the code eventually — but the term serverless refers to the fact that you, as the person writing the function, never have to provision, patch, or manage any server yourself. That responsibility shifts entirely to the provider, which is a deliberate application of the shared responsibility model used throughout cloud computing.
The 'cold start' most beginners eventually notice
Because a cloud function isn't kept running all the time, there's sometimes a short delay the first time it's triggered after a period of inactivity, while the provider prepares a fresh environment to run it in. This brief delay is called a cold start, and while it's usually measured in a fraction of a second to a couple of seconds, it's an important limitation to understand before relying on cloud functions for something that needs to respond instantly every single time.
Cloud functions compared with other compute options
- A virtual machine stays running continuously and costs resources even when idle; a cloud function only runs — and typically only gets billed — while it's actually executing.
- A container is usually kept running to serve ongoing traffic; a cloud function is built around short, individual triggers rather than continuous operation.
- Both containers and virtual machines require more decisions about capacity in advance; cloud functions largely remove that decision by scaling automatically with demand.
Good use cases for cloud functions
Cloud functions tend to shine for small, event-driven tasks: resizing an image right after it's uploaded, sending a confirmation email after an order is placed, validating data as it arrives, or running a scheduled cleanup job once a day. They're a poor match for workloads that need to run continuously for long stretches, or that can't tolerate even the small delay of an occasional cold start.
How billing typically works, in concept
One of the appealing aspects of cloud functions is that you're generally only billed for the time your code is actually executing, measured in small fractions of a second, rather than for a server sitting idle between triggers. This is a meaningful shift from renting a virtual machine that keeps costing money whether it's busy or not. That said, a cloud function that's triggered extremely often, or that runs for a long time on each trigger, can still add up — it isn't automatically the cheapest option for every situation, just a different cost pattern built around actual usage rather than reserved capacity.
Common mistakes beginners make
- Trying to use a cloud function for a job that needs to run continuously, rather than in short, triggered bursts.
- Not accounting for cold start delays in situations where instant responses matter every time.
- Writing one giant function that tries to do many unrelated things, instead of several small, focused functions.
- Assuming 'serverless' means no server is involved anywhere, rather than understanding that the provider manages the server on your behalf.
Frequently asked questions
Do I need to manage a server to use a cloud function?
No — managing the server is exactly what the cloud provider takes care of with a cloud function, which is why this approach is often grouped under serverless computing.
What does 'cold start' mean for a cloud function?
A cold start is the brief extra delay that happens when a cloud function hasn't run in a while and the provider needs to prepare a fresh environment for it before your code can execute.
Is Function as a Service the same as serverless computing?
Function as a Service is one specific form of serverless computing — the one built entirely around small, event-triggered functions — while serverless computing is the broader category that also includes other managed, server-free services.
Can a cloud function run all the time, like a website?
A cloud function is designed for short bursts of work triggered by specific events, not for staying on continuously, so a long-running website is usually better served by a virtual machine, a container, or a platform-as-a-service option instead.
Related reading
Sources
- NIST SP 800-145 — The NIST Definition of Cloud Computing
- Documentation published by major public cloud providers (consulted October 2026)