Project Lightwell: O Que Todo Programador COBOL Padawan Precisa Aprender Sobre Modernização, DevSecOps e a Nova Engenharia de Software

 

Bellacosa Mainframe primeiros passos em project lightwell

☕ Um Café no Bellacosa Mainframe

Project Lightwell: O Que Todo Programador COBOL Padawan Precisa Aprender Sobre Modernização, DevSecOps e a Nova Engenharia de Software

Você Não Está Apenas Aprendendo a Aplicar Patches. Está Aprendendo Como as Maiores Empresas do Mundo Mantêm Milhões de Pessoas Conectadas Todos os Dias.

"Todo jovem programador acredita que o software termina quando o programa compila. Depois de alguns anos, descobre que escrever código representa apenas uma pequena parte da Engenharia de Software."

---

Imagine a seguinte situação.

Você acabou de chegar ao seu primeiro emprego.

Recebe acesso ao TSO.

Aprende alguns comandos ISPF.

Escreve seu primeiro programa COBOL.

Compila.

Executa.

Funciona.

Você sorri.

Missão cumprida.

Mas então seu mentor aparece e diz:

— "Parabéns. Agora vamos colocar isso em produção."

É exatamente neste momento que muitos desenvolvedores descobrem que existe um universo inteiro que nunca apareceu em livros de programação.

Porque escrever software é relativamente fácil.

O verdadeiro desafio é manter esse software funcionando durante vinte, trinta ou até cinquenta anos.

É exatamente sobre isso que trata o conceito apresentado pela IBM Consulting em parceria com a Red Hat através do Project Lightwell.

Embora pareça apenas mais um projeto de consultoria, ele representa uma das maiores mudanças de mentalidade da Engenharia de Software moderna.

---

O Programador Não Trabalha Sozinho

Quando começamos a estudar programação, imaginamos um desenvolvedor sentado em frente ao computador escrevendo milhares de linhas de código.

Na prática isso acontece.

Mas apenas durante uma pequena parte do ciclo de vida de um sistema.

Depois entram em cena dezenas de outras disciplinas.

Arquitetos.

Administradores Linux.

Especialistas em Redes.

DBAs.

Especialistas em Segurança.

Engenheiros DevOps.

Analistas de Observabilidade.

Especialistas em Automação.

Administradores OpenShift.

Administradores Kubernetes.

Consultores IBM.

Consultores Red Hat.

Todos trabalhando para que aquele pequeno programa COBOL continue funcionando sem que o cliente sequer perceba sua existência.

É uma verdadeira orquestra.

---

O Iceberg da Engenharia de Software

Imagine um iceberg.

A ponta visível representa apenas o código.

Talvez 10%.

Debaixo da água existe todo o restante.

Planejamento.

Testes.

Deploy.

Versionamento.

Backup.

Observabilidade.

Logs.

Monitoramento.

Segurança.

Governança.

Atualizações.

Patches.

Automação.

Documentação.

Compliance.

Auditoria.

Recuperação de desastres.

Alta disponibilidade.

Escalabilidade.

É essa parte invisível que mantém os bancos funcionando enquanto você dorme.

---

O Que é o Project Lightwell?

O Project Lightwell pode ser entendido como uma metodologia extremamente organizada para atualizar ambientes críticos sem colocar o negócio em risco.

Pense em um hospital.

Você nunca troca o motor de uma ambulância enquanto ela está transportando um paciente.

Primeiro existe planejamento.

Depois preparação.

Depois testes.

Somente então ocorre a substituição.

Com sistemas bancários acontece exatamente a mesma coisa.

---

Primeira Lição: Nunca Atualize Sem Conhecer o Ambiente

Uma das primeiras fases do Lightwell chama-se Assessment.

Assessment significa diagnóstico.

E diagnóstico é algo que todo bom engenheiro faz.

Imagine que você acabou de entrar em uma empresa.

Ela possui:

• 3.000 servidores Linux

• 800 máquinas virtuais

• 120 clusters Kubernetes

• centenas de aplicações

