Microservices sind doof – sagt Amazon?! // deutsch

Was ist die bessere Architektur? Microservices oder Monolithen? Über diese Frage diskutieren zahlreiche Entwicklerinnen und Entwickler seit Jahren. Nun gießt Amazon Öl in den lodernden Streit: Ein neuer Blogpost sorgt für Aufruhr, denn anscheinend bevorzugt Amazon für ihren Dienst Prime Video neuerdings Monolithen und kehrt Microservices den Rücken zu. Doch was steckt wirklich dahinter? Ist so einfach zu sagen, "Amazon findet Microservices doof"?

00:00 – Einleitung
01:57 – Um was geht es überhaupt?
03:23 – Die bisherige Architektur
04:31 – Zu aufwändig und zu teuer
05:36 – Warum wurde diese Architektur gewählt?
06:56 – Die neue Architektur
08:07 – 9.994 Legobausteine
09:32 – Was mich daran ärgert
10:36 – Die passende Architektur

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[FamilieHausGarten]

"Microservices sind nicht per se falsch, Monolithen sind nicht per se richtig. Umgekehrt gilt das gleiche" 👍

[joga]

Ich hab schon einige Videos zu dem Thema gesehen und fand deine Aufarbeitung sehr gut.😊
Als ich es gelesen habe, ist mir vor allem aufgefallen, wie viel simpler die neue Architektur ist. Komplexe Architekturen kommen meiner Erfahrung nach eher von Vorgaben, als mit Begründungen und das trifft sowohl auf Monolithen als auch auf Microservices zu.

[janbohlen]

Wieder ein echt tolles Video. Wahnsinn, wie sachlich und angenehm ruhig ein Mensch bei dieser unsäglichen Diskussion bleiben kann 👍

[anion]

Ob Microservices oder monolithische Architekturen sinnvoller sind, hängt finde ich immer ganz vom Anwendungsfall und von den Anforderungen hinsichtlich Skalierbarkeit usw. ab.
Ich dachte schon ich bin allein und veraltet mit der Ansicht, dass Microservices zumindest nicht pauschal immer die beste Lösung sind. Ich bin bei Microservice-Architekturen tatsächlich meistens eher skeptisch, was aber nicht heißen soll, dass ich sie schlecht reden möchte.
Danke für das Video! Ich kann deine Aufregung aber auch sehr gut verstehen.

[GoreCode]

Super Video 👍
Ich kann noch nicht mit viel Erfahrung glänzen, bin erst am Anfang meiner Entwicklerkarriere. Aber ich hab durch Zufall ganz am Anfang ständig gelesen Microservice sind besser als Monolithen - noch bevor ich wirklich was damit anfangen konnte.
Jetzt bin ich in einer fünf tätig, wo meine Abteilung auf Microservice setzt und die Kollegen in der Nachbarabteilung auf Monolithen. Ich sehe das zwar mittlerweile ähnlich wie du, es kommt immer darauf an - aber ich bin froh das wir bei uns Microservice einsetzen, weil man so an mehreren Services arbeiten kann und sich weniger oft durch merge Konflikte auf die Füße tritt (bei den Kollegen öfter zu hören). Mal sehen was die Zeit so bringt.

[abergy]

Wenn mir demnächst jemand von dem Blog-Post erzählt, verweise ich einfach auf dein Video. Danke Golo und bis zum nächsten Mal! ;)

[devchannel]

Also der Klassiker in der Programmierung. Ein Prototyp wird Produkt xDDD - jetzt bin ich beruhigt, dass es auch Tech-Giganten so geht.

[lou]

Auf HN und reddit hab ich die reißerischen Headlines mitbekommen, dass der Monolith jetzt doch die Zukunft sei. Allerdings kam mir das etwas verdächtig vor und nach dem Lesen des Artikels war auch sofort klar, dass man eben doch nicht so pauschal Schlüsse ziehen kann 👏

[boredbytrash]

Das problem ist, dass Microservice Architektur nicht die Lösung für jedes Problem ist. Das sollte jetzt auch dem letzten überambitionierten Dev und Architekten bewusst sein.

Was Amazon da mit seinem Video Audio Monitoring gemacht hat, ist ja extremst overengineered und krank. Deshalb super, dass die wieder auf den Boden der Tatsachen geholt wurden.

Microservice Architektur ist auch ein organisatorisches Thema. Wenn ich nur ein Team habe, und sie nur eine Domäne betreiben, warum sollte man jetzt 20 Services bauen, die alle hart gekoppelt sein und somit nur einen verteilten Monolithen darstellen?

Einen Monolithen über mehrere Teams zu verteilen, ist genauso schwachsinnig.

—> Microservice Architektur: JA, aber nur wenn es erforderlich ist (100% entkoppelter und „fault-tolerant“ Service, der wirklich auch skalierbar weil muss) ODER wenn es die Organisationsstruktur unterstützt.
Aber aus Prinzip 20 AWS Services und mehrere microservices weil es ach so modern ist oder mir von meinem AWS Partner Architekten so vorgeschlagen wird, ist ein No Go.

[Erik_Fa]

Ich habe den Artikel gelesen und mir hat er gut gefallen. Der Titel war etwas clickbaity aber der Inhalt ist ein schönes Beispiel für the right tool for the right job. Zu Beginn meiner Karriere als SW-Entwickler bin ich auch Feuer und Flamme für Microservices gewesen, mittlerweile betrachte ich das Thema aber etwas differenzierter. Microservices erzeugen einen nicht unerheblichen Mehraufwand und erzeugen zusätzliche Komplexität. Da sollte man dringend abwägen, ob dies gerechtfertigt ist oder ob eine andere Architektur nicht die bessere Wahl ist.

[rniestroj]

Ich freue mich über den Artikel und das er hoffentlich einige Leute von der Microservices Palme bringt. Habe in den letzten 6 Jahren in 3 Microservices Projekten gearbeitet. Alle davon waren möchtegern Microservices Projekte. Entwicklerfreundlichkeit null. Komplexität level 10000. Alle Bad Practises angewendet. Jeder was frustiert vom Kunden bis zum Entwickler. Nur der Architekt grinste. Ich könnte weiter ausführen aber merke das ich mich auch ärgere.

[omegapirat]

Das wichtigste bei einer Microservice-Architektur ist halt das Schneiden der Services.
Es kann durchaus passieren, dass man Services schlecht schneidet und dann Dinge in getrennten Services laufen lässt, die besser in einem Service vereinigt gehören. So war das wahrscheinlich auch beim ersten Entwurf des hier besprochenen Amazon Services

[dominikn]

Ich beweg mich in einem Anwendungsumfeld, wo viele viele viele auf Monolithen setzten. Wir setzten schon immer auf Microservices und uns ist viel erleichtert hinsichtlich Skalierung. Zum Glück aber noch nicht in diese Diskussion geraten, wo der blogpost relevant war. Coole Aufarbeitung, Speicher ich mir mal ab, falls der Blogpost mal zu sprechen kommt, dann muss ich selber nichts erklären 😅

[micknamens]

Ich finde das Plug-in Konzept für Modularität gut, als leichtgewichtige Alternative zu Microservices. Wenn man in der selben Sprache bzw. Ausführungsplattform (JVM, Nodes oder C) bleibt (was Vorteile hat), kann man unabhängige Projekte haben, die als Abhängigkeiten dann zur Laufzeit zu einem "Monolithen" integriert werden. Dies erlaubt Polymorphismus auf Komponentenebene. Man braucht aber (versionierte) Deklarationsdateien (ähnlich den C header files) um client und service code konsistent zu halten.

[DynamicSun]

wegen solcher Videos, mag ich diesen Kanal :-) thx

[nitrovent]

Derek Comartin von CodeOptinion sieht an der Stelle noch nichtmal, dass es vorher ein Microservice war und jetzt nicht mehr, sondern vielmehr nur die Architektur eines Services von verteilt auf in-process geändert wurde, da der Kontext/die Aufgabe des Services sich nicht verändert hat. Das passt gut zu einer domänenorientierten Definition von einem Service, wie ich finde.

[TheGamestime]

Tolles Video hat es auf den Punkt gebracht. 2 Anmerkungen:
1. nur eine kleine Randbemerkung aber hat es sich bei den Streams nicht tatsächlich um livestreams gehandelt statt allen Prime Video Streams.
2. Ich finde das Problem ist nicht mal die Architektur sondern das Grundprinzip des Dienstes. Den gesamten Stream als Video Stream in ein Dienst zu laden klingt irgendwie extrem umständlich. Gibt der Browser nicht ohnehin Metadaten über verschluckte Pakete etc, ?

[marcotroster]

Bei Rechenzentrumsanwendungen geht es um Performance und Skalierung. Dass eine Lösung, die viel weniger Daten zwischen den einzelnen Services hin und her schicken muss, natürlich viel besser performt, ist ja nicht weiter verwunderlich. Datenlokalität ist im Rechenzentrum nunmal ne entscheidende Sache, die man beim Design unbedingt beachten sollte. Das spart Geld und hilft dem Klima.

Aktuell gibt es halt den Ressourcenfluch, dass selbst die dummen Ideen aufgrund der extrem leistungsfähigen Hardware nicht mehr automatisch aussortiert werden. Dann wird eine "wirtschaftliche" Entscheidung getroffen, dass man bewusst eine ineffiziente Lösung anstrebt, weil man sich nicht die Mühe machen will, es ordentlich zu programmieren. Das finde ich einen gefährlichen Trend.

[christianbaer]

Ich finde, dass die viel spannendere Tatsache sowohl im Blogpost und natürlich auch in der "Verwertungs" völlig unter den Tisch fällt. Die haben ihre Anwendung genommen und komplett anders aufgezogen. Ohne große Probleme. Im Hintergrund. Hat niemand gemerkt. Wie gut muss die Architektur des Codes gewesen sein, damit das so geht? Darum geht es nämlich wirklich in der Softwareentwicklung. Software muss änderbar sein. Das haben sie offensichtlich gut hinbekommen.

[BenjaminWagener]

Das Problem war bzw. ist hier ja nicht nur, dass der Prozess wohl nicht nur ineffizient konstruiert war, sondern auch die Kostenstruktur bei AWS, wo teilweise Kosten aufgerufen werden, wo technisch betrachtet eigentlich keine oder zumindest keine so hohen Kosten entstehen. Wenn innerhalb eines Rechenzentrums Server untereinander kommunizieren verursacht das doch so gut wie keine laufenden Kosten für die Server-Betreiber. Das Problem ist hier also auch die Gier von AWS an sich, was wiederum aufzeigt, dass nicht unbedingt ineffiziente Microservicestrukturen im Betrieb Kosten verursachen, sondern die Nutzung von überteuerten Cloud-Strukturen.