Was wir durch Virtualisierung über Skalierung lernen können

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Als sich die Virtualisierung zunehmend durchsetzte, wurden verschiedene Kennzahlen zur Erfolgsmessung vorgeschlagen. Zu den am häufigsten verwendeten Kennzahlen für die Messung und Bewertung des Erfolgs von Virtualisierungsprojekten gehörten Konsolidierungsquoten, das Verhältnis von Administratoren zu virtuellen Maschinen, die Bereitstellungsdauer und der Anteil virtualisierter Server.

Heute erleben wir, wie DevOps zunehmend an Bedeutung gewinnt und ähnliche Kennzahlen zur Messung seines Erfolgs vorgeschlagen werden. Markteinführungszeit, mittlere Wiederherstellungszeit, Vorlaufzeit für Änderungen und Bereitstellungshäufigkeit gehören zu den gängigeren Messgrößen, die diskutiert werden, wenn wir uns auf das „M“ in der CAMS-Definition (Kultur, Automatisierung, Messung, Austausch) von DevOps konzentrieren.

Diese Kennzahlen sind sinnvoll und notwendig, doch DevOps bietet einen weiteren Vorteil – einen Anwendungsfall, wenn man so will –, der nur selten thematisiert wird, aber ebenso entscheidend ist: die betriebliche Skalierbarkeit.

Es ist dasselbe Problem, das SDN durch Operationalisierung „im Netzwerk“ zu lösen versucht: Mithilfe von Technologie sollen Teams so skaliert werden können, dass sie mit dem vom Unternehmen angestrebten und tatsächlich verzeichneten Wachstum Schritt halten – einem Wachstum, das durch die rasante Verbreitung mobiler Anwendungen und Webanwendungen ermöglicht wird. Es handelt sich um ein klassisches „30/30/3“-Problem: Das Datenwachstum treibt die IT-Kosten für Übertragung, Verarbeitung und Speicherung in die Höhe, während der Umsatz nur minimal steigt. Um dieses Problem zu lösen, müssen wir uns auf den Teil der Gleichung konzentrieren, den wir beeinflussen können: die steigenden 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. Allen liegt dieselbe Prämisse zugrunde: Eine schnelle operative Skalierung ist für das Wachstum entscheidend.

Es geht nicht nur um Hardware- und Softwareressourcen, sondern auch darum, wie wir diese Ressourcen bereitstellen und verwalten. Ziel ist es, den Aufwand für die Verwaltung der Hardware- und Softwareressourcen zu reduzieren, die für die Bereitstellung und Auslieferung einer Anwendung erforderlich sind.

Hier kommt das „A“ für „Automatisierung“ ins Spiel: Es trägt dazu bei, die IT-Kosten zu senken, die Wachstumsgleichung zu verändern und die Skalierung zu ermöglichen, die für ein stärkeres Unternehmenswachstum erforderlich ist.

Doch wir dürfen Automatisierung nicht nur oberflächlich betrachten. Die Automatisierung (mithilfe von Skripten und Orchestrierung zur Steuerung der Bereitstellung und Verwaltung sowie der betrieblichen Prozesse, die für die Bereitstellung von Diensten und Anwendungen erforderlich sind) ist zwar wichtig, doch sollten wir nicht vergessen, welch entscheidende Rolle „Infrastructure as Code“ spielt.

Das können wir zum Teil erreichen, indem wir einen Blick zurück auf den Erfolg der Virtualisierung bei der Skalierung der Verwaltung von Rechenressourcen werfen – ein Erfolg, der zu einem nicht unerheblichen Teil darauf beruht, dass diese Infrastruktur „als Code“ behandelt wurde.

Ich weiß, ich weiß, es war nicht wirklich Code in dem Sinne, dass es sich weder um ein Skript noch um eine Konfigurationsdatei oder irgendetwas handelte, das wie „Code“ aussah. Aber es wurde insofern „wie Code“ behandelt, als wir zentrale Repositorys mit „Golden Images“ verwendeten, über die sich Server schnell bereitstellen und konfigurieren ließen: Webserver, Anwendungsserver, Datenserver. Verschiedene Servertypen wurden durch ein vordefiniertes „Image“ standardisiert, das es den Betreibern ermöglichte, zu skalieren.

Und wenn ich von Skalierung spreche, dann meine ich SKALIERUNG. Auch wenn viele Zahlen im Umlauf sind, war es bereits 2011 keine Seltenheit, Organisationen mit einem Verhältnis von einem Administrator zu 350 virtuellen Servern zu finden. Einige gaben sogar Verhältnisse von 1:500 bis 1:1000 an, während andere, schlicht durch die Größe ihrer Organisation eingeschränkt, lediglich auf 1:100 oder 1:150 kamen. Ein Bericht aus dem Jahr 2012, in dem Daten aus mehreren IT-Benchmark-Berichten analysiert wurden, bezifferte das Verhältnis von Administratoren zu Servern bei physischen Servern auf 1:50–75 und bei virtuellen Servern auf 1:185–450.

Was die Skalierbarkeit angeht, ist das beeindruckend. So wird Wachstum ermöglicht, ohne dass die IT-Kosten wie sonst üblich entsprechend steigen.

Bedenken Sie nun, dass das mediane Verhältnis von IT-Fachkräften zu Geräten bei Unternehmen aller Größenordnungen etwa 1:36 beträgt. Das ist an und für sich interessant, finden Sie nicht? Dieses Verhältnis scheint sich mit dem Wachstum eines Unternehmens nicht zu verändern. Das ist eher ungünstig und verschärft lediglich das 30/30/3-Problem.

Wenn wir das jedoch irgendwie ändern und die Anzahl der Geräte pro Techniker auch nur verdoppeln könnten, 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, sondern durch die Nutzung der Konzepte, die ein unglaubliches Verhältnis von Administratoren zu Servern ermöglicht haben: Infrastructure as Code und Automatisierung.

Der Grund, warum wir nicht einfach Golden Images von Switches und Load Balancern sowie den mehr als 20 weiteren L4-7-Anwendungsdiensten erstellen können, die Unternehmen bekanntermaßen zur Bereitstellung und Absicherung ihrer Anwendungen einsetzen, liegt darin, dass jede Konfiguration einzigartig ist. Sie ist anwendungszentriert, und das bedeutet: Sie können zwar durchaus auf Software (virtuell) setzen und ein Golden Base Image für jeden dieser Dienste bereitstellen, benötigen aber dennoch jemanden, der die Konfiguration übernimmt. Und diese Konfiguration ist alles andere als einfach.

Möchten Sie einige App-Dienste für Exchange konfigurieren? Dafür müssen über 80 verschiedene Objekte erstellt, konfiguriert und korrekt miteinander verknüpft werden, um die erforderliche Verfügbarkeit, Leistung und Sicherheit zu gewährleisten.

Hier entstehen zweifellos der Zeitaufwand (und die damit verbundenen Kosten) „im Netzwerk“.

Genau hier müssen wir skalieren. Hier müssen wir Infrastruktur „wie Code“ behandeln.

Aus diesem Grund gehört die Verwendung von Vorlagen zur DevOps-Komponente „A“ für Automatisierung. Denn Vorlagen ermöglichen es dem Netzwerkbetrieb (und auch dem Sicherheitsbetrieb), gängige Konfigurationen „als Code“ zu behandeln, der in einem zentralen Repository verwaltet werden kann. Die Vorlage wird zum „Golden Image“, auf dessen Grundlage Anwendungsdienste bereitgestellt und konfiguriert werden. Dieser Ansatz ermöglicht eine Automatisierung und Orchestrierung nach dem Vorbild der Bereitstellung virtueller Maschinen und schafft die Grundlage für die betriebliche Skalierbarkeit, die Unternehmen benötigen, um ihr Wachstum zu fördern.

Bei DevOps, SDN, SDDC und selbst der Cloud geht es nicht nur darum, die Markteinführungszeit zu verkürzen oder die Betriebskosten zu senken. Sie sind auch entscheidend für eine effiziente Skalierung, die das Unternehmenswachstum ermöglicht, statt es zu behindern. Die Kosten für immer mehr Administratoren oder Techniker, die die wachsenden Ressourcen im gesamten Rechenzentrum (Rechenleistung, Netzwerk, Sicherheit, Speicher) verwalten, werden das durch diese Skalierung erzielte Wachstum aufzehren. Eine effizientere Skalierung durch Automatisierung und die Behandlung der Infrastruktur als Code kann eine Möglichkeit sein, die erforderliche Skalierung zu bewältigen und so das vom Unternehmen angestrebte Wachstum zu unterstützen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie