Transkript: Microservices

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast, Episode Nummer 41.

Heute unterhalten wir uns über Microservices.

Schön, dass ihr wieder eingeschaltet habt.

Hi Joan.

Hallo Dominik.

Und wir haben einen Gast dabei.

Guten Abend.

Hi Janis.

Ja, das bin ich.

Hallo, hallo Janis.

Ich bin der Dominik.

Ich bin der Janis.

Ja, dann.

Janis, willst du dich mal kurz vorstellen, vielleicht direkt?

Ja, das geht schnell.

Ich bin der Janis.

Noch 29 Jahre alt, jung, aus Wuppertal.

Ich entwickle mit Python viel und oft und gerne.

Bereich Data Engineering, Data Science.

Irgendwo da bewege ich mich rum.

Und du hast gesagt, du hättest was zu Microsoft zu sagen und deswegen unterhalten wir uns heute darüber.

Ich würde sagen, wir fangen wieder mit News aus der Szene an.

Ja, genau, machen wir das immer.

Was hast du denn?

Ja, ich weiß nicht, hier so ein bisschen wild gemischt ist, auch nicht nur Python, aber ich dachte irgendwie, gut, das hat schon eine gewisse Relevanz, weil ich weiß ja nicht, aber vielleicht gibt es ja auch sogar Leute hier zuhören oder dabei sind gerade, die irgendwie davon betroffen sind.

Es gab da so eine Sicherheitsschwankung bei Okta.

Ja.

Ich weiß nicht, wenn du meinst, denn betroffen gemacht.

Keine Ahnung.

Ja, also das fand ich, war mal wieder.

Also October erst so ein Multi-Login-Service, Single Sign-on.

Ja, genau.

Viele Kunden, viele Konzerne sind da Kunden und so.

Und eigentlich war sozusagen die Marketing-Story dabei halt irgendwie, ja, du musst irgendwie keinem vertrauen und das funktioniert einfach so und das löst das Problem für dich.

Und jetzt mussten die Leute, die das irgendwie, die diese Dienstleistung in Anspruch genommen haben, feststellen, dass sie doch jemandem vertrauen mussten.

Und dass sie dem eigentlich nicht wirklich vertrauen können, weil die Kommunikation war halt so, dass sie irgendwie nur so scheibchenweise zugegeben haben, was da eigentlich passiert ist.

Tja.

Und das ist natürlich schlecht.

Ja, das ist also, ich würde auch sagen, das ist ziemlich beschädigt jetzt auch mal.

Ja, ja, aber ich meine, ich habe mich da ja mal, ich frage mich, warum das, warum das gerade große Unternehmen so leicht fertig machen, weil das ist ehrlich gesagt irgendwie, sieht irgendwie schon von weitem wie eine nicht so richtig gute Idee aus, da sowas zu machen, so gerade Authentifizierung irgendwie outzusourcen.

Ja, weil die alle nicht wissen, wie das geht und weil die das Problem haben, dass die ganz viele kleine Anwendungen haben, die Leute benutzen und die alle irgendwo ihre Passwörter verhalten sollen und die dann immer unsicherere Passwörter nehmen, wenn die ganz viele verschiedenen Services auf ihrem Rechner benutzen sollen oder so.

Und diese Single-Sand-On, da kann man dann, glaube ich, die Policies vielleicht ein bisschen besser einhalten und die Leute dazu, dass sie so ein bisschen mehr drüber nachdenken, was die tun.

Ja.

Ja, gut, Single-Sand-On verstehe ich auch irgendwie, aber ich verstehe nicht so richtig, warum man dann auch.

Wenn man das selber machen muss, dann haben wir es genau, ist auch wieder schwierig.

Ja, also das war auf jeden Fall, denke ich, ein großes Ding, was dann irgendwie in der letzten Jahr

passiert ist.

Ja, ich habe auch für Okta tatsächlich so ein Dunkel-Modul geschrieben, mit dem das dann doch irgendwie geht, aber ja, das ist halt nutzer nichts, wenn Okta kaputt ist.

Ja, doof.

Mehr News.

Dann, äh, ah, oh, gibt es einen, wir hatten ja schon mal diesen Thiobel Programmiersprachen.

Ach, der spannende große

Index, ja.

Index, der immer so zitiert wird, wo man dann irgendwie, wenn man genauer drauf schaut, sehen muss, oh, die gucken nur, wie die Menge der Suchergebnisse bei so ein paar Suchanfragen aussieht und das ist ja alles irgendwie so, wie viel das so sagt, keine Ahnung.

Es gibt einen anderen, der macht so was ähnliches, der heißt Pipel, Piple, ich weiß gar nicht, wie der heißt.

Naja, jedenfalls, da ist Python auch momentan die beliebteste Programmiersprache.

Oh je.

Also das ist, insofern kann man sagen, es ist halt jetzt nicht nur ein Service, der das halt sagt, sondern es gibt mehrere, die das halt unabhängig voneinander rausfinden.

Insofern wird das ein bisschen mehr Glaubmürdigkeit, dass da irgendwie was dran sein könnte.

Ja, es ist auf jeden Fall Python sehr populär zur Zeit.

Sogar Meta hat einen großen Beitrag an die Python Software Foundation gespendet, habe ich mitbekommen in letzter Zeit.

Ja, das sind tatsächlich sehr gute Neuigkeiten.

Das ist ja eigentlich noch nicht so lange her, dass tatsächlich die, also Python Software Foundation irgendwie, hatte bisher alles Mögliche um diese, um die Marke, drumherum gemacht und so und irgendwie Rechtsbeistand und solche Sachen für irgendwie Leute, die das verletzen.

Und so, aber sie haben halt eigentlich keine Entwicklung bezahlt oder niemanden gehabt, der halt, es gab niemanden, der sich Vollzeit irgendwie bezahlt um Python gekümmert hätte.

Und klar, es gab Leute, die bei Firmen gearbeitet haben, dann zumindest einen Teil der Zeit irgendwie dafür zur Verfügung, irgendwie sich damit zu beschäftigen, aber jetzt gibt es seit, ich weiß nicht, ist das jetzt schon seit zwei Jahren, glaube ich.

Ja, ja.

Wird auch verlängert.

Developer in Residence sozusagen und zuerst hat Google den bezahlt und das ist Lukas Langer macht das, macht das sehr gut.

Schreibt auch immer wieder Blogposts, was er so tut.

Und jetzt quasi damit bezahlt das jetzt erstmals auf Facebook, was natürlich super ist.

Und ja, vielleicht werden jetzt ja nochmal irgendwann mehr Leute, also es ist auf jeden Fall, wird es irgendwie mehr Geld und das ist ja schon mal toll.

Ja, genau.

Voll gut.

Ja.

Also ich meine, eigentlich denke ich, dass große Konzerne das ja eigentlich fast wie eine Art Versicherung sehen können.

Sollte man meinen.

Sollte man denken, dass sie das so betrachten, weil wenn das irgendwie nicht mehr funktioniert, dann haben die ein großes Problem, was sie sehr teuer zuständig kommen hat.

Es ist halt schwierig, sowas zu vermitteln, dass du halt irgendwie Dinge bezahlen musst, die in der Zukunft eventuell einen Return on Rest geben und

auch nur ein Risiko abwenden.

Ja, aber dass das gerade bei Open Source, die kriegt man ja einfach immer so umsonst.

Das reduziert ja bis meistens immer nur irgendwie die Kosten auf einer Kostenstelle.

Ja.

Ja.

Ja, ja, das genau.

Aber irgendwie geht es da voran, das ist voll gut.

Ja, was haben wir noch?

Oh, äh, genau, Bugspython.org, da weiß ich auch schon seit Jahren.

Versuchen wir da irgendwie zu migrieren auf GitHub.

Ist aber noch nicht.

Nein, wir haben

es verschoben.

Achso.

Auch jetzt am 8.

April, also quasi bald.

Nicht übermorgen, aber in ein paar Tagen.

Und zwar auf uns schon GitHub, weil die gesagt haben, oh, wir haben Schwierigkeiten, da weiß ich, ob das, wissen nicht, ob das funktionieren wird, wenn wir die als alle so eine Menge-Issues erzeugen und so.

Wartet lieber nochmal ein bisschen.

Ja.

Okay, ja gut, das setzt du nicht mehr so lange hin.

Also ist jetzt quasi, wenn ihr es hört, vielleicht schon migriert.

Oder kurz davor.

Und gestern am 4.4.

ist tatsächlich Seiten 20.

Seiten 20 Jahren geworden.

Das ist auch ein richtiger Meilenstein.

Hätte ich jetzt auch nicht gedacht, aber das ist natürlich alles irgendwie Zeitgefühl, komische Sache.

Das ist schon ein bisschen abgehangen, gemerkt, wie erstmal alt wird.

Ja, aber Seiten ist total wichtig, super.

Also immer wenn man sich fragt, okay, ja, Python selber langsam, aber macht trotzdem Dinge schnell und so, wie geht denn das eigentlich?

Ja, da ist meistens Zeit-Ran beteiligt und ja, tolles Projekt.

Irgendwie man schreibt so eine Python-ähnliche Syntax und das wird dann halt in C Cross-Compiles sozusagen und dann.

Man kann auch C-Funktion direkt laden, glaube ich, wenn man das möchte.

Ja, genau, und dann kann man es wieder einbinden als Python-Modul.

Dann gibt es sogar sowas wie ein Cell Magic in Jupyter Notebooks oder JupyterLab.

Und da kann man einfach sagen, Prozent, Prozent Zeiten und dann wird das halt eine Funktion einfach so wieder reimportiert und dann wird die halt tausendmal schneller oder so.

Das ist halt sehr schick.

Ja.

Ja, okay.

Also Apo, kennst du Wie, die Language?

Wie Läng V.

Ja.

Bin ich irgendwie letztens so gestolpert, weil ein Kollege mich drauf brachte und habe ich mal geguckt, kannte ich noch nicht, ist noch in so einer Beta-Version.

Sieht irgendwie witzig aus, so eine Kombination von Rust und Go irgendwie.

Ja, momentan ist auch wieder so die Zeit für neue Programmiersprachen.

Letztens habe ich gehört von Sig.

SIG.

Das ist auch so ein Ding.

Voller lustiger Name, das ist wieder so, wenn man drüber fällt, aber den Namen direkt nicht so.

Ja, das sieht auch so ein bisschen aus wie eine Kreuzung aus Go und JavaScript und irgendwie Rust und weiß nicht, ganz vielen Dingen.

Also ich habe es noch nicht reingeguckt, also falls ihr darüber was wisst, das könnte auch interessant sein.

Also wie lange IO.

Okay, ich muss mich mir auch mal angucken.

Kompliziert auch zu C, deswegen kam ich gerade drauf.

Ach so, ah, okay.

Das ist ja auch interessant.

Ja.

Witzig.

Ja.

Ja.

Okay.

Dann sind wir eigentlich schon fast.

Das war diesmal schnell.

Ja, wir haben gar nicht mehr sonst.

Ja, dann sind wir damit eigentlich durch.

Achso, ja, haben wir eigentlich Veranstaltungshinweise oder sowas?

Ja, das wollten wir.

Achso, du wolltest du wolltst vor PyCon, bist du da?

Fritz findet man dich da.

Montan sieht es nicht danach aus.

Ich hätte jetzt zufällig, also zuerst hatte ich gedacht, das schaffe ich irgendwie nicht, beziehungsweise ich habe gar nicht so richtig mitbekommen, dass sie überhaupt stattfindet.

Also vor Ort, weil das wäre es für mich interessant geworden, aber nicht vor Ort halt eher nicht so richtig.

Weil das schaffe ich eben, wenn ich, das habe ich auch schon mal probiert, irgendwie Remote-Aufkonferenzen oder dass es funktioniert eigentlich.

Dann warten wir jetzt eine halbe Stunde da und dann gepa.

Ja, genau, und dann ist halt vorbei.

Und das funktioniert einfach nicht.

Also wenn das funktionieren soll, muss ich da irgendwo hin und getrennt sein von irgendwie anderweitigen Verpflichtungen.

Und da habe ich das halt nicht so mitgekriegt, dass das tatsächlich vor Ort sein sollte.

Und dann habe ich es mitgekriegt und dann waren aber schon Tickets, und dann dachte ich, ich hätte gerne Zeit und dann habe ich dann gemerkt, oh, ich habe vielleicht doch Zeit und dann waren aber keine Tickets mehr da.

Insofern.

Ja.

Na gut, wenn es daran lag.

Aber vielleicht machen wir auch nochmal eine Sendung oder so dazu, wie das da gewesen ist von Finden, noch Leute, die da, die da waren und dann davon erzählen können.

Ja, das war nicht mehr zu sagen oder so.

Vielleicht.

Genau, den habe ich schon gefragt.

Er hat sich auch schon gemeldet und wollte eigentlich ja auch.

Okay, cool.

Also gibt es noch irgendwann eine Pike-on-Folge.

Ja.

Ja, im Sommer, Europyton-Tickets sind auch gerade draußen.

Da gibt es sogar noch welche von, glaube ich, es war noch nicht so super angelaufen, der Vorverkauf, obwohl die so schnell immer weg waren, sonst.

In Dublin, also wenn ihr mit mir abends in Dublin ein Bierchen trinken wollt.

Da könnte es auch gut sein, dass ich damit komme.

Ja, das wäre nicht.

Würde ich gerne machen.

Ich bin gespannt.

Und dann gibt es noch die, also gut, dass jetzt nicht mehr so aggressiv ist.

Aber das Conference Center in Dublin ist relativ nah an der Bluedog-Außenstelle.

Das war.

Bluedog Burry.

Ja, ja, genau.

Das Angenehme mit dem nützlichen Superverbindung.

Genau, und im Herbst, irgendwann im September, gibt es die DjangoCon EU, diesmal auch tatsächlich vor Ort und in Porto.

Die sollte ja eigentlich die letzten beiden Jahre in Porto stattfinden, aber hat es ja nicht.

Und genau da denke ich ja wahrscheinlich leider nicht, weil irgendwie so viele Konferenzen.

Ist Johannes da?

Habe ich noch nicht gefragt.

Aber wer auf jeden Fall da ist, ist Ronny.

Ronny ist da stimmt.

Das ganze Team ist auch.

Das ist natürlich ein bisschen schade.

Das wäre natürlich nett.

Das ist ja schön, ja.

Ja.

Naja.

Ja, jetzt haben wir doch noch ein bisschen News gemacht.

Okay.

Gut.

Dann kommt jetzt wieder der obligatorische Werbeblock, habt ihr schon gehört?

Und diesmal ist Janis dann.

Janis darf Werbema.

Ich darf Werbung machen, ne?

Als Neuling.

Ja, wofür mache ich Werbung?

Ich mache Werbung für meinen Arbeitgeber.

Ich arbeite bei Elio, wir machen Consulting, mit Fokus auf künstliche Intelligenz und den Weg dahin.

Alles, was dazugehört.

Und ihr sucht neue Leute?

Wir suchen neue Leute, genau.

Wie hieß die Domain nochmal?

Ich versuche die gerade Elio?

alio.de.

a-I-L-I-O.de.

Quasi AI im Namen.

Als Programm, wenn man so möchte.

Genau, und wir suchen neue Leute immer.

Also es ist wahrscheinlich sogar ziemlich egal, wann du die Folge hörst.

Wir suchen dich.

Was müssen die Leute können, die zu euch kommen?

Wir haben einen Fokus auf künstliche Intelligenz, ne?

Also Data Science, Machine Learning, Deep Learning, NLP, das ist natürlich super interessant, wenn man sich damit schon mal auseinandergesetzt hat.

Aber auch ganz, ganz normale Backend-Tools, sag ich jetzt mal, sind sehr herzlich willkommen und sehr gerne gesehen.

Generell haben wir den Ansatz, dass man wunderbar in Rollen hineinwachsen kann und wir jeden dabei unterstützen wollen.

Das heißt, wenn Pandas dein Liebestool ist, ist das vielleicht auch interessant.

Welches Tool?

Pandas.

Pandas, ja klar.

Sicher, ist ja Data Science, ne?

Ja, Data

Science passt natürlich eigentlich schon ziemlich gut zusammen.

Und da kann man dann wahrscheinlich auch Remote arbeiten oder so.

Eigentlich ist es die Form in Bielefeld, sehe ich gerade.

Genau, wir sitzen in Bielefeld.

Remote-Arbeit.

Ich arbeite sehr viel Remote.

Wir haben immer so einen Stammtisch irgendwie, damit man sich doch auch mal in Person sieht.

Aber rein optional, sage ich jetzt mal.

Insofern sind wir gespannt.

Ja, ich finde gut.

Also falls ihr einen Job sucht, dann schaut doch mal da vorbei.

Ja, ich würde mich freuen.

Kriegen das fans nette Jungs und Kollegen.

Mindestens einmal, ne?

Mindestens.

Ja, vielleicht auch mehr.

Ich habe davon gehört.

Du musst jetzt noch persönliche Coachings und Benefits anbieten von dir aus, damit das dann.

Ja, würde ich natürlich machen.

Also wenn du Hörer der Folge bist und so begeistert von mir bist, ganz gut.

Genau, da gibt es einen Aktionskurs, Gejanne, groß geschrieben.

Ja, schreibe mich an.

Genau, eine E-Mail-Adresse und eine Internetseite gibt es auch, LUDE, business at lu.de, da könnt ihr euch gerne hinbewerben.

Ansonsten gibt es bestimmt auch irgendwo so einen Text, wo man sowas verlinken kann bei euch im Podcast.

Ja, und vielleicht genau, wenn man sich meldet, dann kann ich dazu sagen, dass das über Python-Podcasts, dass man sich da das gehört hat, weil dann kann man das vielleicht so ein bisschen irgendwie verfolgen.

Habt ihr auf jeden Fall bessere Chancen, da wissen wir auch, dass er das hatte.

Genau, dass ihr interessiert seid und so.

Keine Ahnung, ob das irgendjemand hört, den das auf der Suche ist.

Ich glaube tatsächlich, das hat einen Wert.

Also ich wurde mal gefragt in einem Interview, welche Bücher und Podcasts ich so empfehlen kann.

Das war ganz lustig.

Python Podcast ist mir vielleicht in den Sinn gekommen, vielleicht auch nicht.

Ich wurde tatsächlich auch im Arbeitskontest von jemandem angesprochen, also der ein Projektmanager war, der für ein größeres Projekt irgendwie gehört hatte, was da so gibt und der einen Danke-Podcast von uns gehört hat und dachte so, oh cool, das weißt du nicht, der Tür mit dem Podcast hat.

Ja, interessant.

Ja, hilft manchmal, ne?

Also das ist schon cool.

Genau.

Ja, super.

Hört mal rein.

Wenn ihr was sucht, bist du jetzt wo.

Oder nicht sucht und doch zu uns wollen, ne?

Man weiß ja nie.

Ja.

Okay, genau.

Ja, Thema diesmal Microservices.

Microservices.

Ja, also ich habe ja wie immer keine Ahnung und würde erstmal, was ist denn überhaupt so ein Microservice?

Ja, was ist das denn?

Wer soll das denn erklären?

Ja, keine Ahnung.

Möchtest du anfangen oder so?

Ich kann gerne anfangen.

Also es gibt relativ harte Definitionen darüber.

Ich bin da kein Freund von.

Also im Prinzip ist ein Microservice erstmal etwas, was wenig Sachen macht, aber dafür sehr gut.

So würde ich es beschreiben.

Man stellt jetzt ja ganz gerne mal so einen Monolithen gegenüber.

Und wir haben schon vorrangig überlegt, wollen wir jetzt so ein Versus-Ding machen oder nicht.

Schauen wir mal, was das wird.

Aber ja, ich weiß nicht, vielleicht, wenn man Selbstentwickler ist, man kennt das ja, man hat irgendwie tausend Funktionen, die man gerne in einer Anwendung hat.

Und dann überlegt man halt hoffe ich, wie man das gestaltet.

Und der Microservice-Ansatz ist eben, dass man viele einzelne Funktionen in verschiedenen Codebasen auslagert mit eigenen Text-Stacks und ganz wild und ganz toll und hoch skalierbar.

Und erstmal ist alles cool in Microservices.

Okay.

Die Meinung von ja alles.

Ja, ganz so ist es nicht, ne?

Das ist ein bisschen plakativ.

Werden wir noch sehen, ob das wirklich so ist am Ende.

Ja, aber das ist doch genau spannend jetzt.

Also du sagst also, Microservices sind quasi eine isolierte Funktionalität.

Genau.

Wenn ich jetzt eine Anwendung habe.

Wir tun jetzt mal so, als wäre es eine Webanwendung, vielleicht ist das am einfachsten zu verstehen.

Das heißt, es gibt ein Frontend und die bezieht dann ihre Quellen aus unterschiedlichen, ja, also ihre Bestandteile, ihre Logik aus unterschiedlichen Quellen.

Aus dem jeweils einzelnen Microservice.

Würdest du sagen, das ist eine gute Idee?

Es gibt verschiedene Ansätze, ne?

Das ist Thema Best Practice, sage ich jetzt mal.

Und auch immer so ein bisschen ein Thema der Architektur.

Also ich glaube, das werden wir im Laufe der Folge, wenn ich in die Zukunft gucke, immer mal häufiger hören.

Man kann sich natürlich verschiedene API-Endpunkte suchen und alle einzelnen Anfragen ist, würde ich sagen, aber keine gute Idee.

Da gibt es dann meistens AP-Gateways, beziehungsweise eine Schnittstelle, die man anfragt, die verschiedene Endpunkte sammeln.

Genau, darüber hatte ich eben auch schon mal, glaube ich, ganz kurz mit Jochen gesprochen, weil es halt genau darum geht, also wer ist dann die Spinne im Netz, wovon bekommt man das, wenn man jetzt ein Frontend hat?

Sollte das Frontend die einsammeln, einzeln oder holt man das von so einem Gateway ab?

Oder wie macht man das am liebsten?

Ja, keine Ahnung.

Also ich glaube, wenn man das wirklich konsequent machen wollen würde, dann müsste man ja auch im Frontend das sozusagen.

Mikrofrontends müsste man machen.

Was da nur ein bisschen.

Aber die fand ein Frontend, oder?

Wer liefert denn das Mikrofrontend aus?

Also wenn man zum Beispiel HTMX das ausliefert, dann wäre ein Dango ein sogenannter Spinne oder so ein Aggregator, ein Gabi-Gateway, obwohl ich jetzt das Wording da immer nicht ganz treffen finde, ehrlich gesagt.

Das spielt dann letztlich ja keine große Rolle mehr, weil du musst ja dann, das wäre nur noch eine statische Seite.

Was ich mir jetzt halt da kompliziert drin vorstelle, ist, wenn ich so ganz viele verschiedene Zeug habe, aber ich habe ja eigentlich nur eine Anwendung.

Warum mache ich das nicht in der einen Anwendung direkt und habe dann diesen ganzen Gefummel mit dem Ganzen drumherum nicht?

Darüber wollen wir ja reden, ne?

Ja, also das ist ja das Ziel der Folge.

Wäre eine kurze Folge, wenn wir das jetzt so einfach und so schnell machen.

Diese Einsatz fertig, ja, danke schön.

Heute haben wir euch nicht so lange geklickt.

Nee, ganz, ganz so ist es natürlich nicht.

Man muss halt auch mal sehen, welche verschiedenen Funktionalitäten man haben möchte.

Wir sind jetzt im Bereich Web unterwegs, von deinem Beispiel.

Das klingt erstmal sehr, sehr einfach.

Web-Anwendung, ich meine, so eine Standard-Firmen-Webseite meinetwegen mit einem Kontaktformular, da braucht man keine Microservices für, das stimmt schon.

Aber wenn wir jetzt zum Beispiel mal eine Kurswebseite meinetwegen sehen, wo wir ein Empfehlungssystem, wir haben so ein Dashboard, wir haben einen Nutzerbereich, wir haben einen Content Creator-Modus, da werden die Sachen schon komplizierter.

Wir haben ganz viele verschiedene Sachen, die ineinander greifen, die ineinander funktionieren müssen.

Und da muss man natürlich überlegen, wie gestalte ich das designtechnisch, wie gestalte ich die Suchfunktion und so weiter und so fort.

Und kann ich das überhaupt in einem einzelnen Django-Monolithen gewährleisten, meinetwegen, oder ist es vielleicht manchmal einfacher, einen eigenen Service für etwas zu schreiben?

Ja.

Also genau, vielleicht einfach hake ich an der Stelle mal ein und sag mal so, was ich denken würde, was Microservice ist.

Und ich würde denken, der entscheidende Punkt dabei ist eben die Einheit, wie deployed man das.

Also alles, was man, wenn man, wenn man es insgesamt, wenn man es halt getrennt deployt, dann ist es halt ein Microservice, würde ich jetzt mal so sagen.

Und oder getrennt deployen kann.

Und also wenn es halt irgendwie, wenn die gesamte Applikation etwas ist, was man insgesamt deployt, dann ist es halt irgendwie eher ein Monolith.

Und eben Microservice hat halt den Vorteil, du kannst halt da unterschiedliche Technologien ausprobieren, du kannst halt unterschiedliche Sprachen verwenden.

Man sagt mal auch mal, man sollte das halt so machen, dass man da quasi unterschiedliche Sprachen verwenden kann, dass sie halt möglichst irgendwie ihre eigene Datenhaltung irgendwie haben oder zumindest ihre eigene Sicht auf die Daten.

Und da ist man dann halt schon so ein bisschen bei dem, ich weiß nicht, diesen Domain-Driven Design-Ansatz, da gibt es immer diese Begriff Bounded Context, ne?

Und das ist halt immer so das, was man so klassischerweise Bounded Context.

Bounded Context.

Jetzt musst du wieder irgendwie anwenden, was dann Context ist.

Ja, das ist quasi so, ja, also Dinge, die halt irgendwie so zusammengehören und nur gemeinsam verändert werden sollen.

Ich glaube, das Standardbeispiel auch eben aus dem Domain-Diven-Design Buch ist halt sowas wie eine Bestellung und die Punkte, die einzelnen Positionen auf einer Bestellung oder so, will man vielleicht, das Ding will man immer zusammen verändern.

Das heißt, man holt das insgesamt aus der Datenbank, macht irgendwelche Änderungen und schreibt es halt in einer Transaktion wieder irgendwie in die Datenbank rein oder so.

Und das ist halt sozusagen ein, ja, brauchende Kontext eben.

Ja, dann ist aber eine spannende Frage.

Also was gehört halt dazu oder nicht?

Also bei einer Bestellung und deren Position geht es vielleicht noch, aber wenn du jetzt an den zuständigen Sachbearbeiter beispielsweise denkst, der irgendwie im Innen- oder Außendienst hängt, ist die Frage, gehört das dann zum Bauendkontext da dazu oder holt man das aus dem CRM?

Ich glaube auch, dass der Grund, also vielleicht der Name, das kommt daher, dass es halt unterschiedliche Dinge in unterschiedlichen Kontexten bedeuten kann.

Also zum Beispiel User ist halt was anderes, wenn du dich auf einer Webseite einloggen möchtest oder kann halt was anderes sein, als User oder Person, an die irgendwas geschickt wird im Kontext einer irgendwas Bestellung oder so.

Und im einen Fall hat man halt da komplizierte Adressgeschichten und weißer Teufel irgendwie Zeugs und im anderen Fall braucht man das gar nicht, weil da muss man nur überprüfen, stimmt der Passwort-Hash oder so.

Und ja, je nachdem, welchem Kontext man unterwegs ist, ist das halt unterschiedlich und man erlaubt dann halt auch unterschiedlichen Kontexten die Daten unterschiedlich zu halten und unterschiedliche Sachen zu speichern und so.

Okay, interessant.

Also Bounded Kontext abstrahiert das so ein bisschen.

Was aber jetzt dafür sprechen wir, in dem Masch, was du gesagt hast, braucht man ja irgendwie eine Wahrheit der Daten, wenn das eben.

Ja, das ist dann, glaube ich, da wird es ein bisschen schwieriger bei dem Microservice.

Single Point of Truth, ja.

Das ist eine Herausforderung.

Also ich sage jetzt mal, das ist eine ganz gängige Frage.

Wie gewährleistet man den in Microservices?

Und eine Frage, die damit einhergeht, ist immer das Datenmanagement.

Vielleicht vielleicht nochmal gerade Entschuldigung, dass ich euch gerade direkt einhaber wieder.

Aber was heißt Datenmanagement an der Stelle?

Ein Microservice, beziehungsweise Microservices allgemein zeichnen sich ja dadurch aus, dass das isolierte Systeme sind.

Also im Idealfall hält jeder Microservice genau die Daten, die er braucht oder eben nicht.

Und wenn er die Daten nicht hält, muss er natürlich überlegen, woher kriege ich meine Daten eigentlich und wie kriege ich sie.

Und dann gibt es eben verschiedene Möglichkeiten, damit umzugehen.

Ich könnte zum Beispiel mal irgendwelche AP-Requests gegen irgendeinen anderen Microservice machen, meinetwegen, und hole von da meine Daten.

Hab dann aber den Nachteil, okay, das ist langsam und irgendwie kopple ich meine Microservices dann wieder zusammen.

Genau, ja, also wenn es im dieselbe Datenbank liegt, dann ist doch die Frage, warum macht man da eine unterschiedliche Architektur?

Aber obwohl, vielleicht kann er auch das dann machen, wenn er halt irgendwie hingehe und möchte aus derselben Datenbank Dinge erzeugen mit unterschiedlichen Sprachen und die dann unabhängig.

Genau, eine selbe Datenbank wird schwierig, weil dann kannst du es halt nicht mehr getrennt voneinander deployen.

Also wenn du jetzt zum Beispiel auf der, wenn du eine gemeinsame Datenbank hast und du änderst die jetzt.

Na gut, er kann ja einfach den Datenbank deployen.

Also die Datenbank kann ja noch ein dritter Punkt sein, der ganz unabhängig von den Services läuft.

Ja, aber da kannst du es nicht mehr unabhängig deployen, weil wenn du jetzt die Datenbank änderst, dann hat das ja Auswirkungen auf einen anderen, hat es ja auch Auswirkungen auf die anderen Services.

Ja, und es ist ein Single Point of Failure.

Also da spreche ich aus ganz, ganz schmerzhafter Erfahrung.

Wenn verschiedene Services an einer Datenbank hängen, verschiedene Microservices und die Datenbank kippt um, dann kippen dir die Microservices auch um, weil irgendjemand Schluss gemacht hat.

Das will man eigentlich auch vermeiden.

Also das ist so ein Shared-Datenbank, Anti-Pattern heißt das.

Das macht man manchmal, weil es einfach schnell ist, weil es einfach einfach ist.

Aber wenn man wirklich Microservice macht und sie wirklich braucht, dann ist das eigentlich mal eine relativ schlechte Idee, wenn man sich da doch, wie gesagt, in Single Point of Failure reinholt.

Aber ja, eigentlich hat jeder Service seine eigene Daten, seine eigene Datenbank.

Und du musst halt überlegen, okay, will ich jetzt mehrfach die gleichen Daten in verschiedenen Microservices verteilen?

Oder will ich dafür sorgen, dass sich die einzelnen Microservices die Daten von anderen Microservices holen und erzeuge damit eine Kopplung und mache die Sache vielleicht ein bisschen unübersichtlicher, vielleicht ein bisschen langsamer.

Und das beschreibt eben das Datenbankmanagement.

Das heißt, wir haben viele Datenreplikationen an unterschiedlichen Stellen und das macht natürlich den Punkt der Wahrheit, wie ich es so schön sagte, extrem schwierig.

Ja, da musst du vielleicht über diesen Flora am Anfang halt Gedanken machen.

Also wo kommen die Daten überhaupt her?

Und wo sollen die hin?

Und dann, ja, also ist ja die Frage, ist das eine Architekturentscheidung, wenn du jetzt sagst, es ist Design, Domain-Driven Design, was würde denn da.

Damit sind noch keine Architekturentscheidungen gefallen, quasi.

Damit ist es halt einfach nur so ein Konzept, wie man Dinge angehen könnte, aber

ich stelle das ja so ein bisschen in den Raum dann vielleicht.

Also die Wahl.

Ja, also ich weiß es nicht.

Ich meine, es ist halt die Frage, ob man tja, also ich hab's, ich habe in der Vorbereitung habe ich jetzt mal so ein Podcast auch gehört, von wo der, da gibt es irgendwie ein Buch, das mal empfohlen wird zu Microservices von Sam Newman und der ist auch in diversen Podcasts schon zu Last gewesen und der sagte dann dazu quasi so, naja, also das mit den Datenbanken ist ja so eine Sache, also wenn man, wenn das

funktioniert, wenn man halt eine Datenbank haben kann und so, und dann sollte man das schon machen, weil es gibt ja einen Grund, warum die so verbreitet sind und sich so lange gehalten haben und alle die benutzen.

Und wenn man das halt, äh, wenn man das halt nicht kann, gut, weil man halt Microsoft machen muss, dann okay, da muss man sich halt was überlegen, dann wird es halt schwierig.

Und dann derjenige, der ihn interviewt hat, fragte dann halt auch so, ja, kann man denn dann irgendwie was tun, um Datenbanken schon drauf auszulegen, dass man die dann vielleicht trennen kann oder kann man das irgendwie Architekturen so, ja, das kann man, warum sollte man das tun?

Man muss der Datenbank schreckliche Dinge antun, damit das geht.

Also es muss einem halt klar sein.

Also, ja, also es geht schon, aber es ist halt, die Frage wäre, würde man so anfangen wollen?

Und da denke ich, ja, warum nicht einfach mit einem ganz normalen Datenbankschirm anfangen?

Genau, ja, aber das würde ja nicht für Microsoft sprechen, sondern für einen Monolith oder einen Service, der.

Es würde nicht dafür sprechen, damit anzufangen, ja, genau.

Würde ich auch sagen, normalerweise, sollte man einen Grund haben, worum man das macht.

Also das heißt, also ich würde jetzt auch so intuitiv sagen, du baust halt erst einmal dein Deployment für ein Tool, für eine Webanwendung und hast halt dann eine Datenbank dahinter und arbeitest dann damit und erweiterst sie halt.

Und die Frage ist halt, wann komme ich denn überhaupt in diese Sphäre, dass ich sage, so Microsoft ist jetzt eine gute Idee oder das behilft mir irgendwo bei.

Das ist unterschiedlich.

Vielleicht erstmal eingehakt noch bei diesem Datenbank auseinanderschneiden, das stelle ich mir sehr, sehr kompliziert vor.

Das, was wesentlich einfacher ist, sich vorzustellen, ist, dass jeder Service tatsächlich seine eigene echte Datenbank hat.

Und man verteilt die Daten dann quasi auf verschiedene Microservices in ganz normalen Datenbanken.

Also das, was du gesagt hast, das kam relativ kompliziert.

Aber du hast ja dann das Problem.

Du hast dann ja ein verteiltes, du hast ja eine verteilte Datenhaltung, wo du nicht einfach einen Join machen kannst, sondern du musst dann halt.

Ja, ja, klar.

Also das Datenmanagement selbst, das ist wesentlich komplizierter geworden, aber die Datenhaltung pro Service, die ist immer noch relativ.

Das muss man halt ganz klar sagen.

Also die einzelnen Microservices in sich, die sind unglaublich einfach.

Wenn du zum Beispiel einen Monolithen hast, und da kommen wir direkt zu deiner Frage, die du gestellt hast, Monolith wird sehr schnell sehr kompliziert.

Also gerade dann, wenn du viele Leute an einer Codebasis arbeiten hast, mit vielen verschiedenen Services da drin, die sich vielleicht auch gegenseitig affektieren.

Also du bindest ja unter Umständen einzelner Services aneinander und du hast dann auf einmal teamübergreifende Bugs, meinetwegen, weil du eine gemeinsame Codebasis hast, dann denkt man schon relativ schnell bei Microservices nach.

Okay, aber das klingt ja so, als wären die Apps-Sets nicht so gut getestet im Staging oder sowas.

Und als würden jetzt, also Dinge, die halt eine Seite kaputt machen, andere Apps kaputt machen.

Und wenn man jetzt beispielsweise in Django-App-Sets denkt, ja, wenn man das parallel entwickelt, dann könnte man die ja voneinander trennen.

Im besten Fall tut man das, ja.

Also wenn

die sich gegenseitig differenzieren, kommt man natürlich in so ein Dependency-Problem vielleicht.

Ja, ja, ich glaube, also ich, ich meine, das ist auch mal was, wo ich dann, also es geht eigentlich im Grunde, das zentrale Problem irgendwie bei der Softwareentwicklung ist eben dieses Modularisierungsproblem.

Das ist halt irgendwie so das Ding, was jeder hat und was irgendwie ganz einfach aussieht, wo alle sagen, ah, da muss man halt ein bisschen modularisieren, kein Problem.

Das ist aber tatsächlich sehr schwierig.

User musst du sehr oft importieren.

Das heißt, dass zum Beispiel, wenn da irgendwas kaputt geht, das ist schon doof dann wahrscheinlich.

Ja, aber du kannst ja trotzdem sozusagen die Dinge irgendwie auseinanderhalten, die nichts miteinander zu tun haben.

Wenn es nicht geht, dann geht es halt nicht.

Aber dann kannst du immer noch die Abhängigkeiten explizit machen.

Also es ist, man kann da schon was tun und man kann das richtig und falsch machen und meistens machen sie total falsch.

Das ist halt so.

Und die allerschlimmsten Geschichten sind dann halt, oder wenn man es halt halt verteilt falsch macht, das ist halt.

Ja, insofern, ich bin auch so ein bisschen immer vorsichtig, weil häufig, was ich halt schon häufiger gesehen habe, ist, dass Leute dann sagen, also sie haben halt dieses Problem, das Standardproblem irgendwie, dass alle haben in der Softwareentwicklung irgendwie, sie kriegen ihren Kram halt nicht organisiert.

So richtig und richtig strukturiert und nicht modularisiert.

Und dann nehmen sie halt irgendwie Teile, die kompliziert sind und machen daraus mehr Mikroservices, weil sie sagen, ja, dann haben wir das irgendwie modularisiert.

Aber das ist ja nicht so, sondern dann hat man es einfach nur verteilt.

Das heißt, man hat ein Ding, was man nicht modularisiert hatte, verteilt und dann hat man halt einen verteilten Monolithen und das ist halt leider sehr offen.

Ich weiß nicht, ob die ganzen Dinge nicht.

Ja, insofern, genau.

Aber ich glaube, dem kann man so ein bisschen entgehen, wenn man sich überlegt am Anfang, so wofür will ich das eigentlich bauen und warum mache ich das?

Und dann geht das wahrscheinlich schon besser.

Die Frage ist auch immer, ob man es besser oder schlimmer macht oder ob man überhaupt was am Zustand ändert.

Ich meine, wenn man innerhalb seiner Architektur bzw.

innerhalb seines Codes Referenzen hat, dann hat man die ja nicht automatisch nicht mehr, nur wenn man auf einmal Microservices verwendet.

Genau.

Man verlagert das Problem.

Aber ich sage jetzt mal, man macht die Sache halt, die Codebasis selbst wesentlich einfacher und manchmal läuft man auch einfach in eine Situation, wo man feststellt, okay, die Funktion, die ich jetzt hier machen möchte, die ist in dem Umfeld, in dem ich mich gerade bewege, einfach super schwierig zu implementieren.

