 |
| Bellacosa Mainframe apresenta microservices |
☕ Um Café no Bellacosa Mainframe
🧠 Microservices sob a Batuta de Chris Knight — Real Genius, Arquitetura e a Arte de Não Construir um Laser para Aquecer Pipoca
Quando todo mundo está fascinado pela tecnologia, talvez o verdadeiro gênio seja justamente aquele que pergunta: “Legal... mas por que estamos construindo isso?”
Existe uma cena mental perfeita para explicar boa parte da arquitetura de software moderna.
Imagine uma sala cheia de engenheiros brilhantes. Há diagramas nas paredes, notebooks abertos, APIs sendo desenhadas, Kubernetes em algum canto, Kafka atravessando o desenho, containers surgindo aos montes e alguém acaba de pronunciar palavras capazes de provocar arrepios em qualquer apresentação corporativa:
“Precisamos migrar para microservices.”
Todos concordam.
Alguém acrescenta:
— E microfrontends.
Outro melhora:
— Event-driven!
Do fundo da sala:
— Service mesh!
Então aparece Chris Knight, de Real Genius, observa o quadro por alguns segundos e provavelmente pergunta:
“Tá... qual problema vocês estão tentando resolver?”
Silêncio.
E é justamente aí que começa nossa conversa.
Porque transformar um desenvolvedor em arquiteto não significa ensiná-lo a colocar mais tecnologias dentro de um desenho.
Significa ensiná-lo a questionar o desenho.
Para um programador COBOL começando a olhar para arquitetura moderna, existe uma excelente notícia: você provavelmente já conhece vários dos princípios fundamentais. Talvez apenas os conheça por outros nomes.
Pegue seu café.
Hoje vamos entrar no laboratório de Chris Knight.
E alguém, por favor, esconda a pipoca.
🎬 1. Primeiro precisamos falar sobre Real Genius
Real Genius, lançado em 1985, acompanha estudantes extremamente talentosos envolvidos em um projeto científico universitário. Chris Knight, interpretado por Val Kilmer, é um daqueles personagens que parecem estar permanentemente brincando enquanto enxergam coisas que outras pessoas não percebem.
E isso combina maravilhosamente com arquitetura.
O estereótipo do arquiteto costuma ser alguém extremamente sério diante de um enorme diagrama.
Chris Knight representa quase o contrário.
Ele domina a tecnologia, mas não é hipnotizado por ela.
Essa distinção é fundamental.
Existe uma diferença enorme entre:
saber construir algo
e
saber se aquilo deveria ser construído.
Na arquitetura corporativa encontramos frequentemente pessoas extremamente competentes resolvendo brilhantemente problemas que talvez nem precisassem existir.
Microservices são um excelente exemplo.
🧱 2. “Monólito” não é palavrão
Durante alguns anos, dizer que uma aplicação era monolítica parecia quase uma confissão.
“Nosso sistema ainda é um monólito...”
Pronunciado quase como:
“Temos ratos no datacenter.”
Mas precisamos separar duas coisas:
MONÓLITOe:
MONÓLITO RUIMNão são sinônimos.
Imagine:
SISTEMA DE PEDIDOS
│
├── CLIENTES
├── PRODUTOS
├── PEDIDOS
├── ESTOQUE
├── PAGAMENTOS
└── FATURAMENTOTudo pode existir dentro da mesma aplicação.
Isso não significa necessariamente que temos uma arquitetura ruim.
Podemos possuir módulos claramente definidos, responsabilidades separadas e interfaces controladas.
Temos então aquilo que costuma ser chamado de:
Modular Monolith.
Agora compare com:
SISTEMA
│
├── tudo acessa tudo
├── qualquer módulo altera qualquer tabela
├── regras aparecem duplicadas
├── dependências circulares
└── ninguém sabe quem é dono de quêIsso é ruim.
Mas dividir esse segundo sistema em 50 containers não elimina magicamente seus problemas.
Talvez apenas consigamos transformar:
um monólito ruim
em:
50 pequenos pedaços ruins conversando pela rede.
Chris Knight certamente acharia isso divertido.
O pessoal de produção, provavelmente menos.
🧠 3. COBOL já ensinava modularidade antes de ela ganhar slides coloridos
Vamos colocar nosso programador COBOL iniciante diante disso.
Imagine:
CALL 'CALCJURO'
USING WS-SALDO
WS-TAXA
WS-JUROS.O programa principal não precisa conhecer cada detalhe do cálculo.
Ele conhece uma interface.
Existe entrada.
Existe processamento.
Existe saída.
Isso é uma forma de separação de responsabilidade.
Podemos ter:
PROGRAMA PRINCIPAL
│
├── VALIDCPF
├── CALCJURO
├── CONSULTA
└── GRAVAPGTOIsso não são microservices.
É importante não cair nessa simplificação.
Um subprograma COBOL normalmente não possui várias características associadas a um microservice moderno, como deployment independente, isolamento operacional, endpoint de rede próprio, escalabilidade independente e ownership autônomo.
Mas existe uma ancestralidade conceitual.
Estamos falando de:
modularidade.
coesão.
baixo acoplamento.
contratos.
Esses princípios não nasceram com Docker.
🔬 4. Chris Knight perguntaria onde está a fronteira
Agora imagine que alguém encontre:
PGM001
PGM002
PGM003
...
PGM500e proponha:
“Vamos transformar cada programa COBOL em um microservice.”
Chris Knight provavelmente levantaria a sobrancelha.
Porque programa não é necessariamente domínio de negócio.
Um sistema bancário poderia possuir algo conceitualmente parecido com:
CONTA
├── abrir
├── consultar
├── bloquear
├── movimentar
└── encerrarEssas operações possuem relação.
Talvez façam parte de uma capacidade coerente.
Por outro lado, transformar mecanicamente:
PGM001 → SERVICE001
PGM002 → SERVICE002
PGM003 → SERVICE003não constitui arquitetura.
É conversão de inventário.
Uma boa fronteira deveria tentar responder:
Quem é responsável por esta capacidade?
Quais dados pertencem a ela?
Quem pode modificá-los?
Que contrato oferecemos ao restante do sistema?
Esse raciocínio nos aproxima de conceitos como bounded contexts e Domain-Driven Design.
🚪 5. Então aparece o API Gateway
Nos diagramas modernos frequentemente encontramos:
FRONTEND
│
▼
API GATEWAY
│
┌───────────┼───────────┐
▼ ▼ ▼
PRODUCT BASKET ADVERT
SERVICE SERVICE SERVICEO gateway funciona como uma porta de entrada.
Ele pode participar de tarefas como roteamento, autenticação, autorização, controle de tráfego, transformação e observabilidade.
Isso evita que o consumidor precise conhecer detalhes demais da infraestrutura interna.
Para quem trabalha com mainframe, existe aqui uma conexão importantíssima.
Suponha:
MOBILE
│
▼
REST API
│
▼
API LAYER
│
▼
CICS
│
▼
COBOL
│
▼
Db2O aplicativo móvel não precisa saber que existe COBOL.
Aliás, ele não deveria precisar saber.
Para ele existe:
GET /accounts/123Atrás disso pode existir uma transação CICS construída anos atrás.
Isso nos leva a uma das ideias mais importantes deste artigo:
Modernizar a interface de um sistema não exige necessariamente reescrever seu coração.
⚡ 6. “Mas microservices escalam!”
Sim.
E aqui Chris Knight provavelmente responderia:
“Qual parte precisa escalar?”
Imagine uma loja:
CATÁLOGO
50.000 req/s
PAGAMENTO
2.000 req/s
RELATÓRIOS
200 req/sSe tudo estiver dentro de uma aplicação indivisível, talvez seja necessário escalar todo o conjunto.
Com serviços independentes, podemos ter:
CATÁLOGO
████████████████████
PAGAMENTO
████
RELATÓRIO
█Agora temos uma vantagem concreta.
Não estamos usando microservices porque são modernos.
Estamos usando porque determinadas capacidades possuem características operacionais diferentes.
Esse é pensamento arquitetural.
🌐 7. Só existe um pequeno problema chamado rede
No COBOL podemos ter:
CALL 'VALIDA' USING WS-DADOS.Agora transforme conceitualmente essa interação em:
SERVICE-A
│
│ HTTP
▼
SERVICE-BParece semelhante no PowerPoint.
Na operação, não é.
O Service B pode estar indisponível.
A rede pode estar congestionada.
O DNS pode falhar.
A resposta pode demorar.
A conexão pode cair.
A solicitação pode ser processada e a resposta se perder.
Aí Service A pensa:
“Não recebi resposta. Vou tentar novamente.”
Só que Service B executou a operação.
Parabéns.
Talvez você tenha cobrado o cliente duas vezes.
🔁 8. Bem-vindo ao maravilhoso mundo dos retries
Precisamos começar a pensar em:
timeout
retry
backoff
circuit breaker
idempotency
correlation ID
distributed tracingSuponha:
POST /paymentA chamada chega.
O pagamento é processado.
A resposta desaparece.
O consumidor repete:
POST /paymentO sistema precisa conseguir perceber:
“Eu já processei esta operação.”
Daí surge a importância de idempotência.
Por exemplo:
IDEMPOTENCY-KEY: TX-928374Se a mesma operação chegar novamente, podemos reconhecer que ela já aconteceu.
Observe como algo que parecia simplesmente:
A → Bacabou se tornando uma discussão arquitetural inteira.
Essa é uma das contas escondidas dos sistemas distribuídos.
💾 9. E então chegamos aos dados
Aqui começa a diversão de verdade.
Em um monólito podemos encontrar:
APPLICATION
│
▼
DB2Uma transação pode executar várias operações e depois:
COMMITou:
ROLLBACKÉ uma ideia maravilhosa.
Tudo funcionou?
COMMIT.
Alguma coisa falhou?
ROLLBACK.
Agora distribua:
ORDER SERVICE
│
▼
ORDER DB
PAYMENT SERVICE
│
▼
PAYMENT DB
STOCK SERVICE
│
▼
STOCK DBUma compra precisa:
criar pedido
reservar estoque
autorizar pagamento
emitir nota
solicitar entregaQuem controla a transação?
Agora a resposta pode envolver eventos, mensagens, compensações, Saga Pattern e consistência eventual.
🍿 10. O microservice que virou laser de pipoca
Aqui está nossa metáfora Real Genius.
Imagine que o requisito fosse:
aquecer pipoca.
A primeira equipe sugere:
panelaOutra diz:
micro-ondasEntão o arquiteto extremamente entusiasmado apresenta:
satélite
↓
laser de alta potência
↓
espelho orbital
↓
sistema de coordenadas
↓
pipocaFunciona?
Provavelmente conseguimos inventar uma maneira.
É impressionante?
Sem dúvida.
Era necessário?
Aí está a pergunta.
Em software fazemos exatamente isso.
Requisito:
600 usuários
CRUD
4 desenvolvedores
1 release mensalArquitetura proposta:
37 microservices
Kubernetes
Kafka
service mesh
Redis
API Gateway
15 databases
distributed tracing
GitOps
multi-cloudE alguém precisa perguntar:
“Nós estamos construindo uma aplicação ou tentando ganhar a feira de ciências?”
🕸️ 11. O monólito distribuído
Existe uma criatura particularmente cruel.
Ela possui microservices no diagrama:
A → B → C → D → EMas A não consegue funcionar sem B.
B depende de C.
C depende de D.
Todos compartilham dados.
Precisam ser publicados juntos.
Uma alteração em E exige mudanças em A.
Temos então algo parecido com:
Distributed Monolith.
Conseguimos preservar o acoplamento do monólito e adicionar:
latência
rede
timeouts
deployment
containers
observabilidade
versionamento
falhas distribuídasÉ quase uma obra de arte.
Chris Knight estaria impressionado.
📡 12. Observabilidade deixa de ser luxo
Imagine uma operação:
APP
↓
GATEWAY
↓
ORDER
↓
PAYMENT
↓
BROKER
↓
FRAUD
↓
BANKÀs 03:17, toca o telefone.
Easter egg encontrado. ☕
O cliente foi cobrado, mas o pedido não existe.
Agora precisamos reconstruir a viagem daquela transação.
Precisamos de algo parecido com:
TRACE-ID = ABC938271Esse identificador acompanha a operação:
Gateway ABC938271
Order ABC938271
Payment ABC938271
Fraud ABC938271
Bank ABC938271Finalmente podemos reconstruir a história.
Esse é o valor do distributed tracing.
Em sistemas distribuídos, logs isolados deixam de contar a história completa.
Precisamos correlacioná-los.
🎯 13. Microservices não são principalmente uma decisão tecnológica
Aqui encontramos uma das maiores curiosidades da arquitetura.
Microservices também são uma decisão organizacional.
Imagine uma empresa com 300 desenvolvedores divididos em equipes:
CATALOG TEAM
PAYMENT TEAM
ORDER TEAM
SHIPPING TEAM
CUSTOMER TEAMSe cada equipe puder controlar uma capacidade com ciclo próprio:
code
↓
test
↓
deploy
↓
operatea independência arquitetural pode trazer enorme valor.
Agora imagine quatro desenvolvedores mantendo tudo.
Criar 40 serviços talvez não proporcione autonomia.
Talvez proporcione 40 coisas para quatro pessoas cuidarem.
Arquitetura precisa considerar a organização que vai operá-la.
🧩 14. Microfrontends repetem a experiência
Depois dos microservices alguém percebeu:
“E o frontend?”
Surge então:
Microfrontends.
Podemos ter:
BASE APPLICATION
│
├── PRODUCT
├── BASKET
└── ADVERTEquipes diferentes podem desenvolver partes da experiência.
Em organizações enormes isso pode oferecer independência.
Mas imediatamente surgem novas perguntas.
Quem controla o design?
Quem controla as bibliotecas?
Como evitamos duplicação?
Como mantemos performance?
Como garantimos experiência consistente?
Outra vez:
Todo benefício arquitetural compra alguma complexidade.
A pergunta é se vale o preço.
🤖 15. “Micro/vibe everything” é mais perigoso do que parece
A imagem original contém uma pequena provocação maravilhosa:
Micro/vibe everything.
Em plena era da IA generativa, isso merece atenção.
Hoje podemos pedir:
“Crie 15 microservices para uma plataforma de vendas.”
E minutos depois receber:
/auth
/customer
/product
/order
/payment
/shipping
/inventory
/notification
/recommendation
...Temos Dockerfiles.
APIs.
Testes.
YAML.
Filas.
Bancos.
Tudo parece extraordinariamente profissional.
Só existe uma questão:
Por que 15?
Talvez fossem necessários três.
Talvez oito.
Talvez nenhum.
IA reduziu dramaticamente o custo de produzir código.
Mas isso não reduz automaticamente o custo de:
possuir o código.
Alguém terá que entender, testar, proteger, atualizar, observar e recuperar aquilo.
Esta talvez seja uma das maiores mudanças para o arquiteto moderno:
Quanto mais barato fica criar complexidade, mais valiosa fica a capacidade de recusá-la.
🏛️ 16. O velho mainframe entra no laboratório
Aqui nosso programador COBOL pode sorrir.
Mainframes corporativos carregam décadas de lições sobre:
contratos
compatibilidade
transações
workload
segurança
mensageria
recuperação
disponibilidade
observabilidadeSistemas antigos sobreviveram não porque nunca mudaram.
Sobreviveram justamente porque conseguiram mudar preservando contratos importantes.
Podemos encontrar algo como:
React
↓
REST
↓
API
↓
CICS
↓
COBOL
↓
Db2E isso não deveria provocar vergonha arquitetural.
Talvez seja uma arquitetura excelente.
O frontend pode ser substituído.
A API pode evoluir.
A camada de integração pode mudar.
Enquanto isso, uma rotina COBOL comprovada durante bilhões de transações continua fazendo exatamente aquilo para que foi construída.
Chris Knight provavelmente perguntaria:
“Se funciona, escala, é seguro e atende ao negócio... exatamente por que vocês querem reescrever?”
Excelente pergunta.
🧠 17. O que realmente transforma Engineer em Architect
Não é Kubernetes.
Não é Kafka.
Não é AWS, Azure ou qualquer outra plataforma.
Não é conhecer cinquenta design patterns.
A transformação acontece quando mudamos de:
COMO CONSTRUO?para:
POR QUE CONSTRUIR?
QUAL PROBLEMA?
QUAL ESCALA?
QUAL SLA?
QUAL CUSTO?
COMO FALHA?
COMO RECUPERA?
COMO OBSERVAMOS?
QUEM MANTÉM?
COMO EVOLUI?
QUAL É A ALTERNATIVA MAIS SIMPLES?Um arquiteto não deveria ser simplesmente o profissional capaz de desenhar mais caixas.
Às vezes sua maior contribuição é pegar o desenho:
□ → □ → □ → □ → □
↓
□
↓
□ → □ → □e perguntar:
“Podemos fazer isso com três?”
⚖️ 18. A regra Bellacosa-Chris Knight
Podemos transformar toda esta conversa em uma pequena regra:
Não escolha uma arquitetura porque consegue construí-la. Escolha porque consegue justificar sua existência.
Microservices podem ser extraordinários.
Um modular monolith também.
Event-driven architecture pode resolver problemas difíceis.
Uma chamada síncrona simples também.
Kafka pode ser fantástico.
Uma fila MQ pode continuar sendo exatamente aquilo que o problema exige.
REST pode ser perfeito.
Uma transação CICS pode estar executando sua função impecavelmente há décadas.
O arquiteto não deveria possuir religião tecnológica.
Deveria possuir critérios.
🔬 19. Passo a passo: antes de escolher microservices
Quando alguém disser:
“Precisamos de microservices.”
Faça o exercício Chris Knight.
Primeiro pergunte:
Qual problema atual queremos resolver?Depois:
Precisamos de deployment independente?Depois:
Partes diferentes precisam escalar independentemente?Depois:
Existem boundaries de negócio claros?Depois:
As equipes realmente possuem autonomia?Depois:
Temos CI/CD maduro?Depois:
Temos observabilidade?Depois:
Sabemos operar sistemas distribuídos?Depois:
Como trataremos consistência de dados?Finalmente:
Um modular monolith resolveria?Se ninguém consegue responder à primeira pergunta, não precisamos discutir a décima.
🎓 20. A lição para o programador COBOL iniciante
Se você está começando COBOL e olha para diagramas modernos pensando:
“Meu Deus, preciso aprender tudo isso antes de entender arquitetura.”
Não.
Comece pelos fundamentos.
Entenda profundamente:
dados
interfaces
responsabilidades
transações
dependências
falhas
contratos
estado
recuperaçãoAprenda por que existe:
CALLEntenda por que existe:
COMMITEntenda por que existe:
ROLLBACKEntenda arquivos, Db2, VSAM, CICS e mensageria.
Depois olhe novamente para microservices.
Você começará a reconhecer velhos problemas usando roupas novas.
Naturalmente, sistemas distribuídos trouxeram desafios e soluções próprias. Não devemos fingir que um CALL COBOL e uma chamada HTTP são equivalentes.
Mas ambos obrigam o arquiteto a pensar:
Quem chama quem?
Qual é o contrato?
O que acontece quando falha?
Essas perguntas atravessam gerações tecnológicas.
🍿 Epílogo — alguém trouxe pipoca?
No final, talvez essa seja a melhor contribuição de Chris Knight para nossa imaginária aula de arquitetura.
Tecnologia pode — e deve — ser divertida.
Precisamos experimentar.
Precisamos construir protótipos.
Precisamos estudar microservices, containers, APIs, eventos, IA e tudo aquilo que surgir depois.
Mas devemos conservar uma pequena irreverência diante das modas.
Quando uma apresentação disser:
“Todo mundo está migrando para microservices.”
Pergunte:
Por quê?
Quando disserem:
“Precisamos quebrar o monólito.”
Pergunte:
Onde exatamente ele está nos prejudicando?
Quando disserem:
“Precisamos de 70 serviços.”
Pergunte:
Por que 70?
E quando alguém apresentar uma arquitetura gigantesca para resolver um problema relativamente pequeno, imagine Chris Knight entrando na reunião, olhando aquele maravilhoso laser tecnológico apontado para uma simples panela de milho e perguntando:
“Vocês sabem que existe um jeito mais fácil de fazer pipoca, não sabem?”
Essa é a diferença entre conhecer tecnologia e compreender arquitetura.
O desenvolvedor aprende a construir o laser.
O engenheiro aprende a fazê-lo funcionar.
O arquiteto calcula potência, disponibilidade, segurança e custo.
Mas o Real Genius olha para o requisito e pergunta:
“A gente precisava mesmo do laser?”
☕ Bellacosa Mainframe — porque às 03:17 da madrugada, simplicidade também é uma feature.
