eBizTalk - Berichten, Unterhalten, Weiterbilden

Wer ein SPA-Framework wie Angular zur Entwicklung einer Website nutzt, muss sich früher oder später über das Thema SEO Gedanken machen. Denn anders als bei serverseitigen Frameworks, wie ASP.NET Core, wird das Markup erst durch JavaScript auf dem Client generiert. Ohne zusätzliche Anstrengungen, findet die Suchmaschine also bei der Indizierung keine Inhalte.

Serverseitiges Rendering (SSR) wäre in diesem Fall die naheliegendste Option. Dabei wird das Markup beim Aufruf einer Seite schon auf dem Server bereitgestellt und dann an den Client zurückgeliefert. In meinem Fall sollte die Website allerdings möglichst kostengünstig in einem Azure Storage Account als statische Website gehostet und serverseitige Funktionalität verbrauchsbasiert durch Azure Functions abgebildet werden. Dadurch besteht beim Aufruf der Seite keine Möglichkeit serverseitigen Code auszuführen, weshalb ich eine andere Option in Erwägung ziehen musste – Prerendering beim Build. Dabei wird die SPA während des Builds in einer lokalen Webserver-Instanz ausgeführt, alle Routen aufgerufen und das gerenderte Markup als statische HTML-Seiten gespeichert. Die einzelnen Seiten sind dann entsprechend als physische Dateien mit den notwendigen Inhalten vorhanden.

Für das Prerendering habe ich das npm-Paket angular-prerender verwendet, das wiederum auf dem bekannten Paket angular-universal basiert. Das Ergebnis wird damit in zwei Schritten erreicht:

1. Installation des Pakets (npm install angular-prerender --save-dev)
2. Ausführung der Prerenderings (npx angular-prerender)

Nachdem ich das Ergebnis in den Container im Azure Storage Account kopiert habe, konnten die einzelnen Seiten einwandfrei indiziert und damit über eine Suchmaschine einfach gefunden werden.

Beispiel App:

Ohne Prerendering:

Mit Prerendering:

In diesem Artikel, der bereits der sechste Teil in einer Serie zu API Management ist, erkläre ich, warum es wichtig ist, Transparenz über APIs innerhalb einer Firma zu schaffen und mehrere Möglichkeiten benennen, wie dies mithilfe des API Management ermöglicht werden kann.

„Sharing is the new black“

Das Sprichwort “Sharing is the new black.” wird häufig verwendet, um den Trend zu beschreiben, dass viele ihre monatlichen Abos, von zum Beispiel Netflix oder Spotify, mit Freunden teilen, um so Kosten zu sparen.

Einen ähnlichen Trend sieht man auch schon seit Längerem in der Data Governance. Die Schwerpunktbereiche der Data Governance liegen in der Verbesserung von Verfügbarkeit, Usability, Konsistenz, Integrität und dem Schutz von Daten. “Die Datenverwaltung umfasst die Personen, Prozesse und Informationstechnologien, die erforderlich sind, um einen konsistenten und ordnungsgemäßen Umgang mit den Daten einer Organisation im gesamten Unternehmen zu erstellen.” (quelle). Es ist also im Sinne der Organisation, interne Daten und Datenquellen wiederzuverwenden. Die Gründe liegen auf der Hand:

• Nur bekannte Risiken können vermieden werden. Wenn bestimmte Datenzusammenhänge nicht geschaffen werden können, dann können Risiken auch schnell übersehen werden.
• Standardisierte und wiederverwendete Datenquellen erhöhen die Datenqualität und das Vertrauen in die Daten.
• Vertrauenswürdige Daten verbessern Entscheidungen, Prozesse und sind daher sehr wertvoll. Es können sogar neue Wertschöpfungsketten gebildet werden.

Rolle des API Managements in guter Data Governance

