☕ 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

quinta-feira, 12 de janeiro de 2017

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Bellacosa Mainframe e o red team

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

🎬 Ferris Bueller, engenharia social, computadores, confiança e a estranha arte de descobrir que o sistema acredita mais no banco de dados do que nos próprios olhos

Chicago, 1986.

Não existe ChatGPT.

Não existe LinkedIn.

Não existe Zero Trust.

Não existe SOC com 14 monitores mostrando mapas vermelhos enquanto alguém grita SEV-1.

Não existe MFA perguntando se você realmente é você.

Não existe aquele maravilhoso ritual moderno:

Digite sua senha.

Digite o código enviado ao celular.

Confirme no aplicativo.

Resolva o CAPTCHA.

Selecione todas as imagens contendo semáforos.

Sua sessão expirou.

Em algum lugar dos Estados Unidos, porém, existe algo muito mais perigoso.

Um adolescente inteligente.

Um computador.

Um telefone.

Muito tempo livre.

E uma instituição absolutamente convencida de que seus procedimentos funcionam.

Senhoras e senhores:

Ferris Bueller acaba de entrar no Red Team.


💾 Antes do Kali Linux havia Ferris Bueller

Quando pensamos em Red Team, é fácil imaginar uma sala escura.

Monitores.

Terminal Linux.

$ whoami
root

Um sujeito de capuz olhando para hexadecimal enquanto uma música eletrônica toca ao fundo.

Hollywood fez um belo estrago na nossa imaginação.

O verdadeiro atacante nem sempre começa procurando uma vulnerabilidade tecnológica.

Ele procura uma suposição.

Ferris Bueller é praticamente uma coleção ambulante delas.

A escola supõe que os alunos obedecerão.

Os pais supõem que o filho doente permanecerá na cama.

O restaurante supõe que alguém suficientemente convincente dizendo ser uma pessoa importante provavelmente seja essa pessoa.

O diretor supõe que perseguir Ferris resolverá o problema.

As pessoas supõem que aquilo que aparece no computador corresponde à realidade.

E Ferris?

Ferris pergunta silenciosamente:

“E se não corresponder?”

Bem-vindo ao Red Team.


🖥️ O computador da escola sabe quantas vezes Ferris faltou

Existe uma cena particularmente deliciosa para qualquer pessoa que passou a vida trabalhando com sistemas.

O registro escolar mostra as faltas de Ferris.

E então aquela informação começa a mudar.

A máquina registra uma realidade.

Ferris altera o registro.

A realidade administrativa muda junto.

Não importa que o corpo físico de Ferris tenha faltado.

Não importa que professores tenham visto sua cadeira vazia.

Não importa que alguém tenha contado suas ausências.

Para a burocracia, existe uma fonte oficial da verdade.

E a fonte oficial diz:

menos faltas.

Quarenta anos depois, continuamos cometendo exatamente o mesmo erro.

Só que agora chamamos isso de:

Single Source of Truth.


☕ “Mas está no sistema!”

Quem trabalha há algumas décadas com tecnologia conhece essa frase.

— O pagamento foi feito?

— Está no sistema.

— O cliente tem autorização?

— Está no sistema.

— O funcionário ainda trabalha aqui?

— Está no sistema.

— Esse usuário pode executar essa transação?

— Está no sistema.

— Esse processo realmente aconteceu?

— Está no sistema.

Maravilhoso.

Agora vem a pergunta desagradável do Red Team:

Quem pode alterar o sistema?

Essa pequena pergunta transforma uma tarde tranquila em uma reunião com Segurança, Auditoria, Compliance, Infraestrutura, Desenvolvimento e um gerente olhando para o teto.

Porque dados não são verdade.

Dados são representações da verdade.

E representações podem ser modificadas.


🔴 Red Team não pergunta apenas “é seguro?”

Essa talvez seja uma das diferenças fundamentais.

Uma organização olha para seu ambiente e pergunta:

“Estamos seguros?”

O Red Team pergunta:

“Como eu quebraria isso?”

Mas existe uma pergunta ainda melhor:

“O que vocês precisam acreditar para que isso funcione?”

Porque toda arquitetura possui pressupostos.

O usuário protegerá a senha.

O funcionário reconhecerá uma tentativa de fraude.

O administrador não abusará do privilégio.

O fornecedor protegerá sua integração.

O sistema legado receberá dados confiáveis.

A API será chamada apenas pelos sistemas autorizados.

O operador perceberá uma anomalia.

O backup funcionará.

O log não poderá ser alterado.

A IA reconhecerá uma instrução maliciosa.

Ferris Bueller olha para essa lista e sorri.


📞 Cameron, precisamos de você

Um dos aspectos mais interessantes de Curtindo a Vida Adoidado é que Ferris raramente depende de uma única técnica.

Ele combina recursos.

Computador.

Telefone.

Conhecimento das pessoas.

Improvisação.

Timing.

Cameron.

Sloane.

Expectativas sociais.

Autoridade.

Confusão.

Isso é muito mais próximo de uma operação adversarial real do que a imagem do hacker apertando freneticamente um teclado.

Imagine uma organização com cinco controles.

Firewall
   ↓
MFA
   ↓
EDR
   ↓
SIEM
   ↓
SOC

Parece formidável.

Agora imagine:

Atacante
   ↓
Funcionário
   ↓
Processo legítimo
   ↓
Credencial legítima
   ↓
Sistema legítimo

Houston...

Temos um problema.

O atacante não atravessou o firewall.

O firewall deixou o usuário autorizado entrar.


🌭 Abe Froman, o Rei da Salsicha de Chicago

E então chegamos a uma das minhas partes favoritas.

Ferris precisa de uma identidade.

Surge:

Abe Froman.

O Sausage King of Chicago.

É absurdo.

É maravilhoso.

E funciona porque identidade é uma construção social antes de ser uma construção tecnológica.

Você não precisa necessariamente demonstrar quem é.

Às vezes basta convencer alguém de que deveria ser aquela pessoa.

Esse princípio continua vivo em 2026.

Mudaram apenas as ferramentas.

Hoje temos:

Identity
↓
Authentication
↓
Authorization
↓
Privilege
↓
Action

E segurança moderna tenta impedir que uma coisa seja confundida com a seguinte.

Conhecer meu nome não prova que você sou eu.

Possuir minha senha não deveria necessariamente provar que você sou eu.

Conseguir autenticar-se não deveria significar que pode acessar tudo.

Ter acesso não deveria significar poder alterar qualquer coisa.

E poder alterar alguma coisa não deveria significar fazê-lo sem deixar evidências.

É por isso que Red Team adora identidades.

Porque organizações são construídas sobre confiança.


🔎 OSINT: Ferris conhece o ambiente

Existe outra característica fundamental.

Ferris presta atenção.

Ele conhece pessoas.

Conhece comportamentos.

Conhece horários.

Conhece relações.

Conhece expectativas.

Conhece a linguagem necessária para representar determinado papel.

Em segurança moderna chamamos parte disso de OSINT — Open Source Intelligence.

E existe uma quantidade quase obscena de informação disponível publicamente.

Uma organização publica que está contratando:

“Especialista em Kubernetes, AWS, Terraform, Jenkins e GitLab.”

Interessante.

Outra pessoa escreve:

“Orgulhoso de concluir nossa migração para determinada plataforma!”

Interessante.

Um administrador publica uma captura de tela comemorando uma certificação.

Interessante.

Um desenvolvedor deixa um projeto antigo no GitHub.

Interessante.

Um executivo anuncia uma viagem.

Interessante.

Uma empresa publica seu organograma.

Interessante.

Separadamente, quase nada disso parece perigoso.

Junto?

Ferris começa a montar o quebra-cabeça.


🧀 O queijo suíço de Ferris Bueller

É aqui que Red Team fica realmente fascinante.

Raramente existe uma vulnerabilidade cinematográfica:

APERTE ESTE BOTÃO E O BANCO EXPLODE.

Na vida real encontramos pequenas imperfeições.

Uma informação pública demais.

Uma permissão um pouco excessiva.

Uma conta antiga.

Um processo manual.

Uma senha reutilizada.

Uma API esquecida.

Um funcionário excessivamente prestativo.

Um fornecedor com acesso.

Um endpoint sem monitoramento adequado.

Uma exceção criada três anos atrás durante uma emergência.

Cada uma isoladamente parece tolerável.

Mas alinhe os buracos.

OSINT
  ↓
Engenharia Social
  ↓
Credencial
  ↓
Acesso
  ↓
Escalada
  ↓
Movimento Lateral
  ↓
Sistema Crítico

Parabéns.

Você acaba de transformar pequenas imperfeições em uma cadeia de ataque.

Ferris não precisa encontrar um buraco gigantesco.

Ele precisa encontrar buracos alinhados.


🚗 A Ferrari do Cameron é nosso ambiente de produção

Agora precisamos falar daquela Ferrari.

O pai de Cameron possui uma joia.

Uma máquina preciosa.

Protegida não necessariamente por controles técnicos sofisticados, mas por algo profundamente humano:

ninguém ousaria tocar nela.

Excelente estratégia.

Até aparecer Ferris Bueller.

Em tecnologia também fazemos isso.

— Ninguém mexe nesse dataset.

— Por quê?

— É produção.

— Existe controle impedindo?

— Não.

— Auditoria?

— Mais ou menos.

— Aprovação dupla?

— Não.

— Então por que ninguém mexe?

— Porque todo mundo sabe que não pode.

Ferris lentamente coloca os óculos escuros.

SAVE FERRIS.


🔐 Least Privilege: Cameron não deveria ter acesso à Ferrari

Aqui entra um dos conceitos mais importantes da segurança:

Least Privilege.

