VDI Szolgáltató Zárolás: Kockázatok és Megoldások

Bevezetés

A Virtuális Asztali Infrastruktúra (VDI) egyszerűsíti a központosított asztali menedzsmentet, de összekapcsolt komponensei megnehezíthetik a platformok közötti váltást. A saját tulajdonú kapcsolati brókerektől a licencelési korlátozásokig ezek a függőségek korlátozhatják az IT választásokat és növelhetik a migráció bonyolultságát. Ez a cikk megvizsgálja a VDI szolgáltatói zárolás okait és kockázatait, elmagyarázza, hogyan lehet csökkenteni ezeket, és gyakorlati lépéseket vázol fel a Windows alkalmazás szállítás rugalmasságának megőrzésére.

Mi az a VDI szolgáltató zárolás?

A VDI szolgáltatóhoz való kötődés olyan helyzet, amikor egy szervezet rendkívül függővé válik egy adott asztali virtualizációs platformtól, olyan mértékben, hogy a szolgáltatók váltása rendkívül nehéz, költséges vagy zavaró lenne a cég számára.

A VDI komponensek, mint a hypervisorok, kapcsolati brókerek, asztali képek, felhasználói profilok, hitelesítési rendszerek és egyéb kezelőeszközök általában VDI környezetekben kombinálva vannak. Azonban, bár különállóak, speciális gyártói dokumentációra és konfigurációra lehet szükségük ahhoz, hogy sikeresen kölcsönhatásba lépjenek egymással.

Az az oka, hogy bár a Windows nyelven írt alkalmazások általában bárhol működnek, a konkrét VDI környezetre épített asztalok jelentős időt igényelnek az újrakonfiguráláshoz. Ezért a beszállítói zárolás nem leküzdhetetlen probléma, de jelentős akadályokat teremt a platformváltást kereső szervezetek számára.

Mik a VDI környezetekben a beszállítói zárolás okai?

A VDI szolgáltatóhoz való kötődés ritkán egy konkrét technikai korlátozásból ered. Általában a kapcsolódó infrastruktúrára, menedzsment eszközökre, licencelésre és alkalmazáskonfigurációkra való több függőségből fakad.

Saját kapcsolati brókerek és kezelőeszközök

A kapcsolati brókerek felelősek a felhasználói kapcsolatok kezeléséért a virtuális asztalokhoz, míg a menedzsment eszközöket az asztalok és alkalmazások biztosítására, elhelyezésére és karbantartására használják. Az olyan eszközök, mint a Citrix Virtual Apps and Desktops, az Omnissa Horizon és az Azure Virtual Desktop különböző menedzsment infrastruktúrák és konfigurációs technikák felhasználásával készültek.

Ez azt jelenti, hogy amikor egyik platformról a másikra váltunk, szükség lehet az asztali poolok, alkalmazások, kapcsolatok és automatizált eszközök átszervezésére. Az alkalmazások maguk változatlanok maradhatnak, azonban a megvalósításuk eltérő lesz a kezdeti szoftvertől függően.

Hypervisor és Infrastruktúra Függőségek

A VDI platformok olyan infrastruktúrát igényelnek, amely képes virtuális asztalok hosztolására és kezelésére. Ez magában foglalhatja a specifikus hipervizort, felhőt, tárolást vagy provisioning technológiákat.

A migrációs folyamat ezért több feladatot is magában foglalhat:

• Virtuális gép képek átalakítása vagy újjáépítése
• Hálózat, tárolás és erőforrás-elosztás újrakonfigurálása
• A szállító-specifikus ellátási eszközök cseréje
• V alkalmazás-kompatibilitás és teljesítmény érvényesítése
• Elérhetőség és katasztrófa-helyreállítási mechanizmusok újbóli létrehozása

A hordozhatóság fogalma azonban nem mindig terjed ki az asztali szolgáltatási környezetre. Egy virtuális gép sikeres migrálása nem garantálja, hogy a környező szolgáltatási környezet módosítás nélkül működni fog.

Licencelési és Szerződéses Korlátozások

A VDI-implementációk általában több különböző licencet igényelnek – operációs rendszerekhez, virtualizációs termékekhez, felhasználói hozzáférési jogokhoz, kezelőeszközökhöz és harmadik féltől származó alkalmazásokhoz.

A szolgáltatók jelentősen eltérnek ezen technológiák csomagolásában vagy szétbontásában, ami bonyolultabbá teheti a költségvetés tervezését és az új infrastruktúrákra való átállást.

Ez különösen fontos, amikor a szervezetek egyik VDI halmazról a másikra szeretnének áttérni, például helyben telepített megoldásról felhőalapú megoldásra, mert az operációs rendszerek, a felhasználói jogosultságok és az infrastruktúra-fogyasztás licencmodellei drámaian megváltozhatnak.

A Microsoft Learn weboldal biztosít egy az Azure Virtual Desktop licencelésének áttekintése és hogyan alkalmazható különböző operációs rendszerekre és felhasználási esetekre.

Ezért elengedhetetlen, hogy elemezzük az egész licencelési struktúrát, beleértve bármilyen szerződéses kötelezettség következményeit is, amikor a döntést meghozzuk, nemcsak az előfizetési költségeket.

Alkalmazás- és Felhasználói Profil Függőségek

A Windows alkalmazásoknak számos függősége lehet az operációs rendszertől, a regisztertől, az illesztőprogramoktól, a helytől vagy más szolgáltatásoktól.

Ezeket a típusú alkalmazásokat általában VDI környezetekben virtualizálják, bizonyos követelmények aspektusait a mesterképekbe építik be, vagy fejlett profilkezelő eszközökbe integrálják. Néhány vállalat saját eszközöket és szkripteket készít és tart fenn, hogy a saját alkalmazásaik igényeit a többi infrastruktúrához viszonyítva kezeljék.

Ezekben a helyzetekben rendkívül nehézzé válik az alkalmazások elválasztása a támogató elemeiktől, jelentős technikai adósságot okozva, és rendkívül megnehezítve a hordozhatóságot.

Még ha az alkalmazás maga hordozható is, akkor is vannak alapvető elemek, mint például a telepítés, a konfiguráció, a felhasználói beállítások és az adatkezelés, amelyeket újra kell állítani az új környezetben. A megkülönböztetés megértése a Windows alkalmazáscsomagolás és alkalmazáskiadás segíthet az IT csapatoknak elkülöníteni a szoftvertelepítési követelményeket az alkalmazáskézbesítési függőségektől.

Mik a kockázatai a VDI szolgáltatóhoz való kötődésnek?

A beszállítói függőség különös nehézségeket jelent, amikor egy szervezetnek meg kell változtatnia az infrastruktúra stratégiáját, alkalmazkodnia kell a licencváltozásokhoz vagy új alkalmazás-átadási technológiákat kell bevezetnie.

A főbb kockázatok a költségekkel, az építészeti rugalmassággal és a működési folytonossággal kapcsolatosak.

Növekvő infrastruktúra- és licencköltségek

Egy szorosan összekapcsolt VDI környezet megnehezítheti egy szervezet számára az infrastruktúra komponenseinek optimalizálását.

Amikor a licencfeltételek megváltoznak vagy az infrastruktúra költségei emelkednek, ez nagyszabású migrációs projektet tehet szükségessé, ha szándékukban áll szolgáltatót váltani. Ez károsíthatja a tárgyalási pozíciójukat és a költségek optimalizálásának képességét.

Továbbá, az összes alkalmazás biztosítása egy teljes virtuális asztalon felesleges terhet jelenthet azok számára a munkaterhelések számára, amelyek csak egy vagy két ablakos alkalmazást igényelnek.

Az alkalmazáskiadás egyáltalán nem olcsóbb, mint a VDI: a két megközelítés gazdasági szempontjai a munkaterhelések sűrűségétől, a szükséges operációs rendszerektől, az infrastruktúra lábnyomától, valamint az adminisztrációs és kezelési követelményektől függenek.

Csökkentett építészeti rugalmasság

A hibrid infrastruktúra bevezetésére törekvő szervezetek, az elavult szerverek cseréjére, a szolgáltatók közötti váltásra, vagy akár új szállítási technológiák alkalmazására törekvő szervezetek lehet, hogy lehetőségeik korlátozottak a meglévő beszállító-specifikus függőségek miatt.

Egy VDI platform, amely szorosan kapcsolódik egy infrastruktúra halmazhoz, teljes újratervezést igényelhet az olyan alkalmazások számára, amelyeket más halmazokon és hosztoló szolgáltatóknál kívánnak szállítani, ezáltal lassítva a digitális átalakulás folyamatát.

Növekvő migrációs összetettség

A VDI szolgáltatók átállása nem csupán a virtuális gépek migrációjáról szól.

A rendszergazdáknak meg kell őrizniük az azonosítást, a felhasználói profilokat, az alkalmazásbeállításokat, a nyomtatást, a fájlhozzáférést, a biztonsági irányelveket és a munkamenet viselkedését.

Ezeknek a függőségeknek a gyenge dokumentációja megnehezítheti a folyamat mennyiségének, tesztelésének és esemény nélküli végrehajtásának meghatározását.

Nagyobb kitettség a szállítói változásoknak

A termékek megszüntetése, új licencmodellek, támogatási változások vagy infrastruktúra követelmények szükségessé tehetik a telepítési stratégia megváltoztatását.

Minél nagyobb a függőség egyetlen telepítési platformtól, annál nagyobb a potenciális működési hatás ezeknek a változásoknak az üzletre.

Az alternatív szállítási lehetőségek megőrzése csökkentheti ezt a kockázatot, és nagyobb rugalmasságot teremthet, ahogy az üzleti vagy technológiai igények változnak.

Hogyan csökkentheti a VDI szolgáltató által okozott zárolás kockázatait?

A VDI szolgáltatóktól való függőség csökkentéséhez technikai, munkaterheléshez kapcsolódó és architekturális szempontok sorozatára van szükség.

Az ötlet nem az eladók elkerülése, hanem inkább a platformváltozások lehetővé tétele anélkül, hogy megzavarnánk az alkalmazás szállításának egyéb aspektusait.

1. Audit meglévő VDI függőségek

Az első lépés annak meghatározása, hogy mi kritikus az alkalmazások és asztali számítógépek szállításához, és mely összetevők függenek a beszállítókra jellemző technológiától.

A függőségi leltárnak a következő kérdéseket kell megválaszolnia:

Komponens	Kérdések megvizsgálásra
Kapcsolati bróker	Lehet-e az asztali és alkalmazás hozzárendeléseket máshol újra létrehozni?
Hypervisor	A virtuális gépek és képek áthelyezhetők alternatív infrastruktúrára?
Alkalmazások	Az alkalmazásokhoz szükségesek specifikus képek, operációs rendszerek vagy illesztőprogramok?
Felhasználói profilok	A beállítások és az adatok függetlenül migrálhatók?
Hitelesítés	A személyazonossági politikák kapcsolódnak a szabadalmaztatott integrációkhoz?
Licencelés	Milyen kötelezettségek, hozzáférési jogok és kilépési költségek vonatkoznak?
Automatizálás	Melyik szkript támaszkodik a gyártó-specifikus API-kra vagy eszközökre?

A leltárnak tartalmaznia kell az alkalmazás tulajdonosait, az üzleti fontosságot, a helyreállítási követelményeket és a dokumentálatlan testreszabásokat.

Ez a besorolás segíthet az IT menedzsereknek megérteni, hogy mely függőségek cserélhetők könnyen, és melyek igényelnek jelentős újratervezést.

2. Az alkalmazás-átadás elkülönítése a desktop infrastruktúrától

Az egyik legjobb módszer a VDI iránti igény csökkentésére, ha biztosítjuk, hogy minden alkalmazás valóban megköveteli ezt a bonyolult megoldást.

Míg a VDI virtuális asztalokat kínál, az alkalmazáskiadás biztosít távoli hozzáférés egyedi alkalmazásokhoz anélkül, hogy feltétlenül egy teljes asztalt szállítanánk.

Mindkét módszer központosítja az alkalmazásokat, de különböző módon.

Követelmény	Teljes VDI	Ülésalapú alkalmazás közzététele
Teljesen személyre szabott asztal	Jól illeszkedik	Nem a fő cél
Egyedi Windows alkalmazások	Támogatott	Jól illeszkedik
Dedikált asztali operációs rendszer izoláció	Elérhető	Általában megosztott munkamenet-hosztokat használ.
Szakosított asztali konfigurációk	Gyakran alkalmas	A kompatibilitástól függ
Központosított alkalmazáskezelés	Támogatott	Támogatott
Böngészőalapú hozzáférés	Platform-függő	Kompatibilis megoldásokkal elérhető
Teljes VDI stack nélküli szállítás	Nem általában	Lehetséges

A különbség architekturális, nem funkcionális.

Sok ilyen VDI rendszer már lehetővé teszi az alkalmazások közzétételét, így az alkalmazások közzétételének engedélyezése nem feltétlenül segít elkerülni a beszállítói zárolást, hacsak ezek az alkalmazások nem választhatók le a VDI vezérlő síkról.

Mondjuk például, hogy van egy könyvelési osztály, amelynek szüksége van hozzáférésre egy Windows pénzügyi alkalmazáshoz, de nincs szüksége saját virtuális asztalokra. Az alkalmazás Windows környezetben (megfelelően beállítva) történő közzétételével elkerülhetné, hogy mindenkinek a VDI-t kelljen használnia, miközben az alkalmazás adminisztrációját központosítva tarthatja.

Másrészt azoknak az embereknek, akiknek állandó asztalok szükségesek, ahol minden felhasználónak saját asztali munkamenete van, szükségük lehet teljes VDI-ra.

3. Fogadjon el moduláris és interoperábilis architektúrákat

A moduláris architektúrák lehetővé teszik az egyes elemek cseréjét anélkül, hogy megzavarnák az általános alkalmazás-átviteli környezetet.

Az IT csapatoknak a következőket kell előnyben részesíteniük, ahol alkalmazható:

• Standardizált Azonosítás és Hitelesítés
• Hordozható alkalmazás kód és dokumentált függőségek
• Felhasználói adatok elválasztva az asztali képektől
• Infrastruktúra mint kód: ismételhető telepítés, automatizálás
• Szállítás, amely működik az végpontok és a hosztolási környezetek között

Vegye figyelembe, hogy a felhasználói adatok és az asztali képek elkülönítése egyszerűsíti a migrációkat és a katasztrófa-helyreállítást: hasonlóképpen, az infrastruktúra kód formájában segíti a műveleteket a környezetek jobb következetességgel történő újraalkotásában.

Azonban még a nyílt szabványok és az automatizálás sem akadályozhatja meg a beszállítói zárolást: gyakran finom eltérések vannak a különböző beszállítók technológiáinak megvalósítása között, és a szkriptek tartalmazhatnak hívásokat a szabadalmaztatott API-khoz.

Ezért a cél az, hogy elkerüljük a felesleges összekapcsolódást az alkalmazás és az infrastruktúra komponensei, a menedzsment és a működési komponensek között.

4. Fontolja meg a hibrid alkalmazás-szállítást

A szervezeteknek nem kell választaniuk a teljes VDI infrastruktúrájuk megtartása és valami teljesen másra való cseréje között.

Olyan hibrid stratégiát alkalmazhatnának, amely különböző munkaterheléseket használ ki az igényeik szerint.

Egy szervezet dedikált asztalokat használhat a nagy teljesítményű felhasználók számára, miközben kompatibilis üzleti alkalmazásokat hosztol megosztott Windows munkamenet-hosztokon.

