Adaptive Governance gibt API-Entwicklern die nötige Autonomie

NGINX | 10. November 2022

Heutige Unternehmen bestehen häufig aus weltweit verteilten Teams, die APIs und Microservices entwickeln und bereitstellen – meist in mehreren Bereitstellungsumgebungen. Laut dem State of Application Strategy Report von F5 betreiben 81 % der Unternehmen ihre Anwendungen in drei oder mehr Umgebungen, darunter Public Clouds, Private Clouds, lokale Rechenzentren und Edge-Umgebungen.

Die Zuverlässigkeit und Sicherheit dieser komplexen Multi-Cloud-Architekturen zu gewährleisten, stellt die für deren Betrieb verantwortlichen Platform-Ops-Teams vor eine große Herausforderung. Laut den im F5-Bericht befragten Führungskräften aus dem Bereich Softwareentwicklung stehen Transparenz (45 %) und einheitliche Sicherheit (44 %) ganz oben auf der Liste der Multi-Cloud-Herausforderungen, mit denen Platform-Ops-Teams konfrontiert sind.

Angesichts der wachsenden Zahl von APIs und Microservices entwickelt sich API-Governance schnell zu einem der wichtigsten Themen bei der Planung und Umsetzung einer unternehmensweiten API-Strategie. Doch was ist API-Governance und warum ist sie für Ihre API-Strategie so wichtig?

Was ist API-Governance?

Grundsätzlich umfasst API-Governance die Erstellung von Richtlinien sowie die Durchführung von Prüfungen und Validierungen, um sicherzustellen, dass APIs auffindbar, zuverlässig, beobachtbar und sicher sind. Sie schafft Transparenz über den Zustand der komplexen Systeme und Geschäftsprozesse, auf denen Ihre modernen Anwendungen basieren. Diese Erkenntnisse können Sie nutzen, um die Weiterentwicklung Ihrer API-Infrastruktur langfristig zu steuern.

Warum brauchen Sie API-Governance?

Die strategische Bedeutung von API-Governance kann kaum überschätzt werden: Sie ist das Mittel, mit dem Sie die übergreifende API-Strategie Ihres Unternehmens umsetzen. Ohne eine angemessene Governance können Sie bei der Gestaltung, dem Betrieb und der Produktisierung Ihrer APIs keine durchgängige Konsistenz erreichen.

Bei schlechter Umsetzung führt Governance häufig zu aufwendigen Anforderungen, die Teams ausbremsen. Gut umgesetzte API-Governance hingegen reduziert den Arbeitsaufwand, vereinfacht Genehmigungsprozesse und ermöglicht es den verschiedenen Teams in Ihrem Unternehmen, unabhängig voneinander zu arbeiten und zugleich die übergeordneten Ziele Ihrer API-Strategie zu erreichen.

Welche Arten von APIs müssen Sie verwalten?

Die Entwicklung eines effektiven API-Governance-Plans als Teil Ihrer API-Strategie beginnt damit, die Arten von APIs zu ermitteln, die Sie in der Produktion einsetzen, sowie die Tools, Richtlinien und Leitlinien, die Sie für deren Verwaltung benötigen. Heutzutage arbeiten die meisten Unternehmensteams mit vier grundlegenden Arten von APIs:

  • Externe APIs – Werden externen Nutzern und Entwicklern bereitgestellt, um Self-Service-Integrationen mit Daten und Funktionen zu ermöglichen
  • Interne APIs – Werden zur Verbindung interner Anwendungen und Microservices verwendet und stehen nur den Entwicklern Ihres Unternehmens zur Verfügung
  • Partner-APIs – Ermöglichen strategische Geschäftsbeziehungen, indem Sie Entwicklern aus Partnerorganisationen Zugriff auf Ihre Daten oder Anwendungen gewähren
  • Drittanbieter-APIs – Werden als Dienst von Drittanbietern genutzt, häufig zur Zahlungsabwicklung oder um den Zugriff auf Daten oder Anwendungen zu ermöglichen

