☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta cloud computing. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta cloud computing. Mostrar todas as mensagens

segunda-feira, 27 de julho de 2026

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

 

Bellacosa Mainframe compara o aws com o mainframe

☕ Um Café no Bellacosa Mainframe

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

Quando um Programador COBOL Descobre que a Nuvem Não Inventou Tudo... Apenas Deu Novos Nomes às Velhas Ideias

Existe uma frase muito conhecida entre os profissionais de tecnologia:

"Toda tecnologia nova parece revolucionária... até você descobrir que o mainframe já fazia algo parecido há décadas."

Naturalmente, essa frase é um exagero. A computação em nuvem trouxe inúmeras inovações reais: elasticidade praticamente infinita, cobrança sob demanda, infraestrutura global distribuída, APIs padronizadas e uma velocidade de provisionamento que seria impensável nos anos 1970.

Por outro lado...

Quem trabalhou muitos anos em IBM Z percebe rapidamente algo curioso.

Boa parte dos conceitos fundamentais da Cloud Computing já existiam, apenas recebiam outros nomes.

É justamente isso que o infográfico procura mostrar.

Não se trata de afirmar que AWS = Mainframe.

Muito menos que um substitui o outro.

A proposta é muito mais inteligente:

Traduzir conceitos.

Da mesma forma que um brasileiro aprende inglês associando "house" com "casa", um programador COBOL aprende AWS muito mais rapidamente quando pensa:

"EC2... isso lembra uma LPAR."

É exatamente essa mudança mental que acelera o aprendizado.

Vamos aprofundar essa comparação.


Antes de tudo...

Existe um erro extremamente comum.

Muitos profissionais perguntam:

"Qual é o equivalente do AWS Lambda no Mainframe?"

Na verdade essa pergunta está errada.

O correto seria perguntar:

"Qual tecnologia do Mainframe resolve um problema semelhante?"

Porque tecnologias diferentes podem resolver o mesmo problema de maneiras completamente distintas.

É exatamente isso que veremos.


EC2 × LPAR

AWS

EC2 fornece máquinas virtuais sob demanda.

Você cria.

Liga.

Desliga.

Apaga.

Escala.

Tudo em minutos.


Mainframe

A comparação natural é a LPAR (Logical Partition).

Mas aqui existe uma enorme diferença filosófica.

Uma instância EC2 normalmente é um servidor virtual.

Uma LPAR é praticamente um computador completo.

Dentro dela existe:

  • z/OS

  • JES

  • RACF

  • CICS

  • Db2

  • MQ

  • milhares de usuários

Ou seja...

Uma única LPAR frequentemente faz o trabalho de centenas de servidores Linux.

Por isso muitos profissionais dizem:

"Comparar uma EC2 com uma LPAR é como comparar um apartamento com um condomínio inteiro."


Curiosidade

O conceito de particionamento lógico apareceu comercialmente décadas antes da virtualização popularizada pelo VMware.

A IBM fazia isso quando a maioria dos servidores ainda era física.


S3 × VSAM / DASD

Esta comparação merece cuidado.

S3 não é um disco.

É um armazenamento de objetos.

VSAM não é armazenamento de objetos.

É um método de acesso.

Então por que a comparação?

Porque ambos representam onde os dados vivem.


S3

Armazena objetos.

  • fotos

  • backups

  • vídeos

  • PDFs

  • logs

Escala praticamente infinita.


Mainframe

No IBM Z os dados normalmente ficam em:

  • DASD

  • VSAM

  • Sequential datasets

  • GDGs

  • PDS/PDSE

O conceito é diferente.

Enquanto S3 trabalha com objetos identificados por chaves, o mainframe trabalha com datasets catalogados e métodos de acesso especializados.

Um VSAM KSDS, por exemplo, comporta-se muito mais como um banco de dados indexado do que como um bucket S3.


Melhor analogia

Talvez fosse mais correto dizer:

S3 ≈ Conjunto de datasets altamente duráveis.

Não existe equivalente perfeito.


RDS × Db2 for z/OS

Aqui a aproximação é muito boa.

AWS oferece banco relacional gerenciado.

Db2 oferece banco relacional corporativo.

Mas termina aí.


O que muda?

No AWS:

Você administra menos infraestrutura.

No Mainframe:

Você administra muito mais parâmetros.

Em compensação...

Obtém níveis absurdos de disponibilidade.

Db2 z/OS foi construído para:

  • bancos

  • cartões

  • bolsas

  • governos

  • seguradoras

Milhões de transações por segundo.

Décadas de evolução.

Consistência extrema.


Easter Egg

Quando alguém diz:

"Meu banco usa RDS."

O programador de mainframe responde:

"Interessante... o meu banco inteiro usa Db2."


Lambda × CICS

Essa comparação é conceitual.

Lambda executa código quando um evento ocorre.

CICS executa transações quando uma requisição chega.

Ambos respondem a eventos.

Mas de maneiras completamente diferentes.


Lambda

Sem servidor visível.

Escala automaticamente.

Cada chamada inicia uma execução.


CICS

Servidor transacional residente.

As tarefas reutilizam recursos.

Baixíssima latência.

Controle rigoroso.

Extrema confiabilidade.


Uma transação CICS pode durar poucos milissegundos.

E atender milhares de usuários simultaneamente.

Há bancos onde o cliente insere a senha no caixa eletrônico...

E em menos de um décimo de segundo:

  • RACF valida

  • CICS executa

  • Db2 consulta

  • MQ envia mensagens

  • resposta retorna

Tudo isso antes do usuário piscar.


API Gateway × CICS Web Services

Nos últimos anos o CICS tornou-se um verdadeiro servidor de APIs.

Hoje é possível expor programas COBOL como:

  • REST

  • SOAP

  • JSON

Sem reescrever décadas de código.

A ideia é semelhante ao API Gateway:

publicar serviços de forma segura.

A diferença é que no CICS o backend muitas vezes continua sendo um programa escrito em 1989.

E funcionando perfeitamente.


CloudWatch × RMF / SMF

Talvez uma das melhores comparações.

CloudWatch monitora.

RMF mede.

SMF registra praticamente tudo.


No mainframe existem registros para:

CPU.

I/O.

Memória.

Logons.

Jobs.

CICS.

Db2.

MQ.

Segurança.

Tudo vira SMF.

Depois essas informações alimentam:

  • relatórios

  • capacity planning

  • billing interno

  • auditoria

  • performance

É praticamente uma caixa-preta de avião.


VPC × VTAM / TCP-IP

VPC cria uma rede privada lógica.

No mainframe temos:

  • TCP/IP

  • Enterprise Extender

  • SNA

  • VTAM (historicamente)

São tecnologias diferentes.

Mas ambas organizam comunicações seguras entre aplicações.

Hoje, o TCP/IP é predominante no z/OS, enquanto o VTAM permanece como parte importante da arquitetura SNA e do gerenciamento de sessões legadas.


IAM × RACF

Esta talvez seja a comparação mais intuitiva.

IAM controla identidades.

RACF controla identidades.

Mas RACF faz isso desde os anos 1970.


No RACF encontramos:

  • usuários

  • grupos

  • perfis

  • datasets

  • transações

  • comandos

  • permissões

Tudo centralizado.

Em ambientes corporativos enormes, RACF continua sendo um dos sistemas de segurança mais robustos do mercado.


CloudFront

Aqui o infográfico coloca:

Sem equivalente.

Concordo parcialmente.

CloudFront é uma CDN.

Mainframe nunca precisou distribuir imagens para milhões de navegadores.

Mas existe um conceito parecido.

CICS, z/OS Connect e balanceadores corporativos podem distribuir carga entre regiões, embora isso não seja uma CDN. Portanto, realmente não há um equivalente direto.


DynamoDB

Também não existe equivalente perfeito.

O mainframe tradicional trabalha principalmente com:

  • Db2

  • IMS DB

  • VSAM

Entretanto...

IMS Hierarchical Database possui algumas características que lembram bancos NoSQL modernos.

Não são iguais.

Mas resolvem certos problemas semelhantes.


SQS × IBM MQ

Esta comparação é excelente.

Ambos trabalham com filas.

Mensagens.

Processamento assíncrono.

Desacoplamento.

A principal diferença está no foco.

IBM MQ nasceu para ambientes corporativos críticos.

SQS nasceu para aplicações distribuídas na nuvem.

Ambos resolvem brilhantemente problemas de integração, mas IBM MQ oferece recursos avançados de transação, persistência e integração com sistemas legados que o tornam um pilar do processamento empresarial.


SNS × WTO / Console Messages

Aqui talvez seja a comparação mais discutível.

SNS distribui notificações para diversos assinantes.

Já WTO (Write To Operator) envia mensagens ao console do operador do z/OS.

Embora ambos "notifiquem", cumprem papéis muito diferentes.

Uma analogia funcional mais próxima seria:

  • SNS ↔ combinação de IBM MQ + Event Notification + automação (como IBM Z System Automation ou NetView), dependendo do cenário.

WTO é muito mais voltado para operação do sistema do que para publicação de eventos para consumidores.


O que ficou faltando?

O universo AWS é enorme. Diversos serviços modernos também encontram paralelos conceituais no ecossistema IBM Z:

AWSMainframe
EBSVolumes DASD
EFSzFS / HFS
Elastic Load BalancerSysplex Distributor
Auto ScalingWLM + Capacity on Demand
Secrets ManagerRACF Key Rings + ICSF
KMSICSF + Hardware Crypto Express
CloudTrailSMF + RACF Auditing
Systems Managerz/OSMF
ECS/EKSzCX (z/OS Container Extensions)
EventBridgeIBM MQ + CICS START + automação
Step FunctionsJCL + Scheduler (TWS/IWS, CA 7, Control-M)
GlueDFSORT, SyncSort, DataStage e ferramentas ETL
AthenaDb2 Analytics, SQL Federation e consultas distribuídas
RedshiftDb2 Analytics Accelerator (IDAA)
CognitoRACF + provedores de identidade (LDAP, SAF, z/OS Connect)

A Filosofia por Trás da Comparação

A maior lição do infográfico não é decorar equivalências.

É perceber que os problemas fundamentais da computação permanecem os mesmos:

  • executar aplicações;

  • armazenar dados;

  • proteger acessos;

  • integrar sistemas;

  • monitorar ambientes;

  • processar eventos;

  • escalar capacidade.

O que muda é a forma como cada arquitetura resolve esses desafios.

O IBM Z foi concebido para oferecer estabilidade, consistência transacional e disponibilidade extrema em um ambiente centralizado. A AWS foi projetada para privilegiar elasticidade, automação, distribuição geográfica e provisionamento sob demanda em uma infraestrutura de nuvem.

Essas filosofias não são concorrentes em todos os casos — são frequentemente complementares. Hoje, é comum encontrar bancos, seguradoras e governos executando seus sistemas críticos em IBM Z enquanto utilizam AWS para APIs, analytics, inteligência artificial, aplicações móveis e serviços digitais.


Conclusão: O Melhor Profissional Fala Dois "Idiomas"

No início da carreira, muitos especialistas em mainframe enxergavam a nuvem como uma ameaça. Da mesma forma, muitos profissionais de cloud acreditavam que o mainframe era apenas uma tecnologia ultrapassada.

Com o tempo, o mercado mostrou uma realidade bem diferente.

Os ambientes corporativos mais sofisticados são híbridos.

O cartão de crédito pode ser autorizado por um programa COBOL executando em CICS e Db2 no IBM Z, enquanto o aplicativo móvel utiliza APIs hospedadas na AWS, com autenticação moderna, monitoramento em nuvem e microsserviços.

Em vez de escolher entre "mainframe ou cloud", as organizações escolhem mainframe e cloud.

Para o profissional de tecnologia, isso significa uma oportunidade extraordinária: dominar os dois mundos. Quem entende como traduzir conceitos entre AWS e IBM Z consegue atuar como uma ponte entre equipes, acelerar projetos de modernização e preservar décadas de conhecimento corporativo enquanto incorpora as práticas mais recentes da computação em nuvem.

No fim das contas, aprender AWS não exige esquecer o mainframe. Pelo contrário: para quem já conhece IBM Z, muitas ideias da nuvem deixam de parecer completamente novas e passam a ser apenas uma nova linguagem para resolver problemas que a computação empresarial enfrenta — e resolve — há mais de meio século.

domingo, 5 de julho de 2026

Kubernetes Autoscaling Muito Além do HPA

 

Bellacosa Mainframe e o kubernetes autoscaling

☕ Um Café no Bellacosa Mainframe

Kubernetes Autoscaling Muito Além do HPA

O Que Todo Programador COBOL Padawan Precisa Saber Sobre HPA, VPA, Cluster Autoscaler e Como os Grandes Bancos Escalam Milhões de Transações Sem Desperdiçar Recursos

"No Mainframe aprendemos que desempenho nunca foi apenas velocidade. Sempre foi equilíbrio entre capacidade, disponibilidade, custo e confiabilidade. Kubernetes apenas reinventou esse conceito para a era da nuvem."


Introdução

Existe uma pergunta que praticamente todo desenvolvedor faz quando começa a estudar Kubernetes:

"Se meu sistema receber mais acessos, o Kubernetes cria novos Pods automaticamente?"

A resposta é:

Depende.

E é justamente esse "depende" que confunde milhares de profissionais todos os anos.

Quando um Programador COBOL começa a estudar Kubernetes, normalmente imagina que existe apenas um mecanismo responsável por aumentar a capacidade da aplicação.

Na prática, isso está longe da realidade.

Na verdade, Kubernetes possui diversos mecanismos diferentes de escalabilidade, cada um resolvendo um problema específico.

Alguns aumentam a quantidade de Pods.

Outros aumentam CPU e memória.

Outros adicionam novos servidores inteiros ao cluster.

Cada um trabalha em uma camada diferente da infraestrutura.

É exatamente como acontece em um grande banco.

Quando o Internet Banking começa a ficar lento, ninguém simplesmente compra um novo servidor.

Antes disso existem diversas decisões:

  • aumentar regiões CICS?

  • criar novos servidores WebSphere?

  • ajustar WLM?

  • aumentar memória?

  • ativar Capacity on Demand?

  • adicionar uma nova LPAR?

No Kubernetes acontece exatamente a mesma filosofia.

Neste artigo vamos entender profundamente como funcionam:

  • Horizontal Pod Autoscaler (HPA)

  • Vertical Pod Autoscaler (VPA)

  • Cluster Autoscaler (CA)

Sempre fazendo paralelos com IBM Z, COBOL, CICS, Batch, WLM e arquitetura corporativa.


Antes de falar sobre Autoscaling...

Precisamos entender um conceito fundamental.

O verdadeiro objetivo não é aumentar recursos.

É utilizar exatamente os recursos necessários.

Essa diferença parece pequena.

Mas muda completamente a forma de projetar sistemas.

Imagine um supermercado.

Às 3 horas da manhã existem apenas cinco clientes.

Às 18 horas existem dois mil clientes.

Você contrataria:

  • 200 caixas funcionando o dia inteiro?

Claro que não.

Também não deixaria apenas dois caixas funcionando às 18 horas.

A solução inteligente é adaptar a quantidade de caixas conforme o movimento.

É exatamente isso que Kubernetes faz.


O grande problema dos sistemas tradicionais

Durante décadas o modelo foi simples.

Comprar servidores suficientes para suportar o pior cenário.

Imagine uma aplicação bancária.

Segunda-feira:

CPU: 12%

Terça-feira:

CPU: 18%

Quarta-feira:

CPU: 22%

Na Black Friday:

CPU: 98%

O servidor foi comprado pensando apenas nesse último dia.

Resultado:

Durante praticamente todo o ano:

  • CPU parada

  • memória parada

  • discos subutilizados

  • energia desperdiçada

  • dinheiro desperdiçado

Cloud Computing mudou completamente essa lógica.

Agora infraestrutura pode crescer e diminuir automaticamente.


Elasticidade x Escalabilidade

Esses conceitos costumam ser confundidos.

Escalabilidade

É a capacidade do sistema suportar mais carga.

Exemplo:

Um servidor suporta:

500 usuários

Depois de melhorias:

5.000 usuários

Ele ficou mais escalável.


Elasticidade

É a capacidade de crescer e diminuir automaticamente.

Hoje:

2 Pods

Daqui cinco minutos:

20 Pods

Mais tarde:

4 Pods

Tudo sem intervenção humana.

Isso é elasticidade.

É justamente o coração do Kubernetes.


Os três tipos de escalabilidade

A maioria das pessoas acredita que existe apenas um tipo.

Na realidade existem três.

Escalabilidade Horizontal

Adicionar mais instâncias.

Exemplo:

Antes

2 Pods

Depois

8 Pods

Cada Pod continua igual.

Apenas existem mais deles.


Escalabilidade Vertical

Não aumenta quantidade.

Aumenta potência.

Antes

CPU 500m

Memória 512Mi

Depois

CPU 2

Memória 4Gi

Mesmo Pod.

Mais poderoso.


Escalabilidade da Infraestrutura

Agora nem estamos falando da aplicação.

Estamos falando do próprio cluster.

Antes

3 Workers

Depois

10 Workers

Agora existe espaço para muito mais Pods.


HPA — Horizontal Pod Autoscaler

Este é o autoscaler mais famoso.

Seu trabalho é extremamente simples.

Responder uma única pergunta.

Existem Pods suficientes?

Observe o que ele NÃO pergunta.

  • Existe CPU suficiente?

  • Existe memória suficiente?

  • Existem servidores suficientes?

Nada disso.

Ele pensa apenas em quantidade de Pods.


Como o HPA funciona?

Imagine uma API.

Ela começou o dia assim.

2 Pods

CPU média:

20%

Tudo funcionando.

Então começa uma campanha de marketing.

A CPU sobe para:

92%

O HPA verifica que sua meta era:

70%

Então ele faz um cálculo.

Simplificando:

Novos Pods =
Pods atuais ×
(CPU Atual / CPU Desejada)

Se havia:

4 Pods

CPU:

84%

Meta:

70%

Resultado:

4 × 84 ÷ 70

≈ 4,8

O Kubernetes arredonda.

Agora teremos:

5 Pods

Se a carga continuar aumentando:

6

8

12

20 Pods

Tudo automático.


Mas o HPA não olha apenas CPU

Esse é um erro muito comum.

Na realidade ele pode observar praticamente qualquer métrica.

Exemplos.

CPU

Memória

Requests por segundo

Tempo médio de resposta

Fila Kafka

RabbitMQ

Prometheus

Número de usuários

Sessões abertas

Mensagens pendentes

Quantidade de pedidos

Pix aguardando processamento

Fila de cartões

Custom Metrics

Isso significa que o HPA pode crescer baseado na necessidade real do negócio.

Imagine um banco.

Talvez CPU nem seja importante.

O importante pode ser:

Fila PIX > 2000

Nesse momento:

Criar novos Pods.

Muito mais inteligente.


Como o HPA conversa com Kubernetes?

O fluxo é relativamente simples.

Usuário

Ingress

Service

Pods

Kubelet mede CPU

Metrics Server coleta

API Server publica

HPA consulta

ReplicaSet aumenta Pods

Deployment cria novas réplicas

Tudo acontece continuamente.

Sem intervenção humana.


HPA não fica escalando o tempo todo

Imagine esta situação.

CPU:

69%

71%

69%

70%

71%

69%

Sem mecanismos de estabilização.

Teríamos:

8 Pods

9 Pods

8 Pods

9 Pods

8 Pods

Isso seria um desastre.

Por isso existem diversos mecanismos internos.

Cooldown.

Stabilization Window.

Tolerance.

Scale Policies.

Esses mecanismos evitam oscilações desnecessárias.


HPA possui limitações

Ele não faz milagres.

Imagine.

Seu cluster possui apenas:

2 Workers

Cada Worker possui:

8 CPUs

Todos estão completamente ocupados.

O HPA decide criar:

30 Pods

Mas onde eles serão executados?

Resposta.

Em lugar nenhum.

Eles ficam:

Pending

É aqui que entra outro personagem.


VPA — Vertical Pod Autoscaler

Agora o problema mudou completamente.

Não queremos mais criar novos Pods.

Queremos melhorar os Pods existentes.

Imagine.

Seu Deployment foi criado assim.

requests:
 cpu: 100m
 memory: 128Mi

Na prática ele utiliza:

CPU

850m

Memória

950Mi

Resultado.

CPU Throttling.

OOMKilled.

Baixo desempenho.

O VPA observa isso.


Como o VPA aprende?

Ao contrário do HPA.

Ele analisa histórico.

Dias.

Semanas.

Meses.

Depois calcula recomendações.

Exemplo.

Atual.

CPU

100m

Recomendado.

900m

Atual.

256Mi

Recomendado.

1Gi

Isso reduz desperdício.

E melhora desempenho.


Os modos do VPA

Off

Apenas recomenda.

Muito usado em produção.

Você recebe um relatório.

Mas nenhuma alteração acontece.


Auto

Atualiza automaticamente.

Se necessário reinicia Pods.

É extremamente poderoso.


Initial

Aplica apenas durante a criação.

Excelente para aplicações críticas.


Por que o VPA reinicia Pods?

Muitos iniciantes estranham isso.

O motivo é simples.

CPU e memória fazem parte da especificação do Pod.

Depois que o container está em execução.

Esses parâmetros normalmente não podem ser alterados.

Então o Kubernetes cria um novo Pod.

Com os novos valores.


O que o VPA não faz?

Não cria novos Pods.

Não cria servidores.

Não aumenta Workers.

Não substitui HPA.

São ferramentas complementares.


Cluster Autoscaler

Agora chegamos à infraestrutura.

Imagine.

Seu HPA criou:

50 Pods

Mas existem apenas:

3 Workers

Todos lotados.

Resultado.

Pods Pending

O Scheduler tenta.

Não consegue.

Agora entra o Cluster Autoscaler.


O trabalho do Cluster Autoscaler

Ele pergunta.

Existe algum Pod que não consegue ser agendado?

Se existir.

Ele conversa com o provedor de nuvem.

AWS.

Azure.

Google.

OpenShift.

VMware.

E solicita novos Workers.

Depois que os novos servidores entram no cluster.

O Scheduler distribui os Pods.


Fluxo completo

Usuários aumentam.

CPU aumenta.

HPA cria Pods.

Pods ficam Pending.

Cluster Autoscaler detecta.

Cloud cria Workers.

Workers entram.

Scheduler agenda Pods.

Aplicação volta ao normal.

Tudo automático.


Como o Cluster Autoscaler decide remover servidores?

Ele também reduz custos.

Imagine.

Domingo.

Pouquíssimos acessos.

Existem:

15 Workers

Mas apenas:

3

são necessários.

O Cluster Autoscaler verifica.

Os Pods podem ser movidos?

Se sim.

Executa.

Drain.

Eviction.

Delete Node.

Resultado.

Economia de infraestrutura.


Comparando HPA, VPA e Cluster Autoscaler

Imagine um supermercado.

HPA

Contrata mais caixas.

Mais pessoas atendendo clientes.


VPA

Entrega computadores mais rápidos para cada caixa.

Cada funcionário trabalha melhor.


Cluster Autoscaler

Constrói uma nova loja.

Agora existe espaço para muito mais caixas.

São três problemas diferentes.


Um exemplo real de um grande banco

Imagine um aplicativo bancário.

Às 8h da manhã.

Começam os acessos.

Primeiro.

O HPA aumenta.

6 Pods

↓

20 Pods

Depois percebe-se que cada Pod está consumindo muito mais memória.

O VPA recomenda.

512Mi

↓

2Gi

Agora não existe mais capacidade física.

O Cluster Autoscaler adiciona.

8 Workers

↓

16 Workers

O usuário final nem percebe.

Essa é a magia da elasticidade.


Analogia com IBM Mainframe

Quem trabalha com IBM Z perceberá rapidamente várias semelhanças.

HPA

Lembra aumentar regiões CICS.

Ou criar mais servidores Liberty.

Mais instâncias.

Mesmo programa COBOL.


VPA

Lembra ajustar REGION.

Heap Java.

Parâmetros WLM.

Mais recursos para uma região existente.


Cluster Autoscaler

Lembra.

Adicionar novas LPARs.

Capacity on Demand.

Expandir Parallel Sysplex.

Mais infraestrutura.

A filosofia é praticamente idêntica.


Quando utilizar cada um?

Use HPA.

Quando existem picos de acesso.

APIs REST.

Microsserviços.

Front-end.

Aplicações stateless.


Use VPA.

Quando deseja otimizar CPU e memória.

Eliminar desperdício.

Evitar OOMKilled.

Melhorar desempenho.


Use Cluster Autoscaler.

Quando a infraestrutura precisa crescer automaticamente.

Principalmente em Cloud.

AWS.

Azure.

Google Cloud.

OpenShift.


O futuro: KEDA e Event-Driven Autoscaling

Os mecanismos que estudamos são apenas a base. Em arquiteturas modernas, surge um quarto componente importante: o KEDA (Kubernetes Event-Driven Autoscaling).

Enquanto o HPA reage principalmente a métricas como CPU e memória, o KEDA reage a eventos.

Imagine um sistema de processamento de boletos. Não importa a CPU; o importante é saber quantos boletos aguardam processamento em uma fila do IBM MQ ou do Kafka.

Se houver 10 mensagens, um Pod é suficiente.

Se houver 10.000 mensagens, o KEDA pode solicitar ao HPA dezenas de Pods para processar a fila rapidamente.

Esse modelo aproxima o Kubernetes dos conceitos de processamento orientado a filas, muito conhecidos por profissionais de Mainframe que trabalham com IBM MQ, CICS Trigger Transactions e Batch.


Conclusão

Quando começamos a estudar Kubernetes, é comum acreditar que autoscaling significa apenas "criar mais Pods". Porém, vimos que a realidade é muito mais rica. O ecossistema foi projetado para atacar diferentes gargalos de forma especializada:

  • HPA responde ao aumento da carga criando ou removendo Pods.

  • VPA ajusta CPU e memória para que cada Pod tenha os recursos ideais.

  • Cluster Autoscaler adiciona ou remove nós do cluster conforme a capacidade física necessária.

  • KEDA amplia essa inteligência ao escalar aplicações com base em eventos e filas.

Para um Programador COBOL Padawan, essa arquitetura não deve ser vista como algo completamente novo. Ela representa a evolução de princípios que sempre existiram no mundo corporativo: distribuir carga, otimizar recursos, garantir disponibilidade e controlar custos.

No IBM Z, esses objetivos eram alcançados com WLM, Parallel Sysplex, Capacity on Demand, regiões CICS, tuning de DB2 e planejamento de capacidade. No Kubernetes, os mesmos princípios são implementados de forma declarativa, automática e integrada à nuvem.

A tecnologia mudou. As ferramentas evoluíram. Mas a missão continua exatamente a mesma: entregar sistemas resilientes, escaláveis e eficientes, capazes de atender milhões de usuários sem desperdiçar recursos. É essa mentalidade de engenharia que transforma um desenvolvedor em um verdadeiro arquiteto de soluções modernas.


sábado, 27 de junho de 2026

O Grande Equívoco: A Modernização Não é Sair do Mainframe

 

Bellacosa Mainframe e a modernizacao na Stack mainframe



☕ Um Café no Bellacosa Mainframe

O Grande Equívoco: A Modernização Não é Sair do Mainframe

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

COBOL

CICS

z/OS Connect

REST

Mobile

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.


2. Refatorar

Melhora código COBOL.

COBOL 74

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.


3. Reescrever

Maior risco.

COBOL

Java

COBOL

Go

COBOL

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.


4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age


Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico


Bellacosa Mainframe e o mainframe no Brasil


Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.


Descobrir significa:

inventário

mapear

catalogar

entender


Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.


Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta


Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

Há empresas cujo negócio inteiro está aqui.


A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.


Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

Programa B

VSAM

MQ

DB2

Batch

Scheduler

API


Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.


Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes


Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.


Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.


Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks


IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid


Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.


Go

Ótimo.

Microserviços.

Baixo consumo.


Node

Excelente APIs.

Menor adequação para batchs enormes.


.NET

Muito usado em seguradoras.


E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.


Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.


Docker resolve.

Empacotamento.

Não arquitetura.


Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança


Para muitas empresas.

OpenShift.

É mais comum.


Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.


Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.


Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.


Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic


Imagine.

SMF 110

OpenTelemetry

Grafana

Isso já acontece.


O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.


Ela lê.

20 milhões linhas COBOL.

Em minutos.


Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.


Minha visão sobre a frase central


A maior oportunidade tecnológica da próxima década não será abandonar o Mainframe, mas integrá-lo ao ecossistema moderno de APIs, IA, DevOps, observabilidade e computação híbrida.

O IBM Z não está desaparecendo. Está se tornando um nó de alto valor dentro de arquiteturas distribuídas, orientadas a eventos e assistidas por IA.

Acredito que estamos diante de uma das maiores ondas de transformação desde a popularização da internet comercial e da computação em nuvem, mas provavelmente ela não será uma história de "COBOL versus Java". Será uma história de preservar décadas de capital intelectual enquanto se adicionam capacidades modernas, reduzindo risco, aumentando a velocidade de entrega e mantendo a confiabilidade que fez o Mainframe sobreviver por mais de meio século. Afinal, substituir tecnologia é relativamente simples; substituir quarenta anos de conhecimento de negócio embutido em milhões de linhas de código é muito mais difícil.


Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe


A história do software pode ser entendida como uma sucessão de grandes ondas tecnológicas. Nos anos 1960 surgiu a Crise do Software, quando projetos se tornavam caros, atrasados e difíceis de manter, motivando o nascimento da Engenharia de Software. A Crise do Petróleo dos anos 1970 aumentou a pressão por eficiência, impulsionando a automação bancária, industrial e governamental.

Nos anos 1980 ocorreu o movimento de downsizing, migrando parte do processamento de grandes sistemas centralizados para servidores menores e estações de trabalho. Na década de 1990 surgiu o rightsizing, buscando equilibrar custos, desempenho e confiabilidade, reconhecendo que nem tudo deveria sair do mainframe.

A popularização da Internet revolucionou os negócios, exigindo aplicações conectadas, comércio eletrônico e integração global. No final dos anos 1990, o Y2K mobilizou milhares de profissionais para corrigir sistemas legados, preservando um enorme patrimônio tecnológico e renovando plataformas críticas.

A partir dos anos 2000, a Cloud Computing trouxe elasticidade, pagamento sob demanda e novas arquiteturas distribuídas, embora também revelasse desafios de custo, governança e dependência de fornecedores. Atualmente, a onda da Inteligência Artificial acelera desenvolvimento, documentação, testes e modernização de sistemas legados. Diferentemente das revoluções anteriores, a IA não elimina o conhecimento humano: amplia a capacidade dos especialistas de compreender, preservar e evoluir décadas de regras de negócio.

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/








Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...