--- title: "Kubernetes on day one: a ship's wheel for a paper boat" description: "The myth says day-one Kubernetes is an investment in the future. The post-mortem data, the escape stories, and the wheel's own history say otherwise. Where Kubernetes escaped from, what it actually costs a small team, five ways to run containers from bare metal to no cluster at all, and the observable signals that say it is finally time to climb." slug: kubernetes-day-one status: published published_at: 2025-03-04 author: Arman Obosyan author_url: https://sugra.systems/about section: general primary_keyword: kubernetes startup day one managed kubernetes monolith hero_image: /blog/images/posts/kubernetes-day-one-hero.jpg hero_alt: "Engineering blueprint of a seven-spoke ship's wheel in amber hairlines, with dimension callouts, an inspection stamp reading NOT FOR DAY ONE, and a tiny teal paper boat marked payload (ref)." og_image: /blog/images/posts/kubernetes-day-one-hero.jpg tags: - engineering - infrastructure - kubernetes - architecture --- The pitch always sounds the same. We are building a serious product. If we do not lay down scalable, cloud-native infrastructure now, we will pay for it when the load arrives. Kubernetes from day one is professional. It is future-proof. It sounds like mature engineering. It is closer to the most expensive sentence a small team can say, and it has burned more runway than any traffic spike ever did. This is a field guide to the wheel: where it came from, what it actually costs, where it genuinely belongs, and how to tell - with observable signals, not vibes - when it is finally your turn to hold it. ## Where the wheel came from Kubernetes did not descend on the industry as a neutral standard. It escaped from one very specific building. Google spent the 2000s learning to pack machines. Its engineers pushed cgroups into the Linux kernel, and its internal scheduler - Borg - grew into the thing that ran Search, Gmail and MapReduce alike: one brain bin-packing hundreds of thousands of jobs onto shared fleets so that no machine ever sat idle. Borg stayed a trade secret for a decade. The public confession only arrived in April 2015, when the [Borg paper](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/) was finally published - by which point its grandchild was already famous. The grandchild started on June 6, 2014, with a first GitHub commit of 250 files and 47,501 lines. Inside Google the project ran as Project Seven - after Seven of Nine, the Star Trek drone who left the Borg collective; a friendlier Borg. The public name became Kubernetes, Greek for helmsman, and [the seven spokes in the ship's wheel logo](https://www.geekwire.com/2016/ever-come-kooky-kubernetes-name-heptio/) stayed on as the receipt for the joke. On July 21, 2015, version 1.0 shipped at OSCON - 14,000 commits from more than 400 contributors in thirteen months - and Google donated the project to the newly founded Cloud Native Computing Foundation the same day. Then came the orchestration war: Docker Swarm, Mesos, Nomad, half a dozen contenders for the default. It effectively ended in October 2017, when Docker began shipping Kubernetes inside its own product. By mid-2018 Kubernetes had become the first project to graduate from the CNCF, and Amazon and Microsoft had taken their managed offerings GA within weeks of each other, three years behind Google's. The wheel had won. ![Timeline of the Kubernetes decade, from Borg through the first commit, v1.0 and CNCF, the orchestration war, k3s and the autopilot tier, to EKS Auto Mode at year ten.](/blog/images/posts/kubernetes-day-one/the-decade.jpg) *Ten years from first commit to default answer. Born to bin-pack Google's fleet, adopted to run everything.* Hold on to the origin, because it is the whole argument. Kubernetes is the public descendant of a system built to bin-pack enormous shared fleets for thousands of engineers. That is the problem it solves brilliantly. So the question for a startup is not whether Kubernetes is good. It is whether you have Google's problem yet. ## The graveyard has no scalability wing CB Insights maintains a long-running analysis of startup post-mortems, [The Top 20 Reasons Startups Fail](https://s3-us-west-2.amazonaws.com/cbi-content/research-reports/The-20-Reasons-Startups-Fail.pdf). The leaders: no market need at 42%, ran out of cash at 29%, not the right team at 23%. Read all twenty entries. Could not scale the infrastructure is not on the list. Not at number twenty. Not anywhere. The graveyard of startups killed by a lack of microservices is empty. The graveyard of startups that shipped too slowly while the money ran out is the entire cemetery. And day-one Kubernetes bills you in exactly the two currencies the post-mortems name: cash and attention. If the trade is that lopsided, why do smart engineers keep making it? Four honest reasons. **Resume-driven development.** Migrated to Kubernetes reads better in a performance review than decided we did not need it. Nobody gets promoted for keeping the system boring - which is a defect in performance reviews, not in boring systems. **The cargo cult.** Netflix does microservices, so we should. Netflix also streams to 190 countries. The essay every founder should frame - [You Are Not Google](https://web.archive.org/web/20190406163106/https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb), 2017 - said it plainly: copying the form of a giant's architecture without the giant's context is imitation, not engineering. **Imported defaults.** Engineers arriving from big platform teams know how to build Kubernetes systems; it is what they did all day. Knowing how is not the same as knowing when, and the previous employer's defaults travel in the luggage. **Enterprise cosplay.** A cluster makes twelve users look like a serious operation. Actual due diligence reads uptime, code quality and unit economics; a twelve-user cluster signals a capital allocation problem, not maturity. ## What the wheel actually costs The managed tier is real progress: EKS, AKS and GKE run the control plane for you, at list prices around $0.10 per cluster hour. That is $876 a year and the least interesting line on the bill, because the control plane was never the expensive part. Everything else still lives on your side of the fence. Node pools and their upgrades - upstream ships three releases a year and supports each for about fourteen months, and falling behind now has a price tag: [EKS bills extended support at $0.60 per cluster hour](https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing/), six times the standard rate, a version-lag tax institutionalized in April 2024. The CNI and its IP exhaustion moods. Ingress controllers and cert-manager. Secrets, which are base64 by default, not encryption. RBAC, admission policies, autoscaler tuning, and the observability stack you need to see any of it. None of that is the control plane. All of it is now your platform. Then there is the fleet itself. [Datadog's 2023 container report](https://www.datadoghq.com/about/latest-news/press-releases/datadog-announces-2023-report-on-real-world-container-use-reveals-rise-in-serverless-containers/), drawn from 2.4 billion containers, found that more than 65% of Kubernetes workloads use less than half of the CPU and memory they request. Overprovisioning is not an accident of sloppy teams; it is the default outcome when three people are shipping product and nobody's job is tuning requests. Which points at the real line item: the person. The moment the cluster exists, someone owns it - the upgrades, the incidents, the 3 a.m. page. At startup scale that is a platform engineer hired to serve three services and a Postgres. The adoption numbers are what make the myth feel safe. [CNCF's 2023 survey](https://www.cncf.io/reports/cncf-annual-survey-2023/) put 66% of surveyed organizations in production with Kubernetes and another 18% evaluating it. The standard is real. It was also standardized by organizations that have the fleet problem - and adoption statistics do not transfer the problem to you along with the YAML. ## The escape stories are the honest data The direction of travel among teams that measured is instructive. - **Prime Video, 2023.** The audio/video monitoring team [rebuilt its distributed pipeline as a single process](https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90) after Step Functions orchestration and S3 round-trips between components dominated the bill. Cost fell by over 90%. The footnote that matters: this was one workload, not all of Prime Video - which is precisely the lesson. Architecture is a per-workload decision even inside Amazon. - **Segment, 2018.** [Goodbye Microservices](https://segment.com/blog/goodbye-microservices/): about 140 services consolidated back toward one, because the queues, repos and version skew had eaten the team alive. - **Istio, 2020.** The flagship service mesh - the product whose entire job is making microservices survivable - [merged its own control-plane microservices into one binary, istiod](https://istio.io/latest/blog/2020/istiod/). When the mesh itself goes monolith, update your priors. - **Kelsey Hightower, January 2020.** On the record, mid-Kubernetes-boom, from one of the faces of Kubernetes itself: [Monoliths are the future](https://changelog.com/posts/monoliths-are-the-future) - because the problem people try to solve with microservices rarely lines up with the problem they actually have. - **37signals, 2022 onward.** The adjacent exit - cloud rather than Kubernetes, same disease. A $3.2 million annual cloud bill traded for [about $700,000 of owned Dell hardware that paid for itself within 2023](https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010), with [close to $2 million saved in the first year](https://www.datacenterdynamics.com/en/news/37signals-claims-it-saved-almost-2m-last-year-from-cloud-repatriation/) and a projected ten million over five. Infrastructure ceremony is a bill, and bills compound. None of these stories say Kubernetes is bad. They say complexity is bought with real money, the receipt arrives monthly, and even very large teams periodically discover they bought too much. ## Where the wheel belongs At the right scale Kubernetes is not merely defensible - it is glorious. The honest list: - **You ship software into other people's clusters.** For ISVs the Helm chart is a distribution format. Your customers' platform teams expect it; this alone justifies living the cluster life. - **Multiple teams block on each other's deploys**, and services genuinely need different scaling profiles and release cadences. - **Mixed fleets.** Batch plus serving plus GPU on shared capacity, where bin-packing pays salaries. This is literally the problem Borg was born for. - **On-prem, air-gapped, regulated.** No PaaS exists inside your data center; k3s or Talos on your own metal is the honest platform there. - **A contract says portability or multi-cloud**, with penalties attached. - **A platform owner already exists** - not will be hired. Ownership precedes the cluster, never follows it. And the mirror list, where it does not belong: product-market fit still hypothetical; one team, one product, one database; a CRUD API in front of Postgres; nobody whose full-time job the platform would be; investors will like it. If the scaling problem is hypothetical, the cluster is a costume. ## Five ways to hold a container The implementation menu, from most metal to least: **Your own metal.** kubeadm, k3s or Talos on machines you rack. You own everything: etcd, CNI, storage, load balancing, power. Cheapest iron per unit of compute, dearest weekends. The right answer for GPU fleets, edge boxes and sovereignty constraints; the wrong answer for a first cluster. **Self-managed on cloud VMs.** kubeadm on EC2 or Azure VMs: cloud prices and bare-metal operations at the same time. Once a hedge against lock-in; today mostly a historical artifact. **Managed control plane.** EKS, AKS, GKE. They run the API server and etcd; node pools, upgrades, CNI, ingress, secrets and observability remain yours. The honest deal once you actually have the fleet problem. **The autopilot tier.** GKE Autopilot since 2021, Fargate under EKS, AKS Automatic, and - [since re:Invent in December 2024 - EKS Auto Mode](https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-eks-auto-mode/). You pay a premium per pod and surrender node control; the vendor absorbs node operations. Even AWS now sells the admission that node ops were the expensive part all along. **No cluster at all.** Cloud Run, Azure Container Apps - which runs Kubernetes, KEDA, Dapr and Envoy under the hood and simply declines to show you the YAML - App Runner, Fly.io, Railway, Render. A Dockerfile goes in, a URL comes out, idle services scale to zero. For day one this is not the compromise option. It is the correct engineering. ![Comparison table: no cluster versus managed Kubernetes versus your own metal, across control plane, node ops, what you write, TLS, scaling, cost floor, team needed, failure modes and when each is right.](/blog/images/posts/kubernetes-day-one/where-containers-live.jpg) *Where containers live. Start in the left column; climb right only when a signal says so.* ## The ladder, again Regular readers will recognize the shape - it is the same escalation ladder as [our load balancer field guide](/blog/l4-vs-l7): start at the bottom rung, climb only when it hurts, keep the exits marked. Keeping the exits open costs almost nothing: ``` FROM node:20-slim WORKDIR /app COPY . . RUN npm ci --omit=dev CMD ["node", "server.js"] ``` A Dockerfile from day one keeps every future door open - the image that runs on Railway today runs unmodified on EKS in three years. Keep state in managed services, keep the app tier stateless, hold the twelve-factor line. That is the entire day-one obligation to the future. Then run every complexity proposal through the one-sentence test: name, in one sentence, the problem Kubernetes solves for us today, without the words when we grow. If the answer needs three paragraphs, it is a resume, not a requirement. The signals that say climb - all observable, none aspirational: - ten or more services with genuinely divergent scaling profiles - several teams stepping on each other's deploys - a platform owner who already exists and already spends the week on this - a cloud bill large enough that utilization gains pay that salary - a customer contract that says Helm, on-prem, or multi-cloud Migrating a working, containerized monolith onto Kubernetes when the signals turn real is weeks of work through a door you kept open. Carrying a cluster for two years while hunting product-market fit is a bill with no refund column. ## Verdict Take the wheel when: - the Borg problem is yours: fleets, many teams, bin-packing that pays - customers receive your software as a Helm chart - regulation or air-gaps keep you on your own metal - the platform owner exists before the platform does Keep the paper boat when: - product-market fit is still a hypothesis - one team, one service, one database - the platform owner would be you, at 3 a.m., between feature branches - the strongest argument on the table is we will be glad later Kubernetes is a superb tool for scaling a success. It is a terrible tool for finding one. ## Reading - [Large-scale cluster management at Google with Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/) - Verma, Pedrosa, Korupolu, Oppenheimer, Tune, Wilkes; EuroSys 2015. The ancestor's confession. - [10 Years of Kubernetes](https://kubernetes.io/blog/2024/06/06/10-years-of-kubernetes/) - the project's own history of the decade, seven spokes included. - [You Are Not Google](https://web.archive.org/web/20190406163106/https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb) - Oz Nova, 2017. The essay this post is footnotes to. - [MonolithFirst](https://martinfowler.com/bliki/MonolithFirst.html) - Martin Fowler, 2015. The pattern the industry keeps rediscovering the hard way. - [Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%](https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90) - the escape story, told from inside. - [The Top 20 Reasons Startups Fail](https://s3-us-west-2.amazonaws.com/cbi-content/research-reports/The-20-Reasons-Startups-Fail.pdf) - CB Insights. Note what is absent from the list.