Heute sind die APIs die neue Grenze in der IT-Strategie und -Architektur. In welcher Branche du auch immer suchst, das digitale Geschäft steht ganz oben auf der Tagesordnung – und APIs sind ein wesentlicher Teil des digitalen Menüs. Bei Yenlo genießen wir das Glück, mit vielen Firmen zusammenzuarbeiten, die APIs bauen und API-Management für diese APIs implementieren. Auch wenn es viele Unterschiede zwischen den verschiedenen Projekten gibt, an denen wir arbeiten, gibt es auch bemerkenswerte Ähnlichkeiten. Ähnlichkeiten in der Art der Herausforderungen, denen Unternehmen gegenüberstehen. Und Ähnlichkeiten in der Art der Entwicklung, die diese Unternehmen durchlaufen.
Aus diesen Fällen haben wir bisher fünf verschiedene Stadien der API-Adoption geerntet. Nun, deine Laufleistung kann natürlich variieren, aber wir wollten unsere Erfahrung mit dir teilen und dir hoffentlich helfen, deine API-Initiative in die richtige Richtung zu lenken.
Stufe 1: API-Bewusstsein
In der ersten Phase der API-Annahme werden die APIs einfach als eine leichte Methode der App-Integration eingeführt. Häufig sehen wir die Integrationsbedürfnisse von mobilen Apps als die ersten Ziele. In einem Mobile-First-Ansatz werden die APIs einfach aus dem User Experience Design extrahiert – oder: Human Interface Design, wie Apple es immer noch bevorzugt nennt. In anderen Worten, die APIs sind so gestaltet, dass sie das Leben für App-Entwickler einfach machen. Und da das Web-zentrierte Modell der APIs dazu neigt, gut mit den Entwicklungs-Frameworks für mobile Apps zu harmonieren, ist die Schwelle zur Übernahme von APIs ziemlich niedrig. In dieser Phase solltest du erwarten, dass deine Entwickler schnell enthusiastisch werden – das neue, vereinfachte Programmiermodell für Remote Procedure Calls erweist sich als viel einfacher zu implementieren als die Technologien, an die sie gewöhnt sind. Darüber hinaus haben die Entwickler das Gefühl, die Kontrolle über den gesamten Integrationspfad zu haben, was die Effizienz der Entwicklung stark erhöht. Es beschleunigt den gesamten Prozess erheblich, was wiederum die Produktbesitzer glücklich macht. Und so breiten sich die Infektionen schnell aus – vor allem bei den Teams, die im Schnelllebigkeitsmodus der IT arbeiten.
Stufe 2: API-Plattform-Architektur
Sobald die Vorteile von APIs fest etabliert sind, wirst du wahrscheinlich anfangen, über verschiedene Arten von Sorgen nachzudenken – und sei es nur, weil bestimmte Anbieter ihre API-Technologien vorantreiben. Die Sorgen, die typischerweise in dieser Phase auf die Management-Agenda gesetzt werden, sind solche wie: die Risiken, die mit der API-Nutzung verbunden sind, wie du die Qualität deiner APIs kontrollierst und wie du diese APIs auf Unternehmensebene verwalten kannst.
Die API-Management-Produkte gehen diese Bedenken durch mehrere Komponenten an. Ein API Gateway ist die Technologie der Wahl, um den Zugang zu deinen APIs zu schützen. Es fungiert als ein Proxy auf App-Ebene, der eine Reihe von Richtlinien durchsetzt. Diese Richtlinien befassen sich mit verschiedenen damit verbundenen Risiken – wie zum Beispiel der Beschränkung des Zugriffs und dem Schutz vor Kapazitätsüberlauf. Der erste Satz von Richtlinien gewährt den Zugriff nur von identifizierten Apps, die von vertrauenswürdigen Entwicklern erstellt wurden, die nachweisen können, dass sie ein gültiges Abonnement für deine API besitzen. Außerdem kann die Autorisierung von Endbenutzern ins Spiel kommen. Schließlich wird nicht jeder, der eine App benutzt, gleich behandelt. Ratenbeschränkung ist eine andere Art von Technik, die darauf abzielt, Client-Anwendungen auf eine vernünftige Anzahl von API-Aufrufen pro Zeiteinheit zu beschränken. Alle folgenden Requests werden gedrosselt. Außerdem können intelligentere Richtlinien zur Ratenbeschränkung die Gesamtzahl der Aufrufe aus allen Quellen zusammen begrenzen. Ist schließlich der Schutz deiner Backend-Systeme vor einem Überlauf von API-Aufrufen dein Ziel, dann ist das der einfachste Ansatz.
Damit das alles funktioniert, sollten Richtlinien definiert (in einem Policy-Administrationspunkt) und veröffentlicht werden, und API-Abonnements müssen verwaltet werden. Das ist der Punkt, an dem ein API Publishing Portal und ein API Developer Store ins Spiel kommen. Es ist sehr sinnvoll, einen einzigen Store für alle angebotenen APIs zu implementieren. Entwickler, die APIs konsumieren, werden dankbar sein, wenn sie einen einzigen Punkt haben, an dem sie deine APIs entdecken, testen und abonnieren können.
Ein System von Gateways und Portalen einzurichten, kann sehr einfach sein. Häufig müssen jedoch alle möglichen Anforderungen berücksichtigt werden. Man denke an Leistung, (globale) Skalierbarkeit, Verfügbarkeit, Handhabbarkeit und Sicherheitsanforderungen, um nur einige zu nennen. Die API-Verwaltungskomponenten müssen in eine bestehende Unternehmensarchitektur eingepasst werden, einschließlich eines Identitätsproviders, eines RDBMS, einer Analyse-Engine, eines Log-Aggregators und eines Gesundheitsmonitors. Wenn du über mehrere Datenzentren verfügst, in der Cloud oder vor Ort, erhöht sich der Grad der Wahlfreiheit proportional. Du verstehst schon. Am besten ist es also wahrscheinlich, mehrere Designworkshops mit deinen führenden Architekten einzuplanen.
Mit einem zentralisierten API-Management kommt die erste Stufe der Standardisierung – insbesondere Namenskonventionen und Richtlinien für das Lebenszyklus-Management. Selbstverständlich ist es von Unternehmen zu Unternehmen unterschiedlich wichtig, das äußere Erscheinungsbild eines gut geführten und synchronisierten Unternehmens zu schaffen, und damit auch der Umfang und die Durchsetzung von Standards, aber nur wenige können es vermeiden, überhaupt einige Standards zu haben.
Stufe 3: API-Management Core Prozesse
Eine Methode, die wir die meiste Zeit erleben, ist, mit der Übernahme eines Großteils der API-Management-Funktionalität out-of-the-box zu beginnen – die minimale praktikable API-Management-Konfiguration – und erst später mit der Skalierung, Anpassung und Feinabstimmung zu beginnen. Diese Veränderungen werden deine Gesamtarchitektur nicht beeinflussen, aber es kann zum Beispiel das Look-and-Feel und sogar die Funktionalität deiner Portale beeinflussen.
Das Engagement der Entwickler bekommt immer mehr Aufmerksamkeit. Zum Beispiel, um die Zusammenarbeit von API-Anbietern und Verbrauchern über zeitliche, sprachliche und geografische Grenzen hinweg zu fördern. Was sind die Best Practices für die Dokumentation? Wie klassifiziert man APIs? Wie baut man Konsistenz über APIs hinweg auf und erhält sie aufrecht? Die richtigen Antworten auf diese Fragen zu finden, ist oft ein kompliziertes Rätsel, das es zu lösen gilt.
Ein weiterer Bereich, der uns Sorgen bereitet, sind die Verwaltungsprozesse, die die Entwickler in deinem Entwicklershop unterstützen. Out-of-the-box werden diese Prozesse einfach vom Entwickler selbst verwaltet. In manchen Fällen kann dies gut genug sein. Häufiger stellen wir fest, dass die Unternehmen oder Geschäftseinheiten, die ihre APIs anbieten, etwas Kontrolle über die Entwickler haben wollen, die sie implementieren. Das kann von der einfachen Überprüfung einer E-Mail-Adresse, wobei vielleicht alle Adressen außerhalb der Firmendomain herausgefiltert werden, über eine umfassende Überprüfung der Entwickler und ihrer Organisationen bis hin zu einer gründlichen Untersuchung der von ihnen entwickelten Anwendungen reichen.
Mit dem WSO2 API-Manager kannst du deine eigenen Prozesse vollständig definieren, in deinem bevorzugten Workflow, Geschäftsprozessmanagement oder Case Management System. Und falls du kein solches System zur Verfügung hast, oder du nicht mehr darin investieren möchtest, dann sei versichert, dass der WSO2 Business Process Server eine gute Wahl ist, um diese Aufgabe für dich zu erledigen.
Stufe 4: Erweiterte API-Management-Praktiken
Mit der Zeit steigt die Anzahl der APIs, die du verwaltest, die Anzahl der Entwickler, mit denen du dich beschäftigst, und die Anzahl der API-Aufrufe, mit denen du konfrontiert wirst. Das ist gut, dein Unternehmen blüht.
Um mit deinem wachsenden Unternehmen Schritt zu halten, bist du immer mehr auf dein API Analytics Dashboard angewiesen. Du musst deine Engpässe frühzeitig entdecken und sie vorzugsweise beheben, sobald sie auftreten. Sofortiges Up- und Downscaling deiner API-Gateways ist ein zunehmend üblicher Lösungsweg. Die gute Nachricht ist, dass deine fortgeschrittene API-Analyse das ideale System ist, um den Zustand deines Systems zu überwachen und Up- und Downscaling-Ereignisse auszulösen. Darüber hinaus kann es – absichtlich oder unabsichtlich – auch die unerwünschte Nutzung deiner APIs überwachen und eine entsprechende Gegenmaßnahme einleiten – beispielsweise die dynamische Begrenzung der Raten pro Entwickler, pro App oder IP-Adresse. Oder sogar ein API-Abonnement widerrufen oder eine IP-Adresse auf die schwarze Liste setzen. Du bist für deine Plattform verantwortlich, und das Gute daran ist, dass du nicht persönlich eingreifen musst, wenn gegen deine Richtlinien verstoßen wird.
Ehrlich gesagt, die Art und Weise, wie diese fortgeschrittenen Gegenstrategien entwickelt werden, ist meistens als Folgemaßnahme zu irgendeinem Vorfall gedacht. Das entspricht unserer empfohlenen Praxis: Verbringe nicht zu viel Zeit damit, dir Alptraumszenarien vorzustellen, sondern überwache deine Systeme genau und werte jeden Vorfall aggressiv aus und verfolge ihn weiter, so dass die Wahrscheinlichkeit einer Wiederholung gleich Null ist. In anderen Worten: Macht schnell und repariert alles, was auf dem Weg kaputt geht. Und verpasst keine Gelegenheit zum Lernen und Verbessern.
Monetarisierung ist ein weiteres Thema, das mit erfahreneren API-Unternehmen einhergeht. Mit der Monetarisierung deiner APIs gewinnt das persönliche Engagement der Entwickler noch mehr an Bedeutung. Dein API Developer Store ist nun zu einem Portal geworden, um mehr Kunden zu gewinnen und sie mit der Zeit glücklich zu machen. Daher möchtest du Statistiken über ihren API-Verbrauch und dein Serviceniveau mit ihnen teilen. Und vor allem solltest du Nutzungsdaten gemäß deinem Abrechnungsplan messen. WSO2 API Manager Analytics ist da, um dir dabei zu helfen.
Stufe 5: API First
In der fünften und derzeit letzten Phase kommen die Unternehmen zu der Erkenntnis, dass das, was für die Frontend-Integration gut funktioniert, genauso gut in der Backend-Integration funktionieren könnte. Die traditionellen SOA-Integrationsbemühungen neigen dazu, als unnötig umständlich, enttäuschend ineffektiv und unzureichend auf die heutigen agilen Entwicklungspraktiken abgestimmt entlassen zu werden. Daher werden APIs zur wichtigsten Sprache der Unternehmensintegration.
Um eine API First-Strategie anzunehmen, müssen ein paar Dinge vorhanden sein. Zunächst muss dein API-Gateway zum Single-Point-of-Entry für deine Dienste werden. Nur so kannst du dich darauf verlassen, dass dein Policy-Durchsetzungspunkt deine Dienste in allen Fällen von Richtlinienverstößen wirksam abschirmt. Keine weiteren Ausreden mehr, alle Service Calls werden über dein API-Gateway geleitet. Und alle Service Calls werden aktiv überwacht und unterliegen verwalteten Richtlinien. Keine Ausnahme.
Zweitens, dein Integrationsansatz muss umgekrempelt werden. Deine Service-Consumer-Teams müssen nicht länger darauf warten, dass die Integrationstruppe ihre Magie entfaltet – meistens, um am Ende festzustellen, dass das Service-Interface doch viel zu wünschen übrig lässt. Bei einem API First-Ansatz beginnst du damit, zuerst deine API zu definieren, und generierst einfach deine Stubs und Clients, damit deine Teams sofort mit dem Experimentieren und Verbessern beginnen können. Und nur wenn du dir sicher bist, dass eine API gut definiert ist, fängst du an, deine Service-Provider und deine Service-Konsumenten aufzubauen. Das kannst du parallel machen, weil die Integration bereits validiert und verifiziert wurde. Im Hinblick auf Effizienzgewinne ist dies wahrscheinlich der größte Schub, den du von deiner API-Management-Initiative erwarten kannst.
Schlussbemerkung
Die API-Ära ist noch frisch und entwickelt sich schnell. Daher sind wir bei weitem nicht sicher, dass die fünfte Stufe die letzte Stufe sein wird. Wenn sich die Vorzeichen als richtig erweisen, verspricht es weiterhin eine aufregende Zeit der Integration zu werden. Auf jeden Fall kannst du von uns erwarten, dass wir dich über unsere Ergebnisse auf dem Laufenden halten.
Wo bist du derzeit auf deiner API-Adoptionsreise? Noch in der Anfangsphase, oder läuft du schon vorne mit? Vielleicht schon über die fünfte Stufe hinaus? Wir würden uns freuen, von dir im Kommentarbereich zu hören. Hast du in der Zwischenzeit Fragen, wie du API-versierter werden kannst? Dann zögere nicht, uns sofort zu kontaktieren. Wenn du es uns erlaubst, werden wir dich auch stolz auf deiner API-Adoptionsreise begleiten.