Você deve possuir apenas o acesso necessário para executar sua função.

Nada além.

Porque permissões acumulam-se.

Funcionários mudam de departamento.

Projetos terminam.

Contas permanecem.

Autorizações antigas sobrevivem.

Service accounts ganham poderes.

Exceções temporárias tornam-se permanentes.

E quinze anos depois alguém pergunta:

— Por que USER123 possui acesso administrativo?

Silêncio.

Um veterano olha para o horizonte.

— Acho que foi por causa daquela migração de 2011.

Ratchet Effect.

Privilégio entra.

Privilégio raramente sai.


🦖 E no mainframe?

Agora Ferris chegou ao meu território.

Se ele entrar no z/OS, as coisas ficam interessantes.

Porque o mainframe possui mecanismos extraordinariamente maduros de segurança.

RACF.

SAF.

Perfis.

Grupos.

Auditoria.

Segregação.

Controles de datasets.

Recursos protegidos.

Mas existe uma pergunta que sempre deve ser feita:

Como o mundo exterior chega até o mainframe?

Porque hoje não estamos falando apenas de alguém sentado num terminal 3270.

Temos:

Internet
   ↓
Aplicação
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Ou:

Cloud
 ↓
MQ
 ↓
Mainframe

Ou:

CI/CD
 ↓
Pipeline
 ↓
Credencial técnica
 ↓
Deploy
 ↓
Produção

O z/OS pode estar magnificamente protegido.

Ferris talvez nem tente atacá-lo diretamente.

Ele procura quem já possui autorização para conversar com ele.

Esse é o detalhe que muda tudo.


🤖 FerrisGPT entrou na escola

E chegamos a 2026.

O Ferris original precisava improvisar.

Pesquisar.

Telefonar.

Interpretar personagens.

Preparar histórias.

Coordenar pessoas.

Hoje podemos automatizar partes dessa preparação com IA.

LLMs podem ajudar a analisar grandes volumes de informação, organizar dados públicos, produzir textos convincentes, correlacionar documentos e operar como componentes de sistemas agentes.

Isso aumenta brutalmente a escala possível de certas operações.

O problema deixa de ser apenas:

“Existe alguém inteligente o suficiente para tentar?”

E passa a incluir:

“Quanto dessa inteligência operacional pode ser automatizada?”

Ao mesmo tempo surge uma superfície completamente nova.

Prompt injection.

Data poisoning.

Excesso de autonomia.

Agentes com privilégios demais.

Credenciais disponíveis no contexto.

Ferramentas conectadas.

RAG contaminado.

Confiança excessiva na resposta do modelo.

Ferris olha para um agente com acesso a e-mail, arquivos, APIs e banco de dados.

Ferris sorri.

O Blue Team começa a suar.


🛡️ E aqui precisamos colocar Rooney na história

Todo Ferris precisa de um Rooney.

O diretor sabe que alguma coisa está errada.

Ele suspeita.

Investiga.

Persegue.

Insiste.

E progressivamente torna-se tão obcecado pela própria hipótese que começa a cometer erros.

Isso também é segurança.

Analistas não são máquinas.

SOC não é máquina.

Red Team não é máquina.

Gestores não são máquinas.

Todos carregamos vieses.

Confirmation Bias.

Anchoring Bias.

Plan Continuation Bias.

Sunk Cost Fallacy.

Outcome Bias.

Automation Bias.

Você pode possuir todas as ferramentas corretas e ainda interpretar os sinais incorretamente.

Pior:

pode encontrar evidências que contradizem sua hipótese e decidir que elas apenas demonstram como o atacante é sofisticado.

Rooney acaba de entrar no SOC.


🚨 ALERTA CRÍTICO!

Imagine Rooney trabalhando num SIEM.

03:14:07 LOGIN FAILURE
03:14:11 LOGIN FAILURE
03:14:16 LOGIN SUCCESS
03:17:44 DATABASE QUERY
03:19:02 PRIVILEGE CHANGE

Rooney:

É O FERRIS!

Analista:

— Senhor, o usuário está de férias.

Rooney:

EXATAMENTE O QUE FERRIS QUER QUE VOCÊ PENSE!

Analista:

— O IP pertence à nossa VPN corporativa.

Rooney:

ELE É BOM!

Analista:

— O acesso foi aprovado pelo gerente.

Rooney:

ELE É MUITO BOM!

Nesse momento alguém deveria retirar Rooney da War Room.


🚗 Coloque a Ferrari em marcha a ré

Talvez nenhuma cena seja tão maravilhosa para um veterano de TI quanto a tentativa de desfazer a quilometragem da Ferrari.

A lógica parece perfeita.

O carro rodou para frente.

A quilometragem aumentou.

Então:

vamos rodar para trás.

Quem nunca viu raciocínio semelhante em produção?

— Podemos voltar?

— Temos backup.

— Testado?

Silêncio.

— Temos backup.

— Quando foi o último restore?

Silêncio ainda maior.

Backup não é restore.

Restore não é rollback.

Rollback não elimina necessariamente logs.

Rollback não apaga consequências.

Rollback não desfaz uma mensagem enviada.

Rollback não recupera confiança.

E colocar a Ferrari em marcha a ré certamente não garante que ela permaneça na garagem.

Produção não possui:

CTRL+Z emocional.


🔵 Então para que serve o Red Team?

Aqui está a parte mais importante.

Red Team não deveria existir para alguém aparecer numa reunião dizendo:

“HAHA! ENGANEI VOCÊS!”

Isso é infantil.

O objetivo não é humilhar o Blue Team.

Não é provar que alguém é hacker.

Não é colecionar shells.

Não é imprimir root numa camiseta.

O objetivo é descobrir alguma coisa que a organização não sabia sobre si mesma.

Talvez um controle não funcione.

Talvez funcione tecnicamente, mas possa ser contornado por processo.

Talvez uma detecção não exista.

Talvez o SOC veja o evento, mas não compreenda seu significado.

Talvez existam privilégios excessivos.

Talvez pessoas confiem demais numa determinada informação.

Talvez a arquitetura tenha criado uma cadeia inesperada.

Red Team produz conhecimento adversarial.

Hipótese
   ↓
Reconhecimento
   ↓
Simulação
   ↓
Evidência
   ↓
Detecção
   ↓
Correção
   ↓
Reteste

O ataque é apenas o instrumento.

Aprendizado é o produto.


☕ O Bellacosa Mainframe encontra Ferris Bueller

Talvez seja por isso que, quase quarenta anos depois, aquela cena do computador continue tão divertida.

A tecnologia envelheceu.

A tela envelheceu.

O computador envelheceu.

A interface envelheceu.

Mas a vulnerabilidade fundamental continua assustadoramente moderna:

alguém confiou no sistema sem perguntar suficientemente quem poderia alterar aquilo em que o sistema acreditava.

Essa pergunta atravessa décadas.

Mainframe.

Client/server.

Internet.

Cloud.

Mobile.

APIs.

IA.

Agentes.

Mudamos as interfaces.

Mudamos os protocolos.

Mudamos as linguagens.

Mudamos os nomes.

Mas continuamos construindo máquinas sobre camadas de confiança humana.

E sempre haverá algum Ferris perguntando:

“O que acontece se eu fizer isto?”


🎬 SAVE FERRIS

Esta será nossa viagem.

Nos próximos artigos, Ferris Bueller deixará de ser apenas o adolescente que queria matar aula.

Vamos transformá-lo em nosso Red Teamer acidental.

Vamos desmontar o computador da escola.

Conhecer Abe Froman.

Usar OSINT.

Telefonar para Cameron.

Perseguir Ferris com Rooney.

Proteger a Ferrari.

Tentar fazer rollback.

Entrar no mainframe.

Conversar com RACF.

Encontrar APIs.

Soltar FerrisGPT.

E descobrir que segurança talvez tenha muito menos a ver com construir uma muralha perfeita e muito mais com compreender como alguém inteligente tentaria contorná-la.

Porque existe uma diferença enorme entre:

“O sistema funciona.”

e:

“O sistema continua funcionando quando alguém deliberadamente tenta fazê-lo funcionar de uma maneira que jamais imaginamos.”

Essa segunda pergunta?

Essa é a pergunta do Red Team.

E como Ferris nos ensinou:

A vida passa muito rápido.

Os sistemas também.

E se você não parar de vez em quando para olhar para eles como um atacante...

pode descobrir tarde demais que Ferris já alterou o número de faltas, pegou Cameron, buscou Sloane, virou Abe Froman, saiu dirigindo a Ferrari...

...e o seu SIEM continua dizendo:

STATUS: GREEN
THREATS DETECTED: 0
ALL SYSTEMS OPERATIONAL

Bem-vindo ao Red Team.

SAVE FERRIS.

E, por favor, alguém coloque MFA naquela Ferrari.

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

  • Red Team
  • OSINT
  • Engenharia Social
  • Blue Team
  • MFA
  • PAM
  • IA Generativa
  • RACF
  • z/OS
  • Mainframe
1

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication
4

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk
6

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access
8

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response
10

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

quarta-feira, 11 de janeiro de 2017

Microsserviços : Quando um Programador Descobre que Dividir um Monólito em Cinquenta Pedaços Não o Transforma Automaticamente em Arquitetura

 

Bellacosa Mainframe apresenta microsserviços para programador cobol

☕ Um Café no Bellacosa Mainframe

Microsserviços sem Mistérios para Programadores COBOL

Quando um Programador Descobre que Dividir um Monólito em Cinquenta Pedaços Não o Transforma Automaticamente em Arquitetura

O jovem programador caminhava lentamente pelo corredor do data center.

