Cloud-native Anwendungen bestehen aus Dutzenden, Hunderten oder sogar Tausenden von APIs, die Microservices miteinander verbinden. Gemeinsam sorgen diese Services und APIs für die Ausfallsicherheit, Skalierbarkeit und Flexibilität, die das Herzstück Cloud-nativer Anwendungen bilden.
Heutzutage werden diese zugrunde liegenden APIs und Microservices häufig von weltweit verteilten Teams entwickelt, die ein gewisses Maß an Autonomie und Unabhängigkeit benötigen, um Funktionen zeitnah auf den Markt zu bringen.
Gleichzeitig sind die Platform-Ops-Teams dafür verantwortlich, die allgemeine Zuverlässigkeit und Sicherheit der Anwendungen und Infrastruktur des Unternehmens einschließlich der zugrunde liegenden APIs zu gewährleisten. Sie benötigen Einblick in den API-Datenverkehr und die Möglichkeit, globale Leitplanken festzulegen, um einheitliche Sicherheit und Compliance zu gewährleisten – und gleichzeitig eine hervorragende API-Entwicklererfahrung zu bieten.
Auch wenn die Interessen dieser beiden Gruppen miteinander in Konflikt geraten können, halten wir das nicht für unvermeidlich. Wir haben den API Connectivity Manager als Teil der F5 NGINX Management Suite entwickelt, damit Platform-Ops-Teams gleichzeitig für Sicherheit und einen reibungslosen Betrieb sorgen können, während API-Entwickler mühelos neue Funktionen entwickeln und veröffentlichen können.
Entwicklung einer Architektur zur Unterstützung der API-Konnektivität
Als Managementebene der nächsten Generation wurde API Connectivity Manager entwickelt, um das Potenzial von NGINX Plus als API-Gateway auszuschöpfen und zu erweitern. Wenn Sie NGINX bereits verwendet haben, kennen Sie die Skalierbarkeit, Zuverlässigkeit, Flexibilität und Leistungsfähigkeit von NGINX als API-Gateway.
Bei der Entwicklung von API Connectivity Manager haben wir eine neue Architektur konzipiert, die eine bessere Zusammenarbeit zwischen Platform-Ops-Teams und Entwicklern ermöglicht. Für ihre Komponenten werden die folgenden branchenüblichen Begriffe verwendet (von denen einige von den Bezeichnungen abweichen, die erfahrenen NGINX-Benutzern vertraut sind):
- Arbeitsbereich – Eine isolierte Sammlung von Infrastruktur zur dedizierten Verwaltung und Nutzung durch einen einzelnen Geschäftsbereich oder ein einzelnes Team; umfasst in der Regel mehrere Umgebungen
- Umgebung – Eine logische Sammlung von NGINX Plus-Instanzen (Clustern), die als API-Gateways oder Entwicklerportale für eine bestimmte Phase des Anwendungslebenszyklus dienen, beispielsweise Entwicklung, Test oder Produktion
- API-Gateway-Proxy-Cluster – Eine logische Darstellung des NGINX API-Gateways, die NGINX Plus-Instanzen gruppiert und deren Status untereinander synchronisiert
- API-Proxy – Repräsentiert eine veröffentlichte Instanz einer API und umfasst Routing, Versionierung und weitere Richtlinien
- Richtlinien – Eine globale oder lokale Abstraktion zur Definition bestimmter Funktionen des API-Proxys, etwa Ausfallsicherheit, Sicherheit oder Dienstgüte
Das folgende Diagramm veranschaulicht, wie die Komponenten innerhalb eines Workspace verschachtelt sind:
Diese logische Hierarchie ermöglicht eine Vielzahl wichtiger Anwendungsfälle, die eine unternehmensweite API-Konnektivität unterstützen. Workspaces können beispielsweise mehrere Infrastrukturtypen umfassen (etwa Public Cloud und On-Premises), sodass Teams auf beide zugreifen können und Infrastrukturverantwortliche Einblick in den API-Datenverkehr in beiden Umgebungen erhalten.
In zukünftigen Beiträgen werden wir uns die Architekturkomponenten genauer ansehen. Zunächst betrachten wir jedoch, wie API Connectivity Manager die verschiedenen Rollen unterstützt, die an der Entwicklung und Bereitstellung von APIs beteiligt sind.
API Connectivity Manager für den Plattformbetrieb
Das Platform-Ops-Team ist für den Aufbau und die Verwaltung des gesamten Infrastrukturlebenszyklus eines Unternehmens verantwortlich. Es stellt die Plattform bereit, auf der Entwickler Anwendungen und Services für Kunden und Partner erstellen. Entwicklungsteams sind häufig dezentral organisiert, arbeiten in mehreren Umgebungen und sind unterschiedlichen Geschäftsbereichen unterstellt. Die Anforderungen dieser verteilten Teams und Umgebungen zu erfüllen und gleichzeitig unternehmensweite Standards einzuhalten, ist heute eine der größten Herausforderungen für Platform-Ops-Teams.
API Connectivity Manager bietet innovative Möglichkeiten, Teams und ihre Abläufe mithilfe von Workspaces als logische Grenze voneinander zu trennen. Zudem können Platform-Ops-Teams damit den Lebenszyklus der Infrastruktur verwalten, ohne die Teams zu beeinträchtigen, die APIs entwickeln und bereitstellen. API Connectivity Manager verfügt über integrierte globale Standardrichtlinien, die grundlegende Sicherheits- und Konfigurationseinstellungen für NGINX Plus-API-Gateways und Entwicklerportale bereitstellen. Platform-Ops-Teams können anschließend ergänzende globale Richtlinien konfigurieren, um optional mTLS vorzuschreiben, Protokollformate festzulegen oder Proxy-Header zu standardisieren.
Die globale Richtlinie sorgt für Einheitlichkeit und Konsistenz bei den APIs, die im gemeinsam genutzten API-Gateway-Cluster bereitgestellt werden. API Connectivity Manager bietet Unternehmen außerdem die Möglichkeit, dezentrale Datenebenen-Cluster zu betreiben, um die Bereitstellungsorte der APIs der einzelnen Teams oder Geschäftsbereiche physisch voneinander zu trennen.
In einem weiteren Blogbeitrag werden wir untersuchen, wie Platform-Ops-Teams den API Connectivity Manager nutzen können, um API-Sicherheit und Governance zu gewährleisten und gleichzeitig API-Entwickler zum Erfolg zu führen.
API Connectivity Manager für Entwickler
Teams aus verschiedenen Geschäftsbereichen besitzen und betreiben jeweils eigene API-Sets. Sie benötigen die Kontrolle über ihre API-Produkte, um ihre Anwendungen und Services rechtzeitig auf den Markt bringen zu können. Daher können sie es sich nicht leisten, auf die Genehmigung anderer Teams für die Nutzung gemeinsam verwendeter Infrastruktur zu warten. Gleichzeitig müssen „Leitplanken“ vorhanden sein, damit sich die Teams nicht gegenseitig in die Quere kommen.
Wie die Rolle „Platform Ops“ erhalten auch Entwickler als API-Verantwortliche eigene Workspaces, in denen ihre APIs von denen anderer Teams getrennt sind. API Connectivity Manager stellt API-Verantwortlichen Richtlinien auf API-Proxy-Ebene bereit, mit denen sie Einstellungen auf Serviceebene wie Ratenbegrenzungen und zusätzliche Sicherheitsanforderungen konfigurieren können.
In einem weiteren Blogbeitrag werden wir untersuchen, wie Entwickler mit API Connectivity Manager die Verwaltung des API-Lebenszyklus vereinfachen können.
Erste Schritte
Starten Sie eine 30-tägige kostenlose Testversion der NGINX Management Suite, die den API Connectivity Manager und den Instance Manager umfasst.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.