Nuestro camino en la gestión de microservicios

En 2017, fintech.works tuvo la posibilidad de empezar a trabajar en un proyecto nuevo con total libertad para definir la arquitectura por lo cual apostamos a una arquitectura de microservicios. Comenzamos con un pequeño conjunto de cinco microservicios en Docker Swarm, lo cual fue suficiente para nuestro entorno de desarrollo.

Sin embargo, nuestras proyecciones de funcionalidades a mediano plazo indicaban que pronto duplicaríamos ese número y que necesitaríamos una solución robusta para producción en un entorno empresarial y que a su vez pueda ser replicado en otros clientes. Así fue como empezamos a explorar Kubernetes.

Por qué elegimos Kubernetes (y Rancher)

Elegir Kubernetes no fue una decisión difícil. Desde el principio sabíamos que sería una herramienta clave para nuestro crecimiento, gracias a su capacidad para gestionar clusters a gran escala, automatizar despliegues y manejar actualizaciones de aplicaciones y en aquella época Docker Swarm empezó a mostrar señales de que sería deprecado.

Tras decidirnos por Kubernetes, evaluamos varias distribuciones. Rancher fue nuestra elección final, que se destacó por:

1. Facilidad de instalación: incluso para equipos con cero experiencia en kubernetes.
2. Opciones de soporte: ideales para un entorno que planeábamos escalar y mantener por mucho tiempo.
3. Versatilidad administrativa: Rancher ofrecía una potente CLI combinada con una interfaz web intuitiva para facilitar la gestión a administradores menos técnicos.

Desde entonces, Rancher sigue siendo nuestro pilar en el ambiente de desarrollo. A pesar de algunos inconvenientes menores, como certificados expirados o reinicios ocasionales de CoreDNS, la experiencia general ha sido positiva.

Los desafíos de Kubernetes

Cuando llegó el momento de llevar Kubernetes a producción, nos encontramos con estos problemas:

1. Mantenimiento complicado: Mantener el cluster actualizado requería, en muchos casos, reconstruirlo desde cero.
2. Escalabilidad horizontal: Aunque teóricamente Kubernetes facilita la escalabilidad, automatizarla de forma confiable fue un desafío. Nuestros scripts personalizados pronto se convirtieron en “legacy”.
3. Cargas altas esporádicas: Necesitamos configurar clusters sobredimensionados para evitar cuellos de botella, lo cual incrementó los costos.
4. Ecosistema complejo: Kubernetes es un “ecosistema de ecosistemas”, lo que significa que cualquier configuración, por básica que sea, tiene múltiples enfoques posibles.

Aunque estos problemas no eran showstoppers, implicaron una carga operativa significativa, reduciendo el tiempo disponible para abordar otras prioridades estratégicas. Esto nos llevó a explorar alternativas más sencillas, como Amazon ECS (Elastic Container Service).

Por qué exploramos ECS

Ninguna de nuestras necesidades dependía exclusivamente de funcionalidades que Kubernetes ofrecía pero que ECS no pudiera manejar. Además, la simplicidad de un modelo SaaS eliminaba muchas de nuestras preocupaciones operativas.

ECS con Fargate fue implementado inicialmente en un proyecto más pequeño, y los resultados fueron evidentes desde el primer momento:

1. Infraestructura simplificada: No más preocupaciones por administrar control planes, nodos etcd o CoreDNS.
2. Cluster management eliminado: No había necesidad de ajustar el tamaño del cluster ni realizar configuraciones personalizadas en load balancers.

Los desafíos de ECS

No todo fue perfecto. Al adaptarnos a ECS, enfrentamos algunas limitaciones:

1. Falta de integración con ArgoCD: Esto complicó nuestro enfoque de GitOps.

2. Task-definitions en lugar de YAMLs: ECS utiliza task-definitions, un formato diferente que requirió aprender otra forma de gestionar microservicios.

3. Curva de aprendizaje adicional: Cambiar entre paradigmas operativos siempre toma tiempo.

El valor de ECS como alternativa

Aunque ECS no está exento de problemas, se convirtió en una alternativa estratégica en nuestra infraestructura. Es especialmente útil para:

• Proyectos más pequeños: Donde la simplicidad es clave.

• Aplicaciones legacy: Que están migrando hacia microservicios y no necesitan toda la complejidad de Kubernetes.

Conclusión

Nuestro viaje de orquestadores que empezó con Docker Swarm, pasando por Rancher y Kubernetes, hasta Amazon ECS nos enseñó que no existe una solución única que sea lo suficientemente versátil para cumplir todas nuestras necesidades. Kubernetes sigue siendo una herramienta poderosa para proyectos grandes y exigentes, pero ECS nos demostró que la simplicidad operativa puede ser un diferenciador clave en proyectos más pequeños o específicos.

Nuestro consejo para equipos en situaciones similares:

1. Evalúen cuidadosamente sus necesidades.
2. No teman explorar alternativas.
3. Equilibren la potencia de las herramientas con la simplicidad operativa.