Container, Microservices oder dynamische Infrastrukturen

Die steigende Komplexität der Cloud

Quelle: Foto: ranjith ravindran / shutterstock.com
20.04.2018
Höher, schneller, weiter – den Entwicklungen in der Cloud scheinen derzeit kaum Grenzen gesetzt. Neue Technologien und neue Möglichkeiten sprießen an jeder Ecke. Hier gilt es, die Übersicht zu wahren.
Der Beitrag wurde erstellt von Alex Rosembat, Vice President bei Datadog.
Alex Rusemblat: Vice President bei Datadog
Quelle: (Quelle: Datadog )
Neue, innovative Cloud-Umgebungen ermöglichen es Unternehmen, ihren Kunden einen schnelleren und besseren Service anzubieten. Cloud-Dienste können innerhalb kürzester Zeit hoch- und runtergefahren werden und haben eine schnelle Skalierbarkeit, daher können moderne Cloud-Anwendungen für Unternehmen ein entscheidender Wettbewerbsfaktor sein. Doch die Cloud besteht aus vielen einzelnen Elementen, mit denen sich die Operations-Teams auseinandersetzen müssen. Dazu zählen diverse Container-Anwendungen, Microservices oder dynamische Infrastrukturen, in die ebenso investiert werden muss. Die Cloud-Komplexität stellt daher auch viele Unternehmen vor neue Herausforderungen, da die unterschiedlichen Anwendungen auch verwaltet werden müssen.

Mit Cloud Monitoring den Überblick wahren

Applikationen sind mittlerweile über zahlreiche Clouds, Backups, Internet of Things, Container, Endgeräte und mehr verteilt. Hier den Überblick zu behalten ist mitunter gar nicht so einfach. Um den zahlreichen Applikationen Herr zu werden, müssen moderne Cloud-Monitoring-Lösungen heutzutage mehr als 300 verschiedene Integrationen abdecken, damit sie zumindest ansatzweise ein Gesamtbild liefern können. Hinzu kommt, dass natürlich auch die einzelnen Metaebenen innerhalb der Cloud genauso von Bedeutung sind, genauso wie jede Ebene, jeder Container oder jede Cloud für sich einzeln genommen. Die Komplexität der Cloud-Umgebungen führt zudem dazu, dass Unternehmen ihre Applikationen und Prozesse von ihrer althergebrachten Legacy-Infrastruktur nicht mehr ohne Weiteres in die Cloud verschieben können. Denn um die gesamte Cloud-Kultur effizient nutzen zu können, muss das gesamte Werkzeug erneuert werden. Nur so kann die Effizienz moderner Technologien gehoben werden.

Das Zeitalter der Container hat begonnen

Bekannte Container-Technologien, wie Packer, Shipyard oder Linuxcontainers haben in den letzten Jahren einen enormen Erfolg in puncto Infrastruktur-Lösungen verzeichnet. Doch der absolute Liebling ist und bleibt Docker. Laut dem Datadog Docker Adoption Report, welcher 2017 Stichproben von mehr als 10.000 Unternehmen und mehr als 200 Millionen Container analysierte, nahm die Nutzung von Docker im Jahresvergleich um 40 Prozent zu. Mit dem Anstieg der Nutzungsrate von Docker nimmt auch der Gebrauch von Orchestrierungstools für das Cloud-Management zu. Zu den bekanntesten Lösungen zählt wohl Kubernetes. Bereits 40 Prozent der Docker-User setzen mittlerweile auf Kubernetes. Das sind 11 Prozent mehr, als im Jahr 2017. Doch auch andere Orchestrierungslösungen wie etwa Apache Mesos, Amazon Elastic Container Service (ECS) oder Azure, werden immer häufig genutzt.

Im Vergleich zu traditionellen, virtuellen Maschinen sind Container viel dynamischer. Während des Betriebs einer Applikation auf einer virtuellen Maschine sind nebenher noch zahlreiche weitere Ressourcen von Nöten. Das Resultat? Abhängigkeit. So gehören benötigte Bibliotheken, ein Betriebssystem oder weitere Dienste und Anwendungen zwingend dazu. Wohingegen ein Docker-Container nur die eigentlichen Anwendungen mit den dazugehörigen Abhängigkeiten umfasst. Grund hierfür ist, dass dieser als separater Prozess auf dem Host-Betriebssystem ausgeführt wird und er sich den Linux Kernel mit weiteren Docker-Containern teilt. Dadurch, dass die Prozesse strickt getrennt ausgeführt werden, haben mehrere Container auf dieselben Kernel-Ressourcen Zugriff. Dabei lässt sich Punkt genau für jeden Container festlegen, welche und wie viele Ressourcen, RAM sowie Bandbreite ihm während des Prozesses zur Verfügung stehen.

Komprimierte Lebensdauer

Container haben nur eine sehr kurze Lebenserwartung. Innerhalb kürzester Zeit können sie vom Nutzer gestoppt oder gar aufgelöst werden. Wenn dies geschieht, sind alle jemals angesammelten Daten des Containers gelöscht. Die Daten können aber auch ebenso schnell wiederhergestellt werden. Das macht sie im Grunde genommen zu sogenannten Einwegartikeln. Selbstverständlich können Container aber auch über einen längeren Zeitraum hinweg auf Anwendungsservern, Datenbanken oder für Web Services genutzt werden. Jedoch wird der Nutzungszeitraum der Container aktuell weiter von Orchestrierungstools, wie etwa Kubernetes, verkürzt, da sie bei Bedarf an- und ausgeschaltet werden.

Die Verdichtung von Containern und deren geringere Lebenserwartung wirkt sich natürlich auch auf die Überwachung der Infrastruktur aus. Das bringt Host-basierte Monitoring-Lösungen, sofern diese noch genutzt werden, relativ schnell an ihre Grenzen. So müssen diese nämlich entweder die Container als Host bewerten, welche von Minute zu Minute erscheinen und wieder gehen (das ist sehr schlecht, weil das System so die Hälfte der Zeit denkt, dies zeuge von einem Ausnahmezustand), oder aber sie werden gar nicht getrackt (das ist ebenso sehr ungünstig, da so Schwachstellen entstehen). Daher können nur Rollen-basierte-Lösungen mithalten, die dazu in der Lage sind mit Ebenen und Tags zu arbeiten.

Effizienz mit Microservices

Um die Modularisierung von Applikationen voranzutreiben, sind vor allem die sogenannten Microservices effektive Ansätze. Denn sind die Anwendungen erst einmal als Service-Set aufgebaut, ist es möglich, diese ganz unabhängig voneinander zu entwickeln, zu testen und zu skalieren. Zudem können die Microservices unabhängig voneinander deployed werden, sodass verschiedenste Technologien und Infrastrukturen genutzt werden können. Diese Option gibt Unternehmen ein ganz neues Maß an Flexibilität und Unabhängigkeit – ganz im Gegensatz zu den herkömmlichen monolithischen Applikationen, da hier alle Komponenten im selben Prozess sowie derselben Infrastruktur laufen und nur sehr schlecht voneinander isoliert werden können. Sollen die eben erwähnten Monolithen dann skaliert werden, müssen am Ende alle Komponenten skaliert werden; ganz egal, ob es sich dabei um eine einzelne, isolierte Komponente handelt, welche einen Engpass darstellt. Diese Form von Applikationen benötigt eine große Anzahl an Ressourcen und führt letztendlich lediglich zur ineffizienten Arbeitsweise.

