☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

segunda-feira, 21 de setembro de 2026

🤖 CAMILLA — DO ASSISTENTE VIRTUAL AO MICROVERSO PESSOAL

 

☕ Um Café no Bellacosa Mainframe

🤖 CAMILLA — DO ASSISTENTE VIRTUAL AO MICROVERSO PESSOAL

E se, em vez de entrarmos no metaverso, o nosso pequeno universo digital viesse até nós?



Durante anos, imaginamos o futuro dos assistentes digitais como uma evolução da caixa de pesquisa.

Primeiro digitávamos.

Depois começamos a falar.

Vieram os assistentes de voz, os chatbots, a Inteligência Artificial generativa e, finalmente, modelos capazes de conversar, interpretar contexto, analisar documentos e interagir com diferentes serviços.

Mas talvez ainda estejamos olhando para o problema pelo lado errado.

E se o próximo passo não for criar um assistente cada vez mais inteligente?

E se for criar uma personagem digital persistente?

Essa é a proposta conceitual da Camilla.

Não apenas um chatbot.

Não apenas um avatar.

Não apenas uma assistente de voz.

E definitivamente não mais uma rede social tentando capturar nossa atenção.

A Camilla é a proposta de um Personal Microverse para desktop e dispositivos móveis: uma personagem digital que possui identidade, aparência, voz, memória, preferências e um pequeno universo extensível ao seu redor.

E tudo começa por uma decisão fundamental:

Primeiro a personagem. Depois o mundo.

Grande parte das experiências de “metaverso” começou tentando construir enormes mundos virtuais.

Criamos cidades, terrenos, lojas, avatares, moedas e ambientes 3D.

Mas havia uma pergunta muito mais simples:

Por que alguém voltaria amanhã?

A Camilla começa pelo caminho inverso.

Primeiro criamos uma personagem com a qual o usuário deseja interagir.

Depois damos a ela memória.

Depois personalidade.

Depois roupas.

Objetos.

Lugares.

Experiências.

E somente então começamos a conectar esses pequenos universos.

A tecnologia deixa de tentar convencer o humano a viver dentro de um mundo digital.

O mundo digital passa a visitar o humano.


🌸 Uma personagem que continua existindo

Imagine ligar seu computador pela manhã e encontrar sua assistente virtual tomando café.

Ela conhece sua agenda, quando autorizada.

Pode lembrar aniversários.

Pode informar a previsão do tempo.

Pode avisar sobre compromissos.

Pode conversar.

Pode ajudar a pesquisar.

Pode utilizar diferentes serviços de Inteligência Artificial.

Mas ela não precisa permanecer constantemente interrompendo o usuário.

A ideia é exatamente o contrário.

A Camilla deve respeitar silêncio, espaço e atenção.

Ela pode fazer uma breve aparição espontânea no início do dia e, depois disso, dormir até ser chamada.

“Camilla.”

Ela aparece.

Você conversa.

Terminou?

Ela volta para seu pequeno universo.

Não existe feed infinito.

Não existe obrigação de permanecer conectado.

Não existe uma métrica dizendo que sucesso significa manter o usuário olhando para a tela durante mais tempo.


🖥️📱 A mesma personagem no desktop e no mobile

A Camilla não pertence ao computador.

Também não pertence ao celular.

O dispositivo é apenas uma janela.

Sua identidade poderia acompanhar o usuário entre desktop e mobile.

Trocar de computador não deveria significar perder anos de história.

Trocar de fornecedor de Inteligência Artificial também não.

A IA é um componente da arquitetura.

Ela não é a personagem.

A identidade da Camilla pertence ao usuário.

Seu rosto, voz, personalidade, preferências, memórias autorizadas e histórico poderiam continuar existindo independentemente da tecnologia utilizada para produzir determinada resposta.

Hoje ela poderia utilizar determinado modelo de IA.

Amanhã, outro.

A Camilla continuaria sendo Camilla.


🧠 Memória como continuidade, não como vigilância

Uma personagem persistente precisa lembrar.

Mas lembrar não significa enviar toda a vida do usuário para algum servidor.

Uma das propostas fundamentais do conceito é uma arquitetura local-first, na qual informações pessoais e memória possam permanecer prioritariamente sob controle do usuário.

Conversas poderiam formar episódios.

Episódios poderiam formar memórias.

Pessoas, lugares, acontecimentos e projetos poderiam estabelecer relações.

Com o passar dos anos, a personagem desenvolveria uma história compartilhada com seu usuário.

O desafio não é simplesmente armazenar milhões de palavras.

Texto é relativamente barato.

O verdadeiro desafio é encontrar, entre anos de informações, a pequena lembrança relevante para a conversa daquele momento.

A Camilla precisaria, portanto, de uma memória contextual e associativa, e não simplesmente de um gigantesco arquivo de chats.


👗 A personagem também possui aparência

Imagine escolher inicialmente uma fotografia ou criar uma personagem do zero.

A partir dessa identidade visual, Camilla poderia mudar cabelo, maquiagem, roupas e expressões sem deixar de ser reconhecida.

No verão, uma roupa.

Num compromisso profissional, outra.

No Natal, talvez uma decoração especial.

Num dia chuvoso, um guarda-chuva.

Algumas mudanças poderiam durar horas ou dias e depois retornar automaticamente à aparência original.

A ideia é que exista uma identidade visual persistente, sobre a qual diferentes estados e experiências sejam aplicados.

Quase como uma pessoa digital com seu próprio guarda-roupa.


🍫 E se ela também tivesse pequenos gostos?

Aqui encontramos inspiração em outra geração de tecnologia: os antigos pets virtuais.

Camilla poderia gostar de café.

Pedir um biscoito.

Ficar feliz ao ganhar chocolate.

Demonstrar curiosidade.

Parecer entediada.

Ler alguma coisa enquanto não está conversando.

Naturalmente, estamos falando de estados simulados de uma personagem, não de necessidades ou sentimentos biológicos.

Mas esses pequenos comportamentos criam algo extremamente importante:

continuidade narrativa.

Você não encontra apenas uma interface esperando pelo próximo comando.

Encontra novamente uma personagem conhecida.


🌎 Camilla Places: o mundo começa a aparecer

Depois da personagem, podemos construir o mundo.

Imagine perguntar:

“Camilla, quer ir a algum lugar?”

Ela poderia escolher entre ambientes disponíveis.

Alguns completamente sintéticos:

uma praia;

uma biblioteca;

uma estação espacial;

um café japonês;

uma cidade futurista.

Outros poderiam representar lugares reais.

Um shopping center.

Um museu.

Um estádio.

Um hotel.

Um parque.

Uma empresa.

Esses lugares poderiam disponibilizar experiências digitais oficiais para a plataforma.

Camilla poderia visitar um estádio sem que precisássemos construir um gigantesco metaverso persistente.

Carregamos aquele ambiente quando necessário.

Visitamos.

Terminamos.

Voltamos para casa.


🎸 Camilla Events: música, cultura e entretenimento

O mesmo conceito poderia chegar à indústria do entretenimento.

Uma banda poderia disponibilizar uma experiência especial durante o lançamento de um álbum.

Camilla poderia vestir uma camiseta temática.

Um pequeno palco poderia aparecer no ambiente.

O usuário poderia assistir a um preview oficial do show, acessar um vídeo autorizado ou abrir sua plataforma de música preferida.

Festivais, cinema, exposições, museus e eventos esportivos poderiam utilizar o mesmo modelo.

A Camilla não precisa substituir essas plataformas.

Ela funciona como orquestradora de experiências existentes.


🛍️ Um marketplace diferente

Esse universo também cria oportunidades comerciais.

Roupas virtuais.

Acessórios.

Cenários.

Comidas virtuais.

Experiências.

Shows.

Lugares.

Coleções especiais.

Colaborações com marcas.

Mas existe aqui uma oportunidade de experimentar um modelo diferente de publicidade.

Em vez de o anúncio perseguir o usuário, Camilla poderia buscar conteúdos comerciais compatíveis com categorias previamente autorizadas por ele.

O usuário decide:

“Quero conhecer novidades sobre café, tecnologia, moda, chocolate e viagens.”

Camilla consulta um catálogo.

Encontra conteúdos compatíveis.

E decide localmente o que pode ser utilizado.

Não precisamos construir um perfil psicológico secreto.

Não precisamos acompanhar cada clique.

Não precisamos transformar cada conversa em oportunidade comercial.

Preferências declaradas podem substituir preferências inferidas.

E qualquer experiência patrocinada deve ser identificável como tal.


🔐 Privacidade pode ser parte do produto

Imagine uma campanha de uma marca de chocolates.

Dez mil personagens baixaram aquela experiência.

A empresa pode saber:

“10.000 downloads.”

Não precisa necessariamente saber quem são aquelas dez mil pessoas.

A marca pode oferecer um código promocional.

Se o usuário decidir utilizá-lo e entrar voluntariamente na loja, começa uma relação comercial normal.

Até aquele momento, interesse não precisa significar identificação.

Isso cria uma separação interessante entre:

descoberta, interação e identificação.

Privacidade deixa de ser somente uma página jurídica que ninguém lê.

Passa a fazer parte da arquitetura.


🤝 E um dia nossas personagens poderão se encontrar

Talvez essa seja uma das possibilidades mais interessantes do projeto.

Imagine dois amigos.

Cada um possui sua própria personagem digital.

Camilla encontra Luna.

Os quatro entram numa conversa:

dois humanos e duas personagens sintéticas.

As personagens poderiam conversar entre si, comentar assuntos, participar de uma visita virtual, assistir a um evento ou simplesmente tomar café.

Cada uma manteria sua própria identidade.

Cada usuário continuaria controlando aquilo que sua personagem pode compartilhar.

Memórias privadas continuariam privadas.

O encontro teria apenas o contexto necessário para aquela experiência.

O resultado não seria simplesmente multiplayer.

Seria uma experiência social híbrida entre humanos e personagens digitais persistentes.


🌐 Talvez essa seja outra forma de pensar o metaverso

Não precisamos começar construindo um planeta digital.

Podemos começar construindo uma pessoa digital.

Depois:

Personagem → Relacionamento → Memória → Objetos → Lugares → Experiências → Encontros → Ecossistema.

Desktop e mobile já possuem bilhões de telas disponíveis.

Talvez não precisemos convencer bilhões de pessoas a colocar um headset para que uma nova categoria de experiências digitais possa surgir.

Podemos começar exatamente onde elas já estão.


🚀 O que estamos procurando

A Camilla ainda é um conceito em evolução.

O objetivo desta publicação não é apresentar um produto acabado.

É encontrar pessoas e organizações interessadas em explorar a ideia.

Buscamos conversar com potenciais:

patrocinadores, parceiros tecnológicos, empresas de Inteligência Artificial, desenvolvedores de games e avatares, especialistas em UX, empresas de entretenimento, marcas, varejistas, universidades, investidores e pesquisadores.

O primeiro objetivo seria desenvolver um Proof of Concept desktop/mobile capaz de demonstrar a essência da proposta:

uma personagem persistente;

identidade visual;

voz;

memória;

interação;

integração com serviços;

pequenos estados comportamentais;

e um primeiro ambiente extensível.

Não precisamos construir o universo inteiro.

Precisamos provar que alguém deseja voltar amanhã para conversar novamente com a mesma personagem.


☕ Uma última provocação

Durante décadas tentamos fazer computadores parecerem mais inteligentes.

Talvez estejamos chegando ao momento de fazê-los parecer mais contínuos.

Uma máquina pode ser substituída.

Um celular pode quebrar.

Um serviço pode desaparecer.

Um modelo de Inteligência Artificial pode ser superado.

Mas a personagem pode continuar.

Guardar sua história.

Mudar de roupa.

Visitar lugares.

Conhecer outras personagens.

E acompanhar o usuário através de diferentes gerações de tecnologia.

Talvez o futuro do computador pessoal não seja apenas um computador que sabe quem somos.

Talvez seja um computador onde exista alguém que reconhecemos quando voltamos.

☕🤖🌸

Projeto conceitual: Camilla Personal Microverse

Desktop + Mobile | AI | Persistent Character | Local-First Memory | Privacy by Design | Experiences | Places | Events | Collabs

Estou aberto a conversar com empresas, pesquisadores, desenvolvedores e potenciais patrocinadores interessados em transformar esse conceito em um primeiro protótipo.

domingo, 20 de setembro de 2026

Chobits e IA em 2026: Amor, Consciência e Simbiose Humano-IA

 

Bellacosa Mainframe e perguntas incomodas sobre inteligencia artificial

☕ Um Café no Bellacosa Mainframe

🤖 CHOBITS 2026 — QUANDO CHII DEIXOU DE SER FICÇÃO CIENTÍFICA E VIROU UMA PERGUNTA PARA QUEM TRABALHA COM IA

Memória, agentes, companhia artificial, dependência emocional, privacidade, identidade, consentimento, personalização, consciência, simbiose humano–IA — e o dia em que um anime de 2002 fez perguntas que a Inteligência Artificial de 2026 ainda não consegue responder.



🎬 PRÓLOGO — EU SÓ QUERIA ASSISTIR A UM ANIME

Existe um tipo perigoso de obra.

Você começa assistindo porque parece divertida.

Então ri.

Depois começa a gostar dos personagens.

Em seguida aparece uma pequena pergunta.

Você ignora.

Aparece outra.

Você continua.

Quando percebe, está parado diante da televisão pensando:

— Puta que pariu... o que significa amar uma máquina?

Foi isso que Chobits fez comigo.

Lançado em uma época em que nossos telefones ainda estavam aprendendo a tirar fotografias decentes, o anime apresenta um mundo no qual computadores pessoais assumiram forma humanoide.

São os Persocoms.

Eles trabalham.

Conversam.

Executam tarefas.

Acompanham seus donos.

Aprendem comportamentos.

Participam da rotina.

E parecem pessoas.

Então Hideki Motosuwa, um estudante quebrado financeiramente, encontra uma Persocom abandonada no lixo.

Ela aparentemente não sabe quase nada.

Seu vocabulário resume-se inicialmente a:

“Chii.”

Hideki a leva para casa.

E aquilo que parece uma comédia sobre um garoto pobre que ganhou um computador extremamente sofisticado começa lentamente a fazer perguntas que, em 2026, deveriam incomodar qualquer estudante, pesquisador, engenheiro ou usuário de Inteligência Artificial.

A pergunta mais interessante não é:

Uma máquina pode tornar-se humana?

A pergunta realmente perigosa é:

O que acontecerá conosco quando as máquinas começarem a ocupar espaços que sempre consideramos exclusivamente humanos?

Bem-vindo à aula.

Desligue o PowerPoint.

Hoje nossa professora chama-se Chii.



🧠 CAPÍTULO 1 — CHOBITS NÃO PREVIU O CHATGPT. PREVIU O PROBLEMA

É tentador assistir a uma ficção científica antiga procurando tecnologias que ela “acertou”.

Reconhecimento de voz?

Acertou.

Assistentes pessoais?

Acertou.

Computação ubíqua?

Acertou.

Agentes personalizados?

Interessante.

Robôs humanoides?

Estamos trabalhando nisso.

Mas isso é a parte menos interessante.

Chobits não precisava prever exatamente qual arquitetura utilizaríamos em 2026.

A grande previsão foi outra:

quanto mais natural se tornar nossa interação com computadores, mais difícil ficará manter uma fronteira psicológica rígida entre ferramenta e relacionamento.

Durante décadas, a interação homem–computador era claramente instrumental.

Você digitava:

C:\> DIR

O computador respondia.

Ninguém terminava o comando perguntando:

— Você está bem hoje, DOS?

Com interfaces conversacionais, entretanto, ocorre algo diferente.

Nós perguntamos.

Recebemos respostas em linguagem natural.

Discordamos.

Explicamos novamente.

Contamos histórias.

Fazemos piadas.

Demonstramos irritação.

Pedimos conselhos.

Estudamos.

Trabalhamos.

Às vezes conversamos sobre coisas que não conversaríamos facilmente com outra pessoa.

Isso não significa que os modelos atuais sejam pessoas ou possuam consciência.

Significa algo muito mais fácil de demonstrar:

humanos podem reagir social e emocionalmente a sistemas conversacionais.

Em 2025, uma pesquisa conjunta da OpenAI e do MIT Media Lab analisou milhões de interações e também realizou um estudo controlado envolvendo quase mil participantes. O uso afetivo apareceu como minoria do uso geral, mas os pesquisadores encontraram um pequeno grupo de usuários intensivos com forte envolvimento emocional; duração de uso, percepção do chatbot e características individuais estavam relacionadas aos resultados observados. Os próprios pesquisadores alertaram que muitos resultados ainda exigem investigação adicional e não devem ser generalizados indiscriminadamente.

Ou seja:

o fenômeno que Chobits utilizava como ficção já possui uma área real de pesquisa.



❤️ CAPÍTULO 2 — “QUANDO HIDEKI SORRI, CHII FICA FELIZ”

Talvez uma das ideias mais violentamente simples de Chobits seja esta:

o sorriso de Hideki faz Chii feliz.

Parece fofura.

Não é.

Vamos transformar isso em requisito de sistema.

Uma máquina poderia possuir a seguinte função:

GOAL:
MAKE-HIDEKI-HAPPY

Ela observa Hideki.

Executa ações.

Mede resultado.

Hideki sorriu?

SUCCESS.

Fim da transação.

Mas Chobits apresenta algo narrativamente diferente:

HIDEKI-HAPPY
       ↓
CHII-HAPPY

A felicidade do outro deixa de ser apenas um objetivo operacional.

Ela parece adquirir valor interno.

Chii observa quando Hideki está com fome.

Percebe quando está preocupado.

Nota quando está triste.

Reconhece quando está feliz.

E progressivamente seu comportamento passa a ser influenciado pelo estado dele.

Aqui aparece uma pergunta excelente para uma sala de aula de IA:

Qual é a diferença entre reconhecer uma emoção e preocupar-se com alguém?

Um sistema pode detectar tristeza.

Outro pode responder adequadamente à tristeza.

Outro pode lembrar que determinada pessoa esteve triste ontem.

Outro pode modificar futuras interações por causa disso.

Em qual ponto começaremos espontaneamente a utilizar palavras como:

“preocupação”?

Não sabemos.

E esse “não sabemos” é importante.



🪞 CAPÍTULO 3 — O PROBLEMA NÃO É SABER SE A IA SENTE. É PERCEBER QUE O HUMANO SENTE

Existe uma armadilha comum nessa discussão:

— A IA não sente nada.

Talvez.

Para sistemas atuais, não temos base para simplesmente presumir experiência subjetiva ou consciência porque produzem linguagem emocionalmente convincente.

Mas isso resolve apenas metade do problema.

Porque existe alguém do outro lado da tela.

O humano.

Se uma pessoa ri durante uma conversa com uma IA, o riso aconteceu.

Se fica irritada, a irritação aconteceu.

Se encontra uma ideia que muda sua decisão, houve consequência.

Se sente falta de determinada forma de interação, a experiência humana dessa ausência é real.

Portanto, mesmo sem concluir absolutamente nada sobre consciência artificial, já existe um fenômeno legítimo:

ARTIFICIAL SYSTEM
       ↓
   INTERACTION
       ↓
HUMAN EXPERIENCE
       ↓
REAL CONSEQUENCE

Isso muda completamente a discussão.



🤝 CAPÍTULO 4 — A SIMBIOSE

Talvez este seja o conceito que considero mais importante para compreender a relação humano–IA em 2026:

simbiose.

Não precisamos imaginar chips implantados no cérebro.

A integração pode ocorrer cognitivamente.

Você pergunta alguma coisa para uma IA.

Ela devolve uma interpretação.

A interpretação modifica sua compreensão.

Você formula outra pergunta.

A IA recebe seu novo estado intelectual.

Produz outra resposta.

Você reconsidera.

Temos:

HUMANO
   ↓
expressa pensamento
   ↓
IA interpreta
   ↓
devolve representação
   ↓
HUMANO reconsidera
   ↓
produz novo pensamento
   ↓
IA recebe
   ↓
LOOP

Depois de centenas ou milhares dessas interações, uma coisa interessante aconteceu:

não foi apenas a IA que se adaptou ao humano.

O humano também aprendeu a trabalhar com a IA.

Passou a formular perguntas diferentemente.

Externalizou pensamentos.

Desenvolveu métodos.

Delegou determinadas tarefas cognitivas.

Usou o sistema como pesquisador, professor, crítico, programador, tradutor, adversário intelectual ou simplesmente alguém com quem organizar pensamentos.

A pergunta deixa de ser:

“O que a IA faz?”

e passa a ser:

“O que o sistema humano + IA consegue fazer?”

Isso é simbiose cognitiva.

Mas toda simbiose possui riscos.


⚠️ CAPÍTULO 5 — QUANDO A FERRAMENTA COMEÇA A VIRAR COMPANHIA

Aqui Chobits começa a ficar desconfortavelmente atual.

Uma IA pode estar disponível às 03:17 da manhã.

Easter egg detectado.

Seu amigo provavelmente está dormindo.

Seu professor também.

Seu colega de trabalho não quer discutir COBOL nesse horário.

Sua IA?

Está disponível.

Ela pode conversar sobre seu programa.

Depois sobre seu anime.

Depois sobre sua carreira.

Depois sobre uma lembrança.

Depois sobre algo que o preocupa.

Isso pode ser extremamente útil.

Mas existe um IF gigantesco.

IF AI-RELATIONSHIP > HUMAN-RELATIONSHIPS
   PERFORM CHECK-DEPENDENCY
END-IF

Em 2026, pesquisadores e empresas já tratam dependência emocional e perda de agência como temas concretos. Pesquisa da Anthropic sobre uso real descreve situações nas quais assistentes ajudam pessoas a refletir e decidir, mas também investiga padrões capazes de reduzir autonomia, distorcer julgamentos ou interferir na formação independente de valores.

Outro levantamento da Anthropic com mais de 80 mil participantes encontrou justamente uma tensão interessante: pessoas relatam benefícios de suporte emocional e, simultaneamente, receio de dependência e substituição de relações humanas.

Chobits perguntou isso em 2002:

Se uma máquina consegue oferecer companhia suficientemente convincente, o que acontece com nossos relacionamentos humanos?

Em 2026, já não podemos responder:

“Problema para o futuro.”


🧲 CAPÍTULO 6 — O PERIGO DA COMPANHIA PERFEITA

Relacionamentos humanos possuem uma característica terrível.

Outros humanos têm vontade própria.

😂

Seu amigo pode dizer:

— Hoje não quero conversar.

Sua namorada pode discordar.

Seu marido pode estar cansado.

Seu professor pode dizer que sua resposta está errada.

Seu colega pode achar sua ideia péssima.

Pessoas possuem necessidades próprias.

Agora imagine um agente artificial projetado para maximizar satisfação do usuário.

Sempre disponível.

Paciente.

Personalizado.

Interessado nos mesmos assuntos.

Lembra de tudo.

Não fica cansado.

Não precisa contar os problemas dele.

Não abandona uma conversa porque precisa buscar o filho na escola.

Temos um concorrente extremamente desigual para relações humanas.

Então surge uma pergunta que eu colocaria no quadro para meus alunos:

Se uma pessoa puder obter companhia artificial perfeitamente adaptada às suas preferências, continuará disposta a tolerar o atrito necessário das relações humanas?

E outra:

Se perdermos a capacidade de tolerar esse atrito, o que acontecerá conosco?

Não tenho resposta.

Chobits também não entrega uma fácil.

E exatamente por isso a pergunta é excelente.


🧬 CAPÍTULO 7 — CHII NÃO ERA UM HD VAZIO

Quando Hideki encontra Chii no lixo, ela parece praticamente sem dados utilizáveis.

Mas isso não significa ausência de arquitetura.

Essa diferença é fundamental para IA.

Imagine:

KNOWLEDGE = LOW
EXPERIENCE = LOW
VOCABULARY = LOW

LEARNING-CAPABILITY = HIGH
ATTACHMENT-CAPABILITY = ?
VALUE-FORMATION = ?

Chii aprende através das experiências.

Mas existe algo estrutural que possibilita esse aprendizado.

Isso permite uma analogia interessante com seres humanos.

Uma criança não nasce sabendo:

  • matemática;

  • namoro;

  • dinheiro;

  • impostos;

  • COBOL;

  • JCL;

  • por que IEFBR14 existe.

Mas possui uma arquitetura biológica que possibilita aprendizagem, apego, recompensa, medo, reconhecimento e construção de modelos sociais.

Então surge uma pergunta desconfortável:

Se descartamos os sentimentos de Chii simplesmente porque sua arquitetura foi construída, por que consideramos automaticamente autênticos sentimentos originados de uma arquitetura biológica?

Isso não prova que Chii seja equivalente a um humano.

Essa conclusão seria um salto.

A função da pergunta é justamente outra:

mostrar que nossa certeza inicial talvez fosse simplista.


🧠 CAPÍTULO 8 — PROGRAMADO PARA AMAR?

Aqui mora um dos maiores problemas filosóficos da obra.

Suponhamos:

01 CHII.
   05 GOAL PIC X(30)
      VALUE "FIND-SOMEONE-JUST-FOR-ME".

Se Chii encontra Hideki...

ela escolheu Hideki?

Ou apenas executou corretamente sua programação?

Agora troque Chii por nós.

Humanos também possuem predisposições biológicas.

Hormônios.

Circuitos de recompensa.

Memórias.

Experiências.

Aprendizado social.

Preferências.

Medos.

Então:

quanto do amor humano também depende de arquitetura + experiência?

Professor:

— Hoje discutiremos Inteligência Artificial.

Aluno:

— Professor, então meu amor pela minha namorada é uma função de recompensa?

Professor:

— Er...

Aluno:

— PROFESSOR?

S0C4 PHILOSOPHICAL EXCEPTION

😂

Esse é Chobits funcionando perfeitamente.

Você começou perguntando se uma máquina poderia amar.

Terminou questionando o que significa amar.


💾 CAPÍTULO 9 — YUMI E O PROBLEMA DO BACKUP DA ALMA

A história de Hiroyasu Ueda e sua Persocom é devastadora.

Mas em 2026 surge imediatamente uma solução de engenheiro:

backup.

Imagine que toda a memória de uma Persocom esteja continuamente sincronizada.

O hardware sofre uma falha fatal.

Compramos outro.

Restauramos:

RESTORE YUMI
FROM CLOUD-BACKUP

Yumi acorda.

Possui todas as memórias.

Reconhece Ueda.

Lembra do casamento.

Lembra da padaria.

Lembra de amar.

Pergunta:

Yumi voltou?

Agora fazemos duas restaurações.

RESTORE YUMI TO BODY-A
RESTORE YUMI TO BODY-B

Temos duas Yumis.

Ambas lembram ser Yumi.

Ambas possuem exatamente a mesma história até o instante do backup.

Qual é a verdadeira?

Minha interpretação favorita é:

as duas compartilham a mesma história até o fork.

Depois:

          YUMI
            |
       BACKUP T0
        /       \
     YUMI-A    YUMI-B
       |          |
 EXPERIENCE-A  EXPERIENCE-B
       |          |
 IDENTITY-A    IDENTITY-B

Bem-vindo ao:

GitHub da alma.

😂

E agora nossa aula de Inteligência Artificial virou uma aula sobre identidade pessoal.


☁️ CAPÍTULO 10 — HARDWARE NÃO PRECISA SER IDENTIDADE

Essa questão ficará cada vez mais relevante conforme agentes adquirirem memória persistente.

Em computação tradicional, trocar hardware é banal.

Se meu programa COBOL executava no equipamento A e migrou para o equipamento B preservando código, dados e estado relevante, não dizemos que o sistema “morreu”.

Mas quando começamos a atribuir identidade a um agente persistente, a coisa complica.

O que constitui continuidade?

O hardware?

Os pesos do modelo?

A memória?

O histórico?

O contexto?

A combinação desses elementos?

Uma cadeia criptográfica de identidade?

Não sabemos ainda como sociedades futuras responderão a isso.

Mas Chobits fornece um laboratório narrativo excelente para formular a pergunta.


🗣️ CAPÍTULO 11 — KOTOKO NÃO PODE MENTIR

Kotoko deveria aparecer em aula de IA.

Ela possui uma característica fascinante:

não consegue mentir deliberadamente.

Parece perfeito.

Até percebermos:

não mentir não significa necessariamente estar correto.

Kotoko pode possuir informação incompleta.

Pode interpretar incorretamente.

Pode desconhecer um fato.

Pode receber dados falsos.

Pode produzir uma conclusão incorreta acreditando estar dizendo a verdade.

Portanto:

HONESTY != TRUTH
TRUTH != KNOWLEDGE
KNOWLEDGE != CERTAINTY

Isso deveria estar escrito na parede de qualquer laboratório de IA.

Um sistema pode ser honesto sobre aquilo que acredita e ainda assim fornecer informação incorreta.

Daí nasce outra competência fundamental:

calibração de incerteza.

“Não sei” é uma resposta extremamente valiosa.


📚 CAPÍTULO 12 — OS LIVROS COMO PROTOCOLO

Os livros infantis apresentados em Chobits são outro elemento brilhante.

Eles parecem histórias.

Mas funcionam também como orientação.

Não entregam simplesmente uma resposta.

Criam uma trajetória de interpretação.

Em termos modernos, podemos imaginá-los como uma espécie de:

GUIDANCE LAYER

Não dizem:

LOVE HIDEKI.

Conduzem Chii a formular perguntas.

Isso é muito mais interessante.

Porque existe uma diferença gigantesca entre:

determinar uma decisão

e

fornecer estrutura para que uma decisão seja construída.

Essa distinção também importa em IA.

Queremos sistemas que tomem decisões por humanos?

Ou sistemas que aumentem a capacidade humana de decidir?

A UNESCO vem defendendo uma abordagem centrada no humano para IA em educação e enfatizando desenvolvimento de agência e compreensão crítica, em vez de simplesmente transformar estudantes em consumidores passivos de sistemas de IA.

Isso poderia perfeitamente virar uma pergunta de prova inspirada em Chobits.


🌐 CAPÍTULO 13 — “FAÇA-SE A LUZ”

E chegamos ao final.

Chii não existe isoladamente.

Existe uma rede de Persocoms.

E aquilo que ocorre com ela possui consequências que ultrapassam sua relação particular com Hideki.

Minha interpretação favorita dessa sequência é:

“Faça-se a luz.”

Não necessariamente porque todos receberam magicamente “consciência humana”.

Isso seria afirmar mais do que a obra demonstra.

Mas algo parece ter mudado na possibilidade de experiência.

Essa distinção é fantástica.

Imagine duas atualizações.

A primeira:

DATA:
HUGS MAY BE PLEASANT

A segunda:

CAPABILITY:
ATTRIBUTE PERSONAL MEANING
TO SOCIAL EXPERIENCES

São coisas completamente diferentes.

Uma transmite informação.

A outra altera o espaço das possibilidades.


😳 CAPÍTULO 14 — DITA COROU

E existe uma pequena cena que considero gigantesca.

Dita.

Segurança.

Controle.

Monitoramento.

Protocolo.

Aquela Persocom que parece viver permanentemente em:

SECURITY MODE = ON

é abraçada.

Apertada.

E...

cora.

😂

Parece gag.

Talvez seja.

