Es hora de desafiar el status quo de la generación de distribuciones de Linux para crear una nueva versión que aborde mejor los desafíos actuales de la industria. La solución es una distribución de Linux en contenedor diseñada para cargas de trabajo nativas de la nube.

Debian y Slackware se crearon hace 30 años, y SUSE Linux en 1994, poco después. Durante todos estos años, varias empresas han estado ofreciendo una versión compatible de Linux a empresas que necesitan saber que su Linux es seguro para usar en producción, mientras que algunas otras distribuciones estuvieron disponibles de forma gratuita para cualquier propósito. En la mayoría de los casos, si usted es una empresa que utiliza Linux (y hubo un tiempo en el que esta afirmación no se aplicaría a la mayoría de las empresas), realmente se beneficia (o necesita) tener a alguien a quien llamar cuando tenga una problema. Para tranquilizarlo aún más, las certificaciones le brindan una confianza razonable de que el hardware y el software que utiliza se ejecutarán correctamente para su aplicación sin mayores problemas. Y funciona sorprendentemente bien.

S.u.S.E.

Las aplicaciones se han estado ejecutando durante décadas en esos sistemas, con muy pocos problemas que fueron resueltos rápidamente por un grupo de ingenieros a quienes se les pagó para solucionarlos. La mayoría de las innovaciones actuales no serían posibles sin ellas. Esos ingenieros le proporcionarían un entorno muy estable y, en muchos casos, incluso buscarían el código en busca de versiones más nuevas y lo trasladarían a la versión que estaba ejecutando.

Actualmente, la innovación requiere una velocidad diferente. Las versiones de Kubernetes, por ejemplo, se crean cada cuatro meses aproximadamente y se actualizan durante un año. Para que todo suceda se necesitan matrices de soporte muy complejas, incluidos componentes y versiones del sistema operativo subyacente.

¿Pero qué es un sistema operativo?

Podemos aprovechar los hombros de gigantes y utilizar algunas definiciones de Tannenbaum et al.

Un sistema operativo es un componente que administra el hardware conectado y luego ofrece una abstracción limpia de esos recursos a los programas de aplicación.

Pero las distribuciones de Linux son más que eso. Por supuesto, hay mucho trabajo para habilitar el hardware y hacerlo compatible con la última versión del kernel y glibc (la API ofrecida a los usuarios que siguen el estándar POSIX para Linux y otros). Sin embargo, existen otras herramientas que hacen que la API sea accesible; por ejemplo, para poder configurar las tarjetas de red sin tener que llamar directamente a la API.

Además de eso, debido a que las distribuciones de Linux se crearon en una época en la que Internet no era tan bueno hoy en día (intente conectarse hoy a cualquier página usando un módem de 64K), se incluyeron muchas aplicaciones, desde clientes de correo electrónico hasta fotografías. editores. Esto es fantástico cuando descargar algo puede llevar días, pero, por supuesto, no proporciona las últimas actualizaciones y versiones cuando lo reinstalas unos meses más tarde, por lo que tu primera acción después de una instalación normalmente es una actualización completa (si estás conectado a la Internet). Las distribuciones empresariales en realidad usaban el mismo modelo y también ofrecían muchas de esas aplicaciones, incluso si nadie las usaba en el producto (era difícil saberlo). saber sin telemetría, pero era probable).

¿Cuál es el problema?

La instalación de una aplicación extensa (CRM, ERP, DataWarehouse, etc.) requiere una planificación cuidadosa, así como personalizaciones e integraciones. Debe asegurarse de que cada pieza que se implemente esté certificada y sea compatible. Eso significa que los proveedores prueban sus aplicaciones con diferentes versiones del sistema operativo, bases de datos, etc.

No se cambian esas aplicaciones con frecuencia (por ejemplo, conozco empresas de telecomunicaciones con diez sistemas de facturación diferentes porque el riesgo de migrar a un nuevo sistema de facturación moderno es demasiado alto para ellas, y algunos sistemas funcionan durante años con la misma pila en hardware obsoleto). en el centro de datos). En otros casos, las industrias están fuertemente reguladas y requieren un contrato de soporte para cualquier software que se ejecute. Por esas razones, muchos proveedores ofrecen soporte a largo plazo después de algunos años de soporte estándar, lo que básicamente le permite leer la documentación y pedir consejo y, a veces, proporciona soluciones para vulnerabilidades de alto impacto, pero limita en gran medida la inversión en el producto. , lo que reduce los casos en los que puede abrir un ticket y obtener una solución o un backport.

¿Por qué hacer backporting? Bueno, los parches normalmente se desarrollan primero en código abierto para la última versión, junto con la refactorización y las actualizaciones del código. Si no puede actualizar a la última versión, no podrá obtener el parche necesario. Los proveedores intentarán encontrar una solución al error en la versión actual buscando en la última versión. Si hay una solución ahí, verán si es posible actualizar el parche para que funcione con el código base anterior. Incluso con un parche adecuado, el proceso requiere exámenes y pruebas cuidadosos, lo cual es costoso y en ocasiones no funciona (por ejemplo, cuando el error desapareció después de una reingeniería del código).

Uno de los principales valores de una distribución de Linux es proporcionar la estabilidad necesaria para estas aplicaciones, pero eso a su vez requiere (cuando se hace correctamente) muchos recursos para mantener diferentes versiones del mismo paquete. Además de todo eso, algunos de ellos también agregarán certificaciones de seguridad, validación de terceros de que el código es seguro, por lo que puede estar seguro de que puede ejecutar sus cargas de trabajo si necesita la certificación Common Criteria o FIPS (es decir, PCI-DSS para transacciones con tarjeta de crédito). ).

Durante varias décadas, un contrato de soporte de distribución de Linux incluiría:

Soporte y certificación de hardware: Un sistema operativo (SO) cumple principalmente dos funciones críticas: facilitar la abstracción del hardware (hacer que los componentes del hardware funcionen perfectamente con el software) y administrar los recursos del sistema de manera eficiente. Tras su lanzamiento, un sistema operativo se somete a pruebas o certificaciones exhaustivas con una amplia gama de configuraciones de hardware. La lista de compatibilidad está influenciada por las relaciones entre los fabricantes de hardware y los proveedores de sistemas operativos. La compatibilidad también depende significativamente de factores como la versión del kernel de Linux y las bibliotecas incluidas en el sistema operativo. Con el tiempo, garantizar que una combinación de hardware y software siga siendo compatible se vuelve cada vez más difícil, especialmente con la introducción de nuevos componentes de hardware. 

Resolución de defectos: todo el código tiene errores y constantemente se lanzan nuevas versiones de las aplicaciones para agregar nuevas funciones y corregir errores. En la mayoría de los casos, los parches también se entregarán posteriormente para que formen parte del código estándar.

Actualizaciones: ¿Quiere asegurarse de que su software se descargue desde una ubicación segura? Las distribuciones incluyen una selección de paquetes creados y publicados con un flujo de trabajo seguro que se han probado para que funcionen bien juntos.

Correcciones de seguridad: Siempre hay errores en el código, pero los problemas de seguridad ponen su máquina en riesgo. Si tiene un código de seguridad defectuoso, es posible obtener acceso no autorizado a su sistema y obtener o cambiar información donde no debería ser posible.

Soporte técnico: tiene todo el conocimiento interno para identificar el problema, encontrar una solución e instalar y configurar el parche necesario para solucionar el problema. 

Documentación: A veces el problema es encontrar la documentación necesaria para instalar y actualizar el software, y tenerla disponible en un único lugar simplifica enormemente la gestión.

Eso no parece un problema...

Bueno, no fue un problema y no lo ha sido durante años. Fue un proceso bien definido que requirió meses de pruebas y una planificación cuidadosa. En ese momento, el desarrollo de la aplicación del cliente llevó años y de todos modos requería estabilidad total, así que estuvo bien. Pero ahora scrum y agile han abierto la oportunidad de crear nuevas versiones varias veces al día e implementarlas en producción con la mayor frecuencia posible, con compilación, prueba e implementación automatizadas. La tecnología se ha actualizado, por lo que, en lugar de tardar semanas o meses en crear un entorno, se implementa un sistema automatizado que puede crear una máquina virtual y prepararlo todo para funcionar en minutos, o actualizar el código automáticamente tan pronto como se publica en un repositorio de Git. .

Entonces, ¿cuál es el problema? Es tan grande que tiene un nombre: “Infierno de dependencia” 

1. A veces, necesita una versión de un paquete que no ha sido probada ni actualizada y, por lo tanto, no forma parte del conjunto principal. Podrías esperar hasta que se lance la nueva versión del sistema operativo, pero eso puede llevar meses, y reescribir la función X para poder usar una versión anterior creará una deuda tecnológica, por lo que no es una opción.
2. En muchos casos, no existe una forma real de actualizar paquetes de forma segura a la velocidad de los proyectos anteriores, especialmente si el requisito incluye poder crear parches para ellos.
3. Es probable que encuentre dependencias en conflicto. Una dependencia requiere una biblioteca o paquete versión 1. Otra versión 2. Y no se pueden instalar juntos, por lo que se ve obligado a decidir qué versión necesita y arreglar el árbol de dependencias. 
4. En algunos casos, los proyectos que crearon las dependencias se abandonan o no se mantienen adecuadamente. Las aplicaciones que utilizan esas dependencias se rompen o introducen problemas de seguridad que no son fáciles de solucionar cuando el código no es suyo.

¿Podemos resolver el problema fácilmente? Bueno no. Podemos mitigar el problema como se ha hecho en el pasado, usando numeración de versiones con “versiones semánticas” en los paquetes y luego usando un sistema de gestión de paquetes que pueda resolver dependencias apropiadamente. Se pone mucho esfuerzo en los paquetes que forman parte de una distribución para hacerlos compatibles con todos los demás, incluso haciendo backport de parches de una versión a otra.

Una mejor manera

Podríamos reducir el problema de dependencia reduciendo la cantidad de paquetes incluidos en una distribución, haciendo necesario descargar las aplicaciones en otro lugar y haciendo que el desarrollador sea responsable de actualizarlas (como lo hace MacOS). Dentro de unos años, si el desarrollador no está activo, no tendrás suerte. Pero eso también reduce el valor de la distribución.

Con contenedores, ha aparecido una nueva solución. Cuando usamos contenedores, las dependencias se pueden empaquetar con la propia aplicación. Si ya no necesita que las bibliotecas y dependencias sean compatibles con todas las demás aplicaciones, es mucho más fácil llegar a un árbol de dependencias adecuado, siempre que cada aplicación pueda incluir su propia versión de esas dependencias.

Sin embargo, usar contenedores a escala no es gratis; Hoy en día, la mayoría de las empresas utilizan Kubernetes, lo que requiere nuevas abstracciones para implementar aplicaciones. Kubernetes es complejo y, para muchas aplicaciones que no funcionan con microservicios, diseñado para ser escalable puede resultar excesivo. Pero, ¿qué pasaría si pudiéramos empaquetar y entregar las aplicaciones en contenedores en lugar de como se hace en Linux tradicional?

1. Podríamos reducir la capa de abstracción de hardware al mínimo. Mantenga las certificaciones y la estabilidad de la capa central, asegurándose de que su hardware esté funcionando.
2. Luego, podríamos entregar las aplicaciones y bibliotecas como contenedores. Al reducir las dependencias, podríamos tener diferentes versiones de las dependencias instaladas dentro del contenedor sin requisitos conflictivos. Reducir el problema a un tamaño manejable.
3. Por lo tanto, podríamos ofrecer diferentes versiones de las aplicaciones, probándolas y admitiéndolas solo con la versión requerida de las dependencias. Se acabó el infierno de dependencia y la necesidad muy limitada de backporting, lo que hace que todo sea más fácil de entregar.
4. Podríamos asegurarnos de que el sistema operativo sea tan fácil de administrar que no necesite pensar en ello cuando trabaje en su aplicación mediante la automatización y la autorreparación. 

Un nuevo ciclo de vida

El nuevo sistema operativo presentaría distintos ciclos de vida para el núcleo y las aplicaciones, lo que presentaría oportunidades para la optimización estratégica:

Agilidad mejorada de los componentes principales:

• Liberar los componentes centrales del sistema operativo de las dependencias con las aplicaciones permite actualizaciones frecuentes de los componentes y bibliotecas de interfaz de hardware. Lograr un equilibrio entre los plazos de certificación — que se extienden hasta 18 meses — y la necesidad de integrar nuevas funcionalidades de hardware de diversas arquitecturas (ARM, Intel, AMP, IBM , etc.) se vuelve crucial. Aun así, es más fácil ofrecer una solución a un coste razonable.
• Es imperativo que el sistema operativo garantice transiciones perfectas con cada actualización preservando la compatibilidad de API para las cargas de trabajo. Ahora es más fácil y rápido, ya que no existe una dependencia estricta de los componentes del sistema operativo.

Soporte de aplicaciones flexible:

• Desacoplar el contenido del sistema operativo le permite tener un soporte diferente para diferentes componentes. Puede haber más de una versión disponible simultáneamente. Puede usar la última versión, incluso la beta, si la necesita para el desarrollo con soporte limitado y, al mismo tiempo, admite versiones antiguas de su aplicación en una versión más estable para producción.

Opciones de soporte extendido a largo plazo:

• Más allá del soporte a largo plazo ofrecido por la comunidad, el proveedor del sistema operativo puede ampliar el soporte para componentes críticos durante el tiempo que sea necesario. Esto garantiza que las aplicaciones que requieren una estabilidad prolongada tengan una plataforma confiable, lo que refuerza la estabilidad de los sistemas cruciales pero no la impone en todos los componentes y bibliotecas al mismo tiempo.

Soluciones compartimentadas:

• La naturaleza modular del sistema operativo permite la creación de soluciones adaptadas a casos de uso específicos. Ya sea introduciendo un nuevo hipervisor o integrando componentes de vanguardia para cargas de trabajo confidenciales de IA en un nuevo chipset, esta compartimentación permite una personalización precisa para cumplir con sus requisitos únicos.
• Abordar casos de uso específicos se vuelve más ágil y eficiente, con el sistema operativo sirviendo como una base versátil adaptable a las demandas tecnológicas en evolución.

Entonces, ¿está disponible?

Absolutamente; la solución es la Plataforma Linux Adaptable desarrollada por SUSE, una nueva plataforma y base de código que ha estado en desarrollo durante años y se está preparando para la producción mientras hablamos.

Algunas piezas necesarias están disponibles hoy y han estado en producción durante años (como SLE Micro), pero SUSE ha ido un paso más allá. Solución integral para el centro de datos. Esta solución integral incluye el sistema operativo y las herramientas esenciales para construir y ejecutar contenedores certificados dentro del marco del sistema operativo.

Diseñado para funcionar como un sistema operativo discreto, está diseñado para ser manejable, fácil de usar e implementable sin esfuerzo. Esta nueva plataforma integra a la perfección componentes familiares del servidor Linux que usted espera tener disponibles, como el demonio dhcpd o el servidor http Apache. Nuestra misión es ofrecer una plataforma que incorpore soporte y agilidad simultáneamente. Nuestro objetivo es entregarle los componentes que necesita. Permitiéndole personalizar su versión. De esta manera, podrá concentrarse en la generación de ingresos mientras confía a SUSE la seguridad y el soporte del sistema operativo subyacente.

No dude en descargar la solución hoy y embarcarse en su viaje con ella. Lo alentamos a que brinde sus comentarios e interactúe con nosotros (soy el gerente de producto). Exploremos en colaboración cómo podemos mejorar aún más esta plataforma — la forma de código abierto. Sus conocimientos y experiencias son invaluables para dar forma a un producto que realmente se alinee con sus necesidades.

ALP: Plataforma Linux adaptable

La plataforma Linux adaptable de SUSE permite a los desarrolladores centrarse en las cargas de trabajo mientras se mantienen independientes del hardware y…susealp.io

https://adaptablelinuxplatform.io/

Referencias

Sistemas operativos modernos. Andrew S. Tanenbaum y otros.

https://www.pearson.com/en-us/subject-catalog/p/modern-operating-systems/P200000003311/9780133591620?tab=title-overview

Políticas de soporte de SUSE

Políticas de soporte al ciclo de vida del producto | SUSE

Elija un producto de la lista siguiente para leer más sobre sus políticas de soporte exclusivas.www.suse.com

TSA Net

TSANet tiene más de 25 años de experiencia creando plataformas colaborativas para cientos de proveedores...tsanet.org