🔗🔥 Arquitetura Híbrida explicada para quem já integrou tudo com tudo

---

01:12 — Introdução: quando “híbrido” já era a regra, não a exceção

Se você é mainframer e já integrou tudo com tudo, parabéns:
você viveu arquitetura híbrida antes dela virar estratégia corporativa com slide bonito.

Antes de cloud, já existia:

• Mainframe falando com Unix

• CICS conversando com web

• Batch alimentando data warehouse

• MQ colando mundos diferentes

Arquitetura híbrida não nasceu na nuvem.
Ela nasceu da necessidade de sobreviver.

---

1️⃣ O que é Arquitetura Híbrida (sem buzzword)

Arquitetura híbrida é quando:

• Sistemas legados e modernos coexistem

• On-premises e cloud convivem

• Dados e processos são distribuídos

• Nenhuma plataforma reina sozinha

📌 Dialeto mainframe:

“O core fica onde sempre esteve. O resto gira em volta.”

---

2️⃣ Um pouco de história (sim, de novo 🕰️)

• Anos 80/90: mainframe + terminais

• Anos 90/2000: mainframe + client-server

• Anos 2000: mainframe + web

• Anos 2010: mainframe + cloud

• Hoje: tudo junto, ao mesmo tempo

😈 Easter egg histórico:
SOA foi a primeira tentativa “oficial” de arquitetura híbrida.

---

3️⃣ O erro clássico: querer migrar tudo 🧠

Toda empresa passa por isso:

• “Vamos sair do mainframe”

• “Vamos reescrever tudo”

• “Cloud resolve tudo”

Resultado comum:

• Projeto infinito

• Custo explodido

• Sistema pior

👉 Mainframer sabe:

“Core estável não se mexe sem dor.”

---

4️⃣ O papel do mainframe na arquitetura híbrida 🏛️

Mainframe:

• Sistema de registro

• Dado crítico

• Consistência

• Performance previsível

Cloud:

• Elasticidade

• Experimentação

• UX

• Escala variável

📎 Tradução Bellacosa:

“Mainframe é o cérebro. Cloud é o sistema nervoso.”

---

5️⃣ Integração: onde mora o caos (e a arte)

Ferramentas clássicas:

• MQ

• CICS Web Services

• FTP/SFTP

• DB replication

Ferramentas modernas:

• APIs REST

• Event streaming

• iPaaS

• Service Mesh

😈 Easter egg:
Integração mal feita vira dependência invisível.

---

6️⃣ Passo a passo para desenhar arquitetura híbrida sem dor

1️⃣ Identifique o core imutável
2️⃣ Separe o que muda do que não muda
3️⃣ Exponha capacidades, não tabelas
4️⃣ Use mensageria para desacoplar
5️⃣ Observe tudo
6️⃣ Planeje falha e latência
7️⃣ Evolua aos poucos

💣 Dica Bellacosa:
Híbrido bom é aquele que não precisa de herói.

---

7️⃣ Guia de estudo para mainframers integradores 📚

Conceitos

• Arquitetura híbrida

• APIs

• Event-driven

• Observabilidade

• Resiliência

• Segurança distribuída

Ferramentas

• IBM MQ

• CICS TS

• API Connect

• Kafka

• Instana

• Kubernetes

---

8️⃣ Aplicações práticas no mundo real

• Modernização sem big bang

• Exposição de serviços legados

• Escala elástica no front

• Core estável no back

• Redução de risco

🎯 Mainframer híbrido vira arquiteto estratégico.

---

9️⃣ Curiosidades que só veterano percebe 👀

• Quanto mais integração, mais disciplina

• API sem contrato é armadilha

• Mensagem mal definida vira dívida

• Observabilidade é obrigatória

📌 Verdade dura:
Arquitetura híbrida sem governança é gambiarra corporativa.

---

🔟 Comentário final (02:06, sistema respirando)

Arquitetura híbrida não é transição.
É estado permanente.

Se você já:

• Conectou coisa que não deveria conversar

• Sobreviveu a projeto de migração maluco

• Defendeu o core contra modinha

Então você entende o jogo.

🖤 El Jefe Midnight Lunch fecha com autoridade:
Quem domina híbrido não escolhe lado. Escolhe estabilidade.

 

🍱 +30 Comidas Otaku que Aparecem em Animes

(Lista resumida para consulta rápida — estilo Bellacosa Mainframe)

---

🍘 Clássicos Absolutos do Mundo Anime

Nome	O que é	Onde aparece
Onigiri	Bolinho de arroz moldado	Pokémon, Fruits Basket
Bentō	Marmita japonesa elaborada	Demon Slayer, Naruto
Okonomiyaki	“Panqueca” japonesa personalizável	Gintama, Ranma ½
Takoyaki	Bolinhos de polvo feitos na chapa	My Hero Academia
Ramen	Lámen quente com caldo rico	Naruto, Cowboy Bebop
Udon	Massa grossa em caldo suave	Dagashi Kashi
Soba	Macarrão de trigo sarraceno	Your Name
Curry Rice	Arroz com curry japonês	Detective Conan

---

🍡 Doces Icônicos

Nome	O que é	Onde aparece
Dango	Bolinhas de arroz no espeto	Clannad
Mochi	Doce de arroz macio	Sailor Moon
Parfait	Copão com sorvete e frutas	Love Live!
Taiyaki	Peixinho recheado de doce	K-on!, Naruto
Pudding / Purin	Pudim de caramelo japonês	Cardcaptor Sakura
Castella	Bolo macio de origem portuguesa	Fate/Stay Night
Dorayaki	Panqueca recheada de anko	Doraemon

---

🍔 Lanches, Snacks e “Street Foods”

Nome	O que é	Onde aparece
Karaage	Frango frito japonês	Shokugeki no Soma
Korokke	Croquete	My Hero Academia
Nikuman	Pão no vapor com carne	One Piece
Yakisoba-pan	Sanduíche com yakisoba	Lucky Star
Sando Furutsu	Sanduíche de frutas com creme	Horimiya
Oden	Ensopado de inverno com vários itens	Tokyo Revengers
Yakitori	Espetinho de frango grelhado	Gintama
Melon Pan	Pão doce com crosta crocante	Shakugan no Shana

---

🍚 Pratos Caseiros & Reconfortantes

Nome	O que é	Onde aparece
Tonkatsu	Costeleta de porco empanada	Silver Spoon
Hambagu	Hambúrguer caseiro japonês	The Garden of Words
Tamago Kake Gohan (TKG)	Arroz com ovo cru	Silver Spoon
Oyakodon	Tigela de frango com ovo	Shokugeki no Soma
Gyudon	Tigela de carne com arroz	Food Wars
Miso Soup	Sopa tradicional de miso	praticamente todo anime

---

🍣 Clássicos da Culinária Tradicional

Nome	O que é	Onde aparece
Sushi	Arroz avinagrado com peixe	Bleach, JJK
Sashimi	Fatias de peixe cru	One Piece
Tempura	Empanados leves fritos	Demon Slayer
Katsu-don	Tonkatsu + tigela de arroz	Mr. Osomatsu

Truta maluca cantando e dançando

Besteirol puro uma truta que canta

Ter amigos é uma coisa fantástica, poder ir ate eles ou  receber-los em casa. Uma boa jantarada tagarelando banalidades por algumas horas. Uma conversa neutra sem objectivos de ganhar ou perder apenas diversão garantida.

Este video gravei na casa do Luigi e da Ornela, depois de uns copitos de vinho, descobri uma truta maluca na parede.

Ao descobrir que ela cantava e dançava foi gargalhadas generalisadas, maníaco por fotos como sou, não deixei de gravar este pequeno video.

 

🧠 “Quantos tipos de logs existem no SMF? — ou: quando o sistema decide contar TUDO”

SMF explicado para quem já confiou mais em registro binário do que em discurso

---

☕ 01:11 — O dia em que você descobre que o SMF sabe mais que você

Todo mainframer passa por isso:
abre um dump, vê o horário, cruza com o SMF…
e percebe que o sistema lembra melhor do que qualquer humano.

Este artigo é sobre os tipos de registros SMF, como funcionam, o que registram e por que eles continuam sendo a fonte definitiva de observabilidade corporativa.

---

🧬 Um pouco de história (quando log era coisa séria)

O SMF não nasceu para “debug”.
Nasceu para:

• cobrança

• auditoria

• capacidade

• planejamento

• evidência operacional

📌 Comentário Bellacosa:
Antes de “log”, chamava-se prova.

---

🔢 Quantos tipos de SMF existem afinal?

Tecnicamente:

• Tipos SMF vão de 0 a 255

• Nem todos são usados

• Muitos são reservados

• Alguns são específicos de subsistema

🔥 Resposta curta:

Existem centenas, mas menos de 40 são realmente críticos no dia a dia.

---

🧠 Estrutura básica de um registro SMF (o DNA)

Todo registro SMF tem:

📦 Header padrão

• Tipo do registro

• Data e hora

• Sistema

• Identificador do job / task

• Comprimento do registro

🧩 Seções variáveis

• Dependem do tipo

• Podem ter múltiplas ocorrências

• São versionadas

😈 Easter egg:
SMF não quebra compatibilidade — ele adiciona seções.

---

🗂️ Principais tipos de SMF (os que realmente importam)

🔹 SMF Tipo 0 — IPL & Configuração

📌 Registra:

• IPL do sistema

• Mudanças de parâmetros

• Ambiente inicial

🧠 Uso:

• Auditoria

• Linha do tempo do sistema

---

🔹 SMF Tipo 1 — Job Start

📌 Registra:

• Início de jobs

• Classe

• Prioridade

🔥 Analogia distribuída:
“Application started”

---

🔹 SMF Tipo 2 — Job End

📌 Registra:

• Final do job

• RC

• Consumo de recursos

📌 Bellacosa style:
O RC mente. O SMF não.

---

🔹 SMF Tipo 3 — Intervalo de Job

📌 Registra:

• Uso de CPU

• I/O

• Tempo de espera

🧠 Base de:

• Chargeback

• Capacity planning

---

🔹 SMF Tipo 4 / 5 — Step Start / End

📌 Registra:

• Cada step do job

• Recursos por step

😈 Easter egg:
Ideal para descobrir qual step realmente dói.

---

🔹 SMF Tipo 6 — Print/Output

📌 Registra:

• Uso de spool

• Impressão

📌 Hoje menos usado, mas ainda presente.

---

🔹 SMF Tipo 7 / 8 — Accounting & Performance

📌 Registra:

• TSO

• Sessões interativas

🔥 Cloud analogy:
User session metrics.

---

🔹 SMF Tipo 14 / 15 — Dataset Activity

📌 Registra:

• Abertura

• Leitura

• Escrita

• Fechamento de datasets

🧠 Uso:

• Segurança

• Performance

• Forense

---

🔹 SMF Tipo 30 — O canivete suíço

📌 Registra:

• Job start / end

• Step

• Address space

• USS

🔥 Comentário Bellacosa:
Se você só pudesse guardar um tipo… seria o 30.

---

🔹 SMF Tipo 70–79 — RMF (Performance do sistema)

📌 Registra:

• CPU

• Memória

• I/O

• Workload

🧠 Base de:

• Observabilidade real

• Capacity planning

---

🔹 SMF Tipo 80 — Segurança (RACF)

📌 Registra:

• Logon

• Acesso negado

• Alterações críticas

😈 Easter egg:
Auditor ama esse tipo. Operador respeita.

---

🔹 SMF de subsistemas (os mais ricos)

🔸 CICS (110)

• Transações

• Tempo de resposta

• Recursos

🔸 DB2 (100, 101, 102…)

• SQL

• Buffer pools

• Locking

🔸 MQ (115/116)

• PUT / GET

• Depth

• Performance

🔥 Tradução moderna:
Isso aqui são traces distribuídos antes da moda.

---

🧭 Passo a passo: como pensar SMF como observabilidade

1️⃣ Identifique o tipo certo
2️⃣ Leia o header (tempo e contexto)
3️⃣ Analise seções relevantes
4️⃣ Correlacione com outros tipos
5️⃣ Só então conclua

📌 Regra de ouro:
Nunca analise um SMF isolado.

---

📚 Guia de estudo para sobreviver no século XXI

Prioridade de aprendizado

1. Tipo 30

2. Tipos RMF (70–79)

3. Subsystems (CICS, DB2, MQ)

4. Tipo 80 (segurança)

Exercício Bellacosa

👉 Refaça uma RCA antiga
👉 Usando apenas SMF
👉 Compare com o relatório oficial

O SMF geralmente ganha.

---

🎯 Aplicações reais no mundo corporativo

• Observabilidade híbrida

• SRE corporativo

• Auditoria regulatória

• Capacity planning

• Integração com AIOps

🔥 Comentário final:
Todo sistema distribuído sonha em ter a rastreabilidade que o SMF já entrega.

---

🖤 Epílogo — 04:02, tudo documentado

Enquanto o mundo discute qual ferramenta usar,
o SMF continua registrando o que realmente aconteceu.

