Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode Nummer 41.
Heute unterhalten wir uns über Microservices. Schön, dass ihr wieder eingeschaltet habt.
Hi Jochen.
Hallo Dominik.
Und wir haben einen Gäst dabei.
Guten Abend.
Hi Janis.
Ja, das bin ich.
Hallo Janis.
Ich bin der Dominik.
Ich bin der Janis.
Ja, dann Janis, willst du dich mal kurz vorstellen vielleicht direkt?
Ja, das geht schnell. Ich bin der Janis, noch 29 Jahre alt, jung, aus Wuppertal.
Ich entwickle mit Python viel und oft und gerne.
Bereich Data Engineering, Data Science, irgendwo da bewege ich mich rum.
Und du hast gesagt, du hast jetzt was zu Microsoft zu sagen und deswegen unterhalten wir uns heute darüber.
Ich würde sagen, wir fangen 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örer oder dabei sind gerade, die irgendwie davon betroffen sind.
Es gab da so eine Sicherheitsschwankung bei Okta.
Ja, ich weiß nicht, wen du meinst, der betroffen ist.
Keine Ahnung.
Ja.
Ja, also das, ja, fand ich war mal wieder so.
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
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 habe mich da
immer, 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,
sowas zu machen, so gerade Authentifizierung irgendwie
auszuschanzen.
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.
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.
Ich habe auch für Okta tatsächlich so ein Dankmodul geschrieben,
mit dem das dann doch irgendwie geht, aber
das ist halt auch nutzerlich, wenn Okta kaputt ist.
Ja, doof
Menus
Dann, aha, oh, gibt's
einen, wir hatten ja schon mal
diesen Tiobe
Programmiersprachen
Ach, der spannende große Index
der immer so zitiert wird, wo man dann
irgendwie, wenn man genauer drauf schaut, sehen muss, oh, die
gucken nur, wie die Menge der Suchergebnisse
bei so ein paar Suchanfragen aussieht und das ist ja
alles irgendwie, wie viel das so sagt
Keine Ahnung, es gibt einen anderen, der
macht sowas ähnliches, der heißt
Pipel,
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
was dran sein könnte.
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 ist
tatsächlich sehr gute Neuigkeiten.
Das ist ja eigentlich noch nicht so lange her, dass tatsächlich
die Python Software Foundation
irgendwie hatte bisher immer
alles Mögliche um die Marke
drumrum
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 bezahlt,
um Python
zu kümmern.
Es gab Leute, die bei Firm gearbeitet haben,
die dann zumindest einen Teil der Zeit dafür zur Verfügung
hatten, sich damit zu beschäftigen.
Aber jetzt gibt es seit
zwei Jahren, glaube ich,
Developer in Residence.
Zuerst hat Google
den bezahlt.
Lukas Schlanger macht das sehr gut.
Er schreibt auch immer wieder Blogposts,
was er so tut.
Und jetzt quasi damit
bezahlt das jetzt erstmals auf Facebook,
was natürlich super ist.
Vielleicht werden das 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.
Sollte man meinen. Sollte man denken, dass sie das so betrachten,
weil wenn das
irgendwie nicht mehr funktioniert, dann haben die ein großes Problem,
was sie sehr teuer zuschlingen können.
Es ist halt schwierig, so was zu vermitteln, dass du halt
Dinge bezahlen musst, die in der Zukunft
eventuell einen Return on Invest geben und
oder halt auch nur ein Risiko abwenden.
Ja, aber das ist 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, das, genau.
Aber irgendwie geht es da voran, das ist voll gut.
Ja, was haben wir noch?
Oh, genau.
Bugspython.org, das weiß ich auch
schon seit Jahren. Versuchen wir da irgendwie zu
migrieren auf GitHub.
Ist aber noch nicht.
Nein, wir haben es verschoben.
Achso, auch hier darf ich ja 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, wissen nicht ob das
funktioniert, wird für wir die als alle diese
Issues erzeugen und so, wartet
lieber nochmal ein bisschen
Okay, ja gut, das ist jetzt nicht mehr so lange
Also ist jetzt quasi, wenn ihr es hört
vielleicht schon migriert
oder kurz davor
Und gestern am 4.4. ist tatsächlich
20 Jahre.
Das ist auch ein richtiger
Meilenstein. Hätte ich jetzt auch nicht gedacht,
aber das ist natürlich alles
irgendwie
Zeitgefühl, komische Sache.
Schon ein bisschen abgehangen, wie man alt wird.
Ja, aber Python ist total wichtig, super. Also immer wenn man sich fragt,
okay,
Python selber langsam, aber
macht trotzdem Dinge schnell und so.
Wie geht denn das eigentlich? Ja, da ist meistens
Python daran beteiligt und
ja, tolles Projekt.
irgendwie, man schreibt so eine Python-ähnliche
Syntax und das wird dann
halt in C
Cross-Conviled sozusagen und dann... Man kann auch die Funktion
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 Cell Magic
in Jupyter Notebooks oder Jupyter Lab
und da kann man einfach sagen, Prozent, Prozent
Zeiten und dann wird
das halt mit der Funktion
einfach so wieder reimportiert und dann
wird die halt tausendmal schneller oder so.
Das ist halt sehr schick.
Ja
Ja, okay
Kennst du V, die Language
V-Lang
Bin ich irgendwie letztens drüber gestolpert, weil ein Kollege mich draufbrachte
und hab 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
Momentan ist auch wieder so die Zeit für neue
Programmiersprachen, ne, letztens hab ich gehört
von SICK
SICK? Das ist auch so ein
ein toller, lustiger Name, dass das wieder so
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 IO?
Okay, ich muss es mir auch mal angucken.
Komplett Auto C,
deswegen kam ich gerade drauf.
Ach so, ah, okay, das ist auch interessant.
Ja.
Witzig.
Ja.
Okay, dann sind wir eigentlich schon fast...
Das war diesmal schnell.
Ja, wir haben gar nicht viel in den Lügen bleiben.
Dann sind wir damit eigentlich durch.
Achso, haben wir eigentlich
Veranstaltungshinweise oder sowas?
Ja, das wollten wir...
Achso, du wolltest zur PyCon, bist du da?
Momentan sieht es nicht danach aus.
Ich hätte jetzt zufällig...
Zuerst hatte ich gedacht,
das schaffe ich irgendwie nicht,
und Jochen unterhalten sich über die Programmiersprache Python
Tickets. Und dann dachte ich, ich hätte keine Zeit.
Und dann habe ich dann gemerkt, oh, ich habe vielleicht
doch Zeit und dann waren aber keine Tickets mehr da.
Insofern, ja.
Aber vielleicht machen wir auch nochmal
eine Sendung oder so dazu, wie das da gewesen
ist und finden noch Leute, die da waren
und dann davon erzählen können.
Ja, das werden die mal fragen.
Genau, den habe ich schon gefragt.
Hat sich auch schon gemeldet und weiter eigentlich auch.
Okay, cool. Also gibt es doch irgendwann eine PyCon-Folge.
Ja. Im Sommer, die
EuroPython-Tickets sind auch gerade draußen. Da gibt es sogar noch welche von, glaube ich.
Es war noch nicht so super angelaufen, der
vorverkauft, obwohl die so schnell immer weg waren.
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 komme.
Würde ich gerne machen.
Ich bin gespannt. Und dann gibt es noch die,
also gut, dass jetzt nicht mehr so
Konferenzcenter in Dublin ist, relativ nah an der
Brewdog-Außenstelle.
Brewdog-Brewing.
Ja, genau.
Das Angenehme mit dem Nützlichen.
Ja, super Feminu.
Genau, und im Herbst, irgendwann im September, gibt es die DjangoCon EU, diesmal auch tatsächlich vor Ort und in Porto. Die sollte ja eigentlich letzten beiden Jahren in Porto stattfinden, aber hat sie 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, das stimmt, das ganze Team.
Ja, das finde ich ein bisschen schade, das wäre natürlich nett.
Das wäre schön, ja.
Ja, jetzt haben wir doch noch ein bisschen
News gemacht.
Okay, gut.
Dann kommt jetzt wieder der obligatorische Werbeblock, habt ihr schon gehört?
Und diesmal ist Janis da.
Janis darf Werbung machen.
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 dazu gehö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. Ist 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
ein Lieblings-Tool ist, ist das vielleicht auch interessant?
Welches Tool? Pandas. Pandas, ja klar.
Sicher, ist ja Data Science.
Ja, der Python passt natürlich eigentlich
schon ziemlich gut zusammen und
und kann man da dann
wahrscheinlich auch remote arbeiten oder so?
Eigentlich sitzt die von meinem Bielefeld, sehe ich gerade.
Genau, wir sitzen in Bielefeld.
Remote Arbeit. Ich arbeite
sehr viel remote. Wir haben immer so
einen Stammtisch irgendwie, damit man sich doch auch mal in Person
sieht, aber rein
optional, sage ich jetzt mal.
Insofern
sind wir gespannt. Klingt gut. Also falls ihr
doch 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, Aktionskurs
Ja
Schrei mich an, genau, eine E-Mail-Adresse
und eine Internetseite gibt es auch
business.lu.de
da könnt ihr euch gerne hinbewerben, ansonsten
gibt es bestimmt auch irgendwo so einen Text, wo man
sowas verlinken kann bei euch im Podcast
Ja, und vielleicht genau, wenn man sich meldet,
kann man auf jeden Fall den Link dazu sagen, dass das über
Python-Podcasts, dass man sich da das gehört hat,
weil dann kann man das vielleicht so ein bisschen
irgendwie verfolgen.
Da haben wir in der Fähigkeit bessere Chancen,
da wissen wir auch, dass ihr schon das hatte.
Genau, 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 der Projektmanager war, der für
ein größeres Projekt irgendwie
gehört hatte, was da so gibt und der einen Django-Podcast
von uns gehört hat und da dachte ich so, oh cool, da warst du nicht der Typ
mit dem Podcast. Ja, interessant.
Ja, das hilft mir schon. Also das ist schon cool.
Genau. Ja, schick.
Super. Hört mal rein.
Wenn ihr was sucht, wisst ihr jetzt wo.
Oder nicht sucht und
doch zu uns wollen.
und Jochen unterhalten sich über die Programmiersprache Python
Services.
Das ist die Meinung von Jan.
Ja, okay.
Da haben wir schon die Seiten
geklärt.
Ja, das ist ein bisschen plakativ.
Wir werden mal noch sehen, ob das wirklich so ist
am Ende.
Ja, aber das ist doch genau spannend jetzt. Also du sagst,
Microsoft Services 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 das Thema Best Practice, sage ich jetzt mal.
Und auch immer so ein bisschen ein Thema der Architektur.
Also ich glaube, das werden wir im Laufe der Folge, wenn ich in die Zukunft gucke, immer mal häufiger hören.
Man kann sich natürlich verschiedene API-Endpunkte suchen und alle einzelnen anfragen.
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.
Darüber hatte ich eben auch schon mal, glaube ich, ganz kurz mit Jochen
gesprochen, weil es ja genau darum geht, also wer ist
da nicht 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 ein Frontend, das sozusagen
Mikrofrontends
müsste man machen
Da muss ich halt ehrlich sagen, ich mag kein Frontend
Wer liefert denn das Mikrofrontend?
aus. Also wenn man zum Beispiel in HTMLX das ausliefert,
dann wäre ein Django ein sogenannte Spinne
oder so ein Aggregator, ein Gabi-Gateway,
obwohl ich jetzt das Wording da immer nicht ganz
treffen finde, ehrlich gesagt.
Das spielt dann letztlich ja
keine große Rolle mehr,
weil du musst ja dann, das wäre nur noch eine statische
Seite. Also was ich mir jetzt halt da kompliziert drin
vorstelle, ist, wenn ich so ganz viele verschiedene Zeug habe,
aber ich habe ja eigentlich nur eine Anwendung, warum mache ich das nicht
in der einen Anwendung direkt und habe dann diesen ganzen
Gefummel mit dem ganzen
drumherum nicht. Darüber wollen wir ja
reden. Ja. Also, das ist ja das Ziel der Folge. War eine kurze Folge, wenn man das jetzt so einfach
und so schnell... Ein Satz fertig, ja, danke schön. Heute haben wir euch nicht so lange...
Nee, ganz so ist es natürlich nicht. Man muss halt auch mal sehen, welche verschiedenen Funktionalitäten
man haben möchte. Wir sind jetzt im Bereich Web unterwegs, von deinem Beispiel.
Das klingt erstmal sehr, sehr einfach. Web-Anwendung, ich meine, so eine Standard-Firmen-Webseite
meinetwegen mit einem Kontaktformular, da braucht man keine Microservices für, das stimmt schon.
Aber wenn wir jetzt zum Beispiel mal eine Kurs-Webseite meinetwegen sehen, wo wir
und Jochen unterhalten sich über die Programmiersprache Python
Hake ich an der Stelle mal ein und sage mal so,
was ich denken würde, was Microservice ist
und ich würde denken, der entscheidende
Punkt dabei ist eben die Einheit,
wie deployed man das. Also alles, was man
wenn man 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 ein Monolith.
Und eben, Microservice hat halt den Vorteil,
und Jochen unterhalten sich über die Programmiersprache Python
von Texas.
Hilfe!
Das ist quasi so, ja, also Dinge, die
halt irgendwie so zusammengehören und nur
gemeinsam verändert werden sollen.
Ich glaube, das Standardbeispiel auch eben aus dem
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,
im Baune-Kontext eben.
Ja, das ist aber eine spannende Frage.
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, 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
Bestellung oder so.
Und in dem einen Fall hat man halt da komplizierte
Adressgeschichten und weißer Teufel irgendwie Zeugs
und im anderen Fall braucht man das gar nicht, weil da muss man nur überprüfen,
stimmt der Passwort-Hash oder so.
Und ja,
je nachdem, welchen 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 Context
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.
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 lässt man den in Microservices? Und eine Frage,
die damit einhergeht, ist immer das Datenmanagement.
Vielleicht noch mal kurz, Entschuldigung, dass ich euch gerade direkt eingreife, 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.
Wenn es hinterher dieselbe Datenbank liegt, dann ist da die Frage,
warum macht man da eine unterrichtliche Akzeptur?
Aber vielleicht kann auch das man machen, wenn
ich halt irgendwie hingehe und möchte aus derselben Datenbank
Dinge erzeugen mit unterschiedlichen Sprachen
und die dann...
Und dieselbe Datenbank wird schwierig,
weil dann kannst du es halt nicht mehr getrennt voneinander deployen.
Also wenn jetzt zum Beispiel auf der, wenn es
und gemeinsamen Datenbank hast und du änderst die jetzt?
Na gut, er kann ja einfach den Datenbank-Ding 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 Stuss gemacht hat.
Das will man eigentlich auch vermeiden.
Also das ist so ein Shared-Datenbank-Anti-Pattern
heißt das.
Das macht man manchmal,
weil es einfach schnell ist, weil es einfach
einfach ist. Aber wenn man wirklich
Microservice macht und sie wirklich braucht, dann ist das
eigentlich mal eine relativ schlechte Idee, wenn man sich
da doch, wie gesagt, 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 ist ja die Frage, ist das eine
Architekturentscheidung, wenn du jetzt sagst,
Design, Domain dürfen Design
was würde denn da?
Damit sind noch keine Architekturentscheidungen
gefallen quasi
damit ist es halt einfach nur so ein
Konzept, wie man Dinge angehen könnte
aber...
Stell das ja so ein bisschen in den Raum dann vielleicht, also die Wahl
Ja, also
ich weiß es nicht, ich meine, es ist halt die Frage
und
ob man
tja, also
in der Vorbereitung habe ich jetzt mal
so einen Podcast auch gehört,
wo da gibt es
irgendwie ein Buch, das immer empfohlen wird
zu Microsoft Services von Sam Newman
und der ist auch in diversen Podcasts schon zu Gast
gewesen und der sagte
dann dazu quasi so
naja,
also
das mit den Datenbanken ist ja so eine Sache, also wenn
das funktioniert, wenn man halt eine Datenbank haben kann
und so und dann sollte man das schon machen, weil
es gibt ja Grundformen, 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 mit hatte, fragte
dann halt auch so, ja kann man denn dann irgendwie was tun,
um Datenbanken schon
drauf auszulegen, dass man die dann vielleicht trennen kann oder
kann man das irgendwie Architektur, und dann meinte er so, ja das kann man,
warum sollte man das tun?
ist. Man muss der Datenbank schreckliche
Dinge antun, damit das geht.
Das muss einem halt klar sein.
Also, ja, es geht schon,
aber 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.
Würde ich auch sagen, normalerweise sollte man einen Grund haben,
warum man das macht. Also, ich würde jetzt auch so intuitiv
sagen, du baust halt jetzt einmal dein Deployment
für ein Tool, für eine Webman-Winne,
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 ist jetzt eine gute Idee oder das
hilft mir irgendwo bei?
Das ist
unterschiedlich. Vielleicht erstmal eingehakt
noch bei diesem Datenbank-Auseinanderschneiden,
das stelle ich mir sehr, sehr kompliziert vor.
Das, was wesentlich einfacher ist, sich vorzustellen,
ist, dass jeder Service tatsächlich seine eigene, echte
Datenbank hat und man verteilt die Datenbank quasi
auf verschiedene Microservices.
in ganz normalen Datenbanken.
Was du gesagt hast, das kam relativ
kompliziert.
Du hast ja 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 ist wesentlich komplizierter geworden,
aber die Datenhaltung pro Service,
die ist immer noch relativ einfach.
Das muss man halt ganz klar sagen.
Die einzelnen Microservices in sich,
die sind unglaublich einfach.
Wenn du zum Beispiel Monolithen hast, und da kommen wir direkt zu
und Jochen unterhalten sich über die Programmiersprache Python
und das würden jetzt, also Dinge, die halt
eine Seite kaputt machen, andere Apps kaputt machen
und wenn man jetzt beispielsweise in Django-Apps
jetzt denkt, wenn man das parallel
entwickelt, dann könnte man die ja voneinander
trennen.
Im besten Fall tut man das, ja.
Also wenn die sich gegenseitig differenzieren, kommt man natürlich
in so ein Dependency-Problem vielleicht.
Ja, ja, ich glaube,
also ich meine, das ist
auch immer was, wo
es geht eigentlich im Grunde,
das zentrale Problem 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 muss man
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
die allerschlimmsten Geschichten sind dann halt,
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
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.
Das ist ja nicht so. Dann hat man es einfach nur verteilt.
Das heißt, man hat ein Ding, was man nicht modularisiert hat,
verteilt und dann hat man halt einen verteilten Monolithen
und das ist halt...
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?
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 Microsoft verwendet.
Man verlagert das Problem.
Aber ich sage jetzt mal, man macht die Sache halt,
die Codebasis selbst wesentlich einfacher
und manchmal l man auch einfach in eine Situation wo man feststellt okay die Funktion die ich jetzt hier machen m die ist in dem Umfeld in dem ich mich gerade bewege einfach super schwierig zu implementieren Das hei ich finde gar keinen geeigneten technischen Ansatz da mal ein Ding was einzubauen
vielleicht ein 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
parallel Laufenes, 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 Topic-Anwendung
aufmachen zu einem Kafka oder
einer anderen Queue?
und 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?
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.
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 dann wieder aggregieren,
wo du jetzt 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.
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.
Ich kann die auch schwer testen oder sowas.
Wenn ich das aus meiner Seite, das muss halt eigentlich auf deren Seite
getestet sein. Das heißt, ich gebe quasi
die ganze Verantwortung
weg.
Du hast wahrscheinlich wesentlich mehr Integration-Tests
erstmal, als du 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 riesen Herausforderung, worüber du sprichst
beim Single Point of Truth
beziehungsweise auch das ganze
Monitoring. Das ist ja wesentlich komplizierter
in der Microservice-Welt.
Weiß ich nicht, wenn du...
Ja, 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 raus
passt oder irgendwie... Ja, du musst überhaupt mit sowas
erst mal 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 durchgekommen hat, das dann zu machen.
Ein gutes Startprojekt ist halt
zu sagen, okay, dann machen wir doch mal irgendwie
als ersten Microservice
irgendwie zentrales
Log
so Elk-Stack oder sowas,
Log-Management, weil
das ist halt relativ einfach,
das ist eigentlich nicht so schwierig, aber man
muss halt trotzdem irgendwie
Sachen irgendwo hindeployen können
und 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 Logfile sehen kannst und gucken kannst,
was passiert ist, über deine unterschiedlichen
Services hinweg.
Das meinte ich mit dem
Hut auf Farben. Ich muss halt immer irgendwie so ein
Admin haben oder so.
Du hast dann ein Ding für
Log-Geschichten, du hast aber dann vielleicht auch ein anderes Ding für
Monitoring, du hast wieder ein anderes Ding für
dein
Live-Dashboard oder so.
Das müsste ja 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
Das muss, ne?
Ja, wir haben das auch gemacht.
Ich meine, am Ende, ich meine, das, worauf der Jochen hingewiesen hat,
wir haben ja unsere Tools, ne?
Also der Elkstack 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 deine Services einbauen kannst, ne?
Also Filebeat-Logging geht zum Elkstack.
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 doch 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,
um die Logfiles durchsuford zu machen.
und Jochen unterhalten sich über die Programmiersprache Python
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 Bunti
deine Logs durchsuchen und dann hast du
deine Graphen, kannst dir auch Dashboards bauen
Freitextsuche
das ist sehr schön
macht Spaß
Okay
Ja, ich sehe es auch tatsächlich, also wenn du sagst, in der Organisation irgendwie muss auch jemand, die, ich denke, das ist halt eines der Ziele bei dieser ganzen Geschichte, gerade wenn man es bei größeren Organisationen, das sich anschaut, die haben oft das Problem, also wenn man sich jetzt anguckt, was machen denn Firmen vorher oder was machen die normalerweise anders, wenn sie nicht Microsoft machen, dann machen sie meistens so eine, also ich würde sagen, Microsoft ist halt so, versucht das ganze Problem, die Problemdomäne irgendwie zu lösen,
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
irgendeine Organisationsstruktur halt.
Und das
Problem bei dem horizontalen Ding, was halt man da
vielleicht weg möchte von, ist
halt, dass
du halt, wenn du jetzt viele Leute hast, die daran arbeiten, an deinem Produkt,
dann stehen 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.
Und du brauchst sie halt auch deswegen, weil du halt eventuell fiese Datenbank-Probleme hast,
wo Leute irgendwie Queries optimieren müssen oder sich überlegen müssen, wie sie da halt irgendwie
und die möglich 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 hast jetzt
irgendwie ein Projekt und da muss halt irgendwie jetzt
eine Spalte zusätzlich irgendwo in der Tabelle.
Und das ist jetzt eigentlich nichts, was so
sonderlich schwierig ist vielleicht. Sollte man sich überlegen,
ob man das machen will oder nicht oder keine Ahnung, aber
letztlich das zu tun ist gar nicht so schwer
und dein Datenbankteam ist
zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt
oder so. Und dann kommst du nicht weiter
mit deinem eigentlich Projekt,
das nur eine blöde Spalte zusätzlich haben
muss. Es gibt halt eine Menge Anforderungen, die sehr
einfach sind. Also entweder du
beschäftigst dann halt deine teuren Spezialexperten
mit sehr simplen Geschichten
oder
du kannst die nicht auslasten,
weil
die halt
oder du kannst halt
mit deinen Projekten nicht weiter, weil die halt mit
und irgendwelchen anderen Kram ausgelastet sind.
Und das blockiert sich halt gegenseitig.
Du hast halt sehr viel Hand-off-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,
und die anderen sind halt bloß,
die beraten dich
dann halt, wenn es irgendwie
kompliziert wird oder so und
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.
und der
von Rügen.
Ja, aber du bist halt unter Umständen schneller.
Und ich finde,
in einer Firma gibt es das auch sehr schön,
sowohl, dass das einen Vorteil 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 Vorderteil 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.
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 herausgefunden, wofür ich
dann jetzt ein Microservice gut einsetzen können.
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 Jochen so schön sagte,
enablen die Leute, dass sie
selber klarkommen mit den ganzen
Regeln, die ich irgendwie haben will.
Ich glaube, das ist noch viel zu kompliziert.
Ich glaube, erstmal muss man
überlegen, brauche ich das überhaupt? Also macht das für mich
überhaupt Sinn? Habe ich die Größe, wie viele Mitarbeiter
habe ich? Bin ich jetzt zu fünf, dann mache ich keinen
Microservices auf. Aber habe ich meinetwegen
20, 30, 40 Mitarbeiter,
das macht schon super viel Sinn, da über
Microservices nachzudenken, weil ich kann
jetzt eigentlich 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.
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 sogar 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 sie 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.
Ja, genau, aber das 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 Prozessgateway
durchkommen und habt 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
das ist ja gerade der Sinn von Microservices auch,
dass jedes Team eigentlich nach Lust und Laune so arbeiten kann,
wie es will, solange es zum richtigen Produkt führt.
Weil das Team in Berlin wird relativ
wenig Berührungspunkte mit dem Code zum Beispiel
vom Team in Tokio haben. Und umgekehrt
natürlich auch, weil Microservice-Teams,
die stehen ja für sich alleine. Das heißt,
wir haben ein Team, das arbeitet an einer Sache,
das deployed ein Service für sich alleine
und der muss natürlich integrativ mit den
anderen irgendwie funktionieren.
Ich würde auch denken, dass das Problem
eher tatsächlich andersrum ist,
also was dann tatsächlich auftritt.
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 zugehört,
also das ist ein Riesenproblem.
Aber schon ein Riesenproblem ist halt,
Also wenn du jetzt so etwas hast, wie ich weiß jetzt nicht, was das Beispiel war, das kam auch in der Prozessreise. 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 halt da, wenn du derjenige bist, der das produziert und das dann verteilt an Unterrichtsgemeinschaften,
das ist genau das, was ich meine.
Ja, das ist der Nachteil, das geht halt nicht mehr.
Aber das, was ich zentral, das sind wir vielleicht wieder, was man bei Single Porn oder Fools irgendwie überschreiten 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...
Ist halt die Frage, also es geht halt manchmal, ich meine, ich kenne es halt zum Beispiel,
ein Beispiel als zweitgrößte E-Commerce-Konzern der Welt.
Wisst ihr, wer das ist?
Nach Amazon?
Otto?
Ja, das ist Otto, aber tatsächlich, ich weiß nicht,
ob das noch stimmt. Es kann sein, dass
AliExpress
oder so größer ist.
Oder Alibaba.
Da macht man kein Wettbewerb draus.
Otto auf jeden Fall sehr, sehr groß.
Damals, das ist jetzt aber auch schon wieder
lange her, haben sie
das auf die Fahnen geschrieben,
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,
gehört zum Autokonzern.
Du weißt das 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.
Wie machst du das denn jetzt eigentlich,
wenn du quasi Dinge wissen willst über deine User?
Also andersrum, 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 Säkertreuen.
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, sie 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 unsere interne Konkurrenz,
das sollen wir denen jetzt irgendwie freiwillig zur Verfügung
stellen. Dann haben wir halt irgendwie
einen leicht kaputten Export, wo die Daten
so ein bisschen... Ja, aber mit der Konzernbrille,
die du dann aufhast, dann musst du da hingehen, musst den gotischen
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,
und Jochen unterhalten sich über die Programmiersprache Python
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 Softwareseite 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 du
und dann geht es halt immer raus und zusammen.
Ich meine, das macht natürlich auch Sinn. Also wenn du irgendwas
hast, was total verfüllt ist, dann musst du das
erstmal auseinanderspalten, dann hast du kleine
einzelne Services, die untereinander so ein bisschen Wettbewerb haben, die guten Sachen,
muss dann irgendwie wieder konsolidieren und zentralisieren, um dann wieder den guten Benefit rauszubekommen.
Du merkst, dass du wieder doof bist, dann fängst du wieder an, das auseinanderzudröseln.
Das ist ja genau wie bei den Ländern. Mal sind Länder zusammengefasst, dann sind sie auseinander.
Aber das ist ja vielleicht auch dieser natürliche Lebenszyklus von so einem Ding.
Wenn ich jetzt zum Beispiel das Otto-Beispiel nehme und ich möchte diese User-Daten haben,
Ich würde jetzt als Otto hingehen und sagen, ich will wissen, wer sind meine Kunden, wie viele Kunden sind überhaupt irgendwo.
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 einigermaßen echt.
Und da habe ich einen vollen Überblick, 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, ne? Aber du kannst auch überlegen,
ob du, finde ich, im Vorfeld einen gewissen
Standard etablierst, wo du sagst,
da sind wir wieder beim Standard natürlich, ne?
Und bei den Gateways, ja.
Nicht nur bei den Gateways. Ich bin ein Backend,
ich interessiere mich nicht so für die... Ja, doch, auch.
Ja, das ist mein Problem mit der Gatekeeper.
Ich musste gerade, weil du gesagt hast Standards, musste ich an
Infrastrukturstandards denken und
auch dann, du sagst das ja, unheimlich schwierig,
wenn du die gleichen Standards
einführst für Teams, die
auf der Welt irgendwo sitzen.
Damit verlierst du die Vorteile von Microsoft.
Die Frage ist halt, was der Standard ist.
Möchte ich jetzt einfach so ein Plug-in
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?
Es fängt ja schon bei kleineren Sachen an,
wie jeder Dev kriegt einen Windows-Klip-Top
mit AD zugeführt.
Aber das hat er nicht.
Das ist der Punkt. 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
noch 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,
und 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 Microservices.
Ja, genau.
Aber da hast du ja schon eine Antwort.
Also willst du den Hut aufhaben, wie du es so schon sagst,
dann mach keinen Microservice
oder überleg dir halt sehr, sehr gut, wie du das gewährleisten kannst,
wie viel willst du wachsen.
Vielleicht geht das ja so, wenn Microservices verweist.
Oder willst du die Verantwortung abgeben,
dann kannst du Microservices 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 am Ende ist dann ganz einfach,
auf welcher Kostenstelle wird denn das gebucht und wer hält dann wo die Hand auf?
Ja, aber ich glaube,
wenn man nochmal einen Schritt
mehr Richtung Organisation
oder allgemein oder abstraktes Problem geht,
ich denke, ich würde irgendwie diesen Trend
zu Microsoft halt so verorten
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 hast du halt Entwicklungen und Betrieb
oder IT und Operations
und auf der anderen Seite Entwicklung.
Das ist vielleicht auf unterschiedlichen
Seiten deiner Bilanz auch. Das eine sind
Kosten und das andere sind
Investitionen.
Dann siehst du
wenn da Features entwickelt werden,
siehst du das als Investition und
denkst halt, je mehr Features entwickelt werden, voll gut,
gibt mir in der Zukunft mehr Einnahmen, total super.
Das heißt, deine Entwicklung
misst du daran, wie viele Features kriegen die eigentlich
Pro Quartal irgendwie raus oder keine Ahnung, irgendwie sowas.
Und 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 kriegen
nicht mehr Geld dafür, dass sie halt
dafür sorgen, dass sie in den Verkleinern
mehr Features veröffentlichen. Was ist deren
sozusagen rational
der 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
wenn irgendwas nicht geht, solange das Wasser läuft
und der Strom an ist, alles gut
sobald der Strom ausfällt, kriege ich
ein paar Probleme
das heißt, mein Ding ist
ich meine klar, eine Änderung kann sein
dass die gut ist für andere, 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.
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
ein Maß dafür. Man sich fragt so,
also dann macht man dann eine Kostenschwellung, keine Ahnung
und dann sagt man intern so, man 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, ja.
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 das,
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 Sprinter zu packen.
Genau, Agile, auch so ein Ding, wo man sagt, okay, genau, wir packen 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.
DevSecOps jetzt, ne?
Full-Stack-Microservice
DevOps
im agilen Prozess
ja, das ist unglaublich
aber ja
genau, es geht halt darum
irgendwie, dass
einzelne Teams halt möglichst
autark Dinge machen können
dass man halt sozusagen da, wo man investiert
halt auch tatsächlich, dass die auch dann
die Möglichkeit haben
das umzusetzen, aber
und Jochen unterhalten sich über die Programmiersprache Python
dazu, dass diese Idee, Microsoft ist
ganz groß geschrieben, du willst ganz viel
Microsoft machen, aber hast
eigentlich da die ganze Zeit diese Krake, die das
festhält. Und das funktioniert, glaube
ich, überhaupt nicht.
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 denn überhaupt?
Also ich verstehe es immer noch nicht.
Also irgendwie denke ich immer noch so,
warum hält man das dann nicht an einer Stelle fest
und sorgt dann dafür, dass die
alle dann an eine Stelle
kommen, dass sie sich alle gut verstehen,
dass sie alle dieselbe Text-Stack 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 habe die Things of Tuesday,
Ich kann ja von mir verschiedene Rechenzentren
parallel an verschiedenen Orten halten. Das ist ja okay, das kann ja
ein Server-Team mitmachen. Aber warum muss ich, also
die Abhängigkeiten werden dann von mir
aus schwieriger, ja,
so ein bisschen zu managen, weil ich habe halt dann das Problem,
wie Jochen gerade sagte, dass
hochspezialisierte, hochgutbezahlte
Spezialkräfte sich teilweise um trivialen
Scheiß kümmern müssen, bis die Sachen halt mal
integriert sind.
Aber dafür konnte man ja einen Service schreiben, also keinen
Microservice, sondern einen, der halt
in den Monolithen drin hängt, ja.
Ja,
Also ich, ganz grundsätzlich, ich habe so ein bisschen das Gefühl, du bist so ein bisschen biased.
Weitere, das ist mir eine meine 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.
So was 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 Tagstack überhaupt, will ich den überhaupt haben, bringt er mir überhaupt was.
Es gibt halt so wenig gute Leute, dass man wahrscheinlich schon Tagstack multiplexen muss, damit man überhaupt genug Leute findet.
Ah siehst du also Microsoft nein Aber grunds musst du dir ja auch die Frage stellen erstmal vielleicht um von dieser Ebene mal ein bisschen zur zum Code zu kommen Ein Monolith der hat nat
eine riesen Codebasis, die unter Umständen
relativ komplex ist. Das heißt, du musst viel Aufwand
in den Deployment-Prozess an sich stecken.
Also bist du
ein einzelnes Feature, ein neues Feature deployst
oder ein Bug fixst, 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 der Imposition durchrutscht, dann ist im Zweifel rausch ein ganzes System ab und hat eine Daumenteile.
Genau, der Monolith ist so ein klassisches Beispiel für Single-Point-of-Failure.
Auch das kannst du irgendwie umgehen, indem 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
dann denken, wenn ich so zwei, drei
im Tag rausschrauben will, 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 das 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 dass wir zum Beispiel
ein Grund zu sagen, ich will das jetzt aufsplitten.
Ein anderer Grund ist,
dass wir reden über
große Codebasen. 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
weg, 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 noch
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 einfach
das Problem so ein bisschen, dass dieser Entwickler
nicht den ganzen Stack kennt und auch überhaupt nicht
kennen muss.
Gut.
Ich frage mich halt,
ob das
einen Unterschied macht.
Also es 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 also mindestens
habe ich Komplexität draus.
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 vor einer Wand aus Guidelines
und Jira-Pages
und was weiß ich.
und die Programmiersprache Python.
Da musst du die Reihenfolge festlegen.
Auch das hast du in Microservices, wenn sie unabhängig
voneinander sind, teilweise nicht.
Aber klar, Breaking Changes ist immer ein Thema.
Das hast du jetzt auch sehr schön geredet.
In meinem Kopf ploppt gerade wieder aus,
wenn ich das dann warten möchte und wenn ich das
ausbauen möchte, wenn das Team weg ist,
was die Microsoft entwickelt hat, dann muss ich ja wieder
Experten suchen, sich dann mit dem anderen TechSec auskennen,
den ich jetzt gar nicht kenne.
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 baut irgendwie und das dann
günstiger, als den anderen
neu zu warten, ja, okay
Ja, ja, könntest du natürlich
machen, aber ja, ich meine, ja, ehrlich gesagt
ich würde, 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 genau,
das ist halt die Frage,
gibt es irgendwie einen Grund, warum man das machen sollte?
Was ich dann,
was der Autor
von dem Buch da meinte, ist so, 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
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 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, das wird nicht live, das, was wir machen, dann geht es halt vielleicht nicht anders.
aus der Ausbildung machen.
Wir können vielleicht auch sogar in Richtung
Use Cases gehen. Ich meine, wir hatten ja schon
Beispiel der Bestellservice meinetwegen oder IoT,
wäre auch noch so ein Bereich, wo es
prinzipiell durchaus auch natürlich wirken kann,
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 in der SKL-Datenbank hinterhängen, ist alles toll. Und wir haben auf einmal irgendwie meinetwegen IoT-Daten, Geodaten, irgendwas, die in hoher Frequenz beschrieben werden. Da müssen wir uns überlegen, gut, wie verwalten wir den ganzen Spaß eigentlich? Eignet sich dafür meine...
der SQL-Datenbank. Da kommen die Sachen von
der IoT-Sache einfach rein und der User
liest halt auch sehr. 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 dann muss ich überlegen, gut, wie gehe ich
jetzt damit um?
Normalerweise sollte
das gar nicht
so viel langsamer werden, oder?
Wenn du schreibst, klar
aber gut
Also zum Beispiel Postgres lockt jetzt
nur die Zeile, wenn du schreibst und wenn du jetzt
ein neues IoT hast, dann hat der neue Zeile drauf
das heißt der Nutzer kann ja alle anderen Zeilen zum Beispiel
lesen
Ja, also ich meine
Aber es kann natürlich schon passieren,
dass Schreiblast irgendwann
dein System langsam macht.
Aber auch meine Frage wäre halt,
wie häufig kommt das denn vor,
dass man so skalierbar, oder ich würde sagen,
ja, es gibt einen validen Grund, Microservices
aus Skalierbarkeitsgründen einzusein, aber wie häufig kommt denn das vor?
Nein, aber nochmal kurz zu
fragen, 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, der in Flaschen heißt
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.
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.
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.
und Jochen unterhalten sich über die Programmiersprache Python
abarbeiten. 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.
Oder generell hochskalieren muss.
Ja, aber gut, da wäre halt die Frage, was ist...
Ja, also ja, ist alles valide, aber
was ist teurer? Die Architektur aufzuteilen oder
einen dickeren Server zu kaufen.
Ja, aber auch da
gibt es so sehr, sehr schöne Graphen.
Das ist natürlich
ein Monolith. Das ist sehr, sehr lange günstiger
als Microsoft. Das stimmt. Aber irgendwann,
irgendwann kann man zu diesem Punkt
kommen, wo es überproportional
teurer wird, sich größere
Hardware zu kaufen. Also erstmal steigt das
irgendwie sehr, sehr gradlinig.
Ich gestikuliere hier immer so rum,
aber es ist ja Podcast.
Also,
anschauen.
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 Kosten, weil
die Maschinen dann einfach wirklich
sehr, sehr teuer sind.
Also ich finde, das Problem,
was du gerade gesprochen hast, müsste man eigentlich nochmal 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.
und 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 du sagst halt, die Datenbank wird langsam, das verstehe ich nicht so genau,
weil
wie viele Verbindungen hat die denn dann offen?
Nein, aber
zum Beispiel,
du hast ja nur eine bestimmte Bandbreite zu deinen
Platten, wenn du es wirklich schreiben musst.
und Jochen unterhalten sich über die Programmiersprache Python
viel langsamer als sowas wie Redis.
Aber bei Redis ist halt auch, wenn du dann
das Ding ausmachst, dann sind deine Daten
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 die Datenmarkt sagt, deine Transaktion ist durch, dann ist das wirklich
das Klassikland. 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.
und Jochen unterhalten sich über die Programmiersprache Python
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 lässt du ja eh noch auf dem Speicher. Das ist ja egal.
Das I.O. ist ja nur
das CPU.
Ja, das ist sowieso immer
im Hauptspeicher.
Das ist immer im Hauptspeicher. Das ist wirklich so.
Und das Einzige, was halt da dein
Konzern ist, ist dann die CPU-Kerne, die halt damit
beschäftigt sind. Wie viele Prozesse
du offen hast. Das heißt, wie viel Gleichzeitverbindung
und ihr dürft dann in der Datenbank stehen.
Ja, also sagen wir mal so, in der Praxis
das, wo dir häufig
das System platzt, ja, ich sag mal so,
also das ist also Erfahrungswert aus der Praxis,
das, wo du dann merkst, okay, ich hab hier ein Problem,
wo ich irgendwie mit der Architektur
anfangen muss, was zu machen, ist,
dass irgendwann
deine Slaves mit der Schreiblast nicht mehr klarkommen.
Also deine Replikas, ja.
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.
und Jochen unterhalten sich über die Programmiersprache Python
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 bis an den Punkt,
wo es nicht mehr geht. Noch mehr Slaves?
Nein, die können es nicht mehr schnell genug
wegschreiben. Das ist 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 schaben.
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 sie dir später nochmal ab.
Die Frage ist natürlich, wie lange soll er drinbleiben, 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 dir das wegschmeißen und du musst auch überlegen, brauche ich alles?
Brauche ich alles, alles?
Du hast halt eine Latenz dann, ne?
oder nicht nur Latenz.
Vielleicht hast du auch einen Datenverlust unter Umständen.
Aber die Frage ist, kann ich vielleicht Daten verlieren?
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 hast
und einzelne Services dadurch umkippen
und du hast es jetzt irgendwie so ein bisschen entlastet
und
dass das
Replikations-Lag, wie Jochen sehr schön
gesagt hat, das wächst und wächst.
Dann stoppst du halt eine gewisse Zeit lang mal den Schreibprozess
und hast dann meinetwegen ein 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.
IT-Geräte müssen denn da gegeben haben,
damit das ein Problem wird?
Keine Ahnung, das muss man schon ganz genau wissen
Kommt drauf an, wie du das machst, wenn du am Ende auch arbeitest
Ja, aber letztendlich
diese Art von Problemen hast du natürlich immer
Chris Künthopp
für Datenbank
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 Kauf-Transaktionen machen
und es gibt halt
OLAP, also Online
Logistical Processing, das ist also
ein Data Warehouse irgendwie und
er sagte das mal sehr schön, also wenn jetzt die Leute
irgendwas machen und du schreibst halt Sachen, also
OLTP ist zum Schreiben gedacht und OLAP eher
zum Lesen,
wenn die jetzt irgendwie die ganze Zeit
diese Geschichten generieren, dann also im Grunde
jede OLTP-Datenbank
hat in sich so ein Data Warehouse,
das raus möchte.
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.
Dass es dann doch wieder um Datenbank ging
am Ende, bei der Frage, ob man
Microsoft an der Stelle macht.
Nein, das weiß ich ja gar nicht.
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.
Das Schöne ist, dass du quasi,
und das ist vielleicht eher der Knackpunkt,
das Schöne ist, dass man erkannt hat,
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?
Äh, 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
eine 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.
Ja,
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 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-Indent nehmen?
Nimmst du den hoch, ne,
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ße, dann
wird Microservices immer attraktiver.
Aber
auf der anderen Seite,
das ist halt irgendwie jetzt heutzutage
oft irgendwie so, das macht man halt so
und das ist halt jetzt irgendwie so.
Das ist so ein bisschen, da würde ich mir denken,
und so, na, ich weiß nicht.
Und ich meine, da gibt es ja auch
so einen schönen Begriff von
David Hanemeyer-Hansen,
den Rural Rails
Menschen, der sagte, der versuchte
den Monolith-Begriff
halt aufzuwerten, indem er dann noch ein Adjektiv
vorgestellt hat und nennt das
jetzt immer Majestic Monolith
sozusagen, weil
ich meine, wenn man jetzt halt ein kleines Team hat und
irgendwie etwas macht, was halt dann
ist halt das unter Umständen
halt deutlich effizienter, weil
auch einfach was bauen willst.
Genau.
Das ist ja auch sehr, sehr bekannt.
Wenn du jetzt gerade anfängst, dann fängst du
natürlich nicht mit Microservices an.
Du ziehst jetzt von null auf einen Code hoch,
hast ein kleines Team, vielleicht sogar ein großes Team,
das ist komplett egal, aber eigentlich
denkt man da erstmal monolithisch nach.
Einfach um vorwärts zu kommen, um wenig Komplexität
erstmal zu haben, weil die Komplexität, die kommt erst mit der Zeit.
Du bist halt jedes Mal noch einen neuen Klotz ans Bein irgendwie.
Und auch noch weitere Komplexität und
weitere Abhängigkeiten und Dependencies,
Wenn du halt einen neuen Service hast.
ist mitunter, auch dass die
nicht immer unbedingt leicht sind,
alle Prozesse zu parallelisieren.
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 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.
Wären wir ein bisschen positiver. Ist auch schön.
Ja, nicht negativ.
Es geht halt ein bisschen darum, wann das der Fall ist
und welcher Use Case dann wirklich
da für sorgen muss.
Ich denke auch, wenn man das dazu bringen will,
dass es ein
Ding, wie das helfen kann,
wenn man jetzt drüber nachdenkt,
ist halt auch so,
wenn man einen Microservice aufteilen will,
dann ist das ja auch ein sehr schöner Anlass,
darü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
Modularität, 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 will das gerne da raustrennen.
dann wäre halt eine gute,
die schlechte Strategie wäre halt
irgendwie sozusagen
einen JSON oder HTTP-API
irgendwie jetzt vor die Funktion, die die Notifizierung
gemacht, zu klemmen und das
halt auf einen anderen, irgendwo anders hinzulegen
und dann rufen halt aus einem Monolith
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 ganz 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,
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.
Auch um noch eine positive
und weitere Sachen aufzugreifen,
wenn man gerade in den Sinn kommt.
Oft ist es ja so, dass
ein Datensatz, eine Row,
sehr viele verschiedene Prozesse
durchläuft, um
in die Datenbank zu kommen.
Die wird von verschiedenen Prozessen genutzt,
manchmal transformiert, also die wird sehr, sehr oft
durchgereicht.
Das fiel mir jetzt gerade ein,
als Jochen gesprochen hat, wenn du das
jetzt auf einmal anfängst, den Microservices aufzuteilen,
dann musst du dir natürlich überlegen,
okay, wie gestalte ich jetzt den Weg
von 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 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 das 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-Bus 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, also diesen Message-Queue,
oder diesen Message-Booker dann halt, und wenn man den halt hat,
braucht man ihn, will man ihn.
Ja, also,
also, weil das ist ja auch die Independence-City,
und Jochen unterhalten sich über die Programmiersprache Python
und die Programmiersprache Python.
mehr, die wir in einer Anwendung
einbauen.
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
ich kenne,
das ist halt die Frage, also ich kenne das halt so, dass man das intern
in der Applikation vor allen Dingen macht.
Also das ist halt dann auch teils, die Dinge, die man
tut, teilt man halt auch in
Commands, Events und
vielleicht Dokumente gibt es halt auch Da gibt es den ganzen Enterprise Service wo es irgendwie wei ich nicht irgendwas Patterns seit die Frage ob man das braucht keine Ahnung Ich habe letztens mich da so ein bisschen mit besch weil ich mich da einfach mal interessiert hat
wie man denn sowas baut.
Da gibt es ja auch, das buche ich irgendwie auch in jeder
Episode irgendwie, oh,
hier liegt es rum, Architecture Patterns
bloß 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-Applikation
und bauen das dann halt immer weiter um, sodass
am Schluss bleibt halt auch so ein Service-Bus
übrig und das könnte
man dann theoretisch auch in Microservices
dann halt alles dann auslagern,
was man da so tut. Aber
das eigentlich, würde ich sagen, so ein bisschen
die Voraussetzung dafür, dass man das überhaupt kann, ist,
dass man es intern schon so macht.
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
HTTP oder JSON-RPs hast, dann machst du halt
jedes Mal zum Beispiel so ein TLS-Handshake oder
sowas, das ist natürlich extrem
also es verbraucht immer CPU
Ja, du kannst halt ein Socket aufhaben
oder so. Ja, wie
bei HTTP? Nein, nein
einfach kein HTTP, sondern du hast halt
ein Socket auf, irgendwo in der Verbindung
Ja, okay, und wie sicherst du die
irgendwie ab und welchen Standard
wie machst du das? Keine Ahnung, also wie
WebSocket genau 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 ein Socket auch machen, wenn ich
jetzt auch so ein Queue-Ding habe,
beispielsweise. Genau, das ist der Vorteil bei der Queue,
da steht deine 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
vermindest 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
HTT oder so? Nee, also die Frage wäre,
wenn ich jetzt so einen Bus nehme, also warum mache ich das
bei Microservice? Also warum mache ich das nicht trotzdem in meinem
Monolithen oder so? Ja, genau, da würde ich sagen,
so würde ich anfangen.
Ich würde es so anfangen, dass man das zuerst so baut,
und Jochen unterhalten sich über die Programmiersprache Python
Das brauchst du ja nicht.
Wenn du es intern machst, brauchst du das ja nicht. Das ist einfach nur ein Funktionsaufruf.
Da ist eine Queue. Einfach zum Beispiel
in Python ist das halt einfach nur eine Queue-Modell.
Also
von Queue über Queue sozusagen oder so.
Und dann machst du halt, solange irgendwas in der Queue
drin ist, rufst du Funktionen auf.
Das war's. Das ist auch nicht...
Kann man durchaus machen.
Habe ich zum ersten Mal von tatsächlich.
Das ist so ein Python-Ding.
Genau. Queue.
Es hat aber nichts mit Netzwerkverbindung 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
also, wie man das
die Struktur aufteilt und die Architektur von
dem 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
Moduliten hat und das ist tatsächlich
ich fürchte,
das ist halt das, was ich in der Praxis oft sehe.
Ja, dass Leute halt eigentlich
in so einer Situation sind,
sie haben einen Big Ball of 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 stürzen sich auf Microsoft und sagen so
Ja, okay. 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, ne?
Also die anderen funktionieren irgendwie weiter,
da ist dann irgendwie, weiß ich nicht, läuft in einer separaten
in einem gleichen...
Alles in einem Thread im gleichen Prozess.
Das Einzige,
was es halt sozusagen bringt, ist,
dass ich die Sachen halt sauber
voneinander getrennt habe. Ich mache halt auch
immer, wenn ich irgendwas schreiben möchte,
mache ich halt ein Command und
ich habe halt dann meine Event-Händler, die alles mögliche machen.
So zum Beispiel habe ich halt einen Event-Händler,
der schickt das Event dann auf den Websocket raus
für irgendeinen Client, einen anderen Event-Händler,
der tritt
irgendwie einen Prozess los, einen anderen
so. Und das kann ich ja,
aber das ist alles nur Funktionsaufrufe, die
nacheinander passieren. Das ist aber alles im gleichen Prozess.
Okay, also für mich so zum
Verständnis. Vielleicht ergibt sich ja dann so
die Möglichkeit, dass wir alle erkennen, okay, wir brauchen unbedingt
Kafka.
Yay!
Nein, aber nur, damit ich das
verstehe, nehmen wir jetzt mal an, wir sind jetzt in der Django-Anwendung
unterwegs und wir schicken
einen Request rein. So, und der kommt jetzt in die
Queue. Die erste Frage ist, was
passiert beim User? Bekommt er sofort die Antwort zurück
oder wartet er darauf, dass der Prozess von
und Q 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.
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 reinpickt.
Was man schon zurückbekommt, ist,
dass das Command durchgegangen ist.
Also sozusagen man wartet bis,
also ein Request kommt rein
und dann erzeugt
und
Events abgearbeitet wurden.
Wenn das ganze Ding fresh ist, ist es vorbei.
Dann ist es weg.
Das heißt, wir haben jetzt nicht irgendwie...
Okay. Ja gut, aber wenn...
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 der 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 soll nicht so lange auf diese API
und Jochen unterhalten sich über die Programmiersprache Python
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 Lösungsvorschlag...
Wenn du es weggeschrieben hast, dann hast du zwar noch nicht die Queue durch, aber du hast ja 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.
Das dauert nicht lang.
Ja, aber vielleicht doch zu lang.
Na, glaube ich nicht.
Also wenn du irgendwie...
Ich habe gerade 30 Millionen Nutzer, die da draufschreiben.
Ja gut, aber das soll ja 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 Sonderprozess.
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 Rabbit und Q oder
irgendwas anderes ist ja letztlich, fand ich einfach nur interessant gerade.
Ja.
Also, wie gesagt, das war mir jetzt neu.
Ich meine, da tun sich viele Fragen auf, die mit dem eigentlichen Thema nichts zu tun haben.
Also wie gehe ich mit Exception um?
Azure Service Bus hat zum Beispiel einen Exception-Deadletter-Queue.
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.
Du brauchst ja für jeden Microservice eigentlich so ein eigenes Fehlerhandling auch.
Ja, ein bisschen.
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.
Also ich meine, ja, beim Konsumenten
meinte ich jetzt,
wenn du eh die Dependency hast,
dass du irgendwie einen hast, der das konsumieren will und dann halt Sachen macht,
gut, das Fehlerhandling brauchst du sowieso,
je nachdem, was da drinsteckt, aber du hast natürlich
meiner Meinung nach, wenn du
Microservices hast du eine größere
Anzahl an Fehlerquellen.
Es wird halt viel komplizierter. Du musst dich halt
über all diese Dinge Gedanken machen im einzelnen Prozess.
Musst du das nicht. Da ist das alles egal.
Da machst du halt ganz normales Exception Handling
und da brauchst du all diese Dinge nicht.
Was passiert denn mit Retry und gucken?
Das hast du auch da und lebst 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
eben, 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
D-Bagging ist schon super schwer.
Weißt du, dass da was Falsches drinsteht?
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.
Das ist jetzt
so ein sehr, sehr einfacher Fehler. Es kann natürlich sein,
dass ein falscher Nutzer
in deinem Datensatz drin steht und dein Service kann das
nicht überprüfen. Aber da sind wir dann wieder
bei der Herausforderung
des Datenmanagements. Also wie gestalte ich
das richtig? Wie gestalte ich das gut?
Wie kann ich solche Sachen vermeiden? Wie synke
ich vielleicht meine verschiedenen Datenbanken?
Das ist dann wieder so ein eigenes Problemchen.
oder großen Problemen.
Ja, aber das ist wie bei Dependencies.
Ja, wie sagt man so schön,
irgendein Tod muss man sterben.
Das 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 hinhören können
und den trade-offen gegen den Overhead
von, ist das 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, das kann ich jetzt,
ist jetzt auch nur eine gefühlte Sache,
sozusagen so kompliziert,
wie wir hier gerade reden,
ist das in der Realität gar nicht.
Also
wenn du jetzt überlegst, ich will jetzt
zu Microservices rüber migrieren, ich habe einen
funktionierenden 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.
Technischen Appiel, aber für den Kunden bringt das ja jetzt erstmal nichts.
Aber gut, ich verstehe schon.
Das, was ich vielleicht finde, ist, dass wir relativ kompliziert wurden,
habe 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 mal ein bisschen neben, was Jochen gesagt hat.
Die Frage ist, wann braucht man das überhaupt?
Du brauchst halt wirklich einen Fall, wo du dich auskennst und wirklich weißt,
Braustest, das kannst du nicht anders lösen,
bevor du überhaupt die Entscheidung treffen
würdest, da machen wir jetzt ein Microsoft-Draus, weil ich glaube,
vorher muss man erstmal andere Sachen
korrigieren oder so. Ja, also
ich meine, das klingt
jetzt alles schrecklich oder klingt jetzt, wenn ich
ähm, alter Sack.
Irgendwie, ich habe aber früher,
wenn Leute sowas gesagt haben, war ich immer so, ja, ja.
Aber tatsächlich, so Erfahrungen
zu, also oft ist es irgendwie,
dass, also ich
habe das Gefühl, dass das Problem in der
Praxis 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.
Vielleicht die falsche Analogie,
und Jochen unterhalten sich über die Programmiersprache Python
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.
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...
Ohne mal zu der Barth-Analogie zurückzukommen, dann hast du
halt entweder eine Mosaikwand oder
du klebst halt alles mit einem Kleber drüber,
und 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 Handwerksgrund ist natürlich schon sehr wichtig.
Ja, oder ich weiß nicht, vielleicht ist das auch ein blödes Beispiel,
oder 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, sozusagen dieser Modellisierungsbereich
da habe ich das Gefühl
Es gibt schon die kleinen Kinderkunden, die relativ viel
Kraft machen und nennen das so
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
irgendwie so ein O'Reilly-Buch, wo drauf steht
It Depends.
Absolut.
Ich bleibe
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.
Das ist auf jeden Fall ein gutes Argument,
wenn man Geld für mich verdienen kann.
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,
wir müssen nichts neu durchsortieren,
wie der ein bisschen Sales und Marketing machen kann.
Ja, aber das ist halt so ein bisschen,
das ist halt auch das gleiche Problem wie,
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.
Gesundheit ist schwierig
wenn man eine schwere Krankheit
bekommt oder so, dann hat man ein Problem, das sehr schwer
lösbar ist, wo man nicht viel machen kann
das produziert halt den ganzen Markt von
Pseudo-Snack-Oil, weiß ich nicht
Quacksalbern
Computersicherheit, schwieriges Problem
auch da
entsteht so eine Branche von
etwas halbwegs
zielrichtigen, weiß ich nicht genau
manche sind gut, manche sind nicht so gut
Also habe ich schon gesagt, dass du ja durch eine Firma betreibende Organenergie 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 gelöst haben.
Ja, Stundenbesatz aufzählen oder halt so eine 0109-Hängernummer 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.
das ist halt wie, weiß ich nicht, gibt es die ganzen
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
nee, es gibt da schon durchaus
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
alles.
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 mal jemand fragen, der sich damit
auskennt, bevor man
zum Beispiel mehr Änderungen 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? Haben wir alles gesagt von Microservices?
Fällt euch noch was ein?
Bestimmt nicht
Ich habe noch eine andere Frage, aber das hat nichts mit dem Pix zu tun
aber ist an 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, Jochen, was waren das?
Ah, okay
Ja, also das ist etwas
das mich ja auch
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 gerne
ins
Hosting-Geschäft einsteigen
Ja, ganz sicher
Ja, genau
und eine Frage, die mich dann beschäftigt hat
also gerade Podcast-Hosting, ich meine, wir betreiben
unsere eigene Podcast-Hosting
tatsächlich und
da sind etwas spezielle Anforderungen
die Files sind groß
Ja, Files dürfen schnell Files dürfen
und genau, und die Frage ist jetzt, okay, wir können...
Mit Python oder nicht? Ja, mich ärgert, dass wir da so eine Abhängigkeit haben, wir machen das über
ein CDN, über CloudFront und
das ist auch teuer irgendwie.
Erstaunlich teuer. Und
die Frage wäre, kann man das nicht selber machen, weil wenn man irgendwie... Ich miete ja sowieso
Server, auf denen ich den Hum deploye und da ist der Traffic
frei, warum kann man dann nicht die Server auch mit
ausliefern, mit Minio oder sowas. Ja, oder einfach
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 hier geht es um den Fall
zum Beispiel, man editiert halt irgendwie
eine neue Podcast-Episode zum Beispiel
und dann sollte das ja, sollte zum Beispiel
die Audio-Inhalte nicht für jeden sofort
verfügbar sein, sondern erst, wenn das frei veröffentlicht
ist, ja, sozusagen. Also nur wenn man
authentifiziert ist. Wie macht man das denn?
Das geht ja quasi gar nicht, wenn ich
auf dem statischen Files-Server hätte, dann sobald die Files
verfügbar sind.
Von dem Link dann, ja.
Ist jetzt ein Detailproblem eigentlich,
aber mir geht's, also wie wäre das denn,
wenn ich das für andere machen wollen
würde? Die haben ja eventuell auch noch
irgendwie so Anwendungsfälle, wo
sie Sachen vielleicht nur nicht öffentlich
veröffentlichen wollen, also eine ausgewählte
Gruppe von Leuten.
Also wie soll denn Authentifizierung funktionieren?
Dann gibt's dann halt diese ganzen Geschichten mit,
man schickt halt
sozusagen ein Request an den
Fileserver, und da ist halt irgendwie ein Cookie gesetzt oder halt ein Token oder da ist irgendwas in der URL, was signiert ist, und dann der fragt nochmal einen anderen Service und guckt halt nach, ist der jetzt authentifiziert?
Fragt der Microservice?
Bitte?
Fragt der Microservice?
Ja, genau, da hat man dann auch schon so eine Art Microservice oder man schickt halt den Request zum Applikationsserver, der Applikationsserver 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?
Irgendwie so. Ja, genau.
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 Applikationsserver ausliefern würde.
Und ich dachte eigentlich, geht doch. Django Static
Files quasi. Ja,
das gibt's schon. Also wenn
die Assets gemeint sind, also sowas wie
CSS und JavaScript und so,
da gibt's schon was für.
Nicht die Assets, sondern wirklich dann halt mit
Einzel-Single-Permission und
File-Off-Check-Level. Genau, da gibt es nichts.
Und das wäre aber interessant. Und eigentlich
dachte ich irgendwie, das müsste mit Python auch gehen.
Python-Icing-AO, da gibt es 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 es geht auch.
Dein Benchmark hat festgestellt, Keddy ist viel schneller.
Ja, genau.
Dann habe ich irgendwie jetzt ein anderes,
weil ich mich interessiere für Kochen und so.
Dann gibt es so einen Rezeptmanager, Mili.
kann man sich auch mal angucken, ist ja nett.
Und das habe ich dann irgendwie auf meiner Infrastruktur deployed
und da gibt es auch viele Bilder und so.
Und dann dachte ich, ah, das mache ich bei Ubicorn, weil
wozu haben die dann noch extra
einen Caddy laufen?
Und dann habe ich dann auch in ihrem Discord Bescheid gesagt,
so, ja, warum macht ihr denn
da nochmal ein Caddy zusätzlich?
Das ist doch Quatsch, ihr macht das doch einfach über den Ubicorn.
Und dann hieß es, 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 Matchmark machen.
Ich hab ein Benchmark gemacht und gesehen,
stimmt doch, sie haben recht, ich liege falsch.
Auf jeden Fall
tatsächlich Nginx Caddy
viel schneller als
Ubicorn, beziehungsweise die
Fallresponsion von Starlet,
was halt unter FastAPI unterliegt.
Und das ist halt FastAPI Backend.
Ja, keine Ahnung, wo ans liegt,
ich weiß es nicht. Also sagen wir so, es ist immer noch schnell genug
für Gigabit Ethernet
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 10,
das muss doch eigentlich schnell sein. Keine Ahnung.
Also eine mögliche
Grundführung, warum das
so ist, den ich
denke, das könnte es sein, ist
es liegt daran, dass
irgendwie Caddy und Nginx
irgendeine Art von Serial-Copy-TCP verwenden.
wo 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
ein Pull-Request, 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 Colonel direkt
mal mal den Pull-Request kann, mal mal cherrypicken
mal gucken, ob dann...
Also das könnte noch ein Unterschied sein
das wäre dann halt ein relativ langweiliger Grund
und 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önnte man nicht sein File einfach verwenden,
das geht halt nicht, das geht halt nur, wenn es
tatsächlich ein File im Filesystem ist, glaube ich.
Auch da wäre interessant, wenn sich das jemand,
wenn jemand mir damit Bescheid sagen könnte, der sich damit auskennt,
ob das so ist oder nicht.
Hallo, Herr Paisenbocker.
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
Ubiquon oder Ubiloop
beim serbischen Pals.
Und ich weiß nicht warum. Keine Ahnung.
Aber es war 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. Selbst wenn es langweilig wird.
Nicht schlafen.
Ja.
Dann pickt ihr 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
bpytop
Ah, da.
Ich habe es hier laufen.
Oh, das ist hübsch. Das ist ziemlich hübsch, ne?
Ich weiß nicht, ob das Textual verwendet oder Rich oder irgendwas in der Richtung.
Aber genau.
Was ist das oder so?
Ja, das gibt einem so ein bisschen
Daten zu den, also
es ist halt top.
Ja.
Es gibt da so ähnliche Sachen.
Glances gibt es auch.
Ja, Glances gibt es auch.
Gtop, Htop.
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 es macht so große
JSON-Objekte irgendwie vernünftig.
Hast du noch einen Pick, Hannes?
Was genau soll ich denn picken?
Muss das einen Python-Kontext haben?
Nö, irgendwas Cooles,
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
zum Beispiel Write-Only-Prozesse und die werden
dann ganz ganz automatisch in einen Topic
reingeschoben, das nennt sich dann
Source-Connector ohne Code
Also 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.
Ja, das klingt gut. Also Next Level Kafka.
Mindestens.
Mindestens, ja.
Okay, cool.
Ja, vielen Dank, Janis, dass du hier warst heute.
Sehr gerne.
Microservices. Ich hoffe, es hat dir ein bisschen Spaß gemacht, genauso viel wie uns.
Bleibt uns gewogen.
Schaltet uns wieder ein.
Wie auch immer. Montag, Tag.
Dann bis demnächst.
Tschüss.