Last lesson. It is time to lift your eyes from the project and look ahead: which trends in the ecosystem have substance and which are still a bet, what is not going to change — and is therefore where your learning is best invested — and what you have managed to build across these 47 lessons. At the end you will find an honest self-assessment, recommendations for carrying on, and four concrete projects for consolidating what you have learned.

1. Where Docker stands today
2. How to read a trend
3. Rootless and reinforced isolation as the norm
4. WebAssembly in the container ecosystem
5. The supply chain as a regulatory requirement
6. Faster and more reproducible builds
7. Containers at the edge and on devices
8. AI workloads
9. Internal developer platforms
10. Maturity summary
11. What is not going to change
12. The road Aurora Libros travelled
13. Self-assessment
14. How to keep learning
15. Four projects to consolidate

In 2013 Docker was containers. In 2026 it is an excellent implementation of an open standard that it created and donated itself. That sentence sounds like decline and it is not: it is the definition of success for an infrastructure technology.

What is still theirs and still leads the field: the development experience. Docker Desktop, docker compose, BuildKit and Buildx, Scout and the documentation are the shortest path between an idea and a working container, and that is why they are still almost everybody's entry point. The company's strategy moved from the data center — where Kubernetes won — to the developer's laptop and to the supply chain, and there it is strong.

That the standard is open is the best news for you: what you have learned does not expire with a product.

Before the list, a filter. For each trend, three questions: what real problem does it solve?, how mature is it really?, and does it affect me now or in five years? Read it like this:

I am going to label every trend honestly, including the fashionable ones.

Maturity: in production. Docker's rootless mode (05-03), Podman's by default (07-05) and mandatory SecurityContext settings in Kubernetes all point the same way: root inside the container is no longer acceptable by default.

What is coming: admission policies that reject a deployment if the manifest does not comply — Kyverno, OPA Gatekeeper, Pod Security Admission — and reinforced isolation (gVisor, Kata) wherever third-party code runs. Aurora Libros already complies: it runs unprivileged, with read_only, cap_drop: [ALL] and no-new-privileges. What you did in module 5 as a best practice will be an admission requirement within a few years.

Maturity: promising, with niches already in production. Wasm is a portable bytecode format with a sandboxed security model. With WASI it can do input/output, and with runwasi it runs as just another container from containerd.

Where it fits today: serverless functions with unacceptable cold starts, plugins running customer code, proxy and mesh extensions, and devices with scarce resources.

What it does not replace, and it is worth saying plainly: PostgreSQL is not going to run on Wasm, nor is your API with a full node_modules and free access to the file system. Wasm is not here to replace containers; it is here to fill the gap where a container is too heavy. For aurora-api today, the answer is no. It is worth following, not worth rewriting anything for.

Maturity: in production, and moving towards mandatory. It is the trend with the most practical short-term impact, and you have already implemented it without knowing you were ahead of the curve.

The push is no longer only technical. In the United States there have been SBOM requirements for government suppliers since 2021, and in Europe the Cyber Resilience Act imposes security and component-transparency obligations on products with digital elements, with deadlines closing in during the second half of this decade. If your software is sold to European companies, this is going to reach your contracts in the form of a questionnaire.

Important warning: the precise scope, the deadlines and which products are covered are legal questions that change, and this is not legal advice. If your product may be affected, consult your organization's legal or compliance department and do not infer it from a technical course. What I can tell you is the practical part: you already know how to do the technical side, and turning up with SBOM, signing and provenance already in place turns an audit into a formality.

Maturity: in production. The build stopped being "waiting" and turned into an engineering problem, and BuildKit (05-05) is the engine behind almost everything that is coming.

Two deserve attention. Deterministic images take reproducibility to the extreme: today your build is reproducible in content, but timestamps make the digest vary; with fixed timestamps, two builds of the same commit produce the same digest, and that makes provenance verifiable by third parties without trusting anybody. And minimal bases like Wolfi or Chainguard: distributions designed for containers, with very fast patching and a goal of zero known CVEs, which solve the drip of vulnerabilities inherited from the base image. It is the natural successor to your node:22-alpine pinned by digest.

