So vermeiden Sie dieses Jahr die Zahlung von API-Steuern
In den USA ist es Steuerzeit und Sie wissen, was das bedeutet, nicht wahr? Ja, wir alle suchen nach Möglichkeiten, diese Belastung zu verringern.
Es tut mir leid, sagen zu müssen, dass ich, obwohl ich früher als Entwickler für ein Unternehmen für Steuersoftware gearbeitet habe, nicht wirklich qualifiziert bin, Ihnen diesbezüglich Ratschläge zu geben. Wenn Sie jedoch Ratschläge suchen, wie Sie dieses (oder nächstes) Jahr die Zahlung von API-Steuern vermeiden können, sind Sie auf der richtigen Seite im Internet gelandet.
Eine API-Steuer ist der Mehraufwand, den Sie zahlen, wenn Sie APIs verwenden, um die Bereitstellung und Konfiguration der Infrastruktur als Teil des Bereitstellungsprozesses zu automatisieren. Die API-Steuer ist (wie alle Steuern) nicht einfach zu berechnen, da sie eigentlich zwei Aspekte hat: einen operativen und einen technischen.
Operativ verursachen API-Aufrufe Kosten durch Ressourcenverbrauch und Zeit, die durch zu viele Anfragen entstehen. Schon ein so konzeptionell einfaches Beispiel wie ein Lastausgleichsdienst verlangt das Anlegen, Einrichten und Aktivieren mehrerer Objekte. Sie müssen Überwachung, Pools, Algorithmen, IP-Adressen und Netzwerkattribute konfigurieren, und jedes dieser Objekte erfordert mehrere Schritte (API-Aufrufe). Addiert man das alles, braucht selbst ein einfacher Lastausgleichsdienst mehrere API-Aufrufe, um startklar zu sein. Aufrufe, deren Ausführung Zeit kostet. Aufrufe, die Netzwerkressourcen binden.
Architekten und Ingenieure nutzen diese API-Aufrufe, um Skripte zu schreiben (mit Python, PowerShell usw.) und häufige Bereitstellungsaufgaben zu automatisieren. Dadurch entsteht unvermeidbare technische Schuld. Wenn Sie die Aufgabe ändern, müssen Sie den Code anpassen (denn Skripte sind Code, ob wir das akzeptieren oder nicht) und testen, wofür Zeit und Ressourcen anfallen, die sich letztlich in spürbaren Kosten niederschlagen.
Diese Kosten – für die Entwicklung, Prüfung und Wartung der Systeme und Skripte – sind die technischen Steuern auf die Nutzung dieser API. Das bedeutet, dass die Skripte langfristige Kosten in Form von technischen Schulden verursachen, die sich auf die Kosten beziehen, die mit der Wartung des Codes verbunden sind, der für die Automatisierung über diese APIs erforderlich ist, und auf die Kosten, nicht nur die Automatisierung, sondern möglicherweise auch die Infrastruktur zu ändern.
Aus all dem ergibt sich eine beachtliche Rechnung, die sich wie bei „echten“ Steuern praktisch nicht vermeiden lässt. Wenn Sie die Vorteile eines flüssigeren und automatisierten Bereitstellungsprozesses nutzen möchten, müssen Sie die Infrastruktur einbeziehen. Das bedeutet alles, was sich zwischen dem Benutzer und der App befindet und sicherstellt, dass beide nahtlos und sicher kommunizieren können.
Okay, nachdem das gesagt ist, habe ich versprochen, Ihnen zu erklären, wie Sie die Zahlung dieser Steuern vermeiden können, also los geht’s.
Wenn Sie den Bereich der Orchestrierung beobachten (dazu zählen auch SDx-Anbieter wie VMware, Cisco und OpenStack), stellen Sie fest, dass die Nutzung von Vorlagen immer wichtiger wird. Vorlagen ähneln Konfigurationsdateien, denn sie fassen viele Informationen zusammen, die nötig sind, um etwas zu erstellen und zu konfigurieren. Erstellen Sie etwa eine Vorlage, die die Bereitstellung eines Lastausgleichsdienstes umfasst, können Sie die API-Aufrufe auf einen einzigen beschränken – den, mit dem Sie die Vorlage an die Stelle übertragen, auf der der Dienst läuft.
Die Verwendung nur eines API-Aufrufs statt vieler vereinfacht die Automatisierung und ermöglicht Ihnen die Wiederverwendung des Skripts oder Systems, das die Vorlage pusht. Das ist wichtig, denn wenn Sie APIs verwenden, müssen Sie Skripte schreiben, die nicht nur spezifisch für den Dienst, sondern auch spezifisch für die bereitgestellte Anwendung sind. Das würde bedeuten, dass Sie für jede bereitgestellte App ein weiteres Skript schreiben müssten, um die Bereitstellung der benötigten Dienste, wie z. B. die Lastverteilung, zu automatisieren.
Wenn Sie stattdessen Vorlagen verwenden, können Sie dasselbe Skript verwenden und einfach eine andere Vorlage pushen. Das bedeutet weniger Wartezeit für das Warten auf ein neues Skript für jede App und weniger Fehler, die gesucht werden müssen, wie etwa als Bob zum fünfzehnten Mal kopierte und einfügte und vergaß, Zeile 33 zu ändern.
Vorlagen sind Infrastruktur als Code, der heilige Gral von DevOps.
Sie benötigen zwar weiterhin APIs, müssen diese jedoch nicht für alles verwenden. Und wenn Sie dies durch die Verwendung von Vorlagen vermeiden können, können Sie die Zahlung der damit verbundenen Steuern vermeiden und diese Ersparnisse woanders hin übertragen.