Ehemaliger GitHub-CTO: „Der größte Architekturfehler der letzten 10 Jahre war der vollständige Umstieg auf Microservices“

xguru · 2022-11-17T11:17:01+09:00

"Monolith > apps > services > microservices" Erstens: Das ist keine Regel, sondern nur meine Meinung. Wer schon einmal große verteilte Systeme aufgebaut hat, weiß, dass es in der Praxis nicht einfach genau so funktioniert und man sich anpassen muss Zweitens: Die Reihenfolge ist wichtig Für ein Unternehmen mit 5–50 Personen: Geht einfach mit einem Monolithen Bei einem Unternehmen mit 10.000 Mitarbeitenden wird man all das oben Genannte ohnehin haben. Aber wenn ich darüber spreche, was ich heute anders sehe als früher... Zuerst die Definitionen monolith - xyz.com apps - abc.xyz.com services - unterstützen Apps/Monolithen, zentrale Infrastruktur, zentrale Compliance-Funktionen, werden möglicherweise nicht vom App-Team geschrieben (Wartung durch das Infrastrukturteam) microservices - ein paar hundert Zeilen Code, meist einmalig, könnten/sollten eine Bibliothek oder ein SDK sein Warum? : Im Kern wegen "Speed & Risk" #1 Für das gesamte Entwicklungsteam ist es einfacher, in einer einzigen großen App zu entwickeln (stellt euch vor, die ganze Website wäre eine Rails-App) #2 Die verteilten Systeme, die man mit dem Wachstum zwangsläufig bekommt, sind schon ohne Hunderte an sich riskanten Microservices schwer genug zu durchdringen #3 Wenn man vollständig auf Microservices geht, muss man neue Konzepte einführen, um unkontrollierte Ausbreitung zu bewältigen #4 Maßgeschneiderte (Bespoke) Infrastruktur-Services oder Microservices sind eine extreme Form von Schulden. Code ist schon Schuld, aber ein Service ist die Extremversion davon. Denkt darüber nach, was das bedeutet. Macht es zu einem Hebelpunkt Engineers für verteilte Systeme hassen Duplizierung. Wenn also etwas an mehreren Stellen passiert, denken sie: "Lasst uns das herausziehen und einen Microservice daraus machen" Theoretisch ist das richtig, und bis zehn oder zwanzig Stück ist das okay. Aber sobald es über einige Dutzend hinausgeht oder unternehmensweit in großen Firmen genutzt wird, ist es kein technisches Problem mehr, sondern ein organisatorisches Es mag so klingen, als würde ich eine falsche Dichotomie aufmachen, aber bei Microservices gibt es in der Praxis technische Herausforderungen und noch mehr organisatorische Probleme Was mir Sorgen macht #1 (es sei denn, das Unternehmen wird ausnahmsweise von einem CEO mit IT-Hintergrund geführt) Infrastruktur verliert in der Priorisierung immer den Kürzeren #2 Wenn es zu viele Services gibt, entstehen in der Regel Fragen zu Ownership und Abgrenzung #3 Um die vielen Microservices zu bewältigen, führt man noch mehr Tools ein #4 Am wichtigsten: Jeder einzelne Microservice, der eigentlich eine Bibliothek oder ein SDK hätte sein sollen, bringt Produktionsrisiken mit sich Was ich im Allgemeinen empfehle #1 Einen Monolithen so lange wie möglich beibehalten #2 Bei Services mit Dingen beginnen, die die Infrastruktur braucht, nicht auf der App-Entwicklungsseite #3 Wenn ihr den Monolithen aufteilen müsst, dann in große Apps statt in kleine Services #4 Jede neue App als virtuelle Wand innerhalb des Unternehmens betrachten #5 Wenn möglich Bibliotheken statt Microservices bevorzugen

(twitter.com/jasoncwarner)

46 Punkte von xguru 2022-11-17 | 13 Kommentare | Auf WhatsApp teilen

