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.

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, 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.

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

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.

Ja.

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,