2026-01-28//NONSENSE
I Read the Entire K8s Docs So You Don't Have To (Don't Use It)
I spent two weeks reading the Kubernetes documentation cover to cover. All of it. The concepts. The tasks. The tutorials. The API reference. The love letters written by the engineers who clearly lost their minds somewhere around the CRD specification.
Here is what I learned: 90% of startups using Kubernetes should not be using Kubernetes.
You have three developers, a NestJS API, a Postgres database, and maybe a Redis instance. You do not need container orchestration. You need a VPS and a systemd service. That is it. You are DONE. Your deploy script is "git pull and pm2 restart." Total infrastructure cost: 20 dollars a month. Time to set up: an afternoon.
Instead, what I see is: three developers spending two months setting up a K8s cluster on EKS, writing Helm charts, configuring Ingress controllers, debugging DNS resolution between pods, setting up monitoring for the monitoring system that monitors the cluster that runs your single API. Total infrastructure cost: 800 dollars a month. Time to set up: ONGOING. FOREVER. IT NEVER ENDS.
"But we need to scale!" Scale WHAT? Your API handles 50 requests per minute. A Raspberry Pi could handle that. A TI-84 calculator could PROBABLY handle that. You do not have a scaling problem. You have a boredom problem. You wanted to play with cool technology and you dressed it up as a technical requirement.
"But we need zero-downtime deployments!" You know what else gives you zero-downtime deployments? Two servers behind a load balancer. Or even just a single server with a rolling restart. This has been a solved problem since before Docker existed.
"But we need a service mesh!" YOUR THREE-PERSON TEAM DOES NOT NEED A SERVICE MESH. You have TWO services. They can call each other by hostname. Istio is not making your life better. Istio is giving your infrastructure engineer job security.
The Kubernetes documentation is 2,000 pages long. TWO THOUSAND PAGES to learn how to run a container. Docker run is one command. One.
I am not saying Kubernetes is bad. It is genuinely impressive engineering. If you are running hundreds of services at scale with multiple teams, it is the right tool. But if you are reading this and you work at a startup with fewer than 50 engineers, I am begging you: just use a VPS. Write a bash script. Set up a cron job. Touch grass. Be free.
The best infrastructure is the one you do not think about. And Kubernetes is something you think about EVERY SINGLE DAY.