Bellacosa Mainframe e a tecnica de cloud repatriation

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:

"O futuro está na nuvem."

Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.

As apresentações dos fornecedores mostravam um cenário quase perfeito.

Tudo seria:

• mais rápido;

• mais moderno;

• mais simples;

• mais seguro;

• mais barato.

Executivos ficaram encantados.

Arquitetos embarcaram na jornada.

Consultorias venderam projetos bilionários.

E milhares de empresas iniciaram aquilo que ficou conhecido como:

Cloud Migration.

Mas alguns anos depois algo inesperado começou a acontecer.

Empresas gigantes passaram a fazer o caminho inverso.

Sim.

O movimento contrário.

Retirar sistemas da nuvem.

Trazer aplicações de volta para datacenters próprios.

Mover cargas para ambientes especializados.

Consolidar plataformas.

Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:

Cloud Repatriation.

Ou simplesmente:

Repatriação da Nuvem.

E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.

Porque ele está mudando a forma como as empresas enxergam tecnologia.

---

O sonho da nuvem

Vamos voltar alguns anos.

Imagine uma empresa tradicional.

Ela possui:

• servidores físicos;

• storage;

• rede;

• datacenter;

• equipe de infraestrutura.

Tudo precisa ser comprado.

Tudo precisa ser instalado.

Tudo precisa ser mantido.

Quando a nuvem chegou, a promessa parecia revolucionária.

Ao invés de comprar:

• você alugaria.

Ao invés de esperar semanas:

• criaria recursos em minutos.

Ao invés de investir milhões:

• pagaria apenas pelo uso.

Parecia perfeito.

E para muitas situações realmente era.

---

O nascimento do "Cloud First"

Entre 2015 e 2022 surgiu uma expressão muito popular.

Cloud First.

Ou seja:

"A nuvem primeiro."

Toda nova solução deveria nascer em cloud.

Muitas organizações foram além.

Não apenas criaram sistemas novos.

Também migraram sistemas antigos.

Tudo virou candidato à nuvem.

ERP.

CRM.

Banco de dados.

Analytics.

Arquivos.

Aplicações críticas.

Em muitos casos sem uma análise profunda de custo-benefício.

---

A pergunta que ninguém fazia

Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:

"Quanto isso custará daqui a cinco anos?"

A maioria analisava apenas:

• velocidade;

• facilidade;

• inovação.

Mas ignorava:

• crescimento;

• consumo;

• escalabilidade financeira.

A conta parecia pequena no início.

Mas crescia silenciosamente.

---

A armadilha do sucesso

Imagine uma fintech.

Primeiro ano:

100 mil clientes.

Segundo ano:

1 milhão.

Terceiro ano:

10 milhões.

Quarto ano:

50 milhões.

Tudo parece ótimo.

Mas existe um detalhe.

Cada cliente gera:

• armazenamento;

• processamento;

• logs;

• backups;

• monitoramento;

• tráfego de rede.

Quanto mais sucesso a empresa tem, maior fica a fatura.

O paradoxo é interessante.

O crescimento do negócio aumenta também o custo operacional da nuvem.

---

Quando chega a conta

É nesse momento que começa a repatriação.

Os diretores financeiros começam a fazer perguntas.

Por exemplo:

• Estamos usando tudo que pagamos?

• Precisamos realmente dessa configuração?

• Existe alternativa mais barata?

• O custo por transação está aumentando?

• O retorno continua justificando o investimento?

E muitas vezes a resposta é surpreendente.

Nem toda carga de trabalho se beneficia economicamente da nuvem.

---

A analogia da casa

Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.

No começo você mora de aluguel.

Faz sentido.

Você ainda está começando.

Precisa de flexibilidade.

Não quer investir muito.

Mas imagine que passaram vinte anos.

Você continua pagando aluguel.

Todo mês.

Sem parar.

Em algum momento surge a pergunta:

"Não seria melhor comprar?"

A repatriação nasce exatamente dessa reflexão.

---

O caso do Dropbox

Um dos exemplos mais famosos ocorreu com o Dropbox.

