Suche
Vom Leben in einer komplexen Welt

Container, Microservices & Serverless Computing: Gehört ihnen die Zukunft?

Adam LaGreca

© Shutterstock.com / Ralf Gosch

Die Fähigkeiten, schnell skalieren zu können und Dienste in der Cloud hoch- oder herunterzufahren, Feedback iterieren zu können und unkompliziert auf Kundenwünsche zu reagieren, machen moderne Cloud-Umgebungen zu einem starken Wettbewerbsfaktor. Sie machen die Softwareentwicklung und das Operations-Team zum entscheidenden Aktivposten im Unternehmen. Mit Containeranwendungen, Microservices und dynamischen Infrastrukturen investieren Unternehmen in ihre Effektivität. Zugleich sehen sie sich damit aber auch mit einer nie dagewesenen Komplexität der zu verwaltenden Anwendungen konfrontiert.

Applikationen erstrecken sich heute oft über mehrere Clouds – teils als Back-up –, Internet-of-Things-Umgebungen, Container, Endgeräte und mehr. Um den Überblick zu behalten, müssen moderne Cloud-Monitoringlösungen heute schon über dreihundert unterschiedliche Integrationen abdecken können, nur um ein annährend vollständiges Bild liefern zu können. Frei nach dem Systemforscher Frederic Vester könnte man in Bezug auf die immer dynamischer und heterogener werdenden Cloud-Umgebungen davon sprechen, dass „in einem komplexen System die Beziehungen der Elemente zueinander wichtiger sind als die Elemente selbst“. Wenn nicht wichtiger, dann doch zumindest gleich wichtig. Denn klar ist: Das Zusammenspiel der einzelnen Metaebenen im Cloud-Gefüge ist ebenso von Bedeutung wie jede Ebene, jeder Container oder jede Cloud für sich. Ganz gleich, wie unübersichtlich alles auf den ersten Blick sein mag, wenn man aus der Welt klar strukturierter Hosts kommt.

Dabei wird schnell offenkundig, dass Unternehmen schlichtweg nicht mehr in der Lage sind, bestehende Applikationen und Prozesse mal eben einfach so von ihren Legacy-Infrastrukturen in die Cloud zu schieben. Wer die Effektivität moderner Technologien heben will, muss die gesamte Cloud-Kultur und vor allem die genutzten Werkzeuge modernisieren.

Containerisierung der Cloud

Containertechnologien wie Packer, Shipyard oder Linux Containers haben in den vergangenen Jahren eine wahre Erfolgsgeschichte in der Welt der Infrastrukturlösungen geschrieben. Der aktuelle Shootingstar in den „Container Wars“ ist und bleibt jedoch Docker. Zu Recht: Laut „Docker Adoption Report“ von Datadog, der 2017 Stichproben von über 10 000 Unternehmen und über 200 Millionen Container hinweg analysierte, stieg die Nutzungsrate von Docker im Jahresvergleich um 40 Prozent. Mit der zunehmenden Nutzung von Docker wächst auch die Verwendung von Containerorchestrierungstools zum effizienten Management der Containerlandschaft deutlich. Ein bekanntestes Beispiel ist Kubernetes. Datadog verzeichnete von Januar bis Oktober 2017 einen 50-prozentigen Anstieg der Nutzung von Kubernetes unter seinen Kunden. Natürlich kommen auch andere Orchestrierungslösungen, wie Apache Mesos, Amazon Elastic Container Service (ECS) oder Azure Container Service zum Einsatz. Aber schon heute nutzen 40 Prozent der Docker-User auf Datadog Kubernetes, 11 Prozent mehr als noch im Januar 2017.

Die aktuelle Dynamik rund um Tools wie Docker oder Kubernetes ist jedoch kein Produkt der Silicon-Valley-Start-ups, die wie selbstverständlich in der Cloud geboren werden. Auch große Unternehmen aus den Fortune 500 oder dem DAX „containern“ ihre Anwendungen bereits. Sind sie einmal auf den Geschmack gekommen, gibt es selten einen Weg zurück.

Docker-Container und natürlich auch Container generell sind viel dynamischer als traditionelle virtuelle Maschinen. Während des Betriebs einer Applikation auf einer virtuellen Maschine wird neben der Applikation selbst eine Reihe weiterer Ressourcen benötigt, was zu einem enormen Overhead und großen Abhängigkeiten führt. Dazu gehören die notwendigen Bibliotheken, ein vollwertiges Betriebssystem und gegebenenfalls weitere Dienste und Applikationen. Ein Docker-Container hingegen umfasst nur die eigentliche Applikation und die zugehörigen Abhängigkeiten. Er wird als isolierter Prozess auf dem Hostbetriebssystem ausgeführt und teilt sich den Linux-Kernel mit anderen Docker-Containern. Durch die strikte Isolierung können mehrere Container auf dieselben Kernelressourcen zugreifen. Für jeden Container lässt sich dabei exakt definieren, wie viele Ressourcen ihm im Sinne von Prozessor, RAM oder Bandbreite zur Verfügung stehen.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Kurze Lebenserwartung

