WEBVTT

00:00:00.000 --> 00:00:04.120
Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode Nummer 41.

00:00:05.060 --> 00:00:08.600
Heute unterhalten wir uns über Microservices. Schön, dass ihr wieder eingeschaltet habt.

00:00:09.480 --> 00:00:10.940
Hallo Dominik.

00:00:11.340 --> 00:00:12.060
Und wir haben einen Gast dabei.

00:00:12.120 --> 00:00:12.320
Guten Abend.

00:00:12.840 --> 00:00:13.280
Hi Janis.

00:00:13.540 --> 00:00:14.340
Ja, das bin ich.

00:00:14.440 --> 00:00:15.120
Hallo Janis.

00:00:15.300 --> 00:00:15.940
Ich bin der Dominik.

00:00:16.300 --> 00:00:16.920
Ich bin der Janis.

00:00:17.900 --> 00:00:20.080
Ja, dann Janis, würdest du dich mal kurz vorstellen vielleicht direkt?

00:00:20.520 --> 00:00:26.700
Ja, das geht schnell. Ich bin der Janis, noch 29 Jahre alt, jung, aus Wuppertal.

00:00:26.700 --> 00:00:30.640
Ich entwickle mit Python viel und oft und gerne.

00:00:31.980 --> 00:00:35.520
Bereich Data Engineering, Data Science, irgendwo da bewege ich mich rum.

00:00:36.760 --> 00:00:41.180
Und du hast gesagt, du hättest was zu Microsoft zu sagen und deswegen unterhalten wir uns heute darüber.

00:00:43.620 --> 00:00:45.360
Ich würde sagen, wir fangen wieder mit News aus der Szene an.

00:00:45.380 --> 00:00:46.780
Ja, genau, machen wir das wie immer.

00:00:48.100 --> 00:00:48.760
Was hast du denn?

00:00:50.020 --> 00:00:53.000
Ja, ich weiß nicht, so ein bisschen wild gemischt ist auch nicht nur Python,

00:00:53.000 --> 00:00:56.060
aber ich dachte irgendwie, gut, das hat schon eine gewisse Relevanz,

00:00:56.180 --> 00:00:58.140
weil, ich weiß ja nicht, aber vielleicht gibt es

00:00:58.140 --> 00:01:00.060
ja auch sogar Leute hier in der, zuhören

00:01:00.060 --> 00:01:02.020
oder dabei sind gerade, die irgendwie davon betroffen

00:01:02.020 --> 00:01:04.140
sind. Es gab da so eine Sicherheitsschwankung

00:01:04.140 --> 00:01:05.280
bei Okta. Ja.

00:01:05.820 --> 00:01:07.380
Ich weiß nicht, wen du meinst, den Betroffenen immer.

00:01:07.880 --> 00:01:09.320
Keine Ahnung. Ja.

00:01:10.080 --> 00:01:11.700
Ja, also das

00:01:11.700 --> 00:01:13.960
ja, fand ich, war mal

00:01:13.960 --> 00:01:16.420
wieder so ein... Also Okta ist so ein Multi-Login-Service,

00:01:16.660 --> 00:01:17.420
Single-Sign-On.

00:01:17.880 --> 00:01:19.040
Ja, genau. Und viele

00:01:19.040 --> 00:01:22.180
Kunden, viele Konzerne sind da Kunden und so

00:01:22.180 --> 00:01:24.200
und eigentlich war

00:01:24.200 --> 00:01:26.280
war sozusagen die Marketing

00:01:26.280 --> 00:01:28.180
Story dabei, halt irgendwie

00:01:28.180 --> 00:01:30.220
ja, du musst irgendwie keinem

00:01:30.220 --> 00:01:32.240
vertrauen und das funktioniert einfach so und das

00:01:32.240 --> 00:01:34.360
löst das Problem für dich und jetzt mussten die Leute, die das

00:01:34.360 --> 00:01:36.560
irgendwie, die diese Dienstleistung

00:01:36.560 --> 00:01:38.140
in Anspruch genommen haben, feststellen, dass sie doch jemandem

00:01:38.140 --> 00:01:38.740
vertrauen mussten.

00:01:40.160 --> 00:01:42.100
Und dass sie dem eigentlich nicht wirklich vertrauen können,

00:01:42.200 --> 00:01:44.180
weil die Kommunikation war halt so, dass sie irgendwie nur

00:01:44.180 --> 00:01:46.260
so scheibchenweise zugegeben haben, was da eigentlich passiert ist.

00:01:46.920 --> 00:01:48.100
Tja. Und das ist natürlich

00:01:48.100 --> 00:01:48.480
schlecht.

00:01:49.620 --> 00:01:52.080
Ja, das ist also, ich würde auch sagen,

00:01:52.080 --> 00:01:53.000
ziemlich beschädigt jetzt.

00:01:53.380 --> 00:02:06.240
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.

00:02:07.760 --> 00:02:21.620
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.

00:02:21.760 --> 00:02:23.760
Und dieses Single-Sign-On, da kann man dann, glaube ich,

00:02:23.760 --> 00:02:25.520
die Policies vielleicht ein bisschen besser einhalten

00:02:25.520 --> 00:02:27.480
und die Leute dazu zwingen, dass sie so ein bisschen mehr darüber nachdenken,

00:02:27.580 --> 00:02:29.740
was sie tun. Ja, gut, Single-Sign-On

00:02:29.740 --> 00:02:31.600
verstehe ich auch irgendwie, aber ich verstehe nicht so richtig, warum man

00:02:31.600 --> 00:02:33.020
dann... Ja, wenn man da keine Kapazität hat.

00:02:33.020 --> 00:02:35.440
Stimmt, wenn man das selber machen muss, dann ist es auch wieder

00:02:35.440 --> 00:02:35.720
schwierig.

00:02:37.660 --> 00:02:39.740
Ja, also das war auf jeden Fall, denke ich,

00:02:39.740 --> 00:02:41.840
ein großes Ding, was irgendwie in der letzten Zeit passiert ist.

00:02:41.880 --> 00:02:43.400
Ja, ich habe auch für Okta tatsächlich so ein Dango-Modul

00:02:43.400 --> 00:02:45.000
geschrieben, mit dem das dann doch irgendwie geht, aber

00:02:45.000 --> 00:02:47.440
das ist halt auch nützlich, wenn Okta kaputt ist.

00:02:47.660 --> 00:02:47.780
Ja.

00:02:49.660 --> 00:02:50.780
Ja, doof.

00:02:50.780 --> 00:02:52.140
Ja. Menus.

00:02:52.860 --> 00:02:54.120
Dann, ah, oh,

00:02:54.400 --> 00:02:55.340
gibt's einen,

00:02:56.460 --> 00:02:57.960
wir hatten ja schon mal diesen Tiobe

00:02:57.960 --> 00:03:00.520
Programmiersprachen.

00:03:00.800 --> 00:03:02.060
Ach, der spannende große Index.

00:03:02.280 --> 00:03:03.800
Index, ja, der immer so zitiert wird.

00:03:04.420 --> 00:03:06.260
Wo man dann irgendwie, wenn man genauer drauf schaut,

00:03:06.320 --> 00:03:08.200
sehen muss, oh, die gucken nur, wie die

00:03:08.200 --> 00:03:10.480
Menge der Suchergebnisse bei so ein paar Suchanfragen aussieht.

00:03:10.580 --> 00:03:11.440
Und das ist ja alles irgendwie,

00:03:11.680 --> 00:03:14.100
wie viel das so sagt, keine Ahnung.

00:03:14.380 --> 00:03:15.760
Es gibt einen anderen, der macht sowas ähnliches.

00:03:15.940 --> 00:03:18.200
Der heißt Peipel, Pippel?

00:03:18.200 --> 00:03:19.320
Ich weiß gar nicht, wie der heißt.

00:03:20.620 --> 00:03:22.400
Jedenfalls da ist Python auch momentan die

00:03:22.400 --> 00:03:23.700
beliebteste Programmiersprache.

00:03:26.700 --> 00:03:28.700
Insofern kann man sagen, es ist halt jetzt nicht nur

00:03:28.700 --> 00:03:30.740
ein Service, der das halt sagt, sondern es gibt

00:03:30.740 --> 00:03:31.100
mehrere,

00:03:32.220 --> 00:03:34.320
die das halt unabhängig voneinander rausfinden.

00:03:34.460 --> 00:03:36.620
Insofern gibt das ein bisschen mehr

00:03:36.620 --> 00:03:38.740
Glaubwürdigkeit, dass da irgendwie was dran

00:03:38.740 --> 00:03:40.560
sein könnte. Ja, es ist auf jeden Fall

00:03:40.560 --> 00:03:41.960
Python sehr populär zur Zeit.

00:03:45.380 --> 00:03:46.460
Sogar Meta hat

00:03:46.460 --> 00:03:48.540
einen großen Beitrag an die

00:03:48.540 --> 00:03:50.540
Python Software Foundation gespendet, habe ich mitbekommen.

00:03:50.620 --> 00:03:52.500
in letzter Zeit? Ja, das sind

00:03:52.500 --> 00:03:53.960
tatsächlich sehr gute Neuigkeiten.

00:03:54.760 --> 00:03:56.360
Das ist ja eigentlich noch nicht so lange her, dass tatsächlich

00:03:56.360 --> 00:03:57.800
die, also Python Software Foundation

00:03:57.800 --> 00:04:00.660
irgendwie hatte bisher immer alles mögliche

00:04:00.660 --> 00:04:02.100
um die Marke

00:04:02.100 --> 00:04:05.580
drumherum gemacht

00:04:05.580 --> 00:04:06.200
und so und

00:04:06.200 --> 00:04:08.280
Rechtsbeistand und

00:04:08.280 --> 00:04:10.640
solche Sachen für Leute, die das verletzen

00:04:10.640 --> 00:04:12.500
und so, aber

00:04:12.500 --> 00:04:14.340
sie haben halt eigentlich keine Entwicklung bezahlt

00:04:14.340 --> 00:04:16.680
oder niemanden gehabt, der halt, es gab niemanden,

00:04:16.720 --> 00:04:18.580
der sich Vollzeit irgendwie bezahlt, um

00:04:18.580 --> 00:04:20.480
Python gekümmert

00:04:20.480 --> 00:04:22.400
hätte. Und klar, es gab

00:04:22.400 --> 00:04:24.240
Leute, die bei Firmen gearbeitet haben und dann zumindest einen Teil

00:04:24.240 --> 00:04:26.380
der Zeit irgendwie dafür zur Verfügung hatten,

00:04:26.560 --> 00:04:27.740
sich damit zu beschäftigen. Aber

00:04:27.740 --> 00:04:30.140
jetzt gibt es seit,

00:04:30.340 --> 00:04:32.140
ich weiß nicht, das ist jetzt schon seit zwei Jahren, glaube ich.

00:04:32.860 --> 00:04:33.680
Wird auch verlängert.

00:04:34.220 --> 00:04:36.340
Developer in Residence sozusagen. Und zuerst

00:04:36.340 --> 00:04:37.900
hat Google den bezahlt. Und das ist ja

00:04:37.900 --> 00:04:39.660
Lukas Schlanger. Macht das

00:04:39.660 --> 00:04:42.040
sehr gut. Schreibt auch immer wieder

00:04:42.040 --> 00:04:43.280
Blogposts, was er so tut.

00:04:44.140 --> 00:04:46.080
Und jetzt quasi damit

00:04:46.080 --> 00:04:47.880
bezahlt das jetzt erstmals auch Facebook,

00:04:48.060 --> 00:04:50.160
was natürlich super ist. Und ja, vielleicht werden

00:04:50.160 --> 00:04:51.880
ist ja nochmal irgendwann mehr Leute, also auf jeden Fall

00:04:51.880 --> 00:04:53.580
wird es irgendwie mehr Geld, das ist ja schon mal toll.

00:04:54.560 --> 00:04:55.140
Voll gut.

00:04:56.680 --> 00:04:57.900
Also ich meine, eigentlich denke ich,

00:04:58.040 --> 00:04:59.820
dass große Konzerne das ja eigentlich fast wie eine Art

00:04:59.820 --> 00:05:01.420
Versicherung sehen können, weil

00:05:01.420 --> 00:05:03.980
sollte man denken, dass sie das so betrachten,

00:05:04.140 --> 00:05:05.960
weil wenn das

00:05:05.960 --> 00:05:08.040
irgendwie nicht mehr funktioniert, dann haben die ein großes Problem,

00:05:08.140 --> 00:05:09.200
was sie sehr teuer zu stehen kommen.

00:05:09.200 --> 00:05:11.900
Das ist halt schwierig, so was zu vermitteln, dass du halt irgendwie

00:05:11.900 --> 00:05:13.780
Dinge bezahlen musst, die in der Zukunft

00:05:13.780 --> 00:05:15.800
eventuell einen Return on Invest geben und

00:05:15.800 --> 00:05:18.020
oder halt auch nur ein Risiko abwenden.

00:05:18.780 --> 00:05:19.940
Ja, aber dass das gerade

00:05:19.940 --> 00:05:21.640
bei Open-Source, die kriegt man ja immer so umsonst.

00:05:21.740 --> 00:05:23.700
Das reduziert ja meistens immer nur irgendwie die Kosten

00:05:23.700 --> 00:05:24.440
auf einer Kostenstelle.

00:05:25.440 --> 00:05:26.500
Ja, ja.

00:05:28.020 --> 00:05:29.480
Ja, ja, das, genau.

00:05:30.640 --> 00:05:31.720
Aber irgendwie geht's

00:05:31.720 --> 00:05:32.520
da voran, das ist voll gut.

00:05:33.420 --> 00:05:35.780
Was hat man noch? Oh, genau.

00:05:36.880 --> 00:05:37.580
BugsPython.org,

00:05:37.660 --> 00:05:39.460
das weiß ich auch, das ist auch schon seit Jahren.

00:05:39.660 --> 00:05:41.100
Versuchen wir da irgendwie zu migrieren auf GitHub.

00:05:41.780 --> 00:05:43.500
Ist aber noch nicht, nein, wir haben es verschoben.

00:05:43.760 --> 00:05:45.480
Ach so, dachte ich, wir sind durch.

00:05:45.480 --> 00:05:47.300
8. April, also quasi

00:05:47.300 --> 00:05:49.420
bald, nicht übermorgen,

00:05:49.520 --> 00:05:51.180
aber in ein paar Tagen.

00:05:51.420 --> 00:05:53.040
Und zwar auf Wunsch von GitHub, weil die gesagt haben,

00:05:53.120 --> 00:05:53.820
oh, wir haben Schwierigkeiten,

00:05:54.020 --> 00:05:56.020
wir wissen nicht, ob das funktionieren wird,

00:05:56.100 --> 00:05:58.360
wenn wir als alle so eine Menge Issues erzeugen und so.

00:05:59.160 --> 00:06:00.100
Wartet lieber noch mal ein bisschen.

00:06:02.240 --> 00:06:03.700
Okay, ja gut, das ist jetzt nicht mehr so lange hin.

00:06:03.940 --> 00:06:05.440
Also ist jetzt quasi, wenn ihr es hört,

00:06:05.520 --> 00:06:06.580
vielleicht schon migriert.

00:06:07.320 --> 00:06:08.200
Oder kurz davor.

00:06:08.720 --> 00:06:10.980
Und gestern am 4.4. ist tatsächlich

00:06:10.980 --> 00:06:15.160
das Zeitentrack 20 Jahre geworden.

00:06:15.160 --> 00:06:18.160
Das ist auch ein richtiger Meilenstein.

00:06:18.540 --> 00:06:19.400
Hätte ich jetzt auch nicht gedacht,

00:06:19.500 --> 00:06:21.260
aber das ist natürlich alles

00:06:21.260 --> 00:06:21.600
irgendwie,

00:06:22.540 --> 00:06:24.660
ja, Zeitgefühl, komische Sache.

00:06:24.780 --> 00:06:26.480
Schon ein bisschen abgehangen, wie man alt wird.

00:06:26.660 --> 00:06:29.320
Ja, aber Sighten ist total wichtig, super, also immer wenn man sich fragt,

00:06:29.700 --> 00:06:29.960
okay,

00:06:31.420 --> 00:06:33.240
ja, Python selber langsam, aber

00:06:33.240 --> 00:06:35.340
macht trotzdem Dinge schnell und so,

00:06:35.400 --> 00:06:37.160
wie geht denn das eigentlich? Ja, da ist meistens Sighten

00:06:37.160 --> 00:06:38.040
daran beteiligt und

00:06:38.040 --> 00:06:40.880
ja, tolles Projekt,

00:06:40.880 --> 00:06:42.820
irgendwie man schreibt so eine Python-ähnliche

00:06:42.820 --> 00:06:44.800
Syntax und das wird

00:06:44.800 --> 00:06:46.220
dann halt in C

00:06:46.220 --> 00:06:48.880
Cross-Compile sozusagen. Man kann auch C-Funktionen

00:06:48.880 --> 00:06:50.220
Direkt laden, glaube ich, wenn man das möchte.

00:06:50.380 --> 00:06:52.520
Ja, genau. Und dann kann man es wieder einbinden

00:06:52.520 --> 00:06:54.700
als Python-Modul. Und dann gibt es sogar

00:06:54.700 --> 00:06:56.720
sowas wie ein Cellmagic

00:06:56.720 --> 00:06:58.820
in Jupyter Notebooks oder JupyterLab.

00:06:59.020 --> 00:06:59.800
Und da kann man einfach sagen,

00:07:00.400 --> 00:07:02.020
Prozent, Prozent, Zeiten. Und dann

00:07:02.020 --> 00:07:04.720
wird das halt, wird eine Funktion

00:07:04.720 --> 00:07:06.100
einfach so wieder reimportiert.

00:07:06.200 --> 00:07:07.960
Und dann wird die halt tausendmal schneller oder so.

00:07:08.400 --> 00:07:09.600
Das ist halt sehr schick.

00:07:10.700 --> 00:07:10.820
Ja.

00:07:12.280 --> 00:07:14.400
Ja, okay. Also apropos, kennst du

00:07:14.400 --> 00:07:15.680
V, die Language?

00:07:16.300 --> 00:07:17.780
V-Lang? V? Ja.

00:07:18.000 --> 00:07:19.800
bin ich irgendwie letztens drüber gestolpert, weil ein Kollege

00:07:19.800 --> 00:07:21.660
mich draufbrachte und

00:07:21.660 --> 00:07:24.200
habe ich mal geguckt, kannte ich noch nicht, ist nur noch in so einer Beta-Version.

00:07:24.720 --> 00:07:26.180
Sieht irgendwie witzig aus, so eine

00:07:26.180 --> 00:07:27.980
Kombination von Rust

00:07:27.980 --> 00:07:29.020
und Go irgendwie.

00:07:29.720 --> 00:07:31.820
Ja, momentan ist auch wieder so die Zeit

00:07:31.820 --> 00:07:33.900
für neue Programmiersprachen. Letztens

00:07:33.900 --> 00:07:34.840
habe ich gehört von SICK.

00:07:35.940 --> 00:07:37.340
SICK? Das ist auch so ein

00:07:37.340 --> 00:07:39.760
toller, lustiger Name, dass das wieder so irgendwann drüber fällt,

00:07:39.820 --> 00:07:40.480
aber den Namen direkt so.

00:07:43.140 --> 00:07:43.760
Ja, das

00:07:43.760 --> 00:07:45.660
sieht auch so ein bisschen aus wie eine Kreuzung aus Go

00:07:45.660 --> 00:07:47.340
und JavaScript und

00:07:47.340 --> 00:07:49.580
irgendwie Rust und

00:07:49.580 --> 00:07:50.740
weiß nicht, ganz vielen Dingen.

00:07:51.580 --> 00:07:53.760
Also ich habe es noch nicht reingeguckt, also falls ihr darüber was wisst,

00:07:53.800 --> 00:07:55.380
das könnte auch interessant sein. Also wie lang

00:07:55.380 --> 00:07:57.680
I.O.? Okay, muss ich mir auch mal

00:07:57.680 --> 00:07:58.020
angucken.

00:08:00.160 --> 00:08:01.560
Komplett auch zu zäh, deswegen kam ich

00:08:01.560 --> 00:08:03.040
gerade drauf. Ach so,

00:08:03.340 --> 00:08:05.140
okay, das ist auch interessant.

00:08:06.640 --> 00:08:06.780
Ja.

00:08:08.180 --> 00:08:08.720
War witzig.

00:08:09.980 --> 00:08:10.240
Ja.

00:08:11.820 --> 00:08:13.260
Ja. Okay.

00:08:13.840 --> 00:08:15.100
Dann sind wir eigentlich schon fast,

00:08:15.320 --> 00:08:17.140
das war diesmal schnell. Ja, wir haben

00:08:17.140 --> 00:08:20.020
Ja, dann sind wir damit eigentlich durch.

00:08:20.140 --> 00:08:21.780
Achso, haben wir eigentlich

00:08:21.780 --> 00:08:23.020
Veranstaltungshinweise oder sowas?

00:08:23.880 --> 00:08:25.400
Ja, das sollten wir. Achso, du wolltest

00:08:25.400 --> 00:08:26.220
zur PyCon, bist du da?

00:08:27.860 --> 00:08:29.360
Momentan sieht es nicht danach aus.

00:08:30.380 --> 00:08:31.460
Ich hätte jetzt zufällig, also

00:08:31.460 --> 00:08:32.400
zuerst hatte ich gedacht,

00:08:33.220 --> 00:08:35.840
das schaffe ich

00:08:35.840 --> 00:08:37.680
irgendwie nicht, beziehungsweise ich habe gar nicht so richtig mitbekommen,

00:08:37.680 --> 00:08:39.460
dass das überhaupt stattfindet, also vor Ort,

00:08:39.580 --> 00:08:41.200
weil das wäre für mich interessant geworden, aber

00:08:41.200 --> 00:08:43.120
nicht vor Ort halt eher nicht so richtig,

00:08:43.700 --> 00:08:45.580
weil das schaffe ich eben, das habe ich auch schon mal

00:08:45.580 --> 00:08:47.100
probiert, wie Remote aufkommt.

00:08:47.500 --> 00:08:48.340
Aber es funktioniert einfach nicht.

00:08:48.340 --> 00:08:50.140
Du warst so eine halbe Stunde da und dann so, pa, pa.

00:08:50.420 --> 00:08:51.540
Ja, genau. Und dann ist es halt vorbei.

00:08:52.220 --> 00:08:54.100
Und das funktioniert einfach nicht.

00:08:54.240 --> 00:08:56.380
Also, wenn das funktionieren soll, muss ich da irgendwo hin

00:08:56.380 --> 00:08:57.720
und getrennt sein von irgendwie

00:08:57.720 --> 00:08:59.040
anderweitigen Verpflichtungen.

00:08:59.700 --> 00:09:02.180
Und da habe ich das halt nicht so mitgekriegt,

00:09:02.240 --> 00:09:03.340
dass das tatsächlich vor Ort sein sollte.

00:09:03.460 --> 00:09:06.200
Und dann habe ich es mitgekriegt und dann waren aber schon

00:09:06.200 --> 00:09:08.240
Tickets. Und dann dachte ich, ich hätte gerne Zeit.

00:09:08.340 --> 00:09:10.680
Und dann habe ich dann gemerkt, oh, ich habe vielleicht doch Zeit.

00:09:10.760 --> 00:09:11.880
Und dann waren aber keine Tickets mehr da.

00:09:11.880 --> 00:09:13.280
Also insofern, ja.

00:09:14.040 --> 00:09:15.940
Na gut, wenn es darin lag. Aber vielleicht machen wir auch

00:09:15.940 --> 00:09:17.940
nochmal eine Sendung oder so dazu, wie

00:09:17.940 --> 00:09:20.060
das da gewesen ist, von Finden noch Leute, die da

00:09:20.060 --> 00:09:21.980
waren und dann davon erzählen können. Ja, das wollen die mal fragen oder so?

00:09:22.040 --> 00:09:23.540
Vielleicht sind die ja da. Genau, den habe ich schon gefragt.

00:09:24.120 --> 00:09:26.060
Er hat sich auch schon gemeldet und weiter eigentlich auch.

00:09:26.420 --> 00:09:27.920
Okay, cool. Also gibt es doch irgendwann

00:09:27.920 --> 00:09:29.980
eine Pike und Folge. Ja. Ja, im Sommer

00:09:29.980 --> 00:09:31.940
EuroPython-Tickets sind auch gerade draußen. Da gibt es

00:09:31.940 --> 00:09:33.960
sogar noch welche von, glaube ich. Das war noch nicht so super

00:09:33.960 --> 00:09:35.880
angelaufen, der Vorverkauf, obwohl die so schnell

00:09:35.880 --> 00:09:38.040
immer weg waren sonst. Genau, da

00:09:38.040 --> 00:09:39.940
in Dublin, also wenn ihr mit mir abends

00:09:39.940 --> 00:09:41.860
in Dublin ein Bierchen trinken wollt. Da könnte

00:09:41.860 --> 00:09:43.680
es auch gut sein, dass ich damit

00:09:43.680 --> 00:09:45.920
würde ich gerne machen.

00:09:46.300 --> 00:09:47.900
Ich bin gespannt. Und dann gibt es noch

00:09:47.900 --> 00:09:49.780
die, also gut, dass es jetzt nicht mehr so

00:09:49.780 --> 00:09:51.720
gemeint hat. Das Conference Center in Dublin ist

00:09:51.720 --> 00:09:53.880
relativ nah an der Brewdog-Außenstelle.

00:09:54.720 --> 00:09:55.820
Das ist ja kritisch.

00:09:55.960 --> 00:09:56.500
Ja, genau.

00:09:59.580 --> 00:10:01.060
Das Angenehme mit dem Nützlichen.

00:10:01.500 --> 00:10:02.880
Ja, super Verbindung.

00:10:05.520 --> 00:10:07.180
Genau, und im Herbst, irgendwann

00:10:07.180 --> 00:10:09.600
September, gibt es die DjangoCon EU,

00:10:09.600 --> 00:10:11.460
diesmal auch tatsächlich vor Ort und in

00:10:11.460 --> 00:10:13.380
Porto. Die sollte ja eigentlich letzten beiden Jahren in Porto

00:10:13.380 --> 00:10:15.020
stattfinden, aber hat es ja nicht.

00:10:15.600 --> 00:10:17.200
Und genau da denke ich

00:10:17.200 --> 00:10:18.920
ja wahrscheinlich leider nicht, weil

00:10:18.920 --> 00:10:20.780
irgendwie so viele Konferenzen...

00:10:20.780 --> 00:10:21.540
Ist Johannes da?

00:10:22.980 --> 00:10:25.240
Habe ich noch nicht gefragt. Aber wer auf jeden Fall da ist,

00:10:25.240 --> 00:10:26.440
ist Ronny. Ronny ist da, stimmt.

00:10:26.640 --> 00:10:28.720
Das ganze Team ist da. Das ist natürlich ein bisschen schade.

00:10:29.000 --> 00:10:31.100
Das wäre natürlich nett. Das wäre schön, ja.

00:10:32.260 --> 00:10:32.500
Ja.

00:10:33.240 --> 00:10:35.160
Naja. Ja, jetzt haben wir doch noch ein bisschen

00:10:35.160 --> 00:10:36.620
News gemacht. Okay.

00:10:37.140 --> 00:10:39.000
Gut. Dann kommt jetzt wieder der obligatorische

00:10:39.000 --> 00:10:39.940
Werbeblock. Habt ihr das schon gehört?

00:10:41.120 --> 00:10:43.160
Und diesmal ist Janis dran. Janis darf Werbeblock.

00:10:43.180 --> 00:10:45.960
Ich darf Werbung machen, als Neuling.

00:10:46.140 --> 00:10:47.020
Ja, wofür mache ich Werbung?

00:10:47.440 --> 00:10:49.340
Ich mache Werbung für meinen Arbeitgeber.

00:10:49.460 --> 00:10:51.100
Ich arbeite bei Elio.

00:10:51.200 --> 00:10:55.660
Wir machen Consulting mit Fokus auf künstliche Intelligenz

00:10:55.660 --> 00:10:57.880
und den Weg dahin, alles, was dazugehört.

00:10:58.020 --> 00:10:58.860
Und ihr sucht neue Leute?

00:10:59.040 --> 00:11:00.220
Wir suchen neue Leute, genau.

00:11:00.940 --> 00:11:02.300
Wie hieß die Domain nochmal?

00:11:02.480 --> 00:11:03.600
Ich versuche die gerade, Elio?

00:11:03.840 --> 00:11:07.360
Elio.de, A-I-L-I-O.de.

00:11:08.320 --> 00:11:11.780
Quasi AI im Namen, als Programm, wenn man so möchte.

00:11:12.420 --> 00:11:20.440
Genau und wir suchen neue Leute, immer. Also es ist wahrscheinlich sogar ziemlich egal, wann du die Folge hörst. Wir suchen dich.

00:11:20.520 --> 00:11:21.880
Was müssen die Leute können, die zu euch kommen?

00:11:22.360 --> 00:11:34.500
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.

00:11:35.300 --> 00:11:41.380
Aber auch ganz, ganz normale Backend-Tools, sage ich jetzt mal, sind sehr herzlich willkommen und sehr gerne gesehen.

00:11:42.340 --> 00:11:50.100
Generell haben wir den Ansatz, dass man wunderbar in Rollen hineinwachsen kann und wir jeden dabei unterstützen wollen.

00:11:50.120 --> 00:11:52.300
Das heißt, wenn Pandas dein Lieblings-Tool ist, ist das vielleicht auch interessant?

00:11:52.820 --> 00:11:53.240
Welches Tool?

00:11:53.560 --> 00:11:53.880
Pandas.

00:11:54.060 --> 00:11:54.780
Pandas, ja klar.

00:11:55.640 --> 00:11:57.400
Sicher, ist ja Data Science, ne?

00:11:57.440 --> 00:11:59.640
Ja, Data Science und Python passt natürlich eigentlich schon ziemlich gut zusammen.

00:12:00.120 --> 00:12:03.300
Und da kann man dann wahrscheinlich auch remote arbeiten oder so.

00:12:03.300 --> 00:12:05.160
Eigentlich sitzt ihr im Bielefeld, sehe ich gerade.

00:12:05.460 --> 00:12:06.600
Genau, wir sitzen im Bielefeld.

00:12:07.280 --> 00:12:08.860
Remote-Arbeit. Ich arbeite

00:12:08.860 --> 00:12:11.220
sehr viel remote. Wir haben immer

00:12:11.220 --> 00:12:13.120
so einen Stammtisch irgendwie, damit man sich doch auch mal

00:12:13.120 --> 00:12:14.920
in Person sieht. Aber rein

00:12:14.920 --> 00:12:17.540
optional, sage ich jetzt mal.

00:12:18.520 --> 00:12:18.880
Insofern

00:12:18.880 --> 00:12:21.160
sind wir gespannt. Das klingt gut. Also falls

00:12:21.160 --> 00:12:22.500
ihr einen Job sucht, dann schaut doch mal da vorbei.

00:12:23.440 --> 00:12:25.300
Ich würde mich freuen. Klingt, als wären es nette Jungs

00:12:25.300 --> 00:12:26.900
und Kollegen. Mindestens einer.

00:12:28.400 --> 00:12:28.760
Mindestens.

00:12:29.860 --> 00:12:31.440
Ja, vielleicht auch mehr.

00:12:31.560 --> 00:12:33.240
Ich habe davon gehört. Du musst jetzt noch persönliche

00:12:33.240 --> 00:12:35.540
Coachings und Benefits anbieten von dir

00:12:35.540 --> 00:12:37.440
aus, damit das dann... Ja, würde ich natürlich

00:12:37.440 --> 00:12:39.300
machen. Also wenn du Hörer der

00:12:39.300 --> 00:12:41.380
Folge bist und so begeistert

00:12:41.380 --> 00:12:43.200
von mir bist. Genau, dann gibt es einen Aktionskurs

00:12:43.200 --> 00:12:43.640
Jan.

00:12:46.640 --> 00:12:47.260
Schreibe mich an.

00:12:47.340 --> 00:12:49.260
Genau, eine E-Mail-Adresse und eine Internetseite

00:12:49.260 --> 00:12:51.860
gibt es auch, ljo.de, business.ljo.de

00:12:51.860 --> 00:12:53.460
da könnt ihr euch gerne hinbewerben.

00:12:53.560 --> 00:12:55.260
Ansonsten gibt es bestimmt auch irgendwo so einen

00:12:55.260 --> 00:12:57.200
Text, wo man sowas verlinken kann bei euch im Podcast.

00:12:57.220 --> 00:12:58.860
Ja, und vielleicht genau, wenn man sich meldet, dann

00:12:58.860 --> 00:13:01.020
dazu sagen, dass das über

00:13:01.020 --> 00:13:03.060
Python-Podcast, dass man sich da das

00:13:03.060 --> 00:13:05.160
gehört hat, weil dann kann man das vielleicht so ein bisschen

00:13:05.160 --> 00:13:06.960
irgendwie

00:13:06.960 --> 00:13:09.020
verfolgen. Da habt ihr auf jeden Fall bessere Chancen,

00:13:09.100 --> 00:13:11.760
da wissen wir auch, dass ihr interessiert seid.

00:13:13.140 --> 00:13:13.660
Keine Ahnung,

00:13:13.740 --> 00:13:14.620
ob das irgendjemand hört,

00:13:14.740 --> 00:13:16.220
der auf der Suche ist.

00:13:16.500 --> 00:13:18.960
Ich glaube tatsächlich, das hat einen Wert. Also ich wurde mal

00:13:18.960 --> 00:13:20.640
gefragt in einem Interview,

00:13:20.980 --> 00:13:23.140
welche Bücher und Podcasts ich so empfehlen kann.

00:13:23.240 --> 00:13:23.840
Das war ganz lustig.

00:13:24.720 --> 00:13:27.080
Python-Podcast ist mir vielleicht in den

00:13:27.080 --> 00:13:28.000
Sinn gekommen, vielleicht auch nicht.

00:13:29.080 --> 00:13:31.120
Ich wurde tatsächlich auch im Arbeitskontest

00:13:31.120 --> 00:13:32.080
von jemandem angesprochen.

00:13:32.880 --> 00:13:34.400
Also ein Projektmanager war, der für ein

00:13:34.400 --> 00:13:36.740
größeres Projekt irgendwie gehört hatte,

00:13:36.800 --> 00:13:38.720
was da so gibt und der einen Danko-Podcast von uns gehört hat

00:13:38.720 --> 00:13:40.580
und dachte so, oh cool, da warst du nicht der Typ mit dem Podcast.

00:13:40.760 --> 00:13:41.560
Ja, interessant.

00:13:42.200 --> 00:13:44.100
Das hilft manchmal, ne? Also das ist schon cool.

00:13:44.840 --> 00:13:46.520
Genau. Ja, schick. Okay. Super.

00:13:46.920 --> 00:13:48.840
Hört mal rein. Ja. Wenn ihr was sucht,

00:13:49.120 --> 00:13:50.720
wisst ihr jetzt wo. Oder nichts sucht

00:13:50.720 --> 00:13:52.780
und doch zu uns wollen, ne?

00:13:53.720 --> 00:13:54.500
Man weiß ja nie.

00:13:54.940 --> 00:13:56.260
Ja. Okay, genau.

00:13:56.260 --> 00:13:57.720
Dann, ja, Thema diesmal

00:13:57.720 --> 00:13:58.580
Microservices.

00:14:00.000 --> 00:14:02.040
Ja, also ich habe ja wie immer keine Ahnung

00:14:02.040 --> 00:14:04.000
und will erst mal, was ist denn überhaupt so ein Microservice?

00:14:04.860 --> 00:14:05.980
Ja, was ist das denn? Wer soll das

00:14:05.980 --> 00:14:07.240
dann erklären? Ja, keine Ahnung.

00:14:07.660 --> 00:14:10.000
Möchtest du anfangen oder so? Ich kann gerne anfangen.

00:14:10.140 --> 00:14:12.280
Also es gibt relativ harte Definitionen

00:14:12.280 --> 00:14:13.940
darüber. Ich bin da kein Freund von.

00:14:14.360 --> 00:14:16.080
Also im Prinzip ist ein Microservice erst mal

00:14:16.080 --> 00:14:17.820
etwas, was wenig Sachen macht,

00:14:17.920 --> 00:14:19.740
aber dafür sehr gut. So würde ich es beschreiben.

00:14:20.880 --> 00:14:22.080
Man stellt es ja ganz gerne

00:14:22.080 --> 00:14:24.040
mal so einem Monolithen gegenüber und wir

00:14:24.040 --> 00:14:26.100
haben schon vorrangig überlegt,

00:14:26.180 --> 00:14:27.620
wollen wir jetzt so ein Versus-Ding machen oder nicht?

00:14:27.720 --> 00:14:54.240
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.

00:14:54.880 --> 00:14:55.180
Okay.

00:14:55.460 --> 00:14:56.680
Das ist die Meinung von Janis.

00:14:57.280 --> 00:14:58.380
Ja, okay.

00:14:58.500 --> 00:15:02.000
Da haben wir schon die Seiten geklärt.

00:15:03.180 --> 00:15:04.220
Ja, ganz so ist es nicht.

00:15:04.380 --> 00:15:05.460
Das ist ein bisschen plakativ.

00:15:06.140 --> 00:15:07.840
Werden wir noch sehen, ob das wirklich so ist am Ende.

00:15:08.860 --> 00:15:10.340
Ja, aber das ist doch genau spannend jetzt.

00:15:10.340 --> 00:15:16.320
Also du sagst, Microservices sind quasi eine isolierte Funktionalität.

00:15:16.680 --> 00:15:16.980
Genau.

00:15:18.140 --> 00:15:20.060
Wenn ich jetzt eine Anwendung habe.

00:15:20.440 --> 00:15:21.960
Wir tun jetzt mal so, als wäre es eine Web-Anwendung.

00:15:22.060 --> 00:15:23.440
Vielleicht ist das am einfachsten zu verstehen.

00:15:24.060 --> 00:15:32.760
Das heißt, es gibt ein Frontend und die bezieht dann ihre Quellen aus unterschiedlichen, ja, also ihre Bestandteile, ihre Logik aus unterschiedlichen Quellen.

00:15:34.000 --> 00:15:37.620
Aus dem jeweils einzelnen Microservice, würdest du sagen, das ist eine gute Idee?

00:15:38.580 --> 00:15:45.560
Es gibt verschiedene Ansätze, das ist Thema Best Practice, sag ich jetzt mal, und auch immer so ein bisschen ein Thema der Architektur.

00:15:45.560 --> 00:15:51.180
Also ich glaube, das werden wir im Laufe der Folge, wenn ich in die Zukunft gucke, immer mal häufiger hören.

00:15:52.460 --> 00:15:55.060
Man kann sich natürlich verschiedene API-Endpunkte suchen

00:15:55.060 --> 00:15:56.000
und alle einzeln anfragen.

00:15:56.180 --> 00:15:57.640
Das ist, würde ich sagen, aber keine gute Idee.

00:15:58.320 --> 00:16:00.760
Da gibt es dann meistens API-Gateways

00:16:00.760 --> 00:16:03.040
beziehungsweise eine Schnittstelle, die man anfragt,

00:16:03.160 --> 00:16:04.220
die verschiedene Endpunkte sammeln.

00:16:05.440 --> 00:16:07.060
Genau, darüber hatte ich eben auch schon mal, glaube ich,

00:16:07.080 --> 00:16:09.540
ganz kurz mit Jochen gesprochen, weil es ja genau darum geht,

00:16:09.660 --> 00:16:10.500
also wer ist dann die Spinne im Netz?

00:16:10.620 --> 00:16:12.200
Wovon bekommt man das, wenn man jetzt ein Frontend hat?

00:16:12.320 --> 00:16:14.000
Sollte das Frontend die einsammeln einzeln

00:16:14.000 --> 00:16:15.380
oder holt man das von so einem Gateway ab?

00:16:15.660 --> 00:16:17.040
Oder wie macht man das am liebsten?

00:16:17.220 --> 00:16:19.500
Ja, keine Ahnung.

00:16:19.620 --> 00:16:21.920
Also ich glaube, wenn man das wirklich konsequent machen wollen würde,

00:16:22.020 --> 00:16:23.840
dann müsste man ja auch im Frontend das sozusagen

00:16:23.840 --> 00:16:26.200
Mikrofrontends

00:16:26.200 --> 00:16:26.800
müsste man machen.

00:16:28.840 --> 00:16:30.540
Da muss ich halt

00:16:30.540 --> 00:16:32.000
ehrlich sagen, ich mach kein Frontend.

00:16:32.920 --> 00:16:34.400
Wer liefert denn das Mikrofrontend aus?

00:16:34.460 --> 00:16:36.360
Also wenn man zum Beispiel in HTMLX das ausliefert,

00:16:36.440 --> 00:16:38.420
dann wäre ein Django ein sogenannter Spinne

00:16:38.420 --> 00:16:40.560
oder so ein Aggregator, ein Gabi-Gateway,

00:16:40.920 --> 00:16:42.440
wo ich jetzt das Wording da immer nicht ganz

00:16:42.440 --> 00:16:43.360
treffen würde, ehrlich gesagt.

00:16:44.920 --> 00:16:46.580
Das spielt dann letztlich ja

00:16:46.580 --> 00:16:48.300
keine große Rolle mehr,

00:16:48.420 --> 00:16:50.400
weil du musst ja dann, das wäre nur noch eine statische

00:16:50.400 --> 00:16:52.180
Seite. Also was ich mir jetzt halt da kompliziert

00:16:52.180 --> 00:16:54.200
darin vorstelle, ist, wenn ich so ganz viele verschiedene Zeug habe,

00:16:54.280 --> 00:16:56.160
aber ich habe ja eigentlich nur eine Anwendung, warum mache ich das

00:16:56.160 --> 00:16:58.160
nicht in der einen Anwendung direkt und habe dann diesen

00:16:58.160 --> 00:16:59.980
ganzen Gefummel mit dem ganzen

00:16:59.980 --> 00:17:02.200
drumherum nicht? Darüber wollen

00:17:02.200 --> 00:17:03.220
wir ja reden, ne? Ja. Also

00:17:03.220 --> 00:17:06.160
das ist ja das Ziel der Folge, eine kurze Folge, wenn wir das jetzt

00:17:06.160 --> 00:17:08.080
so einfach und so schnell machen. Ein Satz fertig, ja,

00:17:08.100 --> 00:17:09.580
danke schön, ja, heute haben wir euch nicht so lange.

00:17:09.860 --> 00:17:12.140
Nee, ganz so ist es natürlich nicht. Man muss halt

00:17:12.140 --> 00:17:14.340
auch immer sehen, welche verschiedenen Funktionalitäten

00:17:14.340 --> 00:17:16.080
man haben möchte, ne? Wir sind jetzt im Bereich

00:17:16.080 --> 00:17:18.180
Web unterwegs, ne, von deinem Beispiel.

00:17:18.600 --> 00:17:19.880
Das klingt erstmal sehr, sehr einfach,

00:17:20.080 --> 00:17:37.360
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.

00:17:37.360 --> 00:17:56.100
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.

00:17:58.780 --> 00:18:01.160
Also genau, vielleicht einfach hake ich an der Stelle mal ein

00:18:01.160 --> 00:18:02.960
und sage mal so etwas, was ich denken würde,

00:18:03.040 --> 00:18:04.360
was Microservice ist.

00:18:04.940 --> 00:18:06.920
Und ich würde denken, der entscheidende Punkt dabei ist eben

00:18:06.920 --> 00:18:09.060
die Einheit, wie deployed man das.

00:18:09.280 --> 00:18:09.960
Also alles, was man,

00:18:10.820 --> 00:18:12.900
wenn man es insgesamt, wenn man es halt getrennt

00:18:12.900 --> 00:18:14.940
deployt, dann ist es halt ein Microservice, würde ich

00:18:14.940 --> 00:18:15.560
jetzt mal so sagen.

00:18:17.240 --> 00:18:18.940
Oder getrennt deployen kann

00:18:18.940 --> 00:18:20.880
und also wenn es halt irgendwie,

00:18:20.880 --> 00:18:22.840
wenn die gesamte Applikation

00:18:22.840 --> 00:18:24.580
etwas ist, was man insgesamt deployt, dann ist es halt

00:18:24.580 --> 00:18:25.680
irgendwie eher Monolith.

00:18:26.580 --> 00:18:28.740
Und eben, Microservice hat halt den Vorteil, du kannst halt da

00:18:28.740 --> 00:18:30.620
unterschiedliche Technologien ausprobieren, du kannst halt

00:18:30.620 --> 00:18:32.780
unterschiedliche Sprachen verwenden, man sagt mal auch immer, man sollte

00:18:32.780 --> 00:18:34.900
das halt so machen, dass man da quasi

00:18:34.900 --> 00:18:36.380
unterschiedliche Sprachen verwenden kann,

00:18:36.840 --> 00:18:38.220
dass sie halt möglichst irgendwie

00:18:38.220 --> 00:18:41.240
ja, ihre eigene Datenhaltung

00:18:41.240 --> 00:18:42.840
irgendwie haben oder zumindest ihre eigene Sicht

00:18:42.840 --> 00:18:44.720
auf die Daten und da ist man dann halt schon

00:18:44.720 --> 00:18:46.500
so ein bisschen bei dem, ich weiß nicht, diesen

00:18:46.500 --> 00:18:48.720
Domain-Driven-Design-Ansatz, da gibt es

00:18:48.720 --> 00:18:50.420
immer diesen Begriff

00:18:50.420 --> 00:18:52.500
Bounded Context und das ist halt immer so das, was man

00:18:52.500 --> 00:18:53.820
so, ja, das ist klassischerweise

00:18:53.820 --> 00:18:55.560
Bounded Context.

00:18:56.280 --> 00:18:58.520
Jetzt musst du wieder erklären, was Bounded Context ist.

00:18:58.740 --> 00:19:20.400
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.

00:19:20.400 --> 00:19:29.000
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.

00:19:29.480 --> 00:19:43.840
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?

00:19:43.840 --> 00:19:45.740
Ich glaube auch, dass der Grund,

00:19:46.240 --> 00:19:48.320
vielleicht der Name, das kommt daher, dass es halt

00:19:48.320 --> 00:19:50.240
unterschiedliche Dinge in unterschiedlichen Kontexten

00:19:50.240 --> 00:19:52.260
bedeuten kann. Also zum Beispiel User ist halt

00:19:52.260 --> 00:19:54.260
was anderes, wenn du dich auf einer Webseite einloggen

00:19:54.260 --> 00:19:56.180
möchtest oder kann halt was anderes sein

00:19:56.180 --> 00:19:58.160
als User oder

00:19:58.160 --> 00:20:00.160
Personen, an die irgendwas geschickt wird

00:20:00.160 --> 00:20:01.600
im Kontext einer

00:20:01.600 --> 00:20:04.340
irgendwas Bestellung oder

00:20:04.340 --> 00:20:06.280
so. Und in dem einen Fall hat man halt da

00:20:06.280 --> 00:20:08.260
komplizierte Adressgeschichten und weiß der Teufel

00:20:08.260 --> 00:20:10.160
irgendwie Zeugs und im anderen Fall braucht man das gar nicht, weil

00:20:10.160 --> 00:20:12.040
da muss man nur überprüfen, stimmt der Passwort

00:20:12.040 --> 00:20:13.860
Hash oder so und

00:20:13.860 --> 00:20:16.120
ja, je nachdem, welchem

00:20:16.120 --> 00:20:18.100
Kontext man unterwegs ist, ist

00:20:18.100 --> 00:20:19.980
das halt unterschiedlich und man erlaubt

00:20:19.980 --> 00:20:21.980
dann halt auch unterschiedlichen Kontexten

00:20:21.980 --> 00:20:24.060
die Daten unterschiedlich zu halten und unterschiedliche

00:20:24.060 --> 00:20:25.720
Sachen zu speichern und so. Okay, interessant, also

00:20:25.720 --> 00:20:27.600
Bounded-Kontext abstrahiert das so ein bisschen.

00:20:28.040 --> 00:20:30.200
Was aber jetzt dafür sprechen würde, in dem Beispiel, was du gesagt hast,

00:20:30.340 --> 00:20:31.520
braucht man ja irgendwie eine

00:20:31.520 --> 00:20:33.940
Wahrheit der Daten, wenn das

00:20:33.940 --> 00:20:36.180
ja, das ist dann glaube ich,

00:20:36.180 --> 00:20:37.020
dann wird es ein bisschen schwieriger.

00:20:37.880 --> 00:20:38.940
Single Point of Truth,

00:20:39.060 --> 00:20:41.100
das ist eine Herausforderung.

00:20:41.760 --> 00:20:46.100
Also ich sage jetzt mal, das ist eine ganz gängige Frage,

00:20:46.360 --> 00:20:49.120
wer leistet man den in Microservices?

00:20:49.580 --> 00:20:52.560
Und eine Frage, die damit einhergeht, ist immer das Datenmanagement.

00:20:54.540 --> 00:20:55.900
Entschuldigung, dass ich euch gerade direkt einhabe,

00:20:56.020 --> 00:20:57.880
aber was heißt Datenmanagement?

00:20:58.860 --> 00:21:01.580
Ein Microservice beziehungsweise Microservices allgemein

00:21:01.580 --> 00:21:03.860
zeichnen sich ja dadurch aus, dass das isolierte Systeme sind.

00:21:03.860 --> 00:21:07.060
Also im Idealfall hält jeder Microservice genau die Daten,

00:21:07.200 --> 00:21:08.220
die er braucht oder eben nicht.

00:21:08.520 --> 00:21:10.140
Und wenn er die Daten nicht hält,

00:21:10.820 --> 00:21:12.220
muss er natürlich überlegen, woher

00:21:12.220 --> 00:21:14.560
kriege ich meine Daten eigentlich? Und wie kriege ich sie?

00:21:15.220 --> 00:21:16.400
Und dann gibt es eben

00:21:16.400 --> 00:21:18.200
verschiedene Möglichkeiten, damit umzugehen.

00:21:18.280 --> 00:21:20.240
Ich könnte zum Beispiel mal irgendwie hier AP-Request

00:21:20.240 --> 00:21:22.200
gegen irgendeinen anderen Microservice machen,

00:21:22.420 --> 00:21:23.900
meinetwegen, und hole von da meine Daten.

00:21:24.340 --> 00:21:26.120
Habe dann aber den Nachteil, okay, das ist langsam

00:21:26.120 --> 00:21:28.540
und irgendwie kopple ich meine Microservices dann wieder zusammen.

00:21:28.720 --> 00:21:30.400
Genau, wenn es hinterher dieselben Datenbanken

00:21:30.400 --> 00:21:32.300
liegt, dann ist da die Frage, warum

00:21:32.300 --> 00:21:33.660
macht man da eine unterrichtliche Architektur?

00:21:34.080 --> 00:21:36.500
Aber vielleicht kann auch das so machen, wenn ich halt irgendwie hingehe

00:21:36.500 --> 00:21:38.220
und möchte aus derselben Datenbank

00:21:38.220 --> 00:21:39.960
Dinge erzeugen mit unterschiedlichen Sprachen

00:21:39.960 --> 00:21:41.800
und die dann... Ja, nicht dieselbe Datenbank.

00:21:41.940 --> 00:21:44.120
Genau, und dieselbe Datenbank wird schwierig,

00:21:44.240 --> 00:21:46.040
weil dann kannst du es halt nicht mehr getrennt voneinander deployen.

00:21:46.100 --> 00:21:47.960
Also wenn du jetzt zum Beispiel auf der, wenn du es in gemeinsamen

00:21:47.960 --> 00:21:50.300
Datenbank hast und du änderst die jetzt...

00:21:50.300 --> 00:21:51.980
Na gut, er kann ja einfach den Datenbank-Link deployen.

00:21:52.160 --> 00:21:54.160
Also die Datenbank kann ja noch ein dritter Punkt sein,

00:21:54.240 --> 00:21:55.960
der ganz unabhängig von den Services läuft.

00:21:55.960 --> 00:21:57.880
Ja, aber da kannst du es nicht mehr unabhängig

00:21:57.880 --> 00:21:59.980
deployen, weil wenn du jetzt die Datenbank änderst,

00:22:00.080 --> 00:22:01.340
dann hat das ja Auswirkungen auf den anderen.

00:22:01.640 --> 00:22:03.360
Hat das ja auch Auswirkungen auf die anderen Services.

00:22:03.780 --> 00:22:06.320
Ja, und es ist ein Single-Pointer-Failure.

00:22:06.520 --> 00:22:09.860
Also da rede ich aus ganz, ganz schmerzhafter Erfahrung.

00:22:10.320 --> 00:22:12.440
Wenn verschiedene Services an einer Datenbank hängen,

00:22:12.660 --> 00:22:14.760
verschiedene Microservices, und die Datenbank kippt um,

00:22:14.840 --> 00:22:16.300
dann kippen dir die Microservices auch um,

00:22:16.520 --> 00:22:18.600
weil irgendjemand Stoß gemacht hat.

00:22:18.960 --> 00:22:20.280
Das will man eigentlich auch vermeiden.

00:22:20.500 --> 00:22:23.460
Also das ist so ein Shared-Datenbank-Anti-Pattern, heißt das.

00:22:24.760 --> 00:22:28.180
Das macht man manchmal, weil es einfach schnell ist,

00:22:28.220 --> 00:22:29.080
weil es einfach einfacher ist.

00:22:29.500 --> 00:22:31.960
Aber wenn man wirklich Microservices macht und sie wirklich braucht,

00:22:31.960 --> 00:22:33.760
dann ist das eigentlich mal eine relativ schlechte Idee,

00:22:34.000 --> 00:22:37.420
wenn man sich da doch, wie gesagt, den Single-Point-of-Fail reinholt.

00:22:38.620 --> 00:22:41.280
Aber ja, eigentlich hat jeder Service seine eigene Daten,

00:22:41.420 --> 00:22:42.420
seine eigene Datenbank.

00:22:42.640 --> 00:22:43.580
Und du musst halt überlegen, okay,

00:22:44.540 --> 00:22:45.900
will ich jetzt mehrfach die gleichen Daten

00:22:45.900 --> 00:22:47.580
in verschiedenen Microservices verteilen?

00:22:47.920 --> 00:22:51.300
Oder will ich dafür sorgen, dass sich die einzelnen Microservices

00:22:51.300 --> 00:22:53.320
die Daten von anderen Microservices holen

00:22:53.320 --> 00:22:54.700
und erzeuge damit eine Kopplung

00:22:54.700 --> 00:22:56.460
und mache die Sache vielleicht ein bisschen unübersichtlicher,

00:22:56.600 --> 00:22:57.320
vielleicht ein bisschen langsamer?

00:22:57.740 --> 00:22:59.800
Und das beschreibt eben das Datenbankmanagement.

00:22:59.800 --> 00:23:08.780
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.

00:23:08.780 --> 00:23:10.900
Ja, da musst du vielleicht über diesen Flora am Anfang halt Gedanken machen.

00:23:11.060 --> 00:23:12.720
Also wo kommen die Daten überhaupt her?

00:23:13.120 --> 00:23:13.920
Und wo sollen die hin?

00:23:14.560 --> 00:23:16.580
Und dann, ja, also die Frage ist,

00:23:16.600 --> 00:23:18.200
ist das eine Architekturentscheidung, wenn du jetzt sagst,

00:23:18.280 --> 00:23:19.880
Design, Domain-Driven-Design?

00:23:20.960 --> 00:23:21.920
Was würde denn da...

00:23:21.920 --> 00:23:26.780
Damit sind noch keine Architekturentscheidungen gefallen quasi.

00:23:26.780 --> 00:23:29.880
Damit ist es halt einfach nur so ein Konzept,

00:23:30.000 --> 00:23:31.080
wie man Dinge angehen könnte.

00:23:31.720 --> 00:23:33.420
Ich stelle das ja so ein bisschen in den Raum dann vielleicht.

00:23:33.780 --> 00:23:34.700
Also die Wahl.

00:23:35.280 --> 00:23:37.660
Ja, also ich weiß es nicht.

00:23:37.780 --> 00:23:55.120
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.

00:23:55.400 --> 00:24:15.560
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.

00:24:17.100 --> 00:24:25.440
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.

00:24:26.920 --> 00:24:35.120
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?

00:24:35.120 --> 00:24:43.640
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.

00:24:44.400 --> 00:24:46.340
Also, ja, also es geht schon,

00:24:46.500 --> 00:24:47.720
aber es ist halt, die Frage wäre,

00:24:48.060 --> 00:24:49.220
würde man so anfangen wollen?

00:24:49.340 --> 00:24:50.300
Und da denke ich, ja,

00:24:51.520 --> 00:24:53.360
warum nicht einfach mit einem ganz normalen Datenbankschema anfangen?

00:24:53.860 --> 00:24:56.400
Genau, ja, aber das würde ja nicht für Microsoft versprechen,

00:24:56.520 --> 00:24:58.380
sondern für einen Monolithen oder einen Service, der...

00:24:58.380 --> 00:25:00.180
Es würde nicht dafür sprechen, damit anzufangen, ja, genau.

00:25:00.300 --> 00:25:02.380
Würde ich auch sagen, normalerweise sollte man einen Grund haben,

00:25:02.420 --> 00:25:02.880
warum man das macht.

00:25:02.900 --> 00:25:04.540
Also, das heißt, ich würde das auch so intuitiv sagen,

00:25:04.600 --> 00:25:06.380
du baust halt jetzt einmal dein Deployment

00:25:06.380 --> 00:25:08.120
für ein Tool, für eine Web-Anwendung

00:25:08.120 --> 00:25:09.740
und hast halt dann eine Datenbank dahinter

00:25:09.740 --> 00:25:13.280
und arbeitest dann damit und erweiterst sie halt.

00:25:13.700 --> 00:25:17.580
Und die Frage ist halt, wann komme ich denn überhaupt in diese Sphäre,

00:25:17.660 --> 00:25:19.400
dass ich sage, Microsoft wäre jetzt eine gute Idee

00:25:19.400 --> 00:25:21.440
oder das behilft mir irgendwo bei?

00:25:23.560 --> 00:25:25.180
Das ist unterschiedlich.

00:25:25.280 --> 00:25:26.300
Vielleicht erst mal eingehakt,

00:25:26.680 --> 00:25:28.240
noch bei diesem Datenbank-Auseinanderschneiden,

00:25:28.320 --> 00:25:29.920
das stelle ich mir sehr, sehr kompliziert vor.

00:25:30.340 --> 00:25:32.340
Das, was wesentlich einfacher ist, sich vorzustellen,

00:25:32.400 --> 00:25:34.820
ist, dass jeder Service tatsächlich seine eigene, echte Datenbank hat.

00:25:34.940 --> 00:25:38.240
Und man verteilt die Daten dann quasi auf verschiedene Microservices

00:25:38.240 --> 00:25:39.480
in ganz normalen Datenbanken.

00:25:39.480 --> 00:25:42.940
Also das, was du gesagt hast, das kam relativ kompliziert.

00:25:43.400 --> 00:25:45.240
Nee, gut, aber du hast ja dann das Problem.

00:25:45.480 --> 00:25:47.400
Du hast ja eine verteilte

00:25:47.400 --> 00:25:49.260
Datenhaltung, wo du nicht einfach einen Join

00:25:49.260 --> 00:25:50.900
machen kannst, sondern du musst dann halt...

00:25:50.900 --> 00:25:53.000
Ja, klar. Also das Datenmanagement selbst,

00:25:53.020 --> 00:25:54.720
das ist wesentlich komplizierter geworden.

00:25:54.880 --> 00:25:57.060
Aber die Datenhaltung pro Service, die ist immer noch

00:25:57.060 --> 00:25:59.280
relativ einfach. Und das muss man

00:25:59.280 --> 00:26:01.100
halt ganz klar sagen. Also die einzelnen

00:26:01.100 --> 00:26:03.120
Microservices in sich, die sind unglaublich

00:26:03.120 --> 00:26:05.040
einfach. Wenn du zum Beispiel

00:26:05.040 --> 00:26:06.700
Monolithen hast, und da kommen wir direkt zu deiner

00:26:06.700 --> 00:26:08.900
Frage, die du gestellt hast. Ein Monolith, der wird sehr schnell

00:26:08.900 --> 00:26:10.960
sehr kompliziert. Also gerade dann, wenn du viele

00:26:10.960 --> 00:26:12.820
Leute an einer Codebasis arbeiten hast, mit

00:26:12.820 --> 00:26:14.280
vielen verschiedenen Services da drin,

00:26:14.740 --> 00:26:16.560
die sich vielleicht auch gegenseitig affektieren.

00:26:16.820 --> 00:26:20.720
Also du bindest ja unter Umständen einzelne Services aneinander

00:26:20.720 --> 00:26:25.560
und du hast dann auf einmal teamübergreifende Bugs,

00:26:25.800 --> 00:26:27.940
meinetwegen, weil du eine gemeinsame Code-Basis hast.

00:26:28.660 --> 00:26:31.300
Dann denkt man schon relativ schnell bei Microservices nach.

00:26:31.620 --> 00:26:32.780
Okay, aber das klingt jetzt so,

00:26:32.860 --> 00:26:36.540
als wären die Apps jetzt nicht so gut getestet im Staging oder sowas

00:26:36.540 --> 00:26:40.060
und als würden jetzt Dinge, die halt eine Seite kaputt machen,

00:26:40.060 --> 00:26:40.900
andere Apps kaputt machen.

00:26:41.040 --> 00:26:43.020
wenn man jetzt beispielsweise in Django-Apps jetzt

00:26:43.020 --> 00:26:44.800
denkt, ja, wenn man das parallel

00:26:44.800 --> 00:26:46.760
entwickelt, dann könnte man die ja voneinander

00:26:46.760 --> 00:26:49.040
trennen, also. Im besten Fall

00:26:49.040 --> 00:26:50.460
tut man das, ja, das ist dann.

00:26:50.940 --> 00:26:52.940
Also wenn die sich gegenseitig differenzieren, kommt man natürlich in

00:26:52.940 --> 00:26:54.380
so ein Dependency-Problem vielleicht,

00:26:55.100 --> 00:26:56.900
aber. Ja, ja, ich glaube, also

00:26:56.900 --> 00:26:58.900
ich meine, das ist auch

00:26:58.900 --> 00:26:59.660
immer was, wo

00:26:59.660 --> 00:27:03.100
es geht eigentlich im Grunde, das zentrale

00:27:03.100 --> 00:27:04.960
Problem irgendwie bei der Softwareentwicklung ist eben dieses

00:27:04.960 --> 00:27:06.920
Modularisierungsproblem, das ist halt irgendwie so

00:27:06.920 --> 00:27:08.940
das Ding, was jeder hat und was irgendwie

00:27:08.940 --> 00:27:10.520
ganz einfach aussieht, wo alle sagen, ah, dann

00:27:10.520 --> 00:27:12.160
sondern halt ein bisschen modularisieren, kein Problem.

00:27:12.720 --> 00:27:14.240
Das ist aber tatsächlich sehr schwierig.

00:27:14.600 --> 00:27:16.340
Ja, User musst du sehr oft importieren.

00:27:16.480 --> 00:27:18.100
Das heißt, dass zum Beispiel, wenn da irgendwas kaputt geht,

00:27:18.180 --> 00:27:19.940
das ist schon doof dann wahrscheinlich.

00:27:21.000 --> 00:27:25.720
Ja, aber du kannst ja trotzdem sozusagen die Dinge irgendwie auseinanderhalten,

00:27:25.800 --> 00:27:27.280
die nichts miteinander zu tun haben.

00:27:27.360 --> 00:27:28.600
Wenn es nicht geht, dann geht es halt nicht.

00:27:28.600 --> 00:27:30.960
Aber dann kannst du immer noch die Abhängigkeiten explizit machen.

00:27:31.360 --> 00:27:34.080
Also man kann da schon was tun und man kann das richtig und falsch machen.

00:27:34.560 --> 00:27:35.740
Und meistens machen sie es total falsch.

00:27:37.380 --> 00:27:39.260
Und das, die allerschlimmsten

00:27:39.260 --> 00:27:41.080
Geschichten sind dann halt, oder wenn man es halt

00:27:41.080 --> 00:27:42.540
verteilt falsch macht, das ist halt

00:27:42.540 --> 00:27:45.240
ja, insofern, ich bin

00:27:45.240 --> 00:27:46.240
auch so ein bisschen immer

00:27:46.240 --> 00:27:49.260
also vorsichtig,

00:27:49.400 --> 00:27:51.180
weil häufig, was ich

00:27:51.180 --> 00:27:53.180
halt schon häufiger gesehen habe, ist,

00:27:53.280 --> 00:27:55.120
dass Leute dann sagen, also sie haben halt dieses

00:27:55.120 --> 00:27:57.080
Problem, das Standardproblem irgendwie, das

00:27:57.080 --> 00:27:59.160
alle haben in der Softwareentwicklung irgendwie, sie kriegen

00:27:59.160 --> 00:28:00.400
ihren Kram halt nicht organisiert,

00:28:01.160 --> 00:28:03.080
so richtig und richtig strukturiert

00:28:03.080 --> 00:28:04.940
und nicht modularisiert und

00:28:04.940 --> 00:28:07.260
dann nehmen sie halt

00:28:07.260 --> 00:28:09.280
irgendwie Teile, die kompliziert sind und machen daraus

00:28:09.280 --> 00:28:11.200
Mikroservices, weil sie sagen, ja, dann haben wir das

00:28:11.200 --> 00:28:13.260
irgendwie modularisiert. Aber das ist ja nicht so, sondern

00:28:13.260 --> 00:28:15.320
dann hat man es einfach nur verteilt. Das heißt, man hat ein Ding,

00:28:15.380 --> 00:28:17.300
was man nicht modularisiert hatte, verteilt und dann hat man

00:28:17.300 --> 00:28:18.920
halt einen verteilten Monolithen und das ist halt

00:28:18.920 --> 00:28:21.500
und das passiert leider

00:28:21.500 --> 00:28:21.840
sehr oft.

00:28:23.600 --> 00:28:25.120
Ja, insofern, genau.

00:28:25.720 --> 00:28:27.220
Aber ich glaube, dem kann man so ein bisschen entgehen,

00:28:27.300 --> 00:28:29.280
wenn man sich überlegt am Anfang so, wofür will ich das

00:28:29.280 --> 00:28:31.120
eigentlich bauen und warum mache ich das?

00:28:31.500 --> 00:28:33.040
Und dann geht das wahrscheinlich schon besser.

00:28:34.040 --> 00:28:35.100
Die Frage ist auch immer,

00:28:35.460 --> 00:28:38.160
ob man es besser oder schlimmer macht oder ob man überhaupt was am Zustand ändert.

00:28:38.340 --> 00:28:40.340
Ich meine, wenn man innerhalb seiner Architektur

00:28:40.340 --> 00:28:42.480
beziehungsweise innerhalb seines Codes Referenzen hat,

00:28:42.600 --> 00:28:44.120
dann hat man die ja automatisch nicht mehr nur,

00:28:44.220 --> 00:28:45.620
wenn man auf einmal Microsofts verwendet.

00:28:46.000 --> 00:28:47.680
Man verlagert das Problem.

00:28:48.040 --> 00:28:49.980
Aber ich sage jetzt mal, man macht die Sache halt,

00:28:50.440 --> 00:28:52.100
die Code-Basis selbst wesentlich einfacher

00:28:52.100 --> 00:28:54.520
und manchmal läuft man auch einfach in eine Situation,

00:28:55.000 --> 00:28:58.260
wo man feststellt, okay, die Funktion, die ich jetzt hier machen möchte,

00:28:58.380 --> 00:28:58.960
die ist...

00:28:58.980 --> 00:29:18.220
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.

00:29:18.220 --> 00:29:31.540
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.

00:29:31.600 --> 00:29:36.600
Also du willst eine Socke-Verbindung aufmachen zu einem Kafka oder einer anderen Q?

00:29:37.820 --> 00:29:58.820
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.

00:30:00.140 --> 00:30:19.260
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?

00:30:22.920 --> 00:30:41.220
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.

00:30:41.940 --> 00:31:02.180
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.

00:31:02.460 --> 00:31:03.960
Aber das ist ja kein API-Gateway.