Durante anos a empresa utilizou cloud pública.

Mas conforme cresceu percebeu algo importante.

O volume de armazenamento era gigantesco.

A escala era enorme.

A previsibilidade era alta.

O resultado?

Passou a investir fortemente em infraestrutura própria.

A economia foi medida em centenas de milhões de dólares ao longo dos anos.

Isso chamou a atenção do mercado.

---

O caso da 37signals

Outro exemplo muito discutido foi a empresa por trás do Basecamp.

Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.

O argumento principal?

Economia.

Segundo eles, a redução de custos seria enorme.

A notícia gerou debates em toda a indústria.

---

O que isso ensina para uma Analista COBOL?

Ensina algo extremamente importante.

Tecnologia não é religião.

Não existe:

• Mainframe bom.

• Cloud ruim.

Nem o contrário.

Existe apenas:

o ambiente correto para a carga correta.

Essa é uma das maiores lições da arquitetura moderna.

---

Nem toda carga é igual

Imagine duas aplicações.

Primeira aplicação:

• Website promocional.

• Acessos variáveis.

• Crescimento imprevisível.

Cloud faz sentido.

Agora imagine:

• processamento de contas bancárias;

• liquidação financeira;

• batch noturno;

• milhões de transações previsíveis.

Talvez a análise econômica seja diferente.

Talvez uma plataforma especializada seja mais eficiente.

Talvez um mainframe seja mais competitivo.

Tudo depende do contexto.

---

O papel do Mainframe nessa história

É aqui que muitos jovens profissionais ficam surpresos.

Durante anos ouviram que o Mainframe estava desaparecendo.

Mas a realidade mostrou algo curioso.

Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.

Por quê?

Porque o Mainframe foi construído justamente para:

• alta escala;

• alta disponibilidade;

• processamento transacional;

• confiabilidade extrema.

Essas características continuam valiosas.

Muito valiosas.

---

O custo invisível da nuvem

Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.

Na cloud surgem custos menos óbvios.

Por exemplo:

• transferência de dados;

• snapshots;

• logs;

• replicação;

• monitoramento;

• APIs;

• tráfego entre regiões.

Cada item parece pequeno.

Somados podem se tornar gigantescos.

É por isso que tantas empresas passaram a adotar práticas de FinOps.

---

O nascimento do FinOps

FinOps significa:

Financial Operations.

Ou seja:

Operações financeiras aplicadas à tecnologia.

Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:

• Quem está consumindo recursos?

• Quanto custa cada aplicação?

• Qual é o custo por cliente?

• Qual é o custo por transação?

Isso praticamente não existia no início da corrida para a nuvem.

---

A verdade que ninguém gosta de ouvir

Existe uma verdade que incomoda muitos vendedores de tecnologia.

Nem toda inovação reduz custos.

Algumas aumentam custos.

Mas aumentam receita.

E isso pode ser perfeitamente aceitável.

Cloud frequentemente se encaixa nesse cenário.

A empresa paga mais.

Mas cresce mais rápido.

Lança produtos mais rapidamente.

Conquista clientes mais cedo.

Portanto o custo adicional pode valer a pena.

---

Então por que repatriar?

Porque chega um momento em que determinadas cargas se tornam:

• previsíveis;

• estáveis;

• maduras.

Nesse ponto a elasticidade da cloud perde parte do valor.

E a eficiência operacional começa a ganhar importância.

A pergunta muda.

Deixa de ser:

"Como crescer?"

E passa a ser:

"Como operar com eficiência?"

---

O futuro é híbrido

Talvez essa seja a maior conclusão.

O futuro não parece ser:

• tudo na cloud;

• tudo no mainframe;

• tudo on-premises.

O futuro parece híbrido.

Cada carga de trabalho executada no ambiente mais adequado.

É exatamente isso que vemos nos grandes bancos.

Itaú.

Bradesco.

Banco do Brasil.

Santander.

Caixa.

Todos operam ambientes mistos.

Cloud.

Linux.

Containers.

APIs.

Mainframe.

Tudo convivendo.

Tudo integrado.

---

O que você deve aprender como profissional

Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.

Pelo contrário.

O mercado está procurando profissionais que entendam integração.

Profissionais que consigam conversar sobre:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Kubernetes;

• IBM Z;

• Arquitetura distribuída.

Porque a verdadeira transformação digital não consiste em destruir o legado.

Consiste em conectá-lo ao futuro.

---

Conclusão: O Retorno da Maturidade Tecnológica

Cloud Repatriation não significa fracasso da nuvem.

Também não significa vitória do Mainframe.

Significa algo muito mais interessante.

Significa maturidade.

O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.

Nem por marketing.

Nem por tendências.

Ela deve ser escolhida por critérios objetivos:

• custo;

• desempenho;

• segurança;

• disponibilidade;

• escalabilidade.

A nuvem continuará crescendo.

Os datacenters continuarão existindo.

Os mainframes continuarão processando bilhões de transações.

E as arquiteturas híbridas se tornarão cada vez mais comuns.

Para uma Analista COBOL Júnior, essa é uma excelente notícia.

Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.

O profissional do futuro não será aquele que conhece apenas uma tecnologia.

Será aquele que entende quando usar cada uma delas.

E talvez essa seja a maior lição da Cloud Repatriation.

Às vezes a inovação não está em mover tudo para a nuvem.

Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.

 

Bellacosa Mainframe quando o sonho da nuvem virada pesadelo

☕💸☁️ CLOUD BILL SHOCK — QUANDO A FATURA DA NUVEM CHEGA E O MAINFRAME COMEÇA A PARECER BARATO

Existe um momento muito curioso na vida de quase toda empresa que embarca na jornada da computação em nuvem.

No início tudo parece maravilhoso.

O desenvolvedor cria um servidor em poucos minutos.

O ambiente de testes nasce instantaneamente.

Os sistemas escalam sozinhos.

As equipes ganham agilidade.

Os executivos sorriem.

Os arquitetos comemoram.

Os fornecedores fazem apresentações cheias de gráficos coloridos.

E então chega a primeira fatura realmente grande.

Nesse momento nasce um fenômeno que ficou conhecido mundialmente como:

Cloud Bill Shock.

Ou, em português:

O Choque da Fatura da Nuvem.

Para muitos profissionais jovens, especialmente quem está começando carreira em COBOL e Mainframe, esse termo parece estranho.

Afinal, durante anos ouvimos que a nuvem era mais moderna, mais simples e mais barata.

Mas a realidade dos grandes ambientes corporativos mostrou uma verdade muito interessante.

Cloud pode ser fantástica.

Cloud pode ser revolucionária.

Cloud pode acelerar negócios.

Mas cloud nem sempre é barata.

E algumas empresas descobriram isso da forma mais dolorosa possível.

Ao abrir a fatura no final do mês.

---

O que uma Analista COBOL Júnior precisa entender

Vamos começar do início.

Imagine que você trabalha em um banco tradicional.

Existe um ambiente mainframe que processa:

• contas correntes;

• cartões;

• PIX;

• empréstimos;

• aplicações financeiras.

Tudo funciona há décadas.

O sistema está pago.

A infraestrutura está instalada.

Os profissionais conhecem a plataforma.

Os processos são estáveis.

Então surge a pergunta:

"Por que não colocar tudo na nuvem?"

Parece uma pergunta simples.

Mas a resposta é extremamente complexa.

Porque existe uma enorme diferença entre:

custo inicial
e
custo operacional contínuo.

---

O encanto da nuvem

Imagine uma startup recém-criada.

Ela possui:

• 5 desenvolvedores;

• 1 produto;

• 100 clientes.

Comprar um datacenter próprio seria loucura.

A nuvem resolve o problema.

Você cria:

• servidores;

• bancos de dados;

• armazenamento;

• monitoramento.

Tudo com poucos cliques.

O modelo parece perfeito.

E realmente é.

Nesse estágio.

---

O problema da escala

Agora imagine que essa startup cresceu.

