API steht für Application Programming Interface. Im Laufe der Jahre hat es sich von einer eng gekoppelten imperativen Spezifikation zu einem lose gekoppelten deklarativen Modell entwickelt. Die heute am häufigsten verwendeten APIs sind RESTful und werden zur Ermöglichung der Integration verwendet. Unabhängig von der Implementierung und der Aufrufart werden APIs häufig mit der App-Entwicklung in Verbindung gebracht.
Doch eine andere API-Wirtschaft expandiert stetig. Es liegt im operativen Geschäft. Und in diesem Bereich steht das „A“ in API für Automatisierung.
Im operativen Bereich stellen APIs die Möglichkeit dar, die Einbindung, Konfiguration und den Betrieb von Infrastruktur- und Application zu automatisieren. Daher müssen sich die zur Unterstützung des Betriebs erforderlichen Schnittstellen (APIs) auf die Vereinfachung der Automatisierung konzentrieren.
Dieser Schwerpunkt ist wichtig, da Unternehmen vollständig in die zweite Phase der digitale Transformation eintreten und beginnen, die Automatisierung über die Bereitstellungs- und Implementierungspipelines hinweg auszuweiten. Um die Automatisierung zu skalieren, ist die Fähigkeit erforderlich, konsistente, wiederholbare und vorhersehbare Prozesse zu entwickeln, die die Bereitstellungspipeline für eine App verkörpern.
Aus einem Bericht von Kentik zum Stand der Automatisierung im Jahr 2019 geht hervor, dass mehr als die Hälfte der Organisationen (53 %) bereits Automatisierung für die Netzwerkkonfiguration nutzten und weitere 40 % die Richtlinienverwaltung automatisierten. Unsere eigenen Untersuchungen zeigen, dass der Prozentsatz viel höher ist – eine überwältigende Mehrheit von 86 %, die das Netzwerk automatisiert. Die gleiche Studie, „State of Application Services 2020“, hat auch eine zunehmende Konsistenz des Automatisierungsgrads in der gesamten Bereitstellungspipeline festgestellt.
Auch die von Organisationen verwendeten Tools verändern sich. Obwohl Python immer noch eine der beliebtesten Optionen ist, sehen wir den Einfluss von DevOps und Cloud-native-Apps auf die IT. Die Bereitstellungspipeline wird zunehmend von Tools wie Jenkins und Ansible gesteuert und von Repositories wie GitHub und GitLab Enterprise ausgelöst. Mit Blick auf die Zukunft werden Infrastruktur- und App-Dienste auf umsetzbaren Erkenntnissen basieren, die durch erweiterte Analysen gewonnen werden.
Es sind Systeme und nicht Menschen, die APIs in der Bereitstellungspipeline aufrufen. Daher ist es zwingend erforderlich, betriebliche APIs speziell im Hinblick auf die Automatisierung zu entwickeln. Das erfordert mehrere Überlegungen.
Zunächst muss möglicherweise das System berücksichtigt werden, von dem aus eine betriebliche API aufgerufen werden könnte. Die von Jenkins oder einem Repository verfügbaren Daten unterscheiden sich zweifellos deutlich von den Daten, die von herkömmlichen Tools und Diensten zur Netzwerkautomatisierung stammen. Das kann bedeuten, dass die Daten woanders bezogen werden oder, soweit möglich, standardmäßig auf standardisierte Werte zurückgegriffen wird.
Zweitens ist es von entscheidender Bedeutung, dass wir uns mit der Notwendigkeit des Aufrufs von APIs durch „anmeldepflichtige Maschinen“ und des Aufrufs durch „anmeldepflichtige Benutzer“ befassen. Die meisten unserer heutigen Authentifizierungssysteme gehen davon aus, dass es sich bei dem „Benutzer“ um einen Menschen handelt. API-Schlüssel können eine gute Option sein, erfordern jedoch einige Kenntnisse im IT-Betrieb, um ein System bereitzustellen, zu betreiben und zu verwalten, das nur für die Speicherung maschinengebundener Anmeldeinformationen konzipiert ist. Dennoch ist dies von entscheidender Bedeutung, da wir uns auf die dritte und letzte Phase der digitale Transformation zubewegen, in der KI-gestützte Application und Betriebsabläufe einen größeren Teil der Betriebslasten tragen werden.
Es ist großartig, dass wir heute Tools zum Erstellen von Skripten verwenden können, mit denen sich Vorgänge automatisieren lassen. Es ist jedoch wichtig zu erkennen, dass sich das A in API in Zukunft fast ausschließlich auf die Automatisierung beziehen wird – zumindest im Betriebskontext –, da es sich auf Interaktionen und Aufrufe zwischen Maschinen statt zwischen Menschen auswirken wird.