VDI-toimittajan lukitus: riskit ja ratkaisut

Johdanto

Virtuaalinen työpöytäinfrastruktuuri (VDI) yksinkertaistaa keskitettyä työpöydän hallintaa, mutta sen toisiinsa liittyvät komponentit voivat tehdä alustojen vaihtamisesta vaikeaa. Omistusoikeudelliset yhteysvälittäjät ja lisenssirajoitukset voivat rajoittaa IT-valintoja ja lisätä siirtymisen monimutkaisuutta. Tämä artikkeli tarkastelee VDI-toimittajan lukkiutumisen syitä ja riskejä, selittää, miten niitä voidaan vähentää, ja hahmottaa käytännön vaiheita Windows-sovellusten toimituksen joustavuuden säilyttämiseksi.

Mikä on VDI-toimittajan lukitus?

VDI-toimittajan lukitus on tilanne, jossa organisaatio tulee äärimmäisen riippuvaiseksi tietystä työpöytävirtualisointialustasta siihen pisteeseen, että toimittajan vaihtaminen olisi äärimmäisen haastavaa, kallista tai häiritsevää yritykselle.

VDI-komponentit, kuten hypervisorit, yhteysvälittäjät, työpöytäkuvat, käyttäjäprofiilit, todennusjärjestelmät ja muut hallintatyökalut, yhdistetään yleensä VDI-ympäristöissä. Kuitenkin, vaikka ne ovat erillisiä, ne saattavat vaatia erityisiä toimittajakohtaisia asiakirjoja ja konfigurointia toimiakseen onnistuneesti yhdessä.

Syynä on se, että vaikka Windows-kielellä kirjoitetut sovellukset yleensä toimivat missä tahansa, tietokoneet, jotka on rakennettu tiettyä VDI-ympäristöä varten, vaativat merkittävästi aikaa uudelleenkonfiguroimiseen. Siksi toimittajalukitus ei ole ylittämätön ongelma, mutta se luo merkittäviä esteitä organisaatioille, jotka pyrkivät vaihtamaan alustoja.

Mitä ovat syyt toimittajalukitukseen VDI-ympäristöissä?

VDI-toimittajan lukitus johtuu harvoin yhdestä erityisestä teknisestä rajoituksesta. Se johtuu yleensä useista riippuvuuksista liittyvään infrastruktuuriin, hallintatyökaluihin, lisensointiin ja sovelluskokoonpanoihin.

Omistautuneet yhteysvälittäjät ja hallintatyökalut

Yhteysvälittäjät ovat vastuussa käyttäjäyhteyksien hallinnasta virtuaalisiin työpöytiin, kun taas hallintatyökaluja käytetään työpöytien ja sovellusten provisionointiin, sijoittamiseen ja ylläpitämiseen. Työkalut kuten Citrix Virtual Apps and Desktops, Omnissa Horizon ja Azure Virtual Desktop on rakennettu käyttäen erilaisia hallinta-infrastruktuureja ja konfigurointitekniikoita.

Tämä tarkoittaa, että siirryttäessä yhdeltä alustalta toiselle voi olla tarpeen uudelleenjärjestellä työpöytäryhmiä, sovelluksia, yhteyksiä ja automatisoituja työkaluja. Itse sovellukset voidaan pitää samoina, mutta niiden toteutus vaihtelee alkuperäisestä ohjelmistosta riippuen.

Hypervisor ja infrastruktuuririippuvuudet

VDI-alustat vaativat infrastruktuurin, joka pystyy isännöimään ja hallitsemaan virtuaalisia työpöytiä. Tämä voi sisältää erityisiä hypervisor-, pilvi-, tallennus- tai provisionointiteknologioita.

Siirtoprosessi saattaa siten sisältää useita tehtäviä:

• Virtuaalikonekuvien muuntaminen tai uudelleenrakentaminen
• Verkko-, tallennus- ja resurssijakelun uudelleenkonfigurointi
• Korvataan toimittajakohtaiset varausvälineet
• V Sovelluksen yhteensopivuuden ja suorituskyvyn validoiminen
• Saatavuuden ja katastrofipalautusmekanismien uudelleenluominen

Kuitenkin, kannettavuuden käsite ei aina ulotu työpöytätoteutusympäristöön. Virtuaalikoneen onnistunut siirto ei takaa, että ympäröivä toteutusympäristö toimii ilman muutoksia.

Lisensointi ja sopimukselliset rajoitukset

VDI-implementoinnit vaativat tyypillisesti useita erilaisia lisenssejä – käyttöjärjestelmille, virtualisointituotteille, käyttäjäoikeuksille, hallintatyökaluille ja kolmannen osapuolen sovelluksille.

Myyjät eroavat merkittävästi näiden teknologioiden paketoimisessa tai erottamisessa, mikä voi tehdä budjetoinnista ja siirtymisestä uusiin infrastruktuureihin monimutkaisempaa.

Tämä on erityisen tärkeää, kun organisaatiot haluavat siirtyä yhdestä VDI-pinoista toiseen, esimerkiksi paikallisesta pilvipohjaiseen ratkaisuun, koska käyttöjärjestelmien, käyttäjäoikeuksien ja infrastruktuurin kulutuksen lisensointimallit voivat muuttua dramaattisesti.

Microsoft Learn -verkkosivusto tarjoaa yhden näkemyksiä Azure Virtual Desktop -lisensoinnista ja miten se soveltuu eri käyttöjärjestelmiin ja käyttötapauksiin.

Siksi on olennaista analysoida koko lisensointikokonaisuus, mukaan lukien mahdollisten sopimusvelvoitteiden vaikutukset, päätöstä tehtäessä, ei vain tilauskustannuksia.

Sovellus- ja käyttäjäprofiiliriippuvuudet

Windows-sovelluksilla voi olla useita riippuvuuksia käyttöjärjestelmästä, rekisteristä, ohjaimista, sijainnista tai muista palveluista.

Nämä sovellustyypit virtualisoidaan yleisesti VDI-ympäristöissä, ja tietyt vaatimusten osa-alueet sisällytetään master-kuviin tai edistyneisiin profiilihallintatyökaluihin. Jotkut yritykset rakentavat ja ylläpitävät omia työkalujaan ja skriptejä vastatakseen erityisten sovellustensa tarpeisiin suhteessa muuhun infrastruktuuriin.

Näissä tilanteissa on äärimmäisen haastavaa erottaa sovellukset niiden tukielementeistä, mikä aiheuttaa merkittävää teknistä velkaa ja tekee siirrettävyydestä äärimmäisen vaikeaa.

Vaikka sovellus itsessään onkin siirrettävä, on silti olemassa olennaisia elementtejä, kuten asennus, konfigurointi, käyttäjäasetukset ja tietojen hallinta, jotka on jälleenrakennettava uudessa ympäristössä. Erojen ymmärtäminen Windows-sovellusten pakkaaminen ja sovellusten julkaiseminen voi auttaa IT-tiimejä erottamaan ohjelmiston käyttöönoton vaatimukset sovellustoimituksen riippuvuuksista.

Mitä riskejä on VDI-toimittajan lukitsemisessa?

Toimittajariippuvuus aiheuttaa erityisiä vaikeuksia, kun organisaation on muutettava infrastruktuuristrategiaansa, sopeuduttava lisenssimuutoksiin tai omaksuttava uusia sovellusten toimitusteknologioita.

Pääriskit liittyvät kustannuksiin, arkkitehtoniseen joustavuuteen ja toiminnan jatkuvuuteen.

Kohottavat infrastruktuuri- ja lisenssikustannukset

Tiiviisti sidottu VDI-ympäristö voi vaikeuttaa organisaation infrastruktuurikomponenttien optimointia.

Kun lisenssiehdot muuttuvat tai infrastruktuurin kustannukset nousevat, se voi edellyttää laajamittaista migraatioprojektia, jos he aikovat vaihtaa palveluntarjoajia. Tämä voi heikentää heidän neuvotteluasemaansa ja kykyään optimoida kustannuksia.

Lisäksi kaikkien sovellusten tarjoaminen täydellisen virtuaalisen työpöydän kautta voi aiheuttaa tarpeetonta ylikuormitusta työkuormille, jotka tarvitsevat vain yhden tai kaksi ikkunasovellusta.

Sovellusten julkaiseminen ei suinkaan ole halvempaa kuin VDI: näiden kahden lähestymistavan taloudellisuus vaihtelee työkuormien tiheyden, tarvittavien käyttöjärjestelmien, infrastruktuurin jalanjäljen sekä hallinta- ja johtamisvaatimusten mukaan.

Vähentynyt arkkitehtoninen joustavuus

Organisaatiot, jotka pyrkivät ottamaan käyttöön hybridin infrastruktuurin, korvaamaan vanhentuneita palvelimia, vaihtamaan hosting-palveluntarjoajien välillä tai jopa omaksumaan uusia toimitusteknologioita, saattavat huomata, että heidän vaihtoehtonsa ovat rajoitettuja olemassa olevista toimittajakohtaisista riippuvuuksista.

VDI-alusta, joka on tiiviisti sidoksissa yhteen infrastruktuuripinoon, saattaa vaatia sovellusten täydellistä uudelleen suunnittelua, jotka on tarkoitettu toimitettavaksi muilla pinoilla ja hosting-palveluntarjoajilla, mikä hidastaa digitaalisen transformaation prosessia.

Lisääntynyt siirtokompleksisuus

VDI-toimittajan siirtymät eivät koske vain virtuaalikoneiden siirtoa.

Järjestelmänvalvojien on myös säilytettävä todennus, käyttäjäprofiilit, sovelluksen asetukset, tulostus, tiedostojen käyttö, turvallisuuspolitiikat ja istuntojen käyttäytyminen.

Heikko dokumentaatio näistä riippuvuuksista voi tehdä prosessista vaikeampaa kvantifioida, testata ja toteuttaa ilman ongelmia.

Suurempi altistus toimittajamuutoksille

Tuotteen lopettaminen, uudet lisensointimallit, tukimuutokset tai infrastruktuurivaatimukset voivat edellyttää muutosta käyttöönotto-strategiassa.

Mitä suurempi riippuvuus yhdestä käyttöönottoalustasta, sitä suurempi on näiden muutosten mahdollinen vaikutus liiketoimintaan.

Vaihtoehtoisten toimitusvaihtoehtojen säilyttäminen voi vähentää tätä riskiä ja luoda suurempaa joustavuutta liiketoiminnan tai teknologian tarpeiden muuttuessa.

Miten voit vähentää VDI-toimittajan lukkiutumisen riskejä?

VDI-toimittajan lukituksen vähentäminen vaatii joukon teknisiä, työkuormaan liittyviä ja arkkitehtonisia huomioita.

Ajatuksena ei ole välttää myyjiä, vaan pikemminkin mahdollistaa alustan muutokset häiritsemättä kaikkia muita sovellustoimituksen osa-alueita.

1. Tarkista olemassa olevat VDI-riippuvuudet

Ensimmäinen askel on tunnistaa, mikä on kriittistä sovellusten ja työpöytien toimituksessa, ja mitkä komponentit ovat riippuvaisia toimittajakohtaisesta teknologiasta.

Riippuvuuksien inventaarion tulisi käsitellä seuraavia kysymyksiä:

Komponentti	Kysymyksiä tutkittavaksi
Yhteysvälittäjä	Voidaanko työpöytä- ja sovellusmääritykset luoda uudelleen muualla?
Hypervisor	Voivatko virtuaalikoneet ja kuvat siirtyä vaihtoehtoiseen infrastruktuuriin?
Sovellukset	Vaativatko sovellukset erityisiä kuvia, käyttöjärjestelmiä tai ohjaimia?
Käyttäjäprofiilit	Voiko asetuksia ja tietoja siirtää itsenäisesti?
Todennus	Onko identiteettipolitiikka sidottu omiin integraatioihin?
Lisensointi	Mitä sitoumuksia, käyttöoikeuksia ja poistumiskustannuksia sovelletaan?
Automaatio	Mitkä skriptit riippuvat toimittajakohtaisista API:ista tai työkaluista?

Inventaarion on myös sisällettävä sovellusten omistajat, liiketoiminnan kriittisyys, palautusvaatimukset ja dokumentoimattomat mukautukset.

Tämä luokittelu voi auttaa IT-päälliköitä ymmärtämään, mitkä riippuvuudet voidaan helposti korvata ja mitkä vaativat merkittävää uudelleensuunnittelua.

2. Erottele sovellustoimitus työpöytäinfrastruktuurista

Yksi parhaista tavoista vähentää VDI:n tarvetta on varmistaa, että kukin sovellus todella vaatii näin monimutkaista ratkaisua.

Vaikka VDI tarjoaa virtuaalisia työpöytiä, sovellusten julkaiseminen tarjoaa etäkäyttö yksittäisiin sovelluksiin ilman, että koko työpöytää toimitetaan.

Molemmat menetelmät keskittävät sovellukset, mutta eri tavoin.

Vaatimus	Koko VDI	Istuntoon perustuva sovellusten julkaisu
Täydellinen henkilökohtainen työpöytä	Hyvin soveltuva	Ei ensisijainen tarkoitus
Yksittäiset Windows-sovellukset	Tuettu	Hyvin soveltuva
Omistettu työpöytäkäyttöjärjestelmän eristys	Saatavilla	Yleensä käyttää jaettuja istuntoisäntiä
Erityiset työpöytäkonfiguraatiot	Usein sopiva	Riippuu yhteensopivuudesta
Keskitetty sovellushallinta	Tuettu	Tuettu
Selaimeen perustuva pääsy	Alustariippuvainen	Saatavilla yhteensopivilla ratkaisuilla
Toimitus ilman täydellistä VDI-pinoa	Ei yleensä	Mahdollinen

Ero on arkkitehtoninen, ei toiminnallinen.

Monet tällaiset VDI-järjestelmät mahdollistavat jo sovellusten julkaisemisen, joten sovellusten julkaisemisen salliminen ei välttämättä auta sinua välttämään toimittajalukitusta, ellei näitä sovelluksia voida irrottaa VDI-ohjaustasosta.

Sanotaan esimerkiksi, että sinulla on kirjanpito-osasto, joka tarvitsee pääsyn Windowsin talousohjelmaan, mutta ei tarvitse omia virtuaalisia työpöytiä. Julkaisemalla sovelluksen Windows-laatikossa (oikein asetettuna) voit välttää sen, että kaikkien on käytettävä VDI:tä, samalla kun sovelluksen hallinta pysyy keskitettynä.

Toisaalta ihmiset, jotka tarvitsevat pysyviä työpöytiä, joissa jokaisella käyttäjällä on oma työpöytäistuntonsa, saattavat tarvita täydellistä VDI:tä.

3. Hyväksy modulaariset ja yhteensopivat arkkitehtuurit

Modulaariset arkkitehtuurit mahdollistavat yksittäisten elementtien vaihtamisen häiritsemättä koko sovellustoimitusympäristöä.

IT-tiimien tulisi priorisoida seuraavat asiat, mikäli se on mahdollista:

• Standardisoitu identiteetti ja todennus
• Kannettava sovelluskoodeksi ja dokumentoidut riippuvuudet
• Käyttäjätiedot eristetty työpöytäkuvista
• Infrastruktuuri koodina: toistettava käyttöönotto, automaatio
• Toimitus, joka toimii eri päätepisteissä ja hosting-ympäristöissä

Huomaa, että käyttäjätietojen erottaminen työpöytäkuvista yksinkertaistaa sekä siirtoja että katastrofipalautusta: samoin infrastruktuuri koodina auttaa toimintoja luomaan ympäristöjä paremmalla johdonmukaisuudella.

Kuitenkin, jopa avoimet standardit ja automaatio eivät välttämättä estä toimittajalukitusta: eri toimittajien teknologioiden toteutuksessa on usein hienovaraisia eroja, ja skriptit saattavat sisältää kutsuja omistettuihin API:hin.

Siksi tavoitteena on välttää tarpeetonta kytkentää sovellus- ja infrastruktuurikomponenttien, hallinnan ja operatiivisten komponenttien välillä.

4. Harkitse hybridisovellusten toimitusta

Organisaatioiden ei tarvitse valita kaikkien VDI-infrastruktuuriensa säilyttämisen ja niiden täydellisen korvaamisen välillä.

He voisivat omaksua hybridistrategian, joka hyödyntää erilaisia kuormituksia tarpeidensa mukaan.

Organisaatio voisi hyödyntää omistettuja työpöytiä teho käyttäjille samalla, kun se isännöi yhteensopivia liiketoimintasovelluksia jaetuilla Windows-istuntoisäntillä.

He voisivat myös toimittaa vanhoja sovelluksia selainten kautta. Windows-ohjelmistolle, jota ei voida helposti kirjoittaa uudelleen, ymmärtäminen kuinka julkaista Windows-ohjelmisto verkkoon voi auttaa IT-tiimejä arvioimaan selainpohjaista toimitusta osana heidän hybridistrategiaansa.

Paikalliset sovellukset säilyvät parhaiten, kun keskittäminen ei juurikaan paranna yleistä suorituskykyä.

Tällainen strategia mahdollistaa IT-osastolle olemassa olevien investointien säilyttämisen infrastruktuuriinsa samalla, kun he siirtyvät uusiin teknologioihin omassa tahdissaan.

Haaste tässä lähestymistavassa on se, että se luo lisäkompleksisuutta ja vaatii kattavampaa identiteetinhallintaa, turvallisuusmenettelyjä, jotka ovat yhdenmukaisia kaikilla alustoilla, valvontakäytäntöjä ja tukimenettelyjä.

5. Vertaa toimitusmallien kokonaiskustannuksia

Lisensointisäästöt eivät yksinään määritä vaihtoehtoisen sovellustoimitusarkkitehtuurin kustannustehokkuutta.

IT-tiimien tulisi arvioida omistamisen kokonaiskustannukset, mukaan lukien infrastruktuuri, ohjelmistokustannukset, hallinta, turvallisuus ja migraatio.

Kustannusluokka	Arviointikriteerit
Ohjelmisto	Lisensointi, tilaukset, tuki ja uusimiset
Infrastruktuuri	Laskenta, tallennus, verkko ja pilvikäyttö
Käyttöjärjestelmät	Windows-lisensointi ja sovellettavat käyttöoikeudet
Hallinta	Provisionointi, ylläpito, valvonta ja vianetsintä
Turvallisuus	MFA, pääsynhallinta, auditointi ja turvallisuuden hallinta
Siirto	Testaus, konfigurointi, koulutus ja käyttöönotto
Liiketoiminnan jatkuvuus	Saatavuus, varmuuskopiointi, palautus ja käyttökatkosten altistus

Sovellusten julkaiseminen voi vähentää tarpeen erityisille komponenteille VDI-ympäristössä, mutta sillä on omat käyttöönotto- ja lisensointivaatimuksensa.

Esimerkiksi perinteiset Microsoft Remote Desktop Services (RDS) -istuntojen isännöintikonfiguraatiot vaatisivat asianmukaiset RDS-asiakaslisenssit, kuten on kuvattu Microsoftin RDS CAL -dokumentaatio .

Lisensointivaatimukset tulisi vahvistaa todellisen arkkitehtuurin, toimitustuotteen ja asiaankuuluvien Microsoftin ehtojen perusteella.

Tavoitteena tulisi olla kokonaiskustannusten minimointi samalla, kun toimitetaan liiketoiminnan tarpeita vastaava turvallisuus, suorituskyky ja luotettavuus.

Mitä sinun pitäisi tehdä siirtyäksesi pois VDI-toimittajan lukitsemisesta?

Toimittajariippuvuuden vähentäminen on paljon turvallisempaa tehdä vähitellen kuin tehdä täydellinen vaihto alustasta.

Vaiheittainen siirtyminen antaa IT-tiimeille mahdollisuuden todistaa vaihtoehtoisia toimitustapoja samalla kun säilytetään nykytila.

Vaihe 1: Luokittele sovellukset toimitusvaatimusten mukaan

Aloita ryhmittämällä sovellukset niiden teknisten riippuvuuksien ja loppukäyttäjien vaatimusten perusteella. Kolme laajaa kategoriaa on erityisen hyödyllisiä tunnistamisessa:

• Käyttöliittymät, jotka vaativat täydellisiä työpöytiä – kuormitukset, jotka vaativat omistettua käyttöjärjestelmäympäristöä, erityistä konfiguraatiota tai työpöytätason eristystä
• Etäjulkaisulle soveltuvat sovellukset – Windows-sovellukset, jotka ovat yhteensopivia tuettujen jaettujen/omistettujen istuntoisäntäympäristöjen kanssa
• Sovellukset, jotka soveltuvat paikalliseen tai selainpohjaiseen käyttöön – ohjelmisto, jota ei enää tarvitse suorittaa VDI-ympäristössä.

Tällainen luokittelu voi auttaa ylläpitäjää tunnistamaan vaihtoehtoisten toimitusmallien ehdokkaita, jotka eivät vaadi merkittäviä mukautuksia.

Vaihe 2: Valitse matalan riskin pilottikuormitus

Valitse sovellus, jolla on selkeästi määritellyt resurssivaatimukset, vähän riippuvuuksia ja rajallinen käyttäjäkunta.

Vältä aloittamasta liiketoimintakriittisillä sovelluksilla, jotka riippuvat monimutkaisista oheislaitteiden integraatioista, ainutlaatuisista ohjaimista tai haavoittuvista perintökomponenteista.

Pilotin tulisi todistaa vaihtoehtoisen infrastruktuurin kyky riittävästi jäljitellä alkuperäisen ympäristön olennaisia toimintoja ja käyttäjäkokemusta.

Vaihe 3: Vahvista yhteensopivuus, suorituskyky ja turvallisuus

Ennen laajentamista, testaa toimintoja ja käyttöominaisuuksia realistisissa ympäristöissä.

Sovellustoimituksen siirtoprojektin on sisällettävä seuraavat alueet testitapauksessa:

• Sovelluksen asennus, riippuvuudet ja lisensointi
• Todennus, MFA ja käyttäjäoikeudet
• Käyttäjäprofiilit, asetukset ja tiedostojen käyttöoikeus
• Tulostus, leikepöytä ja oheislaitteiden uudelleenohjaus
• Istuntojen samanaikaisuus ja resurssien kulutus
• Viive, reagointikyky ja uudelleenyhteys
• Lokitus, valvonta ja turvallisuuspolitiikat
• Varmuuskopiointi, palautus ja palautusmenettelyt

Sovellusten onnistunut käynnistäminen ei takaa täydellistä yhteensopivuutta.

Esimerkiksi sovellus saattaa toimia hyvin itsenäisesti, mutta epäonnistua, kun useat käyttäjät yrittävät käyttää sitä samanaikaisesti tai tulostaa asiakirjoja tulostimille.

IT-tiimien on suunniteltava tarvittavat testit ja suorituskykykriteerit istunnoille, sovelluksille, turvallisuudelle ja palautusominaisuuksille.

Vaihe 4: Siirrä sovelluksia hallituissa vaiheissa

Kun pilotti täyttää hyväksymiskriteerit, laajenna käyttöönottoa liiketoiminnan prioriteettien ja teknisen monimutkaisuuden perusteella.

Säilytä alkuperäinen toimitusympäristö siirtymän aikana, kun se on mahdollista, mahdollistaen järjestelmänvalvojien verrata suorituskykyä, ratkaista ongelmia tehokkaasti ja palata vakiintuneisiin prosesseihin tarvittaessa.

Dokumentoi onnistumiskriteerit, määritä vastuuhenkilöt ja luo palautusmenettelyt jokaiselle siirron vaiheelle. Nämä toimenpiteet edistävät myös sovelluksen kestävyys auttaen organisaatioita säilyttämään olennaiset liiketoimintatoiminnot infrastruktuurin muutosten aikana.

Vaihe 5: Tarkista jäljellä olevat riippuvuudet

Myyjäriippuvuuden ongelma ei rajoitu yhteen tapaukseen.

Uudet sovellukset, tarpeet alustapäivitykselle, muutokset lisensoinnissa tai toiminnallisessa mukauttamisessa voivat luoda lisäriippuvuuksia migraation valmistuttua.

Siksi tarvitaan säännöllisiä tarkastuksia varmistaakseen, että sovellukset voivat jatkaa toimintaansa kohdealustalla, että kokoonpanot on kirjattu oikein ja että muut toimitustavat pysyvät saatavilla.

Tämä mahdollistaa uuden ympäristön välttää tulemasta toisen toimittajan lukitsemaksi.

Missä tapauksessa VDI on hyvä ratkaisu säilyttää?

VDI-toimittajan lukituksen vähentäminen ei vaadi VDI:n kokonaisvaltaista vaihtamista.

VDI:llä on oikeutettu arvo tilanteissa, joissa tarvitaan omistettuja käyttöjärjestelmiä, pysyviä työpöytiä, graafisesti vaativia sovelluksia tai kuormituksen eristämistä, jota jaetut istuntopalvelimet eivät voi tarjota.

Se on myös arvokasta standardoitujen, keskitetysti hallittujen työpöytien toimittamisessa, joissa on johdonmukaiset työpöydän hallintakäytännöt.

Päätöksen siirtymisestä toiseen arkkitehtuuriin tulisi perustua sovelluksen käyttäytymiseen, turvallisuusvaatimuksiin, käyttäjävaatimuksiin ja taloudellisiin tekijöihin.

Useimmille organisaatioille hajautettu arkkitehtuuri on käytännöllisempi kuin pakottaa kaikki sovellukset samaan toimitusmalliin.

VDI:n säilyttäminen työkuormille, jotka sitä vaativat, samalla kun käytetään itsenäistä sovellusten julkaisemista muille työkuormille, mahdollistaisi VDI-sitoutumisen vähentämisen ilman VDI:n ominaisuuksista luopumista.

Miten sovellustoimitus voi pysyä joustavana pitkällä aikavälillä?

Järjestelmän pitkäaikainen joustavuus saavutetaan kyvyllä säilyttää hallinta sovelluksen, infrastruktuurin ja käyttäjäkäytön suhteessa.

Sovellusten on oltava suunniteltu siten, että ne voivat jatkaa toimintaansa mahdollisesti muuttuvilla infrastruktuurin isännöintipalveluilla, hypervisorilla tai työpöytävirtualisointialustoilla.

Tämä lähestymistapa vaatii tarkkaa huomiota riippuvuuksien asianmukaiseen dokumentointiin, sovellustietojen eristämiseen sen toimitusmekanismeista, toistettavan konfiguraation säilyttämiseen ja jatkuvaan vaihtoehtoisten lähestymistapojen ja konfiguraatioiden tutkimiseen.

Esimerkiksi, vaikka Windowsille kirjoitettu sovellus voitaisiin siirtää toimimaan keskitetysti hallituilla Windows-palvelimilla uudessa organisaatiossa, joka käyttää erilaisia isännöintiohjelmistoja tai hypervisor-ohjelmistoja, tai on korvannut VDI-välitysohjelmistonsa, se ei tarkoita, että sovellus olisi yleisesti siirrettävissä.

Sovelluksia on testattava niiden kyvyn mukaan toimia eri infrastruktuureilla, mukaan lukien peruskäyttöjärjestelmän vaihtelut, asianmukainen lisensointi, sovelluskohtainen yhteensopivuus tai suorituskykyominaisuudet.

Yksi hyödyllinen mittari joustavuudelle on sovelluksen siirrettävyys merkittävästi erilaisissa ympäristöissä.

Jos sovelluksen siirtäminen toiseen, mutta tuettuun infrastruktuuriin vaatii laajaa uudelleentyöstämistä riippumattomien elementtien vuoksi monien riippuvuuksien läsnäolon takia, se osoittaa, että paljon työtä on tehtävä ennen kuin sovellusta voidaan pitää siirrettävänä.

Tätä mittaria voidaan soveltaa iteratiivisesti, jotta voidaan vähitellen lisätä sovelluksen infrastruktuurin tarpeiden joustavuutta tai tehdä operatiivisia säätöjä ilman, että sovellusta itsessään tarvitsee kokonaan muokata.

Etsitkö yksinkertaisempaa tapaa toimittaa Windows-sovelluksia?

TSplus Etäyhteys tarjoaa vaihtoehdon organisaatioille, jotka haluavat julkaista Windows-sovelluksia ja toimittaa etätyöpöytiä ilman perinteisen täyden VDI-pinon käyttöönottoa. Sovellusten julkaisemisen, HTML5-selaimen käytön ja tuen avulla Windows-ympäristöille, jotka on isännöity paikallisesti tai pilvessä, se auttaa IT-tiimejä monipuolistamaan toimitusvaihtoehtoja säilyttäen samalla keskitetyn hallinnan.

Päätelmä

VDI-toimittajan lukitus tulee kalliiksi, kun sovellukset riippuvat tiiviisti integroidusta infrastruktuurista, lisensoinnista ja hallintajärjestelmistä. Näiden riippuvuuksien kartoittaminen ja vaihtoehtoisten toimitustapojen käyttöönotto voivat auttaa organisaatioita säilyttämään hallinnan luopumatta kokonaan VDI:stä.

Joustava arkkitehtuuri mahdollistaa IT-tiimien ylläpitää sopivia kuormituksia virtuaalisilla työpöydillä samalla kun se yksinkertaistaa pääsyä muihin, vähentää siirtoriskiä ja säilyttää tulevat vaihtoehdot.