Git, GitHub e DevOps para Profissionais IBM Z Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

 

Bellacosa Mainframe e o Git Github e DevOps para Mainframers

☕🚀 Um Café no Bellacosa Mainframe

Git, GitHub e DevOps para Profissionais IBM Z

Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

"Deleted your code by mistake? Without Git, it's gone forever."

Confesso que, ao observar aqueles infográficos coloridos sobre Git e DevOps, senti algo curioso.

Em poucos segundos eles conseguiram condensar uma transformação tecnológica que levou quase quarenta anos para acontecer.

Para muitos jovens desenvolvedores, Git sempre existiu.

Para nós, veteranos do Mainframe, sabemos que não foi assim.

Nós vivemos outra realidade.

Vivemos a era dos datasets PDS.

Vivemos a era dos backups manuais.

Vivemos a era do Panvalet.

Do Librarian.

Do Endevor.

Do Changeman.

Do SCLM.

Do ISPW.

Do membro COBOL001.

Do COBOL001.BKP.

Do COBOL001.OLD.

Do COBOL001.TESTE.

Do COBOL001.NOVO.

Do COBOL001.NOVO2.

Do COBOL001.NOVO3.

E, inevitavelmente, do lendário:

COBOL001.FINAL

COBOL001.FINAL2

COBOL001.FINAL_DEFINITIVO

COBOL001.FINAL_DEFINITIVO_OK

COBOL001.AGORA_VAI

Parece piada.

Mas muitos de nós trabalhamos exatamente dessa maneira.

E foi justamente para resolver esse caos que surgiu uma das ferramentas mais importantes da história da Engenharia de Software.

Git.

E não estou exagerando.

Git talvez seja tão revolucionário para o desenvolvimento moderno quanto o JES2 foi para processamento batch, quanto o CICS foi para processamento online ou quanto o DB2 foi para persistência transacional.

Git mudou a maneira como produzimos software.

Bellacosa Mainframe e a evolucao da gestao dos fontes

A primeira geração do controle de versões

Antes do Git existiam várias abordagens.

RCS.

SCCS.

CVS.

Visual SourceSafe.

Subversion.

ClearCase.

Perforce.

Cada um tentou resolver o mesmo problema.

Como permitir que múltiplas pessoas trabalhem no mesmo código sem destruir o trabalho umas das outras?

No Mainframe, resolvemos isso de forma diferente.

Panvalet.

Librarian.

Endevor.

ISPW.

Changeman.

Essas ferramentas foram brilhantes.

E continuam sendo.

Especialmente em ambientes regulados.

Bancos.

Seguradoras.

Governo.

Utilities.

Mas havia uma diferença.

Grande parte delas era centralizada.

Tudo dependia de um servidor.

Git mudou isso.

Git é distribuído.

E isso altera completamente a arquitetura do desenvolvimento.

O que realmente é Git?

A maioria dos cursos ensina:

Git é um sistema de versionamento.

Tecnicamente está correto.

Mas é uma definição pobre.

Git é muito mais.

Git é um banco de dados.

Git é uma máquina do tempo.

Git é um mecanismo de auditoria.

Git é uma ferramenta de colaboração.

Git é um sistema de rastreabilidade.

Git é um gatilho para automação.

Git é praticamente o sistema nervoso central do DevOps moderno.

Cada commit registra:

Quem alterou.

Quando alterou.

Por que alterou.

Qual requisito atendeu.

Qual incidente corrigiu.

Qual sprint participou.

Qual história de usuário foi implementada.

Qual vulnerabilidade foi mitigada.

Git não apenas salva arquivos.

Git preserva conhecimento organizacional.

O segredo escondido do Git

Poucos profissionais conhecem sua arquitetura interna.

Git não armazena arquivos.

Git armazena objetos.

Blob.

Tree.

Commit.

Tag.

Blob representa dados.

Tree representa diretórios.

Commit representa estados.

Tag representa marcos.

Cada commit possui um hash.

Durante muitos anos SHA-1.

Hoje caminhando para SHA-256.

Um commit não é uma diferença.

Ele é uma fotografia completa.

Um snapshot.

É por isso que Git consegue voltar meses no passado.

Como um SMF para código-fonte.

Aliás...

Talvez essa seja a analogia perfeita para um sysprog.

Git é quase um SMF de desenvolvimento.

Cada alteração gera um registro permanente.

O Sysprog e o Git

Talvez alguns sysprogs pensem:

"Mas Git é coisa de desenvolvedor."

Não.

Não mais.

Hoje praticamente toda infraestrutura está migrando para Infrastructure as Code.

Parmlibs.

Policies.

WLM.

NetView.

SA z/OS.

Ansible.

Terraform.

Scripts REXX.

Procedures.

JCL.

USS scripts.

Tudo pode estar em Git.

Imagine uma alteração em uma política WLM.

Antigamente:

Editar.

Salvar.

Copiar.

Torcer.

Hoje:

Criar branch.

Modificar.

Commit.

PR.

Review.

Merge.

Deploy automatizado.

Rollback imediato.

A governança melhora absurdamente.

O Sysadmin moderno também virou desenvolvedor

Existe uma transformação interessante acontecendo.

Sysadmins estão programando.

Desenvolvedores estão automatizando infraestrutura.

DBAs escrevem pipelines.

Sysprogs utilizam APIs REST.

Todos começam a convergir.

A linha entre operações e desenvolvimento desaparece.

Foi exatamente isso que criou DevOps.

DevOps não é ferramenta

Essa talvez seja a maior confusão do mercado.

DevOps não é Jenkins.

Não é GitHub.

Não é Kubernetes.

Não é Docker.

Não é Ansible.

DevOps é cultura.

É reduzir silos.

Eliminar burocracias.

Aproximar pessoas.

Automatizar processos.

Aumentar feedback.

Reduzir tempo de entrega.

No Mainframe isso é extremamente relevante.

Porque o Mainframe sempre teve uma cultura muito compartimentalizada.

Equipe COBOL.

Equipe DB2.

Equipe CICS.

Equipe Storage.

Equipe RACF.

Equipe Sysprog.

Equipe Operações.

Equipe Middleware.

Equipe Rede.

Equipe Segurança.

DevOps propõe outra visão.

Todos trabalham pelo mesmo objetivo.

Entregar valor ao negócio.

GitHub não é Git

Muitos iniciantes confundem.

Git é tecnologia.

GitHub é plataforma.

GitLab é plataforma.

Bitbucket é plataforma.

Azure DevOps é plataforma.

Git continua sendo Git.

Independentemente da hospedagem.

GitHub adicionou uma camada extremamente poderosa.

Issues.

Actions.

Codespaces.

Security.

Dependabot.

Packages.

Container Registry.

Wiki.

Pull Requests.

Tudo integrado.

Pull Request: a maior revolução social do desenvolvimento

Eu particularmente considero Pull Request uma das melhores invenções da engenharia moderna.

Porque ela resolve algo difícil.

Compartilhar conhecimento.

Imagine um desenvolvedor COBOL júnior.

Ele escreve:

MOVE WS-CPF TO WS-TEMP

Um desenvolvedor sênior comenta:

"Poderíamos validar antes."

Outro comenta:

"Talvez usar EVALUATE seja melhor."

Outro:

"Precisamos mascarar LGPD."

Resultado?

O código melhora.

O profissional melhora.

A equipe melhora.

A empresa melhora.

PR é mentoria embutida.

O medo do merge conflict

Todo desenvolvedor já sentiu frio na barriga.

git pull

CONFLICT

Automatic merge failed.

Para iniciantes parece um desastre.

Para equipes maduras é rotina.

Conflitos indicam colaboração.

Duas pessoas trabalharam na mesma área.

Git apenas pede ajuda.

Ele não consegue decidir sozinho.

Você decide.

Git apenas documenta.

Git Flow versus GitHub Flow

Durante anos utilizamos Git Flow.

Main.

Develop.

Feature.

Release.

Hotfix.

Funciona muito bem.

Especialmente em bancos.

Porém empresas modernas começaram simplificar.

GitHub Flow.

Main.

Feature.

PR.

Merge.

Deploy.

Google foi além.

Trunk Based Development.

Branches curtíssimas.

Commits pequenos.

Integração contínua.

Menos divergência.

Menos conflitos.

Mais velocidade.

Git para COBOL Developers

Aqui entramos em um ponto fascinante.

Durante muito tempo dizia-se:

COBOL não combina com Git.

Hoje isso é completamente falso.

IBM DBB.

IBM Dependency Based Build.

zAppBuild.

Z Open Editor.

Rocket Git.

Git Integration for Endevor.

ISPW Git Integration.

IDz.

Wazi Developer.

VS Code.

Tudo isso mudou o cenário.

Hoje um desenvolvedor COBOL pode trabalhar assim.

Abrir VS Code.

Editar programa COBOL.

Executar testes.

Commit.

Push.

Criar PR.

Executar pipeline.

Compilar.

Linkedit.

DB2 Bind.

Newcopy CICS.

Deploy.

Exatamente como Java.

Exatamente como Python.

Exatamente como Node.

Jenkins: o operador automático

Se Git é o cérebro.

Jenkins é o operador.

Ele observa commits.

Dispara builds.

Executa testes.

Compila COBOL.

Gera relatórios.

Aciona SonarQube.

Publica artefatos.

Executa deploy.

Notifica equipes.

No fundo, Jenkins faz o papel que muitos operadores humanos executavam.

Só que 24 horas por dia.

Sem esquecer etapas.

Sem distrações.

GitOps: talvez a próxima revolução

GitOps é simples.

Tudo é Git.

Deseja mudar um cluster Kubernetes?

Commit.

Deseja alterar firewall?

Commit.

Deseja atualizar pipeline?

Commit.

Deseja modificar política?

Commit.

Git torna-se a fonte única da verdade.

Single Source of Truth.

Isso é extremamente poderoso.

Porque elimina configurações manuais.

Elimina servidores "snowflake".

Elimina ambientes misteriosos.

Tudo fica reproduzível.

E a segurança?

Segurança também mudou.

DevSecOps nasceu justamente aqui.

SAST.

DAST.

Dependency Scan.

Secrets Detection.

SBOM.

Tudo integrado ao pipeline.

O desenvolvedor faz commit.

Ferramentas verificam.

Bibliotecas vulneráveis.

Credenciais expostas.

Falhas conhecidas.

Antes de chegar em produção.

No Mainframe isso pode incluir:

RACF reviews.

JCL analysis.

CICS security checks.

DB2 privilege validation.

SMF auditing.

O papel do Sysprog em 2026

Antigamente o Sysprog era apenas administrador.

Hoje é arquiteto.

Automatizador.

Consultor.

Especialista em APIs.

Especialista em observabilidade.

Especialista em pipelines.

Especialista em integração.

Especialista em segurança.

Sysprog moderno entende:

Git.

GitHub.

GitLab.

Ansible.

Python.

REXX.

Jenkins.

OpenShift.

Containers.

z/OSMF.

Zowe.

REST APIs.

Porque o Mainframe deixou de ser uma ilha.

Ele tornou-se parte do ecossistema corporativo.

O novo profissional IBM Z

Acredito que o profissional IBM Z de maior valor em 2026 possui uma característica interessante.

Ele pensa como um desenvolvedor.

Age como um administrador.

Automatiza como um engenheiro DevOps.

Protege como um especialista em segurança.

E governa como um arquiteto.

Ele consegue conversar com:

Desenvolvedor Java.

Equipe Cloud.

Kubernetes.

Segurança.

Storage.

Networking.

Data Science.

IA.

Sem abandonar aquilo que torna o Mainframe único.

Confiabilidade.

Escalabilidade.

Disponibilidade.

Integridade transacional.

Processamento massivo.

Pensando durante o café

Talvez a grande mensagem escondida por trás daqueles simpáticos desenhos coloridos seja esta:

Git não substitui o conhecimento Mainframe.

Git potencializa o conhecimento Mainframe.

Ele não aposenta COBOL.

Ele amplia o alcance do COBOL.

Ele não elimina o Sysprog.

Ele transforma o Sysprog em um engenheiro de plataforma.

Ele não mata operações.

Ele automatiza operações repetitivas.

A próxima geração de profissionais IBM Z provavelmente não conhecerá Panvalet.

Talvez nunca utilize Librarian.

Possivelmente jamais veja um Changeman clássico.

Mas certamente abrirá um Pull Request.

Criará uma branch.

Executará uma pipeline.

Fará deploy automatizado.

E continuará processando bilhões de transações por dia em um IBM Z.

Porque, no final das contas, o objetivo nunca foi Git.

Nunca foi GitHub.

Nunca foi Jenkins.

Nunca foi Kubernetes.

O objetivo sempre foi o mesmo desde os tempos do System/360.

Entregar software confiável.

Mais rápido.

Mais seguro.

Mais auditável.

Mais sustentável.

E, se possível, com uma boa xícara de café ao lado do teclado 3270.

 

Bellacosa Mainframe e a tecnica de cloud repatriation

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:

"O futuro está na nuvem."

Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.

As apresentações dos fornecedores mostravam um cenário quase perfeito.

Tudo seria:

• mais rápido;

• mais moderno;

• mais simples;

• mais seguro;

• mais barato.

Executivos ficaram encantados.

Arquitetos embarcaram na jornada.

Consultorias venderam projetos bilionários.

E milhares de empresas iniciaram aquilo que ficou conhecido como:

Cloud Migration.

Mas alguns anos depois algo inesperado começou a acontecer.

Empresas gigantes passaram a fazer o caminho inverso.

Sim.

O movimento contrário.

Retirar sistemas da nuvem.

Trazer aplicações de volta para datacenters próprios.

Mover cargas para ambientes especializados.

Consolidar plataformas.

Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:

Cloud Repatriation.

Ou simplesmente:

Repatriação da Nuvem.

E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.

Porque ele está mudando a forma como as empresas enxergam tecnologia.

---

O sonho da nuvem

Vamos voltar alguns anos.

Imagine uma empresa tradicional.

Ela possui:

• servidores físicos;

• storage;

• rede;

• datacenter;

• equipe de infraestrutura.

Tudo precisa ser comprado.

Tudo precisa ser instalado.

Tudo precisa ser mantido.

Quando a nuvem chegou, a promessa parecia revolucionária.

Ao invés de comprar:

• você alugaria.

Ao invés de esperar semanas:

• criaria recursos em minutos.

Ao invés de investir milhões:

• pagaria apenas pelo uso.

Parecia perfeito.

E para muitas situações realmente era.

---

O nascimento do "Cloud First"

Entre 2015 e 2022 surgiu uma expressão muito popular.

Cloud First.

Ou seja:

"A nuvem primeiro."

Toda nova solução deveria nascer em cloud.

Muitas organizações foram além.

Não apenas criaram sistemas novos.

Também migraram sistemas antigos.

Tudo virou candidato à nuvem.

ERP.

CRM.

Banco de dados.

Analytics.

Arquivos.

Aplicações críticas.

Em muitos casos sem uma análise profunda de custo-benefício.

---

A pergunta que ninguém fazia

Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:

"Quanto isso custará daqui a cinco anos?"

A maioria analisava apenas:

• velocidade;

• facilidade;

• inovação.

Mas ignorava:

• crescimento;

• consumo;

• escalabilidade financeira.

A conta parecia pequena no início.

Mas crescia silenciosamente.

---

A armadilha do sucesso

Imagine uma fintech.

Primeiro ano:

100 mil clientes.

Segundo ano:

1 milhão.

Terceiro ano:

10 milhões.

Quarto ano:

50 milhões.

Tudo parece ótimo.

Mas existe um detalhe.

Cada cliente gera:

• armazenamento;

• processamento;

• logs;

• backups;

• monitoramento;

• tráfego de rede.

Quanto mais sucesso a empresa tem, maior fica a fatura.

O paradoxo é interessante.

O crescimento do negócio aumenta também o custo operacional da nuvem.

---

Quando chega a conta

É nesse momento que começa a repatriação.

Os diretores financeiros começam a fazer perguntas.

Por exemplo:

• Estamos usando tudo que pagamos?

• Precisamos realmente dessa configuração?

• Existe alternativa mais barata?

• O custo por transação está aumentando?

• O retorno continua justificando o investimento?

E muitas vezes a resposta é surpreendente.

Nem toda carga de trabalho se beneficia economicamente da nuvem.

---

A analogia da casa

Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.

No começo você mora de aluguel.

Faz sentido.

Você ainda está começando.

Precisa de flexibilidade.

Não quer investir muito.

Mas imagine que passaram vinte anos.

Você continua pagando aluguel.

Todo mês.

Sem parar.

Em algum momento surge a pergunta:

"Não seria melhor comprar?"

A repatriação nasce exatamente dessa reflexão.

---

O caso do Dropbox

Um dos exemplos mais famosos ocorreu com o Dropbox.

Durante anos a empresa utilizou cloud pública.

Mas conforme cresceu percebeu algo importante.

O volume de armazenamento era gigantesco.

A escala era enorme.

A previsibilidade era alta.

O resultado?

Passou a investir fortemente em infraestrutura própria.

A economia foi medida em centenas de milhões de dólares ao longo dos anos.

Isso chamou a atenção do mercado.

---

O caso da 37signals

Outro exemplo muito discutido foi a empresa por trás do Basecamp.

Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.

O argumento principal?

Economia.

Segundo eles, a redução de custos seria enorme.

A notícia gerou debates em toda a indústria.

---

O que isso ensina para uma Analista COBOL?

Ensina algo extremamente importante.

Tecnologia não é religião.

Não existe:

• Mainframe bom.

• Cloud ruim.

Nem o contrário.

Existe apenas:

o ambiente correto para a carga correta.

Essa é uma das maiores lições da arquitetura moderna.

---

Nem toda carga é igual

Imagine duas aplicações.

Primeira aplicação:

• Website promocional.

• Acessos variáveis.

• Crescimento imprevisível.

Cloud faz sentido.

Agora imagine:

• processamento de contas bancárias;

• liquidação financeira;

• batch noturno;

• milhões de transações previsíveis.

Talvez a análise econômica seja diferente.

Talvez uma plataforma especializada seja mais eficiente.

Talvez um mainframe seja mais competitivo.

Tudo depende do contexto.

---

O papel do Mainframe nessa história

É aqui que muitos jovens profissionais ficam surpresos.

Durante anos ouviram que o Mainframe estava desaparecendo.

Mas a realidade mostrou algo curioso.

Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.

Por quê?

Porque o Mainframe foi construído justamente para:

• alta escala;

• alta disponibilidade;

• processamento transacional;

• confiabilidade extrema.

Essas características continuam valiosas.

Muito valiosas.

---

O custo invisível da nuvem

Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.

Na cloud surgem custos menos óbvios.

Por exemplo:

• transferência de dados;

• snapshots;

• logs;

• replicação;

• monitoramento;

• APIs;

• tráfego entre regiões.

Cada item parece pequeno.

Somados podem se tornar gigantescos.

É por isso que tantas empresas passaram a adotar práticas de FinOps.

---

O nascimento do FinOps

FinOps significa:

Financial Operations.

Ou seja:

Operações financeiras aplicadas à tecnologia.

Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:

• Quem está consumindo recursos?

• Quanto custa cada aplicação?

• Qual é o custo por cliente?

• Qual é o custo por transação?

Isso praticamente não existia no início da corrida para a nuvem.

---

A verdade que ninguém gosta de ouvir

Existe uma verdade que incomoda muitos vendedores de tecnologia.

Nem toda inovação reduz custos.

Algumas aumentam custos.

Mas aumentam receita.

E isso pode ser perfeitamente aceitável.

Cloud frequentemente se encaixa nesse cenário.

A empresa paga mais.

Mas cresce mais rápido.

Lança produtos mais rapidamente.

Conquista clientes mais cedo.

Portanto o custo adicional pode valer a pena.

---

Então por que repatriar?

Porque chega um momento em que determinadas cargas se tornam:

• previsíveis;

• estáveis;

• maduras.

Nesse ponto a elasticidade da cloud perde parte do valor.

E a eficiência operacional começa a ganhar importância.

A pergunta muda.

Deixa de ser:

"Como crescer?"

E passa a ser:

"Como operar com eficiência?"

---

O futuro é híbrido

Talvez essa seja a maior conclusão.

O futuro não parece ser:

• tudo na cloud;

• tudo no mainframe;

• tudo on-premises.

O futuro parece híbrido.

Cada carga de trabalho executada no ambiente mais adequado.

É exatamente isso que vemos nos grandes bancos.

Itaú.

Bradesco.

Banco do Brasil.

Santander.

Caixa.

Todos operam ambientes mistos.

Cloud.

Linux.

Containers.

APIs.

Mainframe.

Tudo convivendo.

Tudo integrado.

---

O que você deve aprender como profissional

Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.

Pelo contrário.

O mercado está procurando profissionais que entendam integração.

Profissionais que consigam conversar sobre:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Kubernetes;

• IBM Z;

• Arquitetura distribuída.

Porque a verdadeira transformação digital não consiste em destruir o legado.

Consiste em conectá-lo ao futuro.

---

Conclusão: O Retorno da Maturidade Tecnológica

Cloud Repatriation não significa fracasso da nuvem.

Também não significa vitória do Mainframe.

Significa algo muito mais interessante.

Significa maturidade.

O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.

Nem por marketing.

Nem por tendências.

Ela deve ser escolhida por critérios objetivos:

• custo;

• desempenho;

• segurança;

• disponibilidade;

• escalabilidade.

A nuvem continuará crescendo.

Os datacenters continuarão existindo.

Os mainframes continuarão processando bilhões de transações.

E as arquiteturas híbridas se tornarão cada vez mais comuns.

Para uma Analista COBOL Júnior, essa é uma excelente notícia.

Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.

O profissional do futuro não será aquele que conhece apenas uma tecnologia.

Será aquele que entende quando usar cada uma delas.

E talvez essa seja a maior lição da Cloud Repatriation.

Às vezes a inovação não está em mover tudo para a nuvem.

Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.

 

Bellacosa Mainframe quando o sonho da nuvem virada pesadelo

☕💸☁️ CLOUD BILL SHOCK — QUANDO A FATURA DA NUVEM CHEGA E O MAINFRAME COMEÇA A PARECER BARATO

Existe um momento muito curioso na vida de quase toda empresa que embarca na jornada da computação em nuvem.

No início tudo parece maravilhoso.

O desenvolvedor cria um servidor em poucos minutos.

O ambiente de testes nasce instantaneamente.

Os sistemas escalam sozinhos.

As equipes ganham agilidade.

Os executivos sorriem.

Os arquitetos comemoram.

Os fornecedores fazem apresentações cheias de gráficos coloridos.

E então chega a primeira fatura realmente grande.

Nesse momento nasce um fenômeno que ficou conhecido mundialmente como:

Cloud Bill Shock.

Ou, em português:

O Choque da Fatura da Nuvem.

Para muitos profissionais jovens, especialmente quem está começando carreira em COBOL e Mainframe, esse termo parece estranho.

Afinal, durante anos ouvimos que a nuvem era mais moderna, mais simples e mais barata.

Mas a realidade dos grandes ambientes corporativos mostrou uma verdade muito interessante.

Cloud pode ser fantástica.

Cloud pode ser revolucionária.

Cloud pode acelerar negócios.

Mas cloud nem sempre é barata.

E algumas empresas descobriram isso da forma mais dolorosa possível.

Ao abrir a fatura no final do mês.

---

O que uma Analista COBOL Júnior precisa entender

Vamos começar do início.

Imagine que você trabalha em um banco tradicional.

Existe um ambiente mainframe que processa:

• contas correntes;

• cartões;

• PIX;

• empréstimos;

• aplicações financeiras.

Tudo funciona há décadas.

O sistema está pago.

A infraestrutura está instalada.

Os profissionais conhecem a plataforma.

Os processos são estáveis.

Então surge a pergunta:

"Por que não colocar tudo na nuvem?"

Parece uma pergunta simples.

Mas a resposta é extremamente complexa.

Porque existe uma enorme diferença entre:

custo inicial
e
custo operacional contínuo.

---

O encanto da nuvem

Imagine uma startup recém-criada.

Ela possui:

• 5 desenvolvedores;

• 1 produto;

• 100 clientes.

Comprar um datacenter próprio seria loucura.

A nuvem resolve o problema.

Você cria:

• servidores;

• bancos de dados;

• armazenamento;

• monitoramento.

Tudo com poucos cliques.

O modelo parece perfeito.

E realmente é.

Nesse estágio.

---

O problema da escala

Agora imagine que essa startup cresceu.

Não possui mais:

• 100 clientes.

Possui:

• 1 milhão.

Depois:

• 10 milhões.

Depois:

• 50 milhões.

Depois:

• 100 milhões.

Agora o cenário muda completamente.

Cada operação gera consumo.

Cada acesso gera consumo.

Cada consulta gera consumo.

Cada byte armazenado gera consumo.

Cada transferência de dados gera consumo.

Cada serviço adicional gera consumo.

A conta começa a crescer.

E cresce rapidamente.

---

O aluguel invisível

Uma forma simples de explicar cloud para um iniciante é esta:

Mainframe tradicional muitas vezes funciona como casa própria.

Cloud funciona como aluguel.

Imagine um apartamento alugado.

No começo parece excelente.

Pouco investimento inicial.

Entrada reduzida.

Flexibilidade.

Mas depois de vinte anos pagando aluguel...

Você percebe que gastou uma fortuna.

Cloud possui comportamento parecido.

Você paga continuamente por:

• CPU;

• memória;

• armazenamento;

• rede;

• backup;

• tráfego;

• monitoramento;

• segurança.

A conta nunca para.

---

O dia em que o financeiro descobre a AWS

Existe uma história que se repete em inúmeras empresas.

A área técnica está feliz.

A inovação está acelerada.

Os desenvolvedores estão satisfeitos.

Então o departamento financeiro recebe a fatura.

Primeiro mês:

US$ 5 mil.

Segundo mês:

US$ 20 mil.

Terceiro mês:

US$ 80 mil.

Sexto mês:

US$ 500 mil.

Um ano depois:

milhões de dólares.

Nesse momento alguém pergunta:

"Por que estamos gastando tudo isso?"

E nasce uma investigação corporativa.

---

O caso do armazenamento

Uma analista COBOL talvez pense:

"Mas armazenamento é barato."

Sim.

Individualmente.

Mas vamos fazer uma conta simples.

Imagine um banco com:

• 100 milhões de clientes;

• documentos digitalizados;

• extratos;

• imagens;

• logs;

• backups;

• auditoria.

Estamos falando de petabytes.

Talvez dezenas de petabytes.

Quando o volume cresce, cada centavo por gigabyte se transforma em milhões.

---

O inimigo chamado Data Transfer

Existe uma cobrança que assusta muitos arquitetos.

Transferência de dados.

Os provedores de nuvem adoram falar sobre armazenamento.

Sobre CPU.

Sobre inteligência artificial.

Mas existe um detalhe.

Mover dados também custa dinheiro.

Muito dinheiro.

Imagine:

• aplicativos móveis;

• APIs;

• integrações;

• analytics;

• parceiros externos.

Bilhões de chamadas.

Bilhões de respostas.

Terabytes trafegando diariamente.

Cada pacote possui custo.

---

O pesadelo do ambiente esquecido

Todo analista experiente já viu isso.

Um desenvolvedor cria:

• servidor de teste;

• banco temporário;

• ambiente experimental.

O projeto termina.

O ambiente fica ligado.

Dias passam.

Meses passam.

Anos passam.

Ninguém percebe.

Mas a cobrança continua.

Existem empresas pagando milhares de dólares por recursos esquecidos.

---

O efeito multiplicador dos microsserviços

Os microsserviços trouxeram inúmeras vantagens.

Mas também criaram novos desafios.

No mundo tradicional talvez existisse:

• uma aplicação;

• um banco de dados.

No mundo moderno podemos ter:

• centenas;

• milhares;

• dezenas de milhares de serviços.

Cada um consumindo:

• CPU;

• memória;

• armazenamento;

• rede.

Separadamente parecem baratos.

Juntos tornam-se gigantescos.

---

Quando o Mainframe entra na conversa

É aqui que uma analista COBOL começa a entender o debate.

Um mainframe não é vendido como servidor barato.

Nunca foi.

Mas existe algo impressionante nele.

Consolidação.

Um único IBM Z moderno pode processar volumes absurdos de transações.

Em muitos casos substituindo centenas ou milhares de servidores distribuídos.

O resultado é que algumas cargas financeiras apresentam:

• menor consumo energético;

• menor ocupação física;

• menor administração;

• menor complexidade operacional.

Por isso o cálculo econômico não é tão simples quanto parece.

---

O choque das empresas famosas

Nos últimos anos surgiu um movimento chamado:

Cloud Repatriation

Traduzindo:

"Trazer sistemas de volta."

Empresas que migraram tudo para cloud começaram a revisar decisões.

Não porque a nuvem fosse ruim.

Mas porque certas cargas de trabalho ficaram caras demais.

Algumas descobriram economias milionárias ao mover parte dos ambientes para:

• infraestrutura própria;

• colocation;

• plataformas especializadas.

O mercado percebeu que não existe solução mágica.

---

O erro mais comum dos iniciantes

Muitos profissionais novos acreditam que arquitetura é apenas tecnologia.

Mas arquitetura também é economia.

Um arquiteto precisa entender:

• desempenho;

• segurança;

• disponibilidade;

• custos.

A melhor solução técnica do mundo pode fracassar se custar dez vezes mais que o necessário.

---

O que os bancos aprenderam

Os grandes bancos possuem uma experiência valiosa.

Eles processam bilhões de transações há décadas.

Por isso normalmente adotam arquitetura híbrida.

Não colocam tudo na cloud.

Também não deixam tudo no mainframe.

Cada ambiente recebe a carga mais adequada.

Por exemplo:

Aplicativo móvel?

Cloud.

Machine Learning?

Cloud.

Analytics?

Cloud.

Core bancário?

Talvez mainframe.

Liquidação financeira?

Talvez mainframe.

Processamento crítico?

Talvez mainframe.

---

O paradoxo que ninguém conta

Aqui está a parte mais interessante.

O objetivo da cloud nunca foi ser sempre mais barata.

O objetivo principal era:

agilidade.

Você consegue lançar produtos rapidamente.

Experimentar ideias.

Criar novos serviços.

Escalar em minutos.

Essa velocidade possui valor.

Muitas vezes o ganho de negócio compensa o aumento de custo.

Por isso empresas continuam investindo bilhões em nuvem.

---

O que uma Analista COBOL deve aprender com isso

Talvez a maior lição seja esta.

Não existe guerra entre Mainframe e Cloud.

Essa guerra só existe em apresentações simplificadas.

No mundo real os dois convivem.

E convivem muito bem.

O profissional moderno precisa compreender:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Integração;

• Arquitetura distribuída.

Porque o mercado não procura especialistas que conhecem apenas um lado.

Procura profissionais que entendem como tudo se conecta.

---

Conclusão: Quando a Fatura Vira Professor

Cloud Bill Shock é uma das lições mais importantes da tecnologia moderna.

Ele nos lembra que inovação possui custo.

Escalabilidade possui custo.

Conveniência possui custo.

Flexibilidade possui custo.

A nuvem transformou a indústria.

Permitiu o nascimento de empresas como Nubank, Mercado Pago e centenas de fintechs.

Mas também ensinou uma lição valiosa.

Quando os números chegam à casa dos milhões de clientes e bilhões de transações, a discussão deixa de ser tecnológica.

Passa a ser econômica.

E é justamente nesse momento que muitos executivos voltam a olhar para tecnologias que julgavam ultrapassadas.

Mainframe.

COBOL.

CICS.

DB2.

IBM Z.

Não porque sejam antigos.

Mas porque continuam resolvendo problemas extremamente difíceis com eficiência impressionante.

Por isso, da próxima vez que alguém disser que o futuro pertence apenas à nuvem, lembre-se de uma verdade que o mercado financeiro aprendeu ao longo das décadas:

A tecnologia mais moderna nem sempre é a mais barata.
A mais antiga nem sempre é a mais cara.
E a melhor arquitetura quase sempre é aquela que equilibra inovação, desempenho e custo.

É exatamente nesse ponto que nasce o verdadeiro arquiteto de sistemas.

E é exatamente aí que uma analista COBOL deixa de enxergar apenas código e começa a enxergar negócios.

 

Bellacosa Mainframe e uma visão do sistema bancario brasileiro

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

Existe uma frase que se tornou quase um mantra no mercado financeiro moderno:

"O futuro está na nuvem."

E é verdade.

Nubank, Inter, Mercado Pago, PicPay, PagBank e dezenas de fintechs brasileiras nasceram em arquiteturas modernas, utilizando APIs, microsserviços, containers, Kubernetes, inteligência artificial e infraestrutura cloud.

Mas existe uma realidade pouco comentada fora dos bastidores da tecnologia bancária.

Uma realidade que surpreende estudantes, jornalistas, executivos recém-chegados ao setor financeiro e até muitos profissionais de TI.

O dinheiro que movimenta bilhões de reais diariamente no Brasil continua passando por sistemas centrais executados em plataformas que nasceram décadas antes da internet comercial.

Sim.

Enquanto o cliente faz um PIX em um smartphone equipado com processadores capazes de executar bilhões de operações por segundo, uma parte significativa da infraestrutura que garante que aquele dinheiro chegue ao destino continua rodando em ambientes IBM Z, CICS, DB2, MQ e COBOL.

E isso não acontece por nostalgia.

Acontece porque funciona.

Muito bem.

---

O mito do "banco 100% digital"

Quando um banco digital aparece na televisão, geralmente a propaganda mostra:

• aplicativo moderno;

• cartão colorido;

• conta aberta em minutos;

• chatbot inteligente;

• investimentos com poucos cliques.

Tudo parece novo.

Tudo parece revolucionário.

Tudo parece distante do mundo dos grandes datacenters.

Mas existe uma diferença importante entre:

interface digital
e
infraestrutura financeira.

O cliente enxerga o aplicativo.

O sistema financeiro enxerga liquidação.

E são coisas completamente diferentes.

Um banco pode ter uma experiência totalmente digital e, ainda assim, depender de sistemas centrais extremamente robustos para realizar:

• liquidação financeira;

• compensação;

• controle contábil;

• reconciliação;

• registro de operações;

• cálculo de tarifas;

• processamento de empréstimos;

• integração com o Banco Central.

É nesse momento que entram os sistemas de missão crítica.

---

O que acontece quando você faz um PIX?

Vamos imaginar uma situação extremamente comum.

Você abre o aplicativo.

Transfere R$ 100 para um amigo.

A operação parece instantânea.

Na tela tudo ocorre em segundos.

Mas por trás dos bastidores existe uma verdadeira cadeia industrial de processamento.

O aplicativo envia a solicitação.

Uma API recebe o pedido.

Serviços de autenticação validam identidade.

Motores antifraude executam verificações.

Regras de compliance são avaliadas.

Sistemas de limites são consultados.

Dados cadastrais são verificados.

Mensagerias distribuem eventos.

Sistemas contábeis registram a operação.

Mecanismos de liquidação realizam o acerto financeiro.

Tudo isso antes que a mensagem "PIX realizado com sucesso" apareça na tela.

O usuário vê um clique.

O datacenter vê centenas de transações.

---

Onde entra o mainframe?

É aqui que muita gente se surpreende.

O mainframe raramente aparece na camada visual.

Ele normalmente opera na camada mais importante.

A camada onde não pode haver erro.

Imagine o seguinte cenário.

Se uma rede social ficar indisponível por 10 minutos, usuários reclamam.

Se um streaming cair durante uma série, pessoas ficam irritadas.

Mas se um banco perder o controle de saldos durante 10 minutos?

O problema pode atingir milhões de clientes.

Por isso os sistemas responsáveis pelos registros financeiros mais críticos precisam apresentar:

• disponibilidade extrema;

• consistência absoluta;

• segurança rigorosa;

• rastreabilidade completa;

• recuperação imediata.

São justamente essas características que fizeram os mainframes permanecerem relevantes.

---

O paradoxo da fintech

As fintechs surgiram prometendo romper com os bancos tradicionais.

Em muitos aspectos conseguiram.

Mudaram a experiência do cliente.

Reduziram burocracias.

Popularizaram contas digitais.

Criaram novos modelos de negócio.

Mas descobriram rapidamente uma verdade do mercado financeiro.

Movimentar dinheiro é muito mais difícil do que movimentar dados.

Enviar uma foto errada em uma rede social gera um transtorno.

Transferir R$ 10 milhões para a conta errada gera uma crise.

Por isso a arquitetura financeira moderna acabou evoluindo para um modelo híbrido.

Na superfície:

• cloud;

• APIs;

• microsserviços;

• inteligência artificial.

No núcleo:

• processamento transacional;

• bancos de dados críticos;

• mensageria corporativa;

• sistemas centrais de liquidação.

É uma combinação extremamente poderosa.

---

A nuvem descobriu que precisa do mainframe

Durante alguns anos surgiu uma narrativa bastante agressiva.

Muitos especialistas afirmavam que o mainframe desapareceria rapidamente.

A computação em nuvem seria suficiente para tudo.

A realidade mostrou algo diferente.

O que ocorreu foi integração.

Hoje observamos ambientes híbridos onde:

• Kubernetes conversa com CICS;

• APIs REST acessam programas COBOL;

• aplicações cloud consomem serviços do z/OS;

• eventos trafegam através do IBM MQ;

• microsserviços utilizam informações armazenadas em DB2.

Não houve substituição.

Houve convergência.

A nuvem não matou o mainframe.

A nuvem passou a conversar com ele.

---

O caso brasileiro

O Brasil possui um dos sistemas financeiros mais sofisticados do planeta.

Muitas vezes não percebemos isso.

PIX.

TED.

DOC.

Open Finance.

Cartões.

Boletos.

Débito automático.

Tudo isso precisa funcionar para centenas de milhões de contas.

Os números impressionam.

Bilhões de transações são processadas todos os meses.

Milhões de operações acontecem simultaneamente.

O sistema precisa funcionar:

• de madrugada;

• em feriados;

• durante promoções;

• na Black Friday;

• durante a Copa do Mundo;

• durante grandes eventos nacionais.

A infraestrutura necessária para suportar esse volume é gigantesca.

E boa parte dela continua baseada em tecnologias que nasceram décadas atrás, mas evoluíram continuamente.

---

O COBOL que ninguém vê

Poucas tecnologias sofreram tanto preconceito quanto o COBOL.

Para muitos profissionais jovens, COBOL parece uma relíquia.

Algo pertencente a museus de informática.

Mas existe um detalhe curioso.

Grande parte das pessoas que criticam COBOL utilizou sistemas processados por COBOL antes mesmo do café da manhã.

Salário.

PIX.

Cartão.

Financiamento.

Previdência.

Seguros.

Consórcios.

Tudo isso frequentemente passa por programas COBOL.

O motivo é simples.

Esses sistemas foram construídos ao longo de décadas.

Receberam investimentos bilionários.

Foram testados em condições extremas.

Acumularam conhecimento de negócio impossível de reproduzir rapidamente.

Muitas vezes o código representa mais valor do que a própria infraestrutura.

---

O banco invisível

Imagine um iceberg.

O cliente vê apenas a ponta.

Aplicativo.

Cartão.

Notificação.

Interface.

Mas abaixo da superfície existe uma massa gigantesca de tecnologia invisível.

Essa parte inclui:

• motores contábeis;

• sistemas regulatórios;

• integração com Banco Central;

• mecanismos de liquidação;

• auditoria;

• compliance;

• segurança.

É nesse universo invisível que o mainframe continua brilhando.

E justamente por ser invisível, raramente recebe o reconhecimento merecido.

---

Quando tudo funciona ninguém percebe

Existe uma ironia interessante no mundo da infraestrutura.

Quanto melhor um sistema funciona, menos as pessoas falam sobre ele.

Ninguém elogia um elevador por funcionar.

Ninguém agradece à rede elétrica por fornecer energia.

Ninguém faz uma postagem comemorando que o saldo bancário apareceu corretamente.

Mas quando ocorre uma falha?

Todo mundo percebe.

Por isso os sistemas centrais são projetados para uma missão simples:

não chamar atenção.

O sucesso é a invisibilidade.

---

O futuro não é cloud versus mainframe

Uma das maiores lições da última década foi perceber que a discussão estava errada.

A pergunta nunca deveria ter sido:

"Cloud ou Mainframe?"

A pergunta correta é:

"Como integrar os dois da melhor forma possível?"

Os líderes do mercado entenderam isso.

Hoje as arquiteturas mais modernas utilizam o melhor dos dois mundos.

Cloud para:

• inovação rápida;

• elasticidade;

• analytics;

• inteligência artificial.

Mainframe para:

• processamento massivo;

• transações críticas;

• consistência financeira;

• segurança corporativa.

O resultado é uma arquitetura híbrida extremamente eficiente.

---

A verdadeira transformação digital

Muitas empresas acreditam que transformação digital significa abandonar tudo que veio antes.

Mas a história mostra outra coisa.

Transformação digital bem-sucedida raramente consiste em destruir.

Consiste em evoluir.

Os sistemas que sustentam o mercado financeiro brasileiro representam décadas de conhecimento acumulado.

Substituí-los completamente seria como demolir uma usina hidrelétrica para construir um gerador portátil.

Não faz sentido.

O caminho inteligente é modernizar.

Expor APIs.

Integrar plataformas.

Automatizar processos.

Conectar o legado ao futuro.

---

O que os estudantes precisam entender

Quem está começando carreira em tecnologia frequentemente busca apenas as ferramentas mais recentes.

Isso é natural.

Mas existe uma lição valiosa.

As tecnologias que movimentam bilhões nem sempre são as mais populares nas redes sociais.

Muitas vezes são as mais confiáveis.

As mais estáveis.

As mais resilientes.

O profissional que entende:

• cloud;

• APIs;

• Kubernetes;

• segurança;

• mainframe;

• integração corporativa;

torna-se extremamente valioso para o mercado.

Porque consegue enxergar a arquitetura completa.

Não apenas a camada visível.

---

Conclusão: o coração continua batendo

Os maiores bancos digitais do Brasil nasceram na nuvem.

Foram criados por uma geração que cresceu falando de APIs, microsserviços e aplicações móveis.

Mudaram completamente a forma como os brasileiros se relacionam com o dinheiro.

Mas, ao crescerem, descobriram algo que os bancos tradicionais já sabiam há décadas.

No mercado financeiro, velocidade é importante.

Experiência do usuário é importante.

Inovação é importante.

Mas nada é mais importante do que confiança.

E confiança se constrói com sistemas capazes de operar dia após dia, ano após ano, movimentando bilhões de reais sem perder o controle de um único centavo.

Por isso, enquanto milhões de brasileiros fazem PIX, pagam boletos, investem, financiam imóveis e utilizam aplicativos modernos, existe uma infraestrutura silenciosa trabalhando nos bastidores.

Uma infraestrutura que raramente aparece nas propagandas.

Que quase nunca vira manchete.

Mas que continua sustentando o sistema financeiro nacional.

A nuvem trouxe inovação.

As fintechs trouxeram agilidade.

Os aplicativos trouxeram conveniência.

Mas, no coração de boa parte dessa engrenagem, o velho gigante continua trabalhando.

Discreto.

Confiável.

Resiliente.

Processando bilhões.

Como faz há décadas.

E, ao que tudo indica, continuará fazendo por muitos anos.

Bellacosa Mainframe e uma visão da integração mainframe + nuvem

☕🚀 Azure + IBM MQ + CICS + COBOL: Quando a Nuvem Descobre Que Ainda Precisa do Mainframe

A arquitetura híbrida que responde em milissegundos e movimenta bilhões sem que ninguém perceba

Existe uma frase que escuto há mais de trinta e cinco anos:

"O Mainframe está morrendo."

A primeira vez que ouvi isso foi quando ainda existiam fitas magnéticas por todos os lados, terminais 3270 ocupavam salas inteiras e a internet comercial engatinhava.

Depois ouvi novamente quando surgiram os ERPs.

Depois quando surgiram os Data Centers distribuídos.

Depois quando vieram os smartphones.

Depois quando chegaram os containers.

Depois quando Kubernetes virou moda.

Depois quando a nuvem se tornou o assunto do momento.

E agora escuto novamente com a Inteligência Artificial.

Curiosamente, enquanto todos anunciavam o funeral do Mainframe, ele continuava processando cartões de crédito, transações bancárias, reservas aéreas, operações de seguradoras, sistemas governamentais e bilhões de dólares diariamente.

Talvez o erro nunca tenha sido tecnológico.

Talvez o erro tenha sido imaginar que inovação significa substituir tudo o que existe.

Na prática, a verdadeira inovação costuma acontecer quando conseguimos conectar mundos aparentemente incompatíveis.

E poucas arquiteturas representam isso melhor do que a integração entre Microsoft Azure e IBM Mainframe utilizando IBM MQ, CICS e COBOL.

Estamos falando de uma arquitetura capaz de unir o melhor dos dois universos:

• Agilidade da nuvem

• Robustez do Mainframe

• Escalabilidade dos microsserviços

• Consistência transacional do CICS

• Segurança do IBM MQ

• Décadas de regras de negócio escritas em COBOL

Tudo funcionando como uma única plataforma.

---

O Grande Equívoco Sobre Modernização

Quando alguém fala em modernização, muitas pessoas imaginam algo parecido com isto:

