Serverless computing is often described as a model where developers run code without managing servers. While broadly accurate, that definition can obscure the architectural realities that matter in production. The infrastructure still exists, compute capacity still has limits, and responsibility for performance, security, observability and compliance still needs to be clearly defined.
For most organisations, serverless is best understood as an execution model rather than a complete infrastructure strategy. It can be effective for specific workload types, particularly where demand is uneven or event-driven, but it introduces its own constraints around runtime behaviour, portability and operational visibility.
In this insight we will cover:
- What is serverless computing?
- How serverless platforms execute workloads
- When serverless architectures work well
- Operational limitations of serverless computing
- How serverless fits into modern infrastructure environments
- What organisations should consider before adopting serverless
- Evaluating serverless within a managed infrastructure strategy
What is serverless computing?
There are three key terms it is useful to define in order to understand serverless computing:
- Function – a unit of code designed to perform a specific task.
- Event-driven execution – code runs when triggered by a request, message, file upload or other system event.
- Trigger – an event that causes a function to run, such as an API request, a queue message or a scheduled task.
Serverless computing is a cloud execution model where a platform automatically provides the computing capacity needed to run an application. Functions are invoked by triggers, and the platform adjusts the number of running instances according to demand.
In practice, this usually means an organisation deploys a function or service to a platform that handles runtime allocation, scaling and instance lifecycle management. The infrastructure is abstracted from the user, but not removed. Physical hosts, operating systems, networking layers and scheduling logic still underpin the service, even though those layers are no longer managed directly by the application team.
How serverless platforms execute workloads
When a trigger occurs, the platform allocates a runtime environment and runs the relevant function. The function processes the request, interacts with other services if required, and then returns a response or passes the output to another system.
This model changes how workloads are designed. Functions are generally expected to be stateless, meaning they should not rely on local session data or persistent state stored within the execution environment. Where state is required, it is usually handled through external databases, object storage, caches or messaging services.
Scaling is one of the main reasons organisations consider serverless. If demand increases, the platform can run multiple function instances in parallel. That behaviour can be useful for bursty workloads, but it also means downstream services must cope with the same scaling pattern. A database, API dependency or storage layer can become the bottleneck even when the compute layer scales cleanly.
When serverless architectures work well
Serverless tends to work well where compute demand is intermittent, execution units are relatively small, and the workflow is already event-driven.
One common use case is back-end logic behind APIs, where functions process requests, validate data or call other services. Another is automation, such as file processing, scheduled maintenance tasks or notification pipelines. Serverless can also suit integration workflows that connect systems through messages, webhooks or queue-based events.
These scenarios align well with the model because they do not require persistent runtime state and often benefit from scaling only when events occur. That can reduce overprovisioning and simplify deployment for narrowly scoped services. It can also help teams move quickly when the workload boundary is well understood.
Operational limitations of serverless computing
The trade-offs become clearer once workloads move beyond small, event-driven tasks.
Cold start latency is one example. If a function is not already running, the platform may need to initialise a new runtime before execution begins. For some workloads that delay is negligible, but for latency-sensitive services it can affect user experience or create inconsistency in response times.
Execution time limits also matter. Many serverless platforms are designed for short-lived tasks rather than long-running processes. Where jobs exceed runtime thresholds, they may need to be redesigned, broken into smaller units or moved to another execution model.
Observability can also be harder to manage. Because functions are short-lived and highly distributed, tracing behaviour across multiple invocations, dependencies and services can become more complex than in long-running applications. Logging, monitoring and performance analysis remain possible, but they need deliberate tooling and design.
There is also a control boundary to consider. The platform abstracts operating system access, instance behaviour and infrastructure tuning. That can reduce administrative overhead, but it also narrows the degree of control available for workloads that depend on specific runtime behaviour, custom networking or detailed host-level configuration.
Vendor dependency is another architectural consideration. Many serverless platforms are tied closely to surrounding services such as event buses, identity controls, storage systems and monitoring tools. That can improve integration within one platform, while making portability more difficult later.
How serverless fits into modern infrastructure environments
An application estate is the full set of applications and supporting services an organisation operates. Most application estates do not run on a single execution model. Within an estate, serverless often coexists with containers, virtual machines and managed cloud platforms.
Containers are generally better suited to services that need more runtime consistency, longer execution windows or tighter control over dependencies. Virtual machines remain relevant where operating system control, legacy compatibility or stable resource allocation are required. Serverless fits beside these models by handling discrete, event-driven components without demanding that the whole estate follow the same pattern.
This matters in hybrid environments. An organisation may keep regulated systems or legacy applications on private infrastructure, run containerised services on an orchestrated platform, and use serverless for automation, integrations or edge processing. The architectural decision should focus on whether serverless improves the specific workload without introducing disproportionate complexity elsewhere in the environment.
What organisations should consider before adopting serverless
Before adopting serverless, organisations should assess workload behaviour first. The best candidates are usually short-lived, loosely coupled and event-driven. Applications that require persistent state, low-latency consistency, long execution times or deep host-level control may be better served by containers or virtual machines.
Compliance and data handling also need review. If a workload processes regulated data, teams need clarity around execution location, logging, identity controls, retention and service integration boundaries. Abstraction can simplify operations, but it does not remove responsibility for access control, auditability or data governance.
Cost should be evaluated in relation to real usage patterns rather than assumptions. Serverless can be efficient for low-volume or bursty workloads, but costs may become less predictable when invocation counts, concurrency or dependent service consumption increase.
Evaluating serverless within a managed infrastructure strategy
Serverless can be valuable when it is applied selectively and governed properly. It offers a useful execution model for specific tasks, particularly within modern, event-driven architectures, but it is rarely a complete answer to infrastructure design on its own.
Most organisations still need broader decisions around networking, monitoring, security controls, data placement, workload separation and operational support across the full estate. That is where managed infrastructure strategy matters. The objective is not to force workloads into a fashionable model, but to place each workload in the environment that gives the right balance of control, performance, resilience and operational clarity.
If you are assessing where serverless fits within your wider environment, it is worth reviewing those decisions at infrastructure level rather than treating the platform choice as an isolated development question.
Frequently asked questions about serverless computing
Does serverless computing use servers?
Yes. The term means server management is abstracted from the user, not that servers disappear. The underlying infrastructure still exists and still affects performance, security and runtime behaviour.
What is the difference between serverless and containers?
Serverless abstracts the runtime environment and scales execution automatically in response to events. Containers package applications with their dependencies and offer more control over runtime consistency, configuration and lifecycle management.
Is serverless cheaper than traditional infrastructure?
It can be, particularly for bursty or low-frequency workloads, but cost depends on execution volume, concurrency, architecture design and the services around the function itself.
When should organisations avoid serverless architectures?
Serverless may be a poor fit for long-running processes, highly stateful systems, tightly regulated workloads, latency-sensitive services or applications that require detailed runtime and operating system control.