Best Practices für die Verwaltung interner APIs

NGINX | 02. September 2020

Einige verbraucherorientierte APIs sind so weit verbreitet, dass sie allgemein bekannt sind – man denke nur an Google Maps und Stripe. Doch interne APIs sind das eigentliche Kraftzentrum der API-Wirtschaft.

Interne APIs – damit meinen wir APIs, die ausschließlich für Clients und Entwickler innerhalb eines Unternehmens zugänglich sind – bilden eine zentrale Säule der digitalen Transformation eines Unternehmens. Die Entwicklung interner APIs ist in der Regel der erste Schritt bei der Entwicklung digitaler Produkte und Dienstleistungen. Laut der aktuellen IDC-Studie APIs – die entscheidenden Faktoren für Erfolg oder Misserfolg digitaler Unternehmen gehört die Unterstützung der internen Integration von Anwendungen und Produkten zu den wichtigsten Prioritäten bei API-Entwicklungsinitiativen in Unternehmen.

Warum sind interne APIs wichtig? Welche Vorteile bieten interne APIs? Und vor allem: Welche Architektur eignet sich am besten für ihre Verwaltung? Dieser Blogbeitrag geht diesen Fragen nach und unterstützt Sie dabei, interne APIs sicher und skalierbar bereitzustellen.

Warum sind interne APIs wichtig?

Interne APIs lösen Datensilos auf und schlagen Brücken, indem sie die unterschiedlichen Backend-Systeme eines Unternehmens für andere Entwickler innerhalb eines Geschäftsbereichs zugänglich machen. So benötigt beispielsweise die Marketingabteilung eines Herstellers möglicherweise Einblick in die von der Lieferkettenorganisation genutzten Systeme, um zu entscheiden, ob bestimmte Produkte und Modelle rabattiert werden sollten, damit das richtige Marktsegment angesprochen und der Umsatz maximiert werden kann.

Wie brechen interne APIs Silos auf? Sie stellen eine gemeinsame Schnittstelle bereit, die den Datenaustausch über Standardformate wie HTML oder JSON ermöglicht. Eine API lässt sich nicht nur einfach und schnell erstellen, sondern ebenso unkompliziert nutzen. Im Gegensatz dazu steht der Einsatz proprietärer Datenbankkonnektoren und schwer verständlicher Datenaustauschprotokolle, um Informationen aus Datenspeichern abzurufen. Indem APIs Hürden abbauen, steigern sie die Produktivität erheblich. Diese APIs sind für externe Entwickler und Dritte nicht zugänglich. Der interne API-Datenverkehr verbleibt innerhalb des Unternehmens – und damit hinter der Unternehmensfirewall.

Vorteile interner APIs

Interne APIs verkürzen die Markteinführungszeit und reduzieren den Zeit- und Kostenaufwand für die Softwareentwicklung. Sehen wir uns die Vorteile im Detail an.

Betriebliche Effizienz

Interne APIs bieten eine einfach nutzbare Abstraktionsschicht, um verschiedene Bereiche eines Unternehmens miteinander zu verbinden, und ermöglichen die flexible Anpassung an veränderte Anforderungen. Anstatt für die Anwendungen jedes Geschäftsbereichs einen isolierten Technologie-Stack zu erstellen, können Entwickler im gesamten Unternehmen auf einen gemeinsamen Pool interner APIs zurückgreifen, um auf Daten zuzugreifen. Dadurch werden Doppelarbeit vermieden und die Softwareentwicklungszeit verkürzt, was wiederum die Produktivität der Entwickler und der IT steigert.

Entwicklung eines führenden Systems

Interne APIs fördern die Entwicklung eines führenden Systems, das als maßgebliche Quelle für zentrale Datenelemente in einem Unternehmen dient. Um die Datenintegrität zu gewährleisten, darf es für eine bestimmte Information nur ein einziges führendes System geben. Wenn jeder Geschäftsbereich über eigene Daten oder auch nur über eine geringfügig abweichende Version verfügt, führt dies zu Unstimmigkeiten und Verwirrung. Interne APIs bieten einen effizienten Mechanismus für den Zugriff auf diese zentrale verlässliche Datenquelle.

Kosteneinsparungen

Effizienz führt zu Kosteneinsparungen – es ist nicht erforderlich, für jeden Geschäftsbereich proprietäre Plattformen mit umfangreichen individuellen Anpassungen zu entwickeln. Ebenso wenig müssen teure Konnektoren und Integrationen entwickelt oder gekauft werden, bei denen es sich im Wesentlichen um Insellösungen handelt.

So betreibt beispielsweise die estnische Regierung X‑Road, eine Datenaustauschplattform, die alle Behörden nahtlos miteinander verbindet. Estnische Bürger müssen nicht einmal ihren Führerschein mit sich führen, da die entsprechenden Informationen schnell aus dem Bevölkerungs- und dem Fahrzeugregister abgerufen werden können – obwohl es sich dabei um zwei getrennte Datenbestände handelt. Dieser Bericht der Weltbank kam zu der vorsichtigen Schätzung, dass X‑Road der estnischen Regierung und den Bürgern durch den erleichterten Zugang zu Informationen in nur einem Jahr (2014) 2,8 Millionen Arbeitsstunden erspart hat.

Richtlinien für die Verwaltung interner APIs

Sehen wir uns einige Best Practices für die Verwaltung interner APIs an.

Verwenden Sie ein API-Management-Tool

Um sowohl interne als auch externe APIs effizient zu definieren, zu veröffentlichen, abzusichern, zu überwachen und zu analysieren, benötigen Sie eine API-Management-Lösung. Außerdem ist ein Entwicklerportal erforderlich, über das sich interne Entwickler schnell über veröffentlichte APIs informieren können.

Hohe Leistung sicherstellen

Microservices sind ein neuer Architekturansatz für die Softwareentwicklung, der zunehmend an Bedeutung gewinnt. Viele Unternehmen gestalten entweder ihre bestehenden internen Anwendungen entsprechend neu oder entwickeln mithilfe dieses Frameworks neue Anwendungen. In Microservices-Architekturen dienen APIs sowohl der Kommunikation zwischen Clients und der auf Microservices basierenden Anwendung als auch der Kommunikation zwischen den einzelnen Microservices, aus denen die Anwendung besteht. Wenn ein API-Client Ressourcen von einer Backend-Anwendung anfordert, leitet ein API-Gateway den Datenverkehr an den entsprechenden Microservice weiter. Das API-Gateway authentifiziert außerdem Aufrufe und begrenzt die Anfragerate, um Angriffe zu verhindern, zu denen es kommen könnte, wenn es externen Akteuren gelingt, die Unternehmensfirewall zu überwinden.

Microservices sind „kommunikationsintensiver“ als monolithische Anwendungen und erzeugen ein hohes Volumen an „Ost-West“-Datenverkehr untereinander. Daher ist es sehr wichtig, ein leistungsstarkes Gateway zu wählen, das einen hohen Durchsatz (Anfragen pro Sekunde) bewältigen und Antworten sehr schnell bereitstellen kann. Clientanfragen lösen häufig mehrere API-Aufrufe an verschiedene Microservices aus. Daher kann bereits eine Verzögerung eines einzigen Aufrufs am API-Gateway potenziell einen Kaskadeneffekt auslösen und zu sehr hohen Latenzen führen.

Leiten Sie Aufrufe nicht über eine Cloud außerhalb des Unternehmensnetzwerks weiter

