Repensar las versiones con soporte a largo plazo

Tradicionalmente, las versiones de sistemas operativos con soporte a largo plazo han sido el baluarte de los despliegues empresariales. Este es el modelo utilizado por IBM, Oracle, Microsoft, Suse y Red Hat, y ha sido el pensamiento convencional en torno a los sistemas operativos desde el comienzo de las ofertas de soporte hace muchas décadas.

En el pasado ha sido común que tanto las versiones de sistemas operativos para servidores como para escritorio siguieran este modelo, pero específicamente en el ámbito de Linux empezamos a ver cómo esto se sacudía, donde productos menos formales tenían la libertad de experimentar con versiones más rápidas, sin soporte o simplemente no estructuradas. En el espacio de los productos principales, openSuse, Fedora y Ubuntu ofrecían todos versiones con soporte a corto plazo u ofertas de lanzamiento rápido. En lugar de ciclos de versiones medidos en años y ciclos de soporte que se acercaban a una década, acortaron los ciclos de versiones a meses y el soporte a tan solo unos meses o, a lo sumo, unos pocos años.

En el espacio del escritorio, obtener nuevas funciones y aplicaciones antes, en lugar de centrarse principalmente en la estabilidad como era común en los servidores, a menudo tenía sentido y aportaba el beneficio añadido de que se podían probar nuevas tecnologías o enfoques en productos con ciclos de lanzamiento más rápidos antes de integrarlos en productos de servidor con soporte a largo plazo. Fedora, por ejemplo, es un campo de pruebas para tecnologías que, tras demostrar su valía, abrirán su camino hacia las versiones de Red Hat Enterprise Linux. Al usar Fedora, los usuarios finales obtienen funciones antes, llegan a conocer las tecnologías de RHEL más temprano y Red Hat puede probar los productos a gran escala antes de desplegarlos en servidores críticos.

Con el tiempo, la estabilidad de las versiones a corto plazo ha mejorado drásticamente y, cada vez más, estos sistemas se ven como opciones viables para sistemas de servidor. Estos sistemas obtienen mejoras, funciones y actualizaciones más nuevas antes, lo que a menudo se considera beneficioso.

Un beneficio importante de cualquier sistema operativo es su ecosistema de soporte, incluidos los paquetes y bibliotecas que se admiten y se proporcionan como parte del sistema operativo base. Con las versiones a largo plazo, a menudo vemos cómo paquetes críticos envejecen drásticamente a lo largo de la vida de la versión, lo que puede causar problemas de rendimiento, compatibilidad e incluso, en casos extremos, de seguridad. Esto, obviamente, obliga a los usuarios de sistemas operativos con versiones a largo plazo a elegir entre seguir conviviendo con las limitaciones de los componentes más antiguos o integrar ellos mismos componentes nuevos, lo que a menudo rompe el valor fundamental del producto con versión a largo plazo.

Dado que el objetivo de una versión a largo plazo es tener estabilidad y pruebas de integración, reemplazar componentes dentro del producto para “sortear” las limitaciones de una LTS significa que esos componentes no se están tratando de forma propia de una LTS y que las pruebas de integración por parte del proveedor lo más probable es que ya no se estén realizando, o si lo están, no en el mismo grado. En efecto, lo que ocurre es que esto se convierte en un producto con versión a corto plazo construido por uno mismo, pero con componentes centrales heredados y menos supervisión.

En realidad, en la mayoría de los aspectos, hacer esto es peor que ir directamente a un producto con versión a corto plazo. Usar un producto de lanzamiento a corto plazo o rápido permite al proveedor mantener las pruebas y la integración que se dan por supuestas, solo que con un ciclo de versiones y de soporte más rápido, de modo que se mantiene el valor general del concepto de versión a largo plazo y con todos los componentes del sistema operativo actualizados, en lugar de solo unos pocos. Esto permite una mayor estandarización, pruebas por parte de la industria y conocimiento e integración compartidos que con un modelo LTS parcial.

Quizá haya llegado el momento de repensar el valor del soporte a largo plazo para los sistemas operativos. Durante demasiado tiempo, al parecer, el valor de este enfoque simplemente se dio por supuesto y se siguió, y ciertamente tenía y tiene méritos; pero el mundo de los sistemas operativos ha cambiado desde que este enfoque se introdujo por primera vez. La necesidad de actualizaciones ha aumentado, mientras que el ritmo de cambio de elementos como los núcleos y las bibliotecas se ha ralentizado drásticamente. Servidores más potentes han desplazado la compatibilidad más arriba en la pila y, en lugar de escribir el software para un sistema operativo, a menudo se escribe para una versión específica de un lenguaje, un entorno de ejecución u otra capa de abstracción.

Los ciclos de versiones más cortos significan que los sistemas obtienen funciones, de arriba abajo, con más frecuencia. Las actualizaciones entre versiones “principales” son más pequeñas y de menor impacto. Los cambios derivados de las actualizaciones son más incrementales, lo que proporciona una curva de aprendizaje y adaptación más orgánica. Y lo más importante, la necesidad de reemplazar componentes del sistema cuidadosamente probados e integrados por versiones proporcionadas por terceros se vuelve, en la práctica, inaudita.

La estabilidad para los proveedores de software sigue siendo un valor de las versiones a largo plazo y hará que exista la necesidad de usar versiones a largo plazo durante mucho tiempo más. Pero para el administrador de sistemas, el valor de este enfoque parece estar disminuyendo y, en mi opinión personal, ha encontrado un punto de inflexión en los últimos años. Antes parecía esperado y normal esperar dos o tres años para que se actualizaran los paquetes, pero hoy esto resulta innecesariamente engorroso. Parece cada vez más común que los componentes de nivel superior se construyan con el requisito de componentes subyacentes más nuevos; la expectativa de que los sistemas operativos serán o bien más actuales o bien que partes del sistema operativo se actualizarán por separado del resto.

Una fuerte dependencia de las tecnologías de contenedorización puede revertir esta tendencia en algunos aspectos, pero de maneras que siempre reducen al mismo tiempo el valor de las versiones a largo plazo. La contenedorización reduce la necesidad de capacidades extensas en el sistema operativo base, lo que hace más fácil y eficaz actualizar con más frecuencia para mejorar el soporte del núcleo, del sistema de archivos, de los controladores y de los contenedores, mientras se dejan las bibliotecas y otras dependencias dentro de los contenedores, permitiendo que las aplicaciones que necesitan dependencias con soporte a largo plazo las satisfagan de esa manera y que las aplicaciones que pueden beneficiarse de componentes más nuevos se atiendan de esa forma.

Por supuesto, la virtualización ha desempeñado un papel en la reducción del valor de los modelos de soporte a largo plazo al hacer triviales la recuperación rápida y la duplicación de sistemas. La estabilidad que hemos necesitado que aborden las versiones con soporte a largo plazo queda parcialmente cubierta por la capa de virtualización; la abstracción del hardware mejora la estabilidad de los controladores de maneras muy importantes. En la misma línea, los modelos de soporte de estilo devops también reducen la necesidad de soporte a largo plazo y hacen que los ecosistemas de servidores sean más ágiles y flexibles. Las tendencias en los paradigmas de administración de sistemas tienden a favorecer sistemas operativos más modernos.

El tiempo dirá si las tendencias continúan en la dirección hacia la que se dirigen. En mi caso, este último año ha sido revelador y me ha llevado a migrar mis propias cargas de trabajo, tras una década de firme apoyo a productos con soporte a muy largo plazo, hacia productos de lanzamiento rápido, y debo decir que estoy muy contento con el cambio.