Tworzenie aplikacji przenośnych za pomocą aplikacji adaptacyjnych

Azure Kubernetes Service (AKS)
Azure Arc
Azure lokalnie

Pomysły dotyczące rozwiązań

W tym artykule opisano pomysł rozwiązania. Architekt chmury może użyć tych wskazówek, aby ułatwić wizualizację głównych składników typowej implementacji tej architektury. Skorzystaj z tego artykułu jako punktu wyjścia, aby zaprojektować dobrze zaprojektowane rozwiązanie zgodne z konkretnymi wymaganiami obciążenia.

Przenośność to wymaganie zaopatrzenia i operacyjne dla nowoczesnych aplikacji. Zespoły muszą projektować aplikacje, które są odwracalne i mogą być przekierowywane do różnych obiektów docelowych, w tym suwerennych chmur, infrastruktury lokalnej i sporadycznie połączonych środowisk brzegowych. Następujące warunki zwiększają potrzebę przenoszenia:

  • Reguły rezydencji i niezależności danych
  • Mandaty zgodności specyficzne dla sektora
  • Sporadyczne środowiska łączności
  • Wymagania dotyczące ciągłości działania

Wzorce sztucznej inteligencji platformy Kubernetes z obsługą usługi Arc, radius i brzegowej sztucznej inteligencji tworzą praktyczne podstawy dla modelu architektury, który może spełniać wymagania dotyczące przenośności. Ten model architektury to rozwiązanie aplikacji adaptacyjnych .

Aplikacje adaptacyjne oddzielają intencję aplikacji od implementacji specyficznej dla środowiska. Deweloperzy opisują obciążenia i wymagane możliwości raz, a operatorzy platform wiążą te przenośne zasoby z lokalnymi przepisami dotyczącymi usług, zasadami, tożsamością, siecią, możliwością obserwacji i infrastrukturą odpowiednią dla każdego środowiska. W tym artykule opisano rozwiązanie aplikacji adaptacyjnych i pokazano, w jaki sposób portfolio możliwości, otwarte protokoły i przepływy pracy wdrażania oparte na usłudze Radius umożliwiają aplikacjom zachowanie spójności, zarządzania i działania wszędzie tam, gdzie działają.

Architecture

Aplikacja modelowana za pomocą usługi Radius składa się z zestawu zasobów. Te zasoby można podzielić na składniki aplikacji i zasoby na poziomie platformy, które obsługują aplikację. Kolekcja tych zasobów na poziomie platformy jest nazywana portfolio możliwości.

Zasób radius definiuje abstrakcyjny interfejs do możliwości na poziomie platformy. Podczas wdrażania zasobu radius w środowisku docelowym przepis specyficzny dla celu może mapować ten typ zasobu na konkretną implementację specyficzną dla platformy. Projektujesz portfolio możliwości w różnych środowiskach docelowych za pomocą odpowiednich przepisów.

Ta architektura zapewnia aplikację z wymaganymi możliwościami bez konieczności ponownego pisania kodu aplikacji dla każdej konkretnej platformy.

Diagram przedstawiający architekturę aplikacji adaptacyjnych.

Pobierz plik programu Visio tej architektury.

Architektura umożliwia przenośność za pośrednictwem dwóch uzupełniających warstw abstrakcji.

  • Najpierw usługa Radius zapewnia abstrakcję modelu aplikacji, która oddziela wymagania aplikacji od implementacji specyficznych dla platformy. Abstrakcyjne typy zasobów reprezentują zasoby, takie jak bazy danych, pamięci podręczne lub systemy obsługi komunikatów, które mogą być mapowane na różne implementacje za pomocą przepisów specyficznych dla środowiska. Takie podejście umożliwia wdrożenie tej samej definicji aplikacji w wielu środowiskach bez modyfikowania artefaktów wdrożenia.

  • Po drugie, aplikacje mogą przyjąć abstrakcję modelu programowania. Aplikacje mogą wchodzić w interakcje z zależnościami za pośrednictwem powszechnie przyjętych standardów i protokołów lub za pośrednictwem opcjonalnej warstwy abstrakcji opartej na przyczepce, takiej jak Dapr. Te podejścia zmniejszają sprzężenie aplikacji z interfejsami API usług specyficznymi dla platformy i zwiększają przenośność między środowiskami.

Te abstrakcje zapewniają atrakcyjne środowisko "zapisu raz, uruchamiane w wielu środowiskach", ale także wprowadzenie kompromisów. Aby zachować przenośność, aplikacje mogą wymagać ograniczenia bezpośredniego korzystania z funkcji i optymalizacji specyficznych dla platformy, które nie są dostępne we wszystkich środowiskach docelowych. W przypadku korzystania z przyczepki lub typowej abstrakcji programowania w celu osiągnięcia przenośności należy zaakceptować ograniczenia nałożone przez tę warstwę abstrakcji.

Zespoły muszą zobowiązać się do sprawdzania poprawności zachowania aplikacji w obsługiwanych miejscach docelowych wdrażania, co zwiększa złożoność testowania i działania. Wyświetl przenośność jako celowy wybór architektury, który poświęca lepszą integrację platformy w celu zapewnienia elastyczności wdrożenia, zmniejszenia blokady i większej spójności w środowiskach heterogenicznych.

Workflow

Poniższy przepływ pracy odpowiada powyższemu diagramowi. Przepływ pracy opisuje przykładową aplikację zawierającą typowe składniki, takie jak fronton, zaplecze, agent sztucznej inteligencji, broker komunikatów i dostawca tożsamości OpenID Connect (OIDC).

  1. Deweloper aplikacji używa definicji aplikacji radius do opisania obciążenia jednorazowo.

    Definicja aplikacji składa się z listy zasobów, takich jak Applications.Core/containers zasób opisujący fronton i zaplecze konteneryzowanego ładunku. Wzorzec adaptacyjnych aplikacji definiuje również kilka rozszerzeń typu zasobów, które abstrakcji typowych możliwości platformy w celu oddzielenia aplikacji od dowolnej określonej platformy.

    Zamiast definiować abstrakcje nowych płaszczyzn danych, aplikacje adaptacyjne używają powszechnie przyjętych składników typu open source i otwartych protokołów, takich jak OIDC do uwierzytelniania i Queuing Telemetry Transport (MQTT) na potrzeby obsługi komunikatów. Takie podejście uniemożliwia aplikacji ograniczenie przez abstrakcyjny interfejs i umożliwia bezpośrednie korzystanie z pełnych możliwości odpowiednich protokołów.

    Typ zasobu Purpose
    Radius.Resources/agentGuardrails Zasady ładu specyficzne dla agenta
    Radius.Resources/aiModels Modele sztucznej inteligencji obsługujące wnioskowanie sztucznej inteligencji
    Radius.Resources/governance Zasady ładu w przedsiębiorstwie
    Radius.Resources/mqttBrokers Brokerzy komunikatów na podstawie MQTT
    Radius.Resources/workloadIdentities Tożsamości obciążeń używane do identyfikowania obciążenia lub agenta w aplikacji

  2. Deweloper może tworzyć lub aktualizować kod aplikacji przy użyciu przenośnego interfejsu API.

    Na poziomie modelu programowania aplikacja może dalej wdrażać technologie przyczepki, takie jak Dapr, które zapewniają niezależne od platformy interfejsy API do typowych zadań, takich jak pub/sub, zarządzanie stanem i wpisy tajne. Usługa Radius ma natywną obsługę przyczepek Dapr.

    Usługi brownfield, które już używają Azure SDKs, mogą nadal działać w miejscach docelowych, jeśli są dostępne wymagane punkty końcowe Azure, przepływy tożsamości i łączność sieciowa. Usługi korzystające z wspólnych protokołów mogą nadal działać w przypadku zgodnych implementacji. W celu zwiększenia przenośności nowe usługi mogą wdrażać interfejsy API języka Dapr, aby ułatwić aplikacjom dostosowanie się do większej liczby odmian platformy.

  3. Operator platformy uruchamia portfolio możliwości dla każdego obiektu docelowego.

    Operator wybiera jeden z sześciu wstępnie zdefiniowanych portfeli: min, , core, entmin-ai, core-ailub ent-ai, na podstawie potrzeb środowiska i zgodności. Operator instaluje portfolio za pomocą wykresu programu Helm. W poniższej tabeli przedstawiono, czy wstępnie zdefiniowane portfolio obsługują różne protokoły.

    Portfel Tożsamość (OIDC) Siatka usługi (Istio) Obserwowanie (OTel) Ład (OPA) Sztuczna inteligencja w klastrze (Kaito) Poręcz agenta
    min ✓ ✗ ✗ ✗ ✗ ✗
    core ✓ ✓ ✓ ✗ ✗ ✗
    ent ✓ ✓ ✓ ✓ ✗ ✗
    min-ai ✓ ✗ ✗ ✗ ✓ ✗
    core-ai ✓ ✓ ✓ ✗ ✓ ✓
    ent-ai ✓ ✓ ✓ ✓ ✓ ✓

    Aplikacje adaptacyjne udostępniają również narzędzie wiersza polecenia ułatwiające kroki konfiguracji infrastruktury poza instalacją programu Helm i udostępnianie informacji o infrastrukturze na potrzeby wdrażania aplikacji.

  4. Usługa Radius wiąże aplikację z przepisami specyficznymi dla środowiska.

    W przypadku rad deploy uruchamiania względem docelowego obszaru roboczego przepis zarejestrowany w środowisku aprowizuje każdy przenośny zasób w aplikacji adaptacyjnej. Na przykład Radius.Resources/aiModels rozwiązanie jest rozpoznawane jako lokalny model małego języka (SLM) zarządzanego przez firmę Kaito , gdy aplikacja jest wdrażana w lokalnym środowisku Kubernetes. Ten sam zasób jest rozpoznawany jako punkt końcowy openAI lub Azure OpenAI podczas wdrażania w środowisku chmury. Usługa Radius wprowadza informacje o połączeniu dla zależności, które jawnie deklaruje definicja aplikacji.

    Diagram przedstawiający aplikację adaptacyjną modelowaną przy użyciu modelu aplikacji radius przewidywanego w różnych środowiskach docelowych za pośrednictwem odpowiednich przepisów.

    Pobierz plik programu Visio z tego diagramu.