Die meisten großen Unternehmen haben, aus dem einfachen Grund heraus, dass sie historisch so gewachsen sind, in verschiedenen Abteilungen und Unternehmenseinheiten auch unterschiedliche IT Systeme. Ein einfaches Beispiel ist hier das CRM-System. Ob die Abteilungen sich einfach unterschiedliche Systeme angeschafft haben oder ob durch ein Merger ein anderes System der aufgekauften Firma hinzugekommen ist; Fakt ist, dass Entwicklerteams von Applikationen wie zum Beispiel ein Kundenportal, das auf alle unternehmensinternen Kundendaten zugreifen muss auch auf die APIs der verschiedenen Systeme zugreifen müssen.

Wir haben also mehrere Systeme, die gleiche Datentypen über ihre API anbieten. Hier Transparenz zu schaffen ist die Aufgabe eines Daten-Katalogs oder einer API-Library. Letzteres wird durch ein gutes API Management ermöglicht. Wenn APIs in einem zentralen API Management registriert sind, schafft dass die nötige Übersicht für Entwickler, die richtige API oder APIs zu finden. Je nach Fortschritt der API-Strategie werden hier System-APIs oder auch Domain-APIs gefunden, diese würden, um beim Beispiel Kundendaten zu bleiben, über eine API die Kundendaten mehrerer Systeme über nur einen Endpunkt zur Verwaltung anbieten.

Übersicht schaffen bei mehreren API-Management Systemen

Falls Sie auch meine anderen Artikel gelesen haben, oder sich auch gerade mit dem Thema beschäftigen, wissen Sie, dass es gut möglich ist, das Firmen mehr als nur ein API Management System verwenden. Die Frage ergibt sich also: Wie schaffe ich trotzdem eine zentrale Übersicht über alle APIs? Es gibt mehrere Möglichkeiten das zu erreichen.

1. APIs müssen alle zusätzlich im zentralen API Management registriert sein.

2. Es wird ein unabhängiges Tool verwendet, um APIs zu katalogisieren.

In Option 1 werden trotz Verwendung von weiteren API Management Systemen die APIs zusätzlich im zentralisierten, oder auch “common”, API Management registriert. Dies erhält die Zentralität der Steuerung von und Kontrolle über die APIs. Jedoch erhöht es auch die Latenz der Aufrufe minimal. In Fällen wie IoT Lösungen kann dies hinderlich sein.

Das “Common API Management” würde hier die Funktion der API-Library übernehmen können.

Abbildung 1: 2 API Management Systeme in Serie geschalten

Option 2 wäre die Verwendung eins anderen Systems, welche als API-Library fungiert. Mit einer einfachen Integrationslösung können die Daten der vorhandenen APIs aus dem API Management System, das meist auch per API, entnommen und in einem Tool der Wahl hinterlegt werden. APIs bieten in vielen Fällen Daten und Daten-Operationen an. Ein Daten-Katalog würde sich demnach gut für solche Zwecke anbieten.

Abbildung 2: API-Katalog für 2 API Management

Fazit

Es ist essenziell für Firmen einen Überblick über Daten und Datenquellen zu haben. Nur durch Transparenz kann der Wert der gesammelten Daten erst richtig zur Geltung kommen und sogar neue Geschäftsbereiche ermöglichen und die Firma vor Risiken schützen. API Management schafft einen Überblick über die vorhandenen APIs und macht es leichter API-Strategien zur Zentralisierung/Konsolidierung von Datenquellen zu etablieren. Auch wenn mehrere API Management Systeme verwendet werden, ist es wichtig, intern einen Katalog aufzubauen, der für die nötige Transparenz sorgt. Ob das das API Management selbst ist oder ob ein anderes Tool dafür verwendet wird ist hierbei nur Mittel zum Zweck.

Dieser Artikel ist Teil einer Serie zum Thema API Management in großen Unternehmen. Ziel ist es, meine Sicht auf verschiedene Themen zu teilen und die Komplexitäten aufzudecken. In diesem Artikel werde ich Fragestellungen behandeln, die mit der Provisionierung von API Management und APIs zu tun haben. Hierfür nehme ich mir Azure API Management als Beispiel.

Viele Möglichkeiten ein API Management zu provisionieren

Wenn man ein API Management aufsetzen möchte, hat man folgende Möglichkeiten das zu erreichen.

• Manuell über das Azure Portal
• Mit PowerShell
• Über die CLI
• Mit Hilfe vom Azure Ressource Manager (ARM)
• Terraform & Ähnlich
• u.v.m.

Welcher Weg jedoch derjenige ist, der für den Anwendungsfall am Sinnvollsten ist, hängt zu 100% davon ab wie das API Management in Zukunft verwendet werden soll. Hierzu empfehle ich auch Teil 4 von dieser Serie zu lesen. Um die Richtige Entscheidung zu treffen, sollte man sich zu den folgenden Anforderungen eine Antwort suchen:

• Wie wichtig ist ein schnelles Desaster-Recovery?
• Werden mehrere Teams das APIM nutzen?
• Gibt es ein Team, welches die Zuständigkeit inne hat?
• Brauchen Änderungen am APIM ein vorheriges Approval?
• Gibt es mehrere Umgebungen (dev, test, prod), die identisch konfiguriert sein müssen?

To IaC or not to IaC

IaC (Infrastructure as Code) ermöglicht, eine gesamte Infrastrukturarchitektur durch die Ausführung eines Skripts zu beschleunigen. Nicht nur können virtuelle Server bereitgestellt werden, sondern auch vorkonfigurierte Datenbanken, Netzwerkinfrastrukturen, Speichersysteme, Lastausgleiche und vieles mehr.

All das kann schnell und einfach für Entwicklungs-, Test- und Produktionsumgebungen konfiguriert werden, was den Softwareentwicklungsprozess wesentlich effizienter machen kann. Außerdem können problemlos Standardinfrastrukturumgebungen in anderen Projekten wiederverwendet werden.

Die Möglichkeit eine gesamte Infrastruktur durch Ausführung eines Skripts zu konfigurieren ist ein großer Vorteil für die, die ein gutes Desaster Recovery benötigen.

Für Hackathons und kleinere Hobby-projekte ist die Komplexität der Konfiguration und auch die organisatorische Hürde sehr gering. Das verleitet gerne dazu, die Cloud-infrastruktur manuell aufzusetzen. Das ist vielleicht für das eine Projekt auch ausreichend. Trotzdem empfehle ich auch hier die Verwendung von IaC. Der Grund dafür ist, dass die meisten Architekturen auf die ein oder andere Weise wiederverwendet werden. Ein Lösung, die im Hackathon entwickelt wurde findet häufig auch Anwendung in der Organisation.

Ich empfehle generell die Verwendung von Provisionierungs-Automatisierung. Für große Unternehmen ist der Nutzen nicht wegzudenken und mitigiert viele Risiken. Desasterf Recovery ist hier vielleicht das offensichtlichste Beispiel. Ein weiteres ist jedoch auch der Transfer von Wissen und Knowhow. Es wäre schlecht, wenn das Wissen über die Konfiguration der Infrastruktur zusammen mit dem Mitarbeiter die Firma verlässt.

Organisatorische Bedenken

Im vorangehenden Kapitel habe ich meine klare Empfehlung ausgesprochen IaC zu verwenden. In großen Firmen, die aus verschiedenen Gründen die einfachsten Sicherheitsanforderungen an die Infrastruktur generell haben, sind beim Einsatz von IaC jedoch einige Dinge zu beachten.

Viele Firmen haben mehrere IT-Entwicklungsprojekte und Teams. Die Frage ergibt sich also in wie weit diese Teams die gleichen Komponenten der Infrastruktur wiederverwenden dürfen, sollten oder können. Ein Team- und Projektübergreifendes API Management zum Beispiel stellt klare Fragen an die Sicherheit. Aber wie viel Kontrolle erhalten die einzelnen Teams auf das API Management? Wie verhindert man, dass Teams sich nicht gegenseitig Probleme bereiten?

Im Folgenden möchte ich 4 Möglichkeiten aufzeigen, die in 1000 Metern Höhe beschreiben, wie API Management in den verschiedenen Teams verwendet werden könnte.

