🌩️ PARTE 3 — Cloud para Mainframeiros Raiz 

“Explicando AWS para quem já sobreviveu a um CICS travado e a um checkpoint pendurado no JES2.”

---

🏗️ 1. EC2 explicada como se fosse uma LPAR

Imagine que você é o dono do sysplex. A EC2 é exatamente isso:

✅ Uma LPAR que você cria na hora
— Sem pedir aprovação pro Capacity Planner
— Sem abrir ticket pra equipe de Hardware
— Sem esperar janela do HMC
— Sem aquele café de 3 horas enquanto sobem a imagem do z/OS

EC2 é:

• Seu z/OS? → AMI

• Seu IOCDS? → Instance type (t2.micro até p5.48xlarge)

• Seu STORAGE CLASS? → EBS (gp3, io2, st1…)

👉 E sim, dá pra IPLar a instância em segundos. Alô LPAR que demorava 14 minutos pra subir o CICS…

ABEND que todo mainframeiro sente falta no EC2

• S0C4 → “Access denied” no Security Group

• S0C1 → Chamou script que não existe

• S0C7 → JSON inválido na User Data

• S047 → IAM não deixou você fazer nada

---

🌀 2. Kubernetes explicado como se fosse um Sysplex adolescente

Kubernetes (K8s) é literalmente um Sysplex na puberdade:

• Cresce rápido

• Escala sozinho

• Quebra do nada

• Acha que sabe tudo

• E usa jaquetinha escrito “Cloud Native”

📌 Comparações diretas:

Sysplex	Kubernetes
WLM	Autoscaler
LPAR	Node
Address Space	Pod
VTAM	Ingress Controller
RACF	RBAC + Secrets
CICS Regions	Deployments / Services
CPSM	kube-apiserver

📣 A mais pura verdade

K8s nada mais é que um Sysplex que decidiu aprender YAML e virar dev influencer.

---

🗄️ 3. Objetos S3 explicados como datasets SEM limite de extents

Sim. O sonho. O Éden. O paraíso dos Z/OS-fanboys.

No S3:

• Não tem extents

• Não tem space abend

• Não tem MSGIEC161I

• Não tem catarse espiritual abrindo LISTCAT

• Não tem IDCAMS DELETE ... RECATALOG

S3 é literalmente:

DSN('MEU.DATASET.INFINITO(SEM.ANGUSTIA)')

É o dataset definitivo para quem:

• Já sofreu com DSORG=PS

• Já brigou com volumes esgotados

• Já chorou com o catálogo perdido

E mais:

• O S3 não tem tamanho máximo prático

• Não fragmenta

• Não precisa de SMS Storage Group

• E custa quase nada (até você baixar tudo e receber a conta)

Frase Bellacosa:

“S3 é aquele GDG que nunca enche.”

---

🗺️ 4. Mapa de equivalências Cloud ↔ Mainframe (A VERDADE)

Perfeito para pregar na parede do CPD.

---

🎛️ Compute

AWS	Mainframe
EC2	LPAR
AMI	IPL Image / System Residence
Lambda	Transaction short-running tipo CICS START / LINK
ECS	TORRES DE CICS (Regiões)
Auto Scaling	WLM Dynamic CPU Adjust

---

📦 Storage

AWS	Mainframe
EBS	DASD (3390)
S3	Dataset ilimitado / HSM ML2 divino
EFS	ZFS / HFS
Glacier	FITA GUARDADA NO COFRE DA TI

---

🔐 Segurança

AWS	Mainframe
IAM	RACF/ACF2/TSS
KMS	ICSF
Security Groups	VTAM + SAF + NetAccess
Organizations	RACF Group-tree raiz RAIZONA

---

🛰️ Rede

AWS	Mainframe
VPC	VTAM Major Node
Subnet	PU/PU2 entries
NACL	ACF2 resource rules (porque dói igual)
Transit Gateway	NCP / Cross-domain routing

---

📝 Orquestração / Jobs

AWS	Mainframe
Step Functions	JCL Job Steps
CloudWatch Events	JES2 Schedules
Batch	JES2 / JES3 puro
SQS	MQSeries sem DRL

---

🔎 Monitoramento

AWS	Mainframe
CloudWatch Logs	SDSF LOG / OPERLOG
X-Ray	SMF 110 (CICS Perf)
CloudTrail	SMF 80 + 81
Inspector	RACF + zSecure Health Check

