#78 Microservice & Monolith: Was die Industrie in den letzten 9 Jahren gelernt hat

Monolithen und Microservices: Ein Evergreen der Software-Industrie.

Mitte der 2010er Jahre bekam das Thema der Microservices Popularität. Doch was haben wir nach ca. 9 Jahren darüber gelernt? Sind Microservices immer noch der heilige Gral oder war es eine tolle Reise und alle pendeln zurück zu Monolithen? Viele Firmen haben positive und negative Erfahrungen und Learnings mit Microservices gemacht. Doch war es für alle der richtige Schritt? Nutzen die meisten Firmen die wahren Vorteile von Microservices wirklich aus? Und welches Problem löst der Microservice-Trend eigentlich? Ein technisches oder organisatorisches Problem? Welche Probleme gibt es in der Welt um Microservices, besonders in großen, schnell wachsenden Organisationen? Was sind typische Gründe warum Microservices scheitern? Und waren Cloud Native, Container-Scheduler wie Kubernetes und Co einfach nur weiteres Öl, was ins Microservice Feuer gekippt wurde?

In dieser Episode schauen wir uns an, was die Industrie denn so in den letzten 9 Jahren über den ganzen Microservice-Hype gelernt hat.

Bonus: Warum es weiterhin ein Religionsthema bleibt und es keine Gewinner geben wird.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:25) Warum Microservices und Monolithen ein Motivationsloch auslösen

(00:03:14) Wann kam das Thema "Microservices vs. Monolithen" eigentlich auf?

(00:06:07) Geht es wieder zurück zu Monolithen?

(00:09:15) Welches Problem sollte Microservices eigentlich lösen?

(00:17:13) Was ist ein Monolith, Micro- und Nano-Service?

(00:22:49) Löst die Microservice vs. Monolith-Frage ein technisches oder organisatorisches Problem?

(00:24:38) Ist der Erfolg von Kubernetes und Container scheduling direkt mit dem Hype um Microservices zu verbinden?

(00:28:42) Sind Microservices denn immer einzelne Systeme?

(00:31:41) Guidelines für Microservices: Independent Systems Architecture, Reliability Manifesto und Best Practices

(00:42:02) Gute Architekturen um Teams skalierbar zu gestalten und Microservices im Frontend

(00:45:11) Warum Microservices scheitern

(00:47:25) Gemeinsame Datenmodelle und Deployment Monolithen

(00:51:55) Code-Ownership bei Firmen-Umstrukturierungen und Gesetz von Conway

(00:56:14) Beide Modelle sind gleich schlecht

(00:59:51) Feedback zum Motivationsloch

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:02 - 00:00:06)

Würde ich sagen, nur weil man ein Monolith hat, sind nicht alle Probleme gelöst.

Andy Grunwald (00:00:07 - 00:00:23)

Ich denke, dass ziemlich viele Unternehmen gemerkt haben, dass sie die realen Vorteile entweder nicht brauchen oder die Organisation nicht so umgestellt bekommen, beziehungsweise das technische Alignment, was zur Nutzung der Vorteile von Microservices wirklich notwendig ist, umgesetzt bekommen.

Wolfi Gassler (00:00:24 - 00:00:34)

Also ich glaube, das war auch so ein Trend, der da mitgeschwommen ist mit dieser ganzen Microservice-Ecke und den man oft vergisst. Also es geht gar nicht nur um diese Microservices, sondern auch was sich so rundherum entwickelt hat.

Andy Grunwald (00:00:37 - 00:01:41)

Hi, schön, dass du bei einer neuen Episode vom Engineering Kiosk dabei bist. Wir sprechen heute über das Religionsthema Microservices und Monolithen. Seit ca. 9 Jahren wird diese Sau durchs Dorf getrieben. Und irgendwie haben wir das Gefühl, dass es immer mehr und mehr Leute gibt, die sagen, die meisten Firmen sollten doch zurück zu Monolithen wechseln. Deswegen sprechen wir mal ein wenig über die letzten 9 Jahre und schauen uns an, welche Probleme Microservice eigentlich lösen sollte, was die wahren Vorteile dieser Architektur sind, warum die meisten Firmen diese gar nicht vollumfänglich nutzen, wie Firmenumstrukturierungen das ganze gegen die Wand fahren lassen können und warum die ganze Kubernetes und Cloud-Native-Welle gegebenenfalls den Trend befeuert hat. Viel Spaß und los geht's! Die Tage war ich auf unserer Webseite und bin über die vorherigen Podcast-Episoden mal ein bisschen drüber gescrollt. Und dann dachte ich mir, wir müssen mal ein bisschen Stereotypen-Denken anbringen. Wir können kein Software-Engineering-Podcast sein, ohne das Thema anzusprechen, Microservices und Monoliden.

Wolfi Gassler (00:01:41 - 00:01:45)

Jetzt hast du wahrscheinlich 80% unserer Hörerschaft verloren. Bravo, Andi.

Andy Grunwald (00:01:46 - 00:02:28)

Und jetzt mal eine kleine Story von Behind the Scenes. Wolfgang und ich chatten im Slack immer so ein bisschen rum. Okay, was machen wir denn als nächstes Thema? Und wer bereitet das vor? Und haben wir dann schon mal irgendwie ein paar Ideen, die dampfen wir dann immer in so einen Google-Doc. Bis sich dann irgendeiner von uns mal erbarmt, sich da mal wirklich eine Stunde hinzusetzen und das Thema dann mal wirklich vorzubereiten, weil bei manchen Themen müssen wir auch hier und da den einen oder anderen Fakt nochmal nachschlagen. Auf jeden Fall kam ich dann auf diese grandiose Idee, mal über das Thema Microservices und Monolithen zu sprechen, denn kein Software-Engineering-Podcast sollte dieses Thema nicht erwähnen. Und da kam O-Ton, der Satz, da musst du mich aus einem tiefen Motivationsloch holen bei dem Thema. Wolfgang, warum bist du so down bei diesem Thema?

Wolfi Gassler (00:02:28 - 00:02:42)

Ich glaube, ich hatte einfach schon viel zu viele Diskussionen über dieses Thema. Und das ist so ein Religionskrieg, so ähnlich wie Wim gegen Imax. Und da gibt's eigentlich keine Gewinner. Und das sind nur haarstreibende, lange Diskussionen, die man da führt.

Andy Grunwald (00:02:42 - 00:02:47)

Bist du bei diesem Religionskrieg Atheist? Oder hast du einfach ganz klar eine Seite?

Wolfi Gassler (00:02:47 - 00:02:52)

Ich bin ja vielleicht mehr der Agnostiker, dass es noch ungeklärt ist, was die richtige Seite davon ist.

Andy Grunwald (00:02:52 - 00:02:57)

Das bedeutet also auch, du bist nicht gegen beide Seiten. Du bist der Kollege, der sich bei.

Wolfi Gassler (00:02:57 - 00:03:02)

Verändernehmern... Ja, irgendwie muss man es ja machen. Also, da führt ja kein Weg daran vorbei.

Andy Grunwald (00:03:02 - 00:03:12)

Okay, dann versuchen wir dich mal hier heute hier hoch zu hypen und dich entweder zu bekehren oder dir so eine Meinung wie die typischen Consultants aus dem Mund zu locken. It depends.

Wolfi Gassler (00:03:12 - 00:03:13)

Ja, dann hype mal los.

Andy Grunwald (00:03:13 - 00:03:54)

Die erste Frage, die ich mir bei dem ganzen Thema gestellt habe zur Vorbereitung dieser Episode, wann kam dieses Thema eigentlich auf? Also ich habe auch so 2007, 2008 mit dem Programmieren, mit der professionellen Programmierung angefangen. Also da dann wirklich damit Geld verdient. Und da war dieses Microservices-Thema noch nicht auf unserem Tisch. Dann habe ich mal ein bisschen recherchiert. Und wo fängt man eigentlich an zu recherchieren, wenn man wissen möchte, wann ein Thema hochkam? Richtig, Google Trends. Die ganze Sache kam Mitte der 2010er Jahre, also 2014, 2015, 2016. Da gibt es auch so einen knallharten Ausschlag bei Microservices, bei Google Trends. Und da geht dann so ähnlich wie so ein Aktienindex, so wie der Nasdaq vor Corona, ging dann auch immer so schön hoch.

Wolfi Gassler (00:03:54 - 00:04:30)

Ja, ich hatte das erste Mal Kontakt, lustigerweise in einem Interview, also wirklich, wo ich interviewt wurde für eine Stelle. Und ich komme ja aus der Datenbankwelt, da gibt es sowieso nur Monolithen und so Zeug. Und dann war so eine Frage, ob ich mich bei Microservices mit Docker auskenne. Und da hatte ich wirklich zum ersten Mal eigentlich davon gehört. Also das war so zu Beginn 2015er Jahre oder sowas in der Richtung. Und mit Docker hatte ich schon so ein bisschen gearbeitet, aber Microservices und Docker, Da habe ich dann gemerkt, oh, da scheint es irgendwo einen Trend zu geben, der gerade so auf Computerbild-CEO-Niveau herumschwirrt.

Andy Grunwald (00:04:30 - 00:04:40)

Computerbild, Megathema. Wir schreiben das Jahr 2023. Und ich habe ja jahrelang, oder mache es ja immer noch, Meetups organisiert. Und bei Meetups, immer wenn du uns...

Wolfi Gassler (00:04:40 - 00:04:44)

Moment, du machst es wieder. Du hattest eine lange, lange, lange Pause.

Andy Grunwald (00:04:44 - 00:04:50)

Jeder braucht mal seine Pause. Also für alle, die es noch nicht wussten, das Web Engineering Düsseldorf Meetup gibt es jeder jeden Monat.

Wolfi Gassler (00:04:50 - 00:04:53)

Ich hoffe mit Prosecco, oder? Klassisch in Düsseldorf.

Andy Grunwald (00:04:53 - 00:05:37)

Darf ich mir als Duisburger nicht erlauben. Wie dem auch sei, Computerbild. Bei Meetups habe ich immer so ein Sprichwort und zwar, wenn du ein Computerbild-Thema hast, ist die Hütte voll. Und ein Computerbild-Thema ist ein Thema, was jeder schon mal gehört hat, aber was nicht wirklich klar ist, wie man das macht. Das war zum Beispiel mal responsive Webdesign oder Scrum und agiles Projektmanagement. Jeder macht das irgendwie, aber keiner hat wirklich so den heiligen Gral, wie man das macht. Man könnte auch sagen, auch ein Computerbild-Thema ist, wenn das Thema in der Computerbild einen Artikel hat. Und bei der Recherche zum Monolithen habe ich einen Artikel der, Achtung, computerwoche.de gefunden. Vor- und Nachteile für Unternehmen, wenn man auf die Microservice-Architektur setzt.

Wolfi Gassler (00:05:37 - 00:05:39)

Von 2013. 23.

Andy Grunwald (00:05:39 - 00:05:51)