Components

  • Radius to model aplikacji typu open source, który wyraża obciążenie jako graf przenośnych typów zasobów i rozpoznaje każdy typ w przepisie specyficznym dla środowiska w czasie wdrażania. W tej architekturze usługa Radius jest podstawowym kontraktem między zespołami aplikacji i operatorami platformy. Aplikacje adaptacyjne używają również narzędzi radius do wdrażania aplikacji w środowiskach docelowych.

  • Portfolio możliwości to kontrakty między aplikacjami a ich platformami hostingu. Ta architektura ma sześć wstępnie zdefiniowanych portfolio dla warstw możliwości, od punktu odniesienia do pełnej konfiguracji przedsiębiorstwa z wymuszania zasad i sztucznej inteligencji w klastrze. Operatorzy platformy instalują portfolio możliwości jako wykresy helm.

  • Narzędzia oparte na sztucznej inteligencji zapewniają interfejs wiersza polecenia na potrzeby konfiguracji infrastruktury i migracji wspomaganej przez sztuczną inteligencję aplikacji brownfield. W tej architekturze narzędzia ułatwiają migrowanie aplikacji typu brownfield, w tym aplikacji mikrousług, starszych aplikacji i aplikacji mainframe do modelu aplikacji radius.

Szczegóły scenariusza

Zespół ds. obciążeń może wymagać uruchomienia tej samej aplikacji w infrastrukturze heterogenicznej, która może obejmować następujące środowiska:

  • Region chmury publicznej dla obciążeń elastycznych
  • Suwerenny region spełniający zobowiązania dotyczące rezydencji danych
  • Lokalne centrum danych na potrzeby przetwarzania wrażliwego na opóźnienia
  • Flota klastrów brzegowych ze sporadycznymi połączeniami

