Was wir durch Virtualisierung über Skalierung lernen können
Als die Virtualisierung begann, sich durchzusetzen, wurden verschiedene Maßstäbe zur Erfolgsmessung vorgeschlagen. Konsolidierungsverhältnisse, das Verhältnis von Administratoren zu virtuelle Maschine , Bereitstellungszeit und der Prozentsatz virtualisierter Server gehörten zu den am häufigsten verwendeten Parametern zur Messung und Bewertung des Erfolgs von Virtualisierungsprojekten.
Heute beobachten wir, wie DevOps seinen aufsteigenden Stern beginnt und ähnliche Messgrößen zur Messung seines Erfolgs vorgeschlagen werden. Markteinführungszeit, durchschnittliche Wiederherstellungszeit, Vorlaufzeit für Änderungen und Bereitstellungshäufigkeit gehören zu den am häufigsten genannten Messwerten, wenn wir uns auf das „M“ in der CAMS-Definition (Culture, Automation, Measurement, Sharing) von DevOps konzentrieren.
Diese sind gut und notwendig, aber es gibt einen Vorteil – einen Anwendungsfall, wenn Sie so wollen – von DevOps, der selten diskutiert wird, der aber genauso wichtig ist: die betriebliche Skalierbarkeit.
Es handelt sich um dasselbe Problem, das SDN „im Netzwerk“ durch Operationalisierung zu lösen versucht: Es ermöglicht die Skalierung von Teams durch Technologie, um sie an die gewünschte Wachstumsrate anzupassen, die das Unternehmen dank des schnellen Wachstums von Mobil- und Web- Applications bereits erlebt. Es handelt sich um ein klassisches „30/30/3“-Problem, das dadurch entsteht, dass das Datenwachstum die IT-Kosten (für Transport, Verarbeitung und Speicherung) in die Höhe treibt, während die Einnahmen nur minimal steigen. Um dieses Problem zu lösen, müssen wir uns auf den Teil der Gleichung konzentrieren, über den wir Kontrolle haben: höhere IT-Kosten. Wenn Sie es also SDN nennen möchten, nur zu. Wenn Sie es DevOps für das Netzwerk nennen möchten, nur zu. Wenn Sie es SDDC nennen möchten, warum nicht. Nennen Sie es auch Cloud, wenn Ihnen das lieber ist. Ihnen allen liegt eine gemeinsame Prämisse zugrunde: Eine schnelle operative Skalierung ist für das Wachstum von entscheidender Bedeutung.
Dabei geht es nicht nur um Hardware- und Softwareressourcen, sondern auch darum, wie wir diese Ressourcen bereitstellen und verwalten. Der Aufwand für die Verwaltung der Ressourcen (Hardware und Software), die für die Implementierung und Bereitstellung einer Application erforderlich sind, muss reduziert werden.
Hier kommt das „A“ für „Automatisierung“ ins Spiel, denn es senkt die IT-Kosten, die nötig sind, um die Wachstumsgleichung zu ändern und die Skalierung so zu gestalten, dass sie ein stärkeres Geschäftswachstum unterstützt.
Aber wir brauchen nicht nur eine oberflächliche Betrachtung der Automatisierung. Zwar ist die Automatisierung (mithilfe von Skripts und Orchestrierung zur Bereitstellung und Verwaltung sowie der für die Implementierung von Diensten und Apps erforderlichen Betriebsvorgänge) wichtig, doch dürfen wir die entscheidende Rolle von „Infrastruktur als Code“ nicht vergessen.
Dies gelingt uns unter anderem, indem wir mithilfe der Wayback Machine einen Blick auf den Erfolg der Virtualisierung bei der Skalierung der Verwaltung von Rechenressourcen werfen, der (nicht zuletzt) darauf zurückzuführen ist, dass diese Infrastruktur „als Code“ behandelt wird.
Ich weiß, ich weiß, es war nicht wirklich Code in dem Sinne, dass es kein Skript oder eine Konfigurationsdatei oder irgendetwas war, das wie „Code“ aussah. Es wurde jedoch in dem Sinne „als Code“ behandelt, dass wir zentralisierte Repositories mit „Golden Images“ verwendeten, von denen aus wir Server schnell bereitstellen und konfigurieren konnten. Webserver, App-Server, Datenserver. Verschiedene Arten von Servern wurden durch ein vordefiniertes „Image“ idealisiert, das den Betreibern eine Skalierung ermöglichte.
Und wenn ich Maßstab sage, dann meine ich Maßstab. Obwohl viele Zahlen im Umlauf sind, war es bereits 2011 nicht ungewöhnlich, in Unternehmen ein Verhältnis von 1:350 zwischen Administratoren und virtueller Server zu finden. Einige behaupteten, dass das Verhältnis 1:500 bis 1:1000 oder mehr betragen würde, während andere aufgrund der Größe ihrer Organisation nur 1:100 oder 1:150 erreichen konnten. In einem Bericht aus dem Jahr 2012, in dem Daten aus mehreren IT-Benchmark-Berichten analysiert wurden, wurde ein Verhältnis von Administratoren zu Servern von 1 festgestellt: 50–75 für physische Server und 1:185–450 für virtuelle Server.
Das ist vom Ausmaß her erstaunlich. Dies ermöglicht Wachstum ohne die normalerweise damit verbundenen höheren IT-Kosten.
Bedenken Sie nun, dass das durchschnittliche Verhältnis von Ingenieuren zu Geräten in Unternehmen aller Größen bei etwa 1:36 liegt. Das ist an sich schon interessant, finden Sie nicht? Das Verhältnis scheint sich mit dem Wachstum des Unternehmens nicht zu ändern. Das ist irgendwie eine schlechte Sache und trägt nur zum 30/30/3-Problem bei.
Aber wenn wir das irgendwie ändern könnten, und sei es nur durch die Verdoppelung der Geräte pro Techniker, würden wir die Wachstumskosten senken und eine bessere Skalierung des gesamten Netzwerks ermöglichen. Dazu müssen wir den Erfolg der Virtualisierung nachahmen. Nicht unbedingt durch den Einsatz von Virtualisierung, aber durch die Verwendung der Konzepte, die die Unterstützung eines unglaublichen Verhältnisses von Administratoren zu Servern ermöglichten: Infrastruktur als Code und Automatisierung.
Der Grund, warum wir nicht einfach Golden Images von Switches und Load Balancern und den über 20 anderen L4-7-App-Diensten erstellen können, die Unternehmen unseres Wissens zum Bereitstellen und Sichern ihrer Applications einsetzen, liegt darin, dass jede Konfiguration einzigartig ist. Sie ist App-zentriert, und das bedeutet, dass Sie zwar auf Software (virtuell) zurückgreifen und ein Golden Base Image für jeden dieser Dienste bereitstellen können, Sie aber trotzdem jemanden brauchen, der die Konfiguration durchführt. Und es ist keine einfache Konfiguration.
Einige App-Dienste für Exchange konfigurieren? Um die erforderliche Verfügbarkeit, Leistung und Sicherheit zu erreichen, müssen über 80 verschiedene Objekte erstellt, konfiguriert und korrekt verknüpft werden.
Hier entsteht sicherlich Zeit (und die damit verbundenen Kosten) „im Netzwerk“.
Und genau dort müssen wir skalieren. Wo wir Infrastruktur „als Code“ behandeln müssen.
Aus diesem Grund ist die Templating-Funktion in der Komponente „A“ für Automatisierung von DevOps enthalten. Denn durch die Erstellung von Templates können Netz- (und auch Sicherheits-)Ops allgemeine Konfigurationen „als Code“ behandeln, der in einem zentralen Repository verwaltet werden kann. Die Vorlage wird zum „Golden Image“, von dem aus App-Dienste bereitgestellt und konfiguriert werden. Dieser Ansatz ermöglicht eine Automatisierung und Orchestrierung, die der Bereitstellung virtueller Maschinen ähnelt, und bietet die Grundlage für die betriebliche Skalierbarkeit, die Organisationen für Geschäftswachstum benötigen.
Bei DevOps, SDN, SDDC und sogar der Cloud geht es nicht nur darum, die Markteinführungszeit zu verkürzen oder die Betriebskosten zu senken. Sie sind außerdem der Schlüssel zu einer effizienten Skalierung, die Unternehmenswachstum ermöglicht statt behindert. Die Kosten für die Einstellung immer weiterer Bediener oder Ingenieure zur Verwaltung der zunehmenden Ressourcen im gesamten Rechenzentrum (Rechner, Netzwerk, Sicherheit, Speicher) werden das Wachstum, das sich aus dieser Größenordnung ergibt, auffressen. Eine Möglichkeit, den für das gewünschte Unternehmenswachstum erforderlichen Umfang zu erreichen, besteht darin, mithilfe der Automatisierung effizienter zu skalieren und die Infrastruktur als Code zu behandeln.