Transcript: Microservices

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode Nummer 41.

Heute unterhalten wir uns über Microservices. Schön, dass ihr wieder eingeschaltet habt.

Hallo Dominik.

Und wir haben einen Gast dabei.

Guten Abend.

Hi Janis.

Ja, das bin ich.

Hallo Janis.

Ich bin der Dominik.

Ich bin der Janis.

Ja, dann Janis, würdest du dich mal kurz vorstellen vielleicht direkt?

Ja, das geht schnell. Ich bin der Janis, noch 29 Jahre alt, jung, aus Wuppertal.

Ich entwickle mit Python viel und oft und gerne.

Bereich Data Engineering, Data Science, irgendwo da bewege ich mich rum.

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

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

Ja, genau, machen wir das wie immer.

Was hast du denn?

Ja, ich weiß nicht, so ein bisschen wild gemischt ist auch nicht nur Python,

aber ich dachte irgendwie, gut, das hat schon eine gewisse Relevanz,

weil, ich weiß ja nicht, aber vielleicht gibt es

ja auch sogar Leute hier in der, zuhören

oder dabei sind gerade, die irgendwie davon betroffen

sind. Es gab da so eine Sicherheitsschwankung

bei Okta. Ja.

Ich weiß nicht, wen du meinst, den Betroffenen immer.

Keine Ahnung. Ja.

Ja, also das

ja, fand ich, war mal

wieder so ein... Also Okta ist so ein Multi-Login-Service,

Single-Sign-On.

Ja, genau. Und viele

Kunden, viele Konzerne sind da Kunden und so

und eigentlich war

war sozusagen die Marketing

Story dabei, halt irgendwie

ja, du musst irgendwie keinem

vertrauen und das funktioniert einfach so und das

löst das Problem für dich und jetzt mussten die Leute, die das

irgendwie, die diese Dienstleistung

in Anspruch genommen haben, feststellen, dass sie doch jemandem

vertrauen mussten.

Und dass sie dem eigentlich nicht wirklich vertrauen können,

weil die Kommunikation war halt so, dass sie irgendwie nur

so scheibchenweise zugegeben haben, was da eigentlich passiert ist.

Tja. Und das ist natürlich

schlecht.

Ja, das ist also, ich würde auch sagen,

ziemlich beschädigt jetzt.

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

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

Und dieses Single-Sign-On, da kann man dann, glaube ich,

die Policies vielleicht ein bisschen besser einhalten

und die Leute dazu zwingen, dass sie so ein bisschen mehr darüber nachdenken,

was sie tun. Ja, gut, Single-Sign-On

verstehe ich auch irgendwie, aber ich verstehe nicht so richtig, warum man

dann... Ja, wenn man da keine Kapazität hat.

Stimmt, wenn man das selber machen muss, dann ist es auch wieder

schwierig.

Ja, also das war auf jeden Fall, denke ich,

ein großes Ding, was irgendwie in der letzten Zeit passiert ist.

Ja, ich habe auch für Okta tatsächlich so ein Dango-Modul

geschrieben, mit dem das dann doch irgendwie geht, aber

das ist halt auch nützlich, wenn Okta kaputt ist.

Ja.

Ja, doof.

Ja. Menus.

Dann, ah, oh,

gibt's einen,

wir hatten ja schon mal diesen Tiobe

Programmiersprachen.

Ach, der spannende große Index.

Index, ja, der immer so zitiert wird.

Wo man dann irgendwie, wenn man genauer drauf schaut,

sehen muss, oh, die gucken nur, wie die

Menge der Suchergebnisse bei so ein paar Suchanfragen aussieht.

Und das ist ja alles irgendwie,

wie viel das so sagt, keine Ahnung.

Es gibt einen anderen, der macht sowas ähnliches.

Der heißt Peipel, Pippel?

Ich weiß gar nicht, wie der heißt.

Jedenfalls da ist Python auch momentan die

beliebteste Programmiersprache.

Insofern kann man sagen, es ist halt jetzt nicht nur

ein Service, der das halt sagt, sondern es gibt

mehrere,

die das halt unabhängig voneinander rausfinden.

Insofern gibt das ein bisschen mehr

Glaubwürdigkeit, dass da irgendwie was dran

sein könnte. Ja, es ist auf jeden Fall

Python sehr populär zur Zeit.

Sogar Meta hat

einen großen Beitrag an die

Python Software Foundation gespendet, habe ich mitbekommen.

in letzter Zeit? Ja, das sind

tatsächlich sehr gute Neuigkeiten.

Das ist ja eigentlich noch nicht so lange her, dass tatsächlich

die, also Python Software Foundation

irgendwie hatte bisher immer alles mögliche

um die Marke

drumherum gemacht

und so und

Rechtsbeistand und

solche Sachen für Leute, die das verletzen

und so, aber

sie haben halt eigentlich keine Entwicklung bezahlt

oder niemanden gehabt, der halt, es gab niemanden,

der sich Vollzeit irgendwie bezahlt, um

Python gekümmert

hätte. Und klar, es gab

Leute, die bei Firmen gearbeitet haben und dann zumindest einen Teil

der Zeit irgendwie dafür zur Verfügung hatten,

sich damit zu beschäftigen. Aber

jetzt gibt es seit,

ich weiß nicht, das ist jetzt schon seit zwei Jahren, glaube ich.

Wird auch verlängert.

Developer in Residence sozusagen. Und zuerst

hat Google den bezahlt. Und das ist ja

Lukas Schlanger. Macht das

sehr gut. Schreibt auch immer wieder

Blogposts, was er so tut.

Und jetzt quasi damit

bezahlt das jetzt erstmals auch Facebook,

was natürlich super ist. Und ja, vielleicht werden

ist ja nochmal irgendwann mehr Leute, also auf jeden Fall

wird es irgendwie mehr Geld, das ist ja schon mal toll.

Voll gut.

Also ich meine, eigentlich denke ich,

dass große Konzerne das ja eigentlich fast wie eine Art

Versicherung sehen können, weil

sollte man denken, dass sie das so betrachten,

weil wenn das

irgendwie nicht mehr funktioniert, dann haben die ein großes Problem,

was sie sehr teuer zu stehen kommen.

Das ist halt schwierig, so was zu vermitteln, dass du halt irgendwie

Dinge bezahlen musst, die in der Zukunft

eventuell einen Return on Invest geben und

oder halt auch nur ein Risiko abwenden.

Ja, aber dass das gerade

bei Open-Source, die kriegt man ja immer so umsonst.

Das reduziert ja meistens immer nur irgendwie die Kosten

auf einer Kostenstelle.

Ja, ja.

Ja, ja, das, genau.

Aber irgendwie geht's

da voran, das ist voll gut.

Was hat man noch? Oh, genau.

BugsPython.org,

das weiß ich auch, das ist auch schon seit Jahren.

Versuchen wir da irgendwie zu migrieren auf GitHub.

Ist aber noch nicht, nein, wir haben es verschoben.

Ach so, dachte ich, wir sind durch.

8. April, also quasi

bald, nicht übermorgen,

aber in ein paar Tagen.

Und zwar auf Wunsch von GitHub, weil die gesagt haben,

oh, wir haben Schwierigkeiten,

wir wissen nicht, ob das funktionieren wird,

wenn wir als alle so eine Menge Issues erzeugen und so.

Wartet lieber noch mal ein bisschen.

Okay, ja gut, das ist jetzt nicht mehr so lange hin.

Also ist jetzt quasi, wenn ihr es hört,

vielleicht schon migriert.

Oder kurz davor.

Und gestern am 4.4. ist tatsächlich

das Zeitentrack 20 Jahre geworden.

Das ist auch ein richtiger Meilenstein.

Hätte ich jetzt auch nicht gedacht,

aber das ist natürlich alles

irgendwie,

ja, Zeitgefühl, komische Sache.

Schon ein bisschen abgehangen, wie man alt wird.

Ja, aber Sighten ist total wichtig, super, also immer wenn man sich fragt,

okay,

ja, Python selber langsam, aber

macht trotzdem Dinge schnell und so,

wie geht denn das eigentlich? Ja, da ist meistens Sighten

daran beteiligt und

ja, tolles Projekt,

irgendwie man schreibt so eine Python-ähnliche

Syntax und das wird

dann halt in C

Cross-Compile sozusagen. Man kann auch C-Funktionen

Direkt laden, glaube ich, wenn man das möchte.

Ja, genau. Und dann kann man es wieder einbinden

als Python-Modul. Und dann gibt es sogar

sowas wie ein Cellmagic

in Jupyter Notebooks oder JupyterLab.

Und da kann man einfach sagen,

Prozent, Prozent, Zeiten. Und dann

wird das halt, wird eine Funktion

einfach so wieder reimportiert.

Und dann wird die halt tausendmal schneller oder so.

Das ist halt sehr schick.

Ja.

Ja, okay. Also apropos, kennst du

V, die Language?

V-Lang? V? Ja.

bin ich irgendwie letztens drüber gestolpert, weil ein Kollege

mich draufbrachte und

habe ich mal geguckt, kannte ich noch nicht, ist nur noch in so einer Beta-Version.

Sieht irgendwie witzig aus, so eine

Kombination von Rust

und Go irgendwie.

Ja, momentan ist auch wieder so die Zeit

für neue Programmiersprachen. Letztens

habe ich gehört von SICK.

SICK? Das ist auch so ein

toller, lustiger Name, dass das wieder so irgendwann drüber fällt,

aber den Namen direkt so.

Ja, das

sieht auch so ein bisschen aus wie eine Kreuzung aus Go

und JavaScript und

irgendwie Rust und

weiß nicht, ganz vielen Dingen.

Also ich habe es noch nicht reingeguckt, also falls ihr darüber was wisst,

das könnte auch interessant sein. Also wie lang

I.O.? Okay, muss ich mir auch mal

angucken.

Komplett auch zu zäh, deswegen kam ich

gerade drauf. Ach so,

okay, das ist auch interessant.

Ja.

War witzig.

Ja.

Ja. Okay.

Dann sind wir eigentlich schon fast,

das war diesmal schnell. Ja, wir haben

Ja, dann sind wir damit eigentlich durch.

Achso, haben wir eigentlich

Veranstaltungshinweise oder sowas?

Ja, das sollten wir. Achso, du wolltest

zur PyCon, bist du da?

Momentan sieht es nicht danach aus.

Ich hätte jetzt zufällig, also

zuerst hatte ich gedacht,

das schaffe ich

irgendwie nicht, beziehungsweise ich habe gar nicht so richtig mitbekommen,

dass das überhaupt stattfindet, also vor Ort,

weil das wäre für mich interessant geworden, aber

nicht vor Ort halt eher nicht so richtig,

weil das schaffe ich eben, das habe ich auch schon mal

probiert, wie Remote aufkommt.

Aber es funktioniert einfach nicht.

Du warst so eine halbe Stunde da und dann so, pa, pa.

Ja, genau. Und dann ist es halt vorbei.

Und das funktioniert einfach nicht.

Also, wenn das funktionieren soll, muss ich da irgendwo hin

und getrennt sein von irgendwie

anderweitigen Verpflichtungen.

Und da habe ich das halt nicht so mitgekriegt,

dass das tatsächlich vor Ort sein sollte.

Und dann habe ich es mitgekriegt und dann waren aber schon

Tickets. Und dann dachte ich, ich hätte gerne Zeit.

Und dann habe ich dann gemerkt, oh, ich habe vielleicht doch Zeit.

Und dann waren aber keine Tickets mehr da.

Also insofern, ja.

Na gut, wenn es darin lag. Aber vielleicht machen wir auch

nochmal eine Sendung oder so dazu, wie

das da gewesen ist, von Finden noch Leute, die da

waren und dann davon erzählen können. Ja, das wollen die mal fragen oder so?

Vielleicht sind die ja da. Genau, den habe ich schon gefragt.

Er hat sich auch schon gemeldet und weiter eigentlich auch.

Okay, cool. Also gibt es doch irgendwann

eine Pike und Folge. Ja. Ja, im Sommer

EuroPython-Tickets sind auch gerade draußen. Da gibt es

sogar noch welche von, glaube ich. Das war noch nicht so super

angelaufen, der Vorverkauf, obwohl die so schnell

immer weg waren sonst. Genau, da

in Dublin, also wenn ihr mit mir abends

in Dublin ein Bierchen trinken wollt. Da könnte

es auch gut sein, dass ich damit

würde ich gerne machen.

Ich bin gespannt. Und dann gibt es noch

die, also gut, dass es jetzt nicht mehr so

gemeint hat. Das Conference Center in Dublin ist

relativ nah an der Brewdog-Außenstelle.

Das ist ja kritisch.

Ja, genau.

Das Angenehme mit dem Nützlichen.

Ja, super Verbindung.

Genau, und im Herbst, irgendwann

September, gibt es die DjangoCon EU,

diesmal auch tatsächlich vor Ort und in

Porto. Die sollte ja eigentlich letzten beiden Jahren in Porto

stattfinden, aber hat es ja nicht.

Und genau da denke ich

ja wahrscheinlich leider nicht, weil

irgendwie so viele Konferenzen...

Ist Johannes da?

Habe ich noch nicht gefragt. Aber wer auf jeden Fall da ist,

ist Ronny. Ronny ist da, stimmt.

Das ganze Team ist da. Das ist natürlich ein bisschen schade.

Das wäre natürlich nett. Das wäre schön, ja.

Ja.

Naja. Ja, jetzt haben wir doch noch ein bisschen

News gemacht. Okay.

Gut. Dann kommt jetzt wieder der obligatorische

Werbeblock. Habt ihr das schon gehört?

Und diesmal ist Janis dran. Janis darf Werbeblock.

Ich darf Werbung machen, als Neuling.

Ja, wofür mache ich Werbung?

Ich mache Werbung für meinen Arbeitgeber.

Ich arbeite bei Elio.

Wir machen Consulting mit Fokus auf künstliche Intelligenz

und den Weg dahin, alles, was dazugehört.

Und ihr sucht neue Leute?

Wir suchen neue Leute, genau.

Wie hieß die Domain nochmal?

Ich versuche die gerade, Elio?

Elio.de, A-I-L-I-O.de.

Quasi AI im Namen, als Programm, wenn man so möchte.

Genau und wir suchen neue Leute, immer. Also es ist wahrscheinlich sogar ziemlich egal, wann du die Folge hörst. Wir suchen dich.

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

Wir haben einen Fokus auf künstliche Intelligenz, also Data Science, Machine Learning, Deep Learning, NLP. Das ist natürlich super interessant, wenn man sich damit schon mal auseinandergesetzt hat.

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

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

Das heißt, wenn Pandas dein Lieblings-Tool ist, ist das vielleicht auch interessant?

Welches Tool?

Pandas.

Pandas, ja klar.

Sicher, ist ja Data Science, ne?

Ja, Data Science und Python passt natürlich eigentlich schon ziemlich gut zusammen.

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

Eigentlich sitzt ihr im Bielefeld, sehe ich gerade.

Genau, wir sitzen im Bielefeld.

Remote-Arbeit. Ich arbeite

sehr viel remote. Wir haben immer

so einen Stammtisch irgendwie, damit man sich doch auch mal

in Person sieht. Aber rein

optional, sage ich jetzt mal.

Insofern

sind wir gespannt. Das klingt gut. Also falls

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

Ich würde mich freuen. Klingt, als wären es nette Jungs

und Kollegen. Mindestens einer.

Mindestens.

Ja, vielleicht auch mehr.

Ich habe davon gehört. Du musst jetzt noch persönliche

Coachings und Benefits anbieten von dir

aus, damit das dann... Ja, würde ich natürlich

machen. Also wenn du Hörer der

Folge bist und so begeistert

von mir bist. Genau, dann gibt es einen Aktionskurs

Jan.

Schreibe mich an.

Genau, eine E-Mail-Adresse und eine Internetseite

gibt es auch, ljo.de, business.ljo.de

da könnt ihr euch gerne hinbewerben.

Ansonsten gibt es bestimmt auch irgendwo so einen

Text, wo man sowas verlinken kann bei euch im Podcast.

Ja, und vielleicht genau, wenn man sich meldet, dann

dazu sagen, dass das über

Python-Podcast, dass man sich da das

gehört hat, weil dann kann man das vielleicht so ein bisschen

irgendwie

verfolgen. Da habt ihr auf jeden Fall bessere Chancen,

da wissen wir auch, dass ihr interessiert seid.

Keine Ahnung,

ob das irgendjemand hört,

der auf der Suche ist.

Ich glaube tatsächlich, das hat einen Wert. Also ich wurde mal

gefragt in einem Interview,

welche Bücher und Podcasts ich so empfehlen kann.

Das war ganz lustig.

Python-Podcast ist mir vielleicht in den

Sinn gekommen, vielleicht auch nicht.

Ich wurde tatsächlich auch im Arbeitskontest

von jemandem angesprochen.

Also ein Projektmanager war, der für ein

größeres Projekt irgendwie gehört hatte,

was da so gibt und der einen Danko-Podcast von uns gehört hat

und dachte so, oh cool, da warst du nicht der Typ mit dem Podcast.

Ja, interessant.

Das hilft manchmal, ne? Also das ist schon cool.

Genau. Ja, schick. Okay. Super.

Hört mal rein. Ja. Wenn ihr was sucht,

wisst ihr jetzt wo. Oder nichts sucht

und doch zu uns wollen, ne?

Man weiß ja nie.

Ja. Okay, genau.

Dann, ja, Thema diesmal

Microservices.

Ja, also ich habe ja wie immer keine Ahnung

und will erst mal, was ist denn überhaupt so ein Microservice?

Ja, was ist das denn? Wer soll das

dann erklären? Ja, keine Ahnung.

Möchtest du anfangen oder so? Ich kann gerne anfangen.

Also es gibt relativ harte Definitionen

darüber. Ich bin da kein Freund von.

Also im Prinzip ist ein Microservice erst mal

etwas, was wenig Sachen macht,

aber dafür sehr gut. So würde ich es beschreiben.

Man stellt es ja ganz gerne

mal so einem Monolithen gegenüber und wir

haben schon vorrangig überlegt,

wollen wir jetzt so ein Versus-Ding machen oder nicht?

Schauen wir mal, was das wird. Aber ich weiß nicht, vielleicht, wenn man Selbstentwickler ist, man kennt das ja, man hat irgendwie tausend Funktionen, die man gerne in einer Anwendung hat. Und dann überlegt man halt häufig, wie man das gestaltet. Und der Microservice-Ansatz ist eben, dass man viele einzelne Funktionen in verschiedene Codebasen auslagert mit eigenen Tech-Stacks und ganz wild und ganz toll und hoch skalierbar. Und erstmal ist alles cool in Microservices.

Okay.

Das ist die Meinung von Janis.

Ja, okay.

Da haben wir schon die Seiten geklärt.

Ja, ganz so ist es nicht.

Das ist ein bisschen plakativ.

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

Ja, aber das ist doch genau spannend jetzt.

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

Genau.

Wenn ich jetzt eine Anwendung habe.

Wir tun jetzt mal so, als wäre es eine Web-Anwendung.

Vielleicht ist das am einfachsten zu verstehen.

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

Aus dem jeweils einzelnen Microservice, würdest du sagen, das ist eine gute Idee?

Es gibt verschiedene Ansätze, das ist Thema Best Practice, sag ich jetzt mal, und auch immer so ein bisschen ein Thema der Architektur.

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

Man kann sich natürlich verschiedene API-Endpunkte suchen

und alle einzeln anfragen.

Das ist, würde ich sagen, aber keine gute Idee.

Da gibt es dann meistens API-Gateways

beziehungsweise eine Schnittstelle, die man anfragt,

die verschiedene Endpunkte sammeln.

Genau, darüber hatte ich eben auch schon mal, glaube ich,

ganz kurz mit Jochen gesprochen, weil es ja genau darum geht,

also wer ist dann die Spinne im Netz?

Wovon bekommt man das, wenn man jetzt ein Frontend hat?

Sollte das Frontend die einsammeln einzeln

oder holt man das von so einem Gateway ab?

Oder wie macht man das am liebsten?

Ja, keine Ahnung.

Also ich glaube, wenn man das wirklich konsequent machen wollen würde,

dann müsste man ja auch im Frontend das sozusagen

Mikrofrontends

müsste man machen.

Da muss ich halt

ehrlich sagen, ich mach kein Frontend.

Wer liefert denn das Mikrofrontend aus?

Also wenn man zum Beispiel in HTMLX das ausliefert,

dann wäre ein Django ein sogenannter Spinne

oder so ein Aggregator, ein Gabi-Gateway,

wo ich jetzt das Wording da immer nicht ganz

treffen würde, ehrlich gesagt.

Das spielt dann letztlich ja

keine große Rolle mehr,

weil du musst ja dann, das wäre nur noch eine statische

Seite. Also was ich mir jetzt halt da kompliziert

darin vorstelle, ist, wenn ich so ganz viele verschiedene Zeug habe,

aber ich habe ja eigentlich nur eine Anwendung, warum mache ich das

nicht in der einen Anwendung direkt und habe dann diesen

ganzen Gefummel mit dem ganzen

drumherum nicht? Darüber wollen

wir ja reden, ne? Ja. Also

das ist ja das Ziel der Folge, eine kurze Folge, wenn wir das jetzt

so einfach und so schnell machen. Ein Satz fertig, ja,

danke schön, ja, heute haben wir euch nicht so lange.

Nee, ganz so ist es natürlich nicht. Man muss halt

auch immer sehen, welche verschiedenen Funktionalitäten

man haben möchte, ne? Wir sind jetzt im Bereich

Web unterwegs, ne, von deinem Beispiel.

Das klingt erstmal sehr, sehr einfach,

Ich meine, so eine Standard-Firmen-Webseite meinetwegen mit einem Kontaktformular, da braucht man keine Microservices für, das stimmt schon. Aber wenn wir jetzt zum Beispiel mal eine Kurs-Webseite meinetwegen sehen, wo wir ein Empfehlungssystem, wir haben so ein Dashboard, wir haben einen Nutzerbereich, wir haben einen Content-Creator-Modus, da werden die Sachen schon komplizierter.

Wir haben ganz viele verschiedene Sachen, die ineinander greifen, die ineinander funktionieren müssen und da muss man natürlich überlegen, wie gestalte ich das designtechnisch, wie gestalte ich die Suchfunktion und so weiter und so fort und kann ich das überhaupt in einem einzelnen Django-Monolithen gewährleisten meinetwegen oder ist es vielleicht manchmal einfacher, einen eigenen Service für etwas zu schreiben.

Also genau, vielleicht einfach hake ich an der Stelle mal ein

und sage mal so etwas, was ich denken würde,

was Microservice ist.

Und ich würde denken, der entscheidende Punkt dabei ist eben

die Einheit, wie deployed man das.

Also alles, was man,

wenn man es insgesamt, wenn man es halt getrennt

deployt, dann ist es halt ein Microservice, würde ich

jetzt mal so sagen.

Oder getrennt deployen kann

und also wenn es halt irgendwie,

wenn die gesamte Applikation

etwas ist, was man insgesamt deployt, dann ist es halt

irgendwie eher Monolith.

Und eben, Microservice hat halt den Vorteil, du kannst halt da

unterschiedliche Technologien ausprobieren, du kannst halt

unterschiedliche Sprachen verwenden, man sagt mal auch immer, man sollte

das halt so machen, dass man da quasi

unterschiedliche Sprachen verwenden kann,

dass sie halt möglichst irgendwie

ja, ihre eigene Datenhaltung

irgendwie haben oder zumindest ihre eigene Sicht

auf die Daten und da ist man dann halt schon

so ein bisschen bei dem, ich weiß nicht, diesen

Domain-Driven-Design-Ansatz, da gibt es

immer diesen Begriff

Bounded Context und das ist halt immer so das, was man

so, ja, das ist klassischerweise

Bounded Context.

Jetzt musst du wieder erklären, was Bounded Context ist.

Ja, das ist quasi so Dinge, die halt irgendwie so zusammengehören und nur gemeinsam verändert werden sollen. Ich glaube, das Standardbeispiel auch eben aus dem Designbuch ist halt sowas wie eine Bestellung und die Punkte, die einzelnen Positionen auf einer Bestellung oder so will man vielleicht, das Ding will man immer zusammen verändern.

Das heißt, man holt das insgesamt aus der Datenbank, macht irgendwelche Änderungen und streibt es halt in einer Transaktion wieder irgendwie in die Datenbank rein oder so. Und das ist halt sozusagen ein Baune-Kontext eben.

Ja, das ist aber eine spannende Frage. Also was gehört halt dazu oder nicht? Also bei einer Bestellung und deren Position geht es vielleicht noch. Aber wenn du jetzt an den zuständigen Sachbearbeiter beispielsweise denkst, der irgendwie im Innen- oder Außendienst hängt, ist die Frage, gehört das dann zum Baune-Kontext da dazu oder holt man das aus einem CRM?

Ich glaube auch, dass der Grund,

vielleicht der Name, das kommt daher, dass es halt

unterschiedliche Dinge in unterschiedlichen Kontexten

bedeuten kann. Also zum Beispiel User ist halt

was anderes, wenn du dich auf einer Webseite einloggen

möchtest oder kann halt was anderes sein

als User oder

Personen, an die irgendwas geschickt wird

im Kontext einer

irgendwas Bestellung oder

so. Und in dem einen Fall hat man halt da

komplizierte Adressgeschichten und weiß der Teufel

irgendwie Zeugs und im anderen Fall braucht man das gar nicht, weil

da muss man nur überprüfen, stimmt der Passwort

Hash oder so und

ja, je nachdem, welchem

Kontext man unterwegs ist, ist

das halt unterschiedlich und man erlaubt

dann halt auch unterschiedlichen Kontexten

die Daten unterschiedlich zu halten und unterschiedliche

Sachen zu speichern und so. Okay, interessant, also

Bounded-Kontext abstrahiert das so ein bisschen.

Was aber jetzt dafür sprechen würde, in dem Beispiel, was du gesagt hast,

braucht man ja irgendwie eine

Wahrheit der Daten, wenn das

ja, das ist dann glaube ich,

dann wird es ein bisschen schwieriger.

Single Point of Truth,

das ist eine Herausforderung.

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

wer leistet man den in Microservices?

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

Entschuldigung, dass ich euch gerade direkt einhabe,

aber was heißt Datenmanagement?

Ein Microservice beziehungsweise Microservices allgemein

zeichnen sich ja dadurch aus, dass das isolierte Systeme sind.

Also im Idealfall hält jeder Microservice genau die Daten,

die er braucht oder eben nicht.

Und wenn er die Daten nicht hält,

muss er natürlich überlegen, woher

kriege ich meine Daten eigentlich? Und wie kriege ich sie?

Und dann gibt es eben

verschiedene Möglichkeiten, damit umzugehen.

Ich könnte zum Beispiel mal irgendwie hier AP-Request

gegen irgendeinen anderen Microservice machen,

meinetwegen, und hole von da meine Daten.

Habe dann aber den Nachteil, okay, das ist langsam

und irgendwie kopple ich meine Microservices dann wieder zusammen.

Genau, wenn es hinterher dieselben Datenbanken

liegt, dann ist da die Frage, warum

macht man da eine unterrichtliche Architektur?

Aber vielleicht kann auch das so machen, wenn ich halt irgendwie hingehe

und möchte aus derselben Datenbank

Dinge erzeugen mit unterschiedlichen Sprachen

und die dann... Ja, nicht dieselbe Datenbank.

Genau, und dieselbe Datenbank wird schwierig,

weil dann kannst du es halt nicht mehr getrennt voneinander deployen.

Also wenn du jetzt zum Beispiel auf der, wenn du es in gemeinsamen

Datenbank hast und du änderst die jetzt...

Na gut, er kann ja einfach den Datenbank-Link deployen.

Also die Datenbank kann ja noch ein dritter Punkt sein,

der ganz unabhängig von den Services läuft.

Ja, aber da kannst du es nicht mehr unabhängig

deployen, weil wenn du jetzt die Datenbank änderst,

dann hat das ja Auswirkungen auf den anderen.

Hat das ja auch Auswirkungen auf die anderen Services.

Ja, und es ist ein Single-Pointer-Failure.

Also da rede ich aus ganz, ganz schmerzhafter Erfahrung.

Wenn verschiedene Services an einer Datenbank hängen,

verschiedene Microservices, und die Datenbank kippt um,

dann kippen dir die Microservices auch um,

weil irgendjemand Stoß gemacht hat.

Das will man eigentlich auch vermeiden.

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

Das macht man manchmal, weil es einfach schnell ist,

weil es einfach einfacher ist.

Aber wenn man wirklich Microservices macht und sie wirklich braucht,

dann ist das eigentlich mal eine relativ schlechte Idee,

wenn man sich da doch, wie gesagt, den Single-Point-of-Fail reinholt.

Aber ja, eigentlich hat jeder Service seine eigene Daten,

seine eigene Datenbank.

Und du musst halt überlegen, okay,

will ich jetzt mehrfach die gleichen Daten

in verschiedenen Microservices verteilen?

Oder will ich dafür sorgen, dass sich die einzelnen Microservices

die Daten von anderen Microservices holen

und erzeuge damit eine Kopplung

und mache die Sache vielleicht ein bisschen unübersichtlicher,

vielleicht ein bisschen langsamer?

Und das beschreibt eben das Datenbankmanagement.

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

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

Also wo kommen die Daten überhaupt her?

Und wo sollen die hin?

Und dann, ja, also die Frage ist,

ist das eine Architekturentscheidung, wenn du jetzt sagst,

Design, Domain-Driven-Design?

Was würde denn da...

Damit sind noch keine Architekturentscheidungen gefallen quasi.

Damit ist es halt einfach nur so ein Konzept,

wie man Dinge angehen könnte.

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

Also die Wahl.

Ja, also ich weiß es nicht.

Das ist halt die Frage, ob man, tja, also in der Vorbereitung habe ich jetzt mal so einen Podcast auch gehört, da gibt es irgendwie ein Buch, das immer empfohlen wird zu Microsoft, von Simon Newman.

Und der ist auch in diversen Podcasts schon zu Gast gewesen und der sagte dann dazu quasi so, naja, das mit den Datenbanken ist ja so eine Sache, also wenn das funktioniert, wenn man halt eine Datenbank haben kann und so, dann sollte man das schon machen, weil es gibt ja einen Grund, warum die so verbreitet sind und sich so lange gehalten haben und alle die benutzen.

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

Und dann derjenige, der in den Interview hatte, fragte dann halt auch so, ja, kann man denn dann irgendwie was tun, um Datenbanken schon darauf auszulegen, dass man die dann vielleicht trennen kann?

Oder kann man das irgendwie Architektur, ja, das kann man, warum sollte man das tun? Muss der Datenbank schreckliche Dinge antun, damit das geht? Also es muss einem halt klar sein.

Also, ja, also es geht schon,

aber es ist halt, die Frage wäre,

würde man so anfangen wollen?

Und da denke ich, ja,

warum nicht einfach mit einem ganz normalen Datenbankschema anfangen?

Genau, ja, aber das würde ja nicht für Microsoft versprechen,

sondern für einen Monolithen oder einen Service, der...

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

Würde ich auch sagen, normalerweise sollte man einen Grund haben,

warum man das macht.

Also, das heißt, ich würde das auch so intuitiv sagen,

du baust halt jetzt einmal dein Deployment

für ein Tool, für eine Web-Anwendung

und hast halt dann eine Datenbank dahinter

und arbeitest dann damit und erweiterst sie halt.

Und die Frage ist halt, wann komme ich denn überhaupt in diese Sphäre,

dass ich sage, Microsoft wäre jetzt eine gute Idee

oder das behilft mir irgendwo bei?

Das ist unterschiedlich.

Vielleicht erst mal eingehakt,

noch bei diesem Datenbank-Auseinanderschneiden,

das stelle ich mir sehr, sehr kompliziert vor.

Das, was wesentlich einfacher ist, sich vorzustellen,

ist, dass jeder Service tatsächlich seine eigene, echte Datenbank hat.

Und man verteilt die Daten dann quasi auf verschiedene Microservices

in ganz normalen Datenbanken.

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

Nee, gut, aber du hast ja dann das Problem.

Du hast ja eine verteilte

Datenhaltung, wo du nicht einfach einen Join

machen kannst, sondern du musst dann halt...

Ja, klar. Also das Datenmanagement selbst,

das ist wesentlich komplizierter geworden.

Aber die Datenhaltung pro Service, die ist immer noch

relativ einfach. Und das muss man

halt ganz klar sagen. Also die einzelnen

Microservices in sich, die sind unglaublich

einfach. Wenn du zum Beispiel

Monolithen hast, und da kommen wir direkt zu deiner

Frage, die du gestellt hast. Ein Monolith, der wird sehr schnell

sehr kompliziert. Also gerade dann, wenn du viele

Leute an einer Codebasis arbeiten hast, mit

vielen verschiedenen Services da drin,

die sich vielleicht auch gegenseitig affektieren.

Also du bindest ja unter Umständen einzelne Services aneinander

und du hast dann auf einmal teamübergreifende Bugs,

meinetwegen, weil du eine gemeinsame Code-Basis hast.

Dann denkt man schon relativ schnell bei Microservices nach.

Okay, aber das klingt jetzt so,

als wären die Apps jetzt nicht so gut getestet im Staging oder sowas

und als würden jetzt Dinge, die halt eine Seite kaputt machen,

andere Apps kaputt machen.

wenn man jetzt beispielsweise in Django-Apps jetzt

denkt, ja, wenn man das parallel

entwickelt, dann könnte man die ja voneinander

trennen, also. Im besten Fall

tut man das, ja, das ist dann.

Also wenn die sich gegenseitig differenzieren, kommt man natürlich in

so ein Dependency-Problem vielleicht,

aber. Ja, ja, ich glaube, also

ich meine, das ist auch

immer was, wo

es geht eigentlich im Grunde, das zentrale

Problem irgendwie bei der Softwareentwicklung ist eben dieses

Modularisierungsproblem, das ist halt irgendwie so

das Ding, was jeder hat und was irgendwie

ganz einfach aussieht, wo alle sagen, ah, dann

sondern halt ein bisschen modularisieren, kein Problem.

Das ist aber tatsächlich sehr schwierig.

Ja, User musst du sehr oft importieren.

Das heißt, dass zum Beispiel, wenn da irgendwas kaputt geht,

das ist schon doof dann wahrscheinlich.

Ja, aber du kannst ja trotzdem sozusagen die Dinge irgendwie auseinanderhalten,

die nichts miteinander zu tun haben.

Wenn es nicht geht, dann geht es halt nicht.

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

Also man kann da schon was tun und man kann das richtig und falsch machen.

Und meistens machen sie es total falsch.

Und das, die allerschlimmsten

Geschichten sind dann halt, oder wenn man es halt

verteilt falsch macht, das ist halt

ja, insofern, ich bin

auch so ein bisschen immer

also vorsichtig,

weil häufig, was ich

halt schon häufiger gesehen habe, ist,

dass Leute dann sagen, also sie haben halt dieses

Problem, das Standardproblem irgendwie, das

alle haben in der Softwareentwicklung irgendwie, sie kriegen

ihren Kram halt nicht organisiert,

so richtig und richtig strukturiert

und nicht modularisiert und

dann nehmen sie halt

irgendwie Teile, die kompliziert sind und machen daraus

Mikroservices, weil sie sagen, ja, dann haben wir das

irgendwie modularisiert. Aber das ist ja nicht so, sondern

dann hat man es einfach nur verteilt. Das heißt, man hat ein Ding,

was man nicht modularisiert hatte, verteilt und dann hat man

halt einen verteilten Monolithen und das ist halt

und das passiert leider

sehr oft.

Ja, insofern, genau.

Aber ich glaube, dem kann man so ein bisschen entgehen,

wenn man sich überlegt am Anfang so, wofür will ich das

eigentlich bauen und warum mache ich das?

Und dann geht das wahrscheinlich schon besser.

Die Frage ist auch immer,

ob man es besser oder schlimmer macht oder ob man überhaupt was am Zustand ändert.

Ich meine, wenn man innerhalb seiner Architektur

beziehungsweise innerhalb seines Codes Referenzen hat,

dann hat man die ja automatisch nicht mehr nur,

wenn man auf einmal Microsofts verwendet.

Man verlagert das Problem.

Aber ich sage jetzt mal, man macht die Sache halt,

die Code-Basis selbst wesentlich einfacher

und manchmal läuft man auch einfach in eine Situation,

wo man feststellt, okay, die Funktion, die ich jetzt hier machen möchte,

die ist...

In dem Umfeld, in dem ich mich gerade bewege, einfach super schwierig zu implementieren. Das heißt, ich finde gar keinen geeigneten technischen Ansatz, da mal ein wenig was einzubauen. Vielleicht ein ganz, ganz einfaches Beispiel. Wir haben jetzt eine Django-Anwendung und wir haben jetzt irgendwo, weiß ich nicht, RabbitMQ, Kafka, irgendwas rumliegen, irgendeine Queue, irgendein Topic und das will ich konsumieren.

Und dann muss ich mal überlegen, gut, wie baue ich das möglichst elegant in eine Django-Anwendung ein? Dann habe ich da irgendwie permanent etwas Parallellaufendes, kann man machen. Die Frage ist, ob es sich natürlich anfühlt, ob es cool ist, ob man es wirklich so machen will.

Also du willst eine Socke-Verbindung aufmachen zu einem Kafka oder einer anderen Q?

Ich würde es gar nicht mal so ausdrücken. Ich würde einfach mal den Sachverhalt an sich in den Raum stellen, dass ich einen Umstand habe, der sich einfach nicht natürlich fühlt, in die aktuelle Anwendung einzubinden und die man dann reinhackt unter Umständen oder wo man meinetwegen sagt, okay, ich finde jetzt in meiner jetzigen Architektur einfach allgemein keinen schönen Ansatz für das, was ich vorhabe.

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

Und vielleicht geht das mehr so in die Richtung politische Entscheidung oder auch nicht. Aber manchmal ist auch so das Skillset der Mitarbeiter, die du gerade hast, verleiten dich einfach dazu, zu sagen, okay, ich kann nicht alles in dieser einen Codebase lösen, ich kann nicht alles mit diesem einen Deployment lösen. Vielleicht lagern wir das aus und vielleicht ziehen wir dadurch wirklich unsere Vorteile.

Ja, also was ich halt da wieder an Problemen sehe, ist halt, wenn ich das jetzt tue, dann habe ich ja irgendwo den Hut nicht auf. Oder ich muss den Hut an einer Stelle aufsetzen und muss das dann wieder aggregieren, wo du das vom API-Gateway sprachst. Also wenn ich diese Spinne im Netz sein will, die halt die Informationshoheit hat, die die Single Source of Truth irgendwie bereitstellen möchte.

Aber das ist ja kein API-Gateway.

Nein, gut, aber du hast halt

andere Services, andere Teile der Applikation

arbeiten irgendwo auf einer ganz anderen

Maschine, mit einem ganz anderen

Deployment und die liefern mir irgendwas.

Ja.

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

Also wenn ich das aus meiner Seite, das muss halt eigentlich

auf deren Seite dann getestet sein. Das heißt, ich

gebe quasi die ganze Verantwortung

auch weg. Ja, du hast natürlich

sehr viel, du hast wahrscheinlich wesentlich mehr Integration-Tests

erst mal, als du in einem Monolithen hättest.

Auf der anderen Seite sagt man ja, die einzelnen Services, die sind entkoppelt voneinander. Das heißt, wenn deiner läuft, hast du deinen Job gemacht und das ist erstmal alles gut und der andere muss dafür sorgen, dass sein Microservice läuft. Das heißt, man verlässt sich irgendwie aufeinander und ich habe so ein bisschen das Gefühl, dass das Problem, worauf du dich so ein bisschen einschießt, ist das größte Problem in Microservices allgemein.

Das ist immer so eine Sache, die kann man unglaublich gut machen oder unglaublich schlecht machen. Oder man macht es einfach, wie man es macht. Also man bewegt sich irgendwo in der Mitte und mal funktioniert es richtig gut und mal nicht. Also das ist eine Riesenherausforderung, worüber du sprichst beim Single Point of Truth, beziehungsweise auch das ganze Monitoring. Das ist ja wesentlich komplizierter in der Microservice-Welt.

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

Du musst überhaupt mit sowas erstmal anfangen und wir haben das

möglicherweise eben noch nicht. Das ist auch

das erste Projekt, was er vorschlägt,

wenn man sich dann tatsächlich doch mal dazu durchgeguckt hat,

das dann zu machen.

Ein gutes Startprojekt ist halt zu sagen, okay, da machen

wir doch mal irgendwie

als ersten Microservice irgendwie

zentrales

Logmanagement.

Weil das ist halt relativ

einfach. Das ist eigentlich nicht so schwierig.

Aber man muss halt trotzdem

irgendwie Sachen

irgendwo hindeployen können und man hat unterschiedliche

Sprachen, man muss es irgendwie

konfigurieren und diese ganzen

unterschiedlichen Aspekte

irgendwie müssen alle zusammen funktionieren,

sonst geht es halt nicht und wenn man da schon feststellt, okay,

das ist mit der Organisation, weil das

oft hat man ja so Organisationsproblem,

schwierig zu machen, dann weiß man halt, okay,

alles andere, danach wird noch viel schwieriger, daher sollte

man vielleicht nochmal überlegen, wie man das

organisatorisch löst.

Aber ja, genau, genau,

das ist eigentlich, du brauchst dann halt irgendwas, wo

du dann halt zentral deinen Log-File sehen kannst

und gucken kannst, was passiert ist, über

deine unterschiedlichen Services hinweg.

Und das musstest du vorher vielleicht nicht.

Also das meinte ich mit dem Hut auf Farben,

ich musste halt immer irgendwie so ein Admin haben oder so.

Naja, also ich meine, du hast dann

ein Ding für Log-Geschichten, du hast aber

vielleicht auch ein anderes Ding für Monitoring, du hast

wieder ein anderes Ding für, weiß ich nicht,

dein Live-Dashboard

oder so, das müsste ja jetzt nicht alles das

gleiche sein.

Aber das Problem, was ich jetzt habe, ist dann

wahrscheinlich niemand den Hut über alle diese Dinge auf hat.

Und es dann schwerfällt, die halt

in der Bar getragen werden.

Ich meine, am Ende,

ich meine, das, worauf der Jochen

hingewiesen hat, wir haben ja unsere Tools.

Also der Elk-Stack für Logging, meinetwegen

