Serverless computing can reduce infrastructure overhead, improve scalability and help teams release software faster. But it is not a shortcut around good architecture. Used well, it can simplify delivery. Used badly, it can create cost surprises, operational blind spots and vendor dependency.
For CIOs, CTOs and technology leaders, the real question is not whether serverless computing is modern. The question is whether it fits the workload, the operating model and the commercial risk you are prepared to carry.
This guide explains what serverless computing is, where it works, where it does not, and what to consider before using it as part of a cloud migration or legacy modernisation programme.
What is serverless computing?
Serverless computing is a cloud computing model where the cloud provider manages the infrastructure needed to run application code. Developers deploy functions, services or applications without directly provisioning, patching or managing servers.
The term “serverless” can be misleading. Servers still exist. The difference is that your team does not manage them directly. The cloud provider handles much of the infrastructure layer, including provisioning, scaling, availability and runtime management.
In many serverless models, you pay based on actual usage rather than reserved infrastructure capacity. This makes serverless attractive for workloads with variable or unpredictable demand, where paying for always-on infrastructure would be inefficient.
Major cloud providers describe serverless in similar terms. AWS, Google Cloud and IBM all frame serverless as a way to build and run applications without managing the underlying server infrastructure.
How serverless computing works
Most serverless systems are event-driven. Code runs in response to a trigger, such as an API request, file upload, database change, scheduled event or message arriving in a queue.
Instead of running a full application on a dedicated server, teams break specific pieces of logic into smaller units. These may be functions, containers or managed services, depending on the architecture and provider. The cloud platform runs the code when required and scales capacity automatically based on demand.
Common serverless building blocks include:
- Functions as a Service, such as AWS Lambda, Azure Functions or Google Cloud Functions
- Managed APIs and gateways
- Managed databases
- Queue and messaging services
- Event buses
- Serverless containers, such as Google Cloud Run or AWS Fargate
- Managed authentication, monitoring and deployment services
The benefit is that engineering teams can spend less time managing infrastructure and more time delivering business logic. The trade-off is that responsibility moves elsewhere. Serverless reduces some operational burden, but it increases the importance of architecture, observability, cost control and dependency management.
Serverless computing examples
Serverless computing is most useful when work can be split into clear, bounded tasks. These tasks usually start when something happens and stop when the work is complete.
Common examples include:
- API backends: Functions run when a user or system calls an API endpoint.
- File processing: A file upload triggers image resizing, document conversion, virus scanning or metadata extraction.
- Data pipelines: Events trigger validation, transformation, enrichment or movement of data between systems.
- Scheduled jobs: Functions run on a timed schedule to complete reporting, clean-up or synchronisation tasks.
- Notifications: A change in one system triggers an email, SMS, webhook or workflow action.
- IoT and edge events: Device data triggers processing only when readings or events are received.
- Internal automation: Repetitive operational tasks run without needing a permanently active server.
These use cases work because they are discrete. They do not require a large, always-on application to remain active all the time.
The benefits of serverless computing
Serverless computing is attractive because it can remove infrastructure friction. For teams under pressure to move faster, reduce cost and scale more efficiently, that can be valuable.
| Benefit | What it means | Why it matters |
|---|---|---|
| Reduced infrastructure management | Cloud providers manage much of the server layer. | Teams spend less time on provisioning, patching and capacity planning. |
| Automatic scaling | Capacity expands and contracts based on demand. | Useful for variable traffic, seasonal demand and unpredictable workloads. |
| Usage-based pricing | Costs are often linked to execution time, requests or resource use. | Can reduce waste where systems do not need to run continuously. |
| Faster delivery | Teams can deploy smaller pieces of functionality independently. | Supports faster experimentation, iteration and release cycles. |
| Lower operational overhead | Managed services absorb some routine operational responsibility. | Can free internal teams to focus on customer and business outcomes. |
These benefits are real. But they are not automatic. Serverless computing creates value when the workload matches the model and the organisation has the engineering discipline to manage it properly.
The disadvantages of serverless computing
Serverless computing solves some problems and introduces others. A poor serverless architecture can become harder to understand, test, monitor and control than the system it replaced.
The main disadvantages include:
- Vendor lock-in: Serverless services often rely on provider-specific tooling, events and runtime behaviour. Moving away later can be expensive.
- Cold starts: Some functions experience a delay when they have not run recently. This can matter for latency-sensitive user journeys.
- Observability complexity: Distributed event-driven systems can be harder to trace than traditional applications.
- Testing difficulty: Local testing may not fully match behaviour in the cloud provider’s managed environment.
- Cost unpredictability: Usage-based pricing can become expensive when demand grows, functions are inefficient or events trigger unexpectedly.
- Execution limits: Some serverless platforms limit runtime duration, memory, payload size or concurrency.
- Security boundaries: Smaller units of code create more identity, permission and access-control points to manage.
- Architectural sprawl: Teams can create too many small functions without clear ownership, documentation or governance.
This is why serverless should not be treated as a default destination for every cloud migration. It is an architectural choice, not a universal strategy.
Serverless computing vs cloud computing
Serverless computing is not the same as cloud computing. It is a specific model within cloud computing.
Cloud computing gives organisations access to infrastructure, platforms and services over the internet. That can include virtual machines, storage, databases, networking, containers, analytics, AI services and many other managed capabilities.
Serverless goes further by abstracting away more of the infrastructure management. Rather than provisioning and managing servers, teams deploy code or services into a managed execution environment.
In simple terms:
- Cloud computing gives you flexible access to computing resources.
- Serverless computing lets you run workloads without managing the servers that support them.
Both can be useful. The right model depends on the workload, control requirements, cost profile and operating maturity of the organisation.
When serverless computing is a good fit
Serverless works best when workloads are event-driven, modular and variable in demand. It is particularly useful when infrastructure should scale up and down automatically without the team managing capacity manually.
| Workload type | Serverless fit | Why |
|---|---|---|
| Event-driven tasks | High | Functions can run only when triggered. |
| APIs with variable demand | High | Automatic scaling can reduce idle infrastructure. |
| Batch data processing | Medium to high | Useful when jobs are intermittent and bounded. |
| Long-running processes | Low | Execution limits and cost patterns can become problematic. |
| Low-latency customer journeys | Medium to low | Cold starts and distributed dependencies need careful design. |
| Legacy monoliths | Low initially | They usually need decomposition before serverless makes sense. |
| Regulated workloads | Depends | Requires auditability, access control, governance and clear data handling. |
The strongest use cases are usually those where work is short-lived, predictable in scope and triggered by a clear event. The weakest use cases are usually large, stateful systems that need continuous control, predictable latency or deep integration with legacy platforms.
When serverless computing is a poor fit
Serverless is often a poor fit where the workload needs persistent state, long execution time, extremely low latency or heavy control over the underlying runtime environment.
It can also be a poor fit when the organisation is trying to avoid a harder architectural question. Moving a difficult system into serverless will not automatically make it simpler. If the underlying domain model is unclear, integrations are brittle, data ownership is weak or deployment practices are inconsistent, serverless may expose those issues faster.
Be cautious if the system has:
- Large monolithic codebases with unclear boundaries
- Complex shared databases used by multiple applications
- Long-running transactions or batch processes
- Strict latency expectations across customer-facing journeys
- Heavy compliance or audit obligations without mature controls
- Poor monitoring, logging or incident response processes
- High and predictable baseline traffic where reserved infrastructure may be cheaper
In these situations, serverless may still have a role. But it should usually be introduced selectively, not applied as a wholesale replacement.
Serverless computing and legacy modernisation
Serverless is sometimes positioned as a quick route away from legacy infrastructure. That is dangerous thinking.
If a system is difficult to change, difficult to test or difficult to understand, moving parts of it into a serverless model will not remove the core problem. It may simply move complexity from one place to another.
For legacy systems, the right first step is not choosing a cloud service. The right first step is understanding the system boundaries, dependencies, data flows, performance risks and business-critical processes.
This is where legacy system modernisation and cloud migration services need to work together. Serverless may be useful for new capabilities, isolated workflows, data processing or integration layers. It is rarely the right answer for lifting and shifting a monolith without redesign.
A better approach is to identify stable seams in the system. These are areas where functionality can be separated safely, tested properly and operated independently. Once those seams are understood, serverless can become one option in a wider modernisation roadmap.
The migration questions to ask before choosing serverless
Before moving a workload to serverless, technology leaders should ask practical questions about architecture, cost, security, delivery and operational readiness.
| Area | Readiness question | Why it matters |
|---|---|---|
| Workload fit | Is the workload event-driven, bounded and suitable for short execution? | Serverless works best when tasks are discrete and triggered by clear events. |
| Architecture | Are service boundaries and dependencies clearly understood? | Poor boundaries create fragile distributed systems. |
| Cost | Have likely request volumes, execution times and data transfer costs been modelled? | Usage-based pricing can rise quickly if demand or design assumptions are wrong. |
| Performance | Can the system tolerate cold starts, network calls and provider limits? | Latency issues can damage user experience and service reliability. |
| Security | Are permissions, secrets, identities and data access controls clearly defined? | Distributed functions increase the number of access points to govern. |
| Observability | Can teams trace events, errors, dependencies and user impact across the system? | Without monitoring, incidents become harder to diagnose. |
| Delivery | Are testing, deployment and rollback processes mature enough? | Serverless still needs disciplined engineering and release management. |
If these questions expose major gaps, serverless should not be abandoned automatically. But the migration plan should address those gaps before production dependency increases.
Serverless computing and performance at scale
Serverless can improve scalability, but it does not remove the need for performance engineering.
Automatic scaling is useful, but it must be designed around provider limits, concurrency behaviour, downstream dependencies and data transfer patterns. A serverless function may scale quickly, but the database, API or third-party system it calls may not.
This is a common failure pattern. One part of the architecture becomes elastic, while another part becomes the bottleneck. The result can be slower response times, failed requests or rising costs.
If performance and reliability are already concerns, serverless should be assessed alongside wider performance and scaling requirements. The goal is not simply to move compute into a managed service. The goal is to ensure the full system can handle real demand.
Serverless still needs strong delivery practices
Serverless can make deployment faster, but it can also increase the number of moving parts. That makes engineering discipline more important, not less.
Teams need clear standards for:
- Code structure and ownership
- Environment management
- Automated testing
- Security scanning
- Infrastructure as code
- Deployment pipelines
- Rollback processes
- Monitoring and alerting
Without this, serverless estates can become difficult to govern. Functions multiply, dependencies become unclear and no one has a complete view of the system.
For organisations adopting serverless as part of a broader engineering improvement programme, CI/CD pipeline optimisation is often just as important as the cloud architecture itself.
The final verdict: should you use serverless computing?
Serverless computing is a strong option when the workload is event-driven, modular, variable in demand and suitable for managed cloud execution. It can reduce infrastructure overhead, improve scalability and accelerate delivery.
But it is not the right answer for every system. Serverless is a poor default choice for complex monoliths, long-running workloads, latency-sensitive journeys or environments where the organisation lacks mature monitoring, security and delivery practices.
The best use of serverless is selective. Start with workloads where the fit is obvious. Model the cost. Test the performance. Understand the operational impact. Then decide whether serverless should become part of the wider cloud and modernisation strategy.
Serverless is not a magic route out of infrastructure complexity. It reduces some operational burdens, but shifts the architectural burden elsewhere: event design, observability, cost modelling, security boundaries, integration and vendor dependency.
Used carefully, it can be a useful part of a modern cloud architecture. Used carelessly, it becomes another layer of technical debt.
Considering serverless as part of a cloud migration or legacy modernisation programme?
Catapult can help assess which workloads should move, which should stay, and what needs to change before migration begins.
FAQs about serverless computing
What is serverless computing in simple terms?
Serverless computing is a way to run applications or functions in the cloud without managing servers directly. The cloud provider manages the infrastructure, while your team focuses on the code, events and services that make the application work.
Does serverless mean there are no servers?
No. Serverless does not mean servers disappear. It means your organisation does not provision, patch or manage the servers directly. The cloud provider manages the server infrastructure behind the service.
What are examples of serverless computing?
Common examples include AWS Lambda, Azure Functions, Google Cloud Functions, Google Cloud Run, AWS Fargate, event-driven APIs, file-processing services, scheduled jobs, data pipelines and internal workflow automations.
What is the main benefit of serverless computing?
The main benefit is reduced infrastructure management. Teams can deploy code without managing servers directly, while the cloud provider handles much of the provisioning, scaling and runtime management.
What is the main disadvantage of serverless computing?
The main disadvantage is loss of control and increased dependency on provider-specific services. Serverless can also introduce cold starts, observability challenges, testing complexity and cost unpredictability if workloads are not designed carefully.
Is serverless computing cheaper?
Serverless can be cheaper for intermittent, variable or event-driven workloads because you usually pay based on usage. It is not always cheaper for high-volume, predictable or long-running workloads. Cost modelling should happen before migration.
Is serverless suitable for legacy systems?
Serverless can support parts of a legacy modernisation programme, but it is rarely suitable for lifting and shifting an entire monolith. Legacy systems usually need architecture assessment, boundary mapping and dependency analysis before serverless is introduced.
When should you not use serverless?
You should be cautious with serverless for long-running processes, complex stateful systems, low-latency customer journeys, unclear legacy architectures, high-volume predictable workloads or regulated systems without mature governance and monitoring.
