Kubernetes vs Serverless vs Virtual Machines: Choosing an Application Platform
Kubernetes vs serverless vs virtual machines and managed platforms: control, operations effort, scaling, cost behaviour, limits and which fits.
Kubernetes, serverless or virtual machines?
Choose virtual machines for legacy or OS-dependent software and steady workloads; a managed application platform or serverless containers for most web apps and APIs run by small teams; serverless functions for event-driven and spiky workloads that fit their limits; and Kubernetes when you run many services, need consistent portable tooling and have the skills to operate it. Most organisations mix several options; the goal is the least operational effort that meets your needs.
This guide is for CTOs, technical founders and engineering leads. For the delivery practices around any platform, see DevOps for growing businesses.
Key takeaways
- Start with the simplest platform that meets requirements.
- Managed platforms reduce operations work for small teams.
- Serverless suits events and spiky load within its limits.
- Kubernetes pays off with many services and platform skills.
- Compare total cost, including people's time.
The options
| Option | You manage | Provider manages |
|---|---|---|
| Virtual machines | OS, patching, runtime, scaling, app | Hardware, hypervisor |
| Managed app platform (PaaS) | App code and configuration | OS, runtime, scaling, load balancing |
| Serverless containers | Container image and configuration | Servers, scaling (often to zero) |
| Kubernetes (managed) | Workloads, cluster configuration, add-ons, upgrades | Control plane, often node infrastructure |
| Serverless functions | Function code and triggers | Everything else |
Comparison
| Factor | VMs | Managed platform | Kubernetes | Functions |
|---|---|---|---|---|
| Control | Highest | Lower | High | Lowest |
| Operations effort | High | Low | Medium to high | Low |
| Scaling | Manual or autoscaling groups | Built in | Built in, configurable | Automatic, per request |
| Long-running work | Yes | Yes | Yes | Limited (for example 15 minutes on Lambda) |
| Cost behaviour | Pay for capacity | Pay for instances or usage | Pay for nodes | Pay per invocation and duration |
| Portability | Image-based | Platform-specific | High across providers | Provider-specific |
Constraints to check
Serverless functions have time, memory and payload limits; AWS documents a 900-second (15-minute) maximum timeout and memory from 128 MB to 10,240 MB for Lambda (AWS). Cold starts affect latency-sensitive endpoints. Kubernetes needs regular version upgrades, security configuration, networking and observability skills. VMs need patching and configuration management, ideally through infrastructure as code. Check that each service is available in the Australian region you need.
Which fits?
- A single web app or API, small team: managed platform or serverless containers.
- Background jobs, webhooks, scheduled tasks: serverless functions or a job queue.
- Many services, several teams, portability needs: managed Kubernetes.
- Legacy or licensed software: VMs, possibly later containerised.
- AI inference with GPUs: managed inference services or Kubernetes with GPU nodes, depending on scale.
Hypothetical example: a growing SaaS
This example is hypothetical. A SaaS company ran its web app on a managed platform, its webhook handlers and nightly reports on serverless functions, and a licensed reporting tool on a VM. As it grew to a dozen services and three teams, it moved the web app and APIs to managed Kubernetes for consistent deployments, keeping functions for event handlers. It measured deployment time, incidents and monthly cost before and after rather than assuming the move would help.
Common mistakes
- Adopting Kubernetes before there is a need or the skills.
- Forcing long-running jobs into functions.
- Ignoring cold starts on user-facing endpoints.
- Hand-configured VMs nobody can rebuild.
- Comparing cloud bills without engineering time.
Related guides
- Scaling SaaS applications for growth patterns.
- Zero-downtime deployments for releasing on any platform.
- Cloud migration in Australia for moving existing systems.
- Application monitoring and observability for running in production.
Conclusion
There is no single best platform. Use the simplest option that meets your requirements, mix where it helps, and move to more complex platforms such as Kubernetes when service count, team size and skills justify the operational cost.
Choosing where to run your application?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications, APIs and their deployment. We do not offer managed cloud operations, but if it would help to choose a platform for software we build, we are happy to talk it through.
Common questions.
Usually not as a first choice. Kubernetes is powerful for running many services with consistent tooling, but it adds operational work even when managed by a cloud provider. Small teams often move faster on a managed application platform or serverless containers, adopting Kubernetes when scale, service count or portability needs justify it.