 |
| Bellacosa Mainframe e a modernização do cobol |
☕ Um Café no Bellacosa Mainframe
👄 COBOL Horror Picture Show — Frank-N-Furter e a Estranha Arte de Modernizar sem Matar a Criatura
“Don’t dream it. Be it.” — e, se estiver em produção há quarenta anos, talvez seja melhor descobrir primeiro todas as dependências antes de tentar transformá-lo.
Há alguma coisa deliciosamente apropriada em colocar Frank-N-Furter, de The Rocky Horror Picture Show, diante de uma arquitetura de modernização COBOL.
Pense na cena.
No centro do laboratório existe uma aplicação COBOL.
Ela é antiga.
Muito antiga.
Há décadas recebe transações, abre arquivos, atualiza bancos de dados, processa lotes durante a madrugada e alimenta sistemas que provavelmente nem existiam quando sua primeira versão foi compilada.
Em volta dela aparecem engenheiros carregando Git, Jenkins, Terraform, Ansible, AWS EC2, RDS, Secrets Manager e CloudWatch.
Luzes piscam.
Pipelines começam a executar.
Playbooks descem do Git.
EC2s surgem.
O banco ganha vida.
E alguém grita:
“IT'S ALIVE!”
Calma.
Frank-N-Furter ficaria encantado.
Eu ficaria procurando o JCL.
Porque existe uma diferença monumental entre fazer um programa COBOL executar em outro lugar e modernizar o sistema empresarial do qual aquele programa faz parte.
E é justamente essa diferença que vamos explorar.
Bem-vindo ao laboratório.
🎭 1. Antes de tudo: conheça o Dr. Frank-N-Furter
The Rocky Horror Picture Show nasceu como adaptação cinematográfica do musical The Rocky Horror Show, criado por Richard O'Brien, e chegou aos cinemas em 1975.
No centro daquela insanidade musical está o Dr. Frank-N-Furter, interpretado por Tim Curry.
Cientista.
Showman.
Manipulador.
Extravagante.
E, sobretudo, criador.
Frank não quer simplesmente estudar aquilo que existe.
Ele quer construir sua própria criatura.
Rocky nasce dentro do laboratório como materialização dessa ambição.
E é exatamente por isso que Frank é nosso tutor perfeito para esta conversa.
Modernização de sistemas também pode sofrer da síndrome de Frank-N-Furter:
ficamos tão fascinados com nossa capacidade de construir alguma coisa nova que esquecemos de perguntar se entendemos completamente aquilo que estamos substituindo.
⚡ 2. Há uma criatura COBOL sobre a mesa
Nossa arquitetura começa com algo aparentemente simples:
COBOL
+
AWS EC2
+
AWS RDS
+
Ansible
+
Terraform
+
CI/CDA proposta é elegante.
Temos ambientes:
DEV
↓
SIT
↓
UAT
↓
PRE-PROD
↓
PRODTerraform provisiona infraestrutura.
Ansible configura máquinas e instala o ambiente necessário.
O pipeline controla o processo.
RDS fornece banco de dados gerenciado.
Git preserva código e configuração.
CloudWatch observa o ambiente.
Excelente.
Mas Frank-N-Furter aproxima-se da mesa, levanta o lençol e pergunta:
“Isso é realmente tudo que existe dentro da criatura?”
Não.
Quase nunca.
🧟 3. COBOL não é o monstro
Esta talvez seja a primeira grande inversão que precisamos fazer.
Quando alguém anuncia:
“Temos uma aplicação COBOL de quarenta anos.”
muita gente imediatamente imagina que encontrou o problema.
Não encontrou.
Encontrou uma linguagem.
O problema real pode estar em tudo aquilo que cresceu ao redor dela:
COBOL
│
┌──────────┼──────────┐
│ │ │
CICS IMS Db2
│ │ │
VSAM MQ Stored
│ Procedures
│
JCL
│
Scheduler
│
GDG / datasetsDepois aparecem:
SORT
IDCAMS
REXX
PROCs
copybooks
utilities
FTP/SFTP
APIs
arquivos externos
interfaces
sistemas parceirosEntão alguém encontra um programa:
CALL 'XPTO123'Ótimo.
Onde está XPTO123?
Ninguém sabe.
Até que aquele senhor sentado no fundo da sala fala:
“Ah... isso chama uma rotina que o Pereira escreveu em 1997.”
Onde está Pereira?
Aposentado.
Documentação?
Não existe.
Código?
Está numa load library.
Bem-vindo ao castelo.
🔬 4. “I can make you a man” — recompilar não significa modernizar
Imagine que conseguimos pegar determinado programa COBOL e compilá-lo para execução em Linux numa instância EC2.
Fantástico.
COBOL/zOS
│
▼
COBOL/Linux
│
▼
AWS EC2A aplicação executa.
Então:
“IT'S ALIVE!”
Sim.
Mas cuidado.
Fizemos replatforming.
Talvez isso seja exatamente aquilo que o projeto necessita. Não há absolutamente nada de errado com replatforming.
O erro está em chamar qualquer mudança de plataforma de transformação completa.
A lógica pode continuar praticamente igual.
O código pode continuar COBOL.
O que mudou foi o ambiente no qual ele vive.
É como Rocky.
Frank criou um homem.
Mas criar um corpo funcionando não resolveu automaticamente todos os problemas do castelo.
🏗️ 5. Terraform constrói o laboratório
Vamos separar responsabilidades.
Terraform pode assumir a infraestrutura:
Terraform
│
├── VPC
├── Subnets
├── Security Groups
├── EC2
├── IAM
├── RDS
└── outros recursosPense nele como quem prepara o laboratório.
Mesa instalada.
Eletricidade ligada.
Tanque montado.
Cabos conectados.
Máquinas posicionadas.
Mas Terraform não deveria necessariamente decidir cada detalhe de configuração da criatura.
Para isso entra outro personagem.
🧰 6. Ansible entra usando salto alto
Ansible entra no laboratório dizendo:
“Deixem a configuração comigo.”
E começa.
EC2
↓
pacotes do sistema operacional
↓
COBOL compiler/runtime
↓
environment variables
↓
aplicação
↓
configuração
↓
database connectivity
↓
services
↓
health checksÉ aqui que a arquitetura original fica realmente interessante.
Não precisamos ter um processo artesanal para DEV, outro para SIT, outro para UAT e um ritual secreto conhecido apenas por dois operadores para PRE-PROD.
Temos automação reutilizável.
Algo conceitualmente assim:
ANSIBLE ROLE
│
┌──────────┼──────────┐
│ │ │
DEV SIT UAT
│
▼
PRE-PRODA receita permanece.
Os ingredientes variáveis são separados.
🧓 7. O programador COBOL olha para group_vars e começa a rir
Aqui temos uma das minhas partes favoritas.
A turma DevOps explica:
“Nós separamos a lógica da automação dos parâmetros específicos do ambiente.”
O programador COBOL responde:
“Parâmetros?”
Sim.
DEV pode ter:
DB = APP_DEV
PORT = 1521
ENDPOINT = dev-databaseSIT:
DB = APP_SIT
PORT = 1521
ENDPOINT = sit-databaseUAT:
DB = APP_UAT
PORT = 1521
ENDPOINT = uat-databaseO playbook continua fundamentalmente o mesmo.
Para alguém vindo do mainframe, isso não deveria parecer ficção científica.
Nós passamos décadas trabalhando com conceitos semelhantes através de:
JCL
PROCs
symbolic parameters
PARMLIB
SYSIN
DD statementsMudam as ferramentas.
A ideia de externalizar configuração é muito mais antiga que os slides modernos que a apresentam.
Frank-N-Furter provavelmente acrescentaria glitter.
👄 8. “Don’t dream it. Be it.” — Infrastructure as Code
Aqui encontramos uma mudança genuinamente poderosa.
Durante décadas tivemos infraestrutura e configuração documentadas mais ou menos assim:
“Instalar pacote X, editar arquivo Y, trocar parâmetro Z, reiniciar serviço e telefonar para Carlos se não funcionar.”
Carlos sai da empresa.
Fim da documentação.
Infrastructure as Code transforma parte desse conhecimento operacional em algo executável.
CONHECIMENTO
↓
CODE
↓
Version Control
↓
Automation
↓
EnvironmentIsso é importante.
Código pode ser:
revisado, versionado, comparado, testado, auditado e reproduzido.
O conhecimento deixa de existir exclusivamente na memória do operador.
🧪 9. DEV → SIT → UAT → PRE-PROD
Agora Frank conduz nossa criatura pelos diferentes aposentos do castelo.
DEV
Aqui desenvolvemos e realizamos os primeiros testes.
SOURCE
↓
BUILD
↓
TEST
↓
DEPLOYSIT
System Integration Testing.
Aqui descobrimos uma verdade universal da informática:
Tudo funciona perfeitamente até precisar conversar com outra coisa.
Banco.
APIs.
Filas.
Serviços.
Arquivos.
Autenticação.
Sistemas externos.
UAT
User Acceptance Testing.
Agora a pergunta deixa de ser apenas:
“Funciona?”
e torna-se:
“Isso faz aquilo que o negócio realmente precisa?”
Diferença enorme.
PRE-PROD
Aqui chegamos ao ensaio geral.
E PRE-PROD deveria ser assustadoramente parecido com produção.
🏰 10. PRE-PROD precisa ser o castelo quase completo
Um PRE-PROD simplificado demais produz falsa segurança.
Precisamos considerar:
OS version
runtime version
COBOL compiler/runtime
database version
patches
CPU architecture
memory
network
TLS
IAM
filesystem
locale
encoding
timezone
batch
integrations
security policiesQuanto mais diferente de PROD, mais perguntas surgem.
Imagine:
UAT
COBOL Runtime 8.0
PROD
COBOL Runtime 7.4Funcionou no UAT.
Que maravilhoso.
Mas você não testou produção.
Testou outra coisa.
📦 11. Está faltando um personagem importante: o artefato
Aqui eu faria uma alteração importante na arquitetura.
Não gosto da ideia de recompilar arbitrariamente a aplicação em cada ambiente.
Prefiro:
SOURCE
│
▼
BUILD
│
▼
TEST
│
▼
ARTIFACT REPOSITORY
│
┌───────┼─────────┐
▼ ▼ ▼
DEV SIT UAT
│
▼
PRE-PROD
│
▼
PRODIsso nos leva a um princípio extremamente poderoso:
Build once, deploy many.
Produzimos uma criatura.
Depois submetemos aquela mesma criatura aos testes.
Não fazemos Rocky 1 para DEV, Rocky 2 para SIT, Rocky 3 para UAT e Rocky 4 para produção esperando que todos sejam geneticamente idênticos.
🕵️ 12. A pergunta do auditor
Imagine uma mudança chegando a produção.
O auditor pergunta:
“Esse binário é exatamente aquele homologado?”
Se cada ambiente recompila:
SOURCE
↓
DEV BUILD
SOURCE
↓
SIT BUILD
SOURCE
↓
UAT BUILD
SOURCE
↓
PROD BUILDtemos quatro processos de construção.
Mesmo que tudo pareça igual, aumentamos nossa superfície de dúvida.
Com artefato imutável:
SOURCE
↓
BUILD
↓
ARTIFACT 7.3.17
↓
DEV
↓
SIT
↓
UAT
↓
PRE-PROD
↓
PRODagora existe uma cadeia muito mais clara.
🔐 13. Sweet Transvestite não significa senha escrita no YAML
Chegamos aos secrets.
Nunca faça:
database_password: "senha_supersecreta123"e depois:
git commitParabéns.
Você acaba de transformar seu Git em museu arqueológico de credenciais.
A arquitetura corretamente menciona mecanismos como Ansible Vault e AWS Secrets Manager.
O princípio é:
CODE ≠ SECRETIdealmente:
CI/CD
│
▼
IAM / temporary authorization
│
▼
Secrets Manager
│
▼
RuntimeO segredo aparece apenas onde e quando precisa aparecer.
🧛 14. Privilégio mínimo: nem Frank deveria ter acesso a tudo
Outro princípio:
Developer ≠ Production Admin
Application ≠ Database Admin
Pipeline ≠ Unlimited AWS AdministratorCada componente recebe apenas aquilo de que necessita.
Isso é least privilege.
Se determinado processo precisa consultar um segredo, não existe razão automática para permitir que consulte todos.
Se uma aplicação precisa acessar determinado banco, não significa que deva possuir poder administrativo sobre ele.
É o equivalente moderno de algo que o pessoal RACF conhece muito bem:
Quem é você e por que exatamente precisa acessar isso?
🗄️ 15. RDS parece simples até começarmos a falar de Db2
A imagem permite Oracle/PostgreSQL como exemplos.
Tudo bem.
Mas um cenário vindo de mainframe pode envolver:
COBOL
+
Db2 for z/OSE alguém inevitavelmente pensa:
Db2 → Db2Então deve ser simples.
Ah, meu jovem Brad...
Não necessariamente.
Db2 for z/OS
≠
Db2 LUW
≠
RDS for Db2Existe parentesco tecnológico.
Não existe identidade operacional perfeita.
Precisamos investigar SQL utilizado, stored procedures, utilities, comportamento transacional, autorização, integração e características específicas da plataforma.
O banco pode carregar tanta arqueologia quanto o COBOL.
🗃️ 16. E o VSAM?
Agora Frank encontra um arquivo VSAM no porão.
Silêncio.
Se a aplicação original utiliza:
KSDS
ESDS
RRDSprecisamos responder:
Para onde esses dados vão?
RDS?
Arquivos?
Outro datastore?
Mantemos comportamento equivalente?
E principalmente:
a aplicação depende semanticamente da organização original?
Não basta exportar registros e dizer:
“Migrei.”
Dados possuem comportamento.
Chaves.
Ordenação.
Concorrência.
Locking.
Integridade.
Performance.
Tudo isso importa.
📜 17. E o JCL?
Aqui está uma das grandes vítimas dos diagramas bonitos de modernização.
Pegamos o COBOL.
Migramos.
E esquecemos que às 02:00 existe isto:
JOB A
↓
JOB B
↓
JOB C ─── JOB D
│
▼
JOB E
│
▼
JOB FExistem dependências.
Calendários.
Arquivos.
Condições.
Return codes.
Restart.
Checkpoints.
SLA.
Janelas de processamento.
O JCL talvez desapareça.
A necessidade que ele implementava não desaparece.
Alguma outra coisa precisará orquestrar aquilo.
⏰ 18. O batch não quer saber que agora você é cloud
Imagine um processamento que precisa terminar até 06:00.
No mainframe:
23:00 START
...
05:31 ENDMigramos para AWS.
Agora:
23:00 START
...
06:47 ENDTecnicamente funciona.
Funcionalmente funciona.
Os resultados estão corretos.
E mesmo assim:
A MIGRAÇÃO FALHOU.
Porque o negócio precisava dos dados às 06:00.
Essa é uma lição gigantesca.
Compatibilidade funcional não é suficiente.
Precisamos de compatibilidade operacional.
📊 19. CloudWatch não deveria ficar decorando o canto do desenho
Observabilidade precisa atravessar toda a solução.
Não basta:
EC2 = UP
RDS = UPEnquanto:
Pedidos processados = ZEROInfraestrutura saudável não significa aplicação saudável.
Precisamos enxergar:
CPU
memory
disk
network
database latency
connections
locks
errors
transaction rate
response time
batch duration
business transactionsE aqui o veterano do mainframe reconhece novamente uma velha ideia.
O importante não é saber apenas:
“A máquina está ligada?”
O importante é:
“O workload está entregando aquilo que deveria?”
💥 20. PRE-PROD também precisa morrer
Frank provavelmente aprovaria esta parte.
Testamos:
DATABASE ONLINEExcelente.
Agora desligue o banco.
Testamos:
NETWORK OKExcelente.
Agora introduza timeout.
Testamos:
DISK SPACE OKEncha o disco.
Testamos:
PASSWORD VALIDRevogue a credencial.
Queremos descobrir:
database unavailable
network failure
bad credentials
timeout
disk full
process killed
duplicate transaction
corrupted input
rollback failure
partial deploymentPorque produção descobrirá essas condições por você.
E produção não agenda laboratório.
🔥 21. O health check mais importante talvez seja o ABEND
Um health check dizendo:
HTTP 200é agradável.
Mas para uma aplicação empresarial eu quero saber:
Aplicação iniciou?
Banco conecta?
Fila responde?
Transação funciona?
Arquivo abre?
Batch executa?
Rollback funciona?
Restart funciona?
Dados permanecem consistentes?Um sistema não é saudável porque existe um processo no ps.
Ele é saudável quando consegue realizar sua função.
🔄 22. Rollback precisa entrar no espetáculo
Deployment sem rollback testado é fé.
O pipeline deveria conhecer algo como:
VERSION 8.4
│
▼
DEPLOY
│
├── SUCCESS → continue
│
└── FAILURE
│
▼
VERSION 8.3
│
▼
VALIDATIONMas existe uma complicação.
Rollback de executável é relativamente fácil.
Rollback de banco pode não ser.
Se versão 8.4 alterou schema e começou a gravar dados novos, voltar simplesmente o executável para 8.3 talvez não resolva.
Portanto deployment strategy precisa conversar com database migration strategy.
🧬 23. A criatura tem memória
Esse é outro erro frequente.
Tratamos aplicação como código.
Mas aplicações empresariais são:
CODE
+
DATA
+
STATE
+
INTEGRATIONS
+
HISTORYMigrar código é apenas uma parte.
Migrar décadas de dados mantendo integridade pode ser o verdadeiro projeto.
Frank consegue construir outro corpo.
Transferir quarenta anos de memória para ele é outra história.
🕸️ 24. Discovery deveria aparecer antes de Terraform
Se eu redesenhasse completamente a figura, colocaria no início:
DISCOVERY
│
┌──────────┼───────────┐
│ │ │
COBOL JCL DATA
│ │ │
CICS Scheduler VSAM
│ │
IMS Db2
│
MQ
│
External SystemsDepois:
Dependency Mapping
↓
Workload Classification
↓
Modernization Strategy
↓
Architecture
↓
Terraform / Ansible / CI/CDEssa ordem é fundamental.
Não escolha a ferramenta antes de compreender o problema.
🧭 25. Nem tudo precisa sair do mainframe
Aqui está outra heresia contra certas apresentações de modernização.
Podemos terminar com:
ENTERPRISE
│
┌───────────┴───────────┐
│ │
IBM Z AWS
│ │
COBOL/CICS Services
│ │
Db2 ← API/MQ → RDS
│ │
Batch AnalyticsIsso também é modernização.
Talvez seja uma modernização melhor.
Mainframe não precisa desaparecer para AWS existir.
AWS não precisa substituir IBM Z para gerar valor.
O objetivo deveria ser colocar cada workload onde faz sentido técnico, econômico e operacional.
🏎️ 26. Performance: “funciona” é uma palavra perigosíssima
Suponha que uma transação CICS respondesse em:
40 msA nova aplicação responde em:
480 msFunciona?
Sim.
É equivalente?
Talvez não.
Agora multiplique pela quantidade de transações.
Adicione network latency.
Database round trips.
APIs.
TLS.
Logs.
Tracing.
De repente aquela diferença aparentemente pequena torna-se enorme.
Modernização precisa de baseline antes da migração.
Sem baseline você termina dizendo:
“Parece mais lento.”
Isso não é engenharia.
💰 27. E existe FinOps
Outro easter egg escondido sob a mesa do laboratório.
No mainframe alguém pode reclamar:
“MIPS são caros!”
Migramos para cloud.
Então descobrimos:
EC2
RDS
storage
IOPS
snapshots
data transfer
NAT
logs
monitoring
backup
licenses
supporte percebemos que cloud não significa:
barato.
Significa principalmente:
modelo econômico diferente.
Se não medirmos consumo, uma arquitetura elasticamente maravilhosa pode gerar uma conta elasticamente maravilhosa também.
👄 28. “Don’t dream it. Be it.”
Chegamos finalmente à grande lição de Frank-N-Furter.
Não devemos ter medo de transformar sistemas.
COBOL pode viver em novas plataformas.
Pode participar de pipelines modernos.
Pode trabalhar com Git.
Pode ser automatizado com Ansible.
Pode ter infraestrutura criada com Terraform.
Pode conversar com cloud.
Pode expor APIs.
Pode entrar num processo CI/CD.
Não existe qualquer contradição nisso.
O problema começa quando confundimos modernização com maquiagem tecnológica.
Trocar:
z/OSpor:
Linuxnão moderniza automaticamente arquitetura.
Trocar:
Db2por:
PostgreSQLnão moderniza automaticamente dados.
Trocar:
JCLpor:
YAMLnão moderniza automaticamente processos.
E trocar:
datacenterpor:
AWSnão moderniza automaticamente engenharia.
🧠 29. A verdadeira modernização
Para mim, modernização aparece quando conquistamos:
REPRODUCIBILITY
+
AUTOMATION
+
OBSERVABILITY
+
TRACEABILITY
+
SECURITY
+
TESTABILITY
+
RESILIENCE
+
MAINTAINABILITYSe conseguimos isso mantendo COBOL?
Excelente.
Se parte precisa ser reescrita?
Pode fazer sentido.
Se outra parte permanece no IBM Z?
Perfeitamente possível.
Se determinado workload vai para AWS?
Ótimo.
Tecnologia é consequência da decisão arquitetural.
Não deveria ser sua causa.
🥚 Easter egg — 03:17 no castelo
Naturalmente precisamos deixar uma pequena surpresa.
São 03:17 da madrugada.
O telefone toca.
Produção parou.
O dashboard está verde.
EC2:
RUNNINGRDS:
AVAILABLECPU:
12%Memory:
41%CloudWatch:
NO INFRASTRUCTURE ALARMMas o batch não termina.
Um engenheiro olha para outro.
Ninguém entende.
Então aparece um veterano COBOL carregando uma caneca de café.
Ele olha cinco minutos para os logs e pergunta:
“Onde está o arquivo que o JOB anterior deveria ter criado?”
Silêncio.
O arquivo não existe.
O JOB anterior terminou com RC=04.
O novo scheduler considerou RC=04 sucesso.
O sistema antigo possuía uma regra que tratava aquele retorno especificamente.
Ela nunca apareceu no diagrama de migração.
Frank-N-Furter olha para sua criatura.
A criatura olha para Frank.
E o veterano toma outro gole de café.
O COBOL havia sido migrado perfeitamente.
O conhecimento operacional, não.
☕ 30. A lição final do Bellacosa Mainframe
Há algo profundamente fascinante nesses sistemas antigos.
Quando encontramos um programa COBOL escrito em 1989, atualizado em 1997, alterado em 2008, integrado com uma API em 2019 e ainda executando em 2026, não estamos olhando simplesmente para código legado.
Estamos olhando para história empresarial executável.
Cada IF.
Cada copybook.
Cada DD.
Cada tabela.
Cada fila.
Cada estranho RC=04.
Pode existir porque alguma coisa aconteceu.
Alguém tomou uma decisão.
Algum problema ocorreu.
Alguma regra comercial nasceu.
Algum cliente reclamou.
Algum auditor exigiu.
Alguma madrugada de produção ensinou uma lição.
Por isso, quando alguém entrar no laboratório segurando Terraform numa mão e Ansible na outra, não devemos impedi-lo.
Muito pelo contrário.
Acendam as máquinas.
Preparem AWS.
Construam pipelines.
Versionem tudo.
Automatizem.
Observem.
Testem.
Modernizem.
Só não cometam o erro de Frank-N-Furter:
não fiquem tão apaixonados pela nova criatura a ponto de esquecer de compreender o mundo no qual ela terá de sobreviver.
Porque, no final, a pergunta mais importante de uma modernização COBOL não é:
“Conseguimos fazê-lo rodar na AWS?”
É:
“Conseguimos preservar quarenta anos de comportamento, regras, dependências e conhecimento — eliminando aquilo que ficou obsoleto e melhorando aquilo que realmente precisava mudar?”
Se a resposta for sim, então podem aumentar o volume.
As luzes do laboratório podem acender.
Terraform pode subir a infraestrutura.
Ansible pode executar o playbook.
Jenkins pode promover o artefato.
CloudWatch pode começar a observar.
E Frank-N-Furter finalmente poderá anunciar:
⚡ “IT'S ALIVE!”
Enquanto o velho programador COBOL, sentado discretamente no fundo do laboratório, acrescentará:
“Muito bonito. Agora vamos ver se fecha o batch antes das seis.” ☕👄⚡
