Container Strategy
Container Strategy is the enterprise approach to packaging applications in containers (Docker, OCI-compliant images) and orchestrating them at scale — almost universally with Kubernetes (Amazon EKS, Google GKE, Azure AKS, Red Hat OpenShift, or self-managed). The CNCF (Cloud Native Computing Foundation) reports Kubernetes adoption at 96% of organizations using or evaluating containers, with 5+ million Kubernetes developers globally as of 2023. Containers solved the deployment portability problem that plagued the previous decade — 'works on my machine' largely went away, app delivery became environment-agnostic. Kubernetes solved orchestration: scheduling, scaling, self-healing, service discovery across thousands of containers. The KnowMBA POV: Kubernetes is solving a problem most organizations don't have at the scale they have it. The platform is genuinely transformative for organizations running hundreds of services across multiple environments at significant scale. For organizations running 20 services on 5 nodes, Kubernetes is operational complexity that exceeds what it replaces — and the wave of 'we adopted Kubernetes because everyone else was' produced thousands of regretful platform teams maintaining clusters they don't need.
The Trap
The trap is adopting Kubernetes for status rather than need. Kubernetes is operationally heavy: cluster lifecycle management, networking (CNI plugins, service mesh decisions), storage (CSI drivers, persistent volume patterns), security (RBAC, network policies, pod security standards), upgrades (every 4 months Kubernetes ships a new minor version, deprecating APIs), observability, autoscaling tuning. A small platform team running production Kubernetes for an organization with modest scale (e.g., 30 services, 10 nodes, predictable load) is doing a job that managed PaaS (Heroku, Cloud Run, App Runner, Fly.io, Railway) or even traditional VMs would do at a fraction of the cognitive load. The operational headcount required to run a serious internal Kubernetes platform is 4-12 platform engineers depending on scale — easily $1.5-5M/year in fully-loaded cost before the cluster bills. The deeper trap: organizations adopt Kubernetes 'because cloud-native' without ever measuring whether they got the velocity they were promised. They got the complexity for sure.
What to Do
Six moves. (1) Decide whether you need Kubernetes by asking: do we run more than ~50 services? Do we need to deploy on multiple clouds or hybrid? Do we have variable load requiring autoscaling? Do we have a platform team with 4+ engineers we can dedicate to it? If 'no' to most, choose managed PaaS instead. (2) If yes, choose managed Kubernetes (EKS, GKE, AKS) over self-managed — control plane management is the single biggest operational burden of self-managed clusters and adds zero business value. (3) Standardize on a small set of platform abstractions: one CNI, one ingress controller, one secrets manager, one observability stack. Polyglot 'every team picks their tools' Kubernetes is unmaintainable. (4) Build an internal developer platform on top of Kubernetes (Backstage, Humanitec, Internal Developer Platforms) so application teams don't have to learn YAML, kubectl, and Helm to ship — only platform engineers should think in Kubernetes primitives. (5) Treat upgrades as a continuous capability, not a quarterly project — Kubernetes deprecates APIs aggressively, and out-of-support clusters are a security liability. (6) Track cost per workload rigorously — Kubernetes makes resource consumption invisible to teams, leading to massive over-provisioning. Tools like Kubecost, OpenCost, or cloud-provider native (AWS Cost and Usage Reports) are mandatory.
Formula
In Practice
Kubernetes was open-sourced by Google in 2014 (based on internal Borg) and donated to CNCF in 2015. Adoption was rapid: by 2019, the CNCF Annual Survey reported 78% of respondents using Kubernetes in production. The platform's ascendance produced a generation of platform engineers and a thriving ecosystem (Helm, Istio, Prometheus, Argo CD, etc.). The pattern that emerged across enterprise adoption: organizations with genuine scale (Spotify with 1,800+ microservices, Airbnb, Box, Pinterest) reported significant value capture — Kubernetes enabled their engineering velocity at scale. Smaller organizations frequently reported the opposite — they adopted Kubernetes following industry pattern, then spent years discovering they didn't need its complexity. Notably, in 2020 onward, some companies publicly migrated AWAY from Kubernetes back to simpler runtimes (PaaS, managed services, or even VMs) — Pythagora, Render, and others built businesses specifically targeting the 'don't use Kubernetes' segment. Amazon's own ECS and Lambda offerings positioned explicitly as Kubernetes alternatives for many workloads. The market matured into a clearer view: Kubernetes for genuine scale, managed PaaS for everyone else.
Pro Tips
- 01
Count your services before adopting Kubernetes. Below ~30-50 production services, the operational overhead of Kubernetes typically exceeds its benefit. Heroku, AWS App Runner, Google Cloud Run, Fly.io, Railway, and Render exist precisely because most organizations would be better served by them. Kubernetes is excellent at very large scale; it is not the default deployment platform for general workloads.
- 02
Managed Kubernetes vs self-managed is rarely a close call. EKS, GKE, AKS each cost ~$73/month per cluster control plane — trivial compared to the 1-2 platform engineer FTE needed to run a self-managed control plane reliably. The exceptions (regulatory requirements, sovereignty concerns, on-prem-only deployments) are real but smaller than people assume. Default to managed.
- 03
Kubernetes upgrades are the silent operational tax. Kubernetes ships a minor release every ~4 months and supports each version for ~14 months. Out-of-support clusters lose security patches. Production Kubernetes platforms therefore require continuous upgrade capacity — typically 1-2 engineer-weeks per quarter just for upgrades, more if you also run service mesh, ingress controllers, and other ecosystem components. Budget the upgrade tax explicitly.
Myth vs Reality
Myth
“Kubernetes is the standard way to deploy applications now”
Reality
Kubernetes is the standard at large scale — it is dominant for organizations with hundreds of services and dedicated platform teams. For the majority of small and mid-sized organizations, managed PaaS (Cloud Run, App Runner, Heroku, Fly.io) or even traditional VMs deliver application deployment with dramatically less operational complexity. The 'standard' designation reflects industry attention, not universal fit.
Myth
“Containers and Kubernetes are essentially the same decision”
Reality
Containers (Docker, OCI images) are nearly universally beneficial — they solve packaging and portability problems and have low operational cost. Kubernetes is a separate, much larger commitment for orchestration. Many organizations should containerize without adopting Kubernetes — running containers on App Runner, Cloud Run, ECS Fargate, or even VMs delivers most of containerization's benefits without Kubernetes's operational overhead.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Scenario Challenge
You're the new VP Engineering at a 150-person SaaS company. The previous CTO adopted Kubernetes (self-managed on EC2) two years ago when the company had 8 engineers. The cluster runs 18 microservices, you have 1 dedicated 'DevOps engineer' constantly firefighting cluster issues, and the engineering team is frustrated that simple deploys take days because of Kubernetes complexity. Cluster bills are $14K/month (heavily over-provisioned). Velocity is your biggest bottleneck.
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
When Kubernetes Justifies Its Overhead (Service Count)
Heuristic for organizations choosing container orchestration platformsStrong Fit (Kubernetes typically justified)
> 100 services
Reasonable Fit
50-100 services
Marginal Fit
20-50 services
Poor Fit (PaaS likely better)
< 20 services
Source: Hypothetical: composite from CNCF reports, platform engineering community guidance
Platform Engineering Team Size for Self-Managed K8s
Operating self-managed production Kubernetes reliablyMassive Scale (1000+ services)
10-25+ FTE
Large Enterprise
6-10 FTE
Mid-Market
3-6 FTE
Below Critical Mass
<3 FTE — high risk
Source: Hypothetical: composite from platform engineering case studies
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Kubernetes (CNCF)
2014-Present
Google open-sourced Kubernetes in 2014, donated to CNCF in 2015. Within five years, Kubernetes became the dominant container orchestration platform: by 2021, the CNCF survey reported 96% of respondents using or evaluating Kubernetes. The ecosystem grew enormous: Helm (package management), Istio (service mesh), Prometheus (observability), Argo CD (GitOps), Backstage (developer portal), all becoming standards. The success was real for organizations at scale — Spotify (1,800+ microservices), Pinterest, Box, and similar adopted Kubernetes successfully. The market also developed a counter-narrative around 2020-2023: significant numbers of mid-sized organizations publicly reported migrating OFF Kubernetes to managed PaaS, citing operational overhead vs. their scale. Companies like 37signals (Basecamp/HEY) wrote influential blog posts about leaving cloud entirely. The narrative matured: Kubernetes is dominant where it fits, less universally appropriate than the early hype suggested.
CNCF Adoption (2021)
96% using or evaluating
Kubernetes Developers (Globally)
5M+ as of 2023
Major Releases
Every ~4 months
Counter-trend (2020-Present)
PaaS resurgence for sub-scale orgs
Kubernetes adoption became a pattern as much as a decision — many organizations adopted it for industry conformance rather than scale need. The result was thousands of platform teams maintaining clusters they didn't need. The mature view: Kubernetes is excellent at scale, less universal than the hype, and the alternative (managed PaaS) is genuinely good and right for many organizations.
Spotify
2017-2020
Spotify migrated from a homegrown deployment platform (Helios) to Kubernetes (Google GKE) over roughly 3 years, completing the migration around 2020. At the time of migration completion, Spotify ran 1,800+ microservices across multiple Kubernetes clusters, with hundreds of engineering squads deploying autonomously. The migration succeeded largely because Spotify also built Backstage (open-sourced 2020) — an internal developer platform on top of Kubernetes that gave squads a high-level abstraction they could use without learning Kubernetes primitives. Backstage subsequently became a CNCF project itself and the most-adopted internal developer portal pattern, showing that Kubernetes at enterprise scale requires an additional abstraction layer for the application teams.
Microservices at Migration End
1,800+
Engineering Squads
Hundreds, deploying autonomously
Migration Duration
~3 years
Open-source Output
Backstage (developer portal)
At enterprise scale, Kubernetes requires an internal developer platform on top of it — application teams should never need to learn YAML, kubectl, or Helm directly. Spotify's success was as much about Backstage as about Kubernetes. Organizations adopting Kubernetes without budgeting for the developer platform layer are systematically underestimating the work.
Decision scenario
The Kubernetes Adoption Decision
You're the new CTO of a 90-engineer SaaS company. You inherited 22 services running on AWS ECS Fargate, a small platform team (1.5 FTE) that's stretched but functional, $9K/month infrastructure cost. The previous head of engineering had a 'cloud-native modernization' plan ready to launch: migrate to self-managed Kubernetes on EKS with Istio, Argo CD, and a custom internal developer platform. Estimated 9-month migration, requires hiring 3 platform engineers (~$1.2M/year fully loaded), and projected $25K/month cluster infrastructure. The pitch: 'industry-standard platform, future-proof, attracts engineers.'
Services in Production
22
Current Platform
ECS Fargate (managed)
Current Platform Team
1.5 FTE
Current Infrastructure Cost
$9K/month
Engineering Org Size
90 engineers
Decision 1
The migration plan is technically sound — you could absolutely execute it. The question is whether 22 services on a 90-engineer org justify the operational and financial overhead of self-managed Kubernetes with custom platform components. The board has approved the budget. Engineering leadership is divided: half want the 'modern' stack, half think it's overkill.
Execute the plan — Kubernetes is the industry standard, future-proofs the architecture, and helps with hiring senior platform engineersReveal
Pause the migration. Audit what specific problems Kubernetes would solve for the current scale (22 services, 90 engineers). Conclude that ECS Fargate fits the workload well, invest the $1.2M/year that would have gone to platform engineers into product engineering instead. Revisit Kubernetes when service count crosses 60-80 or when multi-cluster/multi-cloud requirements emerge.✓ OptimalReveal
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Container Strategy into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Container Strategy into a live operating decision.
Use Container Strategy as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.