Novo IBM LinuxONE 4 Express – mainframe Linux pré-configurado montado em rack

Preços, licenciamento e relação custo-benefício

• O hardware básico começa em cerca de US$ 135 mil, mas isso exclui SO, software, armazenamento e manutenção; espera-se que os custos reais sejam bem mais altos.
• O LinuxONE usa núcleos IFL (apenas Linux), evitando licenças caras de z/OS, mas muitos observam que o software e o suporte da IBM ainda são caros.
• Alguns argumentam que mainframes podem ser mais baratos do que projetar e operar stacks HA/DR sob medida; outros dizem que o hardware/software de mainframe, a memória e os hipervisores são ordens de magnitude mais caros do que equivalentes x86.
• Comparações de TCO frequentemente dependem de consolidação e licenciamento de software (por exemplo, substituir muitos núcleos x86 por poucos IFLs).

Reivindicações de disponibilidade e confiabilidade

• O marketing menciona disponibilidade de “oito noves”; comentaristas corrigem que:
  • ~30 segundos/ano são seis noves; oito noves são ~316 ms/ano.
• Muitos consideram essa disponibilidade de uma única máquina irrealista; argumentam que você precisa de setups em cluster no estilo sysplex.
• Mainframes são elogiados por CPUs, memória e discos hot-swappable, e por recursos RAS muito fortes; falhas são mascaradas e corrigidas sem downtime.
• Outros observam que, para além da máquina, energia do datacenter, refrigeração e conectividade limitam a disponibilidade no mundo real.

Arquitetura, capacidades e IA

• LinuxONE é um sistema IBM Z apenas para Linux: executa Linux em LPARs via PR/SM, muitas vezes com z/VM ou KVM como hipervisor.
• A ênfase está em single-system image, throughput extremo de IO, processamento de transações e latência previsível, não em FLOPS de pico.
• CPUs Telum operam em torno de 5 GHz e incluem aceleradores de inferência no chip, destinados a coisas como detecção de fraude em tempo real embutida em fluxos de transação.
• A hierarquia de memória e cache (grandes caches compartilhados, RAIM, caminhos largos) é ajustada para workloads de mainframe; a comparação direta com a largura de banda HBM de GPUs é debatida e pouco clara.

Casos de uso e quando escolher mainframes

• O uso dominante hoje: workloads existentes de bancos, seguradoras, governo, companhias aéreas e logística, especialmente sistemas COBOL/PL1/z/OS que “nunca sairão de lá”.
• Novos clientes são considerados raros; a maior parte das vendas são expansões ou upgrades para usuários atuais.
• Defensores apresentam mainframes como ideais quando:
  • disponibilidade e integridade dos dados são existenciais (multi-nines, “toda leitura/escrita correta”).
  • você quer integração vertical e um único fornecedor responsável.
• Críticos argumentam que, para a maioria das aplicações modernas, serviços em nuvem (S3, step functions, K8s gerenciado) oferecem disponibilidade “boa o suficiente” por uma fração do custo.

Comparação com servidores x86 e nuvem/Kubernetes

• Alguns afirmam que um mainframe de entrada pode substituir grandes racks de servidores x86; outros dizem que o desempenho por núcleo não é dramaticamente melhor e muitas vezes é pior para workloads genéricos.
• Mainframes se destacam em disponibilidade, IO e estabilidade de latência; hyperscalers e clusters K8s se destacam em escalabilidade horizontal e economia de commodity.
• Vários observam que engenharia de confiabilidade em cloud/K8s exige uma equipe especializada significativa; outros contrapõem que administradores de mainframe são mais raros e caros.

Experiência de desenvolvedor e ferramentas

• Ferramentas tradicionais de mainframe (terminais 3270, JCL, COBOL/PL1) são descritas como poderosas, porém arcaicas e dolorosas, com restrições (limites de linha, modelos de linkedição) que empurram para código de baixo nível e eficiente.
• Alguns elogiam interfaces green-screen pela produtividade de especialistas; outros destacam ergonomia ruim e curva de aprendizado.
• Há ferramentas modernas (plugins para Eclipse/VS Code, desenvolvimento remoto), mas elas podem adicionar overhead de JVM/serviços web e corroer a eficiência antiga.
• O LinuxONE ameniza muitos desses problemas ao rodar “apenas Linux”, mas abre mão de alguns recursos clássicos de mainframe se você permanecer puramente na stack Linux.

Acesso, ecossistema e lock-in

• Um tema recorrente: é difícil e caro obter acesso prático a mainframes para aprender; as ofertas de dev/test da própria IBM são caras por usuário.
• Opções gratuitas ou mais baratas: emulador Hercules, instâncias comunitárias s390x/LinuxONE na nuvem a tarifas horárias modestas, embora z/OS continue caro.
• Esse acesso limitado é visto como uma grande razão para o fraco tooling de código aberto e para o pequeno conjunto de talentos.
• Muitos se preocupam com lock-in de fornecedor e com a dor de “ter que lidar com a IBM”, embora outros observem que clouds públicas também criam forte lock-in.

Marketing, “nuvem híbrida” e posicionamento

• A linguagem da IBM (“cyber resilient hybrid cloud and AI platform”) é amplamente vista como cheia de buzzwords e voltada a executivos, não a engenheiros.
• “Nuvem híbrida” aqui geralmente significa mainframes on-prem integrados à nuvem pública, muitas vezes via Kubernetes, APIs e ferramentas compartilhadas.
• Alguns veem o LinuxONE basicamente como “uma mistura de mini-cloud/mainframe on-prem”; outros argumentam que a IBM não articulou claramente o nicho além dos clientes existentes.