Serverless architecture: what the provider manages
Follow a serverless image job, change where its result is saved, and see how cold starts, scaling, retries and service limits affect the design.
In a serverless architecture, a provider runs the infrastructure behind managed services and scales it within the service's rules. The application team still owns the code, permissions, persistent data, failure handling and resource settings. Servers still exist; their operation is delegated.
An uploaded image can trigger a function that creates a thumbnail. The provider supplies the environment that runs it. Your code still decides which image to read, where to save the thumbnail and what to do if the same upload is reported twice.
The thumbnail exists, but the status handler says the image has not been processed. In this illustrative example, the first function saved “complete” only in its own memory. The provider ran the next handler in another environment. Both executions worked; the application put a record where the second one could not find it.
Follow one image job#
A small image-processing design has four steps. Store an uploaded image as P42. Publish an event identifying that image. Run a handler that creates and saves its thumbnail. Save a completion record that a later status request can read. The identifier and sequence are a simplified example, not a production incident.
The handler is the function that receives the event and performs the work. Each run is an invocation. In function as a service (FaaS), the provider supplies its execution environment. Azure Functions documents triggers for uploaded files, timers, HTTP requests and queues. An event-triggered image job is one use; serverless does not require every application to be a chain of functions.
| Part of this design | Provider service supplies | Application team decides |
|---|---|---|
| Execution | Infrastructure and runtime execution under the chosen plan | Handler code, dependencies, resource settings and releases |
| Data | A storage service with a documented contract | Object identifiers, records, retention and access rules |
| Events | Transport and triggering under the selected delivery policy | Validation, safe repeated processing and the error path |
| Operations | Service metrics, logs and infrastructure controls | What to monitor, acceptable behaviour and when to intervene |
This division reduces infrastructure work; it does not decide whether P42 belongs to the caller or whether an oversized image is valid. AWS’s Lambda guidance still requires restricted execution permissions, idempotent code and attention to downstream capacity. Those are application decisions even when the runtime is managed.
What survives the next invocation#
The execution environment contains the runtime and its local memory. A later invocation may reuse it, start elsewhere as capacity grows, or run after the old environment has been removed. Changing where P42’s completion record lives changes which of those cases can read it.
Change the next invocation's environment
Illustrative example: one handler finished image P42 in environment A and saved a completion record. A later handler reads that record. Will it find it if the provider starts a different environment?
- Original A's memory
- P42: complete
- Next invocation's environment
- B selected; handler has not run
- Next environment's completion record in memory
- Handler has not read yet
- External store
- No completion record
A's memory contains P42's completion record. A new B cannot read that memory; reusing A can, while A survives. A completed external-store write lets either handler read the record. Enable JavaScript to compare reuse, scaling out and replacement.
Two invocations, one completed write and a successful, current external-store read. The choices are controlled counterexamples, not controls a real caller has over cloud scheduling. This models state location and initialisation; it does not model concurrent updates, store outages, redelivery, startup time or cost.
Try local memory with reuse first: the status read succeeds. Keep local memory and start B: the record is missing even though A still holds it. Replace A and its local record is lost. Move the completed write to the external store and repeat those choices: each handler can read it under the experiment’s stated successful-read assumption.
The lesson is about lifetime and visibility. A reusable connection or a cached static file can be useful inside an environment. A completion record needed after replacement belongs in storage with the required persistence contract. AWS Lambda’s lifecycle documentation describes retained environments, reuse and eventual termination; reuse is an optimisation, not a promise that business state stays available.
An external store can fail or return data under a consistency rule your application did not expect. Moving the record does not solve every failure. Choose how the write becomes visible, what a missing record means, and which operation is safe to repeat. The safe-retry guide follows a lost reply through those decisions.
Cold starts and scaling#
Before a new environment can run a handler, its runtime and code must be ready. The provider may initialise them or restore prepared state: Lambda SnapStart can restore an environment from a snapshot. Startup preparation before the handler is commonly called a cold start. Reusing a ready environment avoids that preparation; it does not eliminate the handler’s processing, network calls or storage wait.
In the experiment, B and the replacement for A initialise before their handlers; reused A is already initialised. The model gives no duration. Actual startup depends on the service, runtime, deployment and capacity settings. Lambda offers provisioned concurrency to prepare environments in advance; that is a separate setting with a cost, rather than a guarantee that every serverless invocation starts immediately.
Scaling also differs by product. Standard Lambda concurrency describes simultaneous in-flight invocations and their execution environments. A Cloud Run service instance can handle multiple concurrent requests. Do not assume one instance per request just because both services are described as serverless.
Cloud Run can scale an idle service to zero by default, or retain instances with a minimum setting. Azure Functions has multiple hosting plans, including always-warm and dedicated options. “Serverless” therefore does not tell you whether a selected plan has zero idle compute cost or what happens to the first request after inactivity.
Retries and downstream limits#
A function running once is different from an event being delivered once. Lambda’s asynchronous invocation contract allows duplicate events, including when the function returned no error. Other triggers have their own retry and acknowledgement rules. Check the actual trigger rather than attaching one delivery guarantee to every serverless service.
For P42, decide whether repeated thumbnail generation can safely replace the same output. That may be acceptable for a deterministic transform of one immutable image version. Sending a notification or charging a payment is a different effect and needs its own duplicate-handling design. The event-delivery experiment shows why a lost acknowledgement can cause repeated processing.
More handlers can also create more calls to the same database. Automatic compute scaling does not expand that database’s connection or write capacity. Cloud Run’s autoscaling documentation explicitly calls out backing-service limits. Measure the work those services can accept, bound concurrency where appropriate, and give queued work a defined expiry or failure path. Connection pooling explains the distinction between reusing a connection and increasing database capacity.
Serverless and microservices answer different questions#
Serverless describes a service’s operating model. Microservices describe how an application is divided into services that can be developed and deployed with suitable boundaries. A thumbnail service can use serverless compute; a serverless application can also keep several features together in one deployment. Counting functions does not establish independent service ownership.
Keep two decisions separate: which capability owns P42’s processing and data, and which platform runs its code. The SOA and microservices comparison examines coordination and service boundaries. Changing the hosting plan cannot repair an unclear data contract between two teams.
Decide from the workload#
For the image job, a useful trial measures whether the selected trigger, runtime and storage can handle representative files and bursts. Observe completion, failures, startup and processing time, concurrency, queue age and the full service bill. Latency and throughput measure different parts of that result; finishing many jobs per minute does not establish that one interactive request responds promptly.
Compare the same workload on a managed function or container plan and on the alternative you would actually operate. Include idle or prepared capacity, data transfer, storage and other services, together with the team’s infrastructure work. Continuous load, long work, strict response requirements or specific runtime needs can change the choice. Neither fewer servers to manage nor more deployment units proves that the complete application is simpler or cheaper.
IF YOU REMEMBER ONE THING
Delegate infrastructure operation deliberately. Keep required state outside an environment that can disappear, check the selected trigger’s delivery rules, and match compute scaling to what the rest of the application can accept.
Questions people also ask
4 QUESTIONSDoes serverless mean functions only?
No. Function as a service is one form of serverless compute. Managed containers, queues and data services can also form a serverless architecture. Check each service's operating and billing model; the label does not make their limits identical.
Does every function invocation have a cold start?
No. A provider can reuse an initialised execution environment. AWS Lambda can reuse a retained environment for a later invocation, but does not promise that it will survive indefinitely. Prepared capacity is a separate configuration choice.
Can a serverless application have state?
Yes. It can save state in a database, object store or another suitable service. A function's local memory may survive reuse, but a different or replacement environment cannot rely on that memory. Persistent storage still needs its own consistency, availability and access design.
Is serverless always cheaper?
No. Compare the selected plan against the same workload and requirements. Include compute, storage, network traffic, other service calls, prepared capacity and operating work. A short burst and continuous traffic can produce different trade-offs; this page supplies no price estimate.