00:31:04.680 --> 00:31:06.080
Nein, gut, aber du hast halt

00:31:06.080 --> 00:31:07.860
andere Services, andere Teile der Applikation

00:31:07.860 --> 00:31:09.620
arbeiten irgendwo auf einer ganz anderen

00:31:09.620 --> 00:31:11.940
Maschine, mit einem ganz anderen

00:31:11.940 --> 00:31:13.420
Deployment und die liefern mir irgendwas.

00:31:16.320 --> 00:31:16.680
Ja.

00:31:18.360 --> 00:31:20.100
Also ich kann die auch schwer testen oder sowas, ja.

00:31:20.240 --> 00:31:22.040
Also wenn ich das aus meiner Seite, das muss halt eigentlich

00:31:22.040 --> 00:31:23.640
auf deren Seite dann getestet sein. Das heißt, ich

00:31:23.640 --> 00:31:25.700
gebe quasi die ganze Verantwortung

00:31:25.700 --> 00:31:27.940
auch weg. Ja, du hast natürlich

00:31:27.940 --> 00:31:30.140
sehr viel, du hast wahrscheinlich wesentlich mehr Integration-Tests

00:31:30.140 --> 00:31:32.180
erst mal, als du in einem Monolithen hättest.

00:31:32.460 --> 00:31:51.420
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.

00:31:51.420 --> 00:32:09.180
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.

00:32:11.940 --> 00:32:24.820
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.

00:32:24.820 --> 00:32:27.020
Du musst überhaupt mit sowas erstmal anfangen und wir haben das

00:32:27.020 --> 00:32:28.660
möglicherweise eben noch nicht. Das ist auch

00:32:28.660 --> 00:32:31.360
das erste Projekt, was er vorschlägt,

00:32:31.400 --> 00:32:33.100
wenn man sich dann tatsächlich doch mal dazu durchgeguckt hat,

00:32:33.140 --> 00:32:33.740
das dann zu machen.

00:32:34.480 --> 00:32:37.120
Ein gutes Startprojekt ist halt zu sagen, okay, da machen

00:32:37.120 --> 00:32:38.000
wir doch mal irgendwie

00:32:38.000 --> 00:32:41.020
als ersten Microservice irgendwie

00:32:41.020 --> 00:32:42.160
zentrales

00:32:42.160 --> 00:32:45.120
Logmanagement.

00:32:47.800 --> 00:32:49.160
Weil das ist halt relativ

00:32:49.160 --> 00:32:51.080
einfach. Das ist eigentlich nicht so schwierig.

00:32:51.560 --> 00:32:52.660
Aber man muss halt trotzdem

00:32:52.660 --> 00:32:54.740
irgendwie Sachen

00:32:54.740 --> 00:32:56.700
irgendwo hindeployen können und man hat unterschiedliche

00:32:56.700 --> 00:32:58.720
Sprachen, man muss es irgendwie

00:32:58.720 --> 00:33:00.540
konfigurieren und diese ganzen

00:33:00.540 --> 00:33:03.080
unterschiedlichen Aspekte

00:33:03.080 --> 00:33:04.680
irgendwie müssen alle zusammen funktionieren,

00:33:04.780 --> 00:33:06.520
sonst geht es halt nicht und wenn man da schon feststellt, okay,

00:33:06.620 --> 00:33:08.540
das ist mit der Organisation, weil das

00:33:08.540 --> 00:33:10.120
oft hat man ja so Organisationsproblem,

00:33:10.680 --> 00:33:12.720
schwierig zu machen, dann weiß man halt, okay,

00:33:12.720 --> 00:33:14.640
alles andere, danach wird noch viel schwieriger, daher sollte

00:33:14.640 --> 00:33:16.160
man vielleicht nochmal überlegen, wie man das

00:33:16.160 --> 00:33:17.560
organisatorisch löst.

00:33:18.660 --> 00:33:20.700
Aber ja, genau, genau,

00:33:20.800 --> 00:33:22.620
das ist eigentlich, du brauchst dann halt irgendwas, wo

00:33:22.620 --> 00:33:24.660
du dann halt zentral deinen Log-File sehen kannst

00:33:24.660 --> 00:33:26.560
und gucken kannst, was passiert ist, über

00:33:26.560 --> 00:33:28.300
deine unterschiedlichen Services hinweg.

00:33:28.540 --> 00:33:29.940
Und das musstest du vorher vielleicht nicht.

00:33:30.660 --> 00:33:32.460
Also das meinte ich mit dem Hut auf Farben,

00:33:32.520 --> 00:33:34.360
ich musste halt immer irgendwie so ein Admin haben oder so.

00:33:34.760 --> 00:33:36.500
Naja, also ich meine, du hast dann

00:33:36.500 --> 00:33:38.440
ein Ding für Log-Geschichten, du hast aber

00:33:38.440 --> 00:33:40.260
vielleicht auch ein anderes Ding für Monitoring, du hast

00:33:40.260 --> 00:33:41.820
wieder ein anderes Ding für, weiß ich nicht,

00:33:42.680 --> 00:33:44.680
dein Live-Dashboard

00:33:44.680 --> 00:33:46.480
oder so, das müsste ja jetzt nicht alles das

00:33:46.480 --> 00:33:46.940
gleiche sein.

00:33:48.340 --> 00:33:50.420
Aber das Problem, was ich jetzt habe, ist dann

00:33:50.420 --> 00:33:52.420
wahrscheinlich niemand den Hut über alle diese Dinge auf hat.

00:33:52.620 --> 00:33:54.080
Und es dann schwerfällt, die halt

00:33:54.080 --> 00:33:55.760
in der Bar getragen werden.

00:33:57.140 --> 00:33:58.460
Ich meine, am Ende,

00:33:58.460 --> 00:34:00.260
ich meine, das, worauf der Jochen

00:34:00.260 --> 00:34:02.160
hingewiesen hat, wir haben ja unsere Tools.

00:34:02.380 --> 00:34:04.100
Also der Elk-Stack für Logging, meinetwegen

00:34:04.100 --> 00:34:06.340
Sentry für Fehlermeldungen, dann hast du vielleicht

00:34:06.340 --> 00:34:08.600
noch Grafana, Prometheus für Metric-Monitoring.

00:34:09.080 --> 00:34:10.620
Das sind ja alles standardisierte

00:34:10.620 --> 00:34:12.300
Ansätze, die du relativ einfach in deiner

00:34:12.300 --> 00:34:14.380
Services einbauen kannst. Also File-Bit-Logging

00:34:14.380 --> 00:34:16.340
geht zum Elk-Stack. Und das ist halt

00:34:16.340 --> 00:34:18.100
etwas, wo man sich auch in einem Monolithen durchaus

00:34:18.100 --> 00:34:20.420
Gedanken drüber machen muss, um da einen einfachen Zugang zu seinen

00:34:20.420 --> 00:34:21.680
Logs zu kriegen zum Beispiel.

00:34:22.180 --> 00:34:24.000
Gerade dann, wenn du in einem Team bist,

00:34:24.160 --> 00:34:26.120
dann finde ich schon, dass man sich relativ früh

00:34:26.120 --> 00:34:28.300
die Gedanken über genau diese Fragestellungen

00:34:28.300 --> 00:34:30.120
machen sollte, damit einfach jedes Teammitglied

00:34:30.120 --> 00:34:31.760
ohne Serverzugriff oder irgendwas

00:34:31.760 --> 00:34:34.000
anderes komisches eben an seine Logs

00:34:34.000 --> 00:34:35.880
kommt und diese möglichst schön filtern kann.

00:34:36.980 --> 00:34:38.220
Elk-Stack ist auch wunderbar.

00:34:38.400 --> 00:34:40.160
Das heißt, diesen Stack, den hast du

00:34:40.160 --> 00:34:41.900
unter Umständen auch in einer guten monolithischen

00:34:41.900 --> 00:34:43.900
Struktur schon. Vielleicht könnt ihr ja mal noch kurz den Elk-Stack

00:34:43.900 --> 00:34:45.520
beschreiben, weil den hatten wir, glaube ich, noch nicht.

00:34:46.780 --> 00:34:48.080
Das ist einfach nur, ich weiß

00:34:48.080 --> 00:34:50.000
jetzt gar nicht, ob ich das richtig, ich habe mit dem

00:34:50.000 --> 00:34:51.820
gar nicht so viel, das ist irgendwie Elasticsearch

00:34:51.820 --> 00:34:53.640
halt, um die Logfiles durchs Ufer zu machen.

00:34:54.160 --> 00:34:55.400
Das ist halt Kibana

00:34:55.400 --> 00:34:58.120
Dashboard.

00:34:58.120 --> 00:34:58.960
Genau, und

00:34:58.960 --> 00:35:00.780
was gehört da noch dazu?

00:35:01.720 --> 00:35:02.120
Logstash.

00:35:03.580 --> 00:35:05.900
Vielleicht auch, um das zu beschreiben,

00:35:06.280 --> 00:35:07.840
du kannst in Python zum Beispiel, schreibst du

00:35:07.840 --> 00:35:10.000
deine Logfiles in Files und dann kannst du dir die mit

00:35:10.000 --> 00:35:12.560
Filebeat Richtung Logstash

00:35:12.560 --> 00:35:14.060
schicken. Das ist einfach nur ein weiterer Service.

00:35:15.340 --> 00:35:16.220
Der sorgt dann letztlich

00:35:16.220 --> 00:35:18.060
einfach nur dafür, dass die Logs, die du

00:35:18.060 --> 00:35:19.920
schreibst, Richtung Elasticsearch gehen.

00:35:20.300 --> 00:35:22.140
und entweder du hast da noch ein Logs-Dash vor oder nicht,

00:35:22.220 --> 00:35:24.060
dann kannst du die vielleicht noch ein bisschen schöner formatieren,

00:35:24.660 --> 00:35:26.880
um sie ein bisschen schöner JSON-tauglicher zu machen

00:35:26.880 --> 00:35:29.520
und durchsuchbarer zu machen, einzelne Felder zu indizieren.

00:35:30.240 --> 00:35:32.700
Und dann wird das eben auf Elasticsearch gespeichert

00:35:32.700 --> 00:35:34.160
und mit Kibana durchsuchst du es einfach.

00:35:34.320 --> 00:35:35.260
Dann kriegst du so ein Dashboard,

00:35:35.780 --> 00:35:37.760
dann kannst du relativ nutzerfreundlich

00:35:37.760 --> 00:35:41.440
mit schön viel Clicky-Bunty deine Logs durchsuchen

00:35:41.440 --> 00:35:43.700
und dann hast du deine Graphen, kannst dir auch Dashboards bauen.

00:35:44.340 --> 00:35:45.460
Ja, Kibana ist super.

00:35:45.700 --> 00:35:47.480
Freitext-Suche, das ist sehr schön.

00:35:48.280 --> 00:35:48.440
Ja.

00:35:48.660 --> 00:35:49.120
Macht Spaß.

00:35:50.300 --> 00:36:19.880
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,

00:36:19.880 --> 00:36:22.280
die Problemdomäne irgendwie vertikal aufzutrennen

00:36:22.280 --> 00:36:24.300
und was man klassischerweise

00:36:24.300 --> 00:36:26.160
vielleicht eher macht, sind Sachen horizontal

00:36:26.160 --> 00:36:27.940
aufzuteilen. Das heißt, du teilst

00:36:27.940 --> 00:36:29.940
normalerweise, sag ich mal, eben dann vielleicht

00:36:29.940 --> 00:36:31.680
eher auf in Frontend

00:36:31.680 --> 00:36:33.740
irgendwie so Service Layer und Backend

00:36:33.740 --> 00:36:34.700
und Datenhaltung

00:36:34.700 --> 00:36:37.840
und sozusagen bei Microservices

00:36:37.840 --> 00:36:39.940
halt eher vertikal, das heißt pro Projekt irgendwie

00:36:39.940 --> 00:36:40.780
oder pro

00:36:40.780 --> 00:36:43.220
eine Organisationsstruktur halt.

00:36:44.000 --> 00:36:46.220
Und das Problem bei dem horizontalen

00:36:46.220 --> 00:36:48.160
Ding, weshalb man da vielleicht weg möchte

00:36:48.160 --> 00:36:49.920
von, ist halt, dass

00:36:49.920 --> 00:36:52.040
du halt, wenn du jetzt

00:36:52.040 --> 00:36:53.500
viele Leute hast, die daran arbeiten,

00:36:53.680 --> 00:36:56.040
an deinem Produkt, dann, genau, dann stehen

00:36:56.040 --> 00:36:57.740
sie halt gegenseitig auf den Füßen unter Umständen.

00:36:58.280 --> 00:36:59.780
Also du hast dann vielleicht halt eben schon

00:36:59.780 --> 00:37:01.960
ein

00:37:01.960 --> 00:37:04.180
Datenbank-Team

00:37:04.180 --> 00:37:06.100
oder so, wo sich die Leute sehr, sehr gut

00:37:06.100 --> 00:37:07.600
mit Datenbanken auskennen, aber

00:37:07.600 --> 00:37:09.920
und du brauchst sie halt auch,

00:37:10.000 --> 00:37:12.400
deswegen, weil du halt eventuell fiese Datenbankprobleme

00:37:12.400 --> 00:37:14.200
hast, wo Leute irgendwie Queries optimieren

00:37:14.200 --> 00:37:16.160
müssen oder sich überlegen müssen, wie sie da

00:37:16.160 --> 00:37:17.780
halt irgendwie möglichst schnell neue

00:37:17.780 --> 00:37:19.840
irgendwie Replikas

00:37:19.840 --> 00:37:21.760
von irgendwelchen Datenmarken hochziehen können und die Daten

00:37:21.760 --> 00:37:22.800
da und so weiter.

00:37:24.540 --> 00:37:25.760
Dieses ganze Zeugs, was man

00:37:25.760 --> 00:37:26.400
halt so machen muss.

00:37:28.200 --> 00:37:29.760
Und das sind dann halt so die

00:37:29.760 --> 00:37:31.680
Sachen, für die du tatsächlich Spezialisten brauchst, aber

00:37:31.680 --> 00:37:33.800
du hast halt oft auch das Problem, du willst

00:37:33.800 --> 00:37:35.820
jetzt, hast jetzt irgendwie ein Projekt und da muss halt

00:37:35.820 --> 00:37:37.840
irgendwie jetzt eine Spalte zusätzlich irgendwo

00:37:37.840 --> 00:37:39.840
in der Tabelle. Und da ist jetzt eigentlich

00:37:39.840 --> 00:37:41.820
nichts, was so sonderlich schwierig ist. Vielleicht

00:37:41.820 --> 00:37:43.760
sollte man sich überlegen, ob man das dann machen will oder nicht oder keine Ahnung,

00:37:43.840 --> 00:37:45.940
aber letztlich das zu tun ist gar nicht so schwer

00:37:45.940 --> 00:37:48.280
und dein Datenbank-Team ist

00:37:48.280 --> 00:37:50.480
jetzt zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt

00:37:50.480 --> 00:37:52.360
oder so. Und dann kommst du nicht weiter

00:37:52.360 --> 00:37:54.340
mit deinem eigentlich Projekt,

00:37:54.400 --> 00:37:56.380
das nur da eine blöde Spalte zusätzlich haben

00:37:56.380 --> 00:37:58.240
muss. Es gibt halt eine Menge Anforderungen, die sehr

00:37:58.240 --> 00:38:00.200
einfach sind. Also entweder du

00:38:00.200 --> 00:38:02.180
beschäftigst dann halt deine teuren Spezialexperten

00:38:02.180 --> 00:38:04.020
irgendwie mit sehr simplen Geschichten

00:38:04.020 --> 00:38:05.300
oder

00:38:05.300 --> 00:38:08.180
du kannst die nicht auslasten,

00:38:08.980 --> 00:38:09.480
weil

00:38:09.480 --> 00:38:12.060
die halt

00:38:12.060 --> 00:38:13.820
oder du kannst halt

00:38:13.820 --> 00:38:15.720
mit deinen Projekten nicht weiter, weil die halt mit

00:38:15.720 --> 00:38:16.920
irgendwelchen anderen Kram ausgelastet sind.

00:38:17.880 --> 00:38:19.920
Und das blockiert sich halt gegenseitig.

00:38:20.000 --> 00:38:22.140
Du hast halt sehr viel Handoffs, zwischendurch viel Kommunikation,

00:38:22.680 --> 00:38:23.740
weil viele Leute miteinander

00:38:23.740 --> 00:38:25.780
reden müssen, damit irgendwas am Schluss

00:38:25.780 --> 00:38:27.780
deployed werden kann. Und wenn du es jetzt anders

00:38:27.780 --> 00:38:29.640
machst und machst es halt vertikal und sagst, ein Team ist

00:38:29.640 --> 00:38:31.820
im Grunde dafür zuständig, das komplett zu deployen

00:38:31.820 --> 00:38:33.820
in ein Produkt, Projekt,

00:38:34.140 --> 00:38:34.520
Microservice,

00:38:35.320 --> 00:38:38.020
dann, und die anderen sind halt bloß,

00:38:38.500 --> 00:38:39.780
die beraten dich

00:38:39.780 --> 00:38:41.560
dann halt, wenn es irgendwie

00:38:41.560 --> 00:38:43.100
kompliziert wird oder so und

00:38:43.100 --> 00:38:45.060
enablen, dich halt irgendwie da

00:38:45.060 --> 00:38:47.500
eine Lösung zu finden, dann kannst du halt sehr viel

00:38:47.500 --> 00:38:49.640
schneller halt Sachen tatsächlich

00:38:49.640 --> 00:38:50.920
raus aus der Tür kriegen

00:38:50.920 --> 00:38:53.120
und du machst

00:38:53.120 --> 00:38:55.680
bestimmte Teile deiner Organisation halt auch

00:38:55.680 --> 00:38:57.500
handlungsfähig,

00:38:57.500 --> 00:38:59.480
ohne dass sie halt sich mit allen anderen abstimmen müssen.

00:39:00.300 --> 00:39:01.640
Und dann, also das sind vor allen Dingen

00:39:01.640 --> 00:39:03.460
zwei Teile, die da halt ein Problem

00:39:03.460 --> 00:39:05.300
sind, das ist halt einmal die Infrastruktur ganz unten,

00:39:05.480 --> 00:39:06.980
das sind halt Datenbank und so und

00:39:06.980 --> 00:39:09.400
IT-Geschichten und dann oben halt aber UI

00:39:09.400 --> 00:39:11.460
und UX ist auch immer problematisch, deswegen

00:39:11.460 --> 00:39:13.240
eben gerade schon mit dem Mikrofon jetzt so ein bisschen,

00:39:13.820 --> 00:39:15.720
weil das Problem ist, wie stellst du Konsistenz

00:39:15.720 --> 00:39:17.640
gegen, quasi

00:39:17.640 --> 00:39:19.500
sicher, wenn halt du nicht mehr ein

00:39:19.500 --> 00:39:21.480
UI-Team hast, das halt alles

00:39:21.480 --> 00:39:23.520
auf allem irgendwie zu einem Ja sagen

00:39:23.520 --> 00:39:25.520
muss, dass das jetzt so funktioniert. Die könnten dann sagen,

00:39:25.600 --> 00:39:27.300
ja, nee, das muss konsistent sein, das können wir so nicht machen.

00:39:27.880 --> 00:39:29.460
Aber wenn jetzt die Teams das einzeln machen sollen,

00:39:29.520 --> 00:39:31.340
dann kann es natürlich inkonsistent werden. Ja, dann müssen ja

00:39:31.340 --> 00:39:32.880
irgendwie komische Style-Guides folgen oder so.

00:39:33.100 --> 00:39:35.220
Ja, aber ob sie das dann tun oder nicht, weil das Team

00:39:35.220 --> 00:39:37.320
muss dann ja verantwortlich sein. Die müssen ja sagen können,

00:39:37.400 --> 00:39:39.240
nee, wir releasen, das ist uns wichtiger und dann,

00:39:39.400 --> 00:39:41.260
oder wir deployen jetzt und dann machen sie das halt einfach.

00:39:41.380 --> 00:39:42.220
Das wäre Kraut und Rüben.

00:39:43.240 --> 00:39:44.580
Ja, aber du bist halt unter Umständen schneller.

00:39:45.200 --> 00:39:47.620
Und ich finde, in einer Firma

00:39:47.620 --> 00:39:48.480
gibt es das auch sehr schön,

00:39:49.120 --> 00:39:51.240
sowohl was das an Vorteilen bringen kann,

00:39:51.360 --> 00:39:53.320
sieht man da, und auch was an Nachteilen, nämlich bei Amazon.

00:39:53.820 --> 00:39:55.200
Die haben ja eigentlich früher schon angefangen mit

00:39:55.200 --> 00:39:57.340
Service-Oriented Architecture, was vielleicht

00:39:57.340 --> 00:39:59.140
auch so ein bisschen Vorläufer ist von Microservices.

00:39:59.840 --> 00:40:01.660
Und auf der Amazon-Shopping-Seite,

00:40:01.780 --> 00:40:03.080
da funktioniert das, finde ich, ganz gut.

00:40:03.220 --> 00:40:05.460
Also ich meine, die sieht auch immer so ein bisschen inkonsistent aus und komisch

00:40:05.460 --> 00:40:06.280
und altbacken und so.

00:40:07.560 --> 00:40:09.420
Aber das geht irgendwie. Also man kann

00:40:09.420 --> 00:40:11.340
einkaufen und meistens funktioniert es sogar besser als

00:40:11.340 --> 00:40:13.180
anderswo vom Prozess her.

00:40:14.080 --> 00:40:15.480
Aber, also das geht.

00:40:15.560 --> 00:40:17.180
Das ist zwar nicht so komplett konsistent, aber das

00:40:17.180 --> 00:40:19.240
funktioniert insgesamt. Und wo ich

00:40:19.240 --> 00:40:21.100
finde, wo es eine ziemliche Katastrophe ist, ist halt

00:40:21.100 --> 00:40:23.180
sowas wie AWS oder so. Wo man auch sieht, dass

00:40:23.180 --> 00:40:25.240
jedes einzelne Team, also einmal es gibt hunderte

00:40:25.240 --> 00:40:27.360
und dann jedes Team macht das halt

00:40:27.360 --> 00:40:28.640
irgendwie anders, so wie sie es halt denken.

00:40:29.140 --> 00:40:31.380
Und das macht es für mich als Benutzer halt total schwierig

00:40:31.380 --> 00:40:33.420
irgendwie das zu

00:40:33.420 --> 00:40:35.300
bedienen, weil ich nie Sachen

00:40:35.300 --> 00:40:36.220
finde und immer

00:40:36.220 --> 00:40:38.840
suchen muss nach Sachen und so.

00:40:39.080 --> 00:40:41.380
Naja, also auch die Konfiguration, wenn man das irgendwie automatisiert,

00:40:41.440 --> 00:40:43.300
ist ja jedes Mal total anders und das ist ein bisschen

00:40:43.300 --> 00:40:45.320
nervig auch. Ja, also ich meine, es geht schon, aber es ist halt

00:40:45.320 --> 00:40:47.080
schon, das macht es echt, da an der Stelle

00:40:47.080 --> 00:40:49.200
macht die fehlende Konsistenz einem das Leben halt echt schwer.

00:40:49.620 --> 00:40:50.980
Und ja, aber

00:40:50.980 --> 00:40:53.280
ich glaube, das sind halt so Trade-offs, da muss man

00:40:53.280 --> 00:40:55.500
sich entscheiden, ist einem die Konsistenz wichtiger oder die Geschwindigkeit?

00:40:56.160 --> 00:40:56.300
Ja.

00:40:58.400 --> 00:40:58.680
Ja.

00:41:02.380 --> 00:41:03.020
Naja, naja.

00:41:04.060 --> 00:41:05.540
Wenig Begeisterung für Microservices

00:41:05.540 --> 00:41:07.220
habe ich das Gefühl. Ja, ich weiß nicht, also

00:41:07.220 --> 00:41:09.120
Ich habe noch nicht so rausgefunden, wofür ich

00:41:09.120 --> 00:41:11.280
dann jetzt ein Microsoft gut

00:41:11.280 --> 00:41:13.100
einsetzen könnte. Also wenn ich mir jetzt vorstelle, ich möchte

00:41:13.100 --> 00:41:14.420
jetzt irgendwie so ein Projekt implementieren,

00:41:15.040 --> 00:41:16.860
irgendwie so eine gewisse Größe und dann

00:41:16.860 --> 00:41:19.340
muss ich

00:41:19.340 --> 00:41:21.220
ja, wie du, Jörg, so schön

00:41:21.220 --> 00:41:23.160
sagst, enablen die Leute, dass

00:41:23.160 --> 00:41:25.280
sie selber klarkommen mit den ganzen

00:41:25.280 --> 00:41:27.260
Regeln, die ich irgendwie haben

00:41:27.260 --> 00:41:29.180
will. Ich glaube, das ist noch viel zu

00:41:29.180 --> 00:41:31.060
kompliziert. Ich glaube, erst mal

00:41:31.060 --> 00:41:33.040
muss man überlegen, brauche ich das überhaupt? Also macht das

00:41:33.040 --> 00:41:35.000
für mich überhaupt Sinn? Habe ich die Größe? Wie viele

00:41:35.000 --> 00:41:37.060
Mitarbeiter habe ich? Bin ich jetzt zu fünf, dann mache ich kein

00:41:37.060 --> 00:41:39.120
Microservices auf. Aber habe ich meinetwegen

00:41:39.120 --> 00:41:40.680
20, 30, 40 Mitarbeiter,

00:41:41.300 --> 00:41:43.380
das macht schon super viel Sinn, da über Microservices

00:41:43.380 --> 00:41:45.220
nachzudenken, weil ich kann jetzt

00:41:45.220 --> 00:41:46.980
eigene Teams machen, diese Teams haben

00:41:46.980 --> 00:41:49.200
verschiedene Verantwortlichkeiten und

00:41:49.200 --> 00:41:51.120
natürlich habe ich hinterher den Trade-off

00:41:51.120 --> 00:41:53.560
mit Konsistenz meinetwegen

00:41:53.560 --> 00:41:55.340
im Frontend. Frontend

00:41:55.340 --> 00:41:57.340
ist halt immer so, ich bin nicht im Frontend

00:41:57.340 --> 00:41:59.260
drin, ich persönlich. Also ich halte mich

00:41:59.260 --> 00:42:01.060
davon so weit fern wie nur möglich

00:42:01.060 --> 00:42:03.220
und so Backend-Prozesse,

00:42:03.600 --> 00:42:05.420
da sind so Guidelines total egal.

00:42:05.740 --> 00:42:23.640
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.

00:42:23.640 --> 00:42:41.780
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.

00:42:41.780 --> 00:42:54.120
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.

00:42:55.240 --> 00:43:02.020
Ja, die Frage ist dann auch immer, welche Prozesse werden durchlaufen, um etwas zu veröffentlichen, das steht halt noch drin.

00:43:02.020 --> 00:43:14.980
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.

00:43:14.980 --> 00:43:35.180
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.

00:43:35.380 --> 00:43:52.460
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.

00:43:52.920 --> 00:44:08.960
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.

00:44:08.960 --> 00:44:10.380
Was aber schon ein Riesenproblem ist,

00:44:10.720 --> 00:44:12.260
wenn du jetzt

00:44:12.260 --> 00:44:14.520
so etwas hast,

00:44:14.680 --> 00:44:15.940
ich weiß jetzt nicht, was das Beispiel war,

00:44:15.980 --> 00:44:18.340
du hast halt irgendwie

00:44:18.340 --> 00:44:20.520
einen Konzern, der hat halt hunderte

00:44:20.520 --> 00:44:22.300
Marken und jede Marke hat irgendwie

00:44:22.300 --> 00:44:24.520
eigene Dienste, die sie

00:44:24.520 --> 00:44:25.200
irgendwie anbieten

00:44:25.200 --> 00:44:28.680
und die sind alle in unterschiedlichen

00:44:28.680 --> 00:44:30.140
Teams und so und auch weltweit verteilt und so.

00:44:30.700 --> 00:44:32.420
Wie stellst du denn sicher, dass du irgendwas

00:44:32.420 --> 00:44:34.460
über einen bestimmten Kunden weißt zentral?

00:44:34.460 --> 00:44:35.800
Das kriegst du halt dann nicht mehr hin.

00:44:35.920 --> 00:44:38.160
Oder halt über die Produktion, wenn du derjenige bist,

00:44:38.220 --> 00:44:39.940
das produziert und das dann verteilt an Unternehmern.

00:44:40.220 --> 00:44:41.120
Das ist genau das, was ich meine.

00:44:41.720 --> 00:44:43.480
Ja, das ist der Nachteil, das geht halt nicht mehr.

00:44:43.840 --> 00:44:46.200
Aber das ist ja das, was

00:44:46.200 --> 00:44:47.860
ich zentral, das sind wir vielleicht wieder,

00:44:48.020 --> 00:44:49.320
was man bei Single Point of Truth irgendwie

00:44:49.320 --> 00:44:51.140
überschreiben kann. Das ist eine Herausforderung.

00:44:51.160 --> 00:44:53.760
Ich muss halt irgendwie sicherstellen, dass die Wahrheit,

00:44:53.940 --> 00:44:55.640
ich will die Wahrheit haben, damit ich das menschen kann,

00:44:55.720 --> 00:44:57.360
damit ich die Entscheidung richtig treffen kann, damit ich

00:44:57.360 --> 00:44:59.000
die Steuerung...

00:44:59.000 --> 00:45:00.980
Es ist halt die Frage, also es geht halt manchmal,

00:45:01.180 --> 00:45:03.400
ich meine, ich kenne es halt zum Beispiel

00:45:03.400 --> 00:45:05.980
als zweitgrößte E-Commerce-Konzer

00:45:05.980 --> 00:45:07.760
in der Welt. Wisst ihr, wer das ist?

00:45:08.220 --> 00:45:10.000
Hm? Nach Amazon?

00:45:12.160 --> 00:45:12.560
Otto?

00:45:13.200 --> 00:45:14.200
Ja, das ist Otto.

00:45:14.320 --> 00:45:16.000
Aber tatsächlich, ich weiß nicht mehr, ob das

00:45:16.000 --> 00:45:17.560
noch stimmt. Es kann sein, dass

00:45:17.560 --> 00:45:20.160
AliExpress oder so

00:45:20.160 --> 00:45:21.160
größer ist.

00:45:21.880 --> 00:45:22.940
Oder Alibaba.

00:45:24.180 --> 00:45:26.140
Aber Otto auf jeden Fall sehr, sehr

00:45:26.140 --> 00:45:27.700
groß. Und damals,

00:45:27.960 --> 00:45:29.280
das ist jetzt aber auch schon wieder lange her,

00:45:29.760 --> 00:45:32.100
hatten sie sich das auf die Fahnen

00:45:32.100 --> 00:45:34.100
auch geschrieben, irgendwie der Zeitgröße nach Amazon zu sein.

00:45:34.900 --> 00:45:36.140
Und die haben halt zum Beispiel genau

00:45:36.140 --> 00:45:37.940
dieses Problem, weil es gibt ja nicht

00:45:37.940 --> 00:45:39.860
die eine Seite, auf der dann alle irgendwie

00:45:39.860 --> 00:45:41.540
Zeugs einkaufen, sondern die haben halt hunderte

00:45:41.540 --> 00:45:44.080
Shops. Also jeder dritte

00:45:44.080 --> 00:45:45.840
Shop, auf dem du irgendwie landest, ist halt letztlich

00:45:45.840 --> 00:45:47.980
gehört zum Autokonzern. Du weißt es aber gar nicht, weil

00:45:47.980 --> 00:45:49.020
das steht da ja auch nicht dran.

00:45:49.960 --> 00:45:51.120
Die haben jetzt genau dieses Problem.

00:45:52.060 --> 00:45:53.940
Jeder einzelne Shop hält

00:45:53.940 --> 00:45:55.260
halt User-Daten und

00:45:55.260 --> 00:45:58.060
genau, wie machst du das denn jetzt

00:45:58.060 --> 00:45:59.900
eigentlich, wenn du quasi irgendwie

00:45:59.900 --> 00:46:01.180
Dinge wissen willst über deine User?

00:46:01.620 --> 00:46:04.120
Also wie kriegen die ganzen Microservices wieder alle zusammen?

00:46:04.440 --> 00:46:06.000
Ja, und die Antwort ist eigentlich

00:46:06.000 --> 00:46:06.460
gar nicht.

00:46:07.060 --> 00:46:08.680
Ich glaube, da kommen so Leute auf die Idee wie

00:46:08.680 --> 00:46:11.060
Data Lake wird dann eher Data Swamp oder so.

00:46:11.620 --> 00:46:12.200
Irgendwas zu sichern.

00:46:12.320 --> 00:46:15.060
Das schlimmste Problem

00:46:15.060 --> 00:46:17.120
ist gar nicht unbedingt die technische Lösung,

00:46:17.320 --> 00:46:19.040
sondern das schlimmste Problem sind halt die

00:46:19.040 --> 00:46:21.420
politischen Geschichten, die du halt auch kriegst automatisch.

00:46:21.900 --> 00:46:23.060
Dass halt Leute sagen so,

00:46:24.020 --> 00:46:25.240
wir haben hier gerade

00:46:25.240 --> 00:46:27.060
einen Vorteil, die sind ja untereinander im Wettbewerb,

00:46:27.240 --> 00:46:29.060
wir haben hier gerade einen Vorteil, weil

00:46:29.060 --> 00:46:31.140
wir irgendwas wissen, was die anderen

00:46:31.140 --> 00:46:32.640
nicht wissen und jetzt sollen wir die Daten,

00:46:32.640 --> 00:46:34.800
das, was uns dazu verhilft,

00:46:34.840 --> 00:46:36.200
dass wir irgendwie besser sein können, als

00:46:36.200 --> 00:46:38.280
wie unsere interne Konkurrenz, da sollen wir

00:46:38.280 --> 00:46:39.820
den jetzt irgendwie freiwillig zur Verfügung stellen?

00:46:40.440 --> 00:46:42.140
Dann haben wir halt irgendwie einen leichten

00:46:42.140 --> 00:46:44.260
kaputten Export, wo die Daten so ein bisschen...

00:46:44.260 --> 00:46:46.060
Ja, aber mit der Konzernbrille, die du dann aufhast,

00:46:46.140 --> 00:46:48.180
dann musst du da hingehen, musst den gordischen Knoten dann kaputt hauen.

00:46:48.260 --> 00:46:49.780
Dann musst du sagen, gib uns die Daten, wir sind der Chef.

00:46:50.680 --> 00:46:52.160
Ja, schwierig. Sehr schwierig.

00:46:52.500 --> 00:46:53.780
Also, ja.

00:46:54.300 --> 00:46:56.020
Aber auch da, ich meine,

00:46:56.060 --> 00:46:58.020
das ist jetzt ein sehr, sehr schönes Beispiel, aber als

00:46:58.020 --> 00:47:00.040
Konzern muss man sich natürlich die Frage stellen, was will ich

00:47:00.040 --> 00:47:02.040
eigentlich? Will ich jetzt ein möglichst großes Franchise

00:47:02.040 --> 00:47:03.940
so schnell wie möglich aufbauen? Habe ich die

00:47:03.940 --> 00:47:05.280
Kapazität, um das aus

00:47:05.280 --> 00:47:07.660
innerer Kraft herauszuschaffen oder

00:47:07.660 --> 00:47:09.500
muss ich dafür sorgen, dass die Leute

00:47:09.500 --> 00:47:11.760
in weiß nicht wo das alles selbst entwickeln

00:47:11.760 --> 00:47:13.520
können, dann machen sie halt ihren eigenen Service und dann

00:47:13.520 --> 00:47:15.580
habe ich das Problem mit den Daten, dass ich nicht unbedingt alle

00:47:15.580 --> 00:47:17.660
Nutzer auf einmal kenne, aber das

00:47:17.660 --> 00:47:19.640
ist dann eine Sache, die man

00:47:19.640 --> 00:47:21.640
lösen muss im Nachhinein. Und was hilft mir jetzt

00:47:21.640 --> 00:47:23.800
mehr? Hilft es mir mehr, da einen Shop hochzuziehen

00:47:23.800 --> 00:47:24.460
und irgendwie

00:47:24.460 --> 00:47:27.520
mein Geld über das Franchise reinzuziehen

00:47:27.520 --> 00:47:29.520
oder wie auch immer? Oder will ich jetzt

00:47:29.520 --> 00:47:31.480
einfach alles wissen und will ich die totale Kontrolle

00:47:31.480 --> 00:47:33.560
haben? Ja, das ist halt genau das klassische Problem

00:47:33.560 --> 00:47:35.580
eigentlich. Machst du halt irgendwie Diversifizierung

00:47:35.580 --> 00:47:37.380
oder machst du Fusionierung

00:47:37.380 --> 00:47:38.880
irgendwie. Das ist

00:47:38.880 --> 00:47:41.140
in der Software-Seite und die Frage,

00:47:41.400 --> 00:47:43.480
die irgendwie die Consultants immer geben, ist immer genau das Gegenteil

00:47:43.480 --> 00:47:44.460
von dem, was gerade da ist.

00:47:45.420 --> 00:47:47.660
Dann kannst du halt so ein Projekt consulten, kannst damit Geld verdienen

00:47:47.660 --> 00:47:49.400
und dann geht es halt immer aus und zusammen.

00:47:49.640 --> 00:47:51.380
Ich meine, das macht natürlich auch Sinn. Also wenn du irgendwas

00:47:51.380 --> 00:47:53.280
hast, was total verfilzt ist, dann musst du das

00:47:53.280 --> 00:47:55.360
erstmal auseinanderspalten, dann hast du kleine

00:47:55.360 --> 00:47:57.420
einzelne Services, die untereinander

00:47:57.420 --> 00:47:58.940
so ein bisschen Wettbewerb haben. Die guten Sachen

00:47:58.940 --> 00:48:01.500
musst du dann irgendwie wieder konsolidieren und zentralisieren,

00:48:01.600 --> 00:48:03.280
um dann wieder den guten Benefit rauszubekommen.

00:48:03.560 --> 00:48:05.600
bis du dann wieder merkst, das ist wieder doof, dann fängst du wieder an, das auseinander

00:48:05.600 --> 00:48:07.600
zu dröseln. Das ist ja genau wie bei den Ländern.

00:48:07.780 --> 00:48:09.520
Mal sind Länder werden zusammengefasst, dann werden die

00:48:09.520 --> 00:48:11.660
auseinander. Ja, aber das ist ja

00:48:11.660 --> 00:48:13.800
vielleicht auch dieser natürliche

00:48:13.800 --> 00:48:15.420
Zyklus, Lebenszyklus von so

00:48:15.420 --> 00:48:17.100
einem Ding.

00:48:17.800 --> 00:48:19.620
Und ja, also wenn

00:48:19.620 --> 00:48:21.460
ich jetzt zum Beispiel hingehe, dieses Otto-Beispiel

00:48:21.460 --> 00:48:23.420
nehme und ich möchte diese User-Daten haben.

00:48:23.500 --> 00:48:25.500
Ich würde jetzt als Otto hingehen und sagen, ich will wissen, wer sind

00:48:25.500 --> 00:48:26.900
meine Kunden, wie viele Kunden sind das überhaupt irgendwo.

00:48:27.180 --> 00:48:29.040
Dann muss ich hingehen und sagen, gebt mir alle eure Daten.

00:48:29.400 --> 00:48:31.440
Dann baue ich einen zentralen Service dann zusätzlich,

00:48:31.600 --> 00:48:33.360
der halt von allen die Daten abholt. Dann kann es sein,

00:48:33.400 --> 00:48:35.140
dass ich jeden einzelnen dieser Shops einzeln integrieren muss,

00:48:35.200 --> 00:48:37.220
kann irgendwie sein, dass das relativ viel Aufwand macht,

00:48:37.300 --> 00:48:39.340
aber dann hole ich mir die alle irgendwann ab

00:48:39.340 --> 00:48:41.240
und dann weiß ich, okay, zumindest

00:48:41.240 --> 00:48:43.220
in der Historie gesehen ist das vielleicht ein Tag alt

00:48:43.220 --> 00:48:45.240
oder so oder eine Woche, ist ja egal, aber da sind

00:48:45.240 --> 00:48:47.300
die Daten sind einigermaßen echt und da habe ich

00:48:47.300 --> 00:48:49.300
einen Vollüberblick über, was da meine Leute sind

00:48:49.300 --> 00:48:51.220
und da kann ich dann bestimmte Analysen

00:48:51.220 --> 00:48:52.540
fahren, die ich vielleicht fahren möchte.

00:48:53.580 --> 00:48:55.160
Aber das ist ja das, was man vielleicht dann braucht

00:48:55.160 --> 00:48:57.160
und dann kann man damit vielleicht dann wieder sagen, ah, aber

00:48:57.160 --> 00:48:59.140
dafür machen wir jetzt wieder so kleine Services, weil dann

00:48:59.140 --> 00:49:00.980
vielleicht, oder du kannst auch überlegen,

00:49:01.480 --> 00:49:02.980
ob du nicht schon im Vorfeld einen

00:49:02.980 --> 00:49:04.900
einen gewissen Standard etablierst, wo du sagst,

00:49:05.480 --> 00:49:06.820
da sind wir wieder beim Standard natürlich.

00:49:07.060 --> 00:49:07.620
Und bei den Gateways.

00:49:09.260 --> 00:49:10.960
Nicht nur bei den Gateways. Ich bin

00:49:10.960 --> 00:49:12.860
im Backend. Ich interessiere mich nicht so für die...

00:49:12.860 --> 00:49:14.820
Ja, doch, auch. Ja, mein Problem ist da bei der

00:49:14.820 --> 00:49:16.680
Gatekeeper. Ich musste gerade, weil du gesagt hast Standards,

00:49:16.780 --> 00:49:18.480
musste ich an Infrastrukturstandards denken.

00:49:19.040 --> 00:49:20.700
Und auch daran, das ist ja unheimlich

00:49:20.700 --> 00:49:22.780
schwierig, wenn du die gleichen

00:49:22.780 --> 00:49:24.820
Standards einführst für Teams, die

00:49:24.820 --> 00:49:26.800
auf der Welt irgendwo sitzen. Ja, damit verlierst

00:49:26.800 --> 00:49:28.660
du die Vorteile von Microsoft. Ja. Eigentlich sofort.

00:49:28.900 --> 00:49:30.580
Genau. Die Frage ist halt, was

00:49:30.580 --> 00:49:32.880
der Standard ist. Möchte ich jetzt einfach so ein Plugin

00:49:32.880 --> 00:49:35.100
auf jedem Shop haben, welches meinetwegen

00:49:35.100 --> 00:49:36.360
in verschiedenen Programmiersprachen

00:49:36.360 --> 00:49:39.100
vorhanden ist, damit die Shops autonom

00:49:39.100 --> 00:49:41.040
sind, ist es für mich ein vertretbarer

00:49:41.040 --> 00:49:42.660
Aufwand, das zu gewährleisten, meinetwegen.

00:49:42.720 --> 00:49:44.820
Das fängt ja schon bei anderen Sachen an,

00:49:44.840 --> 00:49:46.920
wie, keine Ahnung, jeder Dev kriegt ein Windows-Laptop

00:49:46.920 --> 00:49:47.700
mit AD zugefroren.

00:49:47.700 --> 00:49:49.240
Aber das hast du ja nicht.

00:49:49.700 --> 00:49:50.820
Genau, das willst du nicht machen.

00:49:50.820 --> 00:49:53.280
Das ist nämlich der Punkt, weil wenn du Microsoft was machst, musst du erkennen,

00:49:53.420 --> 00:49:54.940
dass das unabhängig sein muss

00:49:54.940 --> 00:49:57.580
von dem Rest und du kannst das da nicht zentralisieren.

00:49:57.660 --> 00:49:59.200
Und wenn du das machst, ist es halt

00:49:59.200 --> 00:50:01.420
kontraproduktiv, weil dann hast du den Monolithen

00:50:01.420 --> 00:50:03.560
irgendwo dazwischen sitzen, der wie eine Krake

00:50:03.560 --> 00:50:05.440
versucht, seine einzelnen Sachen doch festzuhalten

00:50:05.440 --> 00:50:07.040
und dann ist das völlig absurd.

00:50:07.200 --> 00:50:09.220
Wie gesagt, also für mich muss man

00:50:09.220 --> 00:50:11.260
da so ein bisschen von loslassen,

00:50:11.460 --> 00:50:13.440
dass man die Kontrolle, die totale

00:50:13.440 --> 00:50:15.420
Kontrolle haben will. Und wenn man das

00:50:15.420 --> 00:50:16.760
kann und wenn man dann die Vorteile

00:50:16.760 --> 00:50:19.240
für die Flexibilität sieht,

00:50:19.320 --> 00:50:20.900
die man dabei gewinnt, dann

00:50:20.900 --> 00:50:23.000
sind Microservices schon sehr vorteilhaft.

00:50:23.120 --> 00:50:25.160
Ja, genau, aber das ist genau der Punkt, weil

00:50:25.160 --> 00:50:27.300
wenn ich jetzt sage, ich möchte den Hut aufhaben, wird das

00:50:27.300 --> 00:50:29.320
so nicht funktionieren. Sonst wird nur dann funktionieren,

00:50:29.320 --> 00:50:30.920
wenn ich Verantwortung abgeben kann.

00:50:31.060 --> 00:50:32.080
Ja, dann nimmst du einen Microservice.

00:50:32.640 --> 00:50:34.800
Aber da hast du ja schon eine Antwort.

00:50:35.060 --> 00:50:37.000
Also willst du den Hut aufhaben, wie du es so schön sagst,

00:50:37.720 --> 00:50:38.740
dann mach keinen Microservice.

00:50:38.940 --> 00:50:41.400
Oder überleg dir halt sehr, sehr gut, wie du das gewährleisten kannst.

00:50:41.580 --> 00:50:42.260
Wie viel willst du wachsen?

00:50:42.340 --> 00:50:44.280
Vielleicht geht das ja sogar in Microservices, wer weiß.

00:50:45.780 --> 00:50:47.300
Oder willst du die Verantwortung abgeben,

00:50:47.460 --> 00:50:49.100
dann kannst du einen Microservice nehmen.

00:50:49.160 --> 00:50:51.480
Die Frage am Ende ist, wenn du einen riesen Konzern hast,

00:50:52.040 --> 00:50:53.520
hat da überhaupt noch jemand den Hut auf?

00:50:53.600 --> 00:50:54.480
Egal, welchen Ansatz du nimmst.

00:50:54.480 --> 00:50:55.840
Die Frage im Konzern ist dann ganz einfach.

00:50:55.920 --> 00:50:57.320
Auf welcher Kostenstelle wird denn das gebucht?

00:50:57.480 --> 00:50:58.780
Und wer hält dann dann wo die Hand auf?

00:50:59.620 --> 00:51:01.020
Ja, aber ich glaube

00:51:01.020 --> 00:51:02.600
also, wenn man nochmal

00:51:02.600 --> 00:51:04.900
einen Schritt mehr Richtung

00:51:04.900 --> 00:51:06.840
Organisation oder allgemein oder abstraktes Problem geht,

00:51:07.320 --> 00:51:08.800
ich denke, also ich würde irgendwie

00:51:08.800 --> 00:51:10.840
diesen Trend zu Microservices halt so verorten

00:51:10.840 --> 00:51:11.120
in einem

00:51:11.120 --> 00:51:14.840
in einer Reihe von Trends, die halt alle

00:51:14.840 --> 00:51:16.740
in eine ähnliche Richtung laufen. Ich glaube, DevOps ist auch

00:51:16.740 --> 00:51:18.720
so ein Ding, was in eine ähnliche Richtung läuft, weil

00:51:18.720 --> 00:51:20.820
bei all diesen Dingen geht es

00:51:20.820 --> 00:51:21.600
im Grunde darum,

00:51:22.840 --> 00:51:24.780
dass man halt in

00:51:24.780 --> 00:51:26.300
so einer klassischen Organisation,

00:51:26.640 --> 00:51:28.800
dass da die Incentives irgendwie pervers

00:51:28.800 --> 00:51:29.420
sind, so ein bisschen.

00:51:30.480 --> 00:51:32.760
Und das sind alles Versuche, das zu

00:51:32.760 --> 00:51:34.660
lösen, dieses Problem, dass die Incentives

00:51:34.660 --> 00:51:36.680
eigentlich nicht korrekt sind. Also was ich

00:51:36.680 --> 00:51:38.640
damit meine, ist einfach nur, ist eigentlich ein total simples

00:51:38.640 --> 00:51:40.600
Problem. Nehmen wir an, du hast halt irgendwie

00:51:40.600 --> 00:51:41.860
früher, du hast halt

00:51:41.860 --> 00:51:43.460
Entwicklung und

00:51:43.460 --> 00:51:46.120
Betrieb oder

00:51:46.120 --> 00:51:48.480
IT und Operations oder weiß ich nicht

00:51:48.480 --> 00:51:50.280
und dann auf der anderen Seite Entwicklung. Und das ist vielleicht auf

00:51:50.280 --> 00:51:52.780
unterschiedlichen Seiten deiner Bilanz

00:51:52.780 --> 00:51:53.980
auch. Das eine sind dann halt

00:51:53.980 --> 00:51:56.680
Kosten und das andere sind halt Investitionen.

00:51:57.440 --> 00:51:58.660
Ja, so dann hast

00:51:58.660 --> 00:52:00.140
du halt irgendwie, siehst du halt

00:52:00.140 --> 00:52:03.000
wenn da Features entwickelt werden, siehst du das als Investition

00:52:03.000 --> 00:52:04.780
und denkst halt, je mehr Features

00:52:04.780 --> 00:52:06.580
entwickeln werden, voll gut, gibt mir in der Zukunft

00:52:06.580 --> 00:52:07.880
mehr Einnahmen, total super.

00:52:09.560 --> 00:52:10.400
So, das heißt

00:52:10.400 --> 00:52:12.560
irgendwie deine Entwicklung misst du daran,

00:52:12.640 --> 00:52:14.720
wie viele Features kriegen die eigentlich pro Quartal irgendwie raus

00:52:14.720 --> 00:52:15.720
oder keine Ahnung, irgendwie sowas.

00:52:16.300 --> 00:52:18.120
Dann geht das Ganze in den Betrieb.

00:52:19.660 --> 00:52:20.760
Woran misst du deinen Betrieb?

00:52:20.760 --> 00:52:22.740
Den misst du an den Kosten und daran,

00:52:22.880 --> 00:52:24.440
dass es halt funktioniert. Aber

00:52:24.440 --> 00:52:26.320
sozusagen die

00:52:26.320 --> 00:52:28.760
Leute, die da arbeiten, die haben nichts

00:52:28.760 --> 00:52:30.580
davon, dass da mehr Features

00:52:30.580 --> 00:52:32.000
rausgehen. Die werden

00:52:32.000 --> 00:52:34.600
nicht, kriegen nicht mehr Geld dafür,

00:52:34.700 --> 00:52:36.880
dass sie halt dafür

00:52:36.880 --> 00:52:38.560
sorgen, dass die Entwickler mehr Features veröffentlicht werden.

00:52:38.780 --> 00:52:39.580
Was ist deren

00:52:39.580 --> 00:52:41.280
rational

00:52:41.280 --> 00:52:43.760
beste Strategie in diesem

00:52:43.760 --> 00:52:46.260
Setting? Ist halt tatsächlich zu sagen,

00:52:47.440 --> 00:52:48.640
never change a running system.

00:52:49.100 --> 00:52:50.020
Ja, irgendwie.

00:52:50.500 --> 00:52:52.440
Ich werde nicht belohnt dafür.

00:52:52.440 --> 00:52:54.460
Ich bin ein Kostenfaktor. Ich werde nur bestraft,

00:52:54.580 --> 00:52:56.560
irgendwas nicht geht. Ja, solange das Wasser läuft

00:52:56.560 --> 00:52:57.780
und der Strom an ist, alles gut.

00:52:58.720 --> 00:53:00.080
Sobald der Strom ausfällt, kriege ich

00:53:00.080 --> 00:53:01.760
ein Problem.

00:53:02.720 --> 00:53:04.380
Das heißt, mein Ding ist

00:53:04.380 --> 00:53:06.420
also, ich meine, klar, irgendwie eine Änderung kann sein,

00:53:06.480 --> 00:53:08.580
dass sie gut ist für andere, ja, aber ich habe ja nichts davon.

00:53:08.980 --> 00:53:10.240
Oder sie ist schlecht, dann

00:53:10.240 --> 00:53:12.360
trifft mich das. Das heißt,

00:53:12.500 --> 00:53:14.580
ich versuche, möglichst Änderungen zu verhindern.

00:53:15.320 --> 00:53:16.540
Dann, das ist sozusagen für mich

00:53:16.540 --> 00:53:18.420
am besten, weil dann kann ich sicherstellen,

00:53:18.500 --> 00:53:20.300
dass möglichst wenig kaputt geht. Und

00:53:20.300 --> 00:53:22.460
na gut, für die anderen ist das halt nicht so toll, dass sie halt nicht so

00:53:22.460 --> 00:53:24.400
viele Features rauskriegen, aber ist ja ehrlich gesagt nicht mein Problem.

00:53:24.580 --> 00:53:46.080
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?

00:53:46.080 --> 00:53:47.200
Ein Server 50.000 Euro?

00:53:47.380 --> 00:53:48.000
Ja, irgendwie sowas.

00:53:48.100 --> 00:53:49.200
Und die Antwort ist einfach so,

00:53:49.540 --> 00:53:50.940
ja, das ist halt deswegen,

00:53:51.020 --> 00:53:51.860
damit du das nicht machst,

00:53:52.180 --> 00:53:52.820
damit du nichts änderst.

00:53:52.980 --> 00:53:53.760
Ja, das ist der Grund.

00:53:54.380 --> 00:53:55.640
Das ist halt der Preis für die Änderung.

00:53:55.700 --> 00:53:56.380
Dass jemand sagt so,

00:53:56.560 --> 00:53:57.780
irgendwie ich gehe ja für dich das Risiko,

00:53:57.920 --> 00:53:59.460
dass sich irgendwie das Sachen kaputt gehen.

00:53:59.880 --> 00:54:01.220
Ich will möglichst, dass du nichts änderst.

00:54:01.880 --> 00:54:03.000
Und deswegen ist das so teuer.

00:54:03.940 --> 00:54:06.160
Und ja, DevOps ist halt dann so ein,

00:54:06.380 --> 00:54:08.260
also die Lösung dafür ist halt dann sozusagen

00:54:08.260 --> 00:54:10.980
die Verantwortung für diese Dinge halt auch

00:54:10.980 --> 00:54:14.740
mit in den Bereich zu packen,

00:54:14.800 --> 00:54:15.560
der halt davon profitiert,

00:54:15.640 --> 00:54:17.640
wenn was deployed wird. Ja, mit in den agilen Sprint

00:54:17.640 --> 00:54:19.300
das zu packen. Genau, genau,

00:54:19.400 --> 00:54:21.040
Agile, auch so ein Ding, wo man sagt, okay,

00:54:21.600 --> 00:54:23.500
genau, packen wir das alles

00:54:23.500 --> 00:54:25.560
zusammen. Ja, oder

00:54:25.560 --> 00:54:27.160
halt eben DevOps, wo man sagt, okay,

00:54:27.780 --> 00:54:29.560
die Leute, die das deployed

00:54:29.560 --> 00:54:31.620
haben wollen, deployen es dann halt auch selber und betreiben es auch selber.

00:54:31.740 --> 00:54:32.720
Der DevSecOps jetzt, ne?

00:54:33.640 --> 00:54:34.000
Okay.

00:54:36.480 --> 00:54:37.720
Fullstack-Microservice

00:54:37.720 --> 00:54:39.080
DevOps

00:54:39.080 --> 00:54:41.460
im agilen Prozess,

00:54:41.460 --> 00:54:43.460
ja, die haben wir alle zusammen, glaube ich,

00:54:43.520 --> 00:54:44.660
weiß nicht, aber ja,

00:54:45.020 --> 00:54:47.560
Es geht halt darum,

00:54:48.000 --> 00:54:51.920
dass einzelne Teams halt möglichst autark

00:54:51.920 --> 00:54:52.840
Dinge machen können.

00:54:53.760 --> 00:54:55.580
Dass man halt sozusagen da, wo man investiert,

00:54:55.760 --> 00:54:57.500
auch tatsächlich, dass die auch dann

00:54:57.500 --> 00:54:59.660
die Möglichkeit haben,

00:54:59.720 --> 00:55:01.280
das umzusetzen. Aber

00:55:01.280 --> 00:55:03.120
das kommt halt mit dem Preis. Das ist halt Trade-Off.

00:55:03.260 --> 00:55:05.500
Es ist halt nicht so, dass das dann insgesamt automatisch

00:55:05.500 --> 00:55:06.880
super viel besser ist, wenn man das so macht, sondern

00:55:06.880 --> 00:55:09.240
man wird dann halt schneller und so, aber man wird

00:55:09.240 --> 00:55:11.500
eigentlich automatisch halt inkonsistenter dabei.

00:55:13.140 --> 00:55:29.040
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.

00:55:29.040 --> 00:55:42.160
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.

00:55:43.140 --> 00:55:44.960
Äh, weiß ich gar nicht.

00:55:45.220 --> 00:55:46.320
Also ich meine, das Problem,

00:55:47.380 --> 00:55:49.160
also vielleicht kann man das ja

00:55:49.160 --> 00:55:51.020
an einzelnen Projekten irgendwie, also

00:55:51.020 --> 00:55:53.320
ich würde ja auch denken, dass eine schlaue Art

00:55:53.320 --> 00:55:55.060
irgendwie, wenn man jetzt migrieren wollte

00:55:55.060 --> 00:55:56.880
von Modulit auf Microsoft, wäre halt,

00:55:57.180 --> 00:55:59.080
man fängt halt klein mit kleineren Teilen an

00:55:59.080 --> 00:56:01.080
und macht das da und man macht nicht alles auf einmal.

00:56:01.660 --> 00:56:03.160
Weil das wird wahrscheinlich nicht gut

00:56:03.160 --> 00:56:03.660
funktionieren.

00:56:04.960 --> 00:56:06.720
Warum im Haupt? Also ich verstehe es immer noch nicht.

00:56:07.300 --> 00:56:08.900
Also irgendwie denke ich immer noch so, ja,

00:56:08.960 --> 00:56:11.000
warum hält man das dann nicht an einer Stelle fest

00:56:11.000 --> 00:56:15.780
und sorgt dann dafür, dass die Devs alle dann an eine Stelle kommen,

00:56:15.900 --> 00:56:16.980
dass sie sich alle gut verstehen,

00:56:17.280 --> 00:56:19.220
dass sie alle dieselbe Tech-Sec benutzen,

00:56:19.360 --> 00:56:21.340
dass sie die Infrastruktur standardisiert benutzen,

00:56:21.380 --> 00:56:23.500
dass sie nur die standardisierte Infrastruktur benutzen, keine andere.

00:56:23.960 --> 00:56:26.560
Und dass halt dieses ganze Distributed-Quatsch, Entschuldigung,

00:56:26.840 --> 00:56:29.040
dass alles weg ist.

00:56:29.160 --> 00:56:32.240
Ich kann ja von mir verschiedene Rechenzentren

00:56:32.240 --> 00:56:33.900
parallel an verschiedenen Orten halten.

00:56:34.000 --> 00:56:35.460
Das ist ja okay, das kann ja ein Server-Team betonen.

00:56:35.460 --> 00:56:37.820
Aber warum muss ich, also die Abhängigkeiten werden dann

00:56:37.820 --> 00:56:39.680
von mir aus schwieriger,

00:56:39.900 --> 00:56:42.220
so ein bisschen zu managen, weil ich habe halt

00:56:42.220 --> 00:56:44.020
das Problem, wie Jochen gerade sagte, dass

00:56:44.020 --> 00:56:46.520
hochspezialisierte, hochgutbezahlte

00:56:46.520 --> 00:56:48.500
Spezialkräfte sich teilweise um trivialen

00:56:48.500 --> 00:56:50.260
Tries kümmern müssen, bis die Sachen

00:56:50.260 --> 00:56:51.380
halt mal integriert sind.

00:56:52.380 --> 00:56:54.000
Aber dafür könnte man ja einen Service schreiben,

00:56:54.100 --> 00:56:55.160
also keinen Microservice, sondern

00:56:55.160 --> 00:56:57.880
einen, der halt in den Monolithen drin hängt.

00:57:00.020 --> 00:57:00.460
Ja.

00:57:00.780 --> 00:57:02.340
Also ich, ganz grundsätzlich,

00:57:02.340 --> 00:57:04.200
ich habe so ein bisschen das Gefühl, du bist so ein bisschen

00:57:04.200 --> 00:57:04.680
biased.

00:57:06.500 --> 00:57:08.040
Das ist mir eine spontane Meinung.

00:57:08.580 --> 00:57:10.280
Nee, es ist ja alles gut.

00:57:10.660 --> 00:57:14.020
Also grundsätzlich muss man halt die Ausgangslage erstmal in Frage stellen.

00:57:14.160 --> 00:57:15.820
Habe ich denn überhaupt die gleichen Kompetenzen?

00:57:15.920 --> 00:57:17.100
Ich meine, darüber hatten wir ja schon geredet.

00:57:17.400 --> 00:57:20.940
Es ist auch nicht immer ganz leicht, die gleichen Kompetenzen überall zu finden für alles.

00:57:21.060 --> 00:57:25.780
Wenn du eine große Firma bist, dann hast du vielleicht irgendwie einen Java-Entwickler,

00:57:25.840 --> 00:57:29.720
der ist Querensteiger in Python oder C-Sharp in C++, was weiß ich.

00:57:29.880 --> 00:57:30.480
Sowas gibt es.

00:57:31.100 --> 00:57:35.360
Und dann verlangst du halt von dem einen Entwickler, dass er seinen Stack zum Beispiel umstellt.

00:57:35.360 --> 00:57:36.300
Das willst du ja auch nicht unbedingt.

00:57:36.500 --> 00:57:44.520
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.

00:57:46.200 --> 00:57:52.760
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.

00:57:52.880 --> 00:57:54.560
Ah, siehste, also Microservice, nein.

00:57:55.120 --> 00:57:57.980
Aber grundsätzlich musst du dir ja auch die Frage stellen erstmal.

00:57:57.980 --> 00:57:59.980
mal vielleicht, um von dieser Ebene

00:57:59.980 --> 00:58:01.580
mal ein bisschen zurück zum Code zu kommen.

00:58:01.980 --> 00:58:03.700
Ein Monolith, der hat natürlich eine riesen

00:58:03.700 --> 00:58:05.860
Code-Basis, die unter Umständen relativ komplex ist.

00:58:05.960 --> 00:58:07.920
Das heißt, du musst viel Aufwand in den

00:58:07.920 --> 00:58:09.380
Deployment-Prozess an sich stecken.

00:58:09.740 --> 00:58:11.780
Also bist du ein einzelnes

00:58:11.780 --> 00:58:13.660
Feature, ein neues Feature deployst oder ein Bug

00:58:13.660 --> 00:58:15.620
fixt, musst du dich mit relativ vielen Leuten, wie der

00:58:15.620 --> 00:58:17.760
Jochen schon gesagt hat, abgesprochen haben. Du bist insgesamt

00:58:17.760 --> 00:58:19.760
ein bisschen langsamer und vor allem

00:58:19.760 --> 00:58:21.040
auch fehleranfälliger insgesamt.

00:58:21.580 --> 00:58:23.840
Wenn irgendein Integration-Test irgendwie fehl geht

00:58:23.840 --> 00:58:25.660
und der irgendwie den Produktionen durchrutscht, dann ist

00:58:25.660 --> 00:58:27.600
im Zweifel raussteigend ganz das System ab und hat eine Daumentime.

00:58:27.960 --> 00:58:48.800
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.

00:58:49.040 --> 00:59:12.640
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…

00:59:12.640 --> 00:59:16.200
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.

00:59:16.440 --> 00:59:35.780
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.

00:59:35.780 --> 00:59:50.400
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.

00:59:51.020 --> 01:00:09.800
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?

01:00:09.800 --> 01:00:26.800
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.

01:00:27.380 --> 01:00:38.520
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.

01:00:39.800 --> 01:00:46.460
Ich freu mich halt, ob das

01:00:46.460 --> 01:00:48.680
einen Unterschied macht.

01:00:48.820 --> 01:00:50.920
Also ist ja egal, ob jetzt jemand an seinem Feature-Branch

01:00:50.920 --> 01:00:51.840
irgendwie eine App baut.

01:00:53.280 --> 01:00:54.580
Süßer, wenn es keinen Unterschied macht,

01:00:54.640 --> 01:00:55.460
ist es doch doppelt egal.

01:00:55.460 --> 01:00:57.400
Nein, aber das ist ja dann

01:00:57.400 --> 01:00:58.440
trotzdem im Monolithen.

01:00:58.860 --> 01:01:00.900
Ja gut, aber mindestens

01:01:00.900 --> 01:01:02.780
habe ich Komplexität raus.

01:01:02.940 --> 01:01:05.020
Sowohl im Code, Microservices ist ein kleinerer Code,

01:01:05.100 --> 01:01:07.480
der ist ein bisschen leichter zu lesen, du kannst dich ein bisschen schneller einarbeiten,

01:01:07.560 --> 01:01:08.860
weil du nicht vor einer Wand aus Code stehst.

01:01:09.180 --> 01:01:13.780
Du stehst von der Wand aus Guidelines und Jira-Pages und was weiß ich.

01:01:14.280 --> 01:01:14.980
Der gute Jira.

01:01:15.920 --> 01:01:21.520
Genau, aber du steigst nicht irgendwie komponententief in den Code rein, musst du auch gar nicht.

01:01:21.580 --> 01:01:23.000
Du kommst gar nicht erst in die Versuchung.

01:01:23.440 --> 01:01:27.860
Also du hast auf jeden Fall erstmal ein bisschen Komplexität auf Code-Ebene entschlankt.

01:01:27.860 --> 01:01:30.340
So durch Microsoft und vielleicht auch durch Deployment-Ebene.

01:01:30.780 --> 01:01:34.220
Und du hast das Risiko erstmal minimiert, dass du es verhaust.

01:01:34.560 --> 01:01:36.740
Und du behinderst niemand anderen damit.

01:01:37.540 --> 01:01:40.580
Also du deployst halt in einem Monolithen immer nacheinander,

01:01:40.960 --> 01:01:41.840
wenn du verschiedene Teams hast.

01:01:42.000 --> 01:01:43.380
Dann deployst du erst Team A, Team B.

01:01:43.820 --> 01:01:45.160
Dann musst du die Reihenfolge festlegen.

01:01:45.360 --> 01:01:46.560
Auch das hast du in Microservices,

01:01:46.720 --> 01:01:48.720
wenn sie unabhängig voneinander sind, teilweise nicht.

01:01:49.120 --> 01:01:50.580
Na klar, Breaking Changes, immer ein Thema.

01:01:50.880 --> 01:01:52.500
Das hast du jetzt auch sehr schön geredet.

01:01:52.820 --> 01:01:54.260
In meinem Kopf, da ploppt gerade wieder aus,

01:01:54.260 --> 01:01:58.320
wenn ich das dann warten möchte und wenn ich das ausbauen möchte,

01:01:58.420 --> 01:02:00.420
wenn das Team weg ist, was diese Microservices entwickelt hat,

01:02:00.740 --> 01:02:01.800
dann muss ich ja wieder Experten suchen,

01:02:01.860 --> 01:02:03.380
sich dann mit dem anderen Tech-Stack auskennen,

01:02:03.460 --> 01:02:04.160
den ich jetzt gar nicht kenne.

01:02:04.400 --> 01:02:04.900
Vielleicht ja nicht.

01:02:05.320 --> 01:02:07.400
der Microservice an sich, der soll relativ schnell

01:02:07.400 --> 01:02:09.380
entwickelt sein. Ich meine, das ist jetzt auch wieder

01:02:09.380 --> 01:02:11.260
Theorie, aber rein theoretisch soll auch

01:02:11.260 --> 01:02:12.840
ein Microservice austauschbar sein.

01:02:13.520 --> 01:02:14.300
Ja, okay. Das heißt,

01:02:14.460 --> 01:02:17.000
das ist ein Wegwerfding. Das heißt, wenn es nicht mehr läuft,

01:02:17.100 --> 01:02:19.320
dann würde ich halt jemand aus einem anderen TechSec den gleichen

01:02:19.320 --> 01:02:21.340
Microservice neu bauen irgendwie und das dann günstiger

01:02:21.340 --> 01:02:23.520
hat, den anderen neu zu warten.

01:02:23.980 --> 01:02:24.140
Ja, okay.

01:02:25.160 --> 01:02:27.120
Ja, könntest du natürlich machen.

01:02:27.240 --> 01:02:28.880
Aber ja, ich meine, ja, ehrlich gesagt,

01:02:28.980 --> 01:02:31.200
ich bin da, also ich meine, ich würde schon

01:02:31.200 --> 01:02:33.300
sagen, natürlich, das ist klar, dass Situationen

01:02:33.300 --> 01:02:34.880
in den Microservices halt voll gut sind.

01:02:35.320 --> 01:02:37.860
würde ich jetzt gar nicht bestreiten

01:02:37.860 --> 01:02:39.420
wollen, aber auch, also

01:02:39.420 --> 01:02:41.800
würde man damit anfangen wollen, wenn man jetzt

01:02:41.800 --> 01:02:43.740
noch nichts gebaut hat, da wäre ich auch eher

01:02:43.740 --> 01:02:45.340
skeptisch, glaube ich, aber

01:02:45.340 --> 01:02:47.540
also genau, also ich meine, das ist halt hier die

01:02:47.540 --> 01:02:49.740
Frage, gibt es irgendwie einen Grund, warum man das machen

01:02:49.740 --> 01:02:50.840
sollte, der

01:02:50.840 --> 01:02:53.300
was ich dann, was der

01:02:53.300 --> 01:02:55.520
der Autor von dem Buch da meinte, ist

01:02:55.520 --> 01:02:57.620
naja, eigentlich eher so, Microsoft

01:02:57.620 --> 01:02:59.640
das macht man halt dann, wenn sonst nichts mehr

01:02:59.640 --> 01:03:01.480
funktioniert, also wenn halt sozusagen

01:03:01.480 --> 01:03:03.640
wenn alle anderen Ansätze halt nicht

01:03:03.640 --> 01:03:05.040
funktionieren, dann muss man halt

01:03:05.040 --> 01:03:05.920
irgendwie, ne, aber

01:03:05.920 --> 01:03:08.780
ja, also

01:03:08.780 --> 01:03:11.200
und der sagt halt, der Hauptgrund,

01:03:11.360 --> 01:03:13.040
der wichtigste Grund, der tatsächlich irgendwie valide

01:03:13.040 --> 01:03:15.060
ist, ist halt, dass man Teile der Organisation

01:03:15.060 --> 01:03:16.880
halt unabhängig machen will vom Rest

01:03:16.880 --> 01:03:19.040
eben dadurch, dass sie halt selber

01:03:19.040 --> 01:03:21.000
deployen können und

01:03:21.000 --> 01:03:23.140
genau, wenn das halt anders

01:03:23.140 --> 01:03:25.000
nicht geht, dann muss man das halt so machen.

01:03:25.400 --> 01:03:26.980
Aber, und ja, das kann halt

01:03:26.980 --> 01:03:28.900
natürlich sein, wenn du halt einen großen Monolithen hast, den du schlecht

01:03:28.900 --> 01:03:30.840
deployen kannst und dann halt einzelne Teams halt

01:03:30.840 --> 01:03:32.960
sagen so, wir würden gerne, aber wir kommen, es wird nicht

01:03:32.960 --> 01:03:34.720
live, das, was wir machen, dann

01:03:34.720 --> 01:03:35.700
geht es halt vielleicht nicht anders.

01:03:36.600 --> 01:03:38.660
Wir können vielleicht auch sogar

01:03:38.660 --> 01:03:40.760
in Richtung Use Cases gehen. Ich meine, wir hatten

01:03:40.760 --> 01:03:42.700
ja schon Beispiele, Bestellservice meinetwegen oder

01:03:42.700 --> 01:03:44.820
IoT wäre auch noch so ein Bereich, wo es

01:03:44.820 --> 01:03:46.740
prinzipiell durchaus auch

01:03:46.740 --> 01:03:48.880
natürlich wirken kann, Microservices zu etablieren.

01:03:49.040 --> 01:03:50.620
Ich meine, nehmen wir jetzt mal an,

01:03:50.680 --> 01:03:52.600
wir haben einen sehr, sehr großen Datendurchsatz. Also wir

01:03:52.600 --> 01:03:54.600
haben irgendwo eine Nutzerplattform, da machen Nutzer irgendwelche

01:03:54.600 --> 01:03:56.720
Sachen und parallel davon kommen meinetwegen

01:03:56.720 --> 01:03:58.980
aus dem IoT-Bereich irgendwelche

01:03:58.980 --> 01:04:00.600
Temperaturdaten von Heizung rein

01:04:00.600 --> 01:04:02.720
oder Geodaten vom Auto, was weiß

01:04:02.720 --> 01:04:04.600
ich. Also du schreibst ja viele

01:04:04.600 --> 01:04:06.720
Daten, dann willst du natürlich

01:04:06.720 --> 01:04:08.380
dafür sorgen, dass dieser Schreibprozess,

01:04:09.120 --> 01:04:10.820
der die ganze Zeit irgendwo hinschreibt,

01:04:11.300 --> 01:04:12.280
von deinem

01:04:12.280 --> 01:04:14.360
User-Dashboard irgendwie entkoppelt ist.

01:04:14.540 --> 01:04:16.540
Du hast ja keinen Bock, dass die Datenbank dadurch

01:04:16.540 --> 01:04:18.420
langsamer wird. Unter Umständen ist die

01:04:18.420 --> 01:04:20.580
Datenbank da auch gar nicht die Richtige für, um diese Art

01:04:20.580 --> 01:04:22.500
von Daten da reinzuschreiben. Das heißt,

01:04:22.540 --> 01:04:24.620
wir haben auf einmal mit diesem Beispiel einen Kontext

01:04:24.620 --> 01:04:26.560
geschaffen, wo wir sagen müssen, okay, wir

01:04:26.560 --> 01:04:28.540
haben zwei komplett unterschiedliche Anforderungen

01:04:28.540 --> 01:04:30.380
geschaffen. Wir haben einmal irgendein Dashboard,

01:04:30.860 --> 01:04:31.960
das ist so klassisch HTML,

01:04:32.420 --> 01:04:34.340
kannst eine SQL-Datenbank hinterhängen,

01:04:34.380 --> 01:04:36.500
ist alles toll. Und wir haben auf einmal

01:04:36.500 --> 01:04:38.360
irgendwie, meinetwegen IoT-Daten,

01:04:38.740 --> 01:04:40.340
Geodaten, irgendwas, die in

01:04:40.340 --> 01:04:42.080
hoher Frequenz geschrieben werden.

01:04:42.500 --> 01:04:44.360
Da müssen wir uns überlegen, gut, wie verwalten wir den ganzen

01:04:44.360 --> 01:04:46.860
Spaß eigentlich? Eignet sich da für meine...

01:04:46.860 --> 01:04:48.420
Aber ich habe es jetzt nicht genau verstanden.

01:04:48.540 --> 01:04:50.180
Also du sagst, du würdest dich voneinander trennen, also

01:04:50.180 --> 01:04:52.240
du sagst nicht beispielsweise, du hast eine SQL-Datenbank,

01:04:52.700 --> 01:04:54.340
da kommen die Sachen von der IoT-Sache

01:04:54.340 --> 01:04:56.660
einfach rein und der User liest halt aus der...

01:04:56.660 --> 01:04:58.240
Ja, ich fülle das

01:04:58.240 --> 01:04:59.980
erstmal weiter aus noch. Also ich kann überlegen,

01:05:00.160 --> 01:05:01.720
schreibe ich das jetzt gleichzeitig damit rein.

01:05:02.060 --> 01:05:03.340
Aber irgendwann stelle ich halt fest, okay,

01:05:04.280 --> 01:05:06.160
zu Lastzeiten wird auf einmal meine

01:05:06.160 --> 01:05:08.320
Internetseite langsamer, weil ich auf einmal

01:05:08.320 --> 01:05:10.460
zu viele Daten schreibe von diesem IoT-Prozess.

01:05:10.660 --> 01:05:12.020
Und die User, die kriegen

01:05:12.020 --> 01:05:14.580
eine schlechte Nutzererfahrung dadurch.

01:05:14.960 --> 01:05:16.740
Also die Schreiblast,

01:05:16.740 --> 01:05:18.640
die steigt, dadurch wird die Internetseite

01:05:18.640 --> 01:05:20.680
unter Umständen langsamer, weil ich

01:05:20.680 --> 01:05:22.720
alles ineinander verwurschtelt habe. Und da muss ich

01:05:22.720 --> 01:05:24.400
überlegen, gut, wie gehe ich jetzt damit um?

01:05:25.920 --> 01:05:26.080
Also

01:05:26.080 --> 01:05:28.140
normalerweise sollte

01:05:28.140 --> 01:05:30.760
das gar nicht so viel langsamer werden, oder?

01:05:31.000 --> 01:05:32.000
Weil du kannst ja eigentlich...

01:05:32.000 --> 01:05:33.660
wenn du schreibst, klar.

01:05:34.380 --> 01:05:36.180
Aber gut, oder ich meine...

01:05:36.180 --> 01:05:38.060
Also zum Beispiel Postgres lockt jetzt dann nur

01:05:38.060 --> 01:05:40.020
die Zeile, wenn du schreibst. Und wenn du jetzt ein neues

01:05:40.020 --> 01:05:41.860
IoT hast, dann hat der eine neue Zeile drauf. Das heißt,

01:05:41.960 --> 01:05:44.020
der Nutzer, der kann ja alle anderen Zeilen zum Beispiel lesen.

01:05:46.000 --> 01:05:46.320
Ja,

01:05:46.440 --> 01:05:47.660
also ich meine, das kann

01:05:47.660 --> 01:05:49.660
natürlich schon passieren. Das kann natürlich schon passieren, dass

01:05:49.660 --> 01:05:51.400
Schreibtlast irgendwann irgendwie

01:05:51.400 --> 01:05:53.280
dein System langsam macht.

01:05:53.820 --> 01:05:55.760
Aber meine Frage wäre halt ja, wie häufig kommt

01:05:55.760 --> 01:05:58.180
das denn vor, dass man so skalierbar...

01:05:58.180 --> 01:06:00.040
Also ich würde sagen, ja, es gibt einen validen Grund,

01:06:00.440 --> 01:06:01.860
Microservices aus Skalierbarkeitsgründen

01:06:01.860 --> 01:06:03.260
einzusetzen, aber wie häufig kommt denn das vor?

01:06:03.300 --> 01:06:04.820
Es kommt vor.

01:06:05.820 --> 01:06:07.400
Was wäre denn jetzt die Lösung davon?

01:06:07.760 --> 01:06:09.940
Dann habe ich Sachen, die IoT schreibt in eine Datenbank

01:06:09.940 --> 01:06:11.800
rein und dann habe ich ja

01:06:11.800 --> 01:06:13.760
den Flaschenhals bei dem Prozess,

01:06:13.900 --> 01:06:16.060
der von der einen Datenbank in die andere Datenbank

01:06:16.060 --> 01:06:17.920
das übertragen muss. Dann ist ja der Stand

01:06:17.920 --> 01:06:19.920
alt beispielsweise, weil die Verbindung...

01:06:19.920 --> 01:06:21.900
Ja, die Frage ist, ob wir das überhaupt

01:06:21.900 --> 01:06:23.300
übertragen müssen. Also

01:06:23.300 --> 01:06:24.260
Microservices.

01:06:25.380 --> 01:06:26.660
Als erstes stelle ich fest, okay,

01:06:27.660 --> 01:06:29.480
das passt jetzt nicht irgendwie in die SQL-Datenbank.

01:06:29.480 --> 01:06:30.840
Die wächst mir zu schnell. Das sind

01:06:30.840 --> 01:06:33.680
Zeitreihen zum Beispiel

01:06:33.680 --> 01:06:35.540
und dann schreibe ich das in eine Datenbank,

01:06:35.640 --> 01:06:36.660
die extra dafür vorgesehen ist.

01:06:38.280 --> 01:06:39.260
Prometheus ist auch eine,

01:06:39.420 --> 01:06:40.640
aber die ist eher so für Metrikdaten.

01:06:41.220 --> 01:06:42.940
Dann schreibe ich das da rein, dann überlege ich gut,

01:06:43.060 --> 01:06:45.100
wie ziehe ich mir die jetzt in dieses monolithische Ding,

01:06:45.100 --> 01:06:46.440
aber es macht für mich erstmal überhaupt keinen Sinn,

01:06:46.840 --> 01:06:48.940
diese Art von Daten in die SQL-Datenbank vielleicht zu schreiben.

01:06:49.540 --> 01:06:51.340
Das heißt, ich habe diesen Prozess mal getrennt

01:06:51.340 --> 01:06:53.060
und auf einmal habe ich

01:06:53.060 --> 01:06:53.560
Möglichkeiten.

01:06:55.720 --> 01:06:57.100
Auf einmal habe ich es geschafft,

01:06:57.160 --> 01:06:58.840
diesen Prozess zu trennen und jetzt kann ich überlegen, gut,

01:06:59.880 --> 01:07:02.680
Zu Lastzeiten zum Beispiel haben wir immer höhere Peaks.

01:07:03.200 --> 01:07:06.000
So, wie kann ich die Architektur jetzt vielleicht sogar günstig halten?

01:07:07.020 --> 01:07:09.800
Dann kann ich auf einmal überlegen, weil ich jetzt meine Datenbanken getrennt habe,

01:07:09.860 --> 01:07:13.180
ich habe jetzt eingesehen, okay, ich habe einen getrennten Schreibprozess von diesem Dashboard-Prozess.

01:07:13.480 --> 01:07:15.740
Jetzt kann ich anfangen, den Schreibprozess zu optimieren und meinetwegen,

01:07:16.520 --> 01:07:19.900
ich mache es jetzt mal ganz wild, meinetwegen einen Kafka in die Mitte zu hängen.

01:07:20.740 --> 01:07:22.320
So, dann schreibe ich jetzt Richtung Kafka rein.

01:07:22.860 --> 01:07:26.420
Kafka ist letztlich so ein Topic, hast einzelne Nachrichten drin.

01:07:27.020 --> 01:07:30.340
Und diese Nachrichten, die können asynchron zum Prozess konsumiert werden.

01:07:31.060 --> 01:07:35.520
Und zu Schreibzeiten schreibe ich ganz viele Nachrichten in dieses Topic.

01:07:35.520 --> 01:07:40.360
Ich habe aber vielleicht gar nicht die Kapazität, um alles in Echtzeit abzuarbeiten.

01:07:40.820 --> 01:07:43.700
Aber vielleicht ist es auch gar nicht schlimm, ich kann die nachabarbeiten.

01:07:44.200 --> 01:07:49.800
Also von diesem Ticketsystem kann ich mir dann meinetwegen 10 Minuten verzögert Nachrichten rausziehen

01:07:49.800 --> 01:07:51.540
und die dann erst in die Datenbank reinschreiben.

01:07:52.000 --> 01:07:55.320
Und dann habe ich nicht das Problem, dass ich meinen Server unter Umständen dynamisch skalieren muss.

01:07:57.020 --> 01:07:58.660
Wo er generell hochskalieren muss.

01:07:59.700 --> 01:08:00.540
Ja, aber gut,

01:08:00.720 --> 01:08:02.240
da wäre halt die Frage, was ist

01:08:02.240 --> 01:08:04.560
ja, also ja, ist alles

01:08:04.560 --> 01:08:04.920
valide,

01:08:05.780 --> 01:08:08.300
aber was ist teurer, irgendwie

01:08:08.300 --> 01:08:10.700
die Architektur aufzuteilen

01:08:10.700 --> 01:08:12.400
oder irgendwie einen von dickeren Server zu kaufen?

01:08:13.080 --> 01:08:14.040
Ja, aber auch

01:08:14.040 --> 01:08:16.640
da gibt es so sehr, sehr schöne Graphen,

01:08:16.720 --> 01:08:17.460
das ist natürlich

01:08:17.460 --> 01:08:20.720
ein Monolith ist sehr, sehr lange

01:08:20.720 --> 01:08:22.520
günstiger als Microsoft, das stimmt, aber

01:08:22.520 --> 01:08:24.620
irgendwann, irgendwann kann man

01:08:24.620 --> 01:08:26.160
zu diesem Punkt kommen, wo es

01:08:26.160 --> 01:08:28.040
überproportional teurer wird,

01:08:28.240 --> 01:08:29.720
sich größere Hardware zu kaufen.

01:08:30.220 --> 01:08:31.900
Also erstmal steigt das irgendwie sehr, sehr

01:08:31.900 --> 01:08:32.480
geradlinig.

01:08:33.620 --> 01:08:35.820
Ich gestikuliere hier immer so rum, aber es ist ja Podcast.

01:08:41.180 --> 01:08:41.960
Erstmal steigt das

01:08:41.960 --> 01:08:43.780
relativ geradlinig, also irgendwie

01:08:43.780 --> 01:08:45.960
F von X gleich X, kann man sich sehr schön vorstellen.

01:08:46.520 --> 01:08:47.920
Und hinten raus wird es dann auf einmal

01:08:47.920 --> 01:08:48.540
exponentiell.

01:08:49.620 --> 01:08:51.760
Dann explodieren die die Kosten, weil

01:08:51.760 --> 01:08:53.440
die Maschinen dann einfach wirklich

01:08:53.440 --> 01:08:55.900
sehr, sehr

01:08:55.900 --> 01:08:57.720
teuer sein. Also ich finde,

01:08:57.880 --> 01:08:59.880
das Problem, was du gerade gesprochen hast, müsste man eigentlich noch mal

01:08:59.880 --> 01:09:02.040
mit Leuten, die noch ein bisschen mehr Spezialwissen

01:09:02.040 --> 01:09:03.360
in Datenbank haben, sprechen, weil

01:09:03.360 --> 01:09:06.160
für mich hört sich das nicht so an, als wäre da der Flaschenhals

01:09:06.160 --> 01:09:07.360
an der richtigen Stelle.

01:09:08.280 --> 01:09:09.940
Deswegen würde ich sagen, das gibt es alles schon.

01:09:10.140 --> 01:09:11.620
Also es ist halt die Frage, ob es so häufig ist.

01:09:11.900 --> 01:09:13.840
Ich meine, das Problem ist halt, also was du dafür

01:09:13.840 --> 01:09:15.320
aufgibst, ist natürlich die Konsistenz.

01:09:16.600 --> 01:09:17.980
Ja, das stimmt halt

01:09:17.980 --> 01:09:19.800
einfach nicht mehr. Und ich habe halt dazwischen noch so ein extra Layer,

01:09:19.880 --> 01:09:21.480
wenn ich jetzt einen Kafka dazwischen mache. Warum?

01:09:21.660 --> 01:09:23.800
Also wenn ich jetzt eigentlich direkt aus der Datenbank lesen könnte

01:09:23.800 --> 01:09:25.780
und die Frage, du sagst halt, die Datenbank wird langsam, das verstehe ich nicht

01:09:25.780 --> 01:09:26.660
genau, weil

01:09:26.660 --> 01:09:29.320
wie viele Verbindungen hat die denn dann offen?

01:09:30.000 --> 01:09:31.600
Nein, aber einfach die Schreib...

01:09:31.600 --> 01:09:32.300
Zum Beispiel, du

01:09:32.300 --> 01:09:35.340
hast ja nur eine bestimmte Bandbreite zu deinen

01:09:35.340 --> 01:09:37.340
Platten, wenn du es wirklich schreiben musst.

01:09:37.460 --> 01:09:39.460
Wie du denn, ganz ehrlich, die Postgres hängt

01:09:39.460 --> 01:09:40.060
im Bram.

01:09:41.180 --> 01:09:43.280
Nee, nee, nee, wenn du was schreibst,

01:09:43.280 --> 01:09:44.460
nein, nein, das ist ja...

01:09:44.460 --> 01:09:47.280
Nee, ja, nur beim Lesen,

01:09:47.340 --> 01:09:48.660
nicht beim Schreiben. Doch, beim Schreiben auch.

01:09:49.000 --> 01:09:51.400
Doch, das wird dann mit Vakuum

01:09:51.400 --> 01:09:52.120
reingeschrieben.

01:09:52.980 --> 01:09:54.620
Nee, also das ist, wenn

01:09:54.620 --> 01:09:56.520
die Transaktion fertig ist,

01:09:56.940 --> 01:09:58.800
dann hat Postgres F-Sync hinterher

01:09:58.800 --> 01:10:00.820
aufgerufen, dann ist das, dann hat die Platte

01:10:00.820 --> 01:10:02.200
gesagt, ich hab's weggeschrieben.

01:10:03.880 --> 01:10:04.660
Und das

01:10:04.660 --> 01:10:06.840
ist, das macht Postgres

01:10:06.840 --> 01:10:08.540
unfassbar viel langsamer als sowas wie Redis.

01:10:09.340 --> 01:10:10.860
Aber bei Redis ist halt auch, wenn du

01:10:10.860 --> 01:10:12.460
dann, wenn du das Ding ausmachst, dann ist

01:10:12.460 --> 01:10:14.680
die Daten sind halt weg. Bei Postgres

01:10:14.680 --> 01:10:16.680
nicht, da sind die Daten halt noch da. Das ist der große

01:10:16.680 --> 01:10:18.720
Unterschied. Ja, aber die Frage ist halt, was

01:10:18.720 --> 01:10:20.640
halt dann schreiben und so weiter, wann wird das halt überhaupt

01:10:20.640 --> 01:10:21.960
freigegeben? Also das ist ja egal.

01:10:22.280 --> 01:10:24.600
Wenn dir der Datenmarkt sagt, deine Transaktion ist durch, dann ist

01:10:24.600 --> 01:10:26.600
das wirklich in der Platte gelandet. Ja, aber das macht aber die Postgres nicht

01:10:26.600 --> 01:10:28.500
langsamer, sondern das ist halt nur so, dass das

01:10:28.500 --> 01:10:30.720
nur schreiben langsamer. Ja, aber das

01:10:30.720 --> 01:10:32.600
macht die langsamer. Ja, aber das macht schreiben langsamer, aber das heißt

01:10:32.600 --> 01:10:33.760
nicht, dass das Lesen langsamer wird.

01:10:34.660 --> 01:10:36.760
Ja doch, weil in der Zeit, wo du was schreibst,

01:10:36.780 --> 01:10:38.680
kannst du nichts lesen. Nein, du kannst nur die Sachen nicht lesen, die geschrieben

01:10:38.680 --> 01:10:40.860
werden. Also du kannst die Sachen nicht lesen, die noch nicht im Hauptschweiger

01:10:40.860 --> 01:10:42.560
sind, ja? Sagen wir so. Ja, genau. Also die, die noch nicht

01:10:42.560 --> 01:10:44.760
auf der Platte sind, die kannst du nicht lesen,

01:10:45.020 --> 01:10:46.700
aber das heißt ja nicht, dass du nicht die Sachen, die vorher drin

01:10:46.700 --> 01:10:48.740
sind, lesen kannst, weil die Transaktion von den Sachen, die noch nicht geschrieben

01:10:48.740 --> 01:10:50.580
wenn es noch nicht fertig ist. Das heißt, dass du den

01:10:50.580 --> 01:10:52.640
Stand der Schreibdachlichkeit, das heißt aber nicht, dass das Lesen

01:10:52.640 --> 01:10:53.460
langsamer wird.

01:10:54.020 --> 01:10:56.480
Ja, letztlich schon irgendwann.

01:10:57.160 --> 01:10:58.140
Nein, das ist ein eigener Prozess.

01:10:58.680 --> 01:10:59.780
Das ist völlig unabhängig davon.

01:11:00.240 --> 01:11:01.360
Also wenn irgendwann

01:11:01.360 --> 01:11:04.480
quasi, wenn du so viel schreibst, dass du

01:11:04.480 --> 01:11:06.380
nichts anderes mehr machen kannst als schreiben und dann

01:11:06.380 --> 01:11:08.560
die Bandbreite zu deinen Platten halt

01:11:08.560 --> 01:11:10.180
oder SSDs heute halt irgendwie

01:11:10.180 --> 01:11:12.720
ausgefüllt ist mit Schreibvorgängen,

01:11:13.260 --> 01:11:14.660
dann kannst du nicht mehr viel lesen.

01:11:14.660 --> 01:11:16.240
Nein, wieso? Also lesen lest du ja eh noch aus dem Speicher.

01:11:16.320 --> 01:11:16.740
Das ist ja egal.

01:11:18.320 --> 01:11:19.800
Das I.O. ist ja nur das CPU.

01:11:19.900 --> 01:11:21.800
Wenn dein Working-Set komplett im Hauptspeicher ist, ja.

01:11:21.800 --> 01:11:23.080
Ja, das ist sowieso immer im Hauptspeicher.

01:11:24.520 --> 01:11:26.100
Das ist immer im Hauptspeicher, das ist wirklich so.

01:11:26.380 --> 01:11:27.900
Und das Einzige, was halt da dein

01:11:27.900 --> 01:11:29.980
Konzept ist, ist dann die CPU-Kerne, die halt

01:11:29.980 --> 01:11:32.040
damit beschäftigt sind. Wie viele

01:11:32.040 --> 01:11:34.020
Prozesse du offen hast, also das heißt, wie viel Gleichzeit

01:11:34.020 --> 01:11:35.340
in der Verbindung, die auf deiner Datenbank stehen.

01:11:36.520 --> 01:11:38.020
Ja, also sagen wir mal so,

01:11:38.060 --> 01:11:40.120
in der Praxis, das, wo dir

01:11:40.120 --> 01:11:41.620
häufig das System platzt,

01:11:41.720 --> 01:11:44.120
ich sag mal so, also das ist ja so erfahrungswert aus der Praxis,

01:11:44.520 --> 01:11:45.840
das, wo du dann merkst, okay,

01:11:45.840 --> 01:11:47.740
ich hab hier ein Problem, wo ich irgendwie

01:11:47.740 --> 01:11:49.740
mit der Architektur anfangen musst, was zu machen,

01:11:49.900 --> 01:11:51.880
ist, dass irgendwann

01:11:51.880 --> 01:11:53.840
deine Slaves mit der Schreiblast

01:11:53.840 --> 01:11:55.940
nicht mehr klarkommen. Also deine Replikas.

01:11:56.340 --> 01:11:57.700
Wenn du das nicht mehr

01:11:57.700 --> 01:11:59.720
hinkriegst, wenn dein Replikations-Lag

01:11:59.720 --> 01:12:01.580
immer größer wird, weil du das nicht mehr

01:12:01.580 --> 01:12:03.460
weggeschrieben bekommst, was du an Schreiblast hast.

01:12:04.040 --> 01:12:05.880
An dem Moment hast du ein Problem

01:12:05.880 --> 01:12:07.520
mit deiner Architektur. Da musst du das sowieso

01:12:07.520 --> 01:12:09.500
aufbrechen, ob du dann Microservice machst oder

01:12:09.500 --> 01:12:11.500
also sozusagen vertikal auftrennst oder

01:12:11.500 --> 01:12:13.480
ob du es horizontal auftrennst, indem du dann

01:12:13.480 --> 01:12:15.720
halt sozusagen das schadest

01:12:15.720 --> 01:12:17.540
nach irgendeinem Hash oder so, wo du dann halt

01:12:17.540 --> 01:12:19.660
mehrere Master hast, in die du schreibst.

01:12:19.680 --> 01:12:21.680
Ja, Master Slave, ja. Genau, das

01:12:21.680 --> 01:12:23.960
kannst du dir dann überlegen, ist beides schrecklich

01:12:23.960 --> 01:12:25.800
und macht dein ganzes Datenbankmodell

01:12:25.800 --> 01:12:27.700
im Grunde kaputt und inkonsistent, ja.

01:12:27.860 --> 01:12:29.340
Also das, aber das kannst du dir dann nicht mehr aussuchen.

01:12:29.540 --> 01:12:31.500
Ja, aber du machst das Slave-System mit so einer Postgres,

01:12:31.560 --> 01:12:33.660
dann hast du dann, wo die darin reinschreiben und dann

01:12:33.660 --> 01:12:35.080
lesen die halt aus dem anderen Teil.

01:12:35.600 --> 01:12:37.640
Ja, aber was ist, wenn deine Slaves das nicht mehr wegschreiben können?

01:12:37.980 --> 01:12:39.520
Das passiert. Das ist so.

01:12:39.520 --> 01:12:41.940
Das ist halt, dann bist du an dem Punkt, wo es nicht mehr geht.

01:12:42.020 --> 01:12:42.500
Noch mehr Slaves?

01:12:43.220 --> 01:12:45.480
Nein, die können es nicht mehr schnell genug wegschreiben.

01:12:45.640 --> 01:12:46.280
Dann ist es einfach vorbei.

01:12:46.960 --> 01:12:48.720
an der Stelle, also ich meine, das ist

01:12:48.720 --> 01:12:50.920
heutzutage, also wer kommt an diese Punkte? Also das ist halt

01:12:50.920 --> 01:12:53.100
ja, das ist nicht so häufig,

01:12:53.200 --> 01:12:55.060
denke ich, aber das kann schon

01:12:55.060 --> 01:12:56.640
passieren und dann musst du schaden.

01:12:56.740 --> 01:12:58.500
Also wenn man den Rest dann vorher

01:12:58.500 --> 01:13:00.780
richtig gemacht hat, die Frage wäre halt, wenn du das sowieso

01:13:00.780 --> 01:13:02.880
nicht schnell genug wegschreiben kannst, dann musst

01:13:02.880 --> 01:13:04.360
du ja eh warten irgendwo.

01:13:04.700 --> 01:13:06.840
Ja, und da hilft dann noch Kafka. Da hast du die

01:13:06.840 --> 01:13:08.760
Nachrichten schön in einem Topic und holst die später

01:13:08.760 --> 01:13:10.960
nochmal ab. Die Frage ist natürlich, wie langsam

01:13:10.960 --> 01:13:12.820
sie da drin bleiben, aber da brauchst du halt

01:13:12.820 --> 01:13:14.620
genug Worker. Also diesen Prozess, den müsstest du dann

01:13:14.620 --> 01:13:16.220
gewährleisten können, aber auch da hast du Möglichkeiten.

01:13:16.960 --> 01:13:25.920
Dann kannst du sagen, irgendwie bis zu so und so viel Speicher soll vorgehalten werden oder so und so lange und dann kannst du die erst wegschmeißen und du musst auch überlegen, brauche ich alles, brauche ich alles, alles oder.

01:13:26.940 --> 01:13:28.400
Du hast halt eine Latenz dann, ne?

01:13:28.400 --> 01:13:42.660
Ja, nicht nur Latenz, also vielleicht hast du auch einen Datenverlust unter Umständen, aber die Frage ist, kann ich vielleicht Daten verlieren? Also ich meine gerade im Bereich von Zeitreihen ist es auch oft so, dass Daten über einen gewissen Zeitraum hinweg zusammengefasst werden und einfach irgendwie gemittelt werden.

01:13:44.080 --> 01:14:13.120
Und dann ist das Problem, worüber wir uns gerade streiten, gar nicht mehr so schlimm, aber das Problem ist in dem Zeitpunkt schlimm, wenn du es auf einmal in einer monolithischen Struktur vielleicht drin hast und einzelne Services dadurch umkippen und du hast es jetzt irgendwie so ein bisschen entlastet und das Replikations-Lag, wie Jochen sehr schön gesagt hat, das wächst und wächst und dann stoppst du halt eine gewisse Zeit lang mal den Schreibprozess und hast dann meinetwegen ein Consumer-Lag im Kafka, aber das kannst du ja irgendwie so zurechtschrauben, dass es funktioniert, dass es deine Architektur verkraftet.

01:14:13.120 --> 01:14:21.680
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.

01:14:22.160 --> 01:14:25.860
Wie viele IT-Geräte muss es denn da gegeben haben, damit das ein Problem wird?

01:14:27.520 --> 01:14:29.080
Keine Ahnung, das muss man schon ganz genau sagen.

01:14:29.100 --> 01:14:31.960
Kommt drauf an, wie du das machst und wie in paar Firmen du am Ende auch arbeitest.

01:14:32.800 --> 01:15:02.500
Ja, aber letztendlich, also diese Art von Problemen hast du natürlich immer, also Chris Künthopp, der hat das mal irgendwie so schön genannt, es gibt ja im Grunde zwei unterschiedliche Arten von Datenbanken, es gibt halt die OLTP, Online Transaction Processing Datenbanken, das sind halt so die, wenn du jetzt auf einen Kaufen-Button klickst, die dann halt die Kauftransaktionen machen und es gibt halt OLAP, also Online Analytical Processing, das ist halt so dein Data Warehouse irgendwie und er sagte das mal sehr schön,

01:15:02.500 --> 01:15:04.440
jetzt die Leute irgendwas machen und du schreibst halt

01:15:04.440 --> 01:15:06.520
Sachen, also OLTP ist zum Schreiben gedacht

01:15:06.520 --> 01:15:07.800
und OLAP eher zum Lesen.

01:15:09.180 --> 01:15:10.740
So, wenn die jetzt irgendwie die ganze

01:15:10.740 --> 01:15:12.620
Zeit irgendwie diese Geschichten generieren,

01:15:12.740 --> 01:15:15.140
dann, also im Grunde, jede OLTP-Datenbank

01:15:15.140 --> 01:15:16.360
hat in sich so ein

01:15:16.360 --> 01:15:18.020
Data-Warehouse, das raus möchte.

01:15:18.360 --> 01:15:19.560
Irgendwie von einer gewissen Zeit.

01:15:20.260 --> 01:15:22.320
Das fand ich gerade ein sehr schönes Bild. Ja, das ist halt so.

01:15:22.460 --> 01:15:24.520
Irgendwann willst du das halt vielleicht da raustrennen.

01:15:26.000 --> 01:15:26.400
Ja.

01:15:27.440 --> 01:15:28.400
Aber spannend.

01:15:28.400 --> 01:15:30.600
Also, dass es dann doch wieder um Datenbank

01:15:30.600 --> 01:15:32.540
ging am Ende, bei der Frage,

01:15:32.680 --> 01:15:34.420
ob man Microservices an der Stelle macht oder nicht.

01:15:34.420 --> 01:15:35.820
Nein, das weiß ich ja gerade gar nicht.

01:15:35.820 --> 01:15:37.800
Aber es kann doch sein, dass die Datenhaltung,

01:15:37.860 --> 01:15:39.960
da haben wir ja auch fast mit angefangen, dass das Datenmodell,

01:15:40.020 --> 01:15:41.320
die Datenhaltung dafür sehr relevant ist.

01:15:41.500 --> 01:15:43.720
Das ist einfach ein Problem, aber das Schöne ist,

01:15:43.780 --> 01:15:46.260
dass du quasi, und das ist vielleicht

01:15:46.260 --> 01:15:48.480
eher der Knackpunkt, das Schöne ist, dass man erkannt hat,

01:15:48.580 --> 01:15:50.300
okay, wir haben jetzt IoT-Daten, die ich vielleicht

01:15:50.300 --> 01:15:52.300
anders behandeln möchte als meine Nutzerdaten,

01:15:52.780 --> 01:15:54.240
die ich vielleicht anders ablegen möchte.

01:15:54.740 --> 01:15:56.460
Und will ich das in einem Monolithen machen

01:15:56.460 --> 01:15:58.260
oder erkenne ich, dass ich vielleicht dafür

01:15:58.260 --> 01:16:00.500
auch einfach ein ganz, ganz anderes Know-how brauche?

01:16:00.600 --> 01:16:02.440
ich habe jetzt meinetwegen eine SQL-Django-Anwendung,

01:16:02.880 --> 01:16:04.640
erkenne aber, dass das kein SQL-Kontext

01:16:04.640 --> 01:16:06.600
ist. Habe ich jetzt die Leute bei mir,

01:16:06.680 --> 01:16:08.640
die sich mit dieser Art von Daten auskennen

01:16:08.640 --> 01:16:10.540
oder brauche ich dafür vielleicht neue Daten?

01:16:11.340 --> 01:16:12.340
Sorry, neue Leute.

01:16:12.620 --> 01:16:14.500
Und kriege ich diese neuen Leute in das bestehende

01:16:14.500 --> 01:16:16.440
Team rein oder baue ich dafür ein

01:16:16.440 --> 01:16:18.600
separates Team mit einem separaten Service auf,

01:16:18.600 --> 01:16:20.500
der da einfach parallel läuft, weil

01:16:20.500 --> 01:16:22.300
es halt besser ist in diesem Moment

01:16:22.300 --> 01:16:24.440
für das Problem, welches ich jetzt gerade versuche

01:16:24.440 --> 01:16:26.280
zu lösen.

01:16:26.880 --> 01:16:28.280
Ich meine, das ist jetzt

01:16:28.280 --> 01:16:30.320
rückt. Sehr, sehr schöne

01:16:30.320 --> 01:16:32.180
Wendung. Aber das ist jetzt wirklich so

01:16:32.180 --> 01:16:34.020
ein Punkt, wo man sieht, okay, jetzt auf einmal

01:16:34.020 --> 01:16:36.180
auf ganz natürliche Weise macht es auf einmal

01:16:36.180 --> 01:16:37.800
Sinn, darüber nachzudenken.

01:16:39.640 --> 01:16:40.140
Ja, das kann

01:16:40.140 --> 01:16:42.120
cost-efficient sein an der Stelle vielleicht.

01:16:43.980 --> 01:16:45.580
Das ist halt mehrere Trade-offs.

01:16:46.660 --> 01:16:48.060
Auch ein anderes Beispiel, nicht

01:16:48.060 --> 01:16:49.960
unbedingt aus IoT, aber meinetwegen, du hast

01:16:49.960 --> 01:16:52.020
eine Java-Anwendung und du

01:16:52.020 --> 01:16:54.200
möchtest auf einmal eine Recommendation-Engine einbauen.

01:16:54.720 --> 01:16:55.980
So, und dann erkennst du, okay,

01:16:56.660 --> 01:16:58.200
das ist im Bereich Machine Learning,

01:16:59.160 --> 01:17:00.300
Das ist in Python mehr

01:17:00.300 --> 01:17:02.400
vertreten. Da hast du in Python eine größere Community.

01:17:02.860 --> 01:17:04.380
Hast du vielleicht auch bessere Lösungen für.

01:17:04.860 --> 01:17:06.240
Dann suchst du dir ein Python-Team aus,

01:17:06.280 --> 01:17:08.060
welches dir dafür ein Model baut, welches dir dafür

01:17:08.060 --> 01:17:10.120
eine API bereitstellt. Kriegst du das

01:17:10.120 --> 01:17:12.140
jetzt unbedingt in deinen Java-Monolithen

01:17:12.140 --> 01:17:14.280
rein oder stellst du deinen Service daneben?

01:17:15.060 --> 01:17:15.820
Nimmst du den hoch

01:17:15.820 --> 01:17:18.040
und versuchst du das vielleicht zu

01:17:18.040 --> 01:17:19.920
integrieren. Das Problem, welches dann natürlich

01:17:19.920 --> 01:17:22.140
aufkommt, wenn du von Monolithen kommst,

01:17:22.260 --> 01:17:24.020
ist, dass du von einer

01:17:24.020 --> 01:17:25.940
konsistenten Struktur unter Umständen in eine

01:17:26.260 --> 01:17:27.680
inkonsistente reinläufst. Ja, du kannst vielleicht

01:17:27.680 --> 01:17:29.520
gar nicht warten. Du musst halt immer wieder auf das externe Team

01:17:29.520 --> 01:17:31.680
zugreifen. Ja, es muss ja nicht mal ein externes Team sein.

01:17:31.740 --> 01:17:33.400
Das kann ja auch ein neues internes Team sein.

01:17:33.920 --> 01:17:35.160
Oder dann halt intern.

01:17:36.040 --> 01:17:37.660
Klar, dieses Problem hast du dir

01:17:37.660 --> 01:17:39.580
jetzt geschaffen. Das ist irgendwo ein selbst geschaffenes

01:17:39.580 --> 01:17:41.580
Problem. Die Frage ist natürlich, komme ich da drum

01:17:41.580 --> 01:17:43.640
herum? Wie ist der Trade-off? Also man hat

01:17:43.640 --> 01:17:45.880
einfach effektiv immer einen Trade-off.

01:17:45.880 --> 01:17:47.900
Die Frage ist immer, was ist das größere

01:17:47.900 --> 01:17:49.640
Übel am Ende? Und

01:17:49.640 --> 01:17:51.520
was bringt mich jetzt schneller vorwärts?

01:17:54.520 --> 01:17:55.800
Ja, insofern, also

01:17:55.800 --> 01:17:57.660
würde ich auch so sagen, also ich denke auch,

01:17:57.680 --> 01:18:19.120
Es gibt gerade, also wenn man halt ganz viele Leute hat und das sehr groß wird, dann wird Microservices immer attraktiver irgendwie. Aber auf der anderen Seite, das ist halt irgendwie jetzt heutzutage oft irgendwie so, das macht man halt so und das ist halt jetzt so ein bisschen, da würde ich mir denken, na ich weiß nicht.

01:18:19.780 --> 01:18:26.000
Und da gibt es ja auch so einen schönen Begriff von David Hanemeyer-Hansen,

01:18:26.000 --> 01:18:32.500
den Rule-and-Rates-Menschen, der versuchte, den Monolith-Begriff aufzuwerten,

01:18:32.540 --> 01:18:35.240
indem er dann noch ein Adjektiv vorgestellt hat.

01:18:35.360 --> 01:18:38.760
Man nennt das jetzt immer Majestic-Monolith sozusagen.

01:18:39.400 --> 01:18:42.820
Weil ich meine, wenn man jetzt halt ein kleines Team hat und irgendwie etwas macht,

01:18:42.900 --> 01:18:47.060
dann ist halt das unter Umständen halt deutlich effizienter.

01:18:47.760 --> 01:18:50.840
auch einfach was bauen willst.

01:18:51.840 --> 01:18:53.300
Also das ist ja auch

01:18:53.300 --> 01:18:54.900
sehr, sehr bekannt. Also wenn du

01:18:54.900 --> 01:18:57.060
jetzt gerade anfängst, dann fängst du natürlich

01:18:57.060 --> 01:18:59.000
nicht mit Microservices an. Also du ziehst

01:18:59.000 --> 01:19:00.940
jetzt von null auf null ein Code hoch, hast

01:19:00.940 --> 01:19:02.840
ein kleines Team, vielleicht sogar ein großes Team, das ist

01:19:02.840 --> 01:19:04.780
komplett egal. Aber eigentlich

01:19:04.780 --> 01:19:06.420
denkt man da erstmal monolithisch nach.

01:19:06.720 --> 01:19:08.780
Einfach um vorwärts zu kommen, um wenig Komplexität

01:19:08.780 --> 01:19:11.000
erstmal zu haben, weil die Komplexität, die kommt erst mit der Zeit.

01:19:11.020 --> 01:19:12.760
Dann bist du halt jedes Mal noch einen neuen Klotz ans Bein irgendwie.

01:19:12.920 --> 01:19:15.020
Oder auch noch weitere Komplexität und weitere

01:19:15.020 --> 01:19:16.920
Abhängigkeiten und Dependencies, wenn du

01:19:16.920 --> 01:19:29.560
Aber irgendwann wird das erfahrungsgemäß dann so groß, dass du deine Prozesse so verlangsamst und so ineinander verstrickst und dass sich die einzelnen Entwickler auf engem Raum so sehr auf die Füße treten, dass du eben drüber nachdenken musst, das Ding aufzubrechen.

01:19:29.560 --> 01:19:52.280
Und das ist dann, haben wir ja auch gesagt, dann migriert man üblicherweise langsam rüber Richtung Microservices. Man lagert einzelne Funktionalitäten aus, schaut, wie sie alleine dastehen und dann bekommst du auch wesentlich mehr Möglichkeiten. Ich meine, ein Vorteil oder Nachteil eines Monolithen ist mitunter auch, dass die nicht immer unbedingt leicht sind, alle Prozesse zu parallelisieren.

01:19:52.280 --> 01:20:15.200
Also du kannst einen Monolithen sehr schwer teilweise parallel laufen lassen auf verschiedenen Instanzen. Du musst es nicht immer unbedingt, aber das ist bei einer großen komplexen Struktur mit vielen verschiedenen States ein bisschen schwieriger und manchmal ist es leichter, wenn du dir dann einzelne Teile da rausnimmst und damit schon mal anfängst, die auszulagern und dann findest du vielleicht so ein Stückchen, wo es sich lohnen würde, das Teil zu parallelisieren.

01:20:15.200 --> 01:20:36.720
Da würdest du dir vielleicht wünschen, okay, ich will meinen Server, jetzt will ich nicht mehr RAM geben. Eigentlich hätte ich lieber einen weiteren dazugebucht für diesen Service, weil es vielleicht günstiger ist, weil es vielleicht leichter zu machen ist. Dann ziehst du einfach parallel noch eine Node hoch. Das wünscht man sich ja auch manchmal. Und das ist zum Beispiel ein Microservice, ist einfach natürlicherweise leichter als ein Monolithen.

01:20:36.720 --> 01:20:40.900
Ja, werden wir ein bisschen

01:20:40.900 --> 01:20:42.240
positiver. Ist auch schön.

01:20:44.340 --> 01:20:44.540
Ja,

01:20:44.860 --> 01:20:46.880
nicht negativ, also es geht halt so ein bisschen

01:20:46.880 --> 01:20:48.800
darum, wann das der Fall ist, an welcher

01:20:48.800 --> 01:20:50.920
Use Case dann wirklich dafür

01:20:50.920 --> 01:20:52.860
sorgt. Also ich denke auch, wenn man das

01:20:52.860 --> 01:20:54.660
dazu bringen will, dass es

01:20:54.660 --> 01:20:55.700
also ein

01:20:55.700 --> 01:20:58.660
Ding, wie das helfen kann, wenn man jetzt

01:20:58.660 --> 01:20:59.900
drüber nachdenkt, denke ich,

01:21:00.900 --> 01:21:02.580
ist halt auch so, wenn man

01:21:02.580 --> 01:21:04.680
einen Microservice aufteilen will, dann ist

01:21:04.680 --> 01:21:06.400
das ja auch ein sehr schöner Anlass, irgendwie da nochmal

01:21:06.400 --> 01:21:08.360
drüber nachzudenken, wie sind denn eigentlich die Schnittstellen

01:21:08.360 --> 01:21:10.700
und so, wie würde man dann modularisieren

01:21:10.700 --> 01:21:12.640
wollen, also sozusagen

01:21:12.640 --> 01:21:14.560
eigentlich würde man dann anfangen

01:21:14.560 --> 01:21:16.120
und sagen, okay, machen wir es doch mal

01:21:16.120 --> 01:21:18.480
modular, also keine Ahnung, ich habe jetzt irgendwie

01:21:18.480 --> 01:21:19.660
einen Moduliten und

01:21:19.660 --> 01:21:22.080
der notifiziert irgendwie User

01:21:22.080 --> 01:21:23.540
für irgendwas und

01:21:23.540 --> 01:21:26.620
jetzt möchte ich das da raustrennen,

01:21:26.740 --> 01:21:28.020
weil irgendwie dieses ganze

01:21:28.020 --> 01:21:30.460
Handling von unterschiedlichen

01:21:30.460 --> 01:21:32.460
Wegen, wie ich User notifiziere,

01:21:33.040 --> 01:21:34.340
ist halt problematisch und

01:21:34.340 --> 01:21:36.260
ich würde das gerne da raustrennen.

01:21:36.260 --> 01:21:37.520
Dann wäre halt

01:21:37.520 --> 01:21:39.340
eine gute, die schlechte Strategie

01:21:39.340 --> 01:21:40.660
wäre halt irgendwie sozusagen

01:21:40.660 --> 01:21:42.480
irgendwie den Funktionen, also irgendwie

01:21:42.480 --> 01:21:45.140
einen JSON- oder HTTP-API irgendwie jetzt

01:21:45.140 --> 01:21:46.720
vor die Funktionen, die die Notifizierung macht,

01:21:46.840 --> 01:21:49.040
zu klemmen und das halt auf einen anderen

01:21:49.040 --> 01:21:51.160
irgendwo anders hinzulegen und dann rufen

01:21:51.160 --> 01:21:53.080
halt aus einem Monolithen die Sachen halt

01:21:53.080 --> 01:21:54.680
dann diese JSON-API auf oder so.

01:21:55.140 --> 01:21:57.180
Das ist leider halt das, was oft gemacht

01:21:57.180 --> 01:21:58.380
wird und das wird dann halt sehr schrecklich.

01:21:58.860 --> 01:22:01.180
Aber was man ja durchaus tun könnte, ist halt

01:22:01.180 --> 01:22:03.140
okay, man versucht das jetzt sauber

01:22:03.140 --> 01:22:05.020
zu machen, man macht halt irgendwie ein Interface, sagt okay,

01:22:05.620 --> 01:22:07.560
so sehen die Notifizierungen aus

01:22:07.560 --> 01:22:09.260
irgendwie und die haben wir

01:22:09.260 --> 01:22:11.380
das klassische Ding, was halt immer benutzt wird

01:22:11.380 --> 01:22:12.480
und jetzt machen wir einfach eine neue

01:22:12.480 --> 01:22:14.940
Implementation, die halt

01:22:14.940 --> 01:22:16.580
über einen Microservice geht

01:22:16.580 --> 01:22:19.440
und wir können

01:22:19.440 --> 01:22:20.360
das halt auch hinterher gucken,

01:22:21.100 --> 01:22:23.100
dann machen wir das Ganze hinterher in Feature-Flag oder so und sagen,

01:22:23.260 --> 01:22:25.240
okay, jetzt schicken wir mal 1% des Traffics halt irgendwie

01:22:25.240 --> 01:22:27.320
über den Microservice, dann gucken wir an, wie sehen

01:22:27.320 --> 01:22:29.220
die Fehler hinterher aus, sind die irgendwie

01:22:29.220 --> 01:22:30.940
mehr geworden oder hat das genau das gleiche getan,

01:22:31.720 --> 01:22:33.460
oder wir schicken es gar nicht raus,

01:22:33.560 --> 01:22:35.560
wir gucken einfach nur, wir schicken es

01:22:35.560 --> 01:22:37.560
an beide? Wie verhält sich das

01:22:37.560 --> 01:22:39.460
denn unter Last und so? Und dann kann man das schön

01:22:39.460 --> 01:22:40.840
denke ich, machen. Aber

01:22:40.840 --> 01:22:43.260
die Voraussetzung ist eigentlich, dass man das halt schon

01:22:43.260 --> 01:22:45.580
ordentlich modularisiert hat, dass man ordentlich Interfaces

01:22:45.580 --> 01:22:46.920
hat, dass man das irgendwie schon

01:22:46.920 --> 01:22:48.560
halbwegs gut strukturiert hat.

01:22:49.740 --> 01:22:50.860
Und ja, dann

01:22:50.860 --> 01:22:53.580
ja. Und das ist vielleicht auch so eine Möglichkeit

01:22:53.580 --> 01:22:55.540
dann an der Stelle nochmal irgendwie drüber nachzudenken,

01:22:55.540 --> 01:22:57.760
wie modularisiert man eigentlich

01:22:57.760 --> 01:22:59.100
ordentlich? Ja, auf jeden Fall.

01:22:59.580 --> 01:23:01.260
Ich meine, auch

01:23:01.260 --> 01:23:03.160
um noch eine positive weitere Sache

01:23:03.160 --> 01:23:04.900
aufzugreifen, die mir gerade in den Sinn kommt.

01:23:05.560 --> 01:23:20.680
Und oft ist es ja so, dass, ich sage jetzt mal ein Datensatz, eine Row, sehr viele verschiedene Prozesse durchläuft, um in die Datenbank zu kommen. Also die wird von verschiedenen Prozessen genutzt, manchmal transformiert, also die wird sehr, sehr oft durchgereicht.

01:23:22.580 --> 01:23:37.740
Das fiel mir jetzt gerade ein, als er ja auch angesprochen hat. Wenn du das jetzt auf einmal anfängst in Microservices aufzuteilen, dann musst du dir natürlich überlegen, okay, wie gestalte ich jetzt den Weg vom Anfang bis zum Ende durch? Und du bekommst auf einmal wesentlich mehr Möglichkeiten.

01:23:38.140 --> 01:23:42.820
Also üblicherweise ist es ja so, dass dieser Prozess in irgendeiner Form sehr, sehr synchron ist.

01:23:42.960 --> 01:23:47.580
Also der geht von A nach B und im Prinzip wartet der Client darauf, dass der hinten angekommen ist.

01:23:47.580 --> 01:23:54.880
So wird es halt sehr oft strukturiert oder die Anwendung wartet auf eine Antwort, die sie nicht unbedingt braucht.

01:23:55.640 --> 01:24:01.600
Und in einer Microservice-Welt kannst du eben sehr, sehr schön darüber überlegen, wie kommunizieren Services allgemein miteinander.

01:24:01.820 --> 01:24:06.360
Und auf einmal stellt man eben fest, dass sie überhaupt nicht synchron miteinander kommunizieren müssen,

01:24:06.500 --> 01:24:09.260
sondern zum Beispiel auch über Queues und Topics

01:24:09.260 --> 01:24:11.100
und dann schickst du da ein Event hin

01:24:11.100 --> 01:24:12.820
und dann ist das so ein Write-Only-Ding.

01:24:13.040 --> 01:24:15.280
Dann schicke ich diesen einen Datensatz an diesen Endpunkt,

01:24:15.760 --> 01:24:16.860
der schreibt es Richtung Topic

01:24:16.860 --> 01:24:18.900
und von diesem Topic kann das dann

01:24:18.900 --> 01:24:23.240
von verschiedenen Microservices gleichzeitig konsumiert werden,

01:24:23.580 --> 01:24:24.840
ohne dass ich jetzt irgendwie

01:24:24.840 --> 01:24:27.320
ein Async bei mir im Code einbauen musste,

01:24:27.760 --> 01:24:29.420
um das darzustellen.

01:24:30.900 --> 01:24:34.020
Und der Nutzer, der kann sofort weitermachen.

01:24:34.160 --> 01:24:35.840
Der muss nicht unbedingt auf die Antwort warten,

01:24:35.900 --> 01:24:37.260
wenn das ein Write-Only-Prozess ist.

01:24:38.880 --> 01:24:40.080
Auch ein Vorteil.

01:24:40.080 --> 01:24:42.080
Oder auch sehr schön teilweise zu designen.

01:24:43.980 --> 01:24:46.020
Ja, wobei ich denken würde,

01:24:46.180 --> 01:24:47.840
also die Voraussetzung wäre, dass man das halt

01:24:47.840 --> 01:24:49.640
erstmal intern gemacht hat, dass man erstmal intern

01:24:49.640 --> 01:24:51.460
irgendwie so eine Art Service-Boost hat

01:24:51.460 --> 01:24:52.200
und

01:24:52.200 --> 01:24:56.020
dann kann man das halt auch vielleicht nach außen verlagern,

01:24:56.220 --> 01:24:57.960
aber ja, also ich meine,

01:24:58.040 --> 01:24:58.820
das ist halt auch sowas,

01:24:59.720 --> 01:25:01.280
ja,

01:25:02.240 --> 01:25:03.760
wo man dann vielleicht mal drüber nachdenken kann,

01:25:03.880 --> 01:25:05.440
wie strukturiert man die

01:25:05.440 --> 01:25:07.420
Applikationen eigentlich so, dass das halt irgendwie

01:25:07.420 --> 01:25:08.580
so funktioniert.

01:25:11.520 --> 01:25:13.120
Ja, weil, ja.

01:25:13.380 --> 01:25:15.560
Es ist halt saukomplex, ne? Also das muss man halt

01:25:15.560 --> 01:25:17.060
einfach sagen. Braucht man diesen

01:25:17.060 --> 01:25:19.420
Service-Bus oder diesen Message-Queue oder diesen Message-Booker

01:25:19.420 --> 01:25:21.400
dann halt. Und wenn man den halt hat, raucht man

01:25:21.400 --> 01:25:22.140
ihn, will man ihn.

01:25:22.360 --> 01:25:25.480
Also, weil das ist ja auch

01:25:25.480 --> 01:25:27.240
die Dependency, die musst du ja auch dann wieder

01:25:27.240 --> 01:25:29.640
mitnehmen. Ja, klar. Ist das eine Dependency?

01:25:29.640 --> 01:25:31.660
Du brauchst die Kompetenz, ne? Das ist halt immer so das Ding

01:25:31.660 --> 01:25:33.360
mit der Komplexität. Aber

01:25:33.360 --> 01:25:55.140
Aber der Service auf der anderen Seite, der ist vielleicht auch unter Umständen einfach austauschbarer. Du kannst ihn relativ problemfrei austauschen, ohne dass du den aktiven Anwendungen affektierst oder du kannst ihn leichter deployen, ohne dass der Service darauf warten muss, dass das Deployment abgeschlossen ist zum Beispiel. Also du hast weniger Downtime dadurch. Also klar, du brauchst ihn nicht. Du kannst auch weiterhin synchron denken.

01:25:55.140 --> 01:26:12.780
Wenn wir jetzt nur in der Welt von Microservices unterwegs sind, dann haben wir auf einmal mehr Möglichkeiten, wie einzelne Services miteinander kommunizieren können und wie wir gewisse Prozesse strukturieren.

01:26:13.560 --> 01:26:14.400
Das verstehe ich nicht genau.

01:26:16.600 --> 01:26:19.220
Was meinst du mit mehr Möglichkeiten zu kommunizieren?

01:26:19.460 --> 01:26:21.200
Ja, die Service-Bus

01:26:21.200 --> 01:26:21.900
oder die Queues

01:26:21.900 --> 01:26:24.940
beziehungsweise Topics und Queues

01:26:24.940 --> 01:26:26.420
sind natürlich jetzt eine Möglichkeit mehr.

01:26:26.960 --> 01:26:28.580
Die werden einer Anwendung

01:26:28.580 --> 01:26:30.200
Du kannst ja auch

01:26:30.200 --> 01:26:31.940
in die Anwendung einbauen.

01:26:32.220 --> 01:26:33.700
Ja, aber ist das immer so geil?

01:26:34.580 --> 01:26:36.760
Ja, also ich würde sagen, das ist halt so ein bisschen die Voraussetzung

01:26:36.760 --> 01:26:38.860
dafür, dass man das überhaupt dann auftrennen kann,

01:26:39.040 --> 01:26:40.600
weil, oder ich sag mal,

01:26:40.780 --> 01:26:42.760
ich kenne, ist halt die Frage,

01:26:42.860 --> 01:26:44.680
also ich kenne das halt so, dass man das intern in der Applikation

01:26:44.680 --> 01:26:46.660
vor allen Dingen macht, also dass man halt dann aufteilt

01:26:46.660 --> 01:26:48.740
die Dinge, die man tut, teilt man halt

01:26:48.740 --> 01:26:50.600
auch in Commands, Events

01:26:50.600 --> 01:26:52.800
und vielleicht Dokumente gibt es

01:26:52.800 --> 01:26:55.140
halt auch. Es gibt diese ganzen Enterprise-Service-Bus

01:26:55.140 --> 01:26:56.800
irgendwie, weiß ich nicht, irgendwas Patterns.

01:26:56.940 --> 01:26:58.460
Es ist halt die Frage, ob man das braucht. Keine Ahnung.

01:26:59.560 --> 01:27:01.040
Ich habe letztens mich da so ein bisschen

01:27:01.040 --> 01:27:02.760
mit beschäftigt, weil ich mich einfach mal interessiert habe,

01:27:03.700 --> 01:27:04.560
wie man denn sowas baut.

01:27:04.740 --> 01:27:06.600
Da gibt es ja auch, das Buch erwähne ich irgendwie auch in jeder

01:27:06.600 --> 01:27:08.920
Episode irgendwie. Oh, hier

01:27:08.920 --> 01:27:10.900
liegt es rum. Architecture Patterns with Python.

01:27:11.720 --> 01:27:12.980
Die bauen halt, die fangen halt

01:27:12.980 --> 01:27:15.000
an und mit irgendwie auch, das ist auch glaube ich

01:27:15.000 --> 01:27:16.680
ein Allokations,

01:27:17.020 --> 01:27:18.940
also das, womit die sich beschäftigen, ist halt sozusagen

01:27:18.940 --> 01:27:22.640
Bestellungen

01:27:22.640 --> 01:27:24.740
irgendwelchen Lagerbeständen zuordnen,

01:27:24.840 --> 01:27:26.880
sozusagen. Und die fangen halt an, naiv mit so einer

01:27:26.880 --> 01:27:29.020
Flask-Applikationen und bauen das dann halt immer weiter um,

01:27:29.100 --> 01:27:30.880
sodass dann am Schluss bleibt halt auch so

01:27:30.880 --> 01:27:32.300
ein Service-Bus übrig und

01:27:32.300 --> 01:27:34.600
das könnte man dann theoretisch auch in

01:27:34.600 --> 01:27:36.740
Microservices dann halt alles

01:27:36.740 --> 01:27:37.920
auslagern, was man da so tut.

01:27:38.860 --> 01:27:40.780
Aber das eigentlich, würde ich

01:27:40.780 --> 01:27:42.660
sagen, so ein bisschen die Voraussetzung dafür, dass man das überhaupt

01:27:42.660 --> 01:27:44.640
kann, ist, dass man es intern schon so macht.

01:27:45.000 --> 01:27:45.900
Also dass man halt intern schon,

01:27:46.720 --> 01:27:48.680
oder ich weiß es nicht genau, aber wenn man

01:27:48.680 --> 01:27:50.420
das jetzt von außen dran,

01:27:51.180 --> 01:27:52.540
aber nochmal zu dem,

01:27:52.760 --> 01:27:54.760
warum macht man das überhaupt mit diesen Queues und so,

01:27:54.940 --> 01:27:56.540
denke ich, der Vorteil ist halt einfach, wenn du

01:27:56.540 --> 01:27:58.960
wenn du HTTP oder JSON-RPs hast,

01:27:59.260 --> 01:28:01.460
dann machst du halt jedes Mal zum Beispiel so ein TLS-Handshake

01:28:01.460 --> 01:28:02.760
oder sowas. Das ist natürlich extrem

01:28:02.760 --> 01:28:05.220
verbraucht in einer CPU.

01:28:06.400 --> 01:28:07.620
Du kannst ja auch ein Socket aufhaben.

01:28:08.720 --> 01:28:08.900
Oder so.

01:28:09.000 --> 01:28:10.380
Wie bei HTTP?

01:28:11.080 --> 01:28:13.060
Nein, nein. Einfach kein HTTP,

01:28:13.220 --> 01:28:14.800
sondern du hast halt ein Socket auf irgendwo in der Verbindung.

01:28:15.880 --> 01:28:17.100
Ja, okay. Und wie sicherst du die

01:28:17.100 --> 01:28:19.080
irgendwie ab und welchen Standard?

01:28:19.520 --> 01:28:21.300
Wie machst du das? Keine Ahnung. Also wie WebSocket

01:28:21.300 --> 01:28:23.200
genau und drunter funktioniert. Aber der hat ja am Anfang

01:28:23.200 --> 01:28:25.200
beispielsweise auch seinen Handshake, aber der bleibt

01:28:25.200 --> 01:28:27.040
halt offen, der muss dann nicht jedes Mal den neuen Handshake machen, oder?

01:28:27.480 --> 01:28:29.300
Ja, bei HTTP geht das nicht.

01:28:30.680 --> 01:28:31.100
Bei HTTP

01:28:31.100 --> 01:28:32.900
gibt es immer nur Request-Response, das war auch so.

01:28:32.900 --> 01:28:35.120
Genau, ja, aber ich kann jetzt einen Token aufmachen, wenn ich jetzt

01:28:35.120 --> 01:28:37.120
auch so ein Queue-Ding habe, beispielsweise.

01:28:37.400 --> 01:28:38.780
Genau, das ist der Vorteil bei der Queue,

01:28:38.920 --> 01:28:41.180
da steht eine Verbindung und die bleibt halt und du kannst

01:28:41.180 --> 01:28:43.200
halt mehr Sachen drüber schicken, genau. Das ist halt der Riesenvorteil.

01:28:43.280 --> 01:28:45.240
Ja, genau, aber ich verstehe jetzt nicht, wo der Unterschied ist,

01:28:45.260 --> 01:28:46.700
also warum brauche ich dafür einen Microservice?

01:28:47.020 --> 01:28:49.060
Also das hat für mich jetzt nicht so viel miteinander zu tun.

01:28:49.760 --> 01:28:50.980
Nee, aber die Frage ist jetzt,

01:28:50.980 --> 01:28:52.940
wenn du jetzt Microservices hast,

01:28:53.040 --> 01:28:54.140
wie verbindest du die miteinander?

01:28:55.200 --> 01:28:57.120
Oder vielleicht habe ich die Frage einfach nicht verstanden.

01:28:57.220 --> 01:28:59.080
Ich dachte, das wäre die Frage, warum nimmt man denn da so

01:28:59.080 --> 01:29:01.060
einen Bus oder so eine Queue? Warum nimmt man nicht

01:29:01.060 --> 01:29:02.060
einfach HTC oder so?

01:29:02.340 --> 01:29:04.900
Die Frage wäre, also wenn ich jetzt so einen Bus nehme, also warum

01:29:04.900 --> 01:29:06.920
mache ich das bei Microsoft? Also warum mache ich das nicht trotzdem

01:29:06.920 --> 01:29:08.000
in meinem Monolithen oder so?

01:29:08.100 --> 01:29:10.580
Ja, genau, da würde ich anfangen.

01:29:10.700 --> 01:29:12.740
Ich würde so anfangen, dass man das zuerst so baut,

01:29:12.880 --> 01:29:14.200
dass man das intern benutzen kann.

01:29:14.200 --> 01:29:15.520
Also meine Meinung ist, es kann halt

01:29:15.520 --> 01:29:17.460
schon sein, dass man sowas braucht.

01:29:19.080 --> 01:29:20.140
Die Frage ist, ob man es

01:29:20.140 --> 01:29:21.280
in einem Monolithen will, ne?

01:29:22.780 --> 01:29:23.300
Warum nicht?

01:29:24.100 --> 01:29:26.280
Also ich persönlich hatte jetzt noch nicht

01:29:26.280 --> 01:29:28.120
das Anliegen oder das Verlangen, dass ich in einem

01:29:28.120 --> 01:29:30.320
Monolithen mir sowas gewünscht hätte.

01:29:31.020 --> 01:29:32.500
Weil die Wege dort dann natürlicherweise

01:29:32.500 --> 01:29:33.020
kürzer sind.

01:29:34.180 --> 01:29:35.860
Na gut, also kannst du halt einfach jetzt

01:29:35.860 --> 01:29:38.320
theoretisch noch einen Container zu deinem Deployment

01:29:38.320 --> 01:29:40.280
spawnen, wo halt irgendwie so ein Kafka oder

01:29:40.280 --> 01:29:41.300
ein Redis oder irgendwas läuft.

01:29:42.280 --> 01:29:42.940
Nee, nee, das

01:29:42.940 --> 01:29:45.800
brauchst du ja nicht. Wenn du es intern machst, brauchst du das ja nicht.

01:29:45.860 --> 01:29:48.200
Das ist einfach nur ein Funktionsaufruf. Da ist deine Queue einfach zum Beispiel

01:29:48.200 --> 01:29:50.360
in Python ist das halt einfach nur eine Queue-Modell.

01:29:50.400 --> 01:29:50.540
Ja, okay.

01:29:52.600 --> 01:29:54.460
vom Queue über Queue sozusagen oder so

01:29:54.460 --> 01:29:56.340
und dann machst du halt, solange irgendwas

01:29:56.340 --> 01:29:58.420
in der Queue drin ist, machst du halt irgendwie, rufst du Funktionen auf

01:29:58.420 --> 01:29:59.940
und das war's. Das ist auch nicht, ja.

01:30:00.360 --> 01:30:01.200
Kann man durchaus machen.

01:30:01.480 --> 01:30:04.060
Habe ich jetzt zum ersten Mal von tatsächlich,

01:30:04.240 --> 01:30:06.080
dass das so ein Python-Ding ist.

01:30:06.100 --> 01:30:07.580
Ja, genau. Queue.

01:30:07.580 --> 01:30:09.760
Es hat aber nichts mit Netzwerkverbindungen oder so.

01:30:09.760 --> 01:30:10.300
Nein, nein, nein, genau.

01:30:10.600 --> 01:30:13.180
Ist das dann einfach irgendwie so ein State, der existiert

01:30:13.180 --> 01:30:14.960
global und...

01:30:14.960 --> 01:30:15.300
Ja, genau.

01:30:16.680 --> 01:30:17.080
Cool.

01:30:17.480 --> 01:30:21.840
Man kann diese Muster ja durchaus auch einfach so...

01:30:21.840 --> 01:30:25.460
Deswegen meine ich, wie man die Struktur aufteilt

01:30:25.460 --> 01:30:27.540
und die Architektur von einem Ding baut,

01:30:28.080 --> 01:30:30.440
das kann man ja auch schon vorher richtig machen quasi.

01:30:30.640 --> 01:30:32.360
Und dann kann man es halt auch aufteilen.

01:30:32.500 --> 01:30:33.760
Oder es ist sehr einfach, das aufzuteilen.

01:30:33.880 --> 01:30:35.580
Während wenn man jetzt einen Monolithen hat,

01:30:35.920 --> 01:30:37.180
und das ist tatsächlich, ich fürchte,

01:30:37.440 --> 01:30:39.840
das ist halt das, was ich in der Praxis oft sehe.

01:30:39.840 --> 01:30:43.740
Dass Leute halt eigentlich in so einer Situation sind,

01:30:43.800 --> 01:30:45.720
sie haben einen Big Ball of Mud,

01:30:46.020 --> 01:30:47.980
der halt irgendwie kompliziert und komisch ist

01:30:47.980 --> 01:30:48.940
und wo sie nicht weiterkommen.

01:30:50.280 --> 01:30:52.180
Und jetzt suchen sie nach irgendeiner Lösung für dieses Problem.

01:30:52.660 --> 01:30:53.840
Und dann kommen sie auf Microsoft

01:30:53.840 --> 01:30:55.580
und dann stürzen sie auf Microsoft und sagen so,

01:30:55.620 --> 01:30:56.820
das ist die Lösung für mein Problem.

01:30:56.820 --> 01:30:58.980
Ich hänge weiter vorne.

01:30:59.300 --> 01:31:00.900
Ich will wissen, was passiert denn mit dieser

01:31:00.900 --> 01:31:02.320
Queue, wenn der Service eine Downtime hat?

01:31:03.080 --> 01:31:04.320
Nein, das ist einfach nur ein Prozess.

01:31:04.780 --> 01:31:06.340
Das ist einfach ein Prozess. Also die anderen, die

01:31:06.340 --> 01:31:08.340
funktionieren irgendwie weiter, da ist dann irgendwie, weiß ich nicht,

01:31:08.380 --> 01:31:09.920
läuft in einem separaten Thread, in einem gleichen.

01:31:10.740 --> 01:31:12.900
Ja, alles in einem Thread, im gleichen Prozess.

01:31:15.020 --> 01:31:18.860
Das einzige, was das halt sozusagen bringt, ist,

01:31:19.600 --> 01:31:21.740
ich die Sachen halt sauber voneinander getrennt habe.

01:31:21.860 --> 01:31:23.740
Ich mache halt auch irgendwie, ich mache halt immer, wenn ich

01:31:23.740 --> 01:31:25.660
irgendwas schreiben möchte, mache ich halt

01:31:25.660 --> 01:31:27.620
einen Command und ich habe halt dann meine

01:31:27.620 --> 01:31:29.000
Event-Händler, die alles mögliche machen.

01:31:29.360 --> 01:31:31.720
Zum Beispiel habe ich halt einen Event-Händler, der schickt

01:31:31.720 --> 01:31:33.500
das Event dann auf den Web-Socket raus für

01:31:33.500 --> 01:31:35.620
irgendeinen Client, einen anderen Event-Händler,

01:31:36.200 --> 01:31:37.540
der tritt irgendwie

01:31:37.540 --> 01:31:39.220
einen Prozess los, ein anderer, so.

01:31:39.840 --> 01:31:41.440
Und das kann ich ja, aber das ist alles

01:31:41.440 --> 01:31:43.420
nur Funktionsaufrufe, die nacheinander passieren.

01:31:43.620 --> 01:31:44.740
Das ist aber alles im gleichen Prozess.

01:31:45.280 --> 01:31:47.400
Okay, also für mich so zum Verständnis, vielleicht

01:31:47.400 --> 01:31:49.500
ergibt sich ja dann so die Möglichkeit, dass wir alle

01:31:49.500 --> 01:31:50.920
erkennen, okay, wir brauchen unbedingt Kafka.

01:31:52.780 --> 01:31:53.140
Yay!

01:31:54.380 --> 01:31:55.700
Nein, aber nur

01:31:55.700 --> 01:31:57.420
damit ich das verstehe, nehmen wir jetzt mal an,

01:31:57.460 --> 01:31:58.920
wir sind jetzt in der Django-Anwendung unterwegs

01:31:58.920 --> 01:32:01.240
und wir schicken ein Request rein

01:32:01.240 --> 01:32:03.040
und der kommt jetzt in die Queue.

01:32:03.520 --> 01:32:05.200
Die erste Frage ist, was passiert beim User?

01:32:05.300 --> 01:32:07.240
Bekommt er sofort die Antwort zurück oder wartet

01:32:07.240 --> 01:32:09.060
er darauf, dass der Prozess von der Queue komplett

01:32:09.060 --> 01:32:09.880
verarbeitet wurde?

01:32:09.880 --> 01:32:11.880
Der bekommt sofort, also da ist es so,

01:32:12.260 --> 01:32:15.140
der bekommt sofort eine Antwort zurück

01:32:15.140 --> 01:32:19.160
und sozusagen

01:32:19.160 --> 01:32:21.060
die Event-Händler bearbeiten das dann halt

01:32:21.060 --> 01:32:23.000
später weiter. Okay, die bearbeiten das später

01:32:23.000 --> 01:32:24.920
weiter, das heißt, wenn jetzt der nächste User kurz

01:32:24.920 --> 01:32:27.000
danach, bevor das alles abgearbeitet wurde,

01:32:27.080 --> 01:32:27.760
wieder ein Request reinsteckt.

01:32:27.760 --> 01:32:30.880
Was man schon zurückbekommt, ist, dass das

01:32:30.880 --> 01:32:32.520
Command durchgegangen ist.

01:32:33.200 --> 01:32:34.600
Also sozusagen man wartet bis, also

01:32:34.600 --> 01:32:36.560
ein Request kommt rein

01:32:36.560 --> 01:32:38.960
und dann erzeugt man ein Command,

01:32:39.620 --> 01:32:41.020
sagt irgendwie Handle Command

01:32:41.020 --> 01:32:43.200
oder Handle Service Bus

01:32:43.200 --> 01:32:44.600
Handle und

01:32:44.600 --> 01:32:47.120
zurückgekommen ist, kann man sicher sein, die Transaktion

01:32:47.120 --> 01:32:49.040
ist durch, aber dann sind noch nicht alle

01:32:49.040 --> 01:32:50.840
Events bearbeitet worden. Okay, dann sind noch nicht alle Events

01:32:50.840 --> 01:32:52.800
bearbeitet worden. Und dann schickt man einen User zurück,

01:32:52.880 --> 01:32:55.080
okay, das ist jetzt durchgegangen. Okay, und jetzt kommt der nächste

01:32:55.080 --> 01:32:57.100
User an, bevor alle Events abgearbeitet wurden.

01:32:57.960 --> 01:32:59.480
Und der kann dann unbekümmert

01:32:59.480 --> 01:33:01.300
das auch reinschicken, weil die Events

01:33:01.300 --> 01:33:03.120
im Hintergrund noch parallel abgearbeitet werden.

01:33:04.360 --> 01:33:05.440
Okay, das heißt, das geht.

01:33:05.560 --> 01:33:07.380
Und was passiert, wenn der Service

01:33:07.380 --> 01:33:09.460
jetzt crasht, bevor alle Events abgearbeitet

01:33:09.460 --> 01:33:11.040
wurden? Wenn das ganze Ding

01:33:11.040 --> 01:33:11.680
crasht, dann ist es vorbei.

01:33:12.580 --> 01:33:13.560
Das ist einfach ein Prozess.

01:33:14.600 --> 01:33:38.560
Dann ist es weg, ja. Das heißt, wir haben jetzt nicht irgendwie, okay. Ja gut, aber wir brauchen irgendwas. Also wenn ich mich jetzt dafür entscheiden würde, dass es unglaublich wichtig ist, weil dieser Prozess vielleicht eine Minute dauert, weil da irgendwie verschiedene Stages durchläuft. Es gibt Gründe. Keine Ahnung, du hast eine unglaublich langsame API irgendwo dranhängen. Die braucht einfach ewig lang zum Antworten, aber der Nutzer, der soll nicht so lange auf diese API warten müssen, also kriegt er sofort die Antwort zurück.

01:33:38.560 --> 01:33:40.280
wir haben das jetzt in der Queue, das wartet,

01:33:40.440 --> 01:33:42.560
jetzt stürzt der Service ab, aber eigentlich will ich

01:33:42.560 --> 01:33:44.360
unbedingt diese Antwort haben, weil das meinetwegen

01:33:44.360 --> 01:33:46.600
eine Transaktion ist und der Nutzer gerade was gekauft hat.

01:33:46.800 --> 01:33:48.600
Du kannst das ja in der Datenbank kurz wegschreiben

01:33:48.600 --> 01:33:50.500
oder so. Du kannst ja sagen,

01:33:50.860 --> 01:33:52.220
du schreibst es direkt weg in die Datenbank,

01:33:52.540 --> 01:33:54.400
gibst der Nutzer die Antwort und hängst es dann in die Queue

01:33:54.400 --> 01:33:56.060
und dass der aus der Datenbank das dann nimmt.

01:33:56.520 --> 01:33:58.460
Und wenn das dann abstürzt, der Prozessquestion,

01:33:58.480 --> 01:33:59.980
hast du ja in der Datenbank noch die Sachen stehen.

01:34:00.060 --> 01:34:02.280
Du kannst ja einen Fleck dran machen, ist dann fertig oder nicht.

01:34:02.400 --> 01:34:04.520
Ja, aber es ist halt irgendwie

01:34:04.520 --> 01:34:05.460
hacky gefühlt.

01:34:07.680 --> 01:34:08.120
Also

01:34:08.120 --> 01:34:10.000
ich weiß nicht, ob man damit wirklich das Problem

01:34:10.000 --> 01:34:11.960
löst, aber erstmal wird es

01:34:11.960 --> 01:34:14.100
dann so sein, dass der Prozess weg ist

01:34:14.100 --> 01:34:15.820
und dass man

01:34:15.820 --> 01:34:16.960
dort, wenn man diesen

01:34:16.960 --> 01:34:20.040
Wenn du es weggeschrieben hast, dann hast

01:34:20.040 --> 01:34:21.900
du zwar noch nicht die Queue durch, aber du hast halt

01:34:21.900 --> 01:34:24.220
den Daten, dass der gekommen ist. Aber das macht natürlich

01:34:24.220 --> 01:34:26.000
den Prozess dann minimal

01:34:26.000 --> 01:34:27.920
langsamer, weil ich erst was in die Datenbank schreiben

01:34:27.920 --> 01:34:29.880
muss. Da hast du auch nicht lang. Ja, aber vielleicht doch

01:34:29.880 --> 01:34:31.320
zu lang. Na, glaube ich.

01:34:31.600 --> 01:34:33.200
Also wenn du irgendwie lange, Sekundenweite...

01:34:33.200 --> 01:34:36.020
Ich habe gerade 30 Millionen Nutzer, die da draufschreiben

01:34:36.020 --> 01:34:37.560
und dann... Ja gut, aber

01:34:37.560 --> 01:34:39.260
das soll da nicht so lange dauern.

01:34:40.160 --> 01:34:41.900
Aber wie gesagt, ich

01:34:41.900 --> 01:34:43.720
fühle mich dabei dann so ein bisschen

01:34:43.720 --> 01:34:45.740
unwohl, dass ich das innerhalb dieses Python-Prozesses

01:34:45.740 --> 01:34:47.100
habe, weil ich eben

01:34:47.100 --> 01:34:49.800
sicher gehen muss, dass

01:34:49.800 --> 01:34:51.660
ich diese Information

01:34:51.660 --> 01:34:53.040
nicht verliere, wenn ich sie denn nicht

01:34:53.040 --> 01:34:55.560
verlieren muss. Und da hilft dann natürlich

01:34:55.560 --> 01:34:56.500
irgendwie so ein...

01:34:56.500 --> 01:34:58.860
Also, ja,

01:34:58.980 --> 01:35:01.420
ich würde ja sagen,

01:35:01.500 --> 01:35:02.660
man kann das ja auch mal, aber ich meine,

01:35:04.340 --> 01:35:05.800
ja, also

01:35:05.800 --> 01:35:06.660
ja,

01:35:07.120 --> 01:35:11.280
Ich würde eher

01:35:11.280 --> 01:35:13.240
denken, also wie man das dann macht, ist letztlich

01:35:13.240 --> 01:35:15.580
eigentlich, ist ja dann keine Architekturfrage

01:35:15.580 --> 01:35:17.160
mehr, ob man dann auch wieder einen Kafka verwendet oder

01:35:17.160 --> 01:35:19.440
Revit und Q oder nochmal was anderes

01:35:19.440 --> 01:35:21.320
ist ja letztlich nicht einfach nur

01:35:21.320 --> 01:35:21.980
interessant gerade.

01:35:23.720 --> 01:35:25.360
Wie gesagt, das war mir

01:35:25.360 --> 01:35:26.700
jetzt neu. Ich meine, da tun sich viele

01:35:26.700 --> 01:35:29.100
Fragen auf, die mit dem eigentlichen Thema nichts zu tun haben.

01:35:29.360 --> 01:35:30.580
Also wie gehe ich mit Exception um?

01:35:30.920 --> 01:35:32.180
Azure Service Bus hat zum Beispiel

01:35:32.180 --> 01:35:35.280
Exception Dead Letter

01:35:35.280 --> 01:35:35.520
Q.

01:35:36.940 --> 01:35:38.700
Das muss ich mir natürlich relativ umständlich

01:35:38.700 --> 01:35:39.360
dann da reinbauen.

01:35:40.200 --> 01:35:42.580
Also ich brauche ein vergleichsweise umständlicheres

01:35:42.580 --> 01:35:44.320
Fehlerhandling, wenn ich das dann auch irgendwie

01:35:44.320 --> 01:35:46.000
über diese Queues abbauen möchte.

01:35:46.560 --> 01:35:47.820
Das kann ich mir natürlich anders ein bisschen leichter machen.

01:35:47.840 --> 01:35:50.400
Dann brauchst du für jeden Microservice eigentlich so ein eigenes Fehlerhandling auch.

01:35:51.120 --> 01:35:53.000
Ja, also wenn du

01:35:53.000 --> 01:35:54.920
ja, oder ein Standard,

01:35:56.120 --> 01:35:57.160
wie man es dann am Ende

01:35:57.160 --> 01:35:59.040
sieht. Also klar, das bringt

01:35:59.040 --> 01:36:00.600
einen dann wieder zurück zu den Microservices

01:36:00.600 --> 01:36:02.880
und wieder zu einem generellen

01:36:02.880 --> 01:36:04.460
Problem. Und das Fehlerhandling

01:36:04.460 --> 01:36:06.940
entscheidet dann der Service selbst oder das Team

01:36:06.940 --> 01:36:07.460
in dem Fall.

01:36:08.760 --> 01:36:10.200
Beim Konsumenten meinte ich jetzt.

01:36:11.160 --> 01:36:13.200
Ja, wenn du eh die Dependency

01:36:13.200 --> 01:36:14.980
hast, dass du irgendwie einen hast, der das konsumieren

01:36:14.980 --> 01:36:16.760
will und dann halt Sachen macht. Gut, das viele

01:36:16.760 --> 01:36:18.700
Hände brauchst du so oder so, je nachdem, was da drinsteckt, aber

01:36:18.700 --> 01:36:21.280
du hast natürlich, meiner Meinung nach,

01:36:21.320 --> 01:36:23.260
wenn du Microservices hast, eine größere

01:36:23.260 --> 01:36:25.120
Anzahl an Fehlerquellen.

01:36:25.120 --> 01:36:26.900
Es wird halt viel komplizierter. Du musst dir halt

01:36:26.900 --> 01:36:28.760
über all diese Dinge Gedanken machen im einzelnen Prozess.

01:36:28.900 --> 01:36:30.400
Musst du das nicht. Du hast das alles egal.

01:36:31.220 --> 01:36:32.780
Machst du halt ganz normales Exception Handling

01:36:32.780 --> 01:36:35.000
und da brauchst du all diese Dinge nicht.

01:36:36.760 --> 01:36:38.740
Was passiert denn mit retry und gucken?

01:36:39.060 --> 01:36:40.560
Das ist auch da und bleibst du noch.

01:36:41.040 --> 01:36:43.040
War der nur kurz weg? War die Verbindung weg? War der Server weg?

01:36:43.760 --> 01:36:48.620
Ja, aber ich meine, wenn sich darum jeder Service selbst kümmern muss,

01:36:48.700 --> 01:36:50.800
dann ist es natürlich auch wieder nicht so kompliziert.

01:36:51.100 --> 01:36:53.200
Also wenn ich immer nur auf meinen Punkt gucke

01:36:53.200 --> 01:36:55.580
und ich schaue, welche Möglichkeiten gibt es.

01:36:55.680 --> 01:36:58.000
Also im gesamten Prozess gibt es immer mehr Fehlerpunkte.

01:36:58.260 --> 01:37:00.980
Also du glaubst einfach dem, was dann da in deiner Queue steht.

01:37:01.940 --> 01:37:02.560
Ich beispielsweise.

01:37:03.180 --> 01:37:04.720
Ja, das muss natürlich validiert werden.

01:37:04.900 --> 01:37:06.040
Und wenn da was Falsches drinsteht,

01:37:06.120 --> 01:37:07.640
dann weiß ich, dass irgendwas vorher falsch war.

01:37:07.860 --> 01:37:10.140
Klar, diese Art von Debugging, die ist schon super schwer.

01:37:10.720 --> 01:37:12.240
Weiß das, dass da was Falsches drinsteht?

01:37:12.340 --> 01:37:12.440
Okay.

01:37:12.960 --> 01:37:14.300
Also, weiß ich nicht.

01:37:14.300 --> 01:37:15.400
Wenn wir jetzt zum Beispiel,

01:37:15.720 --> 01:37:21.660
wir erwarten jetzt ein bestimmtes JSON in deiner Queue.

01:37:21.980 --> 01:37:23.820
Und dieses JSON entspricht nicht dem richtigen Format,

01:37:23.880 --> 01:37:25.340
dann weiß ich, dass da vorher irgendwas falsch war.

01:37:25.600 --> 01:37:27.360
Okay, dann kann es nicht passieren dürfen,

01:37:27.420 --> 01:37:28.200
dass das da reingeschrieben werden kann.

01:37:28.220 --> 01:37:29.980
Genau, das ist jetzt so ein sehr, sehr einfacher Fehler.

01:37:30.060 --> 01:37:30.780
Es kann natürlich sein,

01:37:30.980 --> 01:37:33.920
dass ein falscher Nutzer irgendwie in deinem Datensatz drinsteht

01:37:33.920 --> 01:37:35.660
und dein Service kann das nicht überprüfen.

01:37:35.800 --> 01:37:38.400
Aber da sind wir dann wieder bei der Herausforderung

01:37:38.400 --> 01:37:40.020
des Datenmanagements.

01:37:40.200 --> 01:37:42.200
Also wie gestalte ich das richtig? Wie gestalte ich das gut?

01:37:42.800 --> 01:37:44.420
Wie kann ich solche Sachen vermeiden?

01:37:44.500 --> 01:37:46.180
Wie synke ich vielleicht meine verschiedenen Datenbanken?

01:37:46.480 --> 01:37:48.140
Aber das ist dann wieder so ein eigenes Problemchen.

01:37:48.640 --> 01:37:49.100
Oder großes Problem.

01:37:49.100 --> 01:37:50.200
Ja, aber das ist wie bei Dependencies.

01:37:50.940 --> 01:37:53.300
Ja, wie sagt man so schön?

01:37:53.380 --> 01:37:54.400
Irgendeinem Tod muss man sterben.

01:37:54.880 --> 01:37:57.280
Also es ist halt leider so.

01:37:57.280 --> 01:37:58.640
Aber die Frage ist halt,

01:37:58.860 --> 01:38:00.840
ich glaube, das hat halt so ein Overhead,

01:38:01.540 --> 01:38:03.040
wenn man mit vielen, vielen Microstores arbeitet

01:38:03.040 --> 01:38:04.740
und den muss man irgendwie handeln können

01:38:04.740 --> 01:38:06.940
und den trade-offen gegen den

01:38:06.940 --> 01:38:09.200
Overhead von, ist es jetzt kompliziert

01:38:09.200 --> 01:38:11.260
oder

01:38:11.260 --> 01:38:13.040
die Sachen weiterzubauen

01:38:13.040 --> 01:38:14.920
in diesem Monolithen, weil halt dann es

01:38:14.920 --> 01:38:17.180
schwierig wird, das zu beherrschen und das ist vielleicht so ein bisschen

01:38:17.180 --> 01:38:18.800
Ja, es ist immer so ein bisschen

01:38:18.800 --> 01:38:20.440
trickreich, aber

01:38:20.440 --> 01:38:22.640
vielleicht, ja,

01:38:23.220 --> 01:38:24.920
ich frage mich immer, ob das jetzt

01:38:24.920 --> 01:38:26.600
wirklich schlimm ist. Klar, als Unternehmen

01:38:26.600 --> 01:38:28.560
möchte ich natürlich so viel

01:38:28.560 --> 01:38:30.800
wie möglich wissen, aber als einzelner Entwickler,

01:38:30.960 --> 01:38:32.560
wie ich jetzt einer bin, interessiert mich das eigentlich

01:38:32.560 --> 01:38:34.620
gar nicht so. Also es ist mir

01:38:34.620 --> 01:38:36.640
eigentlich relativ egal, ob ich jetzt in einem Monolithen

01:38:36.640 --> 01:38:37.980
entwickle oder in einem Microservice.

01:38:38.420 --> 01:38:40.600
Das ist auch so das, was meine persönliche Erfahrung

01:38:40.600 --> 01:38:40.880
ist.

01:38:42.540 --> 01:38:44.220
Ich komme in ein Projekt rein, wo meinetwegen

01:38:44.220 --> 01:38:46.480
Microservices drin sind und dann bin ich

01:38:46.480 --> 01:38:48.500
damit total fein. Dann gucke ich auf meine Sachen.

01:38:48.600 --> 01:38:50.220
Klar, ich habe mehr Abstimmungen mit anderen Leuten,

01:38:50.760 --> 01:38:51.740
aber am Ende ist das

01:38:51.740 --> 01:38:54.580
auch nur eine gefühlte

01:38:54.580 --> 01:38:56.160
Sache, um die sozusagen

01:38:56.160 --> 01:38:58.420
so kompliziert, wie wir hier gerade

01:38:58.420 --> 01:39:00.340
reden, ist das in der Realität

01:39:00.340 --> 01:39:00.760
gar nicht.

01:39:02.720 --> 01:39:04.320
Also, wenn du

01:39:04.320 --> 01:39:06.060
jetzt überlegst, ich will jetzt zum Microservices

01:39:06.060 --> 01:39:08.500
rüber migrieren, ich habe einen funktionierenden Monolithen,

01:39:08.560 --> 01:39:09.980
will ich das eigentlich, klar, für dich

01:39:09.980 --> 01:39:12.340
ist das super kompliziert.

01:39:13.460 --> 01:39:14.220
Aber für mich,

01:39:14.320 --> 01:39:16.540
der als Neuer vielleicht in ein Projekt reinkommt,

01:39:16.920 --> 01:39:18.300
noch nicht alles kennt, noch nicht weiß,

01:39:18.380 --> 01:39:19.560
wie es zu diesem Punkt kam,

01:39:20.240 --> 01:39:22.340
ist der Umstand Microservice gar nicht

01:39:22.340 --> 01:39:23.300
mal so das große Thema.

01:39:25.680 --> 01:39:26.080
Und

01:39:26.080 --> 01:39:28.220
man lernt halt wirklich

01:39:28.220 --> 01:39:30.100
auch viele Dinge, weil man sich

01:39:30.100 --> 01:39:32.540
mit Sachen intensiver auseinandersetzen

01:39:32.540 --> 01:39:34.220
muss, mit denen man sich vorher nicht so wirklich intensiv

01:39:34.220 --> 01:39:36.140
auseinandergesetzt hat, wie zum Beispiel Logging,

01:39:36.340 --> 01:39:37.760
wie zum Beispiel Metric Monitoring,

01:39:38.440 --> 01:39:39.760
wie zum Beispiel...

01:39:39.760 --> 01:39:41.740
Ja, aber das kann auch wieder eine Gefahr sein.

01:39:42.100 --> 01:39:42.980
Ja, okay, komm.

01:39:43.920 --> 01:39:45.900
Aber für den Kunden bringt das ja jetzt erstmal nichts.

01:39:46.300 --> 01:39:47.840
Aber gut, ja, ich verstehe schon.

01:39:48.920 --> 01:39:49.900
Das, was ich

01:39:49.900 --> 01:39:51.720
vielleicht finde, ist, dass wir relativ

01:39:51.720 --> 01:39:53.920
kompliziert wohnen, hatte ich

01:39:53.920 --> 01:39:55.240
so das Gefühl. Aber

01:39:55.240 --> 01:39:57.820
der Sachverhalt an sich, der ist gefühlt

01:39:57.820 --> 01:39:59.640
gar nicht so komplex. Und die

01:39:59.640 --> 01:40:01.840
Probleme, die wir aufgezählt haben, die sind schon da,

01:40:02.240 --> 01:40:03.760
aber die müssen nicht immer ein Problem

01:40:03.760 --> 01:40:05.660
sein. Ich bin da so ein bisschen neben, was

01:40:05.660 --> 01:40:07.560
Jochen gesagt hat. Die Frage ist, wann braucht man das überhaupt?

01:40:07.740 --> 01:40:09.620
Also du brauchst halt wirklich einen Pfeil, wo du dich auskennst

01:40:09.620 --> 01:40:11.900
und wirklich weißt, das brauchst du jetzt, das kannst du nicht anders lösen,

01:40:12.640 --> 01:40:13.420
bevor du überhaupt

01:40:13.420 --> 01:40:15.700
die Entscheidung treffen würdest, da machen wir jetzt ein Microsoft-Ausfall.

01:40:15.800 --> 01:40:17.620
Ich glaube, vorher muss man

01:40:17.620 --> 01:40:19.080
erstmal andere Sachen korrigieren oder so.

01:40:19.280 --> 01:40:21.460
Ja, also ich meine,

01:40:21.920 --> 01:40:23.700
das klingt jetzt alles schrecklich oder klingt jetzt

01:40:23.700 --> 01:40:24.500
wenn ich, ähm,

01:40:25.140 --> 01:40:26.240
alter Sack.

01:40:27.260 --> 01:40:29.380
Ich habe früher, wenn Leute so etwas gesagt haben,

01:40:29.440 --> 01:40:30.000
war ich immer so, ja, ja.

01:40:30.480 --> 01:40:32.240
Aber tatsächlich, so Erfahrungen,

01:40:32.460 --> 01:40:34.000
oft ist es irgendwie,

01:40:34.580 --> 01:40:36.660
ich habe das Gefühl,

01:40:37.000 --> 01:40:39.100
das Problem in der Praxis ist oft

01:40:39.100 --> 01:40:42.240
Kompetenz.

01:40:42.700 --> 01:40:44.920
Da weiß ich nicht, ob Leute das irgendwie hinkriegen oder nicht.

01:40:45.120 --> 01:40:46.260
Kann man das essen?

01:40:46.840 --> 01:40:49.140
Und die Sachen selber

01:40:49.140 --> 01:40:49.960
sind gar nicht so kompliziert.

01:40:49.960 --> 01:40:51.240
Da würde ich vollkommen recht geben.

01:40:52.160 --> 01:40:54.500
Ich würde es so ausdrücken,

01:40:54.800 --> 01:41:05.620
Es gibt einen nicht unerheblichen handwerklichen Teil bei dieser ganzen Geschichte und der ist gar nicht so gut in theoretischer, also sagen wir so, das ist halt nicht so viel, da ist gar nicht so viel Theorie.

01:41:05.620 --> 01:41:19.600
Also genau, ich weiß nicht, das ist vielleicht die falsche Analogie, ich versuche es einfach mal, man sagt irgendwie, ja man möchte gerne irgendwie einen Bart schön gefließt haben oder so, dann das Buch zur Fliesenlegtheorie ist jetzt gar nicht so dick vielleicht.

01:41:20.180 --> 01:41:22.260
Das heißt aber nicht, dass das ein einfaches Problem ist.

01:41:22.500 --> 01:41:24.320
Wenn man das selber versucht, dann wird man feststellen,

01:41:24.560 --> 01:41:26.260
das sieht nicht so aus, wie ich mir das

01:41:26.260 --> 01:41:28.260
vorgestellt habe, blöd. Und tatsächlich

01:41:28.260 --> 01:41:29.500
braucht man möglicherweise lange,

01:41:29.900 --> 01:41:32.160
muss lange üben und viele Better-Gefeest haben,

01:41:32.240 --> 01:41:33.100
bis man das richtig kann.

01:41:34.040 --> 01:41:36.260
Und das ist halt leider beim Programmieren manchmal auch irgendwie so.

01:41:36.820 --> 01:41:39.440
ja,

01:41:39.660 --> 01:41:41.880
das ist halt ein Problem, mit dem

01:41:41.880 --> 01:41:44.300
Organisationen dann auch oft konfrontiert

01:41:44.300 --> 01:41:45.480
sind und

01:41:45.480 --> 01:41:48.100
das nicht so richtig gelöst kriegen.

01:41:48.480 --> 01:41:50.080
Und dann probiert man das halt mit so komplizierten

01:41:50.080 --> 01:41:51.940
Geschichten irgendwie. Also ja,

01:41:52.240 --> 01:41:54.200
okay, aber eigentlich, und das

01:41:54.200 --> 01:41:56.180
Dumme ist, da gibt es halt auch keinen einfachen Weg raus.

01:41:56.360 --> 01:41:58.320
Die Lösung

01:41:58.320 --> 01:41:59.620
dafür ist halt, weiß ich nicht,

01:42:00.020 --> 01:42:02.220
Leute schulen oder abwarten, bis sie so gut

01:42:02.220 --> 01:42:04.140
geworden sind, dass das dann funktioniert oder so viele

01:42:04.140 --> 01:42:06.160
Sachen kaputt gegangen sind, dass sie dann irgendwann gemerkt haben,

01:42:06.220 --> 01:42:08.200
wie es richtig funktioniert. Und das ist halt dann

01:42:08.200 --> 01:42:10.140
vielleicht so ein Zeithorizont mehrere Jahre oder so.

01:42:10.820 --> 01:42:12.060
Das kann man ja, und

01:42:12.060 --> 01:42:13.980
dann ist noch nicht mal sichergestellt, dass es dann hinterher wirklich

01:42:13.980 --> 01:42:16.180
funktioniert, sondern da kann man

01:42:16.180 --> 01:42:17.860
nur die Hoffnung drauf haben, dass es dann vielleicht funktioniert.

01:42:18.200 --> 01:42:19.580
Das ist ja ganz schrecklich.

01:42:19.860 --> 01:42:21.900
wenn ich jetzt ein Projekt habe, wo meine Karriere

01:42:21.900 --> 01:42:23.420
dann hängt, ob das jetzt gut wird oder nicht.

01:42:23.740 --> 01:42:24.900
Das kann mir ja niemandem erzählen.

01:42:25.380 --> 01:42:27.860
Und dann versuchen wir halt irgendwie andere Sachen

01:42:27.860 --> 01:42:29.380
um das. Aber das ist halt alles nur,

01:42:29.560 --> 01:42:31.540
ja. Ich glaube, um nochmal zu der

01:42:31.540 --> 01:42:33.340
Badanalogie zurückzukommen, dann hast du halt entweder

01:42:33.340 --> 01:42:35.800
eine Mosaikwand oder du klebst halt alles

01:42:35.800 --> 01:42:36.680
mit einem Kleber drüber.

01:42:38.020 --> 01:42:40.000
Dann hast du eine glatte Wand, das ist auch, glaube ich,

01:42:40.000 --> 01:42:41.920
modisch gerade. Ich glaube, das ist nicht

01:42:41.920 --> 01:42:42.360
so schlimm.

01:42:44.240 --> 01:42:45.920
Ja, ich weiß nicht. Wichtig ist,

01:42:46.060 --> 01:42:48.020
was kannst du in dem Bad machen? Kannst du da dich duschen

01:42:48.020 --> 01:42:49.700
zum Beispiel? Ja, ja, aber

01:42:49.700 --> 01:42:51.940
ich glaube, das ist halt tatsächlich gar nicht so einfach,

01:42:52.060 --> 01:42:53.700
das hinzukriegen, dass es wirklich gut funktioniert.

01:42:53.820 --> 01:42:55.460
Das ist halt irgendwie schwierig.

01:42:56.640 --> 01:42:57.160
Ja, okay.

01:42:57.680 --> 01:42:59.840
Die Handwerksgrundsätze sind natürlich schon sehr wichtig.

01:42:59.880 --> 01:43:01.580
Ja, oder ich weiß nicht, vielleicht ist das auch ein blödes Beispiel,

01:43:01.700 --> 01:43:04.020
Musikinstrument spielen ist vielleicht auch theoretisch gar nicht so,

01:43:04.380 --> 01:43:05.660
Gitarre gibt nicht so viele Seiten,

01:43:05.920 --> 01:43:07.840
aber trotzdem irgendwie muss man lange üben, bevor das

01:43:07.840 --> 01:43:10.020
irgendwie funktioniert. Und manche Bereiche,

01:43:10.200 --> 01:43:11.820
vielleicht nicht alle, aber manche Bereiche beim Programmieren sind

01:43:11.820 --> 01:43:14.160
halt auch so. So dieser Modulisierungsbereich,

01:43:14.280 --> 01:43:14.860
da habe ich das Gefühl,

01:43:15.300 --> 01:43:17.740
es gibt schon die kleinen Kinder, die können relativ viel

01:43:17.740 --> 01:43:18.720
Krach machen und nennen das Musik.

01:43:19.700 --> 01:43:22.840
naja

01:43:22.840 --> 01:43:24.340
okay

01:43:24.340 --> 01:43:27.480
haben wir eine Quintessenz gefunden damit?

01:43:28.160 --> 01:43:29.140
es kommt drauf an

01:43:29.140 --> 01:43:31.400
genau, das gibt es auch

01:43:31.400 --> 01:43:32.360
hat jemand schön

01:43:32.360 --> 01:43:35.140
die Lösung aller IT-Probleme

01:43:35.140 --> 01:43:37.280
so ein O'Reilly-Buch, wo drauf steht

01:43:37.280 --> 01:43:37.860
it depends

01:43:37.860 --> 01:43:39.320
absolut

01:43:39.320 --> 01:43:43.460
ich bleib dabei

01:43:43.460 --> 01:43:44.860
es ist prinzipiell cool erstmal

01:43:44.860 --> 01:43:47.420
das muss man halt sagen, es klingt natürlich

01:43:47.420 --> 01:43:49.500
cooler, auch wenn das natürlich niemals

01:43:49.500 --> 01:43:51.620
ein Entscheidungspunkt sein sollte und auch

01:43:51.620 --> 01:43:53.600
sehr, sehr subjektiv ist. Aber ich glaube,

01:43:53.680 --> 01:43:55.500
am Ende kommt es immer einfach drauf an, ob man es

01:43:55.500 --> 01:43:56.960
haben will, ob man es braucht.

01:43:59.080 --> 01:43:59.640
Da haben wir wieder,

01:43:59.740 --> 01:44:01.380
es ist ein gutes Sales-Argument. Wir machen

01:44:01.380 --> 01:44:03.520
Microservices, das ist wunderbar, das klingt

01:44:03.520 --> 01:44:05.120
erstmal immer gut. Ja, okay.

01:44:05.340 --> 01:44:07.300
Das ist auf jeden Fall ein gutes Argument, wo man Geld für mich vergeben kann.

01:44:08.280 --> 01:44:08.460
Ja.

01:44:10.060 --> 01:44:11.480
Rein technisch natürlich immer schwer.

01:44:11.800 --> 01:44:13.380
Da sind wir wieder bei den Dingen, wo die

01:44:13.380 --> 01:44:15.400
Infra sagt, da bewegen wir uns gar nicht, sagt

01:44:15.400 --> 01:44:17.320
dann halt Consulting, ja, wir müssen ja nichts

01:44:17.320 --> 01:44:18.880
neu, sau durchs Dorf treiben,

01:44:19.120 --> 01:44:20.840
wieder ein bisschen Sales und Marketing machen kann, ja.

01:44:21.240 --> 01:44:23.280
Ja, aber das ist halt so ein bisschen, das ist halt auch das gleiche

01:44:23.280 --> 01:44:25.420
Problem wie, ich glaube, ich versuche

01:44:25.420 --> 01:44:27.220
immer das noch auf den Punkt zu kriegen, ich kriege es nicht so richtig gut

01:44:27.220 --> 01:44:28.500
formuliert, das ist halt so

01:44:28.500 --> 01:44:30.960
Probleme, die schwer lösbar sind,

01:44:31.200 --> 01:44:33.160
die produzieren im Grunde irgendwie so

01:44:33.160 --> 01:44:35.460
Scheinlösungen, so, weiß ich nicht.

01:44:35.580 --> 01:44:37.260
Lass das mal Edgel machen. Gesundheit

01:44:37.260 --> 01:44:38.520
ist schwierig, ja, irgendwie,

01:44:38.780 --> 01:44:40.640
wenn man irgendwie eine schwere Krankheit

01:44:40.640 --> 01:44:42.580
bekommt oder so, dann hat man ein Problem, das sehr schwer lösbar

01:44:42.580 --> 01:44:44.460
ist, wo man nicht viel machen kann, so, das produziert

01:44:44.460 --> 01:44:46.280
halt irgendwie den ganzen Markt von irgendwie so

01:44:46.280 --> 01:44:48.340
Pseudo-Snack-Oil, weiß ich nicht,

01:44:48.440 --> 01:44:50.780
Quacksalbern. Computer-Sicherheit,

01:44:51.020 --> 01:44:51.860
schwieriges Problem,

01:44:52.280 --> 01:44:53.820
dann auch da

01:44:53.820 --> 01:44:55.660
entsteht so eine Branche von

01:44:55.660 --> 01:44:58.100
etwas halbwegs

01:44:58.100 --> 01:44:59.560
Zwielichtigen, weiß ich nicht genau.

01:44:59.860 --> 01:45:01.280
Manche sind gut, manche sind nicht so gut.

01:45:01.580 --> 01:45:04.120
Da habe ich schon gesagt, dass du durch eine Firma betreibst, bei der du bei Organ-Energie

01:45:04.120 --> 01:45:05.960
auf Telefon anrufen kannst und ich schicke dir dann

01:45:05.960 --> 01:45:07.660
positive Energie durch das Universum zurück.

01:45:08.980 --> 01:45:10.120
Ja, also jetzt musst du

01:45:10.120 --> 01:45:11.320
nur noch das entsprechende Problem

01:45:11.320 --> 01:45:13.820
suchen, was die Leute gerne löst haben.

01:45:14.080 --> 01:45:15.760
Ja, einen Stundensatz aufzählen oder halt so eine

01:45:15.760 --> 01:45:17.220
019er-Nummer oder sowas.

01:45:18.160 --> 01:45:18.320
Ja.

01:45:20.440 --> 01:45:21.680
Wir schweifen schon wieder ab.

01:45:22.960 --> 01:45:23.840
Ja, und

01:45:23.840 --> 01:45:26.000
da muss man halt, ich meine, ja, und es gibt dann

01:45:26.000 --> 01:45:27.260
halt so Dinge, die sind so, ja,

01:45:27.540 --> 01:45:30.100
vielleicht schon sinnvoll, aber man kann sie halt

01:45:30.100 --> 01:45:31.980
auch so benutzen. Es ist halt, das ist halt wie,

01:45:32.120 --> 01:45:34.120
weiß ich nicht, es gibt so ganze Big Data

01:45:34.120 --> 01:45:35.960
Blockchain, weiß ich nicht, und

01:45:35.960 --> 01:45:37.920
Microservices ist halt auch irgendwie so ein bisschen

01:45:37.920 --> 01:45:39.900
irgendwie zumindest irgendwie, man hatte

01:45:39.900 --> 01:45:41.820
so das Gefühl, das wird immer so als Lösung verkauft,

01:45:41.900 --> 01:45:43.320
für Sachen, die schwer sind.

01:45:44.560 --> 01:45:46.020
Ja, aber ich will

01:45:46.020 --> 01:45:47.460
gar nicht sagen, dass das jetzt irgendwie

01:45:47.460 --> 01:45:49.520
Unsinn wäre oder so, sondern ne, also

01:45:49.520 --> 01:45:51.800
es gibt da schon durchaus andere Nutzfallen und das ist auch

01:45:51.800 --> 01:45:52.360
vielleicht eine gute Idee.

01:45:53.540 --> 01:45:55.840
Sie machen nicht immer alles leichter, sie machen manchmal auch

01:45:55.840 --> 01:45:57.740
Sachen schwerer, aber sie machen dabei andere

01:45:57.740 --> 01:45:59.320
Sachen leichter, aber nicht alles.

01:45:59.920 --> 01:46:00.440
Ja, auch wenn es schwerer wird.

01:46:01.440 --> 01:46:03.860
Man hat einfach wirklich diesen, also das ist

01:46:03.860 --> 01:46:05.700
ich glaube, das ist auch immer ganz wichtig zu

01:46:05.700 --> 01:46:07.780
sagen dabei, man hat halt wirklich einen Trade-Off

01:46:07.780 --> 01:46:09.440
und der ist nicht ohne, der ist niemals ohne.

01:46:09.520 --> 01:46:11.780
Ja, vielleicht wollte man jemanden fragen, der sich damit auskennt, bevor man

01:46:11.780 --> 01:46:13.380
zum Beispiel mich.

01:46:13.400 --> 01:46:13.840
Änderung macht.

01:46:16.200 --> 01:46:17.020
Genau, ja.

01:46:18.320 --> 01:46:19.120
Ja, keine Ahnung.

01:46:19.720 --> 01:46:21.020
Wir hätten, also ich hätte auch noch

01:46:21.020 --> 01:46:22.620
Pics, also wir können auch noch, ich weiß nicht genau,

01:46:22.700 --> 01:46:24.460
wie es aussieht. Wollen wir noch irgendwie,

01:46:24.980 --> 01:46:26.940
gibt es noch irgendwie Themen oder haben wir schon alles

01:46:26.940 --> 01:46:28.980
gesagt, was wir sagen wollen? Haben wir alles gesagt zum Microservices?

01:46:29.740 --> 01:46:30.620
Fällt euch noch was ein? Bestimmt nicht.

01:46:31.200 --> 01:46:31.780
Bestimmt nicht, ja.

01:46:32.400 --> 01:46:34.880
Ja, ich habe noch eine andere Frage, aber das hat nichts mit den Pics

01:46:34.880 --> 01:46:35.680
zu tun, aber das ist dann Jochen.

01:46:36.840 --> 01:46:38.720
Aber haben wir noch irgendwas zu Microservices?

01:46:39.100 --> 01:46:40.560
Sonst würden wir das Thema einfach zumachen.

01:46:41.140 --> 01:46:42.140
No. Machen wir es so.

01:46:42.920 --> 01:46:44.520
Du hast irgendwas mit File-Benchmarks gemacht,

01:46:44.620 --> 01:46:45.120
was war denn das?

01:46:46.460 --> 01:46:52.460
Okay, ja, also das ist etwas, das mich ja auch schon eine ganze Zeit lang umtreibt.

01:46:52.880 --> 01:46:54.340
Sollen wir das beim nächsten Mal sonst erzählen?

01:46:54.440 --> 01:46:58.500
Nö, wir können das gerne kurz darauf eingehen.

01:46:59.780 --> 01:47:08.880
Ja, also die Frage, die mich beschäftigt hat, ist, weil ich würde ja gern ins Hosting-Geschäft einsteigen.

01:47:09.220 --> 01:47:10.360
Ja, also ganz dick.

01:47:11.580 --> 01:47:15.900
Ja, genau. Und eine Frage, die mich da beschäftigt hat, also gerade Podcast-Hosting.

01:47:16.040 --> 01:47:17.060
Ich meine, wir betreiben unsere eigene,

01:47:17.240 --> 01:47:19.680
wir sind ja auch unser eigener Podcast-Hauser, tatsächlich.

01:47:20.280 --> 01:47:22.680
Und da sind das etwas spezielle Anforderungen.

01:47:22.760 --> 01:47:23.560
Die Files sind groß.

01:47:24.000 --> 01:47:25.460
Ja, Files surfen, schnell Files surfen.

01:47:26.040 --> 01:47:27.740
Genau, und die Frage ist jetzt, okay,

01:47:27.860 --> 01:47:28.540
mit Pfeifen oder nicht?

01:47:29.080 --> 01:47:30.980
Ja, mich ärgert, dass wir da so eine Abhängigkeit haben.

01:47:31.060 --> 01:47:33.600
Wir machen das über einen CDN, über CloudFront

01:47:33.600 --> 01:47:36.180
und das ist auch teuer irgendwie.

01:47:38.060 --> 01:47:38.700
Erstaunlich teuer.

01:47:39.360 --> 01:47:41.860
Und die Frage wäre, kann man das nicht selber machen?

01:47:41.960 --> 01:47:43.660
Weil wenn man irgendwie, ich miete ja sowieso Server,

01:47:43.660 --> 01:47:45.800
auf den ich den Xamarin deploye und da ist der Traffic

01:47:45.800 --> 01:47:47.980
frei, also warum kann man

01:47:47.980 --> 01:47:49.700
dann nicht die Files auch mit ausliefern?

01:47:49.840 --> 01:47:50.900
Also mit Minio oder sowas?

01:47:51.600 --> 01:47:53.940
Ja, oder im einfachsten Fall ein statischer Web-Server,

01:47:54.020 --> 01:47:56.000
das geht natürlich, das Problem dabei ist halt

01:47:56.000 --> 01:47:57.920
naja, also

01:47:57.920 --> 01:47:58.840
solche Dinge wie

01:47:58.840 --> 01:48:01.800
Authentifizierung und so ist halt schwierig, wie ist das denn

01:48:01.800 --> 01:48:03.240
halt, also ich meine, das ist natürlich

01:48:03.240 --> 01:48:05.560
viele würden sagen, das ist doch egal,

01:48:06.440 --> 01:48:07.220
wenn da jemand deine,

01:48:08.260 --> 01:48:09.460
also mir geht es um den Fall zum Beispiel, man

01:48:09.460 --> 01:48:11.660
editiert halt irgendwie eine neue

01:48:11.660 --> 01:48:13.640
Podcast-Episode zum Beispiel und dann

01:48:13.640 --> 01:48:15.980
Sollte zum Beispiel die Audioinhalte

01:48:15.980 --> 01:48:17.740
nicht für jeden sofort verfügbar sein, sondern

01:48:17.740 --> 01:48:19.380
erst, wenn das frei veröffentlicht ist.

01:48:20.300 --> 01:48:21.720
Also nur, wenn man authentifiziert ist.

01:48:22.060 --> 01:48:24.140
Wie macht man das denn? Das geht ja

01:48:24.140 --> 01:48:25.620
quasi gar nicht, wenn ich das auf dem statischen

01:48:25.620 --> 01:48:27.620
File-Server hätte. Dann, sobald die Files verfügbar sind,

01:48:28.200 --> 01:48:28.820
kann ich sie da sehen.

01:48:31.480 --> 01:48:32.020
Ist jetzt

01:48:32.020 --> 01:48:33.440
ein Detailproblem eigentlich, aber

01:48:33.440 --> 01:48:35.700
wie wäre das denn, wenn ich das für andere

01:48:35.700 --> 01:48:37.460
machen wollen würde?

01:48:37.660 --> 01:48:39.280
Die haben ja eventuell auch noch irgendwie

01:48:39.280 --> 01:48:41.520
so Anwendungsfälle, wo sie Sachen

01:48:41.520 --> 01:48:43.540
vielleicht nur nicht öffentlich veröffentlichen

01:48:43.540 --> 01:48:45.300
wollen, also eine ausgewählte Gruppe

01:48:45.300 --> 01:48:47.380
von Leuten. Also, wie

01:48:47.380 --> 01:48:49.220
soll denn eine Authentifizierung funktionieren? Dann gibt es dann halt

01:48:49.220 --> 01:48:51.180
diese ganzen Geschichten mit, man schickt

01:48:51.180 --> 01:48:53.240
halt sozusagen

01:48:53.240 --> 01:48:55.200
ein Request an den File-Server,

01:48:55.640 --> 01:48:57.200
und da ist dann halt irgendwie ein Cookie gesetzt,

01:48:57.320 --> 01:48:59.360
oder halt ein Token, oder da ist irgendwas in der URL,

01:48:59.480 --> 01:49:01.200
was signiert ist, und dann der fragt nochmal

01:49:01.200 --> 01:49:03.260
einen anderen Service und guckt halt nach, ist der

01:49:03.260 --> 01:49:04.060
jetzt authentifiziert?

01:49:05.300 --> 01:49:06.220
Fragt der einen Microservice?

01:49:06.640 --> 01:49:08.800
Ja, genau, da hat man dann auch schon so eine Art Microservice,

01:49:09.060 --> 01:49:10.580
oder man schickt halt den

01:49:10.580 --> 01:49:13.060
den Request zum Applikations-Server. Der Applikations-Server

01:49:13.060 --> 01:49:14.760
schickt aber nicht die File-Response zurück, sondern

01:49:14.760 --> 01:49:16.760
er schickt nur eine Response zurück, wo

01:49:16.760 --> 01:49:18.840
ein Header gesetzt ist, in dem drin steht, ja,

01:49:18.960 --> 01:49:20.660
dieses File darf ausgeliefert werden. Und dann

01:49:20.660 --> 01:49:22.680
der Reverse-Proxy vorne dran tauscht dann halt diese

01:49:22.680 --> 01:49:24.020
Response, die echte File-Response aus.

01:49:24.200 --> 01:49:26.380
Engine X macht? Ja, genau, das gibt's.

01:49:26.800 --> 01:49:28.920
Wie heißt das? X-Send-File?

01:49:29.500 --> 01:49:30.800
Ich weiß nicht. Irgendwie so. Ja, genau.

01:49:31.360 --> 01:49:31.600
Und

01:49:31.600 --> 01:49:34.400
also das gibt's alles sehr hässlich

01:49:34.400 --> 01:49:36.300
und funktioniert auch alles nicht so richtig gut.

01:49:36.800 --> 01:49:38.540
Und deswegen wäre es auch viel schöner, wenn man das direkt über

01:49:38.540 --> 01:49:40.460
einen Applikations-Server ausliefern würde. Und ich dachte eigentlich

01:49:40.460 --> 01:49:42.440
geht doch. Django Static Files quasi.

01:49:43.480 --> 01:49:44.360
Ja, da gibt's

01:49:44.360 --> 01:49:46.560
also wenn die Assets

01:49:46.560 --> 01:49:48.380
gemeint sind, also sowas wie CSS

01:49:48.380 --> 01:49:50.560
und JavaScript und so Zeugs, da gibt's schon was

01:49:50.560 --> 01:49:52.100
für. Da gibt's zwei Neues. Nicht die Assets, sondern

01:49:52.100 --> 01:49:54.440
wirklich dann halt mit Einzel-Single-Permission

01:49:54.440 --> 01:49:56.700
und File-Offset-Level. Genau, da gibt's

01:49:56.700 --> 01:49:58.400
nix und das wäre aber interessant

01:49:58.400 --> 01:50:00.420
und eigentlich dachte ich irgendwie, das müsste

01:50:00.420 --> 01:50:02.460
mit Python auch gehen, Python-Icing.io, da gibt's ja auch

01:50:02.460 --> 01:50:04.220
alles irgendwie und

01:50:04.220 --> 01:50:06.980
UV-Loop

01:50:06.980 --> 01:50:08.520
ist ja auch sehr schnell

01:50:08.520 --> 01:50:09.200
und so

01:50:09.200 --> 01:50:11.320
und das müsste man doch eigentlich

01:50:11.320 --> 01:50:12.520
machen können und das geht auch.

01:50:13.100 --> 01:50:14.780
Dein Benchmark hat festgestellt, Caddy ist viel schneller.

01:50:15.720 --> 01:50:16.940
Ja, genau.

01:50:17.260 --> 01:50:18.940
Dann habe ich irgendwie jetzt ein anderes,

01:50:19.140 --> 01:50:20.800
weil ich interessiere mich für Kochen und so und

01:50:20.800 --> 01:50:22.340
gibt es so einen Rezeptmanager, Mili.

01:50:22.900 --> 01:50:25.160
Kann man sich auch mal angucken, ist sehr nett.

01:50:25.340 --> 01:50:27.080
Und das habe ich dann irgendwie auf meiner Infrastruktur deployed

01:50:27.080 --> 01:50:28.920
und da gibt es auch viele Bilder und so und dann

01:50:28.920 --> 01:50:30.740
dachte ich, ah, das mache ich bei UV-Corn, weil

01:50:30.740 --> 01:50:32.780
wozu haben die da noch extra

01:50:32.780 --> 01:50:35.080
ein Caddy laufen? Und dann

01:50:35.080 --> 01:50:36.820
habe ich dann auch in deren Discord Bescheid gesagt,

01:50:37.080 --> 01:50:38.980
so, ja, warum macht ihr denn

01:50:38.980 --> 01:50:40.720
da nochmal Caddy irgendwie zusätzlich,

01:50:40.840 --> 01:50:42.660
das ist doch Quatsch, irgendwie macht das doch einfach über den UV-Corn

01:50:42.660 --> 01:50:44.640
und dann hieß es so, ja, aber wir haben die Erfahrung gemacht,

01:50:44.680 --> 01:50:46.960
das ist dann irgendwie schneller und irgendwie sonst ist es langsam.

01:50:47.300 --> 01:50:48.380
Der so, das kann gar nicht sein!

01:50:48.620 --> 01:50:49.580
Dann muss ich mal einen Benchmark machen.

01:50:50.020 --> 01:50:51.540
Hab ich einen Benchmark gemacht und gesehen,

01:50:52.480 --> 01:50:54.500
stimmt doch, sie haben recht, ich liege falsch.

01:50:56.600 --> 01:50:57.140
Benchmark, ja.

01:50:57.980 --> 01:50:58.660
Auf jeden Fall

01:50:58.660 --> 01:51:00.720
tatsächlich Nginx Caddy, viel schneller

01:51:00.720 --> 01:51:02.640
als UV-Corn

01:51:02.640 --> 01:51:04.840
beziehungsweise die File-Response kommt von Starlet,

01:51:05.740 --> 01:51:06.800
was halt unter Fast-DPI

01:51:06.800 --> 01:51:07.300
darunter liegt.

01:51:08.160 --> 01:51:09.800
Und das ist auch fast IPA-Backend.

01:51:10.960 --> 01:51:11.960
Ja, keine Ahnung, wo es liegt.

01:51:12.040 --> 01:51:13.800
Ich weiß es nicht. Also sagen wir so, es ist immer noch schnell genug

01:51:13.800 --> 01:51:16.460
für Gigabit-Interface.

01:51:17.180 --> 01:51:18.160
Aber wenn es

01:51:18.160 --> 01:51:19.920
also 10 Gigabit schafft man damit nicht.

01:51:20.800 --> 01:51:22.060
Und Caddy und

01:51:22.060 --> 01:51:23.860
Nginx schaffen das schon. Also

01:51:23.860 --> 01:51:26.220
irgendwas ist da nicht richtig. Ich weiß aber nicht was.

01:51:26.640 --> 01:51:28.020
Kommen wir wieder zu UV-Con macht das

01:51:28.020 --> 01:51:29.840
ganze Jahr, oder UV-Loop ist halt Zeiten

01:51:29.840 --> 01:51:31.860
vor allen Dingen. Und denken wir, das kompiliert ja nach C.

01:51:31.960 --> 01:51:34.100
Das muss doch eigentlich schnell sein. Keine Ahnung.

01:51:34.220 --> 01:51:35.860
Also eine mögliche

01:51:35.860 --> 01:51:37.940
Grund dafür, warum das

01:51:37.940 --> 01:51:39.400
so ist, den ich,

01:51:40.260 --> 01:51:41.360
wo ich denke, das könnte es sein, ist,

01:51:42.040 --> 01:51:43.000
es liegt daran, dass

01:51:43.000 --> 01:51:45.880
irgendwie Caddy und Nginx

01:51:45.880 --> 01:51:47.800
irgendeine Art von Serial-Copy-TCP verwenden,

01:51:48.500 --> 01:51:49.820
wo es halt nicht nochmal durch den User-Space

01:51:49.820 --> 01:51:51.560
kopiert werden muss, die Daten, und

01:51:51.560 --> 01:51:53.040
das macht Ubiquon halt nicht,

01:51:53.900 --> 01:51:55.780
sondern, weil das kann es halt noch nicht,

01:51:55.900 --> 01:51:57.400
also es gibt da ein Pull-Request, das ist aber noch nicht durch,

01:51:58.160 --> 01:51:59.780
das heißt, da wird immer alles nochmal

01:51:59.780 --> 01:52:01.900
kopiert, also es wird vom Filesystem, vom Hauptspeicher

01:52:01.900 --> 01:52:03.460
von der Anwendung kopiert und dann nochmal

01:52:03.460 --> 01:52:05.880
in den Netzwerkspeicher und dann erst

01:52:05.880 --> 01:52:08.260
raus. Das ist natürlich viel ineffizienter,

01:52:08.360 --> 01:52:09.900
als wenn man es halt, als wenn der Kernel direkt...

01:52:09.900 --> 01:52:11.960
Interessant, wenn man bei den Pool-Requests kann, mal Cherrypicken

01:52:11.960 --> 01:52:13.760
und mal gucken, ob es dann... Ja, das wollen Sie

01:52:13.760 --> 01:52:15.900
vielleicht mal ein bisschen angucken. Also das könnte noch ein Unterschied sein.

01:52:15.980 --> 01:52:17.680
Das wäre dann halt ein relativ langweiliger Grund.

01:52:17.820 --> 01:52:19.900
Dann muss man sagen, ja gut, und das wäre halt

01:52:19.900 --> 01:52:21.960
so, ich weiß nicht, ob das dann mit Minio auch einfach so geht,

01:52:22.060 --> 01:52:23.980
wenn man die Files nicht im Filesystem liegen hat, sondern halt

01:52:23.980 --> 01:52:25.600
irgendwo anders, was man ja vielleicht will,

01:52:25.800 --> 01:52:27.940
heutzutage, dann geht es vielleicht alles nicht

01:52:27.940 --> 01:52:29.940
mehr. Aber dann ging es auch mit

01:52:29.940 --> 01:52:31.940
Nginx und so nicht mehr, auch mit Kelly

01:52:31.940 --> 01:52:32.500
nicht, weil

01:52:32.500 --> 01:52:35.780
die könnten dann nicht sein File einfach verwenden.

01:52:35.880 --> 01:52:37.700
Das geht halt nicht. Das geht halt nur, wenn es tatsächlich

01:52:37.700 --> 01:52:38.820
ein File-in-File-System ist, glaube ich.

01:52:39.580 --> 01:52:41.500
Auch da wäre interessant, wenn sich das jemand,

01:52:41.760 --> 01:52:43.600
wenn jemand Bescheid sagen könnte, der sich damit auskennt,

01:52:43.660 --> 01:52:44.340
ob das so ist oder nicht.

01:52:44.600 --> 01:52:44.740
Genau.

01:52:48.900 --> 01:52:49.980
Ja, genau.

01:52:50.120 --> 01:52:52.120
Damit habe ich mich so ein bisschen beschäftigt.

01:52:52.400 --> 01:52:52.960
Und ja,

01:52:53.560 --> 01:52:55.540
auf jeden Fall scheint es so zu sein, dass

01:52:55.540 --> 01:52:57.940
Caddy viel effizienter ist als

01:52:57.940 --> 01:52:59.920
UV-Con oder UV-Loop

01:52:59.920 --> 01:53:01.560
beim Serven von städtischen Files.

01:53:01.800 --> 01:53:03.200
Und ich weiß nicht, warum. Keine Ahnung.

01:53:03.700 --> 01:53:05.620
Aber es ist doch interessant. Mal gucken, ob ich das

01:53:05.620 --> 01:53:07.720
irgendwie rauskriege. Ja, das werden

01:53:07.720 --> 01:53:09.500
wir euch weiter informieren irgendwann am Ende von irgendeiner

01:53:09.500 --> 01:53:11.460
weiteren Zukunftsfolge. Also hört alle unsere Folgen

01:53:11.460 --> 01:53:12.820
mal bis ganz zum Ende durch, wenn es

01:53:12.820 --> 01:53:14.780
langweilig wird und nicht schlafen.

01:53:16.840 --> 01:53:17.020
Ja.

01:53:18.220 --> 01:53:19.080
Dann pickt der Woche, Jochen.

01:53:20.660 --> 01:53:21.020
Genau,

01:53:21.280 --> 01:53:23.460
picken würde ich diesmal

01:53:23.460 --> 01:53:23.960
tatsächlich,

01:53:25.480 --> 01:53:27.360
wo habe ich das gesehen? Ich weiß gar nicht mehr genau.

01:53:27.360 --> 01:53:28.380
Das Ding nennt sich

01:53:28.380 --> 01:53:32.240
B-Pi-Top.

01:53:32.920 --> 01:53:33.040
Ja.

01:53:34.320 --> 01:53:35.680
Ah, da, ich hab's hier laufen.

01:53:36.400 --> 01:53:37.960
Oh, das ist hübsch. Das ist ziemlich hübsch, ne?

01:53:38.340 --> 01:53:40.100
Ich weiß nicht, ob das Textual verwendet oder Rich

01:53:40.100 --> 01:53:41.360
oder irgendwas in der Richtung, aber

01:53:41.360 --> 01:53:43.280
genau. Post-its oder so?

01:53:43.780 --> 01:53:45.900
Rich? Ja, das gibt einem so ein bisschen

01:53:45.900 --> 01:53:48.040
Daten zu den, zu, also

01:53:48.040 --> 01:53:49.820
es ist halt Top. B-Pi-Top?

01:53:50.060 --> 01:53:50.200
Ja.

01:53:51.960 --> 01:53:54.020
Sehr nettes Ding. Es gibt da so ähnliche

01:53:54.020 --> 01:53:55.940
Sachen, Glances gibt's auch. Ja, Glances

01:53:55.940 --> 01:53:58.040
gibt's noch und also T-Top, H-Top.

01:53:58.560 --> 01:53:58.780
Ja.

01:54:00.080 --> 01:54:02.040
Aber das ist mir so letztens über den Weg gelaufen

01:54:02.040 --> 01:54:03.820
und fand ich, sieht echt ziemlich gut aus.

01:54:04.320 --> 01:54:07.020
Ist jetzt hier langweilig, der Rechner macht überhaupt nichts.

01:54:07.360 --> 01:54:08.520
Ja, das hat keine Last drauf.

01:54:09.700 --> 01:54:11.180
Ich picke iJSON.

01:54:11.880 --> 01:54:12.900
Habe ich auch noch nicht so viel

01:54:12.900 --> 01:54:14.640
benutzt, aber das macht so große

01:54:14.640 --> 01:54:16.960
JSON-Objekte irgendwie vernünftig.

01:54:19.620 --> 01:54:20.800
Hast du auch einen Pick, Janus?

01:54:22.520 --> 01:54:23.100
Was genau

01:54:23.100 --> 01:54:25.160
soll ich denn picken? Muss das einen breiten Kontext haben?

01:54:25.740 --> 01:54:26.020
Nö.

01:54:27.120 --> 01:54:28.920
Irgendwas Cooles, was halt irgendwie, was man

01:54:28.920 --> 01:54:29.600
vielleicht noch nicht kennt.

01:54:30.640 --> 01:54:33.100
Ah, okay. Ich weiß nicht, ob man es heute gehört hat.

01:54:33.260 --> 01:54:35.280
Ich habe so eine gewisse Präferenz zu Kafka.

01:54:36.240 --> 01:54:40.900
Das, was ich da picken würde, ist Kafka Connect tatsächlich.

01:54:42.260 --> 01:54:43.500
Kann man mal nachgoogeln.

01:54:43.660 --> 01:54:45.980
Das sorgt letztlich dafür,

01:54:46.160 --> 01:54:49.340
dass man sich Sachen automatisch aus Datenbanken holen kann,

01:54:49.480 --> 01:54:50.520
wenn sie reingeschrieben wurden.

01:54:51.300 --> 01:54:52.960
Also zum Beispiel Write-Only-Prozesse.

01:54:53.120 --> 01:54:54.640
Und die werden dann ganz, ganz automatisch

01:54:54.640 --> 01:54:56.120
in einen Topic reingeschoben.

01:54:56.720 --> 01:54:59.460
Das nennt sich dann Source Connector ohne Code.

01:54:59.460 --> 01:55:02.320
Quasi so eine Duplikation von der Realität in der Datenbank

01:55:02.320 --> 01:55:02.920
in das Kafka.

01:55:03.260 --> 01:55:05.400
Ja, wir haben ja über Datenkonsistenzen

01:55:05.400 --> 01:55:07.160
heute geredet. Und im Prinzip

01:55:07.160 --> 01:55:09.220
ist das so ein Ansatz, wie du dir die Daten

01:55:09.220 --> 01:55:11.320
quasi aus einer Datenbank, ohne

01:55:11.320 --> 01:55:13.360
den Service selbst da

01:55:13.360 --> 01:55:15.280
beeinflussen zu müssen, rausziehen kannst,

01:55:15.320 --> 01:55:17.060
in ein Topic schreiben kannst und über einen

01:55:17.060 --> 01:55:19.280
Sync-Connector in andere Datenbanken reinschreiben

01:55:19.280 --> 01:55:21.080
kannst. Und das wirklich coole an der Sache ist,

01:55:21.100 --> 01:55:23.240
es gibt Konnektoren für alle möglichen Datenbanken.

01:55:23.620 --> 01:55:24.180
Also Postgres,

01:55:26.100 --> 01:55:26.940
Elasticsearch,

01:55:27.220 --> 01:55:29.120
Neo4j. Das ist relativ interessant.

01:55:29.280 --> 01:55:30.000
Kann man sich mal angucken.

01:55:30.960 --> 01:55:33.120
Das klingt gut. Also Next Level Kafka.

01:55:33.260 --> 01:55:34.520
mindestens.

01:55:36.520 --> 01:55:37.500
Okay, cool.

01:55:38.260 --> 01:55:39.660
Ja, vielen Dank, Janis, dass du hier warst heute.

01:55:40.020 --> 01:55:40.540
Sehr gerne.

01:55:41.440 --> 01:55:43.480
Ich hoffe, es hat dir ein bisschen Spaß gemacht,

01:55:43.520 --> 01:55:44.300
genauso viel wie uns.

01:55:45.600 --> 01:55:47.860
Bleibt uns gewogen. Schaltet uns wieder ein.

01:55:48.640 --> 01:55:49.400
Wie auch immer.

01:55:49.600 --> 01:55:50.020
Vielen Dank.

01:55:51.220 --> 01:55:53.220
Dann bis demnächst.

01:55:55.000 --> 01:55:55.400
Tschüss.