Bellacosa Mainframe e o Gravity do Santander

☕🚀 PADAWAN COBOL, O QUE É O GRAVITY DO SANTANDER?

"Imagine que alguém pegasse décadas de COBOL, CICS, DB2 e Mainframe, colocasse tudo dentro de um foguete espacial e o lançasse rumo à nuvem. Esse foguete atende pelo nome de Gravity."

---

📖 Sinopse

O Gravity é a plataforma tecnológica criada pelo Banco Santander para modernizar seu núcleo bancário (Core Banking).

Não é apenas um software.

Não é apenas uma migração para nuvem.

É uma estratégia completa para permitir que sistemas bancários gigantescos deixem de depender exclusivamente de ambientes tradicionais de mainframe e passem a operar em arquitetura cloud moderna.

O objetivo é simples:

Fazer um banco de 180 milhões de clientes funcionar com a velocidade de uma fintech sem perder a robustez de um mainframe.

---

🏛 História

Durante décadas o Santander construiu seus sistemas bancários sobre tecnologias tradicionais:

• COBOL

• Mainframe IBM

• Bancos relacionais

• Sistemas batch

• Processamento transacional

Essas plataformas eram extremamente confiáveis.

O problema?

O mercado mudou.

Clientes passaram a exigir:

• PIX instantâneo

• Aplicativos móveis

• APIs

• Open Finance

• Integração em tempo real

O modelo tradicional começou a limitar a velocidade de inovação.

Por volta da década de 2010 o Santander iniciou um programa de transformação que culminou no Gravity.

Em 2022 o projeto ganhou notoriedade internacional quando o Google anunciou o uso da tecnologia por trás do Gravity no serviço Dual Run.

Em 2025 o Santander informou que mais de 90% de sua infraestrutura tecnológica já estava em nuvem.

---

Bellacosa Mainframe visuliza o Gravity

🚀 O que é o Gravity?

Pense nele como um:

Tradutor Universal Bancário

Ele permite que aplicações que antes viviam exclusivamente no mainframe possam operar em ambiente cloud.

Sua função principal é:

• Modernizar o Core Banking

• Executar processamento distribuído

• Operar em nuvem

• Facilitar migrações

• Reduzir dependência de hardware especializado

---

Bellacosa Mainframe uma visao geral do gravity

🏦 O que é Core Banking?

Padawan...

Quando você consulta saldo no aplicativo...

Quando faz um PIX...

Quando recebe salário...

Quando solicita empréstimo...

Tudo isso acaba passando pelo Core Banking.

É o coração do banco.

Sem ele:

💀 nada funciona.

---

⚙ Como funciona?

O segredo do Gravity é o conceito chamado:

Dual Run

Imagine duas locomotivas andando lado a lado.

Locomotiva 1

Mainframe

• COBOL

• CICS

• DB2

Locomotiva 2

Cloud

• Microservices

• Containers

• APIs

Durante um período ambas executam simultaneamente.

Os resultados são comparados.

Se tudo bater:

✅ a aplicação pode ser movida para nuvem.

Isso reduz enormemente o risco da migração.

---

🖥 Tecnologias Envolvidas

Embora o Santander não revele todos os detalhes internos, sabe-se que o projeto envolve:

Cloud Computing

• Google Cloud

• Kubernetes

• Containers

APIs

• REST

• Open Banking

DevOps

• CI/CD

• Deploy automatizado

Data

• Processamento distribuído

• Streaming

Engenharia Moderna

• Observabilidade

• Telemetria

• Monitoramento

---

☕ O que acontece com o COBOL?

A pergunta de um milhão de dólares.

Muitos imaginam:

"Migrar para nuvem significa jogar COBOL fora."

Errado.

O próprio Santander declarou que muitos dos profissionais que criaram os sistemas de mainframe há 20 anos participam do Gravity.

Isso revela algo importante:

O conhecimento de negócio continua valendo ouro.

A linguagem muda.

O negócio permanece.

---

🔥 Pontos Fortes

Escalabilidade

Pode crescer rapidamente conforme a demanda.

---

Agilidade

Novas funcionalidades podem ser liberadas em horas.

Antes levavam dias ou semanas.

---

Menor Dependência de Hardware

Não exige expansão física de datacenters.

---

Automação

Reduz atividades operacionais repetitivas.

---

Modernização

Facilita integração com:

• APIs

• Open Finance

• IA

• Aplicativos móveis

---

💣 Pontos Fracos

Complexidade

Migrar um banco não é igual migrar um site.

É extremamente complexo.

---

Custos Elevados

Projetos dessa magnitude custam bilhões.

---

Dependência da Cloud

O banco passa a depender mais dos provedores de nuvem.

---

Escassez de Talentos

Encontrar profissionais que entendam:

• Mainframe

• Cloud

• DevOps

• Negócio bancário

não é simples.

---

🤔 Curiosidades

Curiosidade 1

O Gravity não foi comprado.

Foi desenvolvido pelo próprio Santander.

---

Curiosidade 2

O Google aproveitou conceitos da tecnologia para construir o Dual Run.

---

Curiosidade 3

Poucos bancos do tamanho do Santander tentaram uma transformação tão profunda.

---

Curiosidade 4

O conhecimento dos especialistas de mainframe foi considerado fundamental.

---

Curiosidade 5

Mais de 1 trilhão de operações técnicas por ano deverão ser executadas através da plataforma.

---

🌎 Impacto no Mercado

O Gravity é observado por:

• BBVA

• HSBC

• ING

• Barclays

• Deutsche Bank

• Itaú

• Bradesco

• Banco do Brasil

Todos enfrentam o mesmo desafio:

Como modernizar décadas de sistemas sem parar o banco?

---

👨‍💻 O que muda para o Desenvolvedor COBOL?

Antigamente:

COBOL
 ↓
CICS
 ↓
DB2
 ↓
Produção

Agora:

COBOL
 ↓
API
 ↓
Container
 ↓
Cloud
 ↓
Observabilidade
 ↓
Produção

O desenvolvedor moderno precisa entender:

• APIs

• JSON

• Git

• DevOps

• Cloud

• Segurança

---

⚠ Riscos para a Carreira

Se o profissional pensar:

"Vou aprender apenas COBOL e parar no tempo."

Existe risco.

O mercado quer cada vez mais:

Profissionais Híbridos

• COBOL + Cloud

• COBOL + APIs

• COBOL + Java

• COBOL + Python

• COBOL + DevOps

O especialista puro continua existindo.

Mas o híbrido tende a ser mais valorizado.

---

🎯 Vantagens para o Profissional Mainframe

O Padawan costuma acreditar que:

"Cloud vai matar o Mainframe."

Na prática acontece o contrário.

Quem entende:

• Batch

• Integridade transacional

• Recuperação

• Consistência

• Alta disponibilidade

possui conhecimentos raros que muitos profissionais cloud nunca estudaram.

Por isso diversos arquitetos de transformação digital vieram do mundo mainframe.

---

☕ Resumo Bellacosa Mainframe

Gravity em uma frase

"É a ponte construída pelo Santander para levar décadas de conhecimento em COBOL e Mainframe para a nuvem sem destruir aquilo que fez o banco funcionar durante gerações."

O Padawan precisa aprender?

✅ Sim.

Precisa abandonar COBOL?

❌ Não.

Precisa aprender cloud?

✅ Sim.

O Mainframe vai acabar amanhã?

❌ Não.

O mercado está mudando?

✅ Muito rápido.

Quem será mais valorizado?

🚀 O profissional que souber conversar tanto com o veterano de JCL quanto com o engenheiro de Kubernetes.

Porque o futuro não é COBOL contra Cloud.

O futuro é COBOL + Cloud, e o Gravity talvez seja um dos maiores exemplos dessa convergência já vistos na indústria bancária mundial. ☕🔥🚀🏦💻

Gravity https://www.santander.com/en/press-room/press-releases/2025/06/santander-completes-the-digitalization-of-its-technology-infrastructure-in-spain-with-the-deployment-of-gravity

Gravity Power https://www.jornalintegracao.com/noticia/40336/revista-britanica-the-banker-elege-o-banco-mais-inovador-do-mundo

Inovação https://jornaleconomico.sapo.pt/noticias/santander-escolhido-como-mais-inovador-por-causa-da-plataforma-gravity/

Gravity - https://sapo.pt/artigo/santander-torna-se-o-primeiro-grande-banco-ocidental-a-operar-100-na-cloud-6865c821bf6e672c9d4acb54

Gravity - https://thedigitalbanker.com/santander-passes-key-milestone-in-its-transformation-after-migrating-its-cib-banking-platform-to-the-cloud/

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

• 28.000 linhas

• 134 COPYBOOKS

• 742 parágrafos

• Comentários da época do Plano Real

• Um PERFORM THRU que ninguém entende

• Um campo chamado WK-AREA1

• Outro chamado WK-AREA2

• Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica

---

O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

• principal

• juros

• correção

• multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.

---

EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

• 3.000 agências

• dezenas de fusões

• múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.

---

COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.

---

Frase 2

"É só uma correção rápida."

Nunca é.

---

Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.

---

Frase 4

"Não mexe porque funciona."

O terror dos bancos.

---

OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

• GOTO excessivo

• PERFORM THRU gigantes

• variáveis sem significado

• duplicação

---

2. Arquitetura

Problemas maiores.

Exemplos:

• sistemas monolíticos

• dependências excessivas

• integrações frágeis

---

3. Dados

Muito comum em bancos.

Exemplos:

• arquivos VSAM redundantes

• tabelas DB2 duplicadas

• dados inconsistentes

---

4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

• deploy manual

• testes manuais

• documentação inexistente

---

COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.

---

Sintoma 1

Mudanças simples levam semanas.

---

Sintoma 2

Toda alteração gera incidente.

---

Sintoma 3

Poucas pessoas entendem o sistema.

---

Sintoma 4

Ninguém quer mexer.

---

Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.

---

MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.

---

1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

• mais difícil testar

• mais difícil manter

• maior risco

Meta saudável:

• abaixo de 10 excelente

• até 20 aceitável

• acima de 30 perigoso

---

2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

• 500 linhas → simples

• 5.000 linhas → atenção

• 20.000 linhas → investigação

---

3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

• cadastro

• empréstimo

• cartão

• investimentos

Quando muda uma regra:

quatro programas precisam mudar.

---

4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.

---

5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.

---

6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?

---

FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.

---

IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

• dependências

• impacto

• análise de código

Mostra relacionamentos invisíveis.

---

IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

• DevOps

• testes

• integração

---

SONARQUBE

Uma das mais famosas.

Analisa:

• complexidade

• duplicação

• vulnerabilidades

Possui suporte para COBOL.

---

TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

• visualização

• debugging

• análise

---

ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.

---

GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.

---

COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.

---

PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

• onde está

• quanto existe

• qual impacto

---

PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.

---

PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.

---

PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.

---

PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.

---

PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.

---

PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.

---

O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

---

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.

---

CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.

---

A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

• melhorar nomes

• remover comentários obsoletos

• eliminar duplicações

Pequenas melhorias acumulam enormes resultados.

---

O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

• processar pagamentos

• movimentar bilhões

• atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.

---

O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"

---

☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

• Internet Banking

• Aplicativos móveis

• Chatbots

• APIs

• Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.

---

O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

---

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

• Portais Web

• Gateways API

• Aplicativos móveis

• Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.

---

O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

• Processos manuais escondidos

• Dependência excessiva de funcionários específicos

• Sistemas sem escalabilidade

• Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.

---

☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.

---

O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

• Comprar servidores

• Instalar servidores

• Configurar servidores

Meses de trabalho.

---

NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.

---

A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.

---

RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.

---

O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.

---

O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.

---

👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.

---

O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.

---

O DIA DO DESASTRE

Essa pessoa:

• aposenta

• muda de empresa

• entra em férias

Pronto.

Agora existe um risco operacional.

---

O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.

---

O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

• Git

• APIs

• DevOps

• Cloud

• Automação

• CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.

---

O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.

---

UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

• Git

• VS Code

• Zowe

• APIs REST

• Jenkins

• SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.

---

UM COBOL ANTIGO É REPELENTE

Agora imagine:

• documentação inexistente

• deploy manual

• FTP

• planilhas Excel

• mudanças sem controle

O problema não é COBOL.

É a cultura.

---

O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

• hardware

• software

• licenças

Mas esquecem:

• turnover

• treinamento

• conhecimento perdido

Esses custos podem superar os custos tecnológicos.

---

O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.

---

O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

---

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

• agilidade

• automação

• integração

• APIs

• escalabilidade

• experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

• pessoas

• conhecimento

• processos

• documentação

• cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.

---

CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

• documentação

• testes

• APIs

• observabilidade

• versionamento

• arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.

🔥☕ Do COBOL ao Arquiteto Enterprise Por Que Engenharia de Software Virou a Skill Mais Importante Para o Programador Mainframe Moderno

 

Bellacosa Mainframe e topicos de engenharia de software para mainframers

🔥☕ Do COBOL ao Arquiteto Enterprise

Por Que Engenharia de Software Virou a Skill Mais Importante Para o Programador Mainframe Moderno

Existe uma frase silenciosa que ecoa dentro dos grandes bancos, seguradoras e sistemas financeiros do planeta:

“O sistema pode até mudar de interface… mas o COBOL continua sustentando o mundo.”

E isso não é exagero.

Enquanto muita gente acredita que o universo enterprise vive apenas de microservices coloridos, containers e frameworks JavaScript da moda… milhões de transações financeiras continuam atravessando silenciosamente ambientes IBM Z, CICS, DB2 e aplicações COBOL gigantescas que nunca podem parar.

Mas algo mudou.

Muito.

O mercado não procura mais apenas:

• “quem sabe COBOL”

Hoje o mercado procura:

• engenheiros de software enterprise.

E existe uma diferença brutal entre essas duas coisas.

---

☕ O Antigo Programador COBOL

Durante décadas, muitos profissionais cresceram no modelo clássico:

• alterar rotina

• corrigir bug

• compilar

• subir pacote

• fechar chamado

O foco era:

• implementação

• manutenção

• operação

E isso funcionou por muito tempo.

Mas o mundo enterprise moderno virou um ecossistema absurdamente mais complexo.

Hoje um simples sistema bancário pode envolver:

• APIs REST

• aplicações mobile

• cloud híbrida

• microsserviços

• observabilidade

• CI/CD

• autenticação distribuída

• mensageria

• integração em tempo real

• analytics

• IA

E no meio disso tudo…

o COBOL continua lá.

Silencioso.

Processando.

Confiável.

---

🏗️ O Que é Engenharia de Software de Verdade?

Muita gente acha que engenharia de software é:

• aprender framework

• decorar design pattern

• usar UML

Mas engenharia de software é algo muito maior.

Ela existe para resolver um problema fundamental:

Como construir sistemas gigantes sem criar caos?

Porque sistemas enterprise crescem.

E crescem rápido.

Sem arquitetura:

• o sistema vira espaguete

• manutenção explode

• bugs aumentam

• deploys quebram produção

• integração vira pesadelo

A engenharia surge para controlar complexidade.

---

🧱 Arquitetura Não É Luxo. É Sobrevivência.

O programador júnior normalmente olha para:

• programas

• copybooks

• tabelas

• jobs

O arquiteto olha para:

• ecossistemas

• fluxos

• dependências

• escalabilidade

• disponibilidade

• integração

Essa mudança de mentalidade é gigantesca.

Um banco não sobrevive décadas apenas porque tem “código”.

Ele sobrevive porque existe:

• arquitetura

• organização

• separação de responsabilidades

• governança

E curiosamente…

o mundo mainframe sempre fez isso muito antes da cloud existir.

---

☕ O Mainframe Já Pensava Como Cloud Décadas Atrás

Esse talvez seja um dos maiores segredos da computação enterprise.

Muitos conceitos vendidos hoje como “modernos” já existiam no ecossistema IBM há décadas.

Veja isso:

Mundo Moderno	Mainframe Enterprise
Alta disponibilidade	Sysplex
Load Balancing	CICSPlex
APIs	z/OS Connect
Transactions	CICS
Observabilidade	OMEGAMON
Segurança centralizada	RACF
Mensageria	MQ

Ou seja…

o IBM Z nunca ficou ultrapassado.

O que aconteceu foi:

• a interface mudou

• o marketing mudou

• o nome mudou

Mas os fundamentos de engenharia continuaram fortíssimos.

---

⚔️ O Problema do “Só Saber Programar”

Existe um erro muito comum entre iniciantes.

Acreditar que carreira se resume a:

• linguagem

• sintaxe

• framework

Mas linguagens mudam.

Frameworks morrem.

Hypes desaparecem.

O que permanece é:

• arquitetura

• modelagem

• design

• integração

• capacidade analítica

É exatamente por isso que engenheiros experientes continuam relevantes por décadas.

Eles entendem sistemas.

Não apenas ferramentas.

---

🧩 Design Patterns: O Conhecimento Condensado dos Veteranos

Quando um júnior vê:

• Factory

• Singleton

• Observer

• Strategy

ele normalmente pensa:

“isso parece complicado”

Mas design patterns são apenas soluções repetidas para problemas repetidos.

Eles nasceram porque grandes sistemas começaram a enfrentar:

• acoplamento

• manutenção impossível

• crescimento descontrolado

• dependências caóticas

Então engenheiros começaram a criar padrões reutilizáveis.

E isso mudou a indústria.

No fundo:

• design patterns

• clean code

• arquitetura em camadas

• UML

são tentativas humanas de controlar complexidade.

---

🧠 Clean Code Não É Frescura

Muitos sistemas COBOL antigos sofrem não por causa da idade.

Mas por causa da falta de engenharia.

Código ruim custa:

• dinheiro

• tempo

• performance

• estabilidade

• saúde mental

E isso vale para qualquer linguagem.

Um programa COBOL bem escrito pode durar décadas.

Um programa moderno mal escrito pode virar lixo em seis meses.

A diferença está na engenharia.

---

🌐 O Novo COBOL Está Conectado

Hoje o programador mainframe moderno precisa entender:

• APIs REST

• JSON

• integração

• cloud híbrida

• DevOps

• pipelines

• observabilidade

Porque o COBOL moderno não vive mais isolado.

Agora ele conversa com:

• mobile

• fintechs

• microsserviços

• IA

• analytics

• cloud pública

O COBOL deixou de ser “backoffice”.

Ele virou parte do ecossistema digital global.

---

🚀 DevOps Chegou ao IBM Z

Durante muito tempo existiu um mito:

“Mainframe não acompanha DevOps.”

Hoje isso caiu completamente.

O ecossistema IBM já possui:

• Git

• CI/CD

• automação

• pipelines

• testes automatizados

• observabilidade moderna

• integração cloud-native

Ferramentas como:

• Zowe

• Jenkins

• UrbanCode

• GitHub

• OpenShift

aproximaram ainda mais o IBM Z do universo moderno.

---

☕ O Que o Mercado Espera Agora?

O mercado não procura mais apenas:

• operador

• codificador

• executor de tarefas

Ele procura:

• solucionadores de problemas

O profissional valioso hoje entende:

• negócio

• arquitetura

• integração

• confiabilidade

• escalabilidade

• comunicação

E aqui existe uma vantagem absurda para quem vem do mainframe.

Porque poucos ambientes ensinam:

• sistemas críticos

• alta disponibilidade

• milhões de transações reais

• tolerância zero para falhas

O programador COBOL enterprise já nasce perto de problemas gigantes.

---

🧭 O Roadmap do Programador COBOL Moderno

A evolução natural hoje passa por:

Base

• COBOL

• JCL

• VSAM

• SDSF

Intermediário

• DB2

• CICS

• SQL

• MQ

Modernização

• APIs

• JSON

• REST

• Git

• DevOps

Engenharia

• Arquitetura

• Design Patterns

• UML

• Observabilidade

• Segurança

Próximo nível

• Cloud híbrida

• SRE

• Performance

• Integração distribuída

• Engenharia enterprise

---

🔥 O Grande Erro do Mercado

Enquanto muitos perseguem apenas:

• hype

• frameworks

• modinhas

o mundo enterprise continua valorizando:

• confiabilidade

• estabilidade

• engenharia sólida

E é exatamente aí que o profissional IBM Z moderno pode se tornar raro.

Porque ele entende:

• legado

• missão crítica

• integração

• arquitetura real

---

☕ O Futuro Não Está Escolhendo Entre COBOL ou Cloud

O futuro está integrando os dois.

Os sistemas modernos não vão substituir completamente o mainframe.

Eles vão conversar com ele.

Porque no final:

• o aplicativo pode mudar

• a interface pode mudar

• a cloud pode mudar

Mas alguém ainda precisa garantir:

• consistência

• transação

• segurança

• disponibilidade

E silenciosamente…

o IBM Z continua fazendo isso melhor do que quase qualquer outra plataforma do planeta.

---

🔥☕ Conclusão Bellacosa Mainframe

O programador COBOL que entender engenharia de software deixará de ser apenas:

• “o cara do legado”

e começará a se tornar:

• arquiteto

• integrador

• especialista enterprise

• engenheiro de sistemas críticos

Porque no final…

o verdadeiro diferencial nunca foi apenas a linguagem.

Sempre foi:

entender como sistemas gigantes funcionam.

 

 

Bellacosa Mainframe apresenta EzNoSQL no Z/OS

💣🔥 EzNoSQL no z/OS — O Golpe Silencioso: COMO O MAINFRAME APRENDEU JSON SEM PEDIR PERMISSÃO

Se você é COBOL júnior e acha que NoSQL é coisa de cloud, segura essa:
o mainframe não só entendeu… como absorveu o conceito sem quebrar uma linha de negócio.

---

🧬 Origem — de onde veio essa “mutação”?

Tudo começa com um problema real:

👉 Sistemas core em z/OS
👉 Dados rígidos em Db2, VSAM, IMS
👉 Mundo moderno falando JSON, REST, mobile, eventos

💥 Conflito inevitável.

A IBM já vinha preparando o terreno com:

• Suporte a JSON no Db2
• z/OS Connect expondo APIs
• Integração com cloud

👉 O EzNoSQL for z/OS® surge como uma resposta pragmática:

💣 “E se a gente trouxer o modelo NoSQL pra dentro do mainframe ao invés de empurrar o mainframe pra fora?”

---

📅 História e lançamento

Diferente de produtos clássicos da IBM, o EzNoSQL não nasceu como um “big bang” tipo CICS ou Db2.

👉 Ele aparece por volta da década de 2010 (era pós-cloud), como parte da estratégia de:

• Modernização de aplicações
• APIs REST
• Dados semi-estruturados

💡 Não é um produto mainstream amplamente divulgado como CICS ou Db2
👉 É mais nichado, usado em arquiteturas modernas híbridas

---

🧠 O que ele realmente é (explicação raiz)

Pensa assim, jovem COBOLista:

👉 VSAM = registro fixo
👉 Db2 = tabela estruturada
👉 EzNoSQL = documento flexível (tipo JSON)

Exemplo:

{
  "conta": "123",
  "cliente": "Bellacosa",
  "apps": ["mobile", "web"],
  "config": {
    "notificacao": true
  }
}

💣 Isso no mundo antigo exigiria:

• várias tabelas
• joins
• redesign

👉 Aqui: 1 documento

---

⚙️ Como ele funciona na prática

Arquitetura típica:

App → API → z/OS Connect → COBOL → EzNoSQL

Integra com:

• CICS
• z/OS
• Segurança via RACF

---

🚀 Vantagens (o lado poderoso)

🔥 1. Modernização sem reescrita

Você não precisa jogar COBOL fora.

👉 Você evolui.

---

⚡ 2. JSON nativo no mainframe

Perfeito para:

• APIs REST
• Mobile
• Integrações modernas

---

🛡️ 3. Segurança absurda

Tudo herdado do mainframe:

• RACF
• auditoria
• controle fino

---

🧩 4. Integração natural

Nada de ETL maluco ou sync externo.

---

⚠️ Desvantagens (a parte que ninguém te conta)

❌ 1. Não é cloud-native puro

Não compete diretamente com:

• MongoDB
• Cassandra

---

❌ 2. Escalabilidade diferente

Mainframe escala verticalmente
NoSQL moderno escala horizontalmente

---

❌ 3. Curva de entendimento

COBOL + JSON = choque cultural no começo 😅

---

🧪 Exemplo mental (modo Bellacosa)

🎯 Problema

Cliente muda preferências toda hora.

No Db2:

• ALTER TABLE?
• nova coluna?
• impacto em batch?

💣 Dor.

---

🎯 Com EzNoSQL

{
  "cliente": "123",
  "preferencias": {
    "tema": "dark",
    "idioma": "pt-BR",
    "notificacao": true
  }
}

👉 Mudou? Só adiciona campo.

SEM ALTER TABLE.
SEM impacto global.

---

🧠 Curiosidades (nível raiz)

💡 EzNoSQL não substitui Db2
👉 Ele resolve outro tipo de problema

💡 Ele é mais comum em:

• bancos
• fintechs
• modernização de legado

💡 Muitas vezes você usa sem perceber:
👉 “camada invisível” por trás de APIs

---

🥚 Easter Egg (essa é boa)

💣 O maior segredo:

Muita empresa diz:

👉 “Estamos usando microserviços modernos”

Mas por trás…

👉 ainda existe COBOL chamando algo tipo EzNoSQL no z/OS 😎

---

🧠 Insight profundo (pra você crescer rápido)

👉 O futuro NÃO é:

• COBOL vs NoSQL
• Mainframe vs Cloud

💣 O futuro é:

Mainframe + NoSQL + APIs + eventos

---

🧪 Analogia final (pra fixar de vez)

• Db2 = planilha Excel organizada
• VSAM = arquivo binário rápido
• EzNoSQL = JSON flexível tipo API moderna

---

🚀 Conclusão

O EzNoSQL for z/OS® é uma peça estratégica:

👉 Ele permite que o mainframe:

• fale JSON
• exponha APIs
• se conecte ao mundo moderno

💣 Sem perder:

• performance
• segurança
• confiabilidade
•  

💣 COBOL NÃO É LEGADO — É CARÁTER: O CAMINHO DO DEV QUE QUER SAIR DO “OPERADOR DE JOB” PARA ENGENHEIRO DE MISSÃO CRÍTICA

 

Bellacosa Mainframe uma conversa com DEVs Programadores COBOL

💣 COBOL NÃO É LEGADO — É CARÁTER: O CAMINHO DO DEV QUE QUER SAIR DO “OPERADOR DE JOB” PARA ENGENHEIRO DE MISSÃO CRÍTICA

---

Existe um mito silencioso no mundo corporativo:
o de que o desenvolvedor COBOL é apenas um “mantenedor de código antigo”.

Isso não só está errado — é perigoso.

Porque enquanto muitos enxergam “legado”, poucos entendem que estão sentados em cima de o sistema nervoso de bancos, seguradoras, bolsas e governos inteiros.

E aí vem a pergunta que separa os comuns dos raros:

👉 Você é um digitador de programa… ou um engenheiro de sistema crítico?

---

🧭 ORIGEM: QUANDO O COBOL NÃO ERA “VELHO” — ERA REVOLUCIONÁRIO

COBOL nasceu nos anos 60 com uma missão ousada:

ser compreensível para humanos de negócio

Enquanto outras linguagens eram matemáticas, o COBOL era quase… literatura.

Exemplo clássico:

ADD SALARIO TO TOTAL-PAGAMENTO.

Isso não é código. Isso é intenção.

💡 Easter Egg histórico:
A linguagem foi fortemente influenciada por Grace Hopper, que defendia que código deveria ser legível como inglês — algo que hoje o mundo redescobre com “clean code”.

---

⚠️ O PROBLEMA MODERNO: O DEV QUE PAROU NO TEMPO

O erro mais comum não é técnico.

É mental.

O dev COBOL muitas vezes cai em um desses perfis:

• 🔁 “Eu só faço manutenção”
• 🧱 “Sempre foi assim”
• 📦 “Não mexe nisso que funciona”

Esse mindset transforma profissionais em… gargalos humanos.

E o mercado já percebeu isso.

Hoje não falta vaga para COBOL.
Falta gente que pensa além do COBOL.

---

🧠 EVOLUÇÃO REAL: O QUE SEPARA O DEV COMUM DO DIFERENCIADO

Vamos direto ao ponto.

1. 📊 ENTENDER O NEGÓCIO (DE VERDADE)

Se você não sabe o que seu programa faz no negócio…

👉 você é substituível.

Um dev COBOL de alto nível sabe responder:

• Esse programa impacta qual produto bancário?
• Qual risco financeiro existe aqui?
• Qual o impacto de uma falha?

💡 Exemplo real:

Um simples IF mal feito pode gerar milhões em prejuízo em cálculo de juros.

---

2. 🔍 LER MAIS DO QUE ESCREVER

Dev COBOL sênior não escreve código rápido.

Ele entende código legado absurdo com facilidade.

Exemplo clássico:

IF WS-IND = 'S' OR 'Y' AND NOT = 'N'

👉 Isso aqui é bug esperando acontecer.

O profissional evoluído:

• refatora
• documenta
• simplifica

---

3. ⚙️ DOMINAR O ECOSSISTEMA (NÃO SÓ COBOL)

COBOL sozinho não vive.

Você precisa dominar:

• JCL (o sangue do batch)
• CICS (o tempo real)
• DB2 (a memória do sistema)
• VSAM (o legado vivo)
• SORT / IDCAMS (os bastidores)

💥 Easter Egg técnico:
Muitos problemas de “performance COBOL” são, na verdade, problemas de JCL mal desenhado ou acesso ineficiente ao DB2.

---

4. 🚀 PERFORMANCE É DIFERENCIAL (E POUCOS DOMINAM)

Um dev comum faz funcionar.
Um dev avançado faz escalar.

Exemplo:

• Evitar READ NEXT desnecessário
• Usar buffers corretamente
• Reduzir I/O
• Escolher entre VSAM vs DB2 com critério

💡 Curiosidade:
Mainframe ainda processa bilhões de transações por dia — e COBOL está no centro disso.

---

5. 🌐 APRENDER A CONVERSAR COM O MUNDO MODERNO

Aqui está o divisor de águas atual.

Você precisa saber integrar COBOL com:

• APIs REST
• JSON
• Mensageria
• z/OS Connect
• Microservices

Exemplo simples de mentalidade:

Antes:

Programa batch gera arquivo

Depois:

Programa expõe serviço consumido por app mobile

💥 Isso muda tudo.

---

6. 🧩 REFACTORING: A ARTE QUE QUASE NINGUÉM FAZ

Código COBOL antigo muitas vezes é um labirinto.

Mas cuidado:

👉 refatorar sem entender é quebrar produção.

O profissional diferenciado:

• entende fluxo completo
• cria versões paralelas
• valida com dados reais
• documenta decisões

---

7. 📚 DOCUMENTAR COMO SE SUA VIDA DEPENDESSE DISSO

Porque depende.

Mainframe tem um problema clássico:

conhecimento tribal

Se você sair… o sistema para.

Quem documenta bem:

• vira referência
• cresce rápido
• reduz riscos

---

🧪 EXEMPLO PRÁTICO: DO DEV COMUM AO ENGENHEIRO

Situação:

Programa COBOL lê VSAM e calcula saldo.

Dev comum:

• ajusta campo
• recompila
• entrega

Dev evoluído:

• entende regra de negócio
• valida consistência histórica
• analisa impacto em batch downstream
• melhora performance
• documenta fluxo
• sugere evolução (API, por exemplo)

👉 Resultado: ele não entrega código.

Ele entrega segurança operacional.

---

🧿 FILOSOFIA DO MAINFRAME: DISCIPLINA > MODISMO

Enquanto o mundo corre atrás de frameworks…

o mainframe exige:

• precisão
• previsibilidade
• responsabilidade

💡 Um erro aqui não derruba um site.

👉 Derruba um banco.

---

🧨 EASTER EGG FINAL (PARA QUEM É RAIZ)

Se você nunca:

• analisou um dump S0C7 na unha
• perseguiu um abend fantasma
• ou depurou JOB em produção

… você ainda não viu o verdadeiro mainframe.

---

🏁 CONCLUSÃO: O DEV COBOL DO FUTURO NÃO É LEGADO — É RARO

O mercado não quer mais alguém que “sabe COBOL”.

Quer alguém que:

• entende negócio
• domina ecossistema
• pensa em arquitetura
• integra com o mundo moderno
• resolve problemas críticos

👉 Isso não é um programador.

Isso é um engenheiro de missão crítica.

---

☕ FRASE FINAL (ESTILO BELLACOSA)

“COBOL não é sobre o passado.
É sobre quem tem coragem de carregar o presente… sem margem para erro.”

 

 

Bellacosa Mainframe do jcl ao json laboratorio pratico

🧪 LABORATÓRIO — DO JCL AO JSON

🐍 Missão: Dominar dados reais com Python

👉 Formato: desafios práticos
👉 Nível: iniciante → intermediário
👉 Ideal para 1–2 dias de hands-on
👉 Pode virar curso ou workshop

---

🔹 BLOCO 1 — Arquivos (I/O)

🧩 Desafio 1 — Leitor de arquivo sequencial

Crie um programa que:

• Leia clientes.txt
• Mostre número total de linhas
• Mostre a primeira e última linha

💡 Analog: processamento sequencial COBOL

---

🧩 Desafio 2 — Contador de registros válidos

Arquivo contém linhas vazias e comentários iniciados por #.

Conte apenas registros válidos.

---

🧩 Desafio 3 — Gerador de arquivo batch

Crie um arquivo relatorio.txt contendo:

• Data/hora atual
• Total de registros processados
• Status “OK”

---

🧩 Desafio 4 — Conversor TXT → CSV

Entrada:

123;Ana;1200
456;João;950

Produza um CSV com cabeçalho.

---

🧩 Desafio 5 — Copiador com filtro

Copie transacoes.txt para aprovadas.txt
apenas registros com valor > 1000.

---

🔹 BLOCO 2 — Pandas (Dados tabulares)

🧩 Desafio 6 — Carregar dataset

Use Pandas para:

• Ler um CSV
• Mostrar as 5 primeiras linhas
• Mostrar número de registros

---

🧩 Desafio 7 — Filtro de negócios

Mostre apenas clientes com saldo > 1000.

Ordene por saldo decrescente.

---

🧩 Desafio 8 — Estatísticas rápidas

Calcule:

• Média do saldo
• Máximo
• Mínimo
• Total

---

🧩 Desafio 9 — Agrupamento

Agrupe clientes por cidade e conte quantos há em cada uma.

💡 Similar a GROUP BY

---

🧩 Desafio 10 — Pipeline batch moderno

Leia um CSV → filtre → salve novo CSV com resultados.

---

🔹 BLOCO 3 — NumPy (Processamento numérico)

🧩 Desafio 11 — Operações vetoriais

Crie dois arrays e calcule:

• Soma elemento a elemento
• Produto elemento a elemento
• Produto escalar

---

🧩 Desafio 12 — Matriz de desempenho

Simule vendas por região:

• Matriz 3×4
• Calcule totais por linha e coluna

---

🔹 BLOCO 4 — APIs (Integração moderna)

🧩 Desafio 13 — Consumidor de API

Use uma API pública (ex.: cotação de moedas).

Exiba:

• Valor atual
• Data/hora
• Fonte

💡 Biblioteca: requests

---

🧩 Desafio 14 — API → DataFrame

Obtenha dados JSON de uma API e:

• Converta para Pandas
• Mostre estatísticas
• Salve em CSV

---

🔹 BLOCO 5 — Web Scraping

🧩 Desafio 15 — Minerador de dados web

Extraia dados de uma página pública:

• Títulos de notícias OU
• Tabela da Wikipedia

Salve em arquivo estruturado.

💡 Bibliotecas:

requests
BeautifulSoup
pandas.read_html()

---

🏆 DESAFIO EXTRA (Modo Arquitetura)

🔥 Mega-missão — Pipeline completo

Construa um fluxo:

👉 Coletar dados de API
👉 Complementar com dados de arquivo local
👉 Processar com Pandas
👉 Salvar resultado final

💥 Isso simula um ETL moderno.

---

🎯 O que você dominará ao concluir

✔ Manipulação de arquivos
✔ Processamento tabular
✔ Computação numérica
✔ Integração com sistemas externos
✔ Coleta de dados da web
✔ Data pipelines
✔ Base para Data Science

---

🚀 Tradução para linguagem mainframe

Arquivos → Dataset sequencial

Pandas → DB2 em memória

NumPy → cálculo científico

APIs → integração online

Scraping → coleta automática

 

Bellacosa Mainframe o mundo da APIs em Python e Mainframe

🔥 “API NÃO É CICS! — O Guia PROIBIDO que Todo Coboleiro Precisa Ler Antes de Virar ‘Júnior’ em Python”

---

☕ Introdução no estilo Bellacosa

Se você vem do mundo do COBOL, acostumado com CICS, MQ, VSAM e chamadas bem estruturadas… prepare-se:

👉 Em Python, o mundo gira em torno de APIs.

E não, não é exagero.

Se no mainframe você faz EXEC CICS LINK, no Python você faz requisições HTTP para APIs REST — e isso muda completamente o jogo.

Hoje você não consome arquivos.
Você consome serviços vivos.

---

🧠 Um pouco de história (porque raiz importa)

Antes de falarmos de Python, vamos entender o conceito:

• Anos 70–90 → Integração via arquivos batch (hello JCL 👋)
• Anos 90–2000 → RPC, CORBA, Web Services SOAP
• Pós-2010 → REST APIs (HTTP simples + JSON)

👉 E aí entra Python como o “canivete suíço” dessa nova era.

A linguagem nasceu em 1991 com Guido van Rossum, mas só explodiu quando virou padrão para:

• automação
• integração
• dados
• e claro… consumo de APIs

---

🚀 O que é API (tradução COBOL)

Pensa assim:

COBOL	Python
CICS LINK	HTTP Request
Copybook	JSON
COMMAREA	Body da requisição
Program	Endpoint

👉 API = um programa remoto que você chama via rede.

---

🔥 As APIs mais usadas em Python (ESSENCIAIS)

1. 🌐 requests — o “EXEC CICS” do Python

A biblioteca mais famosa para consumir APIs.

import requests

response = requests.get("https://api.github.com")
print(response.json())

💡 Tradução Bellacosa:

Isso é basicamente um CALL 'API' USING COMMAREA… só que via internet.

---

2. ⚡ FastAPI — o “CICS moderno”

Se você quer criar APIs:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def home():
    return {"message": "Hello Mainframe!"}

🔥 Extremamente rápido, moderno e tipado.

👉 É tipo montar seu próprio CICS + transaction server, só que leve.

---

3. 🧱 Flask — o clássico minimalista

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello COBOL world!"

💡 Muito usado em sistemas menores ou protótipos.

---

4. 🔐 httpx — o “requests turbo”

• Assíncrono (não bloqueia execução)
• Melhor performance

import httpx

response = httpx.get("https://api.github.com")
print(response.json())

👉 Ideal para alta concorrência.

---

5. 🤖 APIs famosas que você VAI usar

• GitHub API
• OpenAI API
• Google Maps API
• AWS APIs

Essas são as “bases de dados modernas”.

---

🧪 Exemplo prático (modo COBOL mindset)

Cenário:

Você quer consultar dados de usuário.

import requests

url = "https://jsonplaceholder.typicode.com/users/1"
response = requests.get(url)

if response.status_code == 200:
    data = response.json()
    print(data["name"])

💡 Pense assim:

• status_code → retorno do programa
• json() → estrutura de dados (tipo copybook dinâmico)

---

⚠️ Pecados capitais do coboleiro em APIs

❌ 1. Esperar estrutura fixa (copybook mental)

JSON muda.

👉 Use:

data.get("campo", "default")

---

❌ 2. Ignorar erro HTTP

if response.status_code != 200:
    print("ERRO!")

👉 Sem isso, você vai quebrar em produção. Certeza.

---

❌ 3. Fazer tudo síncrono (modo batch)

Python moderno usa async.

---

💡 Truques de veterano (ouro puro)

🔥 1. Timeout SEMPRE

requests.get(url, timeout=5)

👉 Evita travar igual job preso em spool.

---

🔥 2. Headers = identidade

headers = {"Authorization": "Bearer TOKEN"}
requests.get(url, headers=headers)

👉 Sem isso, muitas APIs nem respondem.

---

🔥 3. Logging é vida

print(response.text)

👉 Debug de API = olhar payload.

---

🔥 4. Use Postman antes de codar

👉 Teste a API antes. Igual testar JCL antes do PROD.

---

🧠 Curiosidades que poucos sabem

• O termo REST foi criado por Roy Fielding em 2000
• JSON substituiu XML porque é mais leve
• APIs hoje substituem bancos inteiros
• Muitas empresas nem expõem mais DB — só API

👉 Ou seja:
Você não acessa dados.
Você negocia com serviços.

---

🥚 Easter Eggs (pra você brilhar na roda)

🐍 Python tem API embutida para web

import webbrowser
webbrowser.open("https://google.com")

---

🎯 requests aceita JSON direto

requests.post(url, json={"nome": "Bellacosa"})

👉 Sem precisar serializar manualmente.

---

💣 Dá pra mockar API (testes)

from unittest.mock import patch

👉 Igual simular programa no batch.

---

🔥 Conexão com o mundo Mainframe

Você não precisa abandonar COBOL.

👉 Você pode:

• Criar API em Python
• Consumir do COBOL via HTTP (CICS Web Services)
• Integrar legado com cloud

💡 Isso é o futuro real:
Mainframe + APIs + Python

---

🎯 Conclusão estilo Bellacosa

Se você ainda está pensando em arquivo sequencial…

👉 você já está atrasado.

APIs são o novo VSAM.
JSON é o novo copybook.
HTTP é o novo CICS.

E Python?

👉 É a linguagem que cola tudo isso.

---

☕ Frase final pra guardar

“Quem domina API não precisa migrar do mainframe… ele domina o mundo ao redor dele.”