☕ Um Café no Bellacosa Mainframe
⚔️ RICK GLADIATOR E AS TRÊS DUNGEONS DA ARQUITETURA
Monolith, Microservices, Serverless, COBOL, CICS, Db2, VSAM, MQ, APIs, eventos, consistência distribuída, observabilidade — e o dia em que um programador iniciante descobriu que quebrar um programa em 47 pedaços não o transformava automaticamente em arquiteto.
Sob a tutela de Rick Gladiator, de Shinmai Ossan Boukensha.
🎬 PRÓLOGO — VOCÊ TEM 30 ANOS E AINDA USA UM MONÓLITO?
Rick Gladiator conhece muito bem aquela sensação.
Você chega à Guilda dos Aventureiros e encontra uma turma de jovens prodígios.
Um lança magia.
Outro derrota monstros gigantescos.
Outro provavelmente nasceu com KUBERNETES-SKILL LEVEL 99.
Então alguém olha para o velho programador COBOL e pergunta:
— Você ainda trabalha com monólito?
Silêncio.
O programador olha para o terminal.
Rick coloca a espada sobre a mesa.
E responde:
— Antes de chamar alguma coisa de velha, descubra por que ela ainda está funcionando.
Bem-vindo à dungeon.
Hoje não vamos simplesmente comparar três caixas coloridas de um diagrama:
MONOLITH
MICROSERVICES
SERVERLESSVamos descobrir o que realmente muda, onde cada arquitetura funciona, quais problemas aparecem quando distribuímos uma aplicação e, principalmente, como tudo isso conversa com COBOL, CICS, Db2, VSAM, MQ e o Mainframe.
Porque existe uma primeira armadilha escondida no mapa:
Monolith, Microservices e Serverless não são exatamente três alternativas equivalentes.
Rick já percebeu o monstro.
Vamos entrar.
🏰 CAPÍTULO 1 — A PRIMEIRA DUNGEON: O MONÓLITO
Imagine que precisamos desenvolver um comércio eletrônico.
Temos:
Produtos
Carrinho
Pedidos
Pagamentos
ClientesUma arquitetura monolítica poderia ser representada assim:
CLIENTE
|
v
+----------------+
| APLICAÇÃO |
|----------------|
| Produtos |
| Carrinho |
| Pedidos |
| Pagamentos |
| Clientes |
+----------------+
|
v
DATABASEExiste uma aplicação contendo diferentes responsabilidades.
A definição simplificada costuma ser:
One application = one deployable unit.
Mas Rick imediatamente ergue a mão.
— Cuidado.
No mundo Mainframe isso precisa de uma explicação adicional.
Um sistema COBOL pode possuir:
PGMAUTH
PGMCUST
PGMLIMIT
PGMPAY
PGMBILL
PGMSTATPode utilizar:
COPYBOOKS
SUBPROGRAMAS
CICS
Db2
VSAM
JCL
PROCEDURESe possuir centenas ou milhares de módulos.
Mesmo assim, arquiteturalmente, esses componentes podem formar uma grande aplicação fortemente relacionada.
Portanto:
Monólito não significa obrigatoriamente um programa gigantesco com três milhões de linhas.
Essa confusão aparece bastante.
🧱 CAPÍTULO 2 — MONÓLITO NÃO SIGNIFICA CÓDIGO RUIM
Rick encontra o primeiro aventureiro da guilda.
Ele possui uma camiseta:
MICROSERVICES OR DIERick pergunta:
— Por quê?
— Porque monólito é ruim.
— Por quê?
— Porque é monólito.
Rick começa a procurar sua espada.
Um monólito pode ser perfeitamente modular.
Imagine:
+--------------------------------+
| SISTEMA DE CARTÕES |
| |
| AUTHORIZATION MODULE |
| CUSTOMER MODULE |
| LIMIT MODULE |
| BILLING MODULE |
| PAYMENT MODULE |
| FRAUD MODULE |
+--------------------------------+Cada responsabilidade pode estar adequadamente separada internamente.
Em COBOL:
CALL 'LIMITCHK' USING CUSTOMER-DATA
TRANSACTION-DATA
RETURN-DATA.Uma chamada local entre componentes pode ser extremamente rápida.
Não precisamos necessariamente atravessar:
HTTP
TCP/IP
TLS
API Gateway
JSON
Authentication
Load Balancer
Service Discoverypara calcular o limite de um cartão.
A simplicidade também é uma característica arquitetural.
⚡ CAPÍTULO 3 — RICK DESCOBRE QUE A REDE TEM LATÊNCIA
Imagine isto:
CALL 'CALCLIM' USING WS-CUSTOMER
WS-LIMIT.Agora alguém decide:
— CALCLIM precisa virar microservice!
A arquitetura passa a ser algo semelhante a:
COBOL
|
v
HTTP CLIENT
|
v
TCP/IP
|
v
TLS
|
v
API GATEWAY
|
v
AUTHENTICATION
|
v
LIMIT SERVICE
|
v
DATABASEArquiteturalmente ganhamos várias possibilidades.
O serviço pode ser implantado independentemente.
Pode escalar independentemente.
Outra aplicação pode reutilizá-lo.
Mas Rick pergunta:
— E quanto custou atravessar essa ponte?
Porque agora temos:
latência
timeout
retry
serialização
desserialização
falha de rede
DNS
autenticação
observabilidadeA operação que antes acontecia dentro do mesmo processo agora atravessa uma rede.
Não significa que microservices sejam ruins.
Significa apenas:
Toda arquitetura compra vantagens pagando com alguma forma de complexidade.
🔵 CAPÍTULO 4 — A SEGUNDA DUNGEON: MICROSERVICES
Agora vamos quebrar nosso comércio eletrônico.
CLIENT
|
v
API GATEWAY
|
+------------+------------+
| | |
v v v
PRODUCT CART ORDER
SERVICE SERVICE SERVICE
| | |
v v v
MongoDB Redis PostgreSQLA ideia é que cada serviço represente uma capacidade de negócio relativamente independente.
Podemos ter:
Customer Service
Order Service
Payment Service
Inventory Service
Fraud ServiceIdealmente cada um possui autonomia suficiente para evoluir sem exigir um gigantesco deploy coordenado.
Essa palavra é fundamental:
INDEPENDÊNCIA
Queremos independência de:
desenvolvimento
deploy
escalabilidade
tecnologia
ciclo de vida
equipe
dadosPor exemplo, durante a Black Friday:
Product Service = 20 instâncias
Cart Service = 80 instâncias
Order Service = 50 instâncias
Fraud Service = 30 instânciasPodemos aumentar apenas aquilo que está sofrendo pressão.
Essa é uma diferença importante em relação a muitos monólitos.
🐉 CAPÍTULO 5 — VOCÊ DERROTOU O MONÓLITO E DESBLOQUEOU 17 NOVOS MONSTROS
Rick abre a próxima porta.
Há uma placa:
Distributed Systems Dungeon
Ele imediatamente percebe que alguma coisa vai dar errado.
Imagine uma compra.
Em uma aplicação centralizada poderíamos ter conceitualmente:
BEGIN TRANSACTION
UPDATE INVENTORY
INSERT ORDER
INSERT PAYMENT
COMMITAlgo falhou?
ROLLBACKÉ claro que sistemas reais são mais complexos, mas o banco de dados fornece mecanismos transacionais poderosos.
Agora distribuímos tudo:
Order Service
|
+----> Inventory Service
|
+----> Payment Service
|
+----> Shipping ServiceResultado:
Inventory = OK
Payment = OK
Shipping = ERRORE agora?
Não existe necessariamente um botão mágico:
ROLLBACK UNIVERSOTemos vários sistemas, bancos e estados independentes.
Bem-vindo a conceitos como:
Eventual Consistency
Saga
Compensating Transactions
Idempotency
Retry
Timeout
Dead-Letter Queue
Circuit BreakerRick olha para o programador iniciante.
— Ainda acha que dividir tudo em serviços automaticamente simplifica a aplicação?
🔁 CAPÍTULO 6 — IDEMPOTÊNCIA: ATAQUE O MONSTRO DUAS VEZES SEM MATAR DOIS CLIENTES
Suponha que um serviço receba:
PAY CUSTOMER 100Ele processa.
Mas a resposta não retorna por causa de um timeout.
O chamador pensa:
"Não funcionou."
E envia novamente.
Se o sistema não estiver preparado:
Pagamento 1 = R$100
Pagamento 2 = R$100Temos problema.
Uma operação idempotente procura permitir que repetições controladas não produzam efeitos duplicados indevidos.
Podemos trabalhar com algo como:
TRANSACTION-ID = ABC123Antes de processar novamente:
ABC123 já foi processada?Se sim, devolvemos o resultado anterior ou tratamos de acordo com a regra definida.
Em sistemas distribuídos, isso deixa de ser detalhe.
É sobrevivência.
👹 CAPÍTULO 7 — O TERRÍVEL DISTRIBUTED MONOLITH
A guilda comemora.
— Conseguimos! Criamos 27 microservices!
Rick pergunta:
— Eles podem ser implantados independentemente?
Silêncio.
Para instalar PAYMENT, precisamos instalar ORDER.
Para instalar ORDER, precisamos instalar CUSTOMER.
Para instalar CUSTOMER, precisamos atualizar PRODUCT.
Então temos:
27 serviços
27 pipelines
27 APIs
27 logs
27 configurações
mas...
1 deploy coordenadoCriamos um:
DISTRIBUTED MONOLITH
Ou seja:
Pegamos algumas desvantagens do monólito e adicionamos várias dificuldades dos sistemas distribuídos.
Esse é um dos maiores perigos de adotar microservices apenas porque eles estão na moda.
🟣 CAPÍTULO 8 — A TERCEIRA DUNGEON: SERVERLESS
Chegamos ao terceiro bloco do desenho.
Mas existe um segredo.
Serverless não está exatamente no mesmo eixo de Monolith e Microservices.
Monolith e Microservices respondem principalmente:
Como organizamos e dividimos a aplicação?
Serverless responde mais diretamente:
Como determinado código será executado e operacionalizado?
Essa diferença muda tudo.
Podemos ter:
Microservices + ServerlessPodemos ter:
Monolith + Serverless FunctionsPodemos ter:
Mainframe + Microservices + ServerlessPortanto não pense:
MONOLITH
↓
MICROSERVICES
↓
SERVERLESScomo uma linha evolutiva.
Não existe um Pokémon arquitetural chamado:
Monolithmon
↓
Microservicemon
↓
Serverlessmon☁️ CAPÍTULO 9 — MAS SERVERLESS TEM SERVIDOR!
Sim.
Rick também ficou decepcionado.
Serverless não significa que os servidores desapareceram em alguma magia ancestral.
Eles continuam existindo.
A diferença é que o desenvolvedor normalmente não administra diretamente toda a infraestrutura necessária para executar aquela função.
Um modelo simplificado:
EVENT
|
v
FUNCTION
|
v
RESULTPor exemplo:
HTTP REQUEST
|
v
API GATEWAY
|
v
CREATE-ORDER FUNCTION
|
v
DATABASEMas o evento também pode ser:
Queue Message
File Upload
Timer
Database Change
Object Created
Event StreamPor isso Serverless combina muito bem com arquiteturas orientadas a eventos.
🥶 CAPÍTULO 10 — O DRAGÃO DO COLD START
Uma função pode não estar continuamente ativa.
Chega uma solicitação.
A plataforma talvez precise preparar seu ambiente:
REQUEST
|
v
START RUNTIME
|
v
LOAD DEPENDENCIES
|
v
INITIALIZE
|
v
EXECUTE FUNCTIONEssa inicialização pode introduzir latência.
É o famoso:
Cold Start
Isso varia conforme plataforma, linguagem, configuração e modelo operacional.
Para algumas aplicações é irrelevante.
Para outras, alguns milissegundos adicionais podem ser importantes.
A lição é novamente:
Não escolha tecnologia olhando apenas o desenho bonito.
Meça.
🏦 CAPÍTULO 11 — RICK GLADIATOR ENTRA NO CICS
Agora começa a parte que faz o velho programador COBOL sorrir.
Considere:
CLIENT
|
v
CICS
|
v
TRANSACTION
|
v
COBOL PROGRAM
|
+----> Db2
|
+----> VSAMO programador COBOL normalmente não precisa escrever do zero toda a infraestrutura necessária para:
gerenciar processos
controlar recursos
coordenar transações
gerenciar milhares de solicitações
proteger recursosO CICS oferece um ambiente transacional gerenciado.
Isso não significa que CICS seja Serverless no sentido moderno.
Mas existe uma analogia pedagógica deliciosa.
Décadas antes da palavra "serverless" virar assunto de conferência, o Mainframe já trabalhava profundamente com ideias como:
execução gerenciada
workload
transações
eventos
resource management
security
recoveryRick olha para a arquitetura moderna.
Depois olha para o CICS.
— Eu já vi alguns desses golpes antes...
🌉 CAPÍTULO 12 — O COBOL NÃO PRECISA VIRAR MICROSERVICE
Imagine um banco com:
Mobile Banking
Internet Banking
Open Finance
Parceiros
ATMPodemos construir:
Mobile
|
v
API Gateway
|
v
Microservices
|
v
z/OS Connect
|
v
CICS
|
v
COBOL
|
+--> Db2
|
+--> VSAMO programa COBOL pode continuar sendo responsável pela lógica transacional crítica.
A modernização ocorre ao redor e através dele.
Essa é uma mudança enorme de perspectiva.
Modernizar não significa obrigatoriamente:
DELETE COBOL.Pode significar:
ENABLE COBOL.🔌 CAPÍTULO 13 — z/OS CONNECT ABRE A PORTA DA DUNGEON
Imagine que nosso programa trabalha com:
01 CUSTOMER-REQUEST.
05 CUSTOMER-ID PIC X(10).
01 CUSTOMER-RESPONSE.
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-LIMIT PIC 9(09)V99.O mundo moderno deseja conversar usando algo semelhante a:
{
"customerId": "0001234567"
}e receber:
{
"name": "RICK GLADIATOR",
"limit": 15000.00
}Uma integração pode assumir:
REST / JSON
|
v
z/OS Connect
|
v
CICS
|
v
COBOLPerceba a beleza.
O programa COBOL não precisa acordar numa terça-feira dizendo:
"Agora sou JavaScript."
Ele continua executando a responsabilidade para a qual foi construído.
Criamos uma nova fronteira de integração.
📨 CAPÍTULO 14 — MQ: RICK DESCOBRE QUE NEM TODA MISSÃO PRECISA ESPERAR RESPOSTA
Outra possibilidade:
ORDER SERVICE
|
v
MQ
|
v
COBOL CONSUMER
|
v
Db2O produtor publica uma mensagem.
Algo como:
ORDER.CREATEDO consumidor processa quando apropriado.
Podemos ter:
ORDER.CREATED
|
+----> BILLING
|
+----> INVENTORY
|
+----> FRAUD
|
+----> ANALYTICSIsso introduz uma distinção essencial.
Comunicação síncrona:
FAÇA ISTO
E EU ESPERO A RESPOSTAComunicação assíncrona:
ESTE TRABALHO PRECISA SER PROCESSADOEssa diferença é fundamental para arquiteturas corporativas.
🌊 CAPÍTULO 15 — EVENT STREAMING: O MONSTRO MORREU E TODO MUNDO FICOU SABENDO
Em arquiteturas orientadas a eventos, podemos publicar:
PAYMENT.APPROVEDDiversos interessados podem reagir:
PAYMENT.APPROVED
|
+------> ORDER
|
+------> SHIPPING
|
+------> ANALYTICS
|
+------> FRAUD
|
+------> NOTIFICATIONIsso reduz determinados acoplamentos diretos.
O produtor não precisa necessariamente conhecer todos os consumidores.
O conceito muda de:
"Fulano, faça isso."
para:
"Isto aconteceu."
É uma mudança arquitetural poderosa.
🔭 CAPÍTULO 16 — OBSERVABILIDADE: QUEM MATOU O MONSTRO?
No monólito:
Client
|
Application
|
DatabaseInvestigar uma falha pode ser relativamente simples.
Agora:
Client
|
Gateway
|
Service A
|
Service B
|
Queue
|
Service C
|
Mainframe
|
CICS
|
COBOL
|
Db2O usuário reclama:
"Demorou oito segundos."
Onde?
Precisamos correlacionar:
logs
metrics
traces
timestamps
transaction IDs
correlation IDsTalvez a API tenha consumido:
50 msO microservice:
80 msMQ:
20 msCICS:
40 msmas uma consulta esperou:
7.500 mspor um lock no Db2.
Sem observabilidade distribuída, o diagnóstico vira investigação arqueológica.
📊 CAPÍTULO 17 — O MAPA DE RICK
Guarde esta tabela mental:
| Aspecto | Monolith | Microservices | Serverless |
|---|---|---|---|
| Organização | aplicação | serviços | funções/event handlers |
| Deploy | mais coordenado | independente | função |
| Comunicação | frequentemente local | rede/eventos | eventos/APIs |
| Escala | aplicação | serviço | execução/função |
| Estado | mais centralizado | distribuído | normalmente externo |
| Debug | mais simples | distribuído | distribuído |
| Operação | menor complexidade inicial | alta | infraestrutura abstraída |
| Consistência | mais simples | complexa | frequentemente distribuída |
| Rede | menor dependência interna | fundamental | fundamental |
| Observabilidade | concentrada | distribuída | distribuída |
Mas Rick acrescentaria:
Não transforme essa tabela em religião.
💰 CAPÍTULO 18 — SERVERLESS NÃO SIGNIFICA BARATO
Imagine uma função utilizada:
100 vezes por diaExcelente candidata potencial.
Agora imagine:
10.000 requisições/segundo
24 horas/dia
365 dias/anoA análise econômica muda completamente.
Serverless frequentemente oferece cobrança baseada em utilização, mas isso não significa automaticamente:
SERVERLESS = MAIS BARATOVocê precisa avaliar:
volume
duração
memória
I/O
rede
armazenamento
requisições
picos
previsibilidade
SLAA arquitetura correta é também uma decisão econômica.
🧭 CAPÍTULO 19 — PASSO A PASSO PARA ESCOLHER
Rick não escolheria uma arma apenas porque alguém colocou "Cloud Native" na embalagem.
Faça perguntas.
Passo 1 — descubra o domínio
O que a aplicação realmente faz?
Pagamento?
Consulta?
Relatório?
Fraude?
Cadastro?
Processamento de imagem?Passo 2 — descubra o volume
Temos:
100 operações/diaou:
10.000 operações/segundo?Passo 3 — determine a latência
Pode levar:
10 segundos?
1 segundo?
100 ms?
20 ms?Passo 4 — descubra o estado
Precisamos manter informações entre execuções?
Onde?
Passo 5 — determine consistência
É aceitável que dois sistemas fiquem temporariamente diferentes?
Passo 6 — analise as transações
Precisamos alterar vários recursos atomicamente?
Passo 7 — analise escalabilidade
Qual componente realmente precisa crescer?
Passo 8 — pense em falhas
Pergunte:
E se a rede cair?
E se houver timeout?
E se a mensagem chegar duas vezes?
E se o consumidor ficar indisponível?
E se o banco responder e a confirmação desaparecer?Essa talvez seja uma das melhores formas de pensar como arquiteto.
🏗️ CAPÍTULO 20 — A ARQUITETURA REAL NÃO CABE NAS TRÊS COLUNAS
Uma arquitetura corporativa moderna pode ser:
MOBILE
|
v
API GATEWAY
|
+----------+----------+
| |
v v
MICROSERVICES SERVERLESS
| |
+----------+----------+
|
v
EVENT STREAM
|
v
MQ
|
v
+----------------+
| IBM Z |
|----------------|
| CICS |
| IMS |
| COBOL |
| Db2 |
| VSAM |
+----------------+Agora desaparece aquela velha guerra:
MAINFRAME
VS
CLOUDEssa pergunta é pobre.
A pergunta melhor é:
Qual workload deve executar onde?
Essa é uma pergunta de arquiteto.
🥚 EASTER EGG — 03:17 DA MADRUGADA
Às 03:17, o telefone toca.
Produção.
O dashboard está verde.
O cliente diz que pagamentos estão sendo duplicados.
O jovem aventureiro verifica Kubernetes.
Tudo verde.
Verifica API Gateway.
Verde.
Microservices.
Verdes.
Serverless.
Verde.
MQ.
Verde.
CICS.
Verde.
Então Rick pergunta:
— Qual é o CORRELATION-ID da transação?
Silêncio.
Descobrem que um timeout fez o cliente repetir uma requisição e o Payment Service não tratava adequadamente a repetição.
A transação foi processada duas vezes.
Rick fecha o notebook.
Não existe arquitetura suficientemente moderna para compensar uma regra transacional mal compreendida.
03:17.
Incidente encerrado.
Quem acompanha o Bellacosa Mainframe sabe que esse horário nunca aparece por acaso. ☕😈
🎓 CAPÍTULO 21 — O QUE O PROGRAMADOR COBOL INICIANTE PRECISA APRENDER
Não abandone COBOL para correr atrás de todas as palavras da moda.
Expanda o mapa.
Comece com:
COBOL
JCL
VSAM
Db2
CICSDepois acrescente:
TCP/IP
HTTP
REST
JSON
APIsDepois:
MQ
Mensageria
Eventos
Kafka/Event StreamingDepois:
Git
CI/CD
Containers
Microservices
Cloud
ServerlessE finalmente conecte tudo:
COBOL
|
+------ CICS
|
+------ Db2
|
+------ VSAM
|
+------ MQ
|
+------ APIs
|
+------ Events
|
+------ Microservices
|
+------ CloudNesse momento você deixa de enxergar apenas um programa.
Começa a enxergar arquitetura.
⚔️ EPÍLOGO — O OSSAN NÃO PRECISAVA SER O MAIS JOVEM DA GUILDA
Rick Gladiator não é interessante porque começou cedo.
É justamente o contrário.
Ele lembra que experiência, disciplina e treinamento podem alterar completamente aquilo que aparentemente parecia uma desvantagem.
Existe uma bela analogia com Mainframe.
O programador olha para:
COBOL
CICS
VSAM
Db2
JCLe alguém diz:
— Isso é velho.
Então ele olha para:
transactions
workload management
resource management
messaging
security
high availability
event processinge percebe:
— Espere um pouco...
Muitos dos problemas que a computação moderna está tentando resolver não são novos.
As ferramentas mudaram.
As abstrações mudaram.
Os nomes ficaram mais bonitos.
Os slides ganharam cores.
Mas continuamos tentando responder perguntas antigas:
Como executar trabalho?
Como dividir responsabilidades?
Como mover dados?
Como sobreviver a falhas?
Como escalar?
Como garantir uma transação?
Como descobrir onde alguma coisa deu errado?
E é por isso que a pergunta definitiva não deveria ser:
Monolith
VS
Microservices
VS
ServerlessA pergunta deveria ser:
QUAL ARQUITETURA RESOLVE MELHOR ESTE PROBLEMA?
Às vezes será um monólito modular.
Às vezes serão microservices.
Às vezes serverless.
Às vezes CICS e COBOL.
E, em sistemas empresariais de verdade, frequentemente será:
+----------------+
| MICROSERVICES |
+-------+--------+
|
SERVERLESS -------- EVENTS
|
MQ
|
+-------+--------+
| CICS |
+-------+--------+
|
COBOL
|
+------+------+
| |
Db2 VSAMO programador iniciante entrou na dungeon procurando descobrir qual arquitetura era "a moderna".
Saiu dela entendendo algo muito mais importante:
Arquitetura não é escolher a tecnologia mais nova. É compreender suficientemente bem o problema para saber onde cada tecnologia pertence.
Rick pega a espada.
O velho COBOL compila.
O CICS continua processando transações.
O microservice publica um evento.
A função serverless acorda.
MQ entrega uma mensagem.
Db2 confirma o COMMIT.
E, em algum canto escuro da dungeon, alguém propõe transformar os 847 programas COBOL em 847 microservices porque viu isso numa apresentação.
Rick olha para o programador.
O programador olha para Rick.
IF ARCHITECTURE-BY-HYPE
MOVE 'RUN!' TO RECOMMENDATION
END-IF.☕⚔️ Bem-vindo ao Bellacosa Mainframe. Aqui até o aventureiro Rank F aprende que o monstro mais perigoso da arquitetura continua sendo uma solução procurando um problema.
