Die überraschende Wahrheit über die digitale Transformation: Skalennachteile

Dies ist der vierte Blog einer Reihe über die Herausforderungen, die sich aus der digitalen Transformation ergeben.

• Die überraschende Wahrheit über die digitale Transformation
• Die überraschende Wahrheit über die digitale Transformation: Wolkenchaos
• Die überraschende Wahrheit über die digitale Transformation: Sicherheitsüberspringen

Skalennachteile.

Wenn Sie ein Unternehmen vergrößern, insbesondere im Laufe der Zeit, häufen sich häufig Ballaststücke an, die Sie sich um nichts kümmern müssen. Sie verringern selten die Anzahl der Anwendungen, die Sie unterstützen müssen. Normalerweise steigt dieser Wert, manchmal sogar exponentiell innerhalb weniger Jahre. In normalen Zeiten verdoppelt sich die Zahl der Anträge alle vier Jahre. Wenn eine neue Technologie Einzug hält, erhöht sich diese Zahl.

Jede App erfordert mehr Unterstützung im Betrieb (für Uneingeweihte: Netzwerk, Rechenleistung, Speicher und Sicherheit). Aber wir wissen, dass man mit der vertikalen Skalierung nur bis zu einem gewissen Punkt kommt (die Menge an Hardware, die man zur Problemlösung einsetzen kann, ist begrenzt), und wir wissen auch, dass das Gleiche für Humanressourcen gilt. Wir können nicht einfach immer mehr Operationen hinzufügen, um mit dem Wachstum der Apps Schritt zu halten. Dadurch erhöht sich der Verwaltungsaufwand und die Kommunikation wird verlangsamt, da wir kaum herausfinden können, wer für was verantwortlich ist, ganz zu schweigen davon, überhaupt mit der betreffenden Person zu sprechen.

Das zeigt uns das Gesetz der abnehmenden Bereitstellungen. Irgendwann kommt der Punkt, an dem die Anzahl der Operationen den Einsatz tatsächlich behindert und wir sehen, wie Kompromisse beginnen. Wie Faust beim Pakt mit dem Teufel entscheiden wir uns für Geschwindigkeit statt Sicherheit und für Größe statt Stabilität. Irgendwann kommen wir an einen Wendepunkt, an dem wir theoretisch am Ende unserer Möglichkeiten angelangt sind und die Entwicklungs- und Betriebsabteilung sowie das Unternehmen beginnen, anderswo nach Lösungen zu suchen.

Kurz gesagt : Sie können nur eine begrenzte Anzahl an Mitarbeitern einstellen, um die steigende Anzahl an Apps zu bewältigen, bevor Sie mit dem Gesetz der abnehmenden Bereitstellungen in Konflikt geraten . 

Deshalb ist die Automatisierung für den Betrieb von entscheidender Bedeutung, um mit der Zunahme der Anwendungen und der Forderung nach einer schnelleren Bereitstellung Schritt zu halten. Denn egal, wie schnell Sie tippen, die Berechnung erfolgt schneller.

Bedenken Sie jedoch, dass Automatisierung mehr ist als nur Skripting.

Wir verwenden bereits eine Menge Skripting und das hat sicherlich dazu beigetragen, dass wir bei den Bereitstellungen zumindest im Rennen bleiben. Damit die Automatisierung wirklich erfolgreich ist, sollte sie nicht auf Geräte- oder Anwendungsbasis ausgeführt werden. Das sollte es einfach nicht. Das ist nicht skalierbar. Wenn Sie pro Gerät oder App ein Skript schreiben, führen Sie die Automatisierung nicht richtig durch.

Bei der Automatisierung muss es um den Prozess gehen (es geht also eigentlich um Orchestrierung, aber das ist ein Windmühlentyp, gegen den ich immer wieder ankämpfe, der aber einfach nicht umfallen will) und um die konsequente Ausführung. Das bedeutet, dass Sie Automatisierung einführen müssen – nicht nur Skriptänderungen. Und das bedeutet einen neuen Ansatz, der Prinzipien von DevOps wie Infrastruktur als Code beinhaltet.

Infrastruktur als Code

Infrastruktur als Code ist ein Gleichnis. Das bedeutet, dass die eigentliche Infrastruktur aus Software, Hardware, Cloud oder vor Ort bestehen kann. Die Implementierung ist für Bereitstellungszwecke irrelevant, da wir APIs und Bereitstellungsartefakte verwenden, um das Verhalten der Infrastruktur als Code zu erreichen. Indem wir die Konfiguration vom Gerät entkoppeln, können wir das Gerät behandeln, als wäre es eine Blackbox.

Wichtig sind die Bereitstellungsartefakte – die Vorlagen, Skripts und Richtlinien, die zum Bereitstellen und Konfigurieren des Geräts für den gewünschten Dienst verwendet werden. Diese werden in einem Repository (ON-PREMISES) gespeichert. Diese beschreiben einen bestimmten Dienst vollständig – sei es Netzwerk, Sicherheit, Speicher oder App-Infrastruktur – und können verwendet werden, um den Dienst nach Belieben neu zu erstellen. Diese Artefakte können zum Automatisieren einzelner Aufgaben verwendet werden (zum Beispiel zum Hinzufügen einer Firewall-Regel, zum Bereitstellen eines Load Balancers oder zum Konfigurieren der WAF). Anschließend können sie in einem orchestrierten Prozess kombiniert werden, um eine kontinuierliche Bereitstellung zu erreichen.

Der Grund, warum dies für die Behebung der Unökonomie des Maßstabs wichtig ist, liegt darin, dass reines Scripting immer noch eine gerätespezifische Aufgabe ist. Mit einem Skript wird aus einer fünfminütigen Aufgabe eine fünf Sekunden dauernde. Der Vorgang wird jedoch immer noch manuell gestartet und erfordert die Mithilfe von Personen. Es geht nicht auf das größere Bedürfnis ein, den gesamten *Prozess* zu automatisieren – und das ist es, was Sie brauchen, um die Skaleneffekte zu erzielen, die erforderlich sind, um in einer digitalen Wirtschaft wettbewerbsfähig zu sein. 

Seien Sie gespannt auf den letzten Beitrag dieser Reihe, in dem wir näher darauf eingehen, wie Sie die steigende Zahl in Containerumgebungen eingesetzter Apps sicher bereitstellen können.