À esquerda, enormes gabinetes de mainframe piscavam com a serenidade de quem processava milhões de transações sem precisar publicar frases motivacionais no LinkedIn. À direita, servidores modernos executavam containers, APIs, pipelines, gateways, brokers, sidecars e outros pequenos animais digitais que aparentemente se multiplicavam quando ninguém estava olhando.

Em suas mãos, o aprendiz carregava um diagrama colorido chamado:

“How to Design Microservices”

Ele encontrou o velho Mestre Bellacosa sentado diante de um terminal 3270, segurando uma pequena xícara de café.

— Mestre — perguntou o aprendiz — finalmente compreendi os microsserviços. Basta pegar um programa grande, separá-lo em vários programas pequenos e colocá-los em containers.

O mestre tomou um gole de café.

Olhou para o jovem.

Olhou para o terminal.

Olhou novamente para o jovem.

— Pequeno gafanhoto — respondeu — se você cortar um elefante em cinquenta pedaços, não terá cinquenta animais independentes. Terá apenas um grande problema distribuído pelo chão.

O aprendiz permaneceu em silêncio.

Ao longe, ouviu-se o som de um job terminando com RC=0000.

E assim começou mais uma aula no Bellacosa Mainframe.


1. O que são microsserviços, afinal?

Microsserviços não são simplesmente programas pequenos.

Também não são:

  • containers;

  • APIs REST;

  • funções Java;

  • pods Kubernetes;

  • repositórios Git;

  • filas de mensagens;

  • aplicações hospedadas na nuvem.

Essas tecnologias podem participar de uma arquitetura de microsserviços, mas nenhuma delas, isoladamente, cria um microsserviço.

Um microsserviço é uma unidade de software construída em torno de uma responsabilidade clara do negócio.

Ele deve possuir, tanto quanto possível:

  • objetivo bem definido;

  • regras próprias;

  • dados sob seu controle;

  • interface conhecida;

  • equipe responsável;

  • ciclo de vida independente;

  • capacidade de ser implantado sem obrigar todo o sistema a mudar;

  • capacidade de falhar sem destruir a empresa inteira.

Para um programador COBOL iniciante, podemos comparar um microsserviço a um programa bem delimitado, mas com uma diferença importante: ele não vive apenas como uma rotina interna chamada por CALL.

Ele vive em um mundo distribuído.

Nesse mundo, a comunicação pode atravessar:

  • redes;

  • balanceadores;

  • APIs;

  • filas;

  • certificados;

  • gateways;

  • firewalls;

  • serviços de autenticação;

  • bancos distintos;

  • ambientes diferentes.

Uma simples chamada deixa de ser algo como:

CALL 'CALCJURO' USING WS-VALOR WS-TAXA WS-RESULTADO

e passa a ser algo parecido com:

Programa solicitante
        ↓
API Gateway
        ↓
Autenticação
        ↓
Serviço de cálculo
        ↓
Banco de dados
        ↓
Resposta pela rede

No programa COBOL local, se CALCJURO estiver disponível, a chamada acontece dentro do mesmo ambiente de execução.

No ambiente distribuído, tudo pode acontecer:

  • a rede pode estar lenta;

  • o DNS pode falhar;

  • o serviço pode estar reiniciando;

  • o certificado pode ter expirado;

  • o banco pode estar bloqueado;

  • a resposta pode chegar depois do timeout;

  • a operação pode ter sido concluída, embora o cliente não tenha recebido confirmação.

O primeiro ensinamento é simples:

Microsserviços não reduzem a complexidade. Eles transferem parte da complexidade do código para a comunicação, a infraestrutura e a operação.


2. Comece pelo negócio, não pelo programa

O primeiro passo mostrado no diagrama é:

Definir capacidades de negócio.

Esse é o fundamento de tudo.

Imagine um banco.

O banco precisa realizar capacidades como:

  • cadastrar clientes;

  • abrir contas;

  • receber depósitos;

  • efetuar transferências;

  • administrar cartões;

  • calcular limites;

  • detectar fraudes;

  • emitir cobranças;

  • produzir extratos.

Essas são capacidades que fazem sentido para o negócio.

Agora compare com uma divisão puramente técnica:

  • serviço de leitura de tabela;

  • serviço de gravação de arquivo;

  • serviço de validação;

  • serviço de impressão;

  • serviço de conversão de data;

  • serviço de cálculo de dígito.

Essas funções podem existir no sistema, mas não representam necessariamente serviços independentes.

O erro clássico de modernização acontece quando alguém analisa um ambiente legado e conclui:

— Temos 900 programas COBOL. Logo, criaremos 900 microsserviços.

Nesse momento, em algum lugar do universo, um arquiteto experiente derruba lentamente sua caneca.

Um programa COBOL pode ser:

  • um módulo reutilizável;

  • uma etapa de um job;

  • uma rotina de validação;

  • um programa de acesso a dados;

  • um programa online CICS;

  • um módulo chamado por dezenas de outros;

  • uma pequena parte de uma capacidade muito maior.

Transformar cada programa em serviço remoto pode substituir chamadas locais extremamente rápidas por centenas de interações de rede.

Aquilo que antes era:

PERFORM VALIDAR-CLIENTE

pode acabar virando:

Aplicação chama serviço de cliente
Serviço de cliente chama serviço de endereço
Serviço de endereço chama serviço de CEP
Serviço de CEP chama serviço de região
Serviço de região chama serviço tributário

Tudo isso apenas para descobrir que o campo WS-CEP está vazio.

O verdadeiro ponto de partida é perguntar:

  • O que a empresa realmente faz?

  • Quais funções entregam valor?

  • Quais regras mudam de forma independente?

  • Quais áreas possuem responsabilidades próprias?

  • Quais capacidades precisam escalar separadamente?

  • Quais processos podem falhar sem interromper os demais?

Curiosidade do templo

No Domain-Driven Design, uma capacidade empresarial costuma ser estudada dentro de um domínio.

Por exemplo:

Domínio: Comércio eletrônico

Pode conter subdomínios como:

Catálogo
Pedidos
Estoque
Pagamento
Entrega
Fidelidade

Cada domínio possui linguagem, regras e objetivos próprios.

Isso é muito diferente de dividir o sistema apenas por linguagem de programação, tabela ou tipo de arquivo.


3. Identifique os limites do serviço

O segundo passo é descobrir onde um serviço termina e o outro começa.

Esse limite é chamado de service boundary.

Considere a palavra “cliente”.

Para a área de vendas, cliente pode significar:

  • nome;

  • telefone;

  • preferências;

  • histórico comercial.

Para o setor financeiro, cliente pode significar:

  • documento;

  • limite;

  • inadimplência;

  • risco de crédito.

Para o setor de entrega, cliente pode significar:

  • nome do destinatário;

  • endereço;

  • instrução de recebimento.

São visões diferentes da mesma pessoa.

Não é obrigatório construir uma estrutura universal gigantesca contendo tudo o que todos os setores sabem.

No COBOL, essa estrutura poderia acabar assim:

01 CLIENTE-GLOBAL.
   05 CLIENTE-DADOS-PESSOAIS.
   05 CLIENTE-DADOS-FINANCEIROS.
   05 CLIENTE-DADOS-LOGISTICOS.
   05 CLIENTE-PREFERENCIAS.
   05 CLIENTE-DADOS-FISCAIS.
   05 CLIENTE-HISTORICO.
   05 CLIENTE-CAMPOS-FUTUROS.
   05 CLIENTE-CAMPOS-QUE-NINGUEM-SABE-PARA-QUE-SERVEM.

Depois de alguns anos, ninguém teria coragem de alterar esse copybook.

Cada serviço deve conhecer apenas a visão necessária para cumprir sua responsabilidade.

O serviço de entregas não precisa conhecer a renda do cliente.

O serviço de marketing não precisa conhecer o número completo do cartão.

O serviço de catálogo não precisa saber a situação de uma cobrança bancária.

Um bom limite reduz a quantidade de conhecimento compartilhado.

Sinal de limite ruim

Imagine um serviço chamado “Serviço Central”.

Ele:

  • cadastra cliente;

  • calcula preço;

  • reserva estoque;

  • processa pagamento;

  • emite nota;

  • envia e-mail;

  • agenda entrega;

  • atualiza pontos;

  • gera relatório;

  • consulta fraude.

O serviço possui uma API moderna, executa em container e aparece em um desenho cheio de hexágonos.

Mesmo assim, ele continua sendo um monólito.

A roupa mudou.

O imperador continua o mesmo.


4. Escolha a granularidade adequada

O terceiro passo é decidir o tamanho dos serviços.

Esse é um dos pontos mais difíceis porque não existe um número mágico.

Um microsserviço não precisa ter:

  • cem linhas;

  • mil linhas;

  • cinco classes;

  • uma tabela;

  • um endpoint.

O tamanho correto depende da responsabilidade.

Grande demais

Se o serviço cuida de várias capacidades distintas, ele começa a se transformar em outro monólito.

Sintomas:

  • várias equipes alteram o mesmo código;

  • o deployment é arriscado;

  • qualquer mudança exige testes enormes;

  • escalar uma função obriga escalar todas;

  • módulos internos ficam fortemente acoplados.

Pequeno demais

Se cada função mínima vira um serviço, surge uma explosão de componentes.

Podemos imaginar:

Serviço Valida CPF
Serviço Calcula Dígito do CPF
Serviço Remove Pontuação do CPF
Serviço Formata CPF
Serviço Verifica CPF Vazio
Serviço Registra CPF

Agora cadastrar uma pessoa requer uma peregrinação por seis serviços.

O mestre chama isso de:

A Técnica do Nanosserviço de Mil Cortes.

Nenhum corte parece fatal isoladamente, mas o sistema morre lentamente em latência, logs, pipelines e reuniões.

O custo real de cada serviço

Todo novo serviço precisa de:

  • código;

  • testes;

  • repositório;

  • pipeline;

  • documentação;

  • configuração;

  • logs;

  • métricas;

  • alertas;

  • controle de acesso;

  • certificados;

  • versionamento;

  • processo de deployment;

  • suporte;

  • tratamento de falhas;

  • equipe responsável.

Portanto, um serviço de 300 linhas pode gerar uma carga operacional muito maior do que um módulo COBOL de 20 mil linhas bem organizado.

Pergunta prática

Um serviço está em boa granularidade quando podemos dizer:

“Este componente é responsável por esta capacidade e pode evoluir sem exigir mudanças constantes em todo o restante.”

Não existe perfeição inicial.

Os limites podem evoluir à medida que o conhecimento sobre o negócio aumenta.


5. Projete a API como um contrato

Depois que as responsabilidades estão claras, precisamos definir como os serviços se comunicam.

A API é o contrato público do serviço.

Ela deve expressar ações de negócio, não detalhes internos de banco.

Exemplo ruim

POST /insertPedido
PUT /updateStatusPedido
GET /selectPedido
DELETE /deletePedido

Esse modelo simplesmente expõe operações de tabela.

É o equivalente digital de colocar uma janela na parede do banco de dados e deixar cada sistema meter a mão lá dentro.

Exemplo melhor

POST /pedidos
GET /pedidos/123
POST /pedidos/123/cancelamento
POST /pedidos/123/confirmacao

Essas operações representam intenções empresariais.

A API deve definir claramente:

  • formato da requisição;

  • formato da resposta;

  • campos obrigatórios;

  • códigos de erro;

  • autenticação;

  • autorização;

  • versionamento;

  • regras de repetição;

  • limites de consumo;

  • comportamento em falhas.

Idempotência

Esse nome estranho é essencial.

Imagine que uma aplicação solicite um pagamento.

Ela envia a requisição, mas a resposta demora.

O cliente não sabe se o pagamento foi processado.

Então envia novamente.

Sem idempotência, o usuário pode ser cobrado duas vezes.

Uma chave idempotente pode identificar a solicitação:

IDEMPOTENCY-KEY: PAGAMENTO-2026-0009981

Se o serviço receber a mesma chave novamente, devolve o resultado já registrado.

No mundo COBOL, pense em um identificador único de transação armazenado antes do processamento.

Antes de executar, o sistema verifica:

IF TRANSACAO-JA-PROCESSADA
   RETORNAR-RESULTADO-ANTERIOR
ELSE
   PROCESSAR-TRANSACAO
END-IF

Em sistemas distribuídos, isso não é luxo.

É sobrevivência.


6. Cada serviço deve possuir seus dados

O quinto passo do diagrama fala de data ownership.

Um serviço deve controlar os dados de sua responsabilidade.

Isso não significa necessariamente possuir uma máquina física exclusiva.

Significa que outros serviços não devem alterar diretamente suas estruturas internas.

Considere:

Serviço de Pedidos
Serviço de Pagamentos
Serviço de Estoque
Serviço de Entregas

Se todos acessarem e atualizarem as mesmas tabelas, qualquer mudança poderá afetar todos.

O banco compartilhado cria dependências ocultas:

  • uma coluna removida quebra outro serviço;

  • uma atualização direta ignora regras;

  • um relatório pesado afeta transações;

  • ninguém sabe quem é o dono da tabela;

  • todos precisam coordenar deployments.

O sistema pode ter vinte aplicações separadas, mas continuar sendo um monólito de banco de dados.

Estratégia recomendada

Pedidos controla pedidos
Pagamento controla cobranças
Estoque controla quantidades e reservas
Entrega controla remessas

Quando um serviço precisa de informação de outro, utiliza:

  • API;

  • mensagem;

  • evento;

  • réplica controlada;

  • cache;

  • visão materializada.

“Mas e o JOIN?”

O programador COBOL acostumado ao Db2 pergunta:

— Mestre, como faremos o JOIN?

O mestre responde:

— Com cuidado, pequeno gafanhoto.

Em microsserviços, os dados podem estar separados.

Um relatório consolidado pode usar:

  • data warehouse;

  • data lake;

  • modelo de leitura;

  • CQRS;

  • eventos;

  • réplica de consulta;

  • processo batch de consolidação.

Não é recomendável montar todo relatório corporativo chamando quinze APIs em tempo real.

Isso cria uma consulta que depende simultaneamente de quinze serviços.

Se um falhar, o relatório pode virar uma página branca contendo a mensagem:

“Erro inesperado. Tente novamente mais tarde.”

A mensagem oficial da era digital.


7. Comunicação síncrona e assíncrona

O sexto passo é escolher como os serviços conversam.

Comunicação síncrona

Um serviço envia uma solicitação e espera uma resposta.

Exemplos:

  • REST;

  • SOAP;

  • gRPC;

  • z/OS Connect;

  • chamadas via gateway.

Fluxo:

Cliente → Pedido → Estoque → Resposta

É útil quando a resposta é necessária naquele momento.

Por exemplo:

  • consultar saldo;

  • validar limite;

  • obter preço;

  • confirmar disponibilidade.

Mas há um risco.

Se A chama B, B chama C, C chama D e D chama E, temos uma corrente.

A → B → C → D → E

Todos precisam funcionar dentro do tempo esperado.

A latência se acumula.

As probabilidades de falha também.

O usuário clicou uma vez, mas o sistema realizou uma pequena expedição ao Himalaia.

Comunicação assíncrona

O serviço publica uma mensagem e continua.

Exemplo:

PedidoCriado
     ↓
IBM MQ, Kafka ou outro broker
     ├── Estoque
     ├── Pagamento
     ├── Notificação
     └── Fidelidade

Isso permite desacoplamento.

O serviço de pedidos não precisa esperar que o e-mail seja enviado para confirmar o pedido.

A notificação pode ocorrer alguns segundos depois.

A mensageria também ajuda a absorver picos.

Se chegam dez mil pedidos, a fila pode armazená-los enquanto os consumidores processam gradualmente.

Comando e evento

Um comando solicita uma ação:

ReservarEstoque

Um evento declara um fato:

EstoqueReservado

Essa diferença é importante.

O comando pode falhar ou ser recusado.

O evento representa algo que já ocorreu.

Easter egg do mainframe

Programadores mainframe já trabalham com ideias semelhantes há décadas:

  • MQ;

  • filas;

  • processamento batch;

  • desacoplamento;

  • checkpoints;

  • reprocessamento;

  • arquivos de entrada e saída;

  • controle de transação.

Muitas práticas apresentadas como descobertas revolucionárias da computação moderna estavam tranquilamente funcionando em data centers quando os atuais evangelistas de cloud ainda assistiam desenho animado em televisão de tubo.


8. Falhas devem ser previstas

O sétimo passo é tratar falhas desde o início.

Em um programa local, muitos componentes vivem no mesmo ambiente.

Em microsserviços, a rede é parte do sistema.

E a rede possui um senso de humor sombrio.

Timeout

Toda chamada remota precisa de um limite.

Sem timeout, o programa pode esperar indefinidamente.

Exemplo:

Serviço de pedido chama pagamento
Pagamento não responde
Após dois segundos, a chamada é encerrada

O timeout precisa ser escolhido com base em dados reais.

Muito curto:

  • operações válidas são canceladas.

Muito longo:

  • recursos ficam presos;

  • usuários aguardam;

  • filas de threads se acumulam.

Retry

O retry tenta novamente uma operação temporariamente falha.

Pode funcionar para:

  • erro de rede;

  • serviço temporariamente indisponível;

  • timeout transitório;

  • resposta 503.

Não deve ser usado para:

  • senha inválida;

  • saldo insuficiente;

  • documento incorreto;

  • regra de negócio rejeitada;

  • mensagem malformada.

Tentar novamente uma operação impossível é apenas falhar com dedicação.

Backoff e jitter

As tentativas não devem ocorrer todas imediatamente.

Podemos esperar:

500 milissegundos
1 segundo
2 segundos
4 segundos

O jitter adiciona uma variação aleatória.

Sem isso, milhares de clientes podem repetir ao mesmo tempo e esmagar o serviço que estava tentando se recuperar.

Circuit breaker

O circuit breaker interrompe chamadas para um serviço que está falhando.

Estados comuns:

CLOSED
OPEN
HALF-OPEN

Quando fechado, chamadas passam.

Quando aberto, chamadas são bloqueadas rapidamente.

No estado semiaberto, algumas chamadas de teste verificam se houve recuperação.

Pense em um disjuntor elétrico.

Ele não discute filosofia com o curto-circuito.

Ele interrompe a corrente.

Fallback

O fallback fornece alternativa:

  • cache;

  • informação parcial;

  • resposta padrão segura;

  • fila para processamento posterior.

Mas o fallback não pode inventar dados críticos.

Se o saldo não está disponível, o sistema não deve escolher um valor aleatório apenas para manter a experiência “fluida”.


9. Sagas e transações distribuídas

No mainframe, estamos acostumados com transações fortes.

Uma unidade de trabalho pode terminar com:

COMMIT

ou:

ROLLBACK

Em microsserviços, uma transação pode atravessar vários bancos.

Exemplo:

  1. Criar pedido;

  2. Reservar estoque;

  3. Cobrar pagamento;

  4. Criar entrega.

Se o pagamento falhar depois da reserva, o que acontece?

Uma solução é usar o padrão Saga.

Cada etapa possui uma ação e, quando necessário, uma compensação.

Criar pedido
Reservar estoque
Pagamento falhou
Liberar estoque
Cancelar pedido

A compensação não apaga magicamente o passado.

Ela executa uma nova operação que neutraliza o efeito anterior.

Por exemplo:

  • débito realizado;

  • transferência cancelada;

  • crédito compensatório efetuado.

Isso exige regras claras.

A palavra “desfazer” parece simples até envolver:

  • dinheiro;

  • estoque;

  • impostos;

  • nota fiscal;

  • transporte;

  • auditoria.


10. Observabilidade: enxergar o sistema

O oitavo passo é adicionar observabilidade.

Em um monólito, podemos investigar:

  • um log;

  • um dump;

  • uma região CICS;

  • um job;

  • uma tabela;

  • um programa.

Em microsserviços, uma requisição pode atravessar dezenas de componentes.

Precisamos de:

  • logs;

  • métricas;

  • traces.

Logs

Um log útil deve informar:

  • data e hora;

  • serviço;

  • operação;

  • identificador da transação;

  • resultado;

  • tempo;

  • erro;

  • ambiente.

Um log inútil diz:

Ocorreu um erro.

Esse tipo de mensagem possui a precisão investigativa de um oráculo gripado.

Métricas

Métricas respondem perguntas como:

  • quantas requisições chegaram?

  • qual a latência média?

  • quantas falharam?

  • quantos timeouts ocorreram?

  • qual a profundidade da fila?

  • quantas mensagens aguardam processamento?

  • quantos circuit breakers estão abertos?

Tracing distribuído

Um trace acompanha a jornada de uma solicitação.

Gateway: 20 ms
Pedido: 40 ms
Estoque: 80 ms
Pagamento: 950 ms
Notificação: 25 ms

Agora podemos localizar o gargalo.

Sem um correlation ID, investigar um problema distribuído é como procurar um job no JES2 sabendo apenas que ele “rodou na terça-feira”.

Observabilidade empresarial

Não basta saber que CPU e memória estão normais.

Devemos observar:

  • pedidos concluídos;

  • pagamentos recusados;

  • transferências pendentes;

  • reservas expiradas;

  • mensagens em dead-letter queue;

  • divergências de conciliação.

O sistema pode estar tecnicamente perfeito e comercialmente inútil.

Todos os containers verdes.

Nenhuma venda concluída.


11. Segurança em todos os serviços

O nono passo é proteger cada serviço.

Não podemos confiar automaticamente em tudo que está dentro da rede.

A segurança deve considerar:

  • autenticação;

  • autorização;

  • criptografia;

  • segredos;

  • comunicação entre serviços;

  • privilégio mínimo.

Autenticação

Responde:

Quem é você?

Autorização

Responde:

O que você pode fazer?

Uma pessoa autenticada não deve automaticamente poder:

  • alterar limites;

  • consultar qualquer conta;

  • cancelar transferências;

  • acessar dados administrativos.

Identidade entre serviços

Serviços também precisam se identificar.

Podem usar:

  • certificados;

  • mTLS;

  • tokens;

  • contas de serviço;

  • scopes;

  • políticas de rede.

Gestão de segredos

Nunca devemos guardar senhas e tokens:

  • no código;

  • em repositórios;

  • em imagens de container;

  • em logs;

  • em arquivos abertos;

  • em variáveis sem proteção.

No universo mainframe, isso se relaciona com:

  • RACF;

  • SAF;

  • perfis;

  • certificados;

  • keystores;

  • controle de datasets;

  • privilégio mínimo.

Regra do templo

O serviço de notificações não precisa atualizar conta bancária.

O serviço de catálogo não precisa consultar cartão.

O serviço de entrega não precisa acessar dados de fraude.

Cada serviço deve possuir apenas os acessos necessários.


12. Automação de deployment

O décimo passo é automatizar a entrega.

Microsserviços aumentam o número de componentes.

Sem automação, cada deployment vira uma cerimônia.

Imagine cinquenta serviços exigindo:

  • cópia manual;

  • mudança de parâmetro;

  • abertura de chamado;

  • autorização;

  • teste manual;

  • atualização de planilha;

  • conferência por e-mail;

  • reunião de aprovação.

A empresa não criou agilidade.

Criou cinquenta pequenas repartições públicas digitais.

Pipeline típico

Commit
  ↓
Build
  ↓
Teste unitário
  ↓
Análise de qualidade
  ↓
Análise de segurança
  ↓
Teste de contrato
  ↓
Empacotamento
  ↓
Homologação
  ↓
Teste integrado
  ↓
Produção
  ↓
Verificação

Deployment independente

Um serviço deve poder ser implantado sem exigir publicação simultânea de todos os outros.

Se cinco serviços sempre precisam mudar juntos, o acoplamento continua forte.

Eles apenas moram em apartamentos diferentes, mas ainda compartilham o mesmo banheiro.

Estratégias

Rolling

Substitui instâncias gradualmente.

Blue-green

Mantém dois ambientes:

Blue: versão atual
Green: nova versão

Depois da validação, o tráfego muda.

Canary

Uma pequena parcela recebe a nova versão.

5% nova
95% antiga

Se tudo estiver bem, a nova versão avança.

Banco de dados e rollback

Código pode voltar rapidamente.

Banco de dados nem sempre.

Por isso, mudanças de schema devem acontecer em etapas.

Um padrão útil é:

  1. adicionar nova estrutura;

  2. manter compatibilidade;

  3. atualizar aplicações;

  4. migrar dados;

  5. remover estrutura antiga posteriormente.

Esse padrão é conhecido como expand and contract.


13. Microsserviços e COBOL podem viver juntos

Uma das maiores confusões é pensar que microsserviços exigem substituir COBOL.

Não exigem.

Um programa COBOL pode ser exposto ou integrado por:

  • CICS;

  • IMS;

  • IBM MQ;

  • z/OS Connect;

  • APIs REST;

  • eventos;

  • Kafka;

  • adaptadores;

  • pipelines CI/CD;

  • OpenAPI.

Uma transação CICS bem definida pode funcionar como serviço empresarial.

Ela pode possuir:

  • entrada conhecida;

  • saída conhecida;

  • regra delimitada;

  • segurança;

  • transação;

  • alta disponibilidade;

  • auditoria;

  • monitoramento.

Em alguns casos, uma transação COBOL possui limites mais claros do que uma aplicação moderna dividida artificialmente em dezenas de containers.

Padrão Strangler Fig

Uma estratégia segura de modernização é envolver o legado e substituir partes gradualmente.

Usuário
   ↓
Camada de APIs
   ↓
Sistema legado + novos serviços

Com o tempo, determinadas capacidades são extraídas.

O tráfego passa gradualmente para os novos componentes.

Não é necessário desligar o mainframe em uma sexta-feira às 18h e esperar que tudo funcione na segunda-feira.

Essa estratégia normalmente termina com:

  • pizza fria;

  • executivos nervosos;

  • consultores desaparecidos;

  • e um programa COBOL sendo religado às três da manhã.


14. Passo a passo para um projeto real

O jovem aprendiz perguntou:

— Mestre, como começo sem transformar a empresa em um laboratório de caos?

O mestre respondeu:

Passo 1 — Mapear o negócio

Liste processos reais:

  • pedidos;

  • pagamentos;

  • cadastro;

  • faturamento;

  • entrega;

  • atendimento.

Não comece pelas tabelas ou programas.

Passo 2 — Descobrir responsabilidades

Para cada processo, determine:

  • quem decide?

  • quem possui as regras?

  • quem altera?

  • quem utiliza os dados?

  • quem responde pela operação?

Passo 3 — Mapear sistemas atuais

Identifique:

  • programas COBOL;

  • transações CICS;

  • jobs;

  • tabelas Db2;

  • arquivos VSAM;

  • filas MQ;

  • interfaces;

  • dependências.

Passo 4 — Escolher uma capacidade pequena, mas relevante

Evite começar pelo processo mais crítico da empresa.

Escolha algo:

  • com limites claros;

  • risco controlado;

  • valor perceptível;

  • poucas dependências.

Passo 5 — Criar contrato

Defina:

  • API;

  • mensagens;

  • erros;

  • autenticação;

  • versionamento;

  • idempotência.

Passo 6 — Definir propriedade dos dados

Determine:

  • quais dados pertencem ao serviço;

  • como serão migrados;

  • como outros consumidores terão acesso;

  • como evitar atualizações diretas.

Passo 7 — Planejar falhas

Pergunte:

  • o que acontece se o serviço parar?

  • o que acontece se a mensagem duplicar?

  • o que acontece se a resposta atrasar?

  • como reprocessar?

  • como compensar?

  • como recuperar?

Passo 8 — Instrumentar

Inclua desde o início:

  • logs estruturados;

  • métricas;

  • traces;

  • alertas;

  • correlation ID.

Passo 9 — Automatizar

Crie pipeline de:

  • build;

  • teste;

  • segurança;

  • deployment;

  • rollback;

  • validação.

Passo 10 — Medir resultados

Verifique se realmente melhorou:

  • tempo de entrega;

  • frequência de deployment;

  • número de falhas;

  • tempo de recuperação;

  • acoplamento;

  • satisfação da equipe;

  • custo operacional.

Não aceite sucesso apenas porque o diagrama ficou bonito.


15. Sinais de que o caminho está errado

Observe os seguintes sintomas:

Todos os serviços são implantados juntos

Isso indica dependência excessiva.

Todos usam o mesmo banco

A independência pode ser apenas visual.

Uma operação simples chama dezenas de serviços

A granularidade provavelmente está pequena demais.

Ninguém sabe quem é o responsável

Serviço sem dono vira ruína digital.

Qualquer mudança quebra consumidores

O contrato está instável.

Há retries sem limite

Uma pequena falha pode virar tempestade.

Não existe correlation ID

O suporte trabalhará por adivinhação.

