Una Historia de los empaquetadores

A dónde nos puede llevar MSIX

Creemos que el enfoque tradicional para las aplicaciones ha sido un viaje "suficientemente bueno", pero a medida que nos enfocamos en el escritorio moderno necesita haber una ruptura limpia con el pasado y los instaladores de software tradicionales deben irse a favor de los formatos modernos como MSIX para simplificar el despliegue de software, aumentar la seguridad y aislar las aplicaciones del sistema operativo.

Con MSIX, las aplicaciones tradicionales de Windows también pueden aprovechar las nuevas API de Windows 10 para ofrece nuevas formas de comunicación, como el BOT Framework, los equipos, el chat de Skype y la voz, junto con las notificaciones del Centro de actividades.

Por supuesto, el objetivo a largo plazo es la modernización de aplicaciones, pero hemos aprendido a reconocer que algunas aplicaciones son como zombis y son increíblemente difíciles de matar pero no imposible.

MSIX puede ayudar eficazmente a las empresas a modernizar su inventario de software, entonces son buenas noticias para todos.

En nuestra experiencia, las aplicaciones heredadas se están convirtiendo cada vez más en un riesgo para las empresas a medida que las cargas de trabajo informáticas se trasladan a las arquitecturas de nube y la industria se traslada al software como un servicio. 

Esto se remonta a la visión de SoftGrid, donde las aplicaciones se trataban como una utilidad que usted activaba y desactivaba. Ese objetivo no es menos válido hoy en día.

MSIX requiere de especialista que entiendan como personalizar los programas y su gran ventaja los contenedores.

Los contenedores son una capa intermedia que encaja entre un sistema operativo "virtualizado" y una aplicación en la que el contenedor garantiza un aislamiento estricto entre la aplicación y el sistema operativo. 

Es importante no confundir la virtualización de aplicaciones con contenedores de aplicaciones donde la primera es principalmente una tecnología de redireccionamiento, mientras que la segunda mantiene la aplicación aislada del sistema operativo y de otras aplicaciones.

En este post, te guiaremos a través de la historia de la implementación de aplicaciones de Windows y le explicarémos por qué el formato MSIX tiene el potencial de unificar verdaderamente cómo se empaquetan e implementan las aplicaciones de Windows.


Al principio era desordenado

Un desarrollador de software escribiría una aplicación para ejecutarse en Windows y luego compilaría esa aplicación, pero el propio instalador de software era un paso separado que implicaba un esfuerzo de desarrollo separado. 

Esencialmente era el salvaje oeste de la instalación de software, y la mayoría de los proveedores de software tenían una visión estrecha cuando se trataba de los requisitos de las aplicaciones. 

Todo lo que les importaba era algo que pudiera instalar su aplicación, y las mejores prácticas eran en su mayoría un arte negro que muchos ignoraban por ignorancia.

Las primeras generaciones de instaladores de aplicaciones tenían una lógica limitada y no estaban muy bien escritas, lo que resultó en aplicaciones mal instaladas.

 Los instaladores sobrescriben ciegamente los archivos compartidos del sistema (por ejemplo, las DLL) sin comprobar las versiones de los archivos.

El resultado neto fue que los instaladores de aplicaciones sobrescribían continuamente los archivos de sistema compartidos con versiones anteriores (es decir, la versión del archivo con el que estaban empaquetados) y causaban errores de ejecución con otras aplicaciones. 

Este problema se conoció como "DLL Hell", y se convirtió en parte integrante de la instalación de aplicaciones en Windows en los primeros días.

La necesidad de instaladores más sofisticados impulsó el surgimiento del reempaquetado de aplicaciones donde pudimos llevar a los instaladores de aplicaciones suministrados por el proveedor y hacerlos desplegables a través de nuevas tecnologías de gestión como Systems Management Server (SMS). 

El punto que vale la pena destacar es que hasta la llegada de los instaladores de scripts desplegables, se requería físicamente que un técnico o usuario instalara una aplicación en el equipo del usuario.

Con los instaladores de scripts, finalmente pudimos realizar una instalación silenciosa de la aplicación a través de SMS sin interacción humana.

Se crearon herramientas de reempaquetado para supervisar y registrar los cambios realizados en el sistema por los instaladores de software y generar un instalador automatizado para su despliegue masivo.

Los que trabajamos en el reempaquetado de herramientas esperabamos que al monitorear los cambios en el sistema, pudieramos eliminar el ciclo de DLL Hell introducido por el proceso de instalación. Tan inteligente como parecía, la tecnología tenía sus defectos.

Por el lado positivo, las herramientas de reempaquetado eran buenas para capturar el estado de la configuración del sistema cuando se instalaron las aplicaciones.

Desafortunadamente, dependiendo del enfoque de reempaquetado que empleara un desarrollador (máquina limpia vs. imagen corporativa de Windows), la utilidad de captura sólo estaba haciendo una suposición basada en los cambios de sistema de los que tenía conocimiento. 

Aquellos de nosotros que fuimos los primeros en adoptar el sistema operativo, comenzamos a reempaquetarlo en contra de la estructura corporativa del sistema operativo. 

Muy rápidamente, empezamos a notar que los cambios no triviales en la construcción corporativa (es decir, la eliminación de una aplicación) provocaron que muchos de los instaladores de aplicaciones reempaquetadas no pudieran compensar la falta de archivos y entradas de registro que habían existido. 

La situación siguió empeorando porque parte de la lógica de los instaladores de los vendedores no pudo ser capturada por las herramientas de reenvasado. 

Por ejemplo, el mecanismo de captura no era capaz de grabar llamadas o acciones de la API más avanzadas que copiar archivos o establecer valores de registro en el sistema. 

El mayor desafío para quienes creaban instaladores de software reenvasados era cómo identificar los cambios relevantes en el sistema.

La mayoría de las veces, tenían una experiencia limitada en el mundo real y les costaba discernir si lo que se capturaba era una parte necesaria de la instalación del software o si se trataba de ruido de fondo del sistema operativo o de la actividad de otra aplicación.

Como ya sabemos, cada parche, cada nueva versión de Windows y muchas aplicaciones de terceros cambiaron el equipo del usuario, a veces de forma sutil y a veces drástica.

Con el tiempo, la complejidad de instalar aplicaciones en este entorno eclipsó las capacidades de los instaladores e inevitablemente llevó a la inestabilidad del sistema operativo, que se volvió tan omnipresente que se ganó el nombre de Winrot.

La evolución de los instaladores silenciosos condujo a avances que redujeron el tiempo de inactividad del usuario y la cantidad de esfuerzo necesario para desplegar el software en grandes entornos, sin embargo, el riesgo de causar daños seguía existiendo. En consecuencia, los administradores del sistema necesitaban un montón de experiencia y habilidad para asegurarse de que no crearan un desastre en el entorno.

La introducción del instalador de Windows.

El formato MSI era desarrollar un marco estandarizado en torno a la lógica del instalador de software que pudiera negociar mejor los cambios que el instalador necesitaba hacer en el sistema operativo. 

El formato fue utilizado por desarrolladores de software y reempaquetadores de aplicaciones, sin embargo, en lugar de una instalación basada en scripts, el autor (dependiendo de su rol) tuvo que entender la base de datos relacional sobre la que se construyó MSI.

Una de las nuevas características introducidas por el formato MSI era la posibilidad de modificar un instalador sin tener que volver a empaquetarlo desplegando un archivo de transformación con él.

Normalmente, los archivos de transformación se utilizaban para aplicar ajustes de configuración locales (por ejemplo, para desactivar la función de actualización automática de un producto de software).

Microsoft creía que el formato MSI sería más fácil de usar porque pensaban que una gama más amplia de partes interesadas podría analizar el paquete de instalación del software y entender lo que el instalador necesitaba inspeccionando la base de datos subyacente. 

Mientras que una base de datos relacional es ciertamente más estructurada que un archivo de script, en la práctica, es más trabajo obtener la información que necesita porque necesita usar herramientas personalizadas para obtener la información que necesita, y es más difícil interpretar el resultado de la instalación ya que la mayoría de los cambios necesitan ser negociados por el servicio de Windows Installer que es parte del sistema operativo. 

No es de extrañar que se necesitaran herramientas más especializadas para alojar estos instaladores MSI, por lo que Windows Installer implementó acciones personalizadas.

Las acciones personalizadas permitieron a los desarrolladores de software y a los reempaquetadores de aplicaciones eludir la mayoría de las limitaciones impuestas por Windows Installer para que pudieran ejecutar scripts y EXE.

Lo ideal sería que no se necesitaran acciones personalizadas, pero no todo lo que necesita una aplicación se puede instalar de forma nativa mediante el servicio Windows Installer. 

La desventaja de la flexibilidad para eludir las limitaciones de los instaladores permitía a las personas perezosas o incultas romper todo tipo de buenas prácticas cuando se trataba de la instalación de software.

El equipo que está detrás del formato MSI pensó que gradualmente eliminaría DLL Hell y Winrot y, por extensión, mejoraría significativamente la estabilidad tanto del sistema operativo como de las aplicaciones instaladas en la máquina del usuario.

Lo que Microsoft no tuvo en cuenta fue el alcance de desarrollar un ecosistema de herramientas de empaquetado en torno a la tecnología MSI, ni tampoco quiso crear herramientas para este nuevo estándar. 

Tenían la intención de confiar en los proveedores de software para crear herramientas de creación de paquetes para los desarrolladores y herramientas de reempaquetado para el personal de TI.

Durante un tiempo, Windows Installer fue la solución ideal para instalar aplicaciones en máquinas Windows. A medida que la industria evolucionó, la necesidad de tratar con los remanentes de DLL Hell y WinROT llevó al surgimiento de la visualización de aplicaciones.

El reempaquetado de las aplicaciones se hace virtual

En el contexto de la virtualización de aplicaciones, las aplicaciones se consideran "virtuales" cuando no se instalan mediante métodos tradicionales y no tienen acceso directo al sistema de archivos o al registro del sistema. 

En cambio, las aplicaciones virtualizadas acceden a un sistema de archivos y a un registro sintético, o bien la capa de virtualización redirige los datos de la aplicación a ubicaciones alternativas en el sistema de archivos y en el registro. 

La virtualización de aplicaciones suele tener aislamiento COM y un sistema de archivos virtuales para evitar problemas como DLL Hell, pero funciona tan bien que a menudo se pueden ejecutar varias versiones de la misma aplicación sin problemas.

En el caso de los hosts de sesión de escritorio remoto, esto era muy importante porque los entornos más complejos podían simplificarse permitiendo que coexistieran más aplicaciones en el mismo servidor. Las aplicaciones virtuales eliminaron los grupos o silos de servidores que se crearon para conjuntos de aplicaciones específicos y también redujeron la incertidumbre de añadir una nueva aplicación al entorno.

Dado que los hosts de sesión de escritorio remoto son máquinas compartidas, se centró la atención en asegurarse de que fueran estables (es decir, que tuvieran el menor número de errores posible), pero que tampoco tuvieran problemas de rendimiento que el usuario final pudiera notar.

Microsoft reconoció el valor que las empresas estaban obteniendo de la virtualización de aplicaciones y decidió adquirir SoftGrid en 2006 porque era la mejor tecnología de virtualización de aplicaciones del mercado.

La tecnología tenía una gran base de usuarios con bastante conocimiento documentado para hacer que las aplicaciones funcionaran con la tecnología. 

Una vez que Microsoft comenzó a introducir algunos de sus estándares de seguridad en el producto y actualizó muchas de las características, se cambió su nombre a Microsoft Application Virtualization o App-V.

En aquel entonces era obvio que la virtualización de aplicaciones era una tecnología compleja y difícil de utilizar para los ingenieros de Microsoft, y aunque era doloroso de observar, Microsoft necesitaba separarse de algunas de las opciones de diseño que SoftGrid traía consigo.

A pesar de haber comenzado con una base sólida, el App-V 5 fue casi una reescritura completa del producto, lo que no es de extrañar, ya que introdujo errores y una curva de aprendizaje pronunciada que necesitaba ser corregida.

El App-V 5 se basa en las capacidades nativas del sistema operativo para redirigir los archivos y los datos del registro a otras partes del registro y del sistema de archivos, lo que elimina la necesidad de subsistemas sintéticos.

Al final, la App-V 5 resultó ser una tecnología sólida, y los reempaquetadores de aplicaciones fueron capaces de manejar la mayoría de los casos de uso. 

Dicho esto, seguimos trabajando con clientes que encuentran que entre el 5% y el 20% de su inventario de aplicaciones no funcionan correctamente en entornos virtualizados, lo que significa que la búsqueda del instalador perfecto aún estába lejos de haber terminado.

Por otro lado, los métodos, tecnologías y mejores prácticas que los desarrolladores de software utilizaban para escribir su software debían evolucionar para mantenerse al día con el nuevo hardware, los nuevos sistemas operativos (y versiones) y los dispositivos que sus clientes estaban empezando a utilizar en el trabajo y de forma remota

 Si controlas el código controlas el mundo

