Bellacosa Mainframe e os mistérios dos microsserviços

☕ Um Café no Bellacosa Mainframe

🕵️ CHARLIE CHAN E O MISTÉRIO DOS MICROSSERVIÇOS QUE NÃO ERAM MICROSSERVIÇOS

Distributed Monolith, APIs, bancos compartilhados, chamadas síncronas, observabilidade, consistência, Sagas e o estranho caso do COBOL acusado por um crime cometido pela arquitetura distribuída.

Sob a tutela de Charlie Chan

 

Há crimes em que o culpado deixa impressões digitais.

Há outros em que desaparece sem deixar vestígios.

E existem aqueles especialmente interessantes nos quais todas as evidências apontam para o suspeito errado.

Era exatamente esse o caso.

Naquela manhã, Charlie Chan foi chamado para investigar um incidente gravíssimo na fictícia Companhia Internacional de Pagamentos Oriental & Ocidental.

A empresa havia realizado uma enorme modernização.

Durante décadas, seu sistema central funcionara em IBM Z. COBOL, CICS e Db2 processavam clientes, contas, pagamentos e transações. A arquitetura certamente possuía limitações e décadas de evolução acumulada, mas havia uma característica difícil de ignorar:

funcionava.

Então chegou a transformação digital.

Consultorias apareceram.

PowerPoints apareceram.

Post-its apareceram.

Kubernetes apareceu.

Containers apareceram.

APIs apareceram.

Kafka apareceu.

E, naturalmente, apareceram microserviços.

Muitos microserviços.

Centenas deles.

O antigo sistema, considerado monolítico demais para o século XXI, foi cercado por uma maravilhosa arquitetura distribuída.

Até que determinada transação passou a levar quase dois segundos.

Imediatamente alguém encontrou o culpado:

COBOL.

Charlie Chan entrou silenciosamente na sala de guerra.

Na parede havia dashboards, diagramas, traces e gráficos coloridos.

Um arquiteto apontou para o mainframe.

— O legado está atrasando nossa transformação.

Charlie Chan observou o enorme desenho da arquitetura.

Mobile.

API Gateway.

Authentication Service.

Customer Service.

Order Service.

Inventory Service.

Pricing Service.

Payment Service.

Kafka.

Integration Service.

z/OS Connect.

CICS.

COBOL.

Db2.

Depois perguntou:

— Quanto tempo COBOL levou?

Silêncio.

Alguém consultou o monitor.

— Aproximadamente 38 milissegundos.

Chan sorriu discretamente.

Havia encontrado sua primeira pista.

---

🕵️ CAPÍTULO 1 — O morto tinha muitos suspeitos

Para entender o crime, precisamos entender o que microserviços deveriam proporcionar.

A ideia não é simplesmente transformar:

PROGRAMA A
PROGRAMA B
PROGRAMA C

em:

SERVICE A
SERVICE B
SERVICE C

e colocar HTTP entre eles.

Uma arquitetura de microserviços procura estabelecer fronteiras significativas, normalmente relacionadas às capacidades ou domínios do negócio.

Imagine uma loja.

Podemos ter:

CUSTOMER
ORDER
PAYMENT
INVENTORY
SHIPPING

Cada domínio possui responsabilidades relativamente claras.

PAYMENT, por exemplo, deveria poder evoluir sem exigir que cinco outras equipes reconstruíssem simultaneamente seus sistemas.

Esse é um dos objetivos fundamentais:

reduzir acoplamento.

Charlie Chan escreveu três palavras no quadro:

DESIGN
RUNTIME
DATA

O jovem programador COBOL perguntou:

— O que significa isso?

Chan apontou para a primeira.

Acoplamento de design

Se modificar A exige modificar B, existe dependência de design.

A mudou
   ↓
B precisa mudar
   ↓
C também precisa mudar

Depois apontou para a segunda.

Acoplamento de runtime

Se A somente funciona enquanto B estiver disponível naquele exato instante:

A → B

há dependência operacional.

Finalmente:

Acoplamento de dados

Se A precisa conhecer as estruturas internas de dados pertencentes a B:

SERVICE A
    |
    └────> TABLE_B

temos acoplamento de dados.

Charlie Chan circulou as três palavras.

Quando uma arquitetura apresenta simultaneamente forte dependência de design, runtime e dados, podemos ter algo muito interessante:

um monólito distribuído.

---

🕸️ CAPÍTULO 2 — O Distributed Monolith entra na sala

O primeiro suspeito da investigação era elegante.

Vestia containers.

Carregava YAML.

Falava Kubernetes fluentemente.

Apresentava-se como microservices.

Mas seus documentos contavam outra história.

Havia:

Customer Service
Order Service
Payment Service
Inventory Service
Shipping Service

Parecia perfeito.

Charlie Chan perguntou:

— Podemos alterar Payment Service e colocá-lo em produção sozinho?

O arquiteto respondeu:

— Tecnicamente sim...

Charlie Chan conhecia aquela palavra.

Tecnicamente.

Quase sempre alguma coisa interessante aparece depois dela.

— Mas?

— Precisamos coordenar com Order, Customer e Billing.

— Podemos implantar Customer independentemente?

— Normalmente fazemos release conjunto.

— E Inventory?

— Também.

Chan virou-se para o programador.

— Cinco casas com cinco portas não significam cinco famílias independentes se todos precisam sair juntos quando um morador troca a geladeira.

Era exatamente isso.

Fisicamente:

A   B   C   D   E

Arquiteturalmente:

A → B → C → D → E

Você não eliminou o monólito.

Você colocou uma rede dentro dele.

E essa distinção é extraordinariamente importante.

Um monólito tradicional pode possuir chamadas locais extremamente rápidas.

Um distributed monolith mantém parte do acoplamento do monólito e acrescenta:

DNS, TCP, TLS, serialização, desserialização, proxies, gateways, service discovery, containers, balanceadores, retries, timeouts e falhas parciais.

O velho:

CALL 'PAGAMENTO'

vira conceitualmente:

COBOL CALL
      ↓
“Você está aqui.”

Enquanto:

REST CALL

pode significar:

Aplicação
   ↓
DNS
   ↓
Network
   ↓
TLS
   ↓
Gateway
   ↓
Load Balancer
   ↓
Container
   ↓
Framework
   ↓
JSON parser
   ↓
Business Logic

O CALL deixou de ser uma porta.

Virou uma viagem.

---

🧩 CAPÍTULO 3 — O caso dos microserviços pequenos demais

O segundo suspeito parecia inocente.

Chamava-se Excessive Microservices.

A investigação encontrou:

CustomerNameService
CustomerAddressService
CustomerPhoneService
CustomerEmailService
CustomerPreferenceService
CustomerStatusService

Charlie Chan perguntou:

— Por que existem seis serviços?

Responderam:

— Porque microserviços precisam ser pequenos.

Chan permaneceu alguns segundos em silêncio.

Esse é um dos maiores equívocos causados pelo próprio nome microservice.

O “micro” não significa:

menor quantidade possível de linhas de código.

Nem:

transforme cada função em servidor.

O limite deveria fazer sentido arquitetural e comercial.

Se cada pequena operação vira serviço, surge uma explosão de infraestrutura.

Cada serviço pode exigir:

repositório
pipeline
build
container
configuração
secrets
logs
monitoramento
alertas
testes
versionamento
documentação
ownership

Multiplique isso por 300.

A empresa pretendia diminuir complexidade.

Acabou industrializando-a.

Charlie Chan escreveu:

“Dividir problema não necessariamente divide complexidade.”

---

📞 CAPÍTULO 4 — As testemunhas conversavam demais

A terceira pista apareceu no distributed tracing.

Uma simples compra fazia:

Gateway
   ↓
Customer
   ↓
Address
   ↓
Inventory
   ↓
Pricing
   ↓
Discount
   ↓
Fraud
   ↓
Payment
   ↓
Shipping

Nove serviços para responder uma única solicitação.

Isso é Service Chatter.

Serviços excessivamente conversadores transformam pequenas operações em longas sequências de chamadas remotas.

Imagine que cada chamada leve apenas 30 ms.

Parece pouco.

Mas adicionamos:

latência de rede
processamento
autenticação
serialização
consultas
filas
TLS
proxies

E há algo ainda pior:

tail latency.

Um serviço pode normalmente responder em 20 ms, mas ocasionalmente levar 500 ms.

Se uma transação depende sequencialmente de muitos serviços, basta um deles espirrar para a transação inteira pegar gripe.

---

⛓️ CAPÍTULO 5 — A corrente síncrona

Charlie Chan encontrou então:

A → B → C → D → E → F

Cada serviço esperava pelo seguinte.

Se F falhasse:

A → B → C → D → E → F
                      X

E esperariam:

E
D
C
B
A

até os respectivos timeouts.

Mas alguém havia pensado na solução:

RETRY!

Agora:

F falhou
 ↓
retry
 ↓
retry
 ↓
retry

Enquanto centenas de transações faziam exatamente a mesma coisa.

O sistema tentava resolver uma sobrecarga...

produzindo mais carga.

Essa é uma das armadilhas mais deliciosamente perversas dos sistemas distribuídos.

Retries são úteis.

Retries indiscriminados são multiplicadores de desastre.

Entram então padrões como:

Timeout
Circuit Breaker
Bulkhead
Backoff
Rate Limiting
Load Shedding
Async Messaging

O Circuit Breaker é particularmente interessante.

Se determinado serviço está claramente falhando, por que continuar chamando-o milhares de vezes?

É semelhante ao disjuntor elétrico.

Detectamos:

FAIL
FAIL
FAIL
FAIL

e abrimos temporariamente o circuito:

A ─────X────→ B

evitando desperdiçar recursos e potencialmente agravando o incidente.

---

🗄️ CAPÍTULO 6 — Todos juravam ter seu banco. Mas havia apenas um

Charlie Chan então entrou no Db2.

Encontrou algo curioso:

Customer Service ─┐
Order Service ────┤
Payment Service ──┼── DATABASE
Shipping Service ─┤
Inventory Service ┘

— Quem é proprietário desta tabela?

Silêncio.

— Todos.

Chan sorriu.

— Quando todos são proprietários, talvez ninguém seja.

Esse é o problema do Common Shared Database.

O problema não é simplesmente utilizar o mesmo servidor Db2.

É perfeitamente possível organizar:

Db2
│
├── CUSTOMER schema
├── ORDER schema
├── PAYMENT schema
└── SHIPPING schema

O ponto fundamental é ownership.

Payment não deveria simplesmente vasculhar tabelas internas de Customer porque encontrou um SELECT conveniente.

Caso contrário:

ALTER TABLE CUSTOMER...

pode quebrar:

Customer
Payment
Order
Shipping
Fraud

Agora todos precisam coordenar mudanças.

Voltamos ao primeiro suspeito.

Distributed Monolith.

Charlie Chan percebeu que os suspeitos não eram independentes.

Eram cúmplices.

---

🔢 CAPÍTULO 7 — O JSON que mudou de aparência

Outra equipe resolveu melhorar uma API.

Antes:

{
  "customerId": 317,
  "name": "Charlie Chan"
}

Depois:

{
  "customer": {
    "id": 317,
    "fullName": "Charlie Chan"
  }
}

Muito mais elegante.

Deploy realizado.

Dezessete consumidores quebraram.

Bem-vindo ao Missing API Version Control.

Para um programador COBOL isso deveria soar assustadoramente familiar.

Imagine:

01 CUSTOMER-RECORD.
   05 CUSTOMER-ID    PIC 9(09).
   05 CUSTOMER-NAME  PIC X(40).

Alguém modifica irresponsavelmente o COPYBOOK.

Dezenas de programas dependem daquela estrutura.

Temos o mesmo princípio.

COPYBOOK é contrato.

OpenAPI é contrato.

JSON é contrato.

Protobuf é contrato.

Mensagem MQ é contrato.

Evento Kafka é contrato.

Modernização não aboliu contratos.

Apenas lhes deu novos nomes.

---

🔭 CAPÍTULO 8 — O crime aconteceu, mas ninguém sabia onde

Então veio a pergunta mais simples de toda investigação:

— Onde a transação ficou lenta?

Todos olharam os dashboards.

Havia:

gateway.log
customer.log
payment.log
order.log
inventory.log
shipping.log
kafka.log
integration.log

Cada equipe possuía seu próprio pedaço da história.

Ninguém possuía o filme inteiro.

Esse é o Limited Observability.

Em sistemas distribuídos precisamos correlacionar eventos.

Imagine:

TRACE-ID = CHAN-0317

Então conseguimos reconstruir:

03:17:00.001 Gateway
03:17:00.020 Authentication
03:17:00.051 Customer
03:17:00.094 Order
03:17:00.141 Inventory
03:17:00.209 Payment
03:17:01.710 Payment TIMEOUT

