A modernização de mainframes é um problema difícil e divertido de resolver

O título faz duas alegações:

1. A modernização do mainframe é difícil.
2. A modernização do mainframe é divertida.

O meu objectivo neste ensaio é justificar estas alegações. Se eu conseguir, espero persuadir um pequeno número de pessoas técnicas que são encorajadas – além de dissuadidas – por enorme dificuldade em se juntar a nós em nossa busca.

Para começar, devo explicar do que estou falando.

Quando você pensa em um mainframe, você provavelmente imagina um terminal monocromático de tela verde. Por mais de quarenta anos, esse brilhante texto de fósforo tem sido o batimento cardíaco constante das finanças globais.

Essencialmente, a modernização do mainframe está convertendo um aplicativo de software ou um conjunto de aplicativos rodando em um mainframe em um sistema distribuído moderno, preservando o comportamento, correção e garantias operacionais.

O que é um computador mainframe? Por IBM, o maior provedor de mainframes, “[eles] são servidores de dados que são projetados para processar até 1 trilhão de transações web diariamente com os mais altos níveis de segurança e confiabilidade.” Apesar do aumento da computação em nuvem, os mainframes continuam a desempenhar um papel essencial na infraestrutura de TI, especialmente em indústrias mais tradicionais que têm um grande volume de transações críticas.

Com base em um relatório recente da IBM, “45 dos 50 melhores bancos, 4 das 5 melhores companhias aéreas, 7 dos 10 maiores varejistas globais e 67 das empresas Fortune 100 aproveitam o mainframe como sua plataforma principal.” Quando você passa um cartão de crédito em Londres ou retira pesos em Bogotá, você está interagindo com essas máquinas.

O Porquê

Então, por que modernizar? Se os mainframes são tão bons, porquê afastar-se deles? As organizações pretendem ter uma variedade de razões. Mas se você ficar em uma sala de operações de um grande banco hoje, você verá que se resume a dois pontos fundamentais:

1. Agilidade. O número de pessoas que ainda conhecem o COBOL e as infra-estruturas bancárias internas de 40 anos está a diminuir rapidamente. Isso torna perigoso mudar esses programas, fazendo partes de um negócio congelar no tempo. Um negócio que estagna eventualmente morre, e assim a agilidade é o antecedente da sobrevivência.
2. Custo. A IBM detém quase um monopólio no mercado de mainframe. Operar um único mainframe pode custar milhões por ano. Embora não seja um quebra-acordo para todos, muitas empresas mudariam de contratos caro IBM se houvesse um caminho claro e de baixo risco para fazê-lo.

Assim, embora não haja nada de errado com mainframesper se, as condições de mercado e o estado do mundo criam fortes ventos de cauda para modernizar longe deles, com o mercado de modernização mainframe estimado em centenas de bilhões de dólares.

A modernização do mainframe é difícil

A modernização do mainframe é um problema extremamente difícil porque é uma fusão de alguns dos problemas mais difíceis em toda a ciência da computação e engenharia de software, tudo de uma só vez.

Devemos lidar simultaneamente com questões como estado compartilhado implícito, fluxo de controle não documentado, fronteiras transacionais não óbvias, casos de borda numérica que se acumularam ao longo de décadas, e consistência distribuída garante que o mainframe fornece implicitamente. Os sistemas distribuídos não.

Esta é a realidade do legado “tela verde”: a modernização do mainframe enfrenta décadas de dívida tecnológica em uma linguagem quase ninguém sabe (COBOL), escrito antes do advento da engenharia de software moderna e programação orientada a objetos. Os padrões de projeto estão ausentes, documentação dolorosamente incompleta.

Considere algo tão simples quanto números.

COBOL comumente usa formatos decimais embalados como COMP-3, que codificam a aritmética base-10 diretamente na memória para garantir precisão exata. Se você migrar essa lógica para um tipo de ponto flutuante nativo na nuvem, você mudou sutilmente o comportamento matemático do sistema. IEEE 754 flutuadores são aproximações base-2, e valores como 0,1 não podem ser representados exatamente. Embora cada discrepância individual seja pequena, em um sistema bancário mais de milhões de cálculos diários, os compostos de erro.

O sistema começa a criar ou destruir dinheiro sem querer.

Em teoria, e na prática nesta escala, nenhuma análise estática pode caracterizar plenamente o comportamento de um sistema tão grande e antigo. Haverá sempre comportamentos que só se revelam sob entradas reais, dados reais e tempo real.

O aplicativo alvo deve capturar com precisão o "Ghost in the Shell" do mainframe, muitas vezes incluindo suas falhas e bugs. Os aplicativos Downstream podem estar lidando com bugs conhecidos de formas idiossincráticas, e corrigir esses bugs conhecidos pode levar a catástrofes inesperadas de segunda e maior ordem.

Como mencionamos em nosso post sobre o Efeito Lindy, a história está repleta de falhas em larga escala da modernização tradicional focada no humano. Temos de nos esforçar para fazer melhor.

Resolver o problema difícil (é divertido)

Para modernizar com segurança, devemos demonstrar – com precisão matemática – que nosso novo sistema se comporta exatamente como o antigo. Isso requer criar um sofisticado conjunto de testes funcionais que aja como um reflexo perfeito da realidade.

Para isso, precisamos considerar dois objetivos:

1. A Visão do Cliente: Para todas as entradas de produção, o sistema alvo gera exatamente a mesma saída que a fonte?
2. The Engineering View: Podemos escrever o conjunto de testes de uma forma que crie uma especificação inequívoca e compreensível para agentes de IA a partir da qual criar o aplicativo alvo?

Um humano pode raciocinar sobre um caminho de execução de cada vez. Este problema requer raciocínio sobre milhões. O espaço de estado é muito grande, as interações muito sutis, e o loop de feedback muito lento para a intuição humana sozinho. O que nós precisamos não é mais mãos escrevendo código, mas um sistema que pode explorar possibilidades, absorver restrições, e iterar a uma velocidade que nenhum time de humanos pode combinar. Mas esse sistema é tão bom quanto a realidade que é obrigado a obedecer.

A Fronteira

Esta é a fronteira onde o papel do engenheiro muda de escrever código para projetar as restrições que definem a realidade.

Na Hypercubic, acreditamos que isso – a capacidade de restringir a realidade para IA agente – é a habilidade definidora da próxima década de engenharia de software.

Ainda estamos a descobrir a forma correcta de construir estas restrições. Requer raciocínio sobre invariantes de alto nível, como a preservação do equilíbrio, enquanto também rastreia comportamentos de baixo nível como pedidos de I/O de arquivo ou repetições de transação. Ele abrange análise estática de código, gráficos de fluxo de dados dinâmicos e transações de ordenação em sistemas massivamente distribuídos.

A maioria da engenharia de software hoje envolve colar APIs bem documentadas ou mover botões em uma tela. É um trabalho previsível e seguro.

A modernização do mainframe é o oposto. Requer envolver-se diretamente com as bases caóticas e indocumentadas da economia global.

Estamos finalmente atrás daquela tela verde brilhante para puxar a lógica para a luz do século 21.

Se a ideia de resolver problemas teoricamente impossíveis, mas praticamente necessários, vos atrai, queremos conhecer-vos.

Referências

1. https://www.ibm.com/think/topics/mainframe