Aprende a gestionar +100 Pipelines en AWS con CDK

Descubre cómo transformar la gestión de infraestructura escalando a más de 100 pipelines en AWS mediante CDK, «constructs» reutilizables y una cultura DevOps real.

El rol actual de las Bases de datos

Gestionar la infraestructura en la nube puede convertirse rápidamente en una pesadilla si no se escala adecuadamente. «¿Cómo gestionamos más de 100 pipelines sin volvernos locos? Porque al final lo que queremos es dormir bien por las noches y que no falle nada», planteó Rubén J. García, Cloud Architect y AWS Community Builder, al inicio de su ponencia en el pasado SpainClouds Summit.

Con más de 20 años de experiencia en desarrollo y una década trabajando con AWS, García compartió la estrategia técnica y cultural que permitió a su equipo pasar de un cuello de botella operativo a una arquitectura escalable y autónoma.

El "Infierno" de las Versiones y los Cuellos de Botella

Antes de alcanzar la eficiencia, el equipo se enfrentaba a un escenario común en muchas empresas tecnológicas. La infraestructura estaba gestionada con Terraform, pero sufrían inconsistencias graves: diferentes proyectos usaban distintas versiones de código, lo que hacía que actualizar cualquier pipeline fuera costoso y arriesgado. Existía un miedo real a ejecutar cambios por la incertidumbre de sus efectos.

El problema más crítico era la alta dependencia del equipo de infraestructura. Cualquier cambio o nueva funcionalidad requerida por los desarrolladores debía pasar por este equipo, convirtiéndolo en un cuello de botella.

«En una empresa pequeña, esto nos hacía muchas veces no dar el servicio que queríamos a nuestros propios desarrolladores», explicó García. Además, se enfrentaban a una curva de aprendizaje elevada y plantillas legacy difíciles de evolucionar.

La Solución Técnica: Migración a AWS CDK y "Constructs"

Para solucionar esto, el equipo decidió apostar por AWS CDK (Cloud Development Kit). Dado que su entorno era 100% AWS, CDK ofrecía ventajas claras frente a Terraform, como la compilación directa a CloudFormation, herramientas de hot swap y la capacidad de probar infraestructura en local.

La estrategia se basó en tres pilares técnicos:

Constructs Reutilizables (Piezas de LEGO)

La clave del éxito fue la creación de constructs propios. En lugar de reescribir código para cada microservicio, el equipo de infraestructura creó módulos estandarizados que funcionaban como piezas de LEGO. «Si un servicio necesitaba una base de datos, una API Gateway y un Event Bus, simplemente poníamos las piezas y CDK generaba todo por debajo», detalló Rubén. Esto permitía una escalabilidad brutal: escribían el código una vez y lo reutilizaban más de 100 veces.

Configuración por Entornos

Para manejar los despliegues en desarrollo, staging y producción, parametrizaron todo mediante archivos de configuración (JSON). El código base del pipeline era el mismo, pero un archivo específico indicaba las variables de cada entorno (nombres de tablas, capacidad de memoria, número de nodos, etc.).

Pipelines Inteligentes

Implementaron una lógica de despliegue donde cada microservicio definía su propio pipeline. Además, optimizaron los tiempos: si solo se modificaba el código fuente del frontend, el pipeline solo actualizaba los archivos en S3 e invalidaba la caché de CloudFront, sin reconstruir toda la infraestructura, ahorrando tiempo valioso.

DevOps Real y Accountability

Rubén J. García enfatizó que la tecnología por sí sola no basta; es necesario un cambio de mentalidad. «DevOps es una cultura de empresa, no un puesto de trabajo», afirmó contundentemente.

El objetivo era empoderar a los desarrolladores. Gracias a los constructs estandarizados, cada desarrollador podía generar su propio pipeline sin necesidad de ser un experto en infraestructura. Esto fomentó el Accountability (responsabilidad): el desarrollador no solo es responsable de que su código funcione en local, sino de que llegue a producción y funcione en la nube.

Esto no significa caos. «La autonomía no es caos, es eficiencia», señaló Rubén. Al eliminar la necesidad de pasar la pelota entre equipos para tareas rutinarias, se ganó velocidad y autonomía.

Seguridad y Gobernanza Invisible

Una de las grandes dudas al dar autonomía a los desarrolladores es la seguridad. ¿Cómo evitar que un desarrollador exponga datos sensibles? La respuesta de García fue integrar la seguridad dentro de los constructs.

Las buenas prácticas estaban pre-configuradas:

Los buckets de S3 se creaban encriptados por defecto y bloqueaban el acceso público.
Las colas SQS ya incluían gestión de claves KMS y Dead Letter Queues.
Los servicios incluían alarmas y monitorización automática.

«Les dábamos un martillo que no pinchaba», ilustró Rubén. Los desarrolladores tenían libertad para construir, pero dentro de unos raíles de seguridad definidos por el equipo de arquitectura.

Recibe nuestra Newsletter de Cloud semanal

Evolución del Equipo de Infraestructura

El impacto de esta transformación fue radical. El equipo de infraestructura logró reducir drásticamente la carga de tickets operativos.

Si antes dedicaban el 80% de su tiempo a apagar fuegos y gestionar despliegues, ahora podían dedicar ese tiempo a lo que realmente aporta valor: seguridad, observabilidad y evolución de la plataforma. Esto permitió al equipo innovar, integrando nuevas herramientas e incluso Inteligencia Artificial, en lugar de estar atados a tareas repetitivas.

Al adoptar AWS CDK y una cultura de responsabilidad compartida, las empresas pueden lograr que sus equipos de desarrollo sean más felices y eficientes, eliminando fricciones y permitiendo que la innovación fluya.

SmartClouds

SmartClouds helps businesses get in front of the right technical audience. We are experts in content creation and community management. We’ll help you showcase your products and the problems you solve.