Virtualisation, Containers and Serverless

Virtualisation, containers and serverless: the right abstraction per workload

The virtual machine, the container and serverless are three levels of compute abstraction that trade isolation for density, operational effort and cold start. No model is universally superior; each wins for a particular kind of workload.

The question is rarely which abstraction is best, but which one fits a concrete workload. A virtual machine seals off a whole guest environment, a container shares the host kernel and starts in a fraction of a second, a serverless function is conceptually short-lived per request, yet platforms reuse warm execution environments between calls. Each step up removes operational effort and in return gives up some isolation or predictability. This page places the three models along these trade-offs and shows where each one holds, instead of crowning a winner.

The three abstraction levels

The models build on each other but do not replace each other. They differ above all in how much of the underlying system they virtualise:

Virtual machine (VM). A hypervisor virtualises the hardware and gives each VM its own operating system with its own kernel. That delivers the strongest isolation but costs seconds to minutes at start and more memory per instance. The VM remains the default boundary for multi-tenant or regulatorily sensitive workloads.
Container. A container shares the host kernel and encapsulates only the application and its dependencies. That cuts start time and memory footprint sharply and raises density, the number of instances per server. Isolation is weaker than a VM's, because the shared kernel is a larger attack surface. The Open Container Initiative standardises format and runtime, so an image runs across providers. How containers are orchestrated together is covered by the page on Kubernetes.
Serverless and FaaS. Function as a Service pushes the abstraction to the end: there is no visible server any more, the provider starts compute units per call and scales to zero on inactivity. Operational effort drops the most, but in return come the cold start and a tighter binding to the provider's platform.

The boundary is not sharp. Modern serverless platforms often run on lightweight VMs themselves, such as Firecracker, which combines the isolation of a VM with start times in the millisecond range and so deliberately blurs the line between container and VM.

The four trade variables

Every choice between the models comes down to four variables that pull against each other:

Isolation. How strongly is a workload separated from its neighbours? VMs separate at the hardware and kernel level, containers share the kernel, serverless shifts the isolation question to the provider. Anyone processing foreign or particularly sensitive data weights isolation highly.
Density. How many workloads fit on one server? Containers and functions pack far denser than VMs, because they carry no full guest system. Higher density lowers infrastructure cost, a topic that FinOps tracks systematically.
Operational effort. Who maintains patches, scaling and availability? With a VM almost everything sits with the operator, with a container the load is shared with the orchestration, with serverless the provider takes the largest part. Less visible effort also means less control.
Cold start. How long does it take a dormant workload to respond? A running VM or a warm container answers without startup overhead, subject to application and network latency, a scaled serverless function has to spin up first. On latency-critical paths the cold start becomes a knockout criterion.

These four variables cannot be maximised at the same time. A gain in density or a removal of operational effort is usually paid for with weaker isolation or a cold start.

The decision path

Instead of starting from a favourite technology, the trade-off leads from the workload to the model. The classification below turns the trade variables into a repeatable question:

flowchart TD
    A["Workload"] --> B{"Strong isolation<br/>required?"}
    B -->|"yes, foreign tenants<br/>or sensitive data"| C["Virtual machine<br/>or microVM"]
    B -->|"no"| D{"Load steady<br/>or bursty?"}
    D -->|"steady, predictable"| E["Container<br/>orchestrated"]
    D -->|"bursty, event-driven"| F{"Cold start<br/>tolerable?"}
    F -->|"yes"| G["Serverless / FaaS"]
    F -->|"no"| E

The path is not an automatism but an order of questions. Isolation comes first, because it is the least negotiable; then the load profile decides between steady operation and event-driven bursts; finally the cold start clarifies whether serverless holds. Many real systems land on a mixture, for example containers for the core and functions for rare, well-bounded tasks.

Where the choice tips

Serverless for steady load. A continuously busy function mostly stays warm, so the issue is not repeated cold starts but the economics and the platform binding: without the saving from scaling to zero, per-call billing becomes more expensive and predictably ties the organisation to the provider. Here a container is usually cheaper and more portable.
VM out of habit. Packing a stateless application into a full VM gives away density and raises operational effort without ever needing the strong isolation.
Containers without orchestration. Tending individual containers by hand on a server only shifts the effort instead of lowering it. Past a certain number of instances the model demands an orchestration layer.
Cold start underestimated. Putting serverless on a latency-critical path without measuring the cold start builds in an invisible delay. Pre-warmed capacity softens it but costs the saving.

The link to architecture

The choice of abstraction is not an isolated infrastructure decision but hangs on how the application is cut. A Microservices architecture splits a system into independently operable services, which is what makes containers and functions worthwhile in the first place; a monolith rarely benefits from fine-grained scaling. The overarching paradigm is described by Cloud Native, which brings containerisation, orchestration and elastic scaling together. Complementary building blocks such as an API gateway and a service mesh govern the traffic between the services, regardless of whether they run as a container or as a function.

The more distributed the system, the more complexity moves into operations. End-to-end Observability thus becomes the precondition for understanding the state of short-lived containers and functions at all. The organisational answer to this is bundled by Platform Engineering, which provides these abstractions as a self-service platform for development. As a service this is the Platform Engineering (IDP) competence; the ongoing operation including cost steering is covered by the Platform and FinOps Management service.

Portability and data control over the runtime

The abstraction choice co-decides how portable a system stays and how much control over its data remains in-house. Serverless lowers operational effort the most but usually binds to a hyperscaler's platform, whose compute units may, depending on the provider, sit outside Switzerland or the EU. Containers are the most portable thanks to a standardised format and can run on in-house or Swiss infrastructure, which reduces vendor binding. VMs and microVMs in turn deliver the isolation that regulated workloads demand. Weighing cost advantage against sovereignty and portability is the same decision as the underlying Make or Buy question, only at the runtime level. The cost side of this choice is assessed by the Cloud and FinOps Check service.

References

CNCF Cloud Native 2024, Approaching a Decade of Code, Cloud, and Change. Tenth annual survey of the Cloud Native Computing Foundation on the adoption of containers, orchestration and serverless. (01.04.2025). www.cncf.io/reports/cncf-annual-survey-2024/
AWS Firecracker, secure and fast microVMs for serverless. Open-source virtualisation combining VM isolation with start times in the millisecond range, carrying serverless and container workloads alike. (2018). firecracker-microvm.github.io
NIST SP 800-190, Application Container Security Guide. Guidance on the security risks of container technologies and measures across the full lifecycle. (25.09.2017). csrc.nist.gov/pubs/sp/800/190/final
Open Container Initiative Runtime, Image and Distribution Specifications. Open standards for container format and runtime under the Linux Foundation, founded 2015. (2015). opencontainers.org

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.

Virtualisation, Containers and Serverless