VDI-leverandørbinding: Risikoer og løsninger

Introduksjon

Virtuell skrivebordsinfrastruktur (VDI) forenkler sentralisert skrivebordsadministrasjon, men dens sammenkoblede komponenter kan gjøre plattformbytte vanskelig. Fra proprietære tilkoblingsmeglere til lisensieringsbegrensninger, kan disse avhengighetene begrense IT-valg og øke migrasjonskompleksiteten. Denne artikkelen undersøker årsakene til og risikoene ved VDI-leverandørbinding, forklarer hvordan man kan redusere dem, og skisserer praktiske trinn for å holde levering av Windows-applikasjoner fleksibel.

Hva er VDI-leverandørlås?

VDI-leverandørlåsning er en situasjon der en organisasjon blir ekstremt avhengig av en spesifikk skrivebordsvirtualiseringsplattform til det punktet at det å bytte leverandører ville være ekstremt utfordrende, kostbart eller forstyrrende for selskapet.

VDI-komponenter som hypervisorer, tilkoblingsmeglere, skrivebordsbilder, brukerprofiler, autentiseringssystemer og andre administrasjonsverktøy kombineres vanligvis i VDI-miljøer. Imidlertid, til tross for å være separate, kan de kreve spesifikk leverandørdokumentasjon og konfigurasjon for å samhandle vellykket med hverandre.

Årsaken er at selv om applikasjoner skrevet i Windows-språk vanligvis fungerer hvor som helst, krever skrivebord bygget for et spesifikt VDI-miljø betydelig tid for å omkonfigurere. Derfor er leverandørlåsing ikke et uoverkommelig problem, men det skaper betydelige hindringer for organisasjoner som ønsker å bytte plattform.

Hva er årsakene til leverandørlåsing i VDI-miljøer?

VDI-leverandørlås er sjelden forårsaket av en spesifikk teknisk begrensning. Det skyldes vanligvis flere avhengigheter til relaterte infrastrukturer, administrasjonsverktøy, lisensiering og applikasjonskonfigurasjoner.

Egne tilkoblingsmeglere og administrasjonsverktøy

Tilkoblingsmeglere er ansvarlige for å administrere brukerforbindelser til virtuelle skrivebord, mens administrasjonsverktøy brukes til å tildele, plassere og vedlikeholde skrivebord og applikasjoner. Verktøy som Citrix Virtual Apps and Desktops, Omnissa Horizon og Azure Virtual Desktop er bygget ved hjelp av forskjellige administrasjonsinfrastruktur og konfigurasjonsteknikker.

Dette innebærer at når man bytter fra en plattform til en annen, kan det være nødvendig å omstrukturere skrivebordspooler, applikasjoner, tilkoblinger og automatiserte verktøy. Applikasjonene selv kan holdes de samme, men implementeringen deres vil variere avhengig av den opprinnelige programvaren.

Hypervisor og infrastrukturavhengigheter

VDI-plattformer krever infrastruktur som kan være vert for og administrere virtuelle skrivebord. Dette kan inkludere spesifikke hypervisorer, sky-, lagrings- eller provisioning-teknologier.

Migrasjonsprosessen kan derfor involvere flere oppgaver:

• Konvertering eller gjenoppbygging av virtuelle maskinbilder
• Rekonfigurering av nettverk, lagring og ressursallokering
• Erstatte leverandørspesifikke distribusjonsverktøy
• V Validering av applikasjonskompatibilitet og ytelse
• Gjenoppretting av tilgjengelighet og katastrofegjenopprettingsmekanismer

Imidlertid strekker ikke konseptet om portabilitet seg alltid til skrivebordsleveringsmiljøet. Den vellykkede migreringen av en virtuell maskin garanterer ikke at det omkringliggende leveringsmiljøet vil fungere uten modifikasjon.

Lisensiering og kontraktsmessige begrensninger

VDI-implementeringer krever vanligvis flere forskjellige lisenser – for operativsystemer, virtualiseringsprodukter, brukerrettigheter, administrasjonsverktøy og tredjepartsapplikasjoner.

Leverandører varierer betydelig når det gjelder pakking eller oppdeling av disse teknologiene, noe som kan gjøre budsjettplanlegging og overgang til nye infrastrukturer mer komplisert.

