Zamknięcie dostawcy VDI: ryzyka i rozwiązania

Wprowadzenie

Infrastruktura Wirtualnego Pulpitu (VDI) upraszcza centralne zarządzanie pulpitem, ale jej powiązane komponenty mogą utrudniać przełączanie platform. Od własnościowych brokerów połączeń po ograniczenia licencyjne, te zależności mogą ograniczać wybory IT i zwiększać złożoność migracji. Artykuł ten bada przyczyny i ryzyka związane z blokadą dostawcy VDI, wyjaśnia, jak je zredukować, oraz przedstawia praktyczne kroki na rzecz elastycznej dostawy aplikacji Windows.

Czym jest blokada dostawcy VDI?

Zamknięcie dostawcy VDI to sytuacja, w której organizacja staje się niezwykle zależna od konkretnej platformy wirtualizacji pulpitu do tego stopnia, że zmiana dostawców byłaby niezwykle trudna, kosztowna lub zakłócająca działalność firmy.

Komponenty VDI, takie jak hyperwizory, brokerzy połączeń, obrazy pulpitu, profile użytkowników, systemy uwierzytelniania i inne narzędzia zarządzające, są zazwyczaj łączone w środowiskach VDI. Jednak pomimo bycia oddzielnymi, mogą wymagać specyficznej dokumentacji dostawcy i konfiguracji, aby skutecznie współdziałać ze sobą.

Powodem jest to, że chociaż aplikacje napisane w języku Windows zazwyczaj działają wszędzie, komputery stacjonarne zbudowane dla konkretnego środowiska VDI wymagają znacznego czasu na rekonfigurację. Dlatego blokada dostawcy nie jest problemem nie do pokonania, ale stwarza znaczne przeszkody dla organizacji dążących do zmiany platform.

Jakie są przyczyny uzależnienia od dostawcy w środowiskach VDI?

Zamknięcie dostawcy VDI rzadko jest spowodowane jedną konkretną ograniczeniem technicznym. Zwykle wynika z wielu zależności od powiązanej infrastruktury, narzędzi zarządzania, licencjonowania i konfiguracji aplikacji.

Brokerzy połączeń i narzędzia zarządzania własnościowego

Brokerzy połączeń są odpowiedzialni za zarządzanie połączeniami użytkowników z wirtualnymi pulpitami, podczas gdy narzędzia zarządzające są używane do provisioningu, umieszczania i utrzymywania pulpitów oraz aplikacji. Narzędzia takie jak Citrix Virtual Apps and Desktops, Omnissa Horizon i Azure Virtual Desktop są zbudowane przy użyciu różnych infrastruktur zarządzających i technik konfiguracyjnych.

To oznacza, że przy przełączaniu z jednej platformy na drugą może być konieczne przekształcenie pulpitów, aplikacji, połączeń i narzędzi automatycznych. Same aplikacje mogą pozostać takie same, jednak ich wdrożenie będzie się różnić w zależności od początkowego oprogramowania.

Zależności hyperwizora i infrastruktury

Platformy VDI wymagają infrastruktury zdolnej do hostowania i zarządzania wirtualnymi pulpitami. Może to obejmować konkretne technologie hipernadzorcy, chmury, przechowywania lub dostarczania.

Proces migracji może zatem obejmować kilka zadań:

• Konwertowanie lub odbudowywanie obrazów maszyn wirtualnych
• Rekonfiguracja sieci, przechowywania i alokacji zasobów
• Zastępowanie narzędzi do udostępniania specyficznych dla dostawcy
• V walidacja zgodności aplikacji i wydajności
• Odtwarzanie mechanizmów dostępności i odzyskiwania po awarii

Jednak koncepcja przenośności nie zawsze obejmuje środowisko dostarczania na pulpicie. Udana migracja maszyny wirtualnej nie gwarantuje, że otaczające środowisko dostarczania będzie działać bez modyfikacji.

Licencjonowanie i ograniczenia umowne

Wdrożenia VDI zazwyczaj wymagają kilku różnych licencji – na systemy operacyjne, produkty wirtualizacyjne, prawa dostępu użytkowników, narzędzia zarządzające oraz aplikacje firm trzecich.

Dostawcy znacznie różnią się pod względem łączenia lub rozdzielania tych technologii, co może sprawić, że planowanie budżetu i przejście do nowych infrastruktury będą bardziej skomplikowane.

To szczególnie ważne, gdy organizacje chcą przejść z jednego stosu VDI do innego, na przykład z rozwiązania lokalnego do opartego na chmurze, ponieważ modele licencjonowania dla systemów operacyjnych, uprawnień użytkowników i zużycia infrastruktury mogą się dramatycznie zmienić.

strona internetowa Microsoft Learn oferuje an wgląd w licencjonowanie Azure Virtual Desktop i jak to ma zastosowanie w różnych systemach operacyjnych i przypadkach użycia.

Zgodnie z tym, istotne jest przeanalizowanie całego stosu licencyjnego, w tym implikacji wszelkich zobowiązań umownych, przy podejmowaniu decyzji, a nie tylko kosztów subskrypcji.

Zależności aplikacji i profilu użytkownika

Aplikacje systemu Windows mogą mieć szereg zależności od systemu operacyjnego, rejestru, sterowników, lokalizacji lub innych usług.

Te typy aplikacji są powszechnie wirtualizowane w środowiskach VDI, z pewnymi aspektami wymagań wbudowanymi w obrazy główne lub włączonymi do zaawansowanych narzędzi zarządzania profilami. Niektóre firmy budują i utrzymują własne narzędzia i skrypty, aby zaspokoić specyficzne potrzeby swoich aplikacji w odniesieniu do reszty infrastruktury.

W takich sytuacjach niezwykle trudno jest oddzielić aplikacje od ich elementów wspierających, co stwarza znaczne zadłużenie techniczne i sprawia, że przenośność staje się niezwykle trudna.

Nawet jeśli sama aplikacja jest przenośna, istnieją nadal istotne elementy, takie jak instalacja, konfiguracja, ustawienia użytkownika i zarządzanie danymi, które będą musiały zostać ponownie ustalone w nowym środowisku. Zrozumienie różnicy między Pakowanie aplikacji Windows i publikowanie aplikacji może pomóc zespołom IT oddzielić wymagania dotyczące wdrażania oprogramowania od zależności związanych z dostarczaniem aplikacji.

Jakie są ryzyka związane z uzależnieniem od dostawcy VDI?

Zależność od dostawcy stwarza szczególne trudności, gdy organizacja musi zmienić swoją strategię infrastruktury, dostosować się do zmian w licencjonowaniu lub przyjąć nowe technologie dostarczania aplikacji.

Główne ryzyka dotyczą kosztów, elastyczności architektonicznej i ciągłości operacyjnej.

Rosnące koszty infrastruktury i licencji

Ściśle powiązane środowisko VDI może utrudniać organizacji optymalizację komponentów infrastruktury.

Gdy warunki licencyjne się zmieniają lub koszty infrastruktury rosną, może to wymagać dużego projektu migracyjnego, jeśli zamierzają zmienić dostawcę. Może to zaszkodzić ich pozycji negocjacyjnej i zdolności do optymalizacji kosztów.

Ponadto, udostępnianie wszystkich aplikacji za pośrednictwem pełnego wirtualnego pulpitu może generować niepotrzebne obciążenie dla obciążeń wymagających tylko jednej lub dwóch aplikacji okienkowych.

Publikacja aplikacji w żadnym wypadku nie jest tańsza niż VDI: ekonomika obu podejść będzie się różnić w zależności od gęstości obciążeń, potrzebnych systemów operacyjnych, śladu infrastruktury oraz wymagań dotyczących administracji i zarządzania.

