Bellacosa Mainframe e os containers dockers e kubernetes

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ Tintin na Terra dos Containers — O Mistério de Docker & Kubernetes

Uma investigação entre imagens, containers, Pods, Deployments e clusters — porque até Tintin descobriria que colocar uma aplicação em produção é muito mais complicado do que embarcar no Sirius.

Caso nº 03:17 — Arquivo confidencial do Bellacosa Mainframe
Destino: Produção
Suspeitos: Docker, Kubernetes e algumas dezenas de arquivos YAML
Situação: aparentemente simples. Portanto, extremamente suspeita.

Tintin estava acostumado a situações complicadas.

Já havia enfrentado falsificadores, contrabandistas, sociedades secretas, ditadores, traficantes, cientistas excêntricos e até viajado à Lua.

Mas naquela manhã encontrou algo muito mais perigoso.

Um desenvolvedor havia pronunciado a frase:

— Na minha máquina funciona.

Milou levantou as orelhas.

Capitão Haddock largou o café.

Professor Girassol continuou mexendo em alguma coisa que provavelmente explodiria antes do almoço.

Tintin abriu seu pequeno caderno.

Novo caso.

Precisávamos descobrir como levar uma aplicação desde o notebook de um programador até produção sem depender da configuração particular daquela máquina.

E nossa investigação começaria com uma criatura chamada container.

---

📰 1. O estranho caso da aplicação que funcionava ontem

Imagine que nosso jovem programador COBOL decidiu aprender Python e criou uma pequena API usando FastAPI.

No computador dele tudo funciona.

Python instalado.

Bibliotecas instaladas.

Variáveis configuradas.

Banco de dados acessível.

Portas abertas.

Versões corretas.

Ele entrega o programa para Haddock.

Haddock tenta executá-lo.

Nada funciona.

— MIL MILHÕES DE MILHARES DE BIBLIOTECAS INCOMPATÍVEIS!

Eis um problema muito antigo da computação.

O programa não existe sozinho.

Ele depende de um ambiente.

No universo mainframe conhecemos isso muito bem. Um programa COBOL pode depender de determinada versão de runtime, Db2, CICS, arquivos, configurações, parâmetros, bibliotecas e permissões.

No mundo distribuído ocorre exatamente o mesmo fenômeno.

Docker ataca justamente esse problema.

Em vez de entregar apenas:

minha-aplicacao.py

tentamos empacotar:

APLICAÇÃO
   +
RUNTIME
   +
BIBLIOTECAS
   +
DEPENDÊNCIAS
   +
CONFIGURAÇÃO NECESSÁRIA

dentro de uma unidade reproduzível.

Tintin anotaria:

Pista nº 1: não transporte apenas o programa. Transporte uma descrição reproduzível de seu ambiente.

---

📦 2. Surge a primeira testemunha: Docker

Docker popularizou uma maneira extremamente prática de construir, distribuir e executar aplicações em containers.

Mas precisamos separar duas palavras que frequentemente aparecem misturadas:

IMAGE e CONTAINER.

Uma imagem é o artefato preparado.

Um container é uma instância executando aquela imagem.

Podemos imaginar:

Dockerfile
    │
    ▼
docker build
    │
    ▼
┌─────────────────┐
│      IMAGE      │
│ app:v1          │
└─────────────────┘
       │
       │ docker run
       ▼
┌─────────────────┐
│    CONTAINER    │
│ aplicação viva  │
└─────────────────┘

Para quem vem do mainframe, existe uma analogia didática interessante.

Imagem lembra um artefato executável versionado. Container lembra uma execução desse artefato.

Não interprete isso literalmente como LOAD MODULE = IMAGE, porque arquiteturalmente são coisas diferentes.

Mas como ponte mental funciona muito bem.

O detalhe importante é:

uma única imagem pode originar muitos containers.

Temos:

IMAGE: bellacard-api:v7

        │
        ├── Container A
        ├── Container B
        ├── Container C
        └── Container D

Agora Tintin já tinha uma pista importante.

O artefato poderia ser reproduzido.

---

🧾 3. O bilhete encontrado no bolso do suspeito: Dockerfile

Toda boa investigação tem um documento comprometedor.

No nosso caso:

FROM python:3.13-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

Esse arquivo é o Dockerfile.

Ele descreve como construir nossa imagem.

Tintin examina cada linha com a lupa.

FROM determina a imagem-base.

WORKDIR estabelece o diretório de trabalho.

COPY coloca arquivos dentro da imagem.

RUN executa comandos durante sua construção.

ENV pode definir variáveis de ambiente.

CMD estabelece o comando normalmente executado quando o container começa.

E então aparece:

EXPOSE 8000

Haddock imediatamente conclui:

— Então a porta 8000 está publicada!

Não.

EXPOSE não publica automaticamente uma porta no host.

É informação sobre a porta esperada pela aplicação. A publicação efetiva pode ser feita, por exemplo:

docker run -p 8080:8000 bellacard-api

Temos então:

HOST                  CONTAINER

localhost:8080  ───►  :8000

Essa diferença pequena é exatamente o tipo de detalhe que transforma uma explicação introdutória em conhecimento operacional.

---

🌐 4. O mistério das portas

Tintin agora encontra três containers.

frontend
backend
database

Cada um possui seu próprio contexto de rede.

E aqui surge outra mudança mental importante.

Não devemos construir sistemas distribuídos supondo que cada container terá eternamente determinado endereço IP.

Containers aparecem.

Containers desaparecem.

Podem ser recriados.

É muito melhor trabalhar com nomes e mecanismos de descoberta de serviços.

Em um ambiente Docker Compose poderíamos ter:

frontend
    │
    ▼
backend:8000
    │
    ▼
postgres:5432

Isso começa a revelar algo importante.

Containerização não significa simplesmente:

“pegamos uma VM e diminuímos.”

O modelo operacional é diferente.

Containers tendem a ser descartáveis.

A aplicação precisa ser projetada levando isso em consideração.

---

💾 5. Milou encontra o banco de dados

Milou começa a latir para um container.

Tintin abre o container.

Encontra PostgreSQL.

Haddock reinicia a máquina.

O banco desaparece.

— BOMBARDEIOS E BACKUPS INEXISTENTES!

Tintin identifica imediatamente o problema.

Persistência.

O filesystem interno de um container não deve ser tratado ingenuamente como o lugar permanente dos dados importantes.

Precisamos separar:

COMPUTE                  DATA

container              volume/storage
 descartável            persistente

Docker oferece mecanismos como volumes e bind mounts.

Essa separação torna-se ainda mais importante quando chegarmos ao Kubernetes.

Uma aplicação pode morrer.

O Pod pode desaparecer.

O container pode ser substituído.

Mas determinados dados precisam continuar existindo.

Para quem vem de mainframe isso não deveria parecer revolucionário.

Há décadas aprendemos a separar processamento de dados persistentes.