Sentry für Fehlermeldungen, dann hast du vielleicht

noch Grafana, Prometheus für Metric-Monitoring.

Das sind ja alles standardisierte

Ansätze, die du relativ einfach in deiner

Services einbauen kannst. Also File-Bit-Logging

geht zum Elk-Stack. Und das ist halt

etwas, wo man sich auch in einem Monolithen durchaus

Gedanken drüber machen muss, um da einen einfachen Zugang zu seinen

Logs zu kriegen zum Beispiel.

Gerade dann, wenn du in einem Team bist,

dann finde ich schon, dass man sich relativ früh

die Gedanken über genau diese Fragestellungen

machen sollte, damit einfach jedes Teammitglied

ohne Serverzugriff oder irgendwas

anderes komisches eben an seine Logs

kommt und diese möglichst schön filtern kann.

Elk-Stack ist auch wunderbar.

Das heißt, diesen Stack, den hast du

unter Umständen auch in einer guten monolithischen

Struktur schon. Vielleicht könnt ihr ja mal noch kurz den Elk-Stack

beschreiben, weil den hatten wir, glaube ich, noch nicht.

Das ist einfach nur, ich weiß

jetzt gar nicht, ob ich das richtig, ich habe mit dem

gar nicht so viel, das ist irgendwie Elasticsearch

halt, um die Logfiles durchs Ufer zu machen.

Das ist halt Kibana

Dashboard.

Genau, und

was gehört da noch dazu?

Logstash.

Vielleicht auch, um das zu beschreiben,

du kannst in Python zum Beispiel, schreibst du

deine Logfiles in Files und dann kannst du dir die mit

Filebeat Richtung Logstash

schicken. Das ist einfach nur ein weiterer Service.

Der sorgt dann letztlich

einfach nur dafür, dass die Logs, die du

schreibst, Richtung Elasticsearch gehen.

und entweder du hast da noch ein Logs-Dash vor oder nicht,

dann kannst du die vielleicht noch ein bisschen schöner formatieren,

um sie ein bisschen schöner JSON-tauglicher zu machen

und durchsuchbarer zu machen, einzelne Felder zu indizieren.

Und dann wird das eben auf Elasticsearch gespeichert

und mit Kibana durchsuchst du es einfach.

Dann kriegst du so ein Dashboard,

dann kannst du relativ nutzerfreundlich

mit schön viel Clicky-Bunty deine Logs durchsuchen

und dann hast du deine Graphen, kannst dir auch Dashboards bauen.

Ja, Kibana ist super.

Freitext-Suche, das ist sehr schön.

Ja.

Macht Spaß.

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

die Problemdomäne irgendwie vertikal aufzutrennen

und was man klassischerweise

vielleicht eher macht, sind Sachen horizontal

aufzuteilen. Das heißt, du teilst

normalerweise, sag ich mal, eben dann vielleicht

eher auf in Frontend

irgendwie so Service Layer und Backend

und Datenhaltung

und sozusagen bei Microservices

halt eher vertikal, das heißt pro Projekt irgendwie

oder pro

eine Organisationsstruktur halt.

Und das Problem bei dem horizontalen

Ding, weshalb man da vielleicht weg möchte

von, ist halt, dass

du halt, wenn du jetzt

viele Leute hast, die daran arbeiten,

an deinem Produkt, dann, genau, dann stehen

sie halt gegenseitig auf den Füßen unter Umständen.

Also du hast dann vielleicht halt eben schon

ein

Datenbank-Team

oder so, wo sich die Leute sehr, sehr gut

mit Datenbanken auskennen, aber

und du brauchst sie halt auch,

deswegen, weil du halt eventuell fiese Datenbankprobleme

hast, wo Leute irgendwie Queries optimieren

müssen oder sich überlegen müssen, wie sie da

halt irgendwie möglichst schnell neue

irgendwie Replikas

von irgendwelchen Datenmarken hochziehen können und die Daten

da und so weiter.

Dieses ganze Zeugs, was man

halt so machen muss.

Und das sind dann halt so die

Sachen, für die du tatsächlich Spezialisten brauchst, aber

du hast halt oft auch das Problem, du willst

jetzt, hast jetzt irgendwie ein Projekt und da muss halt

irgendwie jetzt eine Spalte zusätzlich irgendwo

in der Tabelle. Und da ist jetzt eigentlich

nichts, was so sonderlich schwierig ist. Vielleicht

sollte man sich überlegen, ob man das dann machen will oder nicht oder keine Ahnung,

aber letztlich das zu tun ist gar nicht so schwer

und dein Datenbank-Team ist

jetzt zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt

oder so. Und dann kommst du nicht weiter

mit deinem eigentlich Projekt,

das nur da eine blöde Spalte zusätzlich haben

muss. Es gibt halt eine Menge Anforderungen, die sehr

einfach sind. Also entweder du

beschäftigst dann halt deine teuren Spezialexperten

irgendwie mit sehr simplen Geschichten

oder

du kannst die nicht auslasten,

weil

die halt

oder du kannst halt

mit deinen Projekten nicht weiter, weil die halt mit

irgendwelchen anderen Kram ausgelastet sind.

Und das blockiert sich halt gegenseitig.

Du hast halt sehr viel Handoffs, zwischendurch viel Kommunikation,

weil viele Leute miteinander

reden müssen, damit irgendwas am Schluss

deployed werden kann. Und wenn du es jetzt anders

machst und machst es halt vertikal und sagst, ein Team ist

im Grunde dafür zuständig, das komplett zu deployen

in ein Produkt, Projekt,

Microservice,

dann, und die anderen sind halt bloß,

die beraten dich

dann halt, wenn es irgendwie

kompliziert wird oder so und

enablen, dich halt irgendwie da

eine Lösung zu finden, dann kannst du halt sehr viel

schneller halt Sachen tatsächlich

raus aus der Tür kriegen

und du machst

bestimmte Teile deiner Organisation halt auch

handlungsfähig,

ohne dass sie halt sich mit allen anderen abstimmen müssen.

Und dann, also das sind vor allen Dingen

zwei Teile, die da halt ein Problem

sind, das ist halt einmal die Infrastruktur ganz unten,

das sind halt Datenbank und so und

IT-Geschichten und dann oben halt aber UI

und UX ist auch immer problematisch, deswegen

eben gerade schon mit dem Mikrofon jetzt so ein bisschen,

weil das Problem ist, wie stellst du Konsistenz

gegen, quasi

sicher, wenn halt du nicht mehr ein

UI-Team hast, das halt alles

auf allem irgendwie zu einem Ja sagen

muss, dass das jetzt so funktioniert. Die könnten dann sagen,

ja, nee, das muss konsistent sein, das können wir so nicht machen.

Aber wenn jetzt die Teams das einzeln machen sollen,

dann kann es natürlich inkonsistent werden. Ja, dann müssen ja

irgendwie komische Style-Guides folgen oder so.

Ja, aber ob sie das dann tun oder nicht, weil das Team

muss dann ja verantwortlich sein. Die müssen ja sagen können,

nee, wir releasen, das ist uns wichtiger und dann,

oder wir deployen jetzt und dann machen sie das halt einfach.

Das wäre Kraut und Rüben.

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

Und ich finde, in einer Firma

gibt es das auch sehr schön,

sowohl was das an Vorteilen bringen kann,

sieht man da, und auch was an Nachteilen, nämlich bei Amazon.

Die haben ja eigentlich früher schon angefangen mit

Service-Oriented Architecture, was vielleicht

auch so ein bisschen Vorläufer ist von Microservices.

Und auf der Amazon-Shopping-Seite,

da funktioniert das, finde ich, ganz gut.

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

und altbacken und so.

Aber das geht irgendwie. Also man kann

einkaufen und meistens funktioniert es sogar besser als

anderswo vom Prozess her.

Aber, also das geht.

Das ist zwar nicht so komplett konsistent, aber das

funktioniert insgesamt. Und wo ich

finde, wo es eine ziemliche Katastrophe ist, ist halt

sowas wie AWS oder so. Wo man auch sieht, dass

jedes einzelne Team, also einmal es gibt hunderte

und dann jedes Team macht das halt

irgendwie anders, so wie sie es halt denken.

Und das macht es für mich als Benutzer halt total schwierig

irgendwie das zu

bedienen, weil ich nie Sachen

finde und immer

suchen muss nach Sachen und so.

Naja, also auch die Konfiguration, wenn man das irgendwie automatisiert,

ist ja jedes Mal total anders und das ist ein bisschen

nervig auch. Ja, also ich meine, es geht schon, aber es ist halt

schon, das macht es echt, da an der Stelle

macht die fehlende Konsistenz einem das Leben halt echt schwer.

Und ja, aber

ich glaube, das sind halt so Trade-offs, da muss man

sich entscheiden, ist einem die Konsistenz wichtiger oder die Geschwindigkeit?

Ja.

Ja.

Naja, naja.

Wenig Begeisterung für Microservices

habe ich das Gefühl. Ja, ich weiß nicht, also

Ich habe noch nicht so rausgefunden, wofür ich

dann jetzt ein Microsoft gut

einsetzen könnte. Also wenn ich mir jetzt vorstelle, ich möchte

jetzt irgendwie so ein Projekt implementieren,

irgendwie so eine gewisse Größe und dann

muss ich

ja, wie du, Jörg, so schön

sagst, enablen die Leute, dass

sie selber klarkommen mit den ganzen

Regeln, die ich irgendwie haben

will. Ich glaube, das ist noch viel zu

kompliziert. Ich glaube, erst mal

muss man überlegen, brauche ich das überhaupt? Also macht das

für mich überhaupt Sinn? Habe ich die Größe? Wie viele

Mitarbeiter habe ich? Bin ich jetzt zu fünf, dann mache ich kein

Microservices auf. Aber habe ich meinetwegen

20, 30, 40 Mitarbeiter,

das macht schon super viel Sinn, da über Microservices

nachzudenken, weil ich kann jetzt

eigene Teams machen, diese Teams haben

verschiedene Verantwortlichkeiten und

natürlich habe ich hinterher den Trade-off

mit Konsistenz meinetwegen

im Frontend. Frontend

ist halt immer so, ich bin nicht im Frontend

drin, ich persönlich. Also ich halte mich

davon so weit fern wie nur möglich

und so Backend-Prozesse,

da sind so Guidelines total egal.

Nein, aber ich versuche jetzt wirklich nochmal von diesem Management-Layer von oben das mir anzugucken, weil du hast natürlich recht, wenn ich jetzt ein Konzern habe mit 100.000 Mitarbeitern, dann macht das vielleicht Sinn, die Teams zu verteilen auf ihre einzelnen Kompetenzen, die sie haben, die in unterschiedlichen Ländern so sitzen, das heißt, die haben ganz andere Abstimmungsprobleme.

