Hybrid- und Multi-Cloud-API-Management: Herausforderungen und Entscheidungen

1. Multi-Cloud & Hybrid Cloud

Microservices sind zu einer beliebten Softwarearchitekturmethode geworden, bei der Organisationen ihre Produkte basierend auf ihrem Verständnis des eigenen Geschäfts und unter Verwendung wissenschaftlicher Methoden wie Domain-Driven Design in einzelne Microservices aufteilen. Die Organisationsstruktur wird ebenfalls an die Microservice-Architektur angepasst, gemäß dem Conway'schen Gesetz, um die iterative Entwicklung des Geschäfts zu unterstützen.

In der Vergangenheit bauten Organisationen ihre eigenen Rechenzentren, um ihre Produkte zu deployen. Diese Rechenzentren konnten sich in gemieteten oder gekauften Einrichtungen befinden, und die Organisationen waren für die Verwaltung der komplexen Infrastruktur wie Switches, Server, Speicher, Racks und andere Hardware verantwortlich. Sie mussten sich auch mit Problemen wie Stromausfällen, hohen Rack-Temperaturen, Serverabstürzen usw. auseinandersetzen. Die Bewältigung solcher Probleme erforderte oft viel Personal und finanzielle Ressourcen, ohne gute Ergebnisse zu erzielen. Infolgedessen konnte das SLA (Service Level Agreement) der eigenen Produkte der Organisationen oft nicht die Versprechen an die Kunden erfüllen, was zu Entschädigungen führte.

Mit dem Aufstieg der Cloud haben sich die Menschen zunehmend daran gewöhnt, ihre Geschäfte auf Public Clouds zu deployen. Public Clouds helfen den Nutzern, die Details der Hardware-Infrastruktur zu abstrahieren, sodass sich die Ingenieure auf das Deployen, Warten und Entwickeln ihres Geschäfts konzentrieren können. Neben dem Komfort, den die Cloud bietet, bringt ihr Aufstieg und ihre Nutzung jedoch auch andere Probleme für die Nutzer mit sich:

• Lock-in: Wenn ein Produkt eines Cloud-Anbieters tief in ein Geschäft integriert ist, wird es sehr schwierig, das Geschäft auf eine andere Cloud zu verlagern oder die Cloud ganz zu verlassen. Dies ist besonders häufig bei PaaS- oder SaaS-Produkten der Fall, die eine starke Bindung an das Geschäft haben. Leider passiert dies oft, wenn ein Geschäft in einer Phase des schnellen Wachstums ist und die Entscheidungsträger die Bindungswirkung der Nutzung von Cloud-Produkten übersehen.
• Verfügbarkeitsprobleme: Das Prinzip der Diversifizierung gilt hier, was bedeutet, dass wir nicht alle Eier in einen Korb legen. Während der Skalierungsphase eines Geschäfts priorisieren Organisationen oft das schnelle Starten von Produkten und die Eroberung von Marktanteilen, wobei sie die Infrastruktur vernachlässigen. Dies kann zu Stromausfällen oder Kabelbrüchen in einer Cloud-Region führen, was sich negativ auf das Geschäft auswirkt.

Infolgedessen gewöhnen sich die Menschen immer mehr daran, mehrere Public Clouds zu nutzen oder zusätzlich zu Public Clouds private Clouds zu bauen, um die oben genannten Probleme zu vermeiden. Dieser Ansatz wird allgemein als "Multi-Cloud" und "Hybrid Cloud" bezeichnet.

"Multi-Cloud" bezieht sich auf die gleichzeitige Nutzung mehrerer Public Clouds, wobei das Geschäft spiegelbildlich oder heterogen auf diesen Clouds deployt wird. Es werden so weit wie möglich Standarddienste verwendet (um Vendor Lock-in zu vermeiden). Durch die Nutzung von Multi-Cloud kann der Einfluss auf das Geschäft minimiert werden, wenn eine Cloud nicht verfügbar ist, und die Geschäftskontinuität durch Änderung der DNS-Auflösung und Aktivierung einer Backup-Cloud sichergestellt werden.

"Hybrid Cloud" bezieht sich auf Organisationen, die zusätzlich zur Nutzung einer oder mehrerer Public Clouds auch eigene private Clouds (oder Rechenzentren) haben. In diesem Szenario könnten einige Dienste auf privaten Clouds deployt werden, während andere auf Public Clouds deployt werden. Oder alle Dienste werden in der Cloud deployt, und die private Cloud ist für die Verwaltung und Überwachung verantwortlich. In jedem Fall werden die Flexibilität und Verfügbarkeit der Softwarebereitstellung nach der Einführung des "Multi-Cloud"- oder "Hybrid Cloud"-Modells erheblich verbessert.

