Módulo 1: Why Kubernetes And The Continuity Challenge
2. Por qué Kubernetes cuando ECS ya alcanzaba
Descripción
aws-serverless-and-containers-guide te dejó con un criterio instalado: ECS/Fargate es "el orquestador de contenedores más simple que ofrece AWS" — sin control plane que administrar, sin kubectl, sin manifiestos YAML de Kubernetes. Y funcionaba: status-api-service con desiredCount: 2, en un awsvpc, detrás de un security group angosto, es un diseño perfectamente razonable para un servicio de solo lectura. Entonces, ¿por qué esta guía entera? La respuesta no es técnica en el sentido de "ECS no puede hacer esto" — en muchos casos, sí puede. La respuesta es de mercado: el trabajo real de plataforma que las empresas contratan en 2026 asume Kubernetes como el terreno común, y esa es una decisión que no depende de qué orquestador sea "mejor" en abstracto.
Conexión con el módulo
Esta lección instala el criterio antes de tocar un solo comando. La lección 3 retoma este mismo criterio para explicar por qué esta guía no reconstruye nada desde cero — solo le da a andes-cargo-status-api el orquestador que el criterio de esta lección justifica.
La evidencia de mercado, sin editar
src/paths/aws-cloud-ecosystem/VALIDACION.md (auditoría de mercado, 44 agentes, 19 de julio de 2026, confianza "alta") es inusualmente tajante en un punto específico — tan tajante que revierte una decisión que el propio STRATEGY.md de este ecosistema había tomado antes de que la evidencia llegara:
"Es el hueco más grave del ecosistema, y no es un olvido: el STRATEGY lo excluye explícitamente ('Kubernetes a fondo → se cubre EKS como servicio gestionado; K8s como plataforma es otro alcance'). Esa frontera está tomada al revés de lo que dice el mercado."
El hallazgo, con cifras y citas textuales de ofertas reales:
"Ninguna de las 10 guías cubre ingress, cert-manager, external-dns, CNI, autoscaling, ni GitOps. ~11 de 13 ofertas (~85%) piden Kubernetes en producción: CookUnity 'Kubernetes cluster deployment, management, and troubleshooting (EKS focus)' + 'Establish GitOps workflows through ArgoCD'; VirtualVocations 'EKS or ECS clusters at scale'; Apptiva (España) 'Helm template expertise for OpenShift 4.X'; MediaStream 'cluster management (cloud AND on-premise)'."
Fíjate en algo importante: ninguna de esas cuatro ofertas dice "ECS". Dos mencionan Kubernetes/EKS por nombre explícito, una pide Helm sobre OpenShift (una distribución de Kubernetes), y una pide gestión de clústeres tanto en la nube como on-premise — algo que solo Kubernetes ofrece, porque ECS es un servicio propietario de AWS, sin equivalente fuera de esa nube. Esa última oferta, por sí sola, es el argumento de portabilidad de esta lección hecho requisito de contratación real.
Qué gana Kubernetes sobre ECS
1. Portabilidad — el mismo YAML corre en cualquier nube, o en ningún lado en particular
Un Deployment de Kubernetes es un objeto que Kubernetes entiende — no AWS, no Google Cloud, no una VM en tu oficina. El mismo manifiesto que corre en kind, en tu laptop, corre —con ajustes de infraestructura alrededor, no de la definición del recurso— en EKS (AWS), en GKE (Google Cloud), en AKS (Azure), o en un clúster on-premise. Una task definition de ECS, en cambio, es un objeto que solo ECS entiende: el JSON completo (networkMode: awsvpc, requiresCompatibilities: [FARGATE]) no significa nada fuera de una cuenta de AWS. Esto no es un detalle académico — es exactamente lo que la oferta de MediaStream de la evidencia de arriba pide explícitamente: alguien capaz de operar "cloud AND on-premise", algo que ECS, por diseño, no puede ofrecer.
2. Un ecosistema de add-ons que el mercado da por sentado
Cuando una empresa dice "necesitamos GitOps con ArgoCD" o "necesitamos cert-manager para renovar certificados TLS automáticamente", está asumiendo Kubernetes como la base — esas herramientas son proyectos de Kubernetes, construidos sobre su modelo de API extensible (CustomResourceDefinition). ECS no tiene un ecosistema equivalente de terceros del mismo tamaño: es un servicio cerrado, mantenido únicamente por AWS, con la superficie de extensión que AWS decide exponer. El Módulo 5 de esta guía instala ArgoCD real; el Módulo 6 instala dos motores de admission control reales (Gatekeeper y Kyverno) — ninguno de los dos tiene equivalente directo en el mundo ECS.
3. GitOps nativo — el propio modelo de API de Kubernetes está diseñado para esto
Todo objeto de Kubernetes es, en el fondo, un documento declarativo (YAML/JSON) que describe un estado deseado, y un bucle de control interno (controller-manager) que reconcilia la realidad contra ese documento sin que nadie lo dispare a mano — vas a ver esto de cerca en el Módulo 2. Un operador como ArgoCD extiende exactamente ese mismo mecanismo: en vez de un pipeline de CI que ejecuta kubectl apply (GitOps push-based, lo que enseña cicd-and-gitops-on-aws-guide), un proceso dentro del propio clúster hace watch de un repositorio Git y converge el clúster hacia lo que ese repositorio declara (GitOps pull-based, el Módulo 5 de esta guía). ECS tiene un concepto de "estado deseado" (desiredCount), pero no un modelo de API extensible sobre el cual construir un operador de terceros que reaccione a cambios arbitrarios.
4. Primitivas más ricas para cargas de trabajo distintas
ECS tiene, en esencia, un solo concepto de carga de trabajo: la task, corriendo dentro de un service. Kubernetes distingue Deployment (servicios sin estado, como andes-cargo-status-api), StatefulSet (cargas con identidad y almacenamiento persistentes, como una base de datos), DaemonSet (un Pod por nodo, para agentes de infraestructura), y Job/CronJob (trabajo que corre hasta terminar, una vez o programado). Esta guía solo necesita Deployment para el caso de Andes Cargo — pero el vocabulario completo es, literalmente, lo que un rol de plataforma necesita dominar para operar cualquier sistema real, no solo uno de solo lectura.
Qué cuesta esa ganancia: Kubernetes no es batteries included
Aquí es donde esta lección se vuelve tan honesta como el resto del ecosistema. Un ingeniero con experiencia real, en un hilo de Hacker News sobre exactamente este tema, lo dice sin adornos:
"it's not at all batteries included... you're still going to be installing a bunch of additional controllers (ingress, cert-manager, external dns to start)" — mikeocool, Hacker News (discusión 48548137).
Esa cita no es una queja aislada — es una descripción precisa de lo que un clúster de Kubernetes recién creado no trae por defecto:
- Sin
Ingresscontroller.kind create clusterte da un clúster funcional, pero sin ninguna forma de recibir tráfico HTTP externo hasta que instalas uno tú mismo (ingress-nginx, en el Módulo 4 de esta guía — la misma fricción real que describe la cita). - Sin
cert-manager. Renovar certificados TLS automáticamente no es un comportamiento de fábrica — es un proyecto separado que alguien tiene que instalar y configurar. - Sin DNS externo. Que un nombre de dominio real apunte a tu
Ingressrequiere un controlador adicional (external-dns), no incluido. - Sin admission control de políticas. Nada te impide, de fábrica, desplegar un Pod sin límites de CPU/memoria, o con la etiqueta
:latest— necesitas instalar Gatekeeper o Kyverno tú mismo (Módulo 6 de esta guía). - Sin GitOps. ArgoCD no viene con el clúster — es, otra vez, algo que instalas.
ECS, en contraste, resuelve varias de estas piezas por diseño, dentro del ecosistema de AWS: el balanceo de carga se integra con el ALB nativo de AWS sin ningún controlador adicional que instalar; los certificados se gestionan con ACM sin un proyecto de terceros. Esa es la ganancia real de ECS, y es exactamente lo que hace que la elección no sea "Kubernetes es objetivamente mejor" — es "el mercado, mayoritariamente, pide instalar y operar esas piezas tú mismo, con Kubernetes como la base común".
La tabla de la decisión, sin adornos
| Eje | ECS/Fargate | Kubernetes (kind / EKS) |
|---|---|---|
| Portabilidad fuera de AWS | Ninguna — objeto propietario de AWS | Total — el mismo YAML, ajustando infraestructura alrededor |
| Curva de aprendizaje inicial | Menor — modelo de tres conceptos (cluster, task, service) | Mayor — modelo de API extensible con docenas de tipos de objeto |
| Add-ons de terceros (GitOps, admission control, service mesh) | Prácticamente ninguno nativo | Ecosistema CNCF completo, la mayoría de proyectos maduros de infraestructura moderna |
| Piezas que hay que instalar y operar tú mismo | Pocas — AWS resuelve balanceo, certificados, DNS de forma integrada | Varias — ingress, cert-manager, external-dns, admission control, todo por separado |
Demanda en ofertas de plataforma/cloud 2026 (VALIDACION.md) | Minoritaria, no citada por nombre en la evidencia revisada | ~85% de las ofertas revisadas (~11 de 13) |
| Costo operativo de un clúster pequeño | Menor — sin plano de control que pagar por separado | Mayor en EKS real (el plano de control tiene costo propio) — Módulo 7 |
Ninguna fila de esta tabla dice "ECS es malo". Dice, con la misma honestidad que sostuvo todo el ecosistema hasta ahora, que Kubernetes gana en portabilidad y en el ecosistema que el mercado da por sentado, y pierde en simplicidad operativa — el mismo tipo de contrapartida que ya viste entre serverless y contenedores en la guía anterior, aplicada un nivel más arriba.
El director de orquesta, otra vez: por qué esta guía no dice "ECS perdió"
Retomando la analogía de la lección 1: ECS es un director capaz de dirigir un cuarteto — perfecto para una sala pequeña, con un repertorio limitado, y sin necesidad de contratar más personal que el director mismo. Kubernetes es un director de orquesta sinfónica — capaz de coordinar secciones enteras de instrumentos que otros compositores (la comunidad de código abierto) siguen agregando, pero eso exige una sala más grande, más ensayo, y —siendo honestos— más gente detrás de escena (los add-ons que la cita de mikeocool describe). Ninguna sala necesita siempre la sinfónica completa. La pregunta que el mercado de contratación 2026 responde, con la evidencia de VALIDACION.md, no es "¿cuál orquesta suena mejor?" — es "¿qué tipo de director están contratando las salas de concierto ahora mismo?". Y la respuesta, con el 85% de las ofertas revisadas pidiendo Kubernetes, es clara.
Errores comunes
Concluir "entonces ECS no sirve para nada" (conceptual, el extremo opuesto igual de equivocado). Qué pasa: alguien, después de ver la evidencia de mercado a favor de Kubernetes, concluye que ECS fue una pérdida de tiempo en la guía anterior, o que ninguna empresa real lo usa. Por qué pasa: es fácil sobrecorregir cuando una cifra como "85%" aparece de forma tan tajante. Cómo detectarlo: si tu conclusión de esta lección es "nunca usaría ECS", sin matices. Cómo corregirlo: ECS sigue siendo, hoy, una elección perfectamente razonable para equipos pequeños, sin necesidad de portabilidad fuera de AWS, que prefieren menos piezas que operar — la tabla de esta lección lo deja explícito. La evidencia de mercado dice qué habilidad es más demandada para roles de plataforma, no que la alternativa sea inválida en cualquier contexto.
Pensar que "instalar Kubernetes" y "aprender Kubernetes" son lo mismo que "instalar y operar los add-ons" (de expectativa, el error que la cita de mikeocool previene). Qué pasa: alguien asume que, una vez que kind create cluster funciona (lección 5), el trabajo pesado de esta guía ya pasó. Por qué pasa: crear un clúster con kind toma menos de un minuto — se siente como "ya está". Cómo detectarlo: si esperas que el Módulo 4 (Ingress) o el Módulo 6 (admission control) sean pasos triviales, de una sola línea. Cómo corregirlo: la cita de esta lección es literal — esos módulos existen exactamente porque instalar y configurar cada pieza adicional (ingress-nginx, Gatekeeper, Kyverno, ArgoCD) es trabajo real, con su propia lección de "manos a la obra" cada vez.
Comparar el costo de EKS real contra kind sin aclarar la diferencia (de comunicación, relevante desde ya porque el Módulo 7 lo retoma). Qué pasa: alguien, al justificar por qué esta guía usa kind en vez de EKS desde el principio, dice simplemente "porque es gratis", sin mencionar que kind es Kubernetes real, no una versión reducida o falsa. Por qué pasa: "gratis" suena a "simulado" o "de juguete". Cómo detectarlo: si describes lo que vas a hacer en esta guía como "practicar con una versión simplificada de Kubernetes". Cómo corregirlo: kind corre el mismo binario kube-apiserver/kubelet/etcd que corre dentro de un nodo de EKS — empaquetado en contenedores Docker, sin ningún atajo pedagógico. Lo que cambia en EKS no es "Kubernetes de verdad" — es quién administra el plano de control y cómo se consigue el cómputo detrás, exactamente el tema del Módulo 7.
Ejercicios
Ejercicio 1 — Cita la evidencia sin verla. Sin volver a leer la sección "La evidencia de mercado", escribe de memoria: (a) el porcentaje aproximado de ofertas de plataforma que piden Kubernetes en producción, según VALIDACION.md; (b) el nombre de al menos una empresa citada; (c) la frase textual de mikeocool sobre "batteries included".
Ver solución
(a) ~85% (aproximadamente 11 de 13 ofertas revisadas). (b) CookUnity ("Kubernetes cluster deployment, management, and troubleshooting (EKS focus)" + "Establish GitOps workflows through ArgoCD"), o VirtualVocations ("EKS or ECS clusters at scale"), o Apptiva/MediaStream, cualquiera de las cuatro cuenta. (c) "it's not at all batteries included... you're still going to be installing a bunch of additional controllers (ingress, cert-manager, external dns to start)".
Ejercicio 2 — Aplica la tabla de decisión a un caso nuevo. Una empresa ficticia necesita desplegar un servicio interno que solo va a correr en AWS, sin ningún plan de multi-nube, con un equipo de dos personas que nunca operó Kubernetes. Usando solo la tabla de esta lección (no tu intuición), argumenta si ECS o Kubernetes es la elección más razonable, y por qué.
Ver solución
Con esa descripción específica —sin necesidad de portabilidad, equipo pequeño, sin experiencia previa—, la tabla apunta con fuerza hacia ECS: la fila de portabilidad no aporta valor (nunca van a salir de AWS), la fila de curva de aprendizaje pesa mucho con un equipo de dos personas sin experiencia, y la fila de "piezas que hay que instalar y operar tú mismo" sería una carga operativa real para un equipo tan pequeño. La única razón para elegir Kubernetes en este caso específico sería una apuesta a futuro (crecimiento del equipo, necesidad eventual de multi-nube) — no una necesidad actual. Este ejercicio existe para mostrar que el criterio de esta lección es una herramienta de decisión, no un veredicto absoluto a favor de Kubernetes en cualquier escenario.
Ejercicio 3 — Explica la contrapartida a un colega escéptico. Un colega dice: "si Kubernetes gana en el 85% de las ofertas, entonces es objetivamente mejor que ECS, punto". Corrígelo en dos o tres frases, sin negar la evidencia de mercado.
Ver solución
Una respuesta completa suena, más o menos, así: "La evidencia de mercado es real, pero '85% de las ofertas lo piden' no es lo mismo que 'es objetivamente mejor' — es 'es lo que las empresas de plataforma más contratan hoy', que es una pregunta distinta. Kubernetes gana en portabilidad y en el ecosistema de add-ons que el mercado da por sentado, pero eso viene con más piezas que instalar y operar tú mismo —ingress, cert-manager, admission control, todo por separado—, algo que ECS resuelve de forma más integrada dentro de AWS. La decisión correcta depende del contexto: para un equipo que nunca va a salir de AWS y prioriza simplicidad, ECS sigue siendo razonable."
Resumen y siguiente paso
En esta lección instalaste el criterio central de toda la guía: Kubernetes gana sobre ECS en portabilidad (el mismo YAML corre en cualquier nube), en el ecosistema de add-ons que el mercado de contratación 2026 da por sentado (~85% de las ofertas de plataforma, según VALIDACION.md), en GitOps nativo (su propio modelo de API está diseñado para reconciliación declarativa), y en primitivas más ricas para cargas de trabajo distintas — pero esa ganancia cuesta más piezas que instalar y operar tú mismo, exactamente lo que describe la cita de mikeocool sobre "no ser batteries included". Ninguna de las dos opciones es objetivamente superior; son contrapartidas distintas para contextos distintos.
Antes de avanzar deberías poder: citar la cifra de mercado y al menos una oferta concreta de memoria; explicar, sin la tabla delante, al menos dos ejes donde Kubernetes gana y uno donde ECS gana; y decidir, para un escenario nuevo, cuál de los dos orquestadores tiene más sentido.
La lección 3 aplica este mismo criterio al caso concreto de Andes Cargo: por qué la imagen que aws-serverless-and-containers-guide construyó se recoge tal cual, sin inventar nada nuevo, y qué significa "darle, por primera vez, un orquestador real".
Recursos
src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA, auditoría de mercado, 19-jul-2026) — la fuente completa de la evidencia citada en esta lección.- Hacker News — discusión 48548137 — el hilo original donde mikeocool describe la experiencia real de "no batteries included".
- Kubernetes — Why Kubernetes? — la posición oficial del proyecto sobre portabilidad y el modelo declarativo.
- AWS — What is Amazon ECS? — referencia oficial del modelo que esta lección usa como punto de comparación.
aws-serverless-and-containers-guide(NIEVA), Módulo 7 — el modelo completo de ECS/Fargate que esta lección da por conocido.