 |
| Bellacosa Mainframe devops muito alem do botao deploy |
☕ Um Café no Bellacosa Mainframe
DevOps Muito Além do Botão "Deploy"
O Que Todo Programador COBOL Padawan Precisa Saber Sobre CI/CD, Containers, Kubernetes, Infrastructure as Code, Pipelines, Monitoramento e Como os Grandes Bancos Automatizam Milhões de Transações por Dia
"Programar é apenas escrever código. Engenharia de Software é garantir que esse código chegue à produção com qualidade, segurança, repetibilidade e confiabilidade."
Durante muitos anos, o mundo Mainframe e o mundo Open pareciam universos completamente diferentes.
De um lado estavam os programadores COBOL, PL/I, Natural e Assembler trabalhando em ambientes IBM Z, produzindo aplicações que movimentam bancos, seguradoras, bolsas de valores, cartões de crédito, governos e empresas de telecomunicações.
Do outro lado estavam Linux, Docker, Kubernetes, Git, Jenkins, Cloud, Terraform e dezenas de ferramentas modernas que pareciam pertencer apenas às startups do Vale do Silício.
Mas existe uma verdade que poucos contam.
Os princípios são exatamente os mesmos.
O que muda são as ferramentas.
O objetivo continua sendo entregar software confiável, rapidamente, sem causar indisponibilidade.
E isso é exatamente o que os profissionais de Mainframe fazem há décadas.
Hoje vamos tomar mais um café e entender por que DevOps não substitui o Mainframe. Na verdade, ele complementa uma filosofia que o IBM Z já pratica há muito tempo.
O maior problema da Engenharia de Software
Imagine um banco em 1995.
Existem cinquenta programadores COBOL.
Cada um altera dezenas de programas durante a semana.
Na sexta-feira chega o momento mais temido.
Alguém diz:
"Vamos subir tudo para produção."
Começa então um ritual que muitos veteranos conhecem.
Primeiro é necessário localizar todos os fontes.
Depois recompilar.
Executar o Link-Edit.
Gerar os módulos de carga.
Executar o BIND dos pacotes DB2.
Atualizar CICS.
Atualizar PROCs.
Atualizar JCL.
Executar testes.
Cruzar os dedos.
Quando algo falhava, ninguém sabia exatamente qual alteração havia provocado o problema.
Esse cenário ficou conhecido no mundo da engenharia como Integration Hell.
Era caro.
Demorado.
Arriscado.
E completamente dependente de trabalho manual.
Foi exatamente para resolver esse problema que nasceu o DevOps moderno.
DevOps não é uma ferramenta
Um dos maiores erros dos iniciantes é acreditar que DevOps seja um software.
Alguns dizem:
"Estamos usando Jenkins."
Logo concluem:
"Então fazemos DevOps."
Não.
Jenkins não é DevOps.
Docker não é DevOps.
Git não é DevOps.
Kubernetes não é DevOps.
Terraform não é DevOps.
Ansible não é DevOps.
Todos eles são apenas ferramentas.
DevOps é uma filosofia de engenharia.
É uma maneira diferente de pensar.
A pergunta deixa de ser:
"Como faço o deploy?"
E passa a ser:
"Como faço milhares de deploys sem interromper o negócio?"
Essa mudança de mentalidade transforma completamente uma equipe.
A filosofia DevOps
Imagine uma corrida de revezamento.
Se um corredor correr muito rápido, mas demorar para entregar o bastão ao próximo, toda a equipe perde.
Em desenvolvimento de software acontece exatamente a mesma coisa.
Não adianta o desenvolvedor produzir código rapidamente se os testes levam semanas.
Não adianta testar rapidamente se a implantação depende de dezenas de procedimentos manuais.
Não adianta implantar rapidamente se ninguém monitora a aplicação depois.
DevOps conecta todas essas etapas em um fluxo contínuo.
É uma esteira de produção de software.
CI — Continuous Integration
A primeira etapa dessa esteira chama-se Integração Contínua.
No passado, cada desenvolvedor trabalhava isoladamente durante dias.
Quando finalmente entregava seu código, surgiam conflitos gigantescos.
Hoje a ideia é completamente diferente.
Cada pequena alteração é enviada ao repositório imediatamente.
A partir desse momento começa um processo totalmente automatizado.
O servidor baixa o código.
Compila.
Executa testes.
Analisa qualidade.
Verifica segurança.
Se tudo estiver correto, aceita a alteração.
Caso contrário, rejeita automaticamente.
Quanto menores forem as mudanças, menor será o risco de incompatibilidades.
Essa é a essência da Integração Contínua.
Como isso acontece no IBM Z
Muitos imaginam que isso exista apenas para Java ou Python.
Não existe essa limitação.
Em um ambiente IBM Z moderno, um commit pode disparar automaticamente:
compilação COBOL;
compilação PL/I;
compilação Assembler;
geração de módulos de carga;
execução de BIND DB2;
criação de artefatos;
testes automatizados;
análise de impacto;
geração de relatórios;
publicação para homologação.
Ferramentas como IBM Dependency Based Build (DBB), Jenkins e Git permitem automatizar todo esse fluxo.
O programador continua escrevendo COBOL.
O restante passa a acontecer automaticamente.
Continuous Delivery
Depois da integração vem a entrega.
Aqui existe uma diferença importante.
O software está totalmente pronto para produção.
Todos os testes passaram.
Os artefatos já foram gerados.
A documentação foi atualizada.
Os relatórios estão disponíveis.
Mas ainda existe uma aprovação humana.
Isso é muito comum em bancos.
Uma equipe de Change Management analisa a mudança.
Se aprovada, a implantação acontece.
Caso contrário, ela permanece aguardando.
Esse modelo recebe o nome de Continuous Delivery.
Continuous Deployment
Existe um passo além.
Nenhuma aprovação humana.
O commit entra no Git.
Os testes passam.
O deploy acontece automaticamente.
Empresas como Netflix, Spotify, Amazon e Google fazem isso milhares de vezes por dia.
É claro que nem toda empresa pode seguir esse modelo.
Bancos, seguradoras e órgãos governamentais normalmente exigem aprovações formais por questões regulatórias.
Mesmo assim, o restante do processo continua totalmente automatizado.
O Pipeline
Imagine uma linha de montagem de automóveis.
Cada estação realiza uma atividade específica.
Motor.
Pintura.
Suspensão.
Acabamento.
Inspeção.
Com software acontece exatamente a mesma coisa.
Essa linha de montagem recebe o nome de Pipeline.
Cada etapa agrega qualidade ao produto.
Um pipeline moderno normalmente executa:
obtenção do código-fonte;
compilação;
geração dos executáveis;
testes unitários;
testes de integração;
análise estática;
análise de segurança;
geração dos pacotes;
publicação;
deploy;
smoke tests;
monitoramento inicial.
Quanto menos intervenção humana existir, menor será a probabilidade de erro.
O papel do Git
Git não serve apenas para armazenar código.
Ele registra toda a história do projeto.
Quem alterou.
Quando alterou.
Por que alterou.
É possível retornar para qualquer versão anterior.
Essa característica transforma o Git em um verdadeiro diário da aplicação.
No mundo Mainframe, ele substitui antigas bibliotecas de controle de versões e integra naturalmente o desenvolvimento COBOL às práticas modernas.
Containers
Agora chegamos a um conceito que costuma gerar bastante confusão.
Um container não é uma máquina virtual.
Ele também não é um servidor.
Pense nele como uma caixa completamente fechada.
Dentro dessa caixa existem:
aplicação;
bibliotecas;
dependências;
arquivos de configuração;
variáveis de ambiente;
executáveis;
tudo o que a aplicação precisa para funcionar.
A grande vantagem é simples.
Se funciona dentro do container, funcionará em qualquer ambiente compatível.
Acabou aquela famosa frase:
"Na minha máquina funciona."
Docker
Docker foi a tecnologia que popularizou os containers.
Em vez de instalar dezenas de programas manualmente, descrevemos tudo em um arquivo chamado Dockerfile.
Esse arquivo funciona como uma receita.
Toda vez que ele é executado, produz exatamente o mesmo ambiente.
É repetível.
Auditável.
Versionável.
Esse conceito é extremamente importante na engenharia moderna.
Uma analogia para o Programador COBOL Padawan
Imagine um PROC JCL extremamente completo.
Ele já referencia todas as bibliotecas.
Possui todos os parâmetros.
Aponta para os datasets corretos.
Possui utilitários.
Define as variáveis necessárias.
Qualquer operador consegue executá-lo.
Esse PROC lembra bastante a ideia de um container.
Tudo o que é necessário já está preparado.
Kubernetes
Se containers resolvem o problema da execução, Kubernetes resolve o problema da administração.
Imagine uma empresa executando cinco mil containers.
Quem decide onde cada um será executado?
Quem reinicia um container que falhou?
Quem aumenta automaticamente a capacidade quando chegam mais usuários?
Quem reduz recursos durante a madrugada?
Quem distribui a carga entre vários servidores?
Quem realiza atualizações sem interromper o serviço?
A resposta para todas essas perguntas é Kubernetes.
Ele funciona como um maestro coordenando milhares de músicos.
Os Pods
No Kubernetes, normalmente não administramos containers diretamente.
Administramos Pods.
Um Pod pode conter um ou mais containers trabalhando em conjunto.
É a menor unidade de execução dentro do cluster.
O Control Plane
O cérebro do Kubernetes chama-se Control Plane.
Ele conhece todo o ambiente.
Sabe quais máquinas existem.
Quantos recursos possuem.
Quais aplicações estão executando.
Quais precisam ser reiniciadas.
Ele toma decisões automaticamente.
Os Worker Nodes
São os servidores que realmente executam as aplicações.
Enquanto o Control Plane decide, os Worker Nodes trabalham.
Essa separação aumenta a confiabilidade e a escalabilidade.
Healing
Imagine que um servidor apresente defeito.
No modelo tradicional alguém recebe um chamado.
Analisa logs.
Reinicia processos.
No Kubernetes tudo isso acontece automaticamente.
O sistema percebe que um container deixou de responder.
Cria outro.
Redireciona o tráfego.
O usuário muitas vezes nem percebe que ocorreu uma falha.
Auto Scaling
Durante uma promoção da Black Friday o número de acessos pode multiplicar por dez.
Kubernetes detecta esse crescimento.
Cria novas instâncias.
Distribui os usuários.
Quando a demanda diminui, remove os recursos excedentes.
Tudo automaticamente.
O equivalente no IBM Z
Embora Kubernetes seja uma tecnologia diferente, a filosofia lembra diversos recursos tradicionais do Mainframe.
O IBM Workload Manager (WLM) distribui cargas conforme prioridades.
O Parallel Sysplex compartilha processamento entre vários sistemas.
O Sysplex Distributor realiza balanceamento de carga.
A ideia continua sendo utilizar os recursos disponíveis da forma mais eficiente possível.
Infrastructure as Code
Durante décadas administradores criaram servidores manualmente.
Clicavam em dezenas de telas.
Criavam usuários.
Configuravam rede.
Firewall.
Discos.
Permissões.
Esse processo era demorado e sujeito a erros.
Hoje escrevemos infraestrutura como escrevemos software.
Esse conceito recebe o nome de Infrastructure as Code.
Terraform
Terraform tornou-se um dos maiores representantes dessa filosofia.
Em vez de clicar em interfaces gráficas, descrevemos a infraestrutura em arquivos de texto.
Esses arquivos ficam armazenados no Git.
São revisados.
Versionados.
Auditados.
Automatizados.
Se for necessário reconstruir todo o ambiente, basta executar novamente o código.
Ansible
Enquanto Terraform normalmente cria infraestrutura, Ansible costuma configurá-la.
Ele instala programas.
Atualiza configurações.
Cria usuários.
Distribui certificados.
Reinicia serviços.
Executa comandos remotamente.
No IBM Z, Ansible já é utilizado para administrar USS, CICS, MQ, Db2, RACF, z/OSMF e diversas outras tecnologias.
Configuration Management
Agora imagine mil servidores.
Todos deveriam possuir exatamente a mesma configuração.
Na prática isso quase nunca acontece quando o trabalho é manual.
Um servidor possui Java 17.
Outro possui Java 21.
Um utiliza uma biblioteca diferente.
Outro perdeu um certificado.
Esse fenômeno chama-se Configuration Drift.
Ferramentas de gerenciamento de configuração eliminam esse problema.
Elas garantem que todos os ambientes permaneçam idênticos.
Isso reduz drasticamente erros difíceis de reproduzir.
Observabilidade e Monitoramento
Muitos acreditam que o deploy encerra o trabalho.
Na verdade ele marca o início da fase mais importante.
Depois que o sistema entra em produção é necessário observar continuamente seu comportamento.
CPU.
Memória.
Latência.
Tempo de resposta.
Quantidade de erros.
Uso de disco.
Rede.
Número de usuários.
Tudo precisa ser medido.
Não se gerencia aquilo que não se mede.
Logs, Métricas e Traces
A observabilidade moderna costuma ser baseada em três pilares.
Os logs registram eventos e mensagens geradas pelas aplicações.
As métricas mostram números agregados, como uso de CPU, quantidade de requisições e tempo médio de resposta.
Os traces acompanham uma única transação atravessando diversos serviços, permitindo identificar exatamente onde ocorreu uma lentidão.
Juntos, esses três elementos fornecem uma visão muito mais completa do ambiente do que um simples monitor de CPU.
Monitoramento no IBM Z
Quem trabalha com Mainframe sabe que monitoramento não é novidade.
Ferramentas como RMF, SMF, OMEGAMON, SDSF e monitores específicos de CICS, IMS e Db2 acompanham o comportamento do sistema há décadas.
A diferença é que hoje essas informações também podem alimentar plataformas modernas de observabilidade, permitindo que aplicações distribuídas e aplicações no IBM Z sejam analisadas de forma integrada.
Segurança no Pipeline
Outra característica importante do DevOps moderno é que segurança deixou de ser uma etapa isolada.
Ela passou a fazer parte da própria esteira de desenvolvimento.
Esse movimento ficou conhecido como DevSecOps.
Durante o pipeline podem ser executadas análises de vulnerabilidades, verificação de dependências, inspeção de imagens de containers, análise estática de código e validação de políticas de conformidade.
O objetivo é detectar problemas o mais cedo possível, quando ainda são baratos de corrigir.
Cultura DevOps
Talvez este seja o conceito mais importante de todo o artigo.
Ferramentas podem ser compradas.
Servidores podem ser instalados.
Softwares podem ser atualizados.
Cultura não.
Ela precisa ser construída.
No modelo tradicional existiam silos.
O desenvolvedor escrevia o código.
A equipe de testes encontrava erros.
A equipe de operações implantava.
Quando algo dava errado começava o jogo da culpa.
DevOps rompe essa barreira.
Todos compartilham a responsabilidade pelo sucesso do produto.
Desenvolvimento, testes, segurança e operações deixam de atuar como departamentos isolados e passam a funcionar como uma única equipe.
DevOps no mundo Mainframe
Existe um mito de que Mainframe é incompatível com DevOps.
Nada poderia estar mais distante da realidade.
Hoje é perfeitamente possível integrar aplicações COBOL ao Git, automatizar compilações com Jenkins ou GitHub Actions, executar testes automatizados, versionar infraestrutura, administrar ambientes com Ansible, disponibilizar APIs por meio do z/OS Connect e monitorar tudo em tempo real.
Na prática, o IBM Z apenas incorporou ferramentas modernas a uma plataforma que sempre foi reconhecida por sua estabilidade, disponibilidade e capacidade de processamento.
O que o Programador COBOL Padawan deve aprender primeiro?
Se você está iniciando sua jornada, não tente aprender todas as ferramentas ao mesmo tempo.
Construa uma base sólida.
Comece entendendo Git e controle de versão.
Depois estude CI/CD e pipelines.
Aprenda como containers funcionam e por que eles resolveram o problema da portabilidade.
Entenda o papel do Kubernetes na orquestração.
Conheça Infrastructure as Code e Configuration Management.
Por fim, aprofunde-se em observabilidade, segurança e cultura DevOps.
As ferramentas mudam com o tempo.
Os princípios permanecem.
Conclusão
Existe uma frase muito conhecida na engenharia de software:
"Automatize tudo o que puder. Padronize tudo o que automatizar. Monitore tudo o que colocar em produção."
Ela resume perfeitamente a essência do DevOps.
Para um Programador COBOL Padawan, compreender esses conceitos não significa abandonar o Mainframe. Significa ampliar sua visão de engenharia. O COBOL continua escrevendo regras de negócio que movimentam bilhões de reais diariamente. O IBM Z continua oferecendo níveis de disponibilidade difíceis de igualar. O que muda é a forma como esse software é desenvolvido, testado, implantado, configurado e observado.
Os grandes bancos já não enxergam fronteiras entre "Mainframe" e "Open". Eles enxergam uma cadeia única de entrega de software, na qual aplicações COBOL, Java, Python, APIs REST, containers e serviços em nuvem convivem em uma arquitetura integrada. Nesse cenário, o profissional mais valorizado não é aquele que domina apenas uma linguagem, mas aquele que compreende o ciclo completo de vida do software.
Assim como um mestre Jedi conhece muito mais do que apenas o sabre de luz, um verdadeiro engenheiro de software precisa entender muito mais do que apenas escrever código. Ele precisa dominar automação, integração contínua, entrega contínua, infraestrutura como código, observabilidade, segurança e colaboração entre equipes.
No fim das contas, DevOps não é sobre Docker, Kubernetes ou Jenkins. É sobre construir sistemas que possam evoluir continuamente, com qualidade, segurança e confiança. E essa sempre foi — e continuará sendo — uma das maiores virtudes do ecossistema IBM Mainframe.
Sem comentários:
Enviar um comentário