Dette er spesielt viktig når organisasjoner ønsker å flytte fra en VDI-stabel til en annen, for eksempel fra lokal løsning til skybasert løsning, fordi lisensieringsmodellene for operativsystemer, brukerrettigheter og infrastrukturforbruk kan endre seg dramatisk.

Microsoft Learn-nettstedet gir en innsikt i Azure Virtual Desktop-lisensiering og hvordan det gjelder for forskjellige operativsystemer og bruksområder.

Derfor er det viktig å analysere hele lisensstakken, inkludert konsekvensene av eventuelle kontraktsforpliktelser, når man tar beslutningen, ikke bare abonnementskostnadene.

Applikasjons- og brukerprofilavhengigheter

Windows-applikasjoner kan ha en rekke avhengigheter til operativsystemet, registeret, drivere, plassering eller andre tjenester.

Disse typene applikasjoner virtualiseres vanligvis i VDI-miljøer, med visse aspekter av kravene bygget inn i masterbilder eller innlemmet i avanserte profiladministrasjonsverktøy. Noen selskaper bygger og vedlikeholder sine egne verktøy og skript for å imøtekomme behovene til sine spesifikke applikasjoner i forhold til resten av infrastrukturen.

I slike situasjoner blir det ekstremt utfordrende å skille applikasjoner fra deres støttende elementer, noe som gir betydelig teknisk gjeld og gjør portabilitet ekstremt vanskelig.

Selv om applikasjonen i seg selv er bærbar, er det fortsatt essensielle elementer, som installasjon, konfigurasjon, brukerinnstillinger og databehandling som må gjenopprettes i det nye miljøet. Å forstå forskjellen mellom Windows applikasjonspakking og applikasjonspublisering kan hjelpe IT-team med å skille programvareutplassering krav fra avhengigheter for applikasjonslevering.

Hva er risikoene ved å ha en VDI-leverandørbinding?

Leverandøravhengighet gir spesielle utfordringer når en organisasjon må endre sin infrastrukturstrategi, tilpasse seg lisensieringsendringer eller ta i bruk nye teknologier for applikasjonslevering.

De viktigste risikoene er knyttet til kostnader, arkitektonisk fleksibilitet og driftskontinuitet.

Økende infrastruktur- og lisenskostnader

Et tett koblet VDI-miljø kan gjøre det vanskelig for en organisasjon å optimalisere sine infrastrukturkomponenter.

Når lisensvilkårene endres eller kostnadene for infrastruktur øker, kan det være nødvendig med et storskalaprosjekt for migrering hvis de har til hensikt å bytte leverandører. Dette kan skade deres forhandlingsposisjon og evne til å optimalisere kostnader.

Videre kan det å tilby alle applikasjoner gjennom et fullt virtuelt skrivebord medføre unødvendig overhead for arbeidsbelastninger som kun krever én eller to vindusapplikasjoner.

Applikasjonspublisering er på ingen måte billigere enn VDI: økonomien i de to tilnærmingene vil variere avhengig av tettheten av arbeidsmengder, de nødvendige operativsystemene, infrastrukturens fotavtrykk og kravene til administrasjon og ledelse.

Redusert arkitektonisk fleksibilitet

Organisasjoner som ønsker å ta i bruk en hybrid infrastruktur, erstatte utdaterte servere, bytte mellom hosting-leverandører, eller til og med ta i bruk nye leveranseteknologier, kan oppleve at alternativene deres er begrenset av eksisterende leverandørspesifikke avhengigheter.

En VDI-plattform som er nært knyttet til en infrastrukturstabel kan kreve en fullstendig redesign av applikasjoner ment for levering på andre stabel og hosting-leverandører, noe som dermed bremser den digitale transformasjonsprosessen.

Økt migrasjonskompleksitet

Overgangen mellom VDI-leverandører handler ikke bare om migrering av virtuelle maskiner.

Administratorer må også opprettholde autentisering, brukerprofiler, applikasjonsinnstillinger, utskrift, filtilgang, sikkerhetspolicyer og sesjonsatferd.

Dårlig dokumentasjon av disse avhengighetene kan gjøre prosessen vanskeligere å kvantifisere, teste og utføre uten hendelser.

Større eksponering for leverandørendringer

Produktavvikling, nye lisensieringsmodeller, endringer i støtte eller infrastrukturkrav kan nødvendiggøre en endring i distribusjonsstrategi.

Jo større avhengigheten er av en enkelt distribusjonsplattform, desto høyere er den potensielle driftsmessige påvirkningen av disse endringene for virksomheten.

Å bevare alternative leveringsalternativer kan redusere denne risikoen og skape større fleksibilitet ettersom forretnings- eller teknologibehov endres.

Hvordan kan du redusere risikoene ved å ha en VDI-leverandørbinding?

Å redusere VDI-leverandørlåsing krever en rekke tekniske, arbeidsbelastningsrelaterte og arkitektoniske hensyn.

Ideen er ikke å unngå leverandører, men heller å tillate plattformendringer uten å forstyrre alle andre aspekter av applikasjonslevering.

1. Revidere eksisterende VDI-avhengigheter

Det første steget er å identifisere hva som er kritisk for leveringen av applikasjoner og skrivebord, og hvilke komponenter som er avhengige av teknologi spesifikk for leverandører.

En avhengighetsinventar bør ta opp følgende spørsmål:

Komponent	Spørsmål å undersøke
Tilkoblingsmegler	Kan skrivebords- og applikasjonstildelinger gjenopprettes andre steder?
Hypervisor	Kan virtuelle maskiner og bilder flyttes til alternativ infrastruktur?
Applikasjoner	Krever applikasjoner spesifikke bilder, operativsystemer eller drivere?
Brukerprofiler	Kan innstillinger og data migrere uavhengig?
Autentisering	Er identitetspolicyer knyttet til proprietære integrasjoner?
Lisensiering	Hvilke forpliktelser, tilgangsrettigheter og utgangskostnader gjelder?
Automatisering	Hvilke skript er avhengige av leverandørspesifikke API-er eller verktøy?

Inventaret må også inkludere applikasjonseiere, forretningskritikalitet, gjenopprettingskrav og udokumenterte tilpasninger.

Denne klassifiseringen kan hjelpe IT-ledere med å forstå hvilke avhengigheter som enkelt kan byttes ut, og hvilke som krever betydelig redesign.

2. Separere applikasjonslevering fra skrivebordsinfrastruktur

En av de beste metodene for å redusere behovet for VDI er å sikre at hver applikasjon faktisk krever en så omfattende løsning.

Mens VDI tilbyr virtuelle skrivebord, gir applikasjonspublisering fjernaksess til individuelle applikasjoner uten nødvendigvis å levere en hel skrivebord.

Begge metodene sentraliserer applikasjoner, men på forskjellige måter.

Krav	Full VDI	Sesjonsbasert applikasjonspublisering
Fullstendig personlig tilpasset skrivebord	Godt egnet	Ikke det primære formålet
Individuelle Windows-applikasjoner	Støttet	Godt egnet
Dedikert skrivebords-OS-isolasjon	Tilgjengelig	Generelt bruker delte sesjonsverter
Spesialiserte skrivebordsoppsett	Ofte egnet	Avhenger av kompatibilitet
Sentralisert applikasjonsadministrasjon	Støttet	Støttet
Nettleserbasert tilgang	Plattformavhengig	Tilgjengelig med kompatible løsninger
Levering uten en full VDI-stakk	Ikke generelt	Mulig

Forskjellen er arkitektonisk, ikke funksjonell.

Mange slike VDI-systemer tillater allerede publisering av applikasjoner, så å tillate publisering av applikasjoner hjelper deg ikke nødvendigvis med å unngå leverandørlåsing, med mindre disse applikasjonene kan frakobles fra VDI-kontrollplanet.

Si for eksempel at du har en regnskapsavdeling som trenger tilgang til en Windows økonomisk applikasjon, men ikke trenger sine egne virtuelle skrivebord. Ved å publisere applikasjonen på en Windows-maskin (riktig konfigurert), kan du unngå å måtte få alle til å bruke VDI, samtidig som du fortsatt holder applikasjonsadministrasjonen sentralisert.

På den annen side kan folk som trenger vedvarende skrivebord, der hver bruker har sin egen skrivebordssession, ha behov for full VDI.

3. Vedta modulære og interoperable arkitekturer

Modulære arkitekturer muliggjør utskifting av individuelle elementer uten å forstyrre det overordnede applikasjonsleveringsmiljøet.

IT-team bør prioritere følgende der det er aktuelt:

• Standardisert identitet og autentisering
• Bærbar applikasjonskode og dokumenterte avhengigheter
• Brukerdata separert fra skrivebildebilder
• Infrastruktur som kode: repeterbar distribusjon, automatisering
• Levering som fungerer på tvers av endepunkter og hostingmiljøer

Merk at separasjon av brukerdata fra skrivebilde vil forenkle både migreringer og katastrofegjenoppretting: på samme måte vil infrastruktur som kode hjelpe driften med å gjenskape miljøer med bedre konsistens.

Imidlertid kan selv åpne standarder og automatisering ikke forhindre leverandørlåsing: det er ofte subtile forskjeller i implementeringen mellom ulike leverandørers teknologier, og skript kan inneholde kall til proprietære API-er.

Derfor er målet å unngå unødvendig kobling mellom applikasjons- og infrastrukturkomponenter, ledelse og driftskomponenter.

4. Vurder hybrid applikasjonslevering

Organisasjoner trenger ikke å velge mellom å beholde all sin VDI-infrastruktur eller erstatte den med noe helt annet.

De kan adoptere en hybridstrategi som utnytter ulike arbeidsbelastninger i henhold til deres behov.

En organisasjon kan bruke dedikerte skrivebord for kraftbrukere mens de hoster kompatible forretningsapplikasjoner på delte vindussesjonsverter.

De kunne også levere eldre applikasjoner gjennom nettlesere. For Windows-programvare som ikke lett kan skrives om, forståelse hvordan publisere Windows-programvare på nettet kan hjelpe IT-team med å evaluere nettleserbasert levering som en del av deres hybride strategi.

Lokale applikasjoner beholdes best når sentralisering gjør lite for å forbedre den totale ytelsen.

En slik strategi vil gjøre det mulig for IT-avdelingen å beholde eksisterende investeringer i infrastrukturen mens de går over til nye teknologier i sitt eget tempo.

Utfordringen med denne tilnærmingen er at den skaper ekstra kompleksitet og krever mer omfattende identitetsadministrasjon, sikkerhetstiltak som er enhetlige på tvers av alle plattformer, overvåkingsregler og støtteprosedyrer.

5. Sammenlign de totale kostnadene for leveringsmodeller

Kostnadsbesparelser fra lisensiering alene dikterer ikke kostnadseffektiviteten til en alternativ applikasjonsleveringsarkitektur.

IT-team bør vurdere de totale eierkostnadene, inkludert infrastruktur, programvarekostnader, administrasjon, sikkerhet og migrering.

Kostnadskategori	Vurderingskriterier
Programvare	Lisensiering, abonnementer, støtte og fornyelser
Infrastruktur	Beregning, lagring, nettverk og skyforbruk
Operativsystemer	Windows-lisensiering og gjeldende tilgangsrettigheter
Administrasjon	Provisionering, vedlikehold, overvåking og feilsøking
Sikkerhet	MFA, tilgangskontroller, revisjon og sikkerhetsstyring
Migrasjon	Testing, konfigurasjon, opplæring og distribusjon
Forretningskontinuitet	Tilgjengelighet, sikkerhetskopiering, gjenoppretting og nedetidseksponering

Applikasjonspublisering kan redusere behovet for spesifikke komponenter i et VDI-miljø, men det har sine egne distribusjons- og lisensieringskrav.

For eksempel, tradisjonelle Microsoft Remote Desktop Services (RDS) sesjonsvertkonfigurasjoner ville kreve de riktige RDS-klienttilgangslisensene som beskrevet i Microsofts RDS CAL-dokumentasjon .

Lisensieringskrav bør valideres basert på den faktiske arkitekturen, leveringsproduktet og relevante Microsoft-vilkår og -betingelser.

Målet bør være å minimere totale kostnader samtidig som man leverer den sikkerheten, ytelsen og påliteligheten som er nødvendig for å møte forretningsbehov.

Hva må du gjøre for å migrere bort fra VDI-leverandørens låsing?

Å redusere avhengigheten av leverandører er mye tryggere å gjøre gradvis enn å foreta en fullstendig erstatning av plattformen.

Fasevis migrering gir IT-team muligheten til å bevise alternative metoder for levering samtidig som de opprettholder status quo.

Steg 1: Klassifiser applikasjoner etter leveringskrav

Begynn med å gruppere applikasjoner basert på deres tekniske avhengigheter og sluttbrukerkrav. Tre brede kategorier er spesielt nyttige for å identifisere:

• Applikasjoner som krever fullstendige skrivebord – arbeidsbelastninger som krever et dedikert OS-miljø, spesialkonfigurasjon eller isolasjon på skrivebordsnivå
• Applikasjoner egnet for fjernpublisering – Windows-applikasjoner, kompatible med støttede delte/ dedikerte sesjonsvertmiljøer
• Applikasjoner som er egnet for lokal eller nettleser-nativ tilgang – programvare som ikke lenger krever å kjøres innenfor et VDI-miljø

En slik klassifisering kan hjelpe administratoren med å identifisere kandidater for alternative leveringsmodeller, som ikke krever betydelige tilpasninger.

Steg 2: Velg en lavrisiko pilotarbeidsbelastning

Velg en applikasjon med klart definerte ressurskrav, få avhengigheter og et begrenset brukergrunnlag.

Unngå å starte med forretningskritiske applikasjoner som er avhengige av kompliserte perifere integrasjoner, unike drivere eller sårbare eldre komponenter.

Piloten bør bevise evnen til den alternative infrastrukturen til å tilstrekkelig replikere essensielle funksjoner og brukeropplevelsen fra det originale miljøet.

Steg 3: Valider kompatibilitet, ytelse og sikkerhet

Før du skalerer opp, test funksjoner og driftsfunksjoner i realistiske miljøer.

Migrasjonsprosjektet for applikasjonslevering må inkludere følgende områder i testscenariet:

• Applikasjonsinstallasjon, avhengigheter og lisensiering
• Autentisering, MFA og brukerrettigheter
• Brukerprofiler, innstillinger og filtilgang
• Utskrift, utklippstavle og periferiredireksjon
• Sesjonskonkurranse og ressursforbruk
• Latens, responsivitet og gjenoppretting
• Logging, overvåking og sikkerhetspolicyer
• Sikkerhetskopiering, gjenoppretting og tilbakestillingsprosedyrer

Å starte applikasjoner vellykket garanterer ikke full kompatibilitet.

For eksempel kan en applikasjon fungere fint alene, men feile når flere brukere prøver å kjøre den samtidig eller skrive ut dokumenter på skrivere.

IT-team må utforme nødvendige tester og ytelseskriterier for økter, applikasjoner, sikkerhet og tilbakestillingsfunksjoner.

Steg 4: Migrer applikasjoner i kontrollerte faser

Når piloten oppfyller sine akseptansekriterier, skal distribusjonen skaleres opp basert på forretningsprioritet og teknisk kompleksitet.

Behold den originale leveringsmiljøet gjennom overgangen når det er mulig, slik at administratorer kan sammenligne ytelse, feilsøke effektivt og gå tilbake til etablerte prosesser om nødvendig.

Dokumentere suksesskriterier, tildele ansvar og etablere tilbakeføringsprosedyrer for hver fase av migrasjonen. Disse tiltakene bidrar også til applikasjonsmotstandskraft , og hjelper organisasjoner med å bevare viktige forretningsfunksjoner under endringer i infrastrukturen.

Trinn 5: Gjennomgå gjenværende avhengigheter

Problemet med leverandørlåsing er ikke begrenset til en enkelt forekomst.

Nye applikasjoner, behovet for oppgradering av plattformen, endringer i lisensiering eller operasjonell tilpasning kan skape ytterligere avhengigheter etter at migreringen er fullført.

Derfor er periodiske vurderinger nødvendige for å sikre at applikasjoner kan fortsette å operere på målplattformen, at konfigurasjoner har blitt riktig registrert, og at andre leveringsmetoder forblir tilgjengelige.

Dette vil gjøre det mulig for det nye miljøet å unngå å bli en annen leverandørlås.

I hvilke tilfeller er VDI den gode løsningen å beholde?

Å redusere leverandørlåsing av VDI krever ikke en total utskifting av VDI.

VDI har legitim verdi for scenarier som involverer behovet for dedikerte operativsystemer, vedvarende skrivebord, grafikkintensive applikasjoner eller arbeidsbelastningsisolasjon som delte sesjonsverter ikke kan tilby.

Det er også verdifullt for å levere standardiserte, sentralt administrerte skrivebord med konsistente skrivebordsadministrasjonspolicyer.

Beslutningen om å adoptere en annen arkitektur bør baseres på applikasjonsatferd, sikkerhetsbehov, brukerkrav og økonomiske faktorer.

For de fleste organisasjoner er en distribuert arkitektur mer praktisk enn å tvinge alle applikasjoner inn i den samme leveringsmodellen.

Å beholde VDI for arbeidsmengder som krever det, samtidig som man bruker uavhengig applikasjonspublisering for andre arbeidsmengder, vil tillate reduksjon av VDI-lås uten å gi opp VDI-funksjonene.

Hvordan kan applikasjonslevering forbli fleksibel på lang sikt?

Den langsiktige fleksibiliteten til et system oppnås gjennom evnen til å beholde kontrollen over forholdet mellom applikasjonsinfrastruktur og brukeradgang.

Applikasjoner må utformes på en måte som tillater deres fortsatte drift på potensielt skiftende infrastrukturvertleverandører, hypervisorer eller skrivebordsvirtualiseringsplattformer.

Denne tilnærmingen krever nøye oppmerksomhet til riktig dokumentasjon av avhengigheter, isolering av applikasjonsdata fra leveringsmekanismene, oppbevaring av reproduserbar konfigurasjon, og kontinuerlig undersøkelse av alternative tilnærminger og konfigurasjoner.

For eksempel, mens en applikasjon skrevet for Windows kan migreres for å kjøre på sentralt administrerte Windows-servere i en ny organisasjon som bruker annen hostingprogramvare eller hypervisorer, eller har erstattet programvaren for VDI-brokering, indikerer det ikke at applikasjonen er universelt transportabel.

Applikasjoner må testes for deres evne til å operere på forskjellige infrastrukturer, inkludert variasjoner i det grunnleggende operativsystemet, passende lisensiering, applikasjonsspesifikk kompatibilitet eller ytelsesegenskaper.

En nyttig måling for fleksibilitet er applikasjonens portabilitet mellom betydelig forskjellige miljøer.

Hvis migrering av en applikasjon til en annen, men støttet, infrastruktur krever omfattende omarbeiding av urelaterte elementer på grunn av tilstedeværelsen av mange avhengigheter, indikerer det at det må gjøres mye arbeid før applikasjonen kan betraktes som portabel.

Denne metrikken kan brukes iterativt for gradvis å øke fleksibiliteten til en applikasjons infrastrukturbehov eller gjøre driftsjusteringer uten å kreve fullstendig omarbeiding av selve applikasjonen.

Ser du etter en enklere måte å levere Windows-applikasjoner på?

TSplus Remote Access gir et alternativ for organisasjoner som ønsker å publisere Windows-applikasjoner og levere eksterne skrivebord uten å implementere en tradisjonell full VDI-stabel. Med applikasjonspublisering, HTML5 nettlesertilgang og støtte for Windows-miljøer som er vert på stedet eller i skyen, hjelper det IT-team med å diversifisere leveringsalternativer samtidig som de beholder sentralisert kontroll.

Konklusjon

VDI-leverandørlås blir kostbart når applikasjoner er avhengige av tett integrert infrastruktur, lisensiering og administrasjonssystemer. Kartlegging av disse avhengighetene og innføring av alternative leveringsmetoder kan hjelpe organisasjoner med å beholde kontrollen uten å gi opp VDI helt.

En fleksibel arkitektur gjør det mulig for IT-team å opprettholde passende arbeidsbelastninger på virtuelle skrivebord samtidig som tilgangen til andre forenkles, noe som reduserer migrasjonsrisikoen og bevarer fremtidige alternativer.