Ah...

03:17.

Quem acompanha o Bellacosa Mainframe sabe que alguma coisa sempre acontece às 03:17. 😉

Agora temos evidência.

Observabilidade moderna costuma trabalhar com três elementos extremamente importantes:

LOGS
METRICS
TRACES

Eu acrescentaria contexto operacional:

EVENTS
DEPLOYMENTS
CONFIG CHANGES
SECURITY EVENTS

Porque descobrir que a latência começou às 03:17 é interessante.

Descobrir que:

03:16:48 deployment PAYMENT V7.4
03:17:00 latency spike

é muito mais interessante.

---

💾 CAPÍTULO 9 — O COMMIT desaparecido

Charlie Chan voltou-se então para o programador COBOL.

— Mostre uma transação tradicional.

Ele escreveu:

BEGIN

UPDATE ACCOUNT
INSERT PAYMENT
UPDATE ORDER

COMMIT

Falhou?

ROLLBACK

Elegante.

Mas agora cada domínio possui seus próprios dados:

Order DB
Inventory DB
Payment DB
Shipping DB

A transação torna-se:

Create Order
      ↓
Reserve Inventory
      ↓
Charge Payment
      ↓
Schedule Shipping

Suponha:

Create Order        OK
Reserve Inventory   OK
Charge Payment      FAIL

O que acontece com o estoque?

Precisamos desfazer semanticamente a operação anterior:

Release Inventory
Cancel Order

Entramos no universo das Sagas e transações compensatórias.

E aqui existe uma diferença filosófica enorme.

No modelo transacional tradicional pensamos frequentemente:

ANTES
  ↓
TRANSAÇÃO
  ↓
DEPOIS

No distribuído podemos precisar reconhecer estados intermediários:

CREATED
   ↓
INVENTORY_RESERVED
   ↓
PAYMENT_PENDING
   ↓
PAYMENT_FAILED
   ↓
COMPENSATING
   ↓
CANCELLED

Esses estados não são acidentes.

Fazem parte do desenho do negócio.

---

⚙️ CAPÍTULO 10 — A configuração escondida no código

Chan encontrou outra evidência:

PAYMENT_HOST=production.company.local

Dentro da aplicação.

Para mudar o endereço:

alterar código
 ↓
build
 ↓
teste
 ↓
deploy

Temos Embedded Configuration.

Configuração operacional deveria normalmente estar separada do código.

Mas Charlie Chan encontrou outra armadilha.

Externalizar tudo também não resolve magicamente o problema.

Se alguém consegue alterar:

PAYMENT_TIMEOUT=3000

para:

PAYMENT_TIMEOUT=30000

sem auditoria, acabamos criando outro mistério.

Configuração precisa de:

versionamento
controle de acesso
auditoria
validação
rollback

Imagine durante uma investigação descobrir:

“Ninguém alterou o programa.”

Verdade.

Alteraram apenas a configuração.

O comportamento mudou completamente.

Essa diferença seria especialmente interessante em uma investigação de Red Team.

---

🧱 CAPÍTULO 11 — Um morreu e levou todos consigo

Restava Weak Fault Isolation.

Payment caiu.

Order começou a esperar.

Checkout esperou Order.

Gateway esperou Checkout.

Threads foram ocupadas.

Connections acabaram.

Retries começaram.

CPU subiu.

Memória subiu.

Filas cresceram.

E finalmente:

PAYMENT
   X
   ↓
ORDER
   X
   ↓
CHECKOUT
   X
   ↓
SYSTEM
   X

Charlie Chan perguntou:

— Por que chamam isso de serviços independentes?

Ninguém respondeu.

Fault isolation deveria permitir algo mais próximo de:

Payment      X

Catalog      OK
Search       OK
Customer     OK
Order        DEGRADED

Talvez o cliente não consiga pagar naquele momento.

Isso não significa necessariamente que ele também precise perder acesso ao catálogo.

Essa é a essência de graceful degradation.

---

🏛️ CAPÍTULO 12 — O suspeito que ninguém interrogou: o monólito modular

Havia outra pessoa na sala.

Ninguém havia interrogado.

Chamava-se:

Modular Monolith.

Durante anos, “monolith” tornou-se quase uma palavra ofensiva em determinados círculos tecnológicos.

Mas Charlie Chan não investigava palavras.

Investigava evidências.

