Do You Need Kubernetes?
The most professional architecture is the smallest one that meets the requirements.
Fast answer: Probably not yet, and possibly never. Kubernetes solves coordination problems that appear when you have many services, many machines, and many teams. A managed platform already restarts failures, scales containers, routes traffic, and rolls out releases for one API and a database. Adopt Kubernetes when you can name the capability your platform lacks, not when the job ads make it feel mandatory.
Match the tool to the system you actually have
Be honest about the shape of the system. The Kubernetes origin story in Lesson 5 was millions of users, many services, many servers. Most real systems, including successful commercial ones, look like this:
one API + one database + maybe a cache
For that shape, the questions Kubernetes answers (which server gets this container? what if a node dies? how do fifty services find each other?) mostly do not exist yet. You would be installing the answer machine before having the questions.
What already does the job
The middle of the ladder is where most projects should live, and it is conspicuously under-marketed:
| Option | It handles | You still own |
|---|---|---|
| Managed app platform (Railway, Render, Fly.io) | HTTPS, deploys, restarts, logs, simple scaling | Your app, your data decisions |
| Managed containers (Cloud Run, ECS Fargate) | Image-based releases, scaling, no hosts to patch | Service design, observability |
| One VM with Compose | Full control at fixed low cost | Patching, backups, routing, supervision |
| Managed Kubernetes (EKS, GKE, AKS) | The full control plane from Lesson 5 | Substantial platform complexity, forever |
Read the first two rows again. Restart on failure, scale on traffic, gradual rollouts, stable routing: the platforms already run these loops for you. They are Kubernetes' benefits, purchased without Kubernetes' operational bill. The bill is real: a cluster is another system to configure, secure, upgrade, monitor, and understand at 3am, and "managed" Kubernetes manages the control plane, not your workloads.
The sentence test
When the "should we use Kubernetes?" conversation arrives, complete this sentence before deciding:
"Our current platform cannot reliably ________, and Kubernetes would provide it by ________."
Filled blanks that justify the move do exist: dozens of services owned by several teams needing one deployment platform; scheduling and networking requirements a managed platform cannot express; compliance rules forcing your own infrastructure; a cost curve at real scale where the platform premium exceeds a platform team. If the blanks stay vague ("scale, probably?", "everyone uses it"), the decision is not ready, and the vague version has a name: resume-driven development.
Growing into it, not starting with it
The honest growth path adds machinery only when a named problem arrives:
one managed platform + managed database ← start here, stay while it works
│ traffic, team, or requirements grow
▼
managed containers + managed data services
│ many services, many teams, platform needs
▼
Kubernetes, adopted for named reasons
Moving up a rung after outgrowing the previous one is a good day: it means the product worked. Skipping rungs "to be ready" means paying the top rung's complexity bill from day one, on the timeline where you least afford it. WhatsApp's famously tiny team (the apps-course capstone) is the canonical proof that boring, minimal infrastructure scales further than the conference talks suggest.
What you should now understand
You now hold the whole map: Docker packages an environment (1), Compose and networks connect services by name (2), registries and pipelines turn images into identifiable, reversible releases (3), four habits keep those images safe (4), and Kubernetes reconciles desired state across a fleet when a fleet is genuinely what you have (5).
The skill that ties it together is not fluency in any one tool. It is hearing a requirement, locating it on the map, and choosing the smallest dependable answer. Tools change; the questions they answer do not.
Try it: make the architecture decision
A three-person team runs one API, PostgreSQL, and Redis. Its managed platform provides HTTPS, health checks, gradual deployments, logs, and autoscaling. The service is growing, but the team cannot name a platform limit it has reached.
Your recommendation: remain on the managed platform and measure the system. "Growing" is not a missing capability. Revisit the decision when a specific requirement (such as unsupported scheduling, multi-team platform consistency, or a demonstrated cost constraint) creates a real gap.
If "it depends" feels unsatisfying
The decision is not subjective; it is conditional. Write the requirement, compare it with what the current platform guarantees, and identify the gap. Kubernetes is justified when it closes that gap at a lower total cost and risk than the alternatives.
Check your understanding
Answer before opening each explanation.
What would Kubernetes add for a two-person team whose managed platform already restarts, rolls out, and scales one API?
Hint: Name the missing capability, not the fashionable tool.
Answer: No required capability is missing in that description. Kubernetes would mainly add another platform to configure, secure, upgrade, monitor, and learn.
What different questions do Docker, a cloud provider, and Kubernetes answer?
Hint: Separate packaging, rented infrastructure, and coordination.
Answer: Docker packages and runs an application consistently. A cloud provider supplies infrastructure and managed services. Kubernetes coordinates container workloads across machines. Saying "we need all three" does not justify the coordination layer until a coordination requirement is named.
What does managed Kubernetes manage, and what remains yours?
Hint: Managed control plane does not mean managed application.
Answer: The provider commonly operates the control-plane components and their availability. You still own workload configuration, images, permissions, secrets, network policy, observability, upgrades and compatibility, data, cost, and incident response.
Give one strong and one weak completion of the sentence test.
Hint: A strong answer names both the gap and the mechanism.
Answer: Strong: "Our platform cannot schedule GPU workloads across our owned machines, and Kubernetes would provide it through device plugins and declarative scheduling." Weak: "Our platform may not scale enough someday, and Kubernetes would make us scalable." The weak version supplies neither evidence nor a mechanism.
Build what you deploy
You know how the machinery works. Mastering APIs With Python is where you build the thing worth deploying: 30 chapters in Python, ending with a containerised API on AWS with CI/CD, monitoring, and a production capstone. Three full chapters are free.