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
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
- Die vorhandene lokale Webanwendung wird die vorhandenen lokalen Webdienste weiterhin direkt nutzen.
- Aufrufe von der vorhandenen Web-App an die vorhandenen HTTP-Dienste bleiben unverändert. Diese Aufrufe erfolgen intern im Unternehmensnetzwerk.
- Eingehende Aufrufe werden von Azure an die vorhandenen internen Dienste gesendet:
- Das Sicherheitsteam verwendet den sicheren Transport (HTTPS/SSL), um zuzulassen, dass Datenverkehr von der APIM-Instanz durch die Unternehmensfirewall zu den vorhandenen lokalen Diensten geleitet wird.
- Das operative Team lässt eingehende Aufrufe der Dienste nur von der APIM-Instanz zu. Innerhalb der Unternehmensnetzwerkumgebung wird die IP-Adresse der APIM-Instanz der Zulassungsliste hinzugefügt, um diese Anforderung zu erfüllen.
- In der Anforderungspipeline der lokalen HTTP-Dienste wird ein neues Modul konfiguriert (um nur externe Verbindungen zu verarbeiten), das ein von APIM bereitgestelltes Zertifikat überprüft.
- 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.
- 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:
- In einem Azure-Lift & Shift-Szenario, das direkt mit dem bereitgestellten virtuellen Azure-Netzwerk verknüpft ist, könnte der Kunde den Back-End-Dienst direkt über private IP-Adressen adressieren.
- Im lokalen Szenario könnte die API Management-Instanz eine private Verbindung über ein Azure-VPN-Gateway und eine Site-to-Site-IPSec-VPN-Verbindung oder ExpressRoute mit dem internen Dienst herstellen, wodurch ein Hybridszenario mit Azure und einer lokalen Umgebung entstehen würde.
- 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
- Azure API Management kann horizontal hochskaliert werden, indem Sie einen Tarif auswählen und anschließend Einheiten hinzufügen.
- Die Skalierung erfolgt auch durch automatische Skalierung.
- Die Bereitstellung in mehreren Regionen ermöglicht die Verwendung von Failoveroptionen und ist im Premium-Tarif verfügbar.
- Erwägen Sie die Integration in Azure Application Insights. Dadurch stehen Ihnen über Azure Monitor auch Metriken für die Überwachung zur Verfügung.
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:
- Ben Gimblett | Senior Customer Engineer
Nächste Schritte
Produktdokumention:
Learn-Module:
- Erkunden von Azure App Service
- Bereitstellen einer Website in Azure mit Azure App Service
- Schützen von APIs in Azure API Management