Örökség alkalmazásokat is szállíthatnak böngészőkön keresztül. A Windows szoftverek esetében, amelyeket nem lehet könnyen újraírásra venni, a megértés hogyan lehet Windows szoftvert közzétenni a weben segíthet az IT csapatoknak értékelni a böngészőalapú szolgáltatást a hibrid stratégiájuk részeként.

A helyi alkalmazások a legjobban akkor maradnak meg, ha a központosítás nem javítja jelentősen az általános teljesítményt.

Ez a stratégia lehetővé teszi az IT osztály számára, hogy megőrizze meglévő beruházásait az infrastruktúrájában, miközben saját tempójában áttér az új technológiákra.

A megközelítés kihívása az, hogy további bonyolultságot teremt, és átfogóbb identitáskezelést, minden platformra egységes biztonsági intézkedéseket, figyelési szabályokat és támogatási eljárásokat igényel.

5. Hasonlítsa össze a szállítási modellek összköltségét

A licencelési megtakarítások önmagukban nem határozzák meg egy alternatív alkalmazás-átadási architektúra költséghatékonyságát.

Az IT csapatoknak értékelniük kell a teljes tulajdonlási költséget, beleértve az infrastruktúrát, a szoftverköltségeket, az adminisztrációt, a biztonságot és a migrációt.

Költségkategória	Értékelési kritériumok
Szoftver	Licencelés, előfizetések, támogatás és megújítások
Infrastruktúra	Számítás, tárolás, hálózatépítés és felhőfogyasztás
Operációs rendszerek	Windows licencelés és alkalmazható hozzáférési jogok
Adminisztráció	Provisionálás, karbantartás, megfigyelés és hibaelhárítás
Biztonság	MFA, hozzáférés-ellenőrzések, auditálás és biztonsági menedzsment
Migráció	Tesztelés, konfiguráció, képzés és telepítés
Üzletmenet-folytonosság	Elérhetőség, biztonsági mentés, helyreállítás és leállási kitettség

Az alkalmazáskiadás csökkentheti a VDI környezetben szükséges specifikus komponensek számát, de saját telepítési és licencelési követelményei vannak.

Például a hagyományos Microsoft Remote Desktop Services (RDS) munkamenet-hosztolási konfigurációkhoz a megfelelő RDS kliens hozzáférési licencek szükségesek, ahogy azt a következőben leírták Microsoft RDS CAL dokumentáció .

A licencelési követelményeket az aktuális architektúra, a szállított termék és a vonatkozó Microsoft feltételek alapján kell érvényesíteni.

A cél az összköltségek minimalizálása, miközben biztosítjuk a szükséges biztonságot, teljesítményt és megbízhatóságot az üzleti igények kielégítéséhez.

Mit kellene tenned a VDI szolgáltató által okozott zárolás elkerüléséhez?

A beszállítói függőség csökkentése sokkal biztonságosabb fokozatosan, mint a platform teljes cseréje.

A fokozatos migráció lehetőséget ad az IT csapatoknak, hogy bizonyítsák az alternatív szállítási módszereket, miközben fenntartják a status quo-t.

1. lépés: Az alkalmazások osztályozása a szállítási követelmények szerint

Kezdje az alkalmazások csoportosításával technikai függőségeik és végfelhasználói igényeik alapján. Három széles kategória különösen hasznos az azonosításhoz:

• Teljes asztalokat igénylő alkalmazások – olyan munkaterhelések, amelyek dedikált operációs rendszer környezetet, különleges konfigurációt vagy asztali szintű elszigetelést igényelnek.
• Alkalmazások távoli közzétételre – Windows alkalmazások, amelyek kompatibilisek a támogatott megosztott/ dedikált munkamenet-hoszt környezetekkel
• Helyi vagy böngésző-natív hozzáférésre alkalmas alkalmazások – szoftver, amely már nem igényli a VDI környezetben való futtatást.

Ez a besorolás segíthet az adminisztrátornak az alternatív szállítási modellekhez való jelöltek azonosításában, amelyek nem igényelnek jelentős alkalmazkodást.

2. lépés: Válasszon egy alacsony kockázatú pilot munkaterhelést

