Mythos Microservices - Stoppt den Wahnsinn!

In meiner täglichen arbeit in der Architekturberatung bin ich immer wieder der Diskussion SOA vs. Microservices ausgesetzt. In dieser Episode lasse ich mal meinen Frust ab und zeige Euch, warum ich diese Diskussion für falsch halte und warum Microservices nichts anderes als modernes SOA ist.

[petermuller]

Einen (mMn großen) Nachteil von Microservices ist die mangelnde Spezialisierung der Teams:
- Gerade in größeren Firmen ist es viel EFFIZIENTER und ZUVERLÄSSIGER,
- wenn sich jeweils 10 Leute ums Deployment, Überwachung, Architektur, Sicherheit, regulatorische Vorgaben, ... kümmern,
- die sich in genau ihr Themengebiet eingearbeitet und dort Erfahrung gesammelt haben,
- als wenn alle 3000 Entwickler das jeweils "irgendwie mit machen" müssen.

"Autonomie" ist selten die beste Lösung für die im Video genannten Herausforderungen, sondern meist nur der persönlichen Präferenz oder einer schlechten Feedbackkultur (wenn die Spezialisten Zeug bauen, das die Entwickler mehr Zeit kosten als sparen) geschuldet.

[theWSt]

Wow, das Video ist schon über 4 Jahre alt, das hätte ich damals 2019 sehen müssen. Ich hab vor knapp 6 Jahren angefangen, als Software-Entwickler an einem damals neuen Projekt zu arbeiten. Damals hab ich den Begriff Microservice Architektur kennen gelernt. Mir ist davor der Begriff SOA zwar auch schon begegnet, aber die beiden hab ich ehrlich gesagt nie in Bezug zueinander gesetzt. Nach diesem Video wird mir klar, was wir seit 6 Jahren machen, ist einfach eine SOA, ganz individuell und genau zugeschnitten auf unsere Usecases. Ein Monolith wäre für dieses Projekt tatsächlich die falsche Architektur, denn Skalierung einzelner Teile ist in diesem Fall sehr wichtig. Es gab sogar einmal den Fall, dass wir einen der Services aufgespalten haben, weil er für 3 Aufgaben zuständig war, die nacheinander und von der jeweils vorherigen abhängig ausgeführt werden. Das ließ sich wunderbar aufteilen und ist seitdem tatsächlich einfacher wartbar. Es gab aber nie die Diskussion, wie groß ein Microservice sein darf. Solche sinnlosen Metriken, wie 2 Entwickler mit 2 Pizzen am Tag können sie warten, bringen niemanden weiter. Das Aufteilung der Funktionalitäten in Services ist, wie gesagt, in diesem Projekt ganz individuell und mmn auch sinnvoll. In unserem Fall hat sich die Architektur seit Jahren bewährt. Natürlich haben wir keinen Vergleich, wie es mit einer anderen Architektur gelaufen wäre, aber zumindest hatten wir nie eine Abwägung zwischen SOA und Microservices, wir hatten hier offenbar nie einen Unterschied gemacht. Ich sehe das in meinem Fall positiv.

[rmbl]

Kunde: wir machen microservices!
Ich: ah ok ihr habt Millionen User gleichzeitig?
Kunde: nein es ist eine fachbereichsanwendung, da sind ca 20 Personen drin.
Ich: warum macht ihr das dann? Ihr s I'd doch nur 2 Entwickler?
Kunde: damit wir schneller werden in der Entwicklung.
Ich: ah Shit here we go again...

[ingowetsches]

Sehr interessant und für mich als "Neueinsteiger" in der Systemarchitektur sehr aufschlussreich. Ich danke Dir!

[IT-Entrepreneur]

Du hast nicht zufällig ein Buch geschrieben indem du über die Vor und Nachteile der einzelnen Architekturmuster schreibst oder? Suche genau sowas

[caoutchouc-cc]

@DavidTielke Ich hab beim schauen deiner Videos zu Systemarchitektur eine Idee entwickelt und würde nun gerne von dir wissen ob diese praktisch einsetzbar wäre. Mal angenommen wir brauchen nicht mehr als nur einen Client-Server-Monolithen und der ist auch wohl Strukturiert nach allen regeln der Kunst. Nun habe ich in einer Komponente Performanceprobleme. Kann ich nicht nur diese einzelne Komponente herausschneiden und als Microservice neben dem monolithischen Server laufen lassen? Und falls nicht kann ich meinen Monolithen nicht von Anfang an so strukturieren, dass so ein Ausgliedern später möglich ist. Danke für deine Tipps. LG

[robink.]

Ich kann deinen Kernpunkt nachvollziehen, bzw. sehe es genauso kritisch, dass viele architekturverantwortliche solchen Hypes unbegründet und ohne Verständnisbemühungen hinterherlaufen. Du hast aber meiner Meinung nach in deinem einstündigen Rant dich entweder bewusst nur auf die negativen Aspekte fokussiert, oder einfach das Pattern Microservices relativiert. Ich denke, das hätte man auch in 5 Minuten erklären können. Trotzdem erneut; vielen, vielen Dank für deinen kostenlosen Beiträge!

[dagorgonzoladotco]

mM ist Conways Law entscheidend: die Struktur der Software spiegelt die Struktur des Unternehmens wider. Je größer die Anzahl Entwickler (1, 10, 100, 1000, ...) desto anders die Struktur der Software...

[grossadmiralthrawn]

Gutes Video. Nur der Sound ist bei mir nicht so toll. Ansonsten aber sehr aufschlussreich.

[daniellyder]

Sehr gutes Video. Ich denke viele (gerade jüngere) Entwickler haben wenig Ahnung bzw. Erfahrungen mit den verschiedenen Architekturen. Sie laufen einfach dem nach was Google Netflix und co. in Ihren Talks propagieren, ohne dies für ihren spezifischen Anwendungsfall zu hinterfragen. >> Weil es die „big corps“ machen ist es cool und wir müssen wir das jetzt auch.<<
Sehe ich leider in meinen Projekten auch viel zu häufig und kann deinen Frust sehr nachvollziehen.

[sral]

wo ist eigentlich der punkt an SOA wenn am ende alles über die gleiche Datenbank läuft?

[Aalii]

Interessantes Thema, danke für die Ausführungen!

[sral]

Microservices: In der Theorie toll und in der Praxis flop...

[sral]

Abstürze Löst man mit Exception handling oder bei low level sprachen durch codeanalyse zur Compilezeit. Wenn man solche Probleme hat sollte man deswegen nicht microservices nehmen ...

[thomasmeyer]

Sorry ich kann ihn beim besten Willen in einigen Bereichen nicht ernstnehmen. Mal davon abgesehen, dass er noch nichtmal die Quellen angibt.