Data4Sales

Data4Sales es una plataforma de marketing inteligente: ayuda a tiendas de e-commerce a fidelizar a sus clientes y a crear campañas específicas. Corre en AWS, y su infraestructura fue creciendo al ritmo que pedía el producto.

Ese crecimiento tenía un costo que no se veía a simple vista. Todo se había creado a mano. No había un ambiente de prueba separado de producción, así que cada cambio llegaba a la operación real sin haber pasado antes por ningún otro lugar. Los deploys no estaban automatizados, no había alarmas configuradas y los problemas se detectaban tarde. El gasto en la nube era difícil de anticipar.

El equipo sabía que tenía que intervenir. Lo que le faltaba era un mapa: qué problemas había, cuáles eran críticos y por dónde empezar. Por eso el primer paso no fue construir. Fue diagnosticar.

El assessment cubrió seis frentes: infraestructura cloud, CI/CD, seguridad, observabilidad, costos y modelo operativo. Revisamos la cuenta de AWS, los repositorios, los pipelines, los permisos, las métricas y la facturación, y entrevistamos a los responsables técnicos.

Clasificamos cada hallazgo por severidad y según los pilares de AWS Well-Architected, el marco de buenas prácticas que propone AWS. Con eso armamos una línea de base de madurez, para poder medir el avance, y un plan de remediación concreto.

Las bases de datos, primero. Migramos el clúster principal de MySQL 5.7 a 8.0 con un despliegue blue/green: la versión nueva se levanta en paralelo y el tráfico pasa recién cuando está lista. Antes, el equipo de Data4Sales validó su aplicación sobre una copia. La base PostgreSQL, que corría en un servidor sin gestión, pasó a RDS y de la versión 13 a la 17. Las bases de producción quedaron accesibles solo desde la red privada.

Una infraestructura escrita en código. Diseñamos una red segmentada y creamos el repositorio de infraestructura en Terraform y Terragrunt, con módulos de red, Kubernetes, permisos y registros de imágenes. Que la infraestructura viva en código significa que se puede revisar, repetir y extender, en lugar de depender de lo que alguien configuró a mano. Sobre esa base levantamos un clúster EKS de staging y migramos el DNS a Route 53.

El giro: Support pasó al frente. A mitad del proyecto, la prioridad pasó a ser Support, un producto nuevo de Data4Sales. Le construimos desde código staging y producción, y un flujo de CI/CD con ambientes temporales por pull request: cada cambio se puede probar aislado antes de integrarse. Después llevamos el mismo esquema a la plataforma principal.

Deploys sin cortes. Ampliamos la capacidad antes de las fechas de alto tráfico y la devolvimos después. Pasamos los deploys a un túnel propio por ejecución con AWS Systems Manager, así varios pueden correr a la vez sin bloquearse entre sí. Con ese cambio eliminamos la ventana sin servicio que dejaban los deploys de Support.

Data4Sales pasó de no tener ambientes de prueba a tener un staging separado de producción. Sus equipos prueban cada cambio en un ambiente propio antes de integrarlo, y la infraestructura nueva se define en código.

Los deploys corren desde el CI, varios servicios se despliegan a la vez sin bloquearse y las bases de producción usan versiones soportadas, accesibles solo desde la red privada.

Lo que sigue. El trabajo continúa. La próxima etapa es llevar la producción de la plataforma principal al mismo esquema.