Existem muitos serviços e poucas equipes

A operação ficará abandonada.

Kubernetes foi instalado antes de compreender o domínio

O projeto começou pelo telhado.


16. Quando não usar microsserviços

O aprendiz esperava uma defesa absoluta.

Mas o mestre surpreendeu:

— Nem todo sistema precisa de microsserviços.

Um monólito modular pode ser melhor quando:

  • a equipe é pequena;

  • o produto está começando;

  • o domínio ainda não é conhecido;

  • a infraestrutura é limitada;

  • o volume é moderado;

  • todas as partes mudam juntas;

  • não existe maturidade operacional.

Um monólito modular oferece:

  • transações locais;

  • debugging mais simples;

  • menor custo;

  • testes mais diretos;

  • menos falhas de rede;

  • deployment único;

  • operação centralizada.

O problema não é o monólito.

O problema é o monólito desorganizado.

Da mesma forma, o mérito não está nos microsserviços.

O mérito está nos serviços bem delimitados.

Um monólito bem construído pode ser elegante.

Um conjunto de microsserviços mal construído pode parecer uma cidade em que cada cômodo da casa possui prefeitura, alfândega e controle de passaporte.


17. Curiosidades e easter eggs do templo

Easter egg 1 — “Novo” nem sempre é novo

Mensageria, transações, isolamento, filas e processamento distribuído existem há décadas em ambientes corporativos.

O vocabulário mudou.

Os problemas continuam reconhecíveis.

Easter egg 2 — O mainframe já conhecia resiliência

CICS, IMS, MQ, RACF, WLM, sysplex e outros componentes foram construídos para:

  • disponibilidade;

  • segurança;

  • recuperação;

  • gerenciamento de carga;

  • integridade transacional.

O microsserviço moderno não inventou a necessidade de sobrevivência em produção.

Easter egg 3 — O verdadeiro monólito distribuído

Quando todos os serviços:

  • compartilham banco;

  • mudam juntos;

  • dependem uns dos outros;

  • falham em cadeia;

  • pertencem à mesma equipe;

temos um monólito distribuído.

Ele possui todas as dificuldades do monólito e todas as dificuldades da rede.

Uma obra-prima do sofrimento híbrido.

Easter egg 4 — A lei do café

Quanto maior a cadeia de serviços, maior a probabilidade de o operador precisar preparar café antes de terminar o trace.

Essa lei ainda aguarda validação acadêmica, mas já foi confirmada empiricamente em milhares de data centers.


Conclusão — A lição do pequeno gafanhoto

O jovem programador fechou o diagrama.

Agora compreendia que microsserviços não eram apenas caixas coloridas conectadas por flechas.

Eles exigiam decisões profundas sobre:

  • negócio;

  • limites;

  • responsabilidade;

  • dados;

  • comunicação;

  • falhas;

  • segurança;

  • observabilidade;

  • deployment;

  • equipes.

O mestre Bellacosa levantou-se e caminhou até o mainframe.

— Pequeno gafanhoto — disse ele — o objetivo não é criar mais serviços.

— Então qual é o objetivo, mestre?

— Criar partes do sistema que possam compreender sua própria missão, carregar seus próprios dados, falar claramente com as demais e sobreviver quando o mundo ao redor estiver falhando.

O jovem refletiu.

— E como saberei se projetei corretamente?

O mestre apontou para o terminal.

— Quando uma equipe puder modificar uma capacidade, testá-la, implantá-la e recuperá-la sem convocar cinquenta pessoas para uma reunião de emergência, você estará próximo do caminho.

— E se eu dividir tudo em serviços pequenos?

— Você terá muitos serviços pequenos.

— E isso não é microsserviço?

— Não necessariamente.

— E se eu usar containers?

— Terá containers.

— Kubernetes?

— Terá Kubernetes.

— APIs?

— Terá APIs.

— Cloud?

— Terá uma fatura mensal muito interessante.

O aprendiz finalmente sorriu.

Na tela, o sistema registrou:

MICROSERVICE DESIGN TRAINING
STATUS: COMPLETED
RETURN CODE: 0000

Mas antes que ele comemorasse, surgiu uma segunda mensagem:

WARNING:
PRODUCTION IS A DISTRIBUTED SYSTEM.
EXPECT THE UNEXPECTED.

O mestre terminou o café.

O jovem observou as luzes do data center.

E, em algum lugar entre uma transação CICS, uma fila MQ, uma API REST e um container perdido no cluster, ele finalmente compreendeu:

Uma boa arquitetura de microsserviços não nasce quando dividimos o sistema em pedaços. Ela nasce quando compreendemos quais pedaços realmente possuem motivo para existir de forma independente.

E esse, caro Padawan do COBOL, é o primeiro golpe da antiga arte de projetar sistemas distribuídos sem transformar a produção em um episódio perdido de Kung Fu, dirigido por um arquiteto, revisado por um monge e patrocinado pelo departamento de incidentes críticos.

terça-feira, 10 de janeiro de 2017

🎼 Leitmotif : Quando um Programador COBOL Descobre que John Williams Também Programava... Só que em Notas Musicais

 

Bellacosa Mainframe apresenta o leitmotif usado para criar trilhas sonoras ost soundtracks

🎼 Leitmotif sem Mistérios

Quando um Programador COBOL Descobre que John Williams Também Programava... Só que em Notas Musicais

Existe um momento curioso na vida de qualquer pessoa que ama cinema, anime, séries ou jogos.

Você está andando pela casa.

Talvez preparando um café.

Talvez mexendo em um velho programa COBOL.

Talvez olhando para uma tela verde que parece ter sobrevivido a três gerações de diretores, quatro fusões bancárias e pelo menos dois fins do mundo previstos pela imprensa.

De repente, alguém assobia:

tan tan tan taaaaan...

E, imediatamente, sua mente viaja.

Você não precisa ver o chapéu.

Não precisa ver o chicote.

Não precisa ver a pedra gigante descendo pelo templo.

Você já sabe.

É Indiana Jones.

Outra pessoa faz:

tan tan tan ta-tan ta-tan...

E surge Darth Vader caminhando por um corredor, acompanhado por soldados imperiais, oficiais nervosos e algum técnico da Estrela da Morte tentando descobrir quem autorizou aquela mudança diretamente em produção.

Como poucas notas conseguem fazer isso?

Como uma sequência tão pequena consegue carregar um personagem, uma história, um universo inteiro?

A resposta está em uma das ferramentas mais poderosas da composição musical:

O leitmotif


O que é um leitmotif?

Leitmotif é uma pequena ideia musical associada a algo específico.

Pode representar:

  • um personagem;

  • um lugar;

  • uma emoção;

  • um objeto;

  • uma ameaça;

  • uma lembrança;

  • um povo;

  • um destino;

  • uma ideia abstrata.

Ele pode ter apenas algumas notas.

Às vezes quatro.

Às vezes três.

Às vezes uma pequena sequência rítmica.

Mas, quando bem construído, funciona como uma assinatura.

Você ouve e reconhece.

É quase um identificador musical.

No mundo do mainframe, poderíamos dizer que o leitmotif é o PROGRAM-ID da emoção.

Ele informa ao cérebro:

“Atenção. Este tema pertence a este personagem.”

Mesmo quando o personagem ainda não apareceu.

Mesmo quando aparece apenas sua sombra.

Mesmo quando alguém menciona seu nome.

Mesmo quando a história quer sugerir que sua presença ainda está viva.


Antes de John Williams, veio Wagner

Embora muita gente associe leitmotifs a filmes como Star Wars, Indiana Jones ou Harry Potter, a ideia é muito mais antiga.

Richard Wagner utilizou extensivamente essa técnica em suas óperas.

Ele criou temas associados a:

  • personagens;

  • espadas;

  • maldições;

  • deuses;

  • famílias;

  • destinos;

  • objetos mágicos.

A música não estava apenas acompanhando a história.

Ela estava comentando a história.

Ela revelava relações escondidas.

Antecipava tragédias.

Ligava personagens.

Recordava eventos anteriores.

Era quase um banco de dados emocional.

Cada motivo funcionava como uma chave.

Quando surgia, acionava uma série de associações na mente do público.

John Williams, décadas depois, levou essa lógica para o cinema popular.

E fez isso com tanta eficiência que milhares de pessoas passaram a reconhecer personagens apenas por algumas notas.


Leitmotif não é apenas uma melodia bonita

Aqui começa o primeiro erro dos iniciantes.

Muita gente imagina que um leitmotif precisa ser uma música completa.

Não precisa.

Na verdade, ele funciona melhor quando é pequeno.

Um leitmotif eficiente pode ser composto por:

  • poucas notas;

  • um ritmo marcante;

  • um intervalo incomum;

  • uma direção melódica clara;

  • uma pausa memorável.

Ele não precisa contar toda a história.

Precisa apenas carregar o DNA dela.

Imagine um programa COBOL gigantesco.

Milhares de linhas.

Dezenas de arquivos.

Centenas de parágrafos.

Mas tudo começa com algumas definições fundamentais.

O leitmotif é isso.

É o COPYBOOK emocional da trilha.


O cérebro ama padrões

Nosso cérebro foi construído para reconhecer padrões.

Reconhecemos rostos.

Vozes.

Passos.

Cheiros.

Ritmos.

Sons.

É por isso que uma criança consegue reconhecer uma música antes mesmo de saber explicar o que é uma nota.

Ela não pensa:

“Isto é uma sequência ascendente com determinado intervalo.”

Ela pensa:

“Eu conheço isso.”

O leitmotif funciona exatamente nesse nível.

Ele contorna a análise racional.

Vai direto para a memória.

É quase um acesso indexado.

Sem necessidade de varredura completa.

