Elegir las versiones de software para el despliegue

Algo que veo discutir muy a menudo en los círculos de TI es “qué versión del software debería instalar”. Esto podría aplicarse a una base de datos, una aplicación, el firmware o, probablemente con mayor frecuencia, los sistemas operativos, y con el próximo fin del soporte de Windows XP el tema ha alcanzado un punto febril.

Hay efectivamente dos posturas en esta discusión. Una sostiene que siempre debe usarse el software más reciente y, presumiblemente, mejor. La otra cree que el software necesita madurar y adopta un enfoque de “esperar a ver qué pasa”, o incluso considera cada versión como un producto diferente y no como un continuo de desarrollo.

Ambos enfoques tienen sus méritos y ninguno debería existir por completo sin el otro. Actualizar el software a ciegas y sin criterio no es prudente, y evitar los parches y las actualizaciones sin motivo tampoco lo es. La consideración cuidadosa de los factores y la empatía hacia el proceso de desarrollo del software son importantes a tener en cuenta al tomar estas decisiones.

En primer lugar, hay dos escenarios completamente distintos a considerar. Uno es la actualización del software actual y existente. Se asume que el estado actual de las cosas está “funcionando”, con la posibilidad aceptada de que “funcionando” podría incluir una exposición de seguridad que se ha descubierto y que requiere actualización para poder cerrarse. El otro escenario es un nuevo despliegue en el que no hay nada en la actualidad y partimos de cero.

Empecemos por el segundo caso, ya que es mucho más fácil ofrecer orientación al respecto.

En el caso de los nuevos despliegues de software (o de nuevos sistemas operativos), utilice siempre la versión actual y más reciente del software, a menos que exista una limitación tecnológica claramente conocida que lo impida, como errores conocidos o incompatibilidades de software.

El software no es como otros tipos de productos, y mucho menos en el mundo actual de los lanzamientos de parches y actualizaciones en línea. Supongo que la mentalidad de que las versiones antiguas del software podrían ser preferibles a las actuales proviene de una combinación de los productos físicos (relojes, automóviles, vajillas, muebles, vino), donde un año o modelo concreto podría ser superior a un modelo más nuevo por diversas razones, y de los modos heredados de entrega de software, donde los productos de software terminados simplemente se “arrojaban por encima del muro” y el estado final era, sencillamente, el estado final, sin ninguna oportunidad razonable de actualizaciones, parches o correcciones. Ninguno de estos casos se aplica al software empresarial moderno (salvo las más raras excepciones).

El desarrollo de software es, a grandes rasgos, un continuo. Los procesos de desarrollo normales hacen que el nuevo software se construya sobre el software antiguo, ya sea directamente (creando actualizaciones de una base de código existente) o indirectamente (reconstruyéndolo a partir del conocimiento adquirido al haber construido una versión anterior del software). La idea es que cada versión posterior del software sea superior a la que la precede. Esto no está garantizado, por supuesto; existen conceptos como los errores de regresión y el simple mal desarrollo, pero en términos generales el software mejora con el tiempo – especialmente cuando hablamos de software de clase empresarial utilizado en las empresas y bajo desarrollo activo. El software nuevo no es solo la siguiente fase del software antiguo, sino que también representa, en casi todos los casos, el estado actual de los parches, las correcciones de errores, las actualizaciones y, cuando es necesario, los cambios de enfoque o de técnica. El software nuevo, proveniente de talleres de calidad, es casi exclusivamente mejor que el software antiguo. El software evoluciona y madura.

Más allá de la calidad del software en sí, está el concepto de invertir en el futuro. El software no es algo que pueda permanecer en la estantería para siempre. Necesita mantenerse, en cierta medida, actualizado o deja de funcionar porque la plataforma sobre la que se ejecuta cambia, sale a la luz algún nuevo artefacto, se descubren agujeros de seguridad o cambian las necesidades. Instalar software antiguo significa que hay una inversión en el pasado, una inversión en instalar, aprender, usar y dar soporte a tecnología antigua. Esto se denomina “deuda técnica”. Esta tecnología antigua podría durar años o incluso décadas, pero el software antiguo pierde valor con el tiempo y se vuelve cada vez más caro de mantener, tanto para los proveedores, si continúan dándole soporte, como para los usuarios finales, que tienen que mantenerlo.

El mismo concepto de deuda técnica se aplica a los proveedores de software en cuestión. Hay un coste muy elevado en crear software y, especialmente, en mantener múltiples versiones de ese software. Los proveedores de software tienen muchos incentivos para reducir el soporte de las versiones más antiguas y centrar los recursos en los lanzamientos de software actuales (esta es una de las principales razones por las que los despliegues SaaS son tan populares: el proveedor controla las versiones disponibles y puede eliminar las versiones heredadas mediante actualizaciones). Si los clientes requieren soporte para versiones antiguas, el coste debe absorberse en algún punto, y a menudo se absorbe tanto en el impacto monetario para todos los clientes como en una disminución del enfoque en el producto nuevo, ya que los equipos de desarrollo deben dividirse para dar soporte al parcheado de versiones antiguas además de desarrollar la nueva. Cuanto más esfuerzo deba dedicarse a las versiones antiguas, menos esfuerzo podrá dedicarse a las nuevas mejoras.

