Última lección. Toca levantar la vista del proyecto y mirar hacia delante: qué tendencias del ecosistema tienen sustancia y cuáles son todavía apuesta, qué no va a cambiar —y por eso es donde conviene invertir el aprendizaje— y qué has llegado a construir en estas 47 lecciones. Al final encontrarás una autoevaluación honesta, recomendaciones para seguir y cuatro proyectos concretos para consolidar lo aprendido.

1. Dónde está Docker hoy
2. Cómo leer una tendencia
3. Rootless y aislamiento reforzado como norma
4. WebAssembly en el ecosistema de contenedores
5. La cadena de suministro como requisito regulatorio
6. Builds más rápidos y reproducibles
7. Contenedores en el borde y en dispositivos
8. Cargas de trabajo de IA
9. Plataformas internas de desarrollo
10. Resumen de madurez
11. Lo que no va a cambiar
12. El camino de Aurora Libros
13. Autoevaluación
14. Cómo seguir aprendiendo
15. Cuatro proyectos para consolidar

En 2013 Docker era los contenedores. En 2026 es una implementación excelente de un estándar abierto que él mismo creó y donó. Esa frase suena a declive y no lo es: es la definición de éxito de una tecnología de infraestructura.

Lo que sigue siendo suyo y sigue mandando: la experiencia de desarrollo. Docker Desktop, docker compose, BuildKit y Buildx, Scout y la documentación son el camino más corto entre una idea y un contenedor funcionando, y por eso siguen siendo el punto de entrada de casi todo el mundo. La estrategia de la empresa se movió del centro de datos —donde ganó Kubernetes— al portátil del desarrollador y a la cadena de suministro, y ahí es fuerte.

Que el estándar sea abierto es la mejor noticia para ti: lo que has aprendido no caduca con un producto.

Antes de la lista, un filtro. Para cada tendencia, tres preguntas: ¿qué problema real resuelve?, ¿qué madurez tiene de verdad?, y ¿me afecta a mí ahora o dentro de cinco años? Se lee así:

Voy a etiquetar cada tendencia con honestidad, incluidas las que están de moda.

Madurez: en producción. El modo rootless de Docker (05-03), el de Podman por defecto (07-05) y los SecurityContext obligatorios en Kubernetes van todos en la misma dirección: root dentro del contenedor deja de ser aceptable por defecto.

Lo que viene: políticas de admisión que rechazan el despliegue si el manifiesto no cumple —Kyverno, OPA Gatekeeper, Pod Security Admission—, y aislamiento reforzado (gVisor, Kata) donde se ejecuta código de terceros. Aurora Libros ya cumple: corre sin privilegios, con read_only, cap_drop: [ALL] y no-new-privileges. Eso que hiciste en el módulo 5 por buenas prácticas será en pocos años un requisito de admisión.

Madurez: prometedor, con nichos ya en producción. Wasm es un formato de bytecode portable con un modelo de seguridad de caja de arena. Con WASI puede hacer entrada/salida, y con runwasi se ejecuta como un contenedor más desde containerd.

Dónde encaja hoy: funciones sin servidor con arranques en frío inaceptables, plugins ejecutando código de clientes, extensiones de proxies y mallas, y dispositivos con recursos escasos.

Qué no sustituye, y conviene decirlo claro: PostgreSQL no se va a ejecutar en Wasm, ni tu API con node_modules completo y acceso libre al sistema de ficheros. Wasm no viene a reemplazar contenedores; viene a ocupar el hueco donde un contenedor es demasiado pesado. Para aurora-api hoy, la respuesta es no. Merece la pena seguirlo, no reescribir nada por él.

Madurez: en producción, y avanzando hacia obligatorio. Es la tendencia con más impacto práctico a corto plazo, y ya la has implementado sin saber que ibas por delante.

El empuje ya no es solo técnico. En Estados Unidos hay requisitos de SBOM para proveedores de la administración desde 2021, y en Europa el Cyber Resilience Act impone obligaciones de seguridad y de transparencia sobre componentes a los productos con elementos digitales, con plazos que se cierran en la segunda mitad de esta década. Si tu software se vende a empresas europeas, esto va a llegar a tus contratos en forma de cuestionario.