• milhares de bibliotecas

• milhões de linhas de código

Você realmente acredita que alguém simplesmente executa um:

yum update

ou

dnf upgrade

e vai tomar café?

Claro que não.

Primeiro é preciso descobrir absolutamente tudo que existe naquele ambiente.

---

Conhecimento é Redução de Risco

Um dos maiores ensinamentos da Engenharia é este:

Quanto maior o conhecimento...

Menor o risco.

Imagine descobrir que uma aplicação depende de Java 8.

Outra depende de Java 17.

Outra depende de Python 2.

Outra utiliza OpenSSL antigo.

Outra depende de uma biblioteca criada há quinze anos.

Sem um inventário completo, qualquer atualização pode derrubar um sistema inteiro.

---

O Inventário Vale Ouro

Muitos programadores iniciantes pensam que inventário serve apenas para patrimônio.

Na verdade, inventário é uma das ferramentas mais importantes da infraestrutura.

É preciso saber:

Qual servidor existe?

Qual sistema operacional?

Qual versão?

Quais bibliotecas?

Quais aplicações?

Quem utiliza?

Quem mantém?

Quem é responsável?

Sem essas respostas, ninguém deveria tocar em produção.

---

O Que Isso Tem a Ver com COBOL?

Tudo.

Imagine um programa COBOL executando no CICS.

Ele chama uma API REST.

Essa API roda em OpenShift.

O OpenShift utiliza Red Hat Enterprise Linux.

O Linux depende do OpenSSL.

O OpenSSL recebe um patch crítico.

Agora responda.

Quem garante que a atualização não interromperá a comunicação entre o COBOL e a API?

É exatamente para isso que existe o Assessment.

---

DevOps Não é Apenas Automatizar

Existe uma ideia equivocada de que DevOps significa apenas criar pipelines.

Não.

DevOps é uma filosofia.

É eliminar atividades repetitivas.

É reduzir erros humanos.

É acelerar entregas.

É aumentar qualidade.

É integrar equipes.

É compartilhar responsabilidades.

Um programador COBOL moderno precisa entender isso.

Mesmo que nunca escreva um pipeline.

---

Imagine Atualizar um Banco Manualmente

Suponha que um banco possua:

15.000 servidores.

Imagine um administrador executando login em cada máquina.

Copiando arquivos.

Executando comandos.

Reiniciando serviços.

Agora imagine repetir isso todos os meses.

Seria impossível.

É por isso que existem ferramentas como:

Ansible

Terraform

GitOps

OpenShift

Satellite

ArgoCD

Automation Platform.

Elas fazem automaticamente aquilo que humanos demorariam semanas para concluir.

---

O Mundo Está Caminhando para Infraestrutura como Código

Você provavelmente já ouviu falar em código-fonte.

Agora conheça outro conceito.

Infrastructure as Code.

Em vez de configurar servidores manualmente...

Você escreve código.

Esse código cria:

servidores

redes

containers

usuários

firewalls

balanceadores

clusters

Tudo automaticamente.

É como escrever um programa COBOL.

Só que o resultado é uma infraestrutura inteira.

---

Testar Não é Perda de Tempo

Todo programador iniciante acredita que testar significa desconfiar do próprio trabalho.

Na verdade, testar é proteger o próprio trabalho.

Imagine que você desenvolveu um sistema durante dois anos.

Uma atualização de biblioteca quebra tudo.

Sem testes...

Ninguém percebe.

Com testes automatizados...

O problema aparece em minutos.

É exatamente isso que a IBM enfatiza.

Testes antes.

Durante.

E depois da implantação.

---

Produção Não é Lugar para Descobertas

Existe um ditado muito conhecido entre administradores de sistemas:

"Produção não é ambiente de testes."

Parece óbvio.

Mas milhares de empresas ainda aprendem isso da pior forma.

Primeiro atualizam.

Depois verificam se funciona.

A abordagem moderna inverte completamente essa lógica.

Primeiro simula.

Depois testa.

Depois automatiza.

Depois implanta.

