Virtualización de aplicaciones y rendimiento: guía completa para exprimir tu infraestructura

Informatec Digital » Recursos » Virtualización de aplicaciones y rendimiento: guía completa para exprimir tu infraestructura

La virtualización, en términos sencillos, consiste en crear versiones virtuales de recursos físicos (servidores, almacenamiento, redes o aplicaciones) para ejecutar múltiples entornos sobre un mismo hardware. Esa capacidad de “trocear” un servidor físico en varias instancias lógicas es la base de la computación en la nube y de la mayoría de centros de datos modernos.

Una máquina virtual (VM) es un sistema aislado con su propia CPU virtual, memoria, almacenamiento y red, construido a partir de los recursos físicos de un host. Cada VM se comporta como si fuera un equipo independiente y se encapsula normalmente en uno o varios archivos, lo que facilita moverla, copiarla y restaurarla con relativa facilidad.

El componente que hace posible todo esto es el hipervisor o VMM (Virtual Machine Monitor). Su función es separar los recursos físicos (CPU, RAM, disco, red) del host y asignarlos a las distintas máquinas virtuales que los necesitan, controlando su uso y aislándolas entre sí para que un fallo en una VM no arrastre al resto del sistema.

Existen dos tipos principales de hipervisor. El tipo 1 (bare metal) se ejecuta directamente sobre el hardware del servidor y es habitual en centros de datos y nubes privadas. El tipo 2 se instala como una aplicación sobre un sistema operativo anfitrión (por ejemplo, un hipervisor de escritorio para ejecutar varias VMs en un portátil).

En el ecosistema Linux es especialmente relevante KVM (Kernel-based Virtual Machine), un hipervisor de tipo 1 integrado en el kernel que permite que las VMs se beneficien del rendimiento y las capacidades de Linux, con un control muy granular de CPU, memoria y dispositivos.

Qué es la virtualización de aplicaciones y cómo se diferencia de la de servidor

La virtualización de aplicaciones separa la aplicación de su sistema operativo de tal forma que el programa se ejecuta sin estar realmente instalado en el dispositivo del usuario. La aplicación “cree” que habla con el sistema operativo, pero en realidad lo hace con una capa intermedia (hipervisor de apps o tecnología de aislamiento) que redirige accesos a archivos, registro y otros recursos.

Lo habitual es que estas aplicaciones se ejecuten en un servidor central (en un CPD o en la nube) y se entreguen por red (LAN o Internet) al dispositivo del usuario. Para el usuario final, la aplicación parece nativa, pero en realidad está publicada o virtualizada en un entorno controlado.

Frente a la virtualización de servidor, que trabaja a nivel de sistema operativo completo, la virtualización de aplicaciones trabaja a nivel de programa individual: un Word, un CRM, un ERP, una herramienta de diseño… Esto facilita mucho la gestión, el aislamiento y las actualizaciones, pero introduce retos de rendimiento ligados a red, almacenamiento y perfil de usuario.

Beneficios de la virtualización de aplicaciones para usuarios, TI y negocio

Desde el punto de vista de los usuarios finales, la principal ventaja es la libertad. Pueden usar el dispositivo que prefieran (portátil de empresa, equipo personal, thin client, tablet) y acceder a las aplicaciones corporativas sin tener que preocuparse de instalar, actualizar o mantener nada. Para ellos, el cambio de dispositivo es casi transparente: inician sesión y tienen los accesos directos listos para trabajar.

Para los administradores de TI, la virtualización de aplicaciones es un alivio considerable. En lugar de desplegar y parchear software en cientos o miles de equipos, instalan y mantienen la aplicación en uno o pocos servidores y la publican para los usuarios autorizados. Así, la gestión se concentra en una ubicación central y es mucho más rápida la aplicación de parches, cambios de versión, configuración de seguridad y políticas.

Los desarrolladores también salen ganando. Pueden disponer de distintos entornos virtualizados en un mismo sistema para probar código en varias versiones de sistema operativo o combinaciones de software, sin tener que montar laboratorios físicos complejos. Además, el aislamiento que ofrece la capa de virtualización permite abrir archivos potencialmente corruptos o peligrosos sin comprometer el sistema anfitrión.

Para la organización en su conjunto, la virtualización de aplicaciones facilita iniciativas como el BYOD (Bring Your Own Device), reduce la necesidad de comprar dispositivos corporativos potentes, simplifica el soporte y acostumbra a traducirse en un ahorro notable en licencias duplicadas, horas de soporte y renovaciones de hardware adelantadas.

Un punto importante es el cumplimiento normativo. Al no residir los datos sensibles en el dispositivo del usuario (sino en el centro de datos o la nube), es más sencillo cumplir con regulaciones como HIPAA o PCI-DSS, ya que se reduce la superficie de exposición y se centraliza el control de acceso y auditoría.

Impacto de la virtualización en el rendimiento: CPU, RAM, disco y red

La virtualización introduce siempre una cierta sobrecarga de recursos, porque entre la aplicación y el hardware aparece una capa extra (el hipervisor, el motor de publicación, el cliente remoto…). Aunque esa penalización suele ser pequeña si la plataforma está bien dimensionada, conviene entender dónde se nota más.

A nivel de CPU, las pruebas comparativas muestran que una VM típica sobre KVM o VMware vSphere obtiene entre un 5 % y un 7,5 % menos de rendimiento que el mismo sistema ejecutado directamente sobre hardware (bare metal). Es una diferencia asumible en la mayoría de aplicaciones empresariales (ofimática, web, ERP), pero puede ser clave en cálculos intensivos, IA o renderizado 3D.

En memoria RAM DDR4 vs DDR5, la velocidad efectiva puede disminuir en torno a un 7-13 % debido a la gestión adicional del hipervisor. En entornos muy exigentes esto obliga a sobredimensionar la memoria o a limitar la densidad de VMs por host para evitar saturaciones.

Donde más se nota la diferencia es en el almacenamiento (IOPS). Las pruebas con herramientas como fio indican caídas de rendimiento que pueden rondar el 17-25 % en operaciones de lectura/escritura aleatoria 4K frente al mismo disco en bare metal. La elección de cabinas NVMe, SSD de alto rendimiento, caches y un buen diseño de almacenamiento compartido es crítica para que las VMs y las aplicaciones virtualizadas respondan con fluidez.

La latencia de red también puede aumentar, sobre todo cuando muchas VMs comparten la misma interfaz física o cuando movemos tráfico de gráficos o vídeo intenso a través de sesiones remotas. El diseño de red (VLANs, QoS, ancho de banda, offloading) y el uso de protocolos eficientes de publicación gráfica marcan la diferencia en la experiencia del usuario.

Windows, App-V y entornos VDI/RDS: rendimiento en la práctica

En entornos Windows modernos (Windows 7 SP1, Windows 10, Windows 11, Windows Server 2012 R2 y 2016), la virtualización de aplicaciones con Microsoft App-V es una de las tecnologías clave para ofrecer aplicaciones en escenarios de Servicios de Escritorio Remoto (RDS) e infraestructuras VDI.

En estos entornos es habitual que los usuarios trabajen sobre máquinas no persistentes (VMs o hosts RDSH que se regeneran frecuentemente). Para que el usuario tenga acceso a sus aplicaciones virtuales en cuestión de segundos tras iniciar sesión, es fundamental ajustar tanto el cliente de App-V como la solución de administración de perfiles y la propia imagen base.

La experiencia de usuario depende de varios intervalos encadenados: el tiempo desde que el usuario introduce sus credenciales hasta que puede interactuar con el escritorio, el tiempo desde ahí hasta que empieza la actualización de publicación de App-V, la duración de esa actualización y, por último, el tiempo que tarda en estar disponible el acceso directo o la asociación de archivo de la aplicación virtual.

Optimizar estos tiempos supone combinar configuraciones de App-V (modo de almacén de contenido compartido, límites de publicación concurrente, preservación de integraciones de usuario), una buena solución de perfiles (UE-V u otra UPM) y una estrategia de imagen base pensada según el objetivo principal: máximo rendimiento o máximo ahorro de almacenamiento.

Escenarios de uso: enfoque orientado a rendimiento vs almacenamiento

Podemos agrupar los despliegues de App-V en entornos VDI/RDSH no persistentes y con estado en dos grandes escenarios extremos, sabiendo que en la práctica muchas empresas se quedan en un punto intermedio: uno optimizado para el rendimiento y otro centrado en reducir consumo de almacenamiento.

En el escenario orientado a rendimiento, la imagen base incluye previamente parte o la totalidad de los paquetes de aplicaciones virtuales relevantes, así como sus grupos de conexión. Esto implica un trabajo adicional de preparación y mantenimiento de imágenes, pero ofrece la mejor experiencia para el usuario: las aplicaciones aparecen prácticamente listas desde el primer instante tras el inicio de sesión.

El escenario orientado al almacenamiento evita incorporar en la imagen base los paquetes específicos de usuario, para no llenar matrices de disco compartidas con datos que quizá muchos usuarios no necesiten. Aquí se prioriza reducir el tamaño de las imágenes de máquina virtual, a costa de que algunas operaciones de configuración se trasladen al momento de inicio de sesión y, por tanto, se alargue ligeramente el tiempo hasta que ciertas aplicaciones estén disponibles.

En la práctica, lo habitual es aplicar el enfoque de rendimiento a un subconjunto de usuarios o paquetes críticos (por ejemplo, personal de atención al cliente o aplicaciones de negocio de uso masivo) y el enfoque de almacenamiento a usuarios ocasionales o aplicaciones menos sensibles al tiempo de arranque.

Preparación del entorno y de la imagen base para App-V

Para que la virtualización de aplicaciones en VDI o RDSH funcione con soltura, hay que preparar bien la imagen base y la solución de gestión de perfiles (UE-V u otra UPM). Un error en esta fase suele traducirse en inicios de sesión eternos, integraciones que se pierden o publicaciones que se duplican innecesariamente.

En el enfoque de rendimiento, los pasos clave incluyen habilitar el cliente de App-V integrado en el sistema, activar UE-V (o una solución equivalente) con la plantilla de configuración de App-V, configurar el modo de almacén de contenido compartido (SCS) para que solo se mantengan en disco los datos de publicación, y establecer en el registro la conservación de integraciones de usuario al iniciar sesión.

Además, se deben preconfigurar todos los paquetes y grupos de conexión tanto globales como de usuario (mediante comandos como Add-AppvClientPackage y Add-AppvClientConnectionGroup) y publicar previamente los paquetes globales. En algunos casos, se recomienda hacer ciclos de publicación/actualización global y de usuario, despublicar paquetes de destino de usuario y limpiar entradas VFS en los perfiles (por ejemplo en AppData\Local y AppData\Roaming relacionados con App-V).

En el enfoque orientado al almacenamiento, la preparación es similar pero solo se preconfiguran los paquetes y grupos de conexión de ámbito global. Los paquetes específicos de usuario se dejan fuera de la imagen base para no incrementar el tamaño y el consumo de disco de las VMs.

Junto a esto, conviene tener claro que la administración de TI deberá actualizar la imagen base con regularidad para reflejar cambios en versiones de paquetes, correcciones de seguridad y nuevos derechos de acceso. En algunos entornos será necesario gestionar varias imágenes diferentes para distintos perfiles de usuario.

Parámetros críticos de rendimiento en el cliente de App-V

Dentro del cliente de App-V existen varios ajustes de registro que influyen de forma directa en la rapidez de las publicaciones y en la carga sobre CPU, disco y red, sobre todo en hosts RDS con muchos usuarios simultáneos.

El modo de almacén de contenido compartido (SCS) permite que solo los metadatos de publicación se almacenen en el disco local, mientras que el resto de recursos de la aplicación se cargan bajo demanda desde un repositorio central (SAN, servidor de contenido). Esto ahorra IOPS locales y reduce el espacio en disco, con la condición de disponer de una red de baja latencia hacia el servidor de contenido.

La opción PreserveUserIntegrationsOnLogin evita que, al iniciar sesión, el cliente desintegre y reintegre las integraciones de usuario de paquetes que no estén preconfigurados. Si esta clave no está habilitada y hay muchos paquetes de usuario sin preconfigurar, cada inicio de sesión puede suponer un doble trabajo de publicación por paquete, con un impacto claro en el tiempo de logon.

Otro parámetro importante es MaxConcurrentPublishingRefresh, que define cuántos usuarios pueden lanzar a la vez una actualización de publicación. Dejarlo sin límite en un servidor RDS puede provocar picos de CPU muy fuertes cuando muchos usuarios inician sesión simultáneamente. Establecer un valor razonable atenúa esos picos, a costa de que, en escenarios de grandes oleadas de inicio de sesión, algunos usuarios tarden un poco más en ver nuevas aplicaciones publicadas.

Gestión del perfil de usuario: UE-V y otras soluciones UPM

Para que las aplicaciones virtuales arranquen casi al instante en entornos no persistentes, es esencial que la solución de administración de perfiles de usuario conserve y aplique las “integraciones de usuario” correctas entre sesiones: claves de registro, accesos directos, menús de inicio, catálogos de App-V, etc.

La virtualización de la experiencia de usuario (UE-V) de Microsoft está muy enfocada a escenarios VDI y RDS. Captura y almacena la configuración del usuario y la aplica automáticamente cuando el usuario inicia sesión en otro dispositivo o sesión. Para App-V, UE-V puede trabajar con plantillas específicas que capturan exactamente las rutas de registro y de archivos donde se guardan las integraciones.

Una peculiaridad relevante es la gestión de los archivos .lnk (accesos directos). UE-V solo admite quitar la extensión .lnk de la lista de archivos excluidos en escenarios donde todos los dispositivos de los usuarios tengan el mismo conjunto de aplicaciones instaladas en la misma ruta. Si no se cumple esta condición (por ejemplo, una aplicación está instalada solo en un equipo o en una ruta distinta), la sincronización de .lnk puede provocar accesos directos rotos.

Cuando se usan otras soluciones de UPM (discos de perfil de usuario, productos de terceros) es crucial que puedan: conservar las integraciones de usuario especificadas (registros y carpetas), sincronizar el perfil en el momento adecuado (inicio de sesión o arranque de aplicación, antes de la publicación de App-V) y capturar los cambios en dichas ubicaciones antes del cierre de sesión.

En App-V, la utilidad SyncAppvPublishingServer.exe se introdujo para facilitar a las soluciones de perfiles un desencadenador claro: se lanza la actualización de publicación del usuario en el inicio de sesión, pero permitiendo retrasarla hasta que el perfil se haya cargado completamente. Con esto se evita que App-V publique sobre un perfil incompleto o antiguo.

Tutorial de experiencia de usuario: qué pasa en cada inicio de sesión

Si miramos el flujo paso a paso, podemos entender mejor cómo se percibe la virtualización de aplicaciones en el día a día de los usuarios, según adoptemos un enfoque de rendimiento o de almacenamiento.

En el enfoque de rendimiento, en el primer inicio de sesión en un VDI/RDSH no persistente se dispara una publicación o actualización de usuario. Si es la primera vez que ese usuario recibe aplicaciones virtuales, la operación dura lo habitual. Una vez completada, la solución de perfiles captura las integraciones de usuario, normalmente al cerrar sesión, con un impacto similar al de guardar el resto del estado del usuario.

En los inicios posteriores, la solución UPM aplica primero todas las integraciones de usuario antes de que App-V empiece a refrescar la publicación. El usuario ve desde el principio los accesos directos en el escritorio o en el menú Inicio y muchos de ellos ya funcionan al instante. Si no hay cambios en los derechos, la publicación se completa en segundos. Cuando los hay, la duración crece en función del número y complejidad de las aplicaciones virtualizadas.

Como resultado, al conservar al 100 % las integraciones de usuario, la carga durante la publicación se reduce al mínimo: el sistema solo ajusta cambios de permisos o versiones, y las aplicaciones están listas en muy poco tiempo desde el login.

En el enfoque de almacenamiento, el primer inicio de sesión también lanza la publicación de usuario, con la duración normal. Sin embargo, tanto en ese primer inicio como en los siguientes, la necesidad de preconfigurar (agregar o actualizar) los paquetes de usuario puede ampliar el tiempo de disponibilidad de las aplicaciones. Es habitual añadir del orden de 10 segundos o más, dependiendo del volumen y la complejidad de los paquetes.

En este caso, los procesos de publicación y actualización deben volver a configurar todas las aplicaciones virtuales en cada inicio de sesión, lo que alarga inevitablemente la fase de refresco de publicación. Se gana en ahorro de espacio en disco, pero se sacrifica algo de agilidad al iniciar sesión.

Ciclo de vida de los paquetes App-V y estados pendientes

La gestión del ciclo de vida de los paquetes de App-V también influye en el rendimiento y en la coherencia de las versiones que ven los usuarios. Cuando un administrador actualiza un paquete, cambia derechos o despublica aplicaciones, esas operaciones pueden quedar en estado pendiente si el paquete está en uso.

A partir de App-V 5.0 SP2 se introdujeron los estados pendientes. En lugar de fallar, las operaciones de publicación o despublicación se marcan para ser completadas en el siguiente reinicio del servicio de App-V o cuando se lance de nuevo un comando publish/unpublish. En paquetes publicados de forma global, esto suele requerir un reinicio del servidor o del servicio de cliente.

En entornos no persistentes, estas tareas pendientes pueden no llegar nunca a procesarse, porque las máquinas se descartan o se recrean antes de que se cumplan las condiciones. Las tareas pendientes se almacenan en el perfil del usuario (por ejemplo, bajo HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\PendingTasks) y, si la solución de perfiles no aplica esa clave antes del inicio de sesión, las operaciones se quedarán en un limbo.

Por eso es tan importante mantener alineada la imagen base con el estado real de los paquetes: versiones, derechos, publicaciones globales. Cuanto menos dependamos de estados pendientes, más predecible será la experiencia y menos sorpresas habrá con paquetes que parecen no actualizarse o desaparecer cuando no toca.

Optimización de secuenciación y configuración para mejorar el rendimiento de publicación

App-V incluye distintas características que influyen en cómo se comportan las operaciones de publicación e inicio de aplicaciones. Algunos ajustes en la fase de secuenciación pueden marcar diferencias apreciables en entornos de red rápida.

Un ejemplo es la eliminación del bloque de características 1 (FB1). Si no se define FB1 (el conjunto mínimo de archivos que se predescargan para iniciar la aplicación), la app intentará arrancar inmediatamente y descargará lo que necesite sobre la marcha. En redes de alta velocidad esto puede acelerar el primer inicio, pero en redes lentas puede provocar cortes o esperas mientras se transmite contenido adicional.

Al crear un nuevo paquete con el secuenciador, basta con no marcar la opción de optimizar el paquete para redes lentas en el paso de streaming. En paquetes existentes, se puede actualizar el paquete sin seleccionar esa optimización. Lo ideal es realizar estas pruebas en un entorno controlado y siempre revertir la máquina de secuenciación a una instantánea limpia después.

Otro aspecto es la gestión de ensamblados Side-by-Side (SxS), como runtimes de Visual C++. No es necesario volver a secuenciar paquetes para modificarlos: si las dependencias SxS se encuentran ya instaladas en el cliente, el instalador MSI que App-V podría lanzar durante la publicación no se ejecutará y se ahorra tiempo. Si se dejan demasiados ensamblados SxS dentro del paquete, la publicación puede disparar instalaciones adicionales que penalicen el rendimiento.

El uso de archivos de configuración dinámica (Deployment/User Configuration) también tiene impacto. El cliente de App-V debe analizar estos archivos y ejecutar scripts o aplicar exclusiones/inclusiones de registro virtual. Si cada paquete arrastra configuraciones enormes, la publicación se verá afectada. Utilizarlos solo donde aporten valor real y deshabilitarlos en paquetes que no lo necesiten puede reducir de forma notable los tiempos de publicación.

Por último, conviene revisar las fuentes virtuales incluidas en los paquetes. Aunque un paquete típico no suele tener más de una veintena, cada fuente declarada implica trabajo extra durante la actualización de publicación. Deshabilitar fuentes virtuales innecesarias mediante configuración dinámica y, en su lugar, instalar las fuentes realmente requeridas de forma nativa en la imagen, ayuda a recortar segundos en despliegues con muchos usuarios.

Optimización general del rendimiento en máquinas virtuales

Más allá de App-V, hay una serie de prácticas comunes para mejorar el rendimiento de cualquier máquina virtual, sea en entornos de escritorio, laboratorio o producción.

Lo primero es asegurarse de que las extensiones de virtualización de hardware, como Intel VT-x o AMD-V, estén habilitadas en la BIOS/UEFI del host. Sin ellas, el hipervisor tendrá que emular más operaciones por software y el rendimiento caerá en picado.

También es recomendable elegir discos virtuales de tamaño fijo frente a los dinámicos. Aunque los discos que crecen según se llenan son más flexibles en cuanto a espacio, tienden a fragmentarse más y a ofrecer peor rendimiento. Si el espacio en el host no es un problema, merece la pena reservar de inicio el tamaño máximo del disco virtual.

La ubicación del almacenamiento es otro factor crítico. Siempre que sea posible, conviene alojar las VMs en unidades SSD rápidas en lugar de discos duros mecánicos o unidades externas lentas. La diferencia de rendimiento en arranque de sistema, apertura de aplicaciones y acceso a datos es muy notable.

No hay que olvidar instalar las herramientas de integración del hipervisor (Guest Additions, VMware Tools, etc.) en los sistemas invitados. Estas añaden drivers optimizados de vídeo, red, ratón y almacenamiento, y permiten un funcionamiento mucho más fluido que con los controladores genéricos del sistema operativo.

Por último, conviene asignar suficiente RAM y núcleos de CPU a cada VM, teniendo en cuenta que cada máquina virtual ejecuta un sistema operativo completo. Para sistemas Windows 7/10/11 o distribuciones Linux actuales, 2 GB son un mínimo muy justo; en la práctica, asignar más memoria mejora mucho la respuesta. Lo mismo ocurre con los núcleos de CPU: si el host dispone de muchos núcleos, repartirlos con cabeza entre las VMs activas marcará la diferencia.

Servidores físicos vs entornos virtualizados: cuándo elegir cada opción

A la hora de desplegar servicios, surge siempre la duda de si es mejor apostar por máquinas virtuales o servidores físicos dedicados. No hay una respuesta única: depende de la carga de trabajo, la criticidad de la latencia y los objetivos de coste y flexibilidad.

Los servidores físicos (bare metal) ofrecen el máximo rendimiento bruto, sin la sobrecarga de un hipervisor. Son la opción preferida para bases de datos transaccionales de muy alto rendimiento, cargas de trabajo con GPUs intensivas (IA, renderizado 3D, CAD avanzado) o servicios en tiempo real (juegos, streaming con codificación pesada) donde cada milisegundo cuenta.

Las máquinas virtuales, en cambio, brillan en entornos de alta flexibilidad y escalabilidad. Servicios web, microservicios y contenedores, entornos de desarrollo y prueba, escritorios virtuales y muchas aplicaciones corporativas funcionan de forma excelente virtualizadas, permitiendo snapshots, migraciones en caliente, aprovisionamiento rápido y una gestión centralizada de recursos.

Desde el punto de vista de licenciamiento y coste, los entornos virtualizados pueden encarecerse si se utilizan hipervisores comerciales con licencias por CPU o socket, pero ahorran en hardware, espacio y consumo energético. Por su parte, un servidor físico dedicado puede ser más barato en licencia, pero menos eficiente en uso de recursos si solo aloja unas pocas aplicaciones.

En la práctica, muchas organizaciones optan por un enfoque híbrido: servidores físicos para las cargas más críticas y sensibles al rendimiento, y un clúster de virtualización para el resto de servicios, incluidas las plataformas de publicación de aplicaciones y VDI.

Pruebas de estrés y métricas para evaluar el rendimiento

Para tomar decisiones informadas, no basta con intuiciones: hay que medir. Las pruebas de estrés de CPU, RAM, disco y red permiten comparar entornos virtualizados frente a servidores físicos y validar si la penalización de rendimiento es aceptable para una aplicación concreta.

Herramientas como sysbench ayudan a medir la capacidad de cálculo de la CPU (por ejemplo, calculando números primos hasta cierto límite), mientras que utilidades como memtester o stress-ng permiten evaluar la latencia y el ancho de banda de la memoria en distintas condiciones de carga.

Para el almacenamiento, herramientas especializadas como fio son el estándar de facto para medir IOPS, throughput y latencias con diferentes patrones de acceso (lectura/escritura secuencial, aleatoria, mezclas de ambas). Con ellas se puede cuantificar el impacto de la capa de virtualización y del tipo de backend de disco utilizado.

En el plano de red, utilidades como iperf3, netperf y ping permiten medir ancho de banda máximo, latencias medias y variabilidad (jitter) entre hosts físicos, VMs y clientes remotos. Estos datos son especialmente relevantes en escenarios de publicación de aplicaciones gráficas o escritorios remotos con altos requisitos de interacción.

Combinar estas métricas con la experiencia real de usuarios piloto permite ajustar el diseño: desde subir RAM o CPU a ciertas VMs, hasta cambiar la ubicación de los discos, modificar el tamaño máximo de publicaciones concurrentes de App-V o decidir que una cierta base de datos debe pasar a correr en un host físico.

A la vista de todo lo anterior, la virtualización de aplicaciones y de infraestructura bien diseñada es capaz de ofrecer un equilibrio muy sólido entre rendimiento, flexibilidad y costes. Aprovechar tecnologías como App-V, UE-V, KVM o hipervisores comerciales, elegir con cuidado entre servidores físicos y VMs según la carga, y ajustar los parámetros críticos de publicación y de perfil de usuario permite que los empleados disfruten de aplicaciones rápidas y disponibles desde cualquier lugar, sin que la complejidad subyacente se convierta en un freno para el negocio.