---

🤓 Curiosidades para contar na aula

• O primeiro Elastic Load Balancer da AWS era tão limitado quanto o VTAM do MVS/XA.

• SMF influenciou CloudTrail? — Indiretamente sim!

• Amazon adotou o conceito de "region/zone" inspirado no modelo de multi-plexers e canais do mainframe.

• Lambda é “quase” um CICS transaction server sem file control.

---

🍵 Easter Eggs “Bellacosa Cloud Edition”

• Se mainframeiros criassem a AWS, o S3 teria comando:

  S3CAT LISTDS('BUCKET.PASTEL.DE.FLANGO')
  

• O autoscaling do EC2 teria mensagem:

  IWMASD0I INSTANCE SUBSTITUTED. CAPACITY AVAILABLE.
  

• Kubernetes daria ABEND S0C7 quando o YAML tivesse tab.

• E toda VPC viria previamente com “PROFILE NETACCESS * ALLOW” (só pra alegria dos devs).

---

🎓 Resumo estilo Bellacosa

👉 EC2 = LPAR instantânea
👉 Kubernetes = Sysplex adolescente hiperativo
👉 S3 = Dataset eterno sem extents (nirvana)
👉 Segurança AWS = RACF com crise de identidade
👉 Cloud = Mainframe com carteirinha de startup

🔥 PARTE 2 — CLOUD PARA MAINFRAMEIROS RAIZ

 

🔥 PARTE 2 — CLOUD PARA MAINFRAMEIROS RAIZ

(Ou: “Explicando cloud pra quem já sobreviveu a VSAM corrompido, JCL sem SYSOUT e abend S0C7 às 17h35.”)

Pegue seu café, abra o SDSF no coração e vem comigo.

---

☁️ 1️⃣ EC2 — Explicado como se fosse uma LPAR (porque… é quase isso mesmo)

Na visão Bellacosa Mainframe:

👉 EC2 = LPAR com liberdade de adolescente que acabou de ganhar a primeira moto.

Enquanto a LPAR do z/OS é aquela coisa séria, parruda, certificada, com CPU, memória e I/O milimetricamente controlados pelo PR/SM…
EC2 é o “irmão caçula” moderninho, criado para escalar, quebrar e renascer com a facilidade de um RESTART JOB no JES2.

🧠 Tabela mental:

Conceito Mainframe	Equivalente Cloud
LPAR	EC2 Instance
CP / IFL / zIIP	vCPU
HCD / IOCP	Flavor / Instance Type
IPL	Boot da VM
Hipervisor PR/SM	Hypervisor Xen/KVM da AWS
HLASM do sistema	AMI (Amazon Machine Image)

💡 Curiosidade estilo Bellacosa:

Se no mainframe você precisa abrir chamado, pedir mudança, esperar janela…
No EC2 você clica em “Launch Instance” e pronto.
Desprotegido? Sim.
Perigoso? Com certeza.
Divertido? Demais. 😎

---

☁️ 2️⃣ Kubernetes — explicado como se fosse um Sysplex adolescente

Se o Sysplex fosse um jovem rebelde, cheio de hormônios, tatuagem de “Available 99.999%”, e que adora brigar com todo mundo…
ele seria o Kubernetes.

🧠 Analogia oficial do Bellacosa:

Sysplex / Parallel Sysplex	Kubernetes
Várias LPARs cooperando	Vários nós (nodes)
XCF/XES faz o cluster conversar	Control Plane/Gossip
WLM distribui workload	Scheduler
CICS Regions, DB2 Data Sharing	Pods/Deployments/StatefulSets
IPL, PARMLIB	YAML (sim, YAML é o novo PARMLIB gagá)
VTAM / TCPIP	kube-proxy / CNI

O Kubernetes faz balancing, reinicia container que cai, escala instâncias e mantém tudo estável — exatamente como um Sysplex faria…
Só que com muito mais drama, logs misteriosos e YAML torto.

🍜 Easter egg para Otakus da Infra:

“Pod” lembra aquelas cápsulas de dormir de anime cyberpunk?
Pois é, funciona parecido: cada pod é um mini-contâiner pronto para morrer no próximo deploy.
Kubernetes é puro shonen: luta, dor, respawn infinito.

---

☁️ 3️⃣ S3 — explicado como datasets SEM limite de extents (o sonho proibido)

Sim, meus caros…
O S3 é o dataset que o VSAM gostaria de ser quando crescer.

🤯 No S3:

• Não tem EXTENT

• Não tem SPACE=TRK

• Não tem DSORG=PS

• Não tem REPRO corrompendo dados

• Você guarda TUDO e ele não reclama

🧠 Comparação:

Mainframe	S3
Dataset	Objeto
Catálogo / VVDS	Bucket Index
SMS Class	Storage Class
HSM MIGRATE/RECALL	Lifecycle Policy
RACF DATASET Profiles	IAM Policies

O S3 é basicamente um GDG infinito que nunca dá “limit exceeded”.
Imagina um STORAGE que nunca vira “primary/secondary insufficient”.
É o paraíso dos operadores e o inferno de quem paga a conta.

---

☁️ 4️⃣ MAPA MÁGICO — Cloud explicado com equivalências Mainframe

🧵 CICS (transações)

→ Lambda, API Gateway, Fargate
(Pedacinhos rápidos de lógica servidos sob demanda.)

🔐 RACF (segurança, profiles, permissões)

→ IAM (políticas, usuários, roles, MFA, keys)

IAM é praticamente um RACF com interface bonitinha (mas tão complicado quanto RACF se você usar errado).

📄 JCL (orquestração de jobs)

→ CloudWatch Events, Step Functions, Terraform, CI/CD YAML
(Jobs em YAML… a vida é cruel.)

📬 JES2 (fila e roteamento de jobs)

→ SQS, SNS, EventBridge
(Filas, roteamento e distribuição — sem o charme do $HASP.)

🌐 VTAM (rede e sessões)

→ VPC, Subnets, Security Groups
(VTAM era o pai do networking, a VPC é o filho hipster dele.)

🤖 OPS/MVS, REXX, Automação

→ Lambda + EventBridge + API + Scripts
(O equivalente moderno ao operador ninja das madrugadas.)

---

🧙‍♂️ Bellacosa Dica Ninja

Se você entende bem mainframe, a cloud fica MUITO mais fácil, porque:

z/OS já fazia tudo antes da cloud existir.
Cloud = um Sysplex gigante e improvisado, distribuído pelo planeta.

 

😈🔥 Lendo um outage cloud como se fosse dump de produção

Conhecimento básico sobre aplicações distribuídas para quem já encarou SYSUDUMP às 03:00

---

☕ 03:07 — Tudo verde… até não estar mais

No cloud, outage começa assim:

• Nada “quebra”

• Nada “cai”

• Tudo só fica estranho

No mainframe, isso tem nome:

pré-abend

Este artigo é um manual de leitura forense, para analisar um outage cloud com a mesma frieza com que se lê um dump de produção.

---

1️⃣ Contexto histórico: do SYSUDUMP ao dashboard vermelho 🧬

No z/OS:

• Dump é fotografia do crime

• O sistema não mente

• A causa está lá, escondida

No cloud:

• O dump foi dividido em:

  • métricas

  • logs

  • traces

📌 Comentário Bellacosa:
O erro não ficou mais difícil.
Só ficou espalhado.

---

2️⃣ Regra de ouro: nunca comece pelo erro final 🚫

Erro final no cloud é como:

• S0C7 no COBOL

• SOC1 sem stack

🔥 Tradução:
É consequência, não causa.

😈 Easter egg:
Quem começa pelo stacktrace termina em teoria.

---

3️⃣ O “dump cloud”: o que equivale a quê 🗂️

Mainframe	Cloud / Instana	Função
SYSUDUMP	Trace completo	Contexto da execução
SMF	Traces + Metrics	Sequência e consumo
RMF	Métricas	Capacidade e gargalo
JES	Logs correlacionados	Ordem e ambiente
Abend Code	Incident	Sintoma visível
Program	Service	Unidade de falha

📌 Tradução prática:
Você já sabe ler isso. Só mudou o formato.

---

4️⃣ Passo a passo: leitura de outage como dump 🔍

4.1 — Ache a primeira transação estranha

• Mais lenta

• Timeout

• Erro intermitente

👉 Equivalente ao primeiro campo inválido no dump.

---

4.2 — Siga o trace como CALL STACK

• Quem chamou quem

• Em que ordem

• Onde parou