Não possui mais:

• 100 clientes.

Possui:

• 1 milhão.

Depois:

• 10 milhões.

Depois:

• 50 milhões.

Depois:

• 100 milhões.

Agora o cenário muda completamente.

Cada operação gera consumo.

Cada acesso gera consumo.

Cada consulta gera consumo.

Cada byte armazenado gera consumo.

Cada transferência de dados gera consumo.

Cada serviço adicional gera consumo.

A conta começa a crescer.

E cresce rapidamente.

---

O aluguel invisível

Uma forma simples de explicar cloud para um iniciante é esta:

Mainframe tradicional muitas vezes funciona como casa própria.

Cloud funciona como aluguel.

Imagine um apartamento alugado.

No começo parece excelente.

Pouco investimento inicial.

Entrada reduzida.

Flexibilidade.

Mas depois de vinte anos pagando aluguel...

Você percebe que gastou uma fortuna.

Cloud possui comportamento parecido.

Você paga continuamente por:

• CPU;

• memória;

• armazenamento;

• rede;

• backup;

• tráfego;

• monitoramento;

• segurança.

A conta nunca para.

---

O dia em que o financeiro descobre a AWS

Existe uma história que se repete em inúmeras empresas.

A área técnica está feliz.

A inovação está acelerada.

Os desenvolvedores estão satisfeitos.

Então o departamento financeiro recebe a fatura.

Primeiro mês:

US$ 5 mil.

Segundo mês:

US$ 20 mil.

Terceiro mês:

US$ 80 mil.

Sexto mês:

US$ 500 mil.

Um ano depois:

milhões de dólares.

Nesse momento alguém pergunta:

"Por que estamos gastando tudo isso?"

E nasce uma investigação corporativa.

---

O caso do armazenamento

Uma analista COBOL talvez pense:

"Mas armazenamento é barato."

Sim.

Individualmente.

Mas vamos fazer uma conta simples.

Imagine um banco com:

• 100 milhões de clientes;

• documentos digitalizados;

• extratos;

• imagens;

• logs;

• backups;

• auditoria.

Estamos falando de petabytes.

Talvez dezenas de petabytes.

Quando o volume cresce, cada centavo por gigabyte se transforma em milhões.

---

O inimigo chamado Data Transfer

Existe uma cobrança que assusta muitos arquitetos.

Transferência de dados.

Os provedores de nuvem adoram falar sobre armazenamento.

Sobre CPU.

Sobre inteligência artificial.

Mas existe um detalhe.

Mover dados também custa dinheiro.

Muito dinheiro.

Imagine:

• aplicativos móveis;

• APIs;

• integrações;

• analytics;

• parceiros externos.

Bilhões de chamadas.

Bilhões de respostas.

Terabytes trafegando diariamente.

Cada pacote possui custo.

---

O pesadelo do ambiente esquecido

Todo analista experiente já viu isso.

Um desenvolvedor cria:

• servidor de teste;

• banco temporário;

• ambiente experimental.

O projeto termina.

O ambiente fica ligado.

Dias passam.

Meses passam.

Anos passam.

Ninguém percebe.

Mas a cobrança continua.

Existem empresas pagando milhares de dólares por recursos esquecidos.

---

O efeito multiplicador dos microsserviços

Os microsserviços trouxeram inúmeras vantagens.

Mas também criaram novos desafios.

No mundo tradicional talvez existisse:

• uma aplicação;

• um banco de dados.

No mundo moderno podemos ter:

• centenas;

• milhares;

• dezenas de milhares de serviços.

Cada um consumindo:

• CPU;

• memória;

• armazenamento;

• rede.

Separadamente parecem baratos.

Juntos tornam-se gigantescos.

---

Quando o Mainframe entra na conversa

É aqui que uma analista COBOL começa a entender o debate.

Um mainframe não é vendido como servidor barato.

Nunca foi.

Mas existe algo impressionante nele.

Consolidação.

Um único IBM Z moderno pode processar volumes absurdos de transações.

Em muitos casos substituindo centenas ou milhares de servidores distribuídos.

O resultado é que algumas cargas financeiras apresentam:

• menor consumo energético;

• menor ocupação física;

• menor administração;

• menor complexidade operacional.

Por isso o cálculo econômico não é tão simples quanto parece.

---

O choque das empresas famosas

Nos últimos anos surgiu um movimento chamado:

Cloud Repatriation

Traduzindo:

"Trazer sistemas de volta."

Empresas que migraram tudo para cloud começaram a revisar decisões.

Não porque a nuvem fosse ruim.

Mas porque certas cargas de trabalho ficaram caras demais.

Algumas descobriram economias milionárias ao mover parte dos ambientes para:

• infraestrutura própria;

• colocation;

• plataformas especializadas.

O mercado percebeu que não existe solução mágica.

---

O erro mais comum dos iniciantes

Muitos profissionais novos acreditam que arquitetura é apenas tecnologia.

Mas arquitetura também é economia.

Um arquiteto precisa entender:

• desempenho;

• segurança;

• disponibilidade;

• custos.

A melhor solução técnica do mundo pode fracassar se custar dez vezes mais que o necessário.

---

O que os bancos aprenderam

Os grandes bancos possuem uma experiência valiosa.

Eles processam bilhões de transações há décadas.

Por isso normalmente adotam arquitetura híbrida.

Não colocam tudo na cloud.

Também não deixam tudo no mainframe.

Cada ambiente recebe a carga mais adequada.

Por exemplo:

Aplicativo móvel?

Cloud.

Machine Learning?

Cloud.

Analytics?

Cloud.

Core bancário?

Talvez mainframe.

Liquidação financeira?

Talvez mainframe.

Processamento crítico?

Talvez mainframe.

---

O paradoxo que ninguém conta

Aqui está a parte mais interessante.

O objetivo da cloud nunca foi ser sempre mais barata.

O objetivo principal era:

agilidade.

Você consegue lançar produtos rapidamente.

Experimentar ideias.

Criar novos serviços.

Escalar em minutos.

Essa velocidade possui valor.

Muitas vezes o ganho de negócio compensa o aumento de custo.

Por isso empresas continuam investindo bilhões em nuvem.

---

O que uma Analista COBOL deve aprender com isso

Talvez a maior lição seja esta.

Não existe guerra entre Mainframe e Cloud.

Essa guerra só existe em apresentações simplificadas.

No mundo real os dois convivem.

E convivem muito bem.

O profissional moderno precisa compreender:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Integração;

• Arquitetura distribuída.

Porque o mercado não procura especialistas que conhecem apenas um lado.

Procura profissionais que entendem como tudo se conecta.

---

Conclusão: Quando a Fatura Vira Professor

Cloud Bill Shock é uma das lições mais importantes da tecnologia moderna.

Ele nos lembra que inovação possui custo.

Escalabilidade possui custo.

Conveniência possui custo.

Flexibilidade possui custo.

A nuvem transformou a indústria.

Permitiu o nascimento de empresas como Nubank, Mercado Pago e centenas de fintechs.

Mas também ensinou uma lição valiosa.

Quando os números chegam à casa dos milhões de clientes e bilhões de transações, a discussão deixa de ser tecnológica.

Passa a ser econômica.

E é justamente nesse momento que muitos executivos voltam a olhar para tecnologias que julgavam ultrapassadas.

Mainframe.

COBOL.

CICS.

DB2.

IBM Z.

Não porque sejam antigos.

Mas porque continuam resolvendo problemas extremamente difíceis com eficiência impressionante.

Por isso, da próxima vez que alguém disser que o futuro pertence apenas à nuvem, lembre-se de uma verdade que o mercado financeiro aprendeu ao longo das décadas:

A tecnologia mais moderna nem sempre é a mais barata.
A mais antiga nem sempre é a mais cara.
E a melhor arquitetura quase sempre é aquela que equilibra inovação, desempenho e custo.

É exatamente nesse ponto que nasce o verdadeiro arquiteto de sistemas.

E é exatamente aí que uma analista COBOL deixa de enxergar apenas código e começa a enxergar negócios.

 

Bellacosa Mainframe fala sobre Cloud Terraform RACF

☁️🔥 Do RACF ao Terraform: Como um Padawan Mainframe Pode Dominar a Nuvem Antes que a Nuvem Domine Você

“A cloud não substituiu o mainframe. Ela apenas espalhou o mainframe pelo planeta — sem manual impresso.”

Se você vem do mundo z/OS, COBOL, CICS, JCL ou operações críticas, este artigo é para você, jovem Padawan. 🧭
Vamos traduzir Cloud Adoption + Cloud Governance + IaC + Segurança para o idioma mainframe — com exemplos reais, curiosidades e alguns easter eggs técnicos no caminho.

---

🧠 A Grande Verdade Que Ninguém Te Conta

Cloud não é “servidor alugado”.

Cloud é:

🏛️ Infraestrutura + Automação + Governança + Segurança + FinOps + Cultura

Sem governança, a cloud vira:

🔥 Caos rápido
💸 Conta gigantesca
🔓 Vulnerabilidades
🕵️ Shadow IT
📉 Falta de controle

---

🏗️ Cloud Adoption = Plano de Migração (Estilo SMPE do Século XXI)

Antes de mover qualquer workload, você precisa responder:

• Por que migrar?
• O que migrar?
• Quando migrar?
• Vale a pena migrar?
• Como voltar se der ruim?

Sim… Exit Strategy é obrigatório.

🧩 Analogia mainframe

Cloud	Mainframe
Cloud Adoption Strategy	Plano de capacity + modernização
Workload migration	Conversão batch / online
Exit strategy	DR site alternativo
Hybrid cloud	Sysplex + distribuído

---

⚔️ As Estratégias de Migração (Os “Rs” da Força)

Nem todo sistema deve ser tratado igual.

🚚 Rehost — Lift and Shift

Mover sem alterar.

👉 Como rodar um COBOL antigo em outro LPAR sem recompilar.

---

✏️ Revise — Ajustar um pouco

Pequenas melhorias para rodar melhor na cloud.

👉 Tipo recompilar com novo runtime.

---

🧠 Refactor — Modernizar arquitetura

Mudanças profundas.

👉 Monolito → Microservices
👉 CICS → APIs
👉 Batch → Event-driven

---

🔄 Replace — Trocar por SaaS

Abandonar o sistema próprio.

👉 Sistema de RH interno → solução pronta.

---

🧱 Rebuild — Reescrever tudo

Quando o legado virou fóssil.

👉 Recriar do zero com arquitetura cloud-native.

---

🏛️ Cloud Governance = RACF + JES + SMF + Auditoria… Só que Global

Governança é o que impede a cloud de virar faroeste.

🎯 Objetivos principais

• 🔐 Segurança
• 💰 Controle de custos
• ⚙️ Operação estável
• 📜 Compliance
• 📊 Monitoramento
• 🧩 Padronização

---

🕵️ Shadow IT — O “Batch Fantasma” da Cloud

Equipes criam recursos sem controle.

Resultado:

🧟 Servidores esquecidos
💸 Custos ocultos
🔓 Riscos
📉 Ninguém sabe o que existe

No mainframe isso seria impensável.

Na cloud? Dois cliques.

---

💰 FinOps — Porque a Conta Chega TODO MÊS

Na cloud você paga por:

• CPU
• Memória
• Storage
• Rede (principalmente rede!)
• Serviços gerenciados
• Recursos ociosos 😈

💣 Maiores vilões

1. Recursos esquecidos
2. Transferência de dados
3. Superdimensionamento
4. Falta de autoscaling

---

⚡ Autoscaling — O WLM da Nuvem

Ajusta capacidade automaticamente.

🧠 Exemplo

E-commerce:

• Normal → poucos servidores
• Black Friday → centenas
• Depois → volta ao normal

Sem autoscaling = pagar pico o ano inteiro.

---

📍 Regra de Ouro da Arquitetura Cloud

💰 “Você paga pela arquitetura que desenha.”

Mover dados entre regiões custa caro.
Mover entre cloud e on-prem custa MAIS caro ainda.

---

🔐 Segurança: O Modelo de Responsabilidade Compartilhada

Cloud NÃO é “segurança terceirizada”.

☁️ Provedor protege:

• Datacenter
• Hardware
• Infra base

🏢 Cliente protege:

• Dados
• Aplicações
• Configuração
• Identidades
• Acessos

👉 Bucket público com dados sensíveis? Culpa sua.

---

🪪 IAM — O RACF da Cloud (Easter Egg #1)

Identity and Access Management é o novo perímetro.

Não existe mais “cerca” física.

Quem controla identidade controla tudo.

Boas práticas dignas de um sysprog Jedi:

✔️ Princípio do menor privilégio
✔️ MFA obrigatório
✔️ Roles, não usuários diretos
✔️ Auditoria contínua

---

🗄️ Data Management — Nem Todo Dado É Igual

Classificação é essencial.

Tipo	Proteção
Público	Básica
Interno	Moderada
Confidencial	Alta
Regulado	Máxima

Aplicar segurança máxima a tudo = caro e ineficiente.

---

📦 Arquivamento — O Hierarchical Storage Management da Cloud

Dados frios devem ir para storage barato.

🔥 Hot → rápido e caro
🌤️ Cool → intermediário
❄️ Archive → lento e barato

Padawan que não arquiva dados… paga caro.

---

⚙️ Infrastructure as Code — O JCL da Cloud (Easter Egg #2)

Na cloud madura, ninguém cria infraestrutura clicando.

Tudo é código.

Exemplo mental:

👉 JCL cria job
👉 IaC cria infraestrutura

Ferramentas comuns

• Terraform
• Ansible
• CloudFormation
• Bicep

---

💻 Exemplo simplificado (Terraform)

Criar uma VM inteira com código:

• Região definida
• Tipo de máquina
• Sistema operacional
• Tags de governança

Reprodutível. Auditável. Versionado.

---

🧩 Por que IaC é obrigatório?

Sem automação:

❌ Deploy manual inseguro
❌ Configurações divergentes
❌ Ambientes inconsistentes
❌ Custos fora de controle
❌ Difícil auditoria

Com IaC:

✔️ Padronização
✔️ Segurança embutida
✔️ Aprovação controlada
✔️ Recriação rápida
✔️ Governança executável

---

🧟 Cloud Sprawl — O “Dataset Órfão” em Escala Planetária

Recursos acumulados sem uso.

Exemplos:

• VMs esquecidas
• Discos soltos
• Snapshots antigos
• Ambientes de teste abandonados

Grandes empresas economizam milhões apenas limpando isso.

---

🧭 O Fluxo Completo da Adoção Cloud

🔎 Assess → 🗺️ Plan → 🚀 Adopt → 🏛️ Govern → ⚡ Optimize

Pular etapas = sofrimento garantido.

---

🧠 Insight de Arquitetura Avançada

Cloud não falha por tecnologia — falha por governança, planejamento e pessoas.

---

🧪 Easter Egg Final

Se você domina:

• RACF
• Auditoria
• Capacity planning
• Operação 24x7
• Sistemas críticos

👉 Você já tem metade do DNA de um Cloud Architect.

O resto é aprender as ferramentas.

---

🏆 Mensagem ao Padawan

A nuvem não matou o mainframe.

Ela espalhou seus princípios:

✔️ Alta disponibilidade
✔️ Segurança rigorosa
✔️ Escalabilidade
✔️ Automação
✔️ Governança
✔️ Processamento crítico

---

☕ Conclusão no Estilo Bellacosa

O verdadeiro poder não está em migrar para a cloud.
Está em governar a cloud sem perder a disciplina do mainframe.

Padawan, se você trouxer a mentalidade z/OS para a nuvem…

👉 Você não será apenas um usuário de cloud.
👉 Você será o arquiteto que impede que tudo desmorone.