Mehr gesunder Menschenverstand in der Software-Entwicklung

Vom Monolithen zum Microservice

Mete Atamel

Mete Atamel

Mete Atamel, Developer Advocate bei Google und Sprecher auf der JAX 2017, erklärt in diesem Artikel, wie sich die klassischen Monolithen zu Microservices weiterentwickelt haben und wie es durch Microservices möglich wird, den Anforderungen unserer vielfältigen Umgebungen gerecht zu werden.

Ich erinnere mich noch an die alten Tage, in denen wir alle unsere Module in eine einzelne Anwendung gepackt haben – unseren Monolithen. Dann wurde alles auf einmal deployed und fertig war unsere sogenannte „Enterprise-Anwendung.“ Es hat sich, das muss ich zugeben, irgendwie gut angefühlt, als ich den Begriff der „Enterprise-Anwendung“ zum ersten Mal gehört habe. Mein kleines Modul war plötzlich gar nicht mehr so klein, sondern Teil von etwas Größerem und Wichtigerem! Das dachte ich zumindest. Es gab zwar jede Menge Konventionen und einen Overhead, der durch die Arbeit nach diesem Enterprise-Modell entstand – das war aber nur ein kleiner Preis, den wir für Konsistenz bezahlen mussten. Oder?

Dieses Modell hat für kleine Projekte mit einer geringen Zahl an Modulen funktioniert. Als die Projekte aber größer wurden und die Anzahl an beteiligten Teams und Modulen wuchs, wurde mir klar, dass der monolithische Ansatz nicht mehr skalierbar ist. Das hatte eine Reihe von Gründen:

  1. Die Integration war deutlich zu schwierig. Um eine einzelne Anwendung zu erstellen, mussten wir eine Menge Module zusammenfügen. Das war nicht nur eine durchaus komplizierte Sache, sondern fand auch zu spät im Release-Zyklus statt. Darum haben wir unsere vollständig integrierten Anwendungen so spät im Entwicklungszyklus nicht mehr wirklich durchgehend getestet. Die zur Integration notwendige Zeit hat ständig Stress ausgelöst. —
  2. Definitiv nicht agil. Man musste immer darauf warten, dass auch das langsamste Modul fertig entwickelt worden war, bevor irgendein Modul veröffentlicht werden konnte. Das war überhaupt nicht agil.
  3. Debuggen war viel zu schwer. Ich konnte mein Modul zwar einzeln debuggen; das Debuggen der gesamten Anwendung als Ganzes, mit allen Modulen, war allerdings so gut wie unmöglich. Der Quellcode der anderen Module war mir nicht zugänglich, und die gesamte App war am Ende so groß, dass ich sie auf meinem Laptop ohnehin nicht ausführen konnte.
  4. Inkonsistente Umgebungen. Auf meinem Laptop hat alles gut funktioniert, aber die Produktionsumgebung war schon immer ein wenig anders. Dort entstanden dann Fehler, die kaum vorhersehbar und schwer zu lösen waren.

In den letzten Jahren ist nun aber einiges passiert, das zur Lösung dieser Probleme beigetragen hat. Man kam in der Branche zu der Erkenntnis, dass Monolithen nicht skalierbar sind; es gab einen Wandel hin zu kleineren, handlichen Microservices. Das hat die Probleme mit der Integration, dem Debuggen und der Agilität gelöst. Docker hat ein konsistentes Umgebungsmodell für diese Microservices zur Verfügung gestellt und hat somit das Problem der Inkonsistenz gelöst.

Ich habe das Gefühl, dass wir etwas gesunden Menschenverstand in die Softwareentwicklung zurückgebracht haben!

Wir mussten allerdings erst noch die Schwierigkeiten lösen, die mit der Verwendung von Containern in der Produktion einhergehen: Nodes für Container vorhalten; Container in Gang setzen; verlässliche Strategien für Rollouts und Rollbacks entwickeln; Health Checks und all die anderen Dinge schreiben, die man braucht, um Software in der Produktion auszuführen.

Zum Glück entstanden dann aber Open Source Container-Management-Plattformen wie Kubernetes. Kubernetes stellt uns ein High-Level API zur Verfügung, das genutzt werden kann, um Deployments zu automatisieren, Rollouts/Rollbacks zu managen und hoch und runter zu skalieren. Das Beste an Kubernets ist aber, dass es überall läuft, sowohl auf dem eigenen Laptop als auch in der Cloud, und dabei mehrere Clouds zugleich umfassen kann, sodass man nicht an eine Plattform gebunden ist.

Im Ergebnis habe ich das Gefühl, dass wir etwas gesunden Menschenverstand zurück in die Entwicklung und den Betrieb von Software gebracht haben. Und das ist ja immer eine gute Sache!

Mehr Beiträge von Mete Atamel auf seinem Blog unter https://meteatamel.wordpress.com/

Geschrieben von
Mete Atamel
Mete Atamel
Mete Atamel is a Developer Advocate at Google, currently focused on helping developers with Google Cloud Platform. Prior to Google, he worked as a Software Engineer at Microsoft, Skype, Adobe, EMC, and Nokia building apps and services using various web, mobile and cloud technologies.
Kommentare
  1. Vom Monolithen zum Microservice – JAXenter – Powerblogger – Aktuelle Nachrichten2017-05-12 10:09:45

    […] JAXenter […]

  2. Vom Monolithen zum Microservice – JAXenter – BB-10 – Aktuell2017-05-12 10:21:04

    […] JAXenter […]

  3. TestP2017-05-12 18:39:38

    Hi,

    und sorry aber Punkt 3 und Punkt 4 empfinde ich jetzt irgendwie als sehr konstruierte Argumente.

    Dass ein fetter Monolith schwer zu debuggen ist, ja das kann sein. Mit Microservices kann man das Gesamtsystem noch viel weniger debuggen. Die Wahrscheinlichkeit keinen Zugriff auf den Sourcecode der anderen Microservices zu haben ist noch viel höher. Und wenn diese noch einer anderen Programmiersprache geschrieben wurde dann gute Nacht. Sprich, der Autor empfindet es als Erleichterung etwas überhaupt nicht mehr zu können was vorher schwer ging.

    Und Punkt 4 sieht für mich eher nach "Ich habe eine Anwendung mit einer vermurksten Architektur, die nur auf meinem Laptop richtig läuft. Wenn ich das ganze Gedöns aber in einen Container packe und das so ausliefere dann fällt das gar nicht auf." Sprich, technische Schulden noch und nöcher und spätestens wenn irgendwo ein Update fällig wird könnte es knallen.

    Grüße

  4. Chris2017-05-15 10:19:03

    Da muss ich TestP Recht geben.
    Punkt 3 und 4 sprechen eher gegen Microservices, weil schwer zu debuggen und gar nicht einheitlich. Es wird immer Unterschiede zwischen produktiv und test geben und Microservices machen alles wesentlich komplexer. Der Schritt muss sehr gut überlegt sein, ob es sich lohnt auf Microservices zu wechseln.

  5. TestQ2017-05-16 02:04:05

    @TestP und Chris
    Dem muss ich widersprechen. Gerade Punkt 3 und 4 sind die Vorteile von Microservices. Die Fehler erkennt man leichter, da idealerweise die Services zum einen unabhängig voneinander sind und zum anderen möglichst wenig Funktionalitäten haben.
    Durch Docker wird außerdem die Konfiguration der Betriebsumgebung zum großen Teil in die Entwicklung verlegt. Während man also vorher auf die Konfiguration eines Administrators angewiesen war, und hoffen musste das alls richtig eingestellt ist, so kann man in einem Docker-Container alles schon vor konfigurieren. Der Container läuft dann genauso auf dem lokalen Rechner wie im Betrieb.

    Punkt 1 und 2 hingegen hält sich meiner Meinung nach die Waage, je nach definierter SW-Architektur. Und Ja, der Vorteil von Microservices ist, dass man sich mehr auf die Anforderungen konzentriert und eventuelle technische Schulden in Kauf nimmt. Diese sind aber nicht so teuer als bei einem Monolithen.
    Ohne einen guten Architekten bringt das alles aber auch nichts ;)

  6. TestW2017-05-18 08:25:55

    @TestQ
    Microservices sind hauptsächlich aus Skalierungsgründen (technisch und team bezogen) trendy. Benötigt man keine solche, haben Microservices mehr Nachteile als Vorteile. Insbesondere Performance und Komplexität.

  7. TestP2017-05-18 08:46:26

    @TestQ

    3 und 4 sind nicht unbedingt Vorteile von Microservices. Denn das kann man mit Monolithen auch haben. Einen Monolithen kann man ebenfalls intern modular gestalten und man auch Docker damit nutzen. Deshalb wirken die Argumente 3 und 4 sehr konstruiert auf mich.

    Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.