Microsoft entendió que las deficiencias de la arquitectura de la aplicación Win32 significaban que no era capaz de evolucionar para satisfacer las demandas de la informática moderna o la visión de Microsoft para el futuro.

Esta necesidad de modernización era especialmente cierta en el caso de las aplicaciones que utilizan arquitecturas de nube en las que el equipo del usuario puede no residir nunca en la red corporativa. 

Office 365 se aprovechó de App-V al integrarla en su versión de Office para ejecutar, lo que le dio a Microsoft mucha experiencia en la creación y el mantenimiento de una compleja aplicación virtual.

Debido al volumen de su base de clientes, Microsoft estaba empezando a revolucionar la forma en que las empresas abordaban el empaquetado y la implementación de aplicaciones. 

Si se añade el floreciente ecosistema de dispositivos que los usuarios comenzaron a utilizar instintivamente en todo tipo de ubicaciones, de repente, los desarrolladores de software se vieron enfrentados a nuevos requisitos para adaptarse a sus aplicaciones. 

Se necesitaba una nueva forma de construir e instalar aplicaciones fáciles de usar que pudieran ajustarse automáticamente a una amplia variedad de factores de forma de los dispositivos. 

Microsoft acortó distancias con la Plataforma Universal de Windows (UWP) y un concepto de "tienda" para el consumo de aplicaciones Windows que imitaba la forma en que se instalaban las aplicaciones en los dispositivos móviles. 

También necesitaban aplicaciones que fueran más autónomas porque Windows ya se estaba dirigiendo por el camino de comportarse más como Android o iOS, donde las aplicaciones se instalan y eliminan de forma fácil y limpia sin afectar a la salud del sistema operativo.

El formato de aplicación UWP es muy estricto, y no existen en él equivalentes significativos de la API de Win32. 

Este hecho plantea un problema serio y costoso para los desarrolladores de Win32 porque tienen que reescribir partes significativas de su base de código para aprovechar UWP e instalar su aplicación a través de la tienda de Windows. 

En algunos casos, las características tuvieron que ser eliminadas porque no había manera de implementar la solución con el conjunto limitado de APIs en el nuevo marco de trabajo de UWP.

Aquellos pocos afortunados que fueron capaces de girar hacia UWP notaron dos beneficios clave:

1) Las aplicaciones UWP no necesitan ser empaquetadas, lo que elimina efectivamente la carga de trabajo necesaria para prepararlas para su instalación automatizada en la máquina del usuario.

 2) La instalación y personalización autoiniciada de una aplicación a través de Windows Store casi elimina la necesidad de que un técnico de TI intervenga en nombre del usuario, ya que el usuario ya tiene experiencia con una tienda de aplicaciones al utilizar su smartphone.

  

La tienda de Windows también ofrece un importante ahorro de costes a sus clientes, ya que Microsoft alberga la infraestructura de despliegue de aplicaciones necesaria para almacenar aplicaciones en la nube.

Esto significa que las empresas ya no necesitan mantener una infraestructura de implementación de software separada con servidores en las instalaciones.

Los dispositivos Windows pueden descargar la aplicación directamente desde la Tienda de Windows en la nube. 

La experiencia se puede administrar a través de Windows Store for Business, que permite a las organizaciones controlar las aplicaciones disponibles y realizar un seguimiento de su uso.

Algunos proveedores de software están legítimamente molestos con el modelo de Windows Store porque la división de 30/70 de Microsoft en cada venta es considerable para aplicaciones costosas - una barrera considerable no técnica para la adopción. 

Si prefiere desplegar sus aplicaciones manualmente o con herramientas de distribución electrónica de software estándar, esa sigue siendo una opción, ya que esta tecnología no es exclusiva de la tienda de Windows. 

Aunque Windows Store para consumidores ofrece una experiencia adecuada, Windows Store for Business sólo incluye un conjunto básico de características para administrar las aplicaciones de Windows Store, lo que es importante, ya que sigue careciendo de características empresariales como el acceso basado en roles. 

Por supuesto, si su organización no puede utilizar la nube para la entrega de aplicaciones, hay formas de entregar aplicaciones UWP utilizando tecnologías de distribución de software más tradicionales. 