Jeder API-Typ im Unternehmen muss verwaltet werden, um sicherzustellen, dass er sicher und zuverlässig ist und den Teams und Benutzern zur Verfügung steht, die darauf zugreifen müssen.

Welche API-Governance-Modelle können Sie verwenden?

Es gibt viele Möglichkeiten, API-Governance zu definieren und umzusetzen. Bei NGINX stellen wir fest, dass Kunden in der Regel eines von zwei Modellen anwenden:

  • Zentralisiert – Ein zentrales Team prüft und genehmigt Änderungen. Je nach Umfang des Betriebs kann dieses Team zu einem Engpass werden, der den Fortschritt verlangsamt.
  • Dezentralisiert – Einzelne Teams können APIs eigenständig entwickeln und verwalten. Dies verkürzt die Markteinführungszeit, geht jedoch zulasten der allgemeinen Sicherheit und Zuverlässigkeit.

Wenn Unternehmen jedoch auf ihrem Weg zu einem API-First-Ansatz voranschreiten, stoßen beide Modelle mit zunehmender Anzahl produktiv eingesetzter APIs an ihre Grenzen. Zentralisierte Modelle verfolgen häufig einen Einheitsansatz, der im Laufe des Prozesses verschiedene Prüfungen und Freigaben erfordert. Das bremst Entwicklungsteams aus und führt zu Reibungsverlusten. Aus Frustration finden Entwickler mitunter sogar Wege, die Vorgaben zu umgehen (die gefürchtete „Schatten-IT“).

Das andere Modell – die dezentrale Governance – funktioniert für API-Entwickler zunächst gut, doch mit der Zeit nimmt die Komplexität zu. Wenn die verschiedenen Teams, die APIs bereitstellen, nicht regelmäßig miteinander kommunizieren, entsteht über die APIs hinweg ein uneinheitliches Gesamterlebnis: Jede API ist anders konzipiert und funktioniert anders, Versionsänderungen führen zu Ausfällen zwischen Diensten und Sicherheitsvorgaben werden von den Teams und Diensten uneinheitlich umgesetzt. Für die Teams, die APIs entwickeln, führen der zusätzliche Aufwand und die zunehmende Komplexität schließlich dazu, dass die Entwicklung nahezu zum Erliegen kommt – genau wie beim zentralisierten Modell.

Cloud-native Anwendungen sind auf APIs angewiesen, damit die einzelnen Microservices miteinander kommunizieren und Antworten an die Quelle der Anfrage zurücksenden können. Da Unternehmen aufgrund ihrer Flexibilität und Agilität weiterhin verstärkt auf Microservices setzen, wird die unkontrollierte Ausbreitung von APIs nicht verschwinden. Stattdessen benötigen Sie einen anderen Ansatz für die Governance von APIs in diesen komplexen, sich ständig verändernden Umgebungen.

API-Entwickler durch adaptive Governance stärken

Glücklicherweise gibt es einen besseren Weg. Adaptive Governance bietet ein alternatives Modell, das API-Entwicklern mehr Handlungsspielraum gibt und gleichzeitig Platform-Ops-Teams die nötige Kontrolle ermöglicht, um die Zuverlässigkeit und Sicherheit von APIs im gesamten Unternehmen zu gewährleisten.

Im Mittelpunkt der adaptiven Governance steht das Gleichgewicht zwischen Kontrolle (dem Bedürfnis nach Konsistenz) und Autonomie (der Fähigkeit, lokale Entscheidungen zu treffen), um Agilität im gesamten Unternehmen zu ermöglichen. In der Praxis entkoppelt das adaptive Governance-Modell die Entscheidungsfindung und verteilt sie auf verschiedene Teams.

Platform-Ops-Teams verwalten gemeinsam genutzte Infrastruktur (API-Gateways und Entwicklerportale) und legen globale Richtlinien fest, um die Konsistenz über alle APIs hinweg sicherzustellen. Teams, die APIs entwickeln, fungieren hingegen als Fachexperten für ihre Services oder Geschäftsbereiche. Sie sind befugt, lokale Richtlinien für ihre APIs festzulegen und anzuwenden – etwa rollenbasierte Zugriffskontrolle (RBAC), Ratenbegrenzung für ihren Service usw. –, um die Anforderungen ihres jeweiligen Geschäftskontexts zu erfüllen.

Adaptive Governance ermöglicht es jedem Team oder Geschäftsbereich, eigene Workflows zu definieren und das erforderliche Maß an Kontrolle auszutarieren, während gleichzeitig die gemeinsam genutzte Infrastruktur des Unternehmens verwendet wird.

Implementieren Sie adaptive Governance für Ihre APIs mit NGINX

Wenn Sie mit der Planung und Umsetzung Ihrer API-Strategie beginnen, befolgen Sie diese Best Practices, um eine adaptive Governance in Ihrem Unternehmen zu etablieren:

Sehen wir uns an, wie Sie diese Anwendungsfälle mit dem API Connectivity Manager, einem Bestandteil der F5 NGINX Management Suite, umsetzen können.

Gemeinsam genutzte Infrastruktur bereitstellen

Teams in Ihrem gesamten Unternehmen entwickeln APIs und müssen ähnliche Funktionen in ihre Microservices integrieren: Authentifizierung und Autorisierung, mTLS-Verschlüsselung und mehr. Außerdem müssen sie ihren API-Nutzern – ob internen Teams, Geschäftspartnern oder externen Entwicklern – Dokumentation und Versionierung zur Verfügung stellen.

Anstatt von den Teams zu verlangen, eigene Lösungen zu entwickeln, können Platform-Ops-Teams den Zugriff auf eine gemeinsam genutzte Infrastruktur bereitstellen. Wie bei allen Aktionen im API Connectivity Manager lässt sich dies innerhalb weniger Minuten entweder über die Benutzeroberfläche oder die vollständig deklarative REST API einrichten. So können Sie den API Connectivity Manager in Ihre CI/CD-Pipelines integrieren. In diesem Beitrag veranschaulichen wir anhand der Benutzeroberfläche einige gängige Workflows.

API Connectivity Manager unterstützt zwei Arten von Workspaces: Infrastruktur und Services. Infrastruktur-Workspaces werden von Platform-Ops-Teams verwendet, um gemeinsam genutzte Infrastruktur in Form von API-Gateway-Clustern und Entwicklerportal-Clustern einzubinden und zu verwalten. Services-Workspaces werden von API-Entwicklern verwendet, um APIs und Dokumentationen zu veröffentlichen und zu verwalten.

Um eine gemeinsam genutzte Infrastruktur einzurichten, fügen Sie zunächst einen Infrastruktur-Workspace hinzu. Klicken Sie in der linken Navigationsspalte auf „Infrastruktur“ und anschließend oben rechts auf der Registerkarte auf die Schaltfläche „+ Hinzufügen“. Geben Sie Ihrem Workspace einen Namen (hier „team-sentence“ – ein fiktives Team, das eine einfache „Hello, World!“-API entwickelt).

Abbildung 1: Infrastruktur-Workspaces hinzufügen

Fügen Sie als Nächstes dem Workspace eine Umgebung hinzu. Umgebungen enthalten API-Gateway-Cluster und Entwicklerportal-Cluster. Klicken Sie auf den Namen Ihres Workspace und anschließend auf das Symbol „…“ in der Spalte „Aktionen“. Wählen Sie im Dropdown-Menü „Hinzufügen“ aus.

Der Bereich „Umgebung erstellen“ wird wie in Abbildung 2 dargestellt geöffnet. Füllen Sie das Feld „Name“ (und optional das Feld „Beschreibung“) aus, wählen Sie den Umgebungstyp (Produktion oder Nicht-Produktion) aus und klicken Sie für die Infrastruktur, die Sie hinzufügen möchten (API-Gateway-Cluster, Entwicklerportal-Cluster oder beides), auf die Schaltfläche „+ Hinzufügen“. Klicken Sie auf die Schaltfläche „Erstellen“, um die Einrichtung Ihrer Umgebung abzuschließen. Eine vollständige Anleitung finden Sie in der Dokumentation zu API Connectivity Manager.

Abbildung 2: Umgebung erstellen und Infrastruktur einbinden

Teams mehr Eigenverantwortung geben

Eine logische Trennung von Teams nach Geschäftsbereich, geografischer Region oder anderen sinnvollen Kriterien ist sinnvoll – sofern ihnen dadurch nicht der Zugang zu den Tools verwehrt wird, die sie für ihren Erfolg benötigen. Der Zugriff auf eine gemeinsam genutzte Infrastruktur sollte nicht dazu führen, dass sich Teams um Aktivitäten auf globaler Ebene kümmern müssen. Stattdessen sollten sie sich darauf konzentrieren können, ihre eigenen Anforderungen zu definieren, eine Roadmap zu erstellen und ihre Microservices zu entwickeln.

Um Teams bei der Organisation zu unterstützen, können Platform-Ops-Teams ihnen Services-Workspaces bereitstellen, in denen sie ihre Services und Dokumentationen organisieren und verwalten können. Diese schaffen logische Grenzen und ermöglichen den Zugriff auf verschiedene Umgebungen – beispielsweise Entwicklung, Test und Produktion – für die Entwicklung von Services. Der Vorgang ähnelt dem Erstellen des Infrastruktur-Workspaces im vorherigen Abschnitt.

Klicken Sie zunächst in der linken Navigationsspalte auf „Services“ und anschließend oben rechts auf der Registerkarte auf die Schaltfläche „+ Add“. Geben Sie Ihrem Workspace einen Namen (hier „api-sentence“ für unseren „Hello, World“-Service) und fügen Sie optional eine Beschreibung und Kontaktinformationen hinzu.

Abbildung 3: Erstellen eines Services-Workspace

Nun können Sie API-Entwickler einladen, Proxys und Dokumentationen in dem für sie erstellten Workspace zu veröffentlichen. Eine vollständige Anleitung zum Veröffentlichen von API-Proxys und Dokumentationen finden Sie in der Dokumentation zu API Connectivity Manager.

Globale Richtlinien und lokale Kontrolle in Einklang bringen

Adaptive Governance erfordert ein ausgewogenes Verhältnis zwischen der Durchsetzung globaler Richtlinien und der Befähigung von Teams, Entscheidungen zu treffen, die die Agilität steigern. Sie müssen eine klare Trennung der Verantwortlichkeiten schaffen, indem Sie die von Platform Ops durchgesetzten globalen Einstellungen definieren und „Leitplanken“ festlegen, die bestimmen, welche Tools API-Entwickler verwenden und welche Entscheidungen sie treffen können.

API Connectivity Manager bietet eine Kombination aus globalen Richtlinien (die auf die gemeinsam genutzte Infrastruktur angewendet werden) und granularen Steuerungsmöglichkeiten, die auf Ebene des API-Proxys verwaltet werden.

Zu den in API Connectivity Manager verfügbaren globalen Richtlinien gehören:

  • Fehlerantwortformat – Passen Sie den Fehlercode und die Antwortstruktur des API-Gateways an
  • Protokollformat – Aktivieren Sie die Zugriffsprotokollierung und passen Sie das Format der Protokolleinträge an
  • OpenID Connect – Sichern Sie den Zugriff auf APIs mit einer OpenID-Connect-Richtlinie ab
  • Antwort-Header – Header in die Antwort einschließen oder davon ausschließen
  • Größe des Anfragekörpers – Größe eingehender API-Nutzdaten begrenzen
  • Eingehendes TLS – Legen Sie die Richtlinie für TLS-Verbindungen mit API-Clients fest
  • Backend-TLS – Sichern Sie die Verbindung zu Backend-Diensten mit TLS ab

