Hace unos años, gracias al iPhone, se hizo más conocido el término "obsolescencia programada". Wikipedia lo define como "una política de planificación o diseño de un producto con un límite artificial del tiempo de vida, para que quede obsoleto después de un cierto período". Pero, ¿qué es la obsolescencia no programada?
Se refiere a aquellos que fueron alcanzados por los límites de vida de los productos sin tener sustitutos. ¿Es posible manejarlo en la industria en que estamos?
Cómo manejar la obsolescencia programada
En general, un servicio no debe estar más de dos años sin actualizaciones del sistema operativo. Si miramos lo que hacen los principales proveedores de nube, podemos descubrir otras pistas. Por ejemplo, Digital Ocean, Huawei y Google sólo mantienen las últimas dos versiones de un sistema operativo. Es decir, no pueden levantarse sistemas legacy en dichos proveedores. Adicionalmente a la política de dos años de caducidad, existen tecnologías y prácticas que permiten a estas compañías lidiar con el cambio.
Actualizaciones de sistemas operativos
Las actualizaciones de seguridad corresponden a parches y mejoras realizadas a distintos componentes del sistema, las cuales son publicadas tanto en los repositorios nativos del sistema operativo (SO), como en los propios del desarrollador. Estas actualizaciones en la mayoría de los casos son seguras, ya que no suponen cambios drásticos en los paquetes. Sin embargo, existen casos puntuales en los que puede haber fallos en los servicios o modificaciones a las funciones que utiliza el código web. Estos fallos son difíciles de prever, o incluso de detectar en algunos casos.
Cuando esto ocurre, la vuelta atrás no es estándar y dependerá en gran medida de qué tan desactualizada se encontraba la máquina, o bien, si se cuenta con respaldos en el caso de las máquinas virtuales. Es posible que existan casos donde no se pueda volver atrás, si los repositorios no cuentan con la versión de software previamente instalada, o no hay respaldos como es el caso de los servidores físicos.
Facilitando el cambio y las actualizaciones
Los contenedores han ganado popularidad, especialmente Docker, al facilitar las actualizaciones. El contenedor es una unidad de software que empaqueta el código y sus dependencias para correr aplicaciones rápidamente y en forma confiable desde un servidor a otro. El contenedor podría verse
como un proceso aislado dentro del sistema operativo.
Un contenedor Docker es una imagen liviana, autónoma y que incluye todo el software necesario para hacer funcionar una aplicación. El contenedor aísla el software de su ambiente y asegura que funcione de la misma forma, ya sea en Windows o Linux o entre un ambiente de desarrollo y uno productivo.
Docker vs máquina virtual (VPS)
Una máquina virtual es una emulación de un computador que entrega las mismas prestaciones de un servidor. Tiene CPU, RAM, disco y sistema operativo exclusivos. Para hacer funcionar una máquina virtual, se requiere de un software de base o virtualizador, como Proxmox, VMware o Hyper-V de Microsoft, entre otros. Al hacer una comparación entre VPS y Docker, este último se ha impuesto debido a sus ventajas: es más liviano que una VPS, requiere menos recursos, menos códigos a transferir, los respaldos son más rápidos, permite acelerar la puesta en producción, simplifica los cambios entre plataformas o proveedores de cloud, y como gran beneficio, reduce y facilita las actualizaciones de seguridad.
La cultura organizacional
Pareciera que la solución es sólo la adopción de nueva tecnología, pero la respuesta es más compleja: es cultural, organizacional y de estructuración del trabajo. Las organizaciones exitosas se caracterizanpor una orientación al rendimiento, con alta colaboración, donde los riesgos son compartidos entre todos.
Los métodos ágiles y Lean son una constante en las empresas, y dentro de los equipos de desarrollo, uno de los favoritos es SCRUM. Estos métodos evitan el cambio de contextos (porque saltar de un proyecto a otro puede introducir errores) y reducen los ciclos de entrega, resolviendo errores muy tempranamente, evitando que se descubran en etapas tardías del proyecto. Si el software y las puestas en producción siguen los antiguos patrones, obviamente esto no funcionará.
Para resolver esos obstáculos aparece el uso de contenedores Docker y las técnicas de entrega contínua (CI/CD) con automatización de procesos, análisis de resultados, el uso de arquitecturas inmutables (que no sufren alteraciones y se van reemplazando) y finalmente la puesta en producción (deployment) con métodos como Blue/Green o Canary Deployments que reducen el riesgo al lanzar el servicio.
El corazón del cambio
Para implementar los cambios mencionados, debe observarse la organización como un proyecto de software con metodología ágil: saber qué se quiere cambiar y hacer los cambios, medir, controlar y refinar. Red Hat recomienda evitar roadmaps prolongados, trabajar en forma incremental, ciclos de feedback frecuentes, automatizar (pruebas y "deployments") y desarrollar nuevas habilidades.
¿Cómo se relaciona con la seguridad? La primera recomendación de los expertos es usar software actualizado, para evitar ataques. Usando la tecnología de contenedores (actualizada constantemente), el desacople de las apps y los datos, la automatización y los mecanismos de puesta en producción (y vuelta atrás), permiten seguir el ritmo de los cambios de una forma armónica y controlada, sin los habituales traumas de los procesos y tecnologías del pasado, evitando que las plataformas sean alcanzadas por la obsolescencia en forma traumática.
