☕ 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
SERVERLESS

Vamos 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
Clientes

Uma arquitetura monolítica poderia ser representada assim:

             CLIENTE
                |
                v
       +----------------+
       |   APLICAÇÃO    |
       |----------------|
       | Produtos       |
       | Carrinho       |
       | Pedidos        |
       | Pagamentos     |
       | Clientes       |
       +----------------+
                |
                v
            DATABASE

Existe 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
PGMSTAT

Pode utilizar:

COPYBOOKS
SUBPROGRAMAS
CICS
Db2
VSAM
JCL
PROCEDURES

e 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 DIE

Rick 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 Discovery

para 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
DATABASE

Arquiteturalmente 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
observabilidade

A 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      PostgreSQL

A ideia é que cada serviço represente uma capacidade de negócio relativamente independente.

Podemos ter:

Customer Service
Order Service
Payment Service
Inventory Service
Fraud Service

Idealmente 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
dados

Por exemplo, durante a Black Friday:

Product Service = 20 instâncias
Cart Service    = 80 instâncias
Order Service   = 50 instâncias
Fraud Service   = 30 instâncias

Podemos 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

COMMIT

Algo 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 Service

Resultado:

Inventory = OK
Payment   = OK
Shipping  = ERROR

E agora?

Não existe necessariamente um botão mágico:

ROLLBACK UNIVERSO

Temos vários sistemas, bancos e estados independentes.

Bem-vindo a conceitos como:

Eventual Consistency
Saga
Compensating Transactions
Idempotency
Retry
Timeout
Dead-Letter Queue
Circuit Breaker

Rick 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 100

Ele 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$100

Temos problema.

Uma operação idempotente procura permitir que repetições controladas não produzam efeitos duplicados indevidos.

Podemos trabalhar com algo como:

TRANSACTION-ID = ABC123

Antes 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 coordenado

Criamos 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 + Serverless

Podemos ter:

Monolith + Serverless Functions

Podemos ter:

Mainframe + Microservices + Serverless

Portanto não pense:

MONOLITH
   ↓
MICROSERVICES
   ↓
SERVERLESS

como 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
RESULT

Por exemplo:

HTTP REQUEST
     |
     v
API GATEWAY
     |
     v
CREATE-ORDER FUNCTION
     |
     v
DATABASE

Mas o evento também pode ser:

Queue Message
File Upload
Timer
Database Change
Object Created
Event Stream

Por 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 FUNCTION

Essa 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
   |
   +----> VSAM

O 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 recursos

O 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
recovery

Rick 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
ATM

Podemos construir:

Mobile
   |
   v
API Gateway
   |
   v
Microservices
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
COBOL
   |
   +--> Db2
   |
   +--> VSAM

O 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
COBOL

Perceba 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
     Db2

O produtor publica uma mensagem.

Algo como:

ORDER.CREATED

O consumidor processa quando apropriado.

Podemos ter:

ORDER.CREATED
      |
      +----> BILLING
      |
      +----> INVENTORY
      |
      +----> FRAUD
      |
      +----> ANALYTICS

Isso introduz uma distinção essencial.

Comunicação síncrona:

FAÇA ISTO
E EU ESPERO A RESPOSTA

Comunicação assíncrona:

ESTE TRABALHO PRECISA SER PROCESSADO

Essa 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.APPROVED

Diversos interessados podem reagir:

PAYMENT.APPROVED
        |
        +------> ORDER
        |
        +------> SHIPPING
        |
        +------> ANALYTICS
        |
        +------> FRAUD
        |
        +------> NOTIFICATION

Isso 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
  |
Database

Investigar uma falha pode ser relativamente simples.

Agora:

Client
 |
Gateway
 |
Service A
 |
Service B
 |
Queue
 |
Service C
 |
Mainframe
 |
CICS
 |
COBOL
 |
Db2

O usuário reclama:

"Demorou oito segundos."

Onde?

Precisamos correlacionar:

logs
metrics
traces
timestamps
transaction IDs
correlation IDs

Talvez a API tenha consumido:

50 ms

O microservice:

80 ms

MQ:

20 ms

CICS:

40 ms

mas uma consulta esperou:

7.500 ms

por 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 dia

Excelente candidata potencial.

Agora imagine:

10.000 requisições/segundo
24 horas/dia
365 dias/ano

A análise econômica muda completamente.

Serverless frequentemente oferece cobrança baseada em utilização, mas isso não significa automaticamente:

SERVERLESS = MAIS BARATO

Você precisa avaliar:

volume
duração
memória
I/O
rede
armazenamento
requisições
picos
previsibilidade
SLA

A 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/dia

ou:

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
CLOUD

Essa 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
CICS

Depois acrescente:

TCP/IP
HTTP
REST
JSON
APIs

Depois:

MQ
Mensageria
Eventos
Kafka/Event Streaming

Depois:

Git
CI/CD
Containers
Microservices
Cloud
Serverless

E finalmente conecte tudo:

COBOL
   |
   +------ CICS
   |
   +------ Db2
   |
   +------ VSAM
   |
   +------ MQ
   |
   +------ APIs
   |
   +------ Events
   |
   +------ Microservices
   |
   +------ Cloud

Nesse 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
JCL

e alguém diz:

— Isso é velho.

Então ele olha para:

transactions
workload management
resource management
messaging
security
high availability
event processing

e 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
Serverless

A 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           VSAM

O 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.