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.
In operativer Hinsicht verursacht die API-Steuer Kosten in Form von Ressourcen und Zeitaufwand durch übermäßige API-Aufrufe. Sogar etwas konzeptionell so Einfaches wie ein Lastenausgleichsdienst erfordert die Erstellung, Konfiguration und Aktivierung mehrerer Objekte. Überwachung, Pools, Algorithmen, IP-Adressen und Netzwerkattribute müssen alle konfiguriert werden, und für jedes dieser Objekte sind hierzu mehrere Schritte (API-Aufrufe) erforderlich. Wenn man sie alle zusammenzählt, sind selbst für einen einfachen Lastausgleichsdienst mehrere API-Aufrufe erforderlich, um starten zu können. Anrufe, deren Ausführung Zeit in Anspruch nimmt. Anrufe, die Netzwerkressourcen verbrauchen.
Diese API-Aufrufe werden von Architekten und Ingenieuren verwendet, die Skripte schreiben (mit Python, PowerShell usw.), um diese allgemeinen Bereitstellungsaufgaben zu automatisieren. Dies führt zu unvermeidlichen technischen Schulden. Um die Aufgabe überhaupt zu ändern, muss der Code geändert (denn Skripte sind Code, ob wir das nun zugeben möchten oder nicht) und getestet werden, was Zeit und Ressourcen kostet, die sich unter dem Strich zu echten Kosten summieren.
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 Orchestrierungsbereich beobachtet haben (und dazu gehören auch SDx-Player wie VMware, Cisco und OpenStack), werden Sie feststellen, dass der Einsatz von Vorlagen immer mehr im Vordergrund steht. Vorlagen ähneln stark Konfigurationsdateien, da sie eine ganze Menge an Informationen kodieren, die zum Erstellen und Konfigurieren von etwas erforderlich sind. Wenn Sie beispielsweise eine einzelne Vorlage erstellen können, die die Bereitstellung dieses Lastausgleichsdienstes umfasst, können Sie die erforderlichen API-Aufrufe scheinbar auf nur einen reduzieren – nämlich einen zum Übertragen der Vorlage auf die Ressource, auf der dieser Dienst gespeichert wird.
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.