"Monolith > apps > services > microservices"
Erstens: Das ist keine Regel, sondern nur meine Meinung. Wer schon einmal große verteilte Systeme aufgebaut hat, weiß, dass es in der Praxis nicht einfach genau so funktioniert und man sich anpassen muss
Zweitens: Die Reihenfolge ist wichtig
- Für ein Unternehmen mit 5–50 Personen: Geht einfach mit einem Monolithen
- Bei einem Unternehmen mit 10.000 Mitarbeitenden wird man all das oben Genannte ohnehin haben. Aber wenn ich darüber spreche, was ich heute anders sehe als früher...

Zuerst die Definitionen

monolith - xyz.com
apps - abc.xyz.com
services - unterstützen Apps/Monolithen, zentrale Infrastruktur, zentrale Compliance-Funktionen, werden möglicherweise nicht vom App-Team geschrieben (Wartung durch das Infrastrukturteam)
microservices - ein paar hundert Zeilen Code, meist einmalig, könnten/sollten eine Bibliothek oder ein SDK sein

Warum? : Im Kern wegen "Speed & Risk"

#1 Für das gesamte Entwicklungsteam ist es einfacher, in einer einzigen großen App zu entwickeln (stellt euch vor, die ganze Website wäre eine Rails-App)
#2 Die verteilten Systeme, die man mit dem Wachstum zwangsläufig bekommt, sind schon ohne Hunderte an sich riskanten Microservices schwer genug zu durchdringen
#3 Wenn man vollständig auf Microservices geht, muss man neue Konzepte einführen, um unkontrollierte Ausbreitung zu bewältigen
#4 Maßgeschneiderte (Bespoke) Infrastruktur-Services oder Microservices sind eine extreme Form von Schulden. Code ist schon Schuld, aber ein Service ist die Extremversion davon. Denkt darüber nach, was das bedeutet. Macht es zu einem Hebelpunkt
Engineers für verteilte Systeme hassen Duplizierung. Wenn also etwas an mehreren Stellen passiert, denken sie: "Lasst uns das herausziehen und einen Microservice daraus machen"
Theoretisch ist das richtig, und bis zehn oder zwanzig Stück ist das okay. Aber sobald es über einige Dutzend hinausgeht oder unternehmensweit in großen Firmen genutzt wird, ist es kein technisches Problem mehr, sondern ein organisatorisches
Es mag so klingen, als würde ich eine falsche Dichotomie aufmachen, aber bei Microservices gibt es in der Praxis technische Herausforderungen und noch mehr organisatorische Probleme

Was mir Sorgen macht

#1 (es sei denn, das Unternehmen wird ausnahmsweise von einem CEO mit IT-Hintergrund geführt) Infrastruktur verliert in der Priorisierung immer den Kürzeren
#2 Wenn es zu viele Services gibt, entstehen in der Regel Fragen zu Ownership und Abgrenzung
#3 Um die vielen Microservices zu bewältigen, führt man noch mehr Tools ein
#4 Am wichtigsten: Jeder einzelne Microservice, der eigentlich eine Bibliothek oder ein SDK hätte sein sollen, bringt Produktionsrisiken mit sich

Was ich im Allgemeinen empfehle

#1 Einen Monolithen so lange wie möglich beibehalten
#2 Bei Services mit Dingen beginnen, die die Infrastruktur braucht, nicht auf der App-Entwicklungsseite
#3 Wenn ihr den Monolithen aufteilen müsst, dann in große Apps statt in kleine Services
#4 Jede neue App als virtuelle Wand innerhalb des Unternehmens betrachten
#5 Wenn möglich Bibliotheken statt Microservices bevorzugen

13 Kommentare

jonnung 2022-11-18

Ich kann die Bedenken und Empfehlungen im letzten Teil gut nachvollziehen.
Tatsächlich sind die Größenordnung des Unternehmens und des Services in einem ähnlichen Kontext zu sehen, und ich hatte den Eindruck, dass es eine hervorragende Entscheidungskraft braucht, sich im Voraus auf den Moment vorzubereiten, in dem man die Dinge zwangsläufig aufteilen muss.

love7peace 2022-11-17

Sollte das nicht eher von der Systemgröße als von der Unternehmensgröße abhängen? Habe ich MSA falsch verstanden?

ilbanin 2022-11-17

Ich stimme zunächst der Meinung in den oberen Kommentaren zu, dass nicht Microservices selbst das Problem sind, sondern eher die unkontrollierte Ausweitung von Services, oder? Je größer ein Unternehmen wird, desto klarer treten zudem die Nachteile eines Monolithen selbst zutage, etwa bei Deployment-Problemen und Branch-Management. Deshalb scheint es wichtig zu sein, den Trade-off zwischen Kosten und Produktivität gut abzuwägen.

functor 2022-11-17

Ein wirklich toller Artikel. Vielen Dank.

ruinnel 2022-11-17

Das wirkt ähnlich wie die Debatte über die Bedeutung von Design Patterns, oder?
Design Patterns sind schließlich Code-Muster, die aus dem Prozess hervorgegangen sind, verschiedenste Probleme zu lösen....
Letztlich sollte man sie je nach Situation und je nach Bedarf anwenden und adaptieren.....

Trotzdem gibt es immer wieder Leute, die Design Patterns geradezu als Musterlösung ansehen, sie für unverzichtbar halten und sich darauf versteifen...

In letzter Zeit scheint es bei MSA etwas Ähnliches zu geben; es gibt immer mehr Leute, die bedingungslos auf MSA setzen.

deokim 2022-11-17

Das wirkt wie die Frage, was zuerst da war – Henne oder Ei.
Ist nicht eher das Problem nicht die Microservices selbst, sondern die unkontrollierte Ausweitung von Services?

bbulbum 2022-11-17

Ich denke, dass das richtige Gleichgewicht wichtig ist.
Wenn man auf Microservices setzt, kann es leicht dazu kommen, dass neue Funktionen automatisch zu neuen Microservices werden,
und ich habe den Eindruck, dass die Verwaltung dadurch mit der Zeit immer schwieriger wird.

hiddenest 2022-11-17

Das erinnert mich an den Beitrag „Goodbye Microservices“, der früher im Technik-Blog von Segment veröffentlicht wurde.
Obwohl auch Segment als CDP enorme Datenmengen in Echtzeit verarbeitet, stellte das Unternehmen von einer Microservices- auf eine Monolith-Architektur um und hat die Gründe dafür im Blog zusammengefasst. Ich denke, dass sich das in gewisser Weise auch mit diesem Artikel deckt :)

https://segment.com/blog/goodbye-microservices/

bamchi 2022-11-17

Dem stimme ich im Großen und Ganzen zu.
In unserem Unternehmen gibt es fünf Entwickler, daher denke ich, dass es für uns nach wie vor richtig ist, auf einen Monolithen (Ruby on Rails) zu setzen.
Wenn es – wie im obigen Artikel – zu einem Projekt wird, an dem mehr als 50 Personen gleichzeitig entwickeln, werden wir dann wohl den zweiten Monolithen entwickeln.

tnrnfl 2022-11-17

Wenn das ein Unternehmen mit 5 bis 50 Mitarbeitern ist, dann sollte man einfach bei einem Monolithen bleiben << Das bezieht sich wohl nicht auf die Zahl der Entwickler, sondern auf die Gesamtzahl der Beschäftigten, oder?

devstorm 2022-11-17

Es scheint um die Unternehmensgröße zu gehen~

yolatengo 2022-11-17

Wenn möglich, sollte man den Monolithen so lange wie möglich beibehalten < dem stimme ich voll zu. Bei der Aufspaltung steigen die Wartungskosten stark an.

nicewook 2022-11-17

Ich denke, der Beitrag ist als Gegenreaktion darauf zu verstehen, dass MSA zunehmend dogmatisiert wird, und in diesem Sinne hat er wohl seine Bedeutung.