Cerramos la Parte IV con EKS (Elastic Kubernetes Service), la alternativa más potente —y más compleja— para ejecutar contenedores en AWS. Es importante entender qué es Kubernetes, qué aporta EKS y, sobre todo, cuándo merece la pena frente a la sencillez de ECS. Spoiler: no siempre.

Kubernetes (a menudo abreviado K8s) es el orquestador de contenedores más popular del mundo. Hace lo mismo que ECS (ejecutar, escalar, reparar y coordinar contenedores), pero con dos diferencias importantes:

• Es open source (código abierto) y estándar de la industria: lo usan empresas de todos los tamaños y funciona en cualquier nube (AWS, Azure, Google...) o incluso en tus propios servidores.
• Es muchísimo más potente y flexible... pero también mucho más complejo.

Analogía: si ECS es un coche automático (fácil de conducir, AWS gestiona casi todo por ti), Kubernetes es un coche de Fórmula 1: increíblemente capaz y configurable, pero requiere un piloto experto y mucho mantenimiento. Para ir al supermercado, el automático es más que suficiente.

Gestionar Kubernetes por tu cuenta es muy difícil: hay que instalar y mantener su «cerebro» (el plano de control), que es complejo y delicado. EKS (Elastic Kubernetes Service) resuelve eso: es Kubernetes gestionado por AWS. AWS se encarga de la parte más difícil (el plano de control), y tú usas Kubernetes sin tener que mantener su núcleo.

Aun así —y esto es clave— EKS sigue siendo más complejo que ECS. AWS te quita una parte del trabajo, pero Kubernetes en sí tiene una curva de aprendizaje pronunciada: conceptos propios (pods, deployments, services, ingress...), su propia forma de configurarse, su propio ecosistema de herramientas.

EKS tiene sentido en estos casos:

• Ya usas Kubernetes o tu equipo tiene experiencia con él. Aprovechas ese conocimiento.
• Necesitas multi-nube o evitar el «vendor lock-in»: quieres que tu aplicación pueda funcionar en AWS, en otra nube o en tus servidores sin reescribirla. Kubernetes es el estándar común.
• Necesidades muy complejas: configuraciones avanzadas de red, despliegues sofisticados, o quieres usar el enorme ecosistema de herramientas de Kubernetes (Helm, operators, service meshes...).
• Organización grande con muchos equipos y aplicaciones, donde la potencia de Kubernetes compensa su complejidad.

Y aquí está el consejo más valioso del subcapítulo. Mucha gente elige Kubernetes por moda, sin necesitarlo, y acaba pagando una complejidad enorme para nada. No elijas EKS si:

• Estás empezando con contenedores. Empieza por ECS/Fargate; es mucho más sencillo.
• Tu equipo no conoce Kubernetes. La curva de aprendizaje y el mantenimiento te robarán tiempo que deberías dedicar a tu producto.
• Tus necesidades son normales: ejecutar unas cuantas aplicaciones, escalarlas, repartir tráfico. ECS hace esto perfectamente y con mucho menos esfuerzo.
• Quieres simplicidad operativa. Fargate (con ECS) te da contenedores sin gestionar casi nada.

El error clásico: un equipo pequeño monta un cluster de Kubernetes complejo para ejecutar tres microservicios, y acaba dedicando más tiempo a mantener Kubernetes que a desarrollar su producto. Con ECS + Fargate habrían tenido lo mismo funcionando en una fracción del tiempo. Elige la herramienta por necesidad real, no por moda.

Empieza siempre por lo simple (ECS/Fargate). Pásate a EKS solo cuando tengas una razón concreta y justificada para necesitar Kubernetes. La complejidad debe ganarse su sitio, no adoptarse por defecto.

• Kubernetes (K8s) es el orquestador de contenedores estándar de la industria: potentísimo, open source y portable a cualquier nube, pero muy complejo. Como un Fórmula 1 frente al coche automático que es ECS.
• EKS (Elastic Kubernetes Service) es Kubernetes gestionado por AWS: AWS mantiene el «cerebro», pero sigue siendo más complejo que ECS.
• Elige EKS si: ya usas Kubernetes, necesitas multi-nube/evitar lock-in, tienes necesidades muy complejas o una organización grande con expertise.
• No elijas EKS si estás empezando, tu equipo no conoce Kubernetes, o tus necesidades son normales: ECS + Fargate hace lo mismo con mucho menos esfuerzo.
• Regla de oro: empieza por lo simple (ECS/Fargate) y pásate a EKS solo con una razón justificada. Elige por necesidad, no por moda.

¡Has terminado el Capítulo 17 y la Parte IV! Ya dominas las arquitecturas intermedias de AWS: balanceo y autoescalado, serverless, mensajería, entrega de contenido y contenedores. En la Parte V subiremos el nivel de Terraform: empezaremos por los módulos, la clave para reutilizar y organizar tu infraestructura como un profesional.