Maslows Bedürfnishierarchie der Automatisierung

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Wenn es derzeit etwas gibt, das noch angesagter ist als Container, dann ist es wahrscheinlich etwas, das auf Containern basiert, wie etwa Serverless. Es ist nicht nur momentan der „coole“ Neuzugang, sondern verdeutlicht auch, wie wichtig Automatisierung und Orchestrierung* für moderne Anwendungen sind.

Fast täglich kommt eine neue Komponente für Container-Architekturen hinzu – und mit ihr der entsprechende Automatisierungsgrad. Wenn sich in einer Container-Welt etwas automatisieren lässt, wird es auch 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 für die digitale Transformation der IT von entscheidender Bedeutung.

Container-Umgebungen bilden da keine Ausnahme. Je mehr sie Einzug in Produktionsumgebungen halten, desto wichtiger wird es, dass vorgelagerte (N-S-)Dienste nicht nur die Anwendungen bereitstellen können, die innerhalb dieser hochdynamischen Umgebungen skaliert und ausgeliefert werden, sondern auch auf der Automatisierungs- und Orchestrierungsebene in diese Umgebungen integriert werden können.

Das liegt daran, dass einige Ebenen dieses Technologie-„Stacks“ dynamischer sind als andere. So werden beispielsweise Container wesentlich häufiger erstellt und entfernt als ganze Cluster. Tatsächlich heißt es im Docker-Adoption-Bericht von Data Dog HQ: „Im März 2017 nutzten rund 40 Prozent der Datadog-Kunden, die Docker einsetzten, zugleich auch Kubernetes, Mesos, Amazon ECS, Google Container Engine oder einen anderen Orchestrator.“ Automatisierung und Orchestrierung sind für den erfolgreichen Einsatz von Containern von entscheidender Bedeutung, insbesondere im Kernbereich. Daher müssen im weiteren Verlauf bestimmte Automatisierungsanforderungen so schnell (und umfassend) wie möglich erfüllt werden, da sie die Grundlage für alles Weitere bilden.

Dies gilt auch für Cloud-Umgebungen. Schließlich ist es nicht nur die hohe Veränderungsdynamik, die den Bedarf an Automatisierung und Orchestrierung begründet, sondern auch die Agilität. Das komplexe Self-Service-Modell des Cloud-Computings erfordert Automatisierung, um elastische, bedarfsgesteuerte Cloud-Architekturen im Rahmen eines Utility-Computing-Modells zu ermöglichen. Sowohl für die Cloud als auch für Container lässt sich eine Reihe gemeinsamer Automatisierungsanforderungen identifizieren, die die Grundlage dafür bilden, ihren geschäftlichen Nutzen zu verstehen.

Ähnlich wie die Maslowsche Bedürfnishierarchie basiert die Hierarchie der Automatisierungsbedürfnisse auf der Annahme, dass es „Defizitbedürfnisse“ gibt, die erfüllt werden müssen, um zu übergeordneten Bedürfnissen aufzusteigen, die Wachstum ermöglichen.

Bevor man sich der Erfüllung höherer Wachstumsbedürfnisse zuwenden kann, müssen zunächst die Defizitbedürfnisse der unteren Ebenen befriedigt werden. Sobald ein Defizitbedürfnis befriedigt ist, verschwindet es, und unsere Aktivitäten richten sich fortan gewohnheitsmäßig darauf, die nächste Gruppe von Bedürfnissen zu erfüllen, die noch unbefriedigt sind. Diese werden dann zu unseren vorrangigen Bedürfnissen. Wachstumsbedürfnisse hingegen bleiben bestehen und können sogar stärker werden, sobald sie geweckt wurden. Sind diese Wachstumsbedürfnisse in angemessenem Maße erfüllt, kann man möglicherweise die höchste Stufe erreichen, die als Selbstverwirklichung bezeichnet wird. -- https://www.simplypsychology.org/maslow.html

Im Kern konzentriert sich diese spezielle Hierarchie der Automatisierungsbedürfnisse auf die grundlegenden Anforderungen bei der Skalierung von Anwendungen und den zugehörigen Diensten. Der äußerst kompetente F5-Ingenieur, der dieses Konzept erstmals vorstellte, erklärt dazu: „Die Automatisierung auf der untersten Ebene ist am wertvollsten, weil sie am häufigsten zum Einsatz kommt und entscheidend dafür ist, dass eine Anwendung online bleibt. Die Automatisierung auf der obersten Ebene ist am wenigsten wertvoll, weil sie seltener stattfindet (vielleicht nur ‚einmal‘) und zu einem Zeitpunkt erfolgt, an dem viele ohnehin bereits manuelle Aufgaben ausführen.“

Dies sind die „grundlegenden“ Anforderungen. Die Automatisierung der Erstellung und Löschung von Containern, virtuellen Maschinen und Anwendungen ist nicht nur für die Skalierung entscheidend, sondern auch für die Effizienz der Skalierung. Diese Effizienz ist wichtig, um Kosten zu begrenzen und den mit der Skalierung verbundenen Aufwand zu verringern, der traditionell durch (kostspielige) manuelle Prozesse bewältigt wird. Angesichts des Umfangs und der Häufigkeit, mit der solche Ereignisse heute auftreten, ist Automatisierung eine Notwendigkeit und kein optionaler Zusatz. Sie ist ein Defizitbedürfnis. Wird dieses nicht erfüllt, besteht kaum Anlass, sich mit anspruchsvolleren, seltener auftretenden Automatisierungsaufgaben zu befassen.

