VDI Leverancier Lock-In: Risico's en Oplossingen

Introductie

Virtuele Desktopinfrastructuur (VDI) vereenvoudigt het centrale desktopbeheer, maar de onderling verbonden componenten kunnen het moeilijk maken om van platform te wisselen. Van propriëtaire verbindingsbrokers tot licentiebeperkingen, deze afhankelijkheden kunnen de IT-keuzes beperken en de migratiecomplexiteit verhogen. Dit artikel onderzoekt de oorzaken en risico's van VDI-leverancierslock-in, legt uit hoe deze te verminderen, en schetst praktische stappen om de levering van Windows-toepassingen flexibel te houden.

Wat is VDI-leverancier lock-in?

VDI-vendor lock-in is een situatie waarin een organisatie extreem afhankelijk wordt van een specifiek desktopvirtualisatieplatform, tot het punt waarop het veranderen van leveranciers extreem uitdagend, kostbaar of verstorend voor het bedrijf zou zijn.

VDI-componenten zoals hypervisors, connectiebrokers, desktopafbeeldingen, gebruikersprofielen, authenticatiesystemen en andere beheertools worden meestal gecombineerd in VDI-omgevingen. Echter, ondanks dat ze afzonderlijk zijn, kunnen ze specifieke documentatie en configuratie van de leverancier vereisen om succesvol met elkaar te communiceren.

De reden is dat, hoewel applicaties geschreven in de Windows-taal meestal overal werken, desktops die zijn gebouwd voor een specifieke VDI-omgeving aanzienlijke tijd nodig hebben om opnieuw te configureren. Daarom is vendor lock-in geen onoverkomelijk probleem, maar het creëert wel aanzienlijke obstakels voor organisaties die willen overstappen naar andere platforms.

Wat zijn de oorzaken van een vendor lock-in in VDI-omgevingen?

VDI-leverancier lock-in wordt zelden veroorzaakt door één specifieke technische beperking. Het is meestal het resultaat van meerdere afhankelijkheden van gerelateerde infrastructuur, beheertools, licenties en applicatieconfiguraties.

Eigen verbinding brokers en beheertools

Verbindingsbrokers zijn verantwoordelijk voor het beheren van gebruikersverbindingen naar virtuele desktops, terwijl beheertools worden gebruikt om desktops en applicaties te provisioneren, plaatsen en onderhouden. Tools zoals Citrix Virtual Apps en Desktops, Omnissa Horizon en Azure Virtual Desktop zijn gebouwd met verschillende beheerinfrastructuur en configuratietechnieken.

Dit houdt in dat het bij het overstappen van het ene platform naar het andere nodig kan zijn om desktoppools, applicaties, verbindingen en geautomatiseerde tools opnieuw te structureren. De applicaties zelf kunnen hetzelfde blijven, maar hun implementatie zal verschillen afhankelijk van de oorspronkelijke software.

Hypervisor en infrastructuurafhankelijkheden

VDI-platforms vereisen infrastructuur die in staat is om virtuele desktops te hosten en te beheren. Dit kan specifieke hypervisors, cloud-, opslag- of provisioningtechnologieën omvatten.

Het migratieproces kan daarom verschillende taken met zich meebrengen:

• Virtuele machine-afbeeldingen converteren of opnieuw opbouwen
• Hernieuwen van netwerken, opslag en resourceallocatie
• Vervangen van leveranciersspecifieke provisioningtools
• V Toepassingscompatibiliteit en -prestaties valideren
• Beschikbaarheids- en herstelmechanismen opnieuw creëren

Echter, het concept van draagbaarheid strekt zich niet altijd uit tot de desktopleveringsomgeving. De succesvolle migratie van een virtuele machine garandeert niet dat de omliggende leveringsomgeving zonder aanpassing zal functioneren.

Licentie- en contractuele beperkingen

VDI-implementaties vereisen doorgaans verschillende licenties - voor besturingssystemen, virtualisatieproducten, gebruikersrechten, beheertools en applicaties van derden.

Leveranciers verschillen aanzienlijk in termen van het bundelen of ontbundelen van deze technologieën, wat het budgetteren en de overgang naar nieuwe infrastructuren complexer kan maken.

Dit is vooral belangrijk wanneer organisaties willen overstappen van de ene VDI-stack naar de andere, bijvoorbeeld van on-premise naar een cloudgebaseerde oplossing, omdat de licentiemodellen voor besturingssystemen, gebruikersrechten en infrastructuurverbruik drastisch kunnen veranderen.

Microsoft Learn-website biedt een inzicht in Azure Virtual Desktop-licenties en hoe het van toepassing is op verschillende besturingssystemen en gebruiksscenario's.

Daarom is het essentieel om de gehele licentiestapel te analyseren, inclusief de implicaties van eventuele contractuele verplichtingen, bij het nemen van de beslissing, niet alleen de abonnements kosten.

Toepassings- en gebruikersprofielafhankelijkheden

Windows-applicaties kunnen een aantal afhankelijkheden hebben van het besturingssysteem, het register, stuurprogramma's, de locatie of andere diensten.

Deze soorten applicaties worden vaak gevirtualiseerd in VDI-omgevingen, met bepaalde aspecten van vereisten ingebouwd in masterafbeeldingen of opgenomen in geavanceerde profielbeheertools. Sommige bedrijven bouwen en onderhouden hun eigen tools en scripts om te voldoen aan de specifieke behoeften van hun applicaties in relatie tot de rest van de infrastructuur.

In deze situaties wordt het uiterst uitdagend om applicaties van hun ondersteunende elementen te scheiden, wat aanzienlijke technische schulden met zich meebrengt en de draagbaarheid uiterst moeilijk maakt.

Zelfs als de applicatie zelf draagbaar is, zijn er nog steeds essentiële elementen, zoals de installatie, configuratie, gebruikersinstellingen en gegevensbeheer die opnieuw moeten worden ingesteld in de nieuwe omgeving. Het begrijpen van het onderscheid tussen Windows-applicatieverpakking en applicatiepublicatie kan IT-teams helpen om de vereisten voor software-implementatie te scheiden van de afhankelijkheden van applicielevering.

Wat zijn de risico's van een VDI-leverancier lock-in?

Leverancierafhankelijkheid brengt bijzondere moeilijkheden met zich mee wanneer een organisatie haar infrastructuurstrategie moet wijzigen, zich moet aanpassen aan licentiewijzigingen of nieuwe technologieën voor appliclevering moet aannemen.

De belangrijkste risico's hebben betrekking op kosten, architectonische flexibiliteit en operationele continuïteit.

Stijgende infrastructuur- en licentiekosten

Een nauw verbonden VDI-omgeving kan het voor een organisatie moeilijk maken om hun infrastructuurcomponenten te optimaliseren.

Wanneer de licentievoorwaarden veranderen of de kosten van de infrastructuur stijgen, kan dit een grootschalig migratieproject noodzakelijk maken als ze van plan zijn om van leverancier te wisselen. Dit kan hun onderhandelingspositie en vermogen om kosten te optimaliseren schaden.

Bovendien kan het aanbieden van alle applicaties via een volledige virtuele desktop onnodige overhead met zich meebrengen voor workloads die slechts één of twee vensterapplicaties vereisen.

Applicatiepublicatie is geenszins goedkoper dan VDI: de economieën van de twee benaderingen zullen variëren afhankelijk van de dichtheid van de werklasten, de benodigde besturingssystemen, de infrastructuuroverlast en de vereisten voor administratie en beheer.

Verminderde architectonische flexibiliteit

Organisaties die een hybride infrastructuur willen adopteren, verouderde servers willen vervangen, willen wisselen tussen hostingproviders of zelfs nieuwe leverings-technologieën willen adopteren, kunnen merken dat hun opties beperkt zijn door bestaande leveranciersspecifieke afhankelijkheden.

Een VDI-platform dat nauw verbonden is met één infrastructuurstack kan een volledige herontwerp van applicaties vereisen die bedoeld zijn voor levering op andere stacks en hostingproviders, waardoor het digitale transformatieproces wordt vertraagd.

Verhoogde migratiecomplexiteit

VDI-leverancierovergangen gaan niet alleen over de migratie van virtuele machines.

Beheerders moeten ook authenticatie, gebruikersprofielen, applicatie-instellingen, afdrukken, bestands toegang, beveiligingsbeleid en sessiegedrag behouden.

Slechte documentatie van deze afhankelijkheden kan het proces moeilijker maken om te kwantificeren, testen en uitvoeren zonder incidenten.

Grotere blootstelling aan wijzigingen van de leverancier

Productstopzetting, nieuwe licentiemodellen, wijzigingen in ondersteuning of infrastructuurvereisten kunnen een wijziging in de implementatiestrategie noodzakelijk maken.

Hoe groter de afhankelijkheid van een enkel implementatieplatform, hoe groter de potentiële operationele impact van deze veranderingen op het bedrijf.

Het behouden van alternatieve leveringsopties kan dit risico verminderen en grotere flexibiliteit creëren naarmate de zakelijke of technologische behoeften veranderen.

Hoe kunt u de risico's van een VDI-leverancier lock-in verminderen?

Het verminderen van VDI-leverancierslock-in vereist een reeks technische, werklastgerelateerde en architecturale overwegingen.

Het idee is niet om leveranciers te vermijden, maar eerder om platformwijzigingen mogelijk te maken zonder alle andere aspecten van appliclevering te verstoren.

1. Audit bestaande VDI-afhankelijkheden

De eerste stap is om te identificeren wat cruciaal is voor de levering van applicaties en desktops, en welke componenten afhankelijk zijn van technologie die specifiek is voor leveranciers.

Een afhankelijkheidsinventaris moet de volgende vragen behandelen:

Component	Vragen om te onderzoeken
Verbindingsbroker	Kunnen desktop- en applicatietoewijzingen ergens anders opnieuw worden aangemaakt?
Hypervisor	Kunnen virtuele machines en afbeeldingen naar alternatieve infrastructuur verhuizen?
Applicaties	Vereisen applicaties specifieke afbeeldingen, besturingssystemen of stuurprogramma's?
Gebruikersprofielen	Kunnen instellingen en gegevens onafhankelijk migreren?
Authenticatie	Zijn identiteitsbeleid gekoppeld aan eigen integraties?
Licenties	Welke verplichtingen, toegangsrechten en exitkosten zijn van toepassing?
Automatisering	Welke scripts zijn afhankelijk van vendor-specifieke API's of tools?

De inventaris moet ook applicatie-eigenaren, bedrijfskritikaliteit, herstelvereisten en niet-gedocumenteerde aanpassingen omvatten.

Deze classificatie kan IT-managers helpen te begrijpen welke afhankelijkheden gemakkelijk kunnen worden vervangen en welke aanzienlijke herontwerpen vereisen.

2. Scheid Applicatielevering van Desktopinfrastructuur

Een van de beste methoden om de behoefte aan VDI te verminderen, is ervoor te zorgen dat elke applicatie daadwerkelijk zo'n uitgebreide oplossing vereist.

Hoewel VDI virtuele desktops biedt, biedt applicatiepublicatie Externe toegang naar individuele applicaties zonder noodzakelijkerwijs een volledig bureaublad te leveren.

Beide methoden centraliseren applicaties, maar op verschillende manieren.

Vereiste	Volledige VDI	Sessie-gebaseerde applicatiepublicatie
Volledig gepersonaliseerde desktop	Goed geschikt	Niet het primaire doel
Individuele Windows-toepassingen	Ondersteund	Goed geschikt
Toegewijde desktop OS-isolatie	Beschikbaar	Over het algemeen worden gedeelde sessiehosts gebruikt
Gespecialiseerde desktopconfiguraties	Vaak geschikt	Hangt af van compatibiliteit
Gecentraliseerd applicatiebeheer	Ondersteund	Ondersteund
Browsergebaseerde toegang	Platformafhankelijk	Beschikbaar met compatibele oplossingen
Levering zonder een volledige VDI-stack	Niet algemeen	Mogelijk

Het verschil is architectonisch, niet functioneel.

Veel van dergelijke VDI-systemen staan al applicatiepublicatie toe, dus het toestaan van applicatiepublicatie helpt je niet noodzakelijkerwijs om vendor lock-in te vermijden, tenzij die applicaties kunnen worden losgekoppeld van het VDI-besturingsvlak.

Zeg bijvoorbeeld dat je een boekhoudafdeling hebt die toegang nodig heeft tot een Windows financiële applicatie, maar geen eigen virtuele desktops nodig heeft. Door de applicatie op een Windows-box (goed ingesteld) te publiceren, kun je voorkomen dat iedereen de VDI moet gebruiken, terwijl je de applicatiebeheer gecentraliseerd houdt.

Aan de andere kant hebben mensen die persistente desktops nodig hebben, waarbij elke gebruiker zijn eigen desktop sessie heeft, mogelijk volledige VDI nodig.

