El contexto
Banco Ripley operaba 25 WebServices críticos sobre IBM WebSphere Application Server (WAS) con Java 1.6. Una plataforma que ya estaba fuera de soporte, con vulnerabilidades de seguridad conocidas y que limitaba severamente la capacidad de escalar y modernizar la infraestructura del banco.
El proyecto fue contratado a través de Creasys, con Focus Consulting como ejecutor técnico. El objetivo era claro pero ambicioso: migrar los 25 WS a Google Cloud Platform (GCP) con Java 1.8, incluyendo aquellos que no formaban parte de las mejoras TEF (Transferencia Electrónica de Fondos), que requerían configuración específica para su despliegue en el nuevo entorno cloud.
El desafío
Migrar WebServices de un application server tradicional (WAS) a cloud no es un simple cambio de JDK. Implica:
- Desacoplar dependencias de WAS: Los WS estaban atados a features propietarias de WebSphere (JNDI, pooling de conexiones, security realms) que no existen en GCP
- Compatibilidad de versiones: Pasar de Java 1.6 a 1.8 implica cambios en APIs deprecated, bytecode y comportamiento del garbage collector
- Configuración de despliegue en GCP: Ajustar cada WS para ejecutarse en el entorno cloud sin WAS de por medio — usando contenedores o VMs según correspondiera
- Mínimo impacto en operación: Los WS daban servicio a procesos productivos del banco. Cada migración debía coordinarse con las ventanas de mantenimiento y sin afectar la continuidad del negocio
El detalle fino: Los WS que no eran parte de las mejoras TEF requerían configuración manual específica para ser desplegados en GCP. No eran servicios homogéneos — cada uno tenía su propia idiosincrasia de configuración en WAS que había que reinterpretar en el nuevo entorno.
Cómo lo hicimos
Fase 1 — Levantamiento y caracterización
Primero, inventario completo: analizamos los 25 WS, identificando dependencias de WAS, librerías privadas, configuraciones JNDI, roles de seguridad y perfiles de consumo. No toda la documentación existía — parte del levantamiento fue ingeniería inversa sobre el código desplegado.
Fase 2 — Migración progresiva
Migramos los WS en batches, priorizando aquellos con menor criticidad para validar el proceso, y luego avanzando hacia los servicios más sensibles. Cada WS pasó por:
- Actualización de código: Migración de Java 1.6 a 1.8, reemplazando APIs deprecated y ajustando configuraciones
- Desacoplamiento de WAS: Sustitución de dependencias propietarias por equivalentes estándar o nativas de GCP
- Configuración para GCP: Ajuste de despliegue, variables de entorno, conectividad a bases de datos y otros servicios
- Pruebas en entorno controlado: Validación funcional, de integración y de rendimiento antes del pase a producción
Fase 3 — Despliegue y validación en GCP
Una vez migrados, los WS se desplegaron en los entornos de GCP del banco. Se realizaron pruebas de integración con los sistemas consumidores para asegurar que los contratos de servicio se mantuvieran idénticos — algo crítico cuando los WS son consumidos por aplicaciones que no pueden modificarse.
Gestión con el equipo del banco
Coordinamos directamente con Hans Álvarez, Líder de Proyectos de Banco Ripley, asegurando que cada entrega parcial tuviera su revisión y recepción conforme. El proyecto se ejecutó entre junio 2023 y marzo 2024.
Resultados
- 25 WebServices migrados de WAS a GCP exitosamente
- Java 1.6 → Java 1.8, eliminando vulnerabilidades del JDK obsoleto
- Desacoplamiento completo de IBM WebSphere — sin dependencias propietarias remanentes
- Operación continua: migración progresiva sin afectar la disponibilidad de los servicios
- Recepción conforme del banco certificando el proyecto como exitoso
- Base preparada para futuras migraciones a versiones superiores de Java y a arquitecturas más modernas
Dato concreto: Cada WS tenía su propia personalidad en WAS — configuraciones JNDI, pools de conexión, realms de seguridad. No existía un "script mágico" para migrarlos a GCP. Fue trabajo de ingeniería caso a caso, con criterio para decidir qué se quedaba, qué se reemplazaba y qué se reescribía.
Lo que aprendimos
- Migrar desde un application server propietario no es trivial. WAS tiene features que no existen en cloud — JNDI jerárquico, security realms, administración centralizada. Hay que entender bien qué se pierde y cómo reemplazarlo.
- El salto de Java 1.6 a 1.8 es más grande de lo que parece. No es solo cambiar la versión del JDK. Cambian APIs, cambia el modelo de memoria, cambian las tools de monitoreo. Cada WS requiere revisión y ajuste.
- Coordinación con el banco es clave. En banca, los webservices no son "microservicios cool" — son contratos formales entre sistemas. Cambiar su plataforma sin cambiar su interfaz externa exige precisión quirúrgica.
- La migración progresiva reduce el riesgo. Migrar de a batches permitió validar el proceso con servicios de menor criticidad antes de tocar los más sensibles. Un big bang aquí habría sido un error.