APIs sind die neuen CLIs. Aber wenn es darum geht, welche Art von API Sie erstellen, ist deklarativer Ansatz das Maß aller Dinge.
Eine API (eine Anwendungsprogrammierschnittstelle) ist heutzutage eine entscheidende Funktion. Organisationen setzen sie auf der Geschäftsebene ein, um die Partnerintegration und Innovation durch sogenannte „Citizen Developer“ zu fördern. Anwendungen verfügen über sie, um die Integration zu erleichtern und die Geschäftslogik – die sich häufig ändern kann – von Schnittstellen – die sich nicht so häufig ändern sollten – zu entkoppeln. Und die Infrastruktur hat sie. Von Switches bis zu Routern, von Anwendungsdiensten bis zu Middleware und Datenbanken wird die Infrastruktur, die die Liefer- und Bereitstellungspipelines umfasst, mit APIs ermöglicht.
Das allein sollte ein Grund sein, innezuhalten und darüber nachzudenken, was das für die aufstrebende NetOps-Community bedeutet. Denn während Unternehmen dazu neigen, einige wenige Schlüsselkomponenten der Anwendungsinfrastruktur zu standardisieren, ist es unwahrscheinlich, dass sie nur einige wenige Schlüsselkomponenten der Netzwerk- und Anwendungsdienste-Infrastruktur standardisieren.
Von den durchschnittlich sechzehn verschiedenen Anwendungsdiensten, die Unternehmen nutzen, um ihre Apps schneller und sicherer zu machen, werden sie mit Sicherheit von mehr als einer Handvoll Infrastrukturkomponenten bereitgestellt. 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“ oft etwas zu wörtlich genommen haben. Das heißt, die API ist lediglich eine REST-fähige Widerspiegelung der CLI.
Jeder, der schon einmal mit CLIs für verschiedene Infrastrukturkomponenten gearbeitet hat, weiß, dass die CLI-Navigation sehr eng mit dem Objektmodell der Infrastruktur verknüpft ist. APIs schaffen es oft nicht, mehr zu tun, als dieses Design auf HTTP zu übertragen. Das bedeutet, dass diejenigen, die die Vorteile der API nutzen möchten, notwendigerweise auch das Objektmodell des betreffenden Geräts erlernen müssen.
Diese Abstraktionsebene behindert den Fortschritt der Automatisierung und Orchestrierung, da wir jetzt nicht nur Automatisierungstalente finden müssen, sondern Automatisierungstalente mit einem gewissen Maß an Fachwissen in fünf oder mehr verschiedenen Netzwerkinfrastrukturmodellen. Das erforderliche Fachwissen erfordert oft auch Fachkenntnisse, die von grundlegenden Kenntnissen der VLAN-Konfiguration und des VLAN-Routings bis hin zu den Beziehungen zwischen virtuellen Servern, virtuellen IP-Adressen, Knoten, Mitgliedern und Pools reichen.
Die Offenlegung der zugrunde liegenden Komplexität der Infrastruktur wirkt sich nachteilig auf die Förderung der Einführung und Ermöglichung der Automatisierung aus. Der Zweck von Schnittstellen sollte darin bestehen, Modelle und Logik zu abstrahieren, um Benutzer und Betreiber vor der Komplexität zu schützen. Die GUI macht dies möglich, indem sie die Notwendigkeit beseitigt, durch Objekthierarchien zu navigieren, um einen einfachen Dienst zu konfigurieren.
Deshalb ist es oft frustrierend, wenn man feststellt, dass die API diesen Navigationsalptraum wieder eingeführt hat.
Dieses Problem ist nicht nur auf Netzwerk- und Anwendungsinfrastrukturen beschränkt. So stellte MuleSoft in seiner Studie „ Der steigende Wert von APIs “ fest, dass die größte Nachfrage (47 % der Befragten) seitens Kunden und Partnern nach API-Integration „angepasste APIs sind, die einem bestimmten Geschäftsbedarf entsprechen“. Dahinter folgten bessere Dokumentation (19 %), Integrationsvorlagen „ohne Code“ (19 %) und SDK-Wrapper für APIs, die sie benötigen und verwenden (13 %).
All dies lässt sich als Plädoyer für eine Vereinfachung zusammenfassen. Und in der Technologie bedeutet Vereinfachung Abstraktion.
Und das bringt uns zum Punkt dieses Beitrags, nämlich dass deklarative Schnittstellen diese Abstraktion darstellen. Durch die Vereinfachung der Schnittstellen, die heute zum Bereitstellen, Konfigurieren, Verwalten und Integrieren von Infrastrukturen verwendet werden, demokratisieren deklarative Schnittstellen die Infrastruktur und eröffnen Möglichkeiten.
Generell können sowohl deklarative als auch imperativische APIs als API-Typen betrachtet werden. Wenn jemand API sagt, denkt man an imperative APIs. Sie sagen dem Zielsystem genau, wie es etwas tun soll. Wenn Sie einen virtuellen Server hinzufügen möchten, müssen Sie ihm genau sagen, wie das zu tun ist – selbst wenn dazu fünf, zehn oder mehr separate API-Aufrufe erforderlich sind.
Das bedeutet, dass Sie ihm sagen, dass es ein bestimmtes Objekt mit den entsprechenden Attributen erstellen soll, beispielsweise einen Knoten mit einer IP-Adresse. Anschließend müssen Sie dem System separat mitteilen, dass es den Pool, dem es zugewiesen wird, mit einem Namen erstellen soll. Dann müssen Sie … also, Sie verstehen jetzt, was ich meine. Imperative APIs belasten den Benutzer nicht nur mit dem System und seinem Objektmodell, sondern auch mit den Schritten, die zum Erreichen der beabsichtigten Ergebnisse erforderlich sind.
Das ist die API-Steuer, die Sie mit Imperative zahlen.
Nun sind imperative APIs insgesamt keine schlechte Sache. Sie sind sehr wichtig, wenn Sie eine GUI erstellen oder in andere Systeme integrieren, die die Granularität benötigen, die Sie mit einer imperativen API erhalten. Wir brauchen auch imperative APIs, allerdings nicht für NetOps und DevOps, die sich mit Automatisierung und Integration befassen.
Aber für den Rest von uns ist es nicht notwendig, so viele Details zu kennen. Und tatsächlich kann die Anforderung eines derart tiefgreifenden Wissens abschreckend wirken und die Automatisierungs- und Orchestrierungsbemühungen verlangsamen. Es eignet sich sicherlich nicht dazu, die Infrastruktur zu demokratisieren und Self-Service-Modelle für DevOps und Entwickler zu ermöglichen, geschweige denn für NetOps außerhalb des spezifischen Infrastrukturbereichs.
Hier kommen deklarative APIs ins Spiel.
Deklarative Schnittstellen geben an, was Sie tun möchten, und überlassen die Logik und den Arbeitsablauf der Entscheidung des Systems. Anstatt dem System also konkret zu sagen, dass es einen Knoten und einen Pool erstellen und die gesamte richtige Logik für die erforderlichen Objekte ausführen soll, beschreiben Sie sie und ihre Beziehungen stattdessen.
Einige deklarative Schnittstellen verwenden JSON, andere XML und einige greifen sogar immer noch auf einfache Formulardaten zurück. Allen ist gemeinsam, dass sie davon ausgehen, dass die Daten die Objekte auf einfache und unkomplizierte Weise beschreiben, die nur ein sehr geringes Verständnis von Objektmodellen und Systemhierarchien erfordert.
Beispielsweise ist diese Deklaration für Menschen ziemlich gut lesbar. Es wird ein grundlegendes Verständnis des Objektmodells vorausgesetzt, allerdings nicht so sehr, dass zum Verfassen der Deklaration eine Zertifizierung für ein bestimmtes Produkt erforderlich wäre:
"web_pool": { "Klasse": "Pool", "Monitore": [ "http" ], "Mitglieder": [ { "ServicePort": 80, "Serveradressen": [ "192.0.1.10", "192.0.1.11" ] } ] }
Hier zeigt sich der Wert deklarativer Schnittstellen: bei der Reduzierung des Domänenwissens und der Komplexität bei der Bereitstellung und Konfiguration der Infrastruktur. Durch die Reduzierung des erforderlichen Fachwissens können NetOps nicht nur schneller und effizienter arbeiten, sondern auch DevOps und Entwickler ermutigen, diese Möglichkeit zu nutzen.
Durch die Einführung deklarativer Schnittstellen als Standardmethode zur Verwaltung der Infrastruktur wird der Pool an Talenten, auf die Sie zurückgreifen können, um Self-Service- und erweiterte Automatisierungsfunktionen bereitzustellen, sofort erweitert. Die obige deklarative Schnittstelle bedarf nur sehr weniger Erklärungen, damit DevOps und Entwickler sie verstehen und verwenden können. Andererseits würde eine imperative Schnittstelle wesentlich mehr Aufmerksamkeit für das Erlernen des infrastrukturspezifischen Modells und der Arbeitsabläufe erfordern, bevor Ergebnisse erwartet werden könnten.
Deklarative Schnittstellen demokratisieren die Infrastruktur, indem sie die Bereitstellung, Konfiguration und Verwaltung vereinfachen, die zur Automatisierung von Bereitstellungspipelines und zur Integration von Systemen in andere Infrastrukturdienste erforderlich sind. Und die Demokratisierung der Infrastruktur bedeutet eine schnellere, intelligentere Automatisierung und die Fähigkeit, die Zusammenarbeit und Kooperation über alle Betriebsbereiche hinweg zu fördern, die erforderlich ist, um die Vorteile der NetOps- und DevOps-Bewegungen zu nutzen.