Incluso con todos los avances en TI, ya sea hardware modular, recursos masivos de computación en la nube o dispositivos de borde de factor de forma pequeño, TI todavía tiene un problema de escala. No físicamente: es fácil agregar más cajas, más almacenamiento y más “cosas” a ese respecto. El desafío con la escala es lograr que sus operaciones funcionen según lo previsto en ese nivel, y comienza con asegurarse de que puede crear, implementar y mantener aplicaciones de manera efectiva y eficiente a medida que crece. Esto significa que el componente básico de devopsel sistema operativo, necesita escalar de forma rápida, fluida y sin inconvenientes.
Diré esto desde el principio: Esto es duro. Muy duro.
Pero podríamos estar entrando en una (otra) era de iluminación para el sistema operativo. He visto cuál podría ser el futuro de los sistemas operativos a escala y comienza con Proyecto atún rojo. ¿Pero cómo funciona un escritorio nuevo y relativamente oscuro? linux ¿El proyecto predice el próximo modelo de informática empresarial? Tres palabras: sistema operativo en contenedores.
En pocas palabras, este modelo es una imagen de contenedor con una distribución de Linux completa, incluido el kernel. Usted extrae una imagen base, la construye, envía su trabajo a un servidor de registro, lo despliega en una máquina diferente, lo coloca en el disco y lo inicia en una máquina virtual o sin sistema operativo. Esto facilita a los usuarios crear, compartir, probar e implementar sistemas operativos, tal como lo hacen hoy con las aplicaciones dentro de contenedores.
¿Qué es el Proyecto Bluefin?
Los contenedores de Linux cambiaron el juego cuando se trataba de desarrollo nativo de la nube y la implementación de aplicaciones de nube híbrida, y ahora la tecnología está preparada para hacer lo mismo con los sistemas operativos empresariales. Para ser claro, Proyecto atún rojo No es un producto empresarial, más bien es una plataforma de escritorio orientada en gran medida a los jugadores, pero creo que es un presagio de cosas más importantes por venir.
“Bluefin es Fedora”, dijo el fundador de Bluefin, Jorge Castro, durante una video charla en la Conferencia ContainerDays del año pasado. «Es un Linux para su computadora con ajustes especiales que hemos superpuesto atómicamente de una manera única que creemos que resuelve muchos de los problemas que han estado plagando los escritorios Linux».
De hecho, con cualquier entorno Linux, los usuarios hacen cosas para hacerlo suyo. Esto podría deberse a varias razones, incluido el deseo de agregar o cambiar paquetes, o incluso a ciertas reglas comerciales. Fedora, por ejemplo, tiene reglas sobre la integración únicamente de contenido de código abierto. Si quisiera agregar, digamos, controladores Nvidia, tendría que pegarlos usted mismo en Fedora y luego implementarlo. Project Bluefin agrega este tipo de salsa especial con anticipación para hacer que el sistema operativo (en este caso, Fedora) sea más fácil de implementar.
La versión “predeterminada” de Bluefin es un escritorio GNOME con una base en la parte inferior, indicadores de aplicaciones en la parte superior y la tienda Flathub habilitada de fábrica. “No es necesario hacer ninguna configuración ni nada”, dijo Castro. “Realmente no tienes que preocuparte de dónde vienen. … Nos encargamos de los códecs por usted, habilitamos un montón de hardware y su controlador de juego funcionará. Habrá cosas que tal vez no funcionen en Fedora predeterminado que intentaremos arreglar, y también tratamos de incorporar tantas cosas como podamos, incluidos los controladores de Nvidia. Ya no hay razón para que su sistema operativo compile un módulo cada vez que realiza una actualización. Lo hacemos todo en CI y es fantástico. Automatizamos completamente el mantenimiento del escritorio porque estamos buscando un Chromebook. … Viene con un tiempo de ejecución de contenedor, como deberían hacerlo todos los buenos escritorios nativos de la nube”.
Cómo presagia Bluefin el potencial empresarial
La forma en que Castro describe cómo y por qué se construyó el proyecto Bluefin suena sorprendentemente similar a las razones por las cuales los desarrolladores, arquitectos, administradores de sistemas y cualquier otra persona que consuma sistemas operativos empresariales crean compilaciones centrales. Y ahí reside el potencial empresarial, aunque la mayoría de la gente no ve que el problema que resuelve Bluefin es idéntico a un problema empresarial que tenemos en la empresa.
Todo comienza con los “retoques especiales” que mencionó Castro.
Tomemos, por ejemplo, un gran banco. Toman lo que les ofrece el proveedor del sistema operativo y le aplican ajustes especiales para adaptarlo a su entorno según sus reglas comerciales. Estos ajustes se acumulan y pueden volverse bastante complicados. Podrían agregar refuerzo de seguridad, bibliotecas y códecs para compresión, algoritmos de cifrado, claves de seguridad, configuraciones para LDAP, software con licencia especial o controladores. Puede haber cientos de personalizaciones en una organización grande con requisitos complejos. De hecho, cada vez que una pieza compleja de software transfiere la custodia entre dos organizaciones, casi siempre requiere ajustes especiales. Ésta es la naturaleza de la informática de las grandes empresas.
Se vuelve aún más complicado dentro de una organización. Distintos expertos internos, como ingenieros de seguridad, administradores de redes, administradores de sistemas, arquitectos, administradores de bases de datos y desarrolladores, colaboran (o intentan hacerlo, de todos modos) para crear una única pila de software que se ajuste al propósito dentro de las reglas y pautas de esa organización específica. Esto es particularmente cierto para el sistema operativo en el borde o con IA, donde los desarrolladores desempeñan un papel más importante en la configuración del sistema operativo subyacente. Para acertar con una sola carga de trabajo, podrían ser necesarias entre 50 y 100 interacciones entre todos estos expertos. Cada una de estas interacciones lleva tiempo, aumenta los costos y amplía el margen de error.
Se vuelve aún más difícil cuando comienzas a agregar socios y consultores externos.
Hoy, todos esos expertos hablan diferentes idiomas. La gestión de la configuración y herramientas como Kickstart ayudan, pero no son elegantes cuando se trata de una colaboración compleja y a veces hostil entre y dentro de las organizaciones. Pero ¿y si pudieras usar contenedores como lengua materna para desarrollar e implementar sistemas operativos? Esto resolvería todos los problemas (especialmente los problemas de personas) que se resolvieron con contenedores de aplicaciones, pero lo llevarás al sistema operativo.
La IA y el aprendizaje automático están maduros para los sistemas operativos en contenedores
Inteligencia artificial y aprendizaje automático Son casos de uso particularmente interesantes para un sistema operativo en contenedores porque son híbridos por naturaleza. Un modelo base a menudo es entrenado, ajustado y probado por ingenieros de calidad y dentro de una aplicación de chatbot, todo en diferentes lugares. Luego, tal vez, vuelva para realizar más ajustes y finalmente se implemente en producción en un entorno diferente. Todo esto exige a gritos el uso de contenedores, pero también requiere aceleración de hardware, incluso en desarrollo, para una inferencia más rápida y menos molestias. Cuanto más rápido se ejecute una aplicación y más corto sea el ciclo de desarrollo interno, más felices estarán los desarrolladores y el personal de ingeniería de calidad.
Por ejemplo, piense en una carga de trabajo de IA que se implementa localmente en la computadora portátil de un desarrollador, tal vez como una máquina virtual. La carga de trabajo incluye un modelo previamente entrenado y un chatbot. ¿No sería bueno si se ejecutara con aceleración de hardware para una inferencia más rápida, de modo que el chatbot responda más rápido?
Ahora, digamos que los desarrolladores están husmeando con el chatbot y descubren un problema. Crean una nueva interacción de usuario etiquetada (documento de preguntas y respuestas) para solucionar el problema y quieren enviarla a un clúster con tarjetas Nvidia para realizar más ajustes. Una vez que se haya entrenado más, los desarrolladores quieren implementar el modelo en el borde en un dispositivo más pequeño que realice algunas inferencias. Cada uno de estos entornos tiene hardware diferente y controladores diferentes, pero los desarrolladores sólo quieren la comodidad de trabajar con los mismos artefactos (una imagen de contenedor, si es posible).
La idea es que puedas implementar la carga de trabajo en todas partes, de la misma manera, con sólo algunos pequeños ajustes. Estás tomando esta imagen del sistema operativo y compartiéndola en una computadora portátil con Windows o Linux. Lo mueves a un entorno de prueba de desarrollo, lo entrenas un poco más en un CI/CD, tal vez incluso trasladarlo a un grupo de capacitación que realice algunas mejoras con otro hardware especializado. Luego, lo implementa en producción en un centro de datos o un centro de datos virtual en una nube o en el borde.
La promesa y la realidad actual
Lo que acabo de describir es actualmente un desafío de lograr. En una organización grande, puede llevar seis meses realizar las compilaciones básicas. Luego viene una actualización trimestral, para la que se necesitan otros tres meses de preparación. La complejidad del trabajo involucrado aumenta el tiempo que lleva llevar un nuevo producto al mercado, por no hablar de “simplemente” actualizar algo. De hecho, las actualizaciones pueden ser la propuesta de mayor valor de un modelo de sistema operativo en contenedores: puede actualizar con un solo comando una vez que se completa la compilación principal. Las actualizaciones ya no se ejecutarían yum: simplemente pasarían del punto A al punto B. Y, si la actualización fallara, simplemente retrocederían. Este modelo es especialmente atractivo en el borde, donde el ancho de banda y la confiabilidad son preocupaciones.
Un modelo de sistema operativo en contenedores también abriría nuevas puertas para aplicaciones que las organizaciones decidieron no incluir en contenedores, por cualquier motivo. Puede simplemente insertar las aplicaciones en una imagen del sistema operativo e implementar la imagen en una máquina virtual o sin sistema operativo. En este escenario, las aplicaciones obtienen algunas, aunque no todas, las ventajas de los contenedores. Obtiene los beneficios de una mejor colaboración entre expertos en la materia, una vía estandarizada para entregar carga (Imágenes y registros de contenedores OCI) y actualizaciones y reversiones simplificadas en producción.
En teoría, un sistema operativo en contenedores también proporcionaría beneficios de gobernanza y procedencia. Al igual que con las aplicaciones en contenedores, todo lo que hay en un sistema operativo en contenedores se confirmaría en GitHub. Podría crear una imagen desde cero y saber exactamente qué contiene y luego implementar el sistema operativo exactamente a partir de esa imagen. Además, podría utilizar su misma infraestructura de prueba, linting y escaneo, incluida la automatización en CI/CD.
Por supuesto, habría algunos obstáculos que superar. Si está implementando el sistema operativo como una imagen de contenedor, por ejemplo, debe pensar en los secretos de una manera diferente. Ya no se pueden tener contraseñas integradas en el sistema operativo. Tienes el mismo problema con las aplicaciones en contenedores. Kubernetes resuelve este problema ahora con su servicio de administración de secretos, pero definitivamente sería necesario trabajar un poco en torno a los secretos con un sistema operativo cuando se implementa como una imagen.
Hay muchas preguntas que responder y escenarios que considerar antes de que consigamos un sistema operativo en contenedores que se convierta en una realidad empresarial. Pero el Proyecto Bluefin insinúa un futuro de sistema operativo en contenedores que tiene demasiado sentido no para llegar a buen término. Será interesante ver si la industria adopta este nuevo paradigma y cómo lo hace.
En sombrero rojoScott McCarty es gerente principal de productos de RHEL Server, posiblemente la empresa de software de código abierto más grande del mundo. Scott es un veterano de las startups de redes sociales, un veterano del comercio electrónico y un veterano tecnólogo de investigación gubernamental, con experiencia en una variedad de empresas y organizaciones, desde startups de siete personas hasta empresas de tecnología con 12.000 empleados. Esto ha culminado en una perspectiva única sobre el desarrollo, la entrega y el mantenimiento de software de código abierto.
—
New Tech Forum ofrece un lugar para explorar y discutir la tecnología empresarial emergente con una profundidad y amplitud sin precedentes. La selección es subjetiva y se basa en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para su publicación y se reserva el derecho de editar todo el contenido aportado. Envía todas las consultas a newtechforum@infoworld.com.
Copyright © 2024 IDG Communications, Inc.