Ograniczona elastyczność architektoniczna

Organizacje dążące do przyjęcia hybrydowej infrastruktury, wymiany starych serwerów, przełączania się między dostawcami hostingu lub nawet przyjęcia nowych technologii dostarczania mogą napotkać ograniczenia wynikające z istniejących zależności specyficznych dla dostawców.

Platforma VDI, która jest ściśle związana z jednym stosem infrastruktury, może wymagać całkowitego prz redesignu aplikacji przeznaczonych do dostarczania na innych stosach i dostawcach hostingu, co spowalnia proces transformacji cyfrowej.

Zwiększona złożoność migracji

Przejścia dostawców VDI nie dotyczą tylko migracji maszyn wirtualnych.

Administratorzy muszą również zachować uwierzytelnianie, profile użytkowników, ustawienia aplikacji, drukowanie, dostęp do plików, polityki bezpieczeństwa i zachowanie sesji.

Słaba dokumentacja tych zależności może utrudnić proces ilościowania, testowania i realizacji bez incydentów.

Większa ekspozycja na zmiany dostawcy

Zakończenie produktu, nowe modele licencjonowania, zmiany w wsparciu lub wymagania dotyczące infrastruktury mogą wymagać zmiany strategii wdrożenia.

Im większa zależność od jednej platformy wdrożeniowej, tym większy potencjalny wpływ operacyjny tych zmian na biznes.

Zachowanie alternatywnych opcji dostawy może złagodzić to ryzyko i stworzyć większą elastyczność w miarę zmiany potrzeb biznesowych lub technologicznych.

Jak możesz zredukować ryzyko związane z uzależnieniem od dostawcy VDI?

Redukcja uzależnienia od dostawcy VDI wymaga zestawu technicznych, związanych z obciążeniem i architektonicznych rozważań.

Pomysł polega nie na unikaniu dostawców, lecz na umożliwieniu zmian platformy bez zakłócania wszystkich innych aspektów dostarczania aplikacji.

1. Audyt istniejących zależności VDI

Pierwszym krokiem jest zidentyfikowanie, co jest kluczowe dla dostarczania aplikacji i pulpitów, oraz które komponenty są zależne od technologii specyficznej dla dostawców.

Inwentaryzacja zależności powinna uwzględniać następujące pytania:

Komponent	Pytania do zbadania
Broker połączeń	Czy przypisania pulpitu i aplikacji mogą być odtworzone gdzie indziej?
Hyperwizor	Czy maszyny wirtualne i obrazy mogą przenosić się do alternatywnej infrastruktury?
Aplikacje	Czy aplikacje wymagają konkretnych obrazów, systemów operacyjnych lub sterowników?
Profile użytkowników	Czy ustawienia i dane mogą migrować niezależnie?
Uwierzytelnianie	Czy polityki tożsamości są powiązane z integracjami własnościowymi?
Licencjonowanie	Jakie zobowiązania, prawa dostępu i koszty wyjścia mają zastosowanie?
Automatyzacja	Jakie skrypty polegają na specyficznych dla dostawcy interfejsach API lub narzędziach?

Inwentaryzacja musi również obejmować właścicieli aplikacji, krytyczność biznesową, wymagania dotyczące odzyskiwania oraz niedokumentowane dostosowania.

Ta klasyfikacja może pomóc menedżerom IT zrozumieć, które zależności można łatwo zastąpić, a które wymagają znacznego prz redesignu.

2. Oddziel dostarczanie aplikacji od infrastruktury pulpitu

Jedną z najlepszych metod na zmniejszenie potrzeby na VDI jest upewnienie się, że każda aplikacja rzeczywiście wymaga tak skomplikowanego rozwiązania.

Podczas gdy VDI oferuje wirtualne pulpity, publikacja aplikacji zapewnia remote access do poszczególnych aplikacji bez konieczności dostarczania całego pulpitu.

Obie metody centralizują aplikacje, ale w różny sposób.

Wymaganie	Pełne VDI	Publikacja aplikacji opartych na sesjach
Pełny spersonalizowany pulpit	Dobrze dopasowany	Nie jest to główny cel
Indywidualne aplikacje Windows	Obsługiwany	Dobrze dopasowany
Izolacja dedykowanego systemu operacyjnego na komputerze stacjonarnym	Dostępny	Ogólnie używa współdzielonych hostów sesji
Specjalistyczne konfiguracje pulpitu	Często odpowiednie	Zależy od zgodności
Zcentralizowane zarządzanie aplikacjami	Obsługiwany	Obsługiwany
Dostęp przez przeglądarkę	Zależny od platformy	Dostępne z kompatybilnymi rozwiązaniami
Dostawa bez pełnego stosu VDI	Nie ogólnie	Możliwe

Różnica jest architektoniczna, a nie funkcjonalna.

Wiele takich systemów VDI już umożliwia publikację aplikacji, więc umożliwienie publikacji aplikacji niekoniecznie pomoże Ci uniknąć uzależnienia od dostawcy, chyba że te aplikacje można odłączyć od płaszczyzny kontrolnej VDI.

Powiedzmy, że masz dział księgowości, który potrzebuje dostępu do aplikacji finansowej Windows, ale nie potrzebuje własnych wirtualnych pulpitów. Publikując aplikację na komputerze z systemem Windows (prawidłowo skonfigurowanym), możesz uniknąć konieczności zmuszania wszystkich do korzystania z VDI, jednocześnie utrzymując centralizację administracji aplikacji.

Z drugiej strony, osoby, które potrzebują trwałych pulpitów, gdzie każdy użytkownik ma swoją własną sesję pulpitu, mogą potrzebować pełnego VDI.

3. Przyjmij modułowe i interoperacyjne architektury

Architektury modułowe umożliwiają wymianę poszczególnych elementów bez zakłócania ogólnego środowiska dostarczania aplikacji.

Zespoły IT powinny priorytetowo traktować następujące kwestie, gdzie to możliwe:

• Ustandaryzowana tożsamość i uwierzytelnianie
• Kod aplikacji przenośnej i udokumentowane zależności
• Dane użytkownika oddzielone od obrazów pulpitu
• Infrastruktura jako kod: powtarzalne wdrażanie, automatyzacja
• Dostawa, która działa w różnych punktach końcowych i środowiskach hostingowych

Zauważ, że oddzielenie danych użytkowników od obrazów pulpitu uprości zarówno migracje, jak i odzyskiwanie po awarii: podobnie, infrastruktura jako kod pomoże operacjom w odtwarzaniu środowisk z lepszą spójnością.

Jednak nawet otwarte standardy i automatyzacja mogą nie zapobiec uzależnieniu od dostawcy: często występują subtelne różnice w implementacji między technologiami różnych dostawców, a skrypty mogą zawierać wywołania do własnych interfejsów API.

Dlatego celem jest unikanie niepotrzebnego sprzężenia między komponentami aplikacji a komponentami infrastruktury, zarządzania i operacyjnymi.

4. Rozważ dostarczanie aplikacji hybrydowych

Organizacje nie muszą wybierać między zachowaniem całej swojej infrastruktury VDI a zastąpieniem jej czymś zupełnie innym.

Mogliby przyjąć hybrydową strategię, która wykorzystuje różne obciążenia zgodnie z ich potrzebami.

Organizacja mogłaby wykorzystać dedykowane pulpity dla zaawansowanych użytkowników, jednocześnie hostując kompatybilne aplikacje biznesowe na współdzielonych hostach sesji Windows.

Mogliby również dostarczać aplikacje dziedziczone przez przeglądarki. W przypadku oprogramowania Windows, które nie może być łatwo przepisane, zrozumienie jak opublikować oprogramowanie Windows w sieci może pomóc zespołom IT ocenić dostarczanie oparte na przeglądarkach jako część ich hybrydowej strategii.

Lokalne aplikacje najlepiej zachować, gdy centralizacja niewiele poprawia ogólną wydajność.

Taka strategia umożliwi działowi IT zachowanie istniejących inwestycji w infrastrukturę, podczas gdy będą przechodzić do nowych technologii we własnym tempie.

Wyzwanie związane z tym podejściem polega na tym, że tworzy ono dodatkową złożoność i wymaga bardziej kompleksowego zarządzania tożsamością, jednolitych środków bezpieczeństwa na wszystkich platformach, zasad monitorowania oraz procedur wsparcia.

5. Porównaj całkowity koszt modeli dostawy

Oszczędności związane z licencjonowaniem same w sobie nie decydują o opłacalności alternatywnej architektury dostarczania aplikacji.

Zespoły IT powinny ocenić całkowity koszt posiadania, w tym infrastrukturę, koszty oprogramowania, administrację, bezpieczeństwo i migrację.

Kategoria kosztów	Kryteria oceny
Oprogramowanie	Licencjonowanie, subskrypcje, wsparcie i odnowienia
Infrastruktura	Obliczenia, przechowywanie, sieci i zużycie chmury
Systemy operacyjne	Licencjonowanie systemu Windows i odpowiednie prawa dostępu
Administracja	Zarządzanie, konserwacja, monitorowanie i rozwiązywanie problemów
Bezpieczeństwo	MFA, kontrole dostępu, audyt i zarządzanie bezpieczeństwem
Migracja	Testowanie, konfiguracja, szkolenie i wdrożenie
Ciągłość działania	Dostępność, kopia zapasowa, odzyskiwanie i narażenie na przestoje

Publikacja aplikacji może zmniejszyć potrzebę na konkretne komponenty w środowisku VDI, ale ma swoje własne wymagania dotyczące wdrożenia i licencjonowania.

Na przykład tradycyjne konfiguracje hostingu sesji Microsoft Remote Desktop Services (RDS) wymagałyby odpowiednich licencji dostępu klienta RDS, jak opisano w Dokumentacja CAL RDS firmy Microsoft .

Wymagania licencyjne powinny być weryfikowane na podstawie rzeczywistej architektury, produktu dostarczanego oraz odpowiednich warunków i zasad Microsoft.

Celem powinno być zminimalizowanie całkowitych kosztów przy jednoczesnym zapewnieniu bezpieczeństwa, wydajności i niezawodności niezbędnych do zaspokojenia potrzeb biznesowych.

Co musisz zrobić, aby uwolnić się od uzależnienia od dostawcy VDI?

Redukcja zależności od dostawcy jest znacznie bezpieczniejsza, gdy jest realizowana stopniowo, a nie poprzez całkowitą wymianę platformy.

Migracja etapowa daje zespołom IT możliwość przetestowania alternatywnych metod dostarczania, jednocześnie utrzymując status quo.

Krok 1: Klasyfikacja aplikacji według wymagań dostawy

Zacznij od grupowania aplikacji na podstawie ich zależności technicznych i wymagań użytkowników końcowych. Trzy szerokie kategorie są szczególnie pomocne w identyfikacji:

• Aplikacje wymagające pełnych pulpitów – obciążenia wymagające dedykowanego środowiska systemu operacyjnego, specjalnej konfiguracji lub izolacji na poziomie pulpitu
• Aplikacje odpowiednie do publikacji zdalnej – aplikacje systemu Windows, kompatybilne z obsługiwanymi środowiskami hostów sesji współdzielonych/poświęconych.
• Aplikacje odpowiednie do lokalnego lub natywnego dostępu przez przeglądarkę – oprogramowanie, które nie wymaga już uruchamiania w środowisku VDI.

Taka klasyfikacja może pomóc administratorowi zidentyfikować kandydatów do alternatywnych modeli dostarczania, które nie wymagają znaczących adaptacji.

Krok 2: Wybierz obciążenie pilotażowe o niskim ryzyku

Wybierz aplikację o jasno określonych wymaganiach dotyczących zasobów, niewielu zależnościach i ograniczonej liczbie użytkowników.

Unikaj rozpoczynania od aplikacji krytycznych dla biznesu, które są zależne od skomplikowanych integracji zewnętrznych, unikalnych sterowników lub podatnych komponentów dziedzictwa.

Pilot powinien udowodnić zdolność alternatywnej infrastruktury do odpowiedniego odwzorowania kluczowych funkcji i doświadczenia użytkownika oryginalnego środowiska.

Krok 3: Sprawdź zgodność, wydajność i bezpieczeństwo

Zanim zwiększysz skalę, przetestuj funkcje i cechy operacyjne w realistycznych środowiskach.

Projekt migracji dostarczania aplikacji musi obejmować następujące obszary w scenariuszu testowym:

• Instalacja aplikacji, zależności i licencjonowanie
• Uwierzytelnianie, MFA i uprawnienia użytkowników
• Profile użytkowników, ustawienia i dostęp do plików
• Drukowanie, schowek i przekierowanie urządzeń peryferyjnych
• Współbieżność sesji i zużycie zasobów
• Opóźnienie, responsywność i ponowne połączenie
• Rejestrowanie, monitorowanie i polityki bezpieczeństwa
• Kopie zapasowe, procedury przywracania i cofania

Uruchamianie aplikacji z powodzeniem nie gwarantuje pełnej zgodności.

Na przykład, aplikacja może działać dobrze samodzielnie, ale może nie działać, gdy kilku użytkowników próbuje ją uruchomić jednocześnie lub drukować dokumenty na drukarkach.

Zespoły IT muszą zaprojektować niezbędne testy i kryteria wydajności dla sesji, aplikacji, bezpieczeństwa i funkcji przywracania.

Krok 4: Migracja aplikacji w kontrolowanych fazach

Gdy pilotaż spełni swoje kryteria akceptacji, zwiększ wdrożenie w oparciu o priorytet biznesowy i złożoność techniczną.

Zachowaj oryginalne środowisko dostawy podczas przejścia, gdy to możliwe, umożliwiając administratorom porównanie wydajności, skuteczne rozwiązywanie problemów i powrót do ustalonych procesów w razie potrzeby.

Dokumentowanie kryteriów sukcesu, przypisanie odpowiedzialności oraz ustalenie procedur przywracania dla każdej fazy migracji. Środki te również przyczyniają się do odporność aplikacji pomagając organizacjom zachować kluczowe funkcje biznesowe podczas zmian w infrastrukturze.

Krok 5: Przejrzyj pozostałe zależności

Problem związany z uzależnieniem od dostawcy nie ogranicza się do pojedynczego przypadku.

Nowe aplikacje, potrzeba aktualizacji platformy, zmiany w licencjonowaniu lub dostosowaniu operacyjnym mogą stworzyć dodatkowe zależności po zakończeniu migracji.

Dlatego potrzebne są okresowe przeglądy, aby zapewnić, że aplikacje mogą nadal działać na docelowej platformie, że konfiguracje zostały prawidłowo zapisane i że inne środki dostawy pozostają dostępne.

To pozwoli nowemu środowisku uniknąć stania się kolejnym zamkniętym systemem dostawcy.

W jakim przypadku VDI jest dobrym rozwiązaniem do zachowania?

Redukcja uzależnienia od dostawcy VDI nie wymaga całkowitej wymiany VDI.

VDI ma uzasadnioną wartość w scenariuszach, które wymagają dedykowanych systemów operacyjnych, trwałych pulpitów, aplikacji intensywnie wykorzystujących grafikę lub izolacji obciążenia, której nie mogą zapewnić współdzielone hosty sesji.

Jest to również cenne dla dostarczania ustandaryzowanych, centralnie zarządzanych pulpitów z jednolitymi zasadami zarządzania pulpitem.

Decyzja o przyjęciu innej architektury powinna opierać się na zachowaniu aplikacji, potrzebach bezpieczeństwa, wymaganiach użytkowników i czynnikach ekonomicznych.

Dla większości organizacji rozproszona architektura jest bardziej praktyczna niż zmuszanie wszystkich aplikacji do tego samego modelu dostarczania.

Zachowanie VDI dla obciążeń, które tego wymagają, podczas korzystania z niezależnego publikowania aplikacji dla innych obciążeń pozwoliłoby na zmniejszenie uzależnienia od VDI bez rezygnacji z możliwości VDI.

Jak może dostarczanie aplikacji pozostać elastyczne w dłuższej perspektywie?

Długoterminowa elastyczność systemu osiągana jest dzięki możliwości zachowania kontroli nad relacją aplikacji z infrastrukturą oraz dostępem użytkowników.

Aplikacje muszą być zaprojektowane w sposób umożliwiający ich dalsze działanie na potencjalnie zmieniającej się infrastrukturze dostawców hostingu, hypervisorach lub platformach wirtualizacji pulpitu.

To podejście wymaga szczególnej uwagi na odpowiednią dokumentację zależności, izolację danych aplikacji od jej mechanizmów dostarczania, zachowanie powtarzalnej konfiguracji oraz ciągłe badanie alternatywnych podejść i konfiguracji.

Na przykład, podczas gdy aplikacja napisana dla systemu Windows może być migrowana do uruchomienia na centralnie zarządzanych serwerach Windows w nowej organizacji, która wykorzystuje różne oprogramowanie hostingowe lub hypervisory, lub zastąpiła swoje oprogramowanie do pośrednictwa VDI, nie oznacza to, że aplikacja jest uniwersalnie przenośna.

Aplikacje muszą być testowane pod kątem ich zdolności do działania na różnych infrastrukturach, w tym wariantach podstawowego systemu operacyjnego, odpowiednich licencjach, zgodności specyficznej dla aplikacji lub cechach wydajnościowych.

Jednym z pomocnych wskaźników elastyczności jest przenośność aplikacji między znacząco różnymi środowiskami.

Jeśli migracja aplikacji do innej, ale wspieranej infrastruktury wymaga znacznego przekształcenia niezwiązanych elementów z powodu obecności wielu zależności, wskazuje to, że należy wykonać wiele pracy, zanim aplikacja będzie mogła być uznana za przenośną.

Ten wskaźnik można stosować iteracyjnie, aby stopniowo zwiększać elastyczność potrzeb infrastrukturalnych aplikacji lub wprowadzać zmiany operacyjne bez konieczności całkowitego przerabiania samej aplikacji.

Szukasz prostszego sposobu na dostarczanie aplikacji Windows?

TSplus Zdalny Dostęp oferuje alternatywę dla organizacji, które chcą publikować aplikacje Windows i dostarczać zdalne pulpity bez wdrażania tradycyjnego pełnego stosu VDI. Dzięki publikacji aplikacji, dostępowi przez przeglądarkę HTML5 oraz wsparciu dla środowisk Windows hostowanych lokalnie lub w chmurze, pomaga zespołom IT zróżnicować opcje dostarczania, zachowując jednocześnie centralną kontrolę.

Wniosek

Zamknięcie dostawcy VDI staje się kosztowne, gdy aplikacje zależą od ściśle zintegrowanej infrastruktury, licencjonowania i systemów zarządzania. Mapowanie tych zależności i wprowadzenie alternatywnych metod dostarczania może pomóc organizacjom zachować kontrolę bez całkowitego porzucania VDI.

Elastyczna architektura pozwala zespołom IT na utrzymanie odpowiednich obciążeń na wirtualnych pulpitach, jednocześnie upraszczając dostęp do innych, zmniejszając ryzyko migracji i zachowując przyszłe opcje.