Der ist im April diesen Jahres rausgekommen, also ein bisschen mehr als zwei Monate alt. Für mich ist das der offizielle Beweis, dass Microservices jetzt ein Computerbild-Thema ist.

Wolfi Gassler (00:05:51 - 00:05:57)

Das heißt eigentlich, deine Vorbereitung besteht daraus, dass du Computerbild liest für diesen Podcast. Sehe ich das richtig?

Andy Grunwald (00:05:57 - 00:06:02)

Computerwoche. ist, soviel ich weiß, nicht vom Axel Springer Verlag, deswegen vielleicht ...

Wolfi Gassler (00:06:02 - 00:06:06)

Klingt nach wesentlich qualitativeren Journalismus, klar.

Andy Grunwald (00:06:06 - 00:07:05)

Aber ich find das lustig, weil in meiner Bubble, in meiner Internet-Bubble, hab ich eher das Gefühl, die Monolithen kommen wieder zurück. Und nicht die Microservices werden weitergepusht. Die Computerwoche sagt, hey, liebe Unternehmen, hey, liebe C-Level-Management, die ihr Computerwoche lest, schaut euch doch mal Microservices an im Jahr 2023, also acht, neun Jahre nachdem die Bubble, also wir zum Beispiel, davon gehört haben, Aber wenn ich jetzt ganzen Leuten, den Software Consultants und so weiter mal zuhöre oder so Leuten wie Kelsey Hightower, auch ein sehr sehr erfolgreicher Developer Advocate von Google, von Google Cloud und war auch mal sehr laut um Kubernetes, da habe ich so ein bisschen das Gefühl, die pendeln jetzt gerade wieder zurück. Wo wir früher in dem einen Extrem waren, alles waren Monolithen. wurde dann die Microservice-Sau durchs Dorf getrieben und alle sind auf den Microservice-Zug aufgesprungen. Danach haben wir so ein bisschen die Probleme und die Herausforderungen erkannt und jetzt advokaten doch schon wieder eine ganze Menge Leute für, sollten wir die Microservice-Schiene nicht links liegen lassen und wieder zu Monolithen gehen, weil das für viele Unternehmen ausreichend ist.

Wolfi Gassler (00:07:06 - 00:08:04)

Und nur DHH hat es schon immer gewusst. David Heinemeier Hansen, der CTO von Basecamp und hate.com, der war ja immer schon ein extremer Befürworter für Monolithen und der hat gerade kürzlich in meinem Blogartikel online gestellt, wo eine Meldung von Amazon kommentiert, und zwar von Prime Video von Amazon, die ihre Serverless-Architektur bzw. Microsoft-Service-Architektur gekillt haben und zurück sind zu einem Monolithen und 90% der Kosten eingespart haben auf EWS. Also ein Prime-Video-Service von Amazon hat 90% der Kosten eingespart, dadurch sie weg sind von Serverless. Also eindeutiger Trend zurück zu Monolithen, ja. Glaubst du, hat es irgendeinen Grund, warum die Leute jetzt zurückgehen Richtung Monolith? Ich hätte eine Theorie, aber ich will mal zuerst die Theorie des Profis hören. Du machst ja dieses ganze DevOps-Zeug und das ist ja dein Kram eigentlich. Und dein Thema heute?

Andy Grunwald (00:08:04 - 00:08:17)

Also eigentlich müsste ich ja voll für Microservices sein, weil Microservices braucht ja auch mehr Infrastruktur beziehungsweise mehr Power, Achtung, im Betrieb, ja im Ops, deswegen das ist ja eigentlich Jobsichern für mich.

Wolfi Gassler (00:08:17 - 00:08:19)

Macht ja dein Leben dann auch komplizierter.

Andy Grunwald (00:08:19 - 00:08:24)

Naja, einen Job zu haben, finde ich erstmal ganz gut. Das macht das ja dann nicht kompliziert. Wenn alles so monolithen ist, dann kann das ja jeder.

Wolfi Gassler (00:08:24 - 00:08:33)

Ja, wobei der Monolith muss ja auch deployed werden. Aber du hast natürlich recht, wenn ich 1000 Services deployen muss, das ist mehr Aufwand, als wenn ich nur zwei Services deployen muss.

Andy Grunwald (00:08:33 - 00:09:14)

Das ist zumindest einer der Nachteile, die oft in Verbindung mit Microservices genannt werden. Ob das dann jetzt wirklich so Realität ist oder nicht, besprechen wir gleich noch. Aber zurück zu der Frage, warum die ganzen Leute wieder zu einem Monolithen pendeln. Ich denke, dass ziemlich viele Unternehmen gemerkt haben, dass sie die realen Vorteile entweder nicht brauchen oder, und jetzt kommt das eigentlich Schwierige, die Organisation nicht so umgestellt bekommen, beziehungsweise das technische Alignment, was zur Nutzung der Vorteile von Microservices wirklich notwendig ist, umgesetzt bekommen. Und damit meine ich, der Key-Vorteil von Microservices, meiner Meinung nach, die Schaffung von wirklich unabhängigen Teams, damit die unabhängigen Teams sich schnell bewegen können.

Wolfi Gassler (00:09:14 - 00:09:30)

Interessanter Ansatz, dann bleiben wir gleich mal bei den Vorteilen. Vielleicht kannst du mal erklären, du hast es ja noch miterlebt von der alten monolithischen Welt hin zu den Microservices. Wie hast du den Trend denn wahrgenommen? Warum war das so in und was wollte man da eigentlich für ein Problem lösen?

Andy Grunwald (00:09:30 - 00:12:16)

Naja, so um die Zeit 2014, 2013, 2015, 2016 und so weiter, da kamen natürlich immer mehr Leute online, mehr und mehr Leute haben schnelleres Internet bekommen und jeder hatte irgendwie Zugriff auf dieses World Wide Web und besonders auch wir Deutschen haben dann endlich mal ordentliches Datenvolumen zu bezahlbaren Preisen bekommen. Punkt ist aber, dass es auch natürlich aus der Internetwelt immer einfacher wurde, weltweite Plattformen zu bauen. Viele Leute denken, wenn ich eine Plattform baue, dann wollen alle Leute meine Plattform und dadurch muss ich natürlich hohe Skalierbarkeit und Flexibilität haben. Das wird ja auch immer als einer der Vorteile von Microservices geültigt. Ich denke, dass diese ganze Trendwende schon dazu geführt hat, genauso wie ein Punkt der Entwickler-Performance. Wie viel Code kannst du aus deinem Team eigentlich so raussqueezen? Weil die Zeit, wo Microservices hochkamen, kam auch so ein bisschen die Agilität hoch, das agile Manifest. Vielleicht kennst du das noch, so Storypoints und Kanban und Scrum. Extreme Programming war ja noch davor, aber da war ja immer so der heilige Gral, unabhängige Entwicklerteams und unabhängige Bereitstellungen zu erreichen, dass jedes Entwicklungsteam eigenes Service entwickeln, testen und bereitstellen kann, damit wirklich Teams autonom arbeiten können. Ich habe sehr, sehr selten eine Firma gesehen, die das wirklich geschafft hat, also zumindest vom Ende, von der Datenbank bis hin zum Frontend. Dann kam natürlich auch noch in dieser ganzen Zeit mehr und mehr Programmiersprachen auf. Also es war ja früher war ja immer alles PHP. Alles was im Web war, war PHP. Und irgendwann kam Ruby und da gab es halt noch so die ein oder andere Firma, die hat so Perl gemacht. Ich glaube Booking.com, es läuft immer noch auf Perl. Aber irgendwann kamen halt die coolen Kids. Die mit dem Gopher. Go. Oder die mit der Krabbe. Rust. Und so weiter. Und irgendwann hat Python Django auch nochmal gemerkt, hey, ich kann auch nicht nur Data Science, sondern ich kann jetzt hier auch Web. Und irgendwann kam halt Node.js und JavaScript konnte auch auf einem Server genutzt werden. Also, da ging es darum, viele Leute wollten mal weg von dem, was sie schon jahrelang machten, zu mal was Neuem. Also, die technologische Vielfalt war dann auch so ein Punkt, meines Erachtens nach. Und wenn du dir mal die Aktienkurse von Amazon und Google Cloud und so weiter ansiehst, dann fallen die irgendwie auch in diesem Zeitpunkt, da gehen die Aktienkurse auch alle durch die Decke, weil jeder sagt irgendwie Cloud und weg vom Data Center und so weiter und so fort. Und wenn du schon mal in Monolithen in die Cloud migriert hast, dann kennst du den Begriff Lift and Shift. Und jeder der das schon mal gemacht hat, da geht grad so ein bisschen Gänsehaut über die Arme, weil das ist alles andere als spaßig. Aber so die ganzen Punkte, die fallen so alle in diese Zeit finde ich. Die Einfachheit weltweite Plattformen zu bauen, das bedeutet unabhängige Skalierbarkeit und Flexibilität. Agile Entwicklerteams, unabhängige Entwicklerteams, technologische Vielfalt, Ausfallsicherheit und Robustheit mit Cloud und DevOps und was es da nicht noch alles gibt. Ist natürlich alles ein bisschen weit hergeholt, diese These, aber ich hab das Gefühl, es gibt nicht den einen Grund, sondern all das fällt so in einen Eimer.

Wolfi Gassler (00:12:17 - 00:12:35)

Aber warum sollten Microservices alle diese Probleme lösen? Ich kann ja trotzdem an Monolithen in die Cloud deployen, bin dann skalierbar, habe die Flexibilität, indem ich einfach den mehrfach auf verschiedenen Servern hochboote. Ich habe dann die Ausfallsicherheit und Robustheit. Also wo liegt da der Vorteil dann?

Andy Grunwald (00:12:35 - 00:13:35)

Bleiben wir einfach mal bei der Skalierbarkeit und bei den Monolithen. Jetzt mal angenommen, du hast ein Monolith, das ist eine Executable. Das sind so 20, 30, 40, 80, 100.000 Lines of Code in einer Java Executable. Wenn du die hochbootest, dann braucht die erstmal 40 GB RAM. Natürlich kannst du den skalieren. Da brauchst du in der Cloud aber auch immer nur Maschinen mit 40 GB RAM. Wenn ich davon jetzt aber den Payment-Service rausnehme und er macht wirklich nur die Payment-Zahlungen, dann braucht er 2 GB RAM. Das bedeutet, ich kann 20 Services vom Payment-Dienstleister starten zu deutlich geringeren Kosten, wenn ich jetzt nicht den 100%igen Monolith skalieren muss. Also wenn du das in eine Cloud-Hardware umrechnest, das ist ja dann schon ein einzelner Punkt. Offen gesprochen heißt das natürlich nicht, dass der Payment-Service dann besser läuft oder ähnliches. Also der Monolith kann trotzdem stabiler sein. Ein weiterer Grund, der mir gerade einfällt, ist vielleicht auch einfach nur, dass die ganzen Software-Entwicklerinnen und Entwickler vielleicht auch einfach nur mal was Neues machen wollten. Die waren es satt, immer an dieser Legacy-Software zu arbeiten und haben gedacht, da kommt was Neues, da kann ich mal wieder meinen Spieltrieb rausholen und experimentieren.