😈 Easter egg:
Stack distribuído é CALL TRACE com latência.

---

4.3 — Correlacione com métricas (RMF feelings) 📊

• CPU alta?

• GC?

• I/O?

• Saturação?

🔥 Comentário Bellacosa:
Se está lento, alguém está esperando.

---

4.4 — Observe dependências externas 🌐

• Banco

• Fila

• API terceira

👉 Equivalente ao dataset indisponível no batch.

---

4.5 — Ignore o barulho 🧹

• Erros cascata

• Alertas repetidos

• Logs genéricos

📌 Mantra:
O erro mais alto não é o primeiro.

---

5️⃣ Curiosidades que só mainframer percebe 😈

• Cloud falha “educadamente”

• Não grita

• Não para

• Cobra depois

🔥 Comentário ácido:
Falha silenciosa é mais cara que abend.

---

6️⃣ Erros clássicos de leitura (não caia neles) ⚠️

❌ Confiar no último erro
❌ Olhar só logs
❌ Ignorar latência
❌ Tratar sintoma como causa
❌ Reagir antes de entender

😈 Easter egg:
Reboot é o novo IPL… e o mais preguiçoso.

---

7️⃣ Guia mental: perguntas de mainframer 🧠

• Quando começou?

• O que mudou?

• Qual transação foi afetada primeiro?

• Onde o tempo foi gasto?

• Quem depende de quem?

• O que aconteceria se isso falhasse antes?

📌 Tradução:
Perguntas que salvam madrugada.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Observabilidade

• Falha parcial

• Resiliência

• SRE

• Dependency management

Exercício

👉 Pegue um incidente real
👉 Monte a linha do tempo
👉 Escreva como se fosse post-mortem de batch

---

🎯 Aplicações reais dessa leitura

• Diagnóstico rápido

• Redução de MTTR

• Comunicação clara com times cloud

• Governança técnica

• Auditoria pós-incidente

---

🖤 Epílogo — 04:01, tudo voltou (por enquanto)

Cloud não é caótica.
Ela só não te dá um dump pronto.

El Jefe Midnight Lunch assina:
“Quando você lê um outage cloud como dump, o pânico vira diagnóstico.”

 

 

🔥 IBM Instana explicado para quem viveu o monólito mas agora enfrenta microsserviços, cloud e caos distribuído

 

---

⏳ Prólogo — De colchão de bit a observabilidade real-time

Imagina você no meio da madrugada, preso àquele batch que nunca deveria ter quebrado…
Agora imagine olhar para um painel que não só diz que a transação falhou, mas por quê, onde, e em quais serviços ela passou — em mil máquinas diferentes. Essa é a promessa do IBM Instana Observability: uma ferramenta de observabilidade automatizada e full-stack para aplicações distribuídas modernas (cloud, containers, serviços, mobiliários exóticos de microserviços e, claro, integração com plataforma tradicional). IBM

---

🏁 Um pouco de história (sem poeira de forno de fita)

🔹 Instana foi fundada em 2015 como startup alemã/americana focada em APM (Application Performance Monitoring) para ambientes dinâmicos baseados em microsserviços e Kubernetes. Wikipedia
🔹 Em novembro de 2020, a IBM adquiriu a Instana para fortalecer seu portfólio de observabilidade e APM, especialmente para ambientes híbridos e multi-cloud, integrando com as capacidades de Watson AIOps e automação. IBM Newsroom
🔹 Desde então, a IBM tem atualizado o produto com releases contínuos, melhorias em integração com infraestrutura tradicional e expansão para novos agentes e métricas (incluindo suporte nativo e agentes para diferentes plataformas). community.ibm.com

👉 Ou seja: não é moda, é evolução integrada acumulando décadas de prática de monitoramento com visão moderna de observabilidade.

---

📊 O que é o IBM Instana (sem blá-blá-blá)

Instana é uma plataforma de observabilidade automatizada e APM que:

✔️ Descobre e mapeia automaticamente toda sua aplicação e infraestrutura.
✔️ Coleta logs, métricas e traces distribuídos em tempo real.
✔️ Correlaciona estes sinais para detectar, diagnosticar e ajudar a resolver problemas rapidamente.
✔️ Possui dashboards dinâmicos e detecção automática de anomalias.
✔️ Funciona em ambientes híbridos — desde mainframe e middleware até cloud moderna. IBM

💡 Easter Egg: Se você já confiou em SMF e RMF para "ver tudo que aconteceu no sistema", Instana faz isso e muito mais — incluindo correlação automática e análise contextual.

---

🧠 O que isso tem a ver com aplicações distribuídas?

Aplicações distribuídas são sistemas espalhados por múltiplos serviços, containers, máquinas e até nuvens. Elas têm desafios como:

• Toda dependência pode falhar em rede

• Latência entre serviços é normal

• Problemas não acontecem em um lugar só

• Monitorar isoladamente “não resolve”

Instana ataca isso mapeando cada componente sem você configurar manualmente. Ele minimiza o tempo de diagnóstico (MTTR) mostrando onde está o impacto real — não só o sintoma. IBM

---

🛠️ O que Instana resolve no seu dia a dia

🔍 Visibilidade completa

Você vê relacionamentos de serviços, fluxo de chamadas e dependências — como um “mapa de topologia” automático.

🧭 Tracing distribuído

Rastreia cada pedido em todo o stack. Isso é o equivalente moderno de um CICS trace completo, mas atravessando Docker, Kubernetes e serviços externos.

🧠 Diagnóstico contextual

Ele correlaciona logs, métricas e traces para ajudar a identificar a causa raiz, não só o alerta. IBM

🚨 Alertas inteligentes

Em vez de gritadores simples de threshold, Instana aciona Smart Alerts — menos ruído, mais significado. IBM

---

📜 Passo a passo mental para usar Instana (modo Bellacosa)

1️⃣ Instrumente sua aplicação — Instana faz discovery e começa a coletar sinais automaticamente.
2️⃣ Explore a topologia — veja como os serviços estão conectados e como as requisições fluem.
3️⃣ Identifique anomalias — instantes antes de alertas padrão.
4️⃣ Use traces distribuídos para encontrar o pico de latência ou erro.
5️⃣ Correlacione com logs e métricas para ver contextos completos.
6️⃣ Crie dashboards e alertas inteligentes alinhados com seus SLOs.
7️⃣ Reaja e aprenda — cada incidente vira material de melhoria contínua.

---

💡 Curiosidades & Easter Eggs

😉 “Agent-less” é mentira que ninguém precisa configurar nada — Instana agiliza, mas seu conhecimento ainda conta (traçar dependências nem sempre é óbvio).
😈 Sem amostragem de traces — Instana coleta 100% dos traces (sem sampling), ou seja, não perde detalhe importante em produção. IBM
📌 Suporte a mais de 300 tecnologias — desde AWS, Kubernetes, DB2, MQ, até serviços modernos e legados. IBM

---

📚 Guia de estudo para quem vem do mundo mainframe

🔹 Aprenda os 3 pilares:

• Logs

• Métricas

• Tracing

🔹 Estude correlação contextual — como Instana junta sinais de diferentes fontes.

🔹 Mergulhe em dashboards dinâmicos — eles mostram dependências e anomalias sem configuração pesada.

🔹 Entenda alertas inteligentes — como Smart Alerts reduzem ruído.

🔹 Mapeie comparativos com SMF/RMF — isso ajuda a contextualizar o que é “novo” vs “velho conhecido”.

---

🚀 Como isso se aplica no mundo real

💼 Times DevOps: diagnósticos mais rápidos entre equipes distribuídas.
☁️ Ambientes híbridos: visibilidade desde mainframe até cloud pública.
🧪 SRE & confiabilidade: SLOs e alertas alinhados com objetivos de serviço.
👨‍💻 Desenvolvedores: visibilidade ponta-a-ponta sem quebrar ambientes.

---

🏁 Epílogo — Da madrugada e do SMF ao real-time de Instana

Se você já:

👾 virou noite atrás de log em fita,
🧠 interpretou SMF em hexadecimal,
🚨 ficou perdido sem causalidade entre eventos…

…o Instana é como um RMF inteligente para o mundo distribuído. É a evolução da observação forense para observabilidade automatizada, reduzindo o tempo até descobrir não só que aconteceu, mas porque aconteceu.

🖤 El Jefe Midnight Lunch finaliza:
Se o monólito falava em SMF, a nuvem fala em traces distribuídos — e Instana traduz tudo para você.

 

📡☁️ “Cloud para Mainframeiros — Um Glossário Bellacosa do Céu Digital”

Por El Jefe Midnight Lunch — Na visão de um veterano de COBOL que olhou para a nuvem e pensou: “Será que dá pra dar um IPL nela?”

---

Quando você vem do mundo z/OS, onde tudo tem cheiro de óleo hidráulico do 3090 e barulho de ventilador de DASD, a tal computação em nuvem parece primeiro um Pokémon raro: todo mundo fala, ninguém sabe direito quem captura.
Mas relaxa, Padawan: hoje vamos fazer o Glossário da Nuvem no melhor estilo Bellacosa Mainframe — explicando como se fosse um SYS1.PARMLIB cheio de comentários espirituosos.

---

☁️ COMPUTAÇÃO EM NUVEM

O “CICS” do céu, pago por minuto

Um modelo que permite ao usuário acessar, quando quiser, um conjunto de recursos de computação compartilhados, sob demanda, facilmente configuráveis, que podem ser ligados/desligados mais rápido do que um REGION=0M queima tua quinzena de CPU.

Em termos Bellacosa:
Cloud é o mainframe do Minecraft — gigante, elástico, programável… e se você derrubar um bloco errado, o ambiente inteiro cai.

---

🌐 ACESSO AMPLO À REDE

“Se tem Wi-Fi, tem acesso.”

Significa que tudo na cloud é acessado via rede — nada de TSO/LU2, nada de 3270 piscando verde.
Seu terminal agora é o navegador, o celular… ou a geladeira inteligente.

---

⚙️ SERVIÇO MEDIDO / PAY-AS-YOU-GO / MODELO DE COBRANÇA POR UTILIDADE

Ou, como eu chamo: “Se rodou o job, pagou.”

O trio de termos que diz a mesma verdade universal:
Na nuvem, tudo é taxímetro.

Quer rodar 1 VM por 5 minutos? Paga 5 minutos.
Quer 8 GPUs por meia hora? Paga meia hora.

É o oposto daquele servidor subutilizado no canto da sala que só roda um programinha mensal há 12 anos.

---

🧬 IA — Inteligência Artificial

Versão moderna do ANALISTA JÚNIOR incansável.

Ferramentas que aprendem, inferem, otimizam e até respondem bobagem às vezes.
Nos animes seria o NPC com excesso de sabedoria.
No mainframe seria um RACF automático que não humilha ninguém com senha expirada.

---

🔐 BLOCKCHAIN

O catálogo VSAM que nunca aceita um DELETE.

Rede imutável: registrou, fica.
Cada membro vê só o que tem que ver.
E sim, é mais organizado que muito PROD.COPYLIB por aí.

---

🧱 HIPERVISOR

O SRM da nuvem moderna.

Pequena camada de software que permite várias máquinas virtuais dividirem o mesmo hardware, sem briga — igual quadra do CECAP quando o pessoal dividia o campinho.

VM aqui é inquilino bem-comportado:
“Cada um com seu pedacinho de CPU e não mexe no do coleguinha.”

---

🖥️ VM — Máquina Virtual

O LPAR da molecada.

Ambiente isolado que roda seu SO como se fosse físico.
Sim, é o conceito do mainframe dos anos 70 sendo redescoberto em 2020 como se fosse hype.

---

🏗️ IaaS, PaaS, SaaS — O trio parada dura

🧱 IaaS — Infraestrutura como Serviço

Você recebe o servidor “cru”: VM, rede, storage.
É o “te vira e instala o que quiser”.

🛠️ PaaS — Plataforma como Serviço

Quer desenvolver sem configurar servidor?
PaaS te dá o ambiente pronto: frameworks, runtime, deploy suave.
É o Endevor da nuvem, mas sem mapear SCL na unha.

🧴 SaaS — Software como Serviço

Você só usa.
Não instala, não configura, não atualiza.
É tipo usar TSO sem ter que cuidar do JES2.

---

🛰️ IoT — Internet das Coisas

Ou “todo objeto agora quer Wi-Fi”.

Seu relógio, sua geladeira, sua cafeteira, tudo falando na rede.
Antigamente era o 3270 plugado no token-ring.
Agora é o micro-ondas postando no Twitter que sua pipoca queimou.

---

📊 IDC — International Data Corporation

Os caras que ficam medindo o mercado, fazendo gráficos e previsões.
É tipo o SDSF do mundo corporativo, só que com PowerPoint bonito.

---

🏛️ NIST — National Institute of Standards and Technology

O COMITÊ DOS PADRÕES.
A turma que diz o que é ou não é cloud de verdade.
Equivalente ao manual de JCL que evita o caos.

---

⚡ ELASTICIDADE RÁPIDA

O “autoscale” que salva sua pele no Black Friday.

A nuvem cresce e encolhe conforme a demanda.
Igual batch que ganha mais CPU quando pega fila.
Mas sem abrir ticket pedindo pro Sysprog melhorar a performance.

---

🌐 POP — Post Office Protocol

Protocolo tradicional de e-mail.
O tiozinho simpático dos protocolos, que ainda funciona.
Tipo aquele COBOL que ninguém mexe há 20 anos e nunca dá erro.

---

☁️ GCP — Google Cloud Platform

A nuvem do Google, cheia de engenharia afiada.
Mais APIs que capítulos filler de Naruto.
Mais produtos que jobs no JES2 no fim do mês.

---

🎯 RESUMINDO NO ESTILO BELLACOSA:

Cloud é:
✔ Mainframe sem rack
✔ CICS sem sala-cofre
✔ Sysprog sem chave inglesa
✔ Job que cresce sozinho
✔ Storage que aparece do nada
✔ CPU que some quando você esquece de desligar a VM (e a fatura chega quente)

☁️ O que é Cloud Computing (sem bullshit)

 

☁️ O que é Cloud Computing (sem bullshit)

Segundo o NIST, cloud computing é:

Um modelo que permite acesso sob demanda a um pool compartilhado de recursos computacionais configuráveis, que podem ser rapidamente provisionados e liberados com mínimo esforço humano.

Traduzindo para o dialeto Bellacosa:

• Recursos não são seus

• Você não vê o ferro

• Você sobe e desce capacidade sem pedir benção

• Você paga pelo que usa

• E se der ruim… é responsabilidade compartilhada (já chegamos lá)

---

🧱 Modelos clássicos: IaaS, PaaS e SaaS (a analogia do carro)

A IBM adora analogias. Vamos à mais famosa:

🚗 O carro

IaaS – Comprar o carro

• Você cuida de tudo

• SO, patch, firewall, aplicação

• Liberdade total

• Dor de cabeça total

👉 Ex: VMs no IBM Cloud, AWS EC2

---

PaaS – Alugar o carro

• Você dirige

• O provedor cuida do motor, manutenção, óleo, troca de peça

• Foco no código, não no ferro

👉 Ex: Cloud Foundry, OpenShift, runtimes gerenciados

---

SaaS – Pegar um táxi

• Só usa

• Não sabe nem onde fica o motor

• Só reclama quando atrasa

👉 Ex: Salesforce, O365, ServiceNow

---

🔐 Segurança na nuvem: não é opcional, é fundação

Se você acha que cloud é insegura, parabéns:
você acabou de repetir uma frase de 2012.

O mantra IBM:

Security by design + Shared Responsibility

📌 Modelo de responsabilidade compartilhada

• Provedor protege:

  • Data center

  • Hardware

  • Infraestrutura física

• Cliente protege:

  • Dados

  • Identidade

  • Acesso

  • Configuração

Se você subir um banco aberto na internet…
👉 o problema não é da nuvem

---

🪪 IAM – Identity & Access Management

No mainframe você tinha:

• RACF

• ACF2

• Top Secret

Na nuvem você tem:

• IAM

• Access Groups

• Policies

• Least Privilege

A regra é a mesma desde os anos 80:

Nunca dê mais acesso do que o necessário.

E sim…
quem dá *.* em produção continua existindo 😅

---

🔒 Criptografia: dados inúteis para quem não deveria ver

Criptografia em nuvem protege dados:

• Em repouso

• Em trânsito

• Em uso

Dois elementos fundamentais:

• 🔑 Algoritmo

• 🔑 Chave

E aqui vai um easter-egg:

🔥 Criptografia não elimina risco.
Ela só garante que o invasor roube lixo ilegível.

---

👀 Monitoring: quem não mede, não governa

No mainframe você tinha:

• SMF

• RMF

• Console verde gritando

Na nuvem você tem:

• Logs

• Métricas

• Traces

• Eventos

• Flow Logs

• Dashboards

As 3 áreas do monitoramento em nuvem:

1. Infraestrutura

2. Aplicações

3. Dados

Monitoramento moderno serve para:

• Detectar falhas antes do usuário

• Medir custo (sim, a fatura dói)

• Garantir compliance

• Reagir a ataques (DDoS, brute force, etc.)

👉 Monitorar não é olhar gráfico bonito.
É tomar decisão rápida.

---

🌪️ DDoS: o velho ataque com roupa nova

Ataque de negação de serviço distribuída é simples:

• Milhares de máquinas

• Um alvo

• Tráfego até cair

A nuvem ajuda porque:

• Escala automaticamente

• Distribui carga

• Usa redes globais (CDN)

Mas não faz milagre se você:

• Não configurou

• Não monitorou

• Ignorou alertas

---

🧠 Boas práticas Bellacosa Approved™

✔ Use monitoramento contínuo, não auditoria ocasional
✔ Aplique least privilege sempre
✔ Separe ambientes (dev / test / prod)
✔ Monitore custo (cloud não é barata por padrão)
✔ Automatize tudo (infra as code)
✔ Desconfie de “funciona na minha máquina”
✔ Lembre-se: cloud não perdoa gambiarra

---

🧩 Curiosidades & Easter-Eggs

🥚 Mainframe é cloud privada ultra resiliente
🥚 LPAR ≈ VM
🥚 WLM ≈ Auto Scaling
🥚 SMF ≈ Observability
🥚 Quem domina mainframe aprende cloud mais rápido
🥚 O problema nunca foi a tecnologia… sempre foi o processo

---

🧘 Visão final para o Padawan

Cloud Computing não é:
❌ só subir VM
❌ só reduzir custo
❌ só modernizar frontend

Cloud é:
✅ modelo operacional
✅ mudança cultural
✅ automação
✅ segurança embutida
✅ monitoramento contínuo

E se você veio do mainframe…
você não está atrasado.

👉 Você só está lembrando de algo que já sabia.

📊 Infográfico: Modelos de Nuvem no Mainframe

🏗️ 1. IaaS (Infrastructure as a Service) - Mainframe como Infraestrutura

Neste nível, você "aluga" o poder de processamento bruto, mas gerencia quase todo o resto.

• O que é fornecido: LPARs (Partições Lógicas), Processadores (CPs, zIIPs), Memória e Storage (DASD).

• O que você gerencia: O Sistema Operacional (z/OS, z/VSE, z/TPF ou Linux on Z), middleware e aplicações.

• Exemplo: Provedores que oferecem zCloud onde você define o tamanho da sua LPAR e instala seu próprio stack.

---

🛠️ 2. PaaS (Platform as a Service) - Mainframe como Plataforma

Aqui, a complexidade da infraestrutura é escondida. O foco é no desenvolvimento e execução de código.

• O que é fornecido: Ambiente de execução pronto, compiladores (COBOL, Java, Python), gerenciadores de banco de dados (DB2, IMS) e monitores de transação (CICS).

• O que você gerencia: Apenas o seu código (programas) e os dados.

• Exemplo: Ambientes de DevOps moderno (como z/OSMF ou containers via OpenShift on Z) onde o desenvolvedor faz o deploy do código sem se preocupar com a configuração do sistema operacional.

---

💻 3. SaaS (Software as a Service) - Mainframe como Serviço

O nível mais alto. O software roda no mainframe, mas o usuário final apenas consome a funcionalidade via web ou API.

• O que é fornecido: A aplicação completa. Toda a manutenção, segurança e escalabilidade do mainframe são invisíveis para o usuário.

• O que você gerencia: Apenas as configurações de usuário e o consumo do serviço.

• Exemplo: Sistemas bancários de core-banking acessados via mobile que rodam transações críticas no mainframe, ou soluções de análise de fraude em tempo real oferecidas como serviço.

---

📉 Tabela de Responsabilidades (Quem controla o quê?)

Camada	IaaS	PaaS	SaaS
Hardware (z14, etc)	Provedor	Provedor	Provedor
Virtualização (z/VM)	Provedor	Provedor	Provedor
S.O. (z/OS, Linux)	VOCÊ	Provedor	Provedor
Middleware (DB2, CICS)	VOCÊ	Provedor	Provedor
Aplicações (COBOL)	VOCÊ	VOCÊ	Provedor
Dados	VOCÊ	VOCÊ	Provedor