Mein Problem ist es aber als Konzern von oben, das so zu managen, diese unterschiedlichen Services, dass sie konsistent sind. Ja, dann habe ich wieder das Problem des Brandings oder wie auch immer. Oder halt, ich möchte eine Nutzbarmachung der einzelnen Services für alle sicherstellen.

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

Ja, die Frage ist dann auch immer, welche Prozesse werden durchlaufen, um etwas zu veröffentlichen, das steht halt noch drin.

Genau, aber ist die Frage, erschlage ich das dann mit irgendwelchen Prozessen? Weiß ich nicht, das macht es ja nicht besser. Dann habe ich den Vorteil von Microsoft, das habe ich dann nicht mehr, weil dann muss ich durch so ein Prozess-Gateway durchkommen und habe dann einen Doorkeeper nach dem anderen.

Ja gut, aber auch um auf deine Frage zu kommen, die Frage ist dann am Ende auch, wie schlimm ist das? Also wenn ich jetzt zum Beispiel in Tokio das eine Team habe und in Berlin das andere, die backen beide ihren eigenen Kuchen, dann ist es ja gerade der Sinn von Microservices auch, dass jedes Team eigentlich nach Lust und Laune so arbeiten kann, wie es will, solange es zum richtigen Produkt führt.

Weil das Team in Berlin wird relativ wenig Berührungspunkte mit dem Code zum Beispiel vom Team in Tokio haben und umgekehrt natürlich auch, weil Microservice-Teams, die stehen ja für sich alleine. Das heißt, wir haben ein Team, das arbeitet an einer Sache, das deployed ein Service für sich alleine und der muss natürlich integrativ mit den anderen irgendwie funktionieren.

Ja, ich würde auch denken, dass das Problem eher tatsächlich andersrum ist. Also das, was dann tatsächlich auftritt. Also ich meine, ja, es kann auch sein, dass es schwierig ist, das zu koordinieren. Keine Ahnung. Kann man sich ja vielleicht irgendwas überlegen. Aber das habe ich jetzt noch gar nicht so gehört, als dass es ein Riesenproblem ist.

Was aber schon ein Riesenproblem ist,

wenn du jetzt

so etwas hast,

ich weiß jetzt nicht, was das Beispiel war,

du hast halt irgendwie

einen Konzern, der hat halt hunderte

Marken und jede Marke hat irgendwie

eigene Dienste, die sie

irgendwie anbieten

und die sind alle in unterschiedlichen

Teams und so und auch weltweit verteilt und so.

Wie stellst du denn sicher, dass du irgendwas

über einen bestimmten Kunden weißt zentral?

Das kriegst du halt dann nicht mehr hin.

Oder halt über die Produktion, wenn du derjenige bist,

das produziert und das dann verteilt an Unternehmern.

Das ist genau das, was ich meine.

Ja, das ist der Nachteil, das geht halt nicht mehr.

Aber das ist ja das, was

ich zentral, das sind wir vielleicht wieder,

was man bei Single Point of Truth irgendwie

überschreiben kann. Das ist eine Herausforderung.

Ich muss halt irgendwie sicherstellen, dass die Wahrheit,

ich will die Wahrheit haben, damit ich das menschen kann,

damit ich die Entscheidung richtig treffen kann, damit ich

die Steuerung...

Es ist halt die Frage, also es geht halt manchmal,

ich meine, ich kenne es halt zum Beispiel

als zweitgrößte E-Commerce-Konzer

in der Welt. Wisst ihr, wer das ist?

Hm? Nach Amazon?

Otto?

Ja, das ist Otto.

Aber tatsächlich, ich weiß nicht mehr, ob das

noch stimmt. Es kann sein, dass

AliExpress oder so

größer ist.

Oder Alibaba.

Aber Otto auf jeden Fall sehr, sehr

groß. Und damals,

das ist jetzt aber auch schon wieder lange her,

hatten sie sich das auf die Fahnen

auch geschrieben, irgendwie der Zeitgröße nach Amazon zu sein.

Und die haben halt zum Beispiel genau

dieses Problem, weil es gibt ja nicht

die eine Seite, auf der dann alle irgendwie

Zeugs einkaufen, sondern die haben halt hunderte

Shops. Also jeder dritte

Shop, auf dem du irgendwie landest, ist halt letztlich

gehört zum Autokonzern. Du weißt es aber gar nicht, weil

das steht da ja auch nicht dran.

Die haben jetzt genau dieses Problem.

Jeder einzelne Shop hält

halt User-Daten und

genau, wie machst du das denn jetzt

eigentlich, wenn du quasi irgendwie

Dinge wissen willst über deine User?

Also wie kriegen die ganzen Microservices wieder alle zusammen?

Ja, und die Antwort ist eigentlich

gar nicht.

Ich glaube, da kommen so Leute auf die Idee wie

Data Lake wird dann eher Data Swamp oder so.

Irgendwas zu sichern.

Das schlimmste Problem

ist gar nicht unbedingt die technische Lösung,

sondern das schlimmste Problem sind halt die

politischen Geschichten, die du halt auch kriegst automatisch.

Dass halt Leute sagen so,

wir haben hier gerade

einen Vorteil, die sind ja untereinander im Wettbewerb,

wir haben hier gerade einen Vorteil, weil

wir irgendwas wissen, was die anderen

nicht wissen und jetzt sollen wir die Daten,

das, was uns dazu verhilft,

dass wir irgendwie besser sein können, als

wie unsere interne Konkurrenz, da sollen wir

den jetzt irgendwie freiwillig zur Verfügung stellen?

Dann haben wir halt irgendwie einen leichten

kaputten Export, wo die Daten so ein bisschen...

Ja, aber mit der Konzernbrille, die du dann aufhast,

dann musst du da hingehen, musst den gordischen Knoten dann kaputt hauen.

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

Ja, schwierig. Sehr schwierig.

Also, ja.

Aber auch da, ich meine,

das ist jetzt ein sehr, sehr schönes Beispiel, aber als

Konzern muss man sich natürlich die Frage stellen, was will ich

eigentlich? Will ich jetzt ein möglichst großes Franchise

so schnell wie möglich aufbauen? Habe ich die

Kapazität, um das aus

innerer Kraft herauszuschaffen oder

muss ich dafür sorgen, dass die Leute

in weiß nicht wo das alles selbst entwickeln

können, dann machen sie halt ihren eigenen Service und dann

habe ich das Problem mit den Daten, dass ich nicht unbedingt alle

Nutzer auf einmal kenne, aber das

ist dann eine Sache, die man

lösen muss im Nachhinein. Und was hilft mir jetzt

mehr? Hilft es mir mehr, da einen Shop hochzuziehen

und irgendwie

mein Geld über das Franchise reinzuziehen

oder wie auch immer? Oder will ich jetzt

einfach alles wissen und will ich die totale Kontrolle

haben? Ja, das ist halt genau das klassische Problem

eigentlich. Machst du halt irgendwie Diversifizierung

oder machst du Fusionierung

irgendwie. Das ist

in der Software-Seite und die Frage,

die irgendwie die Consultants immer geben, ist immer genau das Gegenteil

von dem, was gerade da ist.

Dann kannst du halt so ein Projekt consulten, kannst damit Geld verdienen

und dann geht es halt immer aus und zusammen.

Ich meine, das macht natürlich auch Sinn. Also wenn du irgendwas

hast, was total verfilzt ist, dann musst du das

erstmal auseinanderspalten, dann hast du kleine

einzelne Services, die untereinander

so ein bisschen Wettbewerb haben. Die guten Sachen

musst du dann irgendwie wieder konsolidieren und zentralisieren,

um dann wieder den guten Benefit rauszubekommen.

bis du dann wieder merkst, das ist wieder doof, dann fängst du wieder an, das auseinander

zu dröseln. Das ist ja genau wie bei den Ländern.

Mal sind Länder werden zusammengefasst, dann werden die

auseinander. Ja, aber das ist ja

vielleicht auch dieser natürliche

Zyklus, Lebenszyklus von so

einem Ding.

Und ja, also wenn

ich jetzt zum Beispiel hingehe, dieses Otto-Beispiel

nehme und ich möchte diese User-Daten haben.

Ich würde jetzt als Otto hingehen und sagen, ich will wissen, wer sind

meine Kunden, wie viele Kunden sind das überhaupt irgendwo.

Dann muss ich hingehen und sagen, gebt mir alle eure Daten.

Dann baue ich einen zentralen Service dann zusätzlich,

der halt von allen die Daten abholt. Dann kann es sein,

dass ich jeden einzelnen dieser Shops einzeln integrieren muss,

kann irgendwie sein, dass das relativ viel Aufwand macht,

aber dann hole ich mir die alle irgendwann ab

und dann weiß ich, okay, zumindest

in der Historie gesehen ist das vielleicht ein Tag alt

oder so oder eine Woche, ist ja egal, aber da sind

die Daten sind einigermaßen echt und da habe ich

einen Vollüberblick über, was da meine Leute sind

und da kann ich dann bestimmte Analysen

fahren, die ich vielleicht fahren möchte.

Aber das ist ja das, was man vielleicht dann braucht

und dann kann man damit vielleicht dann wieder sagen, ah, aber

dafür machen wir jetzt wieder so kleine Services, weil dann

vielleicht, oder du kannst auch überlegen,

ob du nicht schon im Vorfeld einen

einen gewissen Standard etablierst, wo du sagst,

da sind wir wieder beim Standard natürlich.

Und bei den Gateways.

Nicht nur bei den Gateways. Ich bin

im Backend. Ich interessiere mich nicht so für die...

Ja, doch, auch. Ja, mein Problem ist da bei der

Gatekeeper. Ich musste gerade, weil du gesagt hast Standards,

musste ich an Infrastrukturstandards denken.

Und auch daran, das ist ja unheimlich

schwierig, wenn du die gleichen

Standards einführst für Teams, die

auf der Welt irgendwo sitzen. Ja, damit verlierst

du die Vorteile von Microsoft. Ja. Eigentlich sofort.

Genau. Die Frage ist halt, was

der Standard ist. Möchte ich jetzt einfach so ein Plugin

auf jedem Shop haben, welches meinetwegen

in verschiedenen Programmiersprachen

vorhanden ist, damit die Shops autonom

sind, ist es für mich ein vertretbarer

Aufwand, das zu gewährleisten, meinetwegen.

Das fängt ja schon bei anderen Sachen an,

wie, keine Ahnung, jeder Dev kriegt ein Windows-Laptop

mit AD zugefroren.

Aber das hast du ja nicht.

Genau, das willst du nicht machen.

Das ist nämlich der Punkt, weil wenn du Microsoft was machst, musst du erkennen,

dass das unabhängig sein muss

von dem Rest und du kannst das da nicht zentralisieren.

Und wenn du das machst, ist es halt

kontraproduktiv, weil dann hast du den Monolithen

irgendwo dazwischen sitzen, der wie eine Krake

versucht, seine einzelnen Sachen doch festzuhalten

und dann ist das völlig absurd.

Wie gesagt, also für mich muss man

da so ein bisschen von loslassen,

dass man die Kontrolle, die totale

Kontrolle haben will. Und wenn man das

kann und wenn man dann die Vorteile

für die Flexibilität sieht,

die man dabei gewinnt, dann

sind Microservices schon sehr vorteilhaft.

Ja, genau, aber das ist genau der Punkt, weil

wenn ich jetzt sage, ich möchte den Hut aufhaben, wird das

so nicht funktionieren. Sonst wird nur dann funktionieren,

wenn ich Verantwortung abgeben kann.

Ja, dann nimmst du einen Microservice.

Aber da hast du ja schon eine Antwort.

Also willst du den Hut aufhaben, wie du es so schön sagst,

dann mach keinen Microservice.

Oder überleg dir halt sehr, sehr gut, wie du das gewährleisten kannst.

Wie viel willst du wachsen?

Vielleicht geht das ja sogar in Microservices, wer weiß.

Oder willst du die Verantwortung abgeben,

dann kannst du einen Microservice nehmen.

Die Frage am Ende ist, wenn du einen riesen Konzern hast,

hat da überhaupt noch jemand den Hut auf?

Egal, welchen Ansatz du nimmst.

Die Frage im Konzern ist dann ganz einfach.

Auf welcher Kostenstelle wird denn das gebucht?

Und wer hält dann dann wo die Hand auf?

Ja, aber ich glaube

also, wenn man nochmal

einen Schritt mehr Richtung

Organisation oder allgemein oder abstraktes Problem geht,

ich denke, also ich würde irgendwie

diesen Trend zu Microservices halt so verorten

in einem

in einer Reihe von Trends, die halt alle

in eine ähnliche Richtung laufen. Ich glaube, DevOps ist auch

so ein Ding, was in eine ähnliche Richtung läuft, weil

bei all diesen Dingen geht es

im Grunde darum,

dass man halt in

so einer klassischen Organisation,

dass da die Incentives irgendwie pervers

sind, so ein bisschen.

Und das sind alles Versuche, das zu

lösen, dieses Problem, dass die Incentives

eigentlich nicht korrekt sind. Also was ich

damit meine, ist einfach nur, ist eigentlich ein total simples

Problem. Nehmen wir an, du hast halt irgendwie

früher, du hast halt

Entwicklung und

Betrieb oder

IT und Operations oder weiß ich nicht

und dann auf der anderen Seite Entwicklung. Und das ist vielleicht auf

unterschiedlichen Seiten deiner Bilanz

auch. Das eine sind dann halt

Kosten und das andere sind halt Investitionen.

Ja, so dann hast

du halt irgendwie, siehst du halt

wenn da Features entwickelt werden, siehst du das als Investition

und denkst halt, je mehr Features

entwickeln werden, voll gut, gibt mir in der Zukunft

mehr Einnahmen, total super.

So, das heißt

irgendwie deine Entwicklung misst du daran,

wie viele Features kriegen die eigentlich pro Quartal irgendwie raus

oder keine Ahnung, irgendwie sowas.

Dann geht das Ganze in den Betrieb.

Woran misst du deinen Betrieb?

Den misst du an den Kosten und daran,

dass es halt funktioniert. Aber

sozusagen die

Leute, die da arbeiten, die haben nichts

davon, dass da mehr Features

rausgehen. Die werden

nicht, kriegen nicht mehr Geld dafür,

dass sie halt dafür

sorgen, dass die Entwickler mehr Features veröffentlicht werden.

Was ist deren

rational

beste Strategie in diesem

Setting? Ist halt tatsächlich zu sagen,

never change a running system.

Ja, irgendwie.

Ich werde nicht belohnt dafür.

Ich bin ein Kostenfaktor. Ich werde nur bestraft,

irgendwas nicht geht. Ja, solange das Wasser läuft

und der Strom an ist, alles gut.

Sobald der Strom ausfällt, kriege ich

ein Problem.

Das heißt, mein Ding ist

also, ich meine, klar, irgendwie eine Änderung kann sein,

dass sie gut ist für andere, ja, aber ich habe ja nichts davon.

Oder sie ist schlecht, dann

trifft mich das. Das heißt,

ich versuche, möglichst Änderungen zu verhindern.

Dann, das ist sozusagen für mich

am besten, weil dann kann ich sicherstellen,

dass möglichst wenig kaputt geht. Und

na gut, für die anderen ist das halt nicht so toll, dass sie halt nicht so

viele Features rauskriegen, aber ist ja ehrlich gesagt nicht mein Problem.

Ja, so und dann, das ist halt etwas, in das Unternehmen dann halt früher oder später irgendwann reinlaufen und überlegen sie sich, wie sie damit irgendwie umgehen, dass das jetzt irgendwie problematisch ist und das halt irgendwie, das ist halt ein Maß dafür, ja, man sich fragt so, also dann macht man dann ein Kostenstellen und keine Ahnung und dann sagt man intern so und dann kostet das unfassbare Beträge, irgendwas sehr simples zu tun, dann fragt man sich, ja, wie kommt denn das zustande, dass das plötzlich so wahnsinnig viel kostet?

Ein Server 50.000 Euro?

Ja, irgendwie sowas.

Und die Antwort ist einfach so,

ja, das ist halt deswegen,

damit du das nicht machst,

damit du nichts änderst.

Ja, das ist der Grund.

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

Dass jemand sagt so,

irgendwie ich gehe ja für dich das Risiko,

dass sich irgendwie das Sachen kaputt gehen.

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

Und deswegen ist das so teuer.

Und ja, DevOps ist halt dann so ein,

also die Lösung dafür ist halt dann sozusagen

die Verantwortung für diese Dinge halt auch

mit in den Bereich zu packen,

der halt davon profitiert,

wenn was deployed wird. Ja, mit in den agilen Sprint

das zu packen. Genau, genau,

Agile, auch so ein Ding, wo man sagt, okay,

genau, packen wir das alles

zusammen. Ja, oder

halt eben DevOps, wo man sagt, okay,

die Leute, die das deployed

haben wollen, deployen es dann halt auch selber und betreiben es auch selber.

Der DevSecOps jetzt, ne?

Okay.

Fullstack-Microservice

DevOps

im agilen Prozess,

ja, die haben wir alle zusammen, glaube ich,

weiß nicht, aber ja,

Es geht halt darum,

dass einzelne Teams halt möglichst autark

Dinge machen können.

Dass man halt sozusagen da, wo man investiert,

auch tatsächlich, dass die auch dann

die Möglichkeit haben,

das umzusetzen. Aber

das kommt halt mit dem Preis. Das ist halt Trade-Off.

Es ist halt nicht so, dass das dann insgesamt automatisch

super viel besser ist, wenn man das so macht, sondern

man wird dann halt schneller und so, aber man wird

eigentlich automatisch halt inkonsistenter dabei.

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

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

Äh, weiß ich gar nicht.

Also ich meine, das Problem,

also vielleicht kann man das ja

an einzelnen Projekten irgendwie, also

ich würde ja auch denken, dass eine schlaue Art

irgendwie, wenn man jetzt migrieren wollte

von Modulit auf Microsoft, wäre halt,

man fängt halt klein mit kleineren Teilen an

und macht das da und man macht nicht alles auf einmal.

Weil das wird wahrscheinlich nicht gut

funktionieren.

Warum im Haupt? Also ich verstehe es immer noch nicht.

Also irgendwie denke ich immer noch so, ja,

warum hält man das dann nicht an einer Stelle fest

und sorgt dann dafür, dass die Devs alle dann an eine Stelle kommen,

dass sie sich alle gut verstehen,

dass sie alle dieselbe Tech-Sec benutzen,

dass sie die Infrastruktur standardisiert benutzen,

dass sie nur die standardisierte Infrastruktur benutzen, keine andere.

Und dass halt dieses ganze Distributed-Quatsch, Entschuldigung,

dass alles weg ist.

Ich kann ja von mir verschiedene Rechenzentren

parallel an verschiedenen Orten halten.

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

Aber warum muss ich, also die Abhängigkeiten werden dann

von mir aus schwieriger,

so ein bisschen zu managen, weil ich habe halt

das Problem, wie Jochen gerade sagte, dass

hochspezialisierte, hochgutbezahlte

Spezialkräfte sich teilweise um trivialen

Tries kümmern müssen, bis die Sachen

halt mal integriert sind.

Aber dafür könnte man ja einen Service schreiben,

also keinen Microservice, sondern

einen, der halt in den Monolithen drin hängt.

Ja.

Also ich, ganz grundsätzlich,

ich habe so ein bisschen das Gefühl, du bist so ein bisschen

biased.

Das ist mir eine spontane Meinung.

Nee, es ist ja alles gut.

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

Habe ich denn überhaupt die gleichen Kompetenzen?

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

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

Wenn du eine große Firma bist, dann hast du vielleicht irgendwie einen Java-Entwickler,

der ist Querensteiger in Python oder C-Sharp in C++, was weiß ich.

Sowas gibt es.

Und dann verlangst du halt von dem einen Entwickler, dass er seinen Stack zum Beispiel umstellt.

Das willst du ja auch nicht unbedingt.

Also du hast halt grundsätzlich erstmal verschiedene Kompetenzen, dann ist die Frage, brauche ich diesen einen globalen Tech-Stack überhaupt, will ich den überhaupt haben, bringt er mir überhaupt was.

Ich sag mal so, also es gibt halt so wenig gute Leute, dass man wahrscheinlich schon Tech-Stack multiplexen muss, damit man überhaupt genug Leute findet.

Ah, siehste, also Microservice, nein.

Aber grundsätzlich musst du dir ja auch die Frage stellen erstmal.

mal vielleicht, um von dieser Ebene

mal ein bisschen zurück zum Code zu kommen.

Ein Monolith, der hat natürlich eine riesen

Code-Basis, die unter Umständen relativ komplex ist.

Das heißt, du musst viel Aufwand in den

Deployment-Prozess an sich stecken.

Also bist du ein einzelnes

Feature, ein neues Feature deployst oder ein Bug

fixt, musst du dich mit relativ vielen Leuten, wie der

Jochen schon gesagt hat, abgesprochen haben. Du bist insgesamt

ein bisschen langsamer und vor allem

auch fehleranfälliger insgesamt.

Wenn irgendein Integration-Test irgendwie fehl geht

und der irgendwie den Produktionen durchrutscht, dann ist

im Zweifel raussteigend ganz das System ab und hat eine Daumentime.

Genau, der Monolith ist so ein klassisches Beispiel für Single Point of Failure, auch das kannst du irgendwie umgehen, du hast ein Backup-System, du hast das parallelisiert, was weiß ich, also du kannst die Chance minimalisieren, dass du genau an solche Punkte läufst, mit Rollback, mit AB-Tests und so weiter, also du hast eine Möglichkeit, aber auch das musst du dir halt erstmal aufbauen.

Das heißt, du musst dir mit der Zeit erstmal aufbauen, mit dieser Komplexität umzugehen und am Ende stellt sich die Frage, wie gut gehst du eigentlich gerade mit der Komplexität um und kann das mein Team zum Beispiel sehr, sehr gut? Und bin ich mit der Geschwindigkeit so zufrieden, weil ich habe die Erfahrung gemacht, dass sich bei einem Monolithen irgendwann viele Entwickler darüber beschweren, dass das Deployment zu langsam ist insgesamt, dass die Features teilweise zu lang rumliegen, weil zu viele Leute…

Acht, neun Stunden dauern, dann denken die natürlich so, hm, wenn ich so zwei, drei am Tag rausschrauben will, dann ist das schon ein bisschen doof.

Ja, nicht nur, wir reden ja nicht über Stunden, wir reden teilweise über Tagen, Wochen. Also das ist schon nicht so einfach. Und dann kippt auf einmal was um. Du musst das irgendwie organisieren, dass du einzelne Sachen deployst. Und dann ist es natürlich schon cooler, wenn du einen einzelnen Microservice hast. Und wenn der mal umkippt, dann ist es nicht so schlimm für die Gesamtanwendung. Du gefährdest dadurch relativ wenig andere Sachen durch das Deployment.

Also erstmal wirst du durch einen Microservice, wie wir schon gesagt haben, unter Umständen auch nicht zwingend. Du musst es natürlich auch erstmal gut machen. Aber du kannst gewisse bürokratische Randeffekte dadurch durchaus vermeiden erstmal. Also das wäre zum Beispiel ein Grund zu sagen, ich will das jetzt aufsplitten.

Ein anderer Grund ist, dass wir reden über große Code-Basen. Also das muss man halt immer erwähnen. Wir reden über große Teams. Und niemand kennt den ganzen Code. Also was bringt dir ein einheitlicher Text-Deck, wenn du dich eh nicht mit Sachen in den Core-Geschichten auseinandergesetzt hast?

Weil du, meinetwegen, weiß ich nicht, im krassesten Beispiel, du bist Frontend-Entwickler in einer Django-Anwendung und du nutzt jetzt kein Vue.js oder sowas, sondern du schreibst irgendwie dein Frontend-Code in die Django-Anwendung rein als JavaScript-Entwickler, hast du auch nichts mit Python am Hut.

Da macht es schon Sinn, dass du sagst, okay gut, ich baue jetzt mein eigenes Frontend irgendwo anders. Ist jetzt nicht wirklich ein Microservice, aber das verhandelt natürlich das Problem so ein bisschen, dass dieser Entwickler nicht den ganzen Stack kennt und auch überhaupt nicht kennen muss.

Ich freu mich halt, ob das

einen Unterschied macht.

Also ist ja egal, ob jetzt jemand an seinem Feature-Branch

irgendwie eine App baut.

Süßer, wenn es keinen Unterschied macht,

ist es doch doppelt egal.

Nein, aber das ist ja dann

trotzdem im Monolithen.

Ja gut, aber mindestens

habe ich Komplexität raus.

Sowohl im Code, Microservices ist ein kleinerer Code,

der ist ein bisschen leichter zu lesen, du kannst dich ein bisschen schneller einarbeiten,

weil du nicht vor einer Wand aus Code stehst.

Du stehst von der Wand aus Guidelines und Jira-Pages und was weiß ich.

Der gute Jira.

Genau, aber du steigst nicht irgendwie komponententief in den Code rein, musst du auch gar nicht.

Du kommst gar nicht erst in die Versuchung.

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

So durch Microsoft und vielleicht auch durch Deployment-Ebene.

Und du hast das Risiko erstmal minimiert, dass du es verhaust.

Und du behinderst niemand anderen damit.

Also du deployst halt in einem Monolithen immer nacheinander,

wenn du verschiedene Teams hast.

Dann deployst du erst Team A, Team B.

Dann musst du die Reihenfolge festlegen.

Auch das hast du in Microservices,

wenn sie unabhängig voneinander sind, teilweise nicht.

Na klar, Breaking Changes, immer ein Thema.

Das hast du jetzt auch sehr schön geredet.

In meinem Kopf, da ploppt gerade wieder aus,

wenn ich das dann warten möchte und wenn ich das ausbauen möchte,

wenn das Team weg ist, was diese Microservices entwickelt hat,

dann muss ich ja wieder Experten suchen,

sich dann mit dem anderen Tech-Stack auskennen,

den ich jetzt gar nicht kenne.

Vielleicht ja nicht.

der Microservice an sich, der soll relativ schnell

entwickelt sein. Ich meine, das ist jetzt auch wieder

Theorie, aber rein theoretisch soll auch

ein Microservice austauschbar sein.

Ja, okay. Das heißt,

das ist ein Wegwerfding. Das heißt, wenn es nicht mehr läuft,

dann würde ich halt jemand aus einem anderen TechSec den gleichen

Microservice neu bauen irgendwie und das dann günstiger

hat, den anderen neu zu warten.

Ja, okay.

Ja, könntest du natürlich machen.

Aber ja, ich meine, ja, ehrlich gesagt,

ich bin da, also ich meine, ich würde schon

sagen, natürlich, das ist klar, dass Situationen

in den Microservices halt voll gut sind.

würde ich jetzt gar nicht bestreiten

wollen, aber auch, also

würde man damit anfangen wollen, wenn man jetzt

noch nichts gebaut hat, da wäre ich auch eher

skeptisch, glaube ich, aber

also genau, also ich meine, das ist halt hier die

Frage, gibt es irgendwie einen Grund, warum man das machen

sollte, der

was ich dann, was der

der Autor von dem Buch da meinte, ist

naja, eigentlich eher so, Microsoft

das macht man halt dann, wenn sonst nichts mehr

funktioniert, also wenn halt sozusagen

wenn alle anderen Ansätze halt nicht

funktionieren, dann muss man halt

irgendwie, ne, aber

ja, also

und der sagt halt, der Hauptgrund,

der wichtigste Grund, der tatsächlich irgendwie valide

ist, ist halt, dass man Teile der Organisation

halt unabhängig machen will vom Rest

eben dadurch, dass sie halt selber

deployen können und

genau, wenn das halt anders

nicht geht, dann muss man das halt so machen.

Aber, und ja, das kann halt

natürlich sein, wenn du halt einen großen Monolithen hast, den du schlecht

deployen kannst und dann halt einzelne Teams halt

sagen so, wir würden gerne, aber wir kommen, es wird nicht

live, das, was wir machen, dann

geht es halt vielleicht nicht anders.

Wir können vielleicht auch sogar

in Richtung Use Cases gehen. Ich meine, wir hatten

ja schon Beispiele, Bestellservice meinetwegen oder

IoT wäre auch noch so ein Bereich, wo es

prinzipiell durchaus auch

natürlich wirken kann, Microservices zu etablieren.

Ich meine, nehmen wir jetzt mal an,

wir haben einen sehr, sehr großen Datendurchsatz. Also wir

haben irgendwo eine Nutzerplattform, da machen Nutzer irgendwelche

Sachen und parallel davon kommen meinetwegen

aus dem IoT-Bereich irgendwelche

Temperaturdaten von Heizung rein

oder Geodaten vom Auto, was weiß

ich. Also du schreibst ja viele

Daten, dann willst du natürlich

dafür sorgen, dass dieser Schreibprozess,

der die ganze Zeit irgendwo hinschreibt,

von deinem

User-Dashboard irgendwie entkoppelt ist.

Du hast ja keinen Bock, dass die Datenbank dadurch

langsamer wird. Unter Umständen ist die

Datenbank da auch gar nicht die Richtige für, um diese Art

von Daten da reinzuschreiben. Das heißt,

wir haben auf einmal mit diesem Beispiel einen Kontext

geschaffen, wo wir sagen müssen, okay, wir

haben zwei komplett unterschiedliche Anforderungen

geschaffen. Wir haben einmal irgendein Dashboard,

das ist so klassisch HTML,

kannst eine SQL-Datenbank hinterhängen,

ist alles toll. Und wir haben auf einmal

irgendwie, meinetwegen IoT-Daten,

Geodaten, irgendwas, die in

hoher Frequenz geschrieben werden.

Da müssen wir uns überlegen, gut, wie verwalten wir den ganzen

Spaß eigentlich? Eignet sich da für meine...

Aber ich habe es jetzt nicht genau verstanden.

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

du sagst nicht beispielsweise, du hast eine SQL-Datenbank,

da kommen die Sachen von der IoT-Sache

einfach rein und der User liest halt aus der...

Ja, ich fülle das

erstmal weiter aus noch. Also ich kann überlegen,

schreibe ich das jetzt gleichzeitig damit rein.

Aber irgendwann stelle ich halt fest, okay,

zu Lastzeiten wird auf einmal meine

Internetseite langsamer, weil ich auf einmal

zu viele Daten schreibe von diesem IoT-Prozess.

Und die User, die kriegen

eine schlechte Nutzererfahrung dadurch.

Also die Schreiblast,

die steigt, dadurch wird die Internetseite

unter Umständen langsamer, weil ich

alles ineinander verwurschtelt habe. Und da muss ich

überlegen, gut, wie gehe ich jetzt damit um?

Also

normalerweise sollte

das gar nicht so viel langsamer werden, oder?

Weil du kannst ja eigentlich...

wenn du schreibst, klar.

Aber gut, oder ich meine...

Also zum Beispiel Postgres lockt jetzt dann nur

die Zeile, wenn du schreibst. Und wenn du jetzt ein neues

IoT hast, dann hat der eine neue Zeile drauf. Das heißt,

der Nutzer, der kann ja alle anderen Zeilen zum Beispiel lesen.

Ja,

also ich meine, das kann

natürlich schon passieren. Das kann natürlich schon passieren, dass

Schreibtlast irgendwann irgendwie

dein System langsam macht.

Aber meine Frage wäre halt ja, wie häufig kommt

das denn vor, dass man so skalierbar...

Also ich würde sagen, ja, es gibt einen validen Grund,

Microservices aus Skalierbarkeitsgründen

einzusetzen, aber wie häufig kommt denn das vor?

Es kommt vor.

Was wäre denn jetzt die Lösung davon?

Dann habe ich Sachen, die IoT schreibt in eine Datenbank

rein und dann habe ich ja

den Flaschenhals bei dem Prozess,

der von der einen Datenbank in die andere Datenbank

das übertragen muss. Dann ist ja der Stand

alt beispielsweise, weil die Verbindung...