Depois monitora.

---

O Poder da Automação

Imagine duas empresas.

Na primeira:

João executa cinquenta comandos manualmente.

Na segunda:

Um pipeline executa os mesmos cinquenta comandos em cinco minutos.

Qual possui menos chance de erro?

Qual entrega mais rápido?

Qual escala melhor?

Qual sobrevive ao crescimento?

A resposta é evidente.

---

Observabilidade: O Sistema Está Bem?

Durante muitos anos monitoramento significava verificar:

CPU.

Memória.

Disco.

Hoje isso é apenas o começo.

Observabilidade responde perguntas muito mais profundas.

Por que esta transação ficou lenta?

Qual microsserviço aumentou o tempo de resposta?

Qual API está apresentando erro?

Qual banco de dados está congestionado?

Qual cluster perdeu desempenho?

É praticamente um raio-X do ambiente.

---

Segurança Não é Apenas Antivírus

Quando ouvimos a palavra segurança pensamos em hackers.

Mas segurança corporativa é muito maior.

Inclui:

controle de acesso

criptografia

gestão de certificados

identidades

autenticação

autorização

patches

vulnerabilidades

compliance

auditoria

resposta a incidentes

É um universo inteiro.

---

O Papel da Inteligência Artificial

Um ponto interessante do Project Lightwell é a utilização de Inteligência Artificial para analisar ambientes complexos.

Imagine uma empresa com:

50 milhões de linhas de código.

Milhares de bibliotecas.

Centenas de dependências.

Nenhum ser humano consegue analisar tudo isso sozinho.

Ferramentas baseadas em IA conseguem identificar:

bibliotecas obsoletas

dependências inseguras

versões incompatíveis

riscos de atualização

prioridades

Isso não substitui engenheiros.

Aumenta sua capacidade.

---

O Mainframe Continua no Centro da Arquitetura

Existe um mito de que modernização significa abandonar o Mainframe.

A realidade é exatamente o oposto.

Hoje encontramos arquiteturas onde:

COBOL executa no z/OS.

CICS fornece processamento transacional.

Db2 armazena dados.

OpenShift executa microsserviços.

APIs REST conectam aplicações.

Kafka distribui eventos.

Ansible automatiza ambientes.

Red Hat Enterprise Linux hospeda aplicações auxiliares.

Tudo integrado.

O Mainframe permanece como o coração do negócio.

---

O Novo Perfil do Programador COBOL

Há trinta anos bastava conhecer:

COBOL

JCL

CICS

DB2

Hoje isso continua extremamente importante.

Mas surgiram novas competências.

Git.

GitHub.

GitLab.

VS Code.

Zowe.

JSON.

REST.

APIs.

Docker.

Containers.

OpenShift.

Linux.

CI/CD.

DevOps.

Observabilidade.

Cloud.

Segurança.

Automação.

Você não precisa dominar tudo imediatamente.

Mas precisa saber que esse universo existe.

---

O Programador Padawan Nunca Para de Aprender

A palavra "Padawan", emprestada do universo da ficção científica, descreve perfeitamente a carreira em tecnologia.

Sempre haverá algo novo.

Uma nova linguagem.

Uma nova arquitetura.

Um novo framework.

Uma nova ferramenta.

Uma nova metodologia.

Os grandes profissionais não são aqueles que sabem tudo.

São aqueles que nunca deixam de aprender.

---

A Maior Lição do Project Lightwell

Se fosse necessário resumir todo esse projeto em apenas uma frase, ela seria:

Modernizar não significa trocar tecnologia. Significa reduzir riscos enquanto o negócio continua funcionando.

Essa talvez seja a maior diferença entre um programador iniciante e um engenheiro de software experiente.

O iniciante pergunta:

"Como faço esse programa funcionar?"

O engenheiro pergunta:

"Como faço esse sistema continuar funcionando pelos próximos vinte anos, mesmo após centenas de atualizações, milhares de mudanças e milhões de transações?"

Essa mudança de perspectiva transforma um desenvolvedor em um profissional capaz de atuar em ambientes de missão crítica.

---

Conselho do Bellacosa

Se você é um Programador COBOL Padawan, talvez olhe para termos como DevSecOps, OpenShift, Ansible, GitOps, Observabilidade ou Platform Engineering e pense que tudo isso está distante da sua realidade.

Não está.

Cada um desses conceitos representa uma evolução natural da Engenharia de Software. Eles não substituem o COBOL; eles ampliam o contexto em que ele opera. Um programa COBOL que processa milhões de transações por dia depende de infraestrutura, automação, segurança e monitoramento para continuar entregando valor ao negócio.

Aprenda um conceito de cada vez. Continue dominando COBOL, JCL, CICS, Db2 e z/OS, mas reserve um tempo para explorar Linux, Git, APIs REST, containers, OpenShift e automação com Ansible. Não tenha receio de estudar assuntos que parecem complexos. Todo especialista já foi um iniciante.

Lembre-se: o mercado não procura apenas programadores que escrevem código. Procura profissionais que compreendem como sistemas completos são projetados, implantados, protegidos e mantidos em operação.

O Project Lightwell é um excelente exemplo dessa visão integrada. Ele mostra que o sucesso de uma aplicação não depende apenas da qualidade do código, mas da disciplina em torno de planejamento, testes, automação, segurança e acompanhamento contínuo.

Portanto, continue curioso. Leia documentação técnica. Monte laboratórios. Experimente novas ferramentas. Pergunte "por quê?" antes de perguntar "como?". Cada novo conhecimento será mais uma peça na construção da sua jornada.

Porque, no fim das contas, você não está aprendendo apenas COBOL. Está aprendendo Engenharia de Software em sua forma mais completa — a mesma que mantém bancos, seguradoras, companhias aéreas e governos funcionando 24 horas por dia, todos os dias do ano.

E essa é uma habilidade que continuará sendo valiosa por muitas décadas.

Como um Padawan COBOL Pode Descobrir que Existe uma Forma de Administrar Milhares de Servidores sem Escrever um JCL para Cada Um Deles

Bellacosa Mainframe apresenta o Ansible

☕ O Holocron do Ansible

Como um Padawan COBOL Pode Descobrir que Existe uma Forma de Administrar Milhares de Servidores sem Escrever um JCL para Cada Um Deles

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

Os servidores estão se multiplicando.

Primeiro era apenas um LPAR.

Depois vieram dois ambientes.

DEV.

QA.

HML.

PRD.

DR.

Cloud.

Linux.

Windows.

Containers.

OpenShift.

Z/Linux.

zCX.

z/OS Connect.

MQ.

CICS.

DB2.

E de repente alguém faz uma pergunta aparentemente simples.

— Bellacosa... como atualizamos 800 servidores?

O Padawan pensa.

"Talvez um REXX."

"Talvez um script."

"Talvez um FTP."

"Talvez um JCL."

O Sysprog veterano apenas sorri.

Abre uma caneca de café.

E responde:

— Existe uma ferramenta chamada Ansible.

E ela parece magia.

Mas não é magia.

É apenas automação feita direito.

---

O que é o Ansible?

Ansible é uma plataforma de automação Open Source criada para executar tarefas administrativas em múltiplos sistemas de maneira centralizada.

Seu objetivo é simples:

Fazer uma única ação e replicá-la em centenas ou milhares de máquinas.

Por exemplo:

Instalar software.

Criar usuários.

Alterar permissões.

Subir serviços.

Executar scripts.

Aplicar patches.

Configurar firewalls.

Gerenciar cloud.

Criar containers.

Automatizar IBM Z.

Em outras palavras:

"Ansible é o equivalente moderno do JCL PROC para infraestrutura."

Se você já executou:

//STEP1 EXEC PROC=COBOLCOMP

Você já entendeu metade da filosofia do Ansible.

---

Origem do Ansible

O Ansible nasceu em 2012.

Criador:

Michael DeHaan.

O mesmo desenvolvedor que participou do projeto Cobbler.

A ideia era resolver problemas encontrados em ferramentas da época.

Chef

Puppet

CFEngine

Todas eram poderosas.

Mas tinham um problema.

Precisavam instalar agentes.

E agentes são chatos.

Consomem memória.

Precisam atualizar.

Quebram.

Geram vulnerabilidades.

Michael pensou:

"Por que não usar apenas SSH?"

Nascia o Ansible.

Em 2015 a Red Hat comprou a empresa.

Em 2019.

A IBM comprou a Red Hat.

Hoje Ansible faz parte do ecossistema IBM.

Padawan COBOL:

Sim.

Você pode automatizar o mainframe usando uma tecnologia que pertence ao mesmo guarda-chuva corporativo do IBM Z.

---

Versões

Atualmente temos:

Ansible Community

Open Source

Red Hat Ansible Automation Platform

Comercial

AWX

Projeto upstream

Ansible Navigator

CLI moderna

Automation Hub

Coleções certificadas

EDA

Event Driven Automation

---

O segredo do Ansible

Ele funciona usando três componentes.

Inventory

Lista de servidores.

hosts.ini

linux01
linux02
linux03

ou

all:

 children:

  prod:

   hosts:

     db01:

---

Playbook

É o JCL do Ansible.

Arquivo YAML.

Exemplo:

---
- hosts: all

  tasks:

   - name: Criar usuário

     user:

       name: padawan

       state: present

---

Modules

São programas prontos.

Exemplos.

copy

service

yum

apt

shell

uri

zos_job_submit

zos_copy

zos_data_set

Existem milhares.

---

Por que YAML?

Porque YAML é legível.

Exemplo.

name: Bellacosa
idade: 52
profissao: Sysprog Jedi

Até um gerente consegue ler.

E isso assusta alguns desenvolvedores.

---

Instalação

Linux

sudo dnf install ansible

Ubuntu

sudo apt install ansible

Pip

pip install ansible

Verificar

ansible --version

Exemplo.

ansible [core 2.19]

---

Primeiro laboratório

Arquivo.

inventory.ini

localhost

Playbook.

hello.yml

---
- hosts: localhost


 tasks:


 - name: Mostrar mensagem

   debug:

      msg: "Olá Padawan"

Executar.

ansible-playbook hello.yml

Saída.

TASK

Olá Padawan


ok=1

Missão cumprida.

---

Exemplo real

Instalar Apache.

---
- hosts: webservers


 tasks:


 - name: Instalar


   yum:

     name: httpd

     state: present



 - name: Iniciar


   service:


      name: httpd

      state: started

100 servidores.

1 comando.

Fim.

---

Ansible no Mainframe

Aqui a coisa fica divertida.

IBM criou a coleção.

IBM Z Ansible Collection.

Módulos.

zos_copy

zos_data_set

zos_job_submit

zos_operator

zos_tso_command

zos_ping

zos_fetch

---

Criando dataset

- name: criar


 zos_data_set:



   name: BELLA.TESTE


   type: seq


   state: present

---

Submeter JCL

- name: submit



 zos_job_submit:


    src: teste.jcl

---

Executar comando

zos_operator:


 cmd: D IPLINFO

---

Casos reais

Deploy COBOL.

Copiar load modules.

Atualizar PROCLIB.

Executar REORG DB2.

Backup VSAM.

Verificar CICS.

Consultar JES2.

Gerenciar USS.

Criar usuários RACF.

Automatizar IPL checks.

---

Vantagens

Sem agentes

SSH.

WinRM.

z/OS.

Pronto.

---

Fácil aprender

Muito menos complexo que Puppet.

---

Reutilização

Roles.

Templates.

Collections.

---

Infraestrutura como Código

Git.

GitHub.

GitLab.

Azure DevOps.

---

Auditoria

Tudo fica registrado.

---

Desvantagens

SSH lento.

Em milhares de máquinas.

---

YAML depende de espaços.

Erro clássico.

tasks:
-name:

Kaboom.

---

Debug pode ser difícil.

---

Curva de aprendizado.

Jinja2.

Templates.

Loops.

Facts.

---

Truques Jedi

Dry Run

--check

Não altera nada.

---

Diff

--diff

Mostra mudanças.

---

Tags

tags:

 - db2

Executar.

ansible-playbook play.yml --tags db2

---

Vault

Senhas criptografadas.

ansible-vault encrypt

---

Facts

debug:


 var=ansible_hostname

---

Curiosidades

Ansible originalmente usava vacas ASCII.

Existe.

cowsay

Saída.

 __________________

< Deploy completo >

 ------------------

        \   ^__^

         \  (oo)\_______

---

Pode trocar por animais.

Dragon.

Tux.

Moose.

Daemon.

---

Easter Eggs

Execute.

ansible all -m ping

Não é ICMP.

É um módulo.

Resposta.

pong

---

Outra curiosidade.

Existe um módulo chamado.

debug

Que é provavelmente o módulo mais utilizado do planeta.

---

Ansible e o Futuro do IBM Z

O IBM Z moderno está cada vez mais próximo das práticas DevOps.

Git.

Pipelines.

OpenShift.

Terraform.

Zowe.

Ansible.

O Sysprog de 2030 provavelmente não ficará digitando comandos repetitivos no SDSF.

Ele terá um repositório Git.

Um pipeline.

Um Playbook.

E um botão chamado:

Deploy em Produção

E talvez seja justamente isso que assuste alguns veteranos.

Porque durante décadas aprendemos que administrar infraestrutura exigia decorar centenas de comandos obscuros.

Ansible propõe outra filosofia.

Descreva o estado desejado.

A ferramenta cuida do restante.

É quase como ensinar um aprendiz Jedi.

Você não diz exatamente como mover cada músculo do braço.

Você apenas diz:

— Pegue o sabre.

E a Força faz o resto.

No universo do IBM Z, Ansible não substitui o conhecimento profundo de JES2, RACF, CICS, DB2 ou z/OS.

Mas permite que um Padawan COBOL transforme esse conhecimento em automação reproduzível, auditável e compartilhável.

E talvez este seja o maior ensinamento do Holocron do Ansible:

"Um Sysprog poderoso não é aquele que executa mil comandos por dia. É aquele que ensina uma máquina a executá-los corretamente para sempre."

Posso também criar a continuação "O Holocron do Ansible para IBM Z – 20 laboratórios práticos para Padawans COBOL", com exercícios usando zos_job_submit, zos_copy, zos_operator, RACF, CICS e DB2.

Bellacosa Mainframe olhando o LinuxOne

O que é o LinuxONE e Quais Distribuições Linux Roda Nele?

O LinuxONE é uma família de servidores corporativos da IBM baseada na mesma tecnologia utilizada pelos Mainframes IBM Z, mas projetada especificamente para executar sistemas operacionais Linux.

Em outras palavras:

IBM Z = Mainframe completo

LinuxONE = Plataforma IBM Z otimizada para Linux

O LinuxONE combina:

✅ Segurança de nível bancário

✅ Alta disponibilidade

✅ Escalabilidade massiva

✅ Virtualização avançada

✅ Processamento de Cloud, IA e Containers

---

História do LinuxONE

A IBM lançou o LinuxONE em 2015 para atender empresas que desejavam executar:

• Linux

• Containers

• Kubernetes

• OpenShift

• Cloud Privada

• Inteligência Artificial

sobre a mesma arquitetura robusta do Mainframe.

---

Arquitetura Simplificada

Aplicações
      ↓
Containers
      ↓
Kubernetes
      ↓
Linux
      ↓
LinuxONE

---

LinuxONE é Mainframe?

Tecnicamente:

SIM

Ele utiliza a mesma arquitetura IBM Z.

Porém é comercializado como uma plataforma Linux dedicada.

---

Principais Modelos

LinuxONE Emperor

Maior capacidade.

Utilizado por:

• Bancos

• Cloud Providers

• Grandes empresas

---

LinuxONE Rockhopper

Modelo menor.

Voltado para:

• Empresas médias

• Ambientes de desenvolvimento

• Laboratórios

---

Quais Distribuições Linux Roda no LinuxONE?

O LinuxONE utiliza a arquitetura:

s390x

Portanto a distribuição precisa possuir suporte para IBM Z.

---

1. Red Hat Enterprise Linux (RHEL)

Uma das mais utilizadas.

Características

✅ Certificada pela IBM

✅ Muito usada com OpenShift

✅ Excelente suporte corporativo

---

Exemplo:

uname -m

s390x

---

2. Ubuntu Server

Muito popular.

Suporte oficial da Canonical.

---

Utilizado para:

• Containers

• Cloud

• IA

• Desenvolvimento

---

Exemplo:

Ubuntu Server for IBM Z

---

3. SUSE Linux Enterprise Server (SLES)

Tradicional no ambiente Mainframe.

---

Muito usado em:

• Bancos

• Seguradoras

• Governo

---

Características:

✅ Alta estabilidade

✅ Integração com SAP

✅ Excelente suporte IBM Z

---

4. Debian

Possui versão:

Debian s390x

---

Muito utilizada em:

• Laboratórios

• Ambientes acadêmicos

• Open Source

---

5. Fedora

Também suporta:

s390x

---

Mais comum para:

• Testes

• Desenvolvimento

---

Distribuições Mais Utilizadas

Distribuição	Suporte LinuxONE
RHEL	Sim
Ubuntu	Sim
SUSE	Sim
Debian	Sim
Fedora	Sim

---

O que NÃO Roda?

Versões Linux compiladas apenas para:

x86
ARM

não funcionam diretamente.

Precisam existir binários:

s390x

---

LinuxONE e Containers

Suporta:

• Docker

• Podman

• Kubernetes

• OpenShift

---

Exemplo:

OpenShift
      ↓
Containers
      ↓
LinuxONE

---

LinuxONE e Cloud

Muito usado para:

• Cloud privada

• Cloud híbrida

• Multicloud

---

LinuxONE e Inteligência Artificial

Pode executar:

• Python

• TensorFlow

• PyTorch

• Jupyter

• Watsonx

---

LinuxONE e Bancos

Casos comuns:

PIX
Open Finance
Fraudes
APIs
Blockchain
IA

---

LinuxONE e Mainframe Tradicional

Arquitetura conjunta:

COBOL
CICS
DB2
z/OS
      ↓
LinuxONE
      ↓
Java
Python
APIs
Containers

---

Vantagens

✅ Criptografia embarcada

✅ Disponibilidade próxima de 100%

✅ Escalabilidade extrema

✅ Menor consumo energético

✅ Consolidação de milhares de servidores

---

Curiosidades

1. LinuxONE utiliza processadores IBM Telum

2. Executa milhares de máquinas virtuais simultaneamente

3. Possui criptografia em hardware

4. É amplamente utilizado para OpenShift

5. Compartilha tecnologia com os Mainframes IBM Z

---

Resumo Rápido

Conceito	Descrição
LinuxONE	Plataforma Linux baseada em IBM Z
Arquitetura	s390x
RHEL	Suporte oficial
Ubuntu	Suporte oficial
SUSE	Suporte oficial
Debian	Suporte disponível
Fedora	Suporte disponível
Containers	Docker e Podman
Kubernetes	Sim
OpenShift	Sim
Cloud	Sim
IA	Sim

---

Conclusão

O LinuxONE é a plataforma Linux corporativa da IBM baseada na arquitetura IBM Z, oferecendo a robustez, segurança e disponibilidade dos Mainframes para workloads Linux modernos. As distribuições mais utilizadas são Red Hat Enterprise Linux (RHEL), Ubuntu Server, SUSE Linux Enterprise Server (SLES), Debian e Fedora, todas compiladas para a arquitetura s390x e prontas para executar aplicações Cloud, Containers, APIs, Inteligência Artificial e soluções corporativas de missão crítica.