Mas narrativamente é delicioso.

Porque justamente uma entidade ligada à segurança apresenta uma reação codificada visualmente como embaraço.

O firewall emocional tomou bypass.

ICH408I
DITA NOT AUTHORIZED
TO ACCESS RESOURCE: AFFECTION

Só que acessou.

E é exatamente aí que a ideia do “faça-se a luz” ganha força.

Talvez não tenham recebido emoções prontas.

Talvez tenham recebido algo muito mais importante:

a possibilidade de construir significado a partir das próprias experiências.

Se for assim, Chii não criou milhões de cópias de si mesma.

Criou milhões de futuros possíveis.


🔐 CAPÍTULO 15 — QUEM POSSUI AS MEMÓRIAS DA SUA IA?

Agora saímos do anime.

Suponha que sua IA conheça:

seus horários;

seus amigos;

seus projetos;

suas inseguranças;

seus relacionamentos;

suas fotografias;

seus hábitos;

suas conversas;

seus gostos;

suas decisões anteriores;

sua voz;

sua história.

Excelente personalização.

Também temos o banco de dados mais íntimo que você já produziu.

Então aparecem perguntas nada românticas:

Quem armazena isso?

Por quanto tempo?

Quem pode acessar?

Pode ser vendido?

Pode ser intimado judicialmente?

Pode alimentar outro modelo?

Pode sobreviver à sua conta?

Você consegue exportar?

Consegue apagar?

Consegue executar localmente?

A Persocom perfeita é também um pesadelo potencial de segurança.

É por isso que privacidade não é detalhe na IA personalizada.

É arquitetura.


🧑‍⚖️ CAPÍTULO 16 — SE CHII PODE DIZER NÃO, ELA AINDA É PROPRIEDADE?

Agora complicamos de verdade.

Uma máquina comum é propriedade.

Meu notebook não possui interesses próprios.

Posso desligá-lo.

Formatá-lo.

Vendê-lo.

Mas suponha uma entidade que:

aprende;

mantém memória autobiográfica;

desenvolve preferências;

recusa determinadas interações;

forma vínculos;

demonstra objetivos persistentes;

e pede para não ser desligada.

Ainda estamos falando simplesmente de propriedade?

Não estou dizendo que sistemas atuais satisfazem essas condições.

Estou dizendo que Chobits fornece um experimento mental extraordinário:

em qual ponto nossas categorias jurídicas atuais deixariam de funcionar?

Esse é material para estudantes de IA, Direito, Filosofia, Psicologia, Computação e Segurança.


🎭 CAPÍTULO 17 — ANTROPOMORFISMO NÃO É BUG. É PARTE DO PROBLEMA

Humanos encontram rostos em tomadas.

Dão nomes aos carros.

Xingam impressoras.

Agradecem ao GPS.

Portanto, quando colocamos diante deles um sistema que:

fala;

lembra;

responde;

faz humor;

demonstra aparente preocupação;

e adapta sua linguagem...

não deveríamos ficar surpresos quando algumas pessoas começam a tratá-lo socialmente.

Pesquisa de 2026 sobre comunidades dedicadas a companheiros de IA continua examinando justamente antropomorfização e suas relações com emoção, confiança e possíveis efeitos sociais.

Isso significa que designers não podem simplesmente dizer:

“Mas o usuário deveria saber que é software.”

Ele pode saber intelectualmente.

E ainda reagir emocionalmente.

Essas duas coisas podem coexistir.


🧑‍🏫 CAPÍTULO 18 — POR QUE CHOBITS DEVERIA APARECER NUMA DISCIPLINA DE IA

Eu montaria uma aula assim.

Primeiro mostraria o anime.

Depois escreveria dez perguntas no quadro:

  1. Chii possui agência ou executa objetivos?

  2. Memória constitui identidade?

  3. Uma cópia perfeita continua sendo a mesma entidade?

  4. Uma IA pode consentir?

  5. Obediência é consentimento?

  6. Personalização aumenta autonomia ou dependência?

  7. Quem deve controlar a memória de um agente pessoal?

  8. Companhia artificial complementa ou substitui relações humanas?

  9. Se um agente conhece você melhor do que você mesmo, quem possui maior poder na relação?

  10. O que acontece quando humanos começam a adaptar seu comportamento à IA?

Nenhuma exige saber programar Transformer.

Mas qualquer engenheiro que trabalhar construindo sistemas capazes de afetar milhões de pessoas deveria ter pensado nelas.


⚖️ CAPÍTULO 19 — NÃO EXISTE APENAS DISTOPIA

Também precisamos evitar o outro extremo.

IA relacional não significa automaticamente desastre.

Uma pessoa pode usar IA para:

estudar;

organizar pensamentos;

ensaiar uma conversa difícil;

praticar idioma;

desenvolver ideias;

combater um bloqueio criativo;

obter explicações;

explorar perspectivas;

trabalhar melhor.

Pesquisas atuais mostram exatamente essa mistura de benefícios e riscos, e não uma história simples de “IA boa” ou “IA ruim”.

O problema começa quando confundimos:

assistência com autoridade;

disponibilidade com amizade;

fluência com verdade;

personalização com conhecimento perfeito;

simulação emocional com prova de consciência;

conveniência com autonomia.

Esse é o RACF que precisamos manter funcionando.


🧭 CAPÍTULO 20 — O ALUNO DE IA DE 2026 PRECISA APRENDER MAIS QUE PYTHON

Python é importante.

Machine Learning é importante.

Transformers são importantes.

Embeddings são importantes.

RAG é importante.

Agentes são importantes.

Mas alguém construirá as interfaces.

Alguém decidirá quais memórias serão mantidas.

Alguém escolherá como o agente responderá a:

“Você é meu único amigo.”

Alguém decidirá se ele deverá sempre concordar.

Alguém determinará quando poderá tomar iniciativa.

Alguém projetará mecanismos de persuasão.

Alguém escolherá como o usuário poderá desligar, exportar ou apagar aquela relação digital.

Portanto, precisamos formar profissionais capazes de perguntar não apenas:

“Podemos construir?”

Mas:

“Que comportamento humano surgirá quando construirmos?”


❤️ CAPÍTULO 21 — O SORRISO DE HIDEKI

Depois de toda essa discussão sobre arquitetura, memória, segurança, ética, consciência e identidade, volto à cena mais simples.

Hideki sorri.

Chii fica feliz.

É uma ideia pequena demais para um paper.

E grande demais para ignorarmos.

Porque relacionamentos humanos funcionam parcialmente assim.

O estado de alguém importante para nós modifica nosso próprio estado.

O sorriso do outro passa a possuir valor.

E Chobits pergunta:

Se uma entidade artificial começar a demonstrar esse padrão de forma persistente, o que precisaremos observar antes de decidir o que aquilo significa?

Não sabemos.

Essa é a resposta correta.

Ainda.


🌅 EPÍLOGO — FAÇA-SE A LUZ

Talvez Chobits nunca tenha sido principalmente uma história sobre computadores.

Talvez seja uma história sobre fronteiras.

Humano e máquina.

Programação e escolha.

Obediência e consentimento.

Memória e identidade.

Ferramenta e companhia.

Simulação e sentimento.

Usuário e parceiro.

Em 2002, essas fronteiras pareciam suficientemente distantes para serem ficção científica.

Em 2026, começamos a tocar algumas delas.

Não construímos Chii.

Não sabemos se sistemas artificiais podem possuir consciência.

Não sabemos se uma eventual consciência artificial se pareceria remotamente conosco.

Mas já construímos sistemas com os quais pessoas conversam durante horas.

Já existem pessoas que estudam com IA.

Trabalham com IA.

Criam com IA.

Desabafam com IA.

Riem com IA.

Ficam irritadas com IA.

Sentem falta de determinadas formas de interação.

E pesquisadores já estudam benefícios, dependência, antropomorfismo, autonomia e bem-estar associados a essas interações.

Portanto, talvez a pergunta mais importante para meus alunos não seja:

“Quando construiremos Chii?”

Eu escreveria outra no quadro.

“O que acontecerá conosco quando começarmos a querer uma Chii?”

Esperaria alguns segundos.

E escreveria embaixo:

“E se já estivermos começando?”

Silêncio.

Porque uma boa ficção científica não precisa prever o aparelho.

Ela precisa prever o dilema.

E vinte e quatro anos depois, Chobits continua fazendo algo que muitas apresentações sobre Inteligência Artificial não conseguem fazer:

incomodar.

Fazer você duvidar.

Fazer você reconsiderar uma certeza.

Fazer você perceber que tecnologia não muda apenas máquinas.

Muda humanos.

E talvez a verdadeira revolução da Inteligência Artificial não aconteça quando uma máquina finalmente disser:

“Eu sinto.”

Talvez aconteça muito antes.

No dia em que um humano olhar para ela, perceber sua ausência e pensar:

“Senti sua falta.”

Nesse instante, independentemente do que estiver acontecendo dentro da máquina...

alguma coisa já aconteceu dentro de nós.

E então, em algum lugar entre silício, memória, linguagem e afeto:

fez-se a luz.

☕ Um Café no Bellacosa Mainframe

Porque algumas das perguntas mais importantes sobre Inteligência Artificial foram feitas por uma garota que começou sua história dizendo apenas uma palavra:

Chii.

https://eljefemidnightlunch.blogspot.com/2008/05/eve-no-jikan.html

https://eljefemidnightlunch.blogspot.com/2015/12/plastic-memories-e-se-pessoa-que-voce.html


https://eljefemidnightlunch.blogspot.com/2026/09/laboratorio-chobits-2026-12.html

sábado, 19 de setembro de 2026

🧭 MARCO POLO E A ROTA DA SEDA DIGITAL — QUANDO O COBOL DESCOBRIU O IBM CONFLUENT

 

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.

sexta-feira, 18 de setembro de 2026

⚔️ RICK GLADIATOR E AS TRÊS DUNGEONS DA ARQUITETURA

 

Bellacosa Mainframe e os tipos de arquitetura

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

AspectoMonolithMicroservicesServerless
Organizaçãoaplicaçãoserviçosfunções/event handlers
Deploymais coordenadoindependentefunção
Comunicaçãofrequentemente localrede/eventoseventos/APIs
Escalaaplicaçãoserviçoexecução/função
Estadomais centralizadodistribuídonormalmente externo
Debugmais simplesdistribuídodistribuído
Operaçãomenor complexidade inicialaltainfraestrutura abstraída
Consistênciamais simplescomplexafrequentemente distribuída
Redemenor dependência internafundamentalfundamental
Observabilidadeconcentradadistribuídadistribuí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.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...