Maslows Hierarchie der Automatisierungsbedürfnisse
Wenn es im Moment etwas gibt, das angesagter ist als Container, dann ist es wahrscheinlich etwas, das auf Containern basiert, wie zum Beispiel Serverless. Es ist nicht nur derzeit das „coole“ Kind im Viertel, sondern zeigt auch, wie wichtig Automatisierung und Orchestrierung* für moderne Anwendungen sind.
Fast jeder Tag bringt eine neue Komponente in die Containerarchitektur und damit auch den entsprechenden Grad der Automatisierung mit sich. Wenn in einer Containerwelt etwas automatisiert werden kann, wird es automatisiert. Eine Vielzahl von APIs und die Abhängigkeit von konfigurations-/vorlagenbasierten Artefakten treiben die nahezu kontinuierliche Weiterentwicklung der Automatisierung in containerbasierten Umgebungen voran. Wenn die API-Ökonomie für die digitale Transformation von Unternehmen wichtig ist, dann ist die andere API-Ökonomie von entscheidender Bedeutung für die digitale Transformation der IT.
Containerumgebungen bilden hier keine Ausnahme. Und da sie immer mehr in Produktionsumgebungen Einzug halten, wird es für Upstream-Dienste (N-S) immer wichtiger, nicht nur in der Lage zu sein, die Apps bereitzustellen, die aus diesen äußerst volatilen Umgebungen skaliert und bedient werden, sondern sich auch auf der Automatisierungs- und Orchestrierungsebene in sie zu integrieren.
Das liegt daran, dass einige Schichten dieses Technologie-„Stapels“ volatiler sind als andere. Beispielsweise kommt es viel häufiger vor, dass Container erstellt und zerstört werden, als dass ganze Cluster erstellt und/oder zerstört werden. Tatsächlich heißt es im Docker Adoption Report von Data Dog HQ , dass „im März 2017 rund 40 Prozent der Datadog-Kunden, die Docker verwenden, auch Kubernetes , Mesos, Amazon ECS , Google Container Engine oder einen anderen Orchestrator im Einsatz hatten.“ Automatisierung/Orchestrierung ist für den Erfolg von Containern von entscheidender Bedeutung, insbesondere in ihrem Kern. Dies bedeutet, dass wir im weiteren Verlauf unbedingt einige Automatisierungsanforderungen so schnell (und gründlich) wie möglich erfüllen müssen, da diese die Grundlage für alles andere bilden.
Dies gilt auch für Cloud-Umgebungen. Es ist nicht nur die Volatilität, die den Bedarf an Automatisierung und Orchestrierung vorantreibt, sondern letztlich auch die Agilität. Das komplexe „Self-Service“-Modell des Cloud Computing erfordert Automatisierung, um das Konzept der elastischen On-Demand-Architekturen des Cloud Computing innerhalb eines Utility-Computing-Modells zu unterstützen. Es gibt eine Reihe erkennbarer Automatisierungsanforderungen, die sowohl für die Cloud als auch für Container gelten und die Grundlage für das Verständnis ihres geschäftlichen Werts bilden.
Ähnlich wie Maslows Bedürfnishierarchie basiert die Hierarchie der Automatisierungsbedürfnisse auf der Annahme, dass es „Defizitbedürfnisse“ gibt, die befriedigt werden müssen, um zu höherwertigen Bedürfnissen aufzusteigen, die Wachstum ermöglichen.
Man muss zunächst die Defizitbedürfnisse auf niedrigerem Niveau befriedigen, bevor man mit der Befriedigung der Wachstumsbedürfnisse auf höherem Niveau fortfahren kann. Sobald ein Defizitbedürfnis befriedigt wurde, verschwindet es und unsere Aktivitäten richten sich gewohnheitsmäßig auf die Befriedigung der nächsten Bedürfnisse, die noch zu befriedigen sind. Dies werden dann zu unseren wichtigsten Bedürfnissen. Der Wachstumsbedarf ist jedoch weiterhin spürbar und könnte sich sogar noch verstärken, wenn er erst einmal gedeckt wird. Wenn diese Wachstumsbedürfnisse einigermaßen befriedigt sind, kann man möglicherweise die höchste Ebene erreichen, die sogenannte Selbstverwirklichung. – https://www.simplypsychology.org/maslow.html
Im Kern konzentriert sich diese spezielle Hierarchie der Automatisierungsanforderungen auf die grundlegenden Anforderungen im Zusammenhang mit der Skalierung von Anwendungen und ihren zusammengesetzten Diensten. Der äußerst talentierte F5-Ingenieur, der dieses Konzept erstmals vorstellte, erklärt: „Die Automatisierung im unteren Bereich ist am wertvollsten, da sie am häufigsten vorkommt und entscheidend dafür ist, dass eine Anwendung online bleibt. Die Automatisierung an der Spitze ist am wenigsten wertvoll, da sie weniger häufig erfolgt (vielleicht nur „einmal“) und zu einer Zeit stattfindet, in der viele Leute bereits manuelle Dinge erledigen.“
Dies sind die „grundlegenden“ Anforderungen für die Automatisierung der Erstellung/Zerstörung von Containern/virtuellen Maschinen und Apps, die nicht nur für die Skalierung, sondern auch für die Wirksamkeit der Skalierung von entscheidender Bedeutung sind. Diese Wirksamkeit ist wichtig, um die Kosten einzuschränken und die Skalenbelastung zu verringern, die traditionell auf (kostspieligen) manuellen Vorgängen beruht. Angesichts der Menge und Häufigkeit, mit der sich derartige Ereignisse heutzutage ereignen, ist Automatisierung ein Muss und kein nettes Extra. Es handelt sich um ein Defizitbedürfnis , d. h., wenn es nicht erfüllt wird, besteht kein Grund zur Sorge über eine Automatisierung höherer Ordnung, die weniger häufig auftritt.
Dies gilt insbesondere für Container und wird durch Data Dog erneut bestätigt, wenn dort festgestellt wird: „Container haben eine durchschnittliche Lebensdauer von 2,5 Tagen, während herkömmliche und Cloud-basierte VMs unternehmensübergreifend eine durchschnittliche Lebensdauer von 23 Tagen haben.“ Dies scheint durch die Automatisierung beeinflusst zu werden. „In Organisationen, die Docker mit einem Orchestrator ausführen, beträgt die typische Lebensdauer eines Containers weniger als einen Tag. In Organisationen, die Docker ohne Orchestrierung ausführen, existiert der durchschnittliche Container 5,5 Tage.“
Die Fähigkeit, die Erstellung/Zerstörung von Containern und anschließend Apps zu automatisieren, ist zwingend erforderlich, um die Geschwindigkeit und Agilität zu erreichen, die erforderlich ist, damit Unternehmen die Vorteile von Containern sowohl in herkömmlichen als auch in Cloud-basierten Umgebungen nutzen können.
Die Automatisierungsanforderungen höherer Ordnung sind im Wesentlichen Routing-Anforderungen und fallen in die Kategorie der Wachstumsanforderungen. Wachstumsbedürfnisse werden angestrebt, sobald die Grundbedürfnisse (Mangelbedürfnisse) erfüllt sind. Die Erstellung/Zerstörung von Clustern sowie Routing-Änderungen erfolgen selten und werden erst dann sinnvoll, wenn die App vorhanden und skalierbar ist. Dies wird zwingend erforderlich, wenn die Umgebung von der Entwicklungs-/Testumgebung in eine Produktionsumgebung migriert wird und durch die Bereitstellung von Anwendungen geschäftlichen Mehrwert liefert. Schließlich ist die Weiterleitung zu einer App, die nicht reagieren kann, so, als würde man einen verhungernden Mann umarmen. Das warme, wohlige Gefühl geht nicht auf das Grundbedürfnis nach Nahrung ein. Eine Mesosphere-Umfrage unter seinen Benutzern aus dem Jahr 2016 ergab, dass 62 % von ihnen bereits Container in Produktionsumgebungen verwendeten. Eine Portworx-Umfrage aus dem Jahr 2017 auf der Container-Konferenz DockerCon ergab, dass 67,2 % der Befragten Container in der Produktion verwendeten. Das bedeutet, dass die Routing-Anforderungen schnell an Bedeutung gewinnen, zumindest für den Teil der Organisationen, die Container einsetzen.
Das ultimative Ziel der Selbstverwirklichung eines Unternehmens – Wachstum – kann erst erreicht werden, wenn die gesamte Hierarchie erfüllt ist; das heißt, bis der gesamte „Stack“ automatisiert und orchestriert ist. Daher sollte es eine Selbstverständlichkeit sein, dass diejenigen, die hauptsächlich auf der NS-Datenebene leben, die Orchestrierung von unten nach oben durchführen, indem sie zuerst die Skalierungsanforderungen der Umgebung berücksichtigen und sich dann zu den Routing-Anforderungen vorarbeiten, bei denen der Übergang vom NS- zum EW-Verkehr stattfindet. Dies zeigt sich auch in der kontinuierlichen Entwicklung des stärker gekoppelten Ökosystems rund um die Container-Orchestratoren selbst, wie etwa Kubernetes. Eine der neueren Entwicklungen konzentrierte sich auf die „Routing“-Anforderungen und umfasste die Einbeziehung von Ingress-Controllern , die auf Ebene 7 (URI/API) routen, um einen reibungslosen Übergang von NS zu EW-Diensten zu gewährleisten. Auch diese Komponente muss letztendlich integriert (automatisiert) werden, um den Routing-Anforderungen gerecht zu werden und Organisationen weiter in der Hierarchie nach oben zu bringen, um Wachstum zu erzielen.
Durch die Übersetzung in containerspezifische Konstrukte können wir den Automatisierungsbedarf der Containerumgebung den Diensten im Netzwerk zuordnen, die den Skalierungsbedarf zur Erzielung von Wachstum unterstützen. Sowohl die Container- als auch die Netzwerk-/Anwendungsdienstkonstrukte erfordern Automatisierung. Das Erstellen von hundert Containern zum Skalieren einer App ohne gleichzeitige Automatisierung der für deren Verwaltung während der Bereitstellung zuständigen Dienste führt zu unbefriedigenden Anforderungen. Diese Netzwerkkonstrukte können entweder als native Containerkonstrukte oder als vorhandene App-Dienste existieren, die so angepasst sind, dass sie nativ in die Containerumgebung passen. Die Implementierungsdetails variieren je nach Architektur und Betriebsanforderungen, dennoch ist die Existenz beider Konstruktsätze erforderlich, um die grundlegenden (Skalierung) und Wachstumsanforderungen (Routing) zu erfüllen und erfolgreich zu sein.
In allen Fällen hängt der Erfolg von Containern und Clouds stark von ihren Ökosystemen ab, und das bedeutet, dass sie auf die andere API-Wirtschaft angewiesen sind, um die Automatisierung und Orchestrierung zu ermöglichen, die für das Unternehmenswachstum durch Initiativen zur digitalen Transformation entscheidend sind.
* Ich finde es frustrierend, dass die Konzepte der Automatisierung und der Orchestrierung in der Containerwelt scheinbar vermischt und einander gegenübergestellt werden . Aber ignorieren wir das vorerst einfach und ich werde versuchen, das Pedant dort zu belassen, wo es hingehört. In meinem Kopf. Schreiend. Verzweifelt.