Um verdadeiro VSAM musical.


Indiana Jones e o chamado da aventura

O tema de Indiana Jones é um exemplo perfeito.

Ele possui energia.

Movimento.

Heroísmo.

Certo exagero.

Certa alegria.

Não é apenas uma música de ação.

É uma música que diz:

“Levante. Existe uma aventura esperando.”

O tema poderia facilmente ser apenas triunfal.

Mas ele possui algo a mais.

Ele parece avançar.

Parece caminhar.

Parece saltar.

Parece tropeçar, recuperar o chapéu e continuar correndo.

Esse é um detalhe importante.

Um bom leitmotif não representa apenas quem o personagem é.

Ele representa como ele se move pelo mundo.

Indiana Jones não é um herói imóvel.

Ele corre.

Erra.

Apanha.

Escapa.

Improvisa.

Por isso seu tema não soa como uma estátua.

Soa como uma perseguição.


Darth Vader e o peso do sistema

A Marcha Imperial possui outra lógica.

Ela é pesada.

Regular.

Militar.

Autoritária.

Os acordes parecem blocos.

As notas não pedem licença.

Elas entram.

O ritmo lembra uma tropa avançando.

A música diz:

“A estrutura chegou.”

Não é apenas Darth Vader.

É o Império.

É a máquina.

É o poder burocrático, militar e tecnológico esmagando tudo pela frente.

No Bellacosa Mainframe, seria o equivalente a ouvir o som de um job crítico entrando na fila com prioridade absoluta, consumindo CPU, memória e a esperança de todos os demais usuários.

O leitmotif de Vader não acompanha apenas o personagem.

Ele anuncia o impacto de sua presença.


Tubarão: quando duas notas bastam

Talvez um dos exemplos mais impressionantes seja o tema de Tubarão.

Duas notas.

Apenas duas.

Repetidas.

Lentas.

Depois mais rápidas.

Mais próximas.

Mais intensas.

Isso mostra algo fundamental:

O poder de um motivo não depende de quantidade.

Depende de contexto.

Depende de repetição.

Depende de expectativa.

Depende do que a história ensinou o público a sentir quando aquela sequência aparece.

Depois de algum tempo, você nem precisa ver o tubarão.

As notas já bastam.

O som se transforma na criatura.

É como um código de erro.

Você vê o número e já sabe que algo ruim aconteceu.


Era Uma Vez no Oeste e o assobio que atravessa o deserto

Ennio Morricone entendia que identidade musical não nasce apenas de melodias.

Nasce também do timbre.

Um assobio pode ser um personagem.

Uma harmônica pode ser um passado.

Uma guitarra pode ser um duelo.

Uma voz sem palavras pode ser uma paisagem inteira.

Em Era Uma Vez no Oeste, a música não apenas acompanha o cenário.

Ela cria o espaço.

Você sente o calor.

A poeira.

A distância.

A espera.

O silêncio.

Morricone compreendia uma verdade poderosa:

O instrumento escolhido também conta a história.

A mesma melodia tocada em um piano infantil, uma tuba, uma harmônica ou um coral terá significados completamente diferentes.

O código pode ser o mesmo.

Mas o ambiente de execução muda tudo.


Leitmotif é como uma sub-rotina

Agora entramos na parte que qualquer programador COBOL reconhece imediatamente.

Imagine que você tem uma pequena rotina:

PERFORM TEMA-DO-HEROI.

Ela pode ser chamada em vários momentos.

Na primeira vez, o herói está começando sua jornada.

Então o tema aparece fraco.

Talvez em uma flauta.

Talvez incompleto.

Depois o herói vence sua primeira batalha.

O mesmo tema retorna.

Agora com cordas.

Mais tarde, ele perde alguém importante.

O tema aparece lento.

Em tom menor.

Quase destruído.

No final, quando finalmente aceita seu destino, a mesma melodia surge completa.

Com orquestra.

Metais.

Percussão.

Coral.

O tema não mudou de identidade.

Mudou de estado.

Exatamente como um programa que recebe novos parâmetros.


A mesma melodia pode viver muitas vidas

Um dos maiores segredos dos grandes compositores é não criar uma música diferente para cada cena.

Eles criam uma identidade e depois a transformam.

Um leitmotif pode aparecer:

  • rápido;

  • lento;

  • alegre;

  • triste;

  • sombrio;

  • infantil;

  • heroico;

  • ameaçador;

  • incompleto;

  • invertido;

  • escondido no baixo;

  • tocado por um único instrumento;

  • executado por uma orquestra inteira.

Essa transformação acompanha a narrativa.

O público talvez nem perceba conscientemente.

Mas sente.

Quando um tema conhecido aparece de maneira diferente, o cérebro entende:

“Algo mudou.”

Essa é uma das formas mais sofisticadas de contar histórias sem palavras.


O motivo pode contar o que o personagem não diz

Imagine um personagem sorrindo.

Ele parece feliz.

Mas, ao fundo, surge uma versão triste de seu tema.

A música informa que o sorriso é falso.

Agora imagine um vilão falando calmamente.

Nada visualmente indica perigo.

Mas uma pequena parte de seu motivo aparece nos graves.

O público entende que algo está errado.

O leitmotif pode revelar:

  • medo escondido;

  • amor não declarado;

  • culpa;

  • conexão entre personagens;

  • destino inevitável;

  • lembrança reprimida;

  • ameaça futura.

Ele é uma espécie de comentário secreto da narrativa.

Quase como um log do sistema.

O usuário vê uma tela tranquila.

Mas o log já registrou que o desastre começou.


Não confunda leitmotif com trilha de fundo

Uma trilha de fundo pode apenas criar clima.

Tristeza.

Suspense.

Ação.

Romance.

O leitmotif possui identidade.

Ele está ligado a algo específico.

Por exemplo:

Uma música triste genérica pode tocar durante uma despedida.

Mas, se aquela música contém o tema do personagem que morreu, ela ganha outro significado.

Ela não representa apenas tristeza.

Representa aquela pessoa.

A memória dela.

Sua ausência.

Sua presença invisível.

É aí que a trilha deixa de ser decoração.

E passa a ser narrativa.


Como criar um leitmotif do zero

Agora vem a parte prática.

Você não precisa começar escrevendo uma sinfonia.

Comece como um programador começaria.

Com uma definição simples.


Etapa 1 — Defina o objeto musical

Pergunte:

O que esse tema representa?

Pode ser:

  • um herói;

  • uma cidade;

  • uma ameaça;

  • uma máquina;

  • uma lembrança;

  • uma guilda;

  • um sistema antigo;

  • uma jornada.

Não tente representar tudo ao mesmo tempo.

Um tema sobre coragem, medo, saudade, raiva, amor, tecnologia, guerra e café provavelmente não representará nada com clareza.

Escolha um núcleo.


Etapa 2 — Defina três palavras

Descreva o tema com três palavras.

Exemplo:

Herói veterano

  • cansado;

  • digno;

  • persistente.

Vilão tecnológico

  • frio;

  • preciso;

  • inevitável.

Cidade antiga

  • misteriosa;

  • grandiosa;

  • decadente.

Essas palavras orientarão:

  • ritmo;

  • velocidade;

  • instrumento;

  • direção melódica;

  • intensidade.


Etapa 3 — Escolha um ritmo

Antes das notas, bata o ritmo na mesa.

Faça algo simples:

TAN — TAN TAN — TAAAAAN

Ou:

TAN TAN TAN — pausa — TAN

O ritmo muitas vezes é mais memorável do que as próprias notas.

Você pode trocar todas as notas e ainda reconhecer um tema pelo ritmo.

É como a estrutura de um registro.

Os valores mudam.

O layout permanece.


Etapa 4 — Use poucas notas

Comece com três a cinco notas.

Não tente criar vinte.

Exemplo:

Dó — Mi — Sol — Fá

Toque.

Repita.

Depois altere uma nota.

Dó — Mi — Sol — Lá

Compare.

Agora mude o ritmo.

Depois faça a sequência descer.

Sol — Mi — Ré — Dó

A partir dessas pequenas experiências, algo começa a ganhar personalidade.


Etapa 5 — Crie uma surpresa

Uma melodia memorável geralmente possui algo esperado e algo inesperado.

Você repete duas notas.

Depois salta.

Ou sobe.

Depois cai.

Ou faz uma pausa onde o ouvinte esperava continuidade.

Essa pequena quebra é a assinatura.

Sem surpresa, o tema pode soar correto.

Mas genérico.

O cérebro gosta de padrões.

Mas lembra das irregularidades.


Etapa 6 — Escolha o timbre

Agora pergunte:

Quem toca esse tema?

Se for um aventureiro:

  • trompa;

  • cordas;

  • percussão.

Se for uma lembrança:

  • piano;

  • flauta;

  • caixa de música.

Se for um vilão:

  • metais graves;

  • sintetizador;

  • coral;

  • contrabaixo.

Se for um mundo antigo:

  • instrumentos acústicos;

  • vozes;

  • sons ambientais;

  • percussão ritual.

O timbre é como o ambiente do mainframe.

O mesmo programa executado em contextos diferentes pode produzir experiências completamente distintas.


Um exemplo Bellacosa Mainframe

Vamos imaginar um personagem:

Um velho programador entra sozinho no data center durante a madrugada para corrigir o último erro antes da aposentadoria.

Três palavras:

  • solitário;

  • experiente;

  • determinado.

Ritmo:

TAN — TAN — TAN TAN — TAAAAAN

Notas possíveis:

Ré — Fá — Mi — Lá — Ré

Instrumento inicial:

Piano elétrico.

Depois:

Cordas graves.

No final:

Metais e coral.

A primeira versão poderia representar o cansaço.

A segunda, o perigo.

A terceira, a vitória.

A quarta, a despedida.

O mesmo motivo.

Quatro estados.

Uma narrativa inteira.


A importância do silêncio

Morricone entendia isso.

John Williams também.

Joe Hisaishi também.

Yoko Kanno também.

Silêncio não é ausência de música.

É espaço.

É expectativa.

É contraste.

Um motivo tocado após cinco segundos de silêncio pode ter muito mais força do que uma orquestra tocando sem parar.

Na engenharia de sistemas, ninguém presta atenção em um alarme que soa o tempo inteiro.

Mas um único alerta no meio do silêncio...

Esse muda tudo.


Leitmotif nos animes

Os animes utilizam essa técnica de maneira brilhante.

Em Attack on Titan, determinados temas carregam guerra, destino, liberdade e tragédia.

Em Made in Abyss, melodias reaparecem alteradas, lembrando que o fascínio e o horror pertencem ao mesmo mundo.

Em Frieren, temas suaves ajudam a transformar tempo, memória e saudade em algo quase físico.

Em filmes do Studio Ghibli, Joe Hisaishi cria melodias simples que parecem ter existido desde sempre.

Em jogos como Final Fantasy, Nobuo Uematsu construiu identidades musicais que continuam vivas décadas depois.

Esses compositores não escrevem apenas música.

Eles escrevem memória.


O erro do excesso

Um iniciante frequentemente acredita que complexidade gera qualidade.

Então adiciona:

  • muitas notas;

  • muitos acordes;

  • muitos instrumentos;

  • muitas mudanças;

  • muitos efeitos.

O resultado pode impressionar tecnicamente.

Mas não grudar.

Um bom leitmotif precisa sobreviver sem produção.

Se você consegue assobiá-lo...

Ele funciona.

Se precisa de oitenta instrumentos, vinte camadas e um manual técnico para ser reconhecido...

Talvez ainda não esteja pronto.


O teste do assobio

Esse é um dos testes mais simples e cruéis.

Assobie seu tema.

Sem acompanhamento.

Sem bateria.

Sem efeitos.

Sem orquestra.

Ele ainda tem identidade?

Você consegue repeti-lo?

Alguém consegue lembrar depois?

Se sim, existe uma boa base.

Se não, continue reduzindo.

Muitas vezes, a força surge quando você remove.

Não quando adiciona.


A música como engenharia emocional

Essa é talvez a maior ligação entre composição e programação.

Ambas trabalham com:

  • padrões;

  • repetição;

  • variação;

  • estrutura;

  • modularidade;

  • expectativa;

  • dependência;

  • reutilização.

Um tema musical bem escrito é quase um módulo.

Pode ser chamado.

Alterado.

Executado em outro contexto.

Combinado com outros temas.

Invertido.

Fragmentado.

Expandido.

Mas continua reconhecível.

O grande compositor não joga notas aleatórias.

Ele projeta relações.


Quando dois leitmotifs se encontram

Existe ainda uma técnica maravilhosa.

Misturar dois temas.

Imagine um herói e um vilão.

Cada um possui seu leitmotif.

Durante a batalha final, os dois aparecem simultaneamente.

Um nas cordas.

Outro nos metais.

Eles brigam musicalmente.

Depois um domina.

Ou os dois se fundem.

Isso pode simbolizar:

  • confronto;

  • união;

  • parentesco;

  • transformação;

  • corrupção;

  • reconciliação.

É quase um MERGE musical.

Dois arquivos.

Duas identidades.

Uma nova saída.


O leitmotif também pode falhar

Assim como qualquer projeto, ele pode sofrer problemas.

Motivo genérico

Parece com centenas de outros.

Motivo longo demais

Difícil de memorizar.

Falta de repetição

O público não aprende a reconhecê-lo.

Excesso de repetição

Perde impacto.

Instrumentação incoerente

O som não combina com a identidade.

Transformação excessiva

Muda tanto que deixa de ser reconhecível.

É preciso equilíbrio.

O motivo precisa evoluir sem perder o nome.

Como um sistema legado modernizado corretamente.


A lição de John Williams

John Williams não criou apenas músicas memoráveis.

Ele entendeu algo fundamental:

O público precisa de âncoras.

Em mundos gigantescos, cheios de personagens, planetas, batalhas e conflitos, a música ajuda a organizar a experiência.

Ela diz:

  • quem chegou;

  • o que está ameaçado;

  • o que foi perdido;

  • o que está retornando;

  • o que ainda vive.

É uma espécie de mapa emocional.

Sem ele, muitas cenas ainda funcionariam.

Mas perderiam profundidade.


A lição de Morricone

Morricone mostrou que não é preciso obedecer às regras tradicionais.

Uma trilha pode usar:

  • assobios;

  • chicotes;

  • sinos;

  • respiração;

  • gritos;

  • ruídos;

  • instrumentos incomuns.

Ele tratava som como matéria-prima.

Isso é importante.

Você não precisa começar com uma orquestra.

Pode começar com um ruído.

Uma porta.

Uma máquina.

Um apito.

Uma tecla.

Um ventilador.

Um terminal.

Talvez o próximo grande leitmotif de um programador COBOL comece com o som de uma impressora matricial.


Conclusão: o COPYBOOK da memória

Um leitmotif é pequeno.

Mas carrega muito.

Poucas notas.

Uma identidade.

Uma emoção.

Uma promessa.

Ele pode atravessar filmes, temporadas, décadas e gerações.

Pode ser tocado por uma orquestra.

Assobiado por uma criança.

Executado em um piano.

Reproduzido em um celular.

E continuará sendo reconhecido.

Essa é sua força.

No Bellacosa Mainframe, poderíamos defini-lo assim:

IDENTIFICATION DIVISION.
PROGRAM-ID. LEITMOTIF.

DATA DIVISION.
WORKING-STORAGE SECTION.

01 EMOCAO.
   05 PERSONAGEM PIC X(20).
   05 MEMORIA    PIC X(20).
   05 DESTINO    PIC X(20).

PROCEDURE DIVISION.

    PERFORM CRIAR-POUCAS-NOTAS
    PERFORM REPETIR-COM-PROPOSITO
    PERFORM VARIAR-SEM-PERDER-IDENTIDADE
    PERFORM GRAVAR-NA-MEMORIA

    STOP RUN.

John Williams talvez nunca tenha escrito COBOL.

Mas compreendia perfeitamente:

  • reutilização;

  • modularidade;

  • padrões;

  • chamadas;

  • variações;

  • identidade;

  • processamento emocional.

Ele programava.

Só que em vez de registros...

Usava notas.

Em vez de arquivos...

Usava memória.

Em vez de JCL...

Usava orquestra.

E em vez de gerar relatórios...

Gerava arrepios.


Aqui está um bloco completo em **HTML + CSS + JavaScript**, pronto para colar em uma página ou postagem do **Blogspot**, com visual inspirado em trilhas sonoras de anime, previews por iframe, resumos, botões externos e links fixos rastreáveis por Google e Bing. ```html
🎼
UM CAFÉ NO BELLACOSA MAINFRAME

Anime Soundtrack Mainframe

Uma viagem pelo código-fonte invisível das trilhas sonoras, dos leitmotifs e das melodias que continuam executando na memória muito depois dos créditos finais.

JOB SOUNDTRACK-HUB EXECUTANDO — RC=0000
TRACK 01
🎼

Leitmotif sem Mistérios

Quando um Programador COBOL Descobre que John Williams Também Programava... Só que em Notas Musicais

Descubra como pequenas sequências musicais podem representar personagens, lugares, ameaças, lembranças e destinos. Um mergulho no leitmotif como COPYBOOK emocional do cinema, dos animes e dos games.

Carregar preview do artigo O iframe será carregado somente quando solicitado.
Abrir artigo ↗
TRACK 02
🎹

Como Criar seu Primeiro Leitmotif

Quando um Tema Inesquecível Cabe em Menos Espaço que um Copybook

Um tutorial prático para criar um motivo musical usando apenas quatro notas. Aprenda a trabalhar ritmo, repetição, timbre, variação, personagem e emoção como módulos reutilizáveis de um sistema musical.

Carregar preview do artigo O iframe será carregado somente quando solicitado.
Abrir artigo ↗
TRACK 03
🧠

Os 10 Segredos de uma Melodia Inesquecível

Quando o Cérebro Também Possui Cache e Alguns Temas Nunca Sofrem RESET

Ritmo, repetição, intervalos, pausas, surpresa, expectativa e resolução. Conheça os mecanismos que fazem temas de filmes, animes e jogos permanecerem residentes no cache emocional durante décadas.

Carregar preview do artigo O iframe será carregado somente quando solicitado.
Abrir artigo ↗
TRACK 04
🎧

O Código-Fonte Invisível dos Animes

Quando as Trilhas Sonoras Também Executam Jobs em Segundo Plano

Uma análise sobre como leitmotifs, instrumentação, silêncio e repetição conduzem personagens, memórias, batalhas, perdas e revelações dentro das trilhas sonoras dos animes.

Carregar preview do artigo O iframe será carregado somente quando solicitado.
Abrir artigo ↗
TRACK 05
💿

Acervo e Coletânea de Trilhas Sonoras

Descubra Onde Pesquisar, Ouvir e Estudar Anime Soundtracks

Um ponto de partida para localizar álbuns, compositores, coleções, bancos de dados, comunidades e referências ligadas às trilhas sonoras de animes, filmes, jogos e produções japonesas.

Carregar preview do artigo O iframe será carregado somente quando solicitado.
Abrir artigo ↗
🎵 ROTEIRO + 🎞️ ANIMAÇÃO + 🎼 TRILHA SONORA = ❤️ MEMÓRIA
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...