Bearbeiten

Migrieren einer Web-App mithilfe von Azure API Management

Azure API Management
Azure Monitor
Azure App Service

In diesem Szenario migriert ein E-Commerce-Unternehmen in der Reisebranche eine Legacy-Webanwendung mithilfe von Azure API Management. Die neue Benutzeroberfläche wird als PaaS-Anwendung (Platform as a Service) in Azure gehostet und ist sowohl von vorhandenen als auch neuen HTTP-APIs abhängig. Diese APIs werden einen besseren Satz von Schnittstellen enthalten, die die Leistung verbessern, die Integration vereinfachen und zukünftige Erweiterbarkeit unterstützen.

Architektur

Architekturdiagramm

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

  1. Die vorhandene lokale Webanwendung nutzt die vorhandenen lokalen Webdienste weiterhin direkt.
  2. Aufrufe von der vorhandenen Web-App an die vorhandenen HTTP-Dienste bleiben unverändert. Diese Aufrufe erfolgen intern im Unternehmensnetzwerk.
  3. Eingehende Aufrufe werden von Azure an die vorhandenen internen Dienste gesendet:
  4. Für die neue API gilt Folgendes:
  5. Die neue browserbasierte Webanwendung ist für die vorhandene HTTP-API und die neue API von der Azure API Management-Instanz abhängig.

Die API Management-Instanz ist so konfiguriert, dass sie die älteren HTTP-Dienste einem neuen API-Vertrag zuordnet. In dieser Konfiguration ist der neuen Webbenutzeroberfläche die Integration einer Gruppe von älteren Diensten/APIs und neuen APIs daher nicht bekannt.

Das Projektteam wird in der Zukunft schrittweise Funktionen zu den neuen APIs portieren und die ursprünglichen Dienste außer Betrieb setzen. Das Team nimmt diese Änderungen in der API Management-Konfiguration vor, sodass die Front-End-Benutzeroberfläche davon nicht betroffen ist und Neuentwicklungen vermieden werden.

Komponenten

Alternativen

  • Wenn die Organisation eine Migration ihrer vollständigen Infrastruktur – einschließlich der virtuellen Computer (VMs), die Legacy-Anwendungen hosten – zu Azure plant, ist API Management dennoch eine gute Option, da der Dienst als Fassade für alle adressierbaren HTTP-Endpunkte fungieren kann.

  • Wenn sich die Organisation dafür entschieden hat, die vorhandenen Endpunkte privat zu halten und nicht öffentlich verfügbar zu machen, kann die API Management-Instanz mit einem virtuellen Azure-Netzwerk verknüpft werden:

  • Die Organisation kann die API Management-Instanz privat halten, indem sie sie im internen Modus bereitstellt. Die Organisation kann dann eine Bereitstellung mit Azure Application Gateway verwenden, um den öffentlichen Zugriff für einige APIs zu ermöglichen, während andere APIs weiterhin nur intern zugänglich sind. Weitere Informationen findest Du unter Integrieren von API Management in ein internes virtuelles Netzwerk mit Application Gateway.

  • Die Organisation entscheidet sich möglicherweise, ihre APIs lokal zu hosten. Ein Grund für diese Änderung kann sein, dass die Organisation Downstream-Datenbankabhängigkeiten, die im Bereich dieses Projekts liegen, sonst nicht in die Cloud verschieben kann. Wenn dies der Fall ist, kann die Organisation API Management weiterhin lokal nutzen, indem sie ein selbstgehostetes Gateway verwendet.

    Das selbstgehostete Gateway ist eine Containerbereitstellung des API Management Gateways, das eine Verbindung mit Azure über einen ausgehenden Socket herstellt. Die erste Voraussetzung ist, dass selbstgehostete Gateways nicht ohne eine übergeordnete Ressource in Azure bereitgestellt werden können, was mit einer zusätzlichen Gebühr verbunden ist. Zweitens ist der Premium-Tarif von API Management erforderlich.

Hinweis

Allgemeine Informationen zum Verbinden von API Management mit einem virtuellen Netzwerk finden Sie in diesem Artikel.

Szenariodetails

Ein E-Commerce-Unternehmen in der Reisebranche modernisiert seinen browserbasierten Legacy-Softwarebestand. Zwar ist der vorhandene Bestand größtenteils monolithisch, jedoch sind einige SOAP-basierte HTTP-Dienste aus einem aktuellen Projekt vorhanden. Das Unternehmen erwägt, zusätzliche Einnahmequellen zu erschließen, um Teile des von ihm entwickelten internen geistigen Eigentums gewinnbringend zu nutzen.

Zu den Zielen für das Projekt zählen der Abbau technischer Schulden, die Verbesserung der laufenden Wartung und die Beschleunigung der Featureentwicklung mit weniger Regressionsfehlern. Bei dem Projekt wird zur Vermeidung von Risiken ein iterativer Prozess eingesetzt, und einige Schritte werden parallel ausgeführt:

  • Das Entwicklungsteam soll das Back-End der Anwendung modernisieren, das aus relationalen Datenbanken besteht, die auf VMs gehostet werden.
  • Das interne Entwicklungsteam wird neue Geschäftsfunktionen entwickeln, die über neue HTTP-APIs verfügbar gemacht werden.
  • Ein externes Entwicklungsteam wird eine neue browserbasierte Benutzeroberfläche erstellen, die in Azure gehostet wird.

Neue Anwendungsfeatures werden in mehreren Phasen bereitgestellt. Diese Features sollen die vorhandene (lokal gehostete) browserbasierte Client/Server-Benutzeroberfläche, die gegenwärtig für das E-Commerce-Geschäft des Unternehmens genutzt wird, schrittweise ersetzen.

Mitglieder des Managementteams möchten unnötige Modernisierungen vermeiden. Außerdem möchte es die Kontrolle über den Umfang und die Kosten des Projekts behalten. Aus diesem Grund hat sich das Unternehmen entschieden, die vorhandenen SOAP-HTTP-Dienste beizubehalten. Zudem sollen Änderungen an der vorhandenen Benutzeroberfläche auf ein Minimum beschränkt werden. Viele der Anforderungen und Auflagen des Projekts können mit Azure API Management erfüllt werden.

Mögliche Anwendungsfälle

In diesem Szenario werden veraltete browserbasierte Softwarestapel modernisiert.

Sie können dieses Szenario für Folgendes verwenden:

  • Erfahren Sie, wie Ihr Unternehmen von der Nutzung des Azure-Ökosystems profitieren kann.
  • Planen der Migration von Diensten zu Azure.
  • Erfahren Sie, wie sich eine Umstellung auf Azure auf vorhandene APIs auswirkt.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die zur Steigerung der Qualität eines Workloads verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Verfügbarkeit und Skalierbarkeit

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

API Management ist in vier Tarifen erhältlich: Developer, Basic, Standard und Premium. Ausführliche Informationen zu den Unterschieden zwischen den einzelnen Tarifen finden Sie in der API Management-Preisübersicht.

API Management lässt sich durch Hinzufügen und Entfernen von Einheiten skalieren. Die Kapazität jeder Einheit ist vom Tarif abhängig.

Hinweis

Sie können den Developer-Tarif zur Evaluierung der API Management-Features verwenden. Verwenden Sie ihn nicht für die Produktion.

Im Azure-Preisrechner können Sie die voraussichtlichen Kosten für Ihre speziellen Bereitstellungsanforderungen ermitteln, indem Sie die Anzahl von Skalierungseinheiten und App Service-Instanzen ändern.

Bereitstellen dieses Szenarios

Der erste Schritt ist das Erstellen einer Azure API Management-Instanz im Portal.

Alternativ können Sie eine der vorhandenen Azure Resource Manager-Schnellstartvorlagen auswählen, die für Ihren spezifischen Anwendungsfall geeignet ist.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Produktdokumentation:

Learn-Module: