Table des matières

Introduction

L'infrastructure de bureau virtuel (VDI) simplifie la gestion centralisée des bureaux, mais ses composants interconnectés peuvent rendre le changement de plateforme difficile. Des courtiers de connexion propriétaires aux restrictions de licence, ces dépendances peuvent restreindre les choix informatiques et augmenter la complexité de la migration. Cet article examine les causes et les risques de l'enfermement par les fournisseurs de VDI, explique comment les réduire et décrit des étapes pratiques pour maintenir la livraison d'applications Windows flexible.

Qu'est-ce que le verrouillage des fournisseurs VDI ?

Le verrouillage des fournisseurs VDI est une situation où une organisation devient extrêmement dépendante d'une plateforme de virtualisation de bureau spécifique au point où changer de fournisseur serait extrêmement difficile, coûteux ou perturbant pour l'entreprise.

Les composants VDI tels que les hyperviseurs, les courtiers de connexion, les images de bureau, les profils d'utilisateur, les systèmes d'authentification et d'autres outils de gestion sont généralement combinés dans des environnements VDI. Cependant, bien qu'ils soient séparés, ils peuvent nécessiter une documentation et une configuration spécifiques du fournisseur pour interagir avec succès les uns avec les autres.

La raison en est que, bien que les applications écrites dans le langage Windows fonctionnent généralement partout, les bureaux conçus pour un environnement VDI spécifique nécessitent un temps considérable pour être reconfigurés. Par conséquent, le verrouillage par le fournisseur n'est pas un problème insurmontable, mais il crée des obstacles substantiels pour les organisations cherchant à changer de plateforme.

Quelles sont les causes d'un verrouillage fournisseur dans les environnements VDI ?

Le verrouillage des fournisseurs VDI est rarement causé par une limitation technique spécifique. Il résulte généralement de multiples dépendances vis-à-vis de l'infrastructure associée, des outils de gestion, des licences et des configurations d'application.

Courtiers de connexion propriétaires et outils de gestion

Les courtiers de connexion sont responsables de la gestion des connexions des utilisateurs aux bureaux virtuels, tandis que les outils de gestion sont utilisés pour provisionner, placer et maintenir les bureaux et les applications. Des outils comme Citrix Virtual Apps and Desktops, Omnissa Horizon et Azure Virtual Desktop sont construits en utilisant différentes infrastructures de gestion et techniques de configuration.

Cela implique que lors du passage d'une plateforme à une autre, il peut être nécessaire de restructurer les pools de bureaux, les applications, les connexions et les outils automatisés. Les applications elles-mêmes peuvent rester les mêmes, cependant, leur mise en œuvre différera en fonction du logiciel initial.

Dépendances de l'hyperviseur et de l'infrastructure

Les plateformes VDI nécessitent une infrastructure capable d'héberger et de gérer des bureaux virtuels. Cela peut inclure des technologies spécifiques de hyperviseur, de cloud, de stockage ou de provisionnement.

Le processus de migration peut donc impliquer plusieurs tâches :

  • Conversion ou reconstruction d'images de machines virtuelles
  • Reconfiguration du réseau, du stockage et de l'allocation des ressources
  • Remplacement des outils de provisionnement spécifiques au fournisseur
  • V Validation de la compatibilité et des performances de l'application
  • Recréer des mécanismes de disponibilité et de récupération après sinistre

Cependant, le concept de portabilité ne s'étend pas toujours à l'environnement de livraison de bureau. La migration réussie d'une machine virtuelle ne garantit pas que l'environnement de livraison environnant fonctionnera sans modification.

Licences et restrictions contractuelles

Les implémentations VDI nécessitent généralement plusieurs licences différentes – pour les systèmes d'exploitation, les produits de virtualisation, les droits d'accès des utilisateurs, les outils de gestion et les applications tierces.

Les fournisseurs diffèrent considérablement en termes de regroupement ou de dissociation de ces technologies, ce qui peut rendre la planification budgétaire et la transition vers de nouvelles infrastructures plus complexes.

Cela est particulièrement important lorsque les organisations souhaitent passer d'une pile VDI à une autre, par exemple, d'une solution sur site à une solution basée sur le cloud, car les modèles de licence pour les systèmes d'exploitation, les droits des utilisateurs et la consommation d'infrastructure peuvent changer de manière significative.

Le site Microsoft Learn fournit un aperçu de la licence Azure Virtual Desktop et comment cela s'applique à différents systèmes d'exploitation et cas d'utilisation.

Il est donc essentiel d'analyser l'ensemble de la structure de licence, y compris les implications de toute obligation contractuelle, lors de la prise de décision, et pas seulement les coûts d'abonnement.

Dépendances des applications et des profils utilisateurs

Les applications Windows pourraient avoir un certain nombre de dépendances sur le système d'exploitation, le registre, les pilotes, l'emplacement ou d'autres services.

Ces types d'applications sont couramment virtualisées dans des environnements VDI, avec certains aspects des exigences intégrés dans des images maîtresses ou incorporés dans des outils avancés de gestion des profils. Certaines entreprises construisent et maintiennent leurs propres outils et scripts pour répondre aux besoins particuliers de leurs applications par rapport au reste de l'infrastructure.

Dans ces situations, il devient extrêmement difficile de séparer les applications de leurs éléments de support, ce qui présente une dette technique considérable et rend la portabilité extrêmement difficile.

Même si l'application elle-même est portable, il y a encore des éléments essentiels, tels que l'installation, la configuration, les paramètres utilisateur et la gestion des données qui devront être rétablis dans le nouvel environnement. Comprendre la distinction entre Emballage d'application Windows et publication d'application peut aider les équipes informatiques à séparer les exigences de déploiement des logiciels des dépendances de livraison des applications.

Quels sont les risques d'un verrouillage par un fournisseur de VDI ?

La dépendance des fournisseurs présente des difficultés particulières lorsqu'une organisation doit changer sa stratégie d'infrastructure, s'adapter aux changements de licence ou adopter de nouvelles technologies de livraison d'applications.

Les principaux risques concernent les coûts, la flexibilité architecturale et la continuité opérationnelle.

Augmentation des coûts d'infrastructure et de licence

Un environnement VDI étroitement couplé peut rendre difficile pour une organisation d'optimiser ses composants d'infrastructure.

Lorsque les conditions de licence changent ou que le coût de l'infrastructure augmente, cela peut nécessiter un projet de migration à grande échelle s'ils envisagent de changer de fournisseur. Cela peut nuire à leur position de négociation et à leur capacité à optimiser les coûts.

De plus, fournir toutes les applications via un bureau virtuel complet peut entraîner une surcharge inutile pour les charges de travail ne nécessitant qu'une ou deux applications Windows.

La publication d'applications n'est en aucun cas moins chère que le VDI : l'économie des deux approches variera en fonction de la densité des charges de travail, des systèmes d'exploitation nécessaires, de l'empreinte de l'infrastructure et des exigences en matière d'administration et de gestion.

Flexibilité architecturale réduite

Les organisations cherchant à adopter une infrastructure hybride, à remplacer des serveurs vieillissants, à changer de fournisseurs d'hébergement ou même à adopter de nouvelles technologies de livraison peuvent constater que leurs options sont limitées par des dépendances spécifiques aux fournisseurs existants.

Une plateforme VDI étroitement liée à une pile d'infrastructure peut nécessiter une refonte complète des applications destinées à être livrées sur d'autres piles et fournisseurs d'hébergement, ralentissant ainsi le processus de transformation numérique.

Complexité accrue de la migration

Les transitions des fournisseurs de VDI ne concernent pas seulement la migration des machines virtuelles.

Les administrateurs doivent également conserver l'authentification, les profils d'utilisateur, les paramètres d'application, l'impression, l'accès aux fichiers, les politiques de sécurité et le comportement des sessions.

Une documentation insuffisante de ces dépendances peut rendre le processus plus difficile à quantifier, tester et exécuter sans incident.

Une plus grande exposition aux changements de fournisseur