Válasszon egy alkalmazást, amelynek világosan meghatározott erőforrásigényei, kevés függősége és korlátozott felhasználói köre van.

Kerülje a bonyolult perifériás integrációkra, egyedi illesztőprogramokra vagy sebezhető örökölt komponensekre támaszkodó üzleti szempontból kritikus alkalmazásokkal való indítást.

A pilótának bizonyítania kell az alternatív infrastruktúra képességét, hogy megfelelően replikálja az eredeti környezet alapvető funkcióit és felhasználói élményét.

3. lépés: A kompatibilitás, a teljesítmény és a biztonság érvényesítése

Mielőtt a méretezésre kerülne sor, tesztelje a funkciókat és a működési jellemzőket reális környezetben.

Az alkalmazás-átadási migrációs projektnek a következő területeket kell tartalmaznia a tesztforgatókönyvben:

• Alkalmazás telepítése, függőségek és licencelés
• Hitelesítés, MFA és felhasználói jogosultságok
• Felhasználói profilok, beállítások és fájlhozzáférés
• Nyomtatás, vágólap és perifériák átirányítása
• Session egyidejűség és erőforrás-felhasználás
• Késleltetés, válaszidő és újracsatlakozás
• Naplózás, figyelés és biztonsági irányelvek
• Biztonsági másolat, helyreállítás és visszaállítási eljárások

Az alkalmazások sikeres indítása nem garantálja a teljes kompatibilitást.

Például egy alkalmazás jól működhet önállóan, de megbukhat, amikor több felhasználó próbálja egyszerre futtatni vagy dokumentumokat nyomtatni a nyomtatókon.

Az IT csapatoknak meg kell tervezniük a szükséges teszteket és teljesítménykritériumokat az ülések, alkalmazások, biztonság és visszaállítási funkciók számára.

4. lépés: Alkalmazások migrálása ellenőrzött fázisokban

Miután a pilóta teljesíti az elfogadási kritériumait, a telepítést a üzleti prioritás és a technikai összetettség alapján bővítsük.

A szállítási környezet megőrzése a váltás során, amikor lehetséges, lehetővé téve az adminisztrátorok számára a teljesítmény összehasonlítását, a hatékony hibaelhárítást és a szükség esetén a megszokott folyamatokhoz való visszatérést.

A siker kritériumainak dokumentálása, a felelősségek kijelölése és a visszaállítási eljárások megállapítása a migráció minden szakaszához. Ezek az intézkedések szintén hozzájárulnak a alkalmazás ellenállóság segítve a szervezeteket az alapvető üzleti funkciók megőrzésében az infrastruktúra változásai során.

Lépés 5: A hátralévő függőségek áttekintése

A beszállítói zárolás problémája nem korlátozódik egyetlen esetre sem.

Új alkalmazások, a platform frissítésének szükségessége, a licencelési vagy működési testreszabások változásai további függőségeket hozhatnak létre a migráció befejezése után.

Ezért időszakos felülvizsgálatokra van szükség annak biztosítására, hogy az alkalmazások továbbra is működhessenek a célplatformon, hogy a konfigurációk megfelelően legyenek rögzítve, és hogy más szállítási módok továbbra is elérhetők maradjanak.

Ez lehetővé teszi az új környezet számára, hogy elkerülje, hogy egy újabb beszállító által történő zárolás áldozatává váljon.

Milyen esetben a VDI a jó megoldás?

A VDI szolgáltatóhoz való kötődés csökkentése nem igényel a VDI teljes körű cseréjét.

A VDI jogos értékkel bír olyan forgatókönyvekben, amelyek dedikált operációs rendszerek, állandó asztalok, grafikai igényes alkalmazások vagy olyan munkaterhelés-izoláció szükségességét vonják maguk után, amelyet a megosztott munkamenet-hosztok nem tudnak biztosítani.

Ez is értékes a szabványosított, központilag kezelt asztali számítógépek biztosításához, amelyek következetes asztali kezelési politikákkal rendelkeznek.

A különböző architektúra elfogadásáról szóló döntést az alkalmazás viselkedése, a biztonsági igények, a felhasználói követelmények és a gazdasági tényezők alapján kell meghozni.

A legtöbb szervezet számára a disztribúciós architektúra praktikusabb, mint az összes alkalmazás egyetlen szállítási modellbe kényszerítése.

A VDI megtartása az olyan munkaterhelésekhez, amelyek megkövetelik, miközben független alkalmazáskiadást használunk más munkaterhelésekhez, lehetővé tenné a VDI zárolás csökkentését anélkül, hogy feladnánk a VDI képességeit.

Hogyan maradhat rugalmas hosszú távon az alkalmazás-átadás?

A rendszer hosszú távú rugalmassága az alkalmazás-infrastruktúra-kapcsolat és a felhasználói hozzáférés feletti kontroll megőrzésének képességén keresztül érhető el.

Az alkalmazásokat úgy kell megtervezni, hogy lehetővé tegyék folyamatos működésüket a potenciálisan változó infrastruktúra, hosztoló szolgáltatók, hipervizorok vagy asztali virtualizációs platformok esetén.

Ez a megközelítés szoros figyelmet igényel a függőségek megfelelő dokumentálására, az alkalmazásadatok elszigetelésére a szállítási mechanizmusaitól, a reprodukálható konfigurációk megőrzésére, valamint az alternatív megközelítések és konfigurációk folyamatos vizsgálatára.

Például, míg egy Windowsra írt alkalmazás átkerülhet egy új szervezet központilag kezelt Windows szervereire, amely különböző hosztoló szoftvereket vagy hipervizorokat használ, vagy amely lecserélte a VDI közvetítő szoftverét, ez nem jelenti azt, hogy az alkalmazás univerzálisan szállítható.

Az alkalmazásokat tesztelni kell a különböző infrastruktúrákon való működési képességük szempontjából, beleértve az alap operációs rendszer változatait, a megfelelő licencelést, az alkalmazás-specifikus kompatibilitást vagy a teljesítményjellemzőket.

Egy hasznos mutató a rugalmasság szempontjából az alkalmazás hordozhatósága jelentősen eltérő környezetek között.

Ha egy alkalmazás migrálása egy másik, de támogatott infrastruktúrára sok független elem átdolgozását igényli a sok függőség miatt, az azt jelzi, hogy sok munkát kell elvégezni, mielőtt az alkalmazás hordozhatónak tekinthető.

Ez a mutató iteratívan alkalmazható az alkalmazás infrastruktúrájának igényeinek fokozatos növelésére, vagy működési kiigazítások végrehajtására anélkül, hogy az alkalmazás teljes újragondolására lenne szükség.

Egyszerűbb módot keres a Windows alkalmazások szállítására?

TSplus Távhozzáférés alternatívát kínál olyan szervezetek számára, amelyek Windows alkalmazásokat szeretnének közzétenni és távoli asztalokat biztosítani anélkül, hogy hagyományos teljes VDI halmazt telepítenének. Az alkalmazás közzétételével, HTML5 böngésző hozzáféréssel és a helyben vagy felhőben hosztolt Windows környezetek támogatásával segíti az IT csapatokat a szállítási lehetőségek diverzifikálásában, miközben megőrzi a központosított irányítást.

Következtetés

A VDI szolgáltatóhoz való kötődés költségessé válik, amikor az alkalmazások szorosan integrált infrastruktúrára, licencelési és menedzsment rendszerekre támaszkodnak. E függőségek feltérképezése és alternatív szállítási módszerek bevezetése segíthet a szervezeteknek megőrizni az irányítást anélkül, hogy teljesen feladnák a VDI-t.

A rugalmas architektúra lehetővé teszi az IT csapatok számára, hogy megfelelő terheléseket tartsanak fenn a virtuális asztalokon, miközben egyszerűsítik a hozzáférést másokhoz, csökkentve a migrációs kockázatot és megőrizve a jövőbeli lehetőségeket.