Nuevo IBM LinuxONE 4 Express – mainframe Linux montado en rack y preconfigurado

Precios, licencias y rentabilidad

• El hardware base empieza en torno a 135k dólares, pero eso excluye el sistema operativo, el software, el almacenamiento y el mantenimiento; se espera que los costes reales sean mucho más altos.
• LinuxONE usa núcleos IFL (solo Linux), evitando las caras licencias de z/OS, pero muchos señalan que el software y el soporte de IBM siguen siendo caros.
• Algunos sostienen que los mainframes pueden ser más baratos que diseñar y operar pilas HA/DR a medida; otros dicen que el hardware/software de mainframe, la memoria y los hipervisores son órdenes de magnitud más caros que sus equivalentes x86.
• Las comparaciones de TCO suelen depender de la consolidación y de la concesión de licencias de software (por ejemplo, sustituir muchos núcleos x86 por pocos IFL).

Afirmaciones de disponibilidad y fiabilidad

• El marketing menciona una disponibilidad de “ocho nueves”; los comentaristas corrigen que:
  • ~30 segundos/año son seis nueves; ocho nueves son ~316 ms/año.
• Muchos consideran irrealista ese tiempo de actividad desde una sola máquina; argumentan que se necesitan configuraciones en clúster al estilo sysplex.
• Los mainframes son elogiados por CPU, memoria y discos intercambiables en caliente, y por sus muy sólidas funciones RAS; los fallos se ocultan y se reparan sin tiempo de inactividad.
• Otros señalan que, más allá de la máquina, la energía del centro de datos, la refrigeración y la conectividad limitan el tiempo de actividad real.

Arquitectura, capacidades e IA

• LinuxONE es un sistema IBM Z solo para Linux: ejecuta Linux en LPARs mediante PR/SM, a menudo con z/VM o KVM como hipervisor.
• El énfasis está en una imagen de sistema única, un rendimiento extremo de E/S y una latencia predecible, no en el pico de FLOPS.
• Las CPU Telum funcionan a unos 5 GHz e incluyen aceleradores de inferencia en el chip, pensados para cosas como la detección de fraude en tiempo real integrada en flujos transaccionales.
• La jerarquía de memoria y caché (grandes cachés compartidas, RAIM, rutas anchas) está ajustada para cargas de trabajo de mainframe; la comparación directa con el ancho de banda HBM de GPU es debatida y poco clara.

Casos de uso y cuándo elegir mainframes

• Hoy predominan las cargas de trabajo existentes de banca, seguros, gobierno, aerolíneas y logística, especialmente sistemas COBOL/PL1/z/OS que “nunca se moverán de ahí”.
• Se considera raro captar clientes nuevos; la mayoría de las ventas son ampliaciones o actualizaciones para usuarios actuales.
• Los defensores presentan los mainframes como ideales cuando:
  • El tiempo de actividad y la integridad de los datos son existenciales (multi-9s, “cada lectura/escritura correcta”).
  • Se quiere integración vertical y un único proveedor responsable.
• Los críticos argumentan que, para la mayoría de las aplicaciones modernas, los servicios cloud (S3, step functions, K8s gestionado) ofrecen una disponibilidad “suficientemente buena” por una fracción del coste.

Comparación con servidores x86 y cloud/Kubernetes

• Algunos afirman que un mainframe de gama baja puede sustituir grandes bastidores de servidores x86; otros dicen que el rendimiento por núcleo no es dramáticamente mejor y a menudo es peor para cargas genéricas.
• Los mainframes brillan en disponibilidad, E/S y estabilidad de latencia; los hyperscalers y los clústeres K8s destacan en escalado horizontal y economía de commodity.
• Varios señalan que la ingeniería de fiabilidad en cloud/K8s requiere mucho personal especializado; otros responden que los administradores de mainframe son más escasos y caros.

Experiencia de desarrollo y herramientas

• Las herramientas tradicionales de mainframe (terminales 3270, JCL, COBOL/PL1) se describen como potentes pero arcaicas y dolorosas, con restricciones (límites de línea, modelos de enlace) que empujan hacia código eficiente y de bajo nivel.
• Algunos elogian las interfaces de pantalla verde por la productividad de los expertos; otros destacan la mala ergonomía y la curva de aprendizaje.
• Existen herramientas modernas (plugins para Eclipse/VS Code, desarrollo remoto), pero pueden añadir sobrecarga de JVM/servicios web y erosionar la antigua eficiencia.
• LinuxONE suaviza muchos de estos problemas al ejecutar “solo Linux”, pero renuncia a algunas funciones clásicas de mainframe si se permanece puramente en la pila Linux.

Acceso, ecosistema y dependencia del proveedor

• Un tema recurrente: es difícil y caro obtener acceso práctico a un mainframe para aprender; las ofertas de desarrollo/pruebas de IBM son costosas por usuario.
• Opciones gratuitas o más baratas: emulador Hercules, instancias comunitarias s390x/LinuxONE en la nube a tarifas horarias moderadas, aunque z/OS sigue siendo caro.
• Este acceso limitado se ve como una razón importante del escaso tooling de código abierto y del pequeño grupo de talento.
• Muchos temen la dependencia del proveedor y el dolor de “tener que lidiar con IBM”, aunque otros señalan que las nubes públicas también crean una fuerte dependencia.

Marketing, “nube híbrida” y posicionamiento

• El lenguaje de IBM (“plataforma de nube híbrida ciberresiliente e IA”) se percibe ampliamente como cargado de jerga y orientado a ejecutivos, no a ingenieros.
• “Nube híbrida” aquí suele significar mainframes on-prem integrados con la nube pública, a menudo mediante Kubernetes, APIs y herramientas compartidas.
• Algunos ven LinuxONE básicamente como “una mezcla on-prem de mini-cloud/mainframe”; otros sostienen que IBM no ha articulado claramente el nicho más allá de los clientes existentes.