Ingeniería de Plataforma Cloud y DevOps | AWS, Kubernetes, Terraform

Señales de que la plataforma es el cuello de botella

Los despliegues se hacen los martes a la tarde, porque es cuando está disponible la persona que sabe.
La infraestructura se armó a mano en una consola y nadie puede reconstruirla.
Staging y producción difieren en formas que solo se descubren durante un incidente.
La factura de AWS crece todos los meses y nadie puede atribuirla a nada.
Todo corre con permisos de administrador porque la única vez que se intentó acotarlos algo se rompió.
Volver atrás significa desplegar el commit anterior y confiar en que la migración era reversible.

Qué construimos

Infraestructura como código

Terraform para toda la infraestructura, con estado remoto, módulos que se reutilizan en vez de copiarse, y planes revisados antes de aplicarse.

Kubernetes aburrido

EKS o equivalentes gestionados, con recursos declarados con criterio, autoescalado que refleja la carga real, chequeos de salud que significan algo, y despliegues que se pueden revertir.

Pipelines que despliegan solos

GitHub Actions del commit a producción: construir, probar, escanear, desplegar, con promoción entre entornos y una vuelta atrás que fue probada y no simplemente supuesta.

Permisos a propósito

IAM de mínimo privilegio, cuentas de servicio acotadas, gestión de secretos, y credenciales de CI que no pueden hacer más de lo que el trabajo requiere.

Costo atribuible

Etiquetado, dimensionamiento correcto, instancias spot donde encajan, y visibilidad de costo por servicio, para que bajar el gasto sea una decisión de ingeniería y no un apuro trimestral.

Proyectos típicos

Poner bajo Terraform una infraestructura hecha a mano

Importar lo que existe, describirlo como código, y llegar al punto en que el entorno se puede reconstruir desde el repositorio.

Construir un pipeline de despliegue desde cero

Del commit a producción sin pasos manuales, con pruebas y escaneos como compuertas y una vuelta atrás que alguien efectivamente ensayó.

Migrar servicios a Kubernetes

Contenerizar, definir recursos y sondas, configurar autoescalado, y mover el tráfico de a poco en lugar de todo junto.

Bajar el gasto en la nube sin romper nada

Encontrar lo sobredimensionado, lo ocioso y lo duplicado, y cambiarlo en un orden donde cada paso sea reversible por separado.

Separar los entornos como corresponde

Un staging que se parezca a producción lo suficiente como para valer la pena, con un manejo de datos que no deje registros de clientes en una base de pruebas.

Qué se lleva

Un repositorio de Terraform que describe su infraestructura, revisado y aplicado desde CI
Pipelines funcionando, con promoción y vuelta atrás documentadas
Un modelo de permisos escrito, incluyendo qué puede y qué no puede hacer cada rol
Runbooks para las operaciones que su equipo hace habitualmente
Una línea base de costos y las palancas que la mueven

Preguntas que nos hacen

¿Necesitamos Kubernetes?

Muchas veces no. Kubernetes se gana su complejidad cuando se corren muchos servicios, hace falta escalado fino, y ya existe la madurez operativa para sostenerlo. Para un puñado de servicios, las plataformas de contenedores gestionadas son más baratas de operar y muchísimo más baratas de entender. Preferimos decirlo antes que venderle un cluster.

¿Pueden trabajar con nuestra infraestructura actual?

Sí. La mayor parte de este trabajo es mejorar algo que ya funciona y no puede dejar de funcionar. Empezamos describiendo lo que existe, y después lo cambiamos en pasos reversibles.

¿Y si el conocimiento de la infraestructura está en la cabeza de una sola persona?

Esa es una de las mejores razones para llamarnos. Escribirlo como código elimina el punto único de falla, y el proceso suele sacar a la luz varias suposiciones que nunca fueron ciertas.

Infraestructura que su equipo puede cambiar sin contener la respiración