{"id":38,"date":"2017-11-09T16:41:08","date_gmt":"2017-11-09T15:41:08","guid":{"rendered":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/?p=38"},"modified":"2022-11-30T16:41:38","modified_gmt":"2022-11-30T15:41:38","slug":"monolith-vs-microservices","status":"publish","type":"post","link":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/?p=38","title":{"rendered":"Monolith vs. Microservices &#8230;"},"content":{"rendered":"\n<p>\u2026 oder warum nicht jeder Monolith geschlachtet werden muss. Seit einiger Zeit ist der Hype ungebrochen, jedes monolithische System schnell zu ersetzen und jede Neuentwicklung als Microservice-Architektur zu realisieren (eventuell nicht jedes aber doch eine Vielzahl).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Problem Mensch<\/h2>\n\n\n\n<p>Aus meiner Sicht ist eines der Hauptprobleme in der Softwareentwicklung, dass nicht Vorhandensein von (geeigneten) Architekturregeln und deren Durchsetzung. Ob dies durch Fehler in der Entwicklung, mangelndes Know How oder fehlende Ressourcen f\u00fcr die Pr\u00fcfung der Einhaltung der Architektur verursacht wird, ist nicht relevant. Das Ergebnis ist ein schwer wart- und erweiterbares Softwaresystem. Dieses Ergebnis wird sich unabh\u00e4ngig von der Architektur einstellen. Bevor wir uns also Gedanken um den geeigneten Architekturansatz machen, ist sicherzustellen, dass es \u00fcberhaupt eine Architektur gibt und diese durch einen QS-Prozess auch abgesichert wird. Schlechte Software wird auch als Microservice nicht besser.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Pro und Kontra<\/h2>\n\n\n\n<p>Im Folgenden habe ich einige Pro- und Kontra-Punkte zu Monolithen und Microservices zusammengestellt.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In einem Monolithen sind die meisten Refactorings wesentlich einfacher und im Allgemeinen mit wenigen Aktionen in der IDE realisierbar.<\/li>\n\n\n\n<li>Reporting, Batchl\u00e4ufe und andere Aktionen, die aus vielen Quellen gespeist werden m\u00fcssen, sind bei Monolithen deutlich einfacher zu realisieren, da auf die zentralen Informationen des Gesamtsystems zugegriffen werden kann.<\/li>\n\n\n\n<li>Monolithen haben interne Abh\u00e4ngigkeiten, die gut erkennbar sind. Bei Microservices wird viel Komplexit\u00e4t in die Netzstruktur verschoben, die schwerer erkenn- und wartbar sind. Probleme von verteilten Systemen (Ausf\u00e4lle, Verl\u00e4sslichkeit von Knoten) k\u00f6nnen bei Monolithen nicht auftreten.<\/li>\n\n\n\n<li>Systeminterene Schnittstellen k\u00f6nnen bei Monolithen einfacher ge\u00e4ndert werden. Bei Microservices kommt hier Consumer-driven Contracts (z.B. https:\/\/jaxenter.de\/microservices-consumer-driven-contract-testing-mit-pact-20574) f\u00fcr die Verbesserung der Situation zum Einsatz.<\/li>\n\n\n\n<li>Durch statische Codeanalysen l\u00e4sst sich bei einem Monolithen die Gesamtarchitektur besser pr\u00fcfen, als bei Microservices. Insbesondere Gesamtsystempr\u00fcfen mit jQAssistant und \u00e4hnlichen Tools sind hier einfach automatisierbar. Automatische und manuelle Pr\u00fcfungen der Architektur sind die Basis f\u00fcr gute Codequalit\u00e4t und damit effizientes Arbeiten an dem Prosukt.<\/li>\n\n\n\n<li>Bei dem Thema Konsistenz liegt aus meiner Sicht der Monolith klar vorne. Er hat eine einheitliche Datenbasis, die bei guter Umsetztung die Konsistenz ohne zus\u00e4tzlichen Aufwand garantiert und im Allgemeinen durch Cluster auch gut skalieren kann. Microservices m\u00fcssen hier auf Eventual Consistency (Achtung nicht eventuell, sondern letztendlich) setzen (Monolithen k\u00f6nnten dies auch), wenn das Konzept der Trennung nicht durch eine einheitliche DB gebrochen werden soll. Der Preis daf\u00fcr ist, dass einiges an Code f\u00fcr die Sicherstellung der Konsitenz und ggf. dem manuellen Rollback von verteilten Transaktionen investiert werden muss. Dies sollte man sich genau \u00fcberlegen, wenn in der Anwendung nicht ein so &#8222;einfaches&#8220; Modell wie beispielsweise bei Netflix eingesetzt wird. Betriebliche Anwendnung haben im Allgemeinen stark abh\u00e4ngige Daten. Wenn diese nicht mehr konsistent sind, sind die Abl\u00e4ufe gef\u00e4hrdert und alle Folgesystem wie DWHs k\u00f6nnen nicht korrekt arbeiten.<\/li>\n\n\n\n<li>Monolithen in Verbindung mit Architektur- und Toolvorgaben machen es einfach, die Anzahl der verwendeten Technologien zu reduzieren. Die Verwendung von weniger Technologien bedeutet, dass viele Teammitglieder an verschiedenen Stellen mit geringer Einarbeitungszeit eingesetzt werden k\u00f6nnen. Es ist im Allgemeinen f\u00fcr die Wartbarkeit eben kein Vorteil, wenn jeder Microservice einen eigenen Technologie Stack hat. Dies sollte nur geschehen, wenn es deutliche Vorteile gibt.<\/li>\n\n\n\n<li>Bei einem guten Design und guter Umsetzung ist auch ein Monolith modular aufgebaut. Ein gutes Design und Pr\u00fcfung der Einhaltung hierf\u00fcr ben\u00f6tigen beide Architekturen.<\/li>\n\n\n\n<li>Einige Artikel beschreiben es als Vorteil, dass nicht gelungene Microservices \u201eweggeworfen\u201c werden k\u00f6nnen. Bei einem guten, modularen Aufbau eines Monolithen k\u00f6nnen ebenfalls Teile ausgetauscht werden. Grunds\u00e4tzlich f\u00f6rdert eine solche Argumentation aber \u201eschlechte\u201c Software und ich kenne wenige zahlende Kunden, die einer solchen Argumentation \u00fcberhaupt folgen wollen.<\/li>\n\n\n\n<li>Domain-Driven-Design ist in beiden Welten umsetzbar.<\/li>\n\n\n\n<li>Achtung bei Microservices, die \u00fcber Datenbanken integrieren oder die Modelle anderer Services direkt weiterverwenden, da in solchen F\u00e4llen kein klarer Bounded Context vorliegt und somit ein Pro von Microservices weniger stark greift.<\/li>\n\n\n\n<li>Monolithen haben das Problem, dass die Stabilit\u00e4t eines Moduls, sich auf das ganze System auswirken kann. Abgeschw\u00e4cht gilt dies auch f\u00fcr Microservices, wenn abh\u00e4ngige Dienste instabil laufen.<\/li>\n\n\n\n<li>Die physikalische Verf\u00fcgbarkeit kann in beiden F\u00e4llen durch Replikation (Cluster von Application Servern bzw. einzelner Schichten oder Servicereplikation) erreicht werden. Dies ist bei Microservices deutlich einfacher. Au\u00dferdem k\u00f6nnen Microservices gut \u201ebei Bedarf\u201c skalieren. Aber auch Monolithen k\u00f6nnen durch Clusterbildung gut skalieren &#8211; nur eben nicht dynamisch.<\/li>\n\n\n\n<li>Die Skalierbarkeit der Entwicklerteams ist bei Microsrvices besser, da es weniger Abh\u00e4ngigkeiten in der Codebasis gibt. Andererseits verz\u00f6gern Schnittstellenabsprachen das Vorgehen, so dass aus meiner Sicht mit guter Qualit\u00e4tssicherung beide Architekturen in gewissen Ma\u00dfen skalieren.<\/li>\n\n\n\n<li>Microservices neigen zur Codeduplizierung mit all ihren Nachteilen.<\/li>\n<\/ul>\n\n\n\n<p>Aus meiner Sicht gibt es Anwendungsklassen, bei denen Microservices insbesondere ihren Skalierungsvorteil klar ausspielen k\u00f6nnen. Gerade im Web-Systemen mit vielen Nutzern und \u00fcberschaubaren Abl\u00e4ufen funktioniert dies pr\u00e4chtig. Bei vielen sogenannten betrieblichen Anwendungen ist ein gut strukturierter und qualit\u00e4tsgesicherter Monolith meistens besser f\u00fcr die Zielerreichung. Wenig Komplexit\u00e4t in den Kommunikationsstrukturen erleichtern die Erweiterbarkeit. In vielen F\u00e4llen ist es effektiver in Softwarearchitektur und den Abbau technischer Schulden zu investieren, als ein ungeeignetes System in Microservices aufzuteilen. Wir werden sehen was die Zukunft bringt &#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u2026 oder warum nicht jeder Monolith geschlachtet werden muss. Seit einiger Zeit ist der Hype ungebrochen, jedes monolithische System schnell zu ersetzen und jede Neuentwicklung als Microservice-Architektur zu realisieren (eventuell nicht jedes aber doch eine Vielzahl). Problem Mensch Aus meiner Sicht ist eines der Hauptprobleme in der Softwareentwicklung, dass nicht Vorhandensein von (geeigneten) Architekturregeln und [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-38","post","type-post","status-publish","format-standard","hentry","category-softwarearchitektur"],"_links":{"self":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/38","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=38"}],"version-history":[{"count":1,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/38\/revisions"}],"predecessor-version":[{"id":39,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/38\/revisions\/39"}],"wp:attachment":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}