Wolfi Gassler (00:13:35 - 00:15:40)

Ich hatte dazu mal 2015, glaube ich, war das, auch die Möglichkeit, einen ziemlich interessanten Talk zu sehen von Chad Fowler. Ich finde es immer noch einen sehr interessanten Talk. Haben wir ihn gerade kürzlich jetzt wieder mal angeschaut. Und zwar war das damals der CTO von Wunderlist. Können sich vielleicht manche noch erinnern, diese To-Do-List, die mal extrem geboomt hat und dann von Microsoft aufgekauft wurde schlussendlich. Und der hatte eigentlich einen extremen Ansatz, genau das, was du jetzt alles erklärt hast mit Microservices, aber der ist fast noch einen Schritt weitergegangen. Der hat Wunderlist dann komplett auch neu gebaut mit dem Team und dem seine Herangehensweise war, man kann einfach jede Programmiersprache verwenden, die man will, solange es, glaube ich, zwei Developer gibt in der Firma, die die Programmiersprache verwenden. Du brauchst nicht nachfragen. Du kannst dein Microservice entwickeln in deiner Programmiersprache deiner Wahl. Solange es so klein ist, dass man es auch jederzeit in einer anderen Programmiersprache wieder neu programmieren kann und wegwerfen kann. Also er wollte, dass man Software programmiert, um sie wegzuwerfen, mit dem Ziel wegzuwerfen. Und er wollte auch keine Upgrades oder große Updates. Sein Ziel war, das alles so klein zu halten, dass man es ganz einfach immer neu programmieren kann und auch gar nicht diese Probleme hat mit den ganzen Updatepfaden und Upgrades von den Frameworks. Und um das zu unterstützen, hat er das natürlich alles automatisieren müssen. Das heißt, Deployment automatisieren, die ganze Infrastruktur automatisiert. Also die Automatisierung, meiner Meinung nach, war auch ein großer Punkt, der dort hineingespielt hat, weil man hat dann erst begonnen, durch diese Microservices sehr viel zu automatisieren. Weil früher der klassische Ops-Ansatz war, ich habe meine Monolithen, ich habe mein Best Script, das wird manuell irgendwie deployed. Und sobald man in die Microservices-Ecke geht, musst du die ganzen Sachen automatisieren, damit dein Deployment überhaupt noch skaliert. Weil wenn du 70 Microservices zum Beispiel hast, dann musst du das automatisieren und kannst es gar nicht mehr manuell machen. Also ich glaube, das war auch so ein Trend, der da mitgeschwommen ist mit dieser ganzen Microservices-Ecke und den man oft vergisst. Also es geht gar nicht nur um diese Microservices, sondern auch was sich so rundherum entwickelt hat, meiner Meinung nach.

Andy Grunwald (00:15:41 - 00:15:58)

Also hat er die Microservices eigentlich als Tool genutzt, um seine Infrastruktur zu, ich sag mal, modernisieren, oder? Beziehungsweise deutlich zu automatisieren und somit über Zeit die Kosten der Firma zu drücken. Also er hat das eigentlich zum Tool ausgerufen, die Effizienz zu steigern.

Wolfi Gassler (00:15:58 - 00:16:48)

Ja, es war natürlich nicht sein direktes Ziel. Sein direktes Ziel war eben, die Programmiersprachen zu haben, produktive Leute, die alle die Programmiersprache verwenden können, die sie gern programmieren. und dadurch produktiver zu werden. Aber du musst dann natürlich auch viel automatisieren, damit du das ermöglichst. Und ich glaube, bei Microservices war das natürlich immer eine Grundvoraussetzung, weil wenn du Microservices verwenden willst, um deine Teams produktiver zu machen und selbstständiger, dann brauchst du dieses ganze Tooling rundherum. Und einerseits war das natürlich ein großer Schritt in die Richtung, diese Tools zu entwickeln, die Infrastruktur zu automatisieren. Aber meiner Meinung nach auch am Ende mehr oder weniger der Gnickbruch, warum das teilweise so schlecht funktioniert hat, weil das Tooling und die ganze Automatisierung ein extremer Aufwand ist, Monitoring und alles, was dazugehört, wenn du so eine Microservice-Architektur überhaupt aufbaust.

Andy Grunwald (00:16:49 - 00:17:12)

Wenn man sich mal im Internet umschaut und nach Nachteilen von Microservices googelt oder Chat-GPT fragt oder wo auch immer ihr eure Informationen heutzutage herbekommt, dann wird immer der Aufwand oder der höhere Aufwand für Infrastruktur und Betrieb erwähnt, weil es ist leider Fakt, dass Microservice eine deutlich effizientere Infrastruktur und auch Standards erfordert, weil primär viele Microservices betrieben werden müssen.

Wolfi Gassler (00:17:12 - 00:17:27)

Was ist denn eigentlich für dich ein Microservice, wenn wir gerade dabei sind? Wo fängt denn bei dir ein Microservice an und wo hört es auf? Wir sprechen ständig jetzt über Microservices, aber was ist eigentlich ein Microservice für dich? Ich habe mir das im Vorfeld auch überlegt und meiner Meinung nach ist es sehr unklar, was ein Microservice eigentlich ist.

Andy Grunwald (00:17:28 - 00:17:32)

Um Microservices zu erklären, muss ich erst mal mein Verständnis von Monolithen erklären.

Wolfi Gassler (00:17:32 - 00:17:35)

Okay, dann darfst du zuerst Monolithen erklären.

Andy Grunwald (00:17:35 - 00:18:31)

Für mich ist halt Monolith einfach nur eine Anwendung, die als ein einzig großer zusammenhängender Block entwickelt wird und auch bereitgestellt wird. Das kann von mir aus auch eine einzelne executable sein, ein ausführbarer Prozess. Den schmeiße ich auf einen Server oder von mir auch über die Wand zum Betriebsteam, zum Ops-Team oder wo auch immer. Dann sage ich hier executable start buff Und dann läuft das. Oder halt mit nem Apache 2 Server oder Nginx und FPM mit PHP oder oder oder. Punkt ist aber ne ganze Menge Source Code, mehrere Verantwortlichkeiten, ne Datenbank Connection da drin und der händelt einfach alles von meiner Applikation. Hab ich jetzt so ne Webseite wie Spotify.com, dann wär das einfach ne Million Zeilen an Code, alles in einem Repository, alles in einer Executable, sei es Java oder in 1000 PHP-Files, wenn's PHP ist oder Alles relativ, wenn ich jetzt sage dichte Kopplung, dann meine ich jetzt gar nicht eine schlechte Software Architektur selbst, sondern es hängt halt alles schon zusammen. Das geht alles über ein paar Controller.

Wolfi Gassler (00:18:31 - 00:18:34)

Etc. etc. Okay, und Microservices im Gegenzug?

Andy Grunwald (00:18:34 - 00:18:45)

Ein Microservice, darunter verstehe ich eigentlich, dass eigenständige Dienste in eigene Anwendungen aufgeteilt werden, damit diese unabhängig voneinander entwickelt, bereitgestellt und auch skaliert werden können.

Wolfi Gassler (00:18:45 - 00:18:46)

Also ganz viele Monolithen.

Andy Grunwald (00:18:47 - 00:18:54)

Eigentlich ja, doch diese ganz vielen Monolithen, wir nennen sie jetzt hier Microservices einfach mal, haben natürlich einen deutlich kleineren Scope.

Wolfi Gassler (00:18:54 - 00:18:59)

Und wie definierst du den Scope oder welchen Scope meinst du jetzt? Den Funktionsscope?

Andy Grunwald (00:18:59 - 00:19:04)

Ja, den Domänenscope, den Funktionsscope. Bei Spotify wäre das dann zum Beispiel ein Suchservice.

Wolfi Gassler (00:19:04 - 00:19:05)

Und auf der Teamseite?

Andy Grunwald (00:19:05 - 00:19:08)

Von diesem Team der Scope und die Domäne ist dann wirklich Suche.

Wolfi Gassler (00:19:09 - 00:19:10)

Und zwar nur ein Team.

Andy Grunwald (00:19:10 - 00:20:02)

Ja, im Optimalfall ein Team, was dann die volle Autonomie über die Suche hat. Je nachdem kann es natürlich hinten dran vielleicht noch ein paar mehr Teams sein. Vielleicht gibt es in der Suchdomäne noch ein spezielles Such-Storage-Backend oder ähnliches. Das weiß ich jetzt nicht. Das kommt dann sehr wahrscheinlich auf die Größe der Organisation, der Daten und so weiter an. Aber gehen wir einfach mal vom ganz normalen Fall aus. Du hast einen Such-Microservice und ein Team kümmert sich nur um die Features, Bugfixes, Weiterentwicklung, Betrieb von dem Such-Microservice. Und was viele Leute jetzt immer so unter Microservice verstehen, ist, dass der Such-Service dann über Netzwerkanfragen mit anderen APIs Daten austauscht. Das ist so die, ich würde mal sagen, globale Definition von Microservices, die so im Internet rumschwirrt. Ob ich damit jetzt 100 Prozent d'accord bin, dass Microservices immer ein Netzwerk Calls machen müssen, da kommen wir gleich noch zu.

Wolfi Gassler (00:20:02 - 00:20:22)

Aber dieses Suchbeispiel, das war doch schon immer eigenständig. Die Suche hat meistens einen eigenen Stack gehabt, da wie irgendein Elasticsearch oder ähnliche Dinge. Das war doch schon immer eigenständig. Also wenn man auf der Ebene agiert, dann war das ein eigener Service, der Suchservice, aber kein Microservice. Also wo ist das Micro da drin?

Andy Grunwald (00:20:22 - 00:20:33)

Also ich hab noch etliche male suchen geschrieben wo ich nur SQL query gegen MySQL geschmissen hab und dann mit like prozent like nee mit like prozent suchbegriff und so weiter.

Wolfi Gassler (00:20:33 - 00:20:35)

Also du hast nie performante suchen geschrieben wolltest du sagen.

Andy Grunwald (00:20:35 - 00:20:38)

Ich hab suchen geschrieben in einem nicht microservice environment.

Wolfi Gassler (00:20:38 - 00:20:40)

Und was sind dann Nanoservices?

Andy Grunwald (00:20:40 - 00:21:13)

Ja, das ist auch noch mal so ein Begriff, der so durchs Internet schwirrt. Ich hab's mal ein bisschen versucht, ich hab noch nie mit Nanoservices gearbeitet, aber ich hab mal versucht, eine Definition rauszuziehen, und die sagen, der Unterschied zwischen Microservices und Nanoservices ist eigentlich nur die Größe und Granularität. Nanoservices sollen stark dezentralisiert sein und können sogar als Lambda Functions, also Serverless, implementiert werden. Also theoretisch kannst du dir dann eigentlich so als Eselsbrücke merken, jede Lambda-Funktion kann ein Nanoservice sein. Muss ich zugeben, finde ich ein bisschen übertrieben, aber gut, hey.

Wolfi Gassler (00:21:13 - 00:21:50)

Also das, was der Chad Fowler mit Wunderlist damals eigentlich so gemacht hat, das wäre dann eher schon so auf Nanoservice-Ebene, dass das wirklich so kurz ist. Er hat es in der Präsentation schön gesagt, die Codezeile, das Programm darf so lang sein, wobei er gleichzeitig mit seinen Fingern gezeigt hat, wie lang diese Funktion sein darf, also Daumen und Zeigefinger weggestreckt voneinander, so lang darf das Programm sein. Also das geht dann mehr in die Nano-Service-Ecke und Serverless, so wie man heutzutage auch vielleicht schnell 100 Zeilen mal programmiert, das in den Lambda Function auslagert und dann dementsprechend aufruft.

Andy Grunwald (00:21:50 - 00:22:00)

Ich habe den Talk jetzt nicht gesehen, aber es hört sich so an. Und deswegen sage ich, irgendwo finde ich es halt ein bisschen übertrieben dann. Aber hey, es mag sehr wahrscheinlich auch valide Anwendungsfälle dafür geben.

Wolfi Gassler (00:22:01 - 00:22:48)

Also was für mich eigentlich ausschlaggebend ist bei dieser Definition, ist weniger die Definition an sich oder irgendwie eine Länge oder den Funktionsscope. Für mich war eigentlich immer ausschlaggebend oder wichtig bei dieser Definition, dass es um ein Team geht, dass du die Teams unabhängig machst. Und wenn ein Team einen gewissen Scope hat, zum Beispiel die Suche oder vielleicht sogar nur ein Teilbereich der Suche, dann sollte dieser Service ausgelagert werden, damit das Team dementsprechend selbst deployen kann, selbst debuggen kann, also wie eine kleine Firma agieren kann, wie ein kleines Startup in der Firma und dementsprechend dann nur eine API zur Verfügung stellt. Das war für mich so eigentlich die Definition von der Größe von einem Microservice und das kann natürlich dann ganz unterschiedlich sein, je nach Team und je nach Funktionsaufwand.

Andy Grunwald (00:22:48 - 00:22:57)

Aber das triggert für mich auch eine interessante Frage. Deiner Meinung nach löst die Microservice versus Monolith-Frage ein technisches oder ein organisatorisches Problem?

Wolfi Gassler (00:22:57 - 00:24:00)

Also primär meiner Meinung nach ein organisatorisches, natürlich auch ein technisches, wenn du zum Beispiel zwei unterschiedliche Programmiersprachen verwenden willst, wenn dein Backend for Frontend PHP ist und dein echtes Backup Java, dann wirst du da zwei unterschiedliche Services haben, einmal in PHP und einmal in Java zum Beispiel, wie es ja oft der Fall ist. Also das ist dann mehr die technische Seite. Aber ich glaube, die organisatorische war damals eigentlich noch viel wichtiger, weil du hattest extrem große Teams, hunderte Leute, die an einem Source Code gearbeitet haben. Und da hat es natürlich überall geknirscht und geknatscht. Und das war dann extrem schwierig mit dem Deployment. Und wie bekommst du die 100 Leute unter einen Hut am Ende? Und darum hat meiner Meinung nach Microservices so ein Erfolg gehabt am Anfang und so ein Hype, weil das eben diese Erleichterung für die Teams bedeutet hat. wenn du die Strukturen ausschneidest, das ganze Deployment automatisierst, die Verantwortung von dem Ops-Team zurück in die Developer-Teams gibst. Also es war mehr so eine gesamte Bewegung, meiner Meinung nach, und weniger eine technische Änderung.

Andy Grunwald (00:24:00 - 00:24:12)

Da bin ich auch d'accord bei dir. Natürlich, wie du sagtest, die technischen Vorteile sind toll, aber ich bin mir nicht sicher, wie viele Firmen wirklich unabhängige Skalierung und Co. brauchen versus sie denken, sie bräuchten es.

Wolfi Gassler (00:24:13 - 00:24:36)

Und was vielleicht auch noch dazugekommen ist, es war überhaupt technisch möglich zu dieser Zeit. Mit der ganzen Dockerisierung ist es erst langsam gekommen, dass ich überhaupt etwas in PHP deployen kann und in Java möglichst einfach, ohne dass ich jetzt meine eigenen Server und solche Dinge zur Verfügung habe. Also es war schon auch überhaupt die technische Lösung vorhanden, damit ich diese Aufsplittung in Services überhaupt durchführen kann.

Andy Grunwald (00:24:37 - 00:24:47)

Da sprichst du aber noch ein spannendes Thema an. Und ich habe mir die Frage gestellt, ist der Erfolg von Kubernetes direkt mit dem Hype um Microservices zu verbinden?

Wolfi Gassler (00:24:47 - 00:25:25)

Das glaube ich überhaupt nicht, weil Kubernetes war ja viel, viel später als Microservices. Aber was ich natürlich schon unterschreiben würde ist, dass man heute sehr wohl eine serviceorientierte Architektur im Normalfall hat und vielleicht weniger Micro- oder Nano-Services. aber Services. Und wenn du mehrere Services hast, dann musst du die auch sinnvoll deployen, die ganze Automatisierung, die dahinter steckt. Und da sind wir dann wieder bei Kubernetes zu Hause. Wobei ich gerade neulich so ein nettes Bild gesehen habe, wo jemand so in einem Kontrollraum von einem Atomkraftwerk so im Vordergrund steht und sagt, das ist unser Kontrollraum von Kubernetes. So einfach ist es ein Pod zu deployen. Das hat mich sehr an die Realität erinnert.

Andy Grunwald (00:25:26 - 00:25:33)

Darf ich dich ganz kurz korrigieren? Das erste Release von Kubernetes war 2014 und die erste Kubernetes 1.0 war im Juli 2015.

Wolfi Gassler (00:25:33 - 00:25:41)

Ja, aber realistisch, der Hype war viel, viel später. Die ersten Microservices waren wahrscheinlich auch 2000 oder so.

Andy Grunwald (00:25:41 - 00:25:43)

Sagte der Late Adopter Wolfgang.

Wolfi Gassler (00:25:43 - 00:25:50)

Ich verwende immer noch kein Kubernetes. Nachdem ich mich in Atomkraftwerken und in Kontrollräumen schlecht auskenne, bleibe ich noch auf einfachen Infrastrukturen.

Andy Grunwald (00:25:50 - 00:26:20)

Okay, dann löse dich mal bitte von Kubernetes, sondern geh hin zu, ich würde schon sagen, fast Vorgängern. Apache Mesos und Co. Worum es da ging, eigentlich über das übergeordnete Thema Container-Scheduling. Würdest du sagen, dass dieses ganze Cloud-Native-Environment, die Container-Scheduler von den Hyperscalern und Co., dass der Erfolg schon so ein bisschen verwoben war mit Microservices? Das eine Thema hat bestimmt das andere befeuert oder so, aber würdest du sagen schon, dass es eine Relation zueinander hat?

Wolfi Gassler (00:26:20 - 00:27:18)

Ja, ich glaube, die Automatisierung an sich ist, wie gesagt, ein wichtiger Punkt. Und die hat natürlich die gesamte Bewegung und die Entwicklung in dem Automatisierungsbereich stark befeuert. Also die ersten waren ja so, die dann ganz groß rausgekommen sind, waren ja eigentlich Netflix, die das komplett automatisiert haben. Vor allem dieses ganze Monitoring, weil das Debugging wird ja dann auch extrem schwierig, wenn du hunderte Services hast, Microservices. Und irgendwo gibt es ein kleines Problem. Du brauchst Rechry-Mechanismen, du musst dein Netzwerk viel besser monitoren. Plötzlich ist dein Netzwerk vielleicht ein Bottleneck. Also die Probleme verschieben sich ja extrem stark bei der Microservice-Architektur. Und Netflix hat begonnen, Dinge zu automatisieren. Und ich glaube, die normale Welt ist dann nachgezogen und hat halt dementsprechend auch Open Source-Produkte dann entwickelt, um eben diese ganze Automatisierung voranzutreiben. Und die Containerisierung ist ja eigentlich auch, ich weiß nicht, ob es ein Produkt ist oder was da wen enabled hat. Aber ich glaube grundsätzlich, dass das technisch überhaupt möglich ist. Das ist schon eine Grundvoraussetzung.

Andy Grunwald (00:27:18 - 00:27:31)

Neben Kubernetes gibt es ja immer noch Plattform-as-a-Service-Tools wie Cloud Foundry, OpenShift und OpenStack. All das hat zu folgendem Begriff geführt, den ich sehr schön fand. Agilisierung des Betriebs.

Wolfi Gassler (00:27:31 - 00:28:42)

Ja, und ich glaube, das trifft es eigentlich ganz gut, weil wenn ich mich zurückerinnere, wie die Teams das so gesehen haben und was sie für eine Hoffnung hatten, dass sie wegkommen von diesen Ops-Leuten, von denen sie abhängig sind, dass das Ganze agiler wird, das Deployment und wie sie arbeiten, dass sie selbstständig sind, dass sie plötzlich auch Zugriff auf eine Datenbank bekommen, da vielleicht das Schema ändern können, ohne irgendwen von Obst zu fragen. Das war so richtig Lichtblick für die Teams. Und darum ist, glaube ich, die Agilisierung schon ein Begriff, der das eigentlich ganz gut zusammenfasst. Und da waren Microservices meiner Meinung nach auch super erfolgreich, weil die haben diese ganze Bewegung vorangetrieben und weitergebracht. Und auch wenn man heute sagt, okay, man will wieder weg von Microservices, wobei, da bin ich auch so gespalten, weil ich glaube, es gibt sehr viele Services. Und auch wenn man sagt, man geht zurück zu Monolithen und fasst vielleicht gewisse Services wieder zusammen. Ich glaube, die Service-Architektur bleibt. Und es gibt wenig größere Software-Stacks, meiner Meinung nach, wo es wirklich nur ein Service gibt, einen Monolithen, weil gewisse Teile sind ausgelagert, Payment zum Beispiel oder solche Dinge. Also, dass man mehrere Services hat, ist, glaube ich, schon noch der Alltag. Auch wenn man vielleicht keine Nano-Services natürlich jetzt mehr hat.

Andy Grunwald (00:28:42 - 00:28:52)

Das bringt mich wieder auf die nächste Frage. Sind Microservices denn immer einzelne Systeme oder können Microservices auch innerhalb eines Monolithen existieren?

Wolfi Gassler (00:28:52 - 00:30:43)

Ja, ich glaube, das ist der nächste Punkt, was da in dieser Welle dann entstanden ist. Und man hat eigentlich daraus gelernt, okay, man will die Teams unabhängig haben. Und dann hat man sich überlegt, gibt es nicht eine Möglichkeit, dass man die Teams unabhängig hat? in einem Monolithen und damit die Produktivität der einzelnen Teams sicherstellt, aber trotzdem am Ende einen Monolithen deployed. Und ich glaube, die ganze CI-CD-Welle, die da eigentlich entstanden ist in die Automatisierung hinein, die hat eigentlich auch gezeigt, wenn wir das alles automatisieren, die Tests automatisieren, das Deployment automatisieren, einen super lokalen DevStack haben, den man schnell hochbooten kann. Dann enabelt man da auch die Teams durch Modularisierung im Source Code. Aber jeder arbeitet am selben Monolithen. Und ich glaube, in die Richtung ist dann auch stark gearbeitet worden. Weil dann fällt natürlich die ganze Komplexität weg von deinem Netzwerk, von den Problemen, was machst du, wenn ein Service nicht erreichbar ist? Sendest du ein Request nochmal, wenn gerade das Service down ist oder zu langsam? Oder was machst du dann? Also es ist eine extreme Komplexität im Hintergrund, wenn du ganz viele Services ansprechen musst. Und wenn man das in einem Monolithen hat, dann ist es natürlich wesentlich einfacher, weil da gibt es nur einen Source-Code-Block, den man deployed. Wenn du aber gleichzeitig die Flexibilität in die Teams bringst, dann hast du natürlich gewonnen. Also glaube ich sehr wohl, dass es heutzutage möglich ist und man hat gelernt, wie kann ich die Vorteile aus der Microservice-Welt übernehmen in den Monolithen. Und wenn man heutzutage die Monolithen-Entwicklung ansieht, ist die natürlich komplett unterschiedlich als wie vor zehn Jahren, wo man eben, ob Steam gehabt hat, manuell irgendwie Tests ausgeführt hat, falls man überhaupt Tests gehabt hat. vielleicht keine saubere Modularisierung im Source-Code hatte, alles war irgendwie zusammengestöpselt, im gleichen Fall womöglich. Also man hat da schon aus der Vergangenheit gelernt und das Beste aus beiden Welten vielleicht vereint, wenn man es so plakativ sagen will.

Andy Grunwald (00:30:43 - 00:30:49)

Aber meine Frage ist jetzt, hast du eigentlich in deinem langen Monolog gesagt, das müssen einzelne Systeme sein oder müssen nicht? Weil das ist nicht ganz klar für mich gewesen.

Wolfi Gassler (00:30:49 - 00:30:53)

Nein, nein, es kann eine Monolith sein, solange es modularisiert ist.

Andy Grunwald (00:30:53 - 00:30:56)

Selten aber wahr, ich bin einer Meinung mit dir.

Wolfi Gassler (00:30:56 - 00:30:58)

Das sollten wir unbedingt ändern.

Andy Grunwald (00:30:58 - 00:31:02)

Microservices müssen nicht immer einzelne Systeme sein.

Wolfi Gassler (00:31:02 - 00:31:39)

Naja, aber sie heißen dann nicht mehr Microservices, also üblicherweise spricht man dann nicht mehr von Microservices. sondern eher von Modulen oder man könnte natürlich auch verschiedene Services in einem Monolithen starten, aber das ist ja eher unüblich. Also man vereint es dann schon irgendwie über Libraries, Module und nennt es selten Microservices, würde ich mal sagen. Aber wenn du natürlich eine unterschiedliche Route hast in deinen Monolithen, dann hast du vielleicht auch ein anderes Subsystem, was ein anderes Team maintaint. Aber du würdest es wahrscheinlich nicht Microservice nennen, sondern irgendwie Submodul oder Modul oder so in der Richtung.

Andy Grunwald (00:31:40 - 00:32:07)

Meines Erachtens nach geht das alles runter auf die reine Software-Architektur. Wie baust du deine einzelnen Module auf? Welche Interfaces werden provided? Welche Verantwortlichkeit gibt es da? Und wie koppelst du die miteinander? Und so ein paar Guidelines aufzustellen, damit man in einer Firma oder in Software-Teams effizient miteinander arbeiten kann, finde ich immer ganz sinnvoll. Und besonders für Microservices habe ich da die Independent System Architecture Principles gefunden. Die werden von der Firma InnoQ bereitgestellt, verlinken wir auch in den Shownotes.

Wolfi Gassler (00:32:07 - 00:32:12)

Ich bin sehr enttäuscht, dass du nicht mit einer DIN-Norm um die Ecke kommst, sondern mit irgendeinem amerikanischen Standard.

Andy Grunwald (00:32:13 - 00:32:20)

Soviel ich weiß, ist InnoQ eine deutsche Firma. Die haben es halt nur noch nicht bei dem Konsortium für deutsche Industrienormen eingeführt oder vorgeschlagen.

Wolfi Gassler (00:32:21 - 00:32:27)

Ich glaube fast, es gibt nicht die Namen für Microservices, bin ich mir fast sicher, aber vielleicht sind das die sinnvolleren Principles.

Andy Grunwald (00:32:27 - 00:33:30)

Auf jeden Fall umfassen die ISA-Prinzipien neun Prinzipien und das sind relativ High-Level-Prinzipien, die aber eine generelle Guidance geben, wie man Microservices entwickelt, damit eine Microservice-Architektur denn auch Sinn macht und all die Herausforderungen wie sowas wie Deployment-Monolithen und Co. vermeiden kann. Da gibt es zum Beispiel um die Trennung von Makro- und Mikroarchitektur. Und das Setzen von Regeln in Makroarchitektur. Wie zum Beispiel ein Microservice loggen sollte, wie die Authentifizierung abläuft. All die generellen Dinge sollten in der Makroarchitektur festgelegt sein. Wie das Ganze, wie der Authentifizierungsmechanismus dann aber implementiert wird oder das Logging implementiert wird, welche Library genutzt wird, das ist Teil der Mikroarchitektur. Und das obliegt dann dem jeweiligen Entwicklerteam. Das bedeutet, das Entwicklerteam hat eigentlich die Implementationshoheit, aber auf teamübergreifender Ebene definiert man die Makroarchitektur, damit man nämlich sowas wie zum Beispiel ein standardisiertes Deployment oder standardisierte Operations wie Monitoring gewährleisten kann.

Wolfi Gassler (00:33:31 - 00:33:38)

Also das ist eine Definition, wie ich in meiner Firma gewisse Dinge organisiere, auf was für einer Ebene ich was definiere.

Andy Grunwald (00:33:38 - 00:34:13)

Genau, da geht es aber unter anderem auch zum Beispiel um Deployment. Zum Beispiel ein Prinzip sagt, jeder Microservice sollte eine unabhängige Continuous Delivery Pipeline sein, dass diese unabhängig releasable ist. Oder die Art und Weise, wie du ein Service konfigurierst oder monitorst oder darauf alertest, ist für alle gleich. Das bedeutet, du hast ein gewisses Set an Standards, die du erfüllen musst. Oder da geht es auch um Resilience, wie zum Beispiel, wie ein Microservice sich zu verhalten hat, wenn er einfach mal ungraceful gestoppt wird, also mit einem Sick Kill oder ähnliches.

Wolfi Gassler (00:34:13 - 00:34:30)

Aber das gilt dann ja auch für jedes Service. Also wenn ich mal die Principles so durchlese, macht das ja für jedes Service Sinn und nicht nur für Microservices in dem Sinne. Wo wir wieder bei dem sind, ob nicht einfach die Microservice-Welt so in der Service-Welt langsam hinüberdriftet, was einfach kein cooler Hype-Begriff mehr ist.

Andy Grunwald (00:34:31 - 00:34:53)

Ich würde sagen, die ISA-Prinzipien können auch ohne Probleme auf Monolithen angewandt werden, doch den realen Value kriegen sie erst in Microservices, wenn du die Vorteile der Standardisierung wirklich rausziehen kannst, wie zum Beispiel das einheitliche Deployment, das einheitliche Operation und so weiter. Umso mehr Microservices du hast, umso mehr Sinn machen diese ISA-Prinzipien dir, weil du mehr Value rauskriegst und weniger diskutieren musst.

Wolfi Gassler (00:34:53 - 00:35:39)

Aber das ist eben meine Argumentation. Ich glaube, dass heutzutage die Best Practices, um einen Monolithen zu deployen, zu entwickeln, auch vielleicht auf mehreren Teams, eigentlich aus dieser Microservice-Ecke kommen und mittlerweile aber einfach Best Practices ganz allgemein sind, egal ob es ein Microservice, ein Service, ein Monolith, wie du das auch immer nennst, du solltest eine CI, CD-Pipeline haben, du solltest eine unabhängige Möglichkeit für dein Team haben, das zu deployen und so weiter. Also diese ganzen Dinge, sind halt heute Best Practices, auch wenn sie vielleicht aus der Microservice-Ecke kommen. Und heute würde niemand mehr sagen, eine gute CI-CD-Pipeline, die von dem Team maintained wird und verwendet werden kann, ist nur im Microservice-Umfeld möglich, sondern es sollte meiner Meinung nach heute Best Practice sein, egal in was für einem Umfeld und egal in welcher Architektur du arbeitest.

Andy Grunwald (00:35:40 - 00:36:09)

Ja, ich find das schön, wie du als Freelancer immer in deiner schönen, heilen Welt da rumtunst. Und das, was du grad gesagt hast, damit verdienst du sehr wahrscheinlich auch einen Job, wenn du nämlich zu altbackenen Firmen gehst und denen sagst du immer, das ist jetzt Best Practice und das sollten wir jetzt tun. Und hier ist mein Angebot für den nächsten Teamworkshop. Aber die Realität sieht halt ein bisschen anders aus, weil all das, wovon du da redest, nämlich jeder sollte seine unabhängige ICD-Pipeline haben und so weiter und so fort, Tut mir leid, das ist alles nicht so einfach, wenn sich einfach mal drei Teams die Köpfe einschlagen, wie das nämlich hier alles auszusehen hat.

Wolfi Gassler (00:36:10 - 00:36:34)

Ja, ich sage bewusst, es sollte so sein, aber ich spreche mir nur dagegen aus, dass ich jetzt sagen muss, ich muss eine Microservice-Architektur einführen. damit ich eine sinnvolle CI-CD-Pipeline aufbauen darf. Das eine schließt das andere ja nicht aus oder mit ein, sondern Best Practices und die kann ich dann in einer Microservice-Architektur fahren, diese Best Practices, aber auch mit einem Monolithen.

Andy Grunwald (00:36:34 - 00:36:56)

Da bin ich ja voll bei dir. Doch ich sage auch, dass umso mehr Services du bauen möchtest, angenommen die Firma befindet sich jetzt gerade in der Strategie, wir bauen jetzt alles auf Microservices, dass das Investment, ein einheitliches Regelset dafür zu haben, du hast später einen höheren Benefit, wenn du mehr Services hast, weil dann die realen Vorteile erst durchkommen, anstatt wenn du das jetzt alles dir in die Köppe einschlägst für einen Service.