Advertencia importante: el alcance concreto, los plazos y qué productos quedan cubiertos son cuestiones jurídicas que cambian, y esto no es asesoramiento legal. Si tu producto puede estar afectado, consúltalo con el departamento legal o de cumplimiento de tu organización y no lo deduzcas de un curso técnico. Lo que sí te puedo decir es lo práctico: la parte técnica ya sabes hacerla, y llegar con SBOM, firma y procedencia ya montados convierte una auditoría en un trámite.

Madurez: en producción. El build dejó de ser «esperar» para convertirse en un problema de ingeniería, y BuildKit (05-05) es el motor de casi todo lo que viene.

Dos merecen atención. Las imágenes deterministas llevan la reproducibilidad al extremo: hoy tu build es reproducible en contenido pero los timestamps hacen que el digest varíe; con marcas de tiempo fijadas, dos builds del mismo commit producen el mismo digest, y eso hace la procedencia verificable por terceros sin confiar en nadie. Y las bases mínimas tipo Wolfi o Chainguard: distribuciones diseñadas para contenedores, con parches muy rápidos y objetivo de cero CVE conocidos, que resuelven el goteo de vulnerabilidades heredadas de la imagen base. Es el sucesor natural de tu node:22-alpine fijado por digest.

Madurez: en producción en su nicho. Llevar contenedores a fábricas, tiendas, vehículos o antenas, donde no hay centro de datos ni administrador.

Si Aurora Libros abriera veinte librerías físicas con un terminal de consulta del catálogo en cada una, este sería su terreno: la misma imagen multiarquitectura, un k3s por tienda o simplemente Compose, y despliegue por GitOps. Ninguna pieza nueva que aprender.

Lo interesante del borde es que invierte las prioridades que has manejado todo el curso. En el centro de datos, el ancho de banda es barato y una imagen de 300 MB no molesta a nadie; en una tienda con una conexión compartida, cada megabyte de la imagen se paga en minutos de actualización multiplicados por veinte sedes. Ahí el trabajo de 05-04 —bajar de 142 a 102 MB— deja de ser una elegancia y se convierte en la diferencia entre actualizar la flota en una noche o en un fin de semana.

Madurez: en producción, con problemas sin resolver. Es hoy el mayor motor de cambio en el ecosistema, y donde más duelen las limitaciones del modelo actual.

La regla de oro que emerge, y que es puro sentido común de contenedores: los pesos del modelo no van dentro de la imagen. Una imagen de 15 GB que hay que reconstruir y redistribuir cada vez que cambia una línea de Python es un despliegue de veinte minutos. Los pesos son datos: van en un volumen, en un almacén de objetos o en un artefacto OCI aparte. Es exactamente la separación entre imagen y estado que aprendiste en 03-06, aplicada a un problema nuevo.

Y una consecuencia que ya te afecta: los tiempos de arranque y el tamaño vuelven a importar mucho, lo que empuja todo el ecosistema hacia imágenes más pequeñas y arranques más rápidos. Nadie va a echar de menos ese empujón.

Madurez: adoptable, con mucha moda alrededor. La constatación de la que nacen: Kubernetes es demasiado para que cada desarrollador lo maneje a diario. La respuesta es una capa por encima —Backstage, Crossplane, Score, Argo CD y un catálogo de plantillas— que ofrece una interfaz sencilla y esconde el YAML.

La regla que separa el éxito del fracaso: una plataforma interna funciona cuando abstrae sin ocultar. El día que algo falle, alguien tendrá que mirar los Pods, los eventos y los logs, y ahí no hay interfaz que valga. Por eso lo que has aprendido en este curso no lo hace obsoleto una plataforma interna: lo hace más valioso, porque tú eres quien puede bajar cuando la abstracción se rompe.

Si tuvieras que dedicar tiempo este trimestre a una sola cosa de esta tabla, sería la segunda fila. Es la que ya tiene fecha.

Las tendencias son entretenidas; los fundamentos son rentables. Estos cinco llevan una década estables y seguirán ahí cuando las modas de esta lección hayan pasado:

Ahí es donde conviene invertir el aprendizaje. Quien entiende de verdad estos cinco puntos se mueve entre Docker, Podman, containerd, Kubernetes o lo que venga en 2030 leyendo la documentación una tarde. Quien solo memorizó comandos, vuelve a empezar cada vez.

Hay una prueba sencilla para saber en qué grupo estás. Piensa en estas cuatro preguntas y respóndelas mentalmente antes de seguir:

1. ¿Por qué cambiar una línea de src/index.js no invalida la capa de npm ci?
2. ¿Por qué un contenedor sin estado puede reemplazarse y uno con estado no?
3. ¿Por qué la misma imagen sirve para desarrollo y para producción?
4. ¿Por qué localhost dentro del contenedor no es tu máquina?

Si las cuatro tienen respuesta inmediata, no son comandos memorizados: es el modelo. Y el modelo es lo que se transfiere a cualquier herramienta futura.

Aurora Libros empezó en 01-07 con quince pasos manuales de onboarding: instalar Node, instalar PostgreSQL de la versión correcta, instalar Redis, crear la base, cargar el catálogo, configurar variables, y rezar. Dos días para que alguien nuevo pudiera arrancar el proyecto, y un «en mi máquina funciona» garantizado.

Hoy Aurora Libros es una plataforma real:

• Una imagen ghcr.io/auroralibros/aurora-api:2.0.0 de 104 MB, multietapa desde node:22-alpine fijado por digest, multiarquitectura (amd64 y arm64), firmada con Cosign, con SBOM y attestation de procedencia.
• Ejecución sin privilegios: read_only, cap_drop: [ALL], no-new-privileges, usuario sin root.
• Configuración fuera de la imagen, validada al arrancar y fallando en 0,4 segundos si falta algo.
• Apagado ordenado sin perder peticiones y tres sondas con semánticas separadas.
• Un pipeline que en cada git push prueba contra PostgreSQL 16 y Redis 7 reales, construye en 41 segundos con caché remota, escanea con Trivy, firma y publica.
• Despliegue en Kubernetes con Kustomize, StatefulSet con PVC para los datos, Ingress con TLS, PgBouncer, HPA de 3 a 12 réplicas que llevó el p95 de 1 840 ms a 88 ms, PodDisruptionBudget y rollback ensayado.
• Observabilidad con Loki, Promtail, Grafana, Prometheus y cAdvisor, con alertas.
• Y el onboarding: clonar el repositorio y ejecutar un comando.

De quince pasos manuales a un comando. Ese es el trabajo de 47 lecciones.

Marca con honestidad. Lo que no puedas explicar a otra persona, no lo dominas todavía.

Si dudas en tres o más filas, vuelve a esas lecciones y ejecuta los ejercicios. Leerlos no cuenta.

Certificaciones que valen algo (por orden de utilidad práctica):

Documentación de referencia, por orden de rentabilidad:

Proyectos de la CNCF que merecen tu atención, agrupados por el problema que resuelven:

No los aprendas todos: elige por el problema que tengas delante. Un proyecto entendido a fondo vale más que diez conocidos de oídas.

Hábitos que valen más que cualquier curso: lee los CHANGELOG de las herramientas que usas; cuando algo falle, no pares al arreglarlo, entiende por qué falló; lee Dockerfiles de proyectos serios; y explica a un compañero lo que acabas de aprender, que es la prueba definitiva de si lo entendiste.

Lo que de verdad fija el conocimiento es aplicarlo a algo que te importe. Por orden de dificultad:

Proyecto 1 — Contenedoriza una aplicación tuya. Coge un proyecto propio, real, con sus manías. Escribe un Dockerfile multietapa que baje de 150 MB, saca toda la configuración a variables de entorno, añade las tres sondas y el apagado ordenado, y móntalo con Compose junto a su base de datos. Objetivo: que otra persona lo arranque con un comando.

Proyecto 2 — Un pipeline completo. Sobre lo anterior, monta CI que ejecute pruebas con Testcontainers, construya multiarquitectura con caché remota, escanee con Trivy y falle si hay críticas, genere SBOM, firme con Cosign y publique en ghcr.io. Objetivo: que un git push produzca una imagen firmada y verificable sin tocar nada.

