Lesezeit: 5 Minuten
DevOps? Warum APIOps der nächste logische Schritt ist
Die letzten beiden Artikel dieser Serie haben sich mit Team-Topologien und Teamschnitten sowie Kommunikationsmustern und kognitiver Last befasst. Jetzt wollen wir unser Blickfeld noch etwas weiten und uns mit dem Thema APIOps befassen. Im folgenden Artikel stellen wir diesen Begriff vor und erläutern, wie er sich in das Umfeld von DevOps einfügt. Außerdem lernen wir Tools kennen, die uns unterstützen.
APIs als Produkte
APIs genießen heute einen hohen Stellenwert, denn sie sind weit mehr als reine technische Schnittstellen (ursprünglich gedacht zur Ermöglichung einer Point-to-Point-Kommunikation) – sie bilden in ihrer Gesamtheit ein Ökosystem und Fundament für die Zusammenarbeit sowohl mit anderen internen Teams als auch mit Geschäftspartnern des Unternehmens (B2B).
APIs sind digitale Produkte, die auf einer Plattform oder Marktplatz angeboten und verschiedenen Konsumenten zur Verfügung gestellt werden. Eine API kann dabei von mehreren Konsumenten genutzt werden, im Extremfall ist dies sogar eine öffentlich angebotene API mit sehr vielen Endnutzern.
API-Lebenszyklus
Die Sichtweise von APIs als Produkten bringt mit sich, dass APIs einen eigenen Lebenszyklus haben, der getrennt vom Lebenszyklus des dahinterliegenden Services verwaltet wird. Der oft einhergehende API-first-Ansatz besagt, dass nicht nur Entwickler, sondern ein funktionsübergreifendes Team die APIs kollaborativ entwirft. APIs bilden fachlich geeignete Abstraktionen von der dahinter liegenden Service-Implementierung, und veröffentlichte APIs haben einen bindenden Vertragscharakter. Dementsprechend sind Änderungen an bestehenden APIs mit Vorsicht vorzunehmen („Operation am offenen Herzen“), damit deren aktive Basis an Konsumenten weiterhin die integrierten APIs ohne Einschränkungen oder Fehler nutzen kann – es gilt das Prinzip der sicheren Evolution: APIs sind geschlossen für Veränderungen an Bestehendem und offen für Erweiterungen (Open-Closed-Prinzip aus der Software-Architektur).
Einzug von DevOps-Praktiken = APIOps
Auch in dem Bereich rund um APIs finden zunehmend DevOps-Praktiken für das automatisierte Management des gesamten API-Lebenszyklus Anwendung. Wir fassen das unter dem Begriff APIOps zusammen – es handelt sich hierbei um eine Menge an (Entwicklungs-)Prozessen und Praktiken, um sowohl die Auslieferungsgeschwindigkeit als auch die Qualität der zur Verfügung gestellten APIs zu verbessern. Das Produktteam bekommt durch standardisierte, automatisierte Prozesse schneller Feedback zu ihren API-Produkten. Wir wollen schließlich mit Stolz am Ende des Tages sagen können: „So liefern wir APIs aus!“
Erspüren von Anpassungsbedarfen
Diese Systematik der Team-Topologien und ihrer Kommunikationsmodi ermöglicht eine gezielte Strukturierung der Inter-Team-Kommunikation im Hinblick auf das Gesetz von Conway zur Erreichung der gewünschten Systemarchitektur, die Angleichung der tatsächlichen kognitiven Last auf die Teamkapazität und den gleichermaßen effizienten wie effektiven Einsatz von Kommunikationsaufwänden. Das Definieren der Kommunikationsstruktur einer Organisation ist jedoch keine einmalige Aufgabe. Ändern sich Voraussetzungen, die einer gewählten Struktur zugrunde liegen, so muss auch die Struktur dem geänderten Bedarf angepasst werden - entweder temporär oder dauerhaft. Daher muss eine Organisation solche Anpassungsbedarfe aktiv erspüren und systematisch darauf reagieren.
Tooling rund um den OpenAPI-Standard
Das Fundament bildet eine Tool-Umgebung, die in der besten Art und Weise verwendet wird, um Entwicklungsteams unter die Arme zu greifen und zu unterstützen, die also so weit wie möglich in die bestehende CI/CD-Landschaft als Sammlung von Frühwarnsystemen integriert wird.
Pipelines und Automatisierung sind Multiplikatoren: je mehr Teams standardisierte Komponenten und Abläufe einsetzen (z. B. wiederverwendbare GitHub Actions), desto höher ist der Gesamtnutzen.
Die OpenAPI-Spezifikation hat sich als Standard etabliert.
Um diesen Standard herum gibt es ein breites, vielfältiges Angebot an Tools, zur Unterstützung der Automatisierung an den unterschiedlichen Phasen des API-Lebenszyklus:
Contract Testing – Testen und Verifikation von Interaktionen einzelner Consumer mit der API, beispielsweise mittels Pact. So lässt sich frühzeitig feststellen, welche Consumer von Änderungen an der API betroffen sind, und ob sie nach den Änderungen immer noch funktionieren werden. Dabei speichert ein Broker die Verträge und verbindet zwei unabhängig voneinander laufende Pipelines: eine auf Consumer-Seite, um die gewünschten Interaktionen festzuhalten, und die andere auf Provider-Seite, um das von den Consumern erwartete Verhalten tatsächlich gegen eine laufende Instanz des Services zu verifizieren.
Linter – Prüfung der OpenAPI-Spezifikationen auf syntaktische Korrektheit (gültiges YAML/JSON und OpenAPI-Format) sowie gegen einen bestehenden API-Styleguide (Governance), z. B. mittels Spectral, wo man sich aus einem bestehenden Fundus an Regeln bedienen, aber auch eigene Regeln definieren kann.
Einhaltung von Security-Regeln: Tools wie 42Crunch oder die „OWASP Top Ten“-Regelsätze in Spectral ermöglichen es uns, den Entwicklern der API frühzeitiges Feedback zu geben, ob etwaige Security-Regeln verletzt werden. Dieser „Shift-Left“-Ansatz spart potenziell sehr viel Frust und Wartungsaufwände, denn Security-Änderungen gehen aus unserer Erfahrung meist einher mit Breaking Changes.
Diff von OpenAPI-Spezifikationen (Vergleich der geänderten Version gegen die vorherige) bei jeder Codeänderung bzw. jedem Merge Request mit automatisierter Prüfung auf rückwärts-kompatible Änderungen. So wird die sichere Evolution von APIs gewährleistet, und man spart sich Wartungskosten, die durch den Parallelbetrieb zweier Versionen der API anfallen würden.
Beispiel-Anfragen und Interaktionen helfen beim Testen von APIs und können beispielsweise in einer Postman-Collection festgehalten werden.
Auf Basis einer OpenAPI-Spezifikation können durch Tools wie Prism bereits Mock-Server bzw. eine Sandbox-Umgebung bereitgestellt werden.
Viele API-Gateways unterstützen durch Admin- und Self-Service-Endpunkte automatisiert ausgelöste Transitionen im API-Lebenszyklus, z. B. das Veröffentlichen von APIs oder Deprecation und Parallelbetrieb.
Fazit und Ausblick
Nachdem wir nun kennengelernt haben, welche Anforderungen an DevOps-Praktiken im Bereich von APIs bestehen und wie diese mit der richtigen Toolunterstützung umgesetzt werden können, wollen wir uns im nächsten und abschließenden Blog-Artikel dieser Serie einem praktischen Beispiel widmen, das die vorgestellten Themen vereint.