Wolfi Gassler (00:36:57 - 00:37:37)

Ja, und ich glaube auch, dass es mehr Services heutzutage gibt im Standardfall. Also auch wenn der DHH behauptet, sie haben alles auf einem Monolithenlaufen, ich glaube trotzdem, dass die viele Monolithenlaufen haben, weil gewisse Services einfach sinnvollerweise ausgelagert werden. Und wenn wir wieder bei dem Suchbeispiel bleiben, wenn ich da ein Elasticsearch dahinter habe, da macht es einfach Sinn, dass das ein eigenständiges Service ist, weil das kann ich besser skalieren. Das hat andere Anforderungen und wenn es teilweise nur darum geht, dass in meinem Docker-Image gewisse Libraries verfügbar sein müssen, die ich für meinen anderen Service gar nicht brauche, dann deploye ich da vielleicht zwei unterschiedliche Docker-Container für das Ganze, weil es einfach das gesamte Handling vereinfacht am Ende.

Andy Grunwald (00:37:38 - 00:38:35)

Aber das, wo wir uns jetzt gerade so ein bisschen drüber zanken, ist ja genau einer der Hauptherausforderungen bei der Einführung beziehungsweise bei der erfolgreichen Nutzung von Microservices. Das ist die Definition von einheitlichen Strategien und Regelsets. Und da möchte ich dir kurz zwei Beispiele nennen, die ich super interessant fande. Und zwar die Firma Delivery Hero hat ein Reliability Manifesto rausgegeben, veröffentlicht auf ihrem Tech-Blog. Und da legen sie eigentlich ihr internes Regelset fest, wie auch ihre Services sich zu verhalten haben, beziehungsweise was ein Service alles bieten muss. Also nicht nur das Service selbst, sondern auch die surrounding infrastructure. Verlinken wir auch in den Shownotes. Super interessant, da geht es halt wirklich dabei um Architektur und technische Schulden, wie das delivered wird, die resilience bei Ausfall, aber auch wie man das kontinuierlich weiterentwickelt bis hin zu we track all incidents we learn from our mistakes und so.

Wolfi Gassler (00:38:35 - 00:38:48)

Weiter super aber auch da denke mir wieder wenn du da jetzt keine ahnung ob der microservice es steht oder nicht wenn du das microservice den begriff durch monolith ersetzt dann ist dieses ganze dokument wahrscheinlich auch noch gültig und macht absolut sinn.

Andy Grunwald (00:38:49 - 00:38:58)

Wolfgang keiner widerspricht dir doch den ganzen aufwand für einen service zu betreiben und alle teams auf dieses alignment zu kriegen du hast dir fehlt ja der hebel.

Wolfi Gassler (00:38:59 - 00:39:53)

Ja, aber das ist ja nicht in der Realität. Jetzt kann ich mal sagen, du lebst ja vielleicht in deiner heilen Welt, aber in der Realität gibt es schon ganz viele Services. Und meiner Meinung nach, wie gesagt, gibt es ganz wenig Plattformen, wo du wirklich einen Hardcore-Monolithen hast. Und sogar wenn du einen externen Payment-Provider anbindest, weil du hast ja selten dein eigenes Payment und deine eigene Kreditkarten-Abrechnung in-house, Das heißt, du bindest externe Services an. Das heißt, du agierst schon mit externen Services und hast vielleicht intern halt dann nur drei, vier Services und selten nur einen Monolithen. Aber auch da musst du sicherstellen, der muss erreichbar sein, der muss resilient sein. Was passiert, wenn ein Server abschmiert? Die ganzen Dinge hast du auch bei, sogar wenn du nur einen Monolithen hast und sogar da musst du viel Zeit investieren, weil wo ist der Unterschied? Wenn dein Monolith weg stirbt, auf deinem Server, dann muss der neu starten oder was auch immer machen, weil sonst ist dein Service down. Und darum gilt es auch bei den Monolithen.

Andy Grunwald (00:39:53 - 00:40:38)

Nicht ganz, weil der Unterschied ist meines Erachtens nach die Komplexität der Implementierung. Du hast ein Monolith und da vorne ist ein Loadbalancer. Der Monolith stirbt, somit sagt der Loadbalancer, ich habe keinen Backend-Service mehr, somit kann der Loadbalancer irgendeine Fehlerseite ausspielen. Hast du jetzt aber hinter dem Loadbalancer 4, 5, 6 Microservices, die gegenfalls hintereinander gechained sind mit asynchronen Requests und so weiter. Ist davon einer down, ist es doch deutlich komplexer, eine Logik in dem anderen Microservice zu implementieren, der den Fehlerfall handeln kann und dann gegebenenfalls einen Error nach vorne rausgibt, weil nur ein Zwanzigstel oder ein Zehntel deiner Infrastruktur down ist. All diese Komplexität muss ja implementiert werden und das ist eine ganz andere Komplexität, das ist eine ganz andere Diskussion, als wenn ich eine Errorseite auf dem Loadbalancer einfach ausspiele.

Wolfi Gassler (00:40:38 - 00:41:24)

Ja, aber das wäre dasselbe, wenn du hast jetzt einen Monolithen, dein Shopsystem und wenn der Payment Provider down ist, dann geht dein ganzes Shopsystem nicht mehr. Also auch da musst du mit deinen Monolithen dementsprechend agieren und umgehen, wenn das Payment Service down ist. Also mein Argument ist, dass es heutzutage eigentlich fast keine Software mehr gibt, glaube ich mal zu wissen oder zu behaupten, die nicht auf andere Services angewiesen ist. Eine CDN, ein Payment Provider, die Infrastruktur darunter, eine Datenbank oder mehrere Datenbanken, externe Service, wo irgendwelche Wetterdatenabfrage, egal was, aber Das kann mir heute eigentlich niemand mehr erzählen, dass es einen Monolithen gibt, der in sich geschlossen ist und nichts tut außer Monolith zu sein und mit keinem externen Service spricht.

Andy Grunwald (00:41:24 - 00:42:03)

Wo du einen Punkt hast, ich glaube wir alle, die Leute in der Softwareindustrie, haben von dem Cloud-Native-Movement und den Microservices gelernt, wie fragil eigentlich das ganze Internet und unsere Programmierung eigentlich sein kann und reagieren darauf. Das stimmt schon. Und du hast auch einen Punkt, dass all diese Elemente mit der Standardisierung und Co., dass diese auch für Monolithen gelten. Ich denke aber auch, dass zum Beispiel um zehn Engineering Teams, a fünf Leute, an einem Monolithen produktiv zu kriegen, ist eine unglaublich hohe Herausforderung bezüglich der Architektur, wie du die Module schneidest, wie die miteinander interagieren Aber ich glaube, das ist.

Wolfi Gassler (00:42:03 - 00:43:44)

Heutzutage auch wesentlich einfacher geworden als früher. Früher hattest du einfach weniger Möglichkeiten. Heute hast du sogar im Frontend mit Web Components und der ganzen Komponentenstruktur, die die Frameworks anbieten, eine Möglichkeit, gewisse Teile zu schneiden und dass mehrere Teams einfacher an etwas arbeiten. Früher war das einfach wesentlich komplexer und ich glaube, da haben sich auch Best Practices entwickelt, die das ermöglichen, im gleichen Source Code zu arbeiten, das lokal zu testen. Im Idealfall haben die anderen Teams auch ihre Teile super getestet. Das heißt, die Tests laufen automatisch durch in der CIDI Pipeline. Ich kann also weniger kaputt machen von anderen Teams. Ich bin durch die Frameworks oder die Architektur vielleicht auch flexibler, dass ich abgetrennter bin sozusagen oder über ein Modulsystem, wie man es dann auch immer löst. Aber ich kann selbstständig arbeiten, lokal testen, mach weniger kaputt. Es wird automatisch deployed. Und ich glaube, heutzutage ist es wesentlich einfacher, 50 Developer an einem Source Code arbeiten zu lassen, als wie vor zehn Jahren. Weil einfach das Tooling rundherum und die Frameworks wesentlich besser geworden sind. Und darum ist man, glaube ich, auch wieder weggegangen von den Microservices, weil man halt gemerkt hat, dass da auch andere Komplexität existiert. Hashtag Netzwerk unter anderem. und Resilience, weil das Problem natürlich auch irgendwo verschoben wird. Und jetzt probiert man, das halt wieder in einem Monolithen zusammenzufassen, ein bisschen zurückzugehen und das Tooling einfach auszunützen, weil das halt gewisse Sachen vereinfacht. Und wenn man aber trotzdem die Teams produktiv haltet und das sauber trennen kann, hat man im Gesamten natürlich mehr gewonnen. Aber es wird, glaube ich, so eine Mischarchitektur, die einen fetteren Monolithen hat, aber auch vereinzelt externe Services mit einbindet.

Andy Grunwald (00:43:44 - 00:44:42)

Ich meine, was du gerade ansprichst, ist eine spannende Frage. Betrifft die Diskussion von Microservices und Monolithen nur Backendsysteme? Und du hattest ja schon Webcomponents und Templates und Slots und so weiter angesprochen. Was man halt jetzt in der aktuellen Entwicklung sieht, ist, dass durch Begriffe wie Headless Frontends oder sogar, da geht man jetzt sogar weiter in Microfrontends, dass sich diese ganze Microservice-Architektur nicht nur aufs Backend bezieht, sondern auch aufs Frontend, was natürlich dann mehr oder weniger Sinn macht, weil wir kennen alle diese Memes, wo man ein schönes Frontend hat, eine schöne UI und hinten dran ist so ein Friedhof und das deklariert so das Backend-System. Weil niemand benutzt heute Services, die einfach scheiße zu bedienen sind und somit kann es auch sehr gut sein, dass man halt 50 Entwickler nur fürs Frontend hat. Ich meine mal gelesen zu haben, dass die Spotify-App, die auch nur eine Web-App sein soll, aus mehreren solcher Microfrontends bestehen soll und dass jeder teil irgendwie die seitenleiste und so weiter und so fort dann von einem einzelnen team entwickelt und.

Wolfi Gassler (00:44:42 - 00:45:09)

Deployed wird ja wie gesagt auch das ist mittlerweile ein standard best practices und ist über komponenten einfach sinnvoll lösbar und Das hat sich einfach geändert, dass du die Sachen schneiden kannst und die Teams unabhängig voneinander daran arbeiten können, sei es im Frontend oder im Backend. Und früher war das halt das große Versprechen mit Microservices wird sowas ermöglicht und heute oder gebrauchst du aber keine Microservices mehr dafür. Du brauchst vielleicht Services, aber dieses Micro fällt zumindest weg.

Andy Grunwald (00:45:10 - 00:46:15)

Meines Erachtens nach ist das aber all das, was du sagst, kein Garant dafür, dass die ganze Sache auch erfolgreich umgesetzt wird. Denn wir haben gerade über diese ISA-Prinzipien gesprochen, und dieselbe Firma hat einen schönen Blogbeitrag rausgebracht, warum Microservice scheitern. Weil, nur mal kurz zur Info, InnoQ ist eine Firma, die kümmern sich um Softwarearchitektur, um Technologieconsulting und so weiter. Das bedeutet, die sehen halt sehr viele Projekte. Und die haben mal eine schöne Auflistung gemacht, warum viele Microservice ... Projekte scheitern und einer der Hauptpunkte ist unter anderem die Organisation beziehungsweise die Unabhängigkeit von Teams beziehungsweise auch das Alignment zwischen den Teams hinzukriegen, denn Entscheidungen müssen getroffen und koordiniert werden. Teams müssen kontinuierlich miteinander sprechen. Teams selbst müssen auch eine Entscheidungsgewalt haben über ihre Services. Wir haben gerade über Makro- und Mikroarchitektur gesprochen. Manche Regeln sollten aber global getroffen werden und das kann mit hoher Wahrscheinlichkeit oder sollte nicht immer nur von einer zentralen Gruppe von Architekten gemacht werden. Also da gibt's von Haus aus schon ziemlich viel Friction.

Wolfi Gassler (00:46:15 - 00:47:05)

Wo wir genau wieder bei dem organisatorischen Teil sind, dass es viel schwieriger ist, es organisatorisch zu regeln und du musst dich vielleicht auf ein gemeinsames Datenmodell einigen, aber komplett unabhängig davon, ob du da mit Microservices arbeitest, ob du mit Modulen arbeitest, wenn viele Leute miteinander arbeiten, dann musst du das organisatorisch hinbekommen. Und da ist eigentlich die große Challenge mit der Kommunikation, mit dem Alignment zwischen den Teams. Ob da jetzt eine API dazwischenhängt innerhalb von einem Monolithen oder einer HTTP API oder eine Datenbank mit einem ganz klassischen Modell in der Datenbank, die Probleme hast du immer. Und ich glaube, die gilt es zu lösen. Und dort entstehen auch die Best Practices, die helfen, diese Organisationschallenges zu lösen und alle Teams unter einen Hut zu bringen. Und da ist die Technik meiner Meinung nach komplett egal.

Andy Grunwald (00:47:05 - 00:47:09)

Ich bin nicht ganz d'accord, dass die Technik alles komplett egal ist.

Wolfi Gassler (00:47:09 - 00:47:24)

Ja, natürlich. Du brauchst natürlich schon eine gewisse Technik, die das ermöglicht, dass deine Teams unabhängig sind. Aber ich glaube, viel größer ist die Challenge, die in deinen Teams besteht und mit dem Alignment und der Kommunikation, weil die Technik existiert, die dir das ermöglicht.

Andy Grunwald (00:47:25 - 00:47:48)

Das ist richtig, aber z.B. wenn du einen Monolithen hast, manche Probleme treten ja gar nicht auf, wie z.B. das gemeinsame Datenmodell. Mit dem gemeinsamen Datenmodell, das kann zwar anders genutzt werden, aber z.B. angenommen, du hast hintendran eine Datenbank und drei Microservices obendrauf. Was du dann hast, ist eigentlich das Problem, dass du das Datenbankschema nicht ändern kannst, ohne alle drei Services gleichzeitig upzudaten.

Wolfi Gassler (00:47:49 - 00:48:23)

Ja, aber das Problem hast du in den Monolithen genauso, weil wenn du verschiedene Teams hast, dann fängt jedes Team an mit eigenen Tabellen oder mit irgendwelchen Views auf den Daten und keiner kennt sich mehr aus. Also wenn du dich auch da nicht auf ein Datenmodell einigst oder es sinnvoll im Source Code hast, dass du da die gleichen Entitäten verwendest und nicht wieder extra irgendwas aus der Datenbank rausholst, deine eigenen Modelle baust, was sehr wohl passieren kann, wenn du in einem Source Code arbeitest, was ja ein großes Problem ist. dann scheiterst du auch mit einem Monolithen daran. Und sogar vielleicht noch ordentlich.

Andy Grunwald (00:48:23 - 00:48:50)

Wir reden von zwei verschiedenen Dingen. Ich rede von Deployment-Monolithen, wo du drei Microservices hast und das Schemata der Datenbank wird geändert, dass du alle drei Microservices anpassen musst und automatisch gleichzeitig deployen kannst. Du redest von einem Monolithen, wo jeder einzelne Tabellen hat, was dann zu Dateninkonsistenz führen kann. Das sind für mich zwei Probleme. Denn ein Monolith, wo das Schemata geändert wird, wo ein Feld gelöscht wird, wird automatisch angepasst, weil du hast ja einen Monolith.

Wolfi Gassler (00:48:50 - 00:49:03)

Wie machst du denn das in der Realität? Du musst ja die Datenbank updaten. Die Datenbank ist schon eigene Service von deiner Software. Du kannst nicht gleichzeitig die Datenbank deployen und deine Monolithen. Und wenn dein Monolith fünf...

Andy Grunwald (00:49:03 - 00:49:03)

Warum nicht?

Wolfi Gassler (00:49:03 - 00:49:17)

Und wenn dein Monolith fünfmal gestartet wird in der Cloud, dann hast du auch noch ein Problem. Wie machst du das? Dann müsstest du alle fünf gleichzeitig durchtreten, dann die Datenbank in der Zwischenzeit updaten und dann wieder alle gleich hochfahren. Sonst hast du ein Problem.

Andy Grunwald (00:49:17 - 00:49:27)

Jetzt komm mal raus aus seinen Kinderschuhen. Also jeder weiß ja wohl, dass man nicht einfach ein Feld von jetzt auf gleich löscht, sondern dass man da eine Migrationsphase drin hat, damit man Breaking Change hat, bis alle Services das haben.

Wolfi Gassler (00:49:28 - 00:49:30)

Ja, aber dann hast du das selber mit drei Services.

Andy Grunwald (00:49:30 - 00:50:10)

Bei einem Monolith habe ich zwei Release-Cycles für die Migrationsfahrt, bei drei Microservices von drei unabhängigen Teams weiß ich nicht wann es ist, das kann ein Jahr dauern, wenn der eine Microservice das ganze Jahr nicht deployed wird. Bei Monolithen habe ich dafür immer zwei Deployment-Cycles. Einmal es wird angepasst und beim zweiten Mal wird's removed. Das ist ja der Vorteil von Monolithen in der Hinsicht, dass nämlich ein Team unter anderem auch Änderungen an anderen Teams machen kann durch ein Pull-Request. Die werden zwar dann in anderen Klassen gemacht und so weiter und so fort. Dennoch kann das alles in einem Service gemacht werden und somit kann ich Schemata-Änderungen in zwei Deployment-Cycles machen, wobei Microservice natürlich nicht.

Wolfi Gassler (00:50:11 - 00:50:24)

Aber da sind wir wieder bei dem Thema, dass du dann Microservices oder Services falsch designt hast, weil du ja einen abgeschlossenen Scope haben solltest. Und daher solltest du eigentlich nicht drei Services haben, die auf die gleiche Datenbank zugreifen überhaupt.

Andy Grunwald (00:50:25 - 00:51:23)

Und da sind wir jetzt wieder d'accord bei den Herausforderungen. Denn bei einer schlechten Struktur, nämlich wie Microservices genutzt werden, hast du nämlich genau diese Probleme. Wenn nämlich drei Microservices eine Datenbank nimmt, dann hat man halt diesen Deployment Monolithen, weil dann haben die Teams, die die Microservices maintainen, auch keine komplette Autonomie über ihre Daten und Co. Das wiederum, jetzt angenommen jeder dieser Microservices hat jedoch seinen eigenen Datenstorage, hat dann eine andere Herausforderung zur Daten Inkonsistenz. Weil da können nämlich Daten auch auseinanderlaufen. Weil was ist, wenn jeder dieser Datenstorages selbst eine Entität kundemaintaint? Was ja sein kann. Da muss dann ganz stark aufgepasst werden, dass die Datenstände nicht auseinanderlaufen. Beziehungsweise, wer hat die Hoheit? Also ein Microservicesystem ordentlich zu schneiden, dass die Daten konsistent sind, Teams aber autonom unterwegs sind, ist unglaublich hart.

Wolfi Gassler (00:51:23 - 00:51:55)

Und ich glaube, genau das ist der Hauptgrund, warum der Monolith aktuell wieder in aller Munde ist und man vielleicht wieder weiter weg geht von den Microservices, weil diese Dinger einfach extrem kompliziert und komplex sind. Aber gleich wie früher, wie man zu Microservices hin wollte, wo man gesagt hat, Microservices sind nicht die Lösung für alles, Ich würde auch sagen, nur weil man ein Monolith hat, sind nicht alle Probleme gelöst, weil die Kommunikationsprobleme und die Datenmodellierungsprobleme gibt es meiner Meinung nach immer noch, aber vielleicht ist es einfacher, sie zu kontrollieren und in den Griff zu bekommen.

Andy Grunwald (00:51:55 - 00:52:40)

Eine Herausforderung bei Microservices, die ich schon öfters erlebt habe, wo die meisten Engineering Teams gar nichts für können, ist einfach, ich sag mal Firmenpolitik. Und zwar geht es um die Umstrukturierung innerhalb einer Firma. Wenn eine Firma wächst oder wenn harte Zeiten im finanziellen Bereich auf die Firma zukommen, dann ist es oft so, dass das C-Level Management oben ein paar Boxen verschiebt. Zwei Abteilungen werden zu einer gemacht, weil das effizienter klingt und so weiter und so fort. Und das C-Level ist natürlich so weit weg von den technischen Implementierungen. Die interessiert das in der Regel ja nicht, ob da Microservices oder Monolithen oder eine serviceorientierte Architektur ist oder Lambda oder oder oder, sondern die schieben Boxen, die schieben Menschen hin und her, um Effizienz zu erschaffen.

Wolfi Gassler (00:52:40 - 00:52:43)

Und zerstören da gleichzeitig unter Umständen ganz viel Effizienz.

Andy Grunwald (00:52:44 - 00:53:24)

Ja ganz genau und wir reden die ganze Zeit von Microservices und autonomen Teams und da kommt es dann natürlich auch ganz auf die Ownership drauf an. Mein Team ownt Service A und Service B oder ähnliches und dann werden Leute gemixt und so weiter und auf einmal bleiben da fünf Services über, die keinen Owner mehr haben, weil das Team wegrationalisiert wurde auf Basis von Effizienz und dann hast du da halt so 100 Container irgendwo in deiner Infrastruktur, die dingeln da so ein bisschen rum. Oder du hast auf einmal Teams, weil die unglücklich geschnitten wurden oder unglücklich umstrukturiert wurden, die auf einmal mit sechs Leuten acht Microservices maintainen. Was ja dann das andere Extrem ist.

Wolfi Gassler (00:53:25 - 00:54:34)

