 |
| Bellacosa Mainframe e o IBM Confluent |
☕ Um Café no Bellacosa Mainframe
🧭 MARCO POLO E A ROTA DA SEDA DIGITAL — QUANDO O COBOL DESCOBRIU O IBM CONFLUENT
COBOL, CICS, Db2, IBM MQ, Apache Kafka, IBM Confluent, CDC, IBM Data Gate, Kafka Connect, Topics, Partitions, Offsets, Schema Registry, Flink, APIs, Cloud, IA — e o dia em que Marco Polo descobriu que o mainframe não precisava viajar para que seus dados atravessassem o mundo.
Sob a tutela de Marco Polo, mercador, explorador e contador de histórias de mundos que pareciam impossivelmente distantes — até alguém construir uma rota entre eles.
🎬 PRÓLOGO — NÃO PRECISAMOS MOVER O IMPÉRIO
Imagine um jovem programador COBOL diante de um terminal.
Na tela:
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - :WS-VALOR
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
EXEC SQL
COMMIT
END-EXEC.
Ele olha para aquilo e pensa:
— Pronto. Transferência concluída.
Marco Polo, sentado ao lado do terminal com um mapa enorme aberto sobre a mesa, pergunta:
— E quem ficou sabendo?
O programador responde:
— O Db2.
Marco continua:
— E o sistema antifraude?
Silêncio.
— O aplicativo mobile?
Mais silêncio.
— O Data Lake?
Silêncio novamente.
— O sistema de analytics?
O programador começa a desconfiar daquela conversa.
— E a inteligência artificial?
Finalmente ele responde:
— Marco... o que você quer exatamente?
Marco Polo aponta para o COMMIT.
— Quero construir uma rota daqui até lá.
E assim começa nossa viagem.
Porque IBM Confluent não é simplesmente "mais uma ferramenta de integração".
Para compreender sua importância dentro do universo mainframe precisamos entender uma mudança conceitual muito maior:
transformar dados armazenados em dados em movimento.
🗺️ CAPÍTULO 1 — O MAINFRAME NÃO É UMA ILHA
Durante décadas, empresas construíram seus sistemas centrais sobre tecnologias como:
COBOL
CICS
IMS
Db2
VSAM
JCL
IBM MQ
E esses sistemas continuam processando quantidades gigantescas de transações.
Banco.
Cartão.
Seguro.
Companhia aérea.
Varejo.
Governo.
Logística.
Imagine nosso IBM Z como uma grande cidade comercial.
Dentro dela existem mercados:
CICS
Armazéns:
Db2
VSAM
IMS DB
Mensageiros:
IBM MQ
Funcionários:
COBOL
PL/I
Java
Guardas:
RACF
E registros das atividades da cidade:
SMF
Tudo funciona.
O problema aparece quando outras cidades precisam saber rapidamente o que aconteceu.
Cloud.
Aplicações mobile.
Analytics.
Data Lakes.
Sistemas antifraude.
Machine Learning.
IA generativa.
Agentes de IA.
Marco Polo olha para o mapa e percebe:
O problema não é necessariamente reconstruir a cidade. Precisamos construir rotas comerciais.
Essa distinção é fundamental.
Modernização não significa obrigatoriamente:
MAINFRAME
|
v
MIGRAR TUDO
|
v
CLOUD
Pode significar:
IBM Z
|
SYSTEM OF RECORD
|
v
EVENT STREAM
|
+--------+--------+
| | |
Cloud IA Analytics
O COBOL continua processando a transação.
O dado viaja.
🐫 CAPÍTULO 2 — A ROTA DA SEDA DOS DADOS
A antiga Rota da Seda não transportava apenas seda.
Transportava:
mercadorias;
informações;
tecnologias;
culturas;
ideias;
conhecimento.
Confluent faz algo conceitualmente parecido com dados.
Imagine que uma transação ocorreu:
TRANSFERÊNCIA
Conta: 123456
Valor: R$ 850
No mundo tradicional podemos pensar:
COBOL
|
v
CICS
|
v
Db2
|
v
COMMIT
O banco de dados agora sabe que o saldo mudou.
Mas o restante da empresa talvez também precise saber.
Podemos representar esse acontecimento como um evento:
{
"eventType": "TRANSFER_COMPLETED",
"account": "123456",
"amount": 850.00,
"currency": "BRL"
}
Agora começa a viagem:
IBM Z
|
v
EVENTO
|
v
CONFLUENT / KAFKA
|
+------> Antifraude
|
+------> Mobile
|
+------> Analytics
|
+------> Data Lake
|
+------> IA
Uma transação ocorreu uma vez.
Mas vários sistemas podem ter interesse nela.
Essa é uma das ideias centrais do event streaming.
📜 CAPÍTULO 3 — ESTADO E ACONTECIMENTO NÃO SÃO A MESMA COISA
Considere:
CONTA: 123456
SALDO: R$ 4.150
Isso representa estado.
Agora observe:
09:00 PIX recebido +1000
10:14 Compra -200
12:07 Saque -300
14:32 Depósito +500
18:44 Transferência -850
Isso representa uma sequência de acontecimentos.
Essa diferença parece pequena.
Mas arquiteturalmente é enorme.
O banco de dados responde muito bem:
Qual é o estado atual?
Um stream de eventos ajuda a responder:
O que aconteceu?
E principalmente:
O que está acontecendo?
📻 CAPÍTULO 4 — APACHE KAFKA: A ESTAÇÃO COMERCIAL DA ROTA
No coração do ecossistema Confluent encontramos o Apache Kafka.
Kafka é uma plataforma distribuída de event streaming.
Para começar, nosso jovem COBOLero precisa conhecer quatro palavras:
Producer
Topic
Consumer
Event
Imagine:
PRODUCER
|
| publica evento
v
TOPIC
|
+------> CONSUMER A
|
+------> CONSUMER B
|
+------> CONSUMER C
Um producer produz eventos.
Um topic organiza eventos.
Consumers consomem eventos.
Parece simples.
E conceitualmente é.
O poder aparece quando colocamos milhões ou bilhões de acontecimentos nessa estrada.
🏷️ CAPÍTULO 5 — TOPIC: A PLACA DA ESTRADA
Imagine uma cidade com diferentes rotas:
payments
customers
accounts
card-transactions
fraud-alerts
No Kafka podemos ter topics semelhantes:
bank.payments
bank.accounts
bank.transactions
bank.fraud
Cada topic representa determinado fluxo de eventos.
Por exemplo:
bank.transactions
poderia receber:
Compra
Compra
PIX
Saque
Transferência
Compra
Depósito
Pense no topic como uma estrada especializada.
Marco Polo não coloca:
seda
cavalos
pimenta
ouro
documentos secretos
sem nenhuma organização na mesma carroça.
Boa arquitetura exige organização.
🧩 CAPÍTULO 6 — PARTITIONS: QUANDO UMA ESTRADA NÃO É SUFICIENTE
Agora imagine:
100 eventos por segundo
Tudo bem.
Mas o banco cresce.
Temos:
100.000 eventos por segundo
Uma única rota pode tornar-se insuficiente.
Kafka permite dividir um topic em partitions:
PAYMENTS
|
+------------+------------+
| | |
v v v
Partition 0 Partition 1 Partition 2
Isso possibilita paralelismo.
Diferentes consumers podem processar diferentes partitions simultaneamente.
O mainframeiro já conhece a ideia geral:
Dividir trabalho mantendo controle.
Nada de particularmente alienígena.
Só trocaram as placas da estrada.
🔑 CAPÍTULO 7 — KEY: NÃO MANDE A CARROÇA ERRADA
Existe um problema.
Imagine eventos da conta:
123456
Chegam:
DEPÓSITO
SAQUE
TRANSFERÊNCIA
COMPRA
A ordem pode ser importante.
Muito importante.
Em Kafka podemos utilizar uma key.
Por exemplo:
KEY = ACCOUNT_NUMBER
Eventos com determinada chave podem ser encaminhados consistentemente para a mesma partition.
Assim conseguimos preservar ordenação dentro daquela partition.
Para sistemas financeiros isso é crucial.
Porque:
CREDITAR 100
DEBITAR 100
pode representar uma história diferente de:
DEBITAR 100
CREDITAR 100
Ordem não é detalhe.
Ordem pode ser negócio.
🔢 CAPÍTULO 8 — OFFSET: O MARCO QUILOMÉTRICO DA ROTA
Cada evento dentro de uma partition possui uma posição.
Chamamos essa posição de:
OFFSET
Imagine:
Partition 0
offset 1001
offset 1002
offset 1003
offset 1004
offset 1005
Um consumidor pode registrar até onde chegou.
Algo como:
— Marco, já percorremos a rota até o marco 1004.
Então continuamos:
1005
1006
1007
Essa característica abre uma possibilidade extremamente poderosa:
REPLAY
Podemos voltar.
Dependendo da retenção disponível, um consumidor pode reler acontecimentos anteriores.
Imagine que criamos hoje um novo sistema analítico.
Ele não necessariamente precisa começar apenas nos eventos novos.
Podemos querer:
REPROCESSAR
eventos históricos disponíveis.
Para um mainframeiro acostumado com restart, checkpoint, logs e reprocessamento, isso começa a soar estranhamente familiar.
📬 CAPÍTULO 9 — "ENTÃO KAFKA É IBM MQ?"
Não.
Essa pergunta precisa aparecer cedo porque a confusão é natural.
IBM MQ
Uma boa simplificação mental:
Entregue esta mensagem.
PRODUTOR
|
v
QUEUE
|
v
CONSUMIDOR
Exemplo:
PROCESSAR PAGAMENTO 12345
Parece uma ordem.
Faça isso.
Kafka
Uma aproximação melhor:
Isto aconteceu.
PAGAMENTO 12345 FOI PROCESSADO
Então:
EVENTO
|
+---------------+---------------+
| | |
v v v
Fraud Mobile Analytics
Não significa que MQ não possa trabalhar com eventos nem que Kafka não possa participar de workflows.
A distinção é um modelo mental inicial, não uma fronteira absoluta.
🧙 CAPÍTULO 10 — CONFLUENT NÃO É APENAS KAFKA COM GRAVATA
Se Apache Kafka é o motor fundamental, Confluent constrói uma plataforma empresarial ao redor desse universo.
Podemos pensar pedagogicamente:
Apache Kafka
|
v
motor de event streaming
Enquanto:
Confluent
|
+--> Kafka
+--> Connectors
+--> Schema Registry
+--> Governança
+--> Segurança
+--> Stream Processing
+--> Flink
+--> Operação
Isso importa em grandes empresas.
Porque instalar Kafka é uma coisa.
Operar streaming empresarial envolvendo milhares de aplicações, segurança, schemas, governança e consumidores é outra aventura completamente diferente.
Marco Polo poderia comprar um cavalo.
Mas organizar uma rota comercial entre continentes exigia muito mais que possuir cavalos.
🗄️ CAPÍTULO 11 — Db2 ENCONTRA A ROTA DA SEDA
Agora chegamos ao ponto especialmente interessante para IBM Z.
Imagine:
COBOL
|
v
CICS
|
v
Db2
O programa executa:
UPDATE ACCOUNT
SET BALANCE = BALANCE - 500
WHERE ACCOUNT_ID = 123;
Depois:
COMMIT
Db2 precisa registrar alterações para garantir propriedades transacionais e recuperação.
Existem logs.
E aqui surge uma ideia poderosa:
Em vez de consultar constantemente as tabelas procurando alterações, podemos capturar mudanças a partir dos logs.
Isso nos leva a:
CDC — CHANGE DATA CAPTURE
🔍 CAPÍTULO 12 — O VIGIA QUE NÃO FICA PERGUNTANDO
Imagine um sistema fazendo:
Mudou?
Mudou?
Mudou?
Mudou?
Mudou?
Mudou?
Ou pior:
SELECT *
FROM TRANSACTIONS
WHERE LAST_UPDATE > ...
continuamente.
Isso é polling.
Agora imagine outra estratégia:
INSERT aconteceu
UPDATE aconteceu
DELETE aconteceu
Capturamos essas mudanças.
Isso é a essência do Change Data Capture.
🚪 CAPÍTULO 13 — IBM DATA GATE FOR CONFLUENT
Aqui nossa rota chega diretamente ao IBM Z.
O IBM Data Gate for Confluent permite transformar alterações provenientes do Db2 for z/OS em streams consumíveis pelo ecossistema Confluent.
Conceitualmente:
COBOL
|
v
CICS
|
v
Db2 for z/OS
|
INSERT
UPDATE
DELETE
|
COMMIT
|
v
Db2 LOG
|
v
IBM Data Gate for Confluent
|
v
Kafka Connect
|
v
Confluent
|
v
Topics
Isso é interessantíssimo.
Porque talvez não seja necessário alterar centenas de programas COBOL apenas para fazer:
PUBLICAR NO KAFKA
A mudança do banco pode ser capturada.
O velho programa continua trabalhando.
A rota moderna aparece ao redor dele.
⚠️ CAPÍTULO 14 — CDC NÃO É EVENTO DE NEGÓCIO
Agora Marco Polo levanta o dedo.
— Cuidado.
Essa talvez seja uma das lições mais importantes de todo este artigo.
Considere:
CUSTOMER.STATUS
A -> B
CDC pode dizer:
Uma coluna mudou.
Mas o negócio talvez queira dizer:
CUSTOMER_ACCOUNT_SUSPENDED
com:
reason = FRAUD_INVESTIGATION
Isso é muito mais rico.
Portanto:
mudança de dado não é automaticamente evento de negócio.
Temos dois conceitos:
CDC
"algo mudou no dado"
e:
BUSINESS EVENT
"algo significativo aconteceu no negócio"
Confundir os dois pode transformar sua arquitetura Kafka num gigantesco banco de dados desmontado em JSON.
📖 CAPÍTULO 15 — SCHEMA REGISTRY: O COPYBOOK DO VIAJANTE
Agora chegamos a algo que fará qualquer COBOLero sorrir.
Temos:
01 PAYMENT-RECORD.
05 ACCOUNT-NUMBER PIC X(10).
05 AMOUNT PIC S9(9)V99 COMP-3.
05 CURRENCY PIC X(03).
COPYBOOK define estrutura.
Agora imagine eventos.
Versão 1:
{
"account": "123",
"amount": 500
}
Um desenvolvedor decide melhorar:
{
"accountNumber": "123",
"amount": 500,
"currency": "BRL"
}
Pronto.
Talvez quinze consumidores tenham quebrado.
Bem-vindo ao problema de evolução de schemas.
Confluent possui Schema Registry, permitindo administrar schemas e compatibilidade.
Pedagogicamente:
COPYBOOK
|
estrutura compartilhada
|
COBOL
versus:
Schema Registry
|
estrutura dos eventos
|
Producers / Consumers
Não são tecnologicamente equivalentes.
Mas o velho programador COBOL entende imediatamente por que aquilo existe.
🌊 CAPÍTULO 16 — FLINK: PROCESSANDO A ÁGUA ENQUANTO O RIO PASSA
Transportar eventos é apenas parte da aventura.
Talvez precisemos analisá-los enquanto passam.
Entre em cena:
Apache Flink.
Imagine:
CARD TRANSACTIONS
|
v
FLINK
|
v
FRAUD ALERTS
Uma regra conceitual:
SE
5 compras
+
3 países
+
30 segundos
ENTÃO
GERAR ALERTA
Antigamente poderíamos imaginar:
23:00
//FRAUD JOB
O batch analisa o dia.
Streaming permite:
evento
evento
evento
evento
|
v
análise imediata
Batch continua tendo seu lugar.
Mas agora temos outra ferramenta.
🔌 CAPÍTULO 17 — E O z/OS CONNECT?
Outra confusão comum.
API e streaming não são necessariamente concorrentes.
Imagine um cliente solicitando:
POST /transfer
Temos:
Mobile
|
v
API
|
v
z/OS Connect
|
v
CICS
|
v
COBOL
A pergunta é:
Faça uma transferência.
Depois a transação ocorre.
Agora:
COBOL
|
v
Db2
|
v
COMMIT
|
v
EVENTO
|
v
Confluent
A API entra.
O evento sai.
Nossa arquitetura fica:
MOBILE
|
| POST /transfer
v
z/OS Connect
|
v
CICS
|
v
COBOL
|
v
Db2
|
COMMIT
|
v
EVENTO
|
v
CONFLUENT
|
+-----------+-----------+
| | |
v v v
Fraud CRM IA
Agora temos uma arquitetura realmente interessante.
🏰 CAPÍTULO 18 — RACF NÃO PROTEGE O MUNDO INTEIRO
O jovem COBOLero pergunta:
— Mas temos RACF.
Marco Polo responde:
— Dentro das muralhas.
Quando o dado sai:
IBM Z
|
v
Confluent
|
v
Cloud
a superfície de segurança muda.
Precisamos considerar:
TLS
certificados
autenticação
autorização
ACLs
criptografia
segredos
PII
governança
retenção
auditoria
mascaramento
Uma regra importante:
A política de proteção precisa acompanhar o dado.
Não adianta possuir uma fortaleza maravilhosa se você coloca documentos secretos numa carroça sem escolta assim que eles atravessam o portão.
🤖 CAPÍTULO 19 — IA DESCOBRE O MAINFRAME EM TEMPO REAL
Aqui a história ganha outro nível.
Imagine IA alimentada assim:
23:00 extrair Db2
00:00 ETL
01:00 Data Lake
02:00 processamento
Ela conhece o passado.
Agora:
19:31:01 transação
19:31:02 evento
19:31:02 stream
19:31:03 processamento
Mudamos a pergunta.
Antes:
O que aconteceu ontem?
Agora:
O que está acontecendo agora?
Para antifraude, logística, recomendação, observabilidade e automação, essa diferença pode ser gigantesca.
📜 CAPÍTULO 20 — KAFKA É QUASE UM SMF DO NEGÓCIO?
Aqui temos nosso Easter Egg mainframeiro.
Quem trabalha com z/OS já convive com event streaming conceitualmente há muito tempo.
Pense no SMF:
JOB iniciou
JOB terminou
usuário acessou
CPU consumida
dataset aberto
transação executada
Depois:
SMF
|
+--> Segurança
+--> Auditoria
+--> Capacity
+--> Performance
+--> Billing
Agora observe:
Kafka
|
+--> Fraud
+--> Analytics
+--> Mobile
+--> AI
+--> Data Lake
Marco Polo olha para o velho programador mainframe.
O velho programador olha para Kafka.
Os dois ficam em silêncio.
Finalmente alguém diz:
— Então vocês reinventaram algumas coisas que nós já fazíamos?
😂
Não exatamente.
Mas existem ideias surpreendentemente familiares.
Easter Egg 03:17: se algum incidente acontecer exatamente nesse horário, procure primeiro o consumer lag antes de culpar o COBOL.
🧨 CAPÍTULO 21 — NÃO JOGUE 4.000 TABELAS NO KAFKA
Um arquiteto empolgado entra na sala:
— Temos quatro mil tabelas Db2!
Marco Polo sorri.
— Excelente.
— Vamos colocar todas no Kafka!
Marco fecha o mapa.
Não.
Essa decisão pode produzir:
4.000 tabelas
|
v
milhares de topics
|
v
schemas
PII
dados inúteis
custos
consumidores desconhecidos
dependências
governança impossível
Antes pergunte:
Qual dado?
Qual evento?
Quem consome?
Por quê?
Qual retenção?
Qual latência?
Qual chave?
Qual schema?
Qual SLA?
Contém PII?
Quem é o owner?
Replay é permitido?
Qual é a classificação de segurança?
Kafka não substitui arquitetura.
Confluent não substitui arquitetura.
Cloud não substitui arquitetura.
IA definitivamente não substitui arquitetura.
🛠️ CAPÍTULO 22 — PASSO A PASSO PARA O PROGRAMADOR COBOL
Se você está começando, estude nessa ordem.
Passo 1 — Entenda a transação
Comece pelo que conhece:
COBOL
CICS
Db2
COMMIT
ROLLBACK
Entenda Unit of Work.
Passo 2 — Entenda evento
Transforme:
UPDATE ACCOUNT
mentalmente em:
ACCOUNT_BALANCE_CHANGED
Depois pergunte se existe um evento de negócio ainda melhor:
PAYMENT_COMPLETED
Passo 3 — Aprenda Kafka básico
Domine:
Producer
Consumer
Topic
Partition
Key
Offset
Consumer Group
Retention
Replay
Passo 4 — Compare MQ
Pergunte:
Estou enviando uma ordem?
ou
Estou anunciando um acontecimento?
Isso já elimina muita confusão.
Passo 5 — Estude CDC
Aprenda:
INSERT
UPDATE
DELETE
LOG
CDC
Passo 6 — Estude Schema Registry
Pense como alguém que já conhece copybook.
Quem é dono do contrato?
Como evolui?
Quem quebra se mudar?
Passo 7 — Estude streaming
Depois avance para:
Flink
windowing
aggregation
filtering
stream processing
Passo 8 — Só então coloque IA
Não comece:
"QUERO IA!"
Comece:
Qual evento?
Qual dado?
Qual qualidade?
Qual latência?
Qual governança?
Depois coloque IA.
☕ CAPÍTULO 23 — A CAFETERIA DE MARCO POLO
Vamos fechar com uma analogia.
Imagine nossa cafeteria.
Db2
É o livro-caixa.
Pergunta:
Qual é o saldo?
API
Cliente pergunta ao balcão:
Quanto custa um espresso?
IBM MQ
Garçom leva uma ordem:
Prepare dois cafés.
Kafka
O sino toca:
DOIS CAFÉS FORAM VENDIDOS.
Então:
estoque escuta
financeiro escuta
fidelidade escuta
analytics escuta
IA escuta
Confluent
É toda a infraestrutura comercial que administra essas rotas.
Data Gate
Observa mudanças relevantes vindas do Db2 e ajuda a colocá-las na rota.
Schema Registry
É o formulário comercial dizendo exatamente como deve ser descrita uma carga.
Flink
É o mercador que analisa as mercadorias enquanto as caravanas ainda estão passando.
🧭 EPÍLOGO — O COBOL NÃO PRECISA FAZER A VIAGEM
Depois de meses viajando pela Rota da Seda Digital, nosso jovem programador retorna ao mesmo terminal.
Na tela ainda existe:
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - :WS-VALOR
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
EXEC SQL
COMMIT
END-EXEC.
Ele olha para Marco Polo.
— Então não precisamos necessariamente reescrever isso?
Marco sorri.
— Finalmente você entendeu a viagem.
O programa COBOL pode continuar fazendo aquilo para o qual foi criado.
Processar uma transação crítica.
Com segurança.
Consistência.
Performance.
Décadas de regras de negócio.
Ao redor dele construímos rotas:
IBM Z
|
CICS / IMS
|
COBOL
|
Db2
|
COMMIT
|
v
Db2 LOG / CDC
|
v
DATA GATE
|
v
CONFLUENT
|
KAFKA
|
+----------------+----------------+
| | |
v v v
CLOUD AI ANALYTICS
| | |
+----------------+----------------+
|
v
NOVOS SERVIÇOS
E talvez essa seja uma das ideias mais importantes para um programador COBOL iniciante compreender sobre modernização.
Modernizar não significa necessariamente substituir.
Às vezes significa conectar.
Às vezes significa expor.
Às vezes significa desacoplar.
Às vezes significa transformar uma alteração em evento.
O IBM Z continua sendo o System of Record.
O Db2 continua preservando o estado confiável.
CICS continua processando transações.
COBOL continua executando regras de negócio.
MQ continua transportando mensagens onde mensageria confiável é necessária.
z/OS Connect abre a porta das APIs.
Kafka cria rios de eventos.
Confluent organiza essas novas rotas.
Data Gate ajuda dados do Db2 for z/OS a entrar nelas.
Flink processa acontecimentos enquanto eles passam.
Cloud, analytics e IA tornam-se consumidores dessa informação.
E assim descobrimos algo que Marco Polo provavelmente entenderia melhor que muitos arquitetos modernos:
Você não precisa mover uma cidade inteira para estabelecer comércio com o outro lado do mundo.
Você precisa construir uma boa rota.
No século XIII ela atravessava desertos, montanhas, impérios e oceanos.
No século XXI ela pode começar humildemente assim:
EXEC SQL
COMMIT
END-EXEC
e terminar milhares de quilômetros — ou alguns milissegundos — depois:
COBOL
↓
CICS
↓
Db2
↓
COMMIT
↓
CDC
↓
IBM Data Gate
↓
Kafka Connect
↓
IBM Confluent
↓
Topic
↓
Partition
↓
Consumer
↓
Flink
↓
Cloud
↓
IA
Marco Polo fecha o mapa.
O programador COBOL olha novamente para o terminal.
E percebe que aquele programa de quarenta anos não estava necessariamente preso ao passado.
Talvez apenas estivesse esperando alguém construir uma estrada.
☕ Bellacosa Mainframe
Porque algumas das tecnologias mais interessantes do futuro começam com alguém perguntando o que realmente aconteceu depois do COMMIT.