Es ist klar, dass Unternehmen nun nicht alle ihre Applikationen in Microservices herunterbrechen können. Doch da, wo es Sinn macht, bringt es immense Vorteile in Bezug auf Unabhängigkeit und der Vereinfachung der Softwareverteilung mit sich. Nutzer können zudem im Gegensatz zu den herkömmlichen Legacy-Infrastrukturen frei wählen, welcher Technologie-Stack sich für die jeweilige Aufgabe am besten eignet. Auch ein Technologiewechsel im Verlauf der verschiedenen Prozessketten ist möglich. Und wurden die verschiedenen Services erst einmal voneinander getrennt, kann eine virusbehaftete Komponente andere Applikationen nicht mehr Schaden zufügen.

Allerdings ist die Umwandlung zentraler und komplexer Anwendungen in Microservices keine leichte Aufgabe. Umso mehr Unternehmen ihre Applikationen in die Cloud implementieren, desto schneller erkennen sie das Potenzial von effektiven und modernen Strukturmodellen. Aus dem Grund handelt es sich bei Microservices auch mehr um eine Evolution statt einer Revolution. Allerdings müssen sich die Operations-Teams auch hier den evolutionären Schwierigkeiten stellen. Denn eines ist klar: wenn jeder einzelne Service auch eine Deployment Unit darstellt, mit samt Releases, Tests und Monitoring, dann steigt auch die Komplexität. Um den Überblick zu wahren, müssen DevOps-Teams, egal wie kleinteilig es auch sein mag, über alle Komponenten und Applikationen im Ökosystem im Bilde sein.

Server? Nein, Danke!

Heutzutage setzen viele Unternehmen um Applikationen hoch- oder runterskalieren vor allem auf Platform-as-a-Service (PaaS) Lösungen wie etwa Heroku oder OpenShift. In der Regel sind PaaS-Lösungen für langfristige Server-Applikationen designt, damit eigehende Anfragen bei Bedarf bearbeitet werden können, doch sie laufen auch dann weiter, wenn mal keine Anfragen kommen.
Bei diesem Leerlauf ist Serverless Computing wie beispielsweise der Service von AWS Lambda die Lösung. So wird eine Funktion beim Eingehen einer Anfrage gestartet und endet, wenn eine Anfrage bearbeitet wurde. Es gibt einen Code, nicht aber einen Server. Der Code wird als Reaktion auf bestimmte Events automatisch ausgeführt und ihm automatisch die notwendigen Rechenressourcen zugewiesen.

Die Zeit, in der alle Anfragen on demand bedient und Anwendungen ad hoc ausgeführt werden, ist natürlich längst nicht erreicht. Zudem würden auch die aktuellen Preismodelle kaum den Einsatz von Serverless in Bezug auf langfristige Aufgaben zulassen. Doch nichtsdestotrotz müssen wir uns zukünftig auf den Einsatz von serverloser Anwendung einstellen, bei denen die Komplexität natürlich genauso zunehmen wird.

Das große Ganze im Blick behalten

DevOps-Teams müssen eine Menge Herausforderungen, wie etwa die Entwicklung und Verteilung von Software und die Verbesserung der User Experience, stemmen. Daher ist es kein Wunder, dass der Einsatz von verteilten Anwendungen, Containern und Microservices oder serverloser Architektur zunimmt. Doch je mehr die Komplexität der einzelnen Komponenten steigt, desto wichtiger ist es, die Verbindungen der einzelnen Elemente zueinander im Blick zu behalten. Denn nur wer auch einen Überblick über das große Ganze behält, kann am Ende auch die technologischen Vorteile nutzen.

Autor(in)

Das könnte sie auch interessieren
Künstliche Intelligenz
Memary - Langzeitgedächtnis für autonome Agenten
Cloud Infrastructure
Oracle mit neuen KI-Funktionen für Sales, Marketing und Kundenservice
Reactive mit Signals
Neuer Vorschlag für Signals in JavaScript
Schellerer Ausbau
Hessen, OXG und Vodafone schließen Partnerschaft für Glasfaser
Mehr News?
Besuchen Sie unsere Seite ...
https://www.com-magazin.de
nach oben