L'arrêt du produit, les nouveaux modèles de licence, les changements de support ou les exigences d'infrastructure peuvent nécessiter un changement de stratégie de déploiement.

Plus la dépendance à une seule plateforme de déploiement est grande, plus l'impact opérationnel potentiel de ces changements sur l'entreprise est élevé.

Préserver des options de livraison alternatives peut atténuer ce risque et créer une plus grande flexibilité à mesure que les besoins commerciaux ou technologiques évoluent.

Comment pouvez-vous réduire les risques d'un verrouillage par un fournisseur de VDI ?

Réduire le verrouillage des fournisseurs VDI nécessite un ensemble de considérations techniques, liées à la charge de travail et architecturales.

L'idée n'est pas d'éviter les fournisseurs, mais plutôt de permettre des changements de plateforme sans perturber tous les autres aspects de la livraison d'applications.

1. Auditer les dépendances VDI existantes

La première étape consiste à identifier ce qui est essentiel à la livraison des applications et des bureaux, et quels composants dépendent de la technologie spécifique aux fournisseurs.

Un inventaire des dépendances devrait aborder les questions suivantes :

Composant Questions à enquêter
Courtier de connexion Les affectations de bureau et d'application peuvent-elles être recréées ailleurs ?
Hyperviseur Les machines virtuelles et les images peuvent-elles être déplacées vers une infrastructure alternative ?
Applications Les applications nécessitent-elles des images, des systèmes d'exploitation ou des pilotes spécifiques ?
Profils d'utilisateur Les paramètres et les données peuvent-ils migrer indépendamment ?
Authentification Les politiques d'identité sont-elles liées à des intégrations propriétaires ?
Licences Quelles obligations, droits d'accès et coûts de sortie s'appliquent ?
Automatisation Quels scripts dépendent des API ou des outils spécifiques au fournisseur ?

L'inventaire doit également inclure les propriétaires d'applications, la criticité commerciale, les exigences de récupération et les personnalisations non documentées.

Cette classification peut aider les responsables informatiques à comprendre quelles dépendances peuvent être facilement remplacées et lesquelles nécessitent une refonte significative.

2. Séparer la livraison d'applications de l'infrastructure de bureau

L'une des meilleures méthodes pour réduire le besoin de VDI est de s'assurer que chaque application nécessite réellement une solution aussi élaborée.

Bien que le VDI offre des bureaux virtuels, la publication d'applications fournit remote access vers des applications individuelles sans nécessairement livrer un bureau entier.

Les deux méthodes centralisent les applications, mais de manières différentes.

Exigence VDI complet Publication d'applications basée sur des sessions
Bureau personnalisé complet Bien adapté Pas le but principal
Applications Windows individuelles Pris en charge Bien adapté
Isolation dédiée du système d'exploitation de bureau Disponible Utilise généralement des hôtes de session partagés
Configurations de bureau spécialisées Souvent adapté Dépend de la compatibilité
Gestion centralisée des applications Pris en charge Pris en charge
Accès basé sur le navigateur Dépendant de la plateforme Disponible avec des solutions compatibles
Livraison sans une pile VDI complète Pas généralement Possible

La différence est architecturale, pas fonctionnelle.

De nombreux systèmes VDI de ce type permettent déjà la publication d'applications, donc permettre la publication d'applications ne vous aide pas nécessairement à éviter le verrouillage des fournisseurs, à moins que ces applications puissent être découplées du plan de contrôle VDI.

Dites, par exemple, que vous avez un service comptable qui a besoin d'accéder à une application financière Windows mais qui n'a pas besoin de ses propres bureaux virtuels. En publiant l'application sur une machine Windows (correctement configurée), vous pourriez éviter de faire en sorte que tout le monde utilise le VDI, tout en gardant l'administration de l'application centralisée.

D'autre part, les personnes qui ont besoin de bureaux persistants, où chaque utilisateur a sa propre session de bureau, peuvent avoir besoin d'un VDI complet.

3. Adopter des architectures modulaires et interopérables

Les architectures modulaires permettent le remplacement d'éléments individuels sans perturber l'environnement global de livraison des applications.

Les équipes informatiques devraient prioriser ce qui suit, le cas échéant :

  • Identité et authentification standardisées
  • Code d'application portable et dépendances documentées
  • Données utilisateur séparées des images de bureau
  • Infrastructure en tant que code : déploiement répétable, automatisation
  • Livraison qui fonctionne sur les points de terminaison et les environnements d'hébergement

Notez que la séparation des données utilisateur des images de bureau simplifiera à la fois les migrations et la récupération après sinistre : de même, l'infrastructure en tant que code aidera les opérations à recréer des environnements avec une meilleure cohérence.

Cependant, même les normes ouvertes et l'automatisation peuvent ne pas empêcher le verrouillage des fournisseurs : il existe souvent des différences subtiles dans l'implémentation entre les technologies des différents fournisseurs, et les scripts peuvent contenir des appels à des API propriétaires.

Par conséquent, l'objectif est d'éviter un couplage inutile entre les composants d'application et d'infrastructure, ainsi que les composants de gestion et opérationnels.

4. Considérer la livraison d'applications hybrides

Les organisations n'ont pas à choisir entre conserver toute leur infrastructure VDI ou la remplacer par quelque chose de complètement différent.

Ils pourraient adopter une stratégie hybride qui tire parti de diverses charges de travail en fonction de leurs besoins.

Une organisation pourrait utiliser des bureaux dédiés pour les utilisateurs avancés tout en hébergeant des applications professionnelles compatibles sur des hôtes de session Windows partagés.

Ils pourraient également fournir des applications héritées via des navigateurs. Pour les logiciels Windows qui ne peuvent pas être facilement réécrits, comprendre comment publier des logiciels Windows sur le web peut aider les équipes informatiques à évaluer la livraison basée sur le navigateur dans le cadre de leur stratégie hybride.

Les applications locales sont mieux conservées lorsque la centralisation n'améliore guère les performances globales.

Une telle stratégie permettra au département informatique de conserver les investissements existants dans leur infrastructure tout en transitionnant vers de nouvelles technologies à leur propre rythme.

Le défi de cette approche est qu'elle crée une complexité supplémentaire et exige une gestion des identités plus complète, des mesures de sécurité uniformes sur toutes les plateformes, des règles de surveillance et des procédures de support.

5. Comparez le coût total des modèles de livraison

Les économies de licence à elles seules ne dictent pas la rentabilité d'une architecture de livraison d'applications alternative.

Les équipes informatiques devraient évaluer le coût total de possession, y compris l'infrastructure, les coûts logiciels, l'administration, la sécurité et la migration.

Catégorie de coût Critères d'évaluation
Logiciel Licences, abonnements, support et renouvellements
Infrastructure Calcul, stockage, mise en réseau et consommation de cloud
Systèmes d'exploitation Licences Windows et droits d'accès applicables
Administration Provisionnement, maintenance, surveillance et dépannage
Sécurité MFA, contrôles d'accès, audit et gestion de la sécurité
Migration Tests, configuration, formation et déploiement
Continuité des activités Disponibilité, sauvegarde, récupération et exposition aux temps d'arrêt

La publication d'applications peut réduire le besoin de composants spécifiques dans un environnement VDI, mais elle a ses propres exigences en matière de déploiement et de licence.

Par exemple, les configurations d'hébergement de session traditionnelles des services de bureau à distance Microsoft (RDS) nécessiteraient les licences d'accès client RDS appropriées comme décrit dans Documentation des CAL RDS de Microsoft .

Les exigences de licence doivent être validées en fonction de l'architecture réelle, du produit de livraison et des termes et conditions pertinents de Microsoft.

L'objectif devrait être de minimiser les coûts totaux tout en offrant la sécurité, la performance et la fiabilité nécessaires pour répondre aux besoins de l'entreprise.

Que devriez-vous faire pour migrer loin du verrouillage des fournisseurs VDI ?

Réduire la dépendance aux fournisseurs est beaucoup plus sûr à faire de manière incrémentielle plutôt que de procéder à un remplacement complet de la plateforme.

La migration par phases offre aux équipes informatiques une opportunité de prouver des méthodes alternatives de livraison tout en maintenant le statu quo.

Étape 1 : Classer les applications par exigences de livraison

Commencez par regrouper les applications en fonction de leurs dépendances techniques et des exigences des utilisateurs finaux. Trois grandes catégories sont particulièrement utiles pour identifier :

  • Applications nécessitant des bureaux complets – charges de travail nécessitant un environnement OS dédié, une configuration spéciale ou une isolation au niveau du bureau
  • Applications adaptées à la publication à distance – applications Windows, compatibles avec les environnements d'hébergement de session partagés/dédiés pris en charge
  • Applications adaptées à un accès local ou natif du navigateur – logiciels qui ne nécessitent plus d'être exécutés dans un environnement VDI.

Une telle classification peut aider l'administrateur à identifier des candidats pour des modèles de livraison alternatifs, qui ne nécessitent pas d'adaptations significatives.

Étape 2 : Sélectionnez une charge de travail pilote à faible risque

Choisissez une application avec des exigences de ressources clairement définies, peu de dépendances et une base d'utilisateurs limitée.

Évitez de commencer par des applications critiques pour l'entreprise qui dépendent d'intégrations périphériques compliquées, de pilotes uniques ou de composants hérités vulnérables.

Le pilote devrait prouver la capacité de l'infrastructure alternative à reproduire adéquatement les fonctions essentielles et l'expérience utilisateur de l'environnement d'origine.

Étape 3 : Valider la compatibilité, la performance et la sécurité

Avant de passer à l'échelle, testez les fonctions et les caractéristiques opérationnelles dans des environnements réalistes.

Le projet de migration de la livraison d'applications doit inclure les domaines suivants dans le scénario de test :

  • Installation de l'application, dépendances et licences
  • Authentification, MFA et autorisations des utilisateurs
  • Profils d'utilisateur, paramètres et accès aux fichiers
  • Impression, redirection du presse-papiers et des périphériques
  • Concurrence de session et consommation de ressources
  • Latence, réactivité et reconnexion
  • Journalisation, surveillance et politiques de sécurité
  • Sauvegarde, restauration et procédures de retour en arrière

Le lancement d'applications avec succès ne garantit pas une compatibilité totale.

Par exemple, une application peut fonctionner correctement seule mais échouer lorsque plusieurs utilisateurs essaient de l'exécuter en même temps ou d'imprimer des documents sur des imprimantes.

Les équipes informatiques doivent concevoir les tests nécessaires et les critères de performance pour les sessions, les applications, la sécurité et les fonctionnalités de restauration.

Étape 4 : Migrer les applications par phases contrôlées

Une fois que le pilote répond à ses critères d'acceptation, augmentez le déploiement en fonction de la priorité commerciale et de la complexité technique.

Conservez l'environnement de livraison d'origine pendant la transition lorsque cela est possible, permettant aux administrateurs de comparer les performances, de résoudre efficacement les problèmes et de revenir aux processus établis si nécessaire.

Documenter les critères de succès, assigner des responsabilités et établir des procédures de retour en arrière pour chaque phase de migration. Ces mesures contribuent également à résilience des applications aider les organisations à préserver les fonctions commerciales essentielles lors des changements d'infrastructure.

Étape 5 : Examiner les dépendances restantes

Le problème de la dépendance envers un fournisseur n'est pas limité à une seule instance.

De nouvelles applications, la nécessité de mettre à niveau la plateforme, des changements dans la licence ou la personnalisation opérationnelle peuvent créer des dépendances supplémentaires après la migration.

Par conséquent, des examens périodiques sont nécessaires pour s'assurer que les applications peuvent continuer à fonctionner sur la plateforme cible, que les configurations ont été correctement enregistrées et que d'autres moyens de livraison restent disponibles.

Cela permettra au nouvel environnement d'éviter de devenir un autre verrouillage fournisseur.

Dans quel cas le VDI est-il la bonne solution à conserver ?

Réduire le verrouillage des fournisseurs VDI ne nécessite pas un remplacement en gros de la VDI.

VDI a une valeur légitime pour les scénarios qui nécessitent des systèmes d'exploitation dédiés, des bureaux persistants, des applications gourmandes en graphiques ou une isolation des charges de travail que les hôtes de session partagés ne peuvent pas fournir.

Il est également précieux pour fournir des bureaux standardisés, gérés de manière centralisée, avec des politiques de gestion de bureau cohérentes.

La décision d'adopter une architecture différente devrait être basée sur le comportement de l'application, les besoins en matière de sécurité, les exigences des utilisateurs et les facteurs économiques.

Pour la plupart des organisations, une architecture distribuée est plus pratique que de forcer toutes les applications dans le même modèle de livraison.

Conserver le VDI pour les charges de travail qui en ont besoin tout en utilisant la publication d'applications indépendante pour d'autres charges de travail permettrait de réduire le verrouillage VDI sans abandonner les capacités du VDI.

Comment la livraison d'applications peut-elle rester flexible à long terme ?

La flexibilité à long terme d'un système est obtenue grâce à la capacité de maintenir le contrôle sur la relation application-infrastructure et l'accès des utilisateurs.

Les applications doivent être conçues de manière à permettre leur fonctionnement continu sur des fournisseurs d'infrastructure, des hyperviseurs ou des plateformes de virtualisation de bureau potentiellement changeants.

Cette approche nécessite une attention particulière à la documentation appropriée des dépendances, à l'isolement des données d'application de ses mécanismes de livraison, à la conservation d'une configuration reproductible et à une enquête continue sur des approches et configurations alternatives.

Par exemple, bien qu'une application écrite pour Windows puisse être migrée pour fonctionner sur des serveurs Windows gérés de manière centralisée dans une nouvelle organisation qui utilise un logiciel d'hébergement ou des hyperviseurs différents, ou qui a remplacé son logiciel de courtage VDI, cela n'indique pas que l'application est universellement transportable.

Les applications doivent être testées pour leur capacité à fonctionner sur différentes infrastructures, y compris les variations du système d'exploitation de base, la licence appropriée, la compatibilité spécifique à l'application ou les caractéristiques de performance.

Une mesure utile pour la flexibilité est la portabilité de l'application entre des environnements significativement différents.

Si la migration d'une application vers une infrastructure différente, mais prise en charge, nécessite une refonte extensive d'éléments non liés en raison de la présence de nombreuses dépendances, cela indique qu'un travail considérable doit être effectué avant que l'application puisse être considérée comme portable.

Cette métrique peut être appliquée de manière itérative pour augmenter progressivement la flexibilité des besoins en infrastructure d'une application ou pour effectuer des ajustements opérationnels sans nécessiter une refonte complète de l'application elle-même.

Vous cherchez un moyen plus simple de livrer des applications Windows ?

TSplus Remote Access fournit une alternative pour les organisations qui souhaitent publier des applications Windows et fournir des bureaux à distance sans déployer une infrastructure VDI complète traditionnelle. Avec la publication d'applications, l'accès via navigateur HTML5 et le support des environnements Windows hébergés sur site ou dans le cloud, cela aide les équipes informatiques à diversifier les options de livraison tout en conservant un contrôle centralisé.

Conclusion

Le verrouillage des fournisseurs VDI devient coûteux lorsque les applications dépendent d'une infrastructure, de licences et de systèmes de gestion étroitement intégrés. Cartographier ces dépendances et introduire des méthodes de livraison alternatives peut aider les organisations à conserver le contrôle sans abandonner complètement le VDI.

Une architecture flexible permet aux équipes informatiques de maintenir des charges de travail appropriées sur des bureaux virtuels tout en simplifiant l'accès à d'autres, réduisant ainsi le risque de migration et préservant les options futures.

Essai gratuit de TSplus Remote Access

Alternative ultime à Citrix/RDS pour l'accès aux bureaux/applications. Sécurisé, rentable, sur site/cloud

Lecture complémentaire

back to top of the page icon