In diesem Artikel erfahren Sie, wie das CSE-Team (Commercial Software Engineering) von Microsoft zusammen mit einem globalen Vertriebspartner unter Verwendung von Serverless Framework eine serverlose Hochverfügbarkeitslösung sowohl für die Azure-Plattform als auch für die AWS-Cloudplattform (Amazon Web Services) bereitgestellt hat.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Datenfluss
- Die Benutzer-App kann aus einer beliebigen Quelle stammen, welche sich bei der Cloud anmelden kann. In dieser Implementierung meldet sich der Benutzer bei einer Gateway-App an, die einen 50/50-Lastenausgleich für Anforderungen für die Azure- und AWS-Clouds vornimmt.
- Auch jede Antwort wird über das API-Manager-Gateway weitergeleitet, das sie dann an die anfordernde App sendet.
Komponenten
Serverless Framework
Diese Lösung verwendet Serverless Framework von Serverless, Inc. Die kostenlose Version von Serverless Framework enthält eine Befehlszeilenschnittstelle, weitere Plug-Ins und eingeschränkte Überwachungsdienste. Die Pro-Edition verfügt über cloudübergreifende operative Funktionen, z. B. die erweiterte Überwachung und Warnungen. Das Framework unterstützt die Sprachen Node.js und Python sowie die Cloudhosts AWS und Azure.
Zum Verwenden von Azure mit dem Serverless Framework benötigen Sie Folgendes:
- Node.js, zum Packen von Microservices
- Azure Functions, zum Bereitstellen von Funktionen, die mit denen anderer Cloudplattformen vergleichbar sind
- Das Serverless Framework, um Bereitstellung und Überwachung in mehreren Clouds zu unterstützen
- Die Serverless Multicloud Library, in der normalisierte Laufzeit-APIs für Entwickler bereitgestellt sind
- Das Azure Functions Serverless-Plug-In, zum Unterstützen der Bereitstellung in mehreren Clouds. Dieses Plug-In war ursprünglich nicht gleichwertig mit dem vergleichbaren AWS Lambda-Plug-In und wurde für dieses Projekt erweitert.
Die Verarbeitungspipeline wird in der folgenden Abbildung veranschaulicht. Auf den Middleware-Ebenen sind alle Zwischenfunktionen dargestellt, die vor dem Erreichen des Handlers erforderlich sind.
Cloudunabhängige APIs
Die serverlose Implementierung auf jeder Plattform unterstützt einzelne Funktionen als Microservices, jeweils eine pro funktionalen VM-Knoten, und die Verarbeitung wird gemäß dem jeweiligen Bedarf ausgeführt. Für jede AWS Lambda-Funktion ist eine entsprechende Azure Functions-Funktion vorhanden. Die Serverless Multicloud Library erstellt analoge Microservices aus beiden Clouds in einer cloudunabhängigen normalisierten REST-API, die Client-Apps als Schnittstelle für die jeweils andere Plattform nutzen können. Da von der abstrahierten API-Schicht Code zum Verarbeiten der entsprechenden Microservices für jede Plattform bereitgestellt wird, ist für Transaktionen keine Übersetzung erforderlich. Über die cloudunabhängige Schnittstelle können Benutzer-Apps mit der Cloud kommunizieren, ohne dass bekannt sein muss, auf welche Cloudplattform jeweils zugegriffen wird.
Dieses Konzept wird im folgenden Diagramm veranschaulicht:
CI/CD mit GitOps
Das primäre Ziel des Serverless Framework besteht darin, sämtliche Infrastrukturaspekte der Bereitstellung einer App in der Cloud so weit zu abstrahieren, dass sie keine Rolle spielen. Dank eines manifestbasierten Ansatzes kann Serverless Framework sämtliche Bereitstellungsprobleme behandeln, wodurch die Bereitstellung ggf. automatisiert werden kann, um GitOps zu unterstützen.
Obwohl in diesem anfänglichen Projekt manuelle Bereitstellungen verwendet wurden, ist es durchaus realistisch, manifestgesteuerte serverlose Builds, Tests und Bereitstellungen innerhalb von Clouds und über die Grenzen von Clouds hinweg zu implementieren. Bei diesem Prozess kann ein GitOps-Entwickler-Workflow genutzt werden: Erstellen in Git, Verwenden von Qualitätszielen für Tests und Bewertungen und Übertragen von serverlosen Lösungen auf beide Cloudanbieter mithilfe von Push. Das Durchführen sämtlicher Bereitstellungen mit dem Serverless Framework vom Anfang des Projekts an ist die effizienteste Vorgehensweise.
API-Manager
Beim API-Manager kann es sich um eine vorhandene oder eine benutzerdefinierte Anwendung handeln. Der Apigee™-API-Manager in dieser Implementierung fungierte lediglich als Router, der einen 50/50-Lastenausgleich für Transaktionen für die beiden Cloudplattformen ausführt, und seine Fähigkeiten wurden nicht voll ausgeschöpft.
Der API-Manager muss zu Folgendem in der Lage sein:
- Bereitstellung entsprechend den jeweiligen Anforderungen innerhalb oder außerhalb einer Cloudplattform
- Weiterleiten von Nachrichten an und von beiden Cloudplattformen
- Protokollieren von Datenverkehrsanforderungen, um den Datenverkehr asynchroner Meldungen zu koordinieren
- Weiterleiten von Anforderungen und Antworten mit der gemeinsamen REST-API von und zur Benutzeranwendung
- Überwachen der Integrität der beiden Serverless Framework-Cloudbereitstellungen, um ihre Fähigkeit zum Empfangen von Anforderungen zu validieren
- Durchführen automatisierter Integritäts- und Verfügbarkeitsprüfungen für die Cloudplattformen, um Routing und Hochverfügbarkeit zu unterstützen
Alternativen
Die Lösung kann mit anderen Sprachen (z. B. Python) implementiert werden, sofern sie von den serverlosen Implementierungen der Cloudplattformen unterstützt werden, in diesem Fall von AWS Lambda und Azure Functions. In diesem Projekt wurde Node.js zum Packen der Microservices verwendet, da der Kunde Node.js bevorzugt und die Sprache sowohl von der AWS- als auch von der Azure-Plattform unterstützt wird.
Die Lösung kann sich auf eine beliebige Cloudplattform stützen, die das Serverless Framework unterstützt, nicht nur auf Azure und AWS. Derzeit ist das Serverless Framework mit acht verschiedenen Cloudanbietern kompatibel. Der einzige Nachteil besteht darin, dass sichergestellt werden muss, dass die Elemente, welche die Multicloud-Architektur oder deren Entsprechung unterstützen, auf den Ziel-Cloudplattformen verfügbar sind.
Der API-Manager in dieser Implementierung fungierte lediglich als Router, der einen 50/50-Lastenausgleich für Transaktionen für die beiden Cloudplattformen ausführt. Für spezielle Szenarien kann der API-Manager auch eine andere Geschäftslogik beinhalten.
Szenariodetails
Beim serverlosen Computing weist der Cloudanbieter ausgeführtem Code dynamisch Microservice-Ressourcen zu, und nur genutzte Ressourcen werden in Rechnung gestellt. Das serverlose Computing abstrahiert App-Code von der Infrastrukturimplementierung, Codebereitstellung und operativen Aspekten wie Planung und Wartung.
Wie bei anderen Diensten verfügt jeder Cloudanbieter über eine eigene serverlose Implementierung, und für Kunden ist es schwierig, ohne erhebliche operative Auswirkungen und hohe Kosten einen anderen Anbieter zu verwenden. Potenzielle Kunden erachten diese Situation möglicherweise als nachteilig für ihre Verhandlungsposition und Agilität. Die Anbieterabhängigkeit ist eines der größten Hemmnisse für die Enterprise-Einführung.
Das Open-Source-Serverless Framework ist eine universelle Cloudschnittstelle zum Entwickeln und Bereitstellen von serverlosen Computinglösungen für verschiedene Cloudanbieter. Die Open-Source-Zugänglichkeit und gängige APIs für serverlose Funktionen unterstützen Anbieter, Kunden und Partner beim Erstellen cloudübergreifender Lösungen für modernste Dienste. Serverless Framework räumt Hindernisse bei der Cloudeinführung aus, da Probleme im Zusammenhang mit der Anbieterabhängigkeit und cloudübergreifender Anbieterredundanz behoben werden. Kunden können Ihre Lösungen hinsichtlich der Kosten, der Agilität und anderer Aspekte optimieren.
CSE und das Azure-Produktteam haben die Serverless-CLI gemeinsam neu geschrieben, sodass nun neue Azure Functions-Features wie Premium Functions, API Management und KeyVault unterstützt werden. Die Serverless-CLI stellt nun eine Standardschnittstelle für die GitOps-Bereitstellung in Azure und AWS bereit. Das Team hat außerdem die Serverless Multicloud Library entwickelt, die eine normalisierte Laufzeit-API zum Bereitstellen von serverlosen Apps in AWS und Azure zugänglich macht.
Dieses Design bietet Hochverfügbarkeit durch Aktiv-Aktiv-Failover zwischen mehreren Cloudplattformen (im Gegensatz zu Aktiv-Passiv-Failover). Sollte der Dienst eines Cloudanbieters fehlerhaft oder nicht mehr verfügbar sein, können von dieser Lösung Anforderungen an eine andere Cloudplattform umgeleitet werde.
Mit diesem Projekt wurden die folgenden technischen Ziele umgesetzt:
- Es wurde eine branchenübergreifende Lösung erstellt.
- Durch Nutzung der Multicloud Serverless Library wird eine cloudunabhängige API unterstützt, die eine Schnittstelle mit Microservices herstellt, unabhängig davon, wo diese bereitgestellt sind.
- Es wird ein Workflow für GitOps-CI/CD-Prozesse für Entwicklung, Tests und Bereitstellung auf allen unterstützten Cloudplattformen unterstützt.
- Der API-basierte Zugriff erfolgt über ein authentifiziertes Cloudgateway, und beim Lastenausgleich zwischen Cloudplattformen wird dieses Gateway als Router verwendet.
Weitere potenzielle Vorteile der Verwendung des Serverless Framework:
- Verhinderung oder Minderung der Anbieterabhängigkeit
- Verwenden der Multicloud Serverless Library reduziert die Codemenge während der Entwicklungsarbeiten um 40 bis 60 %
- Entwicklung branchenführender Lösungen, in denen die Dienste verschiedener Cloudanbieter kombiniert sind
- Eliminierung der meisten Anforderungen hinsichtlich Plattform- und Infrastrukturkomplexität und Wartungsbedarf
- Gemeinsames Nutzen von Daten, Leistungs- und Kostenvergleiche sowie Profitieren von Sonderangeboten wurden erleichtert
- Aktiv/Aktiv-Hochverfügbarkeit
Mögliche Anwendungsfälle
- Sie können clientseitige Anwendungen für mehrere Plattformen mithilfe einer cloudunabhängigen API aus der Serverless Multicloud Library schreiben.
- Sie können eine Sammlung von funktionalen Microservices in einem serverlosen Framework in mehreren Cloudplattformen bereitstellen.
- Sie können eine cloudunabhängige App auf verschiedenen Cloudplattformen verwenden, ohne dass Sie sich über ihren jeweiligen Host Gedanken machen müssen.
Überlegungen
In diesem Artikel werden keine Sicherheitslösungen beschrieben, obwohl sie in der ursprünglichen Bereitstellung enthalten sind. Es gibt eine Vielzahl möglicher Sicherheitslösungen, von denen einige plattformabhängig sind. Dieses Framework sollte jedoch eine sinnvolle Lösung unterstützen. Als Mindestanforderung wird die Benutzerauthentifizierung angenommen.
Da die Unterschiede zwischen den funktionalen serverlosen Angeboten von AWS und Azure nur schwer erläutert werden können, sollte der erste Schwerpunkt darin bestehen, die auf den Cloudplattformen verfügbaren Funktionen zuzuordnen und die Anforderungen nötiger Transformationen zu ermitteln. Anhand dieser Informationen können Sie eine plattformunabhängige API entwickeln.
Der Rückgriff auf eine Open-Source-Lösung kann Risiken mit sich bringen, wegen der Probleme in Bezug auf langfristige Wartung und Unterstützung, die für jede Open-Source-Software gelten.
Im kostenlosen Serverless Framework beschränkt sich die Überwachung hauptsächlich auf das Administrator-Dashboard. Die Überwachung ist im kostenpflichtigen Enterprise-Angebot verfügbar. Derzeit bietet das Azure Functions Serverless-Plug-In keinerlei Regelungen in Bezug auf Beobachtung und Überwachung, und für die Implementierung dieser Funktionen bedarf es einiger Änderungen.
In dieser Lösung könnten Leistung und Kosten der Cloudplattformen mithilfe von Metriken verglichen werden, sodass Kunden die Nutzung über Cloudplattformen hinweg nahtlos optimieren können.
Bereitstellen dieses Szenarios
Bei einer herkömmlichen Blau-Grün-Bereitstellung wird eine App in zwei separaten, jedoch identischen Umgebungen (blau und grün) entwickelt und bereitgestellt, wodurch die Verfügbarkeit gesteigert und Risiken gemindert werden. Die blaue Umgebung ist in der Regel die Produktionsumgebung, die normalerweise Livedatenverkehr verarbeitet, während die grüne Umgebung als Failoverbereitstellung für den Bedarfsfall fungiert. Im Allgemeinen stellt die CI/CD-Pipeline sowohl die blaue als auch die grüne Umgebung automatisch innerhalb derselben Cloudplattform bereit. Diese Konfiguration wird als Aktiv/Passiv-Konfiguration angesehen.
In der Multicloud-Lösung wird die Blau-Grün-Bereitstellung in beiden Cloudplattformen implementiert. Im serverlosen Szenario werden zwei duplizierte Sets von Microservices für jede Cloudplattform bereitgestellt, eines als Produktionsumgebung und das andere als Failoverumgebung. Diese Aktiv/Passiv-Konfiguration innerhalb jeder Cloudplattform mindert das Ausfallrisiko der betreffenden Plattform. Dies bewirkt eine höhere Verfügbarkeit sowie die Aktiv/Aktiv-Multicloud-Hochverfügbarkeit.
Ein weiterer Vorteil der Blau-Grün-Bereitstellung besteht darin, dass die Failoverbereitstellung auf jeder Cloudplattform als Testumgebung für die Updates von Microservices verwendet werden kann, bevor deren Übernahme in die Produktionsumgebung erfolgt.