Kubernetes or serverless?
Serverless is usually the right default for smaller teams – you pay per use and skip operating servers. Kubernetes gives portability and full control, but at a real operating and skills cost. For many, the real answer is a middle form: managed containers like Cloud Run or Fargate.
Left traditional servers behind, and the next question soon appears: should scaling happen with Kubernetes or serverless? The two represent different philosophies for how a modern application should be run – one about control, one about not having to worry. Here’s the trade-off, and why the answer often sits in between.
Serverless: the right default for smaller teams
Serverless means the cloud provider runs your code for you. You upload the functions or application, and the platform handles the rest: spins up when something happens, scales automatically under load, and scales down to zero when it’s quiet. You only pay for actual usage.
For a smaller team, it’s hard to beat. There’s no server to patch, no capacity to size, no on-call for the platform itself. Under uneven or low load it’s also very cheap – it costs nothing when nothing’s happening. It lets the team spend its time on the product instead of the infrastructure.
The price is two things. One is a tighter coupling to the vendor’s way of doing things, which makes a future move harder. The other is certain limits – for example on how long a run is allowed to last. For most smaller products, the simplicity still outweighs that, and serverless is a good default.
Kubernetes: portability and control, at a price
Kubernetes is the opposite philosophy. It’s a system for running and coordinating containers where you control the platform down to the smallest detail. That comes with two real advantages.
- Portability. A Kubernetes setup can run almost anywhere – with any cloud provider, or on your own servers. That reduces lock-in and gives you negotiating room.
- Control. You decide exactly how services run, scale, and connect. Requirements serverless doesn’t allow, like very long-running processes or special networking needs, become achievable.
But control costs. Kubernetes is a platform in itself that has to be operated, upgraded, secured, and monitored – and it demands skills that are specialized and not free to hire. For a small team with a handful of services, it often ends up as more machinery than the benefit justifies. Kubernetes pays off when complexity is already high, not as a way to future-proof a simple product.
A scenario: when the choice flips
Picture a startup with one application and uneven traffic. Serverless is the obvious choice: low cost, no operations, the team focused on the product. Then the company grows. Services multiply into the dozens, load becomes high and steady around the clock, and a couple of components need runs longer than serverless allows. Now the serverless bill starts to sting, and the limits start to chafe. At some point the math flips: the control and steady capacity Kubernetes provides becomes worth its operating cost. The point is the choice isn’t forever – the right answer can change with scale.
The middle forms that are often the real answer
Here’s the most important and most overlooked point: the choice is rarely the two extremes. In between sit managed containers – services like Cloud Run and Fargate.
The idea is that you package your application in a container just as in the Kubernetes world, but skip operating the Kubernetes machinery itself. The provider runs and scales it for you, often down to zero like serverless. You get the container world’s flexibility with serverless-like simplicity.
| Option | Suits when |
|---|---|
| Serverless | Small team, uneven load, product focus |
| Managed containers | Want containers but not operating Kubernetes |
| Kubernetes | Many services, multi-cloud, in-house operations skills |
For a large share of teams, the middle row is the right answer. It gives flexibility without Kubernetes’ full operating burden, and scales smoothly without serverless’s tightest limits.
How to choose
Start with serverless or managed containers. They solve most needs for small and mid-sized products, with low operations and pay-per-use billing. Move to Kubernetes when complexity truly demands it – many services, a need for portability, or requirements serverless can’t meet – and when you have the skills to maintain it.
Want help choosing the right operating model for your product? At Weapp we’re happy to look at it as part of our cloud architecture work. Get in touch and we’ll talk through what’s reasonable before you build yourself into a setup.
Frequently asked questions
What's the difference between Kubernetes and serverless?
Kubernetes is a system for running and coordinating containers where you manage and operate the platform yourself. Serverless means the cloud provider runs your code for you and scales automatically, while you only pay for actual usage. Kubernetes gives control and portability; serverless gives simplicity and low operations at the cost of more vendor dependency.
Is serverless always cheaper?
Not always. Serverless is very cost-effective under uneven or low load, since you don't pay when nothing's happening. Under high, steady load around the clock, the cost can instead end up higher than a well-sized container setup. It's the load profile that decides – spiky load favors serverless, stable high load can argue against it.
When is Kubernetes worth its complexity?
When you have many services to coordinate, need to run the same way across multiple clouds or your own servers, or have requirements serverless doesn't allow, like very long-running processes. And when you actually have the skills to operate it. For a small team with a handful of services, Kubernetes is usually more machinery than the benefit justifies.
What are managed containers like Cloud Run and Fargate?
It's a middle path: you package your application in a container as usual, but skip operating the underlying Kubernetes machinery – the provider handles it and scales for you. You get much of the container world's flexibility with serverless-like simplicity, and it's often the practical answer for teams that want neither extreme.
What does vendor lock-in mean in this choice?
Serverless services are often built around a specific cloud provider's way of doing things, which makes it harder to move to another cloud later. Kubernetes, by contrast, is portable and can run almost anywhere, which reduces lock-in. Control has value, then, but it should be weighed against the operations and skills it demands.