Container sind dafür konzipiert, jederzeit das Zeitliche segnen zu können. Als User kann man sie stoppen und zerstören. Kurz und schmerzlos. Wenn das passiert, sind alle Daten, die im Leben des Containers angesammelt worden sind, standardmäßig gelöscht. Aber: Container können genauso gut binnen Millisekunden wiederhergestellt werden. Auf gewisse Weise sind Container also Einwegartikel. Kein Wunder also, das Codes und Datenpipelines, die die Ausführung temporärer Befehle verlangen, wohl zu den beliebtesten Anwendungsgebieten zählen. Natürlich gibt es auch den anderen Fall. Ein Container kann sehr wohl auch ein langes und erfülltes Leben auf Applikationsservern, in Datenbanken oder für Web Services führen.

Die Lebenserwartung der Container wird derzeit von den genannten Orchestrierungstools wie Kubernetes jedoch weiter verkürzt, da sie von diesen bei Bedarf an- und ausgeschaltet werden. In Unternehmen, die Container wie Docker zusammen mit einem Orchestrator nutzen, beträgt die durchschnittliche Lebenserwartung eines einzelnen Containers laut Untersuchungen mittlerweile weniger als einen Tag.

Die geringere Lebenszeit und zunehmende Verdichtung der Container hat auch auf die Überwachung der Infrastruktur bedeutende Auswirkungen. Denn damit steigt natürlich auch die Zahl der individuell zu überwachenden Datenpunkte bis in Dimensionen, die hostbasierte Monitoringlösungen, sollten sie trotz Cloud immer noch im Einsatz sein, schnell an ihre Grenzen bringen. Entweder müssen sie die Container ebenfalls als Hosts bewerten, die von Minute zu Minute kommen und gehen (was schlecht ist, weil das System dabei die Hälfte der Zeit denkt, es herrsche Ausnahmezustand), oder sie tracken sie gar nicht (was auch schlecht ist, weil dann buchstäblich blinde Flecken entstehen). Hier können nur noch rollenbasierte Lösungen mithalten, die mit Ebenen und Tags arbeiten. Docker und Co. ziehen damit ihre Kreise hinein bis in an die Cloud angrenzende Bereiche wie das Monitoring.

Microservice me

Einer der effektivsten Ansätze, die Modularisierung von Applikationen weiter voranzutreiben, sind Microservices. Die Idee dahinter: Sind Anwendungen als Service-Sets aufgebaut, können sie unabhängig voneinander entwickelt, getestet und skaliert werden. Sie lassen sich als Microservices auch unabhängig voneinander deployen, weshalb dafür jede beliebige Technologie und Infrastruktur zum Einsatz kommen kann. Das eröffnet ein neues Maß an Flexibilität und Maßanfertigung. Dies steht natürlich im krassen Gegensatz zu den monolithischen Applikationen, in denen alle Komponenten im selben Prozess und in derselben Infrastruktur laufen und hierbei nur dürftig voneinander isoliert sind. Werden diese Monolithen skaliert, müssen alle Komponenten skaliert werden, ganz gleich, ob es vielleicht eine einzelne, isolierte Komponente ist, die einen Engpass darstellt. Das frisst Ressourcen und ist schlichtweg ineffizient.

Natürlich muss nicht jede Anwendung in jedem Unternehmen auf Microservices heruntergebrochen werden. Aber wo es sinnvoll ist, bieten sich hier gewaltige Vorteile in Bezug auf Unabhängigkeit und Vereinfachung der Softwareverteilung. Gegenüber traditionellen Anwendungen in Legacy-Infrastrukturen bieten Microservices die Freiheit, wählen zu können, welcher Technologiestack für die Aufgabe der am besten geeignete ist. Außerdem kann im Verlauf der Prozesskette zwischen verschiedenen Technologien gewechselt werden. Sind die Services erst einmal effektiv getrennt und voneinander isoliert, kann zudem eine schadhafte Komponente nicht länger die gesamte Anwendung in Mitleidenschaft ziehen.

Lesen Sie auch: Kubernetes Security: Best Practices für die sichere Nutzung von Containern

