Kubernetes sem Mistérios : Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Bellacosa Mainframe apresenta kubernetes sem misterios

---

☕ Um Café no Bellacosa Mainframe

Kubernetes sem Mistérios 

Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Existe uma curiosidade interessante.

Muitos profissionais enxergam Kubernetes como uma tecnologia revolucionária.

Ela realmente é.

Mas existe outra forma de enxergá-la.

Para quem trabalhou anos em Mainframe, Kubernetes parece muito mais uma redescoberta de conceitos que IBM já aplicava há décadas.

Disponibilidade.

Balanceamento.

Isolamento.

Escalonamento.

Segurança.

Observabilidade.

Recuperação.

Controle de acesso.

Versionamento.

Rollback.

Tudo isso sempre existiu.

A diferença é que hoje esses conceitos aparecem usando containers, pods e YAML.

No IBM Z eles aparecem como:

• JES2

• WLM

• RACF

• Sysplex

• CICS

• Db2

• GDG

• VSAM

• SMF

• RMF

O objetivo continua exatamente o mesmo:

Fazer sistemas críticos permanecerem funcionando.

---

O grande problema

Criar um cluster Kubernetes é extremamente fácil.

Rodar um cluster durante cinco anos, sem interrupções relevantes, é extremamente difícil.

Quase todos os grandes incidentes em produção acontecem por pequenas decisões aparentemente inocentes.

É exatamente isso que o infográfico demonstra.

---

BLOCO 1

Cluster & Infrastructure

Erro 1

Um único Worker Node

Imagine um banco inteiro rodando em apenas um IBM Z.

Parece absurdo.

No Kubernetes isso acontece o tempo inteiro.

Node A

APP1
APP2
APP3
APP4

Se esse servidor falhar...

Tudo cai.

---

No Mainframe isso seria equivalente a:

• um único CPC

• sem Parallel Sysplex

• sem GDPS

• sem redundância

Alta disponibilidade simplesmente deixa de existir.

---

Erro 2

Não proteger o Control Plane

O Control Plane é o cérebro.

Ele contém:

• API Server

• Scheduler

• Controller Manager

• ETCD

Sem ele...

O cluster fica "cego".

Os containers podem continuar rodando por algum tempo.

Mas nada novo consegue ser criado.

É parecido com perder o JES2 Master.

---

Erro 3

Não fazer backup do ETCD

O ETCD guarda praticamente todo o estado do cluster.

É equivalente ao:

• catálogo do sistema

• SYS1

• repositórios de configuração

Sem ETCD...

Você perdeu:

• Deployments

• Services

• Secrets

• ConfigMaps

• RBAC

• Namespaces

Ou seja...

Perdeu o cluster.

---

Erro 4

Misturar Desenvolvimento e Produção

Esse é um erro clássico.

Imagine colocar:

PIX
Internet Banking
Folha de Pagamento

junto com

Sistema de Testes

No mesmo cluster.

Um teste mal executado pode consumir:

CPU

Memória

IO

Rede

e afetar produção.

---

Mainframe resolveu isso há décadas.

LPARs.

WLM.

Classes de serviço.

Ambientes isolados.

---

BLOCO 2

Resource Management

Aqui aparece um dos assuntos mais importantes.

Recursos.

No Kubernetes nada funciona "no automático".

---

Requests

Requests significam:

"O mínimo que preciso."

Exemplo

CPU: 500m

Memory: 1GB

O Scheduler utiliza isso para decidir onde colocar o Pod.

Sem requests...

Ele simplesmente chuta.

---

É semelhante ao WLM tentando distribuir workload sem conhecer prioridades.

---

Limits

Agora vem outra história.

Limits representam o máximo permitido.

CPU

2 cores

RAM

4GB

Se ultrapassar...

O processo sofre throttling.

Ou pode ser encerrado.

---

OOMKilled

Talvez o erro mais famoso.

Quando um container usa mais memória que o permitido.

O Kernel Linux faz:

OOM Killer

e encerra o processo.

No Mainframe seria parecido com:

Storage exhaustion

ou

S878

---

HPA

Horizontal Pod Autoscaler.

Ele aumenta o número de Pods.

Mas cuidado.

Escalar uma aplicação ruim apenas cria mais instâncias lentas.

É parecido com colocar mais CICS Regions para um programa que possui SQL ruim.

O gargalo continua existindo.

---

BLOCO 3

Deployment

Aqui surgem alguns erros extremamente comuns.

---

Nunca usar latest

Jamais.

image: latest

Parece prático.

Mas amanhã...

"latest"

é outra versão.

Você perdeu reprodutibilidade.

---

Sempre utilize

1.2.7

2.1.0

5.8.12

ou melhor ainda

Digest SHA256.

---

Isso lembra muito o mundo Mainframe.

Nunca executamos:

PROD.COBOL

Sabemos exatamente qual Load Module foi promovido.

---

Readiness Probe

O Pod iniciou.

Mas será que ele está pronto?

Não necessariamente.

Uma aplicação Java pode precisar:

30 segundos.

Sem Readiness.

O Kubernetes envia tráfego imediatamente.

Resultado:

Erro.

---

Liveness Probe

Verifica se o processo continua vivo.

Se travar...

O Kubernetes reinicia.

É semelhante ao Automation do SA z/OS detectando um address space congelado.

---

Startup Probe

Ideal para aplicações pesadas.

Sem ela...

O Kubernetes mata a aplicação antes dela terminar de iniciar.

---

Rolling Update

Jamais atualizar todos os Pods simultaneamente.

Sempre:

1
2
3
4

Nunca:

100%

de uma vez

É exatamente o conceito de deploy gradual utilizado por bancos.

---

BLOCO 4

Networking

Aqui muitos iniciantes sofrem.

---

Network Policies

Sem elas...

Todo Pod conversa com qualquer Pod.

Isso é perigosíssimo.

Imagine um malware chegando.

Ele consegue acessar praticamente tudo.

---

É equivalente a um RACF onde todos possuem ALTER em todos os datasets.

Impensável.

---

DNS

Muitos problemas parecem ser de aplicação.

Na verdade são DNS.

service

↓

CoreDNS

↓

IP

Uma falha aqui afeta milhares de Pods.

---

NodePort

Expor NodePort diretamente para Internet.

Nunca.

Use:

Ingress

Load Balancer

API Gateway

WAF

---

TLS

Sem TLS.

Todo tráfego pode ser interceptado.

No Mainframe isso seria equivalente a utilizar TN3270 sem criptografia.

---

BLOCO 5

Storage & Security

Aqui aparecem erros gravíssimos.

---

Rodar como Root

Nunca.

Um container comprometido ganha acesso privilegiado.

Use:

runAsNonRoot

readOnlyRootFilesystem

drop capabilities

---

Secrets em ConfigMaps

Erro extremamente comum.

ConfigMap não criptografa.

Secrets devem permanecer em:

Secret

Vault

KMS

External Secrets

---

RBAC

Sem RBAC.

Todos administram tudo.

Imagine um operador podendo:

Excluir produção.

Criar usuários.

Modificar políticas.

É por isso que RACF existe.

RBAC é o RACF do Kubernetes.

---

BLOCO 6

Observabilidade

Talvez o capítulo mais importante.

---

Sem logs...

Não existe troubleshooting.

---

Sem métricas...

Não existe capacity planning.

---

Sem tracing...

Não existe análise distribuída.

---

Sem dashboards...

Não existe visão operacional.

---

Ferramentas normalmente utilizadas

Logs

• ELK

• OpenSearch

• Loki

Métricas

• Prometheus

Dashboards

• Grafana

Tracing

• Jaeger

• Tempo

• Zipkin

Alertas

• Alertmanager

---

Isso lembra muito:

RMF

SMF

OMEGAMON

NetView

Tivoli

Z APM Connect

---

BLOCO 7

Operação

Aqui aparecem erros humanos.

E a maioria dos grandes incidentes nasce justamente deles.

---

Deploy manual

Nunca.

Sempre:

Git

Pipeline

Automação

---

GitOps

O Git torna-se a verdade absoluta.

Toda alteração passa por:

Commit

↓

Review

↓

Pipeline

↓

Deploy

↓

Rollback

---

É semelhante ao ChangeMan, ISPW ou Endevor.

Nada muda diretamente na produção.

---

Não testar recuperação

Backup sem restore não vale nada.

Todo DR precisa ser testado.

No IBM Z isso sempre foi obrigatório.

GDPS.

Recovery.

Image Copy.

Log Apply.

---

Não auditar segurança

Novas vulnerabilidades surgem diariamente.

Imagens precisam ser continuamente escaneadas.

---

Os "novos" erros 

Os últimos slides ampliam ainda mais a lista.

Entre eles destacam-se:

• Não definir ResourceQuota.

• Não usar LimitRange.

• Ignorar Namespaces.

• Expor aplicações diretamente.

• Não realizar backup periódico do ETCD.

• Não otimizar custos.

• Não separar ambientes.

• Não validar probes continuamente.

• Não monitorar consumo financeiro do cluster.

Esses erros normalmente não derrubam o ambiente no primeiro dia, mas aumentam gradualmente a complexidade operacional e o risco de incidentes.

---

O grande paralelo com IBM Z

O aspecto mais interessante desse material é perceber que praticamente todos os "50 erros do Kubernetes" já possuem um equivalente consolidado no ecossistema IBM Z:

Kubernetes	IBM Z / Mainframe
RBAC	RACF
Scheduler	WLM
Rolling Update	Promoção controlada (Endevor/ISPW/ChangeMan)
ReplicaSet	Parallel Sysplex
ETCD	Catálogos e repositórios críticos do sistema
Observabilidade	RMF, SMF, OMEGAMON
Health Checks	SA z/OS, NetView
GitOps	Gestão de configuração e promoção de software
Secrets	RACF + ICSF + cofres corporativos
Autoscaling	Balanceamento e classes de serviço do WLM

A tecnologia mudou, mas os princípios permanecem.

---

A maior lição para um Padawan COBOL

Quem está começando em Kubernetes costuma imaginar que dominar YAML, Pods e Deployments basta para operar um ambiente de produção. Na realidade, isso representa apenas uma pequena parte do trabalho.

Os profissionais mais experientes pensam primeiro em engenharia operacional. Antes de criar um único Deployment, eles definem como recuperar o cluster após uma falha, como limitar recursos para evitar que uma aplicação afete outra, como monitorar métricas, como proteger segredos, como automatizar implantações, como auditar mudanças e como garantir que qualquer alteração possa ser revertida rapidamente.

Essa é exatamente a mentalidade que sempre existiu no IBM Z. Durante décadas, bancos, seguradoras e governos construíram sistemas que precisavam permanecer disponíveis 24 horas por dia. Kubernetes não substitui esses princípios; ele os reapresenta em uma nova arquitetura baseada em containers.

No Bellacosa Mainframe, essa é talvez a maior mensagem deste material: um bom engenheiro de Kubernetes não é aquele que conhece mais comandos kubectl, mas aquele que projeta plataformas resilientes, observáveis, seguras e previsíveis. A verdadeira maturidade está menos na tecnologia utilizada e muito mais na disciplina de engenharia aplicada a ela.

Git, GitHub e DevOps para Profissionais IBM Z Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

 

Bellacosa Mainframe e o Git Github e DevOps para Mainframers

☕🚀 Um Café no Bellacosa Mainframe

Git, GitHub e DevOps para Profissionais IBM Z

Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

"Deleted your code by mistake? Without Git, it's gone forever."

Confesso que, ao observar aqueles infográficos coloridos sobre Git e DevOps, senti algo curioso.

Em poucos segundos eles conseguiram condensar uma transformação tecnológica que levou quase quarenta anos para acontecer.

Para muitos jovens desenvolvedores, Git sempre existiu.

Para nós, veteranos do Mainframe, sabemos que não foi assim.

Nós vivemos outra realidade.

Vivemos a era dos datasets PDS.

Vivemos a era dos backups manuais.

Vivemos a era do Panvalet.

Do Librarian.

Do Endevor.

Do Changeman.

Do SCLM.

Do ISPW.

Do membro COBOL001.

Do COBOL001.BKP.

Do COBOL001.OLD.

Do COBOL001.TESTE.

Do COBOL001.NOVO.

Do COBOL001.NOVO2.

Do COBOL001.NOVO3.

E, inevitavelmente, do lendário:

COBOL001.FINAL

COBOL001.FINAL2

COBOL001.FINAL_DEFINITIVO

COBOL001.FINAL_DEFINITIVO_OK

COBOL001.AGORA_VAI

Parece piada.

Mas muitos de nós trabalhamos exatamente dessa maneira.

E foi justamente para resolver esse caos que surgiu uma das ferramentas mais importantes da história da Engenharia de Software.

Git.

E não estou exagerando.

Git talvez seja tão revolucionário para o desenvolvimento moderno quanto o JES2 foi para processamento batch, quanto o CICS foi para processamento online ou quanto o DB2 foi para persistência transacional.

Git mudou a maneira como produzimos software.

Bellacosa Mainframe e a evolucao da gestao dos fontes

A primeira geração do controle de versões

Antes do Git existiam várias abordagens.

RCS.

SCCS.

CVS.

Visual SourceSafe.

Subversion.

ClearCase.

Perforce.

Cada um tentou resolver o mesmo problema.

Como permitir que múltiplas pessoas trabalhem no mesmo código sem destruir o trabalho umas das outras?

No Mainframe, resolvemos isso de forma diferente.

Panvalet.

Librarian.

Endevor.

ISPW.

Changeman.

Essas ferramentas foram brilhantes.

E continuam sendo.

Especialmente em ambientes regulados.

Bancos.

Seguradoras.

Governo.

Utilities.

Mas havia uma diferença.

Grande parte delas era centralizada.

Tudo dependia de um servidor.

Git mudou isso.

Git é distribuído.

E isso altera completamente a arquitetura do desenvolvimento.

O que realmente é Git?

A maioria dos cursos ensina:

Git é um sistema de versionamento.

Tecnicamente está correto.

Mas é uma definição pobre.

Git é muito mais.

Git é um banco de dados.

Git é uma máquina do tempo.

Git é um mecanismo de auditoria.

Git é uma ferramenta de colaboração.

Git é um sistema de rastreabilidade.

Git é um gatilho para automação.

Git é praticamente o sistema nervoso central do DevOps moderno.

Cada commit registra:

Quem alterou.

Quando alterou.

Por que alterou.

Qual requisito atendeu.

Qual incidente corrigiu.

Qual sprint participou.

Qual história de usuário foi implementada.

Qual vulnerabilidade foi mitigada.

Git não apenas salva arquivos.

Git preserva conhecimento organizacional.

O segredo escondido do Git

Poucos profissionais conhecem sua arquitetura interna.

Git não armazena arquivos.

Git armazena objetos.

Blob.

Tree.

Commit.

Tag.

Blob representa dados.

Tree representa diretórios.

Commit representa estados.

Tag representa marcos.

Cada commit possui um hash.

Durante muitos anos SHA-1.

Hoje caminhando para SHA-256.

Um commit não é uma diferença.

Ele é uma fotografia completa.

Um snapshot.

É por isso que Git consegue voltar meses no passado.

Como um SMF para código-fonte.

Aliás...

Talvez essa seja a analogia perfeita para um sysprog.

Git é quase um SMF de desenvolvimento.

Cada alteração gera um registro permanente.

O Sysprog e o Git

Talvez alguns sysprogs pensem:

"Mas Git é coisa de desenvolvedor."

Não.

Não mais.

Hoje praticamente toda infraestrutura está migrando para Infrastructure as Code.

Parmlibs.

Policies.

WLM.

NetView.

SA z/OS.

Ansible.

Terraform.

Scripts REXX.

Procedures.

JCL.

USS scripts.

Tudo pode estar em Git.

Imagine uma alteração em uma política WLM.

Antigamente:

Editar.

Salvar.

Copiar.

Torcer.

Hoje:

Criar branch.

Modificar.

Commit.

PR.

Review.

Merge.

Deploy automatizado.

Rollback imediato.

A governança melhora absurdamente.

O Sysadmin moderno também virou desenvolvedor

Existe uma transformação interessante acontecendo.

Sysadmins estão programando.

Desenvolvedores estão automatizando infraestrutura.

DBAs escrevem pipelines.

Sysprogs utilizam APIs REST.

Todos começam a convergir.

A linha entre operações e desenvolvimento desaparece.

Foi exatamente isso que criou DevOps.

DevOps não é ferramenta

Essa talvez seja a maior confusão do mercado.

DevOps não é Jenkins.

Não é GitHub.

Não é Kubernetes.

Não é Docker.

Não é Ansible.

DevOps é cultura.

É reduzir silos.

Eliminar burocracias.

Aproximar pessoas.

Automatizar processos.

Aumentar feedback.

Reduzir tempo de entrega.

No Mainframe isso é extremamente relevante.

Porque o Mainframe sempre teve uma cultura muito compartimentalizada.

Equipe COBOL.

Equipe DB2.

Equipe CICS.

Equipe Storage.

Equipe RACF.

Equipe Sysprog.

Equipe Operações.

Equipe Middleware.

Equipe Rede.

Equipe Segurança.

DevOps propõe outra visão.

Todos trabalham pelo mesmo objetivo.

Entregar valor ao negócio.

GitHub não é Git

Muitos iniciantes confundem.

Git é tecnologia.

GitHub é plataforma.

GitLab é plataforma.

Bitbucket é plataforma.

Azure DevOps é plataforma.

Git continua sendo Git.

Independentemente da hospedagem.

GitHub adicionou uma camada extremamente poderosa.

Issues.

Actions.

Codespaces.

Security.

Dependabot.

Packages.

Container Registry.

Wiki.

Pull Requests.

Tudo integrado.

Pull Request: a maior revolução social do desenvolvimento

Eu particularmente considero Pull Request uma das melhores invenções da engenharia moderna.

Porque ela resolve algo difícil.

Compartilhar conhecimento.

Imagine um desenvolvedor COBOL júnior.

Ele escreve:

MOVE WS-CPF TO WS-TEMP

Um desenvolvedor sênior comenta:

"Poderíamos validar antes."

Outro comenta:

"Talvez usar EVALUATE seja melhor."

Outro:

"Precisamos mascarar LGPD."

Resultado?

O código melhora.

O profissional melhora.

A equipe melhora.

A empresa melhora.

PR é mentoria embutida.

O medo do merge conflict

Todo desenvolvedor já sentiu frio na barriga.

git pull

CONFLICT

Automatic merge failed.

Para iniciantes parece um desastre.

Para equipes maduras é rotina.

Conflitos indicam colaboração.

Duas pessoas trabalharam na mesma área.

Git apenas pede ajuda.

Ele não consegue decidir sozinho.

Você decide.

Git apenas documenta.

Git Flow versus GitHub Flow

Durante anos utilizamos Git Flow.

Main.

Develop.

Feature.

Release.

Hotfix.

Funciona muito bem.

Especialmente em bancos.

Porém empresas modernas começaram simplificar.

GitHub Flow.

Main.

Feature.

PR.

Merge.

Deploy.

Google foi além.

Trunk Based Development.

Branches curtíssimas.

Commits pequenos.

Integração contínua.

Menos divergência.

Menos conflitos.

Mais velocidade.

Git para COBOL Developers

Aqui entramos em um ponto fascinante.

Durante muito tempo dizia-se:

COBOL não combina com Git.

Hoje isso é completamente falso.

IBM DBB.

IBM Dependency Based Build.

zAppBuild.

Z Open Editor.

Rocket Git.

Git Integration for Endevor.

ISPW Git Integration.

IDz.

Wazi Developer.

VS Code.

Tudo isso mudou o cenário.

Hoje um desenvolvedor COBOL pode trabalhar assim.

Abrir VS Code.

Editar programa COBOL.

Executar testes.

Commit.

Push.

Criar PR.

Executar pipeline.

Compilar.

Linkedit.

DB2 Bind.

Newcopy CICS.

Deploy.

Exatamente como Java.

Exatamente como Python.

Exatamente como Node.

Jenkins: o operador automático

Se Git é o cérebro.

Jenkins é o operador.

Ele observa commits.

Dispara builds.

Executa testes.

Compila COBOL.

Gera relatórios.

Aciona SonarQube.

Publica artefatos.

Executa deploy.

Notifica equipes.

No fundo, Jenkins faz o papel que muitos operadores humanos executavam.

Só que 24 horas por dia.

Sem esquecer etapas.

Sem distrações.

GitOps: talvez a próxima revolução

GitOps é simples.

Tudo é Git.

Deseja mudar um cluster Kubernetes?

Commit.

Deseja alterar firewall?

Commit.

Deseja atualizar pipeline?

Commit.

Deseja modificar política?

Commit.

Git torna-se a fonte única da verdade.

Single Source of Truth.

Isso é extremamente poderoso.

Porque elimina configurações manuais.

Elimina servidores "snowflake".

Elimina ambientes misteriosos.

Tudo fica reproduzível.

E a segurança?

Segurança também mudou.

DevSecOps nasceu justamente aqui.

SAST.

DAST.

Dependency Scan.

Secrets Detection.

SBOM.

Tudo integrado ao pipeline.

O desenvolvedor faz commit.

Ferramentas verificam.

Bibliotecas vulneráveis.

Credenciais expostas.

Falhas conhecidas.

Antes de chegar em produção.

No Mainframe isso pode incluir:

RACF reviews.

JCL analysis.

CICS security checks.

DB2 privilege validation.

SMF auditing.

O papel do Sysprog em 2026

Antigamente o Sysprog era apenas administrador.

Hoje é arquiteto.

Automatizador.

Consultor.

Especialista em APIs.

Especialista em observabilidade.

Especialista em pipelines.

Especialista em integração.

Especialista em segurança.

Sysprog moderno entende:

Git.

GitHub.

GitLab.

Ansible.

Python.

REXX.

Jenkins.

OpenShift.

Containers.

z/OSMF.

Zowe.

REST APIs.

Porque o Mainframe deixou de ser uma ilha.

Ele tornou-se parte do ecossistema corporativo.

O novo profissional IBM Z

Acredito que o profissional IBM Z de maior valor em 2026 possui uma característica interessante.

Ele pensa como um desenvolvedor.

Age como um administrador.

Automatiza como um engenheiro DevOps.

Protege como um especialista em segurança.

E governa como um arquiteto.

Ele consegue conversar com:

Desenvolvedor Java.

Equipe Cloud.

Kubernetes.

Segurança.

Storage.

Networking.

Data Science.

IA.

Sem abandonar aquilo que torna o Mainframe único.

Confiabilidade.

Escalabilidade.

Disponibilidade.

Integridade transacional.

Processamento massivo.

Pensando durante o café

Talvez a grande mensagem escondida por trás daqueles simpáticos desenhos coloridos seja esta:

Git não substitui o conhecimento Mainframe.

Git potencializa o conhecimento Mainframe.

Ele não aposenta COBOL.

Ele amplia o alcance do COBOL.

Ele não elimina o Sysprog.

Ele transforma o Sysprog em um engenheiro de plataforma.

Ele não mata operações.

Ele automatiza operações repetitivas.

A próxima geração de profissionais IBM Z provavelmente não conhecerá Panvalet.

Talvez nunca utilize Librarian.

Possivelmente jamais veja um Changeman clássico.

Mas certamente abrirá um Pull Request.

Criará uma branch.

Executará uma pipeline.

Fará deploy automatizado.

E continuará processando bilhões de transações por dia em um IBM Z.

Porque, no final das contas, o objetivo nunca foi Git.

Nunca foi GitHub.

Nunca foi Jenkins.

Nunca foi Kubernetes.

O objetivo sempre foi o mesmo desde os tempos do System/360.

Entregar software confiável.

Mais rápido.

Mais seguro.

Mais auditável.

Mais sustentável.

E, se possível, com uma boa xícara de café ao lado do teclado 3270.

Kubernetes sem Mistérios : O Guia Definitivo do Programador COBOL Padawan para Entender a Plataforma que Virou o "z/OS da Nuvem"

 

Bellacosa Mainframe e o kubernetes sem misterios

☕ Um Café no Bellacosa Mainframe

Kubernetes sem Mistérios

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.

---

A evolução da infraestrutura

Vamos visualizar essa evolução.

Era 1 — Servidor físico

Hardware

↓

Sistema Operacional

↓

Aplicação

Muito simples.

Muito limitado.

---

Era 2 — Virtualização

Servidor

↓

VMware

↓

Máquinas Virtuais

↓

Aplicações

Agora era possível executar diversos servidores no mesmo hardware.

---

Era 3 — Docker

Em vez de criar máquinas completas...

Criamos containers.

Muito mais leves.

Muito mais rápidos.

---

Era 4 — Kubernetes

Agora imagine:

50 servidores

↓

20.000 containers

↓

5.000 aplicações

↓

Tudo funcionando sozinho.

É exatamente isso que Kubernetes faz.

---

Easter Egg nº 1 ☕

Se o Docker é como um apartamento...

O Kubernetes é o síndico.

Ele decide:

• onde cada morador ficará

• quem troca de prédio

• quem recebe visitas

• quem ganha mais espaço

• quem precisa sair

O container apenas mora.

Quem administra é o Kubernetes.

---

O verdadeiro problema

Imagine uma empresa moderna.

Ela possui:

• 600 microsserviços

• 1.200 APIs

• 300 bancos

• milhares de usuários

Agora imagine que um servidor falha.

Quem:

• percebe?

• reinicia?

• move aplicações?

• redistribui carga?

• atualiza DNS?

• mantém disponibilidade?

Fazer isso manualmente seria impossível.

Foi exatamente para isso que Kubernetes nasceu.

---

Cluster — O universo inteiro

O Cluster representa todo o ambiente Kubernetes.

Pode possuir:

10 servidores

100 servidores

1.000 servidores

10.000 servidores

Tudo pertence ao mesmo ambiente.

No IBM Z...

Pense em um grande Sysplex.

---

Node — O servidor

Cada servidor chama-se Node.

Pode ser:

• físico

• virtual

• cloud

Analogia:

No mainframe seria parecido com uma LPAR.

Cada Node executa dezenas ou centenas de Pods.

---

Pod — A menor unidade

Aqui existe uma confusão comum.

Muitos acreditam que Kubernetes administra containers.

Na verdade...

Ele administra Pods.

Um Pod pode conter:

Container principal

+

Container Sidecar

+

Volumes

+

Rede

Exemplo:

Aplicação Java

+

Agente OpenTelemetry

+

Coletor de Logs

Tudo no mesmo Pod.

---

Deployment

Imagine dizer ao Kubernetes:

Quero exatamente

5 Pods.

Ele responde:

"Sem problemas."

Se um morrer...

Outro nasce imediatamente.

Sem operador.

Sem intervenção.

Sem JCL.

Sem abrir chamado.

---

ReplicaSet

ReplicaSet é o guarda-costas do Deployment.

Sua única missão é garantir que o número correto de Pods esteja sempre disponível.

Se deveria haver:

8 Pods

mas existem apenas:

7

Ele cria automaticamente o oitavo.

---

Service

Os Pods vivem pouco.

Eles nascem.

Morrem.

Mudam de IP.

Isso seria um pesadelo para aplicações.

Então surge o Service.

Ele fornece um endereço permanente.

db-service

api-service

payment-service

Não importa onde o Pod esteja.

O nome continua igual.

---

Control Plane — O cérebro

Se o Cluster fosse um corpo humano...

O Control Plane seria o cérebro.

Ele contém diversos componentes.

---

API Server

Tudo passa por ele.

Quando digitamos:

kubectl apply

Na realidade estamos enviando chamadas REST para o API Server.

Ele decide:

• aceitar

• validar

• armazenar

---

etcd

Este talvez seja o componente mais importante.

O etcd é um banco chave-valor extremamente rápido.

Ele guarda:

• Pods

• Nodes

• ConfigMaps

• Secrets

• Deployments

• Namespaces

• Services

Em outras palavras...

Guarda o estado inteiro do Cluster.

Perder o etcd equivale a perder o "catálogo mestre" do ambiente. Por isso, backup e alta disponibilidade do etcd são fundamentais.

---

Scheduler

Imagine um aeroporto.

O controlador decide em qual pista cada avião pousará.

O Scheduler faz exatamente isso.

Ele escolhe:

• qual Node possui CPU

• qual possui memória

• qual atende afinidade

• qual respeita políticas

---

Controller Manager

Existe um conceito muito elegante chamado:

Desired State

Estado desejado.

Você informa:

Desejo:

10 Pods.

O Controller verifica continuamente.

Encontrou apenas 9?

Cria outro.

Encontrou 12?

Remove dois.

Tudo automaticamente.

---

Kubelet

É o agente instalado em cada servidor.

Ele conversa com o Control Plane.

Recebe ordens.

Executa containers.

Monitora saúde.

É semelhante ao operador residente daquele Node.

---

kubectl — O TSO do Kubernetes

Quem vem do z/OS rapidamente faz essa associação.

No mainframe:

TSO

ISPF

SDSF

No Kubernetes:

kubectl

Exemplos:

kubectl get pods

kubectl logs

kubectl exec

kubectl describe

kubectl apply

kubectl delete

É praticamente o console administrativo do Cluster.

---

Operators — O DBA automático

Imagine um DBA que nunca dorme.

Nunca esquece um backup.

Nunca esquece RUNSTATS.

Nunca esquece REORG.

É exatamente isso que um Operator faz.

Ele conhece profundamente determinada aplicação.

Exemplo:

Operator do PostgreSQL.

Ele sabe:

• instalar

• criar réplicas

• atualizar

• restaurar

• monitorar

• recuperar falhas

Automaticamente.

---

Escalabilidade automática

Aqui Kubernetes impressiona.

Horizontal Pod Autoscaler

CPU chegou a:

90%

Resultado:

Cria mais Pods.

Quando a carga diminui...

Remove Pods.

Tudo sem intervenção humana.

---

Vertical Pod Autoscaler

Em vez de criar novos Pods...

Ele aumenta memória.

512 MB

↓

2 GB

---

Cluster Autoscaler

Imagine que todos os servidores ficaram lotados.

Na Cloud...

Kubernetes solicita automaticamente novos servidores.

Minutos depois...

O Cluster cresceu sozinho.

---

Stateful Applications

Nem tudo pode ser descartado.

Banco de dados possui memória.

Histórico.

Arquivos.

Volumes.

Para isso existe:

StatefulSet

Mantém identidade.

Cada Pod possui:

• nome fixo

• armazenamento fixo

• ordem previsível

Ideal para:

• PostgreSQL

• MongoDB

• Kafka

• Elasticsearch

• Redis Cluster

---

Persistent Volume

Representa o disco permanente.

Mesmo que o Pod desapareça...

Os dados continuam lá.

---

Persistent Volume Claim

É um pedido.

A aplicação diz:

"Preciso de 100 GB SSD."

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:

1. Aprenda Docker antes de Kubernetes.

2. Entenda bem Pods, Deployments e Services.

3. Estude YAML, pois ele é a linguagem declarativa da plataforma.

4. Pratique com um cluster local usando Minikube, Kind ou OpenShift Local.

5. Aprenda kubectl como você aprendeu TSO e ISPF.

6. Depois avance para Volumes, Networking e Segurança.

7. Em seguida, mergulhe em Helm, GitOps, Operators e Observabilidade.

8. 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.

 

Bellacosa Mainframe em um visao do dbb e zbuilder

☕ DBB e zBuilder: Os Jedi Invisíveis da Modernização IBM Z   

Quando a Galáxia Fala de IA, OpenShift e APIs, Mas Esquece Quem Realmente Constrói o Sabre de Luz

Por Vagner Bellacosa – Bellacosa Mainframe

Existe uma cena recorrente no universo da tecnologia corporativa contemporânea.

Um executivo sobe ao palco de um grande evento. Atrás dele aparecem imagens futuristas de nuvens híbridas, containers rodando em OpenShift, dashboards coloridos alimentados por Inteligência Artificial Generativa, modelos LLM analisando código COBOL e APIs REST conectando sistemas legados a aplicativos móveis.

A plateia aplaude.

Os fornecedores sorriem.

Os analistas produzem relatórios.

Os CIOs aprovam investimentos milionários.

E, em algum canto silencioso de um datacenter refrigerado, um desenvolvedor COBOL continua aguardando que alguém compile seu programa utilizando um processo criado quando Ronald Reagan ainda era presidente dos Estados Unidos.

Talvez seja exatamente aí que esteja um dos maiores paradoxos da modernização do Mainframe.

Todos querem modernizar aplicações.

Poucos querem modernizar a engenharia que produz essas aplicações.

E talvez seja por isso que IBM Dependency Based Build (DBB) e zBuilder continuem sendo duas das tecnologias mais importantes, poderosas e menos discutidas do ecossistema IBM Z.

A Modernização que o Mercado Enxerga

Quando falamos em transformação digital associada ao Mainframe, normalmente escutamos frases semelhantes a estas:

"Precisamos expor COBOL como APIs."

"Vamos colocar CICS atrás de um API Gateway."

"Devemos integrar IBM Z ao OpenShift."

"Precisamos utilizar IA Generativa para entender programas legados."

"Vamos migrar workloads para a nuvem híbrida."

Tudo isso possui valor.

Tudo isso representa avanços importantes.

Mas existe uma pergunta quase filosófica que raramente aparece nas apresentações corporativas.

Como essas aplicações são construídas hoje?

A resposta costuma ser desconfortável.

Em muitas organizações ainda encontramos processos semelhantes a este:

Desenvolvedor altera programa COBOL.

↓

Salva em um PDS.

↓

Executa compile manual.

↓

Submete JCL.

↓

Espera aprovação.

↓

Abre chamado.

↓

Aguarda CAB.

↓

Equipe operacional promove.

↓

Produção.

Se substituirmos COBOL por Java, Python ou Go, provavelmente qualquer desenvolvedor moderno consideraria esse fluxo algo retirado de um museu de informática.

No entanto, em centenas de empresas ao redor do mundo, essa ainda é a realidade operacional.

Enquanto equipes cloud utilizam GitHub Actions, GitLab Pipelines, ArgoCD, Tekton e GitOps, muitos ambientes z/OS permanecem dependentes de mecanismos desenvolvidos em uma época em que a palavra DevOps sequer existia.

O Mainframe Não Precisa Ser Modernizado. A Engenharia Sim.

Esta talvez seja a primeira provocação importante deste artigo.

O IBM Z já é extremamente moderno.

Executa Linux.

Possui aceleração para IA.

Executa containers.

Suporta APIs.

Possui criptografia embarcada.

Disponibiliza telemetria avançada.

Integra-se com Kubernetes.

Suporta OpenShift.

Conecta-se com praticamente qualquer ecossistema corporativo.

O problema raramente está na plataforma.

O problema está na forma como produzimos software para essa plataforma.

Em outras palavras:

Não basta transformar programas COBOL em APIs.

Precisamos transformar desenvolvedores Mainframe em engenheiros de software do século XXI.

IBM DBB: O Maven que Nasceu em z/OS

IBM Dependency Based Build surgiu justamente para resolver esse problema.

Muitas pessoas imaginam que DBB seja apenas um mecanismo de compilação.

Na prática, ele é muito mais do que isso.

DBB representa uma mudança conceitual profunda.

Historicamente, ambientes Mainframe trabalhavam com builds completos.

Alterou um copybook?

Compila tudo.

Mudou uma tabela?

Compila tudo.

Atualizou uma rotina compartilhada?

Compila tudo.

Imagine um banco contendo dois mil programas COBOL.

Um único COPY chamado CLIENTE é utilizado em mil e duzentos programas.

Uma alteração de dois bytes nesse copybook pode disparar uma compilação massiva.

Horas de processamento.

Centenas de datasets temporários.

JES2 congestionado.

Fila de builds aumentando.

DBB muda completamente essa lógica.

Ele constrói um grafo de dependências.

Algo semelhante ao que Maven, Gradle ou Bazel fazem há anos no mundo distribuído.

O DBB entende que:

CLIENTE

é utilizado por

COB001

COB017

COB105

COB221

COB998

Logo, apenas esses componentes precisam ser recompilados.

O ganho operacional pode ser gigantesco.

Horas podem transformar-se em minutos.

Dias podem transformar-se em horas.

O Encanamento que Ninguém Mostra no LinkedIn

Existe uma razão interessante para DBB receber relativamente pouca atenção.

Ferramentas de build são invisíveis.

Ninguém publica uma foto dizendo:

"Olhem meu maravilhoso sistema hidráulico."

As pessoas mostram a piscina.

Mostram a fachada.

Mostram o jardim.

DBB é o encanamento.

Sem ele, a casa não funciona.

Mas dificilmente aparece na propaganda.

Executivos não compram compiladores.

Executivos compram redução de risco.

Compram velocidade.

Compram governança.

Compram previsibilidade.

Compram auditoria.

Compram produtividade.

DBB entrega exatamente isso.

O Desafio do Groovy

Historicamente, muitas implementações DBB foram construídas utilizando Groovy.

Algo como:

buildProgram("COB001")

compile()

link()

package()

Para equipes acostumadas ao universo z/OS isso pode ser aceitável.

Mas estamos vivendo uma nova era.

A era do Platform Engineering.

E Platform Engineers respiram YAML.

Respiram GitOps.

Respiram Infrastructure as Code.

Respiram Kubernetes.

Respiram ArgoCD.

Respiram Tekton.

Respiram Ansible.

Respiram pipelines declarativos.

Nesse contexto, surge um novo protagonista.

zBuilder: O YAML Desperta na Força

Talvez zBuilder seja uma das iniciativas mais promissoras do ecossistema IBM Z atual.

Sua proposta é elegantemente simples.

Trocar imperatividade por declaratividade.

Trocar scripts complexos por descrições legíveis.

Ao invés de dezenas de linhas em Groovy, podemos imaginar algo semelhante a:

application:

 name: BANKAPP


languages:

 - COBOL
 - PL1
 - JCL



test:

 zunit



deploy:

 cics

Subitamente, o Mainframe começa a falar o mesmo idioma das equipes cloud.

E isso é muito poderoso.

Porque YAML tornou-se praticamente a língua franca da engenharia moderna.

Kubernetes utiliza YAML.

OpenShift utiliza YAML.

GitHub Actions utiliza YAML.

Ansible utiliza YAML.

ArgoCD utiliza YAML.

Crossplane utiliza YAML.

Tekton utiliza YAML.

Terraform possui sintaxe declarativa semelhante.

Platform Engineering gira em torno desse paradigma.

O Surgimento do GitOps Mainframe

Talvez este seja o próximo estágio evolutivo da engenharia IBM Z.

Durante décadas o repositório oficial era um PDS.

Hoje ele pode ser Git.

Antes:

PDS

↓

Compile

↓

Promotion

Agora:

Git

↓

Pull Request

↓

Review

↓

Pipeline

↓

Testes

↓

Security Scan

↓

Deploy

Exatamente igual ao mundo Java.

Exatamente igual ao mundo Python.

Exatamente igual ao universo Go.

Exatamente igual ao desenvolvimento cloud-native.

Isso reduz uma barreira psicológica importante.

O Mainframe deixa de parecer um ambiente exótico.

Passa a parecer apenas mais uma plataforma suportada pelo pipeline corporativo.

DevSecOps Não É Opcional

Durante muitos anos o Mainframe foi considerado seguro por definição.

E, de certa forma, ele realmente é.

RACF.

Criptografia.

Auditoria.

SMF.

Segurança robusta.

Porém, DevSecOps não trata apenas da segurança da plataforma.

Trata da segurança do ciclo de desenvolvimento.

Podemos imaginar pipelines semelhantes a:

Git

↓

DBB

↓

ZUnit

↓

SonarQube

↓

Checkmarx

↓

SBOM

↓

Artifact Repository

↓

Approval

↓

Deploy

Agora COBOL participa das mesmas políticas utilizadas pelo restante da organização.

Existe rastreabilidade.

Existe compliance.

Existe análise estática.

Existe assinatura digital.

Existe inventário de componentes.

Existe governança corporativa.

O Grande Equívoco da Modernização

Talvez o maior erro cometido por algumas organizações seja acreditar que modernização significa abandonar Mainframe.

Na prática, a maior parte dos projetos bem-sucedidos mostra exatamente o oposto.

Modernizar significa aumentar a capacidade de evolução do Mainframe.

Transformá-lo em uma plataforma capaz de competir pela atenção dos novos desenvolvedores.

Se um profissional de vinte e cinco anos consegue utilizar VS Code, GitHub, Pull Request, pipelines automatizados, Zowe, OpenShift e YAML para desenvolver COBOL, a experiência muda completamente.

Ele deixa de enxergar IBM Z como um fóssil tecnológico.

Passa a enxergá-lo como um backend extremamente robusto conectado a práticas modernas.

A Analogia dos Jedi

Talvez DBB e zBuilder possam ser comparados aos técnicos responsáveis por construir os sabres de luz dos Jedi.

Nos filmes, a atenção está sempre voltada para o duelo.

Para a batalha espacial.

Para os poderes da Força.

Pouco se fala sobre os artesãos que produziram as armas.

Mas sem eles não existiria batalha.

Não existiria Ordem Jedi.

Não existiria legado.

DBB e zBuilder desempenham papel semelhante.

Não aparecem em demonstrações de IA.

Não aparecem em apresentações sobre OpenShift.

Não aparecem em propagandas de APIs.

Mas tornam possível algo muito mais importante.

Permitem que a engenharia IBM Z participe plenamente do movimento DevSecOps corporativo.

Considerações Finais

A pergunta original permanece extremamente pertinente.

DBB e zBuilder ainda são subestimados?

Possivelmente sim.

Mas talvez isso esteja começando a mudar.

Estamos observando o surgimento de uma nova geração de profissionais que não deseja apenas integrar Mainframe à nuvem.

Deseja integrar Mainframe à cultura moderna de engenharia.

Quer Git.

Quer pipelines.

Quer automação.

Quer segurança contínua.

Quer observabilidade.

Quer experiência de desenvolvedor.

Quer Platform Engineering.

Quer GitOps.

Quer tratar COBOL exatamente como trata Java, Python ou Go.

Se esse movimento continuar crescendo, talvez daqui a dez anos olhemos para DBB e zBuilder da mesma forma que hoje observamos Git ou Kubernetes.

Ferramentas que inicialmente pareciam apenas componentes técnicos, mas que acabaram redefinindo completamente a maneira como organizações constroem software.

E talvez essa seja a verdadeira modernização do Mainframe.

Não trocar COBOL por outra linguagem.

Não mover aplicações para outro ambiente.

Mas transformar o IBM Z em algo que ele sempre teve potencial para ser:

Uma plataforma de engenharia contínua, capaz de unir a estabilidade de cinquenta anos de missão crítica com a velocidade, automação e governança exigidas pela próxima geração de sistemas corporativos.

Que a Força do Pipeline esteja com vocês.

☕YAML : Como um Padawan COBOL Pode Aprender a Conversar com DevOps, Kubernetes e IA Sem Precisar Decorar um Novo JCL

 

Bellacosa Mainframe apresenta o YAML

☕ O Holocron do YAML

Como um Padawan COBOL Pode Aprender a Conversar com DevOps, Kubernetes e IA Sem Precisar Decorar um Novo JCL

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma estranha verdade do universo corporativo.

Durante décadas, aprendemos a falar linguagens sagradas.

COBOL.

JCL.

REXX.

CLIST.

DFSORT.

IDCAMS.

Parmlibs.

PROCs.

SYSIN.

Control Cards.

E então, certo dia, aparece um desenvolvedor de tênis colorido dizendo:

— Só coloca no YAML.

E o Padawan COBOL pergunta:

— No quê?

— YAML.

— É um utilitário da IBM?

— Não.

— É um APF Authorized?

— Não.

— É um membro do PARMLIB?

— Não.

— Então por que todo mundo está usando isso?

A resposta é simples.

Porque YAML se tornou um dos idiomas universais da automação moderna.

---

O que é YAML?

YAML significa:

YAML Ain't Markup Language

Antigamente significava:

Yet Another Markup Language

Mas os criadores perceberam uma pequena ironia.

YAML não é exatamente uma linguagem de marcação como XML.

Ela é uma linguagem de serialização de dados.

Seu objetivo principal é representar estruturas de dados de forma extremamente legível para humanos.

Imagine um SYSIN bonito.

Ou um membro PARMLIB que alguém resolveu deixar elegante.

---

Origem do YAML

YAML nasceu em 2001.

Criadores:

Clark Evans

Brian Ingerson

Oren Ben-Kiki

A inspiração veio de várias tecnologias.

XML

SGML

Python

Perl

Configurações INI

A ideia era simples:

Criar algo que fosse:

Menos verboso que XML

Mais organizado que INI

Mais amigável que JSON

Mais legível que arquivos proprietários

Eles conseguiram.

---

Evolução das versões

YAML 1.0

2001

Primeira implementação.

---

YAML 1.1

2005

Grande expansão.

Mais tipos de dados.

Booleanos flexíveis.

Exemplo:

yes
no
on
off

Todos eram interpretados como booleanos.

Isso gerou muitos problemas.

---

YAML 1.2

2009

Versão usada atualmente.

Maior compatibilidade com JSON.

Booleanos ficaram:

true
false

mais previsíveis.

---

O conceito principal

YAML é apenas dados.

Nada de lógica.

Nada de loops.

Nada de IF.

Ele descreve objetos.

Como um DSECT.

Como um Copybook.

Como um catálogo.

Como um PROC parametrizado.

---

Estrutura básica

Chave valor

nome: Bellacosa
idade: 52
profissao: Sysprog

---

Lista

animes:

 - ReZero
 - Konosuba
 - Overlord

---

Objetos

usuario:

 nome: Vagner

 perfil: Champion

 stack:

   - COBOL
   - CICS
   - DB2

---

Exemplo equivalente em JSON

JSON:

{
 "nome":"Bellacosa",
 "idade":52
}

YAML

nome: Bellacosa
idade: 52

Muito mais agradável.

---

A regra mais importante

Espaços importam

Não existe:

BEGIN
END

Não existe:

PERFORM
END-PERFORM

Existe indentação.

Correto:

usuario:

  nome: Bellacosa

  idade:52

Errado

usuario:

nome: Bellacosa

O parser explode.

Padawan aprende isso em cinco minutos.

Veterano aprende isso durante uma madrugada inteira.

---

Comentários

# Ambiente produção


server:

 host: z17.ibm.com

---

Strings

nome: COBOL

ou

nome: "COBOL"

---

Multilinhas

descricao: |

  Curso Mainframe

  COBOL

  CICS

  DB2

Resultado:

Texto preservado.

---

Dobrando linhas

descricao: >

 Curso COBOL

 Curso CICS

 Curso DB2

Resultado:

Uma única linha.

---

Exemplo prático passo a passo

Laboratório 1

Criar arquivo.

config.yaml

ambiente: DEV

sistema: COBOLBANK


database:

 tipo: DB2

 versao: 13


cics:

 regiao: CICSPRD


usuarios:


 - nome: Bellacosa

   perfil: SYSADM


 - nome: Padawan

   perfil: DEV

---

Ler em Python

import yaml


with open("config.yaml") as f:

 dados=yaml.safe_load(f)



print(dados)

Resultado:

Dicionário Python.

---

Para que serve?

Praticamente tudo.

---

Kubernetes

Deployment

Pod

Service

Ingress

Secrets

---

Docker Compose

services:

 cobol:

   image: ibm-z

---

GitHub Actions

CI/CD

name: Build


jobs:

 compile:

---

Ansible

Muito usado em IBM Z.

tasks:


 - name: Submit Job


   zos_job_submit:

---

YAML no Mainframe

Aqui começa a parte divertida.

Hoje YAML está presente em:

---

Ansible for IBM Z

Coleções IBM.

Automation.

Provisionamento.

---

Zowe

Perfis.

Plugins.

CLI.

---

OpenShift

IBM Cloud Pak.

---

z/OS Connect

Configurações.

---

Tekton Pipelines

CI/CD Mainframe.

---

IBM Developer for z/OS

Integrações modernas.

---

Exemplo Ansible

- hosts: zos


 tasks:


 - name: Copiar membro


   zos_copy:


      src: TESTE


      dest: USER.COBOL(TESTE)

Padawan COBOL olha isso e pensa:

"Parece um PROC misturado com JSON."

Sim.

É exatamente isso.

---

Vantagens

Legibilidade

Muito melhor que XML.

---

Menos caracteres

XML:

500 linhas.

YAML:

100 linhas.

---

Fácil aprendizado

Padawan aprende em poucas horas.

---

Excelente para automação

DevOps.

IaC.

Pipelines.

Cloud.

Mainframe moderno.

---

Desvantagens

Espaços

Maior inimigo.

Uma tabulação errada.

Tudo quebra.

---

Erros difíceis

Parser informa:

Expected block mapping

Obrigado parser.

Não ajudou em nada.

---

Arquivos gigantes

Pipeline enorme.

5000 linhas.

Fica complicado.

---

Truques de Jedi

Âncoras

padrao: &base

 memoria: 4GB



server1:


 <<: *base

Reutilização.

Muito elegante.

---

Variáveis

host: ${HOST}

---

Referências

perfil: *base

---

Curiosidades

Muita gente pronuncia:

Yamel

Iamel

Yah-mal

Os criadores aceitam qualquer uma.

---

Easter Eggs

Booleanos famosos do YAML 1.1

on
off
yes
no

Podiam gerar bugs catastróficos.

Exemplo:

Senha:

password: no

Parser:

False

Administrador:

ABEND S0C4 emocional.

---

Outro Easter Egg.

YAML é tecnicamente um superconjunto de JSON.

Isto funciona:

{
 "nome":"Bellacosa"
}

É YAML válido.

Pouca gente sabe disso.

---

Dicas para Padawans COBOL

Pense em YAML como um PARMLIB moderno

PARMLIB → YAML

JCL PROC → YAML

Control Cards → YAML

Copybook → YAML

A curva de aprendizado fica muito menor.

---

Use validadores

Ferramentas excelentes:

• yamllint

• VSCode YAML Extension

• IntelliJ YAML Plugin

• Red Hat YAML Support

Evita noites em SDSF procurando um erro que, desta vez, não foi um IEC161I, um JCL ERROR ou um RACF 913, mas simplesmente dois espaços a menos.

---

O Conselho do Mestre Bellacosa

O Padawan COBOL que aprende YAML não está abandonando o IBM Z.

Está aprendendo uma nova língua diplomática do universo corporativo.

O profissional do futuro provavelmente continuará compilando programas COBOL, analisando SMF, ajustando CICS e executando REORG no Db2.

Mas também abrirá um repositório Git, ajustará um pipeline Tekton, criará um playbook Ansible, configurará um ambiente OpenShift e conversará com agentes de IA que utilizam arquivos YAML para descrever fluxos, ferramentas e automações.

No fim das contas, YAML talvez seja apenas isto:

O SYSIN que decidiu fazer intercâmbio com a nuvem, frequentar reuniões de DevOps e voltar para casa falando Kubernetes com sotaque de Ansible.

E, curiosamente, muitos Sysprogs veteranos descobrem que já entendiam YAML há anos. Apenas o chamavam por outros nomes:

PARMLIB, PROC, SYSIN, COPYBOOK ou simplesmente "aquele membro que ninguém ousa mexer em produção numa sexta-feira à tarde". ☕🚀