Sistema Antigo
      ↓
Apagar Tudo
      ↓
Reescrever Tudo
      ↓
Sistema Novo

Na teoria parece simples.

Na prática costuma ser um desastre.

Imagine um banco que possui:

• 40 milhões de clientes

• 30 anos de regras de negócio

• milhares de programas COBOL

• dezenas de sistemas satélites

• integrações desconhecidas

Reescrever tudo pode levar anos.

Custar centenas de milhões.

E ainda introduzir novos erros.

Por isso os grandes bancos do mundo adotaram outro caminho.

Em vez de substituir o Mainframe, passaram a conectá-lo ao ecossistema digital.

É exatamente isso que esta arquitetura faz.

---

O Cliente Nem Imagina o Que Está Acontecendo

Imagine um cliente consultando saldo pelo aplicativo.

Ele toca um botão.

Em menos de um segundo recebe a resposta.

Para ele parece algo simples.

Mas nos bastidores ocorre uma verdadeira orquestra tecnológica.

O aplicativo chama uma API hospedada no Azure.

A API gera uma mensagem JSON.

Essa mensagem atravessa a rede.

Chega ao IBM MQ.

O MQ desperta uma transação CICS.

O CICS chama um programa COBOL.

O COBOL consulta DB2.

A resposta retorna pelo mesmo caminho.

Tudo isso em poucos milissegundos.

O usuário jamais perceberá.

E essa é justamente a beleza da arquitetura.

---

IBM MQ: O Carteiro Mais Confiável do Mundo Corporativo

Muitos profissionais mais jovens cresceram utilizando APIs REST.

Naturalmente surge a pergunta:

Por que usar MQ?

Porque sistemas críticos exigem garantias que HTTP sozinho não consegue fornecer.

Quando uma mensagem entra em uma fila MQ, ela não desaparece.

Ela permanece armazenada até ser processada.

Mesmo que:

• um servidor caia

• a rede falhe

• uma aplicação seja reiniciada

a mensagem continua lá.

Imagine uma transferência financeira de cem mil reais.

Você gostaria que ela dependesse exclusivamente de uma conexão HTTP momentânea?

Provavelmente não.

É por isso que bancos continuam apaixonados pelo MQ.

Ele foi criado para ambientes onde perder uma única mensagem pode significar prejuízo milionário.

---

Request-Reply: O Casamento Entre Dois Mundos

Existe um detalhe fascinante nessa arquitetura.

O mundo web é síncrono.

O mundo MQ é assíncrono.

São filosofias diferentes.

Quando um navegador faz uma requisição HTTP, ele espera uma resposta.

Quando uma aplicação grava uma mensagem em uma fila MQ, ela normalmente segue seu caminho.

Mas o usuário quer uma resposta imediata.

Surge então o padrão Request-Reply.

Funciona assim:

A aplicação envia uma mensagem para a fila REQUEST.

O Mainframe processa.

Depois envia uma resposta para uma fila REPLY.

A aplicação recupera a resposta e devolve ao usuário.

Parece simples.

Mas essa simplicidade esconde décadas de evolução arquitetural.

---

O Poder dos Identificadores

Aqui encontramos um dos elementos mais importantes de toda a solução.

O MsgId.

Cada mensagem recebe um identificador único.

Por exemplo:

A1B2C3D4E5

Quando a resposta é gerada, esse valor reaparece como CorrelId.

Dessa forma:

Request
MsgId = A1B2C3D4E5

Reply
CorrelId = A1B2C3D4E5

A aplicação consegue saber exatamente qual resposta pertence a qual requisição.

Sem isso seria impossível processar milhares de mensagens simultaneamente.

É como o número de protocolo de uma ligação para suporte.

Sem ele tudo viraria uma enorme confusão.

---

MQ Trigger: O Despertador do Mainframe

Uma das partes mais elegantes dessa arquitetura é o Trigger.

Imagine um operador sentado observando uma fila.

Sempre que chegasse uma mensagem ele iniciaria um programa.

Seria absurdo.

O MQ faz isso automaticamente.

Quando uma mensagem chega:

QUEUE DEPTH = 1

o Trigger entra em ação.

Instantaneamente ele inicia uma transação CICS.

Sem polling.

Sem scripts.

Sem agendadores.

Sem desperdício de CPU.

É uma solução extremamente elegante criada décadas antes do conceito moderno de eventos ganhar popularidade.

Na verdade, muitos sistemas chamados hoje de Event-Driven Architecture fazem algo conceitualmente muito parecido com o que MQ e CICS realizam há anos.

---

O Router Program: O Maestro da Orquestra

Após a ativação do Trigger entra em cena o Router Program.

Se eu tivesse que apontar o cérebro da arquitetura, seria ele.

Sua função é simples:

Receber.

Analisar.

Decidir.

Encaminhar.

Ele lê o payload.

Consulta tabelas de roteamento.

Avalia parâmetros.

E escolhe qual backend deverá executar o processamento.

Por exemplo:

CONSULTA_CLIENTE → CUST0001
PIX → PIX0001
CARTAO → CARD0001

Isso oferece enorme flexibilidade.

Novos serviços podem ser adicionados sem alterar toda a arquitetura.

Basta cadastrar uma nova regra.

É o equivalente corporativo de um controlador de tráfego aéreo.

---

Quando COBOL Encontra JSON

Muitos profissionais ainda acreditam que COBOL vive preso a arquivos sequenciais e layouts de 80 colunas.

A realidade atual é muito diferente.

O CICS moderno possui recursos nativos para trabalhar com JSON.

Isso significa que uma estrutura como:

{
  "cliente":"VAGNER",
  "saldo":1500
}

pode ser transformada diretamente em estruturas COBOL.

Sem parsers complexos.

Sem centenas de linhas de manipulação de texto.

Sem gambiarras.

Durante décadas, integrar COBOL com formatos modernos exigia muito esforço.

Hoje o próprio CICS faz grande parte desse trabalho.

Essa é uma das transformações menos conhecidas fora do universo Mainframe.

---

O Segredo da Performance

Quando alguém vê Azure, JSON e microsserviços, normalmente imagina dezenas de chamadas distribuídas.

Mas o processamento principal acontece dentro do CICS.

E isso muda tudo.

Após chegar ao Mainframe, a execução ocorre dentro de um ambiente extremamente otimizado.

Não existe:

• startup de container

• inicialização de JVM

• criação de novos processos

• overhead desnecessário

O programa já está carregado.

O ambiente já está pronto.

A transação apenas executa.

É por isso que muitas operações conseguem responder em poucos milissegundos.

Uma característica frequentemente subestimada por quem nunca trabalhou em ambientes de missão crítica.

---

DB2: O Guardião da Consistência

Toda essa velocidade seria inútil sem consistência.

É aqui que entra o DB2.

Quando o COBOL consulta ou atualiza dados, o DB2 garante:

• integridade

• atomicidade

• isolamento

• durabilidade

Os famosos princípios ACID.

Em outras palavras:

ou tudo acontece corretamente

ou nada acontece.

Em sistemas financeiros isso não é luxo.

É obrigação.

Ninguém quer descobrir que o débito ocorreu mas o crédito não.

---

O Valor das Transações

Um aspecto frequentemente ignorado é o gerenciamento transacional.

Quando MQ, CICS e DB2 trabalham juntos, formam um ecossistema extremamente robusto.

Imagine:

• mensagem recebida

• atualização realizada

• resposta enviada

Tudo dentro de uma única unidade lógica de trabalho.

Se qualquer etapa falhar:

rollback.

Como se nada tivesse acontecido.

Esse é um dos motivos pelos quais Mainframes continuam dominando ambientes financeiros.

Confiabilidade não é um recurso opcional.

É parte fundamental do negócio.

---

Dead Letter Queue: A Sala de Quarentena

Nem toda mensagem nasce perfeita.

Erros acontecem.

Layouts incorretos.

Dados inválidos.

Problemas de roteamento.

Mensagens corrompidas.

Se elas bloqueassem a fila principal, toda a operação sofreria.

A solução é a Dead Letter Queue.

A famosa DLQ.

Ela funciona como uma área de isolamento.

Mensagens problemáticas são removidas do fluxo principal e armazenadas separadamente.

O processamento continua.

Os usuários continuam trabalhando.

A equipe técnica pode investigar posteriormente.

É um conceito simples.

Mas extremamente poderoso.

---

O Que os Jovens Arquitetos Podem Aprender Com Isso

Existe uma tendência atual de acreditar que tudo começou com APIs, Kubernetes e microsserviços.

Arquiteturas como esta mostram que muitos conceitos modernos possuem raízes muito mais antigas.

Observe:

Eventos.

Mensageria.

Roteamento dinâmico.

Processamento assíncrono.

Alta disponibilidade.

Escalabilidade.

Observabilidade.

Resiliência.

Tudo isso já existia em ambientes Mainframe décadas atrás.

A diferença é que hoje utilizamos novos nomes para ideias antigas.

---

O Futuro Não É Cloud ou Mainframe

A pergunta correta não é:

Cloud ou Mainframe?

A pergunta correta é:

Como combinar Cloud e Mainframe?

A resposta está justamente nesta arquitetura.

O Azure fornece velocidade para inovação.

O Mainframe fornece estabilidade para execução.

O MQ conecta os dois mundos.

O CICS orquestra as transações.

O COBOL preserva o conhecimento acumulado.

O DB2 protege os dados.

Juntos, eles formam uma plataforma capaz de atender milhões de usuários simultaneamente.

---

Considerações Finais

Ao observar esta arquitetura, não vejo apenas filas MQ, programas COBOL ou serviços Azure.

Vejo algo muito mais interessante.

Vejo a prova de que tecnologia não é uma disputa entre velho e novo.

É uma construção contínua.

Os sistemas que realmente movem o mundo raramente são os mais barulhentos.

São os mais confiáveis.

Enquanto muitos discutem tendências, frameworks e modismos passageiros, arquiteturas híbridas como esta continuam processando pagamentos, movimentando recursos financeiros, autorizando cartões, executando operações críticas e sustentando economias inteiras.

Talvez essa seja a maior lição de todas.

O futuro não pertence exclusivamente à nuvem.

O futuro pertence às arquiteturas capazes de unir inovação e legado sem sacrificar desempenho, segurança ou confiabilidade.

E poucas combinações fazem isso tão bem quanto Azure, IBM MQ, CICS, COBOL e DB2 trabalhando em perfeita harmonia.

Porque, no final das contas, modernizar não significa destruir o passado.

Significa construir pontes entre o que já funciona e aquilo que ainda está por vir.

E essa arquitetura é uma dessas pontes.

 

Bellacosa Mainframe e a crise silenciosa do COBOL

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

"O problema não é que os sistemas COBOL vão parar amanhã. O problema é que, quando precisarmos deles depois de amanhã, talvez não haja gente suficiente para entendê-los."

---

Introdução: O paradoxo que desafia a lógica

Existe uma frase repetida há décadas no mundo da tecnologia:

"COBOL está morrendo."

Curiosamente, essa frase é tão antiga que já deveria ter morrido antes do próprio COBOL.

Nos anos 1980 diziam isso.

Nos anos 1990 também.

Nos anos 2000 então, parecia inevitável.

Veio Java.

Veio .NET.

Veio Python.

Veio Cloud.

Vieram Microservices.

Vieram Containers.

Vieram APIs.

Veio Inteligência Artificial.

E o COBOL continua processando bilhões de transações diariamente.

Mas há algo diferente acontecendo agora.

Pela primeira vez na história, o risco não é tecnológico.

O risco é humano.

Não estamos falando da morte da linguagem.

Estamos falando da aposentadoria das pessoas que sabem usá-la.

E isso muda completamente a discussão.

---

O grande erro dos anos 90

Durante os anos 1990 aconteceu um fenômeno curioso.

Universidades do mundo inteiro decidiram que COBOL não fazia mais sentido.

Os currículos migraram para:

• C++

• Java

• Redes

• Sistemas Distribuídos

• Orientação a Objetos

Naquele momento parecia uma decisão racional.

A internet estava explodindo.

O mundo falava sobre websites.

Empresas de tecnologia surgiam diariamente.

Tudo indicava que os sistemas legados seriam substituídos rapidamente.

Mas havia um detalhe que ninguém percebeu.

Substituir um sistema crítico não é como trocar um aplicativo de celular.

---

O mito da reescrita fácil

Imagine um sistema bancário criado em 1975.

Durante cinquenta anos ele recebeu:

• correções

• adaptações

• mudanças regulatórias

• novos produtos

• fusões bancárias

• ajustes tributários

• exceções operacionais

Hoje esse sistema possui milhões de linhas de código.

Mas o código é apenas a ponta do iceberg.

O verdadeiro patrimônio é o conhecimento de negócio embutido nele.

Muitas regras não estão documentadas.

Elas vivem no código.

E pior.

Muitas vezes nem o próprio negócio sabe que elas existem.

---

Exemplo real

Uma seguradora decidiu migrar um sistema COBOL para Java.

Projeto estimado:

• 2 anos

• US$ 20 milhões

Resultado:

• 7 anos

• mais de US$ 100 milhões

E ainda assim precisaram manter parte do sistema original funcionando.

Por quê?

Porque descobriram regras escondidas no código que ninguém conhecia.

Uma delas calculava benefícios de clientes antigos utilizando uma legislação que já nem existia mais.

Mas aqueles contratos continuavam válidos.

Remover a regra geraria processos judiciais.

---

O COBOL virou infraestrutura invisível

Hoje ninguém acorda pensando em COBOL.

Da mesma forma que ninguém acorda pensando em:

• rede elétrica

• abastecimento de água

• sistema de esgoto

Mas todos percebem quando param de funcionar.

O COBOL tornou-se uma camada invisível da sociedade moderna.

---

Quando você faz um PIX

Existe grande chance de algum processamento acabar passando por sistemas mainframe.

Quando usa cartão de crédito

Mainframe.

Quando recebe aposentadoria

Mainframe.

Quando paga imposto

Mainframe.

Quando consulta benefícios governamentais

Mainframe.

Quando uma companhia aérea processa reservas

Mainframe.

---

Muitas pessoas acreditam que esses sistemas foram substituídos.

Na realidade, na maioria dos casos, eles foram encapsulados.

Colocou-se uma API na frente.

Um aplicativo bonito.

Uma interface moderna.

Mas atrás continua existindo um programa COBOL executando a lógica crítica.

---

O IRS e o sistema de 60 anos

Um dos exemplos mais famosos é o Internal Revenue Service (IRS) dos Estados Unidos.

Quando falamos do IRS estamos falando do órgão responsável pela arrecadação federal americana.

Grande parte da infraestrutura principal foi construída durante os anos 1960.

Pense nisso.

Quando parte desses sistemas nasceu:

• o homem ainda não havia chegado à Lua;

• a internet não existia;

• computadores ocupavam salas inteiras;

• discos rígidos tinham capacidade ridícula para os padrões atuais.

Mesmo assim esses sistemas continuam funcionando.

Isso não é apenas impressionante.

É quase inacreditável.

---

O custo da modernização

Existe outra ilusão comum.

A ideia de que basta investir dinheiro para resolver o problema.

Se fosse verdade, ele já estaria resolvido.

Governos e bancos gastaram bilhões tentando modernizar sistemas legados.

Alguns tiveram sucesso.

Muitos não.

---

O motivo

A dificuldade não está em programar.

A dificuldade está em entender.

Imagine receber um programa COBOL escrito em 1978.

O programador original já morreu.

O analista de negócios aposentou-se.

A documentação desapareceu.

Os requisitos originais não existem.

Agora descubra exatamente o que ele faz.

Sem errar.

Porque um erro pode impactar:

• milhões de aposentados;

• bilhões de dólares;

• benefícios sociais;

• arrecadação tributária.

---

A aposentadoria em massa

Aqui está o ponto mais preocupante.

O profissional COBOL médio não tem 25 anos.

Nem 35.

Nem 45.

Em muitos lugares ele já ultrapassou os 55 anos.

Isso significa que estamos diante de uma transição geracional gigantesca.

Imagine uma empresa com:

• 100 especialistas COBOL

Se 10% se aposentam por ano:

Ano 1:
100 → 90

Ano 5:
90 → 59

Ano 10:
59 → 35

Ano 15:
35 → 20

Ano 20:
20 → 12

O conhecimento evapora rapidamente.

---

O conhecimento que não está nos livros

Aqui existe algo ainda mais perigoso.

Muitas pessoas confundem saber COBOL com saber sistemas COBOL.

São coisas completamente diferentes.

Aprender COBOL pode levar semanas.

Dominar um ambiente corporativo pode levar décadas.

---

Exemplo

Um desenvolvedor pode aprender:

ADD A TO B GIVING C.

em poucos minutos.

Mas compreender:

• JES2

• CICS

• DB2

• IMS

• RACF

• VSAM

• MQ

• JCL

• SMF

• DFSORT

e a integração entre todos eles...

isso pode exigir anos.

---

O verdadeiro gargalo não é COBOL

Essa é uma observação que faço frequentemente.

As manchetes falam:

"Faltam programadores COBOL."

Mas essa frase é simplista.

O que realmente falta são profissionais capazes de entender ecossistemas corporativos complexos.

---

Porque um especialista de verdade entende:

• negócio

• arquitetura

• operação

• performance

• segurança

• recuperação de desastres

Ele não é apenas programador.

Ele é guardião do conhecimento institucional.

---

A inteligência artificial vai resolver?

Pergunta inevitável em 2026.

A resposta é:

Sim.

E não.

---

Onde a IA ajuda

Hoje a IA consegue:

• explicar código COBOL;

• converter COBOL para Java;

• gerar documentação;

• identificar dependências;

• acelerar manutenção.

Isso é extraordinário.

---

Onde a IA não resolve

A IA não sabe:

• por que determinada regra existe;

• qual acordo político gerou aquela exceção;

• qual legislação de 1987 originou um cálculo;

• qual cliente depende daquela lógica.

Esse conhecimento continua humano.

---

O caso brasileiro

Como brasileiro e profissional de mainframe, vejo um cenário interessante.

O Brasil está em posição melhor do que muitos países.

Por quê?

Porque nunca abandonou completamente a formação em tecnologias corporativas.

Temos profissionais atuando em:

• bancos;

• seguradoras;

• governo;

• telecomunicações.

Instituições como:

• Banco do Brasil

• Caixa

• Bradesco

• Itaú

• Santander

• Serpro

• Dataprev

continuam mantendo grandes ambientes mainframe.

Isso criou uma continuidade geracional que muitos países perderam.

---

O erro estratégico das empresas

Durante anos muitas organizações enxergaram o mainframe apenas como custo.

E isso gerou decisões perigosas.

Redução de equipes.

Pouco treinamento.

Ausência de sucessão.

Falta de documentação.

Perda de conhecimento.

---

O resultado?

Quando um especialista se aposenta, descobre-se que ele era o único que compreendia determinado processo crítico.

Já vi situações em que uma única pessoa entendia completamente um sistema responsável por movimentar bilhões.

Quando ela saiu, a empresa entrou em pânico.

---

O mito do profissional velho

Existe também um preconceito silencioso.

Muita gente associa COBOL a tecnologia ultrapassada.

Logo associa seus profissionais a algo ultrapassado.

Isso é um erro monumental.

Os melhores especialistas que conheci dominavam:

• COBOL

• Java

• APIs

• Linux

• Cloud

• Containers

• DevOps

Eles simplesmente entendiam também a camada que sustenta o mundo.

---

O que deveria estar acontecendo

As organizações mais inteligentes já perceberam o problema.

Elas estão investindo em:

Mentoria reversa

Veteranos treinando jovens.

Pair Programming

Transferência contínua de conhecimento.

Documentação moderna

Captura do conhecimento tácito.

IA aplicada ao legado

Aceleração da curva de aprendizado.

Programas universitários

Retorno do ensino de COBOL.

---

Uma comparação com a engenharia civil

Imagine uma ponte construída há 60 anos.

Ela continua suportando milhões de veículos.

Ninguém diria:

"Vamos demolir porque é antiga."

Primeiro analisamos:

• estabilidade;

• manutenção;

• custo;

• risco.

Sistemas COBOL deveriam ser vistos da mesma forma.

A idade não é o problema.

A capacidade de manutenção é.

---

O verdadeiro risco para o futuro

A pergunta não é:

"Quando o COBOL vai acabar?"

A pergunta correta é:

"Quem vai entender os sistemas quando os especialistas atuais não estiverem mais aqui?"

Essa é uma questão muito mais séria.

Porque linguagens podem ser aprendidas.

Conhecimento institucional não pode ser recriado facilmente.

---

A visão Bellacosa Mainframe

Depois de décadas observando o mundo corporativo, cheguei a uma conclusão simples.

O futuro não será COBOL versus IA.

Nem Mainframe versus Cloud.

Nem Legado versus Modernização.

O futuro pertence à integração.

Os vencedores serão aqueles capazes de unir:

• conhecimento histórico;

• arquitetura moderna;

• inteligência artificial;

• plataformas corporativas.

O profissional mais valioso da próxima década não será aquele que conhece apenas a tecnologia nova.

Nem aquele que conhece apenas a tecnologia antiga.

Será aquele que consegue traduzir um mundo para o outro.

---

Conclusão: a crise silenciosa é real

A grande ironia da história é que o COBOL nunca foi tão invisível e tão importante ao mesmo tempo.

Ele está escondido atrás de aplicativos modernos, APIs elegantes e interfaces digitais sofisticadas.

Mas continua sustentando partes fundamentais da economia global.

O verdadeiro desafio não é técnico.

É humano.

A cada aposentadoria, perde-se mais do que um programador.

Perde-se contexto.

Perde-se história.

Perde-se conhecimento acumulado ao longo de décadas.

E conhecimento não pode ser recompilado.

A crise silenciosa do COBOL não é sobre uma linguagem criada em 1959.

É sobre a transferência de conhecimento de uma geração para outra.

Se governos, bancos e grandes corporações não tratarem isso como prioridade estratégica, poderão descobrir tarde demais que substituir hardware é fácil, substituir software é difícil, mas substituir experiência é quase impossível.

E talvez essa seja a maior lição que o mundo da tecnologia ainda não compreendeu.

O problema nunca foi o COBOL envelhecer. O problema é que seus especialistas envelheceram primeiro. ☕🚀💻🏦

Guard Rails, COBOL, Mainframe, Engenharia de Software, Desenvolvimento COBOL, Sistemas Críticos, Confiabilidade, Governança de TI, DevOps, Arquitetura de Software, Batch Processing, Segurança da Informação, SRE, Boas Práticas, Tecnologia Bancária

 

Bellacosa Mainframe e o guard rails em desenvolvimento de software

Guard Rails: A Arte de Impedir que um Desenvolvedor Derrube o Banco

Uma conversa que todo desenvolvedor COBOL deveria ter

Imagine a seguinte situação.

Você acabou de entrar em uma instituição financeira.

É seu terceiro mês como desenvolvedor COBOL.

Depois de semanas corrigindo pequenos bugs, finalmente recebe uma tarefa importante.

Uma rotina responsável pelo envio de notificações para clientes.

O gerente explica:

— Precisamos incluir um novo tipo de comunicação.

Você faz a alteração.

Compila.

Executa os testes.

Tudo parece funcionar.

A mudança é promovida para produção.

Horas depois, milhares de clientes recebem uma mensagem errada.

O call center entra em colapso.

O aplicativo registra picos de acesso.

O time de negócios inicia uma reunião de emergência.

A diretoria quer explicações.

E então surge a pergunta:

Como isso foi possível?

A resposta geralmente não é:

"Porque o desenvolvedor errou."

A resposta correta costuma ser:

"Porque o sistema permitiu que um erro chegasse à produção."

É exatamente nesse ponto que surge um dos conceitos mais importantes da engenharia moderna:

Guard Rails.

---

O que são Guard Rails?

A tradução literal seria:

"trilhos de proteção".

A inspiração vem das rodovias.

Quando um carro sai da pista, existe uma barreira metálica para impedir que ele caia de um penhasco.

O guard rail não evita o erro do motorista.

Ele reduz as consequências.

Na engenharia de software acontece exatamente a mesma coisa.

Os desenvolvedores inevitavelmente cometerão erros.

Os analistas inevitavelmente esquecerão requisitos.

Os operadores inevitavelmente clicarão em algo errado.

Os administradores inevitavelmente executarão comandos incorretos.

O objetivo não é eliminar o erro humano.

O objetivo é impedir que o erro se transforme em desastre.

---

O erro é inevitável

Desenvolvedores juniores costumam acreditar que sistemas caem porque alguém não sabia programar.

Essa visão desaparece rapidamente em ambientes corporativos.

Os maiores incidentes da história da tecnologia não foram causados por programadores incompetentes.

Foram causados por profissionais experientes trabalhando sob pressão.

Pessoas excelentes.

Pessoas inteligentes.

Pessoas treinadas.

Pessoas humanas.

A questão nunca foi:

"Quem errou?"

A questão sempre foi:

"Por que o sistema permitiu?"

Essa diferença muda completamente a forma de construir software.

---

Um exemplo COBOL simples

Considere um programa que realiza transferência bancária.

Versão sem Guard Rails:

IF SALDO-CONTA > 0
   SUBTRACT VALOR FROM SALDO-CONTA
END-IF.

Parece correto.

Mas existe um problema.

Suponha:

Saldo = 100

Transferência = 1000

O programa permitirá saldo negativo.

Agora uma versão mais segura.

IF VALOR > SALDO-CONTA
   DISPLAY "TRANSFERENCIA NEGADA"
   GO TO FIM-PROGRAMA
END-IF.

O sistema agora protege o negócio.

Isso é um Guard Rail.

---

Guard Rail não é regra de negócio

Esse é um erro comum.

Muitos desenvolvedores confundem os dois conceitos.

Regra de negócio:

"O cliente não pode sacar mais que possui."

Guard Rail:

"Mesmo que alguém esqueça a regra, o sistema impedirá a operação."

Uma regra define comportamento.

Um Guard Rail protege comportamento.

---

A filosofia do mainframe

Durante décadas, os ambientes mainframe desenvolveram uma cultura diferente do mundo moderno.

Em startups existe uma frase famosa:

Move fast.

Nos bancos existe outra:

Don't break production.

A razão é simples.

Um erro em rede social gera reclamações.

Um erro bancário gera prejuízo.

Por isso o mundo COBOL sempre valorizou:

• validação;

• redundância;

• auditoria;

• segregação;

• rastreabilidade.

Sem perceber, os ambientes mainframe implementavam Guard Rails muito antes do conceito ganhar popularidade.

---

O caso clássico do JCL

Todo profissional de mainframe já ouviu histórias de horror envolvendo JCL.

Imagine um dataset:

CLIENTES.PRODUCAO

Agora imagine um utilitário de exclusão.

DELETE CLIENTES.PRODUCAO

Um comando simples.

Um erro simples.

Um desastre gigantesco.

Por isso empresas maduras criam Guard Rails.

Por exemplo:

• confirmação obrigatória;

• aprovação dupla;

• ambiente segregado;

• backup automático.

A exclusão continua possível.

Mas torna-se muito mais difícil.

---

O princípio do “Are You Sure?”

Existe uma categoria inteira de Guard Rails baseada em confirmação.

Exemplo.

Você tenta apagar um arquivo.

O sistema pergunta:

"Tem certeza?"

Parece algo trivial.

Mas essa simples pergunta já evitou milhões de erros ao longo da história da computação.

Em sistemas financeiros essa ideia evolui.

Em vez de uma confirmação:

• duas confirmações;

• dois operadores;

• dois gestores;

• duas aprovações.

Chamamos isso de Four Eyes Principle.

Princípio dos quatro olhos.

---

Guard Rails em processamento batch

O universo COBOL vive cercado de batches.

Folha de pagamento.

Compensação bancária.

Fechamento contábil.

Liquidação financeira.

Imagine um programa que processa:

10.000 registros

Normal.

Agora imagine:

100 milhões de registros

Algo está errado.

Sem Guard Rails o programa continua.

Com Guard Rails ele interrompe:

IF QTDE-REGISTROS > LIMITE-MAXIMO
   DISPLAY "PROCESSAMENTO ANORMAL"
   ABEND
END-IF.

Esse simples teste pode evitar horas de caos operacional.

---

O conceito de Fail Fast

Existe um princípio muito importante:

Fail Fast.

Falhe rapidamente.

Muitos sistemas tentam continuar funcionando mesmo após identificar inconsistências.

Isso parece inteligente.

Na prática costuma piorar tudo.

Se um dado crítico estiver errado, o melhor comportamento é parar imediatamente.

Exemplo:

IF CODIGO-CLIENTE = SPACES
   ABEND
END-IF.

Parar cedo é melhor do que produzir milhões de registros incorretos.

---

Guard Rails contra desenvolvedores

Esse é um tema que incomoda iniciantes.

Ninguém gosta de ouvir:

"O sistema precisa proteger a empresa de você."

Mas essa é a realidade.

Um Guard Rail existe justamente porque até profissionais excelentes erram.

Imagine um comando SQL.

Sem proteção:

DELETE FROM CLIENTES;

Com proteção:

DELETE FROM CLIENTES
WHERE ID = :CLIENTE;

Ou ainda melhor.

Permissão somente leitura em produção.

O desenvolvedor continua competente.

O ambiente apenas se torna mais seguro.

---

O incidente do Nubank e os Guard Rails

O caso do falso aviso de liquidação tornou-se um exemplo interessante.

Independentemente dos detalhes internos, uma pergunta surgiu:

Como uma comunicação tão crítica chegou aos clientes?

A resposta provavelmente envolve ausência ou falha de Guard Rails.

Por exemplo:

• validação insuficiente;

• aprovação inadequada;

• rollout inexistente;

• testes incompletos.

Nenhum sistema deveria conseguir informar a liquidação de um banco sem múltiplas camadas de proteção.

---

Rollout gradual

Imagine um envio para:

50 milhões de clientes

Sem Guard Rail:

envio imediato.

Com Guard Rail:

1% da base.

Validação.

5%.

Validação.

10%.

Validação.

100%.

Empresas como Google, Amazon e Netflix utilizam esse modelo constantemente.

O objetivo é reduzir o raio da explosão.

---

Blast Radius

Todo arquiteto experiente faz uma pergunta.

Se isso falhar, quantas pessoas serão afetadas?

Chamamos isso de Blast Radius.

Raio de explosão.

Exemplo.

Erro em um batch:

Impacto:

500 clientes.

Blast Radius pequeno.

Erro em compensação nacional:

Impacto:

50 milhões de clientes.

Blast Radius enorme.

Guard Rails existem para reduzir esse raio.

---

Observabilidade também é Guard Rail

Muitos desenvolvedores acreditam que Guard Rails são apenas validações.

Não.

Monitoramento também é proteção.

Imagine:

Processamento esperado:

1000 transações por minuto

Sistema detecta:

500.000 transações por minuto

Algo claramente está errado.

Um bom sistema dispara alarmes.

Isso também é Guard Rail.

---

O conceito de Circuit Breaker

Em sistemas distribuídos modernos existe outro Guard Rail famoso.

Circuit Breaker.

Inspirado nos disjuntores elétricos.

Se uma dependência começa a falhar:

o sistema corta a conexão.

Em vez de derrubar tudo.

No mundo mainframe encontramos equivalentes há décadas:

• limites operacionais;

• interrupções controladas;

• filas protegidas;

• rejeições automáticas.

A ideia é a mesma.

Conter danos.

---

O erro mais caro é o silencioso

Existe uma frase conhecida entre engenheiros de confiabilidade:

Sistemas barulhentos são irritantes.

Sistemas silenciosamente errados são perigosos.

Um programa que falha imediatamente chama atenção.

Um programa que produz dados incorretos durante três dias pode gerar prejuízos gigantescos.

Por isso Guard Rails modernos privilegiam transparência.

Tudo deve ser:

• registrado;

• monitorado;

• auditado;

• rastreável.

---

A maturidade profissional

Existe um momento na carreira em que o desenvolvedor deixa de pensar:

"Meu código funciona."

E começa a pensar:

"O que acontece quando ele falhar?"

Essa mudança separa programadores iniciantes de engenheiros experientes.

O foco deixa de ser funcionalidade.

Passa a ser confiabilidade.

---

O que um desenvolvedor COBOL Jr deve fazer

Sempre pergunte:

O que pode dar errado?

Quem será impactado?

Existe limite operacional?

Existe validação?

Existe rollback?

Existe auditoria?

Existe monitoramento?

Existe aprovação?

Existe segregação?

Existe plano de contingência?

Se alguma resposta for "não sei", continue investigando.

---

A grande lição

Guard Rails não existem porque desenvolvedores são ruins.

Eles existem porque sistemas são complexos.

Quanto maior a empresa, mais perigoso se torna assumir que ninguém cometerá erros.

O verdadeiro papel da engenharia não é criar sistemas perfeitos.

É criar sistemas resilientes.

Sistemas que sobrevivam a erros humanos.

Sistemas que sobrevivam a falhas operacionais.

Sistemas que sobrevivam a decisões equivocadas.

No universo bancário, onde bilhões de reais transitam diariamente por programas COBOL escritos ao longo de décadas, essa diferença não é apenas uma questão técnica.

É uma questão de sobrevivência operacional.

E talvez a principal lição para qualquer desenvolvedor COBOL Jr seja esta:

Seu trabalho não é apenas fazer o programa funcionar.

Seu trabalho é impedir que ele cause danos quando inevitavelmente algo der errado.

Esse é o verdadeiro significado de Guard Rails.

 

Bellacosa Mainframe e o blast radius em desenvolvimento de software

Blast Radius: Por Que um Pequeno Erro Pode Derrubar um Banco Inteiro

Uma das perguntas mais importantes da engenharia moderna

Imagine que você acabou de entrar em uma grande instituição financeira.

Você é um desenvolvedor COBOL Jr.

Recebe uma tarefa aparentemente simples.

Alterar uma rotina de validação em um programa batch.

O código possui apenas algumas linhas.

A mudança é pequena.

O teste passou.

O deploy foi aprovado.

Tudo parece sob controle.

Dois dias depois surge uma reunião de crise.

Executivos estão reunidos.

Gerentes estão nervosos.

Equipes de infraestrutura trabalham durante a madrugada.

Milhões de registros foram processados incorretamente.

O prejuízo é enorme.

E então alguém faz uma pergunta que todo arquiteto experiente conhece:

Qual era o Blast Radius dessa mudança?

Essa pergunta vale mais do que qualquer revisão de código.

Mais do que qualquer ferramenta de monitoramento.

Mais do que qualquer framework moderno.

Porque ela determina o tamanho potencial do desastre.

---

O que significa Blast Radius?

A tradução literal seria:

Raio de Explosão.

O termo vem do universo militar.

Quando ocorre uma explosão, existe uma área diretamente afetada.

Quanto maior a explosão, maior o raio de destruição.

A engenharia de software adotou exatamente a mesma ideia.

Quando um sistema falha, uma pergunta precisa ser respondida:

Quantas pessoas, sistemas, operações ou clientes serão impactados?

Essa área de impacto é chamada Blast Radius.

---

O erro que afeta um cliente

Imagine um programa COBOL responsável por atualizar dados cadastrais.

Um erro afeta:

1 cliente

Problema?

Sim.

Crise?

Provavelmente não.

O impacto é localizado.

O Blast Radius é pequeno.

---

O erro que afeta um banco inteiro

Agora imagine um programa responsável pela compensação financeira nacional.

Um erro afeta:

30 milhões de clientes

Mesma quantidade de linhas alteradas.

Mesmo programador.

Mesmo tipo de erro.

Resultado completamente diferente.

Por quê?

Porque o Blast Radius mudou.

---

A pergunta que diferencia um programador de um engenheiro

O desenvolvedor iniciante normalmente pergunta:

Meu código funciona?

O engenheiro experiente pergunta:

O que acontece se ele falhar?

Essa mudança de mentalidade é uma das maiores evoluções na carreira de tecnologia.

Porque sistemas críticos não são avaliados apenas pelo sucesso.

Eles são avaliados pela forma como falham.

---

O mito do pequeno erro

Existe uma crença perigosa em ambientes corporativos.

"Foi só uma alteração pequena."

O tamanho do código raramente determina o tamanho do impacto.

Um único caractere já derrubou sistemas inteiros.

Um único parâmetro incorreto já gerou perdas milionárias.

Uma única configuração errada já interrompeu operações globais.

O impacto depende do Blast Radius.

Não da quantidade de código.

---

O universo COBOL e o poder invisível

Desenvolvedores COBOL trabalham em uma situação peculiar.

Muitas vezes manipulam sistemas que movimentam bilhões de reais diariamente.

Mas a interface parece simples.

Uma tela verde.

Alguns arquivos.

JCLs.

Datasets.

Rotinas batch.

Tudo parece tranquilo.

Até que alguém descobre que aquele programa processa:

• contas correntes;

• cartões;

• empréstimos;

• investimentos;

• liquidações;

• compensações.

De repente o código ganha outra dimensão.

---

O efeito dominó

Imagine uma falha em um cadastro.

Cliente incorreto.

Esse dado alimenta:

• CRM;

• antifraude;

• cobrança;

• compliance;

• atendimento;

• relatórios regulatórios.

Agora uma pequena falha inicial se transforma em dezenas de falhas secundárias.

Isso é amplificação de Blast Radius.

---

O conceito de dependências

Sistemas modernos não vivem isolados.

Um programa chama outro.

Que chama outro.

Que alimenta outro.

Que gera arquivos para outro.

O resultado é uma rede gigantesca.

Quando um componente falha, o impacto se propaga.

Como peças de dominó.

---

O exemplo do CPF inválido

Imagine uma rotina simples.

Um CPF inválido passa pela validação.

O erro parece pequeno.

Mas esse dado segue adiante.

Abre conta.

Gera cartão.

Produz relatórios.

Entra em auditorias.

Alimenta modelos analíticos.

Meses depois ninguém sabe mais onde o problema começou.

O Blast Radius cresceu silenciosamente.

---

O incidente do Nubank como estudo de caso

O episódio envolvendo o falso aviso de liquidação trouxe uma lição interessante.

Independentemente dos detalhes internos, a pergunta arquitetural é:

Qual era o Blast Radius daquele processo?

Se a mensagem atingisse:

10 clientes

O incidente seria pequeno.

Se atingir milhões:

O cenário muda completamente.

A mesma falha produz consequências exponencialmente maiores.

---

Blast Radius e ambientes de produção

Uma regra simples:

Quanto mais próximo da produção, maior o Blast Radius.

Ambiente de desenvolvimento:

Impacto quase zero.

Homologação:

Impacto limitado.

Produção:

Impacto real.

Produção financeira:

Impacto potencialmente gigantesco.

É por isso que instituições financeiras possuem tantos controles.

Não por burocracia.

Mas porque o custo do erro é enorme.

---

O perigo dos batches

O mundo COBOL é dominado por processamento em massa.

Um programa pode executar durante horas.

Processando milhões de registros.

O problema é simples.

Se houver um erro:

Ele será repetido milhões de vezes.

Um erro individual torna-se um erro industrializado.

---

O erro multiplicado

Imagine:

1 registro incorreto

Sem batch:

impacto pequeno.

Agora imagine:

50 milhões de registros

Processados pela mesma lógica defeituosa.

O erro não mudou.

O Blast Radius mudou.

---

Como arquitetos pensam

Arquitetos raramente perguntam:

"Qual tecnologia usamos?"

Eles perguntam:

"Qual o pior cenário possível?"

Essa pergunta direciona toda a arquitetura.

Porque sistemas críticos são construídos para sobreviver a falhas.

Não apenas para funcionar.

---

Blast Radius e permissões

Um desenvolvedor possui acesso de leitura.

Blast Radius reduzido.

Um desenvolvedor possui acesso irrestrito.

Blast Radius elevado.

É por isso que ambientes maduros trabalham com:

• menor privilégio;

• segregação;

• controle de acesso;

• aprovações.

Tudo isso é gestão de Blast Radius.

---

Blast Radius e banco de dados

Imagine um comando SQL.

Primeiro cenário:

UPDATE CLIENTES
SET STATUS='A'
WHERE ID=100;

Impacto:

um cliente.

Segundo cenário:

UPDATE CLIENTES
SET STATUS='A';

Impacto:

todos os clientes.

A diferença visual é mínima.

A diferença operacional é gigantesca.

---

O princípio da contenção

Existe uma palavra muito importante.

Contenção.

Todo sistema moderno deveria conter falhas.

Não espalhá-las.

Por isso empresas investem em:

• segmentação;

• isolamento;

• partições;

• zonas independentes.

O objetivo é impedir que uma falha local se torne global.

---

O conceito de células

Empresas como Amazon popularizaram a ideia de Cell Architecture.

Em vez de uma estrutura única gigante.

Criam-se células menores.

Se uma célula falhar:

As demais continuam operando.

Isso reduz drasticamente o Blast Radius.

---

Mainframe já fazia isso há décadas

Curiosamente, ambientes mainframe utilizavam conceitos semelhantes muito antes da computação em nuvem.

Exemplos:

• LPARs;

• regiões CICS;

• filas separadas;

• ambientes segregados;

• jobs independentes.

A filosofia era exatamente a mesma.

Conter impactos.

---

O problema do compartilhamento excessivo

Quanto mais sistemas compartilham recursos, maior o Blast Radius.

Banco compartilhado.

Fila compartilhada.

Storage compartilhado.

Processamento compartilhado.

Tudo isso cria pontos únicos de falha.

Um problema em um componente afeta dezenas de outros.

---

O conceito de Blast Radius Humano

Pouca gente fala sobre isso.

Mas pessoas também possuem Blast Radius.

Imagine:

Um único operador consegue executar qualquer comando em produção.

Blast Radius enorme.

Agora imagine:

Necessidade de aprovação dupla.

Blast Radius reduzido.

A governança existe para limitar o alcance dos erros humanos.

---

O papel dos Guard Rails

Blast Radius e Guard Rails caminham juntos.

Guard Rails tentam impedir erros.

Blast Radius tenta limitar consequências.

Exemplo:

Guard Rail:

impedir exclusão acidental.

Blast Radius:

caso a exclusão ocorra, limitar o impacto.

São conceitos complementares.

---

Rollout gradual

Uma das formas mais modernas de controlar Blast Radius é o rollout progressivo.

Em vez de liberar uma mudança para todos.

Liberamos para poucos.

Por exemplo:

1%.

Depois 5%.

Depois 10%.

Depois 100%.

Se houver erro, ele será detectado cedo.

O impacto permanece pequeno.

---

O medo saudável da produção

Existe uma característica interessante nos profissionais experientes de mainframe.

Eles respeitam produção.

Não porque tenham medo da tecnologia.

Mas porque entendem o Blast Radius.

Produção concentra:

• clientes;

• dinheiro;

• contratos;

• obrigações regulatórias;

• reputação.

Uma pequena falha pode produzir consequências gigantescas.

---

Observabilidade e Blast Radius

Você não controla aquilo que não consegue enxergar.

Por isso monitoramento é fundamental.

Imagine um batch que normalmente processa:

500 mil registros

Hoje processou:

50 milhões

Algo claramente está errado.

Um sistema observável detecta rapidamente.

Quanto mais cedo o problema é identificado, menor o Blast Radius.

---

O custo da reputação

Em bancos existe um ativo invisível.

Confiança.

Quando uma falha afeta poucos clientes, a recuperação costuma ser simples.

Quando afeta milhões, surge um problema adicional.

Reputação.

O Blast Radius passa a incluir:

• imprensa;

• investidores;

• reguladores;

• mercado.

O dano deixa de ser apenas tecnológico.

---

O exercício mental que todo COBOL Jr deveria fazer

Antes de qualquer alteração, pergunte:

Se eu errar:

• Quantos clientes serão impactados?

• Quantos sistemas dependem disso?

• Existe rollback?

• Existe monitoramento?

• Existe plano de contingência?

• Existe limite operacional?

• Existe validação?

• Existe segregação?

Essas perguntas valem mais do que qualquer linha de código.

---

A verdadeira maturidade profissional

Existe um momento em que o desenvolvedor deixa de ser apenas um programador.

Ele passa a enxergar sistemas.

Passa a enxergar operações.

Passa a enxergar negócios.

Passa a enxergar riscos.

Nesse momento surge uma nova pergunta.

Não mais:

O programa funciona?

Mas sim:

Qual é o Blast Radius se ele parar de funcionar?

Essa mudança de perspectiva transforma a forma de desenvolver software.

---

Conclusão

Blast Radius é um dos conceitos mais importantes da engenharia moderna porque nos obriga a pensar além do código.

Ele nos força a enxergar impacto.

A enxergar consequências.

A enxergar riscos.

Para um desenvolvedor COBOL Jr, compreender Blast Radius significa entender que o tamanho de uma alteração não determina sua importância.

Uma linha de código pode alterar milhões de contas.

Um único parâmetro pode interromper operações nacionais.

Uma pequena falha pode se propagar por dezenas de sistemas.

Os melhores engenheiros não são aqueles que acreditam que nunca errarão.

São aqueles que projetam sistemas assumindo que erros inevitavelmente acontecerão.

E quando eles acontecerem, o objetivo não será impedir a explosão.

Será garantir que o raio da explosão seja o menor possível.

Esse é o verdadeiro significado de Blast Radius.