Dies gilt insbesondere für Container und scheint erneut durch Data Dog bestätigt zu werden. Dort heißt es: „Container haben eine durchschnittliche Lebensdauer von 2,5 Tagen, während herkömmliche und cloudbasierte VMs über alle Unternehmen hinweg im Durchschnitt 23 Tage bestehen.“ Dies wird offenbar durch Automatisierung beeinflusst. „In Unternehmen, die Docker mit einem Orchestrator betreiben, beträgt die typische Lebensdauer eines Containers weniger als einen Tag. In Unternehmen, die Docker ohne Orchestrierung betreiben, besteht ein Container durchschnittlich 5,5 Tage.“

Die Möglichkeit, die Erstellung und Löschung von Containern und damit auch von Anwendungen zu automatisieren, ist unerlässlich, um die für eine Skalierung erforderliche Geschwindigkeit und Agilität zu erreichen. Nur so können Unternehmen sowohl in herkömmlichen als auch in cloudbasierten Umgebungen von den Vorteilen der Container profitieren.

Die übergeordneten Automatisierungsanforderungen betreffen im Wesentlichen das Routing und gehören zu den sogenannten Wachstumsbedürfnissen. Wachstumsbedürfnisse werden erst angestrebt, wenn die Grundbedürfnisse (Defizitbedürfnisse) erfüllt sind. Das Erstellen und Löschen von Clustern sowie Routing-Änderungen kommen selten vor und werden erst dann relevant, wenn die App eingerichtet und skalierbar ist. Dies wird unerlässlich, sobald die Umgebung von der Entwicklungs-/Testphase in eine Produktionsumgebung überführt wird und durch die Bereitstellung von Anwendungen einen geschäftlichen Mehrwert liefern soll. Schließlich ist das Routing zu einer App, die nicht reagieren kann, so, als würde man einen hungernden Menschen umarmen. Das warme, wohlige Gefühl stillt nicht das Grundbedürfnis nach Nahrung. Eine 2016 von Mesosphere unter seinen Nutzern durchgeführte Umfrage ergab, dass 62 % von ihnen Container bereits in Produktionsumgebungen einsetzten. Eine 2017 von Portworx auf der containerorientierten Konferenz DockerCon durchgeführte Umfrage ergab, dass 67,2 % der Befragten Container in der Produktion einsetzten. Das bedeutet, dass Routing-Anforderungen rasch an Bedeutung gewinnen, zumindest für die Teilgruppe der Unternehmen, die Container einführen.

Das oberste Ziel der Selbstverwirklichung eines Unternehmens – Wachstum – kann erst erreicht werden, wenn die gesamte Hierarchie erfüllt ist, das heißt, wenn der gesamte „Stack“ automatisiert und orchestriert ist. Daher liegt es nahe, dass diejenigen, die sich hauptsächlich auf der N-S-Datenebene bewegen, die Orchestrierung von unten nach oben angehen: Zunächst erfüllen sie die Skalierungsanforderungen der Umgebung und arbeiten sich dann zu den Routing-Anforderungen vor, wo der Übergang vom N-S- zum E-W-Datenverkehr stattfindet. Dies zeigt sich auch an der kontinuierlichen Weiterentwicklung des enger verzahnten Ökosystems rund um Container-Orchestratoren wie Kubernetes. Eine der jüngeren Entwicklungen konzentriert sich auf die „Routing“-Anforderungen und umfasst Ingress-Controller , die das Routing auf Layer 7 (URI/API) übernehmen, um einen nahtlosen Übergang von N-S- zu E-W-Diensten zu gewährleisten. Auch diese Komponente muss letztlich integriert (automatisiert) werden, um die Routing-Anforderungen zu erfüllen und Unternehmen auf ihrem Weg durch die Hierarchie weiter voranzubringen, damit sie Wachstum erzielen können.

Durch die Übertragung auf containerspezifische Konstrukte können wir den Automatisierungsbedarf der Containerumgebung denjenigen Netzwerkdiensten zuordnen, die ihre Skalierung und damit ihr Wachstum unterstützen. Sowohl die Containerkonstrukte als auch die Konstrukte für Netzwerk- und Anwendungsdienste müssen automatisiert werden. Hundert Container zur Skalierung einer Anwendung zu erstellen, ohne gleichzeitig die Dienste zu automatisieren, die während der Bereitstellung für deren Verwaltung zuständig sind, lässt wesentliche Anforderungen unerfüllt. Diese Netzwerkkonstrukte können entweder als native Containerkonstrukte oder als bestehende Anwendungsdienste vorliegen, die für die native Einbindung in die Containerumgebung angepasst wurden. Die Details der Implementierung variieren je nach Architektur und betrieblichen Anforderungen. Für den Erfolg sind jedoch beide Arten von Konstrukten erforderlich, um sowohl grundlegende Anforderungen an die Skalierung als auch Wachstumsanforderungen an das Routing zu erfüllen.

In jedem Fall hängt der Erfolg von Containern und der Cloud in hohem Maße von ihren Ökosystemen ab. Das bedeutet, dass sie auf die „Other API Economy“ 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 Automatisierung und Orchestrierung in der Containerwelt offenbar miteinander vermengt und als austauschbar dargestellt werden. Aber lassen wir das vorerst beiseite, und ich versuche, den Pedanten dort zu behalten, wo er hingehört: in meinem Kopf. Schreiend. Verzweifelt.

Ü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