Serverless runs your code in short bursts and the provider manages the servers, containers package an application so it runs the same anywhere, and virtual machines give you a full virtual computer you manage yourself. Serverless is least work to operate, virtual machines give most control, and containers sit between them. The right choice depends on workload, team skills and how much operational effort you can afford.
Key takeaways
- Serverless trades control for convenience: you run functions, not servers, and the provider handles scaling.
- Containers package an app and its dependencies, making it portable and consistent across environments.
- Virtual machines offer the most control and suit legacy or specialised software, with the most upkeep.
- Long-running jobs, steady heavy traffic and tightly state-dependent apps often fit containers or virtual machines better than serverless.
- Kubernetes is powerful but is overkill for many small teams.
- Choose based on workload shape, team skills, cost visibility and exit options, not fashion.
Plain-English definitions
Virtual machines
A virtual machine, or VM, is a complete computer simulated in software on shared hardware. It has its own operating system, which you install, patch and secure. You decide what runs on it and for how long. It is the closest cloud equivalent to a traditional server.
Containers
A container bundles an application with the libraries and settings it needs, and runs on top of a shared operating system. Because everything is packaged together, it behaves the same on a developer laptop, a test server and production. Containers start quickly and use fewer resources than full virtual machines.
Serverless
In serverless computing you upload a function or a small service and the provider runs it when something triggers it, such as a web request, a file upload or a timer. There are still servers, but you do not manage them. Capacity grows and shrinks automatically, including down to nothing when idle.
How each is billed and operated
Without quoting prices, the conceptual models differ.
- Virtual machines are usually paid for while they are running, whether busy or idle. You operate the operating system, security updates, monitoring and capacity planning.
- Containers are paid for through the machines or managed service that run them. You operate the image, its dependencies and the deployment process, while a managed container service can take over much of the machine management.
- Serverless is generally paid for by usage, such as number of executions and the time and memory they consume. You operate only the code and its configuration, but you accept limits set by the provider.
Usage-based billing is attractive for spiky or low traffic and can become less attractive for constant heavy load, so model your expected pattern before deciding.
Strengths and weaknesses
Virtual machines
- Strengths: full control, runs almost any software, familiar to most administrators, good for legacy applications.
- Weaknesses: you patch and secure the operating system, scaling is slower and more manual, and idle machines still cost money.
Containers
- Strengths: consistent environments, good portability, efficient use of resources, fits modern deployment pipelines.
- Weaknesses: needs skills in image building and orchestration, and storage and networking add complexity.
Serverless
- Strengths: minimal operations, automatic scaling, pay for use, quick to start for event-driven tasks.
- Weaknesses: cold starts, where a function that has been idle takes longer on its first call, execution time limits, harder local testing and a stronger tie to one provider's services.
Key trade-offs
- Control: highest with virtual machines, lowest with serverless.
- Scaling: automatic and fast with serverless, configurable with containers, slowest and most manual with virtual machines.
- Operational overhead: lowest with serverless, highest with virtual machines.
- Portability: containers are the most portable. Serverless often depends on provider-specific triggers and services.
- Vendor lock-in: real with serverless, moderate with managed services around containers, lowest with virtual machines and plain containers. Lock-in is not always bad, but it should be a conscious choice.
- State and long-running jobs: serverless functions are generally designed to be short and stateless. Jobs that run for a long time or keep data in memory suit containers or virtual machines.
Typical fits
- Event-driven tasks: resizing uploaded images, sending notifications, processing webhooks. Serverless is a natural fit.
- Web APIs: serverless works well for lighter or spiky traffic. Containers suit APIs with steady load, specific runtime needs or complex dependencies.
- Legacy applications: virtual machines are often the simplest home, because the software expects a traditional server.
- Batch jobs: scheduled or heavy processing may fit containers that run and stop, or virtual machines for long jobs. Serverless works if each unit of work is small enough.
- Databases and stateful services: usually best on managed database services or carefully managed virtual machines rather than stateless functions.
Managed container services and Kubernetes
Most cloud providers offer managed container services that run your containers without you managing the underlying machines. For many teams this is the sweet spot: portable packaging with limited operational work.
Kubernetes is a widely used system for running many containers across many machines, handling scaling, restarts and rollouts. It is very capable and also complex. For a small team with a handful of services it is often overkill. Consider it when you have many services, several teams and a real need for its features, and prefer a managed offering to running it yourself.
Team skills and cost visibility
Choose technology your team can actually run at three in the morning. A simpler platform operated well beats an advanced one operated badly.
Cost visibility differs too. Virtual machine costs are easy to predict but easy to waste. Serverless costs follow usage, which is great until a loop or traffic burst multiplies them. Whatever you choose, tag resources, set budget alerts and review bills regularly. Our guide to cloud cost optimisation goes into more detail.
Security and shared responsibility
In every model the provider secures the underlying infrastructure and you remain responsible for what you put on it, but the split moves.
- With virtual machines, you secure the operating system, patches, network rules and application.
- With containers, you secure the images, their dependencies and the deployment configuration.
- With serverless, you secure your code, permissions and data, while the provider handles more of the platform.
Less to manage does not mean nothing to secure. Over-broad permissions and exposed secrets are risks in every model.
Migration paths
You do not have to choose once and forever.
- Lift and shift: move an existing application to a virtual machine in the cloud with few changes.
- Containerise: package the application in a container, often a first step towards flexibility.
- Move to a managed container service: reduce machine management.
- Extract event-driven pieces into serverless functions: for tasks that suit it.
Take the path that fits each workload rather than rewriting everything. Our cloud migration checklist covers planning in more detail.
A decision checklist
- Does the workload run in short, event-driven bursts, or continuously?
- Is the traffic steady or spiky?
- Does the software need a specific operating system or special configuration?
- How long can a single job run, and does it hold state?
- How much operational work can your team handle?
- How important is portability between providers?
- Can you forecast and monitor the costs?
- Which security responsibilities will your team own?
If most answers point to short, spiky and low-ops, lean towards serverless. If they point to specific environments and steady load, lean towards containers. If they point to legacy software or full control, use virtual machines.
A worked example
Imagine a small business with a customer portal, a nightly report job and an image upload feature. The portal is a conventional web application with steady traffic and several dependencies, so the team packages it in a container and runs it on a managed container service. Image resizing triggers only when someone uploads a file, so it becomes a small serverless function. The nightly report runs for a long time and uses a lot of memory, so it runs as a scheduled container job. An old accounting tool that expects a traditional server stays on a virtual machine until it is replaced. One company, three models, each chosen for the workload.
FAQ
What is the difference between containers and virtual machines?
A virtual machine includes a full operating system and acts like a separate computer. A container shares the host operating system and packages only the application and its dependencies, so it is lighter and starts faster.
Is serverless cheaper than virtual machines?
It depends on the usage pattern. Serverless often costs less for spiky or low traffic, while steady heavy workloads can be cheaper on containers or virtual machines. Estimate your own pattern before deciding.
Do I need Kubernetes?
Most small teams do not. A managed container service covers many needs with much less complexity. Consider Kubernetes when you run many services and have the skills, or a managed offering, to support it.
Can I mix serverless, containers and virtual machines?
Yes, and many businesses do. Matching each workload to the model that suits it is usually better than forcing everything into one.
Related reading
- Web Hosting Explained: Shared, VPS, Cloud and Managed
- Cloud Cost Optimisation: Reduce Your Cloud Bill Safely
- Monitoring and Observability Basics for Small Teams
Next steps
List your applications and jobs, note their traffic pattern, runtime needs and who maintains them, and mark which model fits each. If you want a second opinion or help with the move, see our cloud and DevOps services, or contact us.