Proyecto 3 — Despliega en un clúster gestionado. Lleva la aplicación a un Kubernetes gestionado con Kustomize y dos overlays, Ingress con TLS, HPA, PodDisruptionBudget y observabilidad. Haz una prueba de carga, encuentra el cuello de botella real y ensaya un rollback. Objetivo: romperlo a propósito y recuperarlo en menos de dos minutos.

Proyecto 4 — Contribuye. Elige una imagen oficial o un proyecto de la CNCF que uses y abre una contribución real: una mejora de documentación, un Dockerfile más pequeño, un hadolint que pase limpio, un test que falte. Objetivo: pasar de consumidor a participante, que es donde más se aprende.

Y un consejo sobre los cuatro: termínalos. Un proyecto acabado y desplegado enseña más que cinco a medias.

• Reescribir algo porque salió una tecnología nueva. Ninguna tendencia de esta lección justifica reescribir una plataforma que funciona. Los cambios se hacen por problemas, no por titulares.
• Confundir «prometedor» con «listo». Wasm es técnicamente sólido y su ecosistema es joven. Llevarlo a producción hoy para una API convencional es cambiar problemas resueltos por problemas abiertos.
• Meter los pesos de un modelo en la imagen. Convierte cada despliegue en veinte minutos. Los pesos son datos, no código.
• Esperar a que la normativa obligue. Añadir SBOM, firma y procedencia a un pipeline que ya existe cuesta una tarde; hacerlo con un cliente preguntando y un plazo encima, semanas.
• Confiar en una plataforma interna sin entender lo que hay debajo. El día que la abstracción se rompa, alguien tendrá que mirar los Pods. Que ese alguien sepas ser tú es tu ventaja.
• Estudiar herramientas en vez de fundamentos. Las herramientas caducan; el modelo de capas, la inmutabilidad y el aislamiento por kernel, no.
• Consejo: dedica este trimestre a la cadena de suministro. Es la única fila de la tabla de madurez que ya tiene fecha.
• Consejo: cuando evalúes algo nuevo, escribe en tres líneas qué problema tuyo resuelve. Si no sabes escribirlas, no es para ti todavía.
• Consejo: relee el compose.yaml y el Dockerfile de Aurora Libros dentro de seis meses. Verás cosas que hoy no ves, y esa es la señal de que has crecido.

Ejercicio 1 — Evalúa una tendencia con criterio. Elige una de las tendencias de esta lección (Wasm, bases mínimas tipo Wolfi, imágenes deterministas, plataformas internas o cargas de IA) y escribe un informe breve de decisión para Aurora Libros: qué problema real resolvería, qué madurez tiene, qué habría que cambiar en la plataforma actual, qué coste y qué riesgo tendría, y tu recomendación con un disparador concreto que la haría cambiar. Máximo una página.

Ejercicio 2 — Autoevaluación y plan. Recorre la tabla de §13 y marca cada fila como «lo explico a otra persona», «lo hago mirando la documentación» o «no lo domino». Para cada fila del tercer grupo, localiza la lección correspondiente, ejecuta sus ejercicios y anota qué te faltaba. Convierte el resultado en un plan de cuatro semanas con dos competencias por semana y una comprobación práctica de cada una.

Ejercicio 3 — El proyecto final. Ejecuta el Proyecto 1 de §15 sobre una aplicación tuya de verdad. Entregables: el Dockerfile multietapa con su tamaño final, el compose.yaml con la base de datos, la configuración por variables de entorno documentada, las tres sondas, el apagado ordenado y un README con las instrucciones de arranque. Criterio de éxito: que una persona ajena al proyecto lo levante siguiendo solo el README, sin preguntarte nada.

Solución 1. Ejemplo con bases mínimas tipo Wolfi/Chainguard, que es la de mejor relación beneficio/coste para Aurora Libros:

Disparador de revisión: «si en dos meses seguimos republicando aurora-api más de una vez al mes solo por CVE de la imagen base, migramos; si no, la base actual fijada por digest es suficiente». Fíjate en la forma del disparador: es medible y tiene plazo, igual que el de la solución del ejercicio 3 de 07-02. Una recomendación tecnológica sin condición verificable es una opinión.

Solución 2. El plan sale del diagnóstico, así que no hay una respuesta única, pero sí una estructura que funciona:

Tres reglas que hacen que el plan funcione: la comprobación siempre es hacer, nunca leer; se marca «lo domino» solo cuando puedes explicárselo a otra persona sin mirar; y si una semana se cae, se retrasa el plan, no se salta la comprobación. El error clásico es sustituir la práctica por la relectura: releer una lección de seguridad no te enseña a diagnosticar por qué falla readOnlyRootFilesystem, y provocar el fallo, sí.

Solución 3. Rúbrica de autoevaluación del entregable. Si algo no está, vuelve a la lección indicada:

La última fila es la única que no puedes puntuarte tú: pídeselo de verdad a alguien y cronométralo. Si tiene que preguntarte algo, falta documentación o falta automatización, y en ambos casos el proyecto aún no está terminado. Ese criterio —que otro lo levante solo— es la medida más honesta de todo lo que has aprendido, y es exactamente el problema que Aurora Libros tenía en 01-07 con sus quince pasos manuales.

Has llegado al final de 47 lecciones. Empezaste sin saber qué era una imagen y terminas con una plataforma completa construida con tus manos: Aurora Libros, que pasó de quince pasos manuales de onboarding y un «en mi máquina funciona» a una imagen de 104 MB multiarquitectura, firmada, con SBOM y procedencia, ejecutándose sin privilegios, desplegada por un pipeline que construye en 41 segundos, escalando sola de 3 a 12 réplicas en un clúster, observada, con rollback ensayado y con un onboarding de un solo comando.

Por el camino has aprendido las dos cosas que importan. La primera son los fundamentos que no caducan: la imagen en capas direccionada por digest, la inmutabilidad de la que salen el rollback y la procedencia, la configuración por entorno que permite que la misma imagen viva en desarrollo y en producción, la separación entre construir y ejecutar, y el proceso aislado por namespaces y cgroups del kernel. Esos cinco puntos llevan una década estables y son la razón de que puedas moverte entre Docker, Podman, containerd o lo que venga leyendo la documentación una tarde.

La segunda es el criterio, que es lo que separa a quien ejecuta comandos de quien toma decisiones. Sabes cuándo Compose es la respuesta profesional y cuándo lo es Kubernetes, y sabes formular la pregunta que lo decide: si el clúster se rompe un sábado a las tres de la mañana, ¿quién lo arregla? Sabes que el host es superficie de ataque y que alguien con nombre y apellidos tiene que responder por él. Sabes evaluar una herramienta por su mantenimiento, su licencia, su procedencia y su coste de salida en lugar de por su popularidad. Sabes distinguir lo que está en producción de lo que es apuesta. Y sabes que las decisiones se escriben, con su fecha y su disparador de revisión, para que dentro de un año alguien —quizá tú— entienda por qué se tomaron.

También te llevas algo menos visible y más valioso: la costumbre de no quedarte en la superficie. Abriste el config.json de runc, miraste los siete namespaces, leíste el mediaType de tu propio índice multiarquitectura y comprobaste que tu imagen no era «de Docker» sino un artefacto OCI. Esa curiosidad es lo que hace que las tecnologías nuevas te resulten familiares en lugar de amenazantes, porque casi siempre son combinaciones distintas de las mismas piezas.

Docker cambiará. Kubernetes cambiará. Aparecerán runtimes, formatos y plataformas que hoy no existen, y algunos de los nombres de este curso sonarán antiguos dentro de cinco años, igual que hoy suena Docker Machine. No pasa nada: los contenedores son un estándar abierto, y tú no has aprendido un producto, has aprendido el modelo que hay debajo. Con eso, lo que venga se lee en una tarde.

Ahora coge algo tuyo —una aplicación real, con sus manías, esa que llevas tiempo queriendo poner en marcha— y contenedorízala. Escríbele el Dockerfile multietapa, sácale la configuración, ponle las tres sondas, móntale el pipeline y despliégala. Rómpela a propósito y arréglala. Ese es el último ejercicio del curso y el único que no tiene solución escrita, porque la solución la escribes tú.

Gracias por llegar hasta aquí. Que te funcione en producción.