Microservices sind doof - sagt Amazon?! // deutsch

[@FamilieHausGarten]

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

[@thenativeweb]

[gr] Jep 😊

[@joga9665]

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.

[@janbohlen8488]

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

[@thenativeweb]

[gr] Vielen lieben Dank 😊

[@abergy87]

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! ;)

[@thenativeweb]

[gr] Haha, klingt nach einem Plan 😊

[@devchannel5232]

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

[@anion21]

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.

[@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.

[@lou1134]

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 👏

[@DynamicSun]

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

[@thenativeweb]

[gr] Danke schön 😊

[@micknamens8659]

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.

[@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.

[@dominik48n12]

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 😅

[@geeksy2278]

Aus der Diskussion bei Twitter und co bin ich nicht schlau geworden. Bei dir schon, danke Golo!

[@thenativeweb]

[gr] Das ist schön, das freut mich 😊

[@omegapirat8623]

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

[@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. kzbin.info/www/bejne/p5_HhIueoNOriMU

[@marcotroster8247]

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.

[@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,?

[@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.

[@christianbaer2897]

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.

[@thenativeweb]

[gr] Ja, das stimmt. Wobei das IMHO weniger eine Frage der Architektur ist, sondern schlichtweg von gutem Schnittstellen-Design (sprich API-Design). Solange es für einen Teilbereich einer Software eine wohldefinierte Schnittstelle gibt, über die sämtliche Kommunikation läuft, und diese Schnittstelle fachlich und nicht technisch gedacht ist, kann man im Prinzip jede Implementierung immer gegen eine andere austauschen, ohne dass man das von Außen bemerkt. Das Kunststück ist ja letztlich nur, den jeweiligen Teilbereich als Blackbox anzusehen und ihn entsprechend zu behandeln.

[@chrisrue3470]

Ich hab den Artikel gelesen und mich auch aus den von dir genannten Gründen aufgeregt. Ich frage mich warum Menschen es so lieben dinge in Schubladen zu verstauen, vermutlich weil es einfacher ist. Bei Skripten oder OOP kann ich auch nicht sagen das eine is *immer* besser.

[@sirfakealot5041]

Kann man das Problem das Amazon hatte nicht dadurch erklären, dass die deren Services zu klein geschnitten haben? Sprich QA ist ja jetzt 1 statt 3 Services. Im großen Prime Video Kontext ist ja, wie im Video erwähnt, immer noch eine Microservice Architektur vorhanden

[@thenativeweb]

[gr] Ja, darauf läuft es letztlich hinaus … es war vielleicht etwas *zu* feingranular.

[@_marlak_]

Wer kennt es nicht.. man sagt dem Kunden, egal ob nun intern oder extern, dass etwas nur ein PoC ist... sobald das Ganze aber gut genug ist, Umsätze zu erwirtschaften ist es auf einmal "stable". Aus Sicht des Kunden nachvollziehbar, aus Sicht der Entwickler könnte man im Hinterkopf behalten, dass ein PoC nicht zu gut bzw. zu nach an einer stabilen Version sein sollte. Die tchnischen "Schulden" sind sonst direkt zum Start ggf. viel zu hoch. So zumindest meine Meinung, als ehemaliger Dev und heutiger Product Owner.

[@DJTechnostyler]

Microservices sind ne tolle Sache, wenn man sie denn richtig erstellt. Es kann ganz schön kompliziert sein die Fachlichkeit sauber zu trennen. Gleiches gilt für die technische Umsetzung, wobei man da den Vorteil hat, dass man einfach denken muss, dass man jetzt eine kleine Software schreibt, die eine API anbietet und die API einer anderen Software nutzt. Bei der Fachlichkeit ist das leider nicht so. Je nach Umfeld kann es sein, dass mehrere Domänen die gleichen Abhängigkeiten haben oder sogar zirkuläre Abhängigkeiten. Da kann man schon mal nen Knoten im Kopf bekommen. Das ist auch der Grund, weshalb ich mich mit Microservices nach wie vor schwertue. Bei Monolithen fällt dieses Problem weg, was die Entwicklung deutlich einfacher und damit auch schneller machen kann. Davon abgesehen haben auch Monolithen kleine "Microservices". Die nennt man dann nur Jobs. Also kleine Prozesse, die im Hintergrund gestartet werden und dinge erledigen, die viel Zeit in Anspruch nehmen, die aber nicht sofort antworten müssen, sondern einfach nur irgendwann, wenn überhaupt.

[@StefanStrobl]

Die Kunst ist es halt richtig zu schneiden. Ich glaube ja, dass der Begriff Microservice die Leute dazu anstachelt, alles möglichst kleinzuschneiden und nicht fachlich ...

[@a.r.s.4075]

Microservices sind genau so gut wie ihr Schnitt bzw. ihre Eigenständigkeit. Wählt man das Tailoring der Funktionen falsch, ist es vorbei mit Performance, Vorteilen, gekapselter Architektur oder Dateneffizienz, man baut sich einen Monolithen aus einzelnen Microservices und erstickt im inneren Datenaustausch. Deshalb ist auch das Thema DDD so extrem wichtig, wird oft jedoch falsch verstanden. Denn die althergebrachte Aufspaltung einer größeren Lösung in Funktionsgruppen führt schnell zu lose gekoppelten Einzelkomponenten analog eines Monolithen, nicht zu geschlossenen Microservices. Daher lebt das ganze Microservice-Modell von wirklich guten, sauberen in sich geschlossenen Anwendungsfällen, die kaum weitere Services bzw. Fremddaten zum Lauf benötigen. Ich habe noch kaum eine Lösung im größeren Rahmen gesehen, die hierzu wirklich sauber ist. Ist das überhaupt im Dschungel der umzusetzenden Fachlichkeiten planbar, wenn man nicht nur Basis-Service wie AWS bereit stellt.

[@bg2junge]

Habe nie serverless verstanden, besonders für Unternehmen. Wenn eh ein vorhersehbaren Verkehr(fast bei jedem Unternehmen vorhanden) gibt, sind serverless absolute käse. Es gibt sicherlich Verwendungszweck aber der ist minimal.

[@thenativeweb]

[gr] Geht mir, ehrlich gesagt, auch so. Den Hype konnte ich auch nie nachvollziehen, und es ist - zumindest meinem Empfinden nach - auch wieder sehr ruhig um Serverless geworden.

[@cubexsone]

Meine Frage hat nichts direkt mit dem Thema dazu, mir ist in diesem Video das Mikro am Kragen aufgefallen und wollte Wissen welches das ist und ob das Empfehlenswert ist.

[@thenativeweb]

[gr] Das ist das DJI Mic, ein Set aus zwei kabellosen Clip-Mikrofonen und einem Empfänger. Wir sind sehr zufrieden damit, sowohl im Studio als auch draußen in der Natur. Also ja, wir würden sie empfehlen 😊

[@cubexsone]

@@thenativeweb Danke für die Antwort :)

[@hichaeretaqua]

Ich verstehe die Aufregung gar nicht. Der Title grenzt ganz klar einen kleinen dedizierten Anwendungsbereich ab, in welchem Amazon auf einen Monolithen gewechselt ist. Der Untertitle fasst zusammen, was damit erreicht wurde. Ich finde es ehr fragwürdig daraus eine Aussage zu Micro-Services im Allgemeinen abzuleiten. Aus dem Titel und Untertitle ziehe ich nur Eines raus: "Always use the right tool for the right job"

[@ScriptRaccoon]

+++ LEGO GIBT SEIN MODULARES SPIELSYSTEM AUF +++ Habe ich das Video richtig zusammengefasst? ;)

[@thenativeweb]

[gr] YMMD 😊

[@holger3526]

Nur Überschriften lesen und medial aufbauschen - ob als "Redaktion" oder Privatmensch - scheint schon seit etlichen Jahren immer mehr in Mode gekommen zu sein. Kein Wunder, dass wir in der Debattenkultur dort gelandet sind, wo wir sind. Mich interessiert nur, ob das ein rein Deutsches Phänomen ist, oder ob es ein internationales Problem darstellt.

[@Tekay37]

Ich warte noch auf ein konkretes Beispiel, bei dem eine Microservice-Architektur einen tatsächlichen, messbaren(!) Vorteil bringt, ohne dass dadurch erhebliche Nachteile in Kauf genommen werden müssen. Ich kenne bisher keines.

[@micknamens8659]

Vorteile: 1. unabhängig skalierbar (replicaCount), 2. unabhängige updates, 3. fokussierte Tests bei neuen releases, 4. erlaubt unterschiedliche Evolutionsgeschwindigkeit, 5. Unterteilung in geschäftskritische Funktionalität vs. nette nice-to-have Zusatzfeatures (z.B. Marketing), 6. unabhängige kleine Teams (max. 6 Entwickler), 7. unterschiedliche Sprachen, Frameworks, Platform

[@Tekay37]

@@micknamens8659 Das ist eine Liste von Behauptungen und kein konkretes Beispiel, bei dem tatsächliche Vorteile gemessen wurden.

[@micknamens8659]

@@Tekay37welche Kennzahlen sind denn von Interesse?

[@Tekay37]

@@micknamens8659 Die Kennzahlen kann derjenige festlegen, der Verbesserungen verspricht. Die müssen nur eben messbar sein. Zusätzlich sind Kosten, Verfügbarkeit, Performance immer relevant.

[@micknamens8659]

@@Tekay37 Eine wichtige Kennzahl ist die Zeit zwischen einem Änderungswunsch und dem Deployment in Prod.

[@ThomasJunkOS]

Kernsatz: »Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.« Und das ist eigentlich nix neues.

[@marcbohm2473]

Bester Mann

[@thenativeweb]

[gr] Danke 😊

[@yt7042]

"sagt Amazon" - Gibt es denn bei Amazon, ähnlich wie bei Google, Personen die das Unternehmen in diesem speziellem Bereich repräsentieren oder wird jeder Blog Post als "Konzernentscheidung" gesehen? Die Schreiberlinge springen heutzutage auf jedes Thema drauf, bei welchen die Chance besteht Klicks zu erhalten. Das ist das wahre Problem und zwar nicht nur in diesem Bereich. Schöne Woche!

[@zickzack987]

Da hat sich der Hochschulabsolvent was ausgedacht, Hauptsache kompliziert 😁 Architektur Reviews gibts da scheinbar keine. Auch keine Lasttests. Super peinlich das zu veröffentlichen 🥴

[@NachtmahrNebenan]

Ist doch auch mal schön, wenn dich mal aufregst, Golo.

[@thenativeweb]

[gr] Haha 🤣

[@josefpharma4714]

Nun ja: Microservices, die ungünstig/falsch geschnitten waren zusammenzuführen ist wohl nicht als Abkehr von Microservices zu Interpretieren 😅