Każde środowisko ma zazwyczaj własnego dostawcę tożsamości, nakładkę siatki usług, stos możliwości obserwowania, aparat zasad i strategię sztucznej inteligencji. Bez ujednolicania kontraktu zespoły aplikacji muszą utworzyć rozwidlenie bazy kodu dla każdego obiektu docelowego, zablokować się na jednej platformie lub generować koszty refaktoryzacji za każdym razem, gdy dodają nowe środowisko.

Aplikacje adaptacyjne rozwiązać ten problem, tworząc platformę, a nie aplikację, odpowiedzialną za absorbowanie zmian środowiskowych. Aplikacja jest utworzona raz w modelu aplikacji radius i opcjonalnie model programowania Dapr. Każde środowisko docelowe instaluje portfolio możliwości, które uwidacznia możliwości wymagane przez aplikację. Warstwa przepisu wiąże przenośne zasoby z implementacjami specyficznymi dla środowiska w czasie wdrażania.

Architektura jest celowo nieskrypcyjna dla płaszczyzny sterowania. Dostawcy możliwości mogą dostarczać portfolio za pośrednictwem programów Helm, rozszerzeń Arc, Bicep, Terraform lub instalatorów niestandardowych. Aplikacje pozostają przenośne, o ile wynikowe środowisko spełnia umowę możliwości portfela.

Potencjalne przypadki użycia

  • Suwerenne i regulowane wdrożenia w chmurze

    Regulowane obciążenie musi działać w suwerennej chmurze lub w infrastrukturze kontrolowanej przez klienta podczas udostępniania bazy kodu z wersją chmury publicznej. Portfolio core-ai lub ent-ai zapewnia spójny kontrakt możliwości między celami wdrażania, co umożliwia przenoszenie aplikacji. Środowisko docelowe wymusza konkretną implementację funkcji i mechanizmów kontroli, w tym przechowywania danych, szyfrowania, kontroli dostępu, inspekcji i certyfikacji zgodności w celu spełnienia wymagań dotyczących niezależności i przepisów prawnych.

  • Modernizacja brownfield bez ponownego odtworzenia

    Zespół ds. obciążeń stopniowo modernizuje starszą aplikację mikrousług, wprowadzając definicje zasobów usługi Radius w celu opisania zależności infrastruktury i selektywnego wdrażania funkcji języka Dapr. Narzędzia refaktoryzacji oparte na sztucznej inteligencji pomagają przyspieszyć część migracji. Takie podejście umożliwia zespołom modernizację aplikacji w celu poprawy przenośności, możliwości obserwowania i spójności operacyjnej w tempie zgodnym z wymaganiami biznesowymi i technicznymi.

  • Wnioskowanie hybrydowej sztucznej inteligencji na brzegu

    Obciążenie handlu detalicznego lub przemysłowego uruchamia tę samą aiModel usługę w Azure w siedzibie firmy przez wywołanie Azure OpenAI i klastrów Azure lokalnie w sklepach lub zakładach przez wywołanie modelu open source hostowanego w usłudze Kaito. Kod aplikacji jest identyczny i różni się tylko aiModel przepis.

  • Sporadycznie połączona krawędź

    Wdrożenie obrony, morskiej lub zdalnej lokacji uruchamia min-ai portfolio w jednym klastrze z ograniczonymi zasobami bez zależności od tożsamości hostowanej w chmurze ani usług sztucznej inteligencji. To samo obciążenie, gdy zostanie ponownie wdrożone w usłudze AKS z core-ai portfolio, automatycznie zyskuje siatkę i możliwość obserwacji. Portfolio ent-ai dodaje również wymuszanie zasad ładu.

  • Wdrażanie w wielu chmurach

    Zespół ds. obciążeń wdraża modelowane zasoby aplikacji w innym obszarze roboczym przy użyciu programu rad deploy, o ile każdy element docelowy implementuje ten sam kontrakt możliwości. Traktują one skalowanie obciążeń i odzyskiwanie po awarii jako oddzielne kwestie. Używane środowisko pomocnicze wymaga również pojemności, artefaktu i dostępności danych, sekwencjonowania zależności, tożsamości, łączności sieciowej, routingu ruchu, kontroli kondycji i przetestowanych procedur trybu failover/powrotu po awarii.

Współautorzy

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok