Translate

Mostrar mensagens com a etiqueta Tecnologia Bancária. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Tecnologia Bancária. Mostrar todas as mensagens

terça-feira, 23 de junho de 2026

A Saga de Vagner Bellacosa no Reino dos Mainframes

 



☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe


Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.


O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.


O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.


Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.


O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."


O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.


O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.


Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

quarta-feira, 17 de junho de 2026

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

 

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.

terça-feira, 16 de junho de 2026

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

 

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.


segunda-feira, 15 de junho de 2026

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

 

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.


sexta-feira, 12 de junho de 2026

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

 

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/








quinta-feira, 16 de abril de 2026

💥 CICS Não é Legado: Como o CICS TS 6.3 Está Processando Milhões de Transações por Segundo (Enquanto o Mundo Ainda Subestima o Mainframe)

 

Bellacosa Mainframe apresenta o CICS TS versão 6.3

💥 CICS Não é Legado: Como o CICS TS 6.3 Está Processando Milhões de Transações por Segundo (Enquanto o Mundo Ainda Subestima o Mainframe)

🧠 CICS Transaction Server – visão geral atual

O produto que manda no jogo é o
👉 IBM CICS Transaction Server for z/OS

  • Middleware transacional de altíssimo volume
  • Base de praticamente todos os bancos, seguradoras e governos
  • Arquitetura cooperativa de multitarefa (quase um “mini-OS dentro do z/OS”)

🚀 Versão mais recente (estado da arte)

👉 Versão atual: CICS TS 6.3
👉 Data de GA: 05 de setembro de 2025

📌 Importante:

  • A linha 6.x segue modelo continuous delivery
  • Atualizações continuam saindo (inclusive em 2026)

🧬 Evolução recente (6.1 → 6.2 → 6.3)

🟢 CICS TS 6.1 (2022)

  • Base da nova geração
  • Foco:
    • APIs modernas
    • Cloud enablement
    • Melhor governança operacional

🟡 CICS TS 6.2 (2024)

  • Performance tuning pesado
  • Melhorias operacionais reais (não só dev)
  • Consolidação da documentação (6.x unificado)

💡 Destaque Bellacosa:

Aqui o CICS começou a “respirar DevOps de verdade”


🔵 CICS TS 6.3 (2025 – atual)

  • Foco forte em:
    • Observabilidade (OpenTelemetry)
    • Segurança
    • Automação operacional
    • Integração com APIs modernas

Exemplo prático:

  • Flush automático de dados de telemetria (SMF + observabilidade moderna)

🔐 Segurança evoluída

  • HSTS (HTTP Strict Transport Security)
  • Melhor visibilidade de login (tentativas, timestamps)

⚙️ Limites operacionais (o que ninguém te explica direito)

Agora vem o ouro 👇 (estilo Bellacosa raiz)

👥 Limite de usuários

👉 Não existe limite fixo definido pelo CICS

Depende de:

  • Região (QR TCB)
  • Storage (EDSAs / GDSA / RDSA)
  • Tuning de SIT

💡 Na prática:

  • Milhares de usuários simultâneos são comuns
  • Bancos operam com dezenas de milhares

🧵 Limite de tasks (TCLASS / MAXTASKS)

👉 Controlado por:

  • MXT (Max Tasks global da região)
  • TCLASS (limite por tipo de workload)

💥 Valores típicos:

  • MXT: 500 até 2000+ (ou mais em ambientes modernos)
  • Pode escalar dependendo de CPU e tuning

📌 Importante:

  • Cada transação = 1 TASK
  • CICS é cooperativo (não preemptivo)

🔁 Limite de transações por segundo (TPS)

👉 Não existe limite fixo no produto

Depende de:

  • CPU (MSU / MIPS)
  • I/O (VSAM / DB2 / MQ)
  • Locking
  • Design da aplicação

💥 Casos reais:

  • 10.000+ TPS → comum
  • 50.000+ TPS → ambientes financeiros pesados

🧠 Limite de memória (Storage)

Controlado por:

  • DSAs:
    • CDSA
    • EDSA
    • RDSA
  • 31-bit vs 64-bit storage

💡 Tendência moderna:
👉 mover tudo possível para 64-bit storage (above the bar)


🧬 Limite de regiões CICS

👉 Ilimitado na prática (depende do z/OS)

Arquiteturas modernas usam:

  • CICSPlex SM
  • TOR / AOR / FOR separation

🏗️ Arquitetura operacional (visão de campo)

🧩 Componentes chave

  • QR TCB → coração da região
  • Open TCBs → paralelismo real (DB2, MQ, Java)
  • Dispatcher CICS → controla multitarefa
  • Program Control (PC)
  • Task Control (TC)

🔄 Modelo de execução

  1. Terminal / API chama transação
  2. CICS cria TASK
  3. Dispatcher gerencia CPU
  4. TASK usa serviços:
    • VSAM
    • DB2
    • MQ
  5. Commit (syncpoint)

🔥 O que realmente mudou (visão prática)

Antes (CICS clássico)

  • 3270
  • COBOL puro
  • VSAM pesado
  • Transação síncrona

Agora (CICS moderno)

  • REST via z/OS Connect
  • APIs JSON
  • Observabilidade (OpenTelemetry)
  • Integração cloud
  • DevOps pipeline

💥 Em resumo:
👉 CICS virou Application Server corporativo de missão crítica


📊 Pontos fortes atuais

  • Escalabilidade absurda (vertical + horizontal)
  • Resiliência (quase zero downtime)
  • Integração híbrida (legacy + cloud)
  • Segurança nível bancário

⚠️ Gargalos reais (sem romantizar)

  • Aplicação mal escrita = gargalo (não o CICS)
  • Lock em VSAM/DB2
  • TASK segurando CPU (não liberando)
  • Storage mal dimensionado
  • Falta de paralelismo (Open TCB subutilizado)

🧠 Conclusão estilo Bellacosa

CICS hoje não é legado.

👉 É core digital escondido atrás de APIs modernas

E a versão 6.3 consolida isso:

  • Mais observável
  • Mais seguro
  • Mais integrado
  • Mais preparado para cloud






sexta-feira, 3 de abril de 2026

💀 Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações

 

Bellacosa Mainframe introduz o DB2

💀 “Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações”

Se você acha que banco de dados é só “guardar informação”… prepare-se: no mundo corporativo pesado — bancos, seguradoras, governos — quem reina é a dupla COBOL + Db2.
E não, isso não é legado morto. Isso é infraestrutura crítica global.


🧬 Origem: quando dados viraram ciência

Antes do Db2, existia caos.

  • arquivos flat
  • duplicação
  • dificuldade de acesso

Então surge o modelo relacional, criado por Edgar F. Codd na IBM.

👉 Resultado:

  • tabelas
  • chaves
  • SQL

E nos anos 80 nasce o Db2, trazendo isso para o mundo enterprise.


🏛️ Db2 no Mainframe: onde o jogo é sério

O Db2 roda no z/OS, lado a lado com:

  • COBOL
  • CICS
  • IMS

💀 Tradução:

Isso aqui processa dinheiro de verdade


☕ O Dev COBOL Sênior (vida real)

Imagine um sistema bancário:

Cliente faz transferência → COBOL → Db2 → commit

💡 Exemplo COBOL + Db2

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - 100
WHERE ID = :ORIGEM
END-EXEC.

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + 100
WHERE ID = :DESTINO
END-EXEC.

EXEC SQL
COMMIT
END-EXEC.

👉 Simples? Sim.
👉 Crítico? ABSURDAMENTE.


🔄 Transações: o coração do sistema

Você viu isso no módulo — aqui é onde ganha vida:

START → UPDATE → COMMIT

Se falhar:

ROLLBACK

💀 Isso evita:

  • dinheiro sumir
  • inconsistência

📜 Logging: a caixa preta do banco

Db2 registra TUDO:

  • INSERT
  • UPDATE
  • DELETE

👉 Isso permite:

  • auditoria
  • recovery
  • rastreamento

💡 Insight

Sem log… você está cego
Com log… você reconstrói o passado


🔄 Recovery: sobrevivência do sistema

Cenário:

  • backup às 6:00
  • falha às 11:00

👉 solução:

Backup + Logs = estado correto

💾 Backup no mundo real

❄️ Cold

  • banco parado

🌡️ Warm

  • leitura apenas

🔥 Hot

  • banco online (produção)

💀 No banco:

parar sistema não é opção → usa hot backup


🔒 Locking: guerra silenciosa

3 programas acessando o mesmo registro:

App1 → lock
App2 → espera
App3 → leitura controlada

👉 Locks evitam corrupção


💡 Regra de ouro

Lock só é liberado no COMMIT


⚡ Performance: onde o DBA brilha

📦 Buffers

  • memória → rápido

📚 Index

  • busca instantânea

⚙️ Optimizer

  • escolhe melhor plano

👉 Exemplo:

Sem índice:

SELECT * FROM CLIENTE WHERE NOME='JOÃO';

Com índice:

CREATE INDEX IDX_NOME ON CLIENTE(NOME);

⚡ diferença absurda


🌐 Integração moderna (sim, Db2 evoluiu)

Hoje Db2 conversa com:

  • APIs
  • Java (JDBC)
  • ODBC
  • microservices

👉 Não é mais só terminal verde 😄


🧠 Stored Procedures: lógica dentro do banco

CREATE PROCEDURE TRANSFERIR(...)

👉 roda dentro do Db2
👉 menos rede
👉 mais performance


🧬 Easter Eggs & Curiosidades

💡 Db2 nasceu dentro da IBM Research
💡 COBOL ainda processa ~70% das transações financeiras mundiais
💡 Muitos sistemas críticos têm décadas sem downtime significativo


💀 Easter Egg raiz:

“If it ain’t broken, don’t migrate it”
(tradução: se está rodando há 30 anos… NÃO mexe 😄)


🔥 Insight nível Bellacosa

Mainframe não é legado…
é infraestrutura estável, segura e absurda em escala


🧠 Visão final (arquitetura)

Usuário → Aplicação (COBOL) → Db2 → Dados

Logs / Backup / Recovery

🚀 Conclusão

Você começou aprendendo:

  • o que é banco
  • modelos
  • DBMS
  • transações
  • logs
  • backup
  • performance

👉 E chegou aqui:

💀 Entendendo como o mundo financeiro roda


💥 Frase final

Enquanto todo mundo fala de cloud…
o dinheiro do mundo continua passando por COBOL + Db2