El título hace dos reclamaciones:
- La modernización de mainframe es difícil.
- La modernización de mainframe es divertida.
Mi objetivo en este ensayo es justificar estas afirmaciones. Si tengo éxito, espero persuadir a un pequeño número de técnicos que son estimulados —más que disuasivos— por enormes dificultades para unirse a nosotros en nuestra búsqueda.
Para empezar, debería explicar de qué estoy hablando.
Cuando piensas en un mainframe, es probable que imagines una terminal de pantalla verde monocroma. Durante más de cuarenta años, ese brillante texto del fósforo ha sido el latido constante de la financiación mundial.
Esencialmente, la modernización de mainframe está convirtiendo una aplicación de software o un conjunto de aplicaciones que se ejecutan en un sistema distribuido moderno, preservando al mismo tiempo el comportamiento, la corrección y las garantías operativas.
¿Qué es una computadora central? Per IBM, el mayor proveedor de mainframes, “[ellos] son servidores de datos diseñados para procesar hasta 1 trillón de transacciones web diariamente con los mayores niveles de seguridad y fiabilidad”. A pesar del aumento de la informática en la nube, los mainframes siguen desempeñando un papel esencial en la infraestructura de TI, especialmente en las industrias más tradicionales que tienen un gran volumen de transacciones críticas.
Basado en un reciente informe de IBM, “45 de los 50 principales bancos, 4 de las 5 principales aerolíneas, 7 de los 10 mejores minoristas globales y 67 de las compañías Fortune 100 aprovechan el mainframe como su plataforma central”. Cuando cambias una tarjeta de crédito en Londres o retiras pesos en Bogotá, estás interactuando con estas máquinas.
Por qué
Entonces, ¿por qué modernizar? Si los mainframes son tan buenos, ¿por qué alejarse de ellos? Las organizaciones pretenden tener diversas razones. Pero si usted está en una sala de operaciones de un banco principal hoy, verá que se reduce a dos puntos fundamentales:
- Agilidad. El número de personas que todavía conocen COBOL y los internos de la infraestructura bancaria de 40 años está disminuyendo rápidamente. Esto hace que sea peligroso cambiar estos programas, causando que partes de un negocio se congelen a tiempo. Un negocio que se estanca eventualmente muere, y por lo tanto la agilidad es el antecedente a la supervivencia.
- Costo. IBM tiene un monopolio cercano en el mercado de mainframe. Operar un solo mainframe puede costar millones al año. Si bien no es un negociador para todos, muchas empresas se apartarían de contratos costosos de IBM si hubiera un camino claro y de bajo riesgo para hacerlo.
Así, aunque no hay nada malo en los mainframesper se, las condiciones de mercado y el estado del mundo crean fuertes vientos de cola para modernizarse lejos de ellos, con el mercado de modernización de mainframe estimado estar en los cientos de miles de millones de dólares.
La modernización de mainframe es difícil
La modernización de mainframe es un problema perjudicialmente duro porque es una amalgama de algunos de los problemas más difíciles en toda la ciencia informática y la ingeniería de software, todo a la vez.
Debemos tratar simultáneamente cuestiones como el estado compartido implícito, el flujo de control indocumentado, las fronteras transaccionales no obvias, los casos de borde numérico que se han acumulado durante décadas, y la consistencia distribuida garantiza que el mainframe proporciona implícitamente. Los sistemas distribuidos no lo hacen.
Esta es la realidad del legado de la “pantalla verde”: la modernización de Mainframe aborda décadas de deuda tecnológica en un idioma que casi nadie sabe (COBOL), escrito antes del advenimiento de la ingeniería de software moderna y la programación orientada al objeto. Los patrones de diseño están ausentes, la documentación dolorosamente incompleta.
Considere algo tan simple como los números.
COBOL comúnmente utiliza formatos decimales empaquetados como COMP-3, que codifican base-10 aritmética directamente en memoria para garantizar precisión exacta. Si migras esa lógica a un tipo flotante nativa de la nube, has cambiado sutilmente el comportamiento matemático del sistema. Los flotadores IEEE 754 son aproximaciones base-2, y los valores como 0.1 no pueden ser representados exactamente. Aunque cada discrepancia individual es pequeña, en un sistema bancario sobre millones de computaciones diarias, los compuestos de error.
El sistema comienza a crear o destruir dinero sin querer.
En teoría, y en la práctica a esta escala, ningún análisis estático puede caracterizar completamente el comportamiento de un sistema tan grande y tan viejo. Siempre habrá comportamientos que sólo se revelan bajo entradas reales, datos reales y tiempo real.
La aplicación objetivo debe capturar con precisión el “Ghost in the Shell” del mainframe, a menudo incluyendo sus defectos y errores. Las aplicaciones de Downstream podrían estar manejando errores conocidos de maneras idiosincráticas, y la fijación de estos errores conocidos puede conducir a catástrofes imprevisibles de orden segundo y superior.
Como hemos mencionado en nuestro post sobre el Lindy Effect, la historia se ilumina con fallas a gran escala de la modernización tradicional centrada en el ser humano. Debemos esforzarnos para hacerlo mejor.
Resolver el problema duro (es divertido)
Para modernizar con seguridad, debemos demostrar —con precisión matemática— que nuestro nuevo sistema se comporta exactamente como el antiguo. Esto requiere crear una sofisticada suite de prueba funcional que actúa como un reflejo perfecto de la realidad.
Para crear esto, necesitamos considerar dos objetivos:
- La vista del cliente: Para todas las entradas de producción, ¿el sistema de destino genera exactamente la misma salida que la fuente?
- The Engineering View: ¿Podemos escribir la suite de prueba de una manera que crea una especificaciones inequívocas y comprensibles para los agentes de IA de los cuales crear la aplicación de destino?
Un humano puede razonar sobre un camino de ejecución a la vez. Este problema requiere razonar sobre millones. El espacio del estado es demasiado grande, las interacciones demasiado sutiles, y el bucle de retroalimentación demasiado lento para la intuición humana sola. Lo que necesitamos no es más manos escribiendo código, pero un sistema que puede explorar las posibilidades, absorber las restricciones, y iterar a una velocidad que ningún equipo de humanos puede coincidir. Pero ese sistema es tan bueno como la realidad que se limita a obedecer.
La frontera
Esta es la frontera donde el papel del ingeniero cambia de código de escritura para diseñar las limitaciones que definen la realidad.
En Hypercubic, creemos que esta —la capacidad de limitar la realidad para la AI- es la habilidad definitoria de la próxima década de ingeniería de software.
Todavía estamos descubriendo la manera correcta de construir estas limitaciones. Requiere razonar sobre invariantes de alto nivel como la preservación del equilibrio, mientras que también rastrea comportamientos de bajo nivel como los registros de pedidos de archivos I/O o transacciones. Abarca análisis de código estático, gráficos dinámicos de flujo de datos y pedidos de transacciones en sistemas distribuidos masivamente.
La mayor parte de la ingeniería de software hoy implica pegar juntos API bien documentadas o botones móviles en una pantalla. Es un trabajo predecible y seguro.
La modernización de mainframe es lo contrario. Requiere participar directamente con los fundamentos caóticos e indocumentados de la economía global.
Finalmente estamos llegando detrás de esa brillante pantalla verde para llevar la lógica a la luz del siglo XXI.
Si la idea de resolver problemas que son teóricamente imposibles pero prácticamente necesarios, queremos conocerte.