Después de varias iteraciones en nuestros pipelines llegamos a un punto en el que todo está funcionando sin problemas y la mayoría de las nuevas mejoras están relacionadas con la optimización, como reducir 1 minuto por paso al reducir los tamaños de las imágenes Docker o algo más que pueda considerarse una mejora real para nuestro flujo.

Como somos un Super Equipo Internacional, algunos de los miembros del equipo comienzan a trabajar antes que otros, esto no es un problema para nosotros, ya que estamos más enfocados en el valor que agregamos al negocio que en contar cuánto tiempo pasamos sentados frente a la computadora. El otro día, durante nuestra reunión diaria, estaba escuchando una conversación sobre quién era responsable de desplegar los feature environments - Estos entornos se eliminan todos los días para evitar costos inesperados - y parece que les estaba costando decidir quién necesitaba desplegar el entorno cada mañana, para resumir la historia, llegaron a un acuerdo y lo hicieron funcionar.

Una de las primeras implementaciones de infraestructura que hice fue migrar la app principal de 3 servidores EC2 a ECS Fargate. Este fue el resultado de una conversación que tuve con el CTO cuando propuse ayudar con algunas tareas de DevOps.

Hubo varias razones que me impulsaron a comprometerme con esto. Primero, cuando comencé a trabajar para la compañía tuve acceso a AWS y descubrí que nuestros servidores estaban sobredimensionados y estábamos pagando demasiado por ellos. El uso de CPU del servidor principal estaba por debajo del 5%, este se encargaba de ejecutar un montón de trabajos cron, y los otros 2 servidores estaban por debajo del 2% en uso de CPU. La memoria RAM no era diferente.

Empezar a usar plantillas IaC fue una mejora en nuestras operaciones, ya que cuando queriamos desplegar un nuevo ambiente, simplemente copiamos una plantilla similar y haceiamos algunos pequeños cambios para adaptarla a la nueva infraestructura. Pronto descubrimos un problema con este patrón, estábamos creando balanceadores de carga de aplicación para cada nuevo servicio desplegado.

No eran taaaantos, algo así como 9 servicios tal vez, pero el problema es que también implementamos ambientes para fines de prueba, en nuestro caso Desarrollo y QA además de Producción, y son una réplica exacta, obviamente con menor capacidad, pero cuando hablamos de los ALBs, estos tienen un costo base de alrededor de 19$ por tenerlos corriendo y un costo variable que depende del uso llamado LCU. En la siguiente tabla podemos ver los costos totales asociados:

Antes de que empezara a hacer cambios en la infraestructura, la regla era simplemente subir un nivel en el tamaño del servidor, cada vez que había un pico y se confirmaba que la base de datos era la causa, se aumentaba el tamaño del servidor y en algún momento teníamos una sola instancia 8xlarge para nuestra base de datos principal.

En el pasado no se había implementado ningún sistema de logging y las acciones se basaban únicamente en el uso de recursos. Empezamos a tener una mejor visibilidad de nuestros servicios después de implementar Datadog en AWS, establecimos alertas para el uso de recursos y también habilitamos los logs de la base de datos, incluyendo los slow queries logs.

Podrías estar pensando, ¿Quién despliega una base de datos en una subnet pública? Aún peor, fue desplegada en la VPC pública default de AWS con el acceso público habilitado, esto es lo que pasa cuando los servicios son desplegados solo porque sí, sin pensar en la implementación, sino solo en los requerimientos del negocio.

Al principio fue un poco complejo simplemente cambiar el acceso público a deshabilitado, ya que había algunas herramientas externas de análisis de datos que estaban extrayendo información de la base de datos cada pocas horas, la primera vez que lo intenté, terminé en una llamada con el CTO y el equipo de Análisis de Datos preguntándome por qué deshabilité el acceso público. Respuesta simple - Seguridad.