Warum Microservices das Softwareäquivalent für menschliche Zellen sind (und was wir daraus lernen können)

JAXenter: In deinem DevOpsCon Workshop hast du über Selbstheilungssysteme gesprochen. Dabei vergleichst du Computersysteme mit dem menschlichen Körper. Wo liegen hier die Gemeinsamkeiten?

Viktor Farcic: Da gibt es zahlreiche Parallelen. Viele der Probleme, die wir in der Softwareindustrie zu lösen versuchen, wurden bereits durch Evolution gelöst. Mikrodienste, Unveränderlichkeit, Replikation und Skalierung, zentrale Überwachung und Alarmierung, Dezentralisierung, Selbstheilung und Selbstadaption sind nur einige Beispiele, die im menschlichen Körper ihre Entsprechungen haben. Wenn wir den menschlichen Körper mit einem Rechenzentrum vergleichen, sind die Ziele und Lösungen sehr ähnlich. Der Hauptunterschied ist, dass wir (Menschen) immer noch deutlich hochentwickelter sind als Maschinen und Software. Wenn man keine Lehren aus der Evolution zieht, würde man Millionen von Jahren Erfahrung ignorieren.

JAXenter: Kleinere Einheiten – wie Microservices – sind leichter zu heilen als größere Einheiten – wie Monolithen. Warum?

Viktor Farcic: Kleiner ist immer leichter zu handhaben als größer. Es ist einfacher, ein Auto zu fahren als einen Lastwagen. Ein Zimmer zu renovieren ist einfacher als ein ganzes Haus. Nehmen wir als Beispiel menschliche Zellen. Gerade weil wir aus vielen kleinen Einheiten (Zellen) bestehen, sind wir sehr belastbar. Zellen können bei Bedarf vervielfacht werden. Die Zerstörung einer Zelle ist kein Problem, da das System nicht von einer einzelnen Einheit abhängt. Zellen können ihren Zweck ändern und können wiederverwendet werden. Wenn wir verletzt werden, wird nur ein Teil unseres Systems (Körper) beschädigt, bald danach wird ein gesunder Teil unseres Systems die zerstörten Zellen heilen. Die Heilung selbst ist ein Prozess der Zerstörung und Replikation, nicht ein Versuch, kaputte Zellen zu reparieren.

Wir können uns Microservices als das Softwareäquivalent von Zellen vorstellen. Stell dir vor, wir Menschen wären einzellige Organismen wie monolithische Anwendungen. Was würde passieren, wenn diese Zelle zerstört wird? Wir würden sterben, weil wir nur einen einzigen Point of Failure hätten. Ein einzelliger Organismus zu sein bedeutet eigentlich, dass alles tödlich ist. Die Zusammensetzung aus vielen kleinen Einheiten ist sowohl für den menschlichen Körper als auch für Rechenzentren von Vorteil. Beide versuchen, resilient, elastisch und autark zu sein.

JAX – Die Konferenz für Java, Architektur- und Software-Innovation

DevOps-Soforthilfe in 5 Tagen

mit Bernd Rederlechner | T-Systems International GmbH

High Speed Scrum: Wie man in vier Monaten eine Messe digitalisiert

mit Konstantin Diener | cosee GmbH

Interview mit Christian Schneider zum Thema „DevSecOps“.

DevSecOps ist, bezogen auf Security-Checks, die logische Fortführung der Automatisierung im DevOps-Sinne

JAXenter: Wie funktioniert Selbstheilung technisch? Kannst du einmal ein Beispiel für einen Selbstheilungsmechanismus für Microservices geben?

Viktor Farcic: Selbstheilung ist einfach. Mit Auto-Skalierungs-Gruppen können wir die Infrastruktur in den meisten Fällen in den gewünschten Zustand bringen. Mit Schedulern (Swarm, Kubernetes, Mesos/Marathon) können wir das gleiche mit Services erreichen. Das einzig wahre Ziel der Selbstheilung ist es, dafür zu sorgen, dass sich das System (fast) immer im gewünschten Zustand befindet. Das Problem ist, dass der gewünschte Zustand ständig schwankt. Es reicht nicht aus, einem Scheduler die Anweisung zu geben, dass es fünf Repliken eines Dienstes geben soll. Wir brauchen ein System, das sich selbst anpasst. Ein solches System sollte z.B. die Antwortzeiten eines Dienstes überwachen und je nach Ergebnis den gewünschten Zustand ändern.

Zusammengefasst geht es bei der Selbstheilung um die Aufrechterhaltung des gewünschten Zustands, bei der Selbstanpassung um die Anpassung des gewünschten Zustands auf der Grundlage sowohl interner als auch externer Einflüsse.

JAXenter: Wie kann Docker helfen, Selbstheilungssysteme zu schaffen?

Viktor Farcic: Docker (und Container im Allgemeinen) stellen einen standardisierten Verpackungs- und Bereitstellungsmechanismus bereit. Das erlaubt es uns, alles, was wir wollen, in einen Container zu packen und dabei Eigenschaften wie Isolierung, Skalierbarkeit, etc. beizubehalten. Docker-Images sind Blaupausen, aus denen wir beliebig viele identische Container erstellen können. Diese Container kann man wieder mit menschlichen Zellen vergleichen.

JAXenter: Welche anderen Tools kannst du empfehlen, um resiliente Software zu entwickeln?

Viktor Farcic: Packer/Terraform sind eine gute Kombination von Werkzeugen, die es uns ermöglicht, unveränderliche Infrastrukturen aufzusetzen. Sie sind herstellerunabhängig und für den Einsatz in dynamischen Umgebungen konzipiert. Wenn CFEngine die erste Generation von Konfigurationsmanagement-Tools darstellen würde, wäre Chef/Puppet/Ansible die zweite. Heute tendieren wir zu Packer/Terraform, da sie besser für dynamische und unveränderliche Infrastrukturen geeignet sind. Wir können sie als Konfigurationsmanagement-Tools der dritten Generation bezeichnen.

Docker hat sich als Standard-Verpackungs- und Deployment-Mechanismus durchgesetzt. Das ist Geschichte. Die eigentliche Frage ist jetzt, welches Werkzeug für das Scheduling von Containern (Services) verwendet wird. Kubernetes ist in diesem Bereich führend, auch wenn ich persönlich eine gewisse Vorliebe für Swarm habe.

Prometheus ist wahrscheinlich die beste Wahl als Werkzeug, um Metriken und Alerts zu sammeln, die das System heilen und anpassen. Jenkins ist im Vergleich zu diesen Tools schon etwas älter, wurde in den letzten Jahren aber verjüngt und behauptet die führende Position als Task Executor.

JAXenter: Was ist die Kernaussage Deines Workshops?

Viktor Farcic: Die Menschen werden obsolet. Die Maschinen übernehmen.

Viktor Farcic is a Senior Consultant at CloudBees, a member of the Docker Captains group, and books author. He coded using a plethora of languages starting with Pascal (yes, he is old), Basic (before it got Visual prefix), ASP (before it got .NET suffix), C, C++, Perl, Python, ASP.NET, Visual Basic, C#, JavaScript, Java, Scala, etc. He never worked with Fortran. His current favorite is Go.His big passions are DevOps, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-driven Development (TDD).