> ## Content Index > Fetch the complete content index at: https://blog.ifirestone.dev/llms.txt > Use this file to discover other available public pages before exploring further. # De pantallas verdes a contenedores: pasar de AS/400 e IBM ACE a microservicios - URL: https://blog.ifirestone.dev/de-pantallas-verdes-a-contenedores-pasar-de-as-400-e-ibm-ace-a-microservicios/ - Published: 2026-11-04T13:00:00.000Z - Updated: 2026-11-04T13:00:00.000Z - Description: Llevar una arquitectura empresarial de RPG en AS/400 e IBM App Connect Enterprise (ACE) a microservicios nativos de nube es menos una reescritura y más una evolución operativa. Así se recorre ese camino. - Author: Ivan Firestone - Tags: microservices, architecture, migration, legacy, #spanish > Llevar una arquitectura empresarial de RPG en AS/400 e IBM App Connect Enterprise (ACE) a microservicios nativos de nube es menos una reescritura y más una evolución operativa. Así se recorre ese camino. ## La pantalla verde en la era de Kubernetes Durante décadas, la columna vertebral de la computación empresarial corrió sobre hierro confiable y sólido como una roca. En muchas organizaciones de banca, seguros y logística, la lógica de negocio central sigue viviendo dentro de un IBM AS/400 (Power Systems / IBM i) que ejecuta programas RPG, acoplado a un bus de servicios empresarial (ESB) como IBM App Connect Enterprise (ACE) o su predecesor, Message Broker, que enruta y transforma mensajes por toda la empresa. Para los equipos que los construyeron y los mantienen, estos sistemas son maravillas de estabilidad. Un solo equipo AS/400 puede funcionar años sin reiniciarse, procesando millones de transacciones con un rendimiento predecible. Luego llega el mandato de la dirección: *"Necesitamos modernizarnos. Nos vamos a microservicios y Kubernetes."* De pronto, desarrolladores que pasaron veinte años dominando subrutinas RPG, definiciones de pantallas DDS y flujos de mensajes ESQL en ACE se encuentran mirando Dockerfiles, manifiestos YAML y arquitecturas asíncronas dirigidas por eventos. El reto no es solo aprender un lenguaje nuevo; es desaprender décadas de paradigmas centralizados y fuertemente acoplados. Esta es una forma de tender el puente entre AS/400, IBM ACE y los microservicios nativos de nube modernos sin romper la continuidad del negocio que mantiene viva a la empresa. ## Fase 1: entender el mundo viejo (y por qué cuesta dejarlo) Para migrar con éxito fuera de un AS/400 y de un ESB empresarial, primero hay que entender qué problemas resolvían originalmente y por qué replicar esas funciones en un sistema distribuido es complicado. ### 1\. El poder monolítico de RPG y DB2/400 En el AS/400, la base de datos (DB2 for i) y el código de la aplicación (RPG) están profundamente entrelazados. Las llamadas de programa a programa se ejecutan en memoria, sin sobrecarga de red. El bloqueo a nivel de registro y la integridad transaccional los maneja de forma nativa el sistema operativo. Cuando descompones un monolito RPG en microservicios, pierdes ese rendimiento en memoria que antes era gratis. Lo que era una simple llamada a una subrutina local pasa a ser una llamada REST o un mensaje asíncrono por la red, con sobrecarga de serialización, latencia y modos de fallo nuevos. ### 2\. La trampa del ESB: IBM ACE como cuello de botella IBM App Connect Enterprise (ACE) e IBM Message Broker son motores potentes para traducir protocolos, enrutar mensajes y transformar datos con ESQL. Sin embargo, en muchas organizaciones el ESB pasó de ser una capa de integración a convertirse en un **centro de integración monolítico**, con lógica de negocio compleja, consultas a bases de datos y gestión de estado. ``` [ AS/400 / RPG ] │ ▼ (MQ / DataQueues) [ IBM ACE (ESB) ] ◄─── Lógica de negocio que se filtra │ ▼ [ Sistemas downstream ] ``` Cuando todo pasa por un ESB central, este se convierte en un punto único de fallo y en un cuello de botella de despliegue. Cada cambio menor exige coordinar despliegues en todo el bus empresarial. ## Fase 2: traducir los conceptos legacy a paradigmas nativos de nube Dejar estas plataformas no significa tirar a la basura tu conocimiento del dominio. La mayoría de los patrones arquitectónicos centrales tienen equivalentes modernos directos: | Concepto legacy (AS/400 / ACE) | Equivalente en microservicios | ¿Qué cambia? | | --------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **DataQueues / MQ** | Brokers de eventos (Kafka, RabbitMQ, Redis) | La mensajería asíncrona pasa de colas propietarias a logs de eventos distribuidos y escalables. | | **Transformaciones de datos en ESQL** | Servicios de dominio / transformadores de API | La lógica de transformación centralizada se traslada a microservicios de dominio o a API gateways ligeros. | | **Planificación de jobs a nivel de SO** | Kubernetes CronJobs / planificadores distribuidos | Los flujos de jobs del AS/400 (JOBD, SBMJOB) se reemplazan por workers en contenedores y orquestadores. | | **Transacciones nativas de DB2/400** | Patrón Saga / consistencia eventual | Las transacciones atómicas entre dominios se reemplazan por transacciones compensatorias coreografiadas u orquestadas. | ## Fase 3: la estrategia de migración (la higuera estranguladora en acción) No puedes reescribir un núcleo AS/400 de la noche a la mañana. El negocio depende de él para operar cada día. En lugar de eso, usa una estrategia de extracción por fases. ### Paso 1: envolver y exponer (modernizar los bordes) Antes de mover cualquier código fuera del AS/400, expón sus capacidades centrales como APIs modernas. Puedes usar herramientas como los IBM WebSphere Adapters, envoltorios REST escritos en RPG o capas de proxy ligeras. - Trata el AS/400 como un servicio legacy respaldado por una base de datos. - Construye tu nuevo frontend nativo de nube y los microservicios de apoyo (por ejemplo, en Node.js, Go o Java/Spring Boot) para que consuman esas APIs. ### Paso 2: sacar la integración de ACE Si tus flujos de IBM ACE están cargados de lógica de negocio, empieza a quitarles esas responsabilidades. Saca las reglas de validación y transformación de ESQL y llévalas a microservicios, dejando a ACE estrictamente como puente de protocolos, si todavía hace falta para hablar con los endpoints de los sistemas legacy. ### Paso 3: extraer dominio por dominio Identifica los contextos acotados que cambian con frecuencia, como las notificaciones a clientes, los reportes o la lógica auxiliar de facturación, y reescríbelos por completo como microservicios. Las operaciones de lectura suelen poder migrarse primero, replicando los datos de DB2/400 a una base de datos de lectura moderna con herramientas de Change Data Capture (CDC). ## Retos técnicos y salvaguardas Cuando tu equipo da el salto, espera tropezar con varios obstáculos culturales y técnicos: - **El cambio de mentalidad transaccional:** los desarrolladores acostumbrados a transacciones ACID sobre toda la base de datos deben aprender a diseñar para la consistencia eventual. Si un servicio de pagos tiene éxito pero el de inventario falla más adelante, ¿cómo se maneja el rollback? (Respuesta: el patrón Saga y los eventos compensatorios). - **Depuración distribuida:** rastrear una llamada desde un frontend moderno en React, a través de un API Gateway, hacia un microservicio Java, por Kafka, a través de un flujo de ACE y finalmente hasta un programa RPG exige un trazado distribuido sólido (OpenTelemetry). Sin IDs de correlación, resolver problemas es una pesadilla. - **Transición de habilidades:** respeta el conocimiento profundo del dominio de tus veteranos del AS/400 y de ACE. Entienden las reglas de negocio mejor que nadie. Júntalos con desarrolladores nativos de nube para que la lógica de negocio no se pierda en la traducción durante la reescritura. ## Conclusión Migrar de AS/400 e IBM ACE a microservicios no es solo una mejora tecnológica; es un cambio fundamental en cómo tu organización construye, despliega y escala software. La meta no es borrar la historia ni fingir que los sistemas legacy nunca existieron. La meta es desacoplar la agilidad de tu negocio de una infraestructura que envejece, para que tu equipo itere rápido sobre capacidades nuevas mientras el núcleo confiable sigue haciendo lo que siempre ha hecho mejor, hasta su retiro final.