Workflows versus APIs

Heute habe ich eine Aufgabe für Sie. Ich möchte, dass Sie – ja, genau da sind Sie – einen Scheck bei der Bank einzahlen. Sie müssen ins Auto steigen, zur Bank fahren, hineingehen, den Vorgang mit dem Kassierer erledigen und dann wieder nach Hause fahren.

Gereizt? Das sollten Sie auch sein, insbesondere wenn Sie dazu einfach Ihre Mobile-Banking-App nutzen könnten, ohne dass Sie dazu viele zusätzliche Schritte unternehmen müssen.

Und das, meine Freunde, ist der Unterschied zwischen einem Workflow (einem Prozess) und einer API.

Es gibt etwas ganz Reales (ich habe den Namen erfunden, aber nicht die Existenz), das API-Steuer genannt wird. Dabei handelt es sich um den Zeit- und technischen Aufwand, der durch die Ausführung komplexer Prozesse mithilfe einzelner API-Aufrufe entsteht. Es ist, als würden Sie persönlich zur Bank gehen, anstatt die Einzahlung über die mobile App vorzunehmen.

Diese Steuer steigt mit der Ausweitung der Prozesse. Wenn Sie einen langwierigen Prozess haben, der zehn oder zwanzig verschiedene API-Aufrufe erfordert, wird der Code (auch Skripte sind Code) zunehmend komplizierter, was sich auf die Fehlerbehebung auswirkt und zukünftige Änderungen erschwert. Die Verknöcherung von Prozessen durch einzelne API-Aufrufe ist das Gegenteil von Agilität. Es ist die Fragilität, die die Möglichkeit zur Verbesserung der Effizienz durch Optimierung zunichte macht.

Workflows sind grundsätzlich vordefinierte Prozesse für häufig ausgeführte Aufgaben. Die meisten Geschäftsprozesse (und sogar Betriebsabläufe) fallen in diese Kategorie. Mit diesen Befehlen melden Sie sich an, navigieren zum richtigen Teil des Systems, ändern die Zugriffskontrolle am Port und bestätigen die Änderung. Jedes Mal, wenn Sie diese Aufgabe ausführen, ist es dasselbe. Es handelt sich dabei um einen häufig ausgeführten Prozess, der leicht kodifiziert werden könnte. Im Betrieb gibt es viele solcher Prozesse und indem wir sie in einem Workflow zusammenfassen, können wir nicht nur die API-Steuer eliminieren, sondern auch die Qualität und Nachhaltigkeit der Skripte verbessern, die sie aufrufen.

Denn die Verwendung von Workflows anstelle von APIs bedeutet weniger komplexen Code, der einfacher zu verwalten und zu ändern ist. Sie sind beweglicher und weniger zerbrechlich.

Betrachten Sie dieses völlig erfundene Beispiel. Im ersten Fall verwenden Sie einen API-basierten Ansatz. Jeder einzelne Schritt in diesem Prozess stellt einen API-Aufruf dar. Das bedeutet, dass ein Skript mit fast zwanzig verschiedenen Aufrufen im Laufe der Zeit entwickelt, getestet und gepflegt werden muss. Das ist technische Schuld. Es ist an die API-Version des Systems gebunden, mit dem es zum Zeitpunkt der Erstellung funktioniert. Wenn sich einer dieser Aufrufe ändert, muss auch das Skript geändert werden.

Auf der rechten Seite sehen Sie einen workflowbasierten Ansatz. Sie können den Prozess weiterhin über einen API-Aufruf initiieren (was in vielen Organisationen wahrscheinlich vorzuziehen ist), aber die eigentlichen Schritte des Prozesses werden basierend auf den Parametern (Variablen) ausgeführt, die mit dem ersten Aufruf gesendet wurden. Möglicherweise müssen Sie bereinigen und festschreiben, aber Sie haben den erforderlichen Code dennoch auf zwei oder weniger Interaktionen reduziert.

Das heißt nicht, dass die Verwendung von APIs und Vorlagen eine schlechte Sache ist. Das ist es nicht. Doch gerade in der Netzwerkwelt ist es häufig so, dass die Nutzung von APIs systemspezifisches Wissen und Kenntnisse über Netzwerke im Allgemeinen erfordert. Das erschwert DevOps oder Entwicklern die Arbeit mit den APIs. Bei einem Workflow-Ansatz wird kein Wissen oder Fachwissen vorausgesetzt, sodass DevOps diese problemlos verwenden können und NetOps ihre Arbeitsplatzsicherheit behält.  

In Umgebungen, in denen die Automatisierung um sich greift (und vielleicht sogar die Oberhand gewinnt), kann ein workflow-basierter Ansatz eine wesentliche Entlastung für NetOps bieten, indem er DevOps die Möglichkeit gibt, Aufgaben aufzurufen, ohne dass dafür eine Menge domänenspezifisches Wissen erforderlich ist.

Und hey, sie können auch diese lästigen API-Steuern vermeiden. Und wer vermeidet nicht gerne Steuern?