 |
| Bellacosa Mainframe entre porcos e computadores visoes do sistema legado |
☕ Um Café no Bellacosa Mainframe
🐷 A FÁBULA DOS PORCOS ASSADOS NO MAINFRAME
Ou: como uma empresa construiu 47 subsistemas, 312 jobs, 18 filas de MQ e uma War Room para continuar incendiando a floresta
Era uma vez uma enorme empresa que possuía um mainframe.
Ninguém sabia exatamente quando o primeiro programa havia entrado em produção.
Alguns diziam 1974.
Outros juravam ter encontrado um comentário COBOL contendo:
* ALTERADO EM 12/08/1969 - J.SILVA
Mas ninguém tinha coragem de investigar aquilo profundamente.
O importante era que o mainframe funcionava.
E dentro daquele mainframe existia o mais importante sistema corporativo da empresa:
🐷 O SISTEMA DE ASSAR PORCOS
A história começara décadas antes.
Certo dia, um incêndio acidental atingiu uma floresta próxima ao Data Center.
Havia porcos na floresta.
Quando o incêndio terminou, descobriram que os porcos haviam sido assados.
E estavam deliciosos.
Um programador teve então uma ideia:
— Quando precisarmos de porcos assados, podemos incendiar outra floresta.
Funcionou.
Foi criado o primeiro procedimento operacional:
PROC-PORCO-001 — Procedimento para Incêndio Controlado de Floresta para Produção de Porcos Assados.
Durante algum tempo, tudo correu maravilhosamente.
Quando alguém queria porco assado:
colocavam os porcos na floresta;
incendiavam a floresta;
esperavam;
recolhiam os porcos;
serviam o jantar.
Era simples.
Até a empresa crescer.
🖥️ A INDUSTRIALIZAÇÃO DO PORCO
O número de clientes aumentou.
Agora não eram dez porcos.
Eram dez mil.
Foi necessário automatizar o processo.
Um programador COBOL escreveu:
PORC001
Outro criou:
PORC002
Depois vieram:
PORC003
PORC003A
PORC003B
PORC003B2
e finalmente:
PORC003B2N
Ninguém sabia onde estava PORC003B1.
Mas havia referências a ele em três copybooks.
Por segurança, ninguém mexia.
O processo passou a ser executado pelo JES2.
Às 22:00:
JOB PORCO01
selecionava os animais.
Às 22:30:
JOB FLOREST1
identificava uma floresta disponível.
Às 23:00:
JOB FIRE001
iniciava o incêndio.
À 01:00:
JOB ASSADO1
calculava o grau provável de cozimento.
Às 03:17, invariavelmente, alguma coisa dava errado.
Então começava a War Room.
🔥 O PRIMEIRO INCIDENTE
Certa madrugada, metade dos porcos saiu crua.
A outra metade virou carvão.
Foi declarado:
SEV1 — CRITICAL INCIDENT
Trinta e sete pessoas entraram na conferência.
— É COBOL?
— Não.
— É CICS?
— Não.
— Db2?
— Normal.
— MQ?
— Algumas filas estão crescendo.
— CPU?
— 43%.
— WLM?
— Dentro da política.
— Storage?
— Normal.
Finalmente alguém perguntou:
— E o fogo?
Silêncio.
Ninguém da reunião pertencia à equipe responsável pelo fogo.
Foi necessário abrir um chamado.
INC00473192
A equipe respondeu:
FIRE SYSTEM OPERATING AS DESIGNED.
O incidente foi encerrado como:
ROOT CAUSE UNKNOWN.
🐷 CRIA-SE A ENGENHARIA DE PORCOS
A direção decidiu que aquilo jamais poderia acontecer novamente.
Foi criado o departamento de:
Enterprise Pig Roasting Architecture — EPRA.
O departamento estabeleceu padrões.
Agora cada porco precisava possuir:
PIG-ID;
peso;
idade;
raça;
temperatura inicial;
floresta de destino;
horário de entrada;
previsão de cozimento;
classificação de criticidade.
Foi criado um banco Db2.
TB_PORCO
TB_FLORESTA
TB_INCENDIO
TB_ASSAMENTO
TB_TEMPERATURA
TB_PORCO_FLORESTA
Um arquiteto observou que TB_PORCO_FLORESTA possuía uma relação N:N problemática.
Foram necessárias seis reuniões.
Enquanto isso, os porcos continuavam queimando.
📊 OBSERVABILIDADE
Alguém afirmou:
— O problema é falta de observabilidade.
Todos concordaram.
Foram instalados sensores.
Dashboards.
Métricas.
Logs.
Tracing.
Alertas.
Agora era possível saber em tempo real:
PIGS_PER_SECOND
MEAN_TIME_TO_ROAST
FOREST_BURN_RATE
AVERAGE_PIG_TEMPERATURE
PIG_ERROR_RATE
CARBONIZED_PIG_PERCENTAGE
Um enorme monitor foi colocado no NOC.
Quando um porco queimava demais, uma linha ficava vermelha.
Os executivos ficaram impressionados.
— Agora temos visibilidade!
Os porcos continuavam queimando.
Mas agora isso podia ser acompanhado num dashboard.
☁️ A MODERNIZAÇÃO
Chegou então um consultor.
Depois de analisar a arquitetura durante três semanas, apresentou 186 slides.
O primeiro dizia:
DIGITAL PIG TRANSFORMATION
A conclusão era clara:
o problema estava no legado.
Era necessário modernizar.
O COBOL PORC001 foi encapsulado por uma API REST.
Agora era possível incendiar a floresta utilizando:
POST /api/v1/pigs/roast
Payload:
{
"pigId": "0004711",
"forest": "F023",
"roastingLevel": "MEDIUM"
}
A API chamava z/OS Connect.
Que chamava CICS.
Que chamava COBOL.
Que gravava Db2.
Que publicava MQ.
Que finalmente executava:
INCENDIAR FLORESTA.
O CIO apresentou o projeto numa conferência:
“Transformamos nosso processo tradicional de produção de alimentos em uma plataforma API-first.”
Todos aplaudiram.
Os porcos continuavam sendo assados incendiando florestas.
☁️🐷 PORCOS NA CLOUD
Um novo estudo concluiu que o problema era outro.
A floresta estava on-premises.
Foi criado então:
Hybrid Cloud Pig Roasting Architecture.
O cadastro dos porcos foi para a cloud.
O sistema de incêndio permaneceu no mainframe.
Kafka transmitia eventos:
PIG_ENTERED_FOREST
FOREST_IGNITED
PIG_TEMPERATURE_CHANGED
PIG_ROASTED
PIG_OVERCOOKED
Um Data Lake armazenava vinte anos de telemetria de porcos queimados.
Machine Learning começou a prever quais porcos provavelmente seriam carbonizados.
A precisão chegou a 94%.
Um executivo perguntou:
— E conseguimos evitar que eles queimem?
O cientista de dados respondeu:
— Ainda não. Mas conseguimos prever com excelente precisão quais irão queimar.
O projeto recebeu um prêmio de inovação.
🤖 CHEGA A INTELIGÊNCIA ARTIFICIAL
Em 2026 surgiu a grande esperança.
IA Generativa.
Foi criado:
PigGPT Enterprise Edition.
A IA recebeu documentação, runbooks, logs, dumps, métricas SMF e quarenta anos de incidentes.
Perguntaram:
— Como melhorar o sistema de assar porcos?
A IA respondeu:
“Talvez seja possível assar os porcos diretamente utilizando uma fonte controlada de calor, sem incendiar uma floresta inteira.”
A resposta foi classificada como:
LOW CONFIDENCE / REQUIRES HUMAN VALIDATION
Um comitê de governança de IA foi convocado.
Após oito reuniões decidiu-se que a sugestão representava risco arquitetural porque não respeitava o processo corporativo estabelecido.
👨💻 JOÃO BOM-SENSO ENTRA NO CPD
Foi então que apareceu João.
João era programador COBOL.
Não era Distinguished Engineer.
Não era Enterprise Architect.
Não possuía certificação em transformação digital de porcos.
Ele estava apenas acompanhando um incidente.
Olhou os diagramas.
Olhou os jobs.
Olhou os dashboards.
Olhou os milhares de linhas COBOL.
Olhou Kafka.
Olhou MQ.
Olhou Kubernetes.
Olhou o Data Lake.
Depois perguntou:
— Por que vocês incendeiam uma floresta inteira?
A sala ficou silenciosa.
Um arquiteto respondeu:
— Para assar os porcos.
— Sim. Mas por que não fazemos uma pequena fogueira e colocamos o porco sobre ela?
Silêncio.
Alguém desligou o microfone.
Outro escreveu no chat privado:
“Quem convidou esse cara?”
🧪 A PROVA DE CONCEITO
João pegou um porco.
Algumas brasas.
Uma grelha.
Esperou.
O porco ficou perfeitamente assado.
Nenhuma floresta foi incendiada.
Nenhum batch foi executado.
Nenhuma mensagem MQ.
Nenhuma chamada REST.
Nenhum evento Kafka.
Nenhum Data Lake.
Nenhum SEV1.
Custo operacional:
quase zero.
O resultado foi apresentado à direção.
Por alguns segundos João acreditou que seria promovido.
Então começaram as perguntas.
— E o departamento de Engenharia de Incêndios?
— Não precisaria mais existir dessa forma.
— E nossos especialistas certificados em Propagação Florestal?
— Também não.
— E os 312 jobs?
— Poderíamos desativá-los.
— E nosso contrato de observabilidade?
— Grande parte deixaria de ser necessária.
— E o Data Lake?
— Continuaria existindo para outras coisas.
— E os vinte anos de dados históricos de incêndios?
— Seriam históricos.
— E nossa API?
— Provavelmente desnecessária para isso.
— E Kafka?
— Para assar um porco?
João começou a perceber o problema.
Ele não estava propondo apenas uma grelha.
Estava propondo destruir um ecossistema.
🏢 O SISTEMA NÃO ERA MAIS O SISTEMA
Durante cinquenta anos a empresa construíra organizações inteiras ao redor do método de incendiar florestas.
Existiam:
engenheiros de incêndio;
analistas de capacidade de incêndio;
DBAs especializados em tabelas de porcos;
operadores de batch;
especialistas em temperatura;
arquitetos de integração;
consultores;
auditores;
fornecedores;
contratos;
KPIs;
SLAs;
certificações;
procedimentos;
comitês;
diretorias.
O objetivo original havia sido:
assar porcos.
Mas lentamente o objetivo transformara-se em:
operar eficientemente o Sistema Corporativo de Incêndio de Florestas.
Essa diferença parecia pequena.
Não era.
Era gigantesca.
🧠 O DIRETOR EXPLICA A REALIDADE
O diretor chamou João.
— Sua ideia é interessante.
João sorriu.
— Obrigado.
— Mas você não compreende toda a complexidade.
João parou de sorrir.
O diretor mostrou o organograma.
Centenas de pessoas dependiam daquele processo.
Havia contratos plurianuais.
Depreciação de ativos.
Compliance.
Auditoria.
Treinamentos.
Orçamento.
Fornecedores.
Roadmaps.
Projetos estratégicos.
— Você está olhando apenas para o problema técnico — explicou o diretor.
João respondeu:
— Eu estou olhando para o porco.
O diretor respirou fundo.
— Exatamente. Esse é o problema.
🐷 O PORCO ESQUECIDO
Naquela noite João caminhou pelo Data Center.
Passou pelos enormes computadores.
Viu os painéis.
Os dashboards.
As luzes.
Os gráficos.
Tudo extraordinariamente sofisticado.
Então percebeu algo.
A organização sabia medir praticamente tudo.
Sabia quantas árvores queimavam.
Quanto combustível utilizava.
Quanto tempo levava.
Quantos processadores consumia.
Quantas mensagens trafegavam.
Quantos incidentes aconteciam.
Quanto custava cada floresta.
Mas havia uma pergunta que quase ninguém fazia:
“Ainda precisamos fazer isso dessa maneira?”
Essa pergunta não aparecia no SMF.
Não estava no RMF.
Não aparecia no Splunk.
Não existia no Grafana.
Não estava no Jira.
Não havia campo para ela no ServiceNow.
Porque nenhum sistema de observabilidade consegue detectar sozinho que o próprio processo observado deixou de fazer sentido.
☕ EPÍLOGO — O VERDADEIRO LEGADO
E aqui está a armadilha.
Legado não é COBOL.
Legado não é mainframe.
Legado não é VSAM.
Legado não é CICS.
Um programa COBOL com cinquenta anos que executa perfeitamente uma função necessária pode ser uma extraordinária peça de engenharia.
Enquanto isso, um microsserviço escrito ontem pode nascer legado se automatizar brilhantemente uma coisa que ninguém deveria continuar fazendo.
Modernização verdadeira não significa trocar:
COBOL → Java
ou:
MAINFRAME → CLOUD
ou:
BATCH → KAFKA
A pergunta anterior é muito mais importante:
POR QUE ESTE PROCESSO EXISTE?
Depois:
QUAL PROBLEMA ELE RESOLVE?
Depois:
AINDA PRECISAMOS RESOLVÊ-LO?
E somente então:
QUAL É A MELHOR TECNOLOGIA?
Porque você pode colocar uma API REST na frente do incêndio.
Pode publicar o incêndio no Kafka.
Pode executar o controle do incêndio em containers.
Pode armazenar os incêndios num Data Lake.
Pode usar IA para prever incêndios.
Pode criar dashboards espetaculares mostrando incêndios em tempo real.
E pode chamar tudo isso de transformação digital.
Mas...
se para conseguir um simples porco assado você ainda precisa incendiar uma floresta inteira,
talvez o problema nunca tenha sido o COBOL.
Talvez o problema seja que, em algum momento dos últimos cinquenta anos,
todo mundo começou a cuidar do SISTEMA e ninguém mais perguntou pelo porco.
🥚 EASTER EGG DO OPERADOR
Dizem que até hoje, exatamente às 03:17, existe um job desconhecido no scheduler:
JOB PORK999
Ninguém sabe quem o criou.
Ele executa apenas:
IF FLORESTA-EM-CHAMAS
DISPLAY 'MAS POR QUE?'
END-IF.
O programa possui somente um comentário:
*> J.BOM-SENSO - NAO REMOVER.
Ninguém remove.
Afinal...
é legado.
Inspirado em fabula dos porcos Juício a La Escuela Cirigliano, Forcade Tilich Editorial Editorial Humanitas – Buenos Aires, 1974