Considere:

┌───────────────────────────────┐
│       APPLICATION             │
│                               │
│ CUSTOMER │ ORDER │ PAYMENT    │
│──────────┼───────┼────────────│
│ INVENTORY│ SHIPPING           │
│                               │
└───────────────────────────────┘

Um único deployable não significa necessariamente uma massa desorganizada.

Podemos possuir:

módulos
interfaces
encapsulamento
bounded contexts
ownership
testes
regras arquiteturais

sem obrigatoriamente adicionar:

latência de rede
service discovery
distributed tracing
eventual consistency
orquestração
centenas de pipelines
falhas parciais

E aqui está uma excelente estratégia de engenharia:

comece estabelecendo boas fronteiras.

Depois, se uma fronteira realmente precisar virar serviço independente, extraia-a.

Não precisamos distribuir primeiro para descobrir o domínio depois.

---

🖥️ CAPÍTULO 13 — Finalmente interrogam o COBOL

Depois de horas de investigação, Charlie Chan voltou ao suspeito original.

COBOL.

O relatório dizia:

Tempo total da transação: 1.843 ms

Parecia terrível.

Então Chan pediu a decomposição.

API Gateway             74 ms
Authentication          91 ms
Customer Service        63 ms
Order Service          112 ms
Inventory              127 ms
Pricing                 86 ms
Payment                742 ms
Integration            164 ms
z/OS Connect            49 ms
CICS                    31 ms
COBOL                    38 ms
Db2                      41 ms
demais esperas          225 ms
--------------------------------
TOTAL                 1.843 ms

Todos olharam para o quadro.

COBOL havia sido acusado de produzir uma transação de quase dois segundos.

Sua participação direta era minúscula.

Charlie Chan finalmente declarou:

O homem mais velho da sala não necessariamente cometeu o crime apenas porque estava presente quando aconteceu.

O mainframe não estava necessariamente lento.

Haviam construído uma rodovia cheia de pedágios para chegar até ele.

---

☕ CAPÍTULO 14 — O que um programador COBOL iniciante deveria aprender disso?

Muito.

Especialmente que os conceitos modernos não são tão alienígenas quanto parecem.

Veja:

Mundo tradicional	Mundo distribuído
COPYBOOK	API Schema
CALL	Service Call
COMMAREA	Payload
MQ Message	Event/Message
COMMIT	Local Transaction
ROLLBACK	Compensação/Saga
Return Code	HTTP Status/Error
SMF/monitoramento	Telemetry
Correlation ID	Trace ID
Timeout	Timeout
RACF	Identity/Authorization
JCL/PROC/Parms	Deployment/configuration

As implementações mudam profundamente.

Os problemas fundamentais, nem tanto.

Ainda perguntamos:

Quem chama quem?

Quem possui os dados?

Quem pode alterar?

Quem depende dessa interface?

O que acontece se falhar?

Como recuperamos?

Como sabemos o que aconteceu?

Essas perguntas atravessam gerações tecnológicas.

---

🕵️ CAPÍTULO 15 — Charlie Chan monta o quadro do crime

Chan finalmente ligou todos os fios.

              DISTRIBUTED MONOLITH
                       │
         ┌─────────────┼─────────────┐
         ↓             ↓             ↓
    DESIGN          RUNTIME         DATA
    COUPLING        COUPLING       COUPLING
         │             │             │
         ↓             ↓             ↓
 API versions       chatter       shared DB
 deployments        sync chains   consistency
 contracts          retries       transactions
         │             │             │
         └─────────────┼─────────────┘
                       ↓
                COMPLEXIDADE
                       ↓
               OBSERVABILIDADE
                       ↓
                FAULT ISOLATION

Finalmente tudo fazia sentido.

Os dez anti-patterns da figura original não eram dez crimes isolados.

Eram manifestações de algumas forças fundamentais.

Acoplamento.

Distribuição.

Complexidade.

Quando dividimos uma aplicação fisicamente sem reduzir suficientemente o acoplamento lógico, obtemos o pior dos dois mundos.

Carregamos problemas do monólito...

e adicionamos problemas de sistemas distribuídos.

---

🔎 CAPÍTULO 16 — O checklist Charlie Chan

Antes de criar CustomerService, PaymentService ou WhateverService, Charlie Chan faria perguntas.

Não começaria perguntando:

Qual framework vamos utilizar?

Perguntaria:

Existe uma fronteira real de domínio?

Depois:

Esse componente precisa evoluir independentemente?

Precisa ser implantado independentemente?

Possui necessidades próprias de escala?

Precisa de isolamento operacional?

Existe ownership claramente definido?

Se ficar indisponível, o restante do sistema consegue continuar funcionando?

Quem possui seus dados?

Quantas chamadas serão necessárias para completar uma operação?

Como rastrearemos uma transação entre os componentes?

Como trataremos consistência?

Como evoluiremos contratos?

E existe uma pergunta especialmente incômoda:

Que problema concreto seria impossível — ou significativamente pior — resolver mantendo este componente dentro de um monólito modular?

Se ninguém souber responder...

Charlie Chan já encontrou uma pista.

---

🧠 EPÍLOGO — O mistério nunca foi COBOL versus microservices

Ao final da investigação, o jovem programador perguntou:

— Mestre Chan, então microserviços são ruins?

Charlie Chan sorriu.

Essa seria uma conclusão fácil demais.

Microservices podem ser extraordinários quando suas características resolvem problemas reais.

Grandes organizações podem precisar de autonomia entre equipes.

Partes específicas podem possuir escalabilidade completamente diferente.

Certos domínios podem precisar de ciclos de release independentes.

Alguns componentes podem exigir isolamento de falhas.

Tecnologias diferentes podem ser apropriadas para problemas diferentes.

Há excelentes motivos para distribuir sistemas.

O erro está em confundir:

DISTRIBUIÇÃO

com:

MODERNIZAÇÃO

ou:

QUANTIDADE DE SERVIÇOS

com:

QUALIDADE ARQUITETURAL

Uma aplicação não se torna moderna porque ganhou 200 containers.

Assim como um sistema COBOL não se torna ruim simplesmente porque nasceu há quarenta anos.

Arquitetura precisa ser julgada pelas propriedades que entrega.

Charlie Chan fechou seu caderno.

Na última página havia apenas uma frase:

“Quando vinte microserviços precisam concordar para mudar uma linha, procure novamente. Monólito pode estar usando vinte disfarces.”

Ele caminhou em direção à porta.

Então parou.

Voltou ao terminal.

Abriu o trace do incidente mais uma vez.

Havia uma informação que ninguém percebera.

TRACE-ID: CHAN-0317
TIMESTAMP: 03:17:00

Chan sorriu.

O programador COBOL arregalou os olhos.

— 03:17 outra vez?

Charlie Chan colocou o chapéu.

— Alguns mistérios pertencem à arquitetura.

E saiu.

No Bellacosa Mainframe, entretanto, todos já sabiam:

se aconteceu às 03:17, o incidente ainda não terminou. ☕🕵️

---

☕ MORAL DO CASO

A grande lição para quem está começando em COBOL — ou estudando arquitetura moderna — é surpreendentemente simples:

não modernizamos um sistema trocando nomes antigos por nomes modernos.

Trocar:

PROGRAM

por:

SERVICE

não elimina acoplamento.

Trocar:

COPYBOOK

por:

JSON

não elimina contratos.

Trocar:

CALL

por:

REST

não elimina dependências.

Trocar:

COMMIT

por:

EVENTS

não elimina consistência.

E trocar:

MONOLITH

por:

MICROSERVICES

não produz automaticamente uma boa arquitetura.

Às vezes produz algo muito mais curioso:

        MONÓLITO
           +
          REDE
           +
     200 CONTAINERS
           +
        KAFKA
           +
     KUBERNETES
           =
           
DISTRIBUTED MONOLITH

E talvez essa seja a pista mais importante deixada por Charlie Chan:

tecnologia muda. Os nomes mudam. As ferramentas mudam. Mas dependência, acoplamento, responsabilidade, falha, dados e complexidade continuam sentados na mesma sala de interrogatório.

O bom arquiteto não pergunta primeiro:

“Como transformamos isto em microserviços?”

Pergunta:

“Qual problema estamos tentando resolver?”

Somente depois escolhe a arquitetura.

Porque, como descobriríamos naquela madrugada no Bellacosa Mainframe, às vezes o velho COBOL acusado de todos os crimes estava tranquilamente processando sua transação em 38 milissegundos.

Os outros 1.805 milissegundos estavam ocupados sendo modernos. ☕🕵️‍♂️💻