 |
| Bellacosa Mainframe e a arquitetura do Nubank |
☕ Um Café no Bellacosa Mainframe
The IT Crowd encontra o Nubank: o Dia em que o COBOLzeiro Entrou na Nuvem, Viu Kubernetes, Clojure, Datomic e Perguntou Onde Esconderam o CICS
💳 AWS, microserviços, containers, bancos imutáveis, observabilidade, FinOps, IA e o estranho caso de uma instituição com mais de 100 milhões de clientes que resolveu problemas antigos com ferramentas completamente novas — enquanto o veterano do CPD repetia: “Have you tried turning it off and on again?”
Imagine o porão de um departamento de informática.
Luzes fluorescentes.
Cabos.
Monitores.
Uma caneca esquecida ao lado do teclado.
Um cartaz na parede:
HAVE YOU TRIED TURNING IT OFF AND ON AGAIN?
Roy está sentado olhando para um terminal.
Moss aparece carregando uma pilha de livros.
Na porta surge um programador COBOL iniciante.
Ele segura um notebook.
Na tela:
KUBERNETES
CLOJURE
DATOMIC
AWS
MICROSERVICES
CONTAINERS
Roy olha.
— O que é isso?
O novato responde:
— Estou estudando a arquitetura do Nubank.
Moss imediatamente se interessa.
— Nubank? Fascinante. Instituição financeira digital, arquitetura distribuída, alta escalabilidade...
Roy interrompe:
— Quantas agências?
— Nenhuma.
— Nenhum mainframe?
— Pelo menos não como fundamento público da arquitetura original.
— E atende mais de cem milhões de clientes?
— Sim.
Roy fica em silêncio.
Olha para Moss.
Olha novamente para o novato.
— Então onde esconderam o CICS?
☕
Bem-vindo a mais um Um Café no Bellacosa Mainframe.
Hoje vamos entrar numa das comparações mais interessantes para quem está começando COBOL e quer entender por que o mundo moderno fala tanto de cloud-native, microserviços, containers, Kubernetes e bancos de dados diferentes.
Nosso laboratório será o Nubank.
Não para declarar que cloud venceu mainframe.
Nem para dizer que mainframe é superior à cloud.
Essas guerras religiosas normalmente produzem mais calor do que conhecimento.
A pergunta realmente interessante é:
Como uma instituição financeira que nasceu na nuvem conseguiu crescer até uma escala gigantesca resolvendo problemas que bancos tradicionais enfrentam há décadas?
E mais importante:
Quantos desses problemas são realmente novos?
Spoiler:
Pouquíssimos.
As tecnologias mudaram.
Os problemas fundamentais continuam terrivelmente familiares.
Pegue o café.
Vamos descer ao porão.
1. Primeiro: esqueça o aplicativo roxo
Quando alguém olha para o Nubank, normalmente vê:
APP
CARTÃO ROXO
PIX
CONTA
EMPRÉSTIMO
O profissional de infraestrutura deveria enxergar outra coisa.
Por trás daquele botão bonito existe algo mais parecido com:
CLIENTE
|
v
APLICATIVO
|
v
APIs
|
v
SERVIÇOS
|
v
CORE FINANCEIRO
|
v
DADOS
|
v
EVENTOS
|
v
AUDITORIA
|
v
SEGURANÇA
E ainda:
ANTIFRAUDE
CRÉDITO
KYC
COMPLIANCE
OBSERVABILIDADE
LOGS
BACKUP
DR
CAPACITY
IA
Então guarde uma regra.
Interface simples não significa sistema simples.
O cliente toca em:
PAGAR
e espera:
PAGO
Entre uma coisa e outra pode existir uma pequena guerra civil distribuída.
É justamente aí que Nubank e mainframe começam a ficar curiosamente parecidos.
2. O banco tradicional construiu uma fortaleza
Grandes bancos cresceram durante décadas.
Muitos construíram arquiteturas centradas em:
IBM Z
COBOL
CICS
DB2
IMS
VSAM
MQ
JCL
RACF
Essas tecnologias não apareceram por acaso.
Elas resolvem problemas reais.
Consistência.
Volume.
Disponibilidade.
Segurança.
Recuperação.
Processamento transacional.
Auditoria.
Controle de carga.
Imagine algo conceitualmente parecido:
CLIENTE
|
v
CANAL
|
v
CICS
|
v
PROGRAMA COBOL
|
v
DB2 / VSAM / IMS
|
v
MQ / BATCH / CONTABILIDADE
Agora multiplique isso por:
décadas
milhares de programas
milhões de clientes
centenas de integrações
Pronto.
Você tem um banco.
Ou um monstro mitológico.
Depende do horário do incidente.
3. Nubank começou pelo outro lado
O Nubank nasceu já pensando em cloud.
Esse detalhe muda tudo.
Um banco tradicional frequentemente precisa modernizar sistemas existentes.
O Nubank pôde construir de maneira greenfield.
Greenfield significa basicamente:
“Ainda não temos quarenta anos de decisões para carregar.”
Isso é uma vantagem brutal.
Imagine duas equipes.
A primeira recebe:
SISTEMA X
CRIADO EM 1989
ALTERADO 12.417 VEZES
AUTOR ORIGINAL APOSENTADO
DOCUMENTAÇÃO: TALVEZ
A segunda recebe:
README.md
É outro planeta.
Mas não se engane.
O segundo sistema eventualmente também vira o primeiro.
Só precisa sobreviver tempo suficiente.
4. AWS: o CPD terceirizado
Uma maneira divertida de explicar cloud para um veterano seria:
Você não eliminou o datacenter.
Você terceirizou uma enorme parte dele.
No modelo tradicional:
BANCO
|
+-- DATACENTER
|
+-- SERVIDORES
+-- STORAGE
+-- REDE
+-- ENERGIA
+-- DR
No modelo cloud:
BANCO
|
+-- AWS
|
+-- COMPUTE
+-- STORAGE
+-- NETWORK
+-- DATABASE
+-- SECURITY
Fisicamente continuam existindo máquinas.
CPUs.
Memória.
SSD.
Switches.
Cabos.
Energia elétrica.
O que mudou foi o modelo operacional.
Você pede recursos por software.
Escala.
Cria ambientes.
Destrói ambientes.
Automatiza infraestrutura.
Isso reduz dramaticamente o tempo entre:
PRECISO DE SERVIDOR
e:
SERVIDOR EXISTE
Quem viveu compras corporativas tradicionais entenderá imediatamente a importância disso.
5. A nuvem não é infinita
Aqui aparece um dos maiores mitos.
Muita gente imagina:
CLOUD = INFINITO
Não.
Cloud continua limitada por física.
Em algum ponto existem:
CPU
RAM
SSD
REDE
ENERGIA
DATACENTER
Uma empresa suficientemente grande pode encontrar limites que empresas pequenas jamais verão.
É quase como alguém perguntando:
— A internet aguenta?
Roy responde:
— Depende.
Moss:
— Tecnicamente a internet está naquela pequena caixa preta ali.
Se você entendeu essa referência, parabéns.
Você ganhou o primeiro Easter egg.
6. Clojure: porque Java seria normal demais
Uma das escolhas técnicas mais interessantes do Nubank foi Clojure.
Clojure é uma linguagem funcional da família Lisp executada sobre JVM.
Para quem vem de COBOL, isso parece inicialmente uma linguagem alienígena.
COBOL:
IF SALDO > LIMITE
DISPLAY 'OPERACAO RECUSADA'
END-IF
Lisp-like:
(parênteses
(dentro
(de
(parênteses))))
O COBOLzeiro olha.
Moss aparece.
— É extremamente elegante.
Roy responde:
— Parece que alguém derrubou a caixa de parênteses.
Mas existe racionalidade por trás da escolha.
Linguagens funcionais favorecem conceitos como:
imutabilidade
funções puras
composição
transformação de dados
Isso pode ser interessante em sistemas distribuídos.
Porque estado compartilhado é uma fonte clássica de sofrimento.
E sofrimento distribuído escala muito bem.
7. Datomic: o banco que gosta do passado
Agora chegamos a uma ideia deliciosa.
Em muitos bancos relacionais tradicionais pensamos no estado atual.
Exemplo:
SALDO = 1000
Depois:
SALDO = 800
Atualizamos o registro.
Mas no mundo financeiro o passado importa muito.
Quem alterou?
Quando?
Qual era o estado anterior?
Qual evento produziu o estado atual?
Datomic trabalha com uma filosofia fortemente temporal e imutável.
Conceitualmente:
T0 SALDO = 1000
T1 COMPRA = -200
T2 SALDO = 800
O histórico não desaparece simplesmente.
Para um COBOLzeiro isso desperta uma sensação familiar.
Ele pensa:
— Então vocês guardam histórico?
Sim.
— E querem reconstruir estado?
Sim.
— E auditoria?
Sim.
— E temporalidade?
Sim.
O veterano dá um gole no café.
— Conheço esse filme.
8. A imutabilidade é uma obsessão financeira antiga
Sistemas financeiros gostam de histórico porque dinheiro deixa rastros.
Em muitos casos não queremos:
DELETE
Queremos:
REVERSAO
Por quê?
Porque apagar o passado é péssimo para auditoria.
Imagine:
TRANSAÇÃO 100
TRANSAÇÃO -100
É muito diferente de:
NUNCA EXISTIU
Essa diferença conceitual é crítica.
Sistemas modernos chamam isso de:
event sourcing
immutable data
audit history
O veterano do mainframe talvez diga:
— Interessante.
Depois acrescenta:
— Em 1987 nós chamávamos de “não apague esse registro porque a auditoria vai perguntar”.
9. Microserviços: cada problema ganha sua casinha
Arquiteturas modernas frequentemente dividem sistemas em serviços menores.
Algo como:
CARTÃO
|
+-- limite-service
+-- transaction-service
+-- fraud-service
+-- notification-service
+-- customer-service
Cada serviço pode ter:
código
deployment
dados
observabilidade
equipe
Isso oferece vantagens.
Escalabilidade independente.
Implantação independente.
Domínios separados.
Equipes autônomas.
Mas também cria problemas.
Muitos problemas.
Agora você precisa administrar:
rede
latência
timeout
retry
idempotência
consistência
service discovery
tracing
versionamento
contratos
O sistema que antes tinha chamadas internas agora possui rede entre pedaços.
E existe uma máxima importante:
A rede sempre encontra maneiras criativas de lembrar que existe.
10. O COBOLzeiro conhece microserviços melhor do que pensa
Imagine um banco tradicional com:
CICS REGION A
CICS REGION B
MQ
DB2
BATCH
IMS
Você já possui componentes distribuídos.
Já possui fronteiras.
Já possui mensageria.
Já possui sistemas independentes.
A diferença é que arquiteturas cloud-native tornam essas divisões muito mais granulares.
Então quando alguém disser:
“Microservices revolucionaram tudo.”
Você pode responder:
— Sim, revolucionaram muita coisa.
Mas alguns problemas são velhos.
Por exemplo:
COMO GARANTIR QUE A MESMA OPERAÇÃO NÃO SEJA EXECUTADA DUAS VEZES?
Isso se chama:
IDEMPOTÊNCIA
No mainframe talvez você não usasse esse termo diariamente.
Mas o problema já existia.
11. Kubernetes: o gerente dos containers
Agora surge Kubernetes.
Imagine milhares de pequenos serviços.
Cada um rodando em containers.
Você precisa controlar:
onde roda
quantas cópias
quando reiniciar
como atualizar
como escalar
como descobrir
Kubernetes tenta resolver essa orquestração.
Conceitualmente:
KUBERNETES
|
+-- POD A
+-- POD B
+-- POD C
+-- POD D
Se um morre:
RESTART
Se precisa de mais capacidade:
SCALE
Se uma versão nova chega:
ROLLING UPDATE
Um veterano do mainframe olha para isso e pensa:
“Então vocês construíram um sistema que administra workload, disponibilidade e recursos?”
Sim.
O veterano:
— Interessante.
WLM tossindo discretamente no canto.
12. WLM encontra Kubernetes no corredor
Essa comparação é deliciosa.
Não são tecnologias equivalentes.
Mas ambas convivem com perguntas semelhantes.
QUEM PRECISA DE RECURSO?
QUANTO?
COM QUAL PRIORIDADE?
ONDE EXECUTAR?
COMO REAGIR A CARGA?
No mainframe:
WLM
service classes
importance
goals
No cloud-native:
requests
limits
autoscaling
scheduling
pods
nodes
Mudou o vocabulário.
O problema continua sendo:
recursos são finitos.
Moss explica Kubernetes durante vinte minutos.
Roy resume:
— Basicamente você tem um monte de computadores e precisa impedir que eles façam besteira.
Moss:
— Tecnicamente incorreto.
Roy:
— Mas funcionalmente preciso.
13. Containers não são máquinas virtuais pequeninas
Essa é uma boa dica para o iniciante.
Container não é simplesmente:
VM PEQUENA
Ele compartilha o kernel do host e empacota aplicação e dependências de maneira isolada.
Isso torna deployment mais previsível.
A clássica frase:
NA MINHA MÁQUINA FUNCIONA
vira:
ENTÃO EMPACOTE SUA MÁQUINA
Não literalmente.
Mas quase.
Essa é uma das grandes contribuições dos containers:
reduzir diferenças entre ambientes.
Dev.
Teste.
Produção.
Todos executam artefatos semelhantes.
O sysprog antigo entende imediatamente o valor disso.
Ambiente diferente é combustível para incidente.
14. Observabilidade: porque agora ninguém sabe onde o erro aconteceu
Em um sistema distribuído, uma transação pode atravessar:
APP
↓
API
↓
SERVICE A
↓
SERVICE B
↓
DATABASE
↓
EVENT BUS
↓
SERVICE C
Quando algo falha, surge a pergunta:
ONDE?
Observabilidade tenta responder usando:
logs
metrics
traces
events
Tracing distribuído é especialmente importante.
Você pode acompanhar uma transação atravessando vários serviços.
Para o mundo mainframe isso lembra a necessidade histórica de:
SMF
RMF
CICS statistics
DB2 traces
logs
dumps
Novamente:
tecnologia nova.
Problema velho.
15. SMF provavelmente olharia para observability e diria “fofo”
Brincadeiras à parte, SMF é uma das grandes fontes históricas de telemetria de z/OS.
O mainframe registra uma quantidade extraordinária de informação operacional.
CPU.
Jobs.
I/O.
Segurança.
Subsistemas.
Performance.
Cloud-native descobriu sua própria versão desse universo.
Prometheus.
OpenTelemetry.
Grafana.
Tracing.
Logs centralizados.
A filosofia é semelhante:
se não consigo medir, não consigo administrar.
Esse é um princípio universal.
16. O custo da nuvem: a pergunta que ninguém responde com um número simples
Quanto custa atender 100 milhões de clientes?
Não existe resposta direta.
Porque:
100 MILHÕES DE CLIENTES
não significa:
100 MILHÕES DE CLIENTES ATIVOS AO MESMO TEMPO
Você precisa conhecer:
transações por segundo
storage
network
database I/O
logs
backups
replicação
ML
fraude
analytics
DR
Uma fórmula simplificada seria:
CLOUD COST =
COMPUTE
+ STORAGE
+ DATABASE
+ NETWORK
+ OBSERVABILITY
+ SECURITY
+ BACKUP
+ ANALYTICS
+ ML
Depois vem:
- otimização
- contratos
- reservas
- descontos
E aparece uma nova profissão:
FinOps
17. FinOps: o capacity planner voltou usando tênis
FinOps é a disciplina de administrar financeiramente consumo de cloud.
Porque existe uma armadilha.
Cloud facilita criar recursos.
Muito fácil.
Talvez fácil demais.
Alguém faz:
CREATE INSTANCE
Depois esquece.
Ela continua ligada.
Por semanas.
Meses.
Até alguém encontrar a conta.
No mainframe sempre existiu obsessão com:
CPU
MSU
MIPS
SOFTWARE COST
Cloud reintroduziu a mesma disciplina com nomes diferentes:
vCPU
instance hours
storage
egress
reserved instances
savings plans
O gestor antigo olha.
— Então consumo computacional continua custando dinheiro?
Sim.
— Fascinante.
18. AWS Graviton e os 14%
Uma das otimizações interessantes atribuídas publicamente ao Nubank foi adoção de processadores AWS Graviton.
A motivação é simples:
melhor relação custo/performance em determinados workloads.
Quando uma organização desse tamanho reduz uma fatia percentual relevante do custo de computação, isso pode representar muito dinheiro.
E aqui surge uma lição importante.
Em escala:
1% = DINHEIRO
Muito dinheiro.
No sistema pequeno, otimizar 3% é luxo.
No sistema gigante, pode financiar uma equipe inteira.
Isso é algo que mainframe conhece há décadas.
19. Performance engineering não morreu
Às vezes existe uma ideia ingênua:
cloud elimina preocupação com performance.
Não.
Ela pode tornar performance comprável.
Mas ainda custa.
Se um serviço usa o dobro de CPU porque o código é ruim:
CONTA = DOBRO
aproximadamente, dependendo da carga.
Então aquele velho programador obcecado por eficiência não estava completamente errado.
Talvez estivesse apenas trinta anos adiantado para a reunião de FinOps.
20. Sharding: quando um banco de dados começa a ficar apertado
Quando um banco cresce, existe outro problema.
Dados.
Muito dado.
Em algum momento você pode dividir os dados entre várias unidades.
Isso é sharding.
Imagine:
CLIENTES A-F -> SHARD 1
CLIENTES G-M -> SHARD 2
CLIENTES N-S -> SHARD 3
CLIENTES T-Z -> SHARD 4
É apenas um exemplo.
Na prática estratégias podem ser muito mais sofisticadas.
Sharding resolve alguns problemas.
E cria outros.
Sempre existe essa regra da arquitetura:
Toda solução resolve um problema e ganha três novos de bônus.
Agora surgem questões:
rebalanceamento
hotspots
consistência
roteamento
falhas
migração
Roy olha.
— Parece complicado.
Moss:
— É porque é.
21. Banco distribuído é um casamento entre física e filosofia
Quando dados estão distribuídos, surgem perguntas como:
SE DOIS NÓS DISCORDAM, QUEM ESTÁ CERTO?
Ou:
O QUE ACONTECE SE A REDE CAIR?
Ou:
QUANDO UMA TRANSAÇÃO ESTÁ REALMENTE CONFIRMADA?
Isso nos leva a consistência distribuída.
CAP theorem.
Quórum.
Replicação.
Consensus.
Eventual consistency.
Termos modernos.
Mas bancos sempre tiveram obsessão por:
ACID
COMMIT
ROLLBACK
LOCK
LOG
RECOVERY
Porque dinheiro não aceita filosofia muito abstrata.
O saldo precisa fechar.
22. Cloud-native não elimina contabilidade
Esse ponto parece óbvio.
Mas é importante.
Você pode usar:
Kubernetes
Clojure
Kafka
Datomic
AI
No fim do dia:
DÉBITO = CRÉDITO
A contabilidade continua lá.
Pode mudar a arquitetura.
Pode mudar o deployment.
Pode mudar o banco de dados.
Não muda a matemática.
Esse é o tipo de realidade que une mainframe e fintech.
23. IA agora entra no salão
Com escala gigantesca, atendimento também vira tecnologia.
Imagine milhões de perguntas:
onde está meu cartão?
por que meu limite caiu?
qual minha fatura?
como bloquear?
como negociar dívida?
Atender tudo apenas com humanos custa muito.
Então IA começa a entrar.
Chatbots.
Modelos.
Agentes.
Classificação.
Automação.
Mas agora o problema muda.
Uma IA pode responder errado.
Em banco, resposta errada pode virar:
reclamação
fraude
prejuízo
risco regulatório
Então surge outro desafio:
automação precisa ser auditável.
O mundo tecnológico moderno eventualmente descobre o mesmo princípio do mainframe:
TRUST, BUT LOG EVERYTHING.
24. Segurança: zero confiança, muitos logs
Banco digital é um alvo gigantesco.
Então precisa de:
IAM
MFA
secrets
encryption
network controls
fraud detection
monitoring
audit
No mainframe temos:
RACF
ACF2
Top Secret
SAF
profiles
permissions
logs
Novamente:
novo vocabulário.
Mesmo problema fundamental:
WHO ARE YOU?
WHAT CAN YOU DO?
WHAT DID YOU DO?
Essas três perguntas praticamente resumem segurança corporativa.
25. O curioso caso do “legado cloud”
Agora uma provocação.
Nubank nasceu moderno.
Mas qualquer plataforma suficientemente antiga cria legado.
Se um microsserviço criado em 2015 ainda existe em 2035, ele será legado.
Legado não é:
COBOL
Legado é:
software importante que sobreviveu.
Essa definição é muito mais útil.
Java vira legado.
Python vira legado.
Kubernetes vira legado.
Seu framework JavaScript favorito provavelmente já nasceu legado enquanto você lia esta frase.
26. O mainframe possui uma vantagem obscena
Existe algo que cloud-native frequentemente tenta reconstruir:
simplicidade operacional centralizada.
No mainframe você pode ter enorme quantidade de workloads dentro de uma plataforma extremamente integrada.
No mundo distribuído você ganha flexibilidade.
Mas paga em complexidade.
Milhares de containers.
Centenas de serviços.
Networking.
Observabilidade.
CI/CD.
Secrets.
Deployments.
Dependencies.
Service mesh.
Moss começa a explicar service mesh.
Roy levanta a mão.
— Não.
Moss:
— Mas é fascinante.
— Não.
27. Cloud possui outra vantagem obscena
Agora o outro lado.
Provisionamento.
Automação.
Experimentação.
Escalabilidade.
Velocidade de desenvolvimento.
Um time pode criar infraestrutura via código.
terraform apply
E ambientes aparecem.
Compare com processos históricos:
FORMULÁRIO
APROVAÇÃO
COMPRA
ENTREGA
INSTALAÇÃO
CONFIGURAÇÃO
Cloud mudou radicalmente o ciclo.
Isso foi crucial para empresas que cresceram rápido.
28. Arquitetura segue organização
Conforme a empresa cresce, aparece um problema humano.
Imagine:
10 engenheiros
Todo mundo conversa.
Agora:
100
Complica.
Agora:
1000
Você criou uma cidade.
Precisará de:
equipes
domínios
ownership
standards
platform engineering
governança
A Lei de Conway basicamente diz que sistemas tendem a refletir estruturas de comunicação das organizações.
Ou seja:
organograma também produz arquitetura.
Essa é uma verdade subestimada.
29. O programa COBOL também é arquitetura organizacional fossilizada
Pegue um programa antigo.
Ele talvez tenha:
PARA-CALCULA-TARIFA
PARA-AUTORIZA-LIMITE
PARA-GERA-HISTORICO
Por que esses módulos existem?
Talvez porque em 1994 existiam departamentos diferentes.
Arquitetura captura decisões humanas.
Software é arqueologia organizacional.
Isso vale igualmente para microservices.
Daqui a vinte anos alguém perguntará:
— Por que existem 417 serviços para processar uma fatura?
Resposta:
— Era assim que os squads estavam organizados em 2026.
😂
30. Passo a passo para um COBOLzeiro estudar arquitetura Nubank
Agora uma rota prática.
Passo 1 — Domine transações
Entenda:
COMMIT
ROLLBACK
ACID
LOCK
RECOVERY
Sem isso, arquitetura financeira vira decoração PowerPoint.
Passo 2 — Estude CICS
Entenda:
transaction manager
task
region
program
resource
Depois compare com serviços modernos.
Passo 3 — Estude Db2
Aprenda:
index
transaction
isolation
logging
recovery
Depois veja bancos distribuídos.
Passo 4 — Estude MQ
Mensageria é ponte perfeita entre os mundos.
Entenda:
queue
producer
consumer
delivery
retry
Depois Kafka e event-driven ficam muito mais fáceis.
Passo 5 — Estude containers
Docker primeiro.
Kubernetes depois.
Não comece tentando decorar YAML de 300 linhas.
Entenda o problema antes da ferramenta.
Passo 6 — Estude observabilidade
Compare:
SMF/RMF
com:
metrics/logs/traces
Passo 7 — Estude cloud economics
Aprenda:
compute
storage
network
database
egress
Depois FinOps.
Passo 8 — Estude arquitetura distribuída
Especialmente:
latency
timeout
retry
idempotency
consistency
partition
Passo 9 — Estude segurança
Compare:
RACF
com:
IAM
Passo 10 — Nunca aceite desenho de arquitetura sem perguntar:
WHAT HAPPENS WHEN THIS FAILS?
Essa pergunta vale mais que cem certificações.
31. Easter egg final: desligar e ligar não resolve tudo
Roy provavelmente tentaria:
— Have you tried turning Kubernetes off and on again?
Moss entraria em pânico.
— Não se desliga Kubernetes dessa maneira!
Roy:
— Então por que chamam de cluster?
Jen pisaria num cabo.
Produção cairia.
Alguém abriria um Sev1.
O COBOLzeiro no canto ficaria olhando.
Depois perguntaria:
— Existe rollback?
Silêncio.
— Existe backup?
Mais silêncio.
— Existe DR?
Moss:
— Naturalmente.
O veterano sorri.
Agora eles finalmente falam a mesma língua.
32. A grande conclusão
Nubank e mainframe representam épocas diferentes da engenharia.
Um nasceu em um mundo de:
cloud
smartphone
APIs
containers
distributed systems
Outro consolidou-se num mundo de:
centralized computing
transaction processing
batch
terminals
Mas ambos enfrentam:
dinheiro
estado
risco
falha
segurança
volume
auditoria
performance
E esses problemas não respeitam moda tecnológica.
É por isso que comparar Nubank com mainframe é tão interessante.
Você descobre que muitas vezes não estamos reinventando o problema.
Estamos reinventando a solução.
Às vezes melhor.
Às vezes apenas diferente.
Às vezes mais barata.
Às vezes mais rápida.
Às vezes mais complicada.
Às vezes todas essas coisas ao mesmo tempo.
Epílogo — O chamado do incidente
São 02:47 da manhã.
O celular toca.
Produção.
Roy atende.
— IT.
Do outro lado:
— Os pagamentos estão lentos.
Roy:
— Have you tried turning it off and on again?
Moss arranca o telefone.
— NÃO!
O programador COBOL olha para o dashboard.
CPU normal.
Banco normal.
Rede estranha.
Um serviço está repetindo requisições após timeout.
Retry.
Retry.
Retry.
Milhares.
Ele pergunta:
— As operações são idempotentes?
Moss congela.
Roy pergunta:
— Isso é alguma religião?
O COBOLzeiro dá um gole no café.
— Não.
Aponta para a tela.
— É a diferença entre cobrar uma vez e cobrar três.
Silêncio.
Finalmente todos entendem.
Porque por trás de:
AWS
CLOJURE
DATOMIC
KUBERNETES
MICROSERVICES
AI
continua existindo a pergunta mais antiga do sistema bancário:
O dinheiro chegou ao lugar certo, uma única vez, e conseguimos provar isso?
Se a resposta for sim, o sistema está funcionando.
Se a resposta for não...
bem...
ligue para o CPD.
☕
Sem comentários:
Enviar um comentário