De on-premise a AWS: modernización de una arquitectura de bases de datos heterogénea

La modernización de las arquitecturas de datos rara vez es un proceso lineal. En la mayoría de los casos, no se trata de reemplazar un sistema por otro mediante un “big bang”, sino de evolucionar un ecosistema existente bajo restricciones reales: sistemas legados, múltiples proveedores, motores de bases de datos heterogéneos y decisiones técnicas acumuladas durante años.

Este artículo describe la evolución de una arquitectura on-premise — basada principalmente en Oracle — hacia una arquitectura híbrida en AWS.

Más que una migración tecnológica, este proceso representó un cambio de paradigma: pasar de un modelo centralizado de datos a un ecosistema distribuido, gobernado por la integración y los servicios administrados.

Arquitectura inicial: un sistema centralizado con extensiones

El entorno original estaba fuertemente dominado por una arquitectura on-premise centrada en Oracle, distribuida de la siguiente manera:

• Oracle Database 11g R2: motor principal que alojaba aproximadamente el 98% de los datos
• MySQL 7: base de datos secundaria con el 2% restante
• Mecanismos de integración: Oracle Database Links, Heterogeneous Services (HS), ODBC y persistencia adicional en archivos de disco
• Aplicaciones legacy: Oracle Forms 6i y Java Swing
• Sistemas de terceros: un sistema externo de fidelización desarrollado en PHP (Laravel) con MySQL

Este modelo reflejaba un patrón común en sistemas empresariales maduros: un núcleo fuerte y centralizado con extensiones puntuales para resolver necesidades específicas.

Sin embargo, esta centralización generaba una fuerte inercia arquitectónica: todo nuevo requerimiento tendía a resolverse en el mismo ecosistema, lo que sobrecargaba Oracle.

El problema no era la tecnología, era la evolución

Con el tiempo, el sistema comenzó a mostrar síntomas típicos de arquitecturas altamente centralizadas:

• Integraciones cada vez más frágiles y complejas entre motores heterogéneos
• Uso intensivo y riesgoso de mecanismos síncronos como DB Links
• Dificultad para escalar nuevos módulos con tecnologías distintas
• Dependencia crítica de un único motor como punto único de consolidación (y posible punto de falla)
• Limitaciones para modernizar aplicaciones legacy sin impactar el núcleo del negocio

En este punto, el desafío dejó de ser técnico y pasó a ser arquitectónico:

¿Cómo evolucionar un sistema sin romperlo cuando toda la operación depende de un único centro de datos?

La respuesta no era simplificar, sino redistribuir.

Decisión de arquitectura: coexistencia en lugar de consolidación

Uno de los errores más comunes en procesos de modernización es asumir que la solución óptima es consolidar todo en un único motor o plataforma.

En este caso, la estrategia fue distinta: aceptar la heterogeneidad como una condición permanente y gestionarla de forma explícita.

Esto llevó a un modelo donde múltiples motores coexisten según sus fortalezas:

• Oracle: cargas transaccionales críticas existentes
• PostgreSQL: nuevas capacidades y microservicios
• MySQL: sistemas legados y de terceros

Esta decisión fue estratégica. En sistemas reales a escala empresarial, la estandarización absoluta rara vez es viable sin un costo y riesgo de transformación excesivos.

Evolución hacia AWS: arquitectura híbrida y distribuida

La migración hacia AWS no fue un evento único, sino un proceso incremental y controlado. La arquitectura resultante mantuvo la continuidad operacional mientras introducía capacidades modernas de nube:

• Amazon RDS for Oracle: ~80% de los datos
• Amazon RDS for PostgreSQL: ~14%
• Amazon RDS for MySQL: ~3%
• PostgreSQL en Amazon EC2: ~3%

Sin embargo, el cambio más importante no fue el traslado de bases de datos (lift & shift), sino la introducción de una capa de desacoplamiento entre sistemas.

Integración de datos: del acoplamiento síncrono al modelo asíncrono

En la arquitectura on-premise, la comunicación dependía de mecanismos fuertemente acoplados (DB Links, ODBC y consultas cruzadas directas).

Aunque funcional, este modelo generaba dependencia directa entre sistemas, limitando la escalabilidad y el mantenimiento.

En AWS, la integración evolucionó hacia un modelo desacoplado basado en servicios:

• AWS Database Migration Service (DMS): replicación continua y sincronización de datos
• AWS Lambda: capa de integración ligera y orquestación
• Flujos asíncronos entre motores heterogéneos

Este cambio definió una frontera clara entre sistemas productores y consumidores de datos, reduciendo significativamente el “blast radius” ante cambios o fallos.

AWS DMS como acelerador de migración

AWS DMS fue un habilitador clave en la estrategia de modernización.

Su implementación permitió:

• Replicación continua entre on-premise y AWS
• Migraciones progresivas sin interrupción de servicios críticos
• Coexistencia de ambos entornos durante la transición
• Reducción del riesgo asociado a migraciones tipo “big bang”

AWS Lambda como capa de integración

AWS Lambda actuó como un componente estratégico de integración.

Se utilizó para:

• Ejecutar consultas entre bases de datos heterogéneas
• Realizar transformaciones ligeras de datos en tránsito
• Orquestar flujos en tiempo casi real

Esto eliminó dependencias punto a punto y redujo el acoplamiento entre sistemas.

EC2 vs RDS: control vs operación administrada

Durante la evolución fue necesario equilibrar control técnico y carga operativa.

AWS Glue: evolución de la integración de datos

Con el crecimiento de fuentes de datos, AWS Glue se incorporó como herramienta de procesamiento ETL.

Su rol incluyó:

• Transformación de datos entre sistemas heterogéneos
• Normalización para consumo downstream
• Automatización de pipelines de datos

Esto permitió evolucionar hacia flujos de datos estructurados, auditables y gobernados.

Impacto arquitectónico y lecciones aprendidas

La evolución hacia AWS generó cambios significativos:

• Reducción de carga operativa mediante servicios administrados
• Mayor flexibilidad tecnológica
• Desacoplamiento de sistemas previamente rígidos

Sin embargo, también introdujo nuevos desafíos:

• Mayor complejidad de gobernanza
• Necesidad de observabilidad distribuida
• Gestión de múltiples motores y proveedores

Lecciones clave:

• La homogeneidad tecnológica rara vez es viable en sistemas reales
• La evolución progresiva reduce riesgos frente a migraciones disruptivas
• La integración asíncrona es esencial en arquitecturas distribuidas
• El rol del arquitecto evoluciona hacia la orquestación de sistemas

Conclusión

La modernización de una arquitectura de bases de datos no es únicamente una transformación tecnológica, sino una evolución del modelo de pensamiento arquitectónico.

Pasar de un entorno on-premise centralizado a una arquitectura híbrida en AWS implicó redefinir cómo se conectan los sistemas, cómo fluyen los datos y cómo se toman las decisiones de diseño.

En la nube moderna, el valor del arquitecto no radica en elegir la mejor tecnología individual, sino en diseñar ecosistemas resilientes donde múltiples componentes puedan coexistir, evolucionar y escalar de forma coherente.