Die Implementierung von "Multi-Cloud"- und "Hybrid Cloud"-Strategien kann jedoch die Verwaltung von cloudbasierten Microservices komplexer machen. Eine häufige Herausforderung ist das API-Management, da viele Microservices auf APIs zur Kommunikation angewiesen sind. Daher müssen beim Deployen von Microservices deren APIs extern verfügbar gemacht werden, um Verbindungen mit externen Parteien zu ermöglichen und Dienste bereitzustellen.

2. Die Notwendigkeit des API-Managements in Multi-Cloud- und Hybrid-Cloud-Szenarien

Wie wir wissen, ist ein guter API-Gateway entscheidend für die Verwaltung von Microservices-APIs. Der API-Gateway ermöglicht die sichere und effiziente Bereitstellung von Microservices-APIs. Bei der Implementierung von "Multi-Cloud"- und "Hybrid Cloud"-Strategien geht der Bedarf an einem API-Gateway jedoch über seine grundlegende Funktionalität hinaus. Insbesondere sind Überlegungen wie:

Unterstützung von Multi-Cluster-Management

Wie bereits erwähnt, können die in jeder Cloud oder in privaten Rechenzentren deployten Dienste bei der Implementierung von "Multi-Cloud"- oder "Hybrid Cloud"-Strategien erheblich variieren. Daher müssen Benutzer möglicherweise separate API-Gateway-Cluster in jeder Cloud mit unterschiedlichen Konfigurationen, Zertifikaten und API-Schlüsseln deployen. Wenn das gewählte Gateway kein Multi-Cluster-Management unterstützt, kann dies erhebliche Schwierigkeiten bei der Verwaltung von APIs verursachen, insbesondere in Phasen der Geschäftserweiterung, wenn die Anzahl und der Umfang der Gateway-Cluster zunehmen.

In solchen Fällen kann ein API-Gateway-Produkt, das Multi-Cluster-Management unterstützt, die Verwaltungskosten für Administratoren erheblich reduzieren.

1. Benutzer haben Zugriff auf eine einheitliche Konsole, um den Cluster auszuwählen, den sie konfigurieren und überwachen möchten. Sie können auch einen Gateway-Cluster online oder offline schalten, abhängig von der aktuellen Geschäftsbereitstellungssituation.
2. Benutzer können den Betriebsstatus aller dieser API-Gateway-Cluster auf der Konsole einsehen, einschließlich gängiger QPS, Latenz, CPU- und Speichernutzung des Gateway-Clusters usw.

Unterstützung von Zusammenarbeit

Mit der raschen Entwicklung des Geschäfts kann eine kleine Anzahl von API-Gateway-Administratoren Schwierigkeiten haben, alle API-Gateway-Cluster allein zu verwalten und zu warten. Gleichzeitig können viele Gateway-Konfigurationen, wie das Hinzufügen von Routen und das Konfigurieren von Plugins, von Entwicklern durchgeführt werden, wodurch der Bedarf an umfangreicher Administratorbeteiligung reduziert wird. Daher wird die Unterstützung von "Zusammenarbeit" für das Management entscheidend.

Insbesondere können Administratoren andere Mitglieder der Organisation einladen, sich der Verwaltung des API-Gateway-Clusters anzuschließen, indem sie RBAC (Role-based Access Control) oder andere Strategien verwenden, um Teammitgliedern unterschiedliche Berechtigungen zuzuweisen. Zum Beispiel kann die Rolle des Organization Admin (kann jede Operation durchführen) für den Administrator und Service Admin (kann nur einige Dienste und Routen verwalten) für den allgemeinen Entwickler festgelegt werden. Dieser Ansatz gewährleistet die Sicherheit der Operationen bei gleichzeitiger Implementierung der Zusammenarbeit. Er erleichtert auch die rechtzeitige Wiederherstellung von Konten oder die Änderung von Berechtigungen im Falle von Mitarbeiterfluktuation oder Änderungen der Arbeitspositionen.

Fähigkeit, auf jeder Infrastruktur zu laufen

Da Containerisierung und Container-Orchestrierungstechnologien reifen, wechseln viele Microservices von virtuellen Maschinen zu Kubernetes. Dies bedeutet, dass Benutzer Kubernetes, traditionelle virtuelle Maschinen oder sogar physische Maschinen, wie in ihren privaten Rechenzentren, verwenden können. Wenn das vom Benutzer gewählte API-Gateway-Produkt funktionsreich ist und die Geschäftsanforderungen erfüllt, aber durch die zugrunde liegende Infrastruktur eingeschränkt ist oder keine ausgereiften Installationswerkzeuge bietet, kann dies eine Herausforderung für den Benutzer darstellen, entweder auf die Nutzung zu verzichten oder zusätzliche Entwicklungen durchzuführen, um das API-Gateway auf bestimmten Infrastrukturen laufen zu lassen. In jedem Fall führt dies zu zusätzlichen Nutzungskosten.

3. Entscheidungen

Wie besprochen, wird die Wahl des richtigen API-Gateways im Kontext von "Multi-Cloud"- und "Hybrid Cloud"-Szenarien äußerst wichtig. Einige gängige Optionen sind aufgeführt, und Benutzer sollten sie basierend auf ihren tatsächlichen Szenarien und zukünftigen Plänen analysieren.

Unterschiedliche Lösungen auf verschiedenen Clouds

Typischerweise bietet jeder Public-Cloud-Anbieter seine eigene integrierte API-Gateway-Lösung an, und Benutzer können den Kauf einer API-Gateway-Lösung für jede Cloud in Betracht ziehen.

Vorteile sind:

1. Extrem niedrige Nutzungskosten, ohne Notwendigkeit für Bereitstellung oder Wartung.
2. Unterstützt in der Regel Pay-as-you-go; die frühe Nutzung erfordert möglicherweise nur minimale Kosten.

Nachteile sind:

1. Die Nutzung von API-Gateways auf verschiedenen Clouds ist oft nicht miteinander kompatibel, sodass die gleiche Konfiguration unterschiedliche Wege erfordert.
2. Produktfunktionen sind unter verschiedenen Anbietern nicht symmetrisch. Zum Beispiel unterstützt ein Anbieter möglicherweise mTLS, während ein anderer dies nicht tut.
3. Im "Hybrid Cloud"-Szenario kann es notwendig sein, ein anderes Open-Source- oder kommerzielles API-Gateway zu wählen und es auf der privaten Cloud des Benutzers zu deployen.

Bei der Verwendung dieses Ansatzes kann die Erzielung einer konsistenten Benutzererfahrung über verschiedene Cloud-Anbieter hinweg Produktanpassungen, die Entwicklung eines Konfigurationssynchronisierungstools und die Abstraktion der zugrunde liegenden Details erfordern. Dies kann zusätzliche Recherchen, Analysen und Entwicklungen seitens des Benutzers erfordern. Benutzer können auf Kompatibilitätsprobleme und eingeschränkte Funktionalität stoßen und könnten nur wenige gängige Funktionen von API-Gateway-Produkten nutzen. Zusätzlich muss auch die Möglichkeit eines Synchronisationsfehlers berücksichtigt werden.

Natürlich können Benutzer auch manuell die Konfiguration jedes API-Gateways auf jeder Cloud wiederholen (wenn sie es tolerieren können).

Open-Source-API-Gateway-Lösung

Als Alternative zur Verwendung unterschiedlicher Lösungen auf verschiedenen Clouds können Benutzer die Nutzung von Open-Source-API-Gateway-Lösungen wie Apache APISIX, Kong, Tyk, Traefik usw. in Betracht ziehen. Dieser Ansatz ermöglicht es Benutzern, dasselbe API-Gateway über alle Clouds hinweg zu verwenden, einschließlich privater Rechenzentren, und vermeidet so Kompatibilitätsprobleme zwischen verschiedenen Lösungen. Ein ausgereiftes und robustes Open-Source-API-Gateway kann Benutzern helfen, viele Probleme in verschiedenen Szenarien zu lösen. Selbst wenn es nicht alle Szenarien abdeckt, ermöglichen diese API-Gateways den Benutzern in der Regel, sie auf verschiedene Weise zu erweitern. Zum Beispiel erlaubt Apache APISIX Benutzern, es mit Sprachen und Technologien wie Go, Java, Python, Lua, WASM usw. zu erweitern.

Diese Open-Source-API-Gateways verfolgen jedoch in der Regel eine Open Core-Open-Source-Strategie, bei der die Kernfunktionen des Produkts Open Source sind, aber unternehmensrelevante Managementfähigkeiten wie eine visualisierte Konsole, Multi-Cluster-Management, Auditing, SSO (Single Sign-On) usw. oft kostenpflichtig sind (in ihre kommerziellen Produkte integriert). Wenn Benutzer nicht dafür bezahlen möchten, können sie nur wählen, ihre eigene Managementplattform (auch bekannt als die Kontrollebene des Gateways) zu entwickeln, um diese API-Gateways zu verwalten, was bedeutet, dass Benutzer einen Vollzeit-Ingenieur einstellen müssen, der diese Entwicklungsarbeit übernimmt.

Kauf von Enterprise-Level-API-Gateway-SaaS-Diensten

Wenn Open-Source-API-Gateways die Anforderungen in Bezug auf die Funktionalität erfüllen, aber die Kosten für die Eigenentwicklung der Kontrollebene nicht akzeptabel sind, können Benutzer auch in Betracht ziehen, die Originalhersteller dieser Open-Source-Software zu kontaktieren (wie API7.ai hinter Apache APISIX, Kong Inc hinter Kong und Tyk Inc hinter Tyk usw.). Diese Hersteller bieten oft verschiedene Enterprise-Level-API-Gateway-Produkte und Support-Dienste an. Insbesondere im Szenario von "Multi-Cloud" und "Hybrid Cloud" haben diese Hersteller nacheinander ihre SaaS-Produkte veröffentlicht. Die SaaS-Produkte des API-Gateways konzentrieren sich oft auf die Managementseite und bieten eine gebrauchsfertige Konsole, ohne sich darum kümmern zu müssen, wo die API-Gateway-Instanz deployt ist (natürlich unterstützen einige SaaS-Dienste auch das Hosting der API-Gateway-Instanz, aber dies führt oft auch zu anderen Problemen, wie Latenz beim Proxying der API).

SaaS-Dienste bieten in der Regel ein privates Gateway-Kontrollpanel für jeden Mieter an, das mit Benutzer-deployten (oder SaaS-gehosteten) Gateway-Instanzen über Strategien wie mTLS verbunden ist, um Datensicherheit und Datenschutz zu gewährleisten, und Managementfähigkeiten bereitstellt. Während der Kauf eines SaaS-Dienstes eine Investition erfordern kann, kann er kosteneffektiver sein als die Einstellung eines dedizierten Ingenieurs zur Wartung eines API-Gateways und seines Kontrollpanels.

Natürlich erfordert der Kauf von SaaS-Diensten Vorsicht. Daher sollten Benutzer vor der Bestätigung einer Bestellung einen SaaS-Dienst aus folgenden Aspekten bewerten:

1. Kann dieser SaaS-Dienst die aktuellen und zukünftigen Nutzungsanforderungen erfüllen?
2. Ist der SaaS-Dienstanbieter professionell und vertrauenswürdig? Welche Anwendungsfälle haben sie?
3. Ist dieser SaaS-Dienst konform, GDPR-konform und hat SOC2-Audit-Berichte?
4. Hat dieser SaaS-Dienst klare SLA-Bedingungen?
5. Wie wird dieser SaaS-Dienst abgerechnet? Können Benutzer die zukünftigen Ausgaben für ein Jahr oder einige Jahre schätzen?

Vollständige Eigenentwicklung

Wenn Open-Source-API-Gateway-Lösungen die tatsächlichen Anforderungen des Benutzers nicht erfüllen, können Benutzer in Betracht ziehen, ihr eigenes exklusives API-Gateway-Produkt zu entwickeln, was zeit- und ressourcenintensiv sein kann, und die Stabilität des Gateways ist ebenfalls ein großes Anliegen. Die Entwicklung eines API-Gateways ist nicht so schwierig wie die Implementierung einer relationalen Datenbank oder eines Browsers, aber es ist auch nichts, was über Nacht erledigt werden kann; daher kann die Eigenentwicklung als "die schlechteste Strategie" betrachtet werden. Infolgedessen wird sie oft nur als letzter Ausweg in Betracht gezogen.

4. Fazit

In einer Cloud-nativen Umgebung wird das Management von APIs in "Multi-Cloud"- und "Hybrid Cloud"-Szenarien eine Herausforderung für jede Organisation sein, sogar bevor diese Strategien übernommen werden. Daher ist es, während dieser Artikel verschiedene Optionen präsentiert, wichtig, im Hinterkopf zu behalten, dass es keine Einheitslösung gibt und Benutzer die Option auswählen sollten, die am besten zu ihren spezifischen Geschäftsanforderungen und Entwicklungszielen passt.

Weitere Informationen über API-Gateways finden Sie in unseren Blogs oder kontaktieren Sie uns.