Bellacosa Mainframe e quando o mainframe migra para a cloud

☕ Um Café no Bellacosa Mainframe

O Mercenário das Galáxias Entra no CPD — A Nuvem Chegou, Olhou para o IBM Z e Disse: “Você Vem Junto”

Ou: por que migrar para cloud não obriga ninguém a jogar COBOL no lixo, como uma LPAR já fazia trabalho de “nuvem” quando o Wi-Fi ainda era ficção científica, e por que a Black Friday continua sendo mais perigosa que um buraco negro

No limite da Nebulosa de Andrômeda Menor, a nave RACF Falcon reduz a velocidade. Seu piloto, Capitão Argo Bell, mercenário de aluguel, caçador de recompensas e sobrevivente de três projetos de migração feitos “em um único fim de semana”, recebe uma transmissão urgente.

“Capitão, nosso conselho decidiu ir para a nuvem. Precisamos aposentar o mainframe.”

Argo fecha os olhos, toma um gole de café espacial — uma bebida tão densa que talvez precise de SORT FIELDS=COPY para atravessar o filtro — e pergunta a única coisa sensata:

“O que, exatamente, vocês estão migrando?”

Do outro lado, silêncio.

Porque “ir para cloud” virou uma expressão tão poderosa quanto “vamos usar IA”, “vamos quebrar o monólito” ou “vamos colocar em Kubernetes”. Às vezes significa uma mudança tecnológica profunda e perfeitamente justificável. Outras vezes significa que alguém assistiu a uma apresentação com prédios azuis, hexágonos, setas curvadas e a palavra agility escrita 42 vezes.

Para um programador COBOL iniciante, esta é a primeira grande lição: cloud não é uma arquitetura, não é uma linguagem e não é sinônimo de servidor x86. Cloud é, antes de tudo, uma forma de adquirir, operar e consumir recursos de TI.

E sim: uma empresa pode levar seu ambiente para um modelo de cloud e continuar rodando COBOL, CICS, Db2, IMS, MQ e z/OS numa boa, sem que o programa de folha de pagamento acorde um dia falando Java e chamando isso de evolução.

Prólogo — A falsa guerra entre o templo antigo e a nuvem nova

Por décadas, vendemos uma história simplificada sobre a evolução da computação:

Mainframe → servidores distribuídos → cloud → microsserviços → felicidade eterna

É uma história agradável. Tem começo, meio, fim e um vilão claro: o “legado”.

O problema é que empresas reais não funcionam como um infográfico de palestra. Elas são mais parecidas com uma galáxia: têm sistemas novos, sistemas antigos, órbitas estranhas, satélites esquecidos e pelo menos um arquivo de produção que ninguém toca desde 1997 porque “se mexer nele, talvez pare o faturamento”.

Uma companhia moderna pode usar tudo ao mesmo tempo:

• SaaS para RH, e-mail e colaboração;

• aplicativos móveis em cloud pública;

• microsserviços em containers;

• analytics e IA em hyperscalers;

• Linux em IBM Z;

• CICS e Db2 no z/OS;

• COBOL processando transações que movimentam dinheiro real.

Isso não é incoerência. É arquitetura híbrida.

O objetivo não é escolher uma religião tecnológica. O objetivo é colocar cada workload na plataforma que entrega melhor combinação de segurança, escala, custo, latência, disponibilidade, capacidade operacional e risco.

O Capitão Argo chama isso de Regra do Motor da Nave:

Você não troca o motor de dobra que funciona apenas porque o vizinho comprou uma scooter elétrica.

1. Plataforma não é modelo de consumo

Vamos separar duas coisas que muita gente mistura.

A primeira é a plataforma: onde e como a aplicação executa.

Ela pode ser:

• z/OS num IBM Z;

• Linux em servidor x86;

• Windows;

• Kubernetes;

• uma plataforma PaaS;

• um SaaS pronto.

A segunda é o modelo de consumo: quem compra, opera, mantém, dimensiona e cobra pela infraestrutura.

Uma aplicação COBOL pode continuar sendo COBOL em z/OS, mas seu ambiente pode mudar de várias maneiras.

Mudança	O que acontece	COBOL precisa mudar?
Hospedagem	O IBM Z sai do CPD da empresa e vai para um provedor	Não necessariamente
Gestão	Um parceiro passa a operar z/OS, storage e backup	Não necessariamente
Financeira	Capacidade própria vira serviço contratado	Não necessariamente
Integração	O CICS passa a expor APIs REST ou conversar por MQ	Talvez pouco ou nada
Aplicação	Programas são reescritos, refatorados ou aposentados	Sim, aqui pode mudar
Arquitetura	Parte do monólito é separada em serviços	Talvez

Perceba a diferença: migrar a infraestrutura não é o mesmo que migrar a aplicação.

Se uma empresa muda seu sistema de folha de um IBM Z instalado no próprio prédio para um IBM Z hospedado e operado por um provedor, a folha continua sendo a mesma folha. Os programas podem continuar usando os mesmos arquivos, tabelas Db2, transações CICS, rotinas batch e JCL.

Mudou o dono do ferro, a operação e, possivelmente, a forma de contratar capacidade. Não necessariamente mudou a lógica de negócio.

Para o iniciante em COBOL, pense assim: mudar o datacenter não altera automaticamente isto:

       IF VALOR-PARCELA > LIMITE-CREDITO
           MOVE 'RECUSADA' TO STATUS-PROPOSTA
       ELSE
           MOVE 'APROVADA' TO STATUS-PROPOSTA
       END-IF.

A regra continua sendo a regra. E, em sistemas corporativos, regras de negócio valem muito mais do que a moda da infraestrutura.

2. Quando o mainframe era “seu”: comprar uma estação orbital inteira

No modelo tradicional, uma organização comprava ou alugava o mainframe, instalava-o em seu data center e montava ao redor dele uma civilização inteira.

Não era somente “comprar um computador”.

Era necessário ter ou contratar:

• energia, refrigeração, sala-cofre e conectividade;

• capacidade de CPU e memória;

• storage, cópias, replicação e backup;

• recuperação de desastre;

• segurança, RACF e auditoria;

• z/OS, middleware, Db2, CICS, MQ, ferramentas de monitoramento;

• operadores, administradores, especialistas em storage, performance e rede;

• pessoas capazes de atender aquela ligação às 3h12 da manhã: “o fechamento não terminou”.

E havia outro problema: a capacidade deve ser planejada para os picos.

Um banco pode ter fechamento mensal, datas de pagamento, horários de processamento noturno e campanhas comerciais. Uma seguradora tem suas próprias sazonalidades. Uma varejista precisa sobreviver a uma Black Friday sem que o botão “comprar” vire uma peça de ficção experimental.

Então a empresa mantém recursos para a pior semana previsível — mesmo que, durante boa parte do ano, o consumo seja menor.

Terça-feira comum:       ██████
Fechamento mensal:       ████████████
Black Friday:            ████████████████████
Capacidade adquirida:    ████████████████████

Isso não é incompetência. É sobrevivência operacional.

O problema financeiro é que você imobiliza capital para suportar o pico. É como manter uma nave cargueira interplanetária estacionada o ano todo porque, uma vez por ano, você precisa transportar 40 toneladas de brinquedos para Saturno.

3. A virtualização: o mainframe fez antes de virar palavra de camiseta

Quando alguém diz “cloud depende de virtualização”, o veterano de mainframe normalmente solta uma risada discreta, igual à de quem já viu esse episódio em preto e branco.

No IBM Z existe o PR/SM — Processor Resource/Systems Manager. Ele permite dividir uma máquina física em LPARs, ou Logical Partitions.

Uma LPAR funciona como uma máquina lógica independente. Em uma mesma máquina física, podem existir ambientes separados rodando, por exemplo:

• z/OS de produção;

• z/OS de homologação;

• z/VM;

• Linux on IBM Z;

• ambientes de desenvolvimento e testes.

IBM Z físico
└── PR/SM
    ├── LPAR 1: z/OS Produção
    │   ├── CICS
    │   ├── Db2
    │   ├── MQ
    │   └── COBOL online e batch
    ├── LPAR 2: z/OS Homologação
    ├── LPAR 3: z/VM
    │   └── VMs Linux
    └── LPAR 4: Linux on IBM Z

Aqui vale uma precisão técnica importante: LPAR não é simplesmente uma VM grandona.

No mundo x86, é comum pensar em um hypervisor criando máquinas virtuais sobre um servidor. No IBM Z, o PR/SM é uma função muito integrada à arquitetura da plataforma, com forte isolamento de recursos. Depois, dentro de uma LPAR, o z/VM pode criar máquinas virtuais adicionais, especialmente para Linux.

Para o programador COBOL, isso muda pouco no código. Seu EXEC CICS SEND, seu SELECT de Db2 e seu JCL não precisam saber em qual processador físico estão executando. Mas muda muito para quem administra capacidade, disponibilidade, segurança e custos.

O princípio, porém, é familiar:

Um recurso físico pode ser particionado e entregue como vários ambientes independentes.

A cloud não inventou essa ideia. Ela a transformou em catálogo, portal, automação, cobrança por consumo e serviço em larga escala.

4. Multi-tenancy — vários passageiros, portas trancadas

Se um IBM Z pode ser dividido em ambientes isolados, aparece a pergunta inevitável:

“Um provedor poderia hospedar workloads de clientes diferentes na mesma infraestrutura?”

Pode. Esse é o conceito de multi-tenancy.

Não significa que o cliente A enxerga os arquivos VSAM do cliente B enquanto passeia pelo ISPF. Significa que o provedor usa controles técnicos e operacionais para manter os ambientes segregados.

Há isolamento em várias camadas:

• LPARs e controles de plataforma;

• redes segregadas;

• perfis e grupos RACF separados;

• storage com políticas próprias;

• criptografia e gestão de chaves;

• auditoria e trilhas de acesso;

• equipes, processos e contratos;

• controles de privilégio administrativo.

É parecido com morar em apartamentos no mesmo prédio: compartilhar o prédio não significa compartilhar a chave, o quarto, o cofre ou a conta bancária.

Mas atenção: multi-tenancy não é feitiçaria galáctica. Ele exige desenho, auditoria e governança séria. Quem trabalha com dados financeiros, pessoais ou regulados precisa avaliar cuidadosamente residência de dados, segregação, acesso privilegiado, continuidade, criptografia, requisitos legais e resposta a incidentes.

O Capitão Argo resume:

“Se alguém disser ‘é isolado’, pergunte ‘isolado como, testado por quem e auditado onde?’”

Essa pergunta evita que muita arquitetura bonita exploda na primeira inspeção.

5. Mainframe as a Service: não venda o motor, contrate a oficina

É aqui que entra o termo MaaS — Mainframe as a Service.

Não existe um único padrão universal chamado MaaS. Cada fornecedor pode organizar contrato, infraestrutura, ferramentas, capacidade e responsabilidades de maneira diferente. Mas a ideia é simples:

A empresa continua consumindo os recursos do mainframe, mas deixa de possuir e operar sozinha toda a infraestrutura por trás deles.

Em vez de manter o IBM Z, o storage, a operação de base e todos os especialistas internamente, ela pode contratar um provedor para hospedar e gerenciar parte desse universo.

O provedor pode assumir, conforme o contrato:

• infraestrutura física;

• monitoramento;

• sustentação de z/OS;

• storage;

• backup e recuperação;

• atualização tecnológica;

• parte da gestão de capacidade;

• operação 24x7;

• ferramentas de observabilidade;

• especialização em middleware e plataforma.

A empresa, por sua vez, preserva o que não deveria terceirizar sem pensar: conhecimento do negócio, prioridades, aprovação de mudanças, regras de crédito, dados críticos, controles de risco e decisões de arquitetura.

O que muda para o varejo?

Imagine uma venda parcelada.

O cliente vê um produto no aplicativo. O front-end talvez esteja em cloud pública. Um serviço de catálogo pode rodar em containers. Mas, quando chega a hora de verificar limite, registrar o financiamento, baixar estoque, emitir a transação e garantir consistência financeira, o core pode estar no z/OS.

App / site
   ↓ API
Camada digital em cloud
   ↓ MQ ou serviço seguro
CICS no z/OS
   ↓
COBOL + Db2 + regras de negócio
   ↓
Resposta: aprovada, recusada ou pendente

O consumidor não quer saber se o processamento foi feito por um microsserviço, uma LPAR ou uma tripulação de robôs em Marte. Ele quer saber se a compra foi aprovada e se o pedido não desapareceu.

Por isso, modernizar não significa obrigatoriamente reescrever o core. Muitas vezes significa integrá-lo melhor ao restante da empresa.

6. CAPEX, OPEX e a parte que o slide costuma esconder

Quando a empresa possui infraestrutura própria, há investimento em ativos, renovação, capacidade e operação. Isso costuma ser tratado como CAPEX — investimento de capital.

Ao contratar um serviço, parte desse custo pode migrar para OPEX — despesa operacional. Em tese, a empresa reduz capital imobilizado, ganha previsibilidade e transfere algumas responsabilidades ao provedor.

Mas o mercenário das galáxias pede cautela.

“Cloud não significa que o reator ficou mais barato. Às vezes significa apenas que outra pessoa cuida dele e manda uma fatura melhor organizada.”

A vantagem pode ser muito real, mas não deve ser tratada como automática.

Cloud não é necessariamente:

• mais barata em todos os cenários;

• ilimitada;

• instantânea;

• livre de contratos;

• livre de licenciamento;

• livre de planejamento.

Uma varejista não pode esperar o carrinho de compra travar às 18h da Black Friday para então perguntar se existe capacidade disponível. A estratégia de pico deve ser planejada antes: capacidade contratada, políticas de escala, testes, monitoração, limites de I/O, rede, banco de dados, filas MQ e contingência.

A cloud remove parte da preocupação com o “ferro”. Ela não remove a necessidade de engenharia.

7. O caso Casas Bahia: cloud sem expulsar o mainframe

O caso citado nesta conversa é interessante porque desmonta a velha oposição “mainframe versus cloud”.

O Grupo Casas Bahia divulgou a conclusão da migração de seu ambiente mainframe para um modelo zCloud em parceria com a Kyndryl, apresentando benefícios esperados como flexibilidade, escalabilidade e otimização de custos. Isso é relevante porque o movimento descrito não é “jogar o mainframe fora”; é alterar o modelo de infraestrutura que sustenta workloads críticos.

E há uma observação importante para quem já trabalhou em projetos bancários ligados ao varejo: por trás de uma compra aparentemente simples existe uma cadeia de regras, conciliações, crédito, estoque, pagamentos, cadastros, cobranças e integrações. O consumidor vê “12x sem juros”. O CPD vê cinquenta sistemas discutindo o que a frase significa.

Por razões de confidencialidade, histórias de projetos devem ser contadas sem expor dados internos, arquitetura proprietária ou detalhes de clientes. Mas a lição pública é clara: uma organização pode adotar cloud para ganhar flexibilidade operacional sem tratar décadas de regras de negócio como lixo tecnológico.

8. O perigo do “lift-and-shift emocional”

Agora a parte menos romântica.

Mover o mainframe para um provedor não cura automaticamente todos os males do ambiente. Um sistema hospedado pode continuar tendo:

• JCLs misteriosos;

• jobs que dependem de uma sequência ritualística;

• documentação escrita por alguém que se aposentou em 2004;

• permissões RACF excessivas;

• processos manuais;

• pouca automação de testes;

• interfaces de arquivo difíceis de rastrear;

• dependência de conhecimento tribal.

Colocar tudo em zCloud e chamar isso de transformação é como trocar a garagem da nave, mas manter o painel de controle preso com fita adesiva.

A modernização madura trabalha em quatro frentes.

Frente	Pergunta que importa
Infraestrutura	Onde o workload roda e quem o sustenta?
Operação	Como monitorar, automatizar, recuperar e responder a falhas?
Aplicação	O código deve ser mantido, encapsulado, refatorado ou substituído?
Integração	Como o core conversa com canais digitais com segurança e rastreabilidade?

É perfeitamente possível ter COBOL no coração da operação e uma prática moderna ao redor dele: Git, pipelines, testes automatizados, análise estática, observabilidade, APIs, mensageria, segurança integrada e documentação viva.

COBOL não é o oposto de DevSecOps. Um programa COBOL sem teste e sem governança é um problema; um programa Java sem teste e sem governança também é. A diferença é que o segundo costuma ter uma camiseta mais moderna.

9. Passo a passo para o iniciante não cair no buraco negro

Se você está começando em COBOL e ouve que sua empresa “vai para cloud”, siga este roteiro.

Passo 1 — Não conclua nada pela frase

Pergunte:

• As aplicações serão reescritas?

• O z/OS vai continuar?

• O hardware deixará o data center?

• Quem operará o ambiente?

• O contrato inclui capacidade variável?

• O objetivo é custo, resiliência, escassez de especialistas, agilidade ou tudo isso?

Passo 2 — Descubra onde seu programa vive

Seu COBOL pode ser:

• batch, disparado por JCL;

• online, chamado por CICS;

• integrado ao Db2;

• consumidor ou produtor de MQ;

• parte de uma cadeia de arquivos;

• exposto por uma API através de uma camada de integração.

Antes de falar em modernização, mapeie entradas, saídas, tabelas, arquivos, dependências e horários.

Passo 3 — Separe código de infraestrutura

O programa sabe calcular juros? Ótimo.

Mas ele precisa saber onde está o datacenter? Geralmente, não.

O ambiente de hospedagem pode mudar sem que a regra de negócio mude. Já a integração, a segurança, o acesso a dados e a performance precisam ser testados cuidadosamente.

Passo 4 — Estude integração, não apenas sintaxe

Para o programador COBOL do futuro, além de PIC, PERFORM, REDEFINES, VSAM e SQL, vale entender:

• APIs REST;

• JSON;

• IBM MQ;

• CICS;

• z/OS Connect;

• autenticação e autorização;

• observabilidade;

• logs, métricas e rastreamento;

• pipelines de entrega.

Não para abandonar COBOL. Para fazer o COBOL conversar com o resto da galáxia.

Passo 5 — Desconfie de soluções de uma frase

Se alguém disser:

“Vamos colocar tudo em cloud e pronto.”

Pergunte:

“Tudo o quê?”

Essa pergunta talvez não pareça heroica, mas ela já salvou mais empresas do que muitas espadas laser.

Epílogo — O mainframe embarca na nave

Capitão Argo Bell responde à transmissão inicial:

“Vocês podem migrar para cloud. Podem contratar capacidade como serviço. Podem hospedar o IBM Z fora do CPD. Podem automatizar operações, expor APIs e integrar com hyperscalers. Só não confundam isso com destruir o sistema que mantém a nave no ar.”

Do outro lado, alguém pergunta:

“Então o mainframe vai sobreviver?”

Argo olha para o painel. Um job crítico termina com CC 0000. Uma transação CICS é confirmada. O Db2 responde. O café continua quente.

“Não é questão de sobreviver. É questão de descobrir onde ele entrega mais valor.”

A nuvem não matou o mainframe. Em muitos casos, ela apenas ofereceu a ele uma nova cabine na nave.

E, se a empresa fizer as perguntas certas, o COBOL pode continuar viajando pelo universo — sem precisar fingir que nasceu ontem.