Maturity: in production in its niche. Taking containers to factories, shops, vehicles or antennas, where there is no data center and no administrator.

If Aurora Libros opened twenty physical bookshops with a catalog lookup terminal in each one, this would be its terrain: the same multi-architecture image, one k3s per shop or simply Compose, and deployment via GitOps. Not a single new piece to learn.

The interesting thing about the edge is that it inverts the priorities you have been working with all course long. In the data center bandwidth is cheap and a 300 MB image bothers nobody; in a shop with a shared connection, every megabyte of the image is paid for in minutes of update time multiplied by twenty locations. There the work from 05-04 — going from 142 to 102 MB — stops being an elegance and becomes the difference between updating the fleet overnight or over a weekend.

Maturity: in production, with unsolved problems. It is currently the biggest driver of change in the ecosystem, and where the limitations of the current model hurt the most.

The golden rule that emerges, and that is pure container common sense: model weights do not go inside the image. A 15 GB image that has to be rebuilt and redistributed every time a line of Python changes is a twenty-minute deployment. Weights are data: they go in a volume, in an object store or in a separate OCI artifact. It is exactly the separation between image and state that you learned in 03-06, applied to a new problem.

And one consequence that already affects you: startup times and size matter a great deal again, which pushes the whole ecosystem towards smaller images and faster starts. Nobody is going to miss that push.

Maturity: adoptable, with a lot of fashion around it. The realization they are born from: Kubernetes is too much for every developer to handle daily. The answer is a layer on top — Backstage, Crossplane, Score, Argo CD and a catalog of templates — that offers a simple interface and hides the YAML.

The rule that separates success from failure: an internal platform works when it abstracts without hiding. The day something fails, somebody will have to look at the Pods, the events and the logs, and no interface helps there. That is why what you have learned in this course is not made obsolete by an internal platform: it is made more valuable, because you are the one who can go down when the abstraction breaks.

If you had to spend this quarter on a single item from this table, it would be the second row. It is the one that already has a date attached.

Trends are entertaining; fundamentals are profitable. These five have been stable for a decade and will still be there when the fashions in this lesson have passed:

That is where your learning is best invested. Anyone who genuinely understands these five points moves between Docker, Podman, containerd, Kubernetes or whatever arrives in 2030 by reading the documentation over one afternoon. Anyone who only memorized commands starts over every time.

There is a simple test for finding out which group you are in. Think about these four questions and answer them in your head before reading on:

1. Why does changing a line in src/index.js not invalidate the npm ci layer?
2. Why can a stateless container be replaced and a stateful one cannot?
3. Why does the same image work for development and for production?
4. Why is localhost inside the container not your machine?

If all four have an immediate answer, those are not memorized commands: that is the model. And the model is what transfers to any future tool.

Aurora Libros started in 01-07 with fifteen manual onboarding steps: install Node, install the right version of PostgreSQL, install Redis, create the database, load the catalog, set up variables, and pray. Two days before somebody new could start the project, and a guaranteed "it works on my machine".

Today Aurora Libros is a real platform:

• A ghcr.io/auroralibros/aurora-api:2.0.0 image of 104 MB, multi-stage from node:22-alpine pinned by digest, multi-architecture (amd64 and arm64), signed with Cosign, with an SBOM and a provenance attestation.
• Unprivileged execution: read_only, cap_drop: [ALL], no-new-privileges, a non-root user.
• Configuration outside the image, validated at startup and failing in 0.4 seconds if something is missing.
• Graceful shutdown with no lost requests and three probes with separate semantics.
• A pipeline that on every git push tests against a real PostgreSQL 16 and Redis 7, builds in 41 seconds with a remote cache, scans with Trivy, signs and publishes.
• Deployment on Kubernetes with Kustomize, a StatefulSet with a PVC for the data, an Ingress with TLS, PgBouncer, an HPA from 3 to 12 replicas that took the p95 from 1,840 ms to 88 ms, a PodDisruptionBudget and a rehearsed rollback.
• Observability with Loki, Promtail, Grafana, Prometheus and cAdvisor, with alerts.
• And the onboarding: clone the repository and run one command.

From fifteen manual steps to one command. That is the work of 47 lessons.

Tick honestly. Anything you cannot explain to another person, you have not mastered yet.

If you hesitate on three or more rows, go back to those lessons and do the exercises. Reading them does not count.

Certifications that are worth something (in order of practical usefulness):

Reference documentation, in order of return on your time:

CNCF projects that deserve your attention, grouped by the problem they solve:

Do not learn them all: choose by the problem in front of you. One project understood in depth is worth more than ten known by name.

Habits that are worth more than any course: read the CHANGELOG files of the tools you use; when something fails, do not stop at fixing it, understand why it failed; read Dockerfiles from serious projects; and explain to a colleague what you have just learned, which is the definitive test of whether you understood it.

What really fixes knowledge in place is applying it to something you care about. In order of difficulty:

Project 1 — Containerize an application of your own. Take a real project of yours, with all its quirks. Write a multi-stage Dockerfile that comes in under 150 MB, move all the configuration out into environment variables, add the three probes and graceful shutdown, and set it up with Compose alongside its database. Goal: that somebody else can start it with one command.

Project 2 — A complete pipeline. On top of the above, build CI that runs tests with Testcontainers, builds multi-architecture with a remote cache, scans with Trivy and fails if there are critical findings, generates an SBOM, signs with Cosign and publishes to ghcr.io. Goal: that a git push produces a signed, verifiable image with nothing else to touch.

Project 3 — Deploy on a managed cluster. Take the application to a managed Kubernetes with Kustomize and two overlays, an Ingress with TLS, an HPA, a PodDisruptionBudget and observability. Run a load test, find the real bottleneck and rehearse a rollback. Goal: break it on purpose and recover it in under two minutes.

Project 4 — Contribute. Choose an official image or a CNCF project you use and open a real contribution: a documentation improvement, a smaller Dockerfile, a hadolint run that comes out clean, a missing test. Goal: go from consumer to participant, which is where you learn the most.

And one piece of advice about all four: finish them. One finished, deployed project teaches more than five half-done ones.

• Rewriting something because a new technology came out. No trend in this lesson justifies rewriting a platform that works. Changes are made because of problems, not because of headlines.
• Confusing "promising" with "ready". Wasm is technically sound and its ecosystem is young. Taking it to production today for a conventional API is trading solved problems for open ones.
• Putting a model's weights inside the image. It turns every deployment into twenty minutes. Weights are data, not code.
• Waiting until regulation forces you. Adding SBOM, signing and provenance to a pipeline that already exists costs an afternoon; doing it with a customer asking and a deadline overhead takes weeks.
• Trusting an internal platform without understanding what is underneath. The day the abstraction breaks, somebody will have to look at the Pods. Being able to be that somebody is your advantage.
• Studying tools instead of fundamentals. Tools expire; the layer model, immutability and kernel isolation do not.
• Tip: spend this quarter on the supply chain. It is the only row in the maturity table that already has a date attached.
• Tip: when you evaluate something new, write in three lines which problem of yours it solves. If you cannot write them, it is not for you yet.
• Tip: reread the Aurora Libros compose.yaml and Dockerfile in six months. You will see things you cannot see today, and that is the sign that you have grown.

Exercise 1 — Evaluate a trend with judgment. Choose one of the trends in this lesson (Wasm, minimal bases like Wolfi, deterministic images, internal platforms or AI workloads) and write a short decision report for Aurora Libros: what real problem it would solve, how mature it is, what would have to change in the current platform, what cost and what risk it would carry, and your recommendation with a concrete trigger that would change it. One page maximum.

Exercise 2 — Self-assessment and plan. Go through the table in §13 and mark each row as "I can explain it to another person", "I can do it with the documentation open" or "I have not mastered it". For every row in the third group, find the corresponding lesson, do its exercises and note what you were missing. Turn the result into a four-week plan with two competencies per week and a practical check for each one.

Exercise 3 — The final project. Carry out Project 1 from §15 on a real application of your own. Deliverables: the multi-stage Dockerfile with its final size, the compose.yaml with the database, the environment-variable configuration documented, the three probes, graceful shutdown, and a README with the startup instructions. Success criterion: that somebody outside the project gets it up following only the README, without asking you anything.

Solution 1. An example with minimal bases like Wolfi/Chainguard, which has the best benefit/cost ratio for Aurora Libros:

Review trigger: "if in two months we are still republishing aurora-api more than once a month purely because of base image CVEs, we migrate; if not, the current base pinned by digest is enough". Notice the shape of the trigger: it is measurable and it has a deadline, just like the one in the solution to exercise 3 of 07-02. A technology recommendation without a verifiable condition is an opinion.

Solution 2. The plan comes out of the diagnosis, so there is no single answer, but there is a structure that works:

Three rules make the plan work: the check is always doing, never reading; you mark "I have mastered it" only when you can explain it to another person without looking anything up; and if a week falls through, the plan slips, the check is not skipped. The classic mistake is substituting rereading for practice: rereading a security lesson does not teach you to diagnose why readOnlyRootFilesystem fails, and triggering the failure does.

Solution 3. A self-assessment rubric for the deliverable. If something is missing, go back to the lesson indicated:

The last row is the only one you cannot score yourself: genuinely ask somebody and time them. If they have to ask you something, either documentation or automation is missing, and in both cases the project is not finished yet. That criterion — that somebody else can get it up alone — is the most honest measure of everything you have learned, and it is exactly the problem Aurora Libros had in 01-07 with its fifteen manual steps.

You have reached the end of 47 lessons. You started without knowing what an image was and you finish with a complete platform built with your own hands: Aurora Libros, which went from fifteen manual onboarding steps and an "it works on my machine" to a 104 MB multi-architecture image, signed, with an SBOM and provenance, running unprivileged, deployed by a pipeline that builds in 41 seconds, scaling itself from 3 to 12 replicas on a cluster, observed, with a rehearsed rollback and a one-command onboarding.

Along the way you have learned the two things that matter. The first is the fundamentals that do not expire: the layered image addressed by digest, the immutability from which rollback and provenance come, the per-environment configuration that lets the same image live in development and in production, the separation between building and running, and the process isolated by the kernel's namespaces and cgroups. Those five points have been stable for a decade and they are the reason you can move between Docker, Podman, containerd or whatever comes next by reading the documentation over one afternoon.

The second is judgment, which is what separates whoever runs commands from whoever makes decisions. You know when Compose is the professional answer and when Kubernetes is, and you know how to phrase the question that decides it: if the cluster breaks on a Saturday at three in the morning, who fixes it? You know the host is an attack surface and that somebody with a first and last name has to answer for it. You know how to evaluate a tool by its maintenance, its license, its provenance and its exit cost instead of by its popularity. You know how to tell what is in production from what is a bet. And you know that decisions get written down, with their date and their review trigger, so that a year from now somebody — perhaps you — understands why they were made.

You also take away something less visible and more valuable: the habit of not stopping at the surface. You opened runc's config.json, looked at the seven namespaces, read the mediaType of your own multi-architecture index and confirmed that your image was not "a Docker image" but an OCI artifact. That curiosity is what makes new technologies feel familiar instead of threatening, because they are almost always different combinations of the same pieces.

Docker will change. Kubernetes will change. Runtimes, formats and platforms that do not exist today will appear, and some of the names in this course will sound old in five years, just as Docker Machine sounds old today. That is fine: containers are an open standard, and you have not learned a product, you have learned the model underneath. With that, whatever comes next is an afternoon's reading.

Now take something of your own — a real application, with all its quirks, the one you have been meaning to get running for a while — and containerize it. Write it a multi-stage Dockerfile, take its configuration out, give it the three probes, build it a pipeline and deploy it. Break it on purpose and fix it. That is the last exercise of the course, and the only one with no written solution, because the solution is the one you write.

Thank you for making it this far. May it run well in production.