EKS vs. ECS: diferencias inesperadas y consejos prácticos para elegir

No siempre es fácil decidir si EKS o ECS encaja mejor en un proyecto.

Si lo analizas característica por característica, es fácil declarar un ganador. La complicación llega cuando, para hacer una comparación válida, tienes que ver cada producto como un paquete de características. Por eso es más preciso pensar en cada uno como una mezcla de pros y contras que vienen juntos.

De ahí se desprenden dos consecuencias naturales:

1. Ninguna opción es la mejor por defecto. La mejor opción se determina según los requisitos y restricciones del proyecto y de la organización.

2. Para definir objetivamente cuál encaja mejor en un proyecto hace falta algo de pensamiento crítico y un razonamiento más complejo.

En este artículo encontrarás diferencias, implicaciones e insights pocas veces documentados, relevantes frente a las restricciones habituales a nivel de proyecto y de organización, junto con otros factores que vale la pena considerar al decidir.

Lo mejor es ver este contenido como un razonamiento guiado a base de consejos condicionales que, al cruzarlos con un proyecto concreto, se convierten rápidamente en orientación práctica para tomar una decisión bien fundamentada.

BLUF (la conclusión, de entrada)

Tabla de contenidos

Audiencia objetivo

Introducción

Sección 1: diferencias menores entre EKS y ECS

1. ECS tiene precios de Fargate bastante mejores (EKS Fargate sale caro).

2. La densidad de contenedores en EC2 de EKS es mucho mejor que la de ECS.

3. ECS ofrece opciones de service discovery más avanzadas.

4. EKS le saca una ligera ventaja a ECS en multicloud y desarrollo local, ya que está basado en Kubernetes.

5. ECS no cobra por los costos del control plane; EKS sí.

Sección 2: insights sobre diferencias potencialmente críticas

1. EKS escala los contenedores más rápido por defecto y soporta autoscaling avanzado cuando se usa el add-on keda.sh.

2. La IaC (Infrastructure as Code) de EKS es fundamentalmente superior a la de ECS: estandarizada, fácil de leer, desacoplada, declarativa y con soporte para metadatos con estado.

3. ECS no tiene soporte nativo para volúmenes.

4. La dificultad de EKS suele ser variable y paradójica:

"EKS tiende a ser difícil porque es demasiado fácil".

5. Las actualizaciones de ECS son extremadamente raras, lo cual es una gran ventaja en estabilidad y para evitar el trabajo tedioso ligado a las operaciones del cluster.

6. EKS tiene una sobrecarga de mantenimiento inevitable y un orden de magnitud más de partes móviles que ECS, que prácticamente no necesita mantenimiento.

Sección 3: reglas prácticas para elegir ECS, EKS o ninguno.

1. ECS puede ser la mejor opción en escenarios donde:

2. Justificar objetivamente a EKS como la mejor opción exige un análisis algo más profundo de los factores situacionales (esta sección también incluye buenos consejos sobre EKS Auto Mode).

3. Las aplicaciones con estado son un escenario lo bastante común como para justificar una discusión basada en reglas prácticas:

Conclusión

Este artículo es para cualquiera que quiera saber cómo tomar una decisión bien fundamentada al elegir entre EKS y ECS.

Si formas parte de la audiencia objetivo, vale la pena que dediques tiempo a leerlo, aunque sea relativamente largo, porque al terminar estarás bien posicionado para lograr el objetivo principal —tomar una decisión bien fundamentada— y los siguientes tres objetivos auxiliares:

1. Descubrir diferencias, pros y contras inesperados.

(Me concentraré en los que son difíciles de googlear y que muchas veces no están documentados.)

2. Aprender los metadatos detrás de la toma de decisiones.

(Como las implicaciones reales de cada elección y los insights sobre factores y restricciones críticas que conviene ponderar con fuerza al evaluar opciones. Sirven también como buenos candidatos para construir recomendaciones basadas en reglas prácticas.)

3. Comprender el razonamiento sobre el cual se sustentan las afirmaciones.

Si logras entender, compartir y parafrasear el razonamiento y la justificación que respaldan las afirmaciones, implicaciones o insights, podrás usar ese conocimiento para reforzar la confianza —a nivel personal, de equipo o de organización— en que la decisión es razonable y se basa en argumentos válidos.

El resto del artículo se divide en secciones que coinciden con la tabla de contenidos anterior. Cada una tiene una lista de afirmaciones acompañada de una mezcla de explicaciones aclaratorias, evidencia factual y evidencia anecdótica que ayudan a sostener su validez.

La primera sección es una lista numerada de diferencias específicas entre EKS y ECS que conviene conocer, aunque normalmente no son críticas.

La segunda sección reúne insights sobre diferencias a las que sí vale la pena prestar atención, porque pueden ser factores determinantes al tomar decisiones.

La tercera contiene reglas prácticas condicionales basadas en preocupaciones habituales a nivel de proyecto, equipo u organización. Cruzarlas con tu situación concreta te dará consejos accionables.

Tanto ECS como EKS pueden correr sobre Fargate o EC2. Aunque es posible, hay una tendencia clara: ECS suele ir con Fargate y EKS con instancias EC2.

Las dos primeras diferencias de esta sección señalan un pro de cada uno que explica por qué esa tendencia tiene sentido. Las tres siguientes apuntan ventajas menores acompañadas de las razones por las que son relativamente despreciables.

1. ECS tiene precios de Fargate bastante mejores (EKS Fargate sale caro).

Es una preocupación menor, porque al margen del precio, los usuarios de EKS suelen preferir EC2 por sus ventajas funcionales (EC2 admite caché de imágenes de contenedores y daemonsets, mientras que Fargate no).

• En teoría, según la documentación de Fargate de AWS, las instancias Fargate deberían ser ligeramente más caras que EC2 a cambio de comodidad y beneficios de seguridad, y ese trade-off busca reducir el costo total de propiedad.

En la práctica, esa lógica solo se cumple para ECS, porque ECS admite instancias Fargate basadas en AMD (es decir, Intel/x86_64), ARM, on-demand y Spot.

• EKS solo admite instancias Fargate on-demand basadas en AMD.

EKS no soporta "Fargate Spot instances" ni "Fargate basado en ARM".

• Esto implica que, al comparar precios para EKS, te toca enfrentar la opción más cara con la más barata Y, encima, lidiar con la lógica de redondeo del tamaño de instancia de Fargate sumada a sus costos extra.
• Como ejemplo concreto: imagina que un contenedor pasó por un análisis de right-sizing y se determinó que corre mejor con 1.8 CPU y 1.2 GB de RAM.

Si necesitas 2 CPU, Fargate redondea automáticamente a 4 GB de RAM y hay que aplicar el precio de Fargate on-demand basado en AMD. En us-east-1, el precio de Fargate es de USD 2.37/día. Ese mismo contenedor cabría en un nodo Spot t4g.small basado en ARM de EC2 EKS, que costaría USD 0.1512/día.

• O sea, ¡EKS sobre Fargate puede ser hasta 15 veces más caro que EKS sobre EC2! (Y vale la pena aclarar que esa cifra es sobre la región más barata; ¡en regiones más caras la brecha de 15x se amplía aún más!)

2. La densidad de contenedores en EC2 de EKS es mucho mejor que la de ECS.

Nota: si la mayoría de tus contenedores usan al menos 1 CPU y 1 GB de RAM, la diferencia de precio será mínima, porque un t3/t4g.small puede alojar 2 tareas de ECS de ese tamaño.

Si despliegas muchos microservicios con poco uso de CPU y RAM, esos contenedores pueden salir bastante más baratos de correr en EKS gracias a su mayor densidad de contenedores. (Nota: para organizaciones que despliegan microservicios a gran escala, esto puede ser un diferenciador significativo de ahorro; pero para la mayoría no creo que la brecha de costos sea tan determinante, así que la considero una diferencia menor a tener en cuenta.)

• Muchos usuarios de ECS tienden a usar instancias Fargate, que de todas formas solo permiten una tarea/pod por instancia. Lo que no es de conocimiento general es que ECS sobre EC2 rinde bastante peor que EKS sobre EC2.
• Un t4g.small puede correr 11 pods de EKS, o 2 tareas de ECS.

Un t4g.large puede correr 35 pods de EKS, o 2 tareas de ECS.

• El cálculo lo hice con:

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=t4g.*" \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table

• La salida del comando muestra que t4g.small admite 3 ENIs. ECS necesita 1 para la VM host y luego asigna 1 por tarea. Una buena fórmula abreviada es $MAX_ENI -1 = $MAX_TASKS_PER_EC2_INSTANCE. (3-1=2).
• Nota: ECS sí tiene una característica con un nombre poco afortunado llamada ENI trunking (también conocida como AWS VPC Trunking). En teoría, debería aumentar la densidad de contenedores de ECS, pero en la práctica solo la admiten tipos de instancia que NUNCA tiene sentido usar desde una perspectiva de optimización de costos en FinOps, así que personalmente recomiendo hacer de cuenta que no existe.
• Algunas notas relacionadas que vale la pena mencionar:

Normalmente, las instancias AMD suelen ser la mejor opción por defecto, por su menor costo y mayor rendimiento. La "a" en t3a viene de AMD, así que como regla general: t3a es mejor que t3. Sin embargo, la densidad de contenedores de ECS es uno de esos casos raros donde t3 le gana a t3a: el t3a.small, curiosamente, solo tiene 2 ENIs, así que solo soporta 1 tarea de ECS, mientras que el t3.small tiene 3 ENIs y soporta 2 tareas de ECS.

• Creo que las 2 razones principales por las que los usuarios de ECS prefieren instancias Fargate son:

1. Configurar ECS sobre Fargate es prácticamente turnkey, mientras que ECS sobre EC2 requiere algo de trabajo extra.

2. Al no haber una densidad de contenedores mucho mayor en EC2, hay menos incentivo para migrar de ECS sobre Fargate a ECS sobre EC2.

3. ECS ofrece opciones de service discovery más avanzadas.

Lo considero una ventaja menor de ECS, ya que solo aporta en casos de uso poco frecuentes y, en esos casos, EKS puede lograr resultados similares instalando herramientas opcionales que extienden su funcionalidad base.

• El service discovery de EKS se basa en nombres DNS internos del cluster, que solo se resuelven desde pods dentro del cluster y siguen un patrón predecible: $SERVICE.$NAMESPACE.svc.cluster.local
• ECS ofrece dos opciones de service discovery. Una es vía API y soporta comunicaciones internas del cluster ECS; la otra es vía DNS y soporta comunicaciones internas de la VPC. (Aquí puedes leer más, si te interesa.)

4. EKS le saca una ligera ventaja a ECS en multicloud y desarrollo local, ya que está basado en Kubernetes.

Ahora bien, esa diferencia es relativamente despreciable, y aquí va el porqué:

• Multicloud casi siempre es una idea terrible. La única forma de hacerlo bien es apoyarse en un diseño cloud-agnostic, lo cual también suele ser mala idea. El problema central de multicloud es que en la práctica aparecen 10 problemas reales por cada beneficio teórico.
• Minikube y Rancher Desktop sirven para correr Kubernetes localmente, pero en la práctica solo he visto que ingenieros individuales muy capaces le saquen provecho implementándolo manualmente en su propia laptop.

Hay tantos matices específicos de cada integración que resulta prohibitivo lograr una experiencia de desarrollo local consistente, con integraciones útiles, a nivel de equipo, sin una inversión enorme. Así que en realidad, el valor práctico de este beneficio suele ser muy limitado.

• Como ECS está basado en Docker, los Engineers más capaces pueden hacer desarrollo local basado en Docker en su propia laptop. El desarrollo local con Docker se aplica parcialmente a ECS, igual que el Kubernetes local se aplica parcialmente a EKS.

De la misma forma, dado que solo Engineers altamente capacitados pueden navegar los matices de cada integración para obtener beneficios que solo se aplican a ellos como desarrolladores individuales, estar basado en Docker también termina aportando un valor práctico limitado para ECS.

5. ECS no cobra por los costos del control plane; EKS sí.

Lo considero una ventaja relativamente menor, porque los costos de EKS son muy asequibles y fáciles de justificar. Dicho eso, sí puede pesar en una startup que necesita operar lo más barato posible.

• Si mantienes tu cluster EKS al día, son USD 864/año por cluster. Pero como suele ser práctica común tener clusters de dev, stage, prod y algunos de sandbox temporales, USD 3k/año es una estimación más realista.
• Aquí van 3 razones por las que los costos del control plane de EKS son fáciles de justificar:
• 1. Tienen sentido al margen de ECS.

Si quisieras correr una distribución de Kubernetes cloud-agnostic como Talos o Rancher, tendrías que pagar 3 VMs como nodos de control plane HA/FT. Los costos del control plane de EKS son más baratos que la opción DIY y vienen con los beneficios de un servicio gestionado.

• 2. EKS ofrece características por las que vale pagar un pequeño extra, sobre todo mayor facilidad de depuración y ciclos de retroalimentación más rápidos. (La siguiente sección amplía esto.)
• 3. EKS tiene sus propias características de ahorro de costos: EKS sobre EC2 es más barato que ECS sobre Fargate y, gracias a su mayor densidad de contenedores, potencialmente más barato que ECS sobre EC2; Kubernetes Ingress facilita configurar balanceadores de carga compartidos por múltiples servicios, lo que te ahorra LBs de AWS; karpenter.sh ofrece autoscaling automatizado con right-sizing; y keda.sh aporta autoscaling avanzado de contenedores.
• Todo esto puede hacer que EKS termine teniendo un costo de hosting más bajo que ECS. Hay demasiadas variables condicionales como para sentenciar cuál suele ser más barato, pero lo que sí es cierto es que no es raro que EKS salga más barato en conjunto, o que la diferencia sea neta y despreciable. Y eso convierte la existencia de los costos del control plane de EKS en un punto potencialmente irrelevante.

Esta sección reúne tres pros de EKS, una paradoja de EKS que tiende a ser un contra pero puede ser un pro, y luego dos pros de ECS.

1. EKS escala los contenedores más rápido por defecto y soporta autoscaling avanzado cuando se usa el add-on keda.sh.

• EKS suele escalar hacia arriba más rápido que ECS en general. Al comparar EKS sobre EC2 frente a ECS sobre Fargate esto resulta intuitivo, ya que Fargate no soporta caché de imágenes de contenedores.

Lo que no es tan intuitivo es que EKS también suele lograr arranques rápidos con más frecuencia, incluso cuando ambos están sobre instancias EC2.

Esto se debe a que EKS tiene mayor densidad de contenedores, lo que le permite aprovechar el caché de imágenes con más frecuencia. Gracias a ese caché, no es raro que un pod de EKS arranque en segundos.

• ECS tiene buen soporte de autoscaling y permite escalar con métricas personalizadas de CloudWatch, pero no le llega a EKS en cuanto a escalado. EKS es notablemente más rápido y mejor para hacer autoscaling de contenedores, gracias a algunos matices en los detalles de implementación de ECS, la resolución de métricas y el soporte para escalar a 0.
• Voy a profundizar en los detalles problemáticos de implementación de ECS. El autoscaling basado en target solo puede escalar hacia arriba en un número fijo de unidades de capacidad; ofrece como segunda opción el step scaling, que permite cierto escalado variable, pero termina habiendo un retraso de 1 minuto entre decisiones de escalado, porque los puntos de datos de las métricas se recolectan una vez por minuto.
• (A la frecuencia de recolección de métricas se le suele llamar resolución de métrica.)
• EKS usa el HPA (Horizontal Pod Autoscaler) de Kubernetes, con una resolución de métrica por defecto de 15 segundos, así que puede escalar 4 veces más rápido.
• El escalado de ECS funciona con CloudWatch Metrics, CloudWatch Alarms y una mezcla de valores por defecto subóptimos y no editables que terminan haciéndolo menos competente que las opciones de HPA de EKS.

ECS sí tiene un escenario óptimo en el que puede ganarle a EKS en algo, a cambio de malos trade-offs, pero en general sus opciones no están a la altura.

• Así se ve el mejor caso de autoscaling basado en métricas de ECS:

Una métrica personalizada de CloudWatch de alta resolución puede llegar hasta 1 segundo.

En la práctica, lo que importa es cada 10 segundos, porque lo que dispara el escalado es la alarma de CloudWatch, y esa tiene un período mínimo de evaluación de 10 segundos.

Técnicamente le gana al período de evaluación por defecto, no editable, de 15 segundos del HPA de EKS, pero ese beneficio viene atado a un mal trade-off. Si implementas una resolución de métrica de 10 segundos (en realidad cualquiera por debajo de un minuto), solo obtienes 3 horas de retención de métricas.

• Así se ve el autoscaling basado en métricas de ECS en escenarios habituales:
• Las métricas de CPU y RAM de ECS tienen resolución de 1 minuto, valor por defecto no editable, lo que obliga a que el período mínimo de evaluación de la CloudWatch Alarm sea de un minuto en los escenarios más comunes.
• Incluso si implementas una métrica personalizada, podrías preferir hacerla cada minuto para tener 15 días de retención y un precio más bajo.
• También vale la pena señalar que la resolución de métrica de ECS tiene un valor implícito por defecto de 1 minuto, y requiere configuración explícita para habilitar granularidad de 10 segundos.

El metrics server de Kubernetes tiene un mejor valor implícito por defecto: 15 segundos.

• ECS solo puede escalar a 0 cuando se usan métricas de cola SQS; en condiciones normales, no puede.
• EKS puede instalar un add-on gratuito llamado keda.sh para habilitar capacidades de autoscaling más robustas, como métricas personalizadas, escalado de tráfico HTTP a 0 y escalado basado en cron.

La opción de cron resulta especialmente útil en el escenario común de necesitar capacidad base extra además del autoscaling, para absorber con suavidad los picos de tráfico en horarios pico de negocio y dejar que la capacidad base baje en períodos predecibles de baja actividad.

2. La IaC (Infrastructure as Code) de EKS es fundamentalmente superior a la de ECS: estandarizada, fácil de leer, desacoplada, declarativa y con soporte para metadatos con estado.

Estas características generan ventajas de varios órdenes de magnitud en depurabilidad, ciclos de retroalimentación y experiencia general de DevOps.

• EKS sigue el estándar de Kubernetes: kubectl + yaml.

Es rápido y fácil de leer, aprender y editar para los humanos. (El soporte intrínseco de YAML para JSON es un plus, ya que YAML es un superconjunto de JSON.)

• ECS realmente no tiene un estándar oficial, ni en IaC ni en tooling. Eso hace que su IaC sea más difícil de aprender, porque desde el inicio toca investigar y elegir entre opciones habituales como AWS Copilot, AWS CDK, Terraform o Pulumi.
• En cuanto a opciones de IaC y tooling, EKS tiene más, pero en términos de estándar hay uno solo. Y todas las opciones de EKS se basan en ese único estándar; eso le da a EKS una ventaja significativa, tanto en facilidad de aprendizaje como en las posibilidades de desarrollar habilidades transferibles entre empresas que prefieren trabajar con estándares comunes.
• La falta de desacoplamiento conceptual y de IaC en ECS trae varias desventajas inherentes.

Un ECS Service equivale conceptualmente a un deployment, service, configmap, secret y rol de AWS IAM de EKS, todos fuertemente acoplados en un solo paquete. Eso genera múltiples problemas:

• 1. Un primer problema es que ese acoplamiento estrecho de los deployments de ECS limita las ediciones in-place que se pueden hacer sobre un objeto desplegado.

No es raro que los cambios obliguen a hacer redespliegues completos o procesos molestos de dos pasos con eliminación y recreación.

Eso cansa rápido cuando necesitas hacer cambios iterativos.

ECS hace que agregar, quitar o cambiar tipos de balanceador de carga sea muy molesto. Te darás cuenta de que no puedes reusar el mismo nombre de servicio sin eliminar y recrear desde cero, lo que generaría tiempo de inactividad. Puedes sortearlo con un cutover blue-green, pero eso añade sobrecarga.

En cambio, los Engineers que trabajan con EKS disfrutan de una gran experiencia gracias a las actualizaciones declarativas e idempotentes.

• 2. Los deployments de ECS son por naturaleza más lentos que los de EKS.
• 3. Cuando un deployment de ECS sale mal, es fácil terminar depurando una caja negra sin señales claras de retroalimentación que indiquen si el estado real convergió al estado deseado.

Por eso no es raro que los Engineers de ECS tengan que esperar a que se cumplan timeouts y dediquen unos 4 minutos entre iteraciones de "computer says no".

Algunas elecciones de tooling, como AWS Copilot, pueden empeorar aún más esa experiencia de caja negra. Cuando Copilot cae en ciertos escenarios de depuración, la espera entre iteraciones puede ir de 20 a 60 minutos, porque hay que aguardar a que ECS, CloudFormation y otras capas de abstracción de caja negra hagan timeout.

Y no olvidemos que cuando hay fallas, la naturaleza de caja negra de ECS muchas veces no entrega retroalimentación ni pistas sobre la causa del error.

• 4. Hay una tendencia a que depurar problemas en deployments de ECS requiera más iteraciones que depurar objetos yaml de EKS, que son más simples y desacoplables.

Esa tendencia se debe a que las tareas de ECS son un paquete fuertemente acoplado de varios componentes; el alcance de la resolución de problemas es mayor y no hay una forma fácil de acotar en qué componente enfocarse.

• Cuando finalmente toca depurar EKS, puedes desplegar, editar y depurar componentes de manera sistemática e independiente entre sí. Y resulta fácil llegar a un ciclo de retroalimentación medido en segundos, porque hay señales claras al ejecutar kubectl describe o sacar un yaml y revisar los eventos con estado y el status del objeto YAML. El ciclo de retroalimentación de EKS suele estar limitado por lo rápido que puedas pensar y escribir.
• Gracias a kubectl port-forward, depurar servicios con IP privada en EKS es trivial. ECS no tiene un equivalente real.
• Un elemento esencial de la gran experiencia de Kubernetes en términos de retroalimentación es que los controladores agregan metadatos con estado al manifiesto yaml de los objetos componentes que se aplican con kubectl contra la base de datos etcd de un cluster en vivo.

Gracias a eso, los Engineers pueden apoyarse en kubectl describe y en la salida yaml para revisar los metadatos de eventos o status de un objeto, lo que da retroalimentación rápida y a menudo específica sobre el éxito o el fracaso de cada etapa en cada componente.

Así que cuando algo falla, puedes identificar rápido qué componente concreto falló y qué salió mal.

• Comparémoslo con el flujo defectuoso de ECS: la GUI web de AWS te deja crear un servicio ECS de tipo balanceador de carga, y el cuestionario de despliegue te pregunta a qué subnets quieres desplegar.

Te dirá que no puedes desplegar a la vez en públicas y privadas y que tienes que elegir una, pero no te aclara el detalle crítico de la pregunta:

¿Estas son las subnets para el balanceador de carga o para las instancias backend?

Además, solo te pregunta una vez por las subnets, cuando debería preguntarlo dos veces para que puedas seguir la mejor práctica estándar de poner público el balanceador de carga y privadas las instancias backend.

El flujo de ECS te permite hacer cosas que debería bloquear, como desplegar un balanceador de carga con IP pública en una subnet privada.

Eso, evidentemente, no va a funcionar, y debería ser detectado por la validación de entrada; en cambio, te encuentras con un error evitable y con mala retroalimentación sobre por qué no funciona.

• Otro escenario común de depuración donde EKS brilla:

Pongamos que un Engineer crea una VPC nueva para hacer pruebas y, por error, despliega un cluster EKS o ECS en una VPC sin NAT gateway.

• Con ECS no obtendrás logs ni métricas, porque el pull de la imagen del contenedor fallará por falta de acceso a internet. Vas a estar volando a ciegas, sin retroalimentación sobre qué pasó. ECS exec no viene turn-key activado por defecto en la plataforma y es difícil de habilitar.

Es fácil malgastar muchas iteraciones depurando en vano la configuración de la tarea o el servicio ECS si no caes en cuenta de que es un problema de la VPC, porque ECS funciona más como una caja negra con mala retroalimentación.

Nada te avisa siquiera que el pull de la imagen falló; te toca intuir que esa debe ser la causa.

• Si te topas con el mismo escenario en EKS, se resuelve mucho más fácil, porque aunque los nodos worker no tengan acceso a internet, el control plane es accesible públicamente por defecto, así que con kubectl puedes obtener feedback como "image pull failed", una buena pista sobre la falta de conectividad a internet.

3. ECS no tiene soporte nativo para volúmenes.

• Algo que me sorprendió aprender de ECS es que si quieres inyectar configuración o un secret (desde una configuración inline en un ecs-task-definition.json o referenciada desde AWS Secrets Manager), las variables de entorno son la única opción oficial integrada en ECS para cargar configuración. No hay una opción fácil, integrada en la plataforma ECS, para montar configuración o secrets como archivo.
• Esa imposibilidad de inyectar fácilmente archivos de configuración dinámicos es una de las grandes razones por las que ECS no tiene un equivalente al concepto de Ingress Controller de Kubernetes.
• ECS puede usar EFS para almacenamiento con estado y existen soluciones improvisadas para montar archivos, pero todos son métodos forzados y poco fáciles de implementar, porque no hay soporte nativo a nivel de plataforma ECS para volúmenes.

Vale la pena aclarar un matiz sobre esa afirmación:

ECS tiene soporte para EFS a nivel de plataforma AWS, pero no hay integraciones a nivel de plataforma ECS que faciliten su configuración.

(No solo no es fácil, sino que diría que muchas veces es más difícil configurar EFS sobre ECS que sobre EC2 standalone o EKS, porque ECS suele comportarse como una caja negra difícil de depurar y con un ciclo de retroalimentación lento.)

• EKS, en cambio, tiene un driver EFS CSI para configurar una Storage Class de Kubernetes; esa integración y el soporte integrado a nivel de plataforma EKS facilitan configurar EFS sobre EKS.)
• En EKS, la configuración y los secrets se pueden montar como variable de entorno o como archivo. StatefulSets, storage classes, persistent volumes y otras características avanzadas hacen que los workloads con estado sean relativamente fáciles de implementar.

4. La dificultad de EKS suele ser variable y paradójica: "EKS tiende a ser difícil porque es demasiado fácil".

La dificultad de ECS es relativamente estática, porque ECS tiene restricciones más fundamentales. La importancia de estos matices está en que cuando un equipo de implementación cuenta con consultoría experta basada en experiencia y aplica una buena estrategia, EKS puede resultar más fácil que ECS.

(Para quien no lo tenga claro: este es un punto de vista sostenido en pensamiento crítico que va en contra de una afirmación común en la documentación de AWS, según la cual ECS siempre es más fácil que EKS.)

• Te pido paciencia, porque este insight en particular toma su tiempo: involucra matices, una paradoja empírica y compartir algunos hilos de pensamiento que son esenciales para que el siguiente insight resulte intuitivo:
• EKS tiene el potencial de ser más fácil que ECS. ECS arrastra desventajas intrínsecas e inevitables; las más relevantes ya las mencionamos antes. Las desventajas de EKS son fundamentalmente distintas, porque tienden a ser una propiedad emergente, fruto de una paradoja causada por sesgos naturales.

Si entiendes el panorama general de la desventaja paradójica de EKS, su causa y cómo evitarla estratégicamente, EKS se vuelve mucho más fácil.

• EKS es un gran ejemplo de un viejo refrán: "Demasiado de algo bueno puede ser malo. Cuando las cosas buenas se llevan al extremo, suelen traer problemas".
• Kubernetes es tan bueno, tan capaz y tan exitoso que tiene un ecosistema enorme. Ese ecosistema enorme es complejo, y esa complejidad, sumada al sesgo natural de adoptar herramientas de Kubernetes con beneficios claros pero costos ocultos, es una de las grandes razones por las que se percibe a EKS como difícil.
• Algo importante que hay que asimilar es que todo ese gran ecosistema complejo de Kubernetes es opcional. Si decides estratégicamente minimizar su uso, EKS se mantiene fácil.
• Voy a dar algo de contexto y luego entrar en otra paradoja relacionada:
• Una de las habilidades de ingeniería a nivel de principio que tengo es saber distinguir entre solucionadores de problemas y transformadores de problemas. Los transformadores de problemas son herramientas y técnicas que resuelven 1 problema a cambio de crear N problemas nuevos, y suelen ser malas ideas y cosas a evitar, salvo que de verdad sepas lo que estás haciendo y hayas pensado en varias consecuencias de segundo orden.
• Por esa lógica creo que las siguientes ideas suelen ser malas:

Kubernetes Operators, StatefulSets, usar APIs que no sean v1, los operadores que despliegan StatefulSets usando APIs alpha (este es de los grandes), service meshes y nginx-ingress controller. Y no podemos olvidarnos de HashiCorp Vault: "los amigos no dejan que sus amigos usen hashi-vault".

• Algunos ejemplos de problemas que se introducen: CVEs críticos, sobrecarga de mantenimiento y actualizaciones forzadas a EKS que terminan derivando en actualizaciones forzadas de las apps.

No es raro que las actualizaciones traigan cambios disruptivos, así que ahora hay nuevas formas en que tus servicios pueden fallar y un radio de impacto mayor si algo sale mal, lo que se traduce en pruebas adicionales.

• Un setup lo bastante complejo puede generar problemas de IaC, automatización, documentación, cuellos de botella de habilidades, dotación de personal, y más.
• Con ese contexto en mente, aquí va la paradoja relacionada:

Si a alguien se le ocurre una mala idea, ECS es restrictivo, inflexible y lo bastante difícil como para que sea fácil darse cuenta de que esa mala idea va a costar implementarla. Va a ser tan trabajoso hacer lo mínimo, que se hará lo mínimo, y como resultado se percibe a ECS como más fácil.

• EKS, repito, es demasiado flexible y demasiado capaz para su propio bien.

Cuando a alguien se le ocurre una mala idea, EKS ofrece tanta libertad y tanta facilidad de implementación que cualquier idea se puede llevar a cabo, incluidas las malas.

Es desafortunado cuando se comparten malas ideas, porque Kubernetes es tan fácil de usar que otros pueden adoptarlas e implementarlas sin querer.

Y luego, cuando aparecen los problemas, Kubernetes carga con la culpa por ser "demasiado difícil".

La verdad oculta es que muchos problemas se evitan simplemente evitando malas ideas.

O dicho de otra forma: "EKS es difícil cuando la gente lo hace difícil".

• Estos insights se pueden combinar para sentar la base de una buena estrategia de implementación de EKS:

Básicamente, intenta ceñirte a la funcionalidad simple de EKS aplicando la regla práctica de preferir la funcionalidad integrada, considera con regularidad el principio YAGNI y evita características que no estén disponibles en ECS. (ECS prácticamente no tiene operadores, ingress controllers, persistent volumes, APIs no estables ni un ecosistema masivo de herramientas de terceros, y el soporte de AWS App Mesh está siendo eliminado.)

Si comparas ambos con esta estrategia en mente, te acercas a una comparación de manzanas con manzanas; solo que ahora EKS empieza a parecer una sabrosa manzana Honeycrisp.

5. Las actualizaciones de ECS son extremadamente raras, lo cual es una gran ventaja en estabilidad y para evitar el trabajo tedioso ligado a las operaciones del cluster.

• En teoría, una instancia Fargate on-demand podría pasar años sin actualizarse; eso evita interrupciones causadas por cambios disruptivos asociados a las actualizaciones.
• La plataforma EKS, tarde o temprano, fuerza a actualizar a quienes la adoptan, y si las aplicaciones que corren en el cluster fueron descuidadas y nunca se actualizaron, hay riesgo de que una actualización forzada de plataforma rompa versiones desactualizadas de aplicaciones diseñadas para correr con versiones específicas de Kubernetes.
• El nginx-ingress controller es un buen ejemplo de una aplicación muy conocida que tiene una tabla con las versiones específicas de Kubernetes en las que cada versión del ingress controller está pensada para correr.
• Un escenario relativamente común, autoinfligido y problemático que algunas organizaciones viven con EKS es que contratan a un consultor para montar una solución basada en EKS lo más rápido y barato posible. Cuando termina el contrato, el cluster EKS y sus workloads pueden quedar intactos durante años.

Tarde o temprano alguien aprende que la plataforma EKS termina forzando actualizaciones. Y eso pasa o bien después de que algo se rompió, o bien cuando la organización le pide a alguien actualizar su(s) cluster(s) EKS a último momento, antes de una actualización automática forzada.

Suele pasar que el Engineer descubre que subestimó el esfuerzo que implica la tarea, porque tiene que actualizar varios workloads desplegados en el cluster además del cluster mismo.

• Normalmente eso no es gran cosa, pero hacerlo bajo una fecha límite de último momento es estresante. Y si no se cumple, puede causar interrupciones en producción. Sobre todo porque esas organizaciones suelen lanzarle la tarea a alguien que no es experto en Kubernetes, y los clusters EKS descuidados suelen ser fruto de trabajos apresurados y mal planificados, así que carecen de IaC o de documentación sobre cómo los configuró un Engineer que se fue hace más de 2 años.
• Además de las actualizaciones forzadas, los nodos EC2 de EKS tienen más escenarios en los que los nodos worker necesitan reiniciarse que un cluster ECS sobre instancias Fargate.

(Los nodos EC2 pueden ser reducidos por un cluster autoscaler de ahorro de costos como karpenter.sh, que además, por defecto, reinicia los nodos on-demand cada 30 días para que reciban los últimos parches de las VMs de EKS Worker Node.)

• EKS también facilita introducir complejidad opcional en forma de karpenter.sh, controladores de Kubernetes gateway-api, ingress controllers y service meshes.
• Adoptar estos componentes opcionales suma riesgo: nuevas formas en que pueden ocurrir fallas, más cosas que pueden romperse, nuevos modos de falla como malas configuraciones, malas actualizaciones, vulnerabilidades de cadena de suministro, vulnerabilidades críticas que exigen actualizaciones apresuradas, reinicios semi-frecuentes incorporados como característica, o cambios disruptivos asociados a las actualizaciones.
• Una ironía es que los service meshes como Istio incluyen características pensadas para mejorar el uptime —formar una malla multi-regional entre varios clusters, lógica de reintentos y otras—; sin embargo, en la práctica no es raro que sean fuentes habituales de tiempo de inactividad.
• Una vez que una app está desplegada y funcionando, ECS suele ser libre de mantenimiento.
• Los setups de EKS suelen tener al menos 3 clusters, y cada uno con varios componentes, todos los cuales se actualizan y, en conjunto, generan un trabajo de mantenimiento ineludible.
• Por suerte, muchos avances permiten reducir ese trabajo tedioso de mantenimiento; uno grande es EKS Auto Mode, pero incluso sin él, los AWS Managed Add-ons y las APIs estables v1 para ingress y karpenter han hecho que las actualizaciones sean más fáciles, rápidas y libres de preocupaciones.

6. EKS tiene una sobrecarga de mantenimiento inevitable y un orden de magnitud más de partes móviles que ECS, que prácticamente no necesita mantenimiento.

Estas 2 desventajas, aparentemente menores, de EKS producen efectos de segundo orden que se traducen en desventajas significativas en sobrecarga operacional. Para darle un poco de contexto al término "significativo", usemos como estimación aproximada 2 a 14 días/año de tiempo de ingeniería dedicado al mantenimiento de EKS.

• Las características de ECS lo hacen muy indulgente cuando las mejores prácticas habituales de DevOps no se conocen o se ignoran/minimizan a propósito.

Los administradores de ECS pueden lograr confiabilidad incluso con patrones mal vistos, como:

• 1. Implementar flujos de trabajo con una mezcla de operaciones manuales y automatización parcial, con IaC mínima, o automatizando el despliegue de workloads pero no el aprovisionamiento de clusters.

(Esto puede funcionar, porque una vez que un equipo logra que ECS funcione, suele seguir funcionando.)

• 2. Ignorar los beneficios de seguridad de tener varios clusters y meter todo en 1 solo cluster ECS.

(Aunque dev y prod queden mezclados en 1 cluster ECS, rara vez golpea la confiabilidad gracias a los patrones arquitectónicos comunes de ECS, que hacen que la mayoría de los problemas posibles tengan un radio de impacto pequeño:

Es habitual que los servicios de ECS tengan su propio LB gestionado de AWS, en lugar de un Kubernetes Ingress Load Balancer compartido. Los contenedores Fargate corren en sus propias VMs individuales, lo que mejora el aislamiento.)

• 3. No implementar límites y solicitudes de recursos precisos.

(Como las instancias Fargate tienen una proporción de 1 tarea ECS por 1 VM, esto se queda solo como un problema de optimización de costos, en lugar de ser a la vez un problema de costos y de confiabilidad.)

• EKS tiene tantas partes móviles y tanta complejidad que la implementación rigurosa de mejores prácticas es prácticamente un requisito para los administradores que quieren mantener sus clusters EKS confiables y mantenibles a largo plazo.
• Esa exigencia de implementación rigurosa de mejores prácticas tiene una desventaja importante.

Las tareas asociadas a la implementación de mantenimiento y mejores prácticas consumen tiempo de ingeniería, y las horas de ingeniería son caras. Peor aún, perseguir las mejores prácticas puede llevar a los Engineers a meterse en madrigueras de Yak Shaving de DevOps.

El Yak Shaving de DevOps puede ser una actividad perfectamente razonable, pero también es una madriguera potencialmente problemática, porque cuesta distinguir entre lo perfectamente razonable, lo potencialmente excesivo y lo completamente innecesario.

Quiero subrayar esto con una observación: los administradores de ECS no solo se ahorran tareas; también se cruzan con menos escenarios de Yak Shaving de DevOps.

• Cualquier equipo que gestione EKS llegará rápido a la conclusión de que necesita al menos 2 clusters EKS para mantener la confiabilidad.

Es fácil descubrir que las actualizaciones de componentes de EKS o las malas configuraciones pueden generar cambios disruptivos, y que los problemas con muchos componentes —ingress, DNS, CNI, karpenter.sh, service meshes y nodos no saludables— tienen radios de impacto grandes.

Por eso resulta intuitivamente obvio que los entornos aislados y probar las actualizaciones en entornos inferiores son esenciales para la confiabilidad de EKS.

• Una vez que los equipos de EKS se acostumbran a un flujo de promoción de entornos, llega otra constatación común:

Las pruebas en un entorno inferior solo son válidas si los entornos inferior y superior son relativamente parecidos entre sí.

• Muchos equipos de EKS invierten tiempo en desarrollar implementaciones rigurosas de infrastructure as code, automatización end-to-end y pipelines CICD que mantengan en sintonía sus entornos inferiores y superiores.
• Otra experiencia habitual es que los entornos de desarrollo cambian más rápido y con más frecuencia, y conviven con cambios manuales. Los cambios manuales de emergencia ("break glass") en producción para resolver interrupciones e incidentes tampoco son raros.

Por eso no es raro que los equipos de EKS sufran config drift, donde un entorno en vivo no coincide con la IaC ni con la automatización definidas en git o en un pipeline CICD.

Asegurar que el entorno en vivo coincida con la IaC exige aún más implementación rigurosa de mejores prácticas, lo que normalmente implica una mezcla de pipelines CICD e implementaciones de GitOps.

1. ECS puede ser la mejor opción en escenarios donde:

• Quieres diseñar una app para que corra entre 2 y 10 años con máximo uptime y mínimo mantenimiento.

Pongamos que tienes una aplicación que casi no se actualiza, como servicios de tooling interno —por ejemplo, una aplicación de auditoría interna a medida— o una aplicación de cara al público que no causaría grandes problemas si la golpeara una vulnerabilidad crítica de día cero de ejecución remota de código (gracias a buenas prácticas como usar una imagen distroless sin shell y permisos IAM bajo el principio de menor privilegio).

En esos casos puede tener sentido priorizar la fortaleza de ECS —sobrecarga operacional cercana a cero— por encima de la fortaleza de EKS —depuración más fácil y ciclos de retroalimentación más rápidos—.

• Tienes aplicaciones relativamente simples, despliegas a entornos solo unas pocas veces al día, tienes necesidades de aplicación y arquitectura estables que cambian poco, o planeas invertir en un pipeline CICD propio de ECS que solo despliegue patrones simples y siempre funcionales.

En esas circunstancias, vas a minimizar tu exposición a las desventajas de ECS: lo difícil que es de depurar cuando algo sale mal y su ciclo de retroalimentación lento.

• Tienes un equipo pequeño, solo developers, y ninguno de sus integrantes está mínimamente interesado o dispuesto a aprender a implementar las mejores prácticas de DevOps con rigor.

En ese caso ECS es más indulgente que EKS cuando las mejores prácticas operacionales son escasas o están minimizadas.

2. Justificar objetivamente a EKS como la mejor opción exige un análisis algo más profundo de los factores situacionales:

• Tanto ECS como EKS son una mezcla agridulce, con beneficios y desventajas a la vez. Dicho eso, puedes pensar en ECS como más equilibrado, donde los beneficios y las desventajas son ambos relativamente moderados (bajo riesgo, baja recompensa). EKS, en cambio, es un caso de beneficios más significativos y desventajas moderadas (riesgo moderado, recompensa significativa).
• Antes de entrar en los beneficios de EKS, conviene empezar por las desventajas, porque tenerlas presentes desde el inicio te pone en mejor disposición para sacar más partido a una pregunta que aporta una buena perspectiva:

"¿Los beneficios que estoy viendo, al menos compensan, si no superan, las desventajas?"

• 1ª desventaja de EKS: adoptar EKS con éxito exige una implementación rigurosa de las mejores prácticas de DevOps, lo cual a su vez requiere disposición y una inversión significativa de recursos.

Esto puede llevar más tiempo del que muchos esperan, porque los "problemas de DevOps" suelen necesitar "soluciones de DevOps", que a menudo deben combinarse con transformadores de problemas antes de aplicar las soluciones genuinas.

Por eso los profesionales de DevOps a veces se autodefinen, en broma, como yak shavers profesionales. Si transformas un problema infinitas veces, terminas afeitando un yak.

(Estimemos esto a grandes rasgos en 1 a 4 meses de inversión única en esfuerzo de ingeniería.)

• Si quieres influir positivamente en ese compromiso de tiempo de 1 a 4 meses, paga lo suficiente para contratar pensadores críticos que entiendan las diferencias matizadas entre soluciones de problemas y transformaciones de problemas. Asegúrate de que tu equipo entienda la lógica detrás de la perspicaz paradoja de que "EKS tiende a ser difícil porque es demasiado fácil".

Y favorece principios y consejos como:

KIS (Keep it Simple), YAGNI (You aren't gonna need it), las APIs estables v1 son tus amigas, los servicios gestionados como el AWS LB Controller son preferibles a Ingress Controllers DIY como Nginx (pista: el primero es una solución y el segundo una transformación de problema; ¡el escaneo de vulnerabilidades de quay.io señaló que una imagen de 6 años de nginx-ingress-controller tenía 76 vulnerabilidades críticas, un promedio de 1 CVE crítico por mes!), y EKS Auto Mode es una opción a considerar.

(Auto Mode también es una transformación de problema, ya que tiene desventajas como introducir un efecto de caja negra y aumentar costos; aun así, suele valer la pena para clusters greenfield a pequeña escala.)

Haciendo todo esto, EKS puede mantenerse relativamente fácil.

Recuerda: "EKS es difícil cuando la gente lo hace difícil".

• 2ª desventaja de EKS: tiene un grado ineludible de trabajo tedioso de mantenimiento.

(Estimemos a grandes rasgos 2 a 14 días de mantenimiento al año para 3 clusters.)

• Vale la pena señalar que EKS Auto Mode, lanzado en diciembre de 2024, puede ayudar mucho a reducir las 2 principales desventajas de EKS.
• EKS Auto Mode elimina mucho trabajo previo (asociado a la configuración de add-ons comunes), conocimientos previos, mantenimiento continuo e incluso modos de falla, ya que es capaz de evitar cambios disruptivos al usar y automatizar solo upgrades de add-ons basados en APIs estables v1.
• Dicho esto, no elimina el mantenimiento del todo y tiene algunas desventajas: añade ciertos costos y convierte a EKS en algo más parecido a una caja negra, lo que perjudica la depurabilidad.

(Ejecuta pods de karpenter.sh en los nodos del control plane gestionado, así que no puedes acceder a los logs de los pods de karpenter.sh, y esos suelen ser necesarios para depurar casos extremos.)

• Los prerrequisitos son otra cosa que EKS Auto Mode no elimina del todo. Esta página enlazada menciona que necesitarás suministrar una clase de ingress específica de Auto Mode, anotaciones de servicio para el balanceador de carga y una storage class que referencie un EBS Volume Provisioner específico de Auto Mode para usar todas las características de Auto Mode.
• También conviene saber de antemano que migrar de Auto Mode deshabilitado a Auto Mode habilitado es complicado. A primera vista, el portal web de EKS hace parecer que basta con activarlo o desactivarlo.

Sin embargo, si lees esta página de Migration Reference, descubrirás que una migración in-place es un proceso manual muy doloroso, hasta el punto de que muchas veces resulta más sencillo desplegar un cluster nuevo y hacer una migración blue-green hacia él. La dificultad se debe a que EKS Auto Mode tiene su propia clase única de ingress, su propia clase de balanceador de carga y su propio EBS CSI volume provisioner, así que si intentas hacer una migración in-place de Auto Mode deshabilitado a habilitado en un cluster preexistente, necesitarás recrear servicios de Kubernetes de tipo Load Balancer, objetos Ingress y cualquier PVC creado antes de habilitar Auto Mode.

• Dadas esas pequeñas pegas y los costos extra, no tiene sentido recomendar EKS Auto Mode en todos los casos; aun así, creo que suele ser una buena elección para clusters greenfield a pequeña escala gestionados por equipos que recién empiezan con EKS. También creo que EKS Auto Mode tiene mucho sentido para quienes prevén tener más de 6 clusters de larga duración.
• Ahora sí, hablemos de los beneficios. El más importante a destacar es un ahorro de tiempo que tiene el mayor impacto a la hora de compensar los costos de tiempo mencionados antes.
• EKS aporta un beneficio significativo en depuración más fácil y rápida, junto con ciclos de retroalimentación más ágiles. Y bajo las circunstancias adecuadas (a menudo, el desarrollo implica depuración continua), esa sola característica puede inclinar la balanza al introducir suficiente ahorro de tiempo como para compensar los costos y dejar un saldo neto positivo, además de los demás beneficios de EKS.
• Aquí van algunos escenarios habituales en los que EKS se vuelve fácil de justificar: tu app despliega a entornos con la frecuencia suficiente como para justificar un pipeline CICD lo más rápido posible; tiene cambios frecuentes; tiene integraciones complejas; tiene arquitectura orientada a servicios; está en plena transformación de monolítica a orientada a servicios usando el patrón strangler; o tiene complejidades que hacen que la capacidad de depurar fácilmente con un ciclo de retroalimentación rápido se considere muy valiosa.
• ¿Esperas que algunas de tus apps tengan tráfico muy variable, donde escalar lo más rápido posible podría ser un factor decisivo?

Si es así, las opciones avanzadas de escalado de EKS (impulsadas por el add-on keda.sh), como escalar a cero y escalado por horario cron, pueden convertirse en ventajas significativas, además de oportunidades de ahorro de costos.

• ¿Alguna de tus apps tiene un requisito estricto de cargar la configuración como archivos? ¿Necesitas opciones de almacenamiento robustas?
• ¿Necesitas, o ves un beneficio claro, en tener acceso a funcionalidad avanzada y patrones de ingeniería como RBAC a nivel de cluster, policy as code, GitOps, balanceo de carga avanzado, integraciones OIDC/Authn/z y, en general, una personalización que facilite implementar cualquier idea con una gran experiencia de Engineering?
• EKS puede ser una gran opción para proyectos donde sus beneficios superan la sobrecarga de mantenimiento de 2 a 14 días/año que implica adoptarlo, y donde puedas conseguir que las partes interesadas acepten 1 a 4 meses de inversión única para implementarlo según las mejores prácticas.

3. Las aplicaciones con estado son un escenario lo bastante común como para justificar una discusión basada en reglas prácticas:

• EKS facilita correr aplicaciones con estado y las soporta bien, pero que sea fácil no significa que automáticamente sea buena idea. Intenté ofrecer una visión bien fundada del nivel de dificultad de EKS junto con sus beneficios, pero hay una aclaración importante: la dificultad que mencioné hasta ahora asume que estás corriendo aplicaciones sin estado (y quizás algunas con estado en las que la pérdida de datos es aceptable, como cachés valkey/redis o herramientas de monitoreo autoalojadas tipo el stack de observabilidad PLG de Grafana Labs).
• Muchas veces se instalan aplicaciones con estado en Kubernetes sin considerar el ciclo de vida completo de la aplicación, incluidos backups automatizados, restauraciones automatizadas, pruebas e integraciones con pipelines CICD.

Cuando todo eso se considera de verdad, la sobrecarga operacional para mantener una gran confiabilidad a largo plazo suele ser extremadamente alta.

• Tan alta como para considerar 3 opciones:
• 1. Considera aceptar un mayor riesgo de tener varias horas de tiempo de inactividad aproximadamente una vez al año, a cambio de evitar una sobrecarga operacional importante, al no implementar de forma rigurosa las mejores prácticas asociadas a workloads con estado.
• 2. Si necesitas un uptime altamente confiable y opciones más sencillas de recuperación ante desastres, externalizar a un servicio gestionado costoso puede traducirse en un menor costo total de propiedad.
• 3. Verifica si las partes interesadas tienen apetito y disposición para invertir 1 a 6 meses (por cada app/base de datos con estado) de tiempo y esfuerzo de ingeniería dedicado a implementar con rigor las mejores prácticas asociadas a workloads con estado, sumado a una mayor sobrecarga de mantenimiento.