 |
| Bellacosa Mainframe e a ibm 2007 apresenta o big green |
☕ Um Café no Bellacosa Mainframe
24 Horas em 2007: Jack Bauer, COBOL e o Dia em que a IBM Descobriu que o Próximo Terrorista do Data Center Era a Conta de Luz
🌱 Project Big Green, System z, z/VM, Linux, Java, SOA, VMware, Windows Vista, Oracle, software corporativo, o fantasma do Y2K e uma viagem ao ano em que todo mundo dizia que COBOL estava morrendo — enquanto a IBM preparava 3.900 servidores para entrar em aproximadamente 30 mainframes
THE FOLLOWING TAKES PLACE
BETWEEN 00:00 AND 24:00
ON MAY 10, 2007.
EVENTS OCCUR IN REAL TIME.
00:00:01
TIC.
00:00:02
TIC.
00:00:03
TIC.
Jack Bauer entra correndo no data center.
— Onde está a bomba?
O operador aponta para uma fileira interminável de racks.
— Não temos bomba, senhor Bauer.
— Então por que me chamaram?
— Temos 4.000 servidores.
Jack observa as máquinas.
— E?
— A maioria passa boa parte do tempo subutilizada.
— Continue.
— Todos consomem eletricidade.
— Continue.
— Produzem calor.
— Continue.
— Então usamos mais eletricidade para retirar o calor produzido pela eletricidade que usamos para alimentar os computadores.
Jack permanece imóvel durante cinco segundos.
Isso, em 24 Horas, equivale a uma tese de doutorado.
— Meu Deus.
Do fundo da sala surge um senhor usando crachá da IBM.
— Exatamente.
E naquele 10 de maio de 2007, a IBM anunciou oficialmente o Project Big Green: uma iniciativa de cerca de US$ 1 bilhão por ano em tecnologias e serviços voltados à eficiência energética dos data centers.
O que parecia uma campanha ecológica era, na realidade, resposta a um problema econômico e físico que começava a aterrorizar CIOs:
os data centers estavam ficando sem energia, refrigeração e espaço para continuar colocando servidores.
E o mais extraordinário é perceber que a história aconteceu 19 anos antes de começarmos a discutir clusters de IA em megawatts.
Mas, para entender por que Big Green causou tanto barulho, precisamos voltar ao mundo tecnológico de 2007.
E ele era muito diferente do nosso.
01:00 — IBM não estava morrendo. Muito pelo contrário.
Existe uma tentação histórica de imaginar a IBM dos anos 2000 como uma companhia envelhecida tentando desesperadamente salvar o mainframe.
Os números contam outra história.
A IBM havia acabado de executar uma transformação empresarial gigantesca. Em 2005 concluíra a venda de seu negócio de PCs para a Lenovo e estava concentrando capital em negócios considerados de maior valor: software, serviços, middleware, consultoria e infraestrutura empresarial. Essa mudança continuaria sendo destacada pela própria IBM nos relatórios seguintes. (IBM)
A evolução financeira é reveladora:
| Ano | Receita IBM | Lucro líquido |
|---|
| 2005 | ~US$ 91,1 bilhões | ~US$ 7,9 bilhões |
| 2006 | ~US$ 91,4 bilhões | ~US$ 9,5 bilhões |
| 2007 | ~US$ 98,8 bilhões | ~US$ 10,4 bilhões |
Ou seja:
2005 → 2007
RECEITA
US$ 91,1 bi ───────────► US$ 98,8 bi
LUCRO
US$ 7,9 bi ────────────► US$ 10,4 bi
Isso é importante para interpretar Big Green.
Não era:
IBM EM PÂNICO
↓
PRECISAMOS INVENTAR
ALGUMA COISA VERDE
PARA SALVAR A EMPRESA
Era muito mais:
IBM LUCRATIVA
↓
SERVIÇOS + SOFTWARE
↓
VIRTUALIZAÇÃO
↓
DATA CENTERS CRESCENDO
↓
CLIENTES COM PROBLEMAS DE ENERGIA
↓
HUM...
↓
ISSO PODE VIRAR NEGÓCIO.
Jack Bauer aprovaria.
02:00 — A IBM de 2007 já não era primordialmente “uma fabricante de computadores”
Isso também é fundamental.
A IBM possuía System z, System p, System i, System x, storage e chips.
Mas o coração econômico da companhia estava se deslocando fortemente para serviços e software.
Naquela IBM encontrávamos marcas como:
WebSphere
Tivoli
Lotus
Rational
DB2 / Information Management
Mais Global Technology Services.
Mais Global Business Services.
Mais outsourcing.
Mais consultoria.
Mais financiamento.
Hardware continuava estratégico, especialmente porque funcionava como âncora de ecossistemas inteiros.
O mainframe talvez fosse o melhor exemplo:
SYSTEM z
│
├── z/OS
├── COBOL
├── CICS
├── IMS
├── DB2
├── MQ
├── RACF
├── Tivoli
├── serviços
└── contratos
O valor econômico não estava simplesmente na caixa preta.
Estava no ecossistema ao redor dela.
03:00 — Enquanto isso, o mercado mundial de software parecia um clube muito exclusivo
O software mundial de 2007 já era gigantesco, mas possuía uma concentração impressionante.
Dependendo da metodologia e da definição de “software” usada pelos institutos de pesquisa, os números absolutos variam. Portanto, é perigoso misturar Gartner, IDC e receitas contábeis das empresas como se medissem exatamente o mesmo universo.
Mas a hierarquia geral era bastante clara:
SOFTWARE 2007
MICROSOFT
│
IBM
│
ORACLE
│
SAP
│
outros
A Microsoft era uma potência extraordinária. Seu próprio ano fiscal de 2007 terminou com US$ 51,1 bilhões de receita e US$ 14,1 bilhões de lucro líquido. (Microsoft)
Mas “mercado de software” escondia vários mundos.
Desktop
WINDOWS
OFFICE
Microsoft era gigantesca.
Banco de dados
Oracle
IBM DB2
Microsoft SQL Server
ERP
SAP
Oracle
Middleware
IBM WebSphere
BEA WebLogic
Oracle
Microsoft
Gerenciamento
IBM Tivoli
CA
BMC
HP
Desenvolvimento
Java
.NET
C/C++
COBOL
PHP
Perl
Python
Ruby
E aqui aparece uma diferença fundamental em relação a 2026:
SaaS ainda não havia virado o modelo mental dominante do software empresarial.
A licença perpétua + manutenção ainda reinava em enorme parte do mercado.
04:00 — O mundo estava apaixonado por três letras: SOA
Se você entrasse numa conferência corporativa em 2007 e dissesse:
“SOA”
provavelmente alguém lhe ofereceria um emprego.
Service-Oriented Architecture era uma das grandes obsessões da época.
O diagrama típico parecia:
PORTAL
│
WEB SERVICE
│
↓
ESB
┌───────┼───────┐
│ │ │
JAVA CICS SAP
│ │ │
└───────┼───────┘
│
DATA
REST existia.
Mas no grande enterprise o vocabulário estava repleto de:
SOAP
WSDL
XML
ESB
SOA
Web Services
Para um COBOLzeiro isso significava algo importantíssimo.
A estratégia frequentemente não era:
DELETE COBOL
mas:
COBOL/CICS
│
↓
WEB SERVICE
│
↓
SOA
A modernização começava a significar expor o legado, e não necessariamente eliminá-lo.
05:00 — E Java era o garoto bonito do CPD
Se COBOL era o senhor de terno cinza sentado no fundo da sala, Java era o jovem arquiteto chegando com mochila e UML.
No enterprise:
Java
Java EE
WebSphere
WebLogic
J2EE/Java EE
Spring
estavam por toda parte.
Microsoft respondia com:
.NET
C#
Visual Studio
Windows Server
SQL Server
Linux crescia fortemente no servidor.
Unix ainda tinha enorme relevância:
AIX
Solaris
HP-UX
E x86 multiplicava-se dentro dos data centers.
É justamente aí que nasce nosso problema.
06:00 — SERVER SPRAWL
O administrador instala:
APP A → SERVER A
Depois:
APP B → SERVER B
Depois:
DATABASE → SERVER C
Depois:
WEB → SERVER D
Depois:
TEST → SERVER E
Cinco anos depois:
SERVER001
SERVER002
SERVER003
...
SERVER1847
SERVER1848
SERVER1849
Alguém pergunta:
— Quem usa SERVER0932?
Silêncio.
— Podemos desligá-lo?
Silêncio ainda maior.
Jack Bauer coloca a arma sobre a mesa.
— Vou perguntar novamente.
O problema do server sprawl era extremamente real.
E então VMware apareceu no centro da história.
07:00 — VMware faz o mundo x86 descobrir virtualização
2007 foi um ano espetacular para virtualização.
A VMware já tinha tecnologia madura de virtualização de servidores e tornou-se símbolo de uma transformação gigantesca:
ANTES
APP A → SERVER
APP B → SERVER
APP C → SERVER
DEPOIS
SERVER
│
HYPERVISOR
┌────┼────┐
VM VM VM
│ │ │
APP APP APP
Em 14 de agosto de 2007, a VMware fez seu IPO.
O entusiasmo do mercado foi enorme.
E havia veteranos de mainframe assistindo aquilo com uma expressão curiosa.
— Virtualização?
— Sim!
— Várias máquinas virtuais compartilhando hardware?
— Exatamente!
— Fascinante.
— Isso vai revolucionar a informática!
— Meu caro... sente-se. Precisamos conversar sobre CP/CMS, VM/370 e z/VM.
😄
08:00 — O mainframe tinha uma arma secreta chamada z/VM
Em junho de 2007, z/VM 5.3 tornou-se disponível, trazendo melhorias de escalabilidade em processadores, memória, rede e I/O justamente porque os workloads Linux virtualizados estavam crescendo. (IBM)
O conceito:
SYSTEM z
│
z/VM
│
┌──────────┼──────────┐
│ │ │
Linux Linux Linux
│ │ │
APP A APP B APP C
IBM olhava para milhares de servidores distribuídos e dizia:
Por que não consolidá-los?
E então o relógio começou a correr.
09:00 — 10 de maio de 2007: PROJECT BIG GREEN
09:00:00
TIC
09:00:01
TIC
IBM anuncia:
PROJECT BIG GREEN.
A proposta envolvia aproximadamente US$ 1 bilhão por ano de recursos dedicados a produtos e serviços de eficiência energética.
Havia centenas de especialistas.
A metodologia envolvia essencialmente:
DIAGNOSE
↓
BUILD
↓
VIRTUALIZE
↓
MANAGE
↓
COOL
Não era simplesmente:
“Compre um mainframe porque ele é verde.”
Era uma estratégia de data center.
E isso importa muito.
10:00 — Por que energia virou assunto em 2007?
Porque os números começavam a assustar.
O relatório entregue ao Congresso dos Estados Unidos pela EPA naquele ano estimou que servidores e data centers americanos haviam consumido aproximadamente 61 bilhões de kWh em 2006, cerca de 1,5% do consumo total de eletricidade dos EUA, a um custo aproximado de US$ 4,5 bilhões. O consumo havia aproximadamente dobrado desde 2000. (IBM)
A indústria percebeu:
COMPUTAÇÃO ↑
SERVIDORES ↑
ELETRICIDADE ↑
CALOR ↑
REFRIGERAÇÃO ↑
ELETRICIDADE ↑
E surgiu uma palavra que hoje parece óbvia:
eficiência.
11:00 — O mercado inicialmente enxergou muito marketing
Naturalmente.
Quando IBM disse:
Big Green
a imprensa imediatamente descobriu o irresistível:
Big Blue goes Green.
E houve ironia.
The Register publicou uma manchete maravilhosa:
“IBM: Dinosaurs were green.”
O dinossauro era, naturalmente, o mainframe.
A piada escondia uma mudança narrativa muito inteligente.
Durante anos o ataque ao mainframe era:
GRANDE
CARO
CENTRALIZADO
ANTIGO
IBM começou a responder:
E seus 4.000 servidores são exatamente o quê?
😂
A campanha tentava transformar uma fraqueza de imagem — “uma máquina enorme” — em vantagem:
consolidação.
12:00 — 3.900 servidores entram no CTU
Em 1º de agosto de 2007, IBM fez algo fundamental.
Não ficou apenas no PowerPoint.
Anunciou que consolidaria aproximadamente:
3.900 servidores
em cerca de:
30 System z
rodando Linux. O objetivo declarado era reduzir o consumo energético daquele ambiente em aproximadamente 80% ao longo de cinco anos. (IBM)
A imprensa percebeu imediatamente o tamanho da história.
O desenho era quase absurdo:
██████████████████████████████████████
3.900 SERVIDORES
██████████████████████████████████████
│
│
▼
███████████████████
~30 SYSTEM z
███████████████████
A cobertura contemporânea mencionava também economia prevista de centenas de milhões de dólares e redução enorme do espaço físico.
Aquilo transformou Big Green de slogan em case interno da própria IBM.
13:00 — Isso fez explodir as vendas de mainframe imediatamente?
Não.
E essa nuance é importantíssima.
2007 estava no final do ciclo tecnológico do System z9.
O z9 Enterprise Class havia aparecido em 2005.
O próximo grande salto — System z10 — chegaria em fevereiro de 2008.
Portanto, não devemos olhar Big Green e concluir:
BIG GREEN
↓
VENDAS SYSTEM z EXPLODEM
Hardware enterprise possui ciclos.
Clientes aguardam novas gerações.
Capacidade instalada cresce mesmo quando receita de hardware não acompanha linearmente.
E mainframe possui outra peculiaridade:
HARDWARE
│
├── SOFTWARE
├── LICENCIAMENTO
├── MANUTENÇÃO
├── SERVIÇOS
└── CAPACIDADE
O valor para IBM nunca esteve simplesmente na venda da caixa.
14:00 — E o COBOL? Ah, o pobre COBOL...
Agora chegamos à parte culturalmente deliciosa.
Era 2007.
Sete anos depois do Y2K.
Durante o período 1997–1999, COBOLzeiro tinha virado quase uma unidade monetária.
PRECISAMOS CORRIGIR DATAS.
CHAMEM COBOLZEIROS.
QUANTOS?
TODOS.
Então chegou:
01/01/2000
O mundo não explodiu.
Parabéns.
O prêmio recebido pelo COBOL foi aproximadamente:
“Obrigado. Agora você pode voltar para o porão.”
😂
15:00 — O paradoxo pós-Y2K
A percepção popular era:
COBOL
=
LINGUAGEM VELHA
=
LEGADO
=
MANUTENÇÃO
=
MORTE EVENTUAL
Nas universidades, Java, C++, .NET e linguagens Web eram muito mais atraentes.
O estudante perguntava:
— Qual linguagem devo aprender?
Resposta típica:
Java
C++
C#
PHP
Dificilmente:
COBOL + JCL + CICS + DB2 + VSAM
Mas havia um problema.
Os sistemas não receberam o memorando sobre a morte do COBOL.
16:00 — Enquanto todo mundo declarava COBOL morto...
Dentro dos bancos:
COBOL → PROCESSANDO
Seguradoras:
COBOL → PROCESSANDO
Governos:
COBOL → PROCESSANDO
Varejo:
COBOL → PROCESSANDO
Grandes empresas:
COBOL → PROCESSANDO
A diferença fundamental era:
COBOL tinha deixado de ser tecnologicamente “sexy”.
Isso não significava que tivesse deixado de ser economicamente relevante.
E essa distinção continua sendo crucial.
17:00 — A IBM também não estava abandonando COBOL
Esse detalhe destrói a narrativa de “linguagem congelada”.
Naquele período a IBM continuava evoluindo Enterprise COBOL e todo o ecossistema ao redor do mainframe.
O mundo mainframe de 2007 incluía tecnologias contemporâneas como:
Enterprise COBOL
CICS Transaction Server
DB2
IMS
MQ
WebSphere
XML
Web Services
Java
Linux
Rational
O objetivo era integrar.
Um programa COBOL poderia continuar fazendo:
READ CONTA
COMPUTE SALDO = SALDO - VALOR
REWRITE CONTA.
enquanto externamente alguém enxergava:
SOAP
│
WSDL
│
XML
│
SERVICE
O legado estava ganhando uma porta nova.
18:00 — O problema real não era COBOL. Era conhecimento
Começava a ficar evidente outro problema.
Quem conhecia:
COBOL
JCL
CICS
DB2
IMS
VSAM
RACF
TSO
ISPF
tinha frequentemente começado décadas antes.
E as universidades estavam formando principalmente:
Java
C++
.NET
Web
Nascia o problema que nos acompanharia por décadas:
mainframe skills gap.
O perigo não era simplesmente:
“Ninguém sabe escrever PERFORM.”
Era:
“Quem sabe por que aquele programa de 1987 faz exatamente aquilo às 02h13 do terceiro dia útil?”
Essa informação não está no manual de COBOL.
Está no conhecimento institucional.
19:00 — O COBOL estava morto e recebendo versão nova
Existe algo deliciosamente mainframe nisso.
A indústria:
COBOL está morto.
IBM:
ENTERPRISE COBOL
NEW VERSION
Indústria:
Mainframe está morto.
IBM:
SYSTEM z
Indústria:
Virtualização é o futuro.
IBM:
z/VM
Indústria:
Linux é o futuro.
IBM:
LINUX ON SYSTEM z
Indústria:
SOA é o futuro.
IBM:
CICS WEB SERVICES
O mainframe desenvolveu uma extraordinária habilidade histórica:
deixar os outros anunciarem sua morte enquanto instala a próxima release.
20:00 — Enquanto isso, fora do CPD, 2007 enlouquecia
Esse talvez seja o detalhe mais divertido.
Em janeiro, a Microsoft lançou Windows Vista e Office 2007 para consumidores mundialmente. (Source)
E também em janeiro, Steve Jobs apresentou algo chamado:
iPhone.
A Apple descreveu-o como combinação de telefone, iPod e dispositivo de Internet. (Apple)
Não existia App Store ainda.
Kubernetes?
Não.
Docker?
Não.
ChatGPT?
Não.
Instagram?
Não.
WhatsApp?
Não.
TikTok?
Nem pensar.
Windows Azure?
Ainda não.
Mas existiam:
BlackBerry
Nokia
Symbian
Windows Mobile
E o iPhone estava prestes a destruir boa parte desse universo.
21:00 — E a cloud era apenas uma criança
AWS já existia.
S3 havia aparecido em 2006.
EC2 também havia iniciado sua história.
Mas em 2007 ninguém em uma grande reunião bancária normal dizia:
“Vamos desligar o mainframe e colocar o core inteiro na AWS.”
Seria provavelmente acompanhado educadamente até a porta.
😂
Cloud computing ainda estava emergindo.
O próprio IBM responderia naquele ano.
Em novembro de 2007 apareceu:
Blue Cloud.
Observe a sequência histórica:
MAIO 2007
BIG GREEN
│
↓
ENERGY + CONSOLIDATION
NOVEMBRO 2007
BLUE CLOUD
│
↓
VIRTUALIZATION + AUTOMATION
+ DISTRIBUTED COMPUTING
Em poucos meses IBM estava discutindo simultaneamente eficiência física do data center e o embrião daquilo que viraria cloud computing.
Isso é extraordinariamente importante em retrospecto.
22:00 — 2007 foi o ano em que várias placas tectônicas começaram a se mover
Olhe esta fotografia:
| Área | 2007 |
|---|
| Desktop | Windows dominava |
| Enterprise development | Java/.NET |
| Integração | SOA, SOAP, XML, WSDL |
| Mainframe | IBM System z9 |
| Virtualização x86 | VMware |
| Mainframe virtualization | z/VM |
| Unix | AIX, Solaris, HP-UX |
| Linux | crescimento empresarial |
| Database | Oracle, DB2, SQL Server |
| ERP | SAP/Oracle |
| Cloud | embrionária |
| Mobile | BlackBerry/Nokia, iPhone chegando |
| Containers | inexistentes no sentido atual |
| Kubernetes | inexistente |
| DevOps | termo ainda não estabelecido |
| IA generativa | ficção científica para o mercado |
| COBOL | “morto”, porém trabalhando normalmente |
É isso que torna Big Green tão fascinante.
Ele não nasceu no nosso mundo.
Nasceu antes do nosso mundo.
23:00 — O verdadeiro significado de Big Green aparece
Imagine Jack Bauer olhando dois monitores.
No primeiro:
2007
SERVER SPRAWL
↓
POWER
↓
COOLING
↓
COST
No segundo:
2026
CLOUD
↓
GPU
↓
AI
↓
MEGAWATTS
↓
GRID CAPACITY
Jack pergunta:
— Qual é a diferença?
O sysprog responde:
— Escala.
— Só isso?
— Basicamente.
Big Green identificou corretamente uma verdade física:
a capacidade computacional pode crescer mais rapidamente do que a infraestrutura física capaz de alimentá-la e refrigerá-la.
O que IBM não poderia prever completamente era como o mercado resolveria o problema.
A IBM apostava fortemente em:
CONSOLIDAÇÃO
↓
VIRTUALIZAÇÃO
↓
SYSTEM z / Linux
O mercado também escolheu:
VMWARE
↓
x86 VIRTUALIZATION
↓
HYPERSCALE
↓
PUBLIC CLOUD
E posteriormente:
CONTAINERS
↓
KUBERNETES
↓
CLOUD-NATIVE
A tese física sobreviveu.
A implementação vencedora tornou-se plural.
23:30 — Então Big Green fracassou?
Não.
Mas também seria exagero dizer que Big Green fez o mercado inteiro correr para System z.
O impacto foi mais sofisticado.
Ele ajudou a legitimar energia como métrica de TI.
Antes:
CAPACITY PLANNING
CPU
MEMORY
DISK
I/O
Depois:
CAPACITY PLANNING
CPU
MEMORY
DISK
I/O
+ POWER
+ COOLING
+ SPACE
O setor inteiro caminhava nessa direção.
Virtualização crescia.
A Green Grid trabalhava em métricas para eficiência de data centers.
Performance-per-watt ganhava importância.
A indústria começou a perceber que:
energia não era apenas despesa de Facilities. Era recurso computacional.
Esse talvez seja o maior legado conceitual do Big Green.
23:45 — E havia um componente comercial brilhante
Imagine você como CIO em 2007.
Problema:
MEU DATA CENTER ESTÁ LOTADO.
IBM:
— Podemos ajudar.
Problema:
MINHA CONTA DE ENERGIA SUBIU.
IBM:
— Podemos ajudar.
Problema:
TENHO 2.000 SERVIDORES.
IBM:
— Podemos ajudar.
Problema:
PRECISO VIRTUALIZAR.
IBM:
— Temos feito isso há algumas décadas.
Problema:
QUERO LINUX.
IBM:
— Também temos.
Problema:
NÃO QUERO COBOL.
IBM:
— Quem falou em COBOL?
E aí estava a genialidade comercial:
Big Green não vendia apenas mainframe.
Vendia:
CONSULTORIA
+
HARDWARE
+
SOFTWARE
+
VIRTUALIZAÇÃO
+
STORAGE
+
ENERGY MANAGEMENT
+
DATA CENTER DESIGN
+
SERVIÇOS
Era perfeitamente alinhado à IBM pós-PC.
23:50 — E o mercado de software também estava consolidando violentamente
Outro detalhe ajuda a entender o espírito de 2007.
As gigantes estavam comprando empresas.
Oracle comprava.
SAP comprava.
IBM comprava.
Em novembro de 2007, IBM anunciou a aquisição da Cognos por aproximadamente US$ 5 bilhões, reforçando sua posição em business intelligence e performance management.
O movimento geral era:
SOFTWARE ISOLADO
↓
SUITE
↓
PLATAFORMA
↓
ECOSSISTEMA
Esse processo ajuda a explicar por que IBM queria ser menos:
VENDEDOR DE HARDWARE
e mais:
FORNECEDOR DA PLATAFORMA
EMPRESARIAL COMPLETA
Big Green encaixava perfeitamente nisso.
23:55 — A ironia COBOL
Jack Bauer recebe finalmente o relatório.
SUBJECT:
COBOL
STATUS:
DEAD
Ele olha para Chloe O'Brian.
— Confirme.
Chloe digita.
BANKS .............. RUNNING
INSURANCE .......... RUNNING
GOVERNMENT ......... RUNNING
RETAIL ............. RUNNING
CICS ................ RUNNING
DB2 ................. RUNNING
BATCH ............... RUNNING
Jack olha novamente.
— O relatório diz que está morto.
Chloe:
— A imprensa diz.
— E a produção?
— A produção discorda.
😂
Essa talvez seja a fotografia perfeita de COBOL em 2007.
23:57 — O erro histórico pós-Y2K
Y2K criou uma percepção distorcida.
Durante alguns anos:
COBOL = PROBLEMA DO ANO 2000
Quando Y2K acabou:
PROBLEMA ACABOU
↓
COBOL ACABOU
Mas COBOL nunca existiu por causa do Y2K.
Existia porque empresas tinham milhões de linhas implementando:
contabilidade
pagamentos
seguros
folha
crédito
estoque
faturamento
liquidação
cadastro
transações
Y2K era apenas uma manutenção extraordinariamente grande sobre esse patrimônio.
Quando o problema de data terminou, o patrimônio permaneceu.
23:58 — E isso explica por que Big Green e COBOL pertencem à mesma história
À primeira vista:
BIG GREEN
parece assunto de hardware.
E:
COBOL
parece assunto de software.
Mas ambos tratam da mesma pergunta empresarial:
O que fazemos com décadas de infraestrutura que ainda produz enorme valor?
Uma resposta possível:
REWRITE EVERYTHING
Outra:
USE WHAT WORKS
MORE EFFICIENTLY
Big Green estava muito mais próximo da segunda filosofia.
Consolidar.
Virtualizar.
Integrar.
Modernizar.
Reutilizar.
23:59 — Jack Bauer descobre quem era o terrorista
Jack entra no data center.
O suspeito está numa cadeira.
Ele não é russo.
Não é chinês.
Não trabalha para nenhuma organização clandestina.
É um senhor pacato usando camisa social.
Na identificação:
FACILITIES
Jack coloca as mãos sobre a mesa.
— Onde está a bomba?
— Não existe bomba.
— Então por que o data center vai cair à meia-noite?
O homem aponta para um painel.
POWER CAPACITY
███████████████████░
97%
Jack fica em silêncio.
— O que acontece quando chegar a 100%?
— Não podemos instalar mais servidores.
— Quantos servidores a aplicação pediu?
— Mais 400.
— E quanto tempo temos?
O relógio aparece.
00:00:10
TIC.
00:00:09
TIC.
Jack pega o telefone.
— Chloe!
— Estou aqui.
— Preciso de capacidade.
— Quanto?
— Muita.
— Não temos.
— Então virtualize.
— Já estamos virtualizando.
00:00:05
— Consolide.
— Em quê?
Jack olha para uma máquina preta no fundo da sala.
IBM SYSTEM z
O sysprog toma café.
— Finalmente.
00:00:03
Jack:
— Quantas máquinas virtuais cabem aí?
O sysprog:
— Quantas você trouxe?
00:00:02
Chloe interrompe.
— Jack!
— O quê?
— Descobri uma coisa.
00:00:01
— O quê?!
— A cloud ainda nem chegou direito.
00:00:00
Tela preta.
☕ Epílogo — O que realmente foi 2007?
2007 foi um daqueles anos em que o futuro estava chegando por várias portas simultaneamente.
O consumidor via:
iPhone, Vista, Web 2.0.
O desenvolvedor via:
Java, .NET, Eclipse, PHP, Ruby.
O arquiteto corporativo via:
SOA, SOAP, XML, WebSphere, WebLogic.
O administrador via:
VMware, Linux, blades, SAN.
O mainframe via:
System z, z/VM, Linux, CICS, DB2, IMS, COBOL.
O CIO começava a enxergar:
energia.
E a IBM enxergou uma oportunidade de unir várias dessas histórias sob um nome:
PROJECT BIG GREEN.
O projeto não provou que todo servidor distribuído deveria virar mainframe. O mercado mostrou que VMware, x86, hyperscale e posteriormente cloud também podiam explorar consolidação e virtualização em enorme escala.
Mas Big Green acertou uma previsão extraordinariamente importante:
o crescimento da computação acabaria esbarrando na infraestrutura física necessária para sustentá-la.
Em 2007 falávamos de watts por servidor.
Hoje falamos de megawatts por data center.
Em 2007 IBM perguntava:
Quantos servidores
podemos consolidar?
Em 2026 perguntamos:
Quantas GPUs
podemos energizar?
E COBOL?
O pobre COBOL passou 2007 oficialmente morto.
Só esqueceu de parar de processar.
Talvez essa seja a grande piada histórica daquele ano.
A indústria olhava para o System z e dizia:
“Dinossauro.”
Olhava para COBOL e dizia:
“Legado.”
Olhava para milhares de pequenos servidores e dizia:
“Futuro.”
Então a conta de luz chegou.
A IBM abriu uma pasta verde.
O veterano do z/VM tomou um café.
E alguém no fundo do data center perguntou:
“Vocês têm certeza de que precisamos de uma máquina física para cada aplicação?”
TIC.
TIC.
TIC.
Dezenove anos depois, o relógio continua correndo.
Só trocamos:
SERVER SPRAWL
por:
GPU CLUSTER
e:
WATTS
por:
MEGAWATTS.
Jack Bauer ainda tem 24 horas.
O pessoal de Facilities, aparentemente, tem bem menos. ☕⚡