Im ersten und einfachsten Fall verwendet jedes Entwicklungsteam sein eigenes API Management, welches durch das IaC-Tool der Wahl provisioniert wird. Es kann nur das zuständige Team die Konfiguration des API Managements ändern und ist somit auch zu 100% zuständig für die Prozesse die damit einhergehen. Ein Vorteil von dieser Struktur ist, dass Teams sehr unabhängig agieren können, was die Entwicklungsgeschwindigkeit erhöht.

Abbildung 1: Infrastruktur Entwicklungsprozess in unabhängigen Teams

Wenn sich die Organisation dazu entschieden hat, das API Management zu zentralisieren, um zum Beispiel zentrale Kontrolle über die Sicherheitsmaßnahmen und Zugriffssteuerung zu haben oder einfach im Budget einzusparen, dann stellt sich die Frage wie die Entwicklung und Provisionierung des API Managements dann vonstatten geht.

Hier gibt es mehrere Möglichkeiten.

• Man erlaubt den Teams, ähnlich einer open-source Lösung, an der gemeinsamen Konfiguration des API Managements mitzuwirken.
• Man erlaubt es ihnen, APIs in ein bestehendes APIM direkt zu provisionieren.
• Man erlaubt es nur indirekt über eine API die Provisionierung von APIs.

Welche dieser Möglichkeiten die richtige ist hängt von den Anforderungen ab und ist auch zum großen Teil Geschmacksache. Erlauben die Sicherheitsanforderungen es, dass Teams die Definition von APIs der jeweils anderen sehen dürfen? In welchem Ausmaß haben die Teams die Kontrolle über eigene APIs und dürfen von den Funktionalitäten des API Managements Gebrauch machen?

Möglichkeit 1 bedeutet, dass die gesamte Konfiguration vom API Management in, zum Beispiel, einem Git-repository liegt, auf das  die Teams Zugriff haben. Jedes Team würde im Laufe seiner Entwicklungsphasen Änderungen des API Management vorschlagen. Eine Änderung könnte beinhalten, eine weitere API hinzuzufügen oder zu entfernen, könnte aber auch beinhalten, dass bestimmte Protokolle oder Zertifikate verwendet werden müssen. Team A, welches dafür zuständig ist, das API Management und die APIs sauber und sicher zu halten, würde die vorgeschlagenen Änderungen kontrollieren und evaluieren ob die Änderungen auch andere APIs beeinflussen würden. Wenn die Änderung akzeptabel ist, würde die neue Version des Systems oder der Konfiguration angewandt werden.

Möglichkeit 2 entzieht den Teams das Recht, API Management-weite Änderungen zu unternehmen. Die Teams dürfen APIs anlegen, können jedoch nicht mehr konfigurieren, ob das gesamte API Management zum Beispiel isoliert in einem V-netz ist oder nicht. Diese Entscheidung bleibt Team A vorbehalten.

Möglichkeit 3 limitiert die Rechte der Teams weiter. Team A ist in voller Kontrolle des Systems und stellt eine API bereit, die es den Entwicklungsteams ermöglicht ihre API in dem System zu erstellen. Wie diese API aussieht und welche Kontrollmechanismen angewandt werden, um nur sichere APIs in dem System zu erlauben ist Team A überlassen.

Auch wenn diese Methode die höchsten Sicherheitsvorkehrungen erlaubt, ist das Team jedoch so weit eingeschränkt, dass dies einen starken Einfluss auf die Geschwindigkeit hat.

Fazit

Wie ein API Management oder die APIs provisioniert und verwaltet werden sollten hängt stark von den Anforderungen der Firma ab. Dieser Prozess sollte mit dem Zweck des API Managements übereinstimmen. Unterliegen die APIs besonderen Sicherheitsauflagen, die eine unternehmensweite Transparenz nicht erlaubt, dann empfehle ich ein zentralisiertes API Management, welches den Teams nur via einer kontrollierenden API erlaubt, APIs zu konfigurieren. Der Vorteil ist, dass so sichergestellt werden kann, dass APIs sicher sind und auch sicher sind vor unternehminternen Risiken.

Dies ist jedoch meist eine Extremsituation und trifft bei weitem nicht auf alle Firmen zu. Für die Unternehmen, die nicht diesen Auflagen unterliegen, empfehle ich Möglichkeit 1; die Verwendung von Konfigurations-Versionierung eines zentralen API Managements. Dies maximiert Kostenersparnis und gibt zentralisiert Kontrolle über die APIs. API-Strategien können so leichter verfolgt werden.

Wenn man sich gegen die Verwendung von einem zentralisierten API Managements entscheidet umso die Geschwindigkeit der Entwickler-Teams zu erhöhen stellen sich wiederum andere Fragen. Wie verschaffen wir trotzdem eine gute Transparenz innerhalb des Unternehmens, um die Wiederverwendung von bestehenden APIs zu fördern? Darauf werde ich später in dieser Serie auch noch eingehen.

Dieser Artikel ist Teil einer Serie zu API Management. Ziel der Serie ist es, meine Sicht darauf zu geben wie API Management im Enterprise-Kontext eingesetzt werden kann. Es werden also mit jedem Artikel Themen angesprochen, die eine Komplexität aufdeckt, mit der sich Unternehmen auseinandersetzen sollten. In diesem Teil, der vierte, gehe ich auf Sicherheitsaspekte ein.

Was ist „API-Sicherheit“

APIs sind, wie auch schon im Teil 2 der Serie erwähnt, wichtiger Teil einer Geschäftsstrategie in allen Branchen, und dieser Trend scheint nicht so schnell nachzulassen, insbesondere mit dem Aufstieg von IoT.

Die Zahl der öffentlichen APIs, die auf „ProgrammableWeb“ gelistet sind, liegt bei etwa 25.000, während die Zahl der privaten APIs um vieles höher ist als die Zahl der öffentlichen APIs. Diese Zahl wird auch weiter wachsen wie eine Studie von RapidAPI ergibt (Quelle: https://rapidapi.com/blog/rapidapi-developer-survey-insights/). Die gleiche Studie zeigt auch, dass die Zahl der APIs die in einer Firma verwendet werden mit der Größe des Unternehmens ansteigt.

Das sind eine Menge Daten, die über das Internet oder Netzwerk weitergeleitet werden, einige davon sind vertraulich.

Wie kann man also sicherstellen, dass die eigene Firma nicht auf die Liste der Unternehmen kommt, die von erfolgreichen Angriffen betroffen waren?

Viele Blickwinkel auf „Sicherheit“

Wenn man den Zugriff auf APIs sichern möchte, dann muss man sich nicht nur mit der Zugriffssteuerung beschäftigen, sondern auch mit der Sicherung der Umgebung, in der sich die API aufhält. Themen, die also betrachtet werden sollten, sind:

• Verbindungen direkt oder über das Internet
• IP white/black-listing
• Isolierung und Sichtbarkeit der Endpunkte
• Isolierung des Backends
• Verschlüsselung der Verbindung
• Zugriffssteuerung der Aufrufe
• Zugriffssteuerung auf das Developer-Portal
• Autorisierung der Aufrufer
• Authentifizierung der Aufrufer
• Ausfallsicherung und Load-Balancing
• Absicherung nach OWASP regeln
• DDoS Absicherung
• Etc.

Rolle des API Managements 

Sicherheit ist ein wesentliches Element jeder Anwendung, insbesondere im Hinblick auf APIs, die täglich von Hunderten oder Tausenden von Anwendungen aufgerufen werden. Möglicherweise beseitigt ein API-Management System zwar nicht alle Bedrohungen, aber es kann Sie gegen einige der häufigsten Bedrohungen schützen. Wenn es als Proxy verwendet wird, kann es bösartige Angriffe auf Systeme verhindern. Viele der Sicherheitsmaßnahmen müssen jedoch konfiguriert und auch schon beim Aufsetzen des API Management Systems implementiert werden.

Der erste und fundamentalste Weg durch den das API Management die API schützen kann, ist die Vergabe von Autorisierungs-Schlüsseln, auch „Subscription keys“ genannt. Dieser Schlüssel muss bei jedem Aufruf der API im Header vorhanden sein. Aufrufe, die diesen Schlüssel nicht besitzen, werden bereits vom API Management abgefangen. Es entsteht also keine unnötige Last auf Seiten des Backends.So wie Requests abgefangen werden, die nicht den richtigen Subscription-Key haben, können auch andere Merkmale über „Policies“ konfiguriert werden, die nicht akzeptiert sind. Diese könnten zum Beispiel sein: IP-Bereiche, Größe des Requests, bestimmte Inhalte, Häufigkeit der Requests innerhalb eines Zeitrahmens und viele mehr.

Auch die am häufigsten und auch die nicht so häufig verwendeten Autorisierungsmethoden können bereits im API Management System angewandt werden. OAUTH und Client Certificates sind die am häufigsten verwendeten. Im Folgenden ein Beispiel wie eine solche Konfiguration aussehen könnte. Dieser Policy-Ausschnitt überprüft das Client Certificate, ob es im System hinterlegt ist:

<choose>

<when condition="@(context.Request.Certificate == null || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >

<return-response>

<set-status code="403" reason="Invalid client certificate" />

</return-response>

</when>

</choose>

Policies geben dem/r API-Manager/in oder den Entwicklern die Möglichkeit, viele Aspekte der API zu konfigurieren, ohne dass ein Request erst zum Backend weitergeleitet werden muss. Das macht die API nicht nur performanter, sondern limitiert auch den Bereich, in dem neue Sicherheits-mechanismen angewandt werden müssen. So muss zum Beispiel nur im API Management das Zertifikat erneuert werden im Gegensatz zu jedem einzelnem Backend-Service.

Rolle der Systemumgebung & Architektur

Auch wenn die Zugriffssteuerung auf die API selbst essenziell ist, gibt es doch auch andere Risiken, die sich auf die Sicherheit und Verfügbarkeit einer API und das gesamte System auswirken. So könnte durch mögliche Infrastruktur-Probleme, Kriege, Naturkatastrophen und Vielem mehr das Rechenzentrum, in dem der Service oder das API Management laufen, ausfallen. Dies würde nicht direkt unbefugten Zugriff auf Daten erlauben, die unterbrochene Verfügbarkeit der Services könnte jedoch Auswirkungen auf die konsumierenden Systeme haben und somit auf den gesamten Wertschöpfungsprozess. Es ist demnach auch wichtig, die Systemverfügbarkeit sicherzustellen.

Dies kann ermöglicht werden indem kritische Systeme über mehrere Regionen hinweg verfügbar gemacht werden. Meist ist bei solchen Szenarien ein Loadbalancer gefragt um die Requests and den richtigen backend-service weiterzuleiten. API Management kann hier als einfacher Load-balancer fungieren. Eine weitere Möglichkeit, die den Service beinträchtigen kann, ist, wenn es mehr API-Aufrufe gibt als der Service bearbeiten kann. Das kann passieren, wenn der Service zu bestimmten Zeiten besonders häufig aufgerufen wird, oder wenn absichtlich jemand versucht, das System auf diese Weise lahm zu legen (Stichwort DDoS).

Um dieses Risiko zu minimieren, kann man vor einem API Management einen Service platzieren der Requests nach OWASP und Firewall Regeln prüft und auch automatisch DDoS Attacken erkennen und verhindern kann. Diese Services werden meist als Gateways bezeichnet. Im Azure gibt es für diese Funktion „Azure Front Door“ und auch das „Application Gateway“.

Logging, Analyse und Audit

Sicher zu sein ist gut, sicher zu bleiben ist jedoch auch eine Herausforderung. Anfragen sollten zurück verfolgbar sein, um nicht nur den staatlichen Regularien genüge zu leisten, sondern auch um eventuell mistrauen erweckende Verhalten von Konsumenten früh zu erkennen. Wenn ein Konsument zum Beispiel untypisch viele Daten über die API herunterlädt, dann könnte das ein Anzeichen dafür sein, dass dieser Schaden verursachen möchte.

API Management Systeme bieten meist eine umfassende Prüfungsmöglichkeit aller eingehenden Anfragen, jedoch nur für eine Teilmenge. Wenn ein vollständiges Audit oder verschiedene Rückverfolgungsdetails erforderlich sind, kann APIM so konfiguriert werden, dass diese Details an einen Logger weitergeleitet werden. Aus Performance-Gründen publiziert der Logger normalerweise an einen Event Hub. Es können Abonnenten des Event Hubs eingerichtet werden z.B: Azure Table Storage, Stream Analytics, PowerBI und Azure Machine Learning.

Fazit

Die Sicherheit von APIs ist nicht nur darauf beschränkt, ob ein Konsument der API ein Passwort braucht oder nicht. Es sollten alle Schichten des OSI Models in Betracht gezogen werden, wenn eine sicher API erstellt werden soll. Natürlich ist die Anforderung an die Sicherheit der API von Fall zu Fall unterschiedlich und meist wird der einfachste Weg gesucht, die API so gut wie möglich zu sichern. Hierbei sollte man sich ein API Management genau anschauen, da es mit Policies und Zugriffsbeschränkungen ein umfangreiches Tooling bereitstellt, um APIs zu sichern.

Dies ist der dritte Artikel über API Management in großen Unternehmen. Ziel der Reihe ist, Einblick in die vielen Aspekte und Themen zu gewähren, mit denen sich eine größere Firma mit besonderen Anforderungen auseinandersetzt. In diesem Artikel werde ich auf den Lebenszyklus von APIs eingehen.

Lebenszyklus von APIs

Häufig spricht man, wenn über den Lebenszyklus von APIs gesprochen wird, auch über den Prozess der API-Entwicklung. Beides ist sehr eng miteinander verknüpft. Generell spricht man meist von Aktivitäten, die in eine der vier Hauptphasen fallen: Entwickeln, Veröffentlichen, Verwalten und Entfernen. Jeder dieser Schritte kann beliebig tief detailliert werden.

Entwicklung beinhaltet Aspekte wie Technologie, Sicherheit, Provisionierung und Deployment-Automatisierung. Ebenfalls zu betrachten ist, und das wird häufig vernachlässigt, die Dokumentation der API oder auch das Testen im weiteren Sinne (eg: Mock, Load- und Penetration Test). Entwickler-, Design-, und Strategieleitfäden gehören hier ebenfalls dazu.

Veröffentlichen umfasst nicht allein die Aktion, eine API bereitzustellen. Hier könnte man auch in Betracht ziehen, eine API öffentlich oder intern zu monetarisieren, um eine neue Einkommensquelle für die Firma zu schaffen. In den meisten Fällen, wenn eine API wiederverwendbar zur Nutzung angeboten wird, ergibt sich das Problem wie die Kosten die Services gedeckt oder aufgeteilt werden sollen. Interne Monetarisierung, also die nutzungsbasierte Bezahlung, wäre hierfür eine saubere Lösung wenn die Dimensionen, wie Anzahl der APIs, Verursachte Last, Anzahl der Operationen, und viele mehr, dabei beachtet werden.

Analysieren der Verwendung von APIs ist ein wichtiger Teil des Lebenszyklus, der nicht zu unterschätzen ist. Mit Statistiken zu vielen verschiedenen Metriken, wie Latenzen, Peak-Zeiten, Requesthäufigkeit und ähnlichem können die Services optimiert, angepasst und Probleme schnell behoben werden.

Entfernen von APIs ist häufiger nötig als man denkt. Das liegt daran, dass sich die Services meist weiterentwickelt haben und die veraltete Version nicht mehr verwendet wird. Es ist daher angebracht, auch hierfür einen sauberen Prozess anzulegen, der möglichst automatisch angestoßen wird, um die API-Landschaft sauber zu halten (bspw. Einen Alarmsetzen, der Benachrichtigt, wenn APIs länger als drei Monate nicht verwendet werden).

Abbildung 1 - API Lebenszyklus

Weitere Aspekte der einzelnen Phasen

Entwicklung

1. Entwicklung: Sobald eine solide Strategie und einen solider Plan verfügbar ist, kann die API erstellt werden.

2. Testen: Vor der Veröffentlichung ist es wichtig, API-Tests abzuschließen, um sicherzustellen, dass sie die Leistungs-, Funktionalitäts- und Sicherheitserwartungen erfüllen.

3. Sicherung: Sicherheitsrisiken und -bedenken sind heute ein häufiges Problem. Auf technischer Ebene kann API Management Tooling behilflich sein. Jedoch auch auf Prozessebene muss die Sicherheit sichergestellt werden. Beispielsweise durch Verwendung von sauber implementierten Dev-Ops Prozessen.

Veröffentlichen

1. Veröffentlichen: Nach dem Testen ist es an der Zeit, die API zu veröffentlichen, um für Entwickler verfügbar zu werden. Das Developer Portal stellt diese dann zur Verfügung.

2. Vermarktung: Es gibt mehrere Möglichkeiten, Ihre API zu vermarkten, einschließlich der Auflistung in einem API-Marktplatz wie RapidAPI. Das Developer Portal kann als firmeneigenes Portal dienen.

3. Monetarisieren: Es besteht die Wahl APIs kostenlos intern oder extern anzubieten. Wenn es eine Gelegenheit dafür gibt, können APIs auch monetarisiert und so zusätzliche Einnahmen für das Unternehmen erzielt werden.

4. Onboarding: Wenn APIs für den öffentlichen oder privaten Verbrauch angeboten werden, ist Onboarding eine wichtige Komponente, damit Entwickler die wichtigsten Funktionen verstehen. Eine gute Dokumentation ist hierfür ausschlaggebend. Wie eine solche auszusehen hat sollte firmenweit definiert sein.

Verwalten

1. Verwalten: Nach der Veröffentlichung müssen Entwickler die APIs auch verwalten, um sicherzustellen, dass sie auf dem neuesten Stand sind und die Integrität Ihrer APIs nicht beeinträchtigt wird.

2. Analysieren: Ihre APIs sind live, aber wie funktionieren sie? API-Trafik Analyse hilft Ihnen, Ihr digitales Geschäft zu verstehen und Anomalien zu erfassen, bevor sie sich auf Ihr Unternehmen auswirken.

Ruhestand

1. Ruhestand: Der Ruhestand von APIs ist die letzte Phase eines API-Lebenszyklus und geschieht aus einer Vielzahl von Gründen, einschließlich Technologieänderungen und Sicherheitsbedenken.

Eine Strategie ist ausschlaggebend für ein erfolgreiches Lifecycle Management

Bereits im vorherigen Teil der Blog-Serie habe ich bekräftigt, dass APIs nicht nur als Mittel zum Zweck gesehen werden sollen, sondern auch in die Unternehmensstrategie einfließen können.

Wenn man den Lebenszyklus betrachtet sieht man, dass an vielen Stellen eine Unternehmensstrategie angeraten ist, um sicher und einheitlich APIs zu veröffentlichen und zu verwenden. Eine Strategie sollte demnach aus mehreren Blickwinkeln betrachtet werden. Entwicklungs-Vorschriften, Sicherheitsanforderungen, Kostenverteilungsplan, Minimum service lifetime Versprechen, und vieles mehr. Die Wiederverwendung von bestehenden APIs muss politisch motiviert werden, da sonst die Entstehung von Insellösungen nicht verhindert wird und „Digitale Schulden“ entstehen. Digitale Schulden sind Kosten, die an einem späteren Zeitpunkt anfallen, wenn Fehlentscheidungen und falsche Verwendung von Lösungen nachträglich korrigiert werden müssen.

Fazit

Der Lebenszyklus von APIs unterscheidet sich wenig vom Lebenszyklus anderer Lösungen. Es ist auf Grund ihrer Schnittstellenfunktion ungemein wichtig, diesen klar definiert zu haben. Eine API Strategie ist hier eine Voraussetzung dafür da viele Aspekte unternehmensweit relevant sind.