Das heißt, ich finde gar keinen geeigneten technischen Ansatz, da mal ein wenig was einzubauen.

Vielleicht ein ganz, ganz einfaches Beispiel.

Wir haben jetzt eine Django-Anwendung und wir haben jetzt irgendwo, weiß ich nicht, Rabbit-MQ, Kafka, irgendwas rumliegen, irgendeine Que, irgendein Topic und das will ich konsumieren.

Und dann muss ich mal überlegen, gut, wie baue ich das möglichst elegant in eine Django-Anwendung ein?

Dann habe ich da irgendwie permanent etwas parallel Laufendes.

Kann man machen.

Die Frage ist, ob es sich natürlich anfühlt, ob es cool ist, ob man es wirklich so machen will.

Also du willst eine Verlichtanbindung aufmachen zu einem Kafka oder einer anderen Queue.

Ich würde es gar nicht mal so ausdrücken.

Ich würde einfach mal den Sachverhalt an sich in den Raum stellen, dass ich einen Umstand habe, der sich einfach nicht natürlich fühlt, in die aktuelle Anwendung einzubinden und die man dann reinhackt unter Umständen.

Oder wo man meinetwegen sagt, okay, ich finde jetzt in meiner jetzigen Architektur einfach allgemein keinen schönen Ansatz für das, was ich vorhab.

Weiß ich nicht.

Es kann auch andere Gründe haben.

Du hast einen riesen Monolithen, Django, und du hast meinetwegen einen Java-Entwickler, der eine andere Funktion in Java super cool machen kann, findet sich aber nicht im Django zurecht und überlegst, okay, macht es Sinn, für den jetzt einen eigenen Service aufzumachen oder nicht.

Also vielleicht geht das mehr so in die Richtung politische Entscheidung oder auch nicht.

Aber manchmal ist auch so das Skillset der Mitarbeiter, die du gerade hast, verleiten dich einfach dazu zu sagen, okay, ich kann nicht alles in dieser einen Codebase lösen, ich kann nicht alles mit diesem einen Deployment lösen.

Vielleicht lagern wir das aus und vielleicht ziehen wir dadurch wirklich unsere Vorteile.

Ja, also was ich halt da wieder ein Problem sehen, ist halt, wenn ich das jetzt tue, dann habe ich ja irgendwo den Hut nicht auf.

Oder ich muss den Hut an einer Stelle aufsetzen und muss das halt dann wieder agrigieren, wo du es vom API-Gateway sprachst, ja.

Also wenn ich diese Spinne im Netz sein will, die halt die Informationshoheit hat, die die Single Source of Truths irgendwie bereitstellen möchte.

Das ist ja kein API Gateway.

Nein, gut, aber du hast halt andere Services, andere Teile der Applikation arbeiten irgendwo auf einer ganz anderen Maschine mit einem ganz anderen Deployment und die liefern mir irgendwas.

Ja.

Also ich kann die auch schwer testen oder sowas, ja.

Also wenn ich das auf meiner Seite hast, muss halt eigentlich auf deren Seite dann getestet sein.

Das heißt, ich gebe quasi die ganze Verantwortung weg.

Du hast natürlich sehr viel, du hast wahrscheinlich wesentlich mehr Integration-Tests erstmal, als du in einem Monolithen hättest.

Auf der anderen Seite sagt man ja, die einzelnen Services, die sind entkoppelt voneinander.

Das heißt, wenn deiner läuft, hast du deinen Job gemacht und das ist erstmal alles gut.

Und der andere muss dafür sorgen, dass sein Microservice läuft.

Das heißt, man verlässt sich irgendwie aufeinander.

Und ich habe so ein bisschen das Gefühl, dass das Problem, worauf du dich so ein bisschen einschießt, ist das größte Problem in Microservices allgemein.

Das ist immer so eine Sache, die kann man unglaublich gut machen oder unglaublich schlecht machen.

Oder man macht sie einfach, wie man es macht.

Also man bewegt sich irgendwo in der Mitte.

Und mal funktioniert es richtig gut und mal nicht.

Also das ist eine Riesenherausforderung, worüber du sprichst, beim Single Point of Truth.

Beziehungsweise auch das ganze Monitoring.

Das ist ja wesentlich kompliziert in der Microservice-Welt.

Weiß ich nicht, wenn du zwanzig hast.

Ja, also ich sag mal so, wenn das meine eigene Organisation ist, die die Microservices macht, dann muss ich ja irgendwo dann trotzdem irgendeine Form von Infrastruktur einziehen, jeweils, die dann irgendwie aggregiert bei mir halt, wie du sagst, Monitoring macht und da halt irgendwie die Logites rauspasst oder irgendwie.

Du musst überhaupt mit sowas erstmal anfangen und wir haben das möglicherweise eben noch nicht.

Das ist auch so das erste Projekt, was er vorschlägt und man sich dann tatsächlich doch mal dazu durchkungen hat, das dann zu machen.

Also immer so, dass ein gutes Startprojekt ist halt zu sagen, okay, da machen wir doch mal irgendwie als ersten Microservice irgendwie zentrales Log, äh, so Else-Stack oder sowas, Logmanagement, weil das ist halt relativ einfach, ja, das ist eigentlich nicht so schwierig, aber man muss halt trotzdem irgendwie Sachen irgendwo hindeployen können, man hat unterschiedliche Sprachen, man muss es irgendwie konfigurieren und diese ganzen unterschiedlichen Aspekte irgendwie müssen alle z

usammen funktionieren, sonst geht es halt nicht.

Und wenn man da schon feststellt, okay, das ist mit der Organisation, weil das oft hat man ja so Organisationsprobleme, schwierig zu machen, dann weiß man halt, okay, alles andere danach wird noch viel schwieriger, daher sollte man vielleicht nochmal überlegen, wie man das organisatorisch löst.

Aber ja, genau, genau.

Das ist eigentlich, du brauchst dann halt irgendwas, wo du dann halt zentral deine Logfiles sehen kannst und gucken kannst, was passiert ist, über deine unterschiedlichen Services hinweg.

Und das musstest du für die Frage.

Also ich muss, also das meinte ich mit dem Hutterfaden, ich muss halt immer irgendwie so ein Admin haben oder so.

Naja, also ich meine, du hast dann ein Ding für Loggeschichten, du hast aber dann vielleicht auch ein anderes Ding für Monitoring, du hast wieder ein anderes Ding für, weiß ich nicht, dann Live-Dashboard oder so.

Das müsste ja jetzt nicht alles das gleiche sein.

Das ist auch wieder unterschiedlich.

Also das Problem, was ich jetzt habe, ist dann wahrscheinlich niemand den Hut über alle diese Dinge auf hat und es dann schwerfällt, die halt entspannt der Bark sitzt halt.

Ja, also ich meine, am Ende, ich meine, das, worauf der Jochen hingewiesen hat, wir haben ja unsere Tools.

Also der Elk-Stack für Logging meinetwegen, Sentry für Fehlermeldungen, dann hast du vielleicht noch Grafana Prometheus für Metrikmonitoring.

Das sind ja alles standardisierte Ansätze, die du relativ einfach in deiner Services einbauen kannst.

Also Filebeat-Logging geht zum Elk-Stack.

Und das ist halt etwas, wo man sich auch in einem Monolithen durchaus Gedanken drüber machen muss, um da einen einfach einen Zugang zu seinen Loks zu kriegen, zum Beispiel.

Gerade dann, wenn du in einem Team bist, dann finde ich schon, dass man sich relativ früh die Gedanken über genau diese Fragestellungen machen sollte, damit einfach jedes Teammitglied ohne Serverzugriff oder irgendwas anderes komisches eben an seine Loks kommst und diese möglichst schön filtern kann.

Elk-Stack ist auch wunderbar.

Das heißt, diesen Stack, den hast du unter Umständen auch in einer guten monolithischen Struktur schon.

Vielleicht könnt ihr einfach noch kurz den Egg-Stack beschreiben, weil den hatten wir, glaube ich, noch nicht.

Das ist einfach nur, ich weiß jetzt gar nicht, ob ich das richtig, ich habe mit Hilfe gar nicht so viel.

Das ist irgendwie Elasticsearch halt, um die Logfiles durchsucher zu machen.

Es ist halt Kibana oder so.

Genau, das ist Dashboard.

Dashboard, genau.

Und was gehört da noch dazu?

Logstash.

Logstash, ah ja.

Also vielleicht auch, um das zu beschreiben, du kannst in Python zum Beispiel, schreibst du deine Logfiles und Files, ne?

Und dann kannst du dir die mit FileBeat Richtung Logstash schicken.

Das ist einfach nur ein weiterer Service, ne?

Der sorgt dann letztlich einfach nur dafür, dass die Logs, die du schreibst, Richtung Elasticsearch gehen.

Und entweder du hast da noch einen Logstash vor oder nicht, dann kannst du die vielleicht noch ein bisschen schöner formatieren, um sie ein bisschen schöner JSON-tauglicher zu machen und durchsuchbarer zu machen, einzelne Fan zu indizieren.

Und dann wird das eben auf Elasticsearch gespeichert und mit Kibana durchsuchst du es einfach.

Dann kriegst du so ein Dashboard, dann kannst du relativ nutzerfreundlich mit schön viel klickibunti deine Loks durchsuchen und dann hast du deine Graphen, kannst dir auch Dashboards bauen.

Ja, okay, ja, Kibana ist immer.

Freitext-Suche.

Das ist sehr schön.

Macht Spaß.

Okay.

Ja, also.

Ja, ich sehe es auch tatsächlich, also wenn du sagst, in der Organisation irgendwie muss doch jemand die, ich denke, das ist halt eines der Ziele bei dieser ganzen Geschichte, gerade wenn man es bei größeren Organisationen das sich anschaut, die haben oft das Problem, also wenn man sich jetzt anguckt, was machen denn Firmen vorher oder was machen die denn normalerweise anders, wenn sie das halt, wenn sie nicht Microservice machen, dann machen sie meistens so eine, also ich würde sagen, bei Microservice ist halt so, versucht das ganze Problem, die Problemendomain irgendwie vertikal aufzutrennen.

Und was man klassischerweise vielleicht eher macht, sind Sachen horizontal aufzuteilen.

Das heißt, du teilst normalerweise, sag ich mal, eben dann vielleicht eher auf in Frontend irgendwie so Service Layer und Backend und Datenhaltung.

Und sozusagen bei Microservice ist halt eher vertikal, das heißt pro Projekt irgendwie oder pro irgendwann irgendeine Organisationsstruktur halt.

Und das Problem bei dem horizontalen Ding, weshalb man da vielleicht weg möchte von, ist halt, dass du halt, wenn du jetzt viele Leute hast, die daran arbeiten an deinem Produkt, dann stehen sich halt gegenseitig auf den Füßen unter Umständen.

Also du hast dann vielleicht halt eben schon ein Datenbank-Team oder so, wo sich Leute sehr, sehr gut mit Datenbanken auskennen.

Aber und du brauchst sie halt auch deswegen, weil du halt eventuell fiese Datenbankprobleme hast, wo Leute irgendwie Queries optimieren müssen oder sich überlegen müssen, wie sie da halt irgendwie möglichst schnell neue Replikas von irgendwelchen Datenbanken hochziehen können und die Daten da und so weiter.

Dieses ganzen Kramenloadsing und dieses ganze Zeugs, was man halt so machen muss.

Und das sind dann halt so die Sachen, für die du tatsächlich Spezialisten brauchst, aber du hast halt oft auch das Problem, du willst jetzt, hast jetzt irgendwie ein Projekt und da muss halt irgendwie jetzt eine Spalte zusätzlich irgendwo eine Tabelle.

Und das ist jetzt eigentlich nichts, was so sonderlich schwierig ist, vielleicht sollte man sich überlegen, ob man das halt machen will oder nicht, oder keine Ahnung, aber letztlich das zu tun ist gar nicht so schwer.

Und dein Datenbank-Team ist zwar jetzt zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt oder so.

So, und dann kommst du nicht weiter mit deinem eigentlich Projekt, das nur da eine blöde Spalte zusätzlich haben muss.

Es gibt halt eine Menge Anforderungen, die sehr einfach sind.

Also entweder du beschäftigst dann halt deine teuren Spezialexperten mit sehr simplen Geschichten, oder du kannst sie nicht auslasten, weil die halt oder du kannst halt kommst mit deinem Projekt nicht weiter, weil die halt mit irgendwelchem anderen Kram ausgelastet sind.

Also es ist halt, und das blockiert sich halt gegenseitig.

Du hast halt sehr viel Handoffs zwischendurch viel Kommunikation, weil viele Leute miteinander reden müssen, damit irgendwas am Schluss deployed werden kann.

Und wenn du es jetzt anders machst und machst es halt vertikal und sagst, ein Team ist ein Grund dafür zuständig, das komplett zu deployen, ein Produkt, Projekt, Microservice, dann und die anderen sind halt bloß, die beraten dich dann halt, wenn es irgendwie kompliziert wird oder so und enablen dich halt irgendwie da eine Lösung zu finden, dann kannst du halt sehr viel schneller halt Sachen tatsächlich raus aus der Tür kriegen.

Und du machst bestimmte Teile deiner Organisation halt auch handlungsfähig, ohne dass sie halt sich mit allen anderen abstimmen müssen.

Und dann, also das sind vor allen Dingen zwei Teile, die da halt ein Problem sind.

Das ist halt einmal die Infrastruktur ganz unten, das sind halt Datenbank und so und IT-Geschichten und dann oben halt aber UI und UX ist auch immer problematisch.

Deswegen eben gerade schon so mit Mikrofon jetzt so ein bisschen, weil das Problem ist, wie stellst du Konsistenz gegen quasi sicher, wenn halt du nicht mehr ein UI-Team hast, das halt alles auf allem irgendwie zu einem Ja sagen muss, dass das jetzt so funktioniert.

Die könnten dann sagen, ja, nee, das muss konsistent sein, das können wir so nicht machen.

Aber wenn jetzt die Teams das einzeln machen sollen, dann kann es natürlich inkonsistent werden.

Ja, dann müssen ja irgendwie komische Style Guides folgen oder so.

Ja, aber ob sie das dann tun oder nicht, weil das Team muss dann ja verantwortlich sein.

Die müssen es ja, die müssen ja sagen können, nee, wir releasen, das ist uns wichtiger und dann, oder wir deployen jetzt und dann machen sie das halt einfach.

Ja, aber du bist halt unter Umständen schneller.

Und ich finde, ich finde, eine Firma, in einer Firma gibt es das auch sehr schön, sowohl der, was das an Vorteilen bringen kann, sieht man da, und auch was an Nachteilen, nämlich bei Amazon.

Die haben ja eigentlich früher schon angefangen mit so Service-Oriented Architecture, was vielleicht auch so ein bisschen Vorläufer ist von Microservices.

Und auf der Amazon-Shopping-Seite, da funktioniert das, finde ich, ganz gut.

Also ich meine, die sieht auch immer so ein bisschen inkonsistent aus und komisch und Altbacken und so.

Aber das geht irgendwie.

Also man kann einkaufen und meistens funktioniert es sogar besser als anderswo vom Prozess her.

Aber, und also das geht.

Das ist zwar nicht so komplett konsistent, aber das funktioniert insgesamt.

Und wo ich finde, wo es eine ziemliche Katastrophe ist, ist halt bei sowas wie AWS oder so.

Wo man auch sieht, dass jedes einzelne Team, also einmal es gibt Hunderte und dann jedes Team macht das halt irgendwie anders, so wie sie es halt denken.

Und das macht es für mich als Benutzer halt total schwierig, irgendwie, das irgendwie zu bedienen, weil ich nie Sachen finde und immer da suchen muss nach Sachen und so.

Nee, also auch die Konfiguration, wenn man das irgendwie automatisiert, ist jedes Mal total anders und das ist ein bisschen nervig auch.

Ja, also ich meine, es geht schon, aber es ist halt schon, das macht es echt, da an der Stelle macht die fehlende Konsistenz an das Leben halt echt schwer.

Und ja, aber ich glaube, das sind halt so Trade-offs, ne, muss man sich entscheiden.

Ist einem die Konsistenz wichtiger oder die Geschwindigkeit?

Ja.

Ja.

Naja, naja.

Welche Begeisterung für Microservices, habe ich das Gefühl, ne?

Ja, ich weiß nicht.

Also ich habe noch nicht so rausgefunden, wofür ich denn jetzt einen Microservice gut einsetzen könnte.

Also wenn ich mir jetzt vorstelle, ich möchte jetzt irgendwie so ein Projekt implementieren, ja?

Irgendwie so eine gewisse Größe.

Und dann muss ich ja, wie du ihr auch in so schön sagt, enablen die Leute, dass sie selber klarkommen mit den ganzen Regeln, die ich irgendwie haben will.

Ich glaube, das ist noch viel zu kompliziert.

Ich glaube, erstmal muss man überlegen, brauche ich das überhaupt?

Also macht das für mich überhaupt Sinn?

Habe ich die Größe, wie viele Mitarbeiter habe ich?

Bin ich jetzt zu fünf, dann mache ich keinen Microservice auf.

Aber habe ich meinetwegen 20, 30, 40 Mitarbeiter.

Das macht schon super viel Sinn, da über Microservices nachzudenken, weil ich kann jetzt eigentlich so Teams machen.

Diese Teams haben verschiedene Verantwortlichkeiten.

Und natürlich habe ich hinterher den Trade-off mit Konsistenz meinetwegen im Frontend.

Frontend ist halt immer so ein, ich bin nicht im Frontend drin, ich persönlich.

Also ich halte mich davon so weit fern wie nur möglich, ja.

Und so Backend-Prozesse, da sind so Guidelines total egal, ja.

Nein, aber ich versuche jetzt wirklich nochmal von diesem Management-Layer von oben, das mir anzugucken, weil du hast natürlich recht, ich bin nicht jetzt ein Content habe mit 100.000 Mitarbeitern, macht das vielleicht Sinn, die Teams zu verteilen auf ihre einzelnen Kompetenzen, die sie haben, die in unterschiedlichen Ländern Slogan sitzen.

Das heißt, die haben ganz andere Abstimmungsprobleme.

Mein Problem ist es aber, als Konzern von oben das so zu managen, diese unterschiedlichen Services, dass sie konsistent sind.

Ja, dann habe ich wieder das Problem des Brandings oder wie auch immer.

Oder halt, ich möchte eine Nutzbarmachung der einzelnen Services für alle sicherstellen.

Und wenn die Standards jetzt so sind, dass die jetzt irgendwo im Pazifikraum funktionieren, aber für uns nicht lesbar, dann habe ich ein Problem, weil dann kann ich keine Synergieeffekte daraus ziehen.

Ja, die Frage ist dann auch immer, welche Prozesse werden durchlaufen, um etwas zu veröffentlichen.

Das steht halt noch ein bisschen.

Genau, aber ist die Frage, erschlage ich das dann mit irgendwelchen Prozessen?

Weiß ich nicht, das macht's ja nicht besser.

Dann habe ich den Vorteil von Microservices nicht mehr, weil dann muss ich durch so ein Prozessgateway durchkommen und hab dann einen Doorkeeper nach dem anderen.

Ja, gut, aber auch um auf deine Frage zu kommen, die Frage ist am Ende auch, wie schlimm ist das?

Also wenn ich jetzt zum Beispiel in Tokio das eine Team habe und in Berlin das andere, die bauen beide, die backen beide ihren eigenen Kuchen, dann ist ja gerade der Sinn von Microservices auch, dass jedes Team eigentlich nach Lust und Laune so arbeiten kann, wie es will, solange es zum richtigen Produkt führt.

Weil das Team in Berlin wird relativ wenig Berührungspunkte mit dem Code zum Beispiel vom Team in Tokio haben.

Und umgekehrt natürlich auch, weil Microservice-Teams, die stehen ja für sich alleine.

Das heißt, wir haben ein Team, das arbeitet an einer Sache, das deployt einen Service für sich alleine und der muss natürlich integrativ mit den anderen irgendwie funktionieren.

Ja, ich würde auch denken, dass das Problem eher tatsächlich andersrum ist.

Also das, was dann tatsächlich auftritt.

Also ich meine, ja, es kann auch sein, dass es schwierig ist, das zu koordinieren, keine Ahnung.

Kann man sich halt dann sich halt vielleicht irgendwas überlegen.

Aber das habe ich jetzt noch gar nicht zu gehört, als das ist ein Riesenproblem.

Was aber schon ein Riesenproblem ist, ist halt, also wenn du jetzt so etwas hast, wie, ich weiß jetzt nicht, was das Beispiel war, das kam auch in der Programm, du hast halt irgendwie einen Konzern, der hat halt hunderte Marken und jede Marke hat irgendwie eigene Dienste, die sie irgendwie anbieten.

Und die sind alle in unterschiedlichen Teams und so, auch weltweit verteilt und so.

Wie stellst du denn sicher, dass du irgendwas über einen bestimmten Kunden weißt, zentral?

Das kriegst du halt dann nicht mehr hin.

Oder halt

genau Produktion, wenn du halt da, wenn du denjenige bist, der das produziert und das dann verteilt an Unterrichtungen.

Das ist genau das, was ich meine.

Das ist der Nachteil, das geht halt nicht mehr.

Aber das ist ja das, was ich zentral, das sind wir vielleicht wieder, was bei Singapore und Frühstück irgendwie überschreiben kann.

Ich muss halt irgendwie sicherstellen, dass die Wahrheit, ich will die Wahrheit haben, damit ich das Menschen kann, damit ich die Entscheidung richtig treffen kann, damit ich

Steuer bin.

Es ist halt die Frage, ob es.

Also es geht halt manchmal, ich meine, ich kann es halt zum Beispiel nehmen, ein Beispiel als zweitgrößte E-Commerce-Konzern der Welt, wisst ihr, wer das ist?

Nach Amazon.

Oder?

Vielleicht ist Otto, aber tatsächlich, ich weiß nicht mehr, ob das noch stimmt.

Es kann sein, dass Ali das irgendwie AliExpress oder so größer ist.

Oder Alibaba

drauf, aber

Otto auf jeden Fall sehr, sehr groß und damals, das ist jetzt aber auch schon wieder lange her, hat sie sich das auf die Fahnen auch geschrieben, irgendwie der Zeitgröße nach Amazon zu sein.

Und die haben halt zum Beispiel genau dieses Problem, weil sie haben, es gibt ja nicht die eine Seite, auf der dann alle irgendwie Zeugs einkaufen, sondern die haben halt hunderte Shops.

Also jeder dritte Shop, auf dem du irgendwie landest, ist halt letztlich gehört zum Autokonzern.

Du weißt es aber gar nicht, weil das steht da ja auch nicht dran.

So, und die haben jetzt genau dieses Problem.

Jeder einzelne Shop hält halt User-Daten.

Und genau, wie machst du das denn jetzt eigentlich, wenn du quasi irgendwie Dinge wissen willst über deine User?

Also andersrum.

Also wie kriegen die ganzen Microservices wieder alle zusammen?

Und die Antwort, die das eigentlich gar nicht.

Also kriegst du nicht.

Ich glaube, da kommen so Leute auf die Idee wie Data Lake, wird dann eher Data Swamp oder so.

Irgendwas zu Sekretornen und bauen das dazwischen.

Das schlimmste Problem ist gar nicht unbedingt die technische Lösung, sondern das schlimmste Problem sind halt die politischen Geschichten, die du halt da auch kriegst automatisch.

Dass halt Leute sagen so, wir haben hier gerade einen Vorteil, die sind ja untereinander im Wettbewerb, ja.

Wir haben hier gerade einen Vorteil, weil wir irgendwas wissen, was die anderen nicht wissen.

Und jetzt sollen wir die Daten, das, was wir, was uns dazu verhilft, dass wir irgendwie besser sein können als unsere interne Prokuretz, das sollen wir denen jetzt irgendwie freiwillig zur Verfügung stellen.

Ja, aber dann kann ich nicht mehr so gut.

Dann haben wir halt irgendwie einen leichten kaputten Export, wo die Daten so ein bisschen.

Ja, aber mit der Konzernbrille, die du dann aufhast, dann musst du da hingehen, musst den goldischen Knoten dann kaputt hauen.

Dann musst du sagen, gib uns die Daten, wir sind der Chef.

Ja, schwierig.

Sehr schwierig.

Also, ja.

Aber auch da, ich meine, das ist jetzt ein sehr, sehr schönes Beispiel.

Aber als Konzern muss man sich natürlich die Frage stellen, was will ich eigentlich?

Will ich jetzt ein möglichst großes Franchise so schnell wie möglich aufbauen?

Habe ich die Kapazität, um das aus innerer Kraft herauszuschaffen?

Oder muss ich dafür sorgen, dass die Leute in weiß nicht wo das alles selbst entwickeln können?

Dann machen sie halt ihren eigenen Service und dann habe ich das Problem mit den Daten, dass ich nicht unbedingt alle Nutzer auf einmal kenne.

Aber das ist dann eine Sache, die man lösen muss im Nachhinein.

Und was hilft mir jetzt mehr?

Hilft es mir mehr, da einen Shop hochzuziehen und irgendwie mein Geld über das Franchise reinzuziehen oder wie auch immer.

Oder will ich jetzt einfach alles wissen und will ich die totale Kontrolle haben?

Ja, das ist halt genau das klassische Problem eigentlich.

Machst du halt irgendwie Diversifizierung oder machst du Fusionierung.

Irgendwie, das ist in der Software-Seite und die Frage, die irgendwie die Consultants immer geben, ist immer genau das Gegenteil von dem, was gerade da ist.

Dann kannst du halt so ein Projekt konsulten, kannst du halt Geld verdient.

Und dann geht es halt immer raus und zusammen.

Ich meine, das macht natürlich auch Sinn, ne?

Also, wenn du irgendwas hast, was total verfilzt ist, dann musst du das erstmal auseinandspalten, dann hast du kleine einzelne Services, die untereinander so ein bisschen Wettbewerben haben, die guten Sachen, muss dann irgendwie wieder konsolidieren und zentralisieren, um dann wieder den guten Benefit rauszubekommen.

Bist du dann wieder merkst, das wird dir doof, dann fängst du wieder an, das auseinanderzudröseln.

Das ist ja genau wie bei den Ländern.

Mal sind Länder werden zusammengefasst, dann sind sie auseinandergewogen.

Ja, aber das ist ja vielleicht auch dieser natürliche Zyklus, Lebenszyklus von so einem Ding.

Und ja, also wenn ich jetzt zum Beispiel hingehe, dieses Otto-Beispiel nehme und ich möchte diese User-Daten haben.

Ich würde jetzt als Otto hingehen und sagen, ich will wissen, wer sind meine Kunden, wie viele Kunden sind überhaupt irgendwo.

Da muss ich hingehen, muss sagen, gebt mir alle eure Daten.

Dann baue ich einen zentralen Service dann zusätzlich, der halt von allen die Daten abholt.

Dann kann es sein, dass ich jeden einzelnen dieser Shops einzeln integrieren muss.

Kann irgendwie sein, dass das relativ viel Aufwand macht, aber dann hole ich mir die alle irgendwann ab und dann weiß ich, okay, zumindest in der Historie gesehen, ist jetzt vielleicht ein Tag alt oder so oder eine Woche, ist ja egal, aber da sind die Daten einigermaßen echt und da habe ich einen vollen Überblick über was dann meine Leute sind.

Und da kann ich dann bestimmte Analysen fahren, die ich vielleicht fahren möchte.

Aber das ist ja das, was man vielleicht dann braucht.

Und dann kann man damit vielleicht dann wieder sagen, ah, aber dafür machen wir jetzt wieder so kleine Services, weil dann.

Vielleicht, ne?

Oder du kannst aber überlegen, ob du nicht schon im Vorfeld einen gewissen Standard etablierst, wo du sagst, da sind wir wieder beim Standard natürlich.

Und bei den Gateways.

Und bei den Gatekeepern.

Nicht nur bei den Gateways.

Ich bin ein Backend, ich interessiere mich nicht so für die.

Er doch auch.

Ja, mein Problem ist aber bei der Gatekeeper, ich musste gerade, weil du gesagt hast, Standards, musste ich an Infrastrukturstandards denken.

Und auch das ist ja unheimlich schwierig, wenn du die gleichen Standards einführst für Teams, die auf der Welt irgendwo sitzen.

Ja, damit verlierst du die Vorteile von Microsoft.

Ja, eigentlich sofort.

Genau.

Die Frage ist halt, was der Standard ist.

Möchte ich jetzt einfach so ein Plugin auf jedem Shop haben, welches meinetwegen in verschiedenen Programmiersprachen vorhanden ist, damit die Shops autonom sind.

Es ist für mich ein vertretbarer Aufwand, das zu gewährleisten, meinetwegen.

Das fängt ja schon bei moderneren Sachen an, wie keine Ahnung, jeder Dev kriegt einen Windows-Laptop mit AD Zugriff.

Genau, sowas hört es ja nicht.

Das ist nämlich der Punkt, weil wenn du Microservice das machst, musst du erkennen, dass das unabhängig sein muss von dem Rest.

Und du kannst das da nicht zentralisieren.

Und wenn du das machst, ist es halt kontraproduktiv, weil dann hast du den Monolithen irgendwo dazwischen sitzen, der wie eine Krake versucht, seine einzelnen Sachen doch festzuhalten.

Und dann ist das völlig absurd.

Wie gesagt, für mich muss man da so ein bisschen von loslassen, dass man die Kontrolle, die totale Kontrolle haben will.

Und wenn man das kann und wenn man dann die Vorteile für die Flexibilität sieht, die man dabei gewinnt, dann sind Microservices schon sehr vorteilhaft.

Ja, genau, aber das ist genau der Punkt.

Weil wenn ich jetzt sage, ich möchte den Hud auf haben, wird das so nicht funktionieren.

Sonst wird nur dann die Verantwortung abgeben kann.

Ja, dann

nimmst du Microservices.

Genau.

Aber das ist ja eine, aber da hast du ja schon eine Antwort.

Also willst du den Hut auf haben, wie du es so schön sagst, dann mach keinen Microservice oder überleg dir halt sehr, sehr gut, wie du das gewährleisten kannst, wie viel willst du wachsen.

Vielleicht geht das ja so bei den Microservices, wer weiß.

Oder willst du die Verantwortung abgeben, dann kannst du einen Microservices nehmen.

Die Frage am Ende ist, wenn du einen riesen Konzern hast, hat da überhaupt noch jemand den Hut auf, egal welche Ansatz zu machen.

Die Frage von Tenn ist ja ganz einfach, ist dann auf welcher Kostenstelle wird denn das gebucht und wer halt dann wo die Hand aufhört.

Ja, aber ich glaube, also, wenn man nochmal einen Schritt mehr Richtung Organisation oder allgemein oder abstraktes Problem geht, ich denke, also ich würde irgendwie diesen Trend zu Microservices halt so verorten in einem in einer Reihe von Trends, die halt alle in eine ähnliche Richtung laufen.

Ich glaube, DevOps ist auch so ein Ding, was in eine ähnliche Richtung läuft, weil bei all diesen Dingen geht es im Grunde darum, dass man halt in so einer klassischen Organisation, dass da die Incentives irgendwie pervers sind, so ein bisschen.

Und zwar, und das sind alles Versuche, das zu lösen, dieses Problem, dass die Incentives eigentlich nicht korrekt sind.

Also was ich damit meine, ist einfach nur, das ist eigentlich ein total simples Problem, ja.

Nehmen wir an, du hast halt irgendwie, früher irgendwie war es halt Entwicklung und Betrieb, ja, oder IT und Operations oder weiß ich nicht, und auf deinen Seite Entwicklung.

Und das hast du vielleicht auf unterschiedlichen Seiten deiner Bilanz auch, ne?

Das eine sind halt halt und das andere sind halt Investitionen.

Ja, so, dann hast du halt irgendwie, siehst du halt eine, wenn da Features entwickelt wirst, siehst du das halt Investition und denkst halt, je mehr Features entwickeln wir, voll gut, gib mir in der Zukunft mehr Einnahmen, total super.

So, das heißt, irgendwie deine Entwicklung misst du daran, wie viele Features kriegen die ja eigentlich pro Quartal irgendwie raus oder keine Ahnung, irgendwie sowas.

So, und dann geht das Ganze in den Betrieb, nachdem so und dann, woran misst du deinen Betrieb, den misst du an den Kosten und daran, dass es halt funktioniert.

Aber sozusagen, die Leute, die da arbeiten, die haben nichts davon, dass da mehr Features rausgehen.

Die werden nicht, die werden nicht, kriegen nicht mehr Geld dafür, dass sie halt dafür sorgen, dass die Entwickler mehr Features veröffentlichen.

Was ist deren rational beste Strategie in diesem Setting, ist halt tatsächlich zu sagen, never change a running system.

Ja, ja.

Irgendwie, ich werde nicht belohnt dafür.

Ich bin ein Kostenfaktor, ja, ich werde nur bestraft, wenn irgendwas nicht geht.

Solange das Wasser läuft und der Strom an ist, alles gut.

Sobald der Strom ausfällt, kriege ich auf ein.

Kein Problem.

Das heißt, mein Ding ist also, ich meine, klar, irgendwie eine Änderung kann sein, dass sie gut ist für andere, ja, aber ich habe ja nichts davon.

Oder sie ist schlecht, dann trifft mich das.

Das heißt, ich versuche möglichst Änderungen zu verhindern.

Dann, das ist sozusagen für mich am besten, weil dann kann ich sicherstellen, dass möglichst wenig kaputt geht.

Und na gut, für die anderen ist das halt nicht so toll, dass sie halt nicht so viele Features rauskriegen, aber es ist ja ehrlich gesagt nicht mein Problem.

So, und dann, das ist halt etwas, in das Unternehmen dann halt früher oder später irgendwann reinlaufen und überlegen sich, wie sie damit irgendwie umgehen, dass das jetzt irgendwie problematisch ist und das halt irgendwie, das ist halt halt ein Maß dafür.

Man sich fragt so, also dann macht man dann eine Kostenstellen und keine Ahnung, und dann sagt man intern so, und dann kostet das unfassbare Beträge, irgendwas sehr Simples zu tun.

Dann fragt man sich, ja, wie kommt denn das zustande, dass das plötzlich so wahnsinnig wie kostet?

Ein Server 50.000 Euro.

Ja, irgendwie sowas.

Und die Antwort ist einfach so, ja, das ist halt deswegen, damit du das nicht machst, damit du nichts änderst, ja?

Das ist der Grund.

Das ist halt der Preis für die Änderung.

Dass jemand sagt, so irgendwie, ich gehe hier für dich das Risiko, dass sich irgendwie das Sachen kaputt gehen.

Ich will möglichst, dass du nichts änderst.

Und deswegen ist das so teuer.

Und ja, DevOps ist halt dann so ein, also die Lösung dafür ist halt dann sozusagen die Verantwortung für diese Dinge halt auch mit den in den Bereich zu packen, der halt davon profitiert, wenn was deployed wird.

Ja, mit in den agilen Sprinter, das zu packen.

Genau, genau, Agile, auch so ein Ding, wo man sagt, okay, genau, das packen das alles zusammen.

Ja, oder halt eben DevOps, wo man sagt, okay, die Leute, die das deployed haben wollen, die plonst dann halt auch selber und betreiben es auch selber.

DevStack-Ops jetzt, ne?

Okay.

Full Stack Microservice DevOps im agilen Prozess, ja.

Und es geht halt darum, irgendwie, dass einzelne Teams halt möglichst autark irgendwie Dinge machen können und halt so, dass man halt sozusagen da, wo man investiert, halt auch tatsächlich, dass die auch dann die Möglichkeit haben, das umzusetzen.

Aber das kommt halt mit dem Preis.

Das ist halt Trade-off.

Es ist halt nicht so, dass das dann insgesamt automatisch super viel besser ist, wenn man das so macht, sondern es ist halt dann, ja, man wird dann halt schneller und so, aber dann wird halt eigentlich automatisch halt inkonsistenter dabei.

Und ja, das Projekt ist ja auch komplizierter.

Wenn die Leute aneinander ziehen, wenn es halt dann so ein PM-Layer dazwischen gibt, der halt dann in verschiedenen Schrauben zieht, also auch politisch zieht, weil es halt um Kosten stellen geht und wer wie, wann, wo, warum abrechnen kann und wer welche Investitionen oder Kosten verursachen oder schützen möchte.

Und das führt halt dazu, dass diese Idee Microservices ganz groß geschrieben, du willst ganz viel Microservice machen, aber hast eigentlich da die ganze Zeit diese Krake, die das festhält.

Und das funktioniert, glaube ich, überhaupt nicht gut.

Weiß ich gar nicht.

Also, ich meine, das Problem, also vielleicht kann man das ja an einzelnen Projekten irgendwie, also ich würde ja auch denken, das ist eine schlaue Art irgendwie, wenn man jetzt migrieren wollte von Modulite auf Microsoft oder so, wäre halt, man fängt halt kleinen mit kleineren Teilen an und macht das da und man macht nicht alles auf einmal, weil das wird wahrscheinlich nicht gut funktionieren.

Warum überhaupt?

Also ich verstehe es immer noch nicht.

Also irgendwie denke ich immer noch so, ja, warum hält man das dann nicht an einer Stelle fest und sorgt dann dafür, dass.

Und lösen wir uns mal darum, dass die alle dann an eine Stelle kommen, dass sie sich alle gut verstehen, dass sie alle dieselbe Text-Sag benutzen, dass die die Infrastruktur standardisiert benutzen, dass sie nur die standardisierte Infrastruktur benutzen, keine andere und dass sie halt dieses ganze Distributed Quatsch, Entschuldigung, dass alles weg ist.

Und ich habe die Single Source of Two, ich kann ja von mir aus verschiedenen Rechenzentren parallel an verschiedenen Orten halten.

Das ist ja okay, das kann ja ein Server-Team betonen.

Aber warum muss ich also die Abhängigkeiten werden dann von mir aus schwieriger, ja?

So ein bisschen zu managen, weil ich habe halt dann das Problem, wie Jochen gerade sagte, dass hochspezialisierte, hochgut bezahlte Spezialkräfte sich teilweise um trivialen Tries kümmern müssen, bis die Sachen halt mal integriert sind.

Aber dafür konnte man ja einen Service schreiben, also keinen Microservice, sondern einen, der halt dann in den Monolithen drin hängt, ja.

Ja.

Also ich ganz grundsätzlich, ich habe so ein bisschen das Gefühl, du bist, du bist so ein bisschen biased, ja.

Also ist mir

eine Meinung.

Ja, nee, es ist ja alles gut.

Also grundsätzlich muss man halt die Ausgangslage erstmal in Frage stellen.

Habe ich denn überhaupt die gleichen Kompetenzen?

Ich meine, darüber hatten wir ja schon geredet.

Es ist auch nicht immer ganz leicht, die gleichen Kompetenzen überhaupt zu finden für alles.

Wenn du eine große Firma bist, dann haben, weiß ich nicht, dann hast du vielleicht irgendwie einen Java-Entwickler, der ist Querensteiger in Python oder C Sharp in C<unk>, was weiß ich.

Sowas gibt es.

Und dann verlangst du halt von dem einen Entwickler, dass er seinen Stack zum Beispiel umstellt, das willst du ja auch nicht unbedingt.

Also du hast halt grundsätzlich erstmal verschiedene Kompetenzen.

Dann ist die Frage, brauche ich diesen einen globalen Text-Deck überhaupt?

Will ich den überhaupt haben?

Bringt er mir überhaupt was?

Ist ja immer so, also es gibt halt so wenig gute Leute, dass man wahrscheinlich schon Text-Tag multiplexen muss, damit man überhaupt

genug Leute findet.

Ah, siehst du, also Microservice, nein.

Aber grundsätzlich musst du dir ja auch die Frage stellen, erstmal, vielleicht, um von dieser Ebene mal ein bisschen zurück zum Code zu kommen.

Ein Monolith, der hat natürlich eine riesen Codebasis, die unter Umständen relativ komplex ist.

Das heißt, du musst viel Aufwand in den Deployment-Prozess an sich stecken.

Also bis du ein einzelnes Feature, ein neues Feature deployst oder einen Bug fix, musst du dich mit relativ vielen Leuten, wie der Jochen schon gesagt hat, abgesprochen haben.

Du bist insgesamt ein bisschen langsamer und vor allem auch fehleranfälliger insgesamt.

Wenn irgendein Integration-Test irgendwie fehl geht und der irgendwie den Produktion durchrutscht, dann ist im Zweifel rauscher ein ganzes System ab und hat eine Downtime, ne?

Genau, das kann steuer werden.

Der Monolith ist so ein klassisches Beispiel für Single Point of Failure.

Auch das kannst du irgendwie umgehen, indem du, du hast ein Backup-System, du hast das parallelisiert, was weiß ich.

Also du kannst die Chance minimalisieren, dass du genau in solche Punkten läufst, mit Rollback, mit AB-Tests und so weiter.

Also du hast deine Möglichkeit, aber auch das musst du dir halt erstmal aufbauen.

Das heißt, du musst dir mit der Zeit erstmal aufbauen, mit dieser Komplexität umzugehen.

Und am Ende stellt sich die Frage, wie gut gehst du eigentlich gerade mit der Komplexität um und kann das mein Team zum Beispiel sehr, sehr gut.

Und bin ich mit der Geschwindigkeit so zufrieden, weil ich habe die Erfahrung gemacht, dass sich bei einem Monolithen irgendwann viele Entwickler darüber beschweren, dass das Deployment zu langsam ist insgesamt, dass die Features teilweise zu lange rumliegen, weil zu viele Menschen.

Dann denn natürlich so, hm, wenn ich so zwei, drei am Tag rausschruben will, wäre das schon ein bisschen doof.

Ja, nicht nur, wir reden ja nicht über Stunden, wir reden teilweise über Tagen, Wochen.

Also das ist schon nicht so einfach.

Und dann kippt du auf einmal was um.

Du hast dann irgendwie ein, du musst das irgendwie organisieren, dass du einzelne Sachen deployst.

Und dann ist es natürlich schon cooler, wenn du einen einzelnen Microservice hast.

Und wenn der mal umkippt, dann ist es nicht so schlimm für die Gesamtanwendung.

Du gefährdest dadurch relativ wenig andere Sachen durch das Deployment.

Also erstmal wirst du durch einen Microservice, wie wir schon gesagt haben, unter Umständen auch nicht zwingend.

Du musst es natürlich auch erstmal gut machen.

Aber du kannst gewisse bürokratische Randeffekte dadurch durchaus vermeiden erstmal.

Also das wäre zum Beispiel ein Grund zu sagen, ich will das jetzt aufsplitten.

Ein anderer Grund ist, dass bei einem, wir reden über große Codebasen.

Also das muss man halt immer erwähnen.

Wir reden über große Teams.

So, und niemand kennt den ganzen Code.

Also was bringt dir einen einheitlichen Text-Deck, wenn du dich eh nicht mit Sachen in den Core-Geschichten auseinandergesetzt hast, weil du meinetwegen, weiß ich nicht, im krassesten Beispiel, du bist Frontend-Entwickler in der Django-Anwendung und du nutzt noch, du nutzt jetzt keinen WooJS oder sowas, sondern du schreibst irgendwie deinen Frontend-Code in die Django-Anwendung rein als Java-Entwickler, äh JavaScript-Entwickler.

Hast du auch nichts mit Python am Hut.

Da macht es schon Sinn, dass du sagst, okay, gut, ich baue jetzt mein eigenes Frontend irgendwo anders.

Ist jetzt nicht wirklich ein Microservice, ne?

Aber das veranstaltet einfach das Problem so ein bisschen, dass dieser Entwickler nicht den ganzen Stack kennt und auch überhaupt nicht kennen muss.

Gute Ich freut mich halt, ob das einen Unterschied macht.

Also ist ja egal, ob er jetzt jemand an seinem Feature-Branch irgendwie eine App baut.

Süße, wenn es keinen Unterschied macht, ist es doch doppelt egal.

Nein, aber das ist ja dann trotzdem im Monolithen.

Ja gut, aber also mindestens habe ich Komplexität raus.

Sowohl im Code.

Microservice ist ein kleinerer Code, der ist ein bisschen leichter zu lesen, du kannst dich ein bisschen schneller einarbeiten, weil du nicht vor einer Wand aus Code stehst.

Du stehst vor einer Wand aus Guidelines und Jira-Pages und was weiß ich, ne?

Der guter Jira.

Genau, ne?

Aber du steigst nicht irgendwie komponententief in den Code rein, musst du auch gar nicht, du kommst gar nicht erst in die Versuchungen.

Na, also du hast auf jeden Fall erstmal ein bisschen Komplexität auf Code-Ebene entschlankt.

So durch Microservice und vielleicht auch durch Deployment-Ebene und du hast das Risiko erstmal minimiert, dass du es verhaust.

Und du behinderst niemanden anderen damit.

Also du deployst halt in einem Monolithen immer nacheinander, wenn du verschiedene Teams hast, dann deployst du erst Team A, Team B, da musst du die Reihenfolge festlegen, auch das hast du in Microservices, wenn sie unabhängig voneinander sind, teilweise nicht.

Na klar, Breaking Changes, immer ein Thema.

Das hast du jetzt auch sehr schön geredet, weil also in meinem Kopf, da ploppt gerade wieder aus wie die Angst.

Und wenn ich das dann warten möchte und wenn ich das ausbauen möchte, wenn das Team weg ist, was diesen Microsoft entwickelt hat, dann muss ich ja wieder Experten suchen, sich dann mit dem anderen Text-Seck auskennen, die ich jetzt gar nicht kenne.

Vielleicht ja nicht.

Der Microservice an sich, der soll relativ schnell entwickelt sein.

Ich meine, das ist jetzt auch wieder Theorie, aber rein theoretisch soll er auch ein Microservice austauschbar sein.

Ja, okay.

Das heißt, das ist ein Wegwerf Ding.

Das heißt, wenn es nicht mehr läuft, dann würde ich halt jemand aus dem anderen Text-Stack den gleichen Microservice neu baut, irgendwie in das dann günstiger, wenn es geht, den anderen neu zu warten, ja.

Okay.

Ja, könntest du natürlich machen.

Aber ja, ich meine, ja, ehrlich gesagt, ich bin da, also ich meine, ich würde schon sagen, natürlich, dass es klar, dass es Situationen gibt, in den Microservice halt voll gut sind.

Würde ich jetzt gar nicht bestreiten wollen, aber auch, also würde man damit anfangen wollen, wenn man jetzt noch nichts gebaut hat, da wäre ich auch eher skeptisch, glaube ich.

Aber genau, also ich meine, das ist halt die Frage, gibt es irgendwie einen Grund, warum man das machen sollte?

Der, was ich dann, was der Autor von dem Buch da meinte, ist so, naja, eigentlich eher so, Microsoft, was macht man halt dann, wenn sonst nichts mehr funktioniert, als wenn halt sozusagen, wenn alle anderen Ansätze halt nicht funktionieren, dann muss man halt irgendwie, ne?

Aber ja, also und der sagt halt, der Hauptgrund, der wichtigste Grund, der tatsächlich irgendwie valide ist, ist halt, dass man Teile der Organisation halt unabhängig machen will vom Rest, eben dadurch, dass sie halt selber deployen können.

Und genau, wenn das halt anders nicht geht, dann muss man das halt so machen.

Aber, und ja, das kann halt nicht sein, wenn du halt einen großen Monolithen hast, den du schlecht deployen kannst und dann halt einzelne Teams halt sagen, so wir würden gerne, aber wir kommen, das wird nicht live, das, was wir machen, dann geht es halt vielleicht nicht anders rein.

Da muss man es machen.

Wir können vielleicht auch sogar in Richtung Use Cases gehen.

Ich meine, wir hatten ja schon Beispiel der Bestellservice meinetwegen oder IoT, wäre auch noch so ein Bereich, wo es prinzipiell durchaus auch natürlich wirken kann, Microservice zu etablieren.

Ich meine, nehmen wir jetzt mal an, wir haben einen sehr, sehr großen Datendurchsatz.

Also wir haben irgendwo eine Nutzerplattform, da machen Nutzer irgendwelche Sachen.

Und parallel davon kommen meinetwegen aus dem IoT-Bereich irgendwelche Temperaturdaten von Heizung rein oder Geodaten vom Auto, was weiß ich.

Also du schreibst sehr viele Daten, dann willst du natürlich dafür sorgen, dass dieser Schreibprozess, der die ganze Zeit irgendwo hinschreibt, von deinem User-Dashboard irgendwie entkoppelt ist.

Du hast ja keinen Bock, dass die Datenbank dadurch langsamer wird.

Unter Umständen ist die Datenbank da auch gar nicht die richtige für, um diese Art von Daten da reinzuschreiben.

Das heißt, wir haben auf einmal mit diesen Beispielen einen Kontext geschaffen, wo wir sagen müssen, okay, wir haben zwei komplett unterschiedliche Anforderungen geschaffen.

Wir haben einmal irgendein Dashboard, das ist so klassisch HTML, kannst du eine SQL-Datenbank hinterhängen, ist alles toll.

Und wir haben auf einmal irgendwie meinetwegen IoT-Daten, Geodaten, irgendwas, die in hoher Frequenz geschrieben werden.

Müssen wir uns überlegen, gut, wie verwalten wir den ganzen Spaß eigentlich?

Eignet sich dafür meine.

Aber ich habe es jetzt nicht genau verstanden.

Also du sagst, du würdest dich voneinander trennen.

Also du sagst nicht, beispielsweise, du hast eine SQL-Datenbank, da kommen die Sachen von der IoT-Sache einfach rein und der User liest halt aus der.

Ja, ich fülle das erstmal weiter aus noch.

Also ich kann überlegen, schreibe ich das jetzt gleichzeitig damit rein.

Aber irgendwann stelle ich halt fest, okay, zu Lastzeiten wird auf einmal meine Internetseite langsamer.

Weil ich auf einmal zu viele Daten schreibe von diesem IoT-Prozess.

Und die User, die kriegen eine schlechte Nutzererfahrung dadurch.

Also die Schreiblast, die steigt, dadurch wird die Internetseite unter Umständen langsamer, weil ich alles ineinander verwurscht habe.

Und da muss ich überlegen, gut, wie gehe ich jetzt damit um?

Also normalerweise sollte darfst du gar nicht so viel langsamer werden, oder?

Wenn du schreibst, klar.

Aber gut, oder ich meine.

Also schreiben, also zum Beispiel Boostgres lockt jetzt dann nur die Zeile, wenn du schreibst.

Und wenn du jetzt ein neues IoT hast, dann hat er ja eine neue Zeile drauf.

Das heißt, der Nutzer, der kann ja alle anderen Zeilen zum Beispiel lesen.

Ja, also halt, also ich meine, das kann, aber es kann natürlich schon passieren.

Es kann natürlich schon passieren, dass Schreiblast irgendwann irgendwie dein System langsam macht.

Aber auch meine Frage wäre halt, ja, wie häufig kommt denn so denn vor, dass man so skalierbar oder dass man, also ich würde sagen, ja, es gibt einen mal liegen Grund, Microservices aus Skalierbarkeitsgründen einzusetzen, aber wie häufig kommt denn das vor?

Nochmal kurz zu dürfte Fragen, was wäre denn jetzt die Lösungen davon?

Dann habe ich Sachen, die IoT schreibt in eine Datenbank rein und dann habe ich ja, der in Flaschen heißt bei dem Prozess, der von der einen Datenbank in die andere Datenbank was übertragen muss.

Dann ist ja der Stand alt beispielsweise, weil die Verbindung.

Ja, die Frage ist, ob wir das überhaupt übertragen müssen.

Also Microservices.

Als erstes stelle ich fest, okay, das passt jetzt nicht irgendwie in die SQL-Datenbank, die wächst mir zu schnell, das sind Zeitreihen zum Beispiel.

Dann schreibe ich das in eine Datenbank, die extra dafür vorgesehen ist.

Influence zum Beispiel.

Prometheus ist auch eine, aber die ist eher so für Metrikdaten.

Dann schreibe ich das da rein, dann überlege ich, gut, wie ziehe ich mir die jetzt in dieses monolithische Ding, aber es macht für mich erstmal überhaupt keinen Sinn, diese Art von Daten in die SQL-Datenbank vielleicht zu schreiben.

Das heißt, ich habe diesen Prozess mal getrennt und auf einmal habe ich Möglichkeiten.

Also auf einmal habe ich es geschafft, diesen Prozess zu trennen und jetzt kann ich überlegen, gut, zu Lastzeiten zum Beispiel haben wir immer höhere Peaks.

So, wie kann ich die Architektur jetzt vielleicht sogar günstig halten?

Dann kann ich auf einmal überlegen, weil ich jetzt meine Datenbanken getrennt habe, ich habe jetzt eingesehen, okay, ich habe einen getrennten Schreibprozess von diesem Dashboard-Prozess.

Jetzt kann ich anfangen, den Schreibprozess zu optimieren, meinetwegen, ich mache es jetzt mal ganz wild, meinetwegen einen Kafka in die Mitte zu hängen.

So, dann schreibe ich jetzt Richtung Kafka rein.

Kafka ist letztlich so ein Topic, hast einzelne Nachrichten drin.

Und diese Nachrichten, die können asynchron zum Prozess konsumiert werden.

Und zu Schreibzeiten schreibe ich ganz viele Nachrichten in dieses Topic.

Ich habe aber vielleicht gar nicht die Kapazität, um alles in Echtzeit abzuarbeiten.

Aber vielleicht ist es auch gar nicht schlimm.

Ich kann die nachabarbeiten.

Also von diesem Tickets-System kann ich mir dann meinetwegen 10 Minuten verzögert Nachrichten rausziehen und die dann erst in die Datenbank reinschreiben.

Und dann habe ich nicht das Problem, dass ich meinen Server unter Umständen dynamisch skalieren muss.

Oder generell hochskalieren muss.

Ja, aber ja gut, aber da wäre halt die Frage, was ist ja, also ja, es ist alles valide, aber irgendwie, was ist teurer, irgendwie die Architektur aufzuteilen oder irgendwie einen von dickeren Server zu kaufen?

Ja, aber auch da, da gibt es so sehr, sehr schöne Grafen, dass es natürlich ein Monolith ist sehr, sehr lange günstiger als Microsoft, das stimmt.

Aber irgendwann, irgendwann kann man zu diesem Punkt kommen, wo es überproportional teurer wird, sich größere Hardware zu kaufen.

Also erstmal steigt das irgendwie sehr, sehr gradlinig.

Ich geh es kollier hier immer so rum, aber ist ja Podcast.

Nee, aber erstmal steigt das relativ geradlinig, also irgendwie iPhone X3X, ne?

Kann man sich sehr schön vorstellen.

Und hinten raus wird es dann auf einmal exponentiell.

Dann explodieren die die Kosten, weil die Maschinen dann einfach wirklich sehr, sehr teuer wird.

Also ich finde, das Problem, was du gerade gesprochen hast, müsste man eigentlich nochmal mit Leuten, die noch ein bisschen mehr Spezialbissen Datenbank haben, sprechen, weil für mich hört sich das nicht so an, als wäre da der Flaschenhals an der richtigen Stelle.

Das gibt es alles schon.

Also es ist halt die Frage, ob es so häufig ist.

Ich meine, das Problem ist halt, also was du dafür aufgibst, ist natürlich die Konsistenz.

Ja, das stimmt halt einfach nicht mehr.

Und ich habe halt dazwischen noch so einen extra Layer, wenn ich jetzt einen Kafka dazwischenpacke.

Warum?

Also wenn ich jetzt eigentlich direkt aus der Datenbank lesen könnte und die Frage, du sagst halt die Datenbank wird langsam, das verstehe ich nicht so genau, weil wie viele Verbindungen hat die denn dann offen?

Nein, aber einfach die Schreib, zum Beispiel, du hast ja nur eine bestimmte Bandbreite zu deinen Platten, wenn du es wirklich schreiben musst.

Wie du denn, ganz ehrlich, die Postgres hängt im Bram.

Nee, nee, nee, nee, nee.

Wenn du was schreibst, nein, nein, das ist ja.

Nee, ja, nur beim Lesen, nicht beim Schreiben.

Doch, beim Schreiben auch.

Nein.

Doch, das wird danach mit Vakuum reingeschrieben.

Nee, also das ist, wenn die Transaktion fertig ist, dann hat Postgres F-Sync hinterher aufgerufen.

Dann ist das, dann hat die Platte gesagt, ich hab's weggeschrieben.

Ja.

Das macht Postgres unfassbar viel langsamer als sowas wie Riddis.

Aber bei Ridis ist halt auch, wenn du dann, wenn du das Ding ausmachst, dann sind die Daten sind halt weg.

Bei Postgres nicht, dann sind die Daten halt noch da.

Das ist der große Unterschied.

Ja, aber die Frage ist halt, was halt dann Schreiben und so weiter, wann wird das halt überhaupt freigegeben?

Also das ist ja egal, das macht aber.

Wenn wir die Datenbank sagt, deine Transaktion ist durch, dann ist das wirklich so.

Ja, aber das macht dann nicht.

Das macht aber die Postgres nicht langsamer, sondern das ist doch halt nur langsamer.

Ja, aber das macht die langsamer.

Ja, aber das macht schreiben langsamer, aber das heißt nicht, dass das Lesen langsamer wird.

Ja, doch, weil in der Zeit, wo du was schreibst, kannst du nichts lesen.

Nein, du kannst nur die Sachen nicht lesen, die geschrieben werden.

Also du kannst die Sachen nicht lesen, die noch nicht im Hauptschall hier sind, ja, sagen wir so.

Ja, genau, also die noch nicht auf der Platte sind, die kannst du nicht schreiben.

Also kannst du nicht lesen, aber das heißt ja nicht, dass du nicht die Sachen, die vor drin sind, lesen kannst, weil die Transaktion von den Sachen, die noch nicht geschrieben ist, noch nicht fertig ist.

Das heißt, dass du den Stand der Schreibsachen nicht kannst, das heißt aber nicht, dass das Lesen langsamer wird.

Doch, ja, letztlich.

Nein, das ist ein eigener Prozess.

Also völlig unabhängig davon ist.

Also wenn irgendwann quasi, wenn du so viel schreibst, dass du nichts anderes mehr machen kannst als schreiben und dann die Bandbreite zu deinen Platten halt oder SSDs heute halt irgendwie ausgefüllt ist mit Schreibvorgängen, dann kannst du nicht mehr viel lesen.

Nein, wieso?

Also lesen nimmst du eh noch auch einen Speicher, das ist ja egal.

Das IG einfach nur, dass das nicht mehr so gut ist.

Wenn dein Work-Z komplett im Hauptspeicher ist, ja.

Ja, das ist sowieso immer im Hauptspeicher.

Das ist immer im Hauptspeicher, das ist wirklich so.

Und das Einzige, was halt da dann dein Constraint ist, ist dann die CPU-Kerne, die halt damit beschäftigt sind.

Wie viele Prozesse du offen hast, also das heißt, wie viel gleichzeitig Verbindungen, die auf deiner Datenbank stehen.

Ja, aber sagen wir mal so, in der Praxis, das, wo dir häufig das System platzt, ja, ich sag mal so, also das ist also erfahrungswert aus der Praxis.

Das, wo du dann merkst, okay, ich habe hier ein Problem, wo ich irgendwie mit der Architektur anfangen muss, was zu machen, ist, dass irgendwann deine Slaves mit der Schreiblast nicht mehr klarkommen.

Also deine Replikas.

Wenn du das nicht mehr hinkriegst, wenn die, wenn dein Replikationslack immer größer wird, weil du das nicht mehr weggeschrieben bekommst, was du an Schreiblast hast, in dem Moment hast du ein Problem mit deiner Architektur.

Dann musst du das sowieso aufbrechen, ob du deinen Microservice machst oder sozusagen vertikal auftrennst oder ob du es horizontal auftrennst, indem du dann halt sozusagen das schadest nach irgendeinem Hash oder so, wo du dann halt mehrere Master hast, in die du schreibst.

Ja, auch Master Slave, ja.

Genau, das kannst du dir dann überlegen, ist beides schrecklich und mach dein ganzes Datenbankmodell im Grunde kaputt und inkonsistent, ja.

Also das aber kannst du dann nicht mehr aussuchen.

Ja, aber du Master Slave-System mit so einer Postgres, dann hast du dann, wo die Dachin reinschreiben und dann lesen die halt aus dem anderen Teil.

Ja, aber was ist, wenn deine Slaves das nicht mehr wegschreiben können?

Das passiert.

Das ist so.

Das ist halt, dann bist du an dem Punkt, wo es

nicht mehr geht.

Noch mehr Slaves?

Nein, die können es nicht mehr schnell genug wegschreiben.

Das ist ja vorbei.

An der Stelle, also ich meine, das ist heutzutage, also wer kommt an diese Punkte?

Also das ist halt, ja, das ist nicht so häufig, denke ich.

Aber das kann schon passieren und dann musst du Schaden.

Also wenn man den Rest dann vorher richtig gemacht hat, die Frage wäre halt, wenn du das sowieso nicht schnell genug wegschreiben kannst, dann musst du ja eh warten irgendwo.

Ja, und da hilft dann noch Kafka.

Da hast du die Nachrichten schön in einem Topic und holst du die später nochmal ab.

Die Frage ist natürlich, wie lange sie da drin bleiben, aber da brauchst du halt genug Worker.

Also diesen Prozess, den müsstest du dann gewährleisten können, aber auch da hast du Möglichkeiten.

Dann kannst du sagen, irgendwie bist du so und so viel Speicher soll vorgehalten werden oder so und so lange.

Und dann kannst du dir erst wegschmeißen und du musst auch überlegen, brauche ich alles?

Brauche ich alles, alles?

Gut, dann hat was halt eine Latenz dann, ne?

Ja.

Nicht nur Latenz, ne?

Also vielleicht hast du auch einen Datenverlust unter Umständen.

Aber die Frage ist, kann ich vielleicht Daten verlieren?

Also ich meine, gerade im Bereich von Zeitreihen ist es auch oft so, dass Daten über einen gewissen Zeitraum hinweg zusammengefasst werden und einfach irgendwie gemittelt werden.

Und dann ist das Problem, worüber wir uns gerade streiten, gar nicht mehr so schlimm.

Aber das Problem ist, in dem Zeitpunkt schon, wenn du es auf einmal in einer monolithischen Struktur vielleicht drin hast und einzelne Services dadurch umkippen und du hast es jetzt irgendwie so ein bisschen entlastet und dass das Replikations-Lag, wie Jochen sehr schön gesagt hat, das wächst und wächst.

Dann stoppst du halt eine gewisse Zeit lang mal den Schreibprozess und hast dann meinetwegen ein Konsumer-Lack im Kafka, aber das kannst du ja irgendwie so zurechtschrauben, dass es funktioniert, dass es deine Architektur verkraftet.

Aber das ist natürlich ein sehr, sehr, und das muss man auch sagen, das ist ein extrem spezielles Problem, welches echt nicht jeder hat.

Aber das ist ein Problem, welches man bekämpfen kann.

Wie viele IT-Geräte muss es denn denn da gegeben haben, damit das ein Problem hat?

Keine Ahnung, das wurde schon

ganz gut.

Kommt drauf, aber das war's.

Da spielt ja auch mit rein.

Ja, aber letztendlich, also diese Art von Problem hast du natürlich immer.

Also Chris Küntopp, der hat das mal irgendwann irgendwie so schön genannt, es gibt ja im Grunde zwei unterschiedliche Arten von Datenbanken.

Es gibt halt die OLTP, Online-Transaction Processing Datenbanken.

Das sind halt so die, wenn du jetzt auf irgendwie einen Kaufen-Button klickst, die dann halt die Kauftransaktionen machen.

Und es gibt halt OLAP, also Online Analytical Processing, das ist halt so dein Data Warehouse irgendwie.

Und der sagte das mal sehr schön, also werden jetzt die Leute irgendwas machen und du schreibst halt Sachen, also OTP ist zum Schreiben gedacht und Olaf eher zum Lesen.

So, wenn, wenn die jetzt irgendwie die ganze Zeit irgendwie diese Geschichten generieren, dann, also im Grunde, jede OTP-Datenbank hat in sich so ein Data Warehouse, das raus möchte.

Irgendwie von einer gewissen Zeit.

Das hatte ich gerade ein sehr schönes Bild.

Ja, das ist halt so.

Irgendwann willst du das halt vielleicht da raustrennen.

Ja.

Ja, aber spannend, also dass dann doch wieder um Datenbank ging am Ende, bei der Frage, ob man Microservice an der Stelle macht oder nicht.

Nein, das weiß ich ja gerade gar nicht.

Kann doch sein, dass halt die Datenhaltung, da waren wir auch fast mit angefangen, dass das Datenmodell, die Datenhaltung, dafür sehr relevant ist.

Das ist einfach generell ein Problem, ne?

Aber das Schöne ist, dass du quasi, und das ist vielleicht eher der Knackpunkt, das Schöne ist, dass man erkannt hat, okay, wir haben jetzt IoT-Daten, die ich vielleicht anders behandeln möchte als meine Nutzerdaten, die ich vielleicht anders ablegen möchte.

Und will ich das in einem Monolithen machen oder erkenne ich, dass ich vielleicht dafür auch einfach ein ganz, ganz anderes Know-how brauche?

Ich hatte das meinen wegen einer SQL-Django-Anwendung, erkenne aber, dass das kein SQL-Kontext ist.

Habe ich jetzt die Leute bei mir, die sich mit dieser Art von Daten auskennen oder brauche ich dafür vielleicht neue Daten?

Sorry, neue neue Leute.

Und kriege ich diese neuen Leute in das bestehende Team rein?

Oder baue ich dafür ein separates Team mit einem separaten Service auf, der da einfach parallel läuft, weil es halt besser ist in diesem Moment.

Für das Problem, welches ich jetzt gerade versuche zu lösen?

Und ich meine, das ist jetzt sehr, sehr schöne Wendung, ne?

Aber das ist jetzt wirklich so ein Punkt, wo man sieht, okay, jetzt auf einmal auf ganz natürliche Weise macht es auf einmal Sinn, darüber nachzudenken.

Ja, das kann Cost-Efficient sein an der Stelle vielleicht.

Ja, das hat mehrere Trade-offs, ne?

Oder auch ein anderes Beispiel, nicht unbedingt aus IoT, aber meinetwegen, du hast eine Java-Anwendung und du möchtest auf einmal eine Recommendation Engine einbauen.

So, und dann erkennst du, okay, das ist im Bereich Machine Learning.

Das ist in Python mehr vertreten, da hast du in Python eine größere Community, hast du vielleicht auch bessere Lösungen für.

Dann suchst du dir ein Python-Team aus, welches dir dafür ein Model baut, welches dir dafür eine API bereitstellt.

Kriegst du das jetzt unbedingt in deinen Java-Monoliten rein oder stellst du deinen Service in deinem?

Und versuchst du das vielleicht zu integrieren.

Das Problem, welches dann natürlich aufkommt, natürlich, wenn du von Monolithen kommst, ist, dass du von einer konsistenten Struktur unter Umstände in eine inkonsistente reinläufst.

Ja, du kannst vielleicht gar nicht warten.

Du musst halt immer wieder auf das externe Team zurückgreifen.

Ja, es muss ja nicht mal ein externes Team sein, das kann ja auch ein neues internes Team sein.

Ja, oder dann halt intern, ne?

Aber du bist halt da.

Klar, dieses Problem hast du dir jetzt geschaffen.

Das ist irgendwo ein selbstgeschaffenes Problem.

Die Frage ist natürlich, komme ich da drum herum?

Wie ist der Trade-off?

Also man hat einfach effektiv immer einen Trade-Off.

Die Frage ist immer, was ist das größere Übel am Ende?

Und was bringt mich jetzt schneller vorwärts?

Ja, insofern, also ja, würde ich auch so sagen, also ich denke auch, es gibt gerade gerade, also wenn man halt ganz viele Leute hat und das sehr groß wird, dann wird Microservices immer attraktiver an die.

Aber auf der anderen Seite, aber dass das halt irgendwie jetzt heutzutage oft irgendwie so als, das macht man halt so und das ist halt jetzt irgendwie so.

Das ist ein volliger Quatsch.

Das ist so ein bisschen, da würde ich mir denken, ich weiß nicht.

Und ich meine, da gibt es ja auch so einen schönen Begriff von David Hannemeyer-Henson, dem Ruby and Rails-Menschen, der sagte, der versuchte den Monolith-Begriff halt aufzuwerten, indem er dann noch ein Adjektiv vorgestellt hat.

Man nennt das jetzt immer Majestic Monolith sozusagen.

Weil ich meine, wenn man jetzt halt ein kleines Team hat und irgendwie etwas macht, was halt, dann ist halt das unter Umständen halt deutlich effizienter, weil, ja,

auch wenn du schnell was bauen willst.

Genau.

Also das ist ja auch sehr, sehr bekannt.

Also wenn du jetzt gerade anfängst, dann fängst du natürlich nicht mit Microservices an.

Also du ziehst jetzt von null auf einen Code hoch, hast ein kleines Team, vielleicht sogar ein großes Team, das ist komplett egal.

Aber eigentlich denkt man da erstmal monolithisch nach.

Einfach um vorwärts zu kommen, um wenig Komplexität erstmal zu haben, weil die Komplexität, die kommt erst mit der Zeit.

Du bist halt jedes Mal noch neuen Klotz ans Bein irgendwie, ne?

Und auch noch weitere Komplexität und weitere Abhängigkeiten und Dependencies, wenn du halt einen neuen Service setzt.

Aber irgendwann wird das Erfahrungsgemäß dann so groß, dass du deine Prozesse so verlangsamst und so ineinander verstrickst und dass sich die einzelnen Entwickler auf einem engen Raum so sehr auf die Füße treten, dass du eben drüber nachdenken musst, das Ding aufzubrechen.

Und das ist dann, haben wir ja auch gesagt, dann migriert man üblicherweise langsam rüber Richtung Microservice.

Das ist man lagert einzelne Funktionalitäten aus, schaut, wie sie alleine dastehen und dann bekommst du auch wesentlich mehr Möglichkeiten.

Ich meine, ein Vorteil oder Nachteil eines Monolithen ist mitunter, auch dass die nicht immer unbedingt leicht sind, alle Prozesse zu parallelisieren.

Also du kannst einen Monolithen sehr schwer teilweise parallel laufen lassen auf verschiedenen Instanzen.

Du musst es nicht immer unbedingt.

Aber das ist bei einer großen, komplexen Struktur mit vielen verschiedenen States ein bisschen schwieriger.

Und manchmal ist es leichter, wenn du dir dann einzelne Teile daraus nimmst und damit schon mal anfängst, die auszulagern und dann findest du vielleicht so ein Stückchen, wo es sich lohnen würde, das Teil zu parallelisieren.

Da würdest du dir vielleicht wünschen, okay, ich will meinen Server jetzt, will ich nicht mehr RAM geben.

Eigentlich hätte ich lieber einen weiteren dazu gebucht für diesen Service, weil es vielleicht günstiger ist, weil es vielleicht leichter zu machen ist.

Dann ziehst du einfach parallel noch eine Note hoch.

Das wünscht man sich ja auch manchmal.

Und das ist zum Beispiel ein Microservice ist einfach natürlicherweise leichter als ein Monolithen.

Wären wir ein bisschen positiver.

Ist auch schön.

Ja, nicht negativer.

Also es geht halt so ein bisschen darum, wann das der Fall ist.

Welcher Use Case dann wirklich dafür ist.

Also ich denke

auch, wenn man das dazu bringen will, dass es ein Ding, wie das helfen kann, wenn man jetzt drüber nachdenkt, ist halt auch so, wenn man einen Microservice aufteilen will, dann ist das ja auch ein sehr schöner Anlass, irgendwie da nochmal drüber nachzudenken, wie sind denn eigentlich die Schnittstellen und so, wie würde man dann modularisieren wollen.

Also sozusagen eigentlich würde man dann anfangen und sagen, okay, machen wir es doch mal modular, also keine Ahnung, ich habe jetzt irgendwie einen Modoliten und der notifiziert irgendwie User für irgendwas.

Und jetzt möchte ich das da raustrennen, weil irgendwie dieses ganze Handling von unterschiedlichen Wegen, wenn ich User notifiziere, ist halt problematisch und ich würde das gerne da raustrennen.

Dann wäre halt eine gute, die schlechte Strategie wäre halt irgendwie sozusagen irgendwie den Funktion, also irgendwie eine JSON- oder HTTP-API irgendwie jetzt vor die Funktion, die die Notifizierungen macht, zu klemmen und das halt auf einen anderen irgendwo anders hinzulegen und dann rufen halt aus dem Monolithen die Sachen halt dann diese JSON-API auf oder so.

Das ist leider halt das, was oft gemacht wird und das wird dann halt sehr schrecklich.

Aber was man ja durchaus tun könnte, ist halt, okay, man versucht das jetzt sauber zu machen, man macht halt irgendwie ein Interface, sagt, okay, so sehen die Notifizierungen aus, irgendwie und die haben wir das klassische Ding, was halt immer benutzt wird.

Und jetzt machen wir einfach eine neue Implementation, die halt dann über den Microservice geht.

Und wir können das halt auch hinterher gucken, dann machen wir das Ganze hinter den Feature Flag oder so und sagen, okay, jetzt schicken wir mal 1% des Traffics halt irgendwie über den Microservice, dann gucken wir an, wie sehen die Fehler hinterher aus, sind die irgendwie mehr geworden oder hat das genau das Gleiche getan?

Sind das, ist das, oder wir schicken es gar nicht raus, wir gucken einfach nur, wir schicken geben jetzt, wir schicken es an beide, wie verhält sich das denn unter Last und so?

Und dann kann man das schön, denke ich, machen.

Aber die Voraussetzung ist eigentlich, dass man das halt schon ordentlich modularisiert hat, dass man ordentliche Interfaces hat, dass man das irgendwie schon halbwegs gut strukturiert hat.

Und ja, dann und das ist vielleicht auch so eine Möglichkeit, dann an der Stelle nochmal irgendwie drüber nachzudenken, wie modularisiert man eigentlich ordentlich.

Auf jeden Fall.

Ich meine, auch um noch eine positive weitere Sache aufzugreifen, die mir gerade in den Sinn kommt.

Oft ist es ja so, dass, ich sage jetzt mal, ein Datensatz, eine Row, sehr viele verschiedene Prozesse durchläuft, um in die Datenbank zu kommen.

Also die wird von verschiedenen Prozessen genutzt, manchmal transformiert, also die wird sehr, sehr oft durchgereicht.

Und das fiel mir jetzt gerade ein, als er ja auch angesprochen hat.

Wenn du das jetzt auf einmal anfängst, in Microservices aufzuteilen, dann musst du dir natürlich überlegen, okay, wie gestale ich jetzt den Weg vom Anfang bis zum Ende durch.

Und du bekommst auf einmal wesentlich mehr Möglichkeiten.

Also üblicherweise ist es ja so, dass dieser Prozess in irgendeiner Form sehr, sehr synchron ist.

Also der geht von A nach B.

Und im Prinzip wartet der Client darauf, dass der hinten angekommen ist.

So wird es halt sehr oft strukturiert.

Oder die Anwendung wartet auf eine Antwort, die sie nicht unbedingt braucht.

Und in einer Microservice-Welt kannst du eben sehr, sehr schön darüber überlegen, wie kommunizieren Services allgemein miteinander.

Und auf einmal stellt man eben fest, dass sie überhaupt nicht synchron miteinander kommunizieren müssen, sondern zum Beispiel auch über Cues und Topics.

Und dann schickst du da ein Event hin und dann ist das so ein Write-Ony-Ding.

Dann schicke ich diesen einen Datensatz und diesen Endpunkt, der schreibt es Richtung Topic und von diesem Topic kann das dann von verschiedenen Microservices gleichzeitig konsumiert werden, ohne dass ich jetzt irgendwie einen Async bei mir im Code einbauen musste, um das darzustellen.

Und der Nutzer, der kann sofort weitermachen.

Der muss nicht unbedingt auf die wahre Antwort warten, wenn das ein Bride-only-Prozess ist.

Auch ein Vorteil.

Oder auch sehr schön teilweise zu design.

Ja, wobei ich denken würde, also die Voraussetzung wäre, dass man das halt erstmal intern gemacht hat, dass man erstmal intern irgendwie so eine Art Service-Boost hat und dann kann man das halt auch vielleicht nach außen verlagern.

Aber ja, also ich meine, das ist halt auch so was, wo man dann vielleicht mal drüber nachdenken kann, wie strukturiert man die Applikation eigentlich so, dass das halt irgendwie so funktioniert.

Ja, weil

es ist halt saukomplex, ne?

Also das muss man halt einfach sagen.

Da braucht man diesen Service-Boster, diesen Message oder diesen Message-Boker dann halt.

Und wenn man den halt hat.

Braucht man ihn, will man ihn.

Die musst du ja auch dann wieder mitbetreuen.

Ja, klar, ist das eine Dependency, du brauchst die Kompetenz, ne?

Das ist halt immer so das Ding mit der Komplexität.

Aber der Service auf der anderen Seite, der ist vielleicht auch unter Umständen einfach austauschbarer.

Du kannst ihn relativ problemfrei austauschen, ohne dass du denn aktive Anwendungen affektierst.

Oder du kannst ihn leichter deployen, ohne dass der Service darauf warten muss, dass das Deployment abgeschlossen ist.

Zum Beispiel.

Also du hast weniger Downtime dadurch.

Also klar, du brauchst ihn nicht.

Du kannst auch weiterhin synchron denken.

Wenn wir jetzt nur in der Welt von Microservices unterstellen.

Ja, du wenigstens.

Synchron hat das ja, glaube ich, gar nicht gekriegt.

Ja, oder per AP-Call.

Du kannst.

Wenn wir in der Welt von Microservices unterwegs sind, dann haben wir auf einmal mehr Möglichkeiten, wie einzelne Services miteinander kommunizieren können und wie wir gewisse Prozesse strukturieren.

Das verstehe ich nicht genau.

Also was meinst du mit mehr Möglichkeiten so kommunizieren?