Leider ist es keine ganz einfache Aufgabe, zentrale und komplexe Anwendungen in Microservices-Architekturen umzuwandeln. Je mehr Unternehmen ihre Anwendungen jedoch in die Cloud transferieren, desto mehr erschließt sich ihnen das Potenzial effektiver moderner Strukturmodelle. Microservices sind daher eher eine Evolution als eine Revolution. Operations-Teams stehen jedoch auch hier vor neuen, evolutionären Herausforderungen. Wenn jeder einzelne Service eine eigene Deployment-Unit samt eigenem Release, Tests und Monitoring darstellt, nimmt natürlich auch an diesem Ende die Komplexität zu. DevOps-Teams müssen die Übersicht über alle Komponenten und Anwendungen im Ökosystem behalten können, egal wie kleinteilig es wird.

Kein Server, nur noch Code

Platform-as-a-Service-(PaaS-)Lösungen wie Heroku oder OpenShift finden sich heute in vielen Unternehmen, um Applikationen hoch- oder herunterskalieren zu können. Die Verantwortung, Ressourcen für das Hoch- beziehungsweise Herunterfahren entsprechend zuzuteilen, bleibt dabei jedoch ein manueller Prozess, den Entwickler oder Systemadministratoren ausführen müssen. Weil traditionelle PaaS-Modelle meist für langfristige Serverapplikationen designt worden sind, um eingehende Anfragen bei Bedarf zu bearbeiten, laufen sie eben auch dann, wenn keine Anfragen hereinkommen. Sie sind auf Stand-by. Dieses Leerlaufs nimmt sich Serverless Computing an. Die Idee dahinter: Eine Funktion startet dann, wenn eine Anfrage eingeht. Sie endet, sobald die Anfrage verarbeitet ist. Der aktuell beliebteste Serverless-Computing-Service ist sicher AWS Lambda, der einen Code als Reaktion auf bestimmte Events automatisch ausführt und zudem automatisch die zugrunde liegenden Rechenressourcen verwaltet.

Für Anwendungen, die über einen längeren Zeitraum laufen, behalten dedizierte Server oder virtuelle Maschinen natürlich ihre Berechtigung. Wir sind längst nicht an dem Punkt, an dem alle Anfragen on demand bedient und Applikationen ad hoc ausgeführt werden können. Und selbst, wenn wir es wären – die aktuellen Preismodelle eignen sich kaum für den Einsatz von Serverless für langfristig angelegte Aufgaben. Es wäre schlichtweg zu teuer und deutlich günstiger, hier auch weiterhin auf virtuelle Maschinen zu setzen. Zudem fürchten viele Unternehmen den sogenannten Vendor-Lock-in, also die übermäßige Herstellerabhängigkeit. Im Fall von AWS Lambda wäre dies AWS (Amazon Web Services).

Dennoch werden wir uns in Zukunft auf mehr serverlose Anwendungen einstellen müssen. Und auch hier steigt die Komplexität, vor allem, wenn man versucht, alle Anwendungen immer im Blick zu behalten. Denn wie will man die Performance von etwas überwachen, das aktuell noch als Code ruht und nur bei Bedarf ausgeführt wird?

Komplexität fängt im Kopf an

DevOps-Teams stehen vor der Herausforderung, Software schneller entwickeln und verteilen zu müssen. Sie sollen die User Experience stetig verbessern und an neue Geräte und Services anpassen. Zudem werden sie noch von Geschäftskennzahlen gegängelt und müssen Effektivität und Effizienz im Prozess hochhalten. Kein Wunder also, dass moderne verteilte Applikationen, die Container, Microservices oder sogar serverlose Architekturen nutzen, immer beliebter werden. Je komplexer das Miteinander der einzelnen Elemente jedoch wird, desto wichtiger ist es, einen klaren Überblick über die Beziehungen der einzelnen Elemente zueinander zu bewahren. Komplexität fängt eben im Kopf an, wo alles zusammenläuft und wo der Überblick gewahrt werden sollte. Nur wenn wir es schaffen, den Überblick zu behalten, können wir frohen Mutes und ohne Skrupel die spannenden technologischen Möglichkeiten zu unserem Vorteil nutzen. Und zwar ohne uns den Kopf zerbrechen zu müssen.

Geschrieben von
Adam LaGreca
Adam LaGreca
Adam LaGreca leitet die Kommunikation beim Cloud-Monitoring-Service Datadog mit Sitz in New York. Bevor er zu Datadog stieß, verantwortete er die Kommunikation des Cloud-Infrastrukturunternehmens DigitalOcean. Weitere Stationen seiner Karriere umfassen Bubble (www.bubble.is) und Stae (https://stae.co).
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: