 |
| Bellacosa Mainframe e o legado do projeto Big Green de 2007 |
☕ Um Café no Bellacosa Mainframe
Big Green 2007: o Dia em que a IBM Avisou que o Data Center Ficaria sem Tomada — e Ninguém Imaginava que 19 Anos Depois Chegariam as GPUs
🌱 z/VM, consolidação, Linux on System z, Project Big Green, LinuxONE, z17, IA, watts, megawatts e a perturbadora descoberta de que a resposta para a vida, o universo e tudo mais talvez continue sendo 42 — mas alguém precisa descobrir quantos kWh são necessários para calculá-la
NÃO ENTRE EM PÂNICO.
Essa é provavelmente a primeira recomendação que deveria estar impressa em letras grandes e amigáveis na porta de qualquer data center moderno.
A segunda seria:
TRAGA UMA TOALHA.
A terceira, acrescentada pelo administrador do CPD:
E NÃO LIGUE MAIS NENHUM SERVIDOR SEM FALAR COM O ELETRICISTA.
Estamos em 2007.
O iPhone original acaba de aparecer.
Kubernetes não existe.
Docker não existe.
ChatGPT não existe.
Ninguém está perguntando ao computador se deve terminar o namoro.
Uma GPU ainda é, para a maioria das pessoas, aquela coisa que faz Crysis ficar bonito.
E, em algum escritório da IBM, alguém olha para milhares de servidores espalhados por data centers e percebe algo preocupante:
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
↓
⚡⚡⚡
A IBM então faz aquilo que empresas de tecnologia costumam fazer quando descobrem que existe um problema enorme:
dá um nome para ele.
Em 10 de maio de 2007, nasce o:
PROJECT BIG GREEN
A IBM anunciou uma iniciativa de US$ 1 bilhão por ano em tecnologias e serviços voltados a melhorar a eficiência energética dos data centers. O projeto incluía uma equipe mundial de centenas de especialistas e atacava servidores, armazenamento, refrigeração, virtualização, gerenciamento e instalações. (IBM)
O detalhe delicioso?
Dezenove anos depois estamos discutindo exatamente o mesmo problema.
Só que agora alguém estacionou um caminhão cheio de GPUs na porta.
🌌 Capítulo I — No princípio havia o mainframe
Muito antes de alguém inventar:
VMware
Docker
Kubernetes
Cloud
o mainframe já tinha descoberto uma coisa fundamental:
computador parado é computador caro.
Imagine uma máquina física utilizada por uma única aplicação:
┌────────────────────┐
│ SERVIDOR │
│ │
│ CPU ███░░░░░░░ 30% │
│ │
└────────────────────┘
Setenta por cento da capacidade pode permanecer ociosa durante boa parte do tempo.
Agora multiplique:
SERVER A → 15%
SERVER B → 20%
SERVER C → 8%
SERVER D → 12%
SERVER E → 27%
SERVER F → 6%
Todos ligados.
Todos consumindo energia.
Todos ocupando rack.
Todos precisando de refrigeração.
Todos possuindo componentes.
Todos precisando ser administrados.
O mainframe desenvolveu outra filosofia:
MAINFRAME
│
┌────────┼────────┐
│ │ │
VM VM VM
│ │ │
Linux Linux Linux
│ │ │
APP A APP B APP C
Compartilhe o monstro.
🧙 Capítulo II — z/VM, o ancestral que ninguém convidou para a festa da virtualização
Quando a indústria começou a descobrir entusiasmada a virtualização de servidores x86, havia veteranos de mainframe olhando aquilo com a mesma expressão de um elfo de 4.000 anos vendo humanos descobrirem cerveja.
— Virtualização!
— Fascinante.
— Podemos executar várias máquinas virtuais numa máquina física!
— Sim.
— Isso é revolucionário!
— Naturalmente.
— Você não parece impressionado.
— Meu avô fazia isso.
A linhagem do VM da IBM remonta aos sistemas CP/CMS dos anos 1960 e posteriormente VM/370.
Décadas depois chegamos ao z/VM.
E o conceito fundamental continuava extraordinariamente atual:
HARDWARE
│
z/VM
│
├── Linux
├── Linux
├── Linux
├── Linux
├── Linux
└── Linux
Em vez de possuir cem máquinas físicas para cem workloads, você poderia consolidar muitos deles.
Essa palavra — consolidação — será importantíssima para nossa história.
Porque o problema energético não é simplesmente:
Quanto uma CPU consome?
É também:
Quantas CPUs, fontes, placas-mãe, discos, interfaces, switches e ventiladores preciso manter ligados para entregar determinada quantidade de trabalho útil?
🐋 Capítulo III — Surge a epidemia do servidor pequeno
Nos anos 1990 e 2000, servidores Unix e depois x86 se multiplicaram.
Havia uma lógica perfeitamente razoável.
Uma aplicação?
Servidor.
Outra aplicação?
Outro servidor.
Banco?
Servidor.
Web?
Servidor.
E-mail?
Servidor.
Aplicação do departamento que ninguém sabe mais quem usa?
Naturalmente:
servidor.
Logo:
DATA CENTER
APP1 → SERVER
APP2 → SERVER
APP3 → SERVER
APP4 → SERVER
APP5 → SERVER
APP6 → SERVER
APP7 → SERVER
APP8 → SERVER
...
Nasceu o famoso:
server sprawl.
O problema não era apenas comprar servidores.
Era alimentá-los.
Refrigerá-los.
Conectá-los.
Atualizá-los.
Monitorá-los.
Administrá-los.
E encontrar espaço físico para colocar todos.
Então alguém da IBM provavelmente contemplou aquilo e pensou:
Vocês passaram vinte anos fugindo de computadores grandes e agora construíram um computador grande utilizando cinco mil computadores pequenos.
🌱 Capítulo IV — 10 de maio de 2007: Big Green
Chegamos ao nosso momento histórico.
A IBM anuncia o Project Big Green.
O problema identificado era essencialmente:
CRESCIMENTO DA COMPUTAÇÃO
↓
MAIS SERVIDORES
↓
MAIS ELETRICIDADE
↓
MAIS CALOR
↓
MAIS REFRIGERAÇÃO
↓
MAIS ELETRICIDADE
Observe a perversidade.
Energia alimenta o computador.
O computador produz calor.
Você então utiliza mais energia...
para retirar o calor produzido pela primeira energia.
Douglas Adams provavelmente teria apreciado isso.
A solução Big Green não era simplesmente:
COMPRE MAINFRAME.
Era mais abrangente.
Envolvia:
BIG GREEN
│
┌──────────────┼──────────────┐
│ │ │
COMPUTE STORAGE FACILITIES
│ │ │
virtualização gerenciamento refrigeração
│ │ │
consolidação dados energia
O projeto pretendia olhar para o data center como sistema.
Essa diferença é importante.
🐧 Capítulo V — 3.900 servidores entram num bar...
E apenas aproximadamente 30 mainframes saem.
Não é piada.
Em 1º de agosto de 2007, a IBM anunciou um dos experimentos mais espetaculares dessa estratégia:
consolidar aproximadamente 3.900 servidores em cerca de 30 System z.
A empresa estabeleceu como objetivo uma redução de aproximadamente 80% no consumo energético relacionado àquele ambiente ao longo de cinco anos. (IBM)
A arquitetura conceitual era:
ANTES
Unix Unix x86 Unix x86
x86 Unix x86 x86 Unix
x86 x86 x86 Unix x86
...
~3.900 servidores
↓
DEPOIS
~30 SYSTEM z
│
z/VM
│
Linux Linux Linux
Linux Linux Linux
Linux Linux Linux
Não estavam colocando 3.900 aplicações dentro de uma gigantesca imagem z/OS.
A estrela aqui era:
Linux on System z.
Isso é essencial para entender o restante da história.
🐧 Capítulo VI — “Mas mainframe não roda só COBOL?”
Não.
E aqui mora um dos mal-entendidos mais persistentes sobre IBM Z.
Você pode ter:
IBM Z
│
├── z/OS
│ ├── COBOL
│ ├── CICS
│ ├── Db2
│ └── IMS
│
└── Linux
├── Java
├── databases
├── middleware
└── aplicações open source
Portanto, a proposta Big Green podia dizer ao cliente:
Não precisa reescrever seu servidor Linux em COBOL.
O COBOLzeiro no fundo da sala:
— Pena.
O arquiteto:
— Não ajude.
Você poderia mover workloads Linux para uma plataforma altamente consolidada.
E z/VM funcionava como peça fundamental dessa equação.
⛽ Capítulo VII — O mainframe ganha marcador de combustível
Em outubro de 2007, IBM avançou ainda mais na conversa sobre energia com aquilo que ficou conhecido como:
Mainframe Gas Gauge.
A ideia era fantástica em sua simplicidade.
Se energia virou recurso de data center, precisamos medi-la como recurso operacional.
Pense:
PAINEL DO MAINFRAME
CPU ███████░░░ 70%
MEMORY ██████░░░░ 60%
I/O █████░░░░░ 50%
POWER ███████░░░ 70%
Isso representa uma mudança conceitual enorme.
O capacity planner tradicionalmente perguntava:
Quantos MIPS?
Quantos MSUs?
Quanto DASD?
Quanto storage?
Quanto CPU?
Agora precisava acrescentar:
Quantos WATTS?
E essa pequena pergunta de 2007 acabaria virando uma pergunta monstruosa em 2026:
QUANTOS MEGAWATTS?
🪐 Capítulo VIII — Enquanto isso, nasce outra criatura: cloud
Agora nossa história sofre uma reviravolta digna do Restaurante no Fim do Universo.
IBM tinha diagnosticado corretamente:
SERVIDORES SUBUTILIZADOS
=
DESPERDÍCIO
Mas o mercado encontrou outra solução.
Em vez de:
MEUS 5.000 SERVIDORES
↓
IBM Z
surgiu:
MEUS 5.000 SERVIDORES
↓
NÃO SÃO MAIS MEUS
↓
CLOUD
Genial.
O servidor desapareceu!
Exceto...
não desapareceu.
Mudou de endereço.
EMPRESA
servidor servidor servidor
↓ CLOUD
HYPERSCALER
servidor servidor servidor
servidor servidor servidor
servidor servidor servidor
servidor servidor servidor
A cloud pegou vários princípios economicamente semelhantes:
consolidação, virtualização, compartilhamento, automação e melhor utilização da infraestrutura.
Só os aplicou numa escala completamente diferente.
☁️ Capítulo IX — Someone Else's Computer
A famosa piada diz:
The cloud is just someone else's computer.
É uma simplificação, mas contém uma verdade física maravilhosa.
Quando você executa:
CREATE INSTANCE
não ocorre:
☁️
✨
COMPUTADOR
✨
Em algum lugar existe:
DATA CENTER
│
RACK
│
SERVER
│
CPU
RAM
NIC
SSD
│
⚡
A cloud tornou capacidade programável.
Não tornou capacidade infinita.
Essa distinção nos traz diretamente de volta ao Big Green.
🐧 Capítulo X — 2015: LinuxONE aparece
Agora avance oito anos.
17 de agosto de 2015.
A IBM lança oficialmente:
LinuxONE
Os dois nomes originais eram deliciosamente grandiosos:
LinuxONE Emperor
LinuxONE Rockhopper
O Emperor era destinado a grandes organizações; o Rockhopper, a configurações menores. A IBM dizia que o Emperor poderia escalar para milhares de máquinas virtuais ou containers e destacava compatibilidade com software aberto. (Investing.com)
A mensagem era clara.
Você diz:
— Quero Linux.
IBM:
— Certo.
— Open source.
— Certo.
— PostgreSQL.
— Certo.
— Containers.
— Certo.
— Então não quero mainframe.
IBM:
— Temos uma surpresa sobre a caixa onde tudo isso está rodando.
😄
🌱 Capítulo XI — Big Green não morreu; sofreu um RENAME
Esta é minha interpretação histórica favorita.
Não existe uma linha simples:
PROJECT BIG GREEN
↓
SUCESSO
nem:
PROJECT BIG GREEN
↓
FRACASSO
O que aconteceu foi mais interessante.
O branding Big Green desapareceu gradualmente.
Mas seus princípios foram absorvidos.
BIG GREEN
│
↓
CONSOLIDAÇÃO
│
↓
LINUX ON SYSTEM z
│
↓
LinuxONE
│
↓
HYBRID CLOUD
│
↓
IBM Z + LinuxONE
│
↓
IA
A campanha morreu.
A pergunta permaneceu:
Quanto trabalho útil conseguimos realizar utilizando determinada quantidade de infraestrutura?
🧮 Capítulo XII — O erro de medir apenas preço por servidor
Imagine:
Arquitetura A
1.000 servidores baratos
Arquitetura B
10 máquinas extremamente caras
Perguntar:
Qual servidor é mais barato?
é quase inútil.
Precisamos calcular:
CUSTO TOTAL
────────────
TRANSAÇÕES
E também:
TRANSAÇÕES / WATT
TRANSAÇÕES / RACK
TRANSAÇÕES / m²
TRANSAÇÕES / ADMINISTRADOR
Além de:
software
licenciamento
networking
storage
backup
energia
refrigeração
operações
downtime
segurança
É o famoso:
TCO — Total Cost of Ownership.
O servidor barato pode gerar arquitetura cara.
O servidor caro pode gerar arquitetura barata.
Ou vice-versa.
A resposta correta da engenharia é aquela frase profundamente irritante:
Depende.
🤖 Capítulo XIII — Então chegou a IA
E agora nossa história enlouquece.
Durante anos, Big Green estava preocupado com:
CPU
CPU
CPU
CPU
Então chegaram os aceleradores.
GPU GPU GPU GPU
GPU GPU GPU GPU
GPU GPU GPU GPU
Modelos modernos de IA podem exigir enormes clusters de aceleradores para treinamento. A própria infraestrutura de desenvolvimento de IA generativa da IBM descreve cenários nos quais milhares de GPUs precisam cooperar em um único treinamento. (arXiv)
De repente:
WATTS
↓
kW
↓
MW
↓
GW?
E alguém na sala diz:
— Precisamos escalar o cluster.
O eletricista pergunta:
— Quanto?
O cientista de dados responde:
— Muito.
— Isso não é unidade.
— Então... absurdamente muito.
⚡ Capítulo XIV — O último megawatt
Agora ligamos este artigo à nossa investigação anterior sobre data centers brasileiros.
O limite computacional moderno começa a envolver:
CPU
GPU
RAM
STORAGE
NETWORK
│
↓
POWER
│
↓
COOLING
│
↓
SUBSTATION
│
↓
TRANSMISSION
│
↓
GENERATION
Eis o detalhe quase filosófico:
quanto mais abstrata ficou a computação...
mais importante voltou a ficar a infraestrutura física.
SERVER
↓
VM
↓
CONTAINER
↓
KUBERNETES
↓
CLOUD
↓
AI
↓
...
↓
USINA ELÉTRICA
Parabéns.
Depois de cinquenta anos subindo camadas de abstração, encontramos a tomada.
🧠 Capítulo XV — 8 de abril de 2025: z17 encontra a IA
Agora chegamos ao IBM z17.
A IBM anunciou o sistema em 8 de abril de 2025, descrevendo-o como seu primeiro mainframe inteiramente projetado para a era da IA.
No coração está o:
Telum II.
Acelerador de IA integrado ao processador.
A IBM afirma, para uma configuração e modelo de referência específicos, capacidade superior a 450 bilhões de operações de inferência em um dia, com resposta de aproximadamente 1 ms. O z17 foi anunciado com 50% mais capacidade diária de inferência de IA que o z16. (IBM Brasil Newsroom)
Anúncio oficial do IBM z17 — 8 de abril de 2025
Isso representa uma estratégia muito interessante.
Em vez de:
TRANSAÇÃO
│
↓
MAINFRAME
│
↓
NETWORK
│
↓
GPU FARM
│
↓
AI
│
↓
NETWORK
│
↓
MAINFRAME
certos modelos de inferência podem operar muito próximos da própria transação:
TRANSAÇÃO
│
├── BUSINESS LOGIC
│
└── AI INFERENCE
│
↓
DECISION
Fraude é um exemplo perfeito.
💳 Capítulo XVI — IA perto do dinheiro
Imagine uma compra:
R$ 7.850
03:17
local incomum
dispositivo novo
comportamento estranho
O sistema tradicional pode executar regras:
IF VALOR > LIMITE
PERFORM ANALISE-FRAUDE
END-IF.
Agora podemos adicionar modelos:
TRANSACTION
│
↓
AI MODEL
│
├── normal → APPROVE
│
└── anomalous → REVIEW/BLOCK
Quanto menor a latência entre:
TRANSAÇÃO
e:
INFERÊNCIA
melhor.
Portanto, IA no mainframe não significa necessariamente:
treinar o próximo GPT no z/OS.
Esse seria um entendimento errado.
A proposta mais interessante é:
inferência empresarial próxima dos dados e das transações.
🐬 Capítulo XVII — E as GPUs não vão embora
Isso também precisa ficar claro.
z17 não matou GPU.
LinuxONE não matou x86.
Cloud não matou mainframe.
Mainframe não matou cloud.
A arquitetura futura provavelmente será:
WORKLOAD
│
┌──────────────┼──────────────┐
│ │ │
↓ ↓ ↓
IBM Z GPU FARM CLOUD
│ │ │
transactional AI training elastic compute
core banking huge models applications
low latency HPC analytics
O segredo será:
colocar cada workload onde ele faz mais sentido.
🏗️ Capítulo XVIII — 7 de julho de 2026: o mainframe entra no rack
E chegamos a um acontecimento recentíssimo.
Em 7 de julho de 2026, IBM anunciou novas configurações compactas para z17 e LinuxONE 5, incluindo single-frame e rack-mount em toda a família.
Pela primeira vez, IBM oferece rack mount ao lado das opções tradicionais em todo o portfólio Z/LinuxONE. (IBM Newsroom)
IBM z17 e LinuxONE 5 compactos — anúncio de 7 de julho de 2026
E leia o contexto escolhido pela própria IBM.
O anúncio fala explicitamente sobre organizações enfrentando baixa disponibilidade de espaço em data centers e altos custos por capacidade elétrica. (IBM Newsroom)
É quase possível ouvir um fantasma de 2007 dizendo:
— Big Green.
🌱 Capítulo XIX — O círculo fecha
Agora podemos montar nossa linha do tempo.
1960s
CP/CMS
│
↓
1970s
VM/370
│
↓
z/VM
│
↓
LINUX ON MAINFRAME
│
↓
2007
PROJECT BIG GREEN
│
↓
CONSOLIDAÇÃO
EFICIÊNCIA
ENERGIA
│
↓
2015
LinuxONE
│
↓
HYBRID CLOUD
│
↓
2025
z17 + TELUM II
│
↓
2026
z17 / LinuxONE 5
RACK MOUNT
│
↓
AI + DATACENTERS
│
↓
MEGAWATTS
Essa não é uma evolução linear planejada desde os anos 1960.
Seria absurdo afirmar isso.
Mas existe uma continuidade conceitual extraordinária:
aumentar utilização e consolidar trabalho.
🧪 Capítulo XX — O grande teste: realidade versus marketing
Agora precisamos fazer aquilo que todo COBOLzeiro deveria aprender cedo:
IF MARKETING
PERFORM VALIDATE-CLAIM
END-IF
Quando IBM diz:
80% menos energia
ou:
milhares de servidores consolidados
pergunte:
comparado com quê?
Depois:
qual workload?
Depois:
qual utilização?
Depois:
qual configuração?
Depois:
inclui storage?
Depois:
inclui refrigeração?
Depois:
inclui software?
Depois:
qual período?
Isso vale para IBM.
AWS.
Microsoft.
Google.
NVIDIA.
Qualquer fabricante.
Um benchmark sem contexto é como:
DISPLAY "42".
Pode ser a resposta para a vida, o universo e tudo mais.
Mas continuamos sem saber qual era a pergunta.
🌍 Capítulo XXI — Big Green estava certo?
Agora podemos finalmente julgar.
Previsão:
Energia se tornará restrição importante dos data centers.
Correta.
Previsão:
Consolidação será importante.
Correta.
Previsão:
Virtualização aumentará utilização.
Correta.
Previsão:
Precisaremos medir energia como recurso computacional.
Corretíssima.
Previsão implícita:
Mainframe absorverá enormes quantidades do server sprawl mundial.
Não aconteceu na dimensão que aquela narrativa comercial poderia sugerir.
O mercado escolheu também:
x86
+
virtualization
+
hyperscale
+
cloud
E depois:
containers
+
Kubernetes
Mas isso não refutou o problema.
Encontrou outra maneira de administrá-lo.
☁️ Capítulo XXII — Cloud é o Big Green do outro lado do espelho?
Existe uma provocação interessante aqui.
IBM dizia:
CONSOLIDE
MUITOS SERVIDORES
EM MENOS SISTEMAS.
Hyperscalers disseram:
ENTREGUE OS SERVIDORES
PARA NÓS.
NÓS CONSOLIDAMOS.
São arquiteturas radicalmente diferentes.
Mas existe parentesco econômico:
EVITAR OCIOSIDADE
+
COMPARTILHAR RECURSOS
+
AUTOMATIZAR
+
AUMENTAR UTILIZAÇÃO
A cloud não destruiu necessariamente a tese do Big Green.
Em certo sentido, industrializou parte dela.
🧑🚀 Capítulo XXIII — Guia do Mochileiro para o programador COBOL
Se você está começando agora, grave estas regras.
1. Não confunda máquina virtual com máquina imaginária.
Existe hardware embaixo.
2. Não confunda elasticidade com infinito.
AUTO-SCALING != MAGIC
3. Aprenda virtualização.
Entender z/VM ajuda enormemente a compreender cloud.
4. Aprenda capacity planning.
CPU continua existindo.
Memória continua acabando.
5. Acrescente energia ao modelo mental.
O capacity planner moderno precisa entender:
COMPUTE
+
POWER
+
COOLING
6. Não transforme arquitetura em religião.
Mainframe não é resposta para tudo.
Cloud não é resposta para tudo.
GPU não é resposta para tudo.
Kubernetes definitivamente não precisa rodar sua torradeira.
Ainda.
7. Sempre procure o custo sistêmico.
Não compare simplesmente:
CPU A vs CPU B
Compare:
SERVIÇO ENTREGUE
────────────────
CUSTO TOTAL
🐳 Capítulo XXIV — O elefante, a baleia e o mainframe
Douglas Adams escreveu sobre criaturas gigantescas surgindo em lugares improváveis.
Nossa indústria também possui algumas.
Durante décadas disseram que o mainframe desapareceria.
Ele viu:
client/server
Unix
Windows NT
Java
x86
VMware
cloud
containers
Kubernetes
serverless
AI
passarem pela porta.
Em 2026 ele continua sentado no CPD.
Agora alguém pergunta:
— Você ainda está aqui?
IBM Z responde:
— Sim.
— Mas agora temos IA.
— Também.
— Linux?
— Sim.
— Containers?
— Sim.
— APIs?
— Sim.
— Cloud híbrida?
— Sim.
— Eficiência energética?
O mainframe olha para uma pasta empoeirada:
PROJECT BIG GREEN
2007
— Engraçado você perguntar.
⚡ Capítulo XXV — O paradoxo final da abstração
A história da computação moderna parece uma tentativa constante de esconder a física.
Primeiro escondemos hardware com:
OPERATING SYSTEM
Depois:
VIRTUAL MACHINE
Depois:
CONTAINER
Depois:
ORCHESTRATOR
Depois:
CLOUD
Depois:
SERVERLESS
Serverless!
O próprio nome é maravilhoso.
É como chamar restaurante de:
KITCHENLESS
porque você não consegue ver a cozinha.
🤣
Então chegou IA consumindo tanta infraestrutura que fomos obrigados a seguir a abstração ao contrário:
AI
↓
MODEL
↓
GPU
↓
SERVER
↓
RACK
↓
DATA CENTER
↓
SUBSTATION
↓
POWER GRID
↓
POWER PLANT
Encontramos novamente a física.
🌌 Capítulo XXVI — E finalmente descobrimos a pergunta cuja resposta é 42
Deep Thought levou 7,5 milhões de anos para calcular:
42.
Infelizmente ninguém sabia exatamente qual era a pergunta.
Em 2026 finalmente descobrimos.
Um arquiteto entra no data center.
Pergunta:
— Quantas GPUs ainda posso instalar nesse rack?
O facility manager consulta o painel.
Olha a alimentação elétrica.
Consulta refrigeração.
Volta.
— 42.
O arquiteto fica emocionado.
— A resposta para a vida, o universo e tudo mais!
— Não.
— Não?
— Depois da quadragésima segunda derruba o disjuntor.
☕ Epílogo — O Restaurante no Fim do Data Center
São 23h59.
Em algum lugar do universo, existe um restaurante construído ao lado do último data center ainda com capacidade elétrica disponível.
Sentados à mesa estão:
um programador COBOL de 1978;
um administrador VM de 1985;
um especialista Linux de 2000;
um engenheiro Big Green de 2007;
um arquiteto cloud de 2017;
um engenheiro Kubernetes de 2020;
e um cientista de IA de 2026.
O garçom aproxima-se.
— O que desejam?
O COBOLzeiro:
— Café.
O administrador VM:
— Café.
O arquiteto cloud:
— Café serverless.
O garçom:
— Senhor, alguém ainda precisa fazer o café.
— Estragou a arquitetura.
O cientista de IA abre o notebook.
— Vou executar um modelo de 400 bilhões de parâmetros para decidir o que pedir.
As luzes piscam.
Todos olham para ele.
WARNING
DATA CENTER POWER
98%
O engenheiro Big Green lentamente tira uma pasta da mochila.
Na capa:
IBM
PROJECT BIG GREEN
10 MAY 2007
O cientista de IA pergunta:
— O que é isso?
— Uma mensagem do passado.
— Sobre inteligência artificial?
— Não.
— Cloud?
— Não.
— GPUs?
— Também não.
— Então sobre o quê?
O engenheiro abre o documento.
— Tomadas.
Silêncio.
O veterano do z/VM começa a rir.
O COBOLzeiro levanta sua caneca.
Porque finalmente percebe a extraordinária circularidade daquela história:
z/VM
│
↓
VIRTUALIZAÇÃO
│
↓
CONSOLIDAÇÃO
│
↓
BIG GREEN
│
↓
LINUX ON SYSTEM z
│
↓
LinuxONE
│
↓
HYBRID CLOUD
│
↓
z17
│
↓
IA
│
↓
MEGAWATTS
│
↓
...
E depois de sessenta anos de engenharia:
┌───────────────┐
│ │
│ TOMADA │
│ ⚡ │
│ │
└───────────────┘
Voltamos ao início.
O velho engenheiro IBM fecha a pasta.
— Em 2007 chamamos isso de Big Green.
O engenheiro Kubernetes pergunta:
— E hoje?
Ele olha para o painel:
POWER CAPACITY: 99%
Pensa alguns segundos.
— Hoje chamamos de terça-feira.
🌱 A moral do Guia do Mochileiro do Mainframe
O Project Big Green de 2007 não venceu o mundo como marca comercial. Cloud e hyperscale acabaram seguindo caminhos diferentes daqueles que uma estratégia centrada no System z poderia sugerir.
Mas sua tese central envelheceu extraordinariamente bem:
Computação não deve ser medida apenas pela potência do processador, mas pelo trabalho útil entregue em relação aos recursos físicos necessários para sustentá-la.
A IBM passou daquela discussão para Linux on System z, depois LinuxONE — lançado em 2015 — e hoje chega ao z17, anunciado em 8 de abril de 2025 com Telum II e aceleração de IA integrada. (Investing.com)
Em julho de 2026, quando a IBM anunciou versões compactas e rack-mount de z17 e LinuxONE 5, voltou a mencionar explicitamente um mundo no qual espaço e capacidade elétrica dos data centers tornaram-se recursos cada vez mais preciosos. (IBM Newsroom)
Portanto:
2007
IBM:
"PRECISAMOS PENSAR
EM COMPUTAÇÃO POR WATT."
2026
IA:
"PRECISO DE OUTRO
CLUSTER DE GPUs."
DATA CENTER:
"PRECISO DE OUTRA
SUBESTAÇÃO."
REDE ELÉTRICA:
"PRECISO DE OUTRA
LINHA DE TRANSMISSÃO."
IBM BIG GREEN:
☕
Talvez a maior piada cósmica seja justamente essa.
Passamos décadas discutindo se o futuro seria mainframe, Unix, x86, cloud, Kubernetes ou IA.
E esquecemos que todos eles pertencem à mesma arquitetura fundamental:
//UNIVERSE JOB
//STEP01 EXEC PGM=COMPUTE
//POWER DD *
ELECTRICITY
/*
Sem POWER:
IEF450I
UNIVERSE - ABEND=S0WATT
E se isso acontecer...
NÃO ENTRE EM PÂNICO.
Pegue sua toalha.
Pegue seu café.
E, antes de pedir mais 10.000 GPUs,
pergunte ao pessoal do Facilities.
☕ Fim do café — e lembre-se: 42 continua sendo uma excelente resposta, desde que o disjuntor aguente.