A novidade está nas abstrações utilizadas.

---

🗝️ 6. O envelope secreto

Girassol encontra isto:

DB_PASSWORD=Tintin123
API_KEY=abc123

E sugere colocar tudo no GitHub.

Tintin quase derruba o café.

Variáveis de ambiente são excelentes para retirar determinadas configurações do código.

Podemos ter:

APP_ENV=production
DB_HOST=database
DB_PORT=5432

Arquivos .env também são muito convenientes durante desenvolvimento.

Mas existe uma armadilha:

tirar uma senha do código não significa que ela automaticamente ficou segura.

Um .env contendo credenciais continua sendo um arquivo contendo credenciais.

Precisa ser protegido.

Não deve simplesmente parar no repositório.

E esse problema reaparecerá no Kubernetes com os Secrets.

---

🧩 7. O caso ficou grande demais: Docker Compose

Tintin agora possui cinco containers:

frontend
API
agent
database
redis

Executá-los manualmente começa a parecer uma operação militar.

Então entra Docker Compose.

Podemos declarar um conjunto de serviços em um arquivo compose.yaml.

Algo conceitualmente semelhante a:

services:

  api:
    build: .
    ports:
      - "8000:8000"

  database:
    image: postgres

  redis:
    image: redis

Agora descrevemos uma pequena aplicação multi-container declarativamente.

Essa é uma das grandes virtudes do Compose.

Em vez de Haddock precisar decorar quinze comandos, declaramos como o ambiente deve ser.

Um detalhe merece atualização nos materiais mais antigos: no Compose moderno, aquele tradicional:

version: "3.8"

não é mais necessário. A documentação do Docker classifica a propriedade superior version como obsoleta e meramente informativa; o Compose moderno trabalha com a Compose Specification. (Docker Documentation)

É um belo exemplo de por que bons cursos técnicos precisam ser revisados continuamente.

---

🚢 8. Finalmente embarcamos a imagem

Construímos nossa aplicação:

docker build -t bellacard:v1 .

Temos uma imagem local.

Mas queremos executá-la em outro lugar.

Entram os container registries.

O fluxo conceitual torna-se:

SOURCE CODE
     │
     ▼
DOCKERFILE
     │
     ▼
BUILD
     │
     ▼
IMAGE
     │
     ▼
REGISTRY
     │
     ▼
PULL
     │
     ▼
EXECUTION

É aqui que começa uma ideia extremamente poderosa:

o artefato produzido pelo pipeline deve ser exatamente aquilo que promovemos entre ambientes.

Não queremos recompilar misteriosamente produção de maneira diferente de homologação.

Queremos artefatos versionados, rastreáveis e reproduzíveis.

O velho programador mainframe sentado no fundo da sala provavelmente começa a sorrir.

Ele já ouviu essa música antes.

---

🌊 9. De repente aparecem 500 containers

E aqui nossa aventura muda completamente.

Docker resolveu muito bem vários problemas relacionados a construção e execução de containers.

Mas suponha que nossa aplicação tenha:

300 containers
40 servidores
12 serviços
6 versões
3 ambientes
milhares de requisições

Quem decide onde cada workload executará?

Quem percebe que um deles morreu?

Quem cria outro?

Quem mantém determinada quantidade de réplicas?

Quem distribui tráfego?

Quem atualiza gradualmente uma versão?

Quem associa armazenamento?

Quem controla configuração?

Quem escala a aplicação?

Tintin escreve uma única palavra no caderno:

KUBERNETES

---

☸️ 10. Entramos no território Kubernetes

Kubernetes não é simplesmente um “Docker maior”.

Essa distinção é fundamental.

Ele é uma plataforma de orquestração de workloads containerizados.

Seu grande truque filosófico está no conceito de estado desejado.

Nós declaramos algo como:

QUERO 3 RÉPLICAS DESTA APLICAÇÃO.

O sistema observa:

DESEJADO = 3
ATUAL = 3

Tudo certo.

Um Pod desaparece:

DESEJADO = 3
ATUAL = 2

Existe divergência.

Os controladores trabalham para retornar ao estado desejado:

DESEJADO = 3
ATUAL = 3

Isso é extraordinariamente importante.

O operador deixa de pensar apenas:

“execute este comando.”

e passa também a pensar:

“este é o estado que quero manter.”

Quem conhece automação operacional, WLM e políticas em ambientes corporativos provavelmente já começou a enxergar pontes conceituais.

---

🏰 11. Tintin entra no cluster

Um cluster Kubernetes possui componentes de controle e nós onde workloads são executados.

De forma simplificada:

              KUBERNETES CLUSTER

        ┌─────────────────────────┐
        │      CONTROL PLANE      │
        │                         │
        │ API Server              │
        │ Scheduler               │
        │ Controller Manager      │
        │ etcd                    │
        └────────────┬────────────┘
                     │
          ───────────┼───────────
                     │
       ┌─────────────┴─────────────┐

   WORKER NODE                 WORKER NODE
   ┌──────────────┐           ┌──────────────┐
   │ kubelet      │           │ kubelet      │
   │ runtime      │           │ runtime      │
   │              │           │              │
   │ Pod Pod Pod  │           │ Pod Pod Pod  │
   └──────────────┘           └──────────────┘

O API Server é uma peça central da interface de controle.

O scheduler ajuda a decidir onde Pods serão colocados.

Os controllers observam o estado e trabalham para reconciliá-lo.

O etcd mantém dados importantes do estado do cluster.

E nos workers temos, entre outros componentes, o kubelet e um runtime de containers.

---

🐳 12. Haddock encontra uma pista desatualizada

Em algum velho mapa Tintin encontra:

Kubernetes → Docker

— Caso encerrado! — grita Haddock.

Não tão depressa.

Aqui existe uma atualização histórica importantíssima.

Kubernetes removeu seu dockershim integrado a partir da versão 1.24. Kubernetes moderno trabalha através da Container Runtime Interface — CRI, com runtimes compatíveis, como containerd e CRI-O; Docker Engine ainda pode ser integrado por um adaptador como cri-dockerd. (Kubernetes)

Isso não significa que imagens construídas com Docker deixaram de funcionar no Kubernetes. A própria documentação explica que usar Docker para construir imagens não cria uma dependência de Docker como runtime do cluster. (Kubernetes)

Portanto nosso mapa mental moderno é melhor representado assim:

              KUBERNETES

                 kubelet
                    │
                    ▼
                   CRI
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     containerd             CRI-O

E Docker continua extremamente útil no workflow de desenvolvimento e construção de imagens.

Pista nº 12: Docker não morreu no Kubernetes. Mudou a relação arquitetural entre eles.

---

📦 13. O menor quarto do hotel: Pod

Chegamos agora a uma das palavras mais importantes de Kubernetes:

Pod.

Pod é a menor unidade implantável de computação que Kubernetes gerencia.

Normalmente encontramos um container principal dentro dele, embora um Pod possa conter mais de um container quando esses processos precisam compartilhar estreitamente recursos e ciclo de vida.

Podemos imaginar:

POD
┌────────────────────────────┐
│                            │
│   Application Container    │
│                            │
│   shared networking        │
│   shared volumes/context   │
│                            │
└────────────────────────────┘

Mas existe algo fundamental:

não se apaixone pelo Pod.

Pods são substituíveis.

Podem desaparecer e serem recriados.

E por isso normalmente não administramos aplicações complexas criando Pods soltos manualmente.

Entra outra testemunha.

---

🧬 14. Deployment → ReplicaSet → Pods

Para uma aplicação típica, podemos declarar um Deployment.

Por exemplo:

replicas: 3

Conceitualmente:

Deployment
     │
     ▼
ReplicaSet
     │
 ┌───┼───┐
 ▼   ▼   ▼
Pod Pod Pod

Se um desaparece:

Pod ✖

o sistema trabalha para restaurar o estado desejado.

Isso também permite realizar rolling updates.

Em vez de:

VERSÃO 1
   ↓
DESLIGA TUDO
   ↓
VERSÃO 2

podemos substituir progressivamente instâncias antigas por novas.

E, quando necessário, trabalhar com mecanismos de rollback.

Haddock começa a gostar da história.

Produção sem uma gigantesca janela de “desliga tudo e reza” realmente parece civilização.

---

📞 15. Mas como encontramos esses Pods?

Temos outro problema.

Pods são efêmeros.

Se ficarmos distribuindo seus endereços diretamente, criamos dependências frágeis.

Entra o objeto Service.

Imagine:

CLIENTE
   │
   ▼
SERVICE
   │
 ┌─┼───────────┐
 ▼ ▼           ▼
POD A        POD B        POD C

O Service fornece uma abstração estável para alcançar determinado conjunto de Pods.

Essa é uma mudança mental importantíssima:

não procure indivíduos; procure o serviço.

Para um programador mainframe acostumado com um endpoint lógico de uma aplicação transacional, a ideia começa a soar curiosamente familiar.

---

🗺️ 16. ConfigMap e o documento que não deveria conter a senha

Nossa aplicação precisa saber:

LOG_LEVEL=INFO
LANGUAGE=pt_BR
FEATURE_X=true

Esses valores podem estar em um ConfigMap.

Mas temos também:

PASSWORD
TOKEN
API_KEY
CERTIFICATE

Aí entramos no território dos Secrets.

Contudo, há uma pegadinha digna dos irmãos Dupond e Dupont:

— Está em Base64, portanto está criptografado!

— Exatamente! E eu diria ainda mais: está criptografado porque está em Base64!

Errado duas vezes.

A documentação oficial é explícita: Base64 não é criptografia. Kubernetes Secrets podem ser armazenados sem criptografia por padrão; ambientes sérios precisam considerar controles como RBAC, restrição de acesso, criptografia em repouso e soluções apropriadas de gerenciamento de segredos. (Kubernetes)

Portanto:

ConfigMap
    ↓
configuração não confidencial

Secret
    ↓
informação confidencial
    ↓
+ controle de acesso
+ proteção apropriada
+ encryption at rest quando aplicável
+ gestão segura do ciclo de vida

Esse é um ponto que merece enorme atenção em qualquer treinamento.

---

🗄️ 17. O banco não pode desaparecer novamente

Voltamos ao problema de persistência.

No Kubernetes encontramos conceitos como:

PersistentVolume — PV

e

PersistentVolumeClaim — PVC

Didaticamente:

POD
 │
 ▼
PVC
 │
 ▼
PV
 │
 ▼
STORAGE

O PVC representa a solicitação de armazenamento feita pelo workload.

O PV representa o recurso persistente disponibilizado ao cluster, dependendo do modelo e provisionamento utilizado.

Em ambientes modernos existe ainda toda uma camada envolvendo StorageClass, provisionamento dinâmico e CSI.

Mas para nossa primeira investigação basta guardar:

Pod é descartável; dado importante não pode depender da sobrevivência daquele Pod.

---

🩺 18. Professor Girassol inventa três estetoscópios

Agora precisamos saber se a aplicação está saudável.

Kubernetes trabalha com probes que respondem perguntas diferentes.

Startup probe:

Você conseguiu iniciar?

Liveness probe:

Você continua vivo?

Readiness probe:

Você está pronto para receber tráfego?

Essas perguntas parecem semelhantes.

Não são.

Imagine uma aplicação Java que demora bastante para iniciar.

Ela pode estar viva, mas ainda não pronta para atender.

Ou uma aplicação pode continuar com processo existente, mas ter entrado em um estado do qual não consegue se recuperar adequadamente.

Misturar esses conceitos pode produzir exatamente o tipo de incidente que começa às...

03:17.

Pronto.

Easter egg encontrado. ☕😎

---

🚪 19. Tintin chega ao portão: Ingress

Agora temos serviços funcionando dentro do cluster.

Mas usuários precisam chegar até eles.

Tradicionalmente, Kubernetes utiliza Ingress para definir roteamento HTTP/HTTPS externo, associado a uma implementação/controlador.

Conceitualmente:

INTERNET
   │
   ▼
INGRESS
   │
   ├── /api ─────► Service API
   │                    │
   │                  Pods
   │
   └── /web ─────► Service WEB
                        │
                      Pods

Ingress continua sendo um conceito importante porque existem enormes ambientes usando-o.

Porém nosso curso de 2026 precisa colocar uma anotação vermelha no caderno de Tintin:

⚠️ EXISTE UM NOVO CAPÍTULO

O ecossistema Kubernetes está avançando para Gateway API como abordagem moderna e mais expressiva para networking. Em agosto de 2026, o projeto anunciou Gateway API v1.6, incluindo TCPRoute e UDPRoute no canal Standard. (Kubernetes)

Há inclusive tooling oficial para ajudar migrações de Ingress para Gateway API. (Kubernetes)

Portanto um curso atualizado deveria ensinar:

Ingress
   │
   ├── importantíssimo para ambientes existentes
   │
   └── API congelada para novos recursos
             │
             ▼
         Gateway API
        caminho moderno

Esse pequeno detalhe separa uma apostila histórica de uma formação preparada para os próximos anos.

---

📈 20. De repente chegam dez mil usuários

Haddock finalmente publica seu sistema.

Um usuário acessa.

Tudo funciona.

Dez acessam.

Tudo funciona.

Mil acessam.

Haddock começa a suar.

Dez mil acessam.

— ESCALABILIDADE DOS SETE MARES!

Kubernetes oferece mecanismos de escalabilidade, entre eles o Horizontal Pod Autoscaler — HPA.

Podemos pensar:

TRÁFEGO ↑
CPU ↑
MÉTRICA ↑

       │
       ▼

HPA observa
       │
       ▼

replicas: 3
       │
       ▼
replicas: 7

Quando a demanda diminui, a quantidade pode ser reduzida segundo a configuração e comportamento do autoscaler.

CPU e memória são excelentes exemplos introdutórios, embora arquiteturas reais possam utilizar outras métricas conforme a infraestrutura de métricas disponível.

Aqui encontramos uma ponte interessante com o universo mainframe.

Um profissional de WLM imediatamente perguntaria:

Qual é a política? Qual a prioridade? Qual o recurso disponível? Qual a métrica? Qual o objetivo de serviço?

Excelente.

Essa é exatamente a mentalidade que queremos preservar.

A tecnologia muda.

As boas perguntas sobrevivem.

---

🧠 21. Tintin monta o quadro completo

Depois de centenas de pistas espalhadas pela mesa, finalmente conseguimos enxergar nossa arquitetura.

                    INTERNET
                        │
                        ▼
              ┌──────────────────┐
              │ GATEWAY/INGRESS  │
              └────────┬─────────┘
                       │
                       ▼
                  ┌─────────┐
                  │ SERVICE │
                  └────┬────┘
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
             POD      POD      POD
              ▲        ▲        ▲
              └────────┼────────┘
                       │
                  ReplicaSet
                       ▲
                       │
                  Deployment
                       │
             desired replicas = 3


       CONFIGURAÇÃO                DADOS

        ConfigMap                   PVC
        Secrets                      │
                                     ▼
                                     PV
                                     │
                                     ▼
                                  STORAGE

E por trás disso existe o cluster:

CONTROL PLANE
      │
      ├── API Server
      ├── Scheduler
      ├── Controllers
      └── etcd
             │
             ▼
        WORKER NODES
             │
             ▼
           kubelet
             │
             ▼
             CRI
             │
       container runtime
             │
             ▼
            Pods

Finalmente o mistério começa a fazer sentido.

---

🏦 22. E onde entra o mainframe nessa aventura?

Aqui está talvez a parte mais interessante para quem está entrando nesse mundo vindo de COBOL, CICS, Db2 e z/OS.

Você não precisa apagar quarenta anos de conhecimento para aprender containers.

Muito pelo contrário.

Quem passou anos pensando em disponibilidade, processamento transacional, controle de acesso, recuperação, armazenamento, capacidade, versionamento e produção já possui uma enorme bagagem conceitual.

O segredo é não procurar equivalências literais.

Não diga:

CICS = Kubernetes
JES2 = Kubernetes
WLM = HPA
RACF = RBAC

Não são.

Mas use essas tecnologias como pontes cognitivas.

Você conhece a pergunta:

Quem pode executar isto?

Ótimo. Vamos conversar sobre RBAC.

Você conhece:

Onde os dados sobrevivem?

Excelente. Vamos falar de persistent storage.

Você pergunta:

O que acontece se esta execução morrer?

Bem-vindo ao desired state e reconciliation.

Você pergunta:

Como distribuir capacidade?

Vamos estudar scheduler, requests, limits e autoscaling.

Você pergunta:

Como colocar uma nova versão sem explodir produção?

Deployment, rolling updates, probes, observabilidade e estratégias de rollout estão esperando por você.

O veterano não chega vazio a Kubernetes.

Chega carregando décadas de perguntas extremamente úteis.

---

🚂 23. A viagem completa

Agora podemos reconstruir toda nossa investigação em uma única linha narrativa.

Tintin recebe:

SOURCE CODE

Cria:

Dockerfile

Produz:

IMAGE

Publica:

REGISTRY

Kubernetes referencia essa imagem.

Um:

Deployment

define o workload desejado.

Ele administra ReplicaSets que mantêm:

Pods

Esses Pods são alcançados por:

Service

Configuração chega através de mecanismos como:

ConfigMap
Secret

Dados persistentes podem utilizar:

PVC → PV → Storage

Saúde pode ser acompanhada com:

startup
readiness
liveness

Tráfego externo pode chegar através de:

Gateway API / Ingress

E escalabilidade horizontal pode envolver:

HPA

Isso já não parece uma coleção aleatória de palavras.

Parece uma arquitetura.

---

🔎 24. O que as excelentes ilustrações escondem

Os infográficos que iniciaram nossa investigação são ótimos para aquilo que considero a primeira passagem pelo território.

Você olha.

Reconhece os nomes.

Entende as relações.

Executa alguns comandos.

Constrói uma imagem.

Executa containers.

Cria um Compose.

Publica uma imagem.

Cria Pod.

Deployment.

Service.

PVC.

Ingress.

HPA.

Excelente.

Mas existe uma segunda passagem.

É nela que começamos a perguntar:

“Como isso funciona em produção?”

Então surgem novos personagens:

Namespaces
RBAC
ServiceAccounts
NetworkPolicy
requests/limits
taints
tolerations
affinity
anti-affinity
PodDisruptionBudget
StorageClass
CSI
Helm
Kustomize
observability
metrics
logging
tracing
GitOps
CI/CD
supply-chain security
image scanning
policy enforcement
Gateway API

E existe uma terceira passagem ainda mais interessante para nós:

Kubernetes + IBM Z + LinuxONE + OpenShift + z/OS

Aí a história deixa de ser simplesmente:

“mainframe versus cloud.”

Passa a ser:

“qual workload deve executar onde?”

Esse é um problema arquitetural muito mais adulto.

---

🚀 25. Bellacosa Containers 101 → 201 → 301

Eu transformaria todo esse material em uma trilha em três atos.

101 — Tintin descobre os containers: Linux essencial, Docker, imagens, containers, Dockerfile, registry, networking, volumes, environment variables, secrets e Compose.

201 — Tintin encontra Kubernetes: cluster, control plane, worker, kubectl, Pod, Deployment, ReplicaSet, Service, ConfigMap, Secret, PV/PVC, probes, requests/limits, Ingress, Gateway API e HPA.

301 — Tintin entra em produção: RBAC, namespaces, NetworkPolicy, CSI, Helm/Kustomize, observabilidade, segurança, CI/CD, GitOps, supply chain, OpenShift, LinuxONE/IBM Z e integração de workloads containerizados com serviços corporativos e z/OS.

O aluno poderia começar com:

docker run hello-world

e terminar compreendendo algo como:

Internet
   │
Gateway
   │
OpenShift/Kubernetes
   │
Containerized API
   │
MQ / REST
   │
z/OS Connect
   │
CICS
   │
COBOL
   │
Db2

Agora estamos falando a língua do Bellacosa Mainframe.

---

🏁 Epílogo — Tintin fecha o caderno

Depois de horas investigando containers, imagens, registries, Pods, Deployments, Services, Secrets e clusters, Capitão Haddock finalmente perguntou:

— Então Kubernetes substitui o mainframe?

Tintin fechou o caderno.

Milou olhou para Haddock.

Professor Girassol fingiu não ouvir.

E um velho programador COBOL sentado no canto começou a rir.

Porque essa era a pergunta errada.

Mainframes resolvem determinados problemas extraordinariamente bem.

Containers resolvem outros.

Kubernetes resolve um problema importantíssimo de orquestração e gerenciamento de workloads containerizados em escala.

E arquiteturas modernas podem combinar esses mundos.

A verdadeira habilidade do arquiteto não é escolher uma tecnologia para vencer uma guerra imaginária.

É saber onde cada workload pertence, como conectá-lo aos demais e como operar o conjunto com segurança, disponibilidade e previsibilidade.

Tintin guardou a lupa.

Haddock terminou o café.

Milou finalmente encontrou o container desaparecido.

E o veterano COBOL abriu um terminal e digitou:

kubectl get pods

Havia três.

bellacard-7f84c      Running
bellacard-2b17d      Running
bellacard-91a2e      Running

Deployment desejava três.

Produção tinha três.

Por alguns preciosos minutos, o universo estava em equilíbrio.

Até o telefone tocar.

Eram 03:17.

— Tintin... caiu produção.

Ele pegou o sobretudo.

— Milou, estamos diante de um novo caso.

☕ Bellacosa Mainframe — porque a tecnologia muda, mas produção continua encontrando maneiras criativas de acordar alguém de madrugada.

 

Bellacosa Mainframe apresenta Deployment Patterns

☕ Um Café no Bellacosa Mainframe

🚀 Buck Rogers no Mundo Mainframe — Deployment Patterns no Século XXV

Big Bang, Rolling, Blue-Green, Canary, Feature Toggle, Shadow Deployment, CICS, COBOL, Db2, VSAM, MQ, JCL e a estranha arte de colocar uma V2 em produção sem destruir o universo conhecido.

Imagine a cena.

O programador COBOL termina sua alteração. O compilador não reclamou. O link-edit terminou corretamente. Os testes passaram. O load module está pronto.

Na tela verde surge a mensagem que todo jovem tripulante da nave z/OS esperava:

MAXCC=0000

Ele sorri.

— Funcionou!

Buck Rogers, recém-descongelado depois de séculos, olha desconfiado para a tela.

— Funcionou onde?

Silêncio.

— Em desenvolvimento.

Buck continua:

— Com quais dados?

— Dados de teste.

— Com quantos usuários?

— Um.

— E quando colocarmos isso em produção?

Novo silêncio.

Bem-vindo ao verdadeiro problema.

Desenvolver V2 é somente metade da aventura. A outra metade é descobrir como substituir V1 sem transformar uma alteração COBOL aparentemente inocente em um incidente interplanetário.

É aqui que entram os Deployment Patterns.

E embora Big Bang, Rolling, Blue-Green, Canary e Feature Toggle sejam frequentemente apresentados usando containers, Kubernetes, microsserviços e aplicações web, seus princípios são extremamente úteis quando transportados para o universo do IBM Mainframe.

Prepare o café.

Wilma Deering já está na ponte.

Twiki está emitindo alguns bidi-bidi-bidi preocupantes.

E alguém acabou de perguntar:

“Quem vai promover isso para produção?”

---

🚀 CAPÍTULO 1 — Deployment não é simplesmente copiar um load module

Vamos começar com nosso sistema fictício de cartões, o BELLACARD.

Temos aproximadamente:

POS / ATM / MOBILE
        |
        v
      API
        |
        v
       MQ
        |
        v
      CICS
        |
        v
+------------------+
| AUTHORIZATION    |
|      COBOL       |
+------------------+
        |
   +----+----+
   |         |
  Db2       VSAM
   |
   v
FRAUD / LIMIT / PRODUCT

Existe hoje:

AUTHORIZATION V1

Nossa equipe desenvolveu:

AUTHORIZATION V2

A V2 introduz uma nova regra de risco para compras internacionais.

Compilamos.

Testamos.

Homologamos.

Agora precisamos colocar V2 em produção.

É tentador pensar:

V1
 ↓
V2

Mas o sistema real pode ser:

                    COPYBOOK
                       |
                       v
JCL ───────────────> COBOL <──────────── CICS
                       |
              +--------+--------+
              |        |        |
              v        v        v
             Db2      VSAM      MQ
              |                  |
              v                  v
            BATCH               API
              |
              v
           ARQUIVO
              |
              v
         DOWNSTREAM

Portanto, mudar um programa pode significar alterar uma aresta de um enorme grafo de dependências.

Essa é a primeira lição de Buck Rogers:

Deployment no mainframe não é mover um programa. É introduzir uma mudança em um ecossistema.

---

💥 CAPÍTULO 2 — Big Bang: todos os motores para potência máxima

Big Bang é o modelo mais simples de compreender.

Temos:

PRODUÇÃO

AUTORIZA = V1

Fazemos a implantação:

         DEPLOY
            |
            v

AUTORIZA = V2

Todos passam a executar V2.

No universo batch isso pode parecer absolutamente natural.

Imagine:

//AUTHJOB JOB ...
//STEP010 EXEC PGM=AUTORIZA
//STEPLIB DD DSN=BELLACARD.PROD.LOADLIB,DISP=SHR

Antes:

BELLACARD.PROD.LOADLIB(AUTORIZA)
                           |
                           V1

Depois:

BELLACARD.PROD.LOADLIB(AUTORIZA)
                           |
                           V2

Simples.

Mas existe uma propriedade importante:

O blast radius é enorme.

Se V2 estiver errada e todo o tráfego estiver usando V2:

BUG
 |
 +---- Cliente A
 +---- Cliente B
 +---- Cliente C
 +---- Banco A
 +---- Banco B
 +---- Canal Mobile
 +---- ATM
 +---- POS

O erro se espalha imediatamente.

Isso não significa que Big Bang seja sempre errado.

Um batch fortemente acoplado pode exigir uma mudança coordenada:

JOB001 V2
   |
   v
FILE V2
   |
   v
JOB002 V2
   |
   v
DB2

Às vezes manter V1 e V2 simultaneamente seria mais perigoso.

Portanto:

Big Bang não significa incompetência. Significa concentração temporal do risco.

---

🛞 CAPÍTULO 3 — Rolling: Buck troca os motores com a nave voando

Agora imaginemos quatro regiões CICS:

                 +--> CICS A
                 |
TRANSAÇÕES ------+--> CICS B
                 |
                 +--> CICS C
                 |
                 +--> CICS D

Todas utilizam V1.

Podemos atualizar gradualmente:

FASE 0

A V1
B V1
C V1
D V1

Depois:

FASE 1

A V2
B V1
C V1
D V1

Observamos.

Então:

FASE 2

A V2
B V2
C V1
D V1

Até:

A V2
B V2
C V2
D V2

Parece maravilhoso.

Não houve aquele instante dramático em que todo o universo passou simultaneamente de V1 para V2.

Mas Buck Rogers percebe alguma coisa no radar.

Durante algum tempo temos:

V1 + V2

Isso gera a pergunta mais importante do Rolling Deployment:

V1 e V2 conseguem coexistir?

---

👽 CAPÍTULO 4 — O inimigo não era o COBOL. Era o COPYBOOK

Imagine V1 trabalhando com:

01 CARD-RECORD.
   05 CARD-NUMBER       PIC X(16).
   05 CARD-STATUS       PIC X.
   05 CARD-LIMIT        PIC S9(9)V99 COMP-3.

V2 introduz novos campos ou altera a representação utilizada por algum fluxo.

Enquanto fazemos Rolling:

CICS A → PROGRAM V2
CICS B → PROGRAM V1

Ambos podem consumir ou produzir dados para:

Db2
VSAM
MQ
ARQUIVOS
OUTROS PROGRAMAS

Se V2 produz algo que V1 não compreende:

V2
 |
 v
NOVO LAYOUT
 |
 v
V1
 |
 v
💥

O deployment gradual transformou-se em uma armadilha.

Por isso um conceito aparentemente banal como compatibilidade de copybooks pode decidir se Rolling Deployment é seguro.

E não basta procurar quem chama o programa.

É preciso procurar quem compartilha seu contrato de dados.

---

🔵🟢 CAPÍTULO 5 — Blue-Green: duas Terras, uma produção

Buck Rogers encontra agora dois ambientes.

BLUE:

CICS BLUE
AUTORIZA V1

GREEN:

CICS GREEN
AUTORIZA V2

O tráfego começa assim:

                 BLUE V1
                   ↑
                   |
               100%
                   |
TRANSAÇÕES --------+
                   
                 GREEN V2
                    0%

GREEN pode ser preparado e validado.

Quando decidimos liberar:

BLUE V1   0%

GREEN V2 100%

Problema?

Voltamos:

BLUE V1 100%

GREEN V2  0%

Parece o Santo Graal do rollback.

Mas Dr. Huer chama Buck pelo comunicador:

— Capitão, temos um pequeno problema.

— Qual?

— O Db2.

Ah.

O banco de dados.

Sempre ele.

---

🗄️ CAPÍTULO 6 — O código voltou. Os dados não.

Imagine:

BLUE V1 ───┐
           |
           +---- DB2
           |
GREEN V2 ──┘

GREEN recebeu tráfego durante quinze minutos.

Nesse intervalo processou:

82.347 autorizações

Algumas atualizaram Db2.

Outras atualizaram VSAM.

Outras produziram mensagens MQ.

Talvez outras tenham chamado sistemas externos.

Agora alguém diz:

“Deu problema. Volta para BLUE!”

Podemos devolver o tráfego para V1 em segundos.

Mas o que fazemos com as 82.347 operações produzidas por V2?

Eis uma das lições mais importantes deste artigo:

CODE ROLLBACK
      ≠
STATE ROLLBACK

Restaurar o executável antigo não significa desfazer:

UPDATE DB2
WRITE VSAM
MQ PUT
arquivo produzido
API chamada
pagamento efetuado
evento publicado

Em sistemas financeiros isso se torna ainda mais importante porque alguns efeitos precisam ser compensados, não simplesmente apagados.

Rollback é um problema de arquitetura de estado.

---

🐤 CAPÍTULO 7 — Canary: mande Twiki primeiro

Imagine que Buck tenha uma ideia.

— Em vez de mandar toda a frota para aquele planeta, vamos mandar Twiki.

Twiki responde:

Bidi-bidi-bidi.

É basicamente Canary Deployment.

Começamos:

99% → AUTORIZA V1
 1% → AUTORIZA V2

Observamos.

Se tudo estiver correto:

90% → V1
10% → V2

Depois:

50% → V1
50% → V2

Finalmente:

100% → V2

Se V2 tiver um defeito catastrófico, reduzimos o número inicial de usuários afetados.

Estamos reduzindo o:

Blast Radius

Compare:

BIG BANG

BUG
 |
 v
100% usuários

com:

CANARY

BUG
 |
 v
1% usuários

Mas existe uma condição.

---

📡 CAPÍTULO 8 — Canary sem radar é apenas uma nave perdida

Se enviarmos 1% do tráfego para V2 mas não observarmos o que acontece, apenas demoraremos mais para descobrir o desastre.

Precisamos de telemetria.

No universo mainframe podemos pensar em indicadores técnicos envolvendo:

ABENDs
response time
CPU
transaction rate
SQLCODEs
timeouts
MQ queue depth
CICS performance
erros de aplicação

Mas Buck pergunta:

— E quantas compras estamos recusando?

Excelente pergunta.

Suponha:

V1 APPROVAL RATE = 91,4%
V2 APPROVAL RATE = 73,1%

Enquanto isso:

ABEND      = 0
SQL ERROR  = 0
CPU        = NORMAL
MQ         = NORMAL
CICS       = NORMAL

Do ponto de vista computacional:

Tudo verde.

Do ponto de vista do negócio:

Houston... quer dizer, New Chicago... temos um problema.

V2 está recusando milhares de clientes legítimos.

Daí nasce uma regra preciosa:

RC=0000 não significa que o negócio está correto.

Observabilidade moderna precisa juntar:

TECHNICAL OBSERVABILITY
          +
BUSINESS OBSERVABILITY

---

🚩 CAPÍTULO 9 — Feature Toggle: a arma secreta

Agora chegamos a uma diferença conceitual importantíssima.

Feature Toggle não é exatamente a mesma categoria dos outros padrões.

Big Bang, Rolling, Blue-Green e Canary respondem principalmente:

Como V2 entra no ambiente?

Feature Toggle responde:

Quando determinada funcionalidade de V2 será utilizada?

Podemos fazer deployment hoje:

AUTORIZA V2

mas manter:

NEW-RISK-SCORE = OFF

A nova lógica está instalada, porém não liberada.

Depois:

NEW-RISK-SCORE = ON

Em COBOL, conceitualmente:

IF WS-NEW-RISK-SCORE = 'Y'
    PERFORM 7000-RISK-SCORE-V2
ELSE
    PERFORM 6000-RISK-SCORE-V1
END-IF.

Temos então:

DEPLOYMENT
    ≠
RELEASE

Essa separação é extremamente poderosa.

---

🏛️ CAPÍTULO 10 — Mainframe fazia isso antes de virar moda

Existe uma deliciosa ironia histórica aqui.

Feature Flags parecem extremamente modernas quando aparecem em apresentações sobre Cloud Native.

Mas sistemas corporativos há décadas controlam comportamento através de:

PARÂMETROS
SYSIN
TABELAS DB2
DATASETS
CONFIGURAÇÕES
SWITCHES
REGRAS DE PRODUTO

Não estou dizendo que cada parâmetro antigo seja uma feature flag moderna.

Estou dizendo que o princípio:

“colocar código em produção sem necessariamente ativar determinado comportamento”

não nasceu ontem.

Mainframe frequentemente nos ensina que tecnologias novas são, algumas vezes, ideias antigas usando nomes novos e camisetas mais bonitas.

---

🧟 CAPÍTULO 11 — A Feature Flag que se recusou a morrer

Feature Toggle possui seu próprio perigo.

Começamos inocentemente:

IF FEATURE-A = 'Y'
   ...
END-IF

Depois:

IF FEATURE-A = 'Y'
   IF FEATURE-B = 'N'
      ...
   END-IF
END-IF

Cinco anos depois:

IF FEATURE-A = 'Y'
   IF FEATURE-B = 'N'
      IF FEATURE-C = 'Y'
         IF PRODUCT-TYPE = '07'
            IF OLD-MIGRATION-FLAG NOT = 'X'
               ...

Buck Rogers pede imediatamente para ser congelado novamente.

Feature Flags precisam de ciclo de vida:

CREATE
   ↓
TEST
   ↓
DEPLOY OFF
   ↓
ENABLE CANARY
   ↓
OBSERVE
   ↓
EXPAND
   ↓
100% ON
   ↓
REMOVE OLD CODE
   ↓
REMOVE FLAG

O último passo é importantíssimo.

Caso contrário criamos technical debt condicional.

---

👻 CAPÍTULO 12 — Shadow Deployment: o universo paralelo

Existe uma sexta estratégia que merece entrar na nave.

Imagine que estamos substituindo um algoritmo COBOL de risco.

Hoje:

RISKV1

Novo:

RISKV2

Não confiamos suficientemente em V2 para deixá-lo decidir transações.

Podemos conceitualmente executar ambos:

                     +---- RISKV1
TRANSAÇÃO -----------|        |
                     |        +--> DECISÃO REAL
                     |
                     +---- RISKV2
                              |
                              +--> SOMENTE OBSERVAÇÃO

V1 diz:

APPROVED

V2 também:

APPROVED

Excelente.

Outra:

V1 = APPROVED
V2 = DECLINED

Interessante.

Depois de grande volume:

V1 = V2       99,96%
V1 != V2       0,04%

Agora investigamos aquele 0,04%.

Isso pode ser extremamente poderoso para testar novas regras, modelos de risco ou modernizações sem entregar imediatamente a decisão de produção ao componente novo.

Mas existe uma regra fundamental:

Shadow não pode duplicar efeitos colaterais.

Se ambos executarem:

UPDATE ACCOUNT
MQ PUT
POST TRANSACTION

acabamos de transformar uma compra em duas.

O universo explodiu.

Obrigado, Buck.

---

🧬 CAPÍTULO 13 — Expand and Contract: preparando o Db2 para duas épocas

Imagine que V2 precise de:

RISK_SCORE

na estrutura de dados.

A abordagem ingênua seria mudar tudo simultaneamente.

Uma abordagem evolutiva pode seguir:

FASE 1

SCHEMA antigo
+
estrutura nova compatível

Depois:

FASE 2

V1 + V2 conseguem trabalhar

Depois:

FASE 3

V2 assume

Depois:

FASE 4

V1 desaparece

Finalmente:

FASE 5

estruturas antigas são removidas

É o princípio de Expand and Contract:

OLD
 |
 v
OLD + NEW
 |
 v
NEW
 |
 v
REMOVE OLD

Ele é importantíssimo quando queremos coexistência entre versões.

---

📦 CAPÍTULO 14 — Batch: a galáxia esquecida pelos diagramas DevOps

Muitos diagramas modernos assumem algo parecido com:

USER → LOAD BALANCER → SERVER

No mainframe podemos encontrar:

JOB001
   |
   v
FILE01
   |
   v
JOB002
   |
   v
DB2
   |
   v
JOB003
   |
   v
REPORT

Agora alteramos JOB001.

Ele passa a produzir:

LAYOUT V2

Mas JOB002 continua esperando:

LAYOUT V1

Resultado:

JOB001 V2
    |
    v
FILE V2
    |
    v
JOB002 V1
    |
    v
   💥

Portanto, em processamento batch, a unidade de deployment pode não ser um programa.

Pode ser uma cadeia inteira de processamento.

Essa é uma mudança mental importantíssima para o iniciante.

---

🕸️ CAPÍTULO 15 — Antes de fazer deploy, desenhe o grafo

Buck Rogers agora encontra uma ferramenta muito mais poderosa que qualquer pistola laser:

um lápis.

Antes do deployment, desenhe:

                   COPYBOOK
                       |
                       v
 JCL -------------> COBOL <------------- CICS
                       |
             +---------+---------+
             |         |         |
             v         v         v
            DB2       VSAM       MQ
             |                   |
             v                   v
           BATCH                API
             |
             v
           FILE
             |
             v
        DOWNSTREAM

Pergunte:

Quem chama?

Quem é chamado?

Quem lê os dados produzidos?

Quem escreve os mesmos dados?

Quem compartilha copybook?

Quem recebe MQ?

Quem depende do arquivo?

Quem depende da tabela?

Quem depende da semântica da informação?

Porque o risco não mora apenas nos nós.

Muitas vezes ele mora nas arestas.

---

🔐 CAPÍTULO 16 — Buck Rogers veste o capacete do Red Team

Deployment Patterns também criam superfícies de segurança.

Blue-Green possui dois ambientes.

Canary possui mecanismo de roteamento.

Feature Toggle possui mecanismo de ativação.

Shadow replica tráfego.

Rolling mantém versões coexistindo.

O Red Team começa a perguntar:

Quem pode alterar a feature flag?

Quem consegue mudar o routing?

Quem pode promover load modules?

Quem controla datasets de configuração?

GREEN tem as mesmas proteções de BLUE?

V1 continua acessível?

Quem pode alterar STEPLIB?

Quem controla as libraries?

Existem credenciais esquecidas no ambiente standby?

Shadow recebe dados sensíveis?

As mudanças são auditadas?

No z/OS isso pode trazer para a investigação controles e componentes relacionados a:

RACF
dataset profiles
CICS security
Db2 privileges
USS permissions
started tasks
libraries
pipeline credentials

Veja a transformação.

Começamos discutindo:

Como fazer deployment?

Agora estamos discutindo:

Quem possui autoridade para alterar o comportamento de produção?

Essa segunda pergunta é muito mais interessante para segurança.

---

⚔️ CAPÍTULO 17 — O rollback que existia apenas no PowerPoint

Toda reunião de mudança possui aquela pergunta:

“Tem rollback?”

E alguém responde:

“Sim.”

Buck Rogers deveria imediatamente perguntar:

“Mostre.”

Porque:

BACKUP EXISTE

não significa:

RESTORE FOI TESTADO

E:

LOAD MODULE V1 EXISTE

não significa:

SISTEMA CONSEGUE VOLTAR PARA V1

Se V2 alterou dados, publicou eventos e disparou processos downstream, voltar o programa talvez seja apenas uma parte da recuperação.

Um plano real deveria considerar:

Código
Dados
Mensagens
Arquivos
Configuração
Permissões
Jobs
Dependências
Efeitos externos

O rollback precisa ser tratado como capacidade operacional testável, não como frase tranquilizadora em um documento.

---

📊 CAPÍTULO 18 — A matriz de Buck Rogers

Podemos resumir nossas estratégias assim:

Estratégia	Ideia central	Principal vantagem	Principal risco
Big Bang	V1 → V2 de uma vez	simplicidade	grande blast radius
Rolling	troca gradual	reduz exposição	coexistência V1/V2
Blue-Green	dois ambientes	troca/retorno rápidos	estado e custo
Canary	V2 recebe pouco tráfego	limita impacto	exige observabilidade
Feature Toggle	funcionalidade controlada	deploy ≠ release	dívida técnica
Shadow	V2 observa tráfego	validação realista	efeitos colaterais
Expand/Contract	evolução compatível	suporta coexistência	maior disciplina

Nenhum deles é “o melhor”.

A pergunta correta é:

Qual risco estou tentando controlar?

---

🚀 CAPÍTULO 19 — A combinação intergaláctica

O grande segredo é que não precisamos escolher apenas um.

Podemos ter:

                       TRANSAÇÕES
                            |
                         ROUTER
                       /         \
                      /           \
               BLUE V1          GREEN V2
                                   |
                              FEATURE FLAG
                               /        \
                             OFF         ON
                                          |
                                       CANARY
                                         1%

GREEN recebe V2.

A feature permanece OFF.

Ativamos para um pequeno grupo.

Monitoramos.

Expandimos.

Se necessário, desligamos a funcionalidade.

Se o executável inteiro apresentar problema, alteramos o roteamento.

Temos várias camadas de contenção.

É quase uma defesa em profundidade aplicada ao deployment.

---

👨‍💻 CAPÍTULO 20 — O programador COBOL iniciante recebe sua primeira missão

Você recebeu a seguinte solicitação:

“Alterar AUTORIZA para implementar nova regra de compras internacionais.”

Não abra imediatamente o fonte.

Primeiro investigue.

Passo 1 — Entenda a mudança

Descubra:

Regra de negócio
Entrada
Saída
Dados alterados
Efeitos colaterais

Passo 2 — Descubra dependências

Mapeie:

CALLs
COPYBOOKs
Db2
VSAM
MQ
CICS
JCL
arquivos
downstream

Passo 3 — Pergunte sobre coexistência

V1 consegue ler V2?
V2 consegue ler V1?

Passo 4 — Escolha como limitar o risco

Talvez:

Feature Toggle
+
Canary

seja melhor que simplesmente Big Bang.

Passo 5 — Defina observabilidade

Não somente:

ABEND?

Também:

Approval Rate?
Decline Rate?
Tempo médio?
Fraude?
Volume?

Passo 6 — Defina rollback

Pergunte:

Como voltar código?
Como voltar configuração?
Como tratar dados?
Como tratar mensagens?
Como tratar efeitos externos?

Passo 7 — Teste a recuperação

Porque o pior momento para descobrir que o procedimento de rollback está errado é durante o incidente.

---

🥚 EASTER EGG — 03:17

São 03:17.

O celular toca.

— Produção.

Buck atende.

— O que aconteceu?

— Implantamos V2.

— Qual padrão?

— Big Bang.

— Canary?

— Não.

— Feature Toggle?

— Não.

— Shadow?

— Não.

— Observabilidade?

Silêncio.

— Rollback?

Outro silêncio.

Twiki surge no corredor:

Bidi-bidi-bidi... ABEND... bidi-bidi...

Buck olha diretamente para a câmera.

Continua no próximo episódio.

---

☕ EPÍLOGO — O futuro chegou, mas o COBOL já estava esperando

Há algo deliciosamente Buck Rogers nessa história.

Deployment Patterns aparecem frequentemente envoltos em uma estética futurista:

Cloud
Containers
Kubernetes
GitOps
Microservices
DevOps
Progressive Delivery

E tudo isso trouxe técnicas, automação e possibilidades importantíssimas.

Mas quando olhamos para o problema essencial encontramos perguntas extremamente familiares ao mundo mainframe:

Qual versão está executando?

Quem pode promovê-la?

Quais dados ela utiliza?

Quem depende desses dados?

Como controlar sua ativação?

Como limitar impacto?

Como observar produção?

Como retornar?

Quem audita tudo isso?

Mainframe nunca esteve fora dessa conversa.

O vocabulário apenas mudou.

Talvez ontem chamássemos determinada solução de parâmetro, hoje de Feature Flag.

Talvez tivéssemos múltiplas regiões e hoje alguém reconheça nelas possibilidades associadas a Rolling ou Canary.

Talvez uma mudança coordenada durante a janela batch seja reconhecida conceitualmente como Big Bang.

Não devemos forçar equivalências técnicas onde elas não existem. Kubernetes não é CICS, uma LPAR não é um pod e trocar uma STEPLIB não transforma automaticamente um sistema COBOL em Blue-Green.

O que podemos transportar são os princípios de engenharia.

E essa talvez seja a maior lição para quem começa agora no COBOL.

O programador iniciante acredita que sua responsabilidade termina aqui:

COMPILE
   ↓
LINK
   ↓
MAXCC=0000

O engenheiro começa a enxergar:

SOURCE
   ↓
COMPILE
   ↓
TEST
   ↓
DEPLOY
   ↓
RELEASE
   ↓
OBSERVE
   ↓
VALIDATE BUSINESS
   ↓
EXPAND
   ↓
RECOVER IF NECESSARY
   ↓
REMOVE OLD VERSION

E o profissional realmente experiente ainda acrescenta uma pergunta antes de tudo isso:

“O que acontece com o resto da galáxia quando eu mudar esta linha?”

Essa é a diferença entre programar um COBOL e entender o sistema no qual aquele COBOL vive.

Buck Rogers acordou no século XXV esperando encontrar um mundo completamente diferente.

Encontrou naves espaciais, computadores avançados, cidades futuristas e tecnologias inimagináveis.

Mas, em algum canto da Federação Terrestre, provavelmente ainda existiria um sistema crítico perguntando:

IF NEW-FEATURE = 'Y'
    PERFORM NEW-LOGIC
ELSE
    PERFORM OLD-LOGIC
END-IF.

E alguém, diante da console, perguntaria:

“Tem certeza de que podemos colocar isso em produção?”

Bidi-bidi-bidi.

Talvez algumas perguntas sejam eternas. 🚀☕