Zu den in API Connectivity Manager verfügbaren API-Proxy-Richtlinien gehören:

  • Zulässige HTTP-Methoden – Legen Sie fest, welche Anfragemethoden verwendet werden können (GET, POST, PUT, usw.)
  • Zugriffskontrolle – Sichern Sie den Zugriff auf APIs mithilfe verschiedener Authentifizierungs- und Autorisierungsverfahren (API-Schlüssel, HTTP-Basisauthentifizierung, JSON Web Tokens)
  • Backend-Zustandsprüfungen – Führen Sie kontinuierliche Zustandsprüfungen durch, um fehlgeschlagene Anfragen an Backend-Dienste zu vermeiden
  • CORS – Kontrollierten Zugriff auf Ressourcen durch Clients aus externen Domains ermöglichen
  • Caching – Verbessern Sie die Leistung des API-Proxys mithilfe von Caching-Richtlinien
  • Proxy-Anfrage-Header – Ausgewählte Header an Backend-Dienste weiterleiten
  • Ratenbegrenzung – Eingehende Anfragen begrenzen und API-Workloads schützen

Im folgenden Beispiel verwenden wir die Benutzeroberfläche, um eine Richtlinie zu definieren, die die Kommunikation zwischen einem API-Gateway-Proxy und Backend-Diensten absichert.

Klicken Sie in der linken Navigationsspalte auf „Infrastruktur“. Nachdem Sie auf den Namen der Umgebung geklickt haben, die den zu bearbeitenden API-Gateway-Cluster enthält, werden auf der Registerkarte die API-Gateway-Cluster und Entwicklerportal-Cluster in dieser Umgebung angezeigt.

Abbildung 4: Globale Richtlinien für API-Gateway-Cluster und Entwicklerportal-Cluster konfigurieren

Klicken Sie in der Zeile des API-Gateway-Clusters, auf den Sie eine Richtlinie anwenden möchten, auf das Symbol „…“ in der Spalte „Aktionen“ und wählen Sie im Dropdown-Menü „Erweiterte Konfiguration bearbeiten“ aus. Klicken Sie in der linken Spalte auf „Globale Richtlinien“, um eine Liste aller konfigurierbaren globalen Richtlinien anzuzeigen.

Abbildung 5: Richtlinien für einen API-Gateway-Cluster konfigurieren

Um die Richtlinie „TLS Backend“ anzuwenden, klicken Sie auf das Symbol „…“ am rechten Ende der entsprechenden Zeile und wählen Sie im Dropdown-Menü „Add Policy“ aus. Geben Sie die erforderlichen Informationen ein, laden Sie Ihr Zertifikat hoch und klicken Sie auf „Add“. Klicken Sie anschließend auf die Schaltfläche „Save and Submit“. Von nun an ist der Datenverkehr zwischen dem API Gateway Cluster und den Backend-Diensten durch TLS geschützt. Eine vollständige Anleitung finden Sie in der Dokumentation zu API Connectivity Manager.

Zusammenfassung

Die Planung und Umsetzung einer API-Governance ist ein entscheidender Schritt, um den Erfolg Ihrer API-Strategie sicherzustellen. Indem Sie auf ein verteiltes Modell hinarbeiten und auf eine adaptive Governance setzen, die den individuellen Anforderungen verschiedener Teams und APIs gerecht wird, können Sie skalieren und eine einheitliche Governance anwenden, ohne dabei die Geschwindigkeit und Agilität zu beeinträchtigen, die APIs und Cloud-native-Umgebungen so produktiv machen.

Erste Schritte

Starten Sie eine 30-tägige kostenlose Testversion der NGINX Management Suite, die Zugriff auf den API Connectivity Manager, NGINX Plus als API-Gateway und NGINX App Protect zum Schutz Ihrer APIs umfasst.


Teilen

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

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
NGINX | 08.09.2021

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
NGINX | 16.08.2021

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
NGINX | 12.12.2018

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 | 05.09.2018

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
NGINX | 13.10.2016

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.