Wie Container die Skalierbarkeit verändern
Der Begriff „Cloud-Scale“ wird oft leichtfertig verwendet. Es wird im Marketing häufig verwendet, um einen WIRKLICH GROSSEN Maßstab anzudeuten, im Gegensatz zu, wie ich vermute, dem traditionellen, nicht ganz so großen, aber dennoch signifikanten Maßstab.
Doch ebenso wie in Mythen und Legenden ein Körnchen Wahrheit verborgen liegt, ist auch in der Art und Weise, wie mit dem Begriff „Wolkenmaßstab“ um sich geworfen wird, ein Körnchen Wahrheit enthalten.
Die Wahrheit ist, dass die Cloud – und jetzt auch Container – die zugrunde liegende Basis der Skalierbarkeit verändert haben. Dieser Wandel wurzelt in den grundlegenden Unterschieden zwischen vertikalen und horizontalen Skalierungsstrategien. Im ersten Jahrzehnt dieses Jahrhunderts gingen wir fast ausschließlich davon aus, dass der vertikale Maßstab die beste Möglichkeit wäre, die benötigten Geschwindigkeiten und Vorschübe zu erreichen. Das bedeutete mehr Bandbreite, mehr Rechenleistung und mehr Speicher. Mehr Anschlüsse. Höhere Dichte. Schnellere Verarbeitung.
Doch mit dem Aufkommen des Cloud-Zeitalters verlagerte sich der Fokus auf die horizontale Skalierung. Wir benötigen noch immer mehr Bandbreite sowie Rechen- und Verarbeitungsleistung, aber wir haben gelernt, diesen Bedarf zu verteilen. Wir benötigen noch immer mehr Hardware, wir stellen sie jedoch aus mehreren Quellen zusammen und nicht zu einer einzigen monolithischen Einheit.
Die Spielregeln ändern sich durch die Art und Weise, wie die Ressourcen zusammengestellt werden. Und machen Sie sich nichts vor: Dank Containern hat sich die Spielregel geändert.
Der Maßstab hängt heute von der Steuerungsebene ab. Die Geschwindigkeit der zum Starten und Außerbetriebnehmen von Ressourcen verwendeten API ist möglicherweise wichtiger als die Geschwindigkeit des Lastausgleichsdienstes selbst. In einer Umgebung, in der Ressourcen innerhalb von Minuten gestartet und außer Betrieb genommen werden, ist die Geschwindigkeit der Diensterkennung von größter Bedeutung, um Anforderungen an eine verfügbare Instanz übermitteln zu können.
Mehr als die Hälfte (52 %) der Container haben laut dem Sysdig Container Usage Report 2019 eine Lebensdauer von weniger als fünf Minuten:
- 22 % <= 10 Sekunden
- 17 % <= 1 Minute
- 15 % <= 5 Minuten
Fast die Hälfte (42 %) betreibt zwischen 201 und 500 Containerinstanzen. Um die Genauigkeit aufrechtzuerhalten, aktualisiert die Steuerebene die Komponenten häufig. Noch viel häufiger als die Cloud und sicherlich noch viel häufiger als dies bei monolithischen Anwendungen der Fall ist.
Die Geschwindigkeit, mit der der Ingress-Controller (der Lastausgleichsmechanismus) aktualisiert wird, um den aktuell verfügbaren Satz von Ressourcen widerzuspiegeln, wird dann zu einer kritischen Fähigkeit. Denn wenn die Daten falsch sind, kann die Anfrage eines Verbrauchers an eine Ressource weitergeleitet werden, die nicht mehr existiert – oder einen völlig anderen Dienst hostet. In beiden Fällen ist das Ergebnis eine längere Antwort, da die Anforderung an eine verfügbare Ressource umgeleitet wird. Der Verbraucher muss länger auf eine Antwort warten und entscheidet sich möglicherweise, lieber wegzugehen.
All dies deutet darauf hin, dass die Geschwindigkeit der Steuerebene ein blockierender Faktor für die Skalierbarkeit von Anwendungen ist, die in einer Containerumgebung bereitgestellt werden.
Letztendlich bedeutet dies, dass der Maßstab der Steuerebene ein Problem darstellt. Das Design der API ist ein Problem. Die Mechanismen, mit denen Anfragen und Aktualisierungen der API authentifiziert und autorisiert werden, sind ein Problem.
Wenn es heutzutage um Skalierbarkeit geht, steht die Steuerebene im Mittelpunkt. Eine robuste, skalierbare Steuerebene ist kein nettes Extra. Es ist heute ein RFC-MUSS.