APIs sind die neue CLI. Doch wenn es darum geht, welche Art von API Sie entwickeln, ist der deklarative Ansatz das Maß aller Dinge.
Eine API – eine Anwendungsprogrammierschnittstelle – ist heutzutage eine unverzichtbare Funktion. Unternehmen setzen APIs auf der Geschäftsebene ein, um die Integration von Partnern und Innovationen durch sogenannte „Citizen Developer“ zu fördern. Anwendungen verfügen über APIs, um die Integration zu vereinfachen und die Geschäftslogik – die sich häufig ändern kann – von Schnittstellen zu entkoppeln, die sich nicht so häufig ändern sollten. Auch die Infrastruktur verfügt über APIs. Von Switches und Routern über Anwendungsdienste bis hin zu Middleware und Datenbanken: Die Infrastruktur, aus der die Bereitstellungs- und Deployment-Pipelines bestehen, wird durch APIs unterstützt.
Das allein sollte Anlass sein, innezuhalten und darüber nachzudenken, was dies für die aufstrebende NetOps-Community bedeutet. Denn während Unternehmen dazu neigen, sich bei der Anwendungsinfrastruktur auf einige wenige zentrale Komponenten zu standardisieren, ist dies bei den Infrastrukturkomponenten für Netzwerk- und Anwendungsdienste weniger wahrscheinlich.
Von den durchschnittlich sechzehn verschiedenen Anwendungsdiensten, die Unternehmen nutzen, um ihre Anwendungen schneller und sicherer zu machen, werden mit Sicherheit mehr als nur eine Handvoll Infrastrukturkomponenten bereitgestellt. Selbst wenn wir großzügig von einem Verhältnis von drei Anwendungsdiensten pro Komponente ausgehen, sind das immer noch fünf verschiedene Geräte – mit fünf verschiedenen APIs.
Das Problem dabei ist, dass Infrastrukturanbieter die Aussage „Die API ist die neue CLI“ häufig etwas zu wörtlich genommen haben. Das heißt, die API ist lediglich ein REST-fähiges Abbild der CLI.
Jeder, der schon mit CLIs verschiedener Infrastrukturkomponenten gearbeitet hat, weiß, dass die Navigation in der CLI sehr eng an das Objektmodell der Infrastruktur angelehnt ist. APIs beschränken sich häufig darauf, dieses Design unverändert auf HTTP zu übertragen. Das bedeutet, dass diejenigen, die die API nutzen möchten, zwangsläufig auch das Objektmodell des betreffenden Geräts erlernen müssen.
Diese Abstraktionsebene behindert den Fortschritt bei Automatisierung und Orchestrierung, da wir nun nicht nur Fachkräfte für Automatisierung finden müssen, sondern solche, die zudem über ein gewisses Maß an Erfahrung mit fünf oder mehr verschiedenen Modellen für Netzwerkinfrastrukturen verfügen. Das erforderliche Fachwissen setzt häufig auch Domänenkenntnisse voraus – von einem grundlegenden Verständnis der VLAN-Konfiguration und des Routings bis hin zu den Beziehungen zwischen virtuellen Servern, virtuellen IP-Adressen, Knoten, Mitgliedern und Pools.
Die zugrunde liegende Komplexität der Infrastruktur offenzulegen, erschwert die Akzeptanz und die Automatisierung. Schnittstellen sollten dazu dienen, Modelle und Logik zu abstrahieren, um Benutzer und Betreiber vor dieser Komplexität zu schützen. Die grafische Benutzeroberfläche erfüllt diesen Zweck, indem sie es überflüssig macht, zur Konfiguration eines einfachen Dienstes durch Objekthierarchien zu navigieren.
Umso frustrierender ist es oft, festzustellen, dass die API diesen Navigationsalbtraum wieder eingeführt hat.
Dieses Problem ist nicht auf die Netzwerk- und Anwendungsinfrastruktur beschränkt. So stellte MuleSoft in seiner Studie „Der steigende Wert von APIs“ fest, dass die größte Nachfrage – von 47 % der Befragten – seitens Kunden und Partnern bei der API-Integration „maßgeschneiderten APIs, die einen bestimmten Geschäftsbedarf erfüllen“, galt. Dahinter folgten eine bessere Dokumentation (19 %), Integrationsvorlagen ohne Programmieraufwand (19 %) und SDK-Wrapper für benötigte und verwendete APIs (13 %).
All dies lässt sich als Plädoyer für Vereinfachung zusammenfassen. Und in der Technologie bedeutet Vereinfachung Abstraktion.
Und damit kommen wir zum Kern dieses Beitrags: Deklarative Schnittstellen sind genau diese Abstraktion. Indem sie die heute für die Bereitstellung, Konfiguration, Verwaltung und Integration von Infrastruktur verwendeten Schnittstellen vereinfachen, demokratisieren deklarative Schnittstellen die Infrastruktur und eröffnen neue Möglichkeiten.
Deklarativ versus imperativ
Im Allgemeinen können sowohl deklarative als auch imperative Ansätze als Arten von APIs betrachtet werden. Imperative APIs sind das, woran man üblicherweise denkt, wenn von einer API die Rede ist. Sie geben dem Zielsystem genau vor, wie etwas auszuführen ist. Wenn Sie einen virtuellen Server hinzufügen möchten, teilen Sie dem System also exakt mit, wie dies zu tun ist – selbst wenn dafür fünf, zehn oder noch mehr separate API-Aufrufe erforderlich sind.
Das bedeutet, dass man das System anweisen muss, ein bestimmtes Objekt mit den entsprechenden Attributen zu erstellen, beispielsweise einen Knoten mit einer IP-Adresse. Anschließend muss man das System separat anweisen, den Pool, dem der Knoten zugewiesen werden soll, unter Angabe eines Namens zu erstellen. Danach muss man … nun, Sie verstehen sicher, worauf es hinausläuft. Imperative APIs verlangen von ihren Nutzern nicht nur, das System und sein Objektmodell zu verstehen, sondern auch die Schritte zu kennen, die erforderlich sind, um die gewünschten Ergebnisse zu erzielen.
Das ist der API-Preis, den man für den imperativen Ansatz zahlt.
Nun sind imperative APIs grundsätzlich nichts Schlechtes. Sie sind sehr wichtig, wenn Sie eine grafische Benutzeroberfläche entwickeln oder andere Systeme integrieren, die die Detailgenauigkeit einer imperativen API benötigen. Auch imperative APIs sind notwendig – nur nicht für die Automatisierung und Integration im NetOps- und DevOps-Bereich.
Aber wir anderen müssen nicht über derart detaillierte Kenntnisse verfügen. Tatsächlich kann die Anforderung eines solchen Wissens abschreckend wirken und Automatisierungs- und Orchestrierungsinitiativen ausbremsen. Sie trägt ganz sicher nicht dazu bei, den Zugang zur Infrastruktur zu demokratisieren und Self-Service-Modelle für DevOps und Entwickler zu ermöglichen – ganz zu schweigen von NetOps außerhalb des jeweiligen Infrastrukturbereichs.
Hier kommen deklarative APIs ins Spiel.
Deklarative Schnittstellen geben an, was Sie tun möchten, und überlassen es dem System, die Logik und den Arbeitsablauf zu bestimmen. Anstatt das System also ausdrücklich anzuweisen, einen Knoten und einen Pool zu erstellen und die erforderlichen Objekte entsprechend zu verarbeiten, beschreiben Sie diese und ihre Beziehungen zueinander.
Einige deklarative Schnittstellen verwenden JSON, andere XML, und manche greifen sogar noch auf einfache Formulardaten zurück. Ihnen allen ist gemeinsam, dass sie davon ausgehen, dass die Daten die Objekte auf einfache, unkomplizierte Weise beschreiben, sodass nur sehr wenig Verständnis von Objektmodellen und Systemhierarchien erforderlich ist.
Diese Deklaration ist beispielsweise recht gut lesbar. Sie setzt ein grundlegendes Verständnis von Objektmodellen voraus, jedoch nicht so viel, dass zum Verfassen der Deklaration eine Zertifizierung für ein bestimmtes Produkt erforderlich wäre:
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
Hier zeigt sich der Nutzen deklarativer Schnittstellen: Sie reduzieren das erforderliche Fachwissen und vereinfachen die Bereitstellung und Konfiguration der Infrastruktur. Da weniger Spezialkenntnisse erforderlich sind, kann NetOps nicht nur schneller und effizienter arbeiten, sondern nun auch DevOps und Entwickler dazu ermutigen, diese Funktion zu nutzen.
Die Einführung deklarativer Schnittstellen als Standardmethode für die Verwaltung von Infrastruktur erweitert unmittelbar den Kreis der Fachkräfte, auf die Sie bei der Bereitstellung von Self-Service- und fortschrittlichen Automatisierungsfunktionen zurückgreifen können. Die oben beschriebene deklarative Schnittstelle bedarf kaum einer Erklärung, damit DevOps-Teams und Entwickler sie verstehen und nutzen können. Eine imperative Schnittstelle hingegen würde eine wesentlich intensivere Einarbeitung in das infrastrukturspezifische Modell und die entsprechenden Arbeitsabläufe erfordern, bevor Ergebnisse zu erwarten wären.
Deklarative Schnittstellen demokratisieren die Infrastruktur, indem sie die Bereitstellung, Konfiguration und Verwaltung vereinfachen, die zur Automatisierung von Bereitstellungspipelines und zur Integration von Systemen mit anderen Infrastrukturdiensten erforderlich sind. Die Demokratisierung der Infrastruktur wiederum ermöglicht eine schnellere, intelligentere Automatisierung und fördert die Zusammenarbeit und Kooperation über Betriebsbereiche hinweg, die notwendig sind, um von den NetOps- und DevOps-Ansätzen zu profitieren.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.