DevOps3 min read
Kubernetes for application developers: the ten objects you actually touch
You do not need to run a cluster to ship to one. This is the subset of Kubernetes that appears in an application developer's day.
You need Kubernetes when you are running many services across many machines, need sophisticated scheduling and autoscaling, or have a platform team to operate it. For a handful of services, a managed platform, a container service like ECS or Cloud Run, or plain containers behind a load balancer will do the job with a fraction of the operational burden.
Every one of those is genuinely valuable at scale. The question is whether you have the scale that makes them valuable, or whether you are buying an abstraction for a fleet of three containers.
| Cost | Detail |
|---|---|
| Learning curve | Pods, services, ingress, RBAC, CRDs, network policy, storage classes |
| Operational load | Upgrades, node management, certificate rotation, add-on lifecycle |
| Tooling sprawl | Helm or Kustomize, a GitOps controller, monitoring stack, secret management |
| Debugging depth | More layers between a symptom and its cause |
| Baseline cost | Control plane plus system components before your app runs |
| Option | Good for | Ceiling |
|---|---|---|
| Managed platform (Vercel, Railway, Render) | Web apps, small teams | Limited control, cost at scale |
| Serverless containers (Cloud Run, App Runner) | Stateless HTTP services | Cold starts, execution limits |
| Managed containers (ECS Fargate) | Several services on AWS | AWS-specific concepts |
| Docker Compose on a VM | Internal tools, staging | Single machine, manual failover |
| Nomad | Simpler orchestration | Smaller ecosystem |
For most of the client work we do — a Next.js front end, a Node API, a database, a cache, a worker — a managed platform or a container service handles it completely, and the team spends its time on the product.
Usually yes, in the first year or two. The exception is a team that already knows it deeply, where the familiarity cost is near zero and the abstractions are genuinely useful to them.
Yes, and it is far easier if your app is already containerised, configured entirely through environment variables, stateless, and logs to stdout. Those habits are worth adopting regardless.
It removes control plane operations, which is significant, but you still own workload configuration, networking, upgrades, monitoring and cost management. Managed means less work, not little work.
It is a lot of machinery for one workload. A container service gives you rolling deploys, health checks and autoscaling with a fraction of the concepts.
Harshal Patel
Founder & Lead Engineer, ROVQIX
Harshal leads engineering at ROVQIX, where he has shipped production Next.js, Node.js and PostgreSQL systems for startups, SaaS teams and ecommerce brands. He writes about the trade-offs behind architecture decisions rather than the framework of the week.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
You do not need to run a cluster to ship to one. This is the subset of Kubernetes that appears in an application developer's day.
Microservices solve an organisational problem with a distributed systems bill. If you do not have the organisational problem, you just have the bill.
Vercel sells you time. AWS sells you control. The right answer depends on which of the two your team is short of.
No spam. Just the occasional case study and craft breakdown.