Erstellen von tragbaren Anwendungen mit adaptiven Apps

Azure Kubernetes Service (AKS)
Azure Arc
Azure Lokal

Lösungsmöglichkeiten

In diesem Artikel wird eine Lösungsidee beschrieben. Ihr Cloudarchitekt kann diesen Leitfaden verwenden, um die Hauptkomponenten einer typischen Implementierung dieser Architektur zu visualisieren. Verwenden Sie diesen Artikel als Ausgangspunkt, um eine gut durchdachte Lösung zu entwerfen, die den spezifischen Anforderungen Ihrer Workload entspricht.

Portabilität ist eine Beschaffungs- und Betriebsanforderung für moderne Anwendungen. Teams muss Anwendungen entwerfen, die umkehrbar sind und zu verschiedenen Zielen portiert werden können, darunter souveräne Clouds, lokale Infrastruktur und zeitweise verbundene Edgeumgebungen. Die folgenden Bedingungen fördern die Notwendigkeit der Portabilität:

  • Vorgaben zu Datenresidenz und Datensouveränität
  • Branchenspezifische Compliance-Mandate
  • Intermittierende Konnektivitätsumgebungen
  • Geschäftskontinuitätsanforderungen

Arc-fähige Kubernetes-, Radius- und Edge-KI-Muster schaffen eine praktische Grundlage für ein Architekturmodell, das die Portabilitätsanforderungen erfüllen kann. Dieses Architekturmodell ist die Lösung für adaptive Apps .

Adaptive Apps trennen anwendungsspezifische Absichten von der umgebungsspezifischen Implementierung. Entwickler beschreiben Workloads und erforderliche Funktionen einmal, und Plattformbetreiber binden diese tragbaren Ressourcen an lokale Dienstrezepte, Richtlinien, Identität, Netzwerke, Observierbarkeit und Infrastruktur, die für jede Umgebung geeignet sind. Dieser Artikel beschreibt die Lösung für adaptive Anwendungen und zeigt, wie Fähigkeitsportfolios, offene Protokolle und Radius-basierte Bereitstellungsworkflows es Anwendungen ermöglichen, konsistent, verwaltbar und betriebsfähig zu bleiben, unabhängig davon, wo sie ausgeführt werden.

Architecture

Eine mit Radius modellierte Anwendung besteht aus einer Reihe von Ressourcen. Sie können diese Ressourcen in Anwendungskomponenten und Ressourcen auf Plattformebene kategorisieren, die die Anwendung unterstützen. Die Sammlung dieser Ressourcen auf Plattformebene wird als Funktionsportfolio bezeichnet.

Eine Radius-Ressource definiert eine abstrakte Schnittstelle zu einer Plattformebenenfunktion. Wenn Sie eine Radius-Ressource in einer Zielumgebung bereitstellen, kann ein zielspezifisches Rezept diesen Ressourcentyp einer konkreten plattformspezifischen Implementierung zuordnen. Sie projizieren das Funktionsportfolio in verschiedene Zielumgebungen über entsprechende Rezepte.

Diese Architektur bietet der Anwendung die erforderlichen Funktionen, ohne dass der Anwendungscode für jede bestimmte Plattform neu geschrieben werden muss.

Diagramm, das die Architektur adaptiver Apps zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Architektur ermöglicht die Portabilität durch zwei komplementäre Abstraktionsebenen.

  • Zunächst bietet Radius eine Abstraktion des Anwendungsmodells, die Anwendungsanforderungen von plattformspezifischen Implementierungen trennt. Abstrakte Ressourcentypen stellen Ressourcen wie Datenbanken, Caches oder Messagingsysteme dar, die verschiedenen Implementierungen über umgebungsspezifische Rezepte zugeordnet werden können. Mit diesem Ansatz können Sie dieselbe Anwendungsdefinition in mehreren Umgebungen bereitstellen, ohne Bereitstellungsartefakte zu ändern.

  • Zweitens können Anwendungen eine Programmiermodellstraktion übernehmen. Anwendungen können mit Abhängigkeiten über weit verbreitete Standards und Protokolle oder über eine optionale Sidecar-basierte Abstraktionsebene wie Dapr interagieren. Diese Ansätze reduzieren die Anwendungskopplung mit plattformspezifischen Dienst-APIs und verbessern die Portabilität in allen Umgebungen.

Diese Abstraktionen bieten eine überzeugende "einmal geschriebene, in vielen Umgebungen ausgeführte" Erfahrung, aber sie führen auch Kompromisse ein. Um portabel zu bleiben, müssen Anwendungen möglicherweise die direkte Verwendung plattformspezifischer Features und Optimierungen einschränken, die nicht in allen Zielumgebungen verfügbar sind. Wenn Sie ein Sidecar oder eine allgemeine Programmierabstraktion verwenden, um Portabilität zu gewährleisten, müssen Sie die durch diese Abstraktionsebene vorgegebenen Einschränkungen akzeptieren.

Teams müssen sich dazu verpflichten, das Anwendungsverhalten für alle unterstützten Bereitstellungsziele zu validieren, was die Test- und Betriebskomplexität erhöht. Betrachten Sie Portabilität als eine bewusste architektonische Entscheidung, bei der eine engere Plattformintegration zugunsten von Bereitstellungsflexibilität, geringerer Herstellerbindung und mehr Konsistenz über heterogene Umgebungen hinweg geopfert wird.

Arbeitsablauf

Der folgende Workflow entspricht dem vorhergehenden Diagramm. Der Workflow beschreibt eine Beispiel-App, die typische Komponenten wie Front-End, Back-End, AI-Agent, Nachrichtenbroker und OpenID Connect (OIDC)-Identitätsanbieter enthält.

  1. Ein Anwendungsentwickler verwendet eine Radius-Anwendungsdefinition, um die Workload einmal zu beschreiben.

    Die Anwendungsdefinition besteht aus einer Liste von Ressourcen, z. B. einer Applications.Core/containers Ressource, die ein containerisiertes Nutzlast-Front-End und back-End beschreibt. Das Muster für adaptive Apps definiert auch einige Ressourcentyperweiterungen, die allgemeine Plattformfunktionen abstrahieren, um die Anwendung von einer bestimmten Plattform zu entkoppeln.

    Statt neue Datenebenenabstraktionen zu definieren, verwenden adaptive Apps weit verbreitete Open-Source-Komponenten und offene Protokolle wie OIDC für die Authentifizierung und Message Queuing Telemetry Transport (MQTT) für Messaging. Dieser Ansatz verhindert, dass die Anwendung durch eine abstrakte Schnittstelle eingeschränkt wird und ermöglicht es, die vollständigen Funktionen der entsprechenden Protokolle direkt zu verwenden.

    Ressourcentyp Purpose
    Radius.Resources/agentGuardrails Agentspezifische Governancerichtlinien
    Radius.Resources/aiModels KI-Modelle, die KI-Rückschlüsse unterstützen
    Radius.Resources/governance Richtlinien für die Unternehmensführung
    Radius.Resources/mqttBrokers Nachrichtenbroker basierend auf MQTT
    Radius.Resources/workloadIdentities Workloadidentitäten, die zur Identifizierung einer Workload oder eines Agenten innerhalb einer Anwendung verwendet werden

  2. Der Entwickler kann Anwendungscode mithilfe einer portablen API erstellen oder aktualisieren.

    Auf der Ebene des Programmiermodells kann eine Anwendung zusätzlich Sidecar-Technologien wie Dapr einsetzen, das plattformagnostische APIs für gängige Aufgaben wie Pub/Sub, Zustandsverwaltung und die Verwaltung von Geheimnissen bereitstellt. Radius hat native Unterstützung für Dapr Sidecars.

    Brownfield-Dienste, die bereits Azure SDKs verwenden, können weiterhin in Zielen funktionieren, wenn die erforderlichen Azure Endpunkte, Identitätsflüsse und Netzwerkkonnektivität verfügbar sind. Dienste, die allgemeine Protokolle verwenden, können weiterhin funktionieren, wenn kompatible Implementierungen bereitgestellt werden. Für eine breitere Portabilität können neue Dienste Dapr-APIs einführen, um Anwendungen bei der Anpassung an mehr Plattformvariationen zu unterstützen.

  3. Ein Plattformoperator initialisiert für jedes Ziel ein Fähigkeitsportfolio.

    Der Betreiber wählt eines der sechs vordefinierten Portfolios aus: min, , core, ent, min-ai, core-ai, oder ent-ai, basierend auf den Anforderungen der Umgebung für Fußabdruck und Compliance. Der Betreiber installiert das Portfolio mithilfe eines Helm-Charts. Die folgende Tabelle zeigt, ob die vordefinierten Portfolios verschiedene Protokolle unterstützen.

    Portefeuille Identität (OIDC) Dienstgitter (Istio) Beobachtbarkeit (OTel) Steuerung (OPA) On-Cluster AI (Kaito) Agentenschutzschiene
    min ✓ ✗ ✗ ✗ ✗ ✗
    core ✓ ✓ ✓ ✗ ✗ ✗
    ent ✓ ✓ ✓ ✓ ✗ ✗
    min-ai ✓ ✗ ✗ ✗ ✓ ✗
    core-ai ✓ ✓ ✓ ✗ ✓ ✓
    ent-ai ✓ ✓ ✓ ✓ ✓ ✓

    Adaptive Apps bieten auch ein Befehlszeilentool, um Infrastrukturkonfigurationsschritte über die Helm-Installation hinaus zu erleichtern und Infrastrukturinformationen für die Anwendungsbereitstellung zur Verfügung zu stellen.

  4. Radius bindet die Anwendung an umgebungsspezifische Rezepte.

    Wenn rad deploy gegen den Ziel-Arbeitsbereich ausgeführt wird, stellt ein mit der Umgebung registriertes Rezept jede portierbare Ressource in der adaptiven App bereit. Beispielsweise wird bei der Bereitstellung der App in einer lokalen Kubernetes-Umgebung einem von Radius.Resources/aiModels verwalteten lokalen Small Language Model (SLM) zugeordnet. Die gleiche Ressource wird bei bereitstellung in einer Cloudumgebung in einen OpenAI- oder Azure OpenAI-Endpunkt aufgelöst. Radius fügt Verbindungsinformationen für Abhängigkeiten ein, die von der Anwendungsdefinition explizit deklariert werden.

    Diagramm, das eine adaptive App zeigt, die mithilfe des Radius-Anwendungsmodells in verschiedene Zielumgebungen über entsprechende Rezepte projiziert wird.

    Laden Sie eine Visio-Datei dieses Diagramms herunter.

Komponenten

  • Radius ist ein Open-Source-Anwendungsmodell, das einen Workload als Graph tragbarer Ressourcentypen beschreibt und jeden Typ bei der Bereitstellung in ein umgebungsspezifisches Rezept auflöst. In dieser Architektur ist Radius der primäre Vertrag zwischen Anwendungsteams und Plattformbetreibern. Adaptive Apps verwenden auch Radius-Tools, um Anwendungen in Zielumgebungen bereitzustellen.

  • Funktionsportfolios sind Verträge zwischen Anwendungen und ihren Hostingplattformen. Diese Architektur umfasst sechs vordefinierte Portfolios für Fähigkeitsstufen, die von einer grundlegenden Edge-Bereitstellung bis hin zu einer vollständigen Unternehmensbereitstellung mit Richtliniendurchsetzung und KI im Cluster reichen. Plattformbetreiber installieren Funktionsportfolios als Helm-Diagramme.

  • KI-basierte Tools bieten eine CLI für die Infrastrukturkonfiguration und KI-unterstützte Migration von Brownfield-Anwendungen. In dieser Architektur helfen die Tools beim Migrieren von Brownfield-Anwendungen, einschließlich Microservices-Anwendungen, älteren Anwendungen und Großrechneranwendungen, zum Radius-Anwendungsmodell.

Details zum Szenario

Ein Workloadteam muss möglicherweise dieselbe Anwendung in einer heterogenen Umgebung ausführen, die die folgenden Umgebungen umfassen kann:

  • Eine Public-Cloud-Region für elastische Workloads
  • Eine souveräne Region zur Erfüllung von Anforderungen an die Datenresidenz
  • Ein lokales Rechenzentrum für latenzsensitive Verarbeitung
  • Eine Flotte von Remote-Edgeclustern mit zeitweiliger Konnektivität

Jede Umgebung verfügt in der Regel über einen eigenen Identitätsanbieter, eine Dienstgitterüberlagerung, einen Observability-Stapel, ein Richtlinienmodul und eine KI-Strategie. Ohne einen einheitlichen Vertrag müssen Anwendungsteams entweder die Codebasis für jedes Ziel separat abspalten, sich an eine einzige Plattform binden oder jedes Mal Refaktorierungskosten in Kauf nehmen, wenn sie eine neue Umgebung hinzufügen.

Adaptive Apps beheben dieses Problem, indem sie die Plattform, nicht die Anwendung, verantwortlich für die Aufnahme von Umgebungsvariationen macht. Die Anwendung wird einmal für das Radius-Anwendungsmodell und optional das Dapr-Programmiermodell erstellt. Jede Zielumgebung installiert ein Funktionsportfolio, das die für die Anwendung erforderlichen Funktionen verfügbar macht. Eine Recipe-Layer verknüpft portable Ressourcen bei der Bereitstellung mit umgebungsspezifischen Implementierungen.

Die Architektur macht hinsichtlich der Kontrollebene bewusst keine Vorgaben. Anbieter von Funktionen können Portfolios über Helm, Arc-Erweiterungen, Bicep, Terraform oder benutzerdefinierte Installationsprogramme bereitstellen. Anwendungen bleiben portabel, solange die resultierende Umgebung dem Funktionsvertrag des Portfolios entspricht.

Potenzielle Anwendungsfälle

  • Souveräne und regulierte Cloudbereitstellungen

    Eine regulierte Workload muss in einer souveränen Cloud oder auf kundenseitig kontrollierter Infrastruktur ausgeführt werden und gleichzeitig dieselbe Codebasis wie die Version der öffentlichen Cloud nutzen. Das Portfolio core-ai oder ent-ai bietet über verschiedene Bereitstellungsziele hinweg eine einheitliche Zusicherung von Funktionen und ermöglicht die Portierbarkeit von Anwendungen. Die Zielumgebung erzwingt die spezifische Implementierung von Funktionen und Kontrollen, einschließlich Datenhaltung, Verschlüsselung, Zugriffssteuerung, Überwachung und Compliance-Zertifizierungen, um souveränitäts- und behördliche Anforderungen zu erfüllen.

  • Brownfield-Modernisierung ohne Replatforming

    Ein Workloadteam modernisiert eine ältere Microservices-Anwendung inkrementell, indem Radius-Ressourcendefinitionen eingeführt werden, um seine Infrastrukturabhängigkeiten zu beschreiben und dapr-Funktionen selektiv zu übernehmen. KI-gestützte Umgestaltungstools helfen dabei, Teile der Migration zu beschleunigen. Mit diesem Ansatz können Teams Anwendungen modernisieren, um die Portabilität, Observierbarkeit und operative Konsistenz in einem Tempo zu verbessern, das den geschäftlichen und technischen Anforderungen entspricht.

  • Hybride KI-Ableitung am Rand

    Eine Einzelhandels- oder Industrie-Workload führt denselben aiModel-Dienst auf Azure in der Zentrale unter Verwendung von Azure OpenAI und auf Azure Local-Clustern in Geschäften oder Werken unter Verwendung eines von Kaito gehosteten Open-Source-Modells aus. Der Anwendungscode ist identisch, und nur das aiModel Rezept unterscheidet sich.

  • Zeitweise verbundener Rahmen

    Eine Bereitstellung für Verteidigungs-, maritime oder abgelegene Standorte betreibt das min-ai-Portfolio auf einem einzelnen Cluster mit begrenzten Ressourcen, ohne von in der Cloud gehosteten Identitäts- oder KI-Diensten abhängig zu sein. Dieselbe Workload profitiert bei der erneuten Bereitstellung in AKS mit dem core-ai Portfolio automatisch von Service Mesh und Observability-Funktionen. Das ent-ai Portfolio umfasst auch die Durchsetzung von Governance-Richtlinien.

  • Multicloud-Bereitstellung

    Ein Workloadteam stellt modellierte Anwendungsressourcen mithilfe von rad deploy in einem anderen Arbeitsbereich bereit, sofern jedes Ziel denselben Capability-Vertrag implementiert. Sie behandeln Workload-Bursting und Notfallwiederherstellung als separate Bedenken. Eine nutzbare sekundäre Umgebung benötigt auch Kapazität, die Verfügbarkeit von Artefakten und Daten, Abhängigkeitssequenzierung, Identitäten, Netzwerkanbindung, Datenverkehrssteuerung, Zustandsprüfungen und getestete Failover-/Failback-Verfahren.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächster Schritt