Migrieren einer Web-App per Azure API Management

API Management
Application Insights
Monitor
Web Apps

Ein E-Commerce-Unternehmen in der Reisebranche modernisiert seinen bestehenden browserbasierten Softwarestapel. Der vorhandene Stapel ist größtenteils monolithisch, das Unternehmen hat jedoch einige SOAP-basierte HTTP-Dienste, die aus einem aktuellen Projekt stammen. 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 wird das Anwendungs-Back-End modernisieren, das aus auf VMs gehosteten relationalen Datenbanken besteht.
  • 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 werden 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.

Das Managementteam möchte 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. Mit Azure API Management (APIM) können viele der Anforderungen und Auflagen des Projekts 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.

Architektur

Architecture diagram

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.

Workflow

  1. Die vorhandene lokale Webanwendung wird die vorhandenen lokalen Webdienste weiterhin direkt nutzen.
  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:
    • Die neue API wird nur über die APIM-Instanz verfügbar gemacht, die die API-Fassade bereitstellt. Auf die neue API wird nicht direkt zugegriffen.
    • Die neue API wird als eine Azure-PaaS-Web-API-App entwickelt und veröffentlicht.
    • Die neue API wird so konfiguriert (über Web-App-Einstellungen), dass nur die virtuelle IP-Adresse (VIP) der APIM-Instanz akzeptiert wird.
    • Die neue API wird mit aktiviertem sicheren Transport/SSL-Protokoll in Azure-Web-Apps gehostet.
    • Für die neue API ist die Autorisierung aktiviert. Diese wird von Azure App Service mithilfe von Azure Active Directory und OAuth 2 bereitgestellt.
  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 APIM-Instanz wird so konfiguriert, dass sie die älteren HTTP-Dienste einem neuen API-Vertrag zuordnet. Der neuen Webbenutzeroberfläche ist 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. Diese Änderungen werden in der APIM-Konfiguration vorgenommen, 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 VMs, die ältere Anwendungen hosten) zu Azure planen würde, wäre APIM dennoch eine gute Option, da der Dienst als Fassade für alle adressierbaren HTTP-Endpunkte fungieren kann.
  • Wenn sich der Kunde dafür entschieden hätte, die vorhandenen Endpunkte privat zu halten und nicht öffentlich verfügbar zu machen, könnte die API Management-Instanz mit einem virtuellen Azure-Netzwerk (VNET) verknüpft werden:
  • Die API Management-Instanz kann privat gehalten werden, indem sie im internen Modus bereitgestellt wird. Die Bereitstellung könnte dann mit einer Azure Application Gateway-Instanz verwendet werden, um den öffentlichen Zugriff für einige APIs zu ermöglichen, während andere APIs weiterhin nur intern zugänglich sind. Weitere Informationen finden Sie unter Verbinden von API Management mit einem VNet im internen Modus.

Hinweis

Allgemeine Informationen zum Verbinden von API Management mit einem VNET finden Sie hier.

Überlegungen

Verfügbarkeit und Skalierbarkeit

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.

Preise

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.

Kunden können API Management skalieren, indem sie Einheiten hinzufügen und entfernen. Die Kapazität jeder Einheit ist vom Tarif abhängig.

Hinweis

Der Developer-Tarif kann zur Evaluierung der API Management-Funktionen verwendet werden. Der Developer-Tarif sollte nicht für die Produktion verwendet werden.

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.

Beitragende

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

Hauptautor:

Nächste Schritte

Produktdokumention:

Learn-Module: