¿Cómo hacer cambios en una Infraestructura sin romper nada? Más adelante responderemos esa pregunta detalladamente. Pero primero, comencemos hablando de a qué nos referimos con breaking changes: es el proceso para llevar a cabo cambios en miles de recursos relacionados con la infraestructura como aplicaciones, bases de datos, queues, entre otros, tratando de minimizar el impacto indeseado.
En Pomelo, nuestro objetivo es siempre mantener la calidad de nuestros servicios y mitigar cualquier inconveniente que pueda llegar mientras están productivos. Por eso, los cambios en nuestra infraestructura se llevan adelante con un proceso definido que les contaremos a continuación.
¡Comencemos con un poco de contexto!
¿Por qué es importante coordinar todos los breaking changes en la infraestructura?
Como toda empresa, constantemente nos encontramos desarrollando cambios (fixes, features, hotfixes, etc.) a través de diferentes ambientes y entre varios equipos en simultáneo, como los de desarrollo e infraestructura. Esto puede generar distorsiones que afecten involuntariamente las aplicaciones.
Esta situación lleva a que, de alguna manera, todos tengamos que estar al tanto de qué, cuándo, cómo y por qué está sucediendo algo, ya sea en las aplicaciones donde trabajamos día a día, como en las que no.
Frente a esta situación, ¿cómo podemos hacer en Pomelo para mantener uno de nuestros principios culturales, el de Velocidad (y calidad) Pomelo, y coordinar estas tareas de la mejor manera? ¡Vamos a descubrirlo!
¿Cómo es la infraestructura de Pomelo?
La infraestructura de Pomelo está principalmente dividida en 3 grandes partes:
- Infra Dinámica;
- Infra Estática;
- e Infra Aplicativa.
Tanto para la Infra Dinámica como para la Infra Estática, primero debemos entender el concepto de IaC, la infraestructura como código. ¿Te preguntas qué es eso? Bueno, RedHat lo define de la siguiente manera: “La infraestructura como código (o Infrastructure as Code, de allí su sigla IaC) permite gestionar y preparar la infraestructura a través del código, en lugar de hacerlo mediante procesos manuales”.
Ahora, les contamos más detalles sobre cada una de las partes de nuestra infraestructura:
-
Infra Dinámica
Como comentamos en artículos anteriores, en Pomelo creamos Rocket, nuestro IDP. Desde esta herramienta, se pueden crear productos que nuestra aplicación necesite, como queues y clusters de rds, entre otros ejemplos. Éstos son creados a través de diferentes herramientas como CloudFormation, permitiéndonos cumplir con los estándares definidos previamente.
-
Infra Estática
En la infra estática, donde actualmente gestionamos la infra donde está Rocket, lo hacemos un poco diferente. Para esto, utilizamos Terraform, similar a CloudFormation, que nos permite crear Infra como código.
-
Infra Aplicativa
A su vez, más allá de los recursos que pueda tener una aplicación, requiere su propia infraestructura (ej.: un microservicio). Para ello, como nosotros trabajamos con Kubernetes, necesitamos que cada vez que se manipule un microservicio tenga todo lo necesario para levantarse correctamente en el cluster correspondiente.
¿Cómo planeamos los cambios minimizando el impacto indeseado?
Cabe destacar que con un gran equipo que siempre busca la velocidad, es muy importante no perder calidad en el proceso. Y, por sobre todo, que pueda seguir manteniendo esa velocidad que caracteriza a Pomelo.
Para ello, lo primero que definimos fue una Política de Cambios, la cual entendemos como un contrato donde se determina qué, cómo, cuándo y por qué un cambio debe seguir el flujo. De igual manera, esta política deja constancia de quién o quiénes son los responsables de aprobar cada uno de ellos.
Esta organización nos permite llevar a cabo los breaking changes contemplando que, a la hora de implementarlos en cualquier ambiente que la política disponga, cumpla con los siguientes cuatro pilares:
- sea aprobado por el o los responsables;
- sea debidamente comunicado a los involucrados;
- que esté disponible en un calendario de cambios;
- que quede auditado.
Por último, debemos mencionar que todo esto no solo es importante para mantener un orden y hacer cambios sin romper nada. En Pomelo, también nos da las herramientas para poder cumplir con las auditorías correspondientes, ya que contamos con la certificación PCI-DSS 4.0.
Por lo tanto, cada cambio debe quedar debidamente registrado, pudiendo acceder fácilmente a qué, cómo, cuándo y por qué fue realizado, así como quién o quiénes lo aprobaron.
Para lograrlo, diseñamos el siguiente diagrama (representativo):
Manos a la obra
Teniendo el contexto y lo que queremos hacer, nos queda contar el cómo.
Aquí teníamos otro gran desafío interesante: ¿cómo podíamos desarrollar una herramienta que agregase pasos adicionales al proceso actual de implementación, reduciendo al mínimo la fricción que esta pudiese generar?
Así fue que diseñamos una aplicación que dispone de dos tipos de inputs principales: a través del frontend de Rocket y desde el pipeline que utilizamos en Github. Esto facilita y reduce tiempos en la creación de la Approval (entidad que tiene toda la información necesaria), para luego seguir todo el manejo de aprobación a través de ella.
La arquitectura y sus componentes, entre otros detalles, está compuesto por:
- una AWS RDS PostgreSQL;
- un AWS S3 Bucket con la propiedad Object Lock;
- el uso de Slack para la comunicación;
- y Google Calendar, con un calendario específico con cada uno de los cambios visibles, para que todos puedan disponerlo en la vista de su calendario personal.
Conclusiones
Haciendo una recapitulación, pudimos entender bien cómo estábamos al principio y cuáles eran nuestras necesidades. Desarrollamos una Política de Cambios a modo de contrato, pudiendo definir el scope completo para cada uno. Asimismo, implementamos una aplicación que nos permite cumplir con esta política, reducir la fricción, automatizar los procesos, ahorrar tiempo y llevar al siguiente nivel el desarrollo seguro dentro de nuestra infraestructura.
De esta forma, pudimos generar la auditoría necesaria para poder cumplir con las certificaciones y con la normativa de cada una de ellas, haciéndolo parte del flujo de desarrollo de Pomelo. Por lo tanto, utilizando este proceso podemos llevar a cabo breaking changes contando con una o más revisiones, con su apropiada comunicación, calendarización y auditoría.