✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
☁️💥 Do JCL ao Kubernetes: Como um Padawan Pode Dominar a Nuvem Sem Virar Vapor
“Na galáxia da TI, alguns pilotam X-Wings… outros ainda estão aprendendo a ligar o hyperdrive.”
Se você é um Padawan da Cloud — ou até um Jedi do mainframe explorando novos planetas — este artigo é para você. Vamos atravessar juntos o caminho do zero até arquiteto, com exemplos reais, curiosidades, easter eggs e aquela pitada Bellacosa de conhecimento que não se aprende em slide corporativo. ☕🖥️☁️
🧠 Episódio I — O Despertar da Nuvem
Antes de containers, Kubernetes ou nomes complicados…
👉 Cloud é só alguém rodando computadores para você — em escala absurda.
No mundo on-premises:
Você compra hardware 💸
Instala tudo 🧱
Mantém tudo 🔧
Culpa o ar-condicionado quando cai 🧊
Na cloud:
Você aluga capacidade
Paga pelo uso
Escala sob demanda
💡 Curiosidade mainframe:
O modelo pay-per-use da cloud lembra MUITO o velho conceito de capacity on demand dos grandes sistemas.
🏗️ Episódio II — IaaS, PaaS, SaaS… ou “Quem Faz o Trabalho?”
Imagine que você quer comer pizza 🍕
🧱 On-Prem → você planta o trigo, cria a vaca e assa
🏗️ IaaS → você assa
⚙️ PaaS → você só coloca o recheio
🍕 SaaS → entregam pronta
👉 Quanto mais alto na pilha, menos trabalho (e menos controle).
🌍 Episódio III — Onde Mora a Nuvem?
Modelos de deployment:
☁️ Public — infraestrutura compartilhada
🏢 Private — exclusiva
🌗 Hybrid — mistura dos dois
🌍 Multicloud — vários provedores
🤝 Community — organizações com interesses comuns
💡 Exemplo real:
Banco com dados críticos on-prem + analytics na nuvem = Hybrid.
📦 Episódio IV — Storage: O Cofre dos Dados
Três tipos dominam a galáxia:
🧱 Block Storage
Disco bruto — ideal para bancos.
👉 Pense: DASD virtual.
📂 File Storage
Pastas e arquivos hierárquicos.
👉 Tipo um compartilhamento NFS/SMB.
🎬 Object Storage
Para dados não estruturados:
Vídeos
Fotos
Logs
Backups
💡 Easter egg:
Object storage não tem “diretórios de verdade”. Aquela pastinha é só uma ilusão… tipo o Millennium Falcon parado no espaço.
🐳 Episódio V — Containers: O Segredo da Cloud Moderna
VMs são como apartamentos completos 🏢
Containers são kitnets minimalistas 🐳
Containers:
✔️ Mais leves
✔️ Iniciam rápido
✔️ Compartilham o kernel
✔️ Escalam fácil
🧾 Dockerfile — A Receita do Container
FROM ubuntu COPY app /app CMD ["./app"]
👉 Isso vira uma imagem → que vira container → que roda seu app.
💡 Comentário Bellacosa:
Se JCL descreve job steps… o Dockerfile descreve build steps.
☸️ Episódio VI — Kubernetes: O Maestro dos Containers
Se Docker cria containers, Kubernetes governa exércitos deles.
Principais conceitos:
Pod → unidade mínima
Node → máquina
Cluster → várias máquinas
Service → endereço fixo
Deployment → controla versões
🗄️ etcd — O Cérebro do Cluster
👉 Banco de dados que guarda TODO o estado.
Sem ele:
Kubernetes vira um amnésico digital.
⚡ Episódio VII — Serverless: Código Sem Servidor?
Sim e não.
Você não vê o servidor.
FaaS roda código:
Sob demanda
Escala automática
Paga só pelo uso
💡 Ideal para eventos, APIs simples e automações.
🔐 Episódio VIII — Segurança e Sensibilidade
Nem tudo deve ir para public cloud.
Private ou hybrid são comuns quando há:
Dados financeiros 🏦
Dados médicos 🏥
Segredos governamentais 🏛️
🤖 Episódio IX — Infraestrutura Imutável
Antigamente:
👉 Atualize o servidor.
Hoje:
👉 Destrua e recrie.
Isso reduz inconsistências e bugs misteriosos.
💡 Analogia:
Trocar a nave inteira em vez de consertar no espaço.
🧬 Episódio X — Cloud-Native vs Monólito
🧱 Monólito
Tudo num bloco só.
Vantagem: simples.
Desvantagem: difícil de escalar.
☁️ Cloud-Native
Microservices
APIs
Containers
Automação
Observabilidade
👉 Projetado para falhar e continuar funcionando.
🏆 Episódio XI — O Caminho do Arquiteto
Um arquiteto cloud não escolhe tecnologia… escolhe compromissos:
⚖️ Custo × Performance × Segurança × Resiliência
Princípios Jedi:
🛡️ Design for failure
📈 Scale out
🔗 Loose coupling
🤖 Automação
💰 Otimização de custos
☕ Easter Egg Mainframe Edition
Cloud parece nova… mas várias ideias nasceram no mainframe:
Time sharing → multi-tenant
Capacity on demand → elasticidade
Virtualização → VMs
Alta disponibilidade → Sysplex
👉 A nuvem não reinventou a roda. Só colocou foguetes nela.
🚀 Missão Final para o Padawan
Se você quer evoluir de dev para arquiteto:
1️⃣ Entenda fundamentos
2️⃣ Aprenda containers
3️⃣ Domine Kubernetes
4️⃣ Explore serverless
5️⃣ Pense em arquitetura, não em código
🌟 Conclusão — Que a Força da Nuvem Esteja com Você
Cloud não é só tecnologia.
É uma nova forma de operar sistemas em escala planetária.
Você não precisa saber tudo.
Precisa saber como as peças se encaixam.
“Um Padawan aprende ferramentas.
Um Jedi entende sistemas.”
O Guia Definitivo do Programador COBOL Padawan para Entender a Plataforma que Virou o "z/OS da Nuvem"
"A tecnologia muda. Os princípios permanecem."
— Adaptado da filosofia vulcana do Sr. Spock
Introdução — Quando o mundo saiu do CPD
Se você começou sua carreira em um CPD tradicional, talvez tenha ouvido frases como:
"O programa está em produção."
"Vamos fazer o deploy no fim de semana."
"Precisamos subir outra LPAR."
"Chama o operador."
"O Sysprog já autorizou."
Durante décadas, essa foi a realidade do desenvolvimento corporativo.
Enquanto isso, um novo mundo surgia.
Primeiro vieram os servidores Linux.
Depois as máquinas virtuais.
Depois os containers.
E finalmente apareceu uma tecnologia que mudou completamente a forma de executar aplicações:
Kubernetes.
Hoje praticamente toda grande empresa utiliza Kubernetes em algum lugar.
Google.
Amazon.
Netflix.
Spotify.
Nubank.
Mercado Livre.
IBM.
Red Hat.
Microsoft.
Oracle.
SAP.
Mas existe uma curiosidade interessante.
Embora muitos pensem que Kubernetes representa uma revolução completa, para quem trabalha há anos com IBM Z, muita coisa parece incrivelmente familiar.
Na verdade, boa parte dos conceitos que hoje são chamados de "Cloud Native" já existiam no universo mainframe, apenas com nomes diferentes.
Hoje vamos fazer exatamente essa viagem.
Pegue sua caneca de café.
Abra o ISPF...
...ou o VS Code.
E vamos descobrir por que Kubernetes talvez seja o primo moderno do z/OS.
O que é Kubernetes?
A resposta rápida costuma ser:
"É um orquestrador de containers."
Correto.
Mas extremamente incompleto.
Uma definição muito melhor seria:
Kubernetes é um Sistema Operacional Distribuído capaz de administrar milhares de aplicações executando simultaneamente em centenas ou milhares de servidores.
Perceba a palavra importante:
administrar.
Ele não executa apenas containers.
Ele administra:
disponibilidade
escalabilidade
armazenamento
rede
segurança
monitoramento
atualização
recuperação
balanceamento
automação
Ou seja...
Ele faz exatamente aquilo que o z/OS faz há décadas.
O Kubernetes procura um volume compatível e faz a associação.
CSI
Container Storage Interface.
É uma interface padronizada para integrar armazenamento.
Suporta soluções como:
IBM FlashSystem
IBM Storage Scale
NetApp
Dell
AWS EBS
Azure Disk
Google Persistent Disk
Networking — O assunto que mais assusta
Todo Pod recebe seu próprio endereço IP.
Isso elimina diversas limitações antigas.
DNS
Cada Service ganha um nome.
orders.default.svc.cluster.local
A aplicação usa nomes, não IPs.
kube-proxy
Encaminha tráfego para os Pods corretos.
CNI
Container Network Interface.
É o "driver de rede" do Cluster.
Exemplos:
Calico
Cilium
Flannel
OVN-Kubernetes
Network Policies
Funcionam como firewalls internos.
Você pode permitir, por exemplo:
Frontend
↓
Backend
↓
Banco
Enquanto bloqueia qualquer acesso direto do Frontend ao banco.
Service Mesh
Imagine um "corredor inteligente" entre microsserviços.
Ferramentas como Istio ou Linkerd oferecem:
mTLS
retries automáticos
circuit breaker
roteamento avançado
telemetria
Sem alterar o código da aplicação.
Helm — O instalador do Kubernetes
Helm é frequentemente comparado a um gerenciador de pacotes.
Com um único comando você instala aplicações completas.
helm install grafana
Pronto.
Grafana inteiro.
Com Deployments.
Services.
Volumes.
Secrets.
Tudo configurado.
Kustomize
Enquanto Helm distribui aplicações...
Kustomize adapta configurações para ambientes diferentes.
DEV.
QA.
Homologação.
Produção.
Sem duplicar arquivos.
GitOps
Talvez uma das maiores revoluções dos últimos anos.
O Git deixa de ser apenas um repositório de código.
Ele passa a representar o estado oficial da infraestrutura.
Fluxo:
Git
↓
Argo CD ou Flux
↓
Kubernetes
↓
Deploy automático
Mudou o repositório?
O Cluster converge automaticamente para a nova configuração.
Estratégias modernas de Deploy
Rolling Update
Atualiza gradualmente.
Sem indisponibilidade.
Blue-Green
Mantém duas versões completas.
Depois troca o tráfego de uma só vez.
Canary
Começa pequeno.
1%
↓
5%
↓
10%
↓
25%
↓
50%
↓
100%
Se algo der errado...
Basta interromper.
Segurança
Assim como RACF é essencial no z/OS...
Segurança também é indispensável no Kubernetes.
Principais recursos:
RBAC
IAM
Security Context
Secrets
Criptografia
Políticas de rede
Admission Controllers
A recomendação atual é seguir o princípio do menor privilégio: conceder apenas as permissões estritamente necessárias para cada usuário, serviço ou aplicação.
Observabilidade
Não basta executar aplicações.
É preciso enxergar o que está acontecendo.
Ferramentas comuns:
Prometheus
Grafana
OpenTelemetry
Loki
Jaeger
Alertmanager
Elas mostram:
consumo de CPU
memória
latência
erros
logs
traces distribuídos
eventos do cluster
No mundo IBM Z, essa função lembra o papel conjunto de RMF, SMF, OMEGAMON e ferramentas de automação, cada uma especializada em um aspecto da operação.
Comparando Kubernetes com o Mainframe
Kubernetes
IBM Z
Cluster
Sysplex
Node
LPAR
Pod
Unidade de execução isolada (analogia funcional a um address space para fins didáticos)
Service
VIPA / Endereço lógico
Scheduler
WLM
RBAC
RACF
GitOps
Pipeline DBB/Jenkins/ISPW (conceitualmente)
Persistent Volume
DASD
CSI
Camada de integração com armazenamento
Prometheus
RMF/SMF (observabilidade)
A comparação não é perfeita — as arquiteturas são diferentes —, mas ajuda a compreender como muitos conceitos fundamentais de disponibilidade, gerenciamento e automação já eram familiares para profissionais de mainframe.
Curiosidades
☕ Easter Egg nº 2
O nome Kubernetes vem do grego κυβερνήτης (kybernḗtēs), que significa timoneiro, piloto ou aquele que governa uma embarcação.
Da mesma raiz surgiu a palavra Cibernética, criada por Norbert Wiener em 1948 para representar a ciência do controle e da comunicação em máquinas e seres vivos.
☕ Easter Egg nº 3
O famoso logotipo em forma de roda do Kubernetes representa o leme de um navio, reforçando a ideia de conduzir e coordenar aplicações em um ambiente distribuído.
☕ Easter Egg nº 4
Grande parte das ideias do Kubernetes nasceu da experiência do Google com um sistema interno chamado Borg, utilizado para gerenciar milhões de workloads muito antes da popularização da computação em nuvem.
Dicas para o Programador COBOL Padawan
Se você vem do universo COBOL e IBM Z, não tente decorar centenas de comandos logo no início. Construa uma base sólida:
Aprenda Docker antes de Kubernetes.
Entenda bem Pods, Deployments e Services.
Estude YAML, pois ele é a linguagem declarativa da plataforma.
Pratique com um cluster local usando Minikube, Kind ou OpenShift Local.
Aprenda kubectl como você aprendeu TSO e ISPF.
Depois avance para Volumes, Networking e Segurança.
Em seguida, mergulhe em Helm, GitOps, Operators e Observabilidade.
Só então explore Service Mesh e arquiteturas distribuídas mais sofisticadas.
Essa sequência torna o aprendizado muito mais natural.
Conclusão — O z/OS da Era Cloud
Existe um velho ditado no universo da engenharia:
"Toda tecnologia realmente nova acaba redescobrindo uma boa ideia do passado."
Kubernetes prova isso.
Ele trouxe uma nova forma de empacotar aplicações, distribuir cargas e automatizar operações em larga escala. Porém, muitos de seus princípios — disponibilidade, isolamento, escalabilidade, controle de acesso, recuperação automática e gerenciamento centralizado — já faziam parte da cultura dos grandes sistemas corporativos há décadas.
Para o programador COBOL Padawan, Kubernetes não deve ser visto como um substituto do IBM Z, mas como uma tecnologia complementar. Hoje é comum encontrar arquiteturas híbridas nas quais aplicações executam no mainframe, APIs são expostas pelo z/OS Connect, mensagens trafegam pelo IBM MQ e microsserviços em Kubernetes consomem essas informações para construir soluções modernas.
O profissional mais valorizado do futuro não será aquele que conhece apenas o mundo distribuído ou apenas o mundo mainframe. Será aquele capaz de conectar ambos com segurança, eficiência e visão arquitetural.
Como diria o Sr. Spock:
"A lógica é o começo da sabedoria, não o fim."
No universo da computação corporativa, compreender Kubernetes amplia sua visão sobre a nuvem; compreender IBM Z revela por que muitos desses conceitos já sustentavam os sistemas mais críticos do planeta muito antes da era dos containers. É nessa combinação entre tradição e inovação que surgem as arquiteturas mais robustas do século XXI.
zCX, Kubernetes/OpenShift e Ansible para IBM Z e LinuxONE — fundamentos para quem conhece muito bem o mainframe, mas resolveu atravessar a fronteira do mundo cloud-native
Imagine a cena.
Você passou décadas aprendendo que produção não é playground.
Conhece JOB, STEP, DD, PROC, catalogação, RACF, CICS, Db2, JES2, SDSF, WLM, Sysplex, datasets, USS e provavelmente consegue desconfiar de um S0C7 antes mesmo de alguém terminar de explicar o incidente.
Então chega alguém e diz:
“Agora vamos colocar a aplicação num container, subir num pod, criar um deployment, colocar num cluster Kubernetes, rodar no OpenShift e automatizar tudo com Ansible.”
O COBOLzeiro olha.
Olha novamente.
E pergunta:
“Mas onde está o JCL?”
É justamente aí que começa esta viagem.
CAPÍTULO 1 — IBM z/OS Container Extensions — zCX
Quando colocaram Linux dentro do z/OS e ninguém precisou pedir desculpas ao JES
1. O que diabos é zCX?
IBM z/OS Container Extensions, normalmente chamado simplesmente de zCX, é uma tecnologia que permite executar aplicações Linux empacotadas em containers dentro de um ambiente hospedado pelo próprio z/OS.
A IBM introduziu zCX como recurso do z/OS 2.4, lançado em 2019. A ideia era permitir que software originalmente construído para Linux on Z pudesse trabalhar muito próximo das aplicações tradicionais do z/OS sem obrigatoriamente exigir o provisionamento de uma LPAR Linux separada.
Isso merece ser repetido porque é justamente onde muitos mainframers erram:
zCX não transforma z/OS em Linux.
E:
um container Linux executado em zCX continua sendo um container Linux.
O que acontece é mais interessante.
O z/OS fornece uma infraestrutura especializada dentro da qual existe um ambiente Linux preparado para executar containers.
A IBM descreve cada instância zCX como uma instância executada em um address space do z/OS, representando um servidor virtual capaz de hospedar aplicações containerizadas.
Para um COBOLzeiro, podemos começar com esta representação mental:
IBM Z
│
├── LPAR z/OS
│ │
│ ├── JES2
│ ├── CICS
│ ├── Db2
│ ├── IMS
│ ├── USS
│ │
│ └── zCX
│ │
│ └── Linux
│ │
│ ├── Container A
│ ├── Container B
│ └── Container C
│
└── outras LPARs
Não é tecnicamente uma descrição completa da implementação, mas é uma excelente primeira fotografia mental.
2. Antes de zCX: por que alguém precisaria disso?
Suponha que uma aplicação COBOL execute no CICS e precise chamar um componente escrito em Java, Go, Python ou Node.js.
O container utiliza serviços fornecidos pelo sistema onde é executado.
A grande diferença é que containerização foi construída para tornar aplicações portáveis e reproduzíveis.
O mantra é:
“Funcionou neste ambiente? O mesmo artefato deverá funcionar naquele.”
Não significa que toda aplicação seja magicamente portátil entre arquiteturas de processador.
Aqui aparece uma palavra fundamental para IBM Z:
s390x
Containers executados no IBM Z normalmente precisam possuir imagens compatíveis com arquitetura s390x.
Um container compilado exclusivamente para x86_64 não ganha poderes mágicos ao atravessar a porta do mainframe.
4. Easter egg nº 1 — container não é máquina virtual
Essa confusão é tão comum que vale tatuar no monitor.
Uma VM normalmente possui:
Hardware
└─ Hypervisor
├─ VM
│ ├─ Kernel
│ └─ Aplicações
└─ VM
├─ Kernel
└─ Aplicações
Containers normalmente compartilham recursos do sistema operacional subjacente:
Sistema operacional
└─ Runtime de containers
├─ Container
├─ Container
└─ Container
zCX adiciona uma camada interessante porque oferece o ambiente Linux necessário para esses containers dentro do universo operacional do z/OS.
Portanto:
container ≠ VM zCX ≠ uma simples VM Linux comum zCX ≠ Docker instalado diretamente no kernel do z/OS
Esta última distinção é importantíssima.
5. O z/OS virou Docker?
Não.
Historicamente zCX forneceu um ambiente Linux voltado à execução de aplicações gerenciadas como containers Docker. A própria documentação IBM descreve zCX dessa forma.
Mas o ecossistema atual ficou mais interessante.
Hoje a IBM documenta separadamente:
z/OS Container Extensions — zCX
zCX for OpenShift
IBM z/OS Container Platform
E isso pode confundir até profissional experiente.
A IBM inclusive diferencia explicitamente as opções modernas de containerização:
Red Hat OpenShift em Linux x86 ou Linux s390x;
zCX com Linux s390x sobre z/OS;
IBM z/OS Container Platform com containers nativos do z/OS.
Portanto nunca use “container no mainframe” como se fosse uma arquitetura única.
Pergunte:
Container onde?
6. As quatro fronteiras que o COBOLzeiro precisa enxergar
A IBM também oferece e documenta arquitetura de referência para Red Hat OpenShift Container Platform sobre IBM Z e LinuxONE.
Além disso, existe zCX Foundation for Red Hat OpenShift, portanto a fronteira não deve ser reduzida à ideia “zCX jamais tem OpenShift”. A própria instrumentação moderna do z/OS diferencia instâncias zCX for Containers, zCX for OpenShift e a appliance relacionada ao z/OS Container Platform.
Isso demonstra como o ecossistema evoluiu desde o zCX original de 2019.
10. Passo a passo mental do zCX
Para começar os estudos, não tente instalar nada ainda.
Primeiro memorize esta sequência:
Passo 1 — existe IBM Z
Hardware.
Passo 2 — existe uma LPAR z/OS
Sistema operacional.
Passo 3 — zCX é provisionado dentro desse universo
O z/OS administra sua existência operacional.
Passo 4 — surge um ambiente Linux
Ele fornece o ambiente necessário para software Linux.
Passo 5 — containers executam ali
As imagens precisam ser adequadas à arquitetura.
Passo 6 — networking conecta os mundos
Container precisa conversar com:
CICS
Db2
IMS
MQ
APIs
Internet
outros servidores
É justamente por isso que networking se torna disciplina central.
A documentação IBM dedica uma seção específica à arquitetura de rede do zCX.
11. Easter egg nº 2 — USS não é zCX
Outro erro maravilhoso.
“Mas z/OS já tinha Unix System Services. Para que Linux?”
Porque:
USS ≠ Linux
USS fornece ambiente POSIX dentro do z/OS.
Linux é outro sistema operacional.
Você pode ter:
z/OS
├─ MVS
├─ USS
└─ zCX
└─ Linux
Um shell parece um shell.
ls parece ls.
Isso não transforma os ambientes na mesma coisa.
É como encontrar duas pessoas usando boina e concluir que ambas são francesas.
12. Onde o COBOL entra nessa história?
Em todo lugar.
O erro de marketing é mostrar containers como substitutos para COBOL.
Na prática muitas arquiteturas modernas são:
Mobile
|
API Gateway
|
Microservices
|
Kafka / MQ
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
O container frequentemente não substitui o sistema transacional.
Ele amplia o ecossistema em volta dele.
Esta é uma das ideias mais importantes para o mainframer moderno:
mainframe modernization não significa obrigatoriamente mainframe migration.
13. Checklist do Padawan zCX
Antes de avançar, você deveria conseguir responder:
O que é zCX?
Em qual release do z/OS apareceu?
Por que zCX possui Linux?
Qual a diferença entre USS e Linux?
O que significa s390x?
Container é VM?
Qual a diferença entre Linux on Z e z/OS?
LinuxONE executa z/OS?
Onde OpenShift entra?
Por que latência e proximidade de dados importam?
Se essas respostas estiverem claras, você ganhou seu primeiro sabre de luz containerizado.
CAPÍTULO 2 — Kubernetes e Red Hat OpenShift Container Platform
Quando alguém percebeu que administrar 3 containers era divertido e 30.000 era um pesadelo
Imagine que você tenha um container.
Tudo lindo.
docker run minha-app
Ele funciona.
Agora o gerente pergunta:
“E se cair?”
Você reinicia.
“E se precisarmos de dez?”
Você inicia dez.
“E se uma máquina morrer?”
Você transfere.
“E se precisarmos atualizar sem parar?”
Você começa a suar.
“E se tivermos 6.000 containers em 400 máquinas?”
Nesse momento nasceu a necessidade conceitual do Kubernetes.
14. Kubernetes: o JES2 dos containers?
A comparação não é perfeita.
Mas para um mainframer ela é deliciosa.
Você não entrega cada batch diretamente ao processador.
Você submete trabalho e deixa toda uma infraestrutura decidir como executá-lo.
Kubernetes faz algo filosoficamente semelhante para aplicações containerizadas.
Você declara:
“Quero três instâncias desta aplicação funcionando.”
Kubernetes tenta manter esse estado.
Isso é chamado de:
Desired State
Você não descreve cada pequena operação.
Você declara o estado esperado.
Por exemplo:
replicas: 3
Quer dizer conceitualmente:
“Kubernetes, mantenha três cópias funcionando.”
Se uma morrer:
Esperado: 3
Real: 2
O sistema tenta reconciliar:
Real → 3
Isso é reconciliation.
Um mainframer pode pensar:
“Então existe uma espécie de automação permanentemente verificando se o estado real corresponde ao planejado?”
Exatamente.
15. Quando Kubernetes apareceu?
O projeto Kubernetes nasceu no Google e foi aberto publicamente em 2014.
A versão Kubernetes 1.0 foi lançada em 21 de julho de 2015, quando o projeto também passou para a recém-formada Cloud Native Computing Foundation.
O DNA veio de experiências anteriores do Google administrando enormes quantidades de workloads containerizados.
E aqui temos uma curiosidade histórica maravilhosa:
“kubernetes” vem do grego e significa aproximadamente:
COBOL experiente sempre soube que hardcode de ambiente é receita para desastre.
O cloud-native apenas redescobriu a pólvora usando YAML.
21. O que é OpenShift?
Agora chegamos ao ponto crucial.
OpenShift não é simplesmente outro Kubernetes concorrente.
O Red Hat OpenShift Container Platform é uma plataforma empresarial construída sobre Kubernetes e Red Hat Enterprise Linux, adicionando componentes, processos de instalação, lifecycle management, segurança, ferramentas para desenvolvedores e recursos operacionais.
Kubernetes ≈ kernel + mecanismos de orquestração
OpenShift ≈ plataforma operacional Kubernetes empresarial
Também é simplificada, mas útil.
24. IBM Z entra onde?
OpenShift pode executar sobre Linux na arquitetura IBM Z.
A IBM e a Red Hat mantêm documentação específica para OpenShift Container Platform sobre IBM Z e IBM LinuxONE, incluindo arquiteturas de referência, sizing e performance.
Arquitetura conceitual:
IBM Z
|
+--- LPAR Linux
| |
| +--- OpenShift Node
|
+--- LPAR Linux
| |
| +--- OpenShift Node
|
+--- LPAR z/OS
|
+--- CICS
+--- IMS
+--- Db2
+--- COBOL
Observe a beleza disso.
Você pode ter OpenShift e z/OS extremamente próximos fisicamente.
25. E LinuxONE?
LinuxONE foi construído especificamente para Linux.
“Como coordenar enormes quantidades de trabalho em infraestrutura compartilhada?”
é muito mais antigo que Kubernetes.
Cloud-native não inventou gerenciamento de workloads.
Criou novas abstrações para um novo modelo de aplicações.
30. O primeiro laboratório mental
Pegue uma aplicação:
bellacosa-api
Imagem:
bellacosa-api:v1
Crie um deployment:
Deployment
replicas = 3
Kubernetes cria:
Pod 1 → bellacosa-api:v1
Pod 2 → bellacosa-api:v1
Pod 3 → bellacosa-api:v1
Um pod morre:
Pod 1
Pod 2
X
Kubernetes observa:
Desejado = 3
Atual = 2
Cria outro:
Pod 1
Pod 2
Pod 4
Agora você entendeu talvez 30% da filosofia Kubernetes.
E esses 30% valem mais que decorar cinquenta comandos kubectl.
31. Próximo passo: Service
Service
|
+--------+--------+
| | |
Pod Pod Pod
Usuário não precisa saber qual pod respondeu.
Isso permite escalabilidade e substituição dinâmica.
32. Próximo passo: atualização
Versão atual:
v1
v1
v1
Queremos:
v2
v2
v2
Um deployment pode realizar atualização gradual:
v1 v1 v1
v1 v1 v2
v1 v2 v2
v2 v2 v2
Esse é o famoso:
rolling update.
Mainframer imediatamente enxerga o valor:
reduzir indisponibilidade durante deploy.
33. Operators — quando Kubernetes aprende procedimentos
Operator é um conceito extremamente interessante para sysprogs.
Imagine transformar conhecimento operacional em software.
Algo como:
se condição A:
faça B
se B falhar:
execute C
para upgrade:
valide D
migre E
reinicie F
Operators codificam conhecimento operacional especializado usando os mecanismos de controle do Kubernetes.
Para quem passou anos carregando procedimentos em runbooks ou na cabeça do sysprog João que “não pode tirar férias porque só ele sabe reiniciar aquilo”, Operators são quase poesia.
Se tentar aprender tudo simultaneamente, Kubernetes parece manual de SMP/E traduzido para klingon.
CAPÍTULO 3 — Ansible for IBM Z and LinuxONE Foundations
Finalmente alguém resolveu automatizar o mainframe sem obrigar o COBOLzeiro a escrever 14 mil linhas de shell
Imagine a rotina:
segunda-feira:
crie dataset
copie membro
altere configuração
reinicie started task
verifique resultado
terça-feira:
mesma coisa.
quarta-feira:
mesma coisa em outro sistema.
quinta-feira:
alguém esqueceu o passo quatro.
sexta-feira:
War Room.
Ansible existe para transformar procedimentos repetíveis em automação declarativa.
35. O que é Ansible?
Ansible é uma tecnologia de automação de TI capaz de executar:
provisionamento;
gerenciamento de configuração;
deployment;
orquestração;
tarefas administrativas;
automação de infraestrutura.
A própria Red Hat resume Ansible como um motor open source para automação de provisionamento, configuração, deployment e outros processos de TI.
Historicamente a Red Hat descrevia Ansible como uma ferramenta lançada no começo de 2013; a Red Hat anunciou sua aquisição em outubro de 2015.
O projeto possui raízes anteriores em desenvolvimento comunitário, mas 2013 é uma referência histórica segura para o lançamento da ferramenta conforme a própria Red Hat.
36. Por que Ansible ficou popular?
Uma palavra:
simplicidade.
Ou pelo menos simplicidade relativa.
Você escreve automações normalmente em YAML.
Exemplo conceitual:
- name: Criar dataset
...
Em vez de escrever uma solução enorme baseada em agentes proprietários distribuídos.
Outro princípio famoso do Ansible:
agentless
Na arquitetura tradicional, o sistema gerenciado não precisa de um daemon Ansible permanentemente instalado esperando comandos.
Normalmente o controlador conecta-se aos alvos através de mecanismos existentes como SSH.
No universo z/OS isso é particularmente interessante porque você evita introduzir mais um agente residente simplesmente para automatizar tarefas.
Inclusive a própria plataforma Ansible Automation Platform pode ser implementada sobre IBM Z e LinuxONE com RHEL; a IBM possui orientação específica para esse cenário.
Portanto:
Ansible
|
+--- z/OS
|
+--- Linux on Z
|
+--- LinuxONE
|
+--- x86
|
+--- cloud
|
+--- network
Esse é o verdadeiro poder.
Uma linguagem operacional comum atravessando silos.
49. E OpenShift?
Aqui a coisa fica muito interessante.
Ansible pode automatizar infraestrutura.
OpenShift orquestra containers.
Você pode ter:
Ansible Automation Platform
|
+---- Linux
|
+---- IBM Z
|
+---- z/OS
|
+---- OpenShift
Mas respondem a famílias semelhantes de problemas.
Por isso o mainframer veterano possui uma vantagem inesperada.
Você não começa do zero.
Você já conhece problemas de computação empresarial que o restante da indústria redescobriu em novas camadas.
O segredo é parar de perguntar:
“Qual comando Kubernetes corresponde a este comando z/OS?”
e começar a perguntar:
“Qual problema arquitetural cada tecnologia está resolvendo?”
Aí a ficha cai.
60. Mapa mental definitivo
MODERN ENTERPRISE
|
+------------------+------------------+
| |
IBM Z IBM LinuxONE
| |
+------+-------+ Linux
| | |
z/OS Linux OpenShift
| | |
| OpenShift Kubernetes
| | |
| Kubernetes Pods
| | |
| Pods Containers
| |
| Containers
|
+--- CICS
+--- IMS
+--- Db2
+--- COBOL
+--- MQ
+--- z/OS Connect
|
+--- zCX
|
Linux
|
Containers
AUTOMATION LAYER
|
Ansible
|
+----------------+----------------+
| | |
z/OS Linux OpenShift
Esse desenho é provavelmente a coisa mais importante de todo o material.
61. As dez perguntas que você deve conseguir responder
Quando terminar o estudo inicial, responda sem consultar Google:
Um container é uma VM?
zCX significa que Linux virou parte do kernel z/OS?
USS é Linux?
Qual a diferença entre IBM Z e LinuxONE?
Onde OpenShift executa?
Qual a relação entre Kubernetes e OpenShift?
O que é um Pod?
O que significa desired state?
O que Ansible automatiza no z/OS?
Por que um programa COBOL continua relevante numa arquitetura cloud-native?
Se responder corretamente, você deixou de ser turista.
Agora já tem mapa.
62. Cheat sheet Bellacosa Mainframe
CONTAINER
Aplicação + dependências empacotadas.
IMAGE
Modelo imutável usado para criar containers.
REGISTRY
Repositório de imagens.
KUBERNETES
Orquestra workloads containerizados.
POD
Unidade básica de execução do Kubernetes.
NODE
Máquina participante do cluster.
CLUSTER
Conjunto administrado pelo Kubernetes.
DEPLOYMENT
Declara como uma aplicação deve existir.
SERVICE
Oferece acesso lógico aos pods.
OPENSHIFT
Plataforma Kubernetes empresarial da Red Hat.
IBM Z
Plataforma enterprise que pode executar z/OS e Linux.
LINUXONE
Plataforma IBM orientada a Linux.
USS
Ambiente UNIX do z/OS.
zCX
Ambiente de containers Linux integrado ao universo z/OS.
ANSIBLE
Automação declarativa de TI.
PLAYBOOK
Workflow Ansible escrito normalmente em YAML.
MODULE
Unidade funcional que executa uma tarefa.
COLLECTION
Pacote organizado de módulos/plugins/roles.
INVENTORY
Lista e agrupamento dos sistemas administrados.
IDEMPOTÊNCIA
Reexecutar procurando o mesmo estado sem provocar mudanças desnecessárias.
ibm_zos_core
Collection fundamental para automação z/OS com Ansible.
63. O conselho do velho COBOLzeiro
Não estude essas tecnologias como três disciplinas independentes.
DATA
|
TRANSACTION
|
COBOL
|
APIs / Events
|
OpenShift
|
Digital World
☕ Conclusão — Não é só container. É estratégia.
O jovem desenvolvedor olha para IBM Z e enxerga algo antigo.
O COBOLzeiro olha para Kubernetes e enxerga algo estranho.
Os dois estão olhando errado.
O IBM Z moderno pode conversar com Linux, containers, APIs, OpenShift, Kubernetes, Ansible, Git e pipelines DevOps sem deixar de fazer aquilo que aprendeu a fazer excepcionalmente bem: processar transações críticas e manter sistemas de registro funcionando.
zCX representa uma ponte.
Kubernetes representa orquestração.
OpenShift transforma essa orquestração em uma plataforma empresarial.
Ansible amarra automação entre mundos.
E LinuxONE demonstra que a arquitetura IBM Z não precisa obrigatoriamente significar z/OS.
O objetivo não é transformar o COBOLzeiro em administrador Kubernetes em uma semana.
É muito mais valioso.
É permitir que ele olhe para um diagrama moderno e diga:
“Ahhh... agora entendi onde cada coisa mora.”
E depois faça a pergunta que realmente assusta o arquiteto:
“Muito bonito. Agora me mostra por onde passa a transação.”
Nesse momento o Padawan deixou de decorar buzzwords.
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