Obwohl es Cloud-basierte Lösungen der ersten Generation gibt, die ein vollständiges API-Lifecycle-Management bieten, eignen sie sich nicht für die Verarbeitung interner APIs. Da ihre Architekturen die Datenebene (das API-Gateway, das den API-Datenverkehr verarbeitet) und die Steuerungsebene (die API-Management-Funktionen ausführt) eng miteinander koppeln, muss zur Laufzeit jeder interne API-Aufruf über die Cloud der API-Management-Lösung geleitet werden. Dies hat zwei Nachteile:

  • Erhöht die Latenz – Der Umweg über die Cloud zur Verarbeitung eines internen API-Aufrufs beeinträchtigt zwangsläufig die Leistung.
  • Verstößt gegen die Zero-Trust-Richtlinie des Unternehmens – Da der interne API-Aufruf über die Cloud geleitet werden muss, müssen Ausnahmen in der Firewall eingerichtet werden. Dadurch wird das Unternehmensnetzwerk Angriffen und Sicherheitsverletzungen ausgesetzt und unnötige Komplexität geschaffen.

Aus Sicherheitsgründen muss der interne API-Datenverkehr hinter der Unternehmensfirewall verbleiben, sodass Aufrufe nicht an eine externe Cloud weitergeleitet werden können. Dies gilt selbst für Unternehmen, die Anwendungen und APIs in ihren eigenen privaten Cloud-Umgebungen hosten.

Wie kann NGINX helfen?

NGINX unterstützt Sie auf verschiedene Weise bei der Verwaltung Ihrer internen APIs.

  • NGINX ist für seine Leistungsfähigkeit bekannt. Laut GigaOm, einem unabhängigen Analysten für Technologieforschung, kann NGINX API-Aufrufe durchgängig in weniger als 30 ms verarbeiten, selbst bei mehr als 30.000 Anfragen pro Sekunde. Weitere Informationen zu den Benchmark-Ergebnissen finden Sie in unserem Blog. Wir haben eine Referenzarchitektur mit detaillierten Richtlinien für die Bereitstellung von Echtzeit-APIs veröffentlicht.
  • NGINX und NGINX Plus sind für Container konzipiert, die bevorzugte Infrastruktur für die Entwicklung von Microservices. Mit einem Speicherbedarf von etwa 2 MB laufen NGINX und NGINX Plus auf unterstützten Linux-Servern (Bare Metal, Cloud oder virtuell) oder direkt in Docker-Containern, die von Kubernetes und anderen Plattformen orchestriert werden.
  • Die innovative Architektur der NGINX-Lösung für das API-Management ist auf Skalierbarkeit ausgelegt. NGINX unterstützt verteiltes API-Management, indem das API-Gateway (NGINX Plus) von der API-Management-Software (NGINX Controller [jetzt F5 NGINX Management Suite] ) entkoppelt wird. Zwischen beiden besteht keine Laufzeitabhängigkeit. Dadurch wird sichergestellt, dass der API-Datenverkehr ohne unnötigen Overhead wie zusätzliche Skripte, Datenbankaufrufe oder andere Steuerungsebenenlogik verarbeitet wird. Die entkoppelte Architektur bietet Ihnen maximale Flexibilität bei der Bereitstellung von Controller [NGINX Management Suite] und den NGINX Plus-API-Gateways – Sie können sie lokal, in der Public Cloud oder sogar in mehreren Public Clouds bereitstellen, wenn sich Ihr Unternehmensnetzwerk bis in die Cloud erstreckt. Interne API-Aufrufe müssen nicht über eine Cloud außerhalb des Unternehmensnetzwerks geleitet werden, da die NGINX Plus-API-Gateways, die den API-Datenverkehr verarbeiten, unabhängig hinter der Unternehmensfirewall bereitgestellt werden können.

Verfügen Sie über interne APIs? Oder planen Sie, interne APIs zu entwickeln? Leiten Sie Ihre internen APIs über die Cloud weiter? Wir freuen uns auf Ihre Kommentare. Starten Sie in der Zwischenzeit mit einer kostenlosen 30-Tage-Testversion von NGINX Controller [NGINX Management Suite] oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.


Teilen
Schlagwörter: F5 NGINX, Opinion

Über den Autor

Ä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.