Dentro del marco de lo que ya he dicho, es importante hablar de la madurez del código. A menudo se menciona la madurez del código como una razón para desplegar “código antiguo”, pero creo que esto es una mala interpretación, por parte de TI, de los procesos de desarrollo de software. Si pensamos en una línea de código publicada, el hecho de que esté publicada y en uso no la hace realmente más madura. El código no cambia en la naturaleza, simplemente permanece ahí. Su madurez queda “bloqueada” el día en que se publica. Si se parchea, entonces sí, “maduraría” después de su publicación. Las versiones posteriores del mismo software, basadas en la misma base de código pero más actualizadas, son en verdad el código más “maduro”, ya que se han revisado, actualizado, probado, etc. en mayor grado que el primer lanzamiento del mismo código.

Esto es contraintuitivo respecto a, por ejemplo, un automóvil, donde cada lanzamiento es algo nuevo con nuevas oportunidades de problemas mecánicos y distintas preocupaciones de fiabilidad – donde esperar unos años te da la oportunidad de ver qué problemas de fiabilidad salen a la luz. El software no es así. Por tanto, el concepto de querer software más maduro te empujaría a desplegar lo “más nuevo y mejor” en lugar de lo “probado y confiable”.

Si pensamos en los números de versión del software más bien como edades, esto se hace evidente. Linux 3.1 es mucho más antiguo, en términos de maduración del software, que Linux 2.4. Tiene una década de desarrollo adicional.

Usemos un ejemplo del mundo real que es muy relevante hoy. Estás en una empresa a punto de instalar tu(s) primer(os) servidor(es). Windows Server 2012 R2 acaba de lanzarse. ¿Deberías instalar Windows Server 2008, 2008 R2 (2010), Server 2012 o Server 2012 R2 (finales de 2013)?

Para muchas empresas, esto suena como si estuviéramos hablando de entre dos y cuatro productos completamente diferentes, que probablemente tengan distintas razones para elegir cada uno. Esto, en términos generales, no es cierto. Cada versión más nueva es simplemente una mejora, actualización, parche y aumento de funcionalidades sobre la anterior. Cada una, a su vez, es más avanzada y madura que la que la precede. Cada nueva versión se beneficia del trabajo realizado en el lanzamiento original de su predecesora, así como de las correcciones de errores, los parches y las incorporaciones de funcionalidades realizados en el intervalo entre el lanzamiento original y el lanzamiento sucesor. Cada nuevo lanzamiento es, en realidad, un “lanzamiento menor” del anterior. Si observamos los números de revisión del kernel, en lugar de los nombres de marketing de los lanzamientos, podría tener más sentido.

Windows Server 2008 era Windows NT 6.0. Windows Server 2008 R2 era Windows NT 6.1, obviamente una revisión menor o incluso un “parche” del lanzamiento anterior. Windows Server 2012 era Windows NT 6.2 y nuestro actual Windows Server 2012 R2 es Windows NT 6.3. Si usáramos los números de revisión en lugar de los nombres de marketing, suena casi una locura instalar intencionadamente una versión antigua, menos madura, menos actualizada y menos parcheada. Queremos las últimas actualizaciones, las últimas correcciones de errores y que se hayan abordado los problemas de seguridad más recientes.

Para los nuevos despliegues de software, cuanto más nuevo sea el software instalado, mejor oportunidad de aprovechar las últimas funcionalidades y más tiempo antes de que la inevitable obsolescencia haga mella. Todo el software envejece, por lo que instalar software más nuevo brinda la mejor posibilidad de que ese software perdure durante el mayor tiempo posible. Proporciona la mejor flexibilidad para el futuro desconocido.

Seguir esta línea de pensamiento podría llevarnos a sentir que desplegar software preliminar o incluso en fase beta también tendría sentido. Y si bien podrían existir casos específicos en los que esto sí tenga sentido, como en “grupos de prueba” para evaluar el software antes de liberarlo a la empresa en general, por lo general no lo tiene. La naturaleza del software preliminar es que no cuenta con soporte y puede contener código que nunca lo tendrá. Usar dicho código de forma aislada puede ser beneficioso, pero para un uso general no se aconseja. Hay procesos importantes que se siguen entre los lanzamientos de vista previa o beta y los lanzamientos finales del código, sin importar el nivel de madurez en el que se encuentre el producto en su conjunto.

Eso nos lleva a la otra situación, aquella en la que estamos actualizando software existente. Esto, por supuesto, es un escenario completamente distinto a una instalación nueva, y hay muchos, muchos más factores involucrados.

Uno de los factores más importantes en la mayoría de las situaciones es el de las licencias. Actualizar el software con regularidad puede generar costes de licencia que deben tenerse en cuenta en la ecuación de beneficios y costes. Algunos productos, como la mayoría del software de código abierto, no tienen este coste y pueden actualizarse tan pronto como haya nuevas versiones disponibles.

El otro factor realmente importante en la actualización del software es un coste de esfuerzo humano para actualizar – a diferencia de una instalación nueva, donde el esfuerzo de la instalación es efectivamente equivalente entre el software antiguo y el nuevo. En realidad, el software nuevo tiende a ser más fácil de instalar que el antiguo, simplemente debido a las mejoras y los avances. Mantener una única versión del software durante una década significa que, durante ese tiempo, no se dedicaron recursos a procesos de actualización. Actualizar anualmente durante ese tiempo significa que se emplearon recursos diez veces para llevar a cabo actualizaciones independientes. Eso hace que la actualización sea mucho más difícil de justificar en términos de coste. Pero hay más que solo el esfuerzo del propio proceso de actualización; también está la capacitación continua necesaria para los usuarios finales, que se verán obligados a experimentar más cambios, con mayor frecuencia, a través de actualizaciones constantes.

Esto podría hacer que actualizar el software suene como algo negativo, pero no lo es. Es simplemente una ecuación en la que cada lado debe sopesarse. Las actualizaciones regulares a menudo implican cambios pequeños e incrementales en lugar de grandes saltos, lo que permite a los usuarios finales adaptarse de forma más natural. Las actualizaciones regulares hacen que los procesos de actualización sean a menudo más fáciles y predecibles. Las actualizaciones regulares hacen que la deuda técnica se gestione siempre, y que los beneficios de las versiones más nuevas, que pueden ser funcionalidades, eficiencias o mejoras de seguridad, estén disponibles antes, lo que permite aprovecharlos durante un período más prolongado.

Tomando lo que hemos aprendido de los dos escenarios anteriores, sin embargo, hay otra conclusión importante que extraer aquí. Una vez que se ha tomado la decisión de realizar una actualización, la pregunta suele ser “¿a qué versión actualizamos?”. En realidad, sin embargo, cada actualización que va más allá de un proceso de parcheado estándar es en verdad como una decisión de compra de “software nuevo” en miniatura, y la lógica de por qué “siempre” instalamos la versión más nueva disponible al hacer una instalación nueva también se aplica aquí. Así que, al realizar una actualización, casi siempre deberíamos actualizar tan lejos como podamos – idealmente a la versión actual.

Para aplicar de nuevo el ejemplo de Microsoft, podemos tomar una organización que tiene Windows XP desplegado hoy. La empresa decide invertir en un ciclo de actualización a una versión más nueva, no solo en el parcheado continuo. Hay varias versiones de la plataforma de escritorio de Windows que aún cuentan con soporte activo de Microsoft. Estas incluyen Windows Vista, Windows 7, Windows 8 y Windows 8.1. Actualizar a una de las versiones menos actuales resulta en menos tiempo antes del fin de la vida útil de esa versión, lo que aumenta el riesgo organizativo; usar versiones más antiguas significa una inversión continuada en tecnologías ya antiguas, lo que implica un aumento de la deuda técnica y un menor acceso a nuevas funcionalidades que podrían resultar beneficiosas una vez disponibles. En este ejemplo concreto, las versiones más nuevas también se consideran más seguras y requieren menos recursos de hardware.

Cada empresa necesita encontrar el equilibrio adecuado para ella en los ciclos de actualización del software existente. Cada empresa y cada paquete de software es diferente. El software empresarial como Microsoft Windows, Microsoft Office o una base de datos Oracle se ajustan muy bien a estos modelos. Los pequeños proyectos de software y aquellos que se acercan al ámbito a medida pueden tener un ciclo de lanzamiento más dinámico e impredecible, pero por lo general seguirán cumpliendo la mayoría de estas reglas. Considere aplicar empatía al proceso de desarrollo de software para comprender cómo usted y su proveedor de software pueden asociarse de la mejor manera para ofrecer el mayor valor a su organización, y combine eso con su necesidad de reducir la deuda técnica para aprovechar su inversión en software de la mejor manera posible para su organización.

Pero las reglas generales son relativamente sencillas:

Al desplegar software nuevo o al actualizar, apunte a la versión razonable más reciente del software. Aproveche cualquier oportunidad de despliegue para eliminar la deuda técnica en la mayor medida posible.

Cuando el software ya existe, sopese factores como el esfuerzo humano, los costes de licencia, la coherencia del entorno y las pruebas de compatibilidad frente a los beneficios en funcionalidades, rendimiento y deuda técnica.