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.
Hallo Dominik.
Und wir haben einen Gast dabei.
Guten Abend.
Hi Janis.
Ja, das bin ich.
Hallo Janis.
Ich bin der Dominik.
Ich bin der Janis.
Ja, dann Janis, würdest 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 wie immer.
Was hast du denn?
Ja, ich weiß nicht, 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 in der, zuhören
oder dabei sind gerade, die irgendwie davon betroffen
sind. Es gab da so eine Sicherheitsschwankung
bei Okta. Ja.
Ich weiß nicht, wen du meinst, den Betroffenen immer.
Keine Ahnung. Ja.
Ja, also das
ja, fand ich, war mal
wieder so ein... Also Okta ist so ein Multi-Login-Service,
Single-Sign-On.
Ja, genau. Und viele
Kunden, viele Konzerne sind da Kunden und so
und eigentlich war
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,
ziemlich beschädigt jetzt.
Ja, aber ich frage mich, warum das gerade große Unternehmen so leichtfertig 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 auszusourcen.
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 verwalten sollen und die dann immer unsicherere Passwörter nehmen, wenn die ganz viele verschiedene Services auf ihrem Rechner benutzen sollen oder so.
Und dieses Single-Sign-On, da kann man dann, glaube ich,
die Policies vielleicht ein bisschen besser einhalten
und die Leute dazu zwingen, dass sie so ein bisschen mehr darüber nachdenken,
was sie tun. Ja, gut, Single-Sign-On
verstehe ich auch irgendwie, aber ich verstehe nicht so richtig, warum man
dann... Ja, wenn man da keine Kapazität hat.
Stimmt, wenn man das selber machen muss, dann ist es auch wieder
schwierig.
Ja, also das war auf jeden Fall, denke ich,
ein großes Ding, was irgendwie in der letzten Zeit passiert ist.
Ja, ich habe auch für Okta tatsächlich so ein Dango-Modul
geschrieben, mit dem das dann doch irgendwie geht, aber
das ist halt auch nützlich, wenn Okta kaputt ist.
Ja.
Ja, doof.
Ja. Menus.
Dann, ah, oh,
gibt's einen,
wir hatten ja schon mal diesen Tiobe
Programmiersprachen.
Ach, der spannende große Index.
Index, ja, 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,
wie viel das so sagt, keine Ahnung.
Es gibt einen anderen, der macht sowas ähnliches.
Der heißt Peipel, Pippel?
Ich weiß gar nicht, wie der heißt.
Jedenfalls da ist Python auch momentan die
beliebteste Programmiersprache.
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 gibt das ein bisschen mehr
Glaubwü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 immer alles mögliche
um die Marke
drumherum gemacht
und so und
Rechtsbeistand und
solche Sachen für 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 und dann zumindest einen Teil
der Zeit irgendwie dafür zur Verfügung hatten,
sich damit zu beschäftigen. Aber
jetzt gibt es seit,
ich weiß nicht, das ist jetzt schon seit zwei Jahren, glaube ich.
Wird auch verlängert.
Developer in Residence sozusagen. Und zuerst
hat Google den bezahlt. Und das ist ja
Lukas Schlanger. Macht das
sehr gut. Schreibt auch immer wieder
Blogposts, was er so tut.
Und jetzt quasi damit
bezahlt das jetzt erstmals auch Facebook,
was natürlich super ist. Und ja, vielleicht werden
ist ja nochmal irgendwann mehr Leute, also auf jeden Fall
wird es irgendwie mehr Geld, das ist ja schon mal toll.
Voll gut.
Also ich meine, eigentlich denke ich,
dass große Konzerne das ja eigentlich fast wie eine Art
Versicherung sehen können, weil
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 zu stehen kommen.
Das ist halt schwierig, so was zu vermitteln, dass du halt irgendwie
Dinge bezahlen musst, die in der Zukunft
eventuell einen Return on Invest geben und
oder halt auch nur ein Risiko abwenden.
Ja, aber dass das gerade
bei Open-Source, die kriegt man ja immer so umsonst.
Das reduziert ja meistens immer nur irgendwie die Kosten
auf einer Kostenstelle.
Ja, ja.
Ja, ja, das, genau.
Aber irgendwie geht's
da voran, das ist voll gut.
Was hat man noch? Oh, genau.
BugsPython.org,
das weiß ich auch, das ist auch schon seit Jahren.
Versuchen wir da irgendwie zu migrieren auf GitHub.
Ist aber noch nicht, nein, wir haben es verschoben.
Ach so, dachte ich, wir sind durch.
8. April, also quasi
bald, nicht übermorgen,
aber in ein paar Tagen.
Und zwar auf Wunsch von GitHub, weil die gesagt haben,
oh, wir haben Schwierigkeiten,
wir wissen nicht, ob das funktionieren wird,
wenn wir als alle so eine Menge Issues erzeugen und so.
Wartet lieber noch mal ein bisschen.
Okay, ja gut, das ist jetzt 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
das Zeitentrack 20 Jahre geworden.
Das ist auch ein richtiger Meilenstein.
Hätte ich jetzt auch nicht gedacht,
aber das ist natürlich alles
irgendwie,
ja, Zeitgefühl, komische Sache.
Schon ein bisschen abgehangen, wie man alt wird.
Ja, aber Sighten 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 Sighten
daran beteiligt und
ja, tolles Projekt,
irgendwie man schreibt so eine Python-ähnliche
Syntax und das wird
dann halt in C
Cross-Compile sozusagen. Man kann auch C-Funktionen
Direkt laden, glaube ich, wenn man das möchte.
Ja, genau. Und dann kann man es wieder einbinden
als Python-Modul. Und dann gibt es sogar
sowas wie ein Cellmagic
in Jupyter Notebooks oder JupyterLab.
Und da kann man einfach sagen,
Prozent, Prozent, Zeiten. Und dann
wird das halt, wird eine Funktion
einfach so wieder reimportiert.
Und dann wird die halt tausendmal schneller oder so.
Das ist halt sehr schick.
Ja.
Ja, okay. Also apropos, kennst du
V, die Language?
V-Lang? V? Ja.
bin ich irgendwie letztens drüber gestolpert, weil ein Kollege
mich draufbrachte und
habe ich mal geguckt, kannte ich noch nicht, ist nur 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 SICK.
SICK? Das ist auch so ein
toller, lustiger Name, dass das wieder so irgendwann drüber fällt,
aber den Namen direkt 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 lang
I.O.? Okay, muss ich mir auch mal
angucken.
Komplett auch zu zäh, deswegen kam ich
gerade drauf. Ach so,
okay, das ist auch interessant.
Ja.
War witzig.
Ja.
Ja. Okay.
Dann sind wir eigentlich schon fast,
das war diesmal schnell. Ja, wir haben
Ja, dann sind wir damit eigentlich durch.
Achso, haben wir eigentlich
Veranstaltungshinweise oder sowas?
Ja, das sollten wir. Achso, du wolltest
zur PyCon, bist du da?
Momentan 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 das überhaupt stattfindet, also vor Ort,
weil das wäre für mich interessant geworden, aber
nicht vor Ort halt eher nicht so richtig,
weil das schaffe ich eben, das habe ich auch schon mal
probiert, wie Remote aufkommt.
Aber es funktioniert einfach nicht.
Du warst so eine halbe Stunde da und dann so, pa, pa.
Ja, genau. Und dann ist es 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.
Also insofern, ja.
Na gut, wenn es darin lag. Aber vielleicht machen wir auch
nochmal eine Sendung oder so dazu, wie
das da gewesen ist, von Finden noch Leute, die da
waren und dann davon erzählen können. Ja, das wollen die mal fragen oder so?
Vielleicht sind die ja da. Genau, den habe ich schon gefragt.
Er hat sich auch schon gemeldet und weiter eigentlich auch.
Okay, cool. Also gibt es doch irgendwann
eine Pike und Folge. Ja. Ja, im Sommer
EuroPython-Tickets sind auch gerade draußen. Da gibt es
sogar noch welche von, glaube ich. Das war noch nicht so super
angelaufen, der Vorverkauf, obwohl die so schnell
immer weg waren sonst. Genau, da
in Dublin, also wenn ihr mit mir abends
in Dublin ein Bierchen trinken wollt. Da könnte
es auch gut sein, dass ich damit
würde ich gerne machen.
Ich bin gespannt. Und dann gibt es noch
die, also gut, dass es jetzt nicht mehr so
gemeint hat. Das Conference Center in Dublin ist
relativ nah an der Brewdog-Außenstelle.
Das ist ja kritisch.
Ja, genau.
Das Angenehme mit dem Nützlichen.
Ja, super Verbindung.
Genau, und im Herbst, irgendwann
September, gibt es die DjangoCon EU,
diesmal auch tatsächlich vor Ort und in
Porto. Die sollte ja eigentlich letzten beiden Jahren 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 da. Das ist natürlich ein bisschen schade.
Das wäre natürlich nett. Das wäre 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 das schon gehört?
Und diesmal ist Janis dran. Janis darf Werbeblock.
Ich darf Werbung machen, 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?
Elio.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, 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, sage 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 Lieblings-Tool ist, ist das vielleicht auch interessant?
Welches Tool?
Pandas.
Pandas, ja klar.
Sicher, ist ja Data Science, ne?
Ja, Data Science und Python passt natürlich eigentlich schon ziemlich gut zusammen.
Und da kann man dann wahrscheinlich auch remote arbeiten oder so.
Eigentlich sitzt ihr im Bielefeld, sehe ich gerade.
Genau, wir sitzen im 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. Das klingt gut. Also falls
ihr einen Job sucht, dann schaut doch mal da vorbei.
Ich würde mich freuen. Klingt, als wären es nette Jungs
und Kollegen. Mindestens einer.
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. Genau, dann gibt es einen Aktionskurs
Jan.
Schreibe mich an.
Genau, eine E-Mail-Adresse und eine Internetseite
gibt es auch, ljo.de, business.ljo.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
dazu sagen, dass das über
Python-Podcast, dass man sich da das
gehört hat, weil dann kann man das vielleicht so ein bisschen
irgendwie
verfolgen. Da habt ihr auf jeden Fall bessere Chancen,
da wissen wir auch, dass ihr interessiert seid.
Keine Ahnung,
ob das irgendjemand hört,
der 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 ein Projektmanager war, der für ein
größeres Projekt irgendwie gehört hatte,
was da so gibt und der einen Danko-Podcast von uns gehört hat
und dachte so, oh cool, da warst du nicht der Typ mit dem Podcast.
Ja, interessant.
Das hilft manchmal, ne? Also das ist schon cool.
Genau. Ja, schick. Okay. Super.
Hört mal rein. Ja. Wenn ihr was sucht,
wisst ihr jetzt wo. Oder nichts sucht
und doch zu uns wollen, ne?
Man weiß ja nie.
Ja. Okay, genau.
Dann, ja, Thema diesmal
Microservices.
Ja, also ich habe ja wie immer keine Ahnung
und will erst mal, was ist denn überhaupt so ein Microservice?
Ja, was ist das denn? Wer soll das
dann 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 erst mal
etwas, was wenig Sachen macht,
aber dafür sehr gut. So würde ich es beschreiben.
Man stellt es ja ganz gerne
mal so einem 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 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 häufig, wie man das gestaltet. Und der Microservice-Ansatz ist eben, dass man viele einzelne Funktionen in verschiedene Codebasen auslagert mit eigenen Tech-Stacks und ganz wild und ganz toll und hoch skalierbar. Und erstmal ist alles cool in Microservices.
Okay.
Das ist die Meinung von Janis.
Ja, okay.
Da haben wir schon die Seiten geklärt.
Ja, ganz so ist es nicht.
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, Microservices sind quasi eine isolierte Funktionalität.
Genau.
Wenn ich jetzt eine Anwendung habe.
Wir tun jetzt mal so, als wäre es eine Web-Anwendung.
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, das ist Thema Best Practice, sag 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 einzeln anfragen.
Das ist, würde ich sagen, aber keine gute Idee.
Da gibt es dann meistens API-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 ja 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.
Da muss ich halt
ehrlich sagen, ich mach kein Frontend.
Wer liefert denn das Mikrofrontend aus?
Also wenn man zum Beispiel in HTMLX das ausliefert,
dann wäre ein Django ein sogenannter Spinne
oder so ein Aggregator, ein Gabi-Gateway,
wo ich jetzt das Wording da immer nicht ganz
treffen würde, 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. Also was ich mir jetzt halt da kompliziert
darin 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, eine kurze Folge, wenn wir das jetzt
so einfach und so schnell machen. Ein Satz fertig, ja,
danke schön, ja, heute haben wir euch nicht so lange.
Nee, ganz so ist es natürlich nicht. Man muss halt
auch immer sehen, welche verschiedenen Funktionalitäten
man haben möchte, ne? Wir sind jetzt im Bereich
Web unterwegs, ne, von deinem Beispiel.
Das klingt erstmal sehr, sehr einfach,
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 Kurs-Webseite 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.
Also genau, vielleicht einfach hake ich an der Stelle mal ein
und sage mal so etwas, 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 es insgesamt, wenn man es halt getrennt
deployt, dann ist es halt ein Microservice, würde ich
jetzt mal so sagen.
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 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 immer, man sollte
das halt so machen, dass man da quasi
unterschiedliche Sprachen verwenden kann,
dass sie halt möglichst irgendwie
ja, 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 diesen Begriff
Bounded Context und das ist halt immer so das, was man
so, ja, das ist klassischerweise
Bounded Context.
Jetzt musst du wieder erklären, was Bounded Context ist.
Ja, das ist quasi so Dinge, die halt irgendwie so zusammengehören und nur gemeinsam verändert werden sollen. Ich glaube, das Standardbeispiel auch eben aus dem Designbuch 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 streibt es halt in einer Transaktion wieder irgendwie in die Datenbank rein oder so. Und das ist halt sozusagen ein Baune-Kontext eben.
Ja, das 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 Baune-Kontext da dazu oder holt man das aus einem CRM?
Ich glaube auch, dass der Grund,
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
Personen, an die irgendwas geschickt wird
im Kontext einer
irgendwas Bestellung oder
so. Und in dem einen Fall hat man halt da
komplizierte Adressgeschichten und weiß der 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 würde, in dem Beispiel, was du gesagt hast,
braucht man ja irgendwie eine
Wahrheit der Daten, wenn das
ja, das ist dann glaube ich,
dann wird es ein bisschen schwieriger.
Single Point of Truth,
das ist eine Herausforderung.
Also ich sage jetzt mal, das ist eine ganz gängige Frage,
wer leistet man den in Microservices?
Und eine Frage, die damit einhergeht, ist immer das Datenmanagement.
Entschuldigung, dass ich euch gerade direkt einhabe,
aber was heißt Datenmanagement?
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 irgendwie hier AP-Request
gegen irgendeinen anderen Microservice machen,
meinetwegen, und hole von da meine Daten.
Habe dann aber den Nachteil, okay, das ist langsam
und irgendwie kopple ich meine Microservices dann wieder zusammen.
Genau, wenn es hinterher dieselben Datenbanken
liegt, dann ist da die Frage, warum
macht man da eine unterrichtliche Architektur?
Aber vielleicht kann auch das so machen, wenn ich halt irgendwie hingehe
und möchte aus derselben Datenbank
Dinge erzeugen mit unterschiedlichen Sprachen
und die dann... Ja, nicht dieselbe Datenbank.
Genau, und dieselbe Datenbank wird schwierig,
weil dann kannst du es halt nicht mehr getrennt voneinander deployen.
Also wenn du jetzt zum Beispiel auf der, wenn du es in gemeinsamen
Datenbank hast und du änderst die jetzt...
Na gut, er kann ja einfach den Datenbank-Link 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 den anderen.
Hat das ja auch Auswirkungen auf die anderen Services.
Ja, und es ist ein Single-Pointer-Failure.
Also da rede 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 Stoß 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 einfacher ist.
Aber wenn man wirklich Microservices macht und sie wirklich braucht,
dann ist das eigentlich mal eine relativ schlechte Idee,
wenn man sich da doch, wie gesagt, den Single-Point-of-Fail 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 es so schön sagt, 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 die Frage ist,
ist das eine Architekturentscheidung, wenn du jetzt sagst,
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.
Ich stelle das ja so ein bisschen in den Raum dann vielleicht.
Also die Wahl.
Ja, also ich weiß es nicht.
Das ist halt die Frage, ob man, tja, also in der Vorbereitung habe ich jetzt mal so einen Podcast auch gehört, da gibt es irgendwie ein Buch, das immer empfohlen wird zu Microsoft, von Simon Newman.
Und der ist auch in diversen Podcasts schon zu Gast gewesen und der sagte dann dazu quasi so, naja, das mit den Datenbanken ist ja so eine Sache, also wenn das funktioniert, wenn man halt eine Datenbank haben kann und so, 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 nicht kann, gut, weil man halt Microsoft das machen muss, dann okay, da muss man sich halt was überlegen, dann wird es halt schwierig.
Und dann derjenige, der in den Interview hatte, fragte dann halt auch so, ja, kann man denn dann irgendwie was tun, um Datenbanken schon darauf auszulegen, dass man die dann vielleicht trennen kann?
Oder kann man das irgendwie Architektur, ja, das kann man, warum sollte man das tun? 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 Datenbankschema anfangen?
Genau, ja, aber das würde ja nicht für Microsoft versprechen,
sondern für einen Monolithen 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,
warum man das macht.
Also, das heißt, ich würde das auch so intuitiv sagen,
du baust halt jetzt einmal dein Deployment
für ein Tool, für eine Web-Anwendung
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, Microsoft wäre jetzt eine gute Idee
oder das behilft mir irgendwo bei?
Das ist unterschiedlich.
Vielleicht erst mal 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.
Nee, gut, aber du hast ja dann das Problem.
Du hast ja eine verteilte
Datenhaltung, wo du nicht einfach einen Join
machen kannst, sondern du musst dann halt...
Ja, klar. Also das Datenmanagement selbst,
das ist wesentlich komplizierter geworden.
Aber die Datenhaltung pro Service, die ist immer noch
relativ einfach. Und das muss man
halt ganz klar sagen. Also die einzelnen
Microservices in sich, die sind unglaublich
einfach. Wenn du zum Beispiel
Monolithen hast, und da kommen wir direkt zu deiner
Frage, die du gestellt hast. Ein Monolith, der 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 einzelne Services aneinander
und du hast dann auf einmal teamübergreifende Bugs,
meinetwegen, weil du eine gemeinsame Code-Basis hast.
Dann denkt man schon relativ schnell bei Microservices nach.
Okay, aber das klingt jetzt so,
als wären die Apps jetzt nicht so gut getestet im Staging oder sowas
und als würden jetzt Dinge, die halt eine Seite kaputt machen,
andere Apps kaputt machen.
wenn man jetzt beispielsweise in Django-Apps jetzt
denkt, ja, wenn man das parallel
entwickelt, dann könnte man die ja voneinander
trennen, also. Im besten Fall
tut man das, ja, das ist dann.
Also wenn die sich gegenseitig differenzieren, kommt man natürlich in
so ein Dependency-Problem vielleicht,
aber. Ja, ja, ich glaube, also
ich meine, das ist auch
immer was, wo
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, dann
sondern halt ein bisschen modularisieren, kein Problem.
Das ist aber tatsächlich sehr schwierig.
Ja, 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 man kann da schon was tun und man kann das richtig und falsch machen.
Und meistens machen sie es total falsch.
Und das, die allerschlimmsten
Geschichten sind dann halt, oder wenn man es halt
verteilt falsch macht, das ist halt
ja, insofern, ich bin
auch so ein bisschen immer
also 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, das
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
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
und das passiert leider
sehr oft.
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
beziehungsweise innerhalb seines Codes Referenzen hat,
dann hat man die ja automatisch nicht mehr nur,
wenn man auf einmal Microsofts verwendet.
Man verlagert das Problem.
Aber ich sage jetzt mal, man macht die Sache halt,
die Code-Basis 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, RabbitMQ, Kafka, irgendwas rumliegen, irgendeine Queue, 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 Parallellaufendes, 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 Socke-Verbindung aufmachen zu einem Kafka oder einer anderen Q?
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 vorhabe.
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?
Und 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 an Problemen sehe, 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 dann wieder aggregieren, wo du das vom API-Gateway sprachst. Also wenn ich diese Spinne im Netz sein will, die halt die Informationshoheit hat, die die Single Source of Truth irgendwie bereitstellen möchte.
Aber 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 aus meiner Seite, das muss halt eigentlich
auf deren Seite dann getestet sein. Das heißt, ich
gebe quasi die ganze Verantwortung
auch weg. Ja, du hast natürlich
sehr viel, du hast wahrscheinlich wesentlich mehr Integration-Tests
erst mal, 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 es 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 komplizierter in der Microservice-Welt.
Ja, also 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 Logfiles rauspasst oder irgendwie.
Du musst überhaupt mit sowas erstmal anfangen und wir haben das
möglicherweise eben noch nicht. Das ist auch
das erste Projekt, was er vorschlägt,
wenn man sich dann tatsächlich doch mal dazu durchgeguckt hat,
das dann zu machen.
Ein gutes Startprojekt ist halt zu sagen, okay, da machen
wir doch mal irgendwie
als ersten Microservice irgendwie
zentrales
Logmanagement.
Weil das ist halt relativ
einfach. Das ist eigentlich nicht so schwierig.
Aber man muss halt trotzdem
irgendwie Sachen
irgendwo hindeployen können und man hat unterschiedliche
Sprachen, man muss es irgendwie
konfigurieren und diese ganzen
unterschiedlichen Aspekte
irgendwie müssen alle zusammen 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 Organisationsproblem,
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 deinen Log-File sehen kannst
und gucken kannst, was passiert ist, über
deine unterschiedlichen Services hinweg.
Und das musstest du vorher vielleicht nicht.
Also das meinte ich mit dem Hut auf Farben,
ich musste halt immer irgendwie so ein Admin haben oder so.
Naja, also ich meine, du hast dann
ein Ding für Log-Geschichten, du hast aber
vielleicht auch ein anderes Ding für Monitoring, du hast
wieder ein anderes Ding für, weiß ich nicht,
dein Live-Dashboard
oder so, das müsste ja jetzt nicht alles das
gleiche sein.
Aber 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
in der Bar getragen werden.
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 Metric-Monitoring.
Das sind ja alles standardisierte
Ansätze, die du relativ einfach in deiner
Services einbauen kannst. Also File-Bit-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 einfachen Zugang zu seinen
Logs 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 Logs
kommt 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 ja mal noch kurz den Elk-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 dem
gar nicht so viel, das ist irgendwie Elasticsearch
halt, um die Logfiles durchs Ufer zu machen.
Das ist halt Kibana
Dashboard.
Genau, und
was gehört da noch dazu?
Logstash.
Vielleicht auch, um das zu beschreiben,
du kannst in Python zum Beispiel, schreibst du
deine Logfiles in Files und dann kannst du dir die mit
Filebeat Richtung Logstash
schicken. Das ist einfach nur ein weiterer Service.
Der sorgt dann letztlich
einfach nur dafür, dass die Logs, die du
schreibst, Richtung Elasticsearch gehen.
und entweder du hast da noch ein Logs-Dash 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 Felder 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 Clicky-Bunty deine Logs durchsuchen
und dann hast du deine Graphen, kannst dir auch Dashboards bauen.
Ja, Kibana ist super.
Freitext-Suche, das ist sehr schön.
Ja.
Macht Spaß.
Okay. Ja, ich sehe es auch tatsächlich, also wenn du sagst, in der Organisation irgendwie muss doch jemand, ich denke, das ist halt eines der Ziele bei dieser ganzen Geschichte, gerade wenn man es bei größeren Organisationen sich anschaut, die haben oft das Problem, also wenn man sich jetzt anguckt, was machen denn Firmen vorher oder was machen die normalerweise anders, wenn sie nicht Microsoft machen, dann machen sie meistens so eine, also ich würde sagen, Microsoft versucht das ganze Problem,
die Problemdomäne 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 Microservices
halt eher vertikal, das heißt pro Projekt irgendwie
oder pro
eine 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, genau, dann stehen
sie halt gegenseitig auf den Füßen unter Umständen.
Also du hast dann vielleicht halt eben schon
ein
Datenbank-Team
oder so, wo sich die 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
irgendwie Replikas
von irgendwelchen Datenmarken hochziehen können und die Daten
da und so weiter.
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
in der Tabelle. Und da ist jetzt eigentlich
nichts, was so sonderlich schwierig ist. Vielleicht
sollte man sich überlegen, ob man das dann machen will oder nicht oder keine Ahnung,
aber letztlich das zu tun ist gar nicht so schwer
und dein Datenbank-Team ist
jetzt zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt
oder 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
irgendwie mit sehr simplen Geschichten
oder
du kannst die nicht auslasten,
weil
die halt
oder du kannst halt
mit deinen Projekten nicht weiter, weil die halt mit
irgendwelchen anderen Kram ausgelastet sind.
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
im Grunde dafür zuständig, das komplett zu deployen
in 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 mit dem 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 ja sagen können,
nee, wir releasen, das ist uns wichtiger und dann,
oder wir deployen jetzt und dann machen sie das halt einfach.
Das wäre Kraut und Rüben.
Ja, aber du bist halt unter Umständen schneller.
Und ich finde, in einer Firma
gibt es das auch sehr schön,
sowohl 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
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, 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
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 zu
bedienen, weil ich nie Sachen
finde und immer
suchen muss nach Sachen und so.
Naja, also auch die Konfiguration, wenn man das irgendwie automatisiert,
ist ja 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 einem das Leben halt echt schwer.
Und ja, aber
ich glaube, das sind halt so Trade-offs, da muss man
sich entscheiden, ist einem die Konsistenz wichtiger oder die Geschwindigkeit?
Ja.
Naja, naja.
Wenig Begeisterung für Microservices
habe ich das Gefühl. Ja, ich weiß nicht, also
Ich habe noch nicht so rausgefunden, wofür ich
dann jetzt ein Microsoft gut
einsetzen könnte. Also wenn ich mir jetzt vorstelle, ich möchte
jetzt irgendwie so ein Projekt implementieren,
irgendwie so eine gewisse Größe und dann
muss ich
ja, wie du, Jörg, so schön
sagst, 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, erst mal
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 kein
Microservices auf. Aber habe ich meinetwegen
20, 30, 40 Mitarbeiter,
das macht schon super viel Sinn, da über Microservices
nachzudenken, weil ich kann jetzt
eigene 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, ich bin nicht im Frontend
drin, ich persönlich. Also ich halte mich
davon so weit fern wie nur möglich
und so Backend-Prozesse,
da sind so Guidelines total egal.
Nein, aber ich versuche jetzt wirklich nochmal von diesem Management-Layer von oben das mir anzugucken, weil du hast natürlich recht, wenn ich jetzt ein Konzern habe mit 100.000 Mitarbeitern, dann macht das vielleicht Sinn, die Teams zu verteilen auf ihre einzelnen Kompetenzen, die sie haben, die in unterschiedlichen Ländern so 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 drin.
Genau, aber ist die Frage, erschlage ich das dann mit irgendwelchen Prozessen? Weiß ich nicht, das macht es ja nicht besser. Dann habe ich den Vorteil von Microsoft, das habe ich dann nicht mehr, weil dann muss ich durch so ein Prozess-Gateway durchkommen und habe dann einen Doorkeeper nach dem anderen.
Ja gut, aber auch um auf deine Frage zu kommen, die Frage ist dann 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 backen beide ihren eigenen Kuchen, dann ist es 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 deployed ein 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 ja vielleicht irgendwas überlegen. Aber das habe ich jetzt noch gar nicht so gehört, als dass es ein Riesenproblem ist.
Was aber schon ein Riesenproblem ist,
wenn du jetzt
so etwas hast,
ich weiß jetzt nicht, was das Beispiel war,
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 und 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 über die Produktion, wenn du derjenige bist,
das produziert und das dann verteilt an Unternehmern.
Das ist genau das, was ich meine.
Ja, das ist der Nachteil, das geht halt nicht mehr.
Aber das ist ja das, was
ich zentral, das sind wir vielleicht wieder,
was man bei Single Point of Truth irgendwie
überschreiben kann. Das ist eine Herausforderung.
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
die Steuerung...
Es ist halt die Frage, also es geht halt manchmal,
ich meine, ich kenne es halt zum Beispiel
als zweitgrößte E-Commerce-Konzer
in der Welt. Wisst ihr, wer das ist?
Hm? Nach Amazon?
Otto?
Ja, das ist Otto.
Aber tatsächlich, ich weiß nicht mehr, ob das
noch stimmt. Es kann sein, dass
AliExpress oder so
größer ist.
Oder Alibaba.
Aber Otto auf jeden Fall sehr, sehr
groß. Und damals,
das ist jetzt aber auch schon wieder lange her,
hatten 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 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.
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 wie kriegen die ganzen Microservices wieder alle zusammen?
Ja, und die Antwort ist eigentlich
gar nicht.
Ich glaube, da kommen so Leute auf die Idee wie
Data Lake wird dann eher Data Swamp oder so.
Irgendwas zu sichern.
Das schlimmste Problem
ist gar nicht unbedingt die technische Lösung,
sondern das schlimmste Problem sind halt die
politischen Geschichten, die du halt auch kriegst automatisch.
Dass halt Leute sagen so,
wir haben hier gerade
einen Vorteil, die sind ja untereinander im Wettbewerb,
wir haben hier gerade einen Vorteil, weil
wir irgendwas wissen, was die anderen
nicht wissen und jetzt sollen wir die Daten,
das, was uns dazu verhilft,
dass wir irgendwie besser sein können, als
wie unsere interne Konkurrenz, da sollen wir
den jetzt irgendwie freiwillig zur Verfügung stellen?
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 gordischen 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 consulten, kannst damit Geld verdienen
und dann geht es halt immer aus und zusammen.
Ich meine, das macht natürlich auch Sinn. Also wenn du irgendwas
hast, was total verfilzt ist, dann musst du das
erstmal auseinanderspalten, dann hast du kleine
einzelne Services, die untereinander
so ein bisschen Wettbewerb haben. Die guten Sachen
musst du dann irgendwie wieder konsolidieren und zentralisieren,
um dann wieder den guten Benefit rauszubekommen.
bis du dann wieder merkst, das ist wieder doof, dann fängst du wieder an, das auseinander
zu dröseln. Das ist ja genau wie bei den Ländern.
Mal sind Länder werden zusammengefasst, dann werden die
auseinander. 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 das überhaupt irgendwo.
Dann muss ich hingehen und 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 das vielleicht ein Tag alt
oder so oder eine Woche, ist ja egal, aber da sind
die Daten sind einigermaßen echt und da habe ich
einen Vollüberblick über, was da 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, oder du kannst auch überlegen,
ob du nicht schon im Vorfeld einen
einen gewissen Standard etablierst, wo du sagst,
da sind wir wieder beim Standard natürlich.
Und bei den Gateways.
Nicht nur bei den Gateways. Ich bin
im Backend. Ich interessiere mich nicht so für die...
Ja, doch, auch. Ja, mein Problem ist da bei der
Gatekeeper. Ich musste gerade, weil du gesagt hast Standards,
musste ich an Infrastrukturstandards denken.
Und auch daran, 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, ist es für mich ein vertretbarer
Aufwand, das zu gewährleisten, meinetwegen.
Das fängt ja schon bei anderen Sachen an,
wie, keine Ahnung, jeder Dev kriegt ein Windows-Laptop
mit AD zugefroren.
Aber das hast du ja nicht.
Genau, das willst du nicht machen.
Das ist nämlich der Punkt, weil wenn du Microsoft was 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, also 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 Hut aufhaben, wird das
so nicht funktionieren. Sonst wird nur dann funktionieren,
wenn ich Verantwortung abgeben kann.
Ja, dann nimmst du einen Microservice.
Aber da hast du ja schon eine Antwort.
Also willst du den Hut aufhaben, 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 sogar in Microservices, wer weiß.
Oder willst du die Verantwortung abgeben,
dann kannst du einen Microservice nehmen.
Die Frage am Ende ist, wenn du einen riesen Konzern hast,
hat da überhaupt noch jemand den Hut auf?
Egal, welchen Ansatz du nimmst.
Die Frage im Konzern ist dann ganz einfach.
Auf welcher Kostenstelle wird denn das gebucht?
Und wer hält dann dann wo die Hand auf?
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 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, ist eigentlich ein total simples
Problem. Nehmen wir an, du hast halt irgendwie
früher, du hast halt
Entwicklung und
Betrieb oder
IT und Operations oder weiß ich nicht
und dann auf der anderen Seite Entwicklung. Und das ist vielleicht auf
unterschiedlichen Seiten deiner Bilanz
auch. Das eine sind dann halt
Kosten und das andere sind halt Investitionen.
Ja, so dann hast
du halt irgendwie, siehst du halt
wenn da Features entwickelt werden, siehst du das als Investition
und denkst halt, je mehr Features
entwickeln werden, voll gut, gibt mir in der Zukunft
mehr Einnahmen, total super.
So, das heißt
irgendwie deine Entwicklung misst du daran,
wie viele Features kriegen die eigentlich pro Quartal irgendwie raus
oder keine Ahnung, irgendwie sowas.
Dann geht das Ganze in den Betrieb.
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, kriegen nicht mehr Geld dafür,
dass sie halt dafür
sorgen, dass die Entwickler mehr Features veröffentlicht werden.
Was ist deren
rational
beste Strategie in diesem
Setting? Ist halt tatsächlich zu sagen,
never change a running system.
Ja, irgendwie.
Ich werde nicht belohnt dafür.
Ich bin ein Kostenfaktor. Ich werde nur bestraft,
irgendwas nicht geht. Ja, solange das Wasser läuft
und der Strom an ist, alles gut.
Sobald der Strom ausfällt, kriege ich
ein 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 ist ja ehrlich gesagt nicht mein Problem.
Ja, so und dann, das ist halt etwas, in das Unternehmen dann halt früher oder später irgendwann reinlaufen und überlegen sie sich, wie sie damit irgendwie umgehen, dass das jetzt irgendwie problematisch ist und das halt irgendwie, das ist halt ein Maß dafür, ja, man sich fragt so, also dann macht man dann ein 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 viel 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 ja 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 in den Bereich zu packen,
der halt davon profitiert,
wenn was deployed wird. Ja, mit in den agilen Sprint
das zu packen. Genau, genau,
Agile, auch so ein Ding, wo man sagt, okay,
genau, packen wir das alles
zusammen. Ja, oder
halt eben DevOps, wo man sagt, okay,
die Leute, die das deployed
haben wollen, deployen es dann halt auch selber und betreiben es auch selber.
Der DevSecOps jetzt, ne?
Okay.
Fullstack-Microservice
DevOps
im agilen Prozess,
ja, die haben wir alle zusammen, glaube ich,
weiß nicht, aber ja,
Es geht halt darum,
dass einzelne Teams halt möglichst autark
Dinge machen können.
Dass man halt sozusagen da, wo man investiert,
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
man wird dann halt schneller und so, aber man wird
eigentlich automatisch halt inkonsistenter dabei.
Ja, das Problem ist, wenn die Leute aneinander ziehen, wenn es halt dann so einen PM-Layer dazwischen gibt, der dann in verschiedenen Schrauben zieht, also auch politisch zieht, weil es um Kostenstellen 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, Microservice ist 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.
Äh, 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, dass eine schlaue Art
irgendwie, wenn man jetzt migrieren wollte
von Modulit auf Microsoft, wäre halt,
man fängt halt klein mit kleineren Teilen an
und macht das da und man macht nicht alles auf einmal.
Weil das wird wahrscheinlich nicht gut
funktionieren.
Warum im Haupt? 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 die Devs alle dann an eine Stelle kommen,
dass sie sich alle gut verstehen,
dass sie alle dieselbe Tech-Sec benutzen,
dass sie die Infrastruktur standardisiert benutzen,
dass sie nur die standardisierte Infrastruktur benutzen, keine andere.
Und dass halt dieses ganze Distributed-Quatsch, Entschuldigung,
dass alles weg ist.
Ich kann ja von mir verschiedene 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,
so ein bisschen zu managen, weil ich habe halt
das Problem, wie Jochen gerade sagte, dass
hochspezialisierte, hochgutbezahlte
Spezialkräfte sich teilweise um trivialen
Tries kümmern müssen, bis die Sachen
halt mal integriert sind.
Aber dafür könnte man ja einen Service schreiben,
also keinen Microservice, sondern
einen, der halt in den Monolithen drin hängt.
Ja.
Also ich, ganz grundsätzlich,
ich habe so ein bisschen das Gefühl, du bist so ein bisschen
biased.
Das ist mir eine spontane Meinung.
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 überall zu finden für alles.
Wenn du eine große Firma bist, dann hast du vielleicht irgendwie einen Java-Entwickler,
der ist Querensteiger in Python oder C-Sharp in C++, 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 Tech-Stack überhaupt, will ich den überhaupt haben, bringt er mir überhaupt was.
Ich sag mal so, also es gibt halt so wenig gute Leute, dass man wahrscheinlich schon Tech-Stack multiplexen muss, damit man überhaupt genug Leute findet.
Ah, siehste, also Microservice, nein.
Aber grundsätzlich musst du dir ja auch die Frage stellen erstmal.
mal vielleicht, um von dieser Ebene
mal ein bisschen zurück zum Code zu kommen.
Ein Monolith, der hat natürlich eine riesen
Code-Basis, die unter Umständen relativ komplex ist.
Das heißt, du musst viel Aufwand in den
Deployment-Prozess an sich stecken.
Also bist du ein einzelnes
Feature, ein neues Feature deployst oder ein Bug
fixt, 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 Produktionen durchrutscht, dann ist
im Zweifel raussteigend ganz das System ab und hat eine Daumentime.
Genau, der Monolith ist so ein klassisches Beispiel für Single Point of Failure, auch das kannst du irgendwie umgehen, du hast ein Backup-System, du hast das parallelisiert, was weiß ich, also du kannst die Chance minimalisieren, dass du genau an solche Punkte läufst, mit Rollback, mit AB-Tests und so weiter, also du hast eine 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 lang rumliegen, weil zu viele Leute…
Acht, neun Stunden dauern, dann denken die natürlich so, hm, wenn ich so zwei, drei am Tag rausschrauben will, dann ist 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 auf einmal was um. 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 wir reden über große Code-Basen. Also das muss man halt immer erwähnen. Wir reden über große Teams. Und niemand kennt den ganzen Code. Also was bringt dir ein einheitlicher 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 einer Django-Anwendung und du nutzt jetzt kein Vue.js oder sowas, sondern du schreibst irgendwie dein Frontend-Code in die Django-Anwendung rein als 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, aber das verhandelt natürlich das Problem so ein bisschen, dass dieser Entwickler nicht den ganzen Stack kennt und auch überhaupt nicht kennen muss.
Ich freu mich halt, ob das
einen Unterschied macht.
Also ist ja egal, ob jetzt jemand an seinem Feature-Branch
irgendwie eine App baut.
Süßer, wenn es keinen Unterschied macht,
ist es doch doppelt egal.
Nein, aber das ist ja dann
trotzdem im Monolithen.
Ja gut, aber mindestens
habe ich Komplexität raus.
Sowohl im Code, Microservices 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 von der Wand aus Guidelines und Jira-Pages und was weiß ich.
Der gute Jira.
Genau, aber du steigst nicht irgendwie komponententief in den Code rein, musst du auch gar nicht.
Du kommst gar nicht erst in die Versuchung.
Also du hast auf jeden Fall erstmal ein bisschen Komplexität auf Code-Ebene entschlankt.
So durch Microsoft und vielleicht auch durch Deployment-Ebene.
Und du hast das Risiko erstmal minimiert, dass du es verhaust.
Und du behinderst niemand anderen damit.
Also du deployst halt in einem Monolithen immer nacheinander,
wenn du verschiedene Teams hast.
Dann deployst du erst Team A, Team B.
Dann 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.
In meinem Kopf, da ploppt gerade wieder aus,
wenn ich das dann warten möchte und wenn ich das ausbauen möchte,
wenn das Team weg ist, was diese Microservices entwickelt hat,
dann muss ich ja wieder Experten suchen,
sich dann mit dem anderen Tech-Stack auskennen,
den 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 auch
ein Microservice austauschbar sein.
Ja, okay. Das heißt,
das ist ein Wegwerfding. Das heißt, wenn es nicht mehr läuft,
dann würde ich halt jemand aus einem anderen TechSec den gleichen
Microservice neu bauen irgendwie und das dann günstiger
hat, 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, das ist klar, dass Situationen
in den Microservices 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
also genau, also ich meine, das ist halt hier die
Frage, gibt es irgendwie einen Grund, warum man das machen
sollte, der
was ich dann, was der
der Autor von dem Buch da meinte, ist
naja, eigentlich eher so, Microsoft
das macht man halt dann, wenn sonst nichts mehr
funktioniert, also 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
natürlich 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, es wird nicht
live, das, was wir machen, dann
geht es halt vielleicht nicht anders.
Wir können vielleicht auch sogar
in Richtung Use Cases gehen. Ich meine, wir hatten
ja schon Beispiele, Bestellservice meinetwegen oder
IoT wäre auch noch so ein Bereich, wo es
prinzipiell durchaus auch
natürlich wirken kann, Microservices 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 ja 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 diesem Beispiel 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 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.
Da müssen wir uns überlegen, gut, wie verwalten wir den ganzen
Spaß eigentlich? Eignet sich da fü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 verwurschtelt habe. Und da muss ich
überlegen, gut, wie gehe ich jetzt damit um?
Also
normalerweise sollte
das gar nicht so viel langsamer werden, oder?
Weil du kannst ja eigentlich...
wenn du schreibst, klar.
Aber gut, oder ich meine...
Also zum Beispiel Postgres lockt jetzt dann nur
die Zeile, wenn du schreibst. Und wenn du jetzt ein neues
IoT hast, dann hat der eine neue Zeile drauf. Das heißt,
der Nutzer, der kann ja alle anderen Zeilen zum Beispiel lesen.
Ja,
also ich meine, das kann
natürlich schon passieren. Das kann natürlich schon passieren, dass
Schreibtlast irgendwann irgendwie
dein System langsam macht.
Aber meine Frage wäre halt ja, wie häufig kommt
das denn vor, dass man so skalierbar...
Also ich würde sagen, ja, es gibt einen validen Grund,
Microservices aus Skalierbarkeitsgründen
einzusetzen, aber wie häufig kommt denn das vor?
Es kommt vor.
Was wäre denn jetzt die Lösung davon?
Dann habe ich Sachen, die IoT schreibt in eine Datenbank
rein und dann habe ich ja
den Flaschenhals bei dem Prozess,
der von der einen Datenbank in die andere Datenbank
das ü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
und dann schreibe ich das in eine Datenbank,
die extra dafür vorgesehen ist.
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.
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 und 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 Ticketsystem 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.
Wo er generell hochskalieren muss.
Ja, aber gut,
da wäre halt die Frage, was ist
ja, also ja, ist alles
valide,
aber was ist teurer, irgendwie
die Architektur aufzuteilen
oder irgendwie einen von dickeren Server zu kaufen?
Ja, aber auch
da gibt es so sehr, sehr schöne Graphen,
das ist 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
geradlinig.
Ich gestikuliere hier immer so rum, aber es ist ja Podcast.
Erstmal steigt das
relativ geradlinig, also irgendwie
F von X gleich X, 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 sein. Also ich finde,
das Problem, was du gerade gesprochen hast, müsste man eigentlich noch mal
mit Leuten, die noch ein bisschen mehr Spezialwissen
in Datenbank haben, sprechen, weil
für mich hört sich das nicht so an, als wäre da der Flaschenhals
an der richtigen Stelle.
Deswegen würde ich sagen, 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 ein extra Layer,
wenn ich jetzt einen Kafka dazwischen mache. 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
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, wenn du was schreibst,
nein, nein, das ist ja...
Nee, ja, nur beim Lesen,
nicht beim Schreiben. Doch, beim Schreiben auch.
Doch, das wird dann 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.
Und das
ist, das macht Postgres
unfassbar viel langsamer als sowas wie Redis.
Aber bei Redis ist halt auch, wenn du
dann, wenn du das Ding ausmachst, dann ist
die Daten sind halt weg. Bei Postgres
nicht, da 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.
Wenn dir der Datenmarkt sagt, deine Transaktion ist durch, dann ist
das wirklich in der Platte gelandet. Ja, aber das macht aber die Postgres nicht
langsamer, sondern das ist halt nur so, dass das
nur schreiben 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 Hauptschweiger
sind, ja? Sagen wir so. Ja, genau. Also die, die noch nicht
auf der Platte sind, die kannst du nicht lesen,
aber das heißt ja nicht, dass du nicht die Sachen, die vorher drin
sind, lesen kannst, weil die Transaktion von den Sachen, die noch nicht geschrieben
wenn es noch nicht fertig ist. Das heißt, dass du den
Stand der Schreibdachlichkeit, das heißt aber nicht, dass das Lesen
langsamer wird.
Ja, letztlich schon irgendwann.
Nein, das ist ein eigener Prozess.
Das ist völlig unabhängig davon.
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 lest du ja eh noch aus dem Speicher.
Das ist ja egal.
Das I.O. ist ja nur das CPU.
Wenn dein Working-Set 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 dein
Konzept ist, ist dann die CPU-Kerne, die halt
damit beschäftigt sind. Wie viele
Prozesse du offen hast, also das heißt, wie viel Gleichzeit
in der Verbindung, die auf deiner Datenbank stehen.
Ja, also sagen wir mal so,
in der Praxis, das, wo dir
häufig das System platzt,
ich sag mal so, also das ist ja so erfahrungswert aus der Praxis,
das, wo du dann merkst, okay,
ich hab hier ein Problem, wo ich irgendwie
mit der Architektur anfangen musst, was zu machen,
ist, dass irgendwann
deine Slaves mit der Schreiblast
nicht mehr klarkommen. Also deine Replikas.
Wenn du das nicht mehr
hinkriegst, wenn dein Replikations-Lag
immer größer wird, weil du das nicht mehr
weggeschrieben bekommst, was du an Schreiblast hast.
An dem Moment hast du ein Problem
mit deiner Architektur. Da musst du das sowieso
aufbrechen, ob du dann Microservice machst oder
also 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, Master Slave, ja. Genau, das
kannst du dir dann überlegen, ist beides schrecklich
und macht dein ganzes Datenbankmodell
im Grunde kaputt und inkonsistent, ja.
Also das, aber das kannst du dir dann nicht mehr aussuchen.
Ja, aber du machst das Slave-System mit so einer Postgres,
dann hast du dann, wo die darin 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.
Dann ist es einfach 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 die später
nochmal ab. Die Frage ist natürlich, wie langsam
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 bis zu so und so viel Speicher soll vorgehalten werden oder so und so lange und dann kannst du die erst wegschmeißen und du musst auch überlegen, brauche ich alles, brauche ich alles, alles oder.
Du hast halt eine Latenz dann, ne?
Ja, nicht nur Latenz, 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 schlimm, 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 das Replikations-Lag, wie Jochen sehr schön gesagt hat, das wächst und wächst und dann stoppst du halt eine gewisse Zeit lang mal den Schreibprozess und hast dann meinetwegen ein Consumer-Lag 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 da gegeben haben, damit das ein Problem wird?
Keine Ahnung, das muss man schon ganz genau sagen.
Kommt drauf an, wie du das machst und wie in paar Firmen du am Ende auch arbeitest.
Ja, aber letztendlich, also diese Art von Problemen hast du natürlich immer, also Chris Künthopp, der hat das mal 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 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 er sagte das mal sehr schön,
jetzt die Leute irgendwas machen und du schreibst halt
Sachen, also OLTP ist zum Schreiben gedacht
und OLAP eher zum Lesen.
So, wenn die jetzt irgendwie die ganze
Zeit irgendwie diese Geschichten generieren,
dann, also im Grunde, jede OLTP-Datenbank
hat in sich so ein
Data-Warehouse, das raus möchte.
Irgendwie von einer gewissen Zeit.
Das fand ich gerade ein sehr schönes Bild. Ja, das ist halt so.
Irgendwann willst du das halt vielleicht da raustrennen.
Ja.
Aber spannend.
Also, dass es dann doch wieder um Datenbank
ging am Ende, bei der Frage,
ob man Microservices an der Stelle macht oder nicht.
Nein, das weiß ich ja gerade gar nicht.
Aber es kann doch sein, dass die Datenhaltung,
da haben wir ja auch fast mit angefangen, dass das Datenmodell,
die Datenhaltung dafür sehr relevant ist.
Das ist einfach ein Problem, 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 habe jetzt meinetwegen eine 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 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.
Ich meine, das ist jetzt
rückt. Sehr, sehr schöne
Wendung. 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.
Das ist halt mehrere Trade-offs.
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-Monolithen
rein oder stellst du deinen Service daneben?
Nimmst du den hoch
und versuchst du das vielleicht zu
integrieren. Das Problem, welches dann natürlich
aufkommt, wenn du von Monolithen kommst,
ist, dass du von einer
konsistenten Struktur unter Umständen in eine
inkonsistente reinläufst. Ja, du kannst vielleicht
gar nicht warten. Du musst halt immer wieder auf das externe Team
zugreifen. Ja, es muss ja nicht mal ein externes Team sein.
Das kann ja auch ein neues internes Team sein.
Oder dann halt intern.
Klar, dieses Problem hast du dir
jetzt geschaffen. Das ist irgendwo ein selbst geschaffenes
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
würde ich auch so sagen, also ich denke auch,
Es gibt gerade, also wenn man halt ganz viele Leute hat und das sehr groß wird, dann wird Microservices immer attraktiver irgendwie. Aber auf der anderen Seite, das ist halt irgendwie jetzt heutzutage oft irgendwie so, das macht man halt so und das ist halt jetzt so ein bisschen, da würde ich mir denken, na ich weiß nicht.
Und da gibt es ja auch so einen schönen Begriff von David Hanemeyer-Hansen,
den Rule-and-Rates-Menschen, der versuchte, den Monolith-Begriff 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,
dann ist halt das unter Umständen halt deutlich effizienter.
auch einfach was bauen willst.
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 null ein 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.
Dann bist du halt jedes Mal noch einen neuen Klotz ans Bein irgendwie.
Oder auch noch weitere Komplexität und weitere
Abhängigkeiten und Dependencies, wenn du
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 engem 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 Microservices. 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 da rausnimmst 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 dazugebucht für diesen Service, weil es vielleicht günstiger ist, weil es vielleicht leichter zu machen ist. Dann ziehst du einfach parallel noch eine Node hoch. Das wünscht man sich ja auch manchmal. Und das ist zum Beispiel ein Microservice, ist einfach natürlicherweise leichter als ein Monolithen.
Ja, werden wir ein bisschen
positiver. Ist auch schön.
Ja,
nicht negativ, also es geht halt so ein bisschen
darum, wann das der Fall ist, an welcher
Use Case dann wirklich dafür
sorgt. Also ich denke auch, wenn man das
dazu bringen will, dass es
also ein
Ding, wie das helfen kann, wenn man jetzt
drüber nachdenkt, denke ich,
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 Moduliten und
der notifiziert irgendwie User
für irgendwas und
jetzt möchte ich das da raustrennen,
weil irgendwie dieses ganze
Handling von unterschiedlichen
Wegen, wie 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 Funktionen, also irgendwie
einen JSON- oder HTTP-API irgendwie jetzt
vor die Funktionen, die die Notifizierung macht,
zu klemmen und das halt auf einen anderen
irgendwo anders hinzulegen und dann rufen
halt aus einem 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
über einen Microservice geht
und wir können
das halt auch hinterher gucken,
dann machen wir das Ganze hinterher in 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,
oder wir schicken es gar nicht raus,
wir gucken einfach nur, 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 ordentlich Interfaces
hat, dass man das irgendwie schon
halbwegs gut strukturiert hat.
Und ja, dann
ja. Und das ist vielleicht auch so eine Möglichkeit
dann an der Stelle nochmal irgendwie drüber nachzudenken,
wie modularisiert man eigentlich
ordentlich? Ja, auf jeden Fall.
Ich meine, auch
um noch eine positive weitere Sache
aufzugreifen, die mir gerade in den Sinn kommt.
Und 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.
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 gestalte 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 Queues und Topics
und dann schickst du da ein Event hin
und dann ist das so ein Write-Only-Ding.
Dann schicke ich diesen einen Datensatz an 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
ein Async bei mir im Code einbauen musste,
um das darzustellen.
Und der Nutzer, der kann sofort weitermachen.
Der muss nicht unbedingt auf die Antwort warten,
wenn das ein Write-Only-Prozess ist.
Auch ein Vorteil.
Oder auch sehr schön teilweise zu designen.
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 sowas,
ja,
wo man dann vielleicht mal drüber nachdenken kann,
wie strukturiert man die
Applikationen eigentlich so, dass das halt irgendwie
so funktioniert.
Ja, weil, ja.
Es ist halt saukomplex, ne? Also das muss man halt
einfach sagen. Braucht man diesen
Service-Bus oder diesen Message-Queue oder diesen Message-Booker
dann halt. Und wenn man den halt hat, raucht man
ihn, will man ihn.
Also, weil das ist ja auch
die Dependency, die musst du ja auch dann wieder
mitnehmen. Ja, klar. Ist das eine Dependency?
Du brauchst die Kompetenz, ne? Das ist halt immer so das Ding
mit der Komplexität. Aber
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 den aktiven 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 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.
Was meinst du mit mehr Möglichkeiten zu kommunizieren?
Ja, die Service-Bus
oder die Queues
beziehungsweise Topics und Queues
sind natürlich jetzt eine Möglichkeit mehr.
Die werden einer Anwendung
Du kannst 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, oder ich sag mal,
ich kenne, ist halt die Frage,
also ich kenne das halt so, dass man das intern in der Applikation
vor allen Dingen macht, also dass man halt dann aufteilt
die Dinge, die man tut, teilt man halt
auch in Commands, Events
und vielleicht Dokumente gibt es
halt auch. Es gibt diese ganzen Enterprise-Service-Bus
irgendwie, weiß ich nicht, irgendwas Patterns.
Es ist halt die Frage, ob man das braucht. Keine Ahnung.
Ich habe letztens mich da so ein bisschen
mit beschäftigt, weil ich mich einfach mal interessiert habe,
wie man denn sowas baut.
Da gibt es ja auch, das Buch erwähne 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 die fangen halt an, naiv mit so einer
Flask-Applikationen und bauen das dann halt immer weiter um,
sodass dann am Schluss bleibt halt auch so
ein Service-Bus übrig und
das könnte man dann theoretisch auch in
Microservices dann halt alles
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 Queues und so,
denke ich, der Vorteil ist halt einfach, wenn du
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
verbraucht in einer CPU.
Du kannst ja auch ein Socket aufhaben.
Oder so.
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 und drunter funktioniert. Aber der hat ja am Anfang
beispielsweise auch seinen Handshake, aber der bleibt
halt offen, der muss dann nicht jedes Mal den neuen Handshake machen, oder?
Ja, bei HTTP geht das nicht.
Bei HTTP
gibt es immer nur Request-Response, das war auch so.
Genau, ja, aber ich kann jetzt einen Token aufmachen, wenn ich jetzt
auch so ein Queue-Ding habe, beispielsweise.
Genau, das ist der Vorteil bei der Queue,
da steht 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 ist,
also warum brauche ich dafür einen Microservice?
Also das hat für mich jetzt 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 nimmt man denn da so
einen Bus oder so eine Queue? Warum nimmt man nicht
einfach HTC oder so?
Die Frage wäre, also wenn ich jetzt so einen Bus nehme, also warum
mache ich das bei Microsoft? Also warum mache ich das nicht trotzdem
in meinem Monolithen oder so?
Ja, genau, da würde ich anfangen.
Ich würde so anfangen, dass man das zuerst so baut,
dass man das intern benutzen kann.
Also meine Meinung ist, es kann halt
schon sein, dass man sowas braucht.
Die Frage ist, ob man es
in einem Monolithen will, ne?
Warum nicht?
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.
Na gut, also kannst du 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 ein Funktionsaufruf. Da ist deine Queue einfach zum Beispiel
in Python ist das halt einfach nur eine Queue-Modell.
Ja, okay.
vom Queue über Queue sozusagen oder so
und dann machst du halt, solange irgendwas
in der Queue drin ist, machst du halt irgendwie, rufst du Funktionen auf
und das war's. Das ist auch nicht, ja.
Kann man durchaus machen.
Habe ich jetzt zum ersten Mal von tatsächlich,
dass das so ein Python-Ding ist.
Ja, genau. Queue.
Es hat aber nichts mit Netzwerkverbindungen oder so.
Nein, nein, nein, genau.
Ist das dann einfach irgendwie so ein State, der existiert
global und...
Ja, genau.
Cool.
Man kann diese Muster ja durchaus auch einfach so...
Deswegen meine ich, 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 Monolithen hat,
und das ist tatsächlich, ich fürchte,
das ist halt das, was ich in der Praxis oft sehe.
Dass Leute halt eigentlich in so einer Situation sind,
sie haben einen Big Ball of Mud,
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 Microsoft
und dann stürzen sie auf Microsoft und sagen so,
das ist die Lösung für mein Problem.
Ich hänge weiter vorne.
Ich will wissen, was passiert denn mit dieser
Queue, wenn der Service eine Downtime hat?
Nein, das ist einfach nur ein Prozess.
Das ist einfach ein Prozess. Also die anderen, die
funktionieren irgendwie weiter, da ist dann irgendwie, weiß ich nicht,
läuft in einem separaten Thread, in einem gleichen.
Ja, alles in einem Thread, im gleichen Prozess.
Das einzige, was das halt sozusagen bringt, ist,
ich die Sachen halt sauber voneinander getrennt habe.
Ich mache halt auch irgendwie, ich mache halt immer, wenn ich
irgendwas schreiben möchte, mache ich halt
einen Command und ich habe halt dann meine
Event-Händler, die alles mögliche machen.
Zum Beispiel habe ich halt einen Event-Händler, der schickt
das Event dann auf den Web-Socket raus für
irgendeinen Client, einen anderen Event-Händler,
der tritt irgendwie
einen Prozess los, ein anderer, 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.
Yay!
Nein, aber nur
damit ich das verstehe, nehmen wir jetzt mal an,
wir sind jetzt in der Django-Anwendung unterwegs
und wir schicken ein Request rein
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 Event-Hä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 ein Request reinsteckt.
Was man schon zurückbekommt, ist, dass das
Command durchgegangen ist.
Also sozusagen man wartet bis, also
ein Request kommt rein
und dann erzeugt man ein Command,
sagt irgendwie Handle Command
oder Handle Service Bus
Handle und
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, dann ist es vorbei.
Das ist einfach ein Prozess.
Dann ist es weg, ja. Das heißt, wir haben jetzt nicht irgendwie, okay. Ja gut, aber wir brauchen irgendwas. 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 der Service ab, aber eigentlich will ich
unbedingt diese Antwort haben, weil das 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 der Nutzer die Antwort und hängst es dann in die Queue
und dass der aus der Datenbank das dann nimmt.
Und wenn das dann abstürzt, der Prozessquestion,
hast du ja in der Datenbank noch die Sachen stehen.
Du kannst ja einen Fleck dran machen, ist dann fertig oder nicht.
Ja, aber es ist halt 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
und dass man
dort, wenn man diesen
Wenn du es weggeschrieben hast, dann hast
du zwar noch nicht die Queue durch, aber du hast halt
den Daten, dass der gekommen ist. Aber das macht natürlich
den Prozess dann minimal
langsamer, weil ich erst was in die Datenbank schreiben
muss. Da hast du auch nicht lang. Ja, aber vielleicht doch
zu lang. Na, glaube ich.
Also wenn du irgendwie lange, Sekundenweite...
Ich habe gerade 30 Millionen Nutzer, die da draufschreiben
und dann... 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 Information
nicht verliere, wenn ich sie denn nicht
verlieren muss. Und da hilft dann natürlich
irgendwie so ein...
Also, ja,
ich würde ja sagen,
man kann das ja auch mal, 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 einen Kafka verwendet oder
Revit und Q oder nochmal was anderes
ist ja letztlich nicht einfach nur
interessant gerade.
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 Bus hat zum Beispiel
Exception Dead Letter
Q.
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 Queues abbauen möchte.
Das kann ich mir natürlich anders ein bisschen leichter machen.
Dann brauchst du für jeden Microservice eigentlich so ein eigenes Fehlerhandling auch.
Ja, also 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.
Beim Konsumenten meinte ich jetzt.
Ja, wenn du eh die Dependency
hast, dass du irgendwie einen hast, der das konsumieren
will und dann halt Sachen macht. Gut, das viele
Hände brauchst du so oder so, je nachdem, was da drinsteckt, 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. Du hast das alles egal.
Machst du halt ganz normales Exception Handling
und da brauchst du all diese Dinge nicht.
Was passiert denn mit retry und gucken?
Das ist auch da und bleibst du noch.
War der nur kurz weg? War die Verbindung weg? War der Server weg?
Ja, aber 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.
Also du glaubst einfach dem, was dann da in deiner Queue steht.
Ich beispielsweise.
Ja, das muss natürlich validiert werden.
Und wenn da was Falsches drinsteht,
dann weiß ich, dass irgendwas vorher falsch war.
Klar, diese Art von Debugging, die ist schon super schwer.
Weiß das, dass da was Falsches drinsteht?
Okay.
Also, weiß ich nicht.
Wenn wir jetzt zum Beispiel,
wir erwarten jetzt ein bestimmtes JSON in deiner Queue.
Und dieses JSON entspricht nicht dem richtigen Format,
dann weiß ich, dass da vorher irgendwas falsch war.
Okay, dann kann es nicht passieren dürfen,
dass das da reingeschrieben werden kann.
Genau, das ist jetzt so ein sehr, sehr einfacher Fehler.
Es kann natürlich sein,
dass ein falscher Nutzer irgendwie in deinem Datensatz drinsteht
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 synke ich vielleicht meine verschiedenen Datenbanken?
Aber das ist dann wieder so ein eigenes Problemchen.
Oder großes Problem.
Ja, aber das ist wie bei Dependencies.
Ja, wie sagt man so schön?
Irgendeinem Tod muss man sterben.
Also es ist halt leider so.
Aber die Frage ist halt,
ich glaube, das hat halt so ein Overhead,
wenn man mit vielen, vielen Microstores arbeitet
und den muss man irgendwie handeln können
und den trade-offen 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 jetzt einer bin, interessiert mich das eigentlich
gar nicht so. Also es ist mir
eigentlich relativ egal, ob ich jetzt in einem Monolithen
entwickle 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
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 zum Microservices
rüber migrieren, ich habe einen funktionierenden Monolithen,
will ich das eigentlich, klar, für dich
ist das super kompliziert.
Aber für mich,
der als 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 Metric Monitoring,
wie zum Beispiel...
Ja, aber das kann auch wieder eine Gefahr sein.
Ja, okay, komm.
Aber für den Kunden bringt das ja jetzt erstmal nichts.
Aber gut, ja, ich verstehe schon.
Das, was ich
vielleicht finde, ist, dass wir relativ
kompliziert wohnen, 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 da so ein bisschen neben, was
Jochen gesagt hat. Die Frage ist, wann braucht man das überhaupt?
Also du brauchst halt wirklich einen Pfeil, wo du dich auskennst
und wirklich weißt, das brauchst du jetzt, das kannst du nicht anders lösen,
bevor du überhaupt
die Entscheidung treffen würdest, da machen wir jetzt ein Microsoft-Ausfall.
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, ähm,
alter Sack.
Ich habe früher, wenn Leute so etwas gesagt haben,
war ich immer so, ja, ja.
Aber tatsächlich, so Erfahrungen,
oft ist es irgendwie,
ich habe das Gefühl,
das Problem in der Praxis ist oft
Kompetenz.
Da weiß ich nicht, ob Leute das irgendwie hinkriegen oder nicht.
Kann man das essen?
Und die Sachen selber
sind gar nicht so kompliziert.
Da würde ich vollkommen recht geben.
Ich würde es so ausdrücken,
Es gibt einen nicht unerheblichen handwerklichen Teil bei dieser ganzen Geschichte und der ist gar nicht so gut in theoretischer, also sagen wir so, das ist halt nicht so viel, da ist gar nicht so viel Theorie.
Also genau, ich weiß nicht, das ist vielleicht die falsche Analogie, ich versuche es einfach mal, man sagt irgendwie, ja man möchte gerne irgendwie einen Bart schön gefließt haben oder so, dann das Buch zur Fliesenlegtheorie ist jetzt gar nicht so dick vielleicht.
Das heißt aber nicht, dass das ein einfaches Problem ist.
Wenn man das selber versucht, dann wird man feststellen,
das sieht nicht so aus, wie ich mir das
vorgestellt habe, blöd. Und tatsächlich
braucht man möglicherweise lange,
muss lange üben und viele Better-Gefeest haben,
bis man das richtig kann.
Und das ist halt leider beim Programmieren manchmal auch irgendwie so.
ja,
das ist halt ein Problem, mit dem
Organisationen dann auch oft konfrontiert
sind und
das nicht so richtig gelöst kriegen.
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.
Die 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 das ist halt dann
vielleicht so ein Zeithorizont mehrere Jahre oder 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 ganz schrecklich.
wenn ich jetzt ein Projekt habe, wo meine Karriere
dann hängt, ob das jetzt gut wird oder nicht.
Das kann mir ja niemandem erzählen.
Und dann versuchen wir halt irgendwie andere Sachen
um das. Aber das ist halt alles nur,
ja. Ich glaube, um nochmal zu der
Badanalogie 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. Ich glaube, das ist nicht
so schlimm.
Ja, ich weiß nicht. Wichtig ist,
was kannst du in dem Bad 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 Handwerksgrundsätze sind natürlich schon sehr wichtig.
Ja, oder ich weiß nicht, vielleicht ist das auch ein blödes Beispiel,
Musikinstrument spielen 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. So dieser Modulisierungsbereich,
da habe ich das Gefühl,
es gibt schon die kleinen Kinder, die können relativ viel
Krach machen und nennen das Musik.
naja
okay
haben wir eine Quintessenz gefunden damit?
es kommt drauf an
genau, das gibt es auch
hat jemand schön
die Lösung aller IT-Probleme
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, ob man es braucht.
Da haben wir wieder,
es ist ein gutes Sales-Argument. Wir machen
Microservices, das ist wunderbar, das klingt
erstmal immer gut. Ja, okay.
Das ist auf jeden Fall ein gutes Argument, wo man Geld für mich vergeben kann.
Ja.
Rein technisch natürlich immer schwer.
Da sind wir wieder bei den Dingen, wo die
Infra sagt, da bewegen wir uns gar nicht, sagt
dann halt Consulting, ja, wir müssen ja nichts
neu, sau durchs Dorf treiben,
wieder ein bisschen Sales und Marketing machen kann, ja.
Ja, aber das ist halt so ein bisschen, das ist halt auch das gleiche
Problem wie, ich glaube, ich versuche
immer das noch auf den Punkt zu kriegen, ich kriege es 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.
Lass das mal Edgel machen. 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,
Quacksalbern. Computer-Sicherheit,
schwieriges Problem,
dann auch da
entsteht so eine Branche von
etwas halbwegs
Zwielichtigen, weiß ich nicht genau.
Manche sind gut, manche sind nicht so gut.
Da habe ich schon gesagt, dass du durch eine Firma betreibst, bei der du bei Organ-Energie
auf Telefon anrufen kannst und ich schicke dir dann
positive Energie durch das Universum zurück.
Ja, also jetzt musst du
nur noch das entsprechende Problem
suchen, was die Leute gerne löst haben.
Ja, einen Stundensatz aufzählen oder halt so eine
019er-Nummer oder sowas.
Ja.
Wir schweifen schon wieder ab.
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. Es ist halt, das ist halt wie,
weiß ich nicht, es gibt so ganze Big Data
Blockchain, weiß ich nicht, und
Microservices 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 ne, also
es gibt da schon durchaus andere Nutzfallen 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.
Ja, auch wenn es schwerer wird.
Man hat einfach wirklich diesen, also das ist
ich glaube, das ist auch immer ganz wichtig zu
sagen dabei, man hat halt wirklich einen Trade-Off
und der ist nicht ohne, der ist niemals ohne.
Ja, vielleicht wollte man jemanden fragen, der sich damit auskennt, bevor man
zum Beispiel mich.
Änderung macht.
Genau, ja.
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,
gibt es noch irgendwie Themen oder haben wir schon alles
gesagt, was wir sagen wollen? Haben wir alles gesagt zum Microservices?
Fällt euch noch was ein? Bestimmt nicht.
Bestimmt nicht, ja.
Ja, ich habe noch eine andere Frage, aber das hat nichts mit den Pics
zu tun, aber das ist dann Jochen.
Aber haben wir noch irgendwas zu Microservices?
Sonst würden wir das Thema einfach zumachen.
No. Machen wir es so.
Du hast irgendwas mit File-Benchmarks gemacht,
was war denn das?
Okay, ja, 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 kurz darauf eingehen.
Ja, also die Frage, die mich beschäftigt hat, ist, weil ich würde ja gern ins Hosting-Geschäft einsteigen.
Ja, also ganz dick.
Ja, genau. Und eine Frage, die mich da beschäftigt hat, also gerade Podcast-Hosting.
Ich meine, wir betreiben unsere eigene,
wir sind ja auch unser eigener Podcast-Hauser, tatsächlich.
Und da sind das etwas spezielle Anforderungen.
Die Files sind groß.
Ja, Files surfen, schnell Files surfen.
Genau, und die Frage ist jetzt, okay,
mit Pfeifen oder nicht?
Ja, mich ärgert, dass wir da so eine Abhängigkeit haben.
Wir machen das über einen 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, ich miete ja sowieso Server,
auf den ich den Xamarin deploye und da ist der Traffic
frei, also warum kann man
dann nicht die Files auch mit ausliefern?
Also mit Minio oder sowas?
Ja, oder im einfachsten Fall ein statischer Web-Server,
das geht natürlich, das Problem dabei ist halt
naja, also
solche Dinge wie
Authentifizierung und so 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 mir geht es um den Fall zum Beispiel, man
editiert halt irgendwie eine neue
Podcast-Episode zum Beispiel und dann
Sollte zum Beispiel die Audioinhalte
nicht für jeden sofort verfügbar sein, sondern
erst, wenn das frei veröffentlicht ist.
Also nur, wenn man authentifiziert ist.
Wie macht man das denn? Das geht ja
quasi gar nicht, wenn ich das auf dem statischen
File-Server hätte. Dann, sobald die Files verfügbar sind,
kann ich sie da sehen.
Ist jetzt
ein Detailproblem eigentlich, aber
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 eine Authentifizierung funktionieren? Dann gibt es dann halt
diese ganzen Geschichten mit, man schickt
halt sozusagen
ein Request an den File-Server,
und da ist dann 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 der
jetzt authentifiziert?
Fragt der einen Microservice?
Ja, genau, da hat man dann auch schon so eine Art Microservice,
oder man schickt halt den
den Request zum Applikations-Server. Der Applikations-Server
schickt aber nicht die File-Response zurück, sondern
er 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.
Engine X macht? Ja, genau, das gibt's.
Wie heißt das? X-Send-File?
Ich weiß nicht. Irgendwie so. Ja, genau.
Und
also das gibt's 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 Applikations-Server ausliefern würde. Und ich dachte eigentlich
geht doch. Django Static Files quasi.
Ja, da gibt's
also wenn die Assets
gemeint sind, also sowas wie CSS
und JavaScript und so Zeugs, da gibt's schon was
für. Da gibt's zwei Neues. Nicht die Assets, sondern
wirklich dann halt mit Einzel-Single-Permission
und File-Offset-Level. Genau, da gibt's
nix und das wäre aber interessant
und eigentlich dachte ich irgendwie, das müsste
mit Python auch gehen, Python-Icing.io, da gibt's ja auch
alles irgendwie und
UV-Loop
ist ja auch sehr schnell
und so
und das müsste man doch eigentlich
machen können und das 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
gibt es so einen Rezeptmanager, Mili.
Kann man sich auch mal angucken, ist sehr 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 UV-Corn, weil
wozu haben die da noch extra
ein Caddy laufen? Und dann
habe ich dann auch in deren Discord Bescheid gesagt,
so, ja, warum macht ihr denn
da nochmal Caddy irgendwie zusätzlich,
das ist doch Quatsch, irgendwie macht das doch einfach über den UV-Corn
und dann hieß es so, ja, aber wir haben die Erfahrung gemacht,
das ist dann irgendwie schneller und irgendwie sonst ist es langsam.
Der so, das kann gar nicht sein!
Dann muss ich mal einen Benchmark machen.
Hab ich einen Benchmark gemacht und gesehen,
stimmt doch, sie haben recht, ich liege falsch.
Benchmark, ja.
Auf jeden Fall
tatsächlich Nginx Caddy, viel schneller
als UV-Corn
beziehungsweise die File-Response kommt von Starlet,
was halt unter Fast-DPI
darunter liegt.
Und das ist auch fast IPA-Backend.
Ja, keine Ahnung, wo es liegt.
Ich weiß es nicht. Also sagen wir so, es ist immer noch schnell genug
für Gigabit-Interface.
Aber wenn es
also 10 Gigabit schafft man damit nicht.
Und Caddy und
Nginx schaffen das schon. Also
irgendwas ist da nicht richtig. Ich weiß aber nicht was.
Kommen wir wieder zu UV-Con macht das
ganze Jahr, oder UV-Loop ist halt Zeiten
vor allen Dingen. Und denken wir, das kompiliert ja nach C.
Das muss doch eigentlich schnell sein. Keine Ahnung.
Also eine mögliche
Grund dafür, warum das
so ist, den ich,
wo ich denke, das könnte es sein, ist,
es liegt daran, dass
irgendwie Caddy und Nginx
irgendeine Art von Serial-Copy-TCP verwenden,
wo es halt nicht nochmal durch den User-Space
kopiert werden muss, die Daten, und
das macht Ubiquon halt nicht,
sondern, weil das kann es halt noch nicht,
also es gibt da ein Pull-Request, das ist aber noch nicht durch,
das heißt, da wird immer alles nochmal
kopiert, also es wird vom Filesystem, vom Hauptspeicher
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 Kernel direkt...
Interessant, wenn man bei den Pool-Requests kann, mal Cherrypicken
und mal gucken, ob es dann... Ja, das wollen Sie
vielleicht mal ein bisschen angucken. Also das könnte noch ein Unterschied sein.
Das wäre dann halt ein 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 Filesystem 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, auch mit Kelly
nicht, weil
die könnten dann nicht sein File einfach verwenden.
Das geht halt nicht. Das geht halt nur, wenn es tatsächlich
ein File-in-File-System ist, glaube ich.
Auch da wäre interessant, wenn sich das jemand,
wenn jemand Bescheid sagen könnte, der sich damit auskennt,
ob das so ist oder nicht.
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
UV-Con oder UV-Loop
beim Serven von städtischen Files.
Und ich weiß nicht, warum. Keine Ahnung.
Aber es ist doch interessant. Mal gucken, ob ich das
irgendwie rauskriege. Ja, das werden
wir euch weiter informieren irgendwann am Ende von irgendeiner
weiteren Zukunftsfolge. Also hört alle unsere Folgen
mal bis ganz zum Ende durch, wenn es
langweilig wird und nicht schlafen.
Ja.
Dann pickt der Woche, Jochen.
Genau,
picken würde ich diesmal
tatsächlich,
wo habe ich das gesehen? Ich weiß gar nicht mehr genau.
Das Ding nennt sich
B-Pi-Top.
Ja.
Ah, da, ich hab's 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. Post-its oder so?
Rich? Ja, das gibt einem so ein bisschen
Daten zu den, zu, also
es ist halt Top. B-Pi-Top?
Ja.
Sehr nettes Ding. Es gibt da so ähnliche
Sachen, Glances gibt's auch. Ja, Glances
gibt's noch und also T-Top, H-Top.
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.
Habe ich auch noch nicht so viel
benutzt, aber das macht so große
JSON-Objekte irgendwie vernünftig.
Hast du auch einen Pick, Janus?
Was genau
soll ich denn picken? Muss das einen breiten Kontext haben?
Nö.
Irgendwas Cooles, was halt irgendwie, was man
vielleicht noch nicht kennt.
Ah, 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 ein Topic schreiben kannst und über einen
Sync-Connector in andere Datenbanken reinschreiben
kannst. Und das wirklich coole 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.
Das klingt gut. Also Next Level Kafka.
mindestens.
Okay, cool.
Ja, vielen Dank, Janis, dass du hier warst heute.
Sehr gerne.
Ich hoffe, es hat dir ein bisschen Spaß gemacht,
genauso viel wie uns.
Bleibt uns gewogen. Schaltet uns wieder ein.
Wie auch immer.
Vielen Dank.
Dann bis demnächst.
Tschüss.