Dado el elevado coste de entrada, la industria se mostró reacia a migrar las aplicaciones a UWP. Como resultado, Microsoft necesitaba reducir la barrera de entrada para las aplicaciones Win32 y comenzó a trabajar en Desktop Bridges (nombre en clave Project Centennial) para soportar tanto aplicaciones Win32 como UWP. 

Desktop Bridges aflojó el nudo en la API de UWP (un paso en la dirección correcta), pero requería acceso al código fuente para que la aplicación funcionara. 

Esto significaba que Desktop Bridges sólo era útil para los desarrolladores de aplicaciones, ya que las aplicaciones rara vez tenían éxito cuando se reenvasaban utilizando esta tecnología. Había herramientas de reempaquetado de UWP, pero estaban dirigidas a desarrolladores que podían modificar la aplicación para superar los problemas.

Como resultado, la adopción de formatos de aplicación modernos estuvo cerca de resolver los problemas heredados de las aplicaciones Win32. Sin embargo, la compatibilidad de las aplicaciones y el hecho de que las aplicaciones no estuvieran lo suficientemente aisladas fueron áreas en las que UWP se quedó corto. 

En nuestra opinión, Microsoft necesitaba un camino para introducir más aplicaciones heredadas en la tienda para hacer de la migración a los formatos de aplicación modernos una historia de éxito y, lo que es más importante, las tecnologías como S Mode para Windows 10, donde sólo se pueden ejecutar aplicaciones modernas, creaban una necesidad más técnica para completar la visión moderna del escritorio de Windows.

 

Poner una X y todo sale bien

Esto nos lleva al anuncio de Microsoft de MSIX y a la esperanza de un formato de empaquetado unificado que permita a todos ejecutar aplicaciones en Windows 10. 

Puede que pienses que Microsoft acaba de refactorizar su formato de paquete MSI y le ha añadido una "X" para que suene a la moda como Apple, pero MSIX no tiene nada que ver con el formato MSI. 

Tampoco tiene nada que ver con MSI-X, que es la interrupción de señalización de mensajes compatible con PCI V3.0. ¿Confundido?

MSIX es genuinamente diferente de los intentos anteriores de instalación de tecnologías de software porque es una tecnología de contenedor por diseño que se utiliza con aplicaciones de usuario final. 

La segunda razón es que la tecnología es útil tanto para los desarrolladores como para los reempaquetadores.

La industria está trabajando para reducir el reempaquetado, sin embargo, la migración de las aplicaciones existentes a una tecnología de contenedores es un objetivo enorme e importante para lograr la visión de Microsoft. 

Windows 10 hace uso de contenedores desde aplicaciones hasta el sistema operativo. Los contenedores son una excelente manera de entregar rápidamente entornos de aplicaciones aislados a diferentes sistemas. Microsoft también utiliza contenedores para una amplia gama de servicios, principalmente dentro de la nueva arquitectura de seguridad construida sobre Hyper-V. 

Los contenedores, por otro lado, son análogos a la virtualización de aplicaciones, donde el estado de la aplicación se mantiene dentro del contenedor, independientemente de la máquina a la que se entregue la aplicación. 

Puedes usar MSIX para entregar aplicaciones Win32 a través de la tienda de Windows. Esto ayuda a mejorar la historia de la gestión moderna para Windows 10. 

El detractor más notable es la relación entre Windows 10 e Intune, ya que las capacidades de gestión de dispositivos móviles de Intune no son muy compatibles con los instaladores de software heredado. Idealmente, la tienda de Windows se utilizará para entregar aplicaciones, pero sólo se permiten los formatos de aplicación modernos en la tienda.

Aparte de los consumidores tradicionales de aplicaciones Win32, MSIX abre la puerta para obtener más aplicaciones en otros dispositivos Windows como Xbox y el reino de la realidad aumentada, lo que ayuda aún más a toda la historia de Windows Store.

Se menciona el soporte para Linux, OSX y Android, lo que significa que se están desarrollando elementos multiplataforma para MSIX. Como mínimo, el formato del paquete no es exclusivo de Windows.

   

 

A dónde nos lleva MSIX

Creemos que el enfoque tradicional para las aplicaciones ha sido un viaje "suficientemente bueno", pero a medida que nos enfocamos en el escritorio moderno necesitaba haber una ruptura limpia con el pasado y los instaladores de software tradicionales deben irse a favor de los formatos modernos como MSIX para simplificar el despliegue de software, aumentar la seguridad y aislar las aplicaciones del sistema operativo.