Ich meine, diese Möglichkeit ist eh noch die bessere, würde ich sagen, dass Teams zusammengefasst werden oder ein Team ganz viele Microservices wartet. Das ist ja die positivere Variante. Und in diesem Zusammenhang sollte man eigentlich unbedingt Conways Law ins Spiel bringen, haben vielleicht die einen oder anderen schon mal gehört, Gesetz von Conway, die genau diese Problematik beschreibt, dass Schnittstellen in IT-Teams oft so designt werden, wie die Teams gebildet werden. Wenn du jetzt im Nachhinein aber ein Team z.B. zerschneidest, dann hast du das Problem, dass die API nicht mehr die Teamstruktur widerspiegelt und womöglich die Ownership von einer API von einem Service in zwei Teams liegt. Und dann hast du ein Riesenproblem natürlich. Weil ursprünglich wolltest du ja, dass deine Teams möglichst unabhängig sind. Das heißt, die ownen eine API. Das wird so geschnitten. Und plötzlich gibt es zwei Teams, die für eine API verantwortlich sind. Und das müsstest du dann irgendwie trennen. Aber dann gibt es zwei Teams, die einen Monolithen quasi programmieren. Und du hast natürlich ein Riesenproblem. Und daher sind Umstrukturierungen so gefährlich für die internen technischen APIs und Schnittstellen, die existieren.

Andy Grunwald (00:54:34 - 00:55:14)

Als wir bei Trivago gearbeitet haben, ist Trivago ja auch sehr stark gewachsen und dann in der Corona-Pandemie vielleicht auch ein bisschen sehr stark wieder geschrumpft. Aber was ich mehrmals gesehen habe, wenn die Firma umstrukturiert wurde, von diesen Umstrukturierungen und dann von diesem Ownership-Shuffling, nenne ich das mal. Ich glaube, wir haben uns noch nie 100 Prozent von einer Umstrukturierung erholt, was dann die Neuallogierung der Ownership der Services und Komponenten Ich glaube, wir hatten immer irgendwelche Services, die dann so ein Catch-all-Team geerbt hat, weil so eine Umstrukturierung kann auf die Softwarearchitektur in Bezug zum Beispiel auf Converse Law einen unglaublichen Longtail haben.

Wolfi Gassler (00:55:14 - 00:56:13)

Und wir haben das ja in Episode 62 schon besprochen, wo wir diskutiert haben, ob man besser Technologien konsolidieren soll oder einfach jede Programmiersprache oder Technologie verwenden kann, wie man denn so will. Das hat natürlich dann bei so einem Problem auch einen großen Einfluss, weil wenn du plötzlich eine Programmiersprache als Team erbst, die du gar nicht kannst, die du vielleicht noch nie programmiert hast in deinem Leben, dann hast du natürlich auch ein großes Problem. Und umso größer die Firma, umso mehr Umstrukturierungen es gibt, umso schwieriger wird es, diese ganzen Technologien, aber auch die ganzen APIs und Schnittstellen unter einen Hut zu bringen. Und da würde ich mal sagen, bist du vielleicht mit den Monolithen in der gleichen Programmiersprache auch besser dran, als wir mit Microservices. Wobei du natürlich genauso diese harten Cuts und Schnittstellen in der Software haben kannst, also in den Monolithen haben kannst. Aber ich glaube, bei der Microservice-Architektur ist es noch mal schwieriger, solche Umstrukturierungen zu handeln. Aber falls ihr gute Gegenbeispiele kennt, würde uns natürlich freuen, diese zu hören.

Andy Grunwald (00:56:13 - 00:56:17)

Wir haben jetzt natürlich ziemlich viel auf beiden Seiten rumgehackt.

Wolfi Gassler (00:56:17 - 00:57:09)

Ja, für mich ist das schon dieses Grundsatzproblem, diese beiden Seiten. Für mich gibt es diese beiden Seiten nicht, sondern es sind einfach Entwicklungen. Man lernt daraus, erstellt wieder Best Practices, die den einen oder anderen Bereich helfen. Meiner Meinung nach gibt es auch nicht diese klare Trennung. Ich habe eine Microservice-Architektur oder nicht, weil heutzutage ist alles in Services eingeteilt und man geht vielleicht weg von dieser Hardcore-Nano-Service-Architektur, zumindest in manchen Bereichen, zurück zu eher monolithischen Herangehensweisen, aber aufgeteilt auf mehrere Services. Darum ist es für mich kein entweder oder oder ich mache die Seite oder die Seite oder die Architektur oder die Architektur. Das ist alles beweglich und wird ständig neu definiert und man muss sich einfach die perfekte Architektur rauspicken und sollte aber die Best Practices, die man so aus den letzten Jahrzehnten gelernt hat, einfach dementsprechend anwenden.

Andy Grunwald (00:57:09 - 00:57:14)

Ja gut, du kannst aber auch nicht immer ein Rewrite machen. Für mich ist das so wie Ja.

Wolfi Gassler (00:57:14 - 00:57:22)

Genau das meine ich. Es ist alles in Bewegung, und es ist beweglich. Also, es gibt nicht X oder Y. Es ist immer irgendwas Flexibles dazwischen.

Andy Grunwald (00:57:23 - 00:57:49)

Da solltest du jetzt aber auch nicht in das andere Extrem pendeln, dass du sagst, ja, aber was ist, wenn der Rehort kommt, dann muss das doch flexibel anpassbar sein und so weiter, weil dann shippst du ja auch nie was, dann gehst du ja voll ins Over-Engineering. Also, löst halt schon deine aktuellen Probleme, denke ich, und nicht, ja, was wäre, wenn ... Ich hab da auf dem Flur gehört, dass dieses Team bald, bla, Das macht keinen Sinn. Ich denke einfach nur, es gibt nicht das eine oder andere. Ich denke einfach, beides ist gleich scheiße. Kennst du den Comedian Serdar Suomuncu zum Beispiel?

Wolfi Gassler (00:57:49 - 00:57:49)

Nee.

Andy Grunwald (00:57:49 - 00:58:44)

Serdar Suomuncu ist ein Deutsch-Türke, irgendwie sowas. Und der geht auf die Bühne, der sagt einfach, ich beleidige einfach alle. Ich hack nicht nur auf denen rum, sondern auch auf den anderen. Ich beleidige einfach alle und deswegen sage ich auch, beides ist gleich scheiße. Monolithen sind scheiße, Microservices sind scheiße. Weil irgendwann kommt jemand rum, macht eine Reh-Org, Und dann hast du auch die Probleme. Entweder hast du dann Monolithen, und dann wär eine Microservice-Architektur toll, weil die Teams dann autonomer wären. Oder du hast eine Microservice-Architektur, da kommt ein Re-Org, und dann wird das alles wieder so geschnitten, als hättest du gern Monolithen. Also, ich glaub, du hast immer die Probleme. Und ich glaub, das ist dann auch unser Job, das alles ein bisschen zu richten und vielleicht ein bisschen Awareness da reinzubringen, dass dieses Thema nicht entweder-oder, sondern dass das auch koexistent sein kann. Und dass die ganze Sache nicht so einfach ist, mit einem Kubernetes und einem Service Mesh mit Istio und alles auf GCP. Damit ist es halt auch nicht getan.

Wolfi Gassler (00:58:44 - 00:59:50)

So mit dem Positiven hast du es nicht, oder? Alles ist scheiße. Das am Ende hat eh schon positiver geklungen. Wie gesagt, ich glaube, du kannst sehr viel lernen aus dieser ganzen Entwicklung und kannst auch sehr viel rausholen und Probleme vermeiden. Und meiner Meinung nach kannst du sehr wohl strategisch denken und vielleicht, wenn du in einer größeren Firma bist und als CTO oder in Architekturverantwortung, dass du vielleicht zum Beispiel eben nicht diesen Jett-Fowler-Ansatz nimmst, dass jeder alles machen kann, wie es ihm gefällt, sondern wie wir es auch in Episode 62 besprochen haben, vielleicht dann doch gewisse Einschränkungen machst, wenn es um Technologien geht. Also es gibt sehr wohl Dinge, die man auch schon vorausplanen kann, kommt natürlich darauf an, in welcher Ebene man ist und was man zu verantworten hat. Aber ich glaube, ein Blick in die Zukunft kann schon helfen, auch wenn man nicht alles in die Zukunft ausrichten sollte natürlich. Aber wie gesagt, kommt auch darauf an, auf welcher Ebene du bist, wie groß die Firma ist, in welchem Stadium du dich befindest und dann solltest du dementsprechend sinnvolle Entscheidungen treffen und da ändert sich dann natürlich auch der Weitblick, würde ich mal sagen, wie weit du nach vorne blickst oder eben auch gar nicht als kleine Startup vielleicht.

Andy Grunwald (00:59:51 - 00:59:55)

Wolfgang, darf ich dir zum Ende dieser Episode noch etwas Feedback geben?

Wolfi Gassler (00:59:55 - 00:59:56)

Ich bete darum.

Andy Grunwald (00:59:56 - 01:00:17)

Dafür, dass du in einem so tiefen Motivationsloch warst, hast du dafür aber sehr energetisch diskutiert. Also so tief kann das Motivationsloch ja auch nicht gewesen sein. Also das ist positives Feedback, weil entweder habe ich einen Weg gefunden, dich auf die Palme zu bringen, oder du bewirbst dich jetzt in Hollywood als Schauspieler, um einem Motivationstief vorzuspielen.

Wolfi Gassler (01:00:17 - 01:00:29)

Na ja, Motivation heißt ja, dass man über was gerne diskutiert und nicht nur aus seinem Motivationsloch geholt wird, weil der andere einfach Sachen behauptet, wo man unbedingt dagegen was sagen muss. Das ist ja fast Notwehr.

Andy Grunwald (01:00:29 - 01:00:32)

Und wo zählst du jetzt diese Podcast Episode dazu?

Wolfi Gassler (01:00:32 - 01:00:32)

Unter die Notwehr.

Andy Grunwald (01:00:35 - 01:00:57)

Liebe Hörerinnen und Hörer, wenn ihr auch was zu diesem Religionskrieg beizutragen habt, könnt ihr gerne in unserer Discord-Community joinen. Link findet ihr auf unserer Webseite und in den Shownotes. Ich denke, es gibt sehr viele Leute mit unterschiedlichen Meinungen zu dem Thema, was uns dann natürlich auch sehr freuen würde, wenn ihr uns von eurer Meinung teilhaben lässt, denn auch wir sind nicht perfekt.

Wolfi Gassler (01:00:57 - 01:01:12)

Und falls ihr sonst irgendwie Geschichten oder auch Links zu dem Thema habt, freuen wir uns natürlich auch immer in der Community über die Links und den Knowledge Austausch, der dort stattfindet. Es ist immer wieder spannend, den einen oder anderen neuen Blog-Eintrag zu lesen.

Andy Grunwald (01:01:12 - 01:01:18)

Das war's von uns. Alle Links wie immer in den Show Notes. Wir wünschen euch noch einen schönen Tag und bis bald.

Wolfi Gassler (01:01:19 - 01:01:20)

Tschüss! Ciao!