You know how to use both. You brought Aurora Libros up with compose.yaml and per-environment overrides in module 4, and you deployed it on a cluster with a StatefulSet, Ingress, HPA and a rehearsed rollback in module 6. This lesson is not here to tell you which one wins, but to give you the criteria to decide which one your project needs, with the exact equivalences between both formats and an honest figure for the cost of maintaining a cluster.

1. They are not the same category of tool
2. The right question
3. An in-depth comparison, dimension by dimension
4. Conceptual equivalences
5. The same aurora-api, in both formats
6. Decision tree
7. The middle road: Compose in production
8. Swarm as a stepping stone, and the services that run Compose
9. Kompose and the real limits of conversion
10. The hidden cost of Kubernetes
11. Aurora Libros at three sizes

Comparing Compose with Kubernetes is like comparing a recipe with an industrial kitchen. Both are there so you can eat, but one is a document and the other is a system with staff.

The structural difference is in the fourth row. Compose runs what you ask for and finishes; Kubernetes stores your intent and never stops comparing it with reality. That loop is what gives you a node failing at four in the morning and the Pods reappearing on another one without waking anybody. It is also what forces you to maintain a control plane.

It is not "which one is better?". It is a battery of concrete questions:

1. Can you afford for the platform to be down for fifteen minutes while you restart a machine?
2. How many nodes are you really going to have within a year: one, three or thirty?
3. Is there anybody on the team who can debug a CrashLoopBackOff without searching the Internet?
4. Who is on call at three in the morning, and is being paid for it?
5. Is your load constant, or does it have ×8 peaks that demand autoscaling?
6. Does the budget cover the control plane plus the nodes with spare headroom?

If you answered "fifteen minutes is acceptable, one node, nobody, nobody, constant, no" — which is the situation of most projects — then Compose is the professional answer, and saying so out loud will save you a year of suffering. If you answered the opposite on three or more questions, Kubernetes starts to pay for its cost.

The last three rows decide more projects than all the ones above put together, and they are the ones that show up least often in comparisons on the Internet.

Almost everything you wrote in the Aurora Libros compose.yaml has a translation. What changes is not the idea, but how many objects it takes to express it.

Two rows deserve a warning. The depends_on one: in Kubernetes global ordered startup does not exist; the API Pod will start even if PostgreSQL is not there, it will fail, and CrashLoopBackOff will retry it until the database answers. It is ugly to watch and it is the right behavior: it forces the application to tolerate its dependencies being absent, which is exactly what you learned in 06-01. And the Secret one: it is base64-encoded, not encrypted; without encryption at rest for etcd and RBAC set up properly, it is not a secret, it is text that is inconvenient to read.

Compose, as it ended up after module 4:

Twenty-eight lines. Now the same thing in Kubernetes, without cutting anything essential:

The ratio of more than twice the YAML is not a cosmetic detail: it multiplies per service, and with four services and three environments you end up with a directory nobody reads in full any more. In exchange, every extra line buys something real. The question is whether you need what it buys.

Five criteria, and not one of them is "what everybody else is doing". Notice that the path towards Kubernetes demands two yeses in a row — knowledge and budget — and that node H exists because the worst possible decision is a self-managed cluster nobody knows how to repair.

There is a very widespread and false idea: that Compose "is not for production". Compose on a properly set up host serves millions of requests a day at real companies. What it takes is setting it up with judgment:

The two gaps it cannot close: the host is a single point of failure (if the machine dies, the service dies until you bring up another one) and there is no autoscaling. If the business tolerates those two gaps — and a great many businesses do — you have solved the platform with one file, with no control plane and no on-call rota.

An honest sizing rule: a 4 vCPU, 8 GB VM with a well-tuned Aurora Libros stack comfortably serves several hundred requests per second. Before assuming you need a cluster, measure with the load test from 06-06.

If the only problem is the single point of failure, there is an intermediate step before the big leap.

Swarm (06-03) deserves a paragraph of honesty: it is simple, it works, and taking your compose.yaml to three nodes costs you adding deploy: and running docker stack deploy. But its ecosystem is frozen, hiring somebody who knows it gets harder every year and third-party documentation is scarce. As a temporary stepping stone it is reasonable; as a five-year bet, think twice.

Cloud Run-style services are the new development that changes the decision tree: they autoscale from zero to hundreds of instances without any cluster existing to maintain. For ghcr.io/auroralibros/aurora-api:2.0.0 — stateless, with probes, twelve-factor and graceful shutdown — they fit without touching a thing. State moves to a managed database, and availability stops being your problem.

kompose translates a compose.yaml into Kubernetes manifests. It is useful as a starting point and dangerous as a finished result.

The practical conclusion: kompose saves you the first 60 % of the typing and saves you none of the thinking. Everything that makes a deployment production-ready — separate probes, measured requests and limits, a PDB, a network policy, an Ingress with TLS — is still your work. Treat it as a draft, review it line by line, and never apply it directly against a real cluster.

What does not appear in the slide decks:

The last row is the one that decides. Phrase it like this in the meeting: "if the cluster breaks on a Saturday at three in the morning, who fixes it, how fast, and paid how much?". If there is no answer with a person's name in it, Kubernetes is not an option yet, however good it looks on the architecture diagram.

And it is worth saying the other way round too: when the answer does exist, Kubernetes gives back far more than it costs. Real autoscaling, deployments with no outage, automatic rescheduling, per-team quotas and an ecosystem that solves problems you did not know you had. The mistake is not choosing Kubernetes; it is choosing it too early.

Look at the third column: a lot of traffic at peak does not imply Kubernetes. It implies autoscaling, and there is more than one way to get it. And in the second one, what tips the balance is not just the traffic: it is that there is a person with a systems profile. Without that person, the recommendation would be different even if the traffic were the same.

• Choosing Kubernetes for your CV. It is a real, human reason, and it is the worst of them all for the project. If you want to learn it, set up a lab cluster with kind, not the company's production platform.
• Believing that "Compose is not for production". With digests, limits, log rotation, tested backups and monitoring, Compose sustains real businesses. What it does not give you is tolerance to the host falling over, or autoscaling.
• Applying the output of kompose without reviewing it. It loses depends_on, it does not generate the three probes or an Ingress, HPA or PDB, and it ignores bind mounts.
• Migrating to Kubernetes without having measured. Before justifying a cluster on performance grounds, run the load test from 06-06 against the current host. The real limit is usually in the database, and a cluster does not move it.
• Translating depends_on expecting ordered startup. It does not exist. The application has to retry; if it does not, fix that before migrating.
• Treating Secret objects as encrypted. They are base64. Without encryption at rest for etcd and strict RBAC, they protect nothing.
• Tip: write the decision and its reasons in a short document inside the repository, with a date. A year from now you will want to know why it was chosen, and whether the premises still hold.
• Tip: keep the compose.yaml alive even if you deploy on Kubernetes. It is the best way to bring the whole stack up locally to develop and debug.
• Tip: when in doubt, start with Compose. Migrating from Compose to Kubernetes with a well-built image is days of work; dismantling a cluster nobody knows how to operate takes months.

Exercise 1 — Translate a complete service. Take the aurora-cache service (redis:7-alpine, not exposed externally, with a volume for optional persistence, a 256 MB memory limit and a healthcheck using redis-cli ping) exactly as it stands in the compose.yaml. Write it in Kubernetes: Deployment, an internal Service and a PersistentVolumeClaim. State which element of the original has no direct equivalent and how you solve it.

Exercise 2 — Apply the decision tree. For each scenario, walk the tree from §6, state the final node and justify the decision in three sentences. (a) An internal invoicing API used by 30 employees during office hours, with one developer who also acts as the administrator. (b) A ticket-selling platform that sells out a concert in 90 seconds, with a five-person platform team and an on-call rota. (c) A corporate blog with 400 visits a day that an external supplier wants to deploy on a managed cluster "because it is the standard".

Exercise 3 — The real cost of the decision. Aurora Libros is growing and management asks whether "we should move to Kubernetes". Prepare a one-page comparison with: estimated monthly infrastructure cost in both scenarios (use approximate provider figures and state your assumptions), learning and setup time, what measurable improvement the cluster brings, what new risk it introduces, and your recommendation together with the condition that would have to be met to change it.

Solution 1.

What has no direct equivalent is Compose's single healthcheck: here it has been split into liveness and readiness, both using redis-cli ping but with different periods, because in Kubernetes "it is alive" and "it can take traffic" are separate questions. Three more decisions the brief did not give you and that you have to reason about: strategy: Recreate instead of rolling, because a ReadWriteOnce PVC cannot be mounted on two Pods at once and the rolling update would get stuck; Redis's --maxmemory set below the container's limits.memory, so Redis evicts keys before the kernel kills the process with an OOM; and the absence of externally exposed ports, since a Service with no type is ClusterIP and can only be reached from inside the cluster, which is exactly what was asked for.

Solution 2.

(a) Internal invoicing API. Tolerable outage: hours, because outside office hours nobody is using it. A single node is enough and there are no peaks. Final node: Compose on a properly set up host. The single administrator cannot sustain a cluster, and a deployment with restart: unless-stopped, tested backups and basic monitoring covers the requirement with room to spare. Adding Kubernetes here would multiply the operational cost without improving anything you could notice.

(b) Ticket sales. The tolerable outage is zero during the 90 seconds that matter, there is a platform team and there is an on-call rota. The peak is brutal but predictable to the second, which lets you pre-scale ahead of the event instead of waiting for the HPA to react. Final node: managed Kubernetes. This is the textbook case: real high availability, autoscaling, deployments without outages and a team that can operate it. Here the cluster gives back what it costs.

(c) Corporate blog. 400 visits a day is about 0.005 requests per second on average. The tolerable outage is hours. Final node: Compose on one host, or plain static hosting if the content allows it. A managed cluster for this costs more per month than the blog itself generates in value, and it adds a dependency nobody on the team will know how to repair. Being "the standard" is not a requirement: ask the supplier to justify the decision using the same criteria as the tree and the conversation ends on its own.

Solution 3. Structure of the comparison (the amounts are illustrative and must be replaced with those of the real provider and region):

Measurable improvements from the cluster: automatic recovery when a node fails (from "minutes with human intervention" to "seconds without it"), autoscaling from 3 to 12 replicas under peaks, and outage-free deployments with a one-command rollback. New risks: dependence on knowledge that does not exist on the team today, more configuration surface that can fail, and a fixed cost that does not go down when traffic does.

Recommendation: stay on Compose and revisit the decision with a concrete trigger, not with a date. For example: "we move to managed Kubernetes when two of these three conditions are met: sustained host CPU above 60 %, the business setting an availability target above 99.9 %, or somebody with real experience operating clusters joining the team". Writing down the trigger turns a discussion of opinions into a verifiable condition, and that is the real deliverable of the exercise.

You can now defend the decision with criteria instead of with fashion. You are clear about the first and most forgotten point: they are not the same category of tool. Compose is a descriptor you run and it finishes; Kubernetes stores your intent in etcd and never stops reconciling it with reality. Every other difference follows from that one, including the good ones — automatic rescheduling, autoscaling, outage-free deployments — and the expensive ones.

You have the dimension-by-dimension comparison, with the three rows that decide more projects than any other: infrastructure cost, operational cost and team maturity. You have the complete equivalences table, with its two important warnings: depends_on has no translation because in Kubernetes ordered startup does not exist, and a Secret is base64, not encryption. And you have seen the same aurora-api in both formats: 28 lines against 63, one object against three, with the right question hanging over it — do you need what those extra lines buy?

The decision tree gives you five concrete criteria and a detail worth remembering: reaching Kubernetes demands two yeses in a row, knowledge and budget, and the worst option of all is a self-managed cluster nobody knows how to repair. You know that Compose in production is a perfectly professional decision when the host is set up properly — digests, limits, log rotation, tested backups, automatic TLS — with its two declared gaps: single point of failure and no autoscaling. You know the intermediate steps: Swarm, honest but frozen; the services that run your image without any cluster existing; and kompose, which saves you 60 % of the typing and none of the thinking.

And you take away the question that puts everything else in order: if the cluster breaks on a Saturday at three in the morning, who fixes it, how fast, and paid how much?. With the three versions of Aurora Libros — the small shop on Compose, the growing one on managed Kubernetes, the campaign one autoscaling without a cluster — you have three reference answers and the habit of writing the decision down, with its date and its review trigger, inside the repository.

In the next lesson we come down from the infrastructure to the desktop: Docker Desktop. What exactly that Linux VM you have been using without seeing it is, why it explains bind mount performance, what features it adds, what licensing terms it has — and why it is worth checking them before installing it at your company — and what alternatives exist on each operating system.