Pakilala
Ang Virtual Desktop Infrastructure (VDI) ay nagpapadali sa sentralisadong pamamahala ng desktop, ngunit ang mga magkakaugnay na bahagi nito ay maaaring magpahirap sa paglipat ng mga platform. Mula sa mga proprietary connection broker hanggang sa mga limitasyon sa lisensya, ang mga pagdepende na ito ay maaaring magpigil sa mga pagpipilian ng IT at magpataas ng kumplikado ng migrasyon. Sinusuri ng artikulong ito ang mga sanhi at panganib ng VDI vendor lock-in, ipinaliwanag kung paano ito mababawasan, at naglalahad ng mga praktikal na hakbang para mapanatiling flexible ang paghahatid ng mga aplikasyon ng Windows.
Ano ang Vendor Lock-In ng VDI?
Ang VDI vendor lock-in ay isang sitwasyon kung saan ang isang organisasyon ay nagiging labis na umaasa sa isang tiyak na desktop virtualization platform sa puntong ang pagpapalit ng mga vendor ay magiging labis na hamon, mahal, o nakakasagabal sa kumpanya.
Ang mga bahagi ng VDI tulad ng mga hypervisor, connection broker, desktop image, user profile, authentication system, at iba pang mga tool sa pamamahala ay karaniwang pinagsasama-sama sa mga kapaligiran ng VDI. Gayunpaman, sa kabila ng pagiging hiwalay, maaaring mangailangan sila ng tiyak na dokumentasyon at pagsasaayos mula sa vendor upang matagumpay na makipag-ugnayan sa isa't isa.
Ang dahilan ay, kahit na ang mga aplikasyon na nakasulat sa wika ng Windows ay karaniwang gumagana kahit saan, ang mga desktop na itinayo para sa isang tiyak na kapaligiran ng VDI ay nangangailangan ng makabuluhang oras upang muling i-configure. Samakatuwid, ang vendor lock-in ay hindi isang hindi malulutas na problema, ngunit nagdudulot ito ng makabuluhang hadlang para sa mga organisasyon na nagnanais na lumipat ng mga platform.
Ano ang mga Sanhi ng Vendor Lock-In sa mga VDI na Kapaligiran?
Ang pagkakakulong ng vendor ng VDI ay bihirang sanhi ng isang tiyak na teknikal na limitasyon. Karaniwan itong nagmumula sa maraming pag-asa sa kaugnay na imprastruktura, mga kasangkapan sa pamamahala, paglisensya, at mga pagsasaayos ng aplikasyon.
Mga Proprietary Connection Brokers at Management Tools
Ang mga koneksyon ng broker ay responsable para sa pamamahala ng mga koneksyon ng gumagamit sa mga virtual na desktop habang ang mga tool sa pamamahala ay ginagamit upang magbigay, ilagay, at panatilihin ang mga desktop at aplikasyon. Ang mga tool tulad ng Citrix Virtual Apps at Desktops, Omnissa Horizon at Azure Virtual Desktop ay itinayo gamit ang iba't ibang imprastruktura ng pamamahala at mga teknika sa pagsasaayos.
Ito ay nangangahulugan na kapag lumilipat mula sa isang platform patungo sa isa pa, maaaring kailanganing muling ayusin ang mga desktop pool, aplikasyon, koneksyon, at mga automated na tool. Ang mga aplikasyon mismo ay maaaring manatiling pareho, gayunpaman, ang kanilang pagpapatupad ay mag-iiba depende sa paunang software.
Mga Dependensya ng Hypervisor at Inprastruktura
Ang mga platform ng VDI ay nangangailangan ng imprastruktura na kayang mag-host at mag-manage ng mga virtual desktop. Maaaring kabilang dito ang mga tiyak na hypervisor, cloud, storage, o provisioning na teknolohiya.
Ang proseso ng migrasyon ay maaaring samakatuwid ay may kasamang ilang mga gawain:
- Pagko-convert o pagbuo muli ng mga imahe ng virtual machine
- Pag-reconfigure ng networking, storage, at alokasyon ng mapagkukunan
- Papalitan ang mga tool sa pagbibigay ng serbisyo na tiyak sa vendor
- V Pagpapatunay ng pagiging tugma at pagganap ng aplikasyon
- Paglikha muli ng mga mekanismo ng pagkakaroon at pagbawi mula sa sakuna
Gayunpaman, ang konsepto ng portability ay hindi palaging umaabot sa kapaligiran ng desktop delivery. Ang matagumpay na migrasyon ng isang virtual machine ay hindi tinitiyak na ang nakapaligid na kapaligiran ng delivery ay gagana nang walang pagbabago.
Licensing at Mga Paghihigpit sa Kontrata
Karaniwang nangangailangan ang mga implementasyon ng VDI ng ilang iba't ibang lisensya – para sa mga operating system, mga produkto ng virtualization, mga karapatan sa pag-access ng gumagamit, mga kasangkapan sa pamamahala, at mga aplikasyon ng third-party.
Malaki ang pagkakaiba ng mga vendor pagdating sa pagbuo o paghihiwalay ng mga teknolohiyang ito, na maaaring magpahirap sa pagpaplano ng badyet at paglipat sa mga bagong imprastruktura.
Ito ay lalong mahalaga kapag ang mga organisasyon ay nais na lumipat mula sa isang VDI stack patungo sa isa pa, halimbawa, mula sa on-premise patungo sa cloud-based na solusyon, dahil ang mga modelo ng lisensya para sa mga operating system, mga karapatan ng gumagamit at pagkonsumo ng imprastruktura ay maaaring magbago nang malaki.
Nagbibigay ang Microsoft Learn website ng isang kaalaman tungkol sa paglisensya ng Azure Virtual Desktop at kung paano ito naaangkop sa iba't ibang OS at mga kaso ng paggamit.
Samakatuwid, mahalagang suriin ang buong stack ng lisensya, kasama ang mga implikasyon ng anumang obligasyong kontraktwal, kapag gumagawa ng desisyon, hindi lamang ang mga gastos sa subscription.
Mga Pagdepende ng Aplikasyon at User Profile
Maaaring magkaroon ng ilang mga dependency ang mga aplikasyon ng Windows sa operating system, registry, drivers, lokasyon, o iba pang mga serbisyo.
Ang mga ganitong uri ng aplikasyon ay karaniwang na-virtualize sa mga VDI na kapaligiran, na may ilang aspeto ng mga kinakailangan na nakabuo sa mga master image o isinama sa mga advanced na tool sa pamamahala ng profile. Ang ilang mga kumpanya ay bumubuo at nagpapanatili ng kanilang sariling mga tool at script upang matugunan ang mga partikular na pangangailangan ng kanilang aplikasyon kaugnay ng natitirang imprastruktura.
Sa mga sitwasyong ito, nagiging napakahirap na paghiwalayin ang mga aplikasyon mula sa kanilang mga sumusuportang elemento, na nagdudulot ng malaking teknikal na utang at ginagawang napakahirap ang portability.
Kahit na ang aplikasyon mismo ay portable, may mga mahahalagang elemento pa rin, tulad ng pag-install, pagsasaayos, mga setting ng gumagamit, at pamamahala ng data na kailangang muling itatag sa bagong kapaligiran. Ang pag-unawa sa pagkakaiba sa pagitan ng Pagbabalot ng aplikasyon ng Windows at paglalathala ng aplikasyon maaaring makatulong ang mga koponan ng IT na paghiwalayin ang mga kinakailangan sa pag-deploy ng software mula sa mga dependency ng paghahatid ng aplikasyon.
Ano ang mga Panganib ng Pagkakaroon ng VDI Vendor Lock-In?
Ang pag-asa sa vendor ay nagdudulot ng partikular na mga paghihirap kapag ang isang organisasyon ay kailangang baguhin ang estratehiya ng imprastruktura nito, umangkop sa mga pagbabago sa lisensya o magpatibay ng mga bagong teknolohiya sa paghahatid ng aplikasyon.
Ang pangunahing mga panganib ay may kaugnayan sa mga gastos, kakayahang arkitektural, at pagpapatuloy ng operasyon.
Tumaas na Inprastruktura at Gastos sa Lisensya
Ang isang mahigpit na nakaugnay na VDI na kapaligiran ay maaaring maging mahirap para sa isang organisasyon na i-optimize ang kanilang mga bahagi ng imprastruktura.
Kapag nagbago ang mga tuntunin ng lisensya o tumaas ang gastos ng imprastruktura, maaaring mangailangan ito ng isang malawakang proyekto ng migrasyon kung sila ay nagbabalak na lumipat ng mga tagapagbigay. Maaari itong makasakit sa kanilang posisyon sa negosasyon at kakayahang i-optimize ang mga gastos.
Bukod dito, ang pagbibigay ng lahat ng aplikasyon sa pamamagitan ng isang buong virtual desktop ay maaaring magdulot ng hindi kinakailangang overhead para sa mga workload na nangangailangan lamang ng isa o dalawang aplikasyon sa bintana.
Ang pag-publish ng aplikasyon ay hindi mas mura kaysa sa VDI: ang ekonomiya ng dalawang pamamaraan ay mag-iiba depende sa densidad ng mga workload, mga operating system na kinakailangan, ang footprint ng imprastruktura at ang mga kinakailangan sa administrasyon at pamamahala.
Nabawasan ang Arkitektural na Kakayahang Umangkop
Ang mga organisasyon na nagnanais na magpatibay ng hybrid na imprastruktura, palitan ang mga lumang server, lumipat sa pagitan ng mga provider ng hosting, o kahit na magpatibay ng mga bagong teknolohiya sa paghahatid ay maaaring makatagpo ng limitadong mga pagpipilian dahil sa umiiral na mga vendor-specific na dependencies.
Isang VDI platform na malapit na nakatali sa isang infrastructure stack ay maaaring mangailangan ng kumpletong muling disenyo ng mga aplikasyon na nilayon para sa paghahatid sa ibang stacks at mga provider ng hosting, kaya't pinabagal ang proseso ng digital transformation.
Tumaas na Kumplikadong Migrasyon
Ang mga paglipat ng VDI vendor ay hindi lamang tungkol sa paglipat ng virtual machine.
Kailangan din ng mga administrador na panatilihin ang pagpapatotoo, mga profile ng gumagamit, mga setting ng aplikasyon, pag-print, pag-access sa mga file, mga patakaran sa seguridad, at pag-uugali ng sesyon.
Ang mahirap na dokumentasyon ng mga dependencies na ito ay maaaring magpahirap sa proseso ng pagsukat, pagsubok, at pagpapatupad nang walang insidente.
Mas Malawak na Exposure sa mga Pagbabago ng Vendor
Pagwawakas ng produkto, mga bagong modelo ng lisensya, mga pagbabago sa suporta, o mga kinakailangan sa imprastruktura ay maaaring mangailangan ng pagbabago sa estratehiya ng pag-deploy.
Mas malaki ang pag-asa sa isang solong plataporma ng deployment, mas mataas ang potensyal na epekto ng mga pagbabagong ito sa negosyo.
Ang pagpapanatili ng mga alternatibong opsyon sa paghahatid ay makakapagpahina sa panganib na ito at lumikha ng mas malaking kakayahang umangkop habang nagbabago ang mga pangangailangan ng negosyo o teknolohiya.
Paano Mo Maaaring Bawasan Ang Mga Panganib ng Pagkakaroon ng VDI Vendor Lock-In?
Ang pagbabawas ng vendor lock-in ng VDI ay nangangailangan ng isang hanay ng mga teknikal, may kaugnayang workload, at arkitekturang pagsasaalang-alang.
Ang ideya ay hindi upang iwasan ang mga vendor, kundi upang payagan ang mga pagbabago sa platform nang hindi naaapektuhan ang lahat ng iba pang aspeto ng paghahatid ng aplikasyon.
1. Suriin ang Umiiral na VDI Dependencies
Ang unang hakbang ay tukuyin kung ano ang mahalaga sa paghahatid ng mga aplikasyon at desktop, at kung aling mga bahagi ang nakadepende sa teknolohiyang tiyak sa mga nagbebenta.
Ang isang imbentaryo ng mga dependency ay dapat talakayin ang mga sumusunod na tanong:
| Komponenta | Mga Tanong na dapat suriin |
|---|---|
| Tagapamagitan ng koneksyon | Maaari bang muling likhain ang mga desktop at aplikasyon sa ibang lugar? |
| Hypervisor | Maaari bang lumipat ang mga virtual machine at mga imahe sa alternatibong imprastruktura? |
| Mga aplikasyon | Kailangan ba ng mga aplikasyon ng tiyak na mga imahe, operating system o driver? |
| Mga profile ng gumagamit | Maaari bang lumipat nang hiwalay ang mga setting at data? |
| Pagpapatotoo | Nakaugnay ba ang mga patakaran sa pagkakakilanlan sa mga proprietary na integrasyon? |
| Lisensya | Ano ang mga obligasyon, karapatan sa pag-access at mga gastos sa pag-alis na nalalapat? |
| Automation | Aling mga script ang umaasa sa mga vendor-specific na API o mga tool? |
Ang imbentaryo ay dapat ding isama ang mga may-ari ng aplikasyon, kahalagahan sa negosyo, mga kinakailangan sa pagbawi, at mga hindi nakadokumento na pasadya.
Ang klasipikasyong ito ay makakatulong sa mga IT manager na maunawaan kung aling mga dependency ang madaling mapalitan, at kung aling mga kinakailangan ng makabuluhang muling disenyo.
2. Ihiwalay ang Application Delivery Mula sa Desktop Infrastructure
Isa sa mga pinakamahusay na paraan upang mabawasan ang pangangailangan para sa VDI ay tiyakin na ang bawat aplikasyon ay talagang nangangailangan ng ganitong masalimuot na solusyon.
Habang nag-aalok ang VDI ng mga virtual desktop, nagbibigay ang pag-publish ng aplikasyon ng remote access sa mga indibidwal na aplikasyon nang hindi kinakailangang maghatid ng buong desktop.
Parehong pinagsasama-sama ng mga pamamaraan ang mga aplikasyon, ngunit sa magkaibang paraan.
| Kailangan | Buong VDI | Pag-papahayag ng Aplikasyon Batay sa Sesyon |
|---|---|---|
| Kumpletong personalisadong desktop | Sakto | Hindi ang pangunahing layunin |
| Indibidwal na mga aplikasyon ng Windows | Suportado | Sakto |
| Dedikadong paghiwalay ng desktop OS | Available | Karaniwang gumagamit ng mga ibinahaging host ng sesyon |
| Espesyal na mga configuration ng desktop | Madalas na angkop | Nakasalalay sa pagiging tugma |
| Sentralisadong pamamahala ng aplikasyon | Suportado | Suportado |
| Access sa batay ng browser | Nakasalalay sa platform | Available with compatible solutions |
| Paghahatid nang walang kumpletong VDI stack | Hindi karaniwan | Posible |
Ang pagkakaiba ay arkitektural, hindi functional.
Maraming ganitong mga sistema ng VDI ang nagpapahintulot na ng pag-publish ng mga aplikasyon, kaya ang pagpapahintulot ng pag-publish ng mga aplikasyon ay hindi kinakailangang makatulong sa iyo na maiwasan ang vendor lock-in, maliban na lamang kung ang mga aplikasyon na iyon ay maaaring ihiwalay mula sa VDI control plane.
Sabihin nating, halimbawa, mayroon kang departamento ng accounting na nangangailangan ng access sa isang Windows financial application ngunit hindi kailangan ng kanilang sariling virtual desktops. Sa pamamagitan ng pag-publish ng application sa isang Windows box (na maayos na na-set up), maaari mong maiwasan ang pagpilit sa lahat na gumamit ng VDI, habang pinapanatili pa rin ang sentralisadong pamamahala ng application.
Sa kabilang banda, ang mga tao na nangangailangan ng patuloy na mga desktop, kung saan ang bawat gumagamit ay may kanya-kanyang session ng desktop, ay maaaring mangailangan ng buong VDI.
3. Magpatibay ng Modular at Interoperable na Arkitektura
Ang mga modular na arkitektura ay nagpapahintulot sa pagpapalit ng mga indibidwal na elemento nang hindi naaapektuhan ang kabuuang kapaligiran ng paghahatid ng aplikasyon.
Dapat bigyang-priyoridad ng mga IT team ang mga sumusunod kung naaangkop:
- Pamantayang Pagkilala at Pagpapatunay
- Portable na aplikasyon na code at nakadokumento na mga dependencies
- User data na hiwalay mula sa mga desktop na imahe
- Inprastruktura bilang code: maulit na pag-deploy, awtomasyon
- Paghahatid na gumagana sa iba't ibang endpoint at hosting na kapaligiran
Tandaan na ang paghihiwalay ng data ng gumagamit mula sa mga desktop image ay magpapadali sa parehong migrasyon at pagbawi mula sa sakuna: sa katulad na paraan, ang imprastruktura bilang code ay makakatulong sa mga operasyon na muling likhain ang mga kapaligiran na may mas mahusay na pagkakapare-pareho.
Gayunpaman, kahit na ang mga bukas na pamantayan at awtomasyon ay maaaring hindi maiwasan ang vendor lock-in: madalas na may mga banayad na pagkakaiba sa pagpapatupad sa pagitan ng iba't ibang teknolohiya ng mga vendor, at ang mga script ay maaaring maglaman ng mga tawag sa mga proprietary na API.
Samakatuwid, ang layunin ay maiwasan ang hindi kinakailangang pagkakaugnay sa pagitan ng mga bahagi ng aplikasyon at imprastruktura, pamamahala, at mga bahagi ng operasyon.
4. Isaalang-alang ang Hybrid Application Delivery
Hindi kailangang pumili ng mga organisasyon sa pagitan ng pagpapanatili ng lahat ng kanilang VDI infrastructure o pagpapalit nito ng ibang bagay.
Maari silang magpatupad ng hybrid na estratehiya na gumagamit ng iba't ibang workload ayon sa kanilang mga pangangailangan.
Maaaring gumamit ang isang organisasyon ng mga nakalaang desktop para sa mga power user habang nagho-host ng mga katugmang aplikasyon sa negosyo sa mga shared windows session hosts.
Maaari rin nilang ipamahagi ang mga legacy na aplikasyon sa pamamagitan ng mga browser. Para sa software ng Windows na hindi madaling maisulat muli, ang pag-unawa paano i-publish ang Windows software sa web maaaring makatulong ang mga IT team na suriin ang browser-based na paghahatid bilang bahagi ng kanilang hybrid na estratehiya.
Mas mainam na panatilihin ang mga lokal na aplikasyon kapag ang sentralisasyon ay hindi gaanong nakapagpapabuti sa pangkalahatang pagganap.
Ang ganitong estratehiya ay magbibigay-daan sa departamento ng IT na mapanatili ang mga umiiral na pamumuhunan sa kanilang imprastruktura habang sila ay lumilipat sa mga bagong teknolohiya sa kanilang sariling bilis.
Ang hamon sa pamamaraang ito ay nagdudulot ito ng karagdagang kumplikado at nangangailangan ng mas komprehensibong pamamahala ng pagkakakilanlan, mga hakbang sa seguridad na pare-pareho sa lahat ng platform, mga patakaran sa pagmamanman, at mga pamamaraan ng suporta.
5. Ihambing ang Kabuuang Gastos ng mga Modelo ng Paghahatid
Ang mga pagtitipid sa lisensya lamang ay hindi nagdidikta sa pagiging epektibo sa gastos ng isang alternatibong arkitektura ng paghahatid ng aplikasyon.
Dapat suriin ng mga IT team ang kabuuang halaga ng pagmamay-ari kasama ang imprastruktura, mga gastos sa software, administrasyon, seguridad, at migrasyon.
| Kategorya ng gastos | Kriteriya ng pagsusuri |
|---|---|
| Software | Lisensya, mga subscription, suporta, at mga renewal |
| Inprastruktura | Pag-compute, imbakan, networking, at pagkonsumo ng cloud |
| Mga operating system | Licensya ng Windows at mga naaangkop na karapatan sa pag-access |
| Pamamahala | Pagsasaayos, pagpapanatili, pagmamanman, at pagsasaayos ng problema |
| Seguridad | MFA, mga kontrol sa pag-access, pag-audit, at pamamahala ng seguridad |
| Migrasyon | Pagsubok, pagsasaayos, pagsasanay, at pag-deploy |
| Katatagan ng negosyo | Availability, backup, recovery, at pagkakalantad ng downtime |
Ang pag-publish ng aplikasyon ay maaaring bawasan ang pangangailangan para sa mga tiyak na bahagi sa isang VDI na kapaligiran, ngunit mayroon itong sariling mga kinakailangan sa pag-deploy at pag-license.
Halimbawa, ang mga tradisyonal na configuration ng hosting ng session ng Microsoft Remote Desktop Services (RDS) ay mangangailangan ng naaangkop na RDS Client Access Licenses tulad ng inilarawan sa Dokumentasyon ng RDS CAL ng Microsoft .
Dapat suriin ang mga kinakailangan sa lisensya batay sa aktwal na arkitektura, produktong ibinibigay at mga kaugnay na termino at kundisyon ng Microsoft.
Ang layunin ay bawasan ang kabuuang gastos habang nagbibigay pa rin ng seguridad, pagganap, at pagiging maaasahan na kinakailangan upang matugunan ang mga pangangailangan ng negosyo.
Ano ang Kailangan Mong Gawin Upang Lumipat Mula sa VDI Vendor Lock-In?
Mas ligtas ang unti-unting pagbabawas ng pagdepende sa vendor kaysa sa paggawa ng kumpletong pagpapalit ng platform.
Ang phased migration ay nagbibigay sa mga IT team ng pagkakataon na patunayan ang mga alternatibong pamamaraan ng paghahatid habang pinapanatili ang kasalukuyang estado.
Hakbang 1: Iklasipika ang mga Aplikasyon ayon sa mga Kinakailangan sa Paghahatid
Simulan ang pag-grupo ng mga aplikasyon batay sa kanilang teknikal na mga kinakailangan at mga pangangailangan ng end-user. Tatlong malawak na kategorya ang partikular na kapaki-pakinabang upang matukoy:
- Mga aplikasyon na nangangailangan ng buong desktop–mga workload na nangangailangan ng nakalaang kapaligiran ng OS, espesyal na pagsasaayos, o antas ng pag-iisa ng desktop
- Mga aplikasyon na angkop para sa remote publishing–mga aplikasyon ng Windows, na tugma sa sinusuportahang shared/dedicated session-host na mga kapaligiran
- Mga aplikasyon na angkop para sa lokal o browser-native na access–software na hindi na nangangailangan na patakbuhin sa loob ng isang VDI na kapaligiran.
Ang ganitong klasipikasyon ay makakatulong sa administrador na tukuyin ang mga kandidato para sa mga alternatibong modelo ng paghahatid, na hindi nangangailangan ng makabuluhang mga pagbabago.
Hakbang 2: Pumili ng Mababang Panganib na Pilot Workload
Pumili ng isang aplikasyon na may malinaw na tinukoy na mga pangangailangan sa mapagkukunan, kaunting mga dependency, at limitadong bilang ng mga gumagamit.
Iwasan ang pagsisimula sa mga aplikasyon na kritikal sa negosyo na umaasa sa mga kumplikadong peripheral integrations, natatanging drivers, o mahihinang legacy components.
Dapat patunayan ng piloto ang kakayahan ng alternatibong imprastruktura na sapat na maulit ang mga pangunahing function at karanasan ng gumagamit ng orihinal na kapaligiran.
Hakbang 3: I-validate ang Kakayahang Makipag-ugnayan, Pagganap at Seguridad
Bago mag-scale up, subukan ang mga function at operational features sa mga makatotohanang kapaligiran.
Ang proyekto ng migrasyon ng application delivery ay dapat isama ang mga sumusunod na lugar sa senaryo ng pagsubok:
- Pag-install ng aplikasyon, mga kinakailangan, at paglisensya
- Pagpapatunay, MFA, at mga pahintulot ng gumagamit
- Mga profile ng gumagamit, mga setting, at pag-access sa file
- Pagpi-print, clipboard, at peripheral na redirection
- Pagsasabay ng sesyon at pagkonsumo ng mapagkukunan
- Latency, responsiveness, at reconnection
- Pag-log, pagmamanman, at mga patakaran sa seguridad
- Backup, pagbawi, at mga pamamaraan ng pag-rollback
Ang matagumpay na paglulunsad ng mga aplikasyon ay hindi nangangahulugang ganap na pagkakatugma.
Halimbawa, maaaring gumana nang maayos ang isang aplikasyon sa sarili nito ngunit mabigo kapag maraming gumagamit ang sumusubok na patakbuhin ito nang sabay-sabay o mag-print ng mga dokumento sa mga printer.
IT teams must design the necessary tests and performance criteria for sessions, applications, security, and rollback features.
Hakbang 4: Ilipat ang mga Aplikasyon sa Kontroladong Yugto
Kapag natugunan ng pilot ang mga pamantayan ng pagtanggap nito, palakihin ang pag-deploy batay sa prayoridad ng negosyo at teknikal na kumplikado.
Panatilihin ang orihinal na kapaligiran ng paghahatid sa panahon ng paglipat kapag posible, na nagbibigay-daan sa mga administrador na ihambing ang pagganap, epektibong malutas ang mga problema at bumalik sa mga itinatag na proseso kung kinakailangan.
Itakda ang mga pamantayan ng tagumpay ng dokumento, italaga ang mga responsibilidad, at magtatag ng mga pamamaraan ng pag-rollback para sa bawat yugto ng migrasyon. Ang mga hakbang na ito ay nakakatulong din sa katatagan ng aplikasyon tumutulong sa mga organisasyon na mapanatili ang mahahalagang pag-andar ng negosyo sa panahon ng mga pagbabago sa imprastruktura.
Hakbang 5: Suriin ang Natitirang Mga Depende
Ang isyu ng vendor lock-in ay hindi limitado sa isang solong pagkakataon.
Bagong mga aplikasyon, ang pangangailangan para sa pag-upgrade ng platform, mga pagbabago sa lisensya o pag-customize ng operasyon ay maaaring lumikha ng karagdagang mga dependency pagkatapos makumpleto ang migrasyon.
Samakatuwid, kinakailangan ang mga pana-panahong pagsusuri upang matiyak na ang mga aplikasyon ay patuloy na makapagpapatakbo sa target na plataporma, na ang mga configuration ay naitala nang maayos, at na ang iba pang paraan ng paghahatid ay nananatiling magagamit.
Ito ay magbibigay-daan sa bagong kapaligiran na maiwasan ang maging isa pang vendor lock-in.
Sa Aling Kaso ang VDI ang Magandang Solusyon upang Panatilihin?
Ang pagbabawas ng vendor lock-in ng VDI ay hindi nangangailangan ng kabuuang pagpapalit ng VDI.
Ang VDI ay may lehitimong halaga para sa mga senaryo na nangangailangan ng mga dedikadong operating system, patuloy na mga desktop, mga aplikasyon na nangangailangan ng mataas na graphics, o paghihiwalay ng workload na hindi maibigay ng mga shared session host.
Mahalaga rin ito para sa paghahatid ng mga pamantayang desktop na pinamamahalaan sa sentro na may pare-parehong mga patakaran sa pamamahala ng desktop.
Ang desisyon na magpatibay ng ibang arkitektura ay dapat batay sa pag-uugali ng aplikasyon, mga pangangailangan sa seguridad, mga kinakailangan ng gumagamit, at mga salik sa ekonomiya.
Para sa karamihan ng mga organisasyon, mas praktikal ang isang distributed architecture kaysa sa puwersahin ang lahat ng mga aplikasyon sa parehong modelo ng paghahatid.
Ang pagpapanatili ng VDI para sa mga workload na nangangailangan nito habang gumagamit ng independiyenteng pag-publish ng aplikasyon para sa iba pang mga workload ay magpapahintulot na bawasan ang pagkakabihag sa VDI nang hindi iniiwan ang mga kakayahan ng VDI.
Paano Mananatiling Flexible ang Application Delivery sa Pangmatagalan?
Ang pangmatagalang kakayahang umangkop ng isang sistema ay nakakamit sa pamamagitan ng kakayahang mapanatili ang kontrol sa ugnayan ng aplikasyon-inprastruktura at pag-access ng gumagamit.
Dapat na idinisenyo ang mga aplikasyon sa paraang nagpapahintulot sa kanilang patuloy na operasyon sa mga potensyal na nagbabagong imprastruktura ng mga tagapagbigay ng hosting, hypervisor, o mga platform ng desktop virtualization.
Ang pamamaraang ito ay nangangailangan ng masusing atensyon sa wastong dokumentasyon ng mga dependencies, paghihiwalay ng data ng aplikasyon mula sa mga mekanismo ng paghahatid nito, pagpapanatili ng maulit-ulit na configuration, at patuloy na pagsisiyasat ng mga alternatibong pamamaraan at configuration.
Halimbawa, habang ang isang aplikasyon na isinulat para sa Windows ay maaaring ilipat upang tumakbo sa mga sentral na pinamamahalaang Windows server sa isang bagong organisasyon na gumagamit ng iba't ibang software sa pagho-host o hypervisors, o pinalitan ang kanilang software sa VDI brokering, hindi ito nangangahulugan na ang aplikasyon ay maaaring ilipat sa lahat ng dako.
Dapat subukan ang mga aplikasyon para sa kanilang kakayahang gumana sa iba't ibang imprastruktura, kabilang ang mga pagbabago sa pangunahing operating system, angkop na lisensya, pagiging tugma sa partikular na aplikasyon, o mga katangian ng pagganap.
Isang kapaki-pakinabang na sukatan para sa kakayahang umangkop ay ang portability ng aplikasyon sa pagitan ng mga makabuluhang magkakaibang kapaligiran.
Kung ang paglipat ng isang aplikasyon sa ibang, ngunit suportadong, imprastruktura ay nangangailangan ng malawak na pagbabago ng mga hindi kaugnay na elemento dahil sa pagkakaroon ng maraming dependencies, ito ay nagpapahiwatig na maraming trabaho ang dapat gawin bago maituturing na portable ang aplikasyon.
Ang sukatan na ito ay maaaring ilapat nang paulit-ulit upang unti-unting dagdagan ang kakayahang umangkop ng mga pangangailangan sa imprastruktura ng isang aplikasyon o gumawa ng mga pagsasaayos sa operasyon nang hindi kinakailangan ng kumpletong muling paggawa ng mismong aplikasyon.
Naghahanap ng Mas Simpleng Paraan upang Ihatid ang mga Windows Application?
TSplus Remote Access nagbibigay ng alternatibo para sa mga organisasyon na nais maglathala ng mga aplikasyon ng Windows at maghatid ng mga remote desktop nang hindi nag-de-deploy ng tradisyonal na buong VDI stack. Sa pamamagitan ng pag-publish ng aplikasyon, pag-access sa HTML5 browser at suporta para sa mga kapaligiran ng Windows na naka-host sa premises o sa cloud, tinutulungan nito ang mga IT team na pag-iba-ibahin ang mga opsyon sa paghahatid habang pinapanatili ang sentralisadong kontrol.
Wakas
Nagiging magastos ang VDI vendor lock-in kapag ang mga aplikasyon ay umaasa sa mahigpit na pinagsamang imprastruktura, paglisensya, at mga sistema ng pamamahala. Ang pagmamapa sa mga dependency na ito at ang pagpapakilala ng mga alternatibong pamamaraan ng paghahatid ay makakatulong sa mga organisasyon na mapanatili ang kontrol nang hindi ganap na iniiwan ang VDI.
Isang nababaluktot na arkitektura ang nagpapahintulot sa mga IT team na panatilihin ang angkop na mga workload sa mga virtual desktop habang pinapasimple ang pag-access sa iba, binabawasan ang panganib ng migrasyon at pinapanatili ang mga hinaharap na opsyon.
TSplus Libreng Pagsubok ng Remote Access
Pinakamahusay na alternatibo sa Citrix/RDS para sa pag-access ng desktop/app. Ligtas, cost-effective, on-premises/cloud