El Jefe Midnight Lunch assina:
“Logs contam histórias. SMF registra a verdade.”

 

Bellacosa Mainframe estuda o case Mega City

---

📘 Mega City – Case Study Review (Completo)

🎯 Visão Geral do Projeto

O projeto Mega City Commuter Application tem como objetivo desenvolver um aplicativo para apoiar os deslocamentos urbanos, integrando dados do Department of Transportation (DOT) para melhorar a experiência dos usuários.

🎯 Objetivo Principal do App

✅ Allow commuters to determine optimal routes

❌ Não é:

• Previsão do tempo

• Horários de voo

• Sistema ferroviário isolado

---

🧭 Principais Artefatos do Projeto

1️⃣ Agile Project Charter

Finalidade:

• Define objetivos

• Alinha negócio + tecnologia

• Explica o porquê do projeto

📌 Pergunta típica de prova:

“Which document ensures objectives are clear and aligns business and technical teams?”
✅ Agile Project Charter

---

2️⃣ Product Roadmap

Finalidade:

• Visão visual e de alto nível

• Organiza entregáveis por fases e meses

• Indica quando o produto será testado e lançado

📅 Data de lançamento do App (prova):
✅ October

📌 Responsável pela criação:
✅ Project Manager

---

3️⃣ Working Agreement

Finalidade:

• Define regras de convivência

• Cria transparência, expectativas e objetivos comuns

• Focado em como o time trabalha

👤 Quem lidera a criação:
✅ Scrum Master – Anant Kumar

📌 Nunca é imposto, sempre criado pelo time

---

4️⃣ Product Backlog

Finalidade:

• Repositório de todos os User Stories

• Base para planejamento de Sprints

👤 Responsável:
✅ Product Owner – Anant Kumar

📌 Dica de prova:

Quem gerencia e prioriza = Product Owner

---

👥 Papéis-Chave no Case Mega City

🔹 Product Owner

• Define o que será construído

• Gerencia o Product Backlog

✅ Anant Kumar

---

🔹 Scrum Master

• Facilita reuniões

• Remove impedimentos

• Garante adesão ao Scrum

• Lidera o Working Agreement

✅ Anant Kumar (em perguntas específicas do curso)

---

🔹 Subject Matter Expert (SME)

Responsável por garantir que requisitos técnicos e funcionais sejam atendidos.

📍 SME do DOT:
✅ Hiroshi Tanaka

📌 Sempre associado a:

• Dados do DOT

• Funcionalidade específica do domínio

---

📊 Stacey Matrix (Análise Crítica)

📌 Parâmetros Avaliados:

• Level of Agreement

• Technology Complexity

---

🧠 Interpretação para prova

Cenário	Abordagem Correta
Alta concordância + baixa complexidade	Waterfall
Baixa concordância + alta complexidade	✅ Agile / Scrum
Trabalho contínuo	Kanban

📌 No Mega City:

Low agreement + High complexity
✅ Agile / Scrum

---

🧩 Resumo Rápido (Cola de Prova 📝)

• Objetivo do App: Rotas ideais para commuters

• Roadmap: Visual + meses + lançamento em October

• Charter: Alinha negócio e tecnologia

• Working Agreement: Criado pelo time, liderado pelo Scrum Master

• Product Backlog: Responsabilidade do Product Owner

• SME DOT: Hiroshi Tanaka

• Stacey Analysis: Low agreement + High complexity → Agile/Scrum

---

Se quiser, no próximo passo posso:

• Criar um quadro comparativo (tabela) só com quem faz o quê

• Simular questões de prova estilo Coursera

• Ou montar um resumo em inglês, pronto para revisão final 📚

 

🧠 “SMF como fonte de verdade para observabilidade corporativa”

Porque antes de existir observability platform, já existia evidência

---

☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.

---

🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

• auditoria

• cobrança

• capacidade

• performance

• rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.

---

🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

• Logs

• Metrics

• Traces

No z/OS:

• Tudo isso… em um formato só

• Com timestamp confiável

• Com contexto de sistema

• Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.

---

🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.

---

📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade moderna	SMF
Métricas amostradas	Dados completos
Traces instrumentados	Evidência sistêmica
Logs verbosos	Registros estruturados
Dashboards	Capacidade histórica
Alertas	Diagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.

---

🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.

---

🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

• híbridas

• distribuídas

• event-driven

O SMF entra como:

• referência de carga real

• baseline de comportamento

• âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

• se foi CPU

• se foi I/O

• se foi concorrência

• ou se foi culpa de quem chamou demais

---

📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

• Observabilidade ≠ Monitoramento

• Correlação ≠ Alerta

• Evidência ≠ Opinião

• Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.

---

🎯 Aplicações reais no mundo corporativo

• Auditoria e compliance

• Capacity planning sério

• SRE corporativo

• Integração com AIOps

• Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.

---

🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

 

 

🧱🔥 Resiliência explicada para quem já reconstruiu sistema no susto

---

04:41 — Introdução: quando tudo caiu… e você teve que levantar

Se você é mainframer e já reconstruiu sistema no susto, você não leu sobre resiliência — você viveu.
Foi aquela madrugada em que:

• o batch não fechou,

• a base ficou inconsistente,

• o telefone não parava,

• e alguém disse: “Tem que voltar hoje.”

Resiliência não é “não cair”.
É cair, levantar e continuar sem perder a alma do sistema.

---

1️⃣ O que é resiliência (sem frase de LinkedIn)

Resiliência é a capacidade de um sistema:

• Absorver falhas

• Continuar funcionando (mesmo degradado)

• Se recuperar rapidamente

• Aprender com o impacto

📌 Dialeto mainframe:

“Não importa o tamanho do estrago. O sistema volta.”

---

2️⃣ Um pouco de história: resiliência antes da cloud 🕰️

Antes de:

• microservices,

• containers,

• multi-cloud,

já existia:

• Sysplex

• Fallback

• Restart automático

• Controle de ponto de consistência

😈 Easter egg histórico:
Checkpoint de batch era resiliência antes de virar palestra.

---

3️⃣ Resiliência ≠ Alta disponibilidade 🧠

Alta disponibilidade:

• Evita parada

Resiliência:

• Aceita que vai parar

• Planeja a volta

• Minimiza impacto

👉 Mainframer sempre soube:

“Disponível sem consistência é ilusão.”

---

4️⃣ Onde a resiliência mora nas aplicações distribuídas

• Retry com critério

• Timeout bem definido

• Circuit breaker

• Bulkhead

• Fallback funcional

• Reprocessamento

📎 Tradução raiz:

“Se falhar, não propaga. Isola e continua.”

---

5️⃣ Passo a passo para construir resiliência (modo Bellacosa)

1️⃣ Assuma que vai falhar
2️⃣ Defina o que pode falhar
3️⃣ Separe falha crítica de falha tolerável
4️⃣ Implemente contenção
5️⃣ Garanta reprocessamento
6️⃣ Teste recuperação
7️⃣ Documente
8️⃣ Treine
9️⃣ Repita

💣 Dica Bellacosa:
Sistema que só funciona em estado perfeito não é resiliente.

---

6️⃣ Reprocessamento: o herói esquecido 🦸

Mainframer conhece:

• Restart step

• Batch reentrante

• Controle por chave

No mundo distribuído:

• Replay de eventos

• Dead letter queues

• Compensações

😈 Easter egg:
Quem sabe reprocessar não tem medo de falha.

---

7️⃣ Guia de estudo para mainframers sobreviventes 📚

Conceitos

• Resiliência

• Falha parcial

• Circuit breaker

• Bulkhead

• Retry com backoff

• Eventual consistency

Ferramentas

• Resilience4j

• Istio

• Kubernetes

• Kafka

• IBM MQ

---

8️⃣ Aplicações práticas no mundo real

• Ambientes híbridos estáveis

• Sistemas financeiros

• Integração legado + cloud

• Redução de incidentes graves

• Continuidade de negócio

🎯 Mainframer resiliente vira arquiteto natural.

---

9️⃣ Curiosidades que só quem viveu entende 👀

• Sistema que nunca falhou não foi testado

• Restart é mais importante que start

• Documentação de recuperação vale ouro

• Treinamento salva madrugada

📌 Verdade dura:
Resiliência custa projeto, tempo e humildade.

---

🔟 Comentário final (06:22, café requentado)

Resiliência não é luxo.
É requisito mínimo para sistemas que importam.

Se você já:

• Reconstruiu base sob pressão

• Voltou sistema com gambiarra consciente

• Aprendeu mais com falha do que com sucesso

Então você carrega resiliência no DNA.

🖤 El Jefe Midnight Lunch fecha com honra:
Sistemas fortes não são os que não caem. São os que sempre voltam.