Ja, die Service Bus oder die Ques, beziehungsweise Topics und Ques sind natürlich jetzt eine Möglichkeit mehr, die wir in einer Anwendung.

Du kannst ja, die kannst ja auch, oder da hatte ich auch gerade gerade, kannst du ja auch in die Anwendung einbauen.

Ja, aber ist das immer so geil?

Ja, also ich würde sagen, das ist halt so ein bisschen die Voraussetzung dafür, dass man das überhaupt dann auftrennen kann, weil, äh, oder ich sag mal, ich kenne, ist halt, ist halt die Frage.

Also ich kenne das halt so, dass man das intern in der Applikation vor allen Dingen macht.

Also das ist halt dann aufteils, die Dinge, die man tut, halt man halt auch in Commands, Events und irgendwie vielleicht Dokumente gibt es halt auch.

Da gibt es ja diese ganzen Enterprise-Service-Bus, irgendwie, weiß ich nicht, irgendwas Patterns.

Es ist halt die Frage, ob er das braucht, keine Ahnung.

Ich habe mich letztens mich da so ein bisschen mit beschäftigt, weil ich mich einfach mal interessiert hat, wie man denn sowas baut.

Da gibt es ja auch das Buch, er werde ich irgendwie auch in jeder Episode irgendwie, oh, hier liegt es rum, Architecture Patterns with Python.

Die bauen halt, die fangen halt an und mit irgendwie auch, das ist auch glaube ich ein Allokations- also das, womit die sich beschäftigen, ist halt sozusagen Bestellungen irgendwelchen Lagerbeständen zuordnen sozusagen und fangen halt an, naiv mit so einer Flask-Applikation und bauen das dann halt immer weiter um, sodass am Schluss bleibt halt so ein Service-Bus übrig.

Und das könnte man dann theoretisch auch in Microservices dann halt alles dann auslagern, was man da so tut.

Aber das eigentlich würde ich sagen, so ein bisschen die Voraussetzung dafür, dass man das überhaupt kann, ist, dass man es intern schon so macht, also dass man halt intern schon, oder ich weiß es nicht genau, aber wenn man das jetzt von außen dran, aber nochmal zu dem, warum macht man das überhaupt mit diesen Ques und so, denke ich, der Vorteil ist halt einfach, wenn du es, wenn du HTTP oder JSON-RPs hast, dann machst du halt jedes Mal zum Beispiel so ein TLS-Handshake oder sowas.

Das ist natürlich extrem ist halt verbraucht immer CPU.

Du kannst halt ein Socket aufhaben.

Oder so.

Ja, wie bei HTTP.

Nein, nein.

Einfach kein HTTP, sondern du hast halt ein Socket auf, irgendwo in der Verbindung.

Ja, okay, und wie sicherst du die irgendwie ab und welchen Standard, wie machst du das?

Keine Ahnung, also wie Websocket genau unten drunter funktioniert.

Aber der hat ja am Anfang beispielsweise auch seinen Handshake, aber der bleibt halt offen, der muss dann noch jedes Mal den neuen Handshake machen, oder?

Ja, bei HTTP geht das nicht.

Bei HTTP gibt es immer nur Request-Responses.

Genau, ja, aber ich kann jetzt ein Socket aufmachen, wenn ich jetzt auch so ein Q-Ding habe.

Genau, das Support bei der Queue hast du, da steht halt eine Verbindung und die bleibt halt und du kannst halt mehr Sachen drüber schicken, genau.

Das ist halt der Riesenvorteil.

Ja, genau, aber ich verstehe jetzt nicht, wo der Unterschied hat, warum brauche ich dafür einen Microservice?

Also das hat für mich nicht so viel miteinander zu tun.

Nee, aber die Frage ist jetzt, wenn du jetzt Microservices hast, wie verbindest du die miteinander?

Oder vielleicht habe ich die Frage einfach nicht verstanden.

Ich dachte, das wäre die Frage, warum man nimmt man denn da so einen Bus oder so eine Que, warum nimmt man nicht einfach HTTP oder so?

Ja, also die Frage wäre, also wenn ich jetzt schon so einen Bus nehme hatte, warum mache ich das bei Microservice?

Also warum mache ich das nicht trotzdem mit meinen Monolithen oder so?

Ja, ja, genau, da würde ich sagen, ja, das kann man, so würde ich anfangen.

Ich würde so anfangen, dass man das zuerst so baut, dass man das intern benutzt.

Also meine Meinung, es kann halt schon sein, dass man sowas braucht.

Die Frage ist, ob man es in einem Monolithen will, ne?

Warum nicht?

Ich hatte jetzt, also ich persönlich hatte jetzt noch nicht das Anliegen oder das Verlangen, dass ich in einem Monolithen mir sowas gewünscht hätte.

Weil die Wege dort dann natürlicherweise kürzer sind, ne?

Na gut, also du kannst halt einfach jetzt theoretisch noch einen Container zu deinem Deployment spawnen, wo halt irgendwie so ein Kafka oder ein Redis oder irgendwas läuft.

Nee, nee, das brauchst du ja nicht.

Wenn du es intern machst, brauchst du das ja nicht.

Das ist einfach nur Funktionsaufruf.

Da ist ja eine Queue.

Einfach zum Beispiel in Python ist es halt einfach nur ein Q-Modell.

Okay.

Also vom Qur Q sozusagen oder so.

Und dann machst du halt, solange irgendwas in der Q drin ist, machst du halt irgendwie rufst du Funktionen auf.

Das war's.

Das ist auch nicht, ja.

Kann man durchaus machen.

Nicht verwendet.

Da höre ich jetzt zum ersten Mal von tatsächlich, dass das so ein Python-Ding ist.

Es hat aber nichts mit Netzwerkverbindungen oder so.

Nein, nein, nein.

Ist das dann einfach irgendwie so ein State, der existiert, global und cool.

Ja, man kann das einfach so, man kann diese Muster ja durchaus auch einfach so, deswegen meine ich, also wie man die Struktur aufteilt und die Architektur von einem Ding baut, das kann man ja auch schon vorher richtig machen quasi.

Und dann kann man es halt auch aufteilen, oder es ist sehr einfach, das aufzuteilen, während wenn man jetzt einen Modoliten hat und das ist tatsächlich, ich fürchte, also ich das ist halt das, was ich in der Praxis oft sehe, ja, dass Leute halt eigentlich in so einer Situation sind, sie haben einen Big Ball of Mutt, der halt irgendwie kompliziert und komisch ist und wo sie nicht weiterkommen.

Und jetzt suchen sie nach irgendeiner Lösung für dieses Problem.

Und dann kommen sie auf Microservice, stürzen sie auf Microservices und sagen so, was ist die Lösung für mein Problem?

Ich hänge weiter vorne, ich hänge weiter vorne.

Ich will wissen, was passiert denn mit dieser Queue, wenn der Service eine Downtime hat?

Nein, dass du einfach nur ein Prozess da ist.

Das ist einfach ein Prozess.

Also die anderen, die funktionieren irgendwie weiter oder ist dann irgendwie, weiß ich nicht, läuft in einem separaten Thread in einem gleichen.

Alles in einem Thread im gleichen Prozess.

Das Einzige, was es halt sozusagen bringt, ist, dass ich die Sachen halt sauber voneinander getrennt habe.

Ich mache halt auch, ich mache halt immer, wenn ich irgendwas schreiben möchte, mache ich halt einen Command und ich habe halt dann meine Eventhändler, die alles Mögliche machen.

So zum Beispiel habe ich halt einen Event-Händler, der schickt halt das Event dann auf dem Websocket raus für irgendeinen Client, einen anderen Eventhändler, der tritt irgendwie einen Prozess los, einen anderen so.

Und das kann ich ja, aber das ist alles nur Funktionsaufrufe, die nacheinander passieren.

Das ist aber alles im gleichen Prozess.

Okay, also für mich so zum Verständnis.

Vielleicht ergibt sich ja dann so die Möglichkeit, dass wir alle erkennen, okay, wir brauchen unbedingt Kafka.

Nein, aber nur, damit ich das verstehe, nehmen wir jetzt mal an, wir sind jetzt in der Django-Anwendung unterwegs, ja, und wir schicken einen Request rein.

So, und der kommt jetzt in die Queue.

Die erste Frage ist, was passiert beim User?

Bekommt er sofort die Antwort zurück oder wartet er darauf, dass der Prozess von der Queue komplett verarbeitet wurde?

Der bekommt sofort, also da ist es so, der bekommt sofort eine Antwort zurück.

Und sozusagen die Eventhändler bearbeiten das dann halt später weiter.

Okay, die bearbeiten das später weiter.

Das heißt, wenn jetzt der nächste User kurz danach, bevor das alles abgearbeitet wurde, wieder einen Request hat.

Was man schon zurückbekommt, ist, dass das Command durchgegangen ist.

Also sozusagen man wartet bis, also ein Request kommt rein, sozusagen, dann erzeugt man einen Command, sagt irgendwie Handle-Command oder Handle, Service Bus Handle.

Und wenn das zurückgekommen ist, kann man sicher sein, die Transaktion ist durch.

Aber dann sind noch nicht alle Events bearbeitet worden.

Okay, dann sind noch nicht alle Events bearbeitet worden.

Und dann schickt man einen User zurück, okay, das ist jetzt durchgegangen.

Okay, und jetzt kommt der nächste User an, bevor alle Events abgearbeitet wurden.

Und der kann dann unbekümmert das auch reinschicken, weil die Events im Hintergrund noch parallel abgearbeitet werden.

Okay, das heißt, das geht.

Und was passiert, wenn der Service jetzt crasht, bevor alle Events abgearbeitet wurden?

Wenn das ganze Ding crasht, ist vorbei, dann events.

Das ist ja nur ein Prozess.

Dann ist es weg, ja.

Das heißt, wir haben jetzt nicht irgendwie, okay.

Ja gut, aber wenn, wenn wir brauchen irgendwas, ja.

Also wenn ich mich jetzt dafür entscheiden würde, dass es unglaublich wichtig ist, weil dieser Prozess vielleicht eine Minute dauert, weil da irgendwie verschiedene Stages durchläuft.

Es gibt Gründe.

Keine Ahnung, du hast eine unglaublich langsame API irgendwo dranhängen.

Die braucht einfach ewig lang zum Antworten, aber der Nutzer, der soll nicht so lange auf diese API warten müssen, also kriegt er sofort die Antwort zurück.

Wir haben das jetzt in der Queue, das wartet, jetzt stürzt das Service ab.

Aber eigentlich will ich unbedingt diese Antwort haben, weil es meinetwegen eine Transaktion ist und der Nutzer gerade was gekauft hat.

Du kannst das ja in der Datenbank kurz wegschreiben oder so.

Du kannst ja sagen, du schreibst es direkt weg in die Datenbank, gibst du Nutzer die Antwort und hängst es dann in die Queue und dass er aus der Datenbank das dann nimmt.

Und wenn das dann abstürzt, der Prozessquest, dann hast du ja an der Datenbank noch die Sachen stehen.

Du kannst ja einen Fleck dran machen, ist dann fertig oder nicht.

Ja, ja, aber irgendwie hacky gefühlt.

Also ich weiß nicht, ob man damit wirklich das Problem löst, aber erstmal wird es dann so sein, dass der Prozess weg ist.

Wenn du es weggeschrieben

hast, dann hast du das da noch nicht die Queue durch, aber du hast halt den Datenschafter gekommen ist und hast halt so.

Aber das macht natürlich den Prozess dann minimal langsamer, weil ich erst was in der Datenbank schreiben muss.

Das dauert nicht lang.

Ja, aber vielleicht doch zu lang.

Na, glaube ich.

Also wenn du irgendwie lange Sekundenweiter irgendwas

anderes wartet.

Ja gut, aber das soll da nicht so lange dauern.

Aber wie gesagt, ich fühle mich dabei dann so ein bisschen unwohl, dass ich das innerhalb dieses Python-Prozesses habe, weil ich eben sicher gehen muss, dass ich diese Informationen nicht verliere, wenn ich sie denn nicht verlieren muss.

Und da hilft dann natürlich irgendwie so.

Also ja, ich meine, ich würde ja sagen, man kann das ja auch machen, aber ich meine, ja, also ja.

Ich würde eher denken, also wie man das dann macht, ist letztlich eigentlich, ist ja dann keine Architekturfrage mehr, ob man dann auch wieder in Kafka verwendet oder Rabbiting Queue oder nochmal was anderes, ist ja letztlich.

Fand ich einfach nur interessant gerade.

Also, wie gesagt, das war mir jetzt neu.

Ich meine, da tun sich viele Fragen auf, die mit dem eigentlichen Thema nichts zu tun haben.

Also, wie gehe ich mit Exception um?

Azure Service Pass hat zum Beispiel eine Exception Dead Letter Cue.

Das muss ich mir natürlich relativ umständlich dann da reinbauen.

Also ich brauche ein vergleichsweise umständlicheres Fehlerhandling, wenn ich das dann auch irgendwie über diese Ques abbauen möchte.

Das kann ich mir natürlich anders mitbauen.

Du brauchst ja für jeden Microservice eigentlich so ein eigenes Fehlerhandling auch, ne?

Ja, also wenn du, wenn du, ja, oder ein Standard, wie man es dann am Ende sieht.

Also klar, das bringt einen dann wieder zurück zu den Microservices und wieder zu einem generellen Problem.

Und das Fehlerhandling entscheidet dann der Service selbst oder das Team in dem Fall.

Also ich meine, ja, okay, beim Konsumenten meinte ich jetzt in einem.

Ja, wenn du eh die Dependency hast, dass du irgendjemanden hast, der das konsumieren will und dann halt Sachen macht.

Na gut, das Fehlerhändler brauchst du sogar so, je nachdem, was da drin steckt, aber du hast natürlich, meiner Meinung nach, wenn du Microservices hast, eine größere Anzahl an Fehlerquellen.

Es wird halt viel komplizierter, du musst dir halt über all diese Dinge Gedanken machen im einzelnen Prozess, musst du das nicht.

Da hast du alles egal.

Da machst du halt ganz normales Exception Handling und da brauchst du all diese Dinge nicht.

Wie was du hast?

Was passiert denn mit Retry und gucken, genau, was da und lebst du noch und war der nur kurz weg, war die Verbindung weg, war der Server weg.

Ja, aber das, ich meine, wenn sich darum jeder Service selbst kümmern muss, dann ist es natürlich auch wieder nicht so kompliziert.

Also wenn ich immer nur auf meinen Punkt gucke und ich schaue, welche Möglichkeiten gibt es.

Also im gesamten Prozess gibt es immer mehr Fehlerpunkte als.

Also du glaubst einfach dem, was dann da in deiner Que steht.

Beispielsweise.

Ja, das muss natürlich validiert werden, und wenn da was Falsches drinsteht, dann weiß ich, dass irgendwas vorher falsch war.

Klar, dass diese A von D-Balgen, die ist schon super schwer.

Weißt du das, dass da irgendwas Falsches drinsteht?

Okay.

Also weiß ich nicht, wenn wir jetzt zum Beispiel, wir erwarten jetzt ein bestimmtes JSON in deiner Que.

Ja, und dieses JSON entspricht nicht dem richtigen Format, dann weiß ich, dass da vorher irgendwas falsch war.

Okay, dann ist aber gar nicht passieren dürfen, dass es da reinkriegen wird.

Genau, das ist jetzt so ein sehr, sehr einfacher Fehler.

Es kann natürlich sein, dass ein falscher Nutzer irgendwie in deinem Datensatz drin steht und dein Service kann das nicht überprüfen.

Aber da sind wir dann wieder bei der Herausforderung des Datenmanagements.

Also wie gestalte ich das richtig, wie gestalte ich das gut, wie kann ich solche Sachen vermeiden, wie sünke ich vielleicht meine verschiedenen Datenbanken?

Oder ist dann wieder so ein eigenes Problemchen?

Oder großes Problem.

Ja, aber das sind wieder bei Dependencies, ne?

Ja, man, man, irgendwann, wie Sachen so schön, irgendein Tod muss man sterben.

Also das ist halt leider so.

Ja, nein, aber die Frage ist halt, ne, ich glaube, das hat halt so ein Overhead, wenn man mit vielen Microsoft arbeitet und den muss man irgendwie handeln können und den tradeoffen gegen den Overhead von ist es jetzt kompliziert oder die Sachen weiterzubauen in diesem Monolithen, weil halt dann es schwierig wird, das zu beherrschen.

Und das ist vielleicht so ein bisschen.

Ja, es ist immer so ein bisschen trickreich.

Aber vielleicht, ja, ich frage mich immer, ob das jetzt wirklich schlimm ist.

Klar, als Unternehmen möchte ich natürlich so viel wie möglich wissen, aber als einzelner Entwickler, wie ich es einer bin, interessiert mich das eigentlich gar nicht so.

Also es ist mir eigentlich relativ egal, ob ich jetzt in einen Monolithen entwickel oder in einem Microservice.

Das ist auch so das, was meine persönliche Erfahrung ist.

Ich komme in ein Projekt rein, wo meinetwegen Microservices drin sind und dann bin ich damit total fein.

Dann gucke ich auf meine Sachen.

Klar, ich habe mehr Abstimmungen mit anderen Leuten, aber am Ende ist das, und das kann ich jetzt, ist jetzt auch nur eine gefühlte Sache, um die sozusagen, so kompliziert wie wir hier gerade reden, ist das in der Realität gar nicht.

Also wenn du jetzt überlegst, ich will jetzt zu Microservices rüber migrieren, ich habe einen funktionierenden Monolith, dann will ich das eigentlich klar, für dich ist das super kompliziert.

Aber für mich, der jetzt neuer vielleicht in ein Projekt reinkommt, noch nicht alles kennt, noch nicht weiß, wie es zu diesem Punkt kam, ist der Umstand Microservice gar nicht mal so das große Thema.

Und man lernt halt wirklich auch viele Dinge, weil man sich mit Sachen intensiver auseinandersetzen muss, mit denen man sich vorher nicht so wirklich intensiv auseinandergesetzt hat.

Wie zum Beispiel Logging, wie zum Beispiel Metrikmonitoring, wie zum Beispiel.

Ja, aber das kann auch wieder eine Gefahr sein.

Ja, das ist ein

technischen Appiel, aber für den Kunden bringt das ja jetzt erstmal nichts.

Aber gut, ja, ja, ich verstehe schon.

Also das, was ich vielleicht finde, ist, dass wir relativ kompliziert wurden, hatte ich so das Gefühl.

Aber der Sachverhalt an sich, der ist gefühlt gar nicht so komplex.

Und die Probleme, die wir aufgezählt haben, die sind schon da, aber die müssen nicht immer ein Problem sein.

Ich bin aber tatsächlich doch ein bisschen dem, was Jochen gesagt hat.

Die Frage ist, wann braucht man das überhaupt?

Also du brauchst halt wirklich einen Fall, wo du dich auskennst und ein wirklich weißes Paustest, das kannst du nicht anders lösen, bevor du überhaupt die Entscheidung treffen würdest, machen wir jetzt einen Microservice draus, weil ich glaube, vorher muss man erstmal andere Sachen korrigieren

oder so.

Ja, also ich meine, das klingt jetzt alles schrecklich oder klingt jetzt, wenn ich alter Sack.

Ich habe immer früher, wenn Leute sowas gesagt haben, so ja, ja.

Aber tatsächlich, so Erfahrungen zu, also oft ist es irgendwie, also ich habe das Gefühl, dass das Problem in der Praxis ist oft Kompetenz.

Oder weiß ich nicht, ob Leute das irgendwie hinkriegen oder nicht.

Bataban, kann man das essen?

Und die Sachen selber sind gar nicht so kompliziert, das da würde ich vollkommen recht geben.

Ich würde es ausdrücken, es gibt einen nicht unerheblichen handwerklichen Teil bei dieser ganzen Geschichte.

Und der ist gar nicht so gut in theoretischer, also das ist aber so, das ist halt nicht so viel, da ist gar nicht so viel Theorie.

Also genau ich, ich weiß nicht, das ist vielleicht die falsche Analogie.

Ich versuch's einfach mal, wenn man sagt irgendwie, ja, man möchte gerne irgendwie ein Bart schön gefliest haben oder so, dann das Buch zur Fliesenlegt-Theorie ist jetzt gar nicht so dick, vielleicht.

Das heißt aber nicht, dass es ein einfaches Problem ist, ja.

Wenn man das selber versucht, dann wird man feststellt, sieht nicht so aus, wie ich mir das vorgestellt habe, blöd.

Und tatsächlich braucht man möglicherweise lange und muss lange üben und viele Badder gefließt haben, müssen man das richtig kann.

Und das ist halt leider beim Programmieren manchmal auch irgendwie so.

Und ja, das ist halt ein Problem, mit dem Organisationen dann auch oft konfrontiert sind und das nicht so richtig gelöst kriegt, irgendwie.

Und dann probiert man das halt mit so komplizierten Geschichten irgendwie.

Also ja, okay, aber eigentlich, und das Dumme ist, da gibt es halt auch keinen einfachen Weg raus.

Seite der Lösung dafür ist halt, weiß ich nicht, Leute schulen oder abwarten, bis sie so gut geworden sind, dass das dann funktioniert oder so viele Sachen kaputt gegangen sind, dass sie dann irgendwann gemerkt haben, wie es richtig funktioniert.

Und dass es halt dann vielleicht so ein Zeithorizont mehrere Jahre oder so.

So, das kann man ja, und dann ist noch nicht mal sichergestellt, dass es dann hinterher wirklich funktioniert.

Sondern da kann man nur die Hoffnung drauf haben, dass es dann vielleicht funktioniert.

Das ist ja da, das ist ja ganz schrecklich, ja.

Wenn ich jetzt ein Projekt habe, wo meine Karriere dann hängt, ob das jetzt gut wird oder nicht.

Das kann man ja niemandem mal zählen.

Und dann versucht man halt irgendwie andere Sachen um das.

Aber das ist halt alles nur, ja.

Also ich glaube, ohne zu der Bartanalogie zurückzukommen, dann hast du halt entweder eine Mosaikwand oder du klebst halt alles mit einem Kleber drüber.

Dann hast du eine glatte Wand.

Das ist auch, glaube ich, modisch gerade.

Und ich glaube, das ist nicht so schlimm.

Ja, ich weiß nicht.

Wichtig ist, was kannst du in dem Bart machen?

Kannst du da dich duschen zum Beispiel?

Ja, ja, aber ich glaube, das ist halt tatsächlich gar nicht so einfach, das hinzukriegen, dass es wirklich gut funktioniert.

Das ist halt irgendwie schwierig.

Ja, okay.

Die Handwerkskunde ist natürlich schon sehr wichtig.

Ja, oder ich weiß nicht, vielleicht ist das auch ein blödes Beispiel oder ein Musikinstrument spielen.

Das ist vielleicht auch theoretisch gar nicht so.

Gitarre gibt nicht so viele Seiten, aber trotzdem irgendwie muss man lange üben, bevor das irgendwie funktioniert.

Und manche Bereiche, vielleicht nicht alle, aber manche Bereiche beim Programmieren sind halt auch so.

Also dieser Modularisierungsbereich, da habe ich das Gefühl.

Musik ist gut, das ist irgendwie.

Deine Kinder können relativ viel Krach machen und in das Musik.

Naja.

Okay.

Haben wir eine Quintessenz gefunden damit?

Es kommt drauf an.

Genau.

Das gibt es aber auch, da hat jemand schön, dass die Lösung aller IT-Probleme, irgendwie so ein O'Reilly-Buch, wo drauf steht, it depends.

Absolut.

Ich bleib dabei, es ist prinzipiell cool erstmal.

Das muss man halt sagen.

Es klingt natürlich cooler, auch wenn das natürlich niemals ein Entscheidungspunkt sein sollte.

Und auch sehr, sehr subjektiv ist.

Aber ich glaube, am Ende kommt es immer einfach drauf an, ob man es haben will, dass man es braucht.

Da haben wir wieder, es ist ein gutes Sales-Argument.

Wir machen Microservices, ist wunderbar.

Das klingt erstmal immer gut.

Ja, okay.

Ja, das ist auf jeden Fall ein gutes Argument, wenn man Geld für mich vergehen kann.

Ja, ja.

Rein technisch natürlich immer schwer.

Da sind wir wieder bei den Finger, wo die Infra sagt, da bewegen wir uns gar nicht, sagt dann halt Consulting, ja, wir müssen ja nichts Neues drauf treiben, wieder ein bisschen Sales Marketing machen kann.

Ja, aber das ist halt so ein bisschen, das ist halt auch das gleiche Problem wie, also ich glaube, ich versuche mal das noch auf den Punkt zu kriegen, ich krieg's nicht so richtig gut formuliert.

Das ist halt so Probleme, die schwer lösbar sind, die produzieren im Grunde irgendwie so Scheinlösungen.

So, weiß ich nicht, Gesundheit ist schwierig, ja, irgendwie, wenn man irgendwie eine schwere Krankheit bekommt oder so, dann hat man ein Problem, das sehr schwer lösbar ist, wo man nicht viel machen kann.

So, das produziert halt irgendwie den ganzen Markt von irgendwie so Pseudo-Snack Oil, weiß ich nicht, Quacksalwann.

Irgendwie Computersicher halt ein schwieriges Problem, ja, irgendwie dann auch da entsteht so eine Branche von irgendwie mehr so etwas halbwegs vielichtigen, weiß ich nicht genau.

Vielleicht manche sind gut, manche sind nicht

so gut.

Also da habe ich schon gesagt, dass ihr eine Firma betreiben, bei der bei Organ Energie auf Telefon anrufen kannst und ich schicke dir dann positive Energie durch das Universum zurück.

Ja, also jetzt muss ja nur noch das entsprechende Problem suchen, was die Leute gerne löst haben.

Oder halt so eine 009-Hänger-Nummer oder sowas.

Ja.

Sorry, wir schweifen schon wieder ab.

Aber ja, und da muss man halt, ich meine, ja, und es gibt dann halt so Dinge, die sind so, ja, vielleicht schon sinnvoll, aber man kann sie halt auch so benutzen.

Also es ist halt, das ist halt wie, ich weiß nicht, es gibt die ganze Big Data, Blockchain, weiß ich nicht.

Und Microsoft ist halt auch irgendwie so ein bisschen, irgendwie zumindest irgendwie, man hatte so das Gefühl, das wird immer so als Lösung verkauft für Sachen, die schwer sind.

Ja.

Aber ich will gar nicht sagen, dass das jetzt irgendwie Unsinn wäre oder so, sondern nee, also es ist schon, es gibt da schon durchaus Abflussfall und das ist auch vielleicht eine gute Idee.

Sie machen nicht immer alles leichter, sie machen manchmal auch Sachen schwerer, aber sie machen dabei andere Sachen leichter.

Aber nicht alles.

Man hat einfach wirklich diesen, also das ist, ich glaube, das ist auch immer ganz wichtig zu sagen dabei.

Man hat halt wirklich ein Trade-off und der ist nicht ohne.

Der ist niemals ohne Mann.

Ja, vielleicht wollte man jemanden fragen, der sich damit auskennt, bevor man Erinnerung macht.

Genau.

Ja, keine Ahnung.

Wir hätten, also ich hätte auch noch Pics, also wir können auch noch, ich weiß nicht genau, wie es aussieht.

Wollen wir noch irgendwie, äh, gibt es noch irgendwie Themen oder haben wir schon alles gesagt, was wir sagen?

Haben wir alles gesagt zu Microservices?

Bestimmt nicht.

Stimmt nicht, ja.

Ja, ich habe noch eine andere Frage, aber das hat nichts mit den Pics zu tun, aber es ist dann Jochen.

Aber haben wir noch irgendwas zu Microservices?

Sonst würden wir das Thema einfach zumachen.

Machen wir es so.

Du hast irgendwas mit File-Benchmarks gemacht, irgendwas war anders.

Ah, okay.

Ja, um, also das ist etwas, das mich ja auch schon eine ganze Zeit lang umtreibt.

Sollen wir das beim nächsten Mal sonst erzählen?

Nö, wir können das gerne, wir können das gerne, äh, wir können da gerne kurz drauf eingehen.

Ja, also meine, die Frage, die mich beschäftigt hat, ist, weil ich würde ja gern, ich würde ja gern ins Hostin-Geschäft einsteigen.

Ja, also ganz dick.

Ja, genau.

Und eine Frage, die mich da beschäftigt hat, also gerade Podcast-Hosting, ja, ich meine, wir betreiben unsere eigenen, wir sind ja unser eigener Podcast-Hoster tatsächlich.

Und da sind das, das sind etwas spezielle Anforderungen, die Files sind groß.

Ja, File-Serven, schnell File-Serven.

Genau, und die Frage ist jetzt, okay, mich ärgert, dass wir da so eine Abhängigkeit haben.

Wir machen das über ein CDN, über Cloudfront und das ist auch teuer irgendwie.

Erstaunlich teuer.

Und die Frage wäre, kann man das nicht selber machen, weil wenn man irgendwie so ein, ich miete ja sowieso Server, auf denen ich Ding haben, deploye und da ist der Traffic frei.

Warum kann man da nicht die Server, äh, die Files auch mit ausliefern?

So mit einem Menü oder sowas.

Ja, oder einfach im einfachsten Fall ein statischer Webserver.

Das geht natürlich.

Das Problem dabei ist halt, naja, also solche Dinge wie Authentifizierung und sowas ist halt schwierig.

Wie ist das denn halt?

Also ich meine, das ist natürlich, viele würden sagen, das ist doch egal, wenn da jemand deine, also hier geht es um den Fall zum Beispiel, man editiert halt irgendwie eine neue Podcast-Episode zum Beispiel.

Und dann sollte das ja, sollte zum Beispiel die Audio-Inhalte nicht für jeden sofort verfügbar sein, sondern erst wenn das frei veröffentlicht ist, ja, sozusagen.

Also nur wenn man authentifiziert ist.

Wie macht man das dann denn?

Das geht ja quasi gar nicht, wenn ich das auf dem statischen File-Server hätte, dann sobald die Files verfügbar sind.

Wenn man den das kennt von dem Link dann, ja.

Ist jetzt ein Detailproblem eigentlich, aber mir geht es, also wie wäre das denn, wenn ich das für andere machen wollen würde?

Die haben ja eventuell auch noch irgendwie so Anwendungsfälle, wo sie Sachen vielleicht nur nicht öffentlich veröffentlichen wollen, also eine ausgewählte Gruppe von Leuten.

Also, wie soll denn Authentifizierung funktionieren?

Eigentlich gibt es dann halt diese ganzen Geschichten mit, man schickt halt sozusagen einen Request an den File-Server, der und da ist halt irgendwie ein Cookie gesetzt oder halt ein Token oder da ist irgendwas in der URL, was signiert ist und dann der fragt nochmal einen anderen Service und guckt halt nach, ist er jetzt authentifiziert?

Fragt der Microservice-Fall, bitte?

Fragt den Microservice.

Ja, genau.

Da hätte man dann auch schon so eine Art Microservice oder man hat halt, man schickt halt den Request zum Applikations-Server.

Der Applikationsserver schickt aber nicht die File-Response zurück, sondern der schickt nur eine Response zurück, wo ein Header gesetzt ist, in dem drin steht, ja, dieses File darf ausgeliefert werden und dann der Reverse-Proxy vorne dran tauscht dann halt diese Response, die echte File-Response aus und so.

Und den X macht?

Ja, genau, das gibt's, wie heißt das?

X-Send-File oder ich war irgendwie so.

Ja, genau.

Und also das gibt es alles, alles sehr hässlich und funktioniert auch alles nicht so richtig gut.

Und deswegen wäre es auch viel schöner, wenn man das direkt über einen Applikationsserver ausliefern würde.

Und ich dachte eigentlich, oh, geht doch.

Dann Ustatic-Files quasi.

Ja, da gibt's, das gibt's, also wenn die Assets gemeint sind, also sowas wie CSS und JavaScript und so Zeugs, da gibt es schon was für.

Nicht die Assets, sondern wirklich dann halt mit Einzel Single Permission on File.

Genau, da gibt es nichts.

Und das wäre aber interessant.

Und eigentlich dachte ich irgendwie, das müsste mit Python auch gehen.

Python-Isync AO, da gibt es ja auch alles irgendwie.

Und Juve-Loop ist ja auch sehr schnell und so.

Und das müsste man doch eigentlich machen können und es geht auch.

Dein Benchmark hat festgestellt, Caddy ist viel schneller.

Ja, genau.

Dann habe ich irgendwie jetzt ein anderes, weil ich interessiere mich für Kochen und so und habe so einen Rezeptmanager, Melee.

Ja, hab ich mal eingekauft.

Kann man sich auch mal angucken, ist ja nett.

Und das habe ich dann irgendwie auf meiner Infrastruktur deployed und da gibt es auch viele Bilder und so.

Und dann dachte ich, ah, das mache ich bei Juvicorn, weil wozu haben die da noch extra einen Caddy laufen?

Und dann habe ich dann auch in der Discord-Bescheid gesagt, so, ja, warum macht ihr denn da nochmal Caddy irgendwie zusätzlich?

Das ist Quatsch, irgendwie mach das doch einfach über den Juvicorn.

Und dann so, ja, aber wir haben die Erfahrung, macht es dann irgendwie schneller und irgendwie sonst ist langsam.

Das kann gar nicht sein.

Dann muss ich beim Benchmark machen.

Habe ich ein Menschmark gemacht und gesehen, stimmt doch, sie haben recht, ich lieg falsch.

Auf jeden Fall tatsächlich Nginx Caddy viel schneller als Juvicorn, beziehungsweise die File-Response von Sarlet, was halt unter Fast API auch drunter liegt.

Und das ist halt fast IPR-Backend.

Ja, keine Ahnung, woran es liegt.

Ich weiß es nicht.

Also sagen wir so, es ist immer noch schnell genug für Gigabit-Ithernet-Interface.

Aber wenn es, äh, also 10 Gigabit schafft man damit nicht.

Und ein Caddy und Nginx schaffen das schon.

Also irgendwas ist da nicht richtig.

Ich weiß aber nicht was.

Kommen wir wieder zu, Juvicorn macht das Ganze ja, oder Juve-Loop ist halt Seiten vor allen Dingen und denkt man, das kompiliert ja nach C, das muss doch eigentlich schnell sein.

Keine Ahnung.

Also eine mögliche Grundführung, warum das so ist, den ich wo ich denke, das könnte sein, ist, es liegt daran, dass irgendwie CADI und NGIX irgendeine Art von Zero-Copy-TCP verwenden, wo es halt nicht nochmal durch den User-Space kopiert werden muss, die Daten.

Und das macht die ReCorn halt nicht.

Sondern, weil das kann es halt noch nicht.

Also es gibt da einen Pull-Request, das ist aber noch nicht durch.

Das heißt, da wird immer alles nochmal kopiert.

Also es wird vom Fallsystemen im Hauptsprecher von der Anwendung kopiert und dann nochmal in den Netzwerkspeicher und dann erst raus.

Das ist natürlich viel ineffizienter, als wenn man es halt, als wenn der Permine.

Interessant wäre, wenn man den Pool-Request kann, man mal Cherry-picken und mal gucken, ob es dann ein bisschen.

Muss man sich vielleicht mal ein bisschen angucken.

Also das könnte noch ein Unterschied sein.

Das wäre dann halt relativ langweiliger Grund.

Dann muss man sagen, ja gut, und das wäre halt so, ich weiß nicht, ob das dann mit Minio auch einfach so geht, wenn man die Files nicht im Fall-System liegen hat, sondern halt irgendwo anders, was man ja vielleicht will heutzutage.

Dann geht es vielleicht alles nicht mehr.

Aber dann ging es auch mit Nginx und so nicht mehr, weil, auch mit Kelly nicht, weil, ja, dann, weil die könnte man nicht sein File einfach verwenden.

Das geht halt nicht.

Das geht halt nur, wenn es ein tatsächlich ein File- und Fall-System ist, glaube ich.

Auch da wäre interessant, wenn sich das jemand, wenn ihm jemand Bescheid sagen könnte, der sich damit auskennt, ob das so ist oder nicht.

Anware Python-Podcast.

Genau.

Ja, genau.

Damit habe ich mich so ein bisschen beschäftigt.

Und ja, auf jeden Fall scheint es so zu sein, dass Caddy viel effizienter ist als Juvicorn oder Juve Loop beim Server Statischen Files und ich weiß nicht warum.

Keine Ahnung.

Aber es ist doch interessant.

Mal gucken, ob ich das irgendwie rauskriege.

Werden wir euch weiter informieren, irgendwann am Ende von irgendeiner weiteren Zugnoten-Folge.

Also hört alle unsere Folgen ja bis ganz zum Ende durch, wenn es langweilig wird, nicht schlafen.

Ja.

Dann pick der Woche Jochen.

Genau.

Pick picken würde ich diesmal tatsächlich wo habe ich das gesehen?

Ich weiß gar nicht mehr genau.

Das Ding nennt sich BPyTop.

Ja.

Ah, da, ich habe es hier laufen.

Oh, das ist hübsch.

Das ist ziemlich hübsch, ne?

Ich weiß nicht, ob das Textual verwendet oder Rich oder irgendwas in der Richtung, aber genau.

Hostes oder so?

Rich.

Ja, das gibt einem so ein bisschen Daten zu den, zu, also es ist halt top.

BPyTop?

Ja.

Es gibt da so ähnliche Sachen, Glences gibt es auch.

Ja, Glances gibt es noch.

Also G-Top, Hardtop.

Ja.

Aber das ist mir so letztens über den Weg gelaufen und fand ich sieht echt ziemlich gut aus.

Ist jetzt hier langweilig, der Rechner macht überhaupt nichts.

Ja, das hat keine Last drauf.

Ich picke iJSON.

Ah, okay.

Da habe ich auch noch nicht so viel von benutzt, aber es macht so große JSON-Objekte irgendwie vernünftig.

Hast du noch einen Picker, Janis?

Was genau soll ich denn picken?

Muss das in der beiden Kontext haben?

Irgendwas Cooles, was halt irgendwie, was man vielleicht noch nicht kennt.

Aha okay.

Ich weiß nicht, ob man es heute gehört hat.

Ich habe so eine gewisse Präferenz zu Kafka.

Das, was ich da picken würde, ist Kafka Connect tatsächlich.

Kann man mal nachgoogeln.

Das sorgt letztlich dafür, dass man sich Sachen automatisch aus Datenbanken holen kann, wenn sie reingeschrieben wurden.

Also zum Beispiel Write-Only-Prozesse und die werden dann ganz, ganz automatisch in einen Topic reingeschoben.

Das nennt sich dann Source Connector ohne Code.

Quasi so eine Duplikation von der Realität in der Datenbank in das Kafka.

Ja, wir haben ja über Datenkonsistenzen heute geredet.

Und im Prinzip ist das so ein Ansatz, wie du dir die Daten quasi aus einer Datenbank ohne den Service selbst da beeinflussen zu müssen, rausziehen kannst, in einen Topic schreiben kannst und über einen Sync-Connector in andere Datenbanken reinschreiben kannst.

Und das wirklich cool an der Sache ist, es gibt Konnektoren für alle möglichen Datenbanken.

Also Postgres, Elasticsearch, Neo4j.

Das ist relativ interessant, kann man sich mal angucken.

Ja, das klingt gut.