Hace seis meses, nuestro equipo de DevOps se ahogaba en la complejidad. Gestionábamos 47 clústeres Kubernetes en tres proveedores de nube.
Nuestros ingenieros trabajaban los fines de semana. Las rotaciones de guardia eran temidas. Entonces tomamos una decisión que parecía una locura en aquel momento: empezamos a eliminar Kubernetes de nuestra pila.
Hoy, nuestra tasa de éxito de despliegue ha aumentado un 89%. Los costes de infraestructura han bajado un 62%. Y por primera vez en dos años, nuestro equipo de DevOps se tomó vacaciones ininterrumpidas.
Esta es la historia.
El sueño de Kubernetes frente a la realidad
Como muchas empresas, nos subimos al carro de Kubernetes hace tres años. Las promesas eran convincentes:
- Orquestación de contenedores a escala
- Arquitectura nativa en la nube
- Infraestructura como código
- Escalado y recuperación automatizados
Y sí, Kubernetes cumplió estas promesas. Pero conllevaba costes ocultos de los que nadie hablaba.
El punto de ruptura
Nuestro punto de ruptura llegó durante el Black Friday. A pesar de tener
- 8 ingenieros senior de DevOps
- 3 equipos SRE dedicados
- rotaciones de guardia 24/7
- Contratos de soporte empresarial
- Amplia configuración de supervisión
Todavía experimentamos:
- 4 cortes importantes
- 147 falsos positivos
- 23 despliegues de emergencia
- 2 miembros del equipo renunciaron alegando agotamiento
Algo tenía que cambiar.
El coste real de Kubernetes
Cuando analizamos nuestros costes reales, las cifras fueron impactantes:
Gastos generales de infraestructura:
- 40% de nuestros nodos ejecutando componentes Kubernetes
- 25.000 $/mes sólo para planos de control
- 3x de redundancia para alta disponibilidad
Coste humano:
- 3 meses para formar adecuadamente a cada nuevo empleado de DevOps
- 60% del tiempo de DevOps dedicado al mantenimiento
- Aumento del 30% en incidentes de guardia
- 4 ingenieros experimentados abandonan la empresa en 12 meses
Complejidad oculta:
- Más de 200 archivos YAML para despliegues básicos
- 5 herramientas de monitorización diferentes
- 3 soluciones de registro distintas
- Problemas constantes de compatibilidad de versiones
El enfoque alternativo
Empezamos poco a poco. Elegimos nuestro servicio menos crítico y lo trasladamos a una pila más sencilla:
- AWS ECS para la orquestación de contenedores
- CloudFormation para la infraestructura
- Servicios gestionados siempre que fuera posible
- Scripts de shell sencillos para la implementación
Los resultados fueron inmediatos:
- Tiempo de despliegue: 15 minutos → 3 minutos
- Archivos de infraestructura: 200+ → 20
- Coste mensual: 12.000 dólares → 3.200 dólares
- Ruido de alerta: Reducido en un 80
La migración completa
Animados por los resultados iniciales, desarrollamos un plan de migración de 4 meses:
Fase 1: Auditoría y evaluación
- Mapeo de todos los servicios y dependencias
- Identificamos las cargas de trabajo críticas frente a las no críticas.
- Cálculo de los costes operativos reales
- Documentación de los puntos débiles
Fase 2: Arquitectura alternativa
- Selección de las herramientas adecuadas para cada carga de trabajo:
- Aplicaciones sencillas → AWS ECS/Fargate
- Servicios con estado → EC2 con Docker
- Trabajos por lotes → AWS Batch
- Controlados por eventos → Lambda
Fase 3: Migración gradual
- Se comenzó con los servicios no críticos
- Se movió un grupo de servicios a la vez
- Ejecutó sistemas paralelos inicialmente
- Se recopilaron métricas de rendimiento
Fase 4: Reorganización del equipo
- Reducción de funciones especializadas
- Formación cruzada de los miembros del equipo
- Simplificación de las rotaciones de guardia
- Documentación actualizada
Resultados después de 6 meses
Mejoras técnicas:
- Reducción del 58% de los costes de infraestructura
- Tiempo medio de despliegue un 89% más rápido
- 73% menos de incidentes de producción
- 91% de reducción del ruido de las alertas
Beneficios para el equipo:
- Cero despliegues en fin de semana
- Reducción de los incidentes de guardia en un 82
- Ninguna salida por agotamiento
- Incorporación más rápida de nuevos miembros del equipo
Impacto en la empresa:
- Entrega de funciones un 47% más rápida
- Mantenimiento de un tiempo de actividad del 99,99
- Reducción del tiempo de contratación de DevOps en un 60
- Ahorro anual de 432.000 dólares en infraestructura
Cuándo debe (y cuándo no debe) utilizar Kubernetes
Kubernetes no es malo. Simplemente está demasiado prescrito. Puede que necesite Kubernetes si
- Está ejecutando miles de microservicios
- Necesita un autoescalado complejo
- Tiene requisitos multi-nube
- Necesita patrones de despliegue avanzados
Probablemente no necesite Kubernetes si:
- Tienes menos de 20 servicios
- Su escala es predecible
- Utiliza principalmente servicios gestionados
- Su equipo es pequeño (<5 DevOps)
El camino a seguir
Nuestra nueva pila es aburrida. Es simple. No da lugar a interesantes charlas en conferencias. Pero funciona, y a nuestro equipo le encanta.
Ahora nos centramos en:
- Utilizar servicios gestionados siempre que sea posible
- Elegir la simplicidad frente a la flexibilidad
- Automatizar sólo lo necesario
- Mantener la transparencia de las operaciones
Puntos clave
Cuestionar los valores predeterminados:
- Que los gigantes tecnológicos utilicen algo no significa que usted deba hacerlo.
- Las soluciones complejas suelen crear más problemas de los que resuelven
- Considere el coste total, incluido el bienestar del equipo
Dimensione correctamente sus herramientas:
- Empiece con algo sencillo y amplíelo cuando sea necesario
- Utilice tecnología aburrida para problemas aburridos
- Tenga en cuenta el tamaño y la experiencia del equipo
Valore la felicidad del equipo:
- Los equipos felices son equipos productivos
- Los sistemas sencillos son sistemas mantenibles
- Menos tiempo apagando fuegos significa más tiempo innovando
A veces, la mejor decisión de ingeniería es eliminar complejidad en lugar de añadirla. Nuestra «loca» decisión de abandonar Kubernetes resultó ser una de las mejores decisiones técnicas que hemos tomado.
¿Estamos diciendo que Kubernetes es malo? No. Estamos diciendo que para muchos equipos, incluido el nuestro, la complejidad que aporta es mayor que sus beneficios.
Y a veces, la admisión de esta simple verdad puede transformar toda su organización de ingeniería.
EDITAR
Cuando compartimos nuestra experiencia acerca de alejarse de Kubernetes, nos sentimos abrumados por las discusiones que provocó. Muchos lectores plantearon preguntas válidas sobre nuestra arquitectura, costes y enfoque.
Esta edición tiene como objetivo proporcionar el contexto que falta, abordar conceptos erróneos y aclarar cómo evolucionaron nuestras decisiones.
¿Qué falló?
Empezamos a utilizar Kubernetes hace tres años, atraídos por sus promesas de escalabilidad, flexibilidad y automatización.
Al principio funcionó bien, pero a medida que nuestra plataforma crecía, nos encontramos con varios problemas.
¿Por qué 47 clústeres?
Una de las preguntas más comunes que recibimos es: ¿Por qué 47 clusters? Ese número puede parecer elevado, pero he aquí por qué acabamos teniendo tantos:
Aislamiento por seguridad y estabilidad
Cada entorno (desarrollo, ensayo, producción) para servicios críticos tenía propio clúster Kubernetes dedicado.
¿Por qué no utilizar espacios de nombres? Inicialmente utilizamos clústeres para el aislamiento, creyendo que ofrecería una mejor tolerancia a fallos y seguridad. En retrospectiva, esto era innecesario y excesivamente complejo.
Estrategia multi-nube
No queríamos estar atados a un único proveedor de nube, así que distribuimos nuestros clústeres entre AWS, GCP y Azure. Esto añadió redundancia, pero también aumentó la complejidad.
Crecimiento del servicio
A medida que crecía el número de microservicios, cada servicio a menudo tenía su propio clúster dedicado. No consolidamos lo suficientemente pronto y creamos una situación en la que teníamos demasiados clústeres con recursos infrautilizados.
En resumen, las decisiones organizativas y un enfoque demasiado cauteloso del aislamiento de recursos condujeron a un número insostenible de clústeres.
¿Por qué 25.000 dólares por 47 grupos?
He aquí el desglose de cómo llegamos a 25.000 $/mes por 47 clusters:
Costes del plano de control
Estábamos utilizando servicios gestionados de Kubernetes (por ejemplo, AWS EKS, GKE, AKS).
Los servicios gestionados de Kubernetes suelen cobrar por la gestión del plano de control. El coste medio de la gestión del plano de control es de aproximadamente 500 dólares por clúster al mes (aproximadamente).
Para 47 clústeres, eso suma 23 500 $/mes (aproximadamente).
Planes de soporte empresarial en kubernetes
Utilizamos planes de soporte de nivel empresarial para cada proveedor de nube (AWS, GCP, Azure). Estos planes cuestan entre 1.000 y 1.500 dólares al mes por proveedor, en función del uso.
Esto añadió entre 2.000 y 3.000 dólares/mes adicionales al coste total.
Alta disponibilidad y redundancia
Para garantizar una alta disponibilidad y tolerancia a fallos, ejecutamos clústeres en varias zonas de disponibilidad e implementamos despliegues multirregión.
Esta redundancia incrementó los costes, ya que requería más instancias e infraestructura adicional.
En resumen, los 25.000 $/mes se debieron principalmente a los costes del plano de control (23.500 $ aprox.) y los planes de asistencia (1.500 - 2.000 $), junto con los gastos generales de las configuraciones de alta disponibilidad y la distribución en varias nubes.
¿Y la infraestructura y otros costes?
Más allá de los costes del plano de control, también nos enfrentamos a gastos operativos adicionales:
El 40% de los nodos ejecutaban componentes de Kubernetes: Esto significaba que casi la mitad de los recursos informáticos de cada clúster estaban dedicados a componentes de Kubernetes (como el kubelet, etcd y otros servicios del sistema).
Esta cifra era especialmente elevada dada la complejidad de gestionar 47 clústeres.
Alto coste informático: Estábamos ejecutando múltiples nodos maestros por clúster para redundancia, lo que aumentaba los costes de computación y requería más instancias para mantener el sistema.
En total, entre 92.000 y 100.000 dólares al mes era el coste medio de la infraestructura (incluyendo instancias, equilibradores de carga, redes, almacenamiento y costes del plano de control).
No utilizábamos eficazmente los recursos informáticos de muchos clústeres, lo que provocaba una infrautilización de la capacidad y un desaprovechamiento de los recursos.
La decisión de abandonar Kubernetes
La decisión de abandonar Kubernetes no se tomó a la ligera. Después de considerarlo detenidamente, nos dimos cuenta de que Kubernetes, aunque genial en teoría, añadía más complejidad de la que necesitábamos en ese momento.
He aquí un resumen de lo que nos impulsó a hacer el cambio:
Sobrecarga de gestión
Kubernetes requiere importantes recursos humanos para su mantenimiento. Nuestros ingenieros de DevOps dedicaban aproximadamente el 60% de su tiempo a gestionar los clústeres: parchear, escalar, solucionar problemas y garantizar una alta disponibilidad.
Esto no dejaba tiempo suficiente para el trabajo de desarrollo real o la innovación, y causó agotamiento, con 4 ingenieros abandonando en 12 meses debido al estrés.
Alta complejidad operativa
Gestionar más de 200 archivos YAML para despliegues básicos, manejar problemas de compatibilidad y luchar constantemente contra la fatiga de las alertas (con 147 falsos positivos) agotó a nuestro equipo. El mero volumen de complejidad parecía compensar los beneficios.
Coste frente a beneficio
El coste de 100.000 dólares al mes para 47 clústeres, junto con la complejidad de la infraestructura, no justificaba los beneficios que estábamos viendo de Kubernetes.
El cambio: Pasar a tecnologías más sencillas
Empezamos preguntándonos ¿Pueden unas herramientas más sencillas resolver nuestras necesidades?
Nivel 1: Auditoría y evaluación
Analizamos la utilización de recursos, los costes y el historial de incidencias.
Descubrimos que sólo el 20% de las funciones avanzadas de Kubernetes (como el escalado dinámico y las actualizaciones continuas) se utilizaban activamente.
Nivel 2: Elección de las herramientas adecuadas
Seleccionamos herramientas que se ajustaban a cargas de trabajo específicas:
- Servicios sin estado → Trasladados a AWS ECS/Fargate.
- Servicios con estado → Implementados en instancias EC2 con Docker, lo que reduce la necesidad de una orquestación compleja.
- Trabajos por lotes → Gestionados con AWS Batch.
- Flujos de trabajo basados en eventos → Cambiados a AWS Lambda.
Nivel 3: Migración gradual
Migramos los servicios de uno en uno, comenzando por los no críticos.
Los sistemas paralelos se ejecutaron temporalmente para garantizar la estabilidad durante las transiciones.
Resultados // Costes
- Planos de control: Eliminados 25.000 $/mes.
- Costes totales de infraestructura: Reducidos de 100 000 $/mes a 42 000 $/mes (una disminución del 58 %).
Costes de Kubernetes (antes):
- Planos de control: Los servicios gestionados de Kubernetes (como EKS) cuestan 500 $/cluster/mes. Para 47 clústeres, eso suponía 23.500 $/mes.
- Computación y almacenamiento: Ejecutar instancias EC2, almacenamiento y equilibradores de carga para 47 clústeres añadía 70.500 $/mes.
- Soporte empresarial: Estábamos pagando 3.000 $/mes en planes de soporte para Kubernetes.
- Costes totales de Kubernetes: 100 000 $/mes
Costes de AWS ECS/Fargate (después):
- ECS/Fargate: Con ECS y Fargate, pagamos solo por lo que utilizamos. El costo para esto es de alrededor de $30,000/mes (para igualar el total requerido).
Planes de soporte: Bajamos a 2.000 $/mes para el soporte de AWS, un coste razonable para el soporte a nivel empresarial.
- Redes y monitorización: Simplificamos el uso de las herramientas de AWS y redujimos la necesidad de soluciones de monitorización externas, ahorrando unos 10.000 $/mes.
- Costes totales de ECS/Fargate: 42.000 $/mes
- Ahorro: 58.000 $/mes (o una reducción del 58%).
Complejidad operativa
- Archivos de configuración: Reducción de más de 200 archivos YAML a 20 archivos de configuración.
- Herramientas de monitorización: Consolidado en AWS CloudWatch, reduciendo el ruido en un 70%.
- Tiempos de implementación: Mejorados de 15 minutos a 5 minutos de media.
Reducción de archivos YAML (de más de 200 a 20)
Antes:
Las implementaciones de Kubernetes requerían numerosos archivos YAML para diferentes aspectos del sistema: servicios, implementaciones, reglas de entrada, secretos, mapas de configuración, etc. Teníamos más de 200 archivos YAML para gestionar las configuraciones en todos los clústeres.
Después:
- Configuración simplificada: Cambiamos a ECS y Fargate, donde la mayor parte de la configuración se podía gestionar directamente a través de las herramientas de gestión de AWS, eliminando la necesidad de extensos archivos YAML.
- Configuraciones centralizadas: Adoptamos una gestión de configuraciones más sencilla utilizando AWS CloudFormation y ECS Task Definitions. En lugar de archivos YAML separados para cada despliegue, ahora podíamos gestionarlos a través de menos scripts y archivos de configuración centralizados, reduciendo la complejidad.
- Infraestructura como código: Utilizamos AWS CloudFormation para la administración de la infraestructura, que se integró a la perfección con ECS. Esto permitió un conjunto más pequeño de archivos de configuración (solo 20 archivos) para gestionar todos los aspectos de la configuración de la infraestructura y la aplicación.
Esta simplificación no sólo ahorró en el número de archivos YAML, sino que también redujo drásticamente la posibilidad de errores y malas configuraciones.
Impacto en el equipo
- Incidentes de guardia: Reducción del 75%.
- Bajas por agotamiento: Ninguna en los últimos seis meses.
- Frecuencia de despliegue: Aumentó un 40%, lo que permitió una entrega más rápida de funciones.
Otras preguntas y aclaraciones
P: ¿Por qué no utilizar espacios de nombres en lugar de tantas agrupaciones?
Respuesta: Fue un descuido de diseño. Al principio, creíamos que aislar las cargas de trabajo a nivel de clúster proporcionaría mayor seguridad y tolerancia a fallos. Subestimamos que los espacios de nombres podían lograr objetivos similares con una sobrecarga operativa mucho menor.
P: ¿Por qué no se consolidaron antes con un único proveedor de nube?
Respuesta: La multi-nube fue una decisión estratégica, pero no estaba justificada para nuestra escala. La consolidación en AWS durante la migración redujo drásticamente los costes y la complejidad.
P: ¿Por qué era tan cara la monitorización?
Respuesta: Nuestra pila de monitorización incluía cinco herramientas (por ejemplo, Prometheus, Grafana, DataDog) repartidas en varias nubes. Esta redundancia provocaba costes elevados y fatiga de alertas. La consolidación en AWS CloudWatch ahorró dinero y ancho de banda del equipo.
P: ¿Y ECS? ¿No es caro también?
Respuesta: ECS tiene sus costes, pero fueron significativamente más bajos para nuestra carga de trabajo después de optimizarla. Al cambiar a AWS Fargate para los servicios sin estado y a EC2 con Docker para las cargas de trabajo con estado, conseguimos una mayor rentabilidad.
P: ¿Realmente gastaba el 40% de los recursos informáticos en componentes de Kubernetes?
Respuesta: Sí. Esto incluía
Sobrecarga del plano de control
Contenedores Sidecar para registro, métricas y redes
Redundancia de alta disponibilidad, que requería nodos adicionales por clúster.
¿Debería utilizar Kubernetes?
Kubernetes es una herramienta potente, pero no es la más adecuada para todos los equipos. Considere su escala, el tamaño del equipo y la complejidad de la carga de trabajo antes de adoptarlo.
Puede que necesite Kubernetes si
- Estás gestionando cientos de microservicios.
- Necesita un escalado avanzado o redundancia en varias nubes.
- Su equipo tiene la experiencia y el ancho de banda necesarios para gestionarlo eficazmente.
Puede que no necesite Kubernetes si:
- Tienes menos de 20 servicios o cargas de trabajo predecibles.
- Los servicios gestionados (como ECS, Lambda o Fargate) satisfacen sus necesidades.
- Su equipo es pequeño y prefiere la simplicidad a la flexibilidad.
- Al elegir la tecnología, es esencial evaluar el panorama completo: costes, complejidad e impacto en el equipo. Kubernetes es potente, pero también es caro y complejo.
Para muchos equipos más pequeños o equipos con necesidades predecibles y sencillas, soluciones más simples como ECS, Lambda y EC2 pueden proporcionar beneficios sustanciales sin la sobrecarga.
En última instancia, nuestro cambio de Kubernetes no fue un fracaso de la tecnología, sino una elección para adaptar nuestra arquitectura a nuestras necesidades específicas.