Divide et impera - Bestandteile und Dienste einer API Plattform

Was zeichnet eine API Plattform aus?

Die flächenweite Organisation von APIs in einem Unternehmen wird durch eine Menge an Prozessen, Technologien, Werkzeugen und Methodiken (z.B. API-first) unterstützt, welche gebündelt eine lebendige API Plattform ausmachen. Die wiederverwendbaren Bestandteile bilden in ihrer Gesamtheit das Fundament für eine Vielzahl neuer Geschäftsmöglichkeiten und Partnerschaften (Ökosysteme) im B2B und/oder B2C Umfeld.

Marktplätze für APIs

Diese digitalen Ökosysteme werden in der Regel mit Hilfe von Marktplätzen realisiert. Dort können APIs zu verschiedenen Themen veröffentlicht und angeboten und mit Ökosystem-Bewohnern interagiert werden. Es herrscht wie bei einem echten Marktplatz das Gesetz von Angebot (API Provider) und Nachfrage (API Konsumenten), und wer als Provider seine Ware (API) geschickt platziert und passend bewirbt, kriegt sie eher an den Mann oder die Frau gebracht.

Solche Marktplätze sind bei den Public Cloud Anbietern für SaaS Komponenten von Drittanbietern weit verbreitet, warum dann nicht auch analog dazu ein Marktplatz für die eigenen APIs, die ein Unternehmen für seine digitalen Services sich und seinen Geschäftspartnern zur Verfügung stellt?

Analogie zu Legobausteinen – und ihre Grenzen

Man könnte es metaphorisch auch mit dem Legospiel vergleichen:

• die standardisierten digitalen APIs (Legobausteine) einer Organisation werden in entsprechende Marktplätze (Legokisten) sortiert.
• unterschiedliche Ökosystem-Bewohner können sich selbstständig aus dem angebotenen Katalog an APIs bedienen und mit diesen Bausteinen kreativ ihre eigenen Lösungen entwickeln, die einen zusätzlichen Mehrwert bringen.

Das API Design fungiert dabei als „Beipackzettel“ oder „Bastelanleitung“ und wird in der Regel in einem Marktplatz (Developer Portal, API-Shop, API-Katalog) aufgelistet und integriert.

Im Gegensatz zu Legosteinen – und hier endet die Analogie – können sich APIs im Laufe der Zeit sehr wohl ändern, und tun dies auch in der Regel über die Zeit. Das wäre so, als ob sich über Nacht (nach einer neuen Veröffentlichung) die Form mancher Legosteine ändern würde. Die Frage ist nur, ob nach dieser Veränderung die Steine noch zusammenpassen und „klicken“, oder das Gesamtbauwerk seinen Halt verliert (bei Breaking Changes).

Hier hilft uns das API (Lifecycle) Management. Ein gut durchdachtes API Design und ein methodisches Vorgehen helfen uns dabei, bei der natürlichen Evolution von APIs durch geänderte Anforderungen im Laufe der Zeit das Risiko von Breaking Changes drastisch zu reduzieren, so dass weniger Wartungskosten für den teuren Parallelbetrieb von mehreren Versionen einer API anfallen. Manchmal lassen sich aber Breaking Changes nicht vermeiden, z.B. nach dem Auffinden von Security Schwachstellen mit hoher Kritikalität, so dass man abwägen, und ggf. in den sauren Apfel beißen muss (deswegen der eindringliche Appell an dieser Stelle für „Shift Left“ Security, d.h. die Integration von Security Experten so früh wie möglich in den Entstehungsprozess einer API).

Der Sinn hinter API Management

Diese Marktplätze und Ökosysteme lassen sich mit Hilfe sogenannter API Management Plattformen realisieren. Das Ziel ist vorrangig die Bündelung komplexer/generischer Fragestellungen, um die Wertschöpfung zwischen einem API-Anbieter (Provider) Team und einem oder mehreren API-Konsumenten Teams so reibungsfrei wie möglich zu gestalten.

Zu den Kernaufgaben einer API Plattform zählen:

• Bündelung der Angebote für API-Anbieter und API-Konsumenten,
• Standardisierung der Interaktion zwischen Anbieter und Konsument,
• Steigerung der Effizienz und Geschwindigkeit der Abläufe durch Self-Services,
• Absicherung der Zugriffe zur Laufzeit und Umsetzung von Compliance-, Governance- und Security-Vorgaben mit Hilfe von API Gateways

Wir schauen uns jetzt die einzelnen Archetypen von Plattform-Bewohnern näher an, und welche Bedürfnisse diese Zielgruppen haben:

Der API-Konsument. Ein API-Konsument kann sich auf so einer Plattform eigenständig bewegen und wird durch unterschiedliche Dienstleistungen und Self-Services unterstützt, die ihn/sie durch das Angebot an bereitgestellten APIs (in Form eines Katalogs mit Such- und Filter-Funktionen) führt und bei getroffener Auswahl dabei hilft, eine API auf möglichst einfache, sichere und benutzerfreundliche Weise zu konsumieren. Es geht also darum, die User Journey des API-Konsumenten so zu gestalten, dass sich das „gut anfühlt“. Ein sinnvoller KPI (um das Ganze quantifizierbar zu machen) ist hier der „Time to First Use“ (also die Zeit zu messen bis zur ersten Nutzung), den es zu minimieren gilt.

Der API-Anbieter (Provider). Eine weitere Sorte der Plattformbewohner sind die API-Anbieter. Auch für diese Zielgruppe gibt es spezifische Hilfestellungen. Ein Provider hat in erster Linie Interesse daran, dass seine API genutzt wird. Die Qualität der angebotenen API muss dabei stimmen, darüber will der API-Provider durch Analytics und ggf. grafisch aufbereitete Dashboards informiert und auf dem Laufenden gehalten werden. So kann er auch z.B. nachverfolgen und nachvollziehen, inwiefern SLAs eingehalten werden, oder ob bei Lastspitzen die Skalierung richtig funktioniert und entsprechend greift.

Folgende Tabelle bildet die typischen Fähigkeiten einer API Plattform auf die Bedürfnisse der beiden Zielgruppen ab, und fasst sie nochmals kurz zusammen.

Abbildung 2 - Fähigkeiten einer API Plattform nach Zielgruppen

Wir schauen uns als Nächstes die Bestandteile einer API Plattform noch genauer an.

Bestandteile einer API Management Plattform

1. API Lifecycle Management

Umfasst Werkzeuge zur Steuerung des Produkt-Lebenszyklus einer API. Kerngedanke ist, dass eine API als eigenständiges Produkt betrachtet wird, und auch Prinzipen des Produkt-Designs Anwendung finden bei der kontinuierlichen Ausgestaltung von APIs.

Dieser API Lebenszyklus ist getrennt vom Lebenszyklus des dahinterstehenden Services zu betrachten, und gliedert sich in die Phasen „Created“, „Published“, „Deprecated“ und „Retired“ (siehe Abbildung 3). Aus dem „Published“ Zustand gibt es zwei mögliche Transitionen, einmal auf sich selbst (also „Published“ à „Published“) und dann nach „Deprecated“ („Published“ à „Deprecated“). Wann greift welche Transition?

Entscheidend dafür ist, ob es Breaking Changes gibt oder nicht. Im Falle von Breaking Changes muss eine veröffentlichte API „deprecated“ werden, und parallel dazu eine neue Version der API bereitgestellt werden. Im Gut-Fall, also wenn es keine Breaking Changes gibt und die API-Evolution glatt verläuft, bleibt das API-Produkt im „Published“ Zustand. In dieser „Published“-Schleife bleibt die API so lange „happily ever after“ gefangen, wie es keine Breaking Changes gibt.

Abbildung 3 - Produkt-Lebenszyklus einer API

2. Developer Portal

Ein zentraler Marktplatz mit Dienstleistungen für API Consumer Teams, wie z.B.

• Durchsicht des API-Katalogs mit Such- und Filtermöglichkeiten,
• Self-Service für Onboarding (API Subscription),
• Zugriff auf die API-Dokumentation (dazu gehören in erster Linie auch die API Spezifikation und begleitende Beispiele),
• Verwaltung von API Keys für die kontrollierte Nutzung von APIs („know your consumers“ – anhand eines API Keys kann man als API Provider einen API-Konsumenten – meist eine Anwendung oder ein Team und keine Einzelperson – eindeutig zuordnen, und dahinter auch unterschiedliche Nutzungspläne für die Monetarisierung realisieren),
• Kommunikationskanäle für die Interaktion mit Communities und API Providern

3. API Gateway

Infrastruktur zur Erzwingung/Durchsetzung der vom API Provider (und Security- und Governance-Abteilungen) festgesetzten Regeln/Policies, die Nutzung und Security-Aspekte regeln, und Einbau von Resilienz-Mechanismen als Querschnittsfunktionalität, um nicht-funktionale Anforderungen zu erfüllen, z.B.

• Validierung (z.B. gegenüber einer OpenAPI Spezifikation, um ungültige Requests gar nicht erst Richtung dahinterliegende Services zu leiten und diese damit zu schonen),
• Authentifizierung (z.B. Integration mit einem IDP, Umsetzung von Sicherheitsstandards wie OAuth2/OpenID Connect),
• Rate Limits und Spike Arrests (zur Abfederung von Lastspitzen und Vermeidung von DDoS-Angriffen),
• Circuit Breaker (Sicherung zum Schutz vor Überlastung),
• Routing (Weiterleitung auf die dahinterliegenden Services, oft mit Load Balancing verbunden)
• Access Logs, Metriken, Tracing, Fehlerprofile
• u.v.m.

4. Analytics

Überwachung der Nutzungsprofile der API-Produkte und quantitative Datengrundlage für Monetarisierungsvorhaben und Verbesserungsinitiativen, d.h.

• Überprüfung der Einhaltung von SLAs,
• Überprüfung der Einhaltung von Nutzungsplänen (Monetarisierung),
• Feedback-Schleife für das Produktteam, um Rückschlüsse über das Nutzerverhalten in der Realität zu ziehen und auf Basis dessen das API-Produkt kontinuierlich zu verbessern.

Abbildung 4 - Bestandteile einer API Plattform

Fazit und Ausblick

Wie geht es weiter? Nachdem wir uns hier einen Überblick verschafft haben über die Charakteristiken und Komponenten einer API Management Plattform, werden wir uns im nächten Artikel weiter mit diesem Thema beschäftigen und auf die Frage eingehen, wie man am besten solch eine Plattform im Unternehmen aufsetzt. Es geht dabei darum, eine Make-or-Buy Entscheidung zu treffen und entsprechend abzuwägen.