 |
| Bellacosa Mainframe e a corrida pelo ultimo megawatt |
☕ Um Café no Bellacosa Mainframe
A Corrida pelo Último Megawatt: Nubank, Itaú, Santander, AWS, IA e o Dia em que o Mainframe Descobriu que seu Novo Concorrente Não Era a Cloud — Era a Usina Elétrica
⚡ AWS, Gravity, Datomic, Kubernetes, IBM Z, LinuxONE, IA, data centers, energia, contingência e o estranho futuro em que milhões de transações bancárias disputam megawatts com GPUs — enquanto o coronel Potter pergunta quem foi o gênio que colocou o plano de DR inteiro na mesma região
São 06h13.
Algum lugar do interior de São Paulo.
Dentro de uma barraca improvisada que inexplicavelmente contém três monitores, um terminal 3270, um cluster Kubernetes e uma cafeteira que certamente reprovaria numa auditoria elétrica, o radar começa a apitar.
BIP.
BIP.
BIP.
Radar O'Reilly entra correndo.
— Coronel! Temos problemas!
Sherman Potter nem levanta os olhos.
— Coreia?
— Pior.
— Produção?
— Muito pior.
— Fale, Radar.
Ele coloca um relatório sobre a mesa.
NUBANK
AWS
ITAÚ
SANTANDER
IA
DATA CENTERS
GPU
MAINFRAME
DEMANDA: ↑↑↑↑↑
ENERGIA DISPONÍVEL: ¯\_(ツ)_/¯
Hawkeye Pierce aparece com uma caneca.
— Quem foi atingido?
Radar responde:
— Ninguém ainda.
— Então por que estamos acordados?
— Porque todos querem construir data centers ao mesmo tempo.
Hawkeye observa o documento.
— Qual o diagnóstico?
Do outro lado da barraca, um velho sysprog que ninguém lembra de ter contratado olha para o RMF e responde:
Falta de megawatt.
Silêncio.
Potter franze a testa.
— Achei que estávamos falando de computadores.
O sysprog toma o café.
— Coronel, chegamos ao ponto em que falar de computadores significa falar de usinas elétricas.
Bem-vindo ao M*A*S*H tecnológico.
Hoje nosso paciente é o sistema bancário brasileiro.
E talvez precisemos operar.
🩺 1. O diagnóstico mudou
Durante décadas, quando discutíamos capacidade bancária, falávamos de:
CPU
MIPS
MSU
MEMÓRIA
I/O
STORAGE
TPS
Depois veio a cloud.
O discurso mudou para:
vCPU
containers
pods
nodes
autoscaling
serverless
regions
availability zones
Parecia que havíamos eliminado a limitação física.
Precisava de mais capacidade?
scale-out
Mais?
scale-out
Mais?
scale-out
Só havia um pequeno problema.
Cada scale-out eventualmente precisa virar:
CPU REAL
RAM REAL
SSD REAL
SWITCH REAL
RACK REAL
ENERGIA REAL
REFRIGERAÇÃO REAL
E eis a grande ironia da cloud:
o computador desapareceu da visão do programador, mas nunca desapareceu do planeta.
A nuvem é uma extraordinária abstração de recursos físicos.
Não uma violação das leis da termodinâmica.
🩺 2. O primeiro paciente: Nubank
O Nubank talvez seja o melhor exemplo brasileiro dessa transformação.
Ele não começou com um grande legado IBM Z para depois migrar.
Nasceu digital.
Sua história tecnológica pública inclui:
AWS
Clojure
Datomic
Kafka
Kubernetes
microservices
machine learning
E chegou a uma escala impressionante.
Em abril de 2025, a engenharia do Nu revelou operar mais de 4.000 microsserviços, processando aproximadamente 72 bilhões de eventos Kafka diariamente e lidando rotineiramente com milhões de requisições por segundo. (Building Nubank)
Em julho de 2026, outra publicação trouxe um número quase surreal:
mais de 21.000 databases em produção, distribuídos entre Brasil, México e Colômbia.
A camada de database é administrada diretamente por apenas cinco engenheiros, graças a automação, self-service e ownership distribuído. (Building Nubank)
O COBOLzeiro lê:
21.000 DATABASES
e pergunta:
— Vocês estão bem?
Sim.
É uma consequência da granularidade de uma arquitetura de microsserviços.
🩺 3. O dia em que a cloud mostrou que também possui teto
A história técnica do Nubank é particularmente interessante porque seu crescimento obrigou a empresa a enfrentar limites de capacidade e quotas.
Nos primeiros tempos, infraestrutura concentrada em poucas contas AWS foi apelidada internamente de:
Pangeia.
Um supercontinente.
PANGEIA
┌────────────────────┐
│ AWS ACCOUNT │
│ │
│ serviços │
│ Datomic │
│ Kafka │
│ Kubernetes │
│ serviços │
│ serviços │
└────────────────────┘
Funcionou.
Até crescer demais.
A concentração aumentava blast radius, complicava isolamento entre ambientes e pressionava limites.
Então surgiu a:
Continental Drift.
A Deriva Continental.
PANGEIA
|
↓
┌────────┐ ┌────────┐ ┌────────┐
│ACCOUNT │ │ACCOUNT │ │ACCOUNT │
│ A │ │ B │ │ C │
└────────┘ └────────┘ └────────┘
Domínios separados.
Recursos separados.
Falhas mais isoladas.
Quotas menos concentradas. (Building Nubank)
É arquitetura distribuída aprendendo uma das regras mais antigas da engenharia:
não coloque todos os ovos na mesma cesta.
O mainframe chama Potter.
— Coronel?
— Sim?
— Parallel Sysplex mandou lembranças.
🩺 4. Mas atenção: Nubank NÃO esgotou a AWS brasileira
Aqui precisamos colocar uma etiqueta vermelha no prontuário.
NUBANK ESGOTOU TODA A AWS BRASIL
FALSO.
Não há evidência disso.
O que relatos técnicos do Nubank mostram é que determinados modelos de crescimento chegaram a encontrar limites de recursos/capacidade.
Isso é diferente.
Imagine:
AWS BRASIL
████████████████████████████████████████
Nubank não fez:
████████████████████████████████████████
NUBANK
A situação é mais parecida com:
PRECISO:
tipo específico de recurso
+
determinada região/AZ
+
determinada configuração
+
grande quantidade
+
agora
E naquele contexto a resposta pode ser:
CAPACITY NOT AVAILABLE
A própria documentação da AWS reconhece que Availability Zones podem tornar-se capacity constrained, a ponto de o provedor restringir criação de determinados recursos zonais. (Documentação AWS)
Cloud possui estoque.
Só que você não vê o almoxarifado.
🩺 5. Entra Itaú — e agora a coisa fica realmente grande
O segundo paciente é o Itaú Unibanco.
E aqui precisamos atualizar uma informação importante.
A intenção pública divulgada pelo banco é realmente radical.
Durante o AWS re:Invent 2024, em dezembro de 2024, Ricardo Guerra, CIO do Itaú, anunciou o plano de migrar 100% dos sistemas para cloud, incluindo sistemas que atualmente executam no mainframe.
Na ocasião, 65% das aplicações já estavam em cloud.
A meta divulgada foi:
2017
|
início da jornada
|
v
2024
|
65% aplicações cloud
|
v
2028
|
migração prevista
|
v
2030
|
estabilização prevista
Portanto, a história do 2030 possui uma nuance importante.
A migração foi anunciada para 2028, seguida de aproximadamente dois anos previstos para estabilização. (BR About Amazon)
E estamos falando do coração do banco.
Os 35% restantes descritos em 2024 eram fundamentalmente rotinas contábeis — justamente a lógica mais profundamente associada ao core. (BR About Amazon)
Isso muda completamente nossa discussão.
🩺 6. Porque Itaú não é uma fintech de garagem
Migrar um sistema web é uma coisa.
Migrar:
CORE
CONTABILIDADE
LEDGER
TRANSAÇÕES
BATCH
INTEGRAÇÕES
DÉCADAS DE REGRAS
é outra.
É quase como anunciar:
“Vamos trocar o motor do avião.”
Pergunta:
— Quando?
Resposta:
— Durante o voo.
Hawkeye:
— Excelente. Quem trouxe paraquedas?
O Itaú afirma que, desde o início dessa transformação, incidentes de alto impacto na experiência dos clientes diminuíram 99%, enquanto o custo por transação caiu 55%. (BR About Amazon)
O projeto utiliza inclusive IA generativa para ajudar na modernização de aplicações mainframe através do Amazon Q Developer. (BR About Amazon)
Ou seja:
MAINFRAME
|
v
ANÁLISE / MODERNIZAÇÃO
|
+── IA GENERATIVA
|
v
AWS
Isso é uma mudança arquitetural monumental.
🩺 7. Agora entra Santander carregando Gravity
O Santander escolheu outro caminho fascinante.
O nome é:
Gravity.
Em 19 de junho de 2025, o Santander anunciou ter concluído a migração de toda a infraestrutura tecnológica core da operação espanhola para Gravity, sua plataforma cloud-based de core banking. (Santander)
E a escala espanhola já é enorme:
> 4,3 bilhões
transações/ano
picos:
~33.000 transações/segundo
O Santander anunciou ainda que Brasil e México estavam entre os próximos rollouts; com esses avanços, esperava atingir aproximadamente 80% da infraestrutura tecnológica core global migrada para cloud. (Santander)
Quando concluída, Gravity deverá lidar com mais de:
1 trilhão de operações técnicas por ano.
Radar olha para Potter.
— Coronel, acho que vamos precisar de outra extensão elétrica.
🩺 8. A parte brilhante do Gravity: execução paralela
Aqui o COBOLzeiro deveria prestar muita atenção.
O Santander não simplesmente diz:
MAINFRAME OFF
CLOUD ON
BOA SORTE.
Gravity permite processamento simultâneo.
Conceitualmente:
TRANSAÇÃO
|
┌────────┴────────┐
| |
v v
MAINFRAME CLOUD
| |
└───────┬─────────┘
|
COMPARE
|
RESULTADO IGUAL?
|
SIM
|
CUTOVER
O Santander descreve justamente capacidade de processar simultaneamente em mainframe e cloud, permitindo testes em tempo real antes da transição definitiva. (Santander)
Para quem viveu migração bancária:
isso é música.
Você não confia na apresentação do PowerPoint.
Você reconcilia.
🩺 9. E então chegam as fintechs
Agora acrescente:
Nubank
Mercado Pago
PicPay
Inter
C6
Neon
fintech A
fintech B
fintech C
Mais:
e-commerce
streaming
governo
SaaS
telecom
indústria
Todos querendo cloud.
O problema começa a parecer:
DATACENTER
BANCO ────────────────┐
FINTECH ──────────────┤
VAREJO ───────────────┤
GOVERNO ──────────────┼──► COMPUTE
TELECOM ──────────────┤
STREAMING ────────────┤
SaaS ─────────────────┘
Até aí tudo bem.
Então alguém abre a porta.
Entra um sujeito carregando 20.000 GPUs.
— Bom dia.
— Quem é você?
— Inteligência Artificial.
Hawkeye fecha os olhos.
— Estamos ferrados.
🩺 10. IA mudou a unidade de medida
Aplicações empresariais tradicionais consomem energia.
Mas infraestrutura moderna de IA aumentou dramaticamente a densidade computacional.
Agora falamos de:
GPU
GPU
GPU
GPU
GPU
GPU
+
HBM
+
NETWORK FABRIC
+
STORAGE
+
COOLING
O gargalo começa a migrar de:
TEMOS CPU?
para:
TEMOS ENERGIA?
e depois:
TEMOS SUBESTAÇÃO?
e finalmente:
A REDE DE TRANSMISSÃO CONSEGUE ENTREGAR?
A Empresa de Pesquisa Energética brasileira já trata data centers explicitamente como grandes cargas cujo crescimento afeta diretamente o planejamento de expansão da transmissão. (EPE)
Isso é importantíssimo.
Data center deixou de ser apenas assunto de CIO.
Virou assunto de planejamento energético nacional.
⚡ 11. O Brasil descobriu o problema
E aqui os números ficam extraordinários.
Depois do REDATA, instituído em setembro de 2025, ocorreu forte crescimento dos pedidos relacionados a novos data centers.
Segundo a EPE, em apenas pouco mais de 60 dias apareceram 6,4 GW adicionais em projetos solicitando estudos para conexão à Rede Básica.
O pipeline passou de:
SET/2025
19,8 GW
↓
NOV/2025
26,2 GW
(EPE)
26,2 GIGAWATTS.
Agora não estamos mais discutindo servidor.
Estamos discutindo infraestrutura elétrica em escala industrial.
E a própria EPE ressalva corretamente que isso é pipeline de projetos, não capacidade que certamente será construída: implantação depende de transmissão, telecomunicações, viabilidade financeira, garantias e outros fatores. (EPE)
⚡ 12. Onde estão querendo colocar tudo isso?
Principalmente onde você provavelmente imaginou:
São Paulo.
Segundo a EPE, existe forte concentração de projetos no estado, especialmente nas regiões metropolitanas de:
SÃO PAULO
e
CAMPINAS
(EPE)
Não é coincidência.
A região concentra:
mercado financeiro;
empresas;
telecomunicações;
fibras;
IXs;
mão de obra;
infraestrutura;
consumidores;
provedores;
ecossistema tecnológico.
São Paulo é para processamento brasileiro algo próximo do que Wall Street é para finanças americanas:
gravidade.
Quanto mais infraestrutura existe, mais infraestrutura quer ficar perto dela.
⚡ 13. Mas isso cria concentração geográfica
Imagine:
BRASIL
Brasília
●
São Paulo
████████████
Campinas
█████████
Rio ●
Sul ●
Nordeste ●
É apenas uma representação conceitual, não um mapa quantitativo.
Mas o problema é real.
Concentração produz eficiência.
Também produz risco.
Energia.
Fibra.
Subestações.
Eventos climáticos.
Falhas regionais.
Interrupções de backbone.
Se boa parte da infraestrutura crítica brasileira convergir para o mesmo eixo geográfico, surge uma pergunta desconfortável:
Quantas arquiteturas “distribuídas” estão fisicamente concentradas nos mesmos lugares?
Essa é uma pergunta extraordinariamente importante.
⚡ 14. AWS Brasil também possui geografia
A AWS possui a região brasileira sa-east-1.
Ela contém atualmente três Availability Zones:
sae1-az1
sae1-az2
sae1-az3
Cada AZ consiste em um ou mais data centers fisicamente separados, com energia, rede e conectividade redundantes; as zonas são conectadas por redes metropolitanas de baixa latência e alta largura de banda. (Documentação AWS)
Essa arquitetura permite:
REGION
┌──────┼──────┐
│ │ │
AZ1 AZ2 AZ3
Se AZ1 falhar:
AZ1 💥
AZ2 ✓
AZ3 ✓
desde que sua aplicação tenha sido realmente projetada para isso.
Esse último pedaço da frase deveria estar escrito em letras garrafais.
🩺 15. “Estamos na AWS” NÃO é plano de contingência
Esta talvez seja a lição mais importante do artigo.
Alguém pergunta:
— Temos DR?
Resposta:
— Sim. Estamos na cloud.
ERRADO.
Cloud é infraestrutura.
DR é arquitetura.
Você pode construir:
APPLICATION
|
AZ1
e possuir um belo single point of failure.
Melhor:
APPLICATION
|
┌───┴───┐
│ │
AZ1 AZ2
Melhor ainda para certos sistemas críticos:
APPLICATION
|
┌──────────┴──────────┐
│ │
REGION A REGION B
│ │
AZ1/AZ2 AZ1/AZ2
E em casos extremos:
AWS
|
+── REGION A
+── REGION B
PRIVATE CLOUD
IBM Z
A pergunta não é:
“Qual cloud você usa?”
É:
“Qual falha você consegue sobreviver?”
🩺 16. Multi-cloud resolve?
Talvez.
Mas existe um preço.
Você pode fazer:
BANK
|
┌────────┼────────┐
│ │ │
AWS GCP AZURE
Bonito.
Agora mantenha:
IAM
network
database
observability
deployment
security
skills
CI/CD
DR
data synchronization
em três plataformas.
Parabéns.
Você acabou de trocar:
RISCO DE CONCENTRAÇÃO
por:
COMPLEXIDADE OPERACIONAL
Arquitetura é frequentemente escolher qual problema você prefere possuir.
⚡ 17. O sistema elétrico brasileiro entrou oficialmente no war room
A EPE projeta que o consumo total de eletricidade brasileiro poderá chegar a aproximadamente 939 TWh em 2035 no cenário de referência.
O crescimento médio projetado é 3,3% ao ano. (EPE)
Mas existe algo mais interessante.
Cargas especiais — incluindo data centers, hidrogênio e eletromobilidade — podem representar parcela significativa da demanda futura, dependendo do cenário.
O próprio planejamento já considera data centers explicitamente. (EPE)
E o Brasil prevê cerca de:
R$ 120 bilhões
em investimentos no sistema de transmissão até 2035, no cenário de referência do PDE. (EPE)
O velho sysprog observa.
— Então precisamos fazer upgrade do backbone.
O engenheiro elétrico responde:
— Exatamente.
— Fibra?
— Não.
— Ethernet?
— Não.
— Então o quê?
— 500 kV.
Silêncio.
⚡ 18. São Paulo já precisa abrir espaço elétrico
A EPE informou que estudos concluídos recomendaram cerca de R$ 1,6 bilhão em novos investimentos de transmissão para São Paulo, capazes de liberar aproximadamente 4 GW de margem de conexão.
Outros estudos poderiam acrescentar cerca de mais 5 GW de margem no estado. (EPE)
Veja como a conversa evoluiu.
Ontem:
Precisamos de mais EC2.
Hoje:
Precisamos de mais 4 GW.
O programador pede:
kubectl scale deployment
e em algum lugar um engenheiro elétrico responde:
Calma, campeão.
🩺 19. E então IBM entra no centro cirúrgico
Agora chegamos à IBM.
Seria tentador imaginar IBM olhando Itaú, Santander e Nubank e dizendo:
CLOUD É MODA.
Não.
A resposta estratégica da IBM é muito mais sofisticada:
HYBRID CLOUD.
Não:
MAINFRAME
OU
CLOUD
mas:
ENTERPRISE
|
┌──────────┼──────────┐
│ │ │
v v v
IBM Z CLOUD LinuxONE
│ │ │
CICS Kubernetes Linux
COBOL APIs Containers
Db2 AI AI
│ │ │
└──────────┼──────────┘
|
DATA
IBM percebeu que tentar impedir cloud seria inútil.
A estratégia é fazer IBM Z participar do ecossistema moderno.
🩺 20. z17 entra na guerra
E em 7 de julho de 2026 aconteceu algo simbolicamente importante.
IBM expandiu z17 e LinuxONE 5 com configurações single-frame e rack-mount.
Pela primeira vez, rack mount passou a estar disponível através de toda essa família Z/LinuxONE. (IBM Newsroom)
Isso significa colocar arquitetura Z mais naturalmente dentro da infraestrutura contemporânea de data centers.
E o comunicado da IBM toca justamente no nosso assunto:
organizações enfrentando disponibilidade extremamente baixa de espaço em data centers e custos elevados de capacidade. (IBM Newsroom)
IBM está dizendo:
Quer falar de densidade computacional? Ótimo. Vamos conversar.
⚡ 21. O mainframe encontra sua velha arma: densidade
O argumento histórico de sistemas distribuídos era:
commodity hardware
+
scale-out
=
economia
Mas quando chegamos a milhares de servidores:
SERVERS
+
NETWORK
+
STORAGE
+
COOLING
+
ENERGY
+
RACKS
+
SOFTWARE
+
OPERATIONS
precisamos mudar a métrica.
Não pergunte apenas:
Quanto custa uma VM?
Pergunte:
TRANSAÇÕES / WATT
TRANSAÇÕES / RACK
TRANSAÇÕES / m²
TRANSAÇÕES / ADMINISTRADOR
TRANSAÇÕES / DÓLAR
Agora IBM Z volta a uma conversa na qual sempre foi extremamente confortável.
Consolidação.
⚡ 22. LinuxONE torna a discussão ainda mais divertida
Porque alguém pode responder:
— Mas não quero COBOL.
IBM:
— Tudo bem.
— Quero Linux.
— Temos.
— Containers.
— Temos.
— Kubernetes.
— Temos.
— Java.
— Temos.
— Open source.
— Temos.
CLOUD-NATIVE
|
v
CONTAINERS
|
v
LINUX
|
v
LINUXONE
Ou seja, a batalha não é necessariamente:
MAINFRAME vs CLOUD
Pode ser:
QUAL ARQUITETURA
EXECUTA ESTE WORKLOAD
COM MELHOR
CUSTO
RESILIÊNCIA
DENSIDADE
SEGURANÇA
LATÊNCIA
ENERGIA?
Essa é uma discussão muito mais madura.
🩺 23. O futuro provavelmente será heterogêneo
Não acredito que o banco de 2035 necessariamente terá:
100% MAINFRAME
nem:
100% PUBLIC CLOUD
A tendência mais interessante é:
BANCO 2035
|
┌────────────────┼────────────────┐
│ │ │
v v v
IBM Z PUBLIC CLOUD PRIVATE CLOUD
│ │ │
ledger/core digital dados
settlement analytics IA
high TPS APIs containers
│ │ │
└────────────────┼────────────────┘
|
APIs/EVENTS
Santander pode avançar muito mais na direção cloud.
Itaú declarou uma estratégia extremamente agressiva de migração.
Nubank já nasceu cloud-native.
Outras instituições poderão escolher misturas diferentes.
E isso é saudável.
⚠️ 24. Existe, porém, um risco novo: concentração sistêmica
Aqui está algo que merece atenção de bancos centrais, reguladores, CIOs e arquitetos.
No passado:
BANCO A → DC A
BANCO B → DC B
BANCO C → DC C
Agora imagine:
BANCO A ───┐
BANCO B ───┤
FINTECH A ─┤
FINTECH B ─┼──► HYPERSCALER / REGION
VAREJO ────┤
GOVERNO ───┤
SAAS ──────┘
Individualmente, cada empresa pode ter aumentado sua resiliência.
Coletivamente, podemos ter criado uma nova concentração.
Isso é o paradoxo.
Diversificação lógica pode esconder concentração física.
Dez bancos podem possuir arquiteturas diferentes...
executando em instalações que dependem dos mesmos corredores de fibra, da mesma região metropolitana ou de partes relacionadas do mesmo sistema elétrico.
⚠️ 25. E temos soberania
Outro problema.
Dados financeiros são infraestrutura estratégica.
Perguntas inevitáveis surgem:
Onde estão os dados?
Quem controla a infraestrutura?
Quem fabrica os processadores?
Quem controla o hypervisor?
Quem controla o software?
Quem possui as chaves?
Quem consegue desligar?
Qual legislação prevalece?
Cloud traz eficiência extraordinária.
Mas concentração em empresas estrangeiras também introduz questões de soberania tecnológica.
Isso não significa:
“cloud estrangeira é ruim”.
Significa:
infraestrutura crítica exige análise geopolítica além da análise técnica.
O CIO de 2035 precisará conversar com:
CISO
CFO
regulador
engenheiro elétrico
jurídico
geopolítica
O emprego ficou mais interessante.
⚠️ 26. Água também entra na conversa
Data centers precisam dissipar calor.
Dependendo da tecnologia de refrigeração, disponibilidade hídrica também pode ser relevante.
Então o site selection passa a considerar:
ENERGIA
+
ÁGUA
+
FIBRA
+
LATÊNCIA
+
TERRENO
+
IMPOSTOS
+
CLIMA
+
RISCO
+
MÃO DE OBRA
O data center moderno é quase uma cidade industrial.
A aplicação continua dizendo:
POST /payment
Mas atrás dela pode existir uma infraestrutura de centenas de milhões ou bilhões.
⚡ 27. A IA piora tudo — e pode ajudar
Aqui existe outro paradoxo maravilhoso.
IA aumenta brutalmente demanda computacional.
Mas IA também pode otimizar:
cooling
capacity
scheduling
energy
fraud
operations
predictive maintenance
Então:
IA
|
+── consome energia
|
└── ajuda a economizar energia
M*A*S*H teria orgulho.
Criamos um paciente que também trabalha no hospital.
🩺 28. Como deveria ser a contingência bancária?
Para um sistema realmente crítico, eu pensaria em camadas.
Nível 1 — aplicação
retry
timeout
circuit breaker
idempotency
Nível 2 — compute
multiple instances
autoscaling
Nível 3 — AZ
AZ A
AZ B
AZ C
Nível 4 — região
REGION A
REGION B
Nível 5 — plataforma
Dependendo do risco:
PUBLIC CLOUD
+
PRIVATE INFRASTRUCTURE
Nível 6 — dados
replication
backup
immutable backup
reconciliation
Nível 7 — operação
runbook
war room
chaos testing
DR exercise
Porque existe uma diferença enorme entre:
TEMOS DR
e:
TESTAMOS DR NA SEMANA PASSADA.
A segunda frase vale muito mais.
🩺 29. E não esqueça o modo degradado
Bancos deveriam perguntar:
Se 30% da infraestrutura desaparecer, precisamos realmente desligar 100% do banco?
Talvez não.
Imagine:
NORMAL MODE
PIX
CARTÃO
INVESTIMENTOS
EXTRATOS
MARKETING
RECOMENDAÇÕES
CHATBOT
ANALYTICS
Durante crise:
SURVIVAL MODE
PIX
CARTÃO
SALDO
AUTENTICAÇÃO
todo o resto:
WAIT
Aviação, telecomunicações e sistemas críticos conhecem bem esse conceito.
Preservar funções essenciais pode ser melhor que tentar manter tudo e perder tudo.
🩺 30. A grande pergunta do iniciante COBOL
Depois de tudo isso, o jovem programador pergunta:
— Então mainframe venceu?
Não.
— Cloud venceu?
Também não.
— Então quem venceu?
O velho sysprog aponta para a tomada.
⚡
— Ele.
Porque:
COBOL precisa energia.
CICS precisa energia.
Db2 precisa energia.
Kubernetes precisa energia.
Datomic precisa energia.
Kafka precisa energia.
GPU precisa MUITA energia.
Não existe:
cloud computing
sem:
electricity
A física é o sistema operacional abaixo de todos os sistemas operacionais.
☕ 31. O verdadeiro capacity planner de 2035
Talvez o capacity planner futuro não esteja olhando apenas:
CPU 73%
Ele estará olhando:
CPU ............ 73%
GPU ............ 91%
POWER .......... 87%
COOLING ........ 79%
GRID CAPACITY .. 93%
WATER .......... 68%
CARBON ......... 74%
NETWORK ........ 61%
E então perguntará:
Posso executar esse treinamento de IA agora?
Resposta:
JOB HELD
REASON:
POWER CAPACITY
O velho JES2 começa a rir em algum lugar.
🏥 Epílogo — 23h47 no M*A*S*H
Radar entra novamente.
— Coronel!
Potter olha assustado.
— O que caiu agora?
— Nada.
— Então por que está correndo?
— O pessoal da aplicação pediu mais 5.000 GPUs.
Potter olha para Hawkeye.
Hawkeye olha para B.J.
B.J. olha para Klinger.
Klinger, inexplicavelmente vestido de eletricista, pergunta:
— Quantos megawatts?
Radar consulta o papel.
Silêncio.
Potter suspira.
— Ligue para a cloud.
Radar pega o telefone.
Espera.
Desliga.
— E então?
— Disseram que precisamos falar com a concessionária.
O velho sysprog começa a rir.
Hawkeye pergunta:
— Qual a graça?
Ele abre um relatório antigo.
Na capa:
CAPACITY PLANNING
IBM MAINFRAME
1987
— Passamos quarenta anos tentando explicar que recurso computacional não é infinito.
Toma o último gole do café.
— A cloud finalmente concordou conosco.
Potter aponta para o mapa do Brasil.
São Paulo.
Campinas.
Fibra.
Subestações.
AWS.
Bancos.
Fintechs.
IA.
Data centers.
Linhas de transmissão.
Usinas.
E finalmente percebe que o diagrama correto nunca foi:
CLIENTE
|
APP
|
CLOUD
Era:
CLIENTE
|
APP
|
API
|
MICROSERVIÇOS
|
KUBERNETES / IBM Z
|
DATA CENTER
|
RACK
|
CPU/GPU
|
SUBESTAÇÃO
|
TRANSMISSÃO
|
GERAÇÃO
|
⚡
E lá embaixo, escondido sob todas as abstrações modernas, estava o verdadeiro ROOT.
Não Kubernetes.
Não AWS.
Não Clojure.
Não COBOL.
Não z/OS.
Não Linux.
Mas:
//POWER JOB
// EXEC PGM=ELETRICIDADE
Sem ele:
IEF450I CLOUD - ABEND=S0WATT
Hawkeye observa a tela.
— Podemos reiniciar?
O engenheiro elétrico responde:
— A usina?
— É.
— Não recomendo.
Potter fecha o prontuário.
Diagnóstico final
O futuro bancário brasileiro não será decidido apenas pela disputa:
mainframe versus cloud.
Será decidido pela capacidade de combinar computação, energia, telecomunicações, resiliência, segurança, soberania, economia e arquitetura.
O Nubank mostrou que uma instituição cloud-native pode alcançar escala bancária monumental.
O Itaú declarou uma rota para levar até seu coração transacional para cloud.
O Santander está transformando seu core através do Gravity.
AWS e outras hyperscalers continuam expandindo infraestrutura.
IBM responde apostando em hybrid cloud, IA, LinuxONE, z17 e densidade computacional.
E a IA acrescenta uma demanda gigantesca que nenhum capacity planner bancário de 1990 imaginaria.
Enquanto isso, o Brasil possui projetos de data centers que somavam 26,2 GW de pedidos em processo no MME em novembro de 2025, embora apenas uma fração disso necessariamente venha a se materializar. São Paulo concentra grande parte dessa corrida e já exige bilhões em expansão da transmissão. (EPE)
Portanto, talvez a grande discussão da próxima década não seja:
“COBOL ou Java?”
Nem:
“IBM Z ou AWS?”
Nem mesmo:
“Mainframe ou Kubernetes?”
Talvez seja:
“Onde estão os próximos 500 megawatts, quanto custam, como chegam até o data center e o que acontece com meu banco se eles desaparecerem?”
E quando essa pergunta finalmente chegar à reunião de arquitetura, haverá um velho sysprog no fundo da sala.
Ele não dirá nada.
Apenas abrirá o RMF.
Pegará o café.
E sorrirá.
Porque, depois de cinquenta anos de revoluções tecnológicas, alguém finalmente redescobriu a primeira lei não escrita do CPD:
Você pode virtualizar o servidor. Pode abstrair o storage. Pode containerizar a aplicação. Pode distribuir o banco. Pode chamar o datacenter de cloud. Pode até pedir para uma IA escrever o código.
Mas ainda não inventaram
autoscalingpara a tomada.
☕ Fim do café.
