Monolithen vs Microservices // deutsch

[@iham1313]

Fazit für jedes konzept: es kommt drauf an - old news, but important.

[@k3v1n0x90]

Ich arbeite seit ca. 2,5 Jahren in einer microservice Architektur und habe vorher an einem relativ großen Monolithen gearbeitet. Ich persönlich finde das speziell das debugging in einer microservice Architektur viel aufwendiger ist als bei einem Monolithen. Auch ist die Koordination von Übergreifenden Features etwas aufwendiger da hier die Schnittstellen erst festgelegt werden müssen (vor und Nachteil). Beim Monolithen finde ich hat man oft das Problem das die Struktur irgendwann verwässert wenn man nicht mit Tools wie archunit oder ähnlichem gegensteuert.

[@thenativeweb]

[gr] Ja, die Fehlersuche ist viel aufwändiger, das stimmt. Und ja, das Verwässern ist beim Monolithen tatsächlich ein Problem 😉 Am Ende hilft da nur Disziplin und immer dran bleiben, aber das ist ja auch generell in vielen anderen Bereichen hilfreich.

[@christianfaust5141]

Danke für sehr guten und aufgeregten Vergleich zwischen Monolithen und Microservices. Ich sehe die Teamgröße als kritisch an. Im Idealfall gibt es pro Domäne ein separates Software Team, das ist aber oft leider nicht gegeben.

[@MarkusH87]

Beruflich programmiere ich Plugins für ein bestehendes Produkt - da bin ich insofern etwas eingeschränkt. Allerdings sind diese vom Prinzip her eigentlich Monolithen. Privat entwickle ich immer mal wieder verschiedene Dinge - meist auch Monolithen. Aus 2 Gründen: 1. Da ich alleine daran Entwickle, ist es nicht nötig, auf verschiedene Entwickler aufzuteilen, was mit Microservices aus meiner Sicht einfacher geht 2. Microservices benötigen meiner Meinung nach, initial mehr "Abstimmung", dass die Schnittstellen definiert werden - das mag im professionellen Rahmen bei ausreichender Teamgrösse/Erfahrung funktionieren, aber viele Teams würden daran wohl auch scheitern.

[@MrCschoeneich]

Was sind das eigentlich für schöne LED Lichter im Hintergrund ?

[@thenativeweb]

[gr] Das sind die hexagonalen LED-Platten von Nanoleaf 😊

[@DogzDeDoggy]

Ich finde neben Kenntnisse über Vor-/Nachteile von Monolithen und Microservice ebenso wichtig, Kenntnisse über technischen/fachlichen Engstellen zu haben, so dass man die zu skalierenden Bereiche schon früh identifizieren kann und die Anzahl der Microservice so gering wie möglich und so hoch wie nötig zu halten. Wenn man den Monolithen schon gut entwickelt hat, fällt es meist leicht nach und nach die zu skalierenden Teilen in Microservices auszulagern - dann braucht man die Migrationsstrategien. Darüber hat Sam Newman ein Buch geschrieben und zB hier einen Vortrag gehalten. kzbin.info/www/bejne/b3qceJeJhpaVmK8 Auf der anderen Seite sollte man sich nicht zu schade sein, Microservices zu reduzieren/zusammenzufassen. Vielleicht macht es Sinn, aus 80 Services nur 4 zu machen, wenn man nur dort Skalierbarkeit benötigt. Für Release Zyklen und das zusammenbringen der verschiedenen zusammengefassten Services benötigt man ebenfalls kluge Strategien, um die unabhängige Entwicklung zu gewährleisten. Also viele verschiedene Technologien sprächen dem zum Beispiel entgegen. Auf der anderen Seite muss man betrachten, ob sich mit "beste Technologie für jeden Service" aussuchen überhaupt einen Gefallen tut, was je nach vorhandenem know-how ja auch schwierig sein kann.

[@kyrospace]

Monolith und MicroService sind in meinen Augen die beiden extrem Fälle oder Enden. Gibt es auch irgendetwas sinnvolles dazwischen? Mischformen?

[@thenativeweb]

[gr] Das wäre dann im Prinzip das klassische Client-Server, denn auch dort kann man ja durchaus skalieren - wenn auch nicht so gut und so extrem wie bei Microservices. Was sich davon jeweils anbietet, hängt natürlich von der konkreten Anwendung ab.

[@valeridause]

Danke für das Video. Hier ist meine Anmerkung zu der Gegenüberstellung von Microservices vs. Monolith. Nicht umsonst stellt man fest, dass Microservices nicht das sind, was sie versprochen haben. Nein, wo es Sinn macht, habe sie ihre da-sein-Berechtigung. Doch, wenn sie herauskamen als Idee, dann hat man sie als alternativlos zu dem Monolith positioniert. Und diese Übertreibung ging nach Hinten los. Genau das Gleiche passiert gerade mit der Methode Agile. Auch sie positioniert sich als alternativlos zu dem Wasserfall. Und das soll niemandem interessieren, dass im absoluten Wasserfall seit 40 Jahren kein Mensch mehr Projekte durchführt. Für die Positionierung muss man so tun, als ob Agile alle Probleme löst. Und überall stellt man fest, dass dies nicht der Fall ist. Und das Einfachste, was sofort als Erklärung kommt - ihr wendet Agile nicht richtig an. Genauso wie mit dem erhöhten Aufwand bei den komplexen Microservice-Architekturen. Ihr habt die Microservices falsch entworfen. Wenn aber verstanden wird, dass solche Sachen wie Microservices, Agilität usw. nicht alleinige Methoden sind, sondern Teil von der Familie der guten Ideen, dann wird es viel einfacher sein. Doch, wer will das so "komplex" denken. Lösungen müssen "einfach" klingen und das machen die Vertreter von solchen Trend "sehr gut". Es entsteht so was wie cargo-Kult drum herum. Um Microservices weniger, um Agile - kaum auszuhalten. Nur meine private Meinung. Danke für das Video. Sehr gut die Gegenüberstellung und die Aussicht auf Zukunft dargestellt.

[@simonsays6907]

sehr schön gesagt. Wir müssen jetzt auch nach Scrum aka Skröm arbeiten. aber hauptsache noch vms anstelle von Container für Webapps mit starken Zugriffsschwankungen verwenden, copy paste Jobs erledigen, den Storage von Caches manuell löschen wenn sie vollaufen 😅 und Leute die Automatisierung Vorantreiben aus der Firma ekeln.

[@valeridause]

@@simonsays6907 arbeitest du in der selben Firma, wo auch ich bin? #Ironie Ich habe in der letzten Zeit 5 Menschen weg von uns gehen sehen, die mit dieser Art niemals ein Frieden schließen könnten, jedoch sehr gute und erfahrene Spezialisten sind. Ich schaffe irgendwie mich dem auszuweichen. Wie lange, weiß kein Mensch

[@simonsays6907]

@@valeridause bin übrigens auch nicht mehr laamge dort. Ists ne Bundesbehörde dann vielleicht. Aif jedenfall nie wieder zum Bund wenn man Sinn in seiner Arbeit sucht

[@k3v1n0x90]

Das man auch mit einem Monolithen ziemlich weit kommen kann sieht man finde ich persönlich auch ganz gut an Shopify.

[@thenativeweb]

[gr] Leider kann ich zu Shopify nicht wirklich etwas sagen - hatte ich noch nie mit zu tun 🤷‍♂️

[@k3v1n0x90]

Ich meinte das eher aus Unternehmenssicht, die sind ja nicht unerfolgreich shopify.engineering/shopify-monolith

[@thenativeweb]

@@k3v1n0x90 [gr] Ach soooo 😊