3. Neem modulaire en interoperabele architecturen aan

Modulaire architecturen maken het mogelijk om individuele elementen te vervangen zonder de algehele applicatieleveringsomgeving te verstoren.

IT-teams moeten de volgende zaken prioriteit geven waar van toepassing:

• Gestandaardiseerde Identiteit & Authenticatie
• Draagbare applicatiecode en gedocumenteerde afhankelijkheden
• Gebruikersgegevens gescheiden van bureaubladafbeeldingen
• Infrastructuur als code: herhaalbare implementatie, automatisering
• Levering die werkt op verschillende eindpunten en hostingomgevingen

Merk op dat de scheiding van gebruikersgegevens van bureaubladafbeeldingen zowel migraties als herstel na een ramp zal vereenvoudigen: op dezelfde manier zal infrastructuur als code de operaties helpen om omgevingen met betere consistentie te recreëren.

Echter, zelfs open standaarden en automatisering kunnen de vendor lock-in niet voorkomen: er zijn vaak subtiele verschillen in implementatie tussen de technologieën van verschillende leveranciers, en scripts kunnen oproepen bevatten naar propriëtaire API's.

Daarom is het doel om onnodige koppeling tussen applicatie- en infrastructuurcomponenten, beheer- en operationele componenten te vermijden.

4. Overweeg hybride applicatielevering

Organisaties hoeven niet te kiezen tussen het behouden van hun volledige VDI-infrastructuur of het vervangen ervan door iets heel anders.

Ze zouden een hybride strategie kunnen aannemen die verschillende werklasten benut op basis van hun behoeften.

Een organisatie kan dedicated desktops voor power users gebruiken terwijl compatibele zakelijke applicaties op gedeelde Windows-sessiehosts worden gehost.

Ze konden ook legacy-applicaties via browsers leveren. Voor Windows-software die niet eenvoudig kan worden herschreven, is begrip hoe Windows-software op het web te publiceren kan IT-teams helpen bij het evalueren van browsergebaseerde levering als onderdeel van hun hybride strategie.

Lokale applicaties blijven het beste behouden wanneer centralisatie weinig doet om de algehele prestaties te verbeteren.

Zo'n strategie stelt de IT-afdeling in staat om bestaande investeringen in hun infrastructuur te behouden terwijl ze op hun eigen tempo overstappen naar nieuwe technologieën.

De uitdaging van deze aanpak is dat het extra complexiteit met zich meebrengt en meer uitgebreide identiteitsbeheer, uniforme beveiligingsmaatregelen over alle platforms, monitoringregels en ondersteuningsprocedures vereist.

5. Vergelijk de totale kosten van leveringsmodellen

Licentiebesparingen alleen bepalen niet de kosteneffectiviteit van een alternatieve applicatieleveringsarchitectuur.

IT-teams moeten de totale eigendomskosten evalueren, inclusief infrastructuur, softwarekosten, administratie, beveiliging en migratie.

Kostencategorie	Evaluatiecriteria
Software	Licenties, abonnementen, ondersteuning en verlengingen
Infrastructuur	Computing, opslag, netwerken en cloudverbruik
Besturingssystemen	Windows-licenties en toepasselijke toegangsrechten
Administratie	Provisioning, onderhoud, monitoring en probleemoplossing
Beveiliging	MFA, toegangscontroles, auditing en beveiligingsbeheer
Migratie	Testen, configuratie, training en implementatie
Bedrijfscontinuïteit	Beschikbaarheid, back-up, herstel en blootstelling aan downtime

Applicatiepublicatie kan de behoefte aan specifieke componenten in een VDI-omgeving verminderen, maar het heeft wel zijn eigen implementatie- en licentievereisten.

Bijvoorbeeld, traditionele Microsoft Remote Desktop Services (RDS) sessiehostconfiguraties zouden de juiste RDS Client Access Licenses vereisen zoals beschreven in Microsoft's RDS CAL-documentatie .

Licentievereisten moeten worden gevalideerd op basis van de werkelijke architectuur, het leveringsproduct en de relevante Microsoft-voorwaarden.

Het doel moet zijn om de totale kosten te minimaliseren terwijl de beveiliging, prestaties en betrouwbaarheid die nodig zijn om aan de zakelijke behoeften te voldoen, nog steeds worden geleverd.

Wat zou je moeten doen om te migreren van VDI-leverancierslock-in?

Het verminderen van afhankelijkheid van leveranciers is veel veiliger om geleidelijk te doen dan een volledige vervanging van het platform te maken.

Fasegewijze migratie biedt IT-teams de mogelijkheid om alternatieve leveringsmethoden te bewijzen terwijl de status quo behouden blijft.

Stap 1: Classificeer applicaties op basis van leveringsvereisten

Begin met het groeperen van applicaties op basis van hun technische afhankelijkheden en de vereisten van de eindgebruiker. Drie brede categorieën zijn bijzonder nuttig om te identificeren:

• Toepassingen die volledige desktops vereisen – workloads die een toegewijde OS-omgeving, speciale configuratie of isolatie op desktopniveau vereisen
• Toepassingen geschikt voor remote publishing – Windows-toepassingen, compatibel met ondersteunde gedeelde/gewijde sessie-hostomgevingen
• Toepassingen geschikt voor lokale of browser-native toegang – software die niet langer binnen een VDI-omgeving hoeft te worden uitgevoerd

Zo'n classificatie kan de beheerder helpen kandidaten voor alternatieve leveringsmodellen te identificeren, die geen significante aanpassingen vereisen.

Stap 2: Selecteer een laag-risico pilotwerkbelasting

Kies een applicatie met duidelijk gedefinieerde resource-eisen, weinig afhankelijkheden en een beperkte gebruikersbasis.

Vermijd te beginnen met bedrijfskritische applicaties die afhankelijk zijn van ingewikkelde perifere integraties, unieke stuurprogramma's of kwetsbare legacycomponenten.

De pilot moet het vermogen van de alternatieve infrastructuur aantonen om essentiële functies en de gebruikerservaring van de oorspronkelijke omgeving adequaat te repliceren.

Stap 3: Valideer compatibiliteit, prestaties en beveiliging

Voordat u opschaalt, test functies en operationele kenmerken in realistische omgevingen.

Het migratieproject voor de applicatielevering moet de volgende gebieden in het testscenario omvatten:

• Applicatie-installatie, afhankelijkheden en licenties
• Authenticatie, MFA en gebruikersrechten
• Gebruikersprofielen, instellingen en bestands toegang
• Afdrukken, klembord en perifere omleiding
• Sessieconcurrentie en hulpbronnenverbruik
• Latentie, responsiviteit en reconnection
• Logging, monitoring en beveiligingsbeleid
• Back-up-, herstel- en terugrolprocedures

Het succesvol starten van applicaties garandeert geen volledige compatibiliteit.

Bijvoorbeeld, een applicatie kan prima op zichzelf werken, maar falen wanneer meerdere gebruikers proberen deze tegelijkertijd uit te voeren of documenten op printers af te drukken.

IT-teams moeten de noodzakelijke tests en prestatiecriteria voor sessies, applicaties, beveiliging en terugrolfuncties ontwerpen.

Stap 4: Migreer applicaties in gecontroleerde fasen

Zodra de pilot voldoet aan de acceptatiecriteria, schaal de implementatie op op basis van zakelijke prioriteit en technische complexiteit.

Behoud de oorspronkelijke leveringsomgeving tijdens de overgang wanneer mogelijk, zodat beheerders de prestaties kunnen vergelijken, effectief problemen kunnen oplossen en indien nodig kunnen terugkeren naar gevestigde processen.

Documenteer succescriteria, wijs verantwoordelijkheden toe en stel terugrolprocedures vast voor elke fase van de migratie. Deze maatregelen dragen ook bij aan toepassingsweerbaarheid , organisaties helpen om essentiële bedrijfsfuncties te behouden tijdens infrastructuurveranderingen.

Stap 5: Beoordeel de resterende afhankelijkheden

Het probleem van vendor lock-in is niet beperkt tot een enkele instantie.

Nieuwe applicaties, de noodzaak om het platform te upgraden, wijzigingen in licenties of operationele aanpassingen kunnen extra afhankelijkheden creëren nadat de migratie is voltooid.

Daarom zijn periodieke beoordelingen nodig om ervoor te zorgen dat applicaties kunnen blijven functioneren op het doelsysteem, dat configuraties correct zijn vastgelegd en dat andere leveringsmethoden beschikbaar blijven.

Dit zal de nieuwe omgeving in staat stellen om te voorkomen dat het een andere vendor lock-in wordt.

In welk geval is VDI de goede oplossing om te behouden?

Het verminderen van VDI-leverancierslock-in vereist geen volledige vervanging van VDI.

VDI heeft legitieme waarde voor scenario's die de behoefte aan dedicated besturingssystemen, persistente desktops, grafisch intensieve applicaties of werklastisolatie vereisen die gedeelde sessiehosts niet kunnen bieden.

Het is ook waardevol voor het leveren van gestandaardiseerde, centraal beheerde desktops met consistente desktopbeheerbeleid.

De beslissing om een andere architectuur aan te nemen, moet gebaseerd zijn op applicatiegedrag, beveiligingsbehoeften, gebruikersvereisten en economische factoren.

Voor de meeste organisaties is een gedistribueerde architectuur praktischer dan het forceren van alle applicaties in hetzelfde leveringsmodel.

Het behouden van VDI voor workloads die het vereisen, terwijl onafhankelijke applicatiepublicatie voor andere workloads wordt gebruikt, zou het mogelijk maken om VDI-lock-in te verminderen zonder de mogelijkheden van VDI op te geven.

Hoe kan Application Delivery op lange termijn flexibel blijven?

De langetermijnflexibiliteit van een systeem wordt bereikt door de mogelijkheid om controle te behouden over de relatie tussen de applicatie-infrastructuur en de gebruikerstoegang.

Toepassingen moeten zo worden ontworpen dat ze kunnen blijven functioneren op mogelijk veranderende infrastructuurhostingproviders, hypervisors of desktopvirtualisatieplatforms.

Deze aanpak vereist nauwlettende aandacht voor de juiste documentatie van afhankelijkheden, isolatie van applicatiegegevens van de leveringsmechanismen, behoud van repliceerbare configuratie en continue onderzoek naar alternatieve benaderingen en configuraties.

Bijvoorbeeld, terwijl een applicatie die voor Windows is geschreven mogelijk is gemigreerd om te draaien op centraal beheerde Windows-servers bij een nieuwe organisatie die verschillende hostingsoftware of hypervisors gebruikt, of hun VDI-brokeringssoftware heeft vervangen, betekent dit niet dat de applicatie universeel transporteerbaar is.

Toepassingen moeten worden getest op hun vermogen om te functioneren op verschillende infrastructuren, inclusief variaties in het basisbesturingssysteem, geschikte licenties, applicatie-specifieke compatibiliteit of prestatiekenmerken.

Een nuttige maatstaf voor flexibiliteit is de draagbaarheid van de applicatie tussen aanzienlijk verschillende omgevingen.

Als het migreren van een applicatie naar een andere, maar ondersteunde, infrastructuur uitgebreide herwerking van niet-verwante elementen vereist vanwege de aanwezigheid van veel afhankelijkheden, geeft dit aan dat er veel werk moet worden verzet voordat de applicatie als draagbaar kan worden beschouwd.

Deze maatstaf kan iteratief worden toegepast om geleidelijk de flexibiliteit van de infrastructuurbehoeften van een applicatie te vergroten of operationele aanpassingen te maken zonder dat een volledige herwerking van de applicatie zelf nodig is.

Zoekt u een eenvoudigere manier om Windows-toepassingen te leveren?

TSplus Remote Access biedt een alternatief voor organisaties die Windows-toepassingen willen publiceren en externe desktops willen leveren zonder een traditionele volledige VDI-stack te implementeren. Met applicatiepublicatie, HTML5-browsertoegang en ondersteuning voor Windows-omgevingen die on-premises of in de cloud worden gehost, helpt het IT-teams om de leveringsopties te diversifiëren terwijl ze centrale controle behouden.

Conclusie

VDI-leverancier lock-in wordt kostbaar wanneer applicaties afhankelijk zijn van nauw geïntegreerde infrastructuur, licenties en beheersystemen. Het in kaart brengen van deze afhankelijkheden en het introduceren van alternatieve leveringsmethoden kan organisaties helpen de controle te behouden zonder VDI helemaal op te geven.

Een flexibele architectuur stelt IT-teams in staat om geschikte workloads op virtuele desktops te behouden, terwijl de toegang tot andere workloads wordt vereenvoudigd, waardoor het migratierisico wordt verminderd en toekomstige opties worden behouden.