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.
Es geht nicht nur um Hardware- und Software-Ressourcen; wichtig ist auch, wie wir diese Ressourcen bereitstellen und verwalten. Sie müssen den Aufwand für die Verwaltung der Ressourcen – Hardware und Software –, die für die Bereitstellung und Ausführung einer Anwendung notwendig sind, deutlich reduzieren.
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.
Wir schauen dafür auch zurück und erkennen, wie die Virtualisierung die Skalierung der Verwaltung von Rechenressourcen maßgeblich erleichtert hat – nicht zuletzt, weil wir diese Infrastruktur „als Code“ behandeln.
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.
DevOps, SDN, SDDC und auch Cloud zielen nicht nur darauf ab, die Markteinführungszeit zu verkürzen oder die Betriebskosten zu senken. Sie sind entscheidend für eine effiziente Skalierung, die Ihr Geschäftswachstum unterstützt statt bremst. Die steigenden Kosten für zusätzliche Operatoren oder Ingenieure, die die wachsenden Ressourcen im gesamten Rechenzentrum (Rechenleistung, Netzwerk, Sicherheit, Speicher) verwalten, könnten das Wachstum zunichtemachen, das diese Skalierung ermöglicht. Mit intelligenter Automatisierung und indem Sie Infrastruktur als Code behandeln, können Sie die nötige Skalierung effizient stolperfrei steuern, um die gewünschte Entwicklung Ihres Unternehmens zu tragen.