Helios: una distribución de Illumos que impulsa el Rack de Oxide

Artículo original ↗ Discusión en Hacker News ↗

El nuevo sistema operativo Helios de Oxide Computer, de código abierto, una distribución basada en Illumos, sustenta una plataforma de servidores a escala de rack e integrada verticalmente que busca ofrecer una experiencia similar a AWS en los propios centros de datos de los clientes. Los comentaristas sopesan las compensaciones técnicas y comerciales de elegir Illumos y el hipervisor bhyve frente a Linux y KVM, señalando ventajas en cohesión, observabilidad, integración con ZFS y control de toda la pila, al tiempo que advierten sobre la familiaridad del ecosistema, la dependencia del proveedor, la falta de GPU y las funciones nativas de contenedores que aún faltan. Muchos ven el producto como una alternativa de nicho pero oportuna frente a las pilas on-premises tradicionales y a las ofertas de nube y VMware cada vez más costosas o restrictivas, especialmente para grandes empresas e instituciones de investigación.

Producto y arquitectura

  • Helios es una distribución de SO basada en illumos que impulsa el sistema de escala de rack verticalmente integrado de Oxide.
  • El SO es en gran medida un detalle de implementación interno: los clientes aprovisionan VMs mediante APIs; por lo general no interactúan con Helios directamente ni despliegan aplicaciones sobre illumos.
  • La pila del hipervisor usa un VMM basado en bhyve (Propolis). Los racks están diseñados como unidades holísticas de hardware+software (alimentación compartida, switch integrado, firmware personalizado, plano de control basado en Rust).

Por qué illumos en lugar de Linux

  • Las principales razones citadas: gran familiaridad del equipo, capacidad de “poseer toda la pila” y mejor ajuste para construir y mantener una distribución completa (kernel + bibliotecas + userland) en lugar de ensamblar muchos componentes de Linux.
  • La herencia de illumos/ZFS/DTrace, la calidad del código y la cohesión se ven como ventajas para el mantenimiento y la depuración a largo plazo.
  • Algunos sostienen que el tamaño del ecosistema de Linux y su familiaridad facilitarían la contratación y la integración con proveedores; otros responden que hay que contratar por la capacidad de aprendizaje e internalizar la experiencia necesaria.

Modelo de cargas de trabajo: VMs, contenedores, compatibilidad

  • El punto de apoyo principal son las VMs: Helios ejecuta Linux, Windows, *BSD, etc. sin modificaciones como SO invitados.
  • Los contenedores/Kubernetes normalmente se ejecutarían dentro de VMs Linux; todavía no hay una plataforma de contenedores de primera parte integrada.
  • Actualmente no hay virtualización anidada ni soporte de GPU, lo que limita ciertas cargas de trabajo (por ejemplo, kubevirt, Firecracker, WSL2, uso de GPU/LLM).

Propuesta de valor para el cliente y ajuste al mercado

  • Se posiciona como “APIs tipo cloud para tu propio centro de datos”: infraestructura on-premises lista para usar con cómputo, almacenamiento y redes integrados.
  • Clientes objetivo: organizaciones que deben o prefieren on-premises (grandes empresas, laboratorios de investigación, instituciones financieras) y quieren una alternativa de un solo proveedor, fuertemente integrada, a hardware + VMware/OpenStack por su cuenta.
  • La competitividad en costos se debate; algunos creen que los racks pueden rebajar el gasto de varios años en la nube pública, especialmente para cargas con muchos datos.

Preocupaciones: bloqueo, riesgo, nicho

  • A algunos les preocupa depender de un proveedor pequeño con un SO/hipervisor personalizado y de la falta de experiencia amplia en illumos/bhyve.
  • Otros argumentan que los hipervisores específicos de proveedor ya son normales (AWS Nitro, el SO anfitrión de Azure, ESXi), y que la apertura de Oxide más la portabilidad de VMs mitigan el bloqueo.
  • El producto es temprano y de nicho; algunos ven a los laboratorios estatales y a las grandes finanzas como adoptantes tempranos naturales.

Código abierto, licencias y comunidad

  • Helios está licenciado bajo MPL 2.0; la política de la empresa prefiere MPL para el código nuevo, con excepciones donde los ecosistemas tienen licencias predominantes (por ejemplo, Apache/MIT para crates de Rust).
  • Se pretende que el firmware y los diseños de hardware sean abiertos con el tiempo para reducir el riesgo de “pisapapeles” si la empresa fracasa.
  • Se comenta la complejidad de compilación de illumos y la incorporación de desarrolladores; los mantenedores reconocen las concesiones y los recursos limitados, pero reportan desarrollo activo a través de múltiples distribuciones.