WEBVTT

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

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

00:00:09.440 --> 00:00:09.840
Hi Jochen.

00:00:10.080 --> 00:00:10.900
Hallo Dominik.

00:00:11.280 --> 00:00:12.020
Und wir haben einen Gäst dabei.

00:00:12.060 --> 00:00:12.240
Guten Abend.

00:00:12.800 --> 00:00:13.240
Hi Janis.

00:00:13.500 --> 00:00:14.300
Ja, das bin ich.

00:00:14.400 --> 00:00:15.080
Hallo Janis.

00:00:15.280 --> 00:00:15.880
Ich bin der Dominik.

00:00:16.260 --> 00:00:16.900
Ich bin der Janis.

00:00:17.860 --> 00:00:20.040
Ja, dann Janis, willst du dich mal kurz vorstellen vielleicht direkt?

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

00:00:26.660 --> 00:00:30.620
Ich entwickle mit Python viel und oft und gerne.

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

00:00:36.820 --> 00:00:41.120
Und du hast gesagt, du hast jetzt was zu Microsoft zu sagen und deswegen unterhalten wir uns heute darüber.

00:00:43.560 --> 00:00:45.300
Ich würde sagen, wir fangen mit News aus der Szene an.

00:00:45.320 --> 00:00:46.740
Ja, genau, machen wir das wie immer.

00:00:48.060 --> 00:00:48.720
Was hast du denn?

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

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

00:00:56.020 --> 00:01:02.180
weil, ich weiß ja nicht, aber vielleicht gibt es ja auch sogar Leute hier in der Zuhörer oder dabei sind gerade, die irgendwie davon betroffen sind.

00:01:02.740 --> 00:01:04.500
Es gab da so eine Sicherheitsschwankung bei Okta.

00:01:05.060 --> 00:01:07.260
Ja, ich weiß nicht, wen du meinst, der betroffen ist.

00:01:07.840 --> 00:01:08.460
Keine Ahnung.

00:01:09.140 --> 00:01:09.280
Ja.

00:01:10.040 --> 00:01:14.240
Ja, also das, ja, fand ich war mal wieder so.

00:01:14.260 --> 00:01:17.400
Also Okta ist so ein Multi-Login-Service, Single Sign-On.

00:01:17.840 --> 00:01:18.420
Ja, genau.

00:01:18.420 --> 00:01:20.280
und viele Kunden,

00:01:20.720 --> 00:01:22.140
viele Konzerne sind da Kunden und so

00:01:22.140 --> 00:01:24.160
und eigentlich war

00:01:24.160 --> 00:01:26.240
sozusagen die Marketing

00:01:26.240 --> 00:01:28.120
Story dabei halt irgendwie,

00:01:28.400 --> 00:01:30.180
ja, du musst irgendwie keinem

00:01:30.180 --> 00:01:32.200
vertrauen und das funktioniert einfach so und das

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

00:01:34.340 --> 00:01:36.120
irgendwie, die diese

00:01:36.120 --> 00:01:38.100
Dienstleistung in Anspruch genommen haben, feststellen, dass sie doch jemandem

00:01:38.100 --> 00:01:38.700
vertrauen mussten

00:01:38.700 --> 00:01:42.060
und dass sie dem eigentlich nicht wirklich vertrauen können,

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

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

00:01:46.880 --> 00:01:48.060
Tja. Und das ist natürlich

00:01:48.060 --> 00:01:48.420
schlecht.

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

00:01:52.120 --> 00:01:52.940
ziemlich beschädigt jetzt.

00:01:53.420 --> 00:01:55.980
Ja, aber ich habe mich da

00:01:55.980 --> 00:01:57.660
immer, ich frage mich, warum das

00:01:57.660 --> 00:01:59.880
gerade große Unternehmen so leichtfertig machen, weil das ist

00:01:59.880 --> 00:02:01.920
ehrlich gesagt irgendwie, sieht irgendwie

00:02:01.920 --> 00:02:03.960
schon von Weitem wie eine nicht so richtig gute Idee aus,

00:02:04.000 --> 00:02:05.680
sowas zu machen, so gerade Authentifizierung irgendwie

00:02:05.680 --> 00:02:06.200
auszuschanzen.

00:02:07.760 --> 00:02:09.860
Ja, weil die alle nicht wissen, wie das geht und weil die das Problem haben,

00:02:09.940 --> 00:02:12.160
dass die ganz viele kleine Anwendungen

00:02:12.160 --> 00:02:13.920
haben, die Leute benutzen und die alle

00:02:13.920 --> 00:02:15.560
irgendwo ihre Passwörter verwalten sollen

00:02:15.560 --> 00:02:18.000
und die dann immer unsicherere Passwörter

00:02:18.000 --> 00:02:19.920
nehmen, wenn die ganz viele verschiedene Services

00:02:19.920 --> 00:02:21.580
auf ihrem Rechner benutzen sollen oder so.

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

00:02:23.740 --> 00:02:25.900
die Policies vielleicht ein bisschen besser einhalten und die Leute

00:02:25.900 --> 00:02:27.800
dazu zwingen, dass sie so ein bisschen mehr darüber nachdenken, was sie tun.

00:02:28.280 --> 00:02:30.100
Ja, gut, Single-Sign-On verstehe ich

00:02:30.100 --> 00:02:32.080
auch irgendwie, aber ich verstehe nicht so richtig, warum man dann...

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

00:02:33.020 --> 00:02:35.700
Wenn man das selber machen muss, dann ist es auch wieder schwierig.

00:02:35.940 --> 00:02:36.180
Ja, also

00:02:36.180 --> 00:02:39.780
das war auf jeden Fall, denke ich, ein

00:02:39.780 --> 00:02:41.780
großes Ding, was irgendwie in der letzten Zeit passiert ist.

00:02:41.840 --> 00:02:43.640
Ich habe auch für Okta tatsächlich so ein Dankmodul geschrieben,

00:02:43.760 --> 00:02:44.960
mit dem das dann doch irgendwie geht, aber

00:02:44.960 --> 00:02:47.420
das ist halt auch nutzerlich, wenn Okta kaputt ist.

00:02:47.420 --> 00:02:50.780
Ja, doof

00:02:50.780 --> 00:02:52.120
Menus

00:02:52.120 --> 00:02:54.960
Dann, aha, oh, gibt's

00:02:54.960 --> 00:02:57.100
einen, wir hatten ja schon mal

00:02:57.100 --> 00:02:57.900
diesen Tiobe

00:02:57.900 --> 00:03:00.520
Programmiersprachen

00:03:00.520 --> 00:03:02.020
Ach, der spannende große Index

00:03:02.020 --> 00:03:05.140
der immer so zitiert wird, wo man dann

00:03:05.140 --> 00:03:06.940
irgendwie, wenn man genauer drauf schaut, sehen muss, oh, die

00:03:06.940 --> 00:03:09.080
gucken nur, wie die Menge der Suchergebnisse

00:03:09.080 --> 00:03:10.980
bei so ein paar Suchanfragen aussieht und das ist ja

00:03:10.980 --> 00:03:12.960
alles irgendwie, wie viel das so sagt

00:03:12.960 --> 00:03:14.960
Keine Ahnung, es gibt einen anderen, der

00:03:14.960 --> 00:03:16.260
macht sowas ähnliches, der heißt

00:03:16.260 --> 00:03:17.600
Pipel,

00:03:18.300 --> 00:03:19.280
ich weiß gar nicht, wie der heißt.

00:03:20.600 --> 00:03:22.380
Jedenfalls da ist Python auch momentan die

00:03:22.380 --> 00:03:23.660
beliebteste Programmiersprache.

00:03:26.700 --> 00:03:28.360
Insofern kann man sagen, es ist halt jetzt

00:03:28.360 --> 00:03:30.100
nicht nur ein Service, der das halt sagt, sondern

00:03:30.100 --> 00:03:31.060
es gibt mehrere,

00:03:32.160 --> 00:03:34.280
die das halt unabhängig voneinander rausfinden.

00:03:34.420 --> 00:03:36.340
Insofern gibt das ein bisschen

00:03:36.340 --> 00:03:38.180
mehr Glaubwürdigkeit, dass da

00:03:38.180 --> 00:03:39.060
was dran sein könnte.

00:03:39.860 --> 00:03:41.920
Es ist auf jeden Fall Python sehr populär zur Zeit.

00:03:45.360 --> 00:03:46.240
Sogar Meta

00:03:46.240 --> 00:03:48.140
hat einen großen Beitrag

00:03:48.140 --> 00:03:50.480
an die Python Software Foundation gespendet, habe ich mitbekommen

00:03:50.480 --> 00:03:52.260
in letzter Zeit. Ja, das ist

00:03:52.260 --> 00:03:53.920
tatsächlich sehr gute Neuigkeiten.

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

00:03:56.320 --> 00:03:58.620
die Python Software Foundation

00:03:58.620 --> 00:04:00.120
irgendwie hatte bisher immer

00:04:00.120 --> 00:04:02.040
alles Mögliche um die Marke

00:04:02.040 --> 00:04:04.240
drumrum

00:04:05.260 --> 00:04:05.860
gemacht und so

00:04:05.860 --> 00:04:07.620
und Rechtsbeistand

00:04:07.620 --> 00:04:10.280
und solche Sachen für Leute, die das

00:04:10.280 --> 00:04:12.080
verletzen und so.

00:04:12.240 --> 00:04:14.300
Aber sie haben halt eigentlich keine Entwicklung bezahlt

00:04:14.300 --> 00:04:16.160
oder niemanden gehabt, der halt, es gab

00:04:16.160 --> 00:04:18.100
niemanden, der sich Vollzeit bezahlt,

00:04:18.260 --> 00:04:19.860
um Python

00:04:19.860 --> 00:04:20.420
zu kümmern.

00:04:21.320 --> 00:04:23.440
Es gab Leute, die bei Firm gearbeitet haben,

00:04:23.520 --> 00:04:26.080
die dann zumindest einen Teil der Zeit dafür zur Verfügung

00:04:26.080 --> 00:04:27.460
hatten, sich damit zu beschäftigen.

00:04:27.700 --> 00:04:30.120
Aber jetzt gibt es seit

00:04:30.120 --> 00:04:32.100
zwei Jahren, glaube ich,

00:04:32.400 --> 00:04:35.360
Developer in Residence.

00:04:35.920 --> 00:04:36.640
Zuerst hat Google

00:04:36.640 --> 00:04:37.300
den bezahlt.

00:04:37.840 --> 00:04:40.520
Lukas Schlanger macht das sehr gut.

00:04:41.420 --> 00:04:42.640
Er schreibt auch immer wieder Blogposts,

00:04:42.640 --> 00:04:43.240
was er so tut.

00:04:44.200 --> 00:04:46.040
Und jetzt quasi damit

00:04:46.040 --> 00:04:47.860
bezahlt das jetzt erstmals auf Facebook,

00:04:48.020 --> 00:04:48.800
was natürlich super ist.

00:04:49.580 --> 00:04:51.860
Vielleicht werden das ja nochmal irgendwann mehr Leute, also auf jeden Fall

00:04:51.860 --> 00:04:53.540
wird es irgendwie mehr Geld. Das ist ja schon mal toll.

00:04:54.480 --> 00:04:55.100
Voll gut.

00:04:56.600 --> 00:04:57.860
Also ich meine, eigentlich denke ich,

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

00:04:59.800 --> 00:05:01.020
Versicherung sehen können.

00:05:01.580 --> 00:05:03.960
Sollte man meinen. Sollte man denken, dass sie das so betrachten,

00:05:04.120 --> 00:05:05.920
weil wenn das

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

00:05:08.100 --> 00:05:09.300
was sie sehr teuer zuschlingen können.

00:05:09.320 --> 00:05:11.580
Es ist halt schwierig, so was zu vermitteln, dass du halt

00:05:11.580 --> 00:05:13.740
Dinge bezahlen musst, die in der Zukunft

00:05:13.740 --> 00:05:15.760
eventuell einen Return on Invest geben und

00:05:15.760 --> 00:05:18.000
oder halt auch nur ein Risiko abwenden.

00:05:18.740 --> 00:05:20.380
Ja, aber das ist gerade bei Open Source,

00:05:20.500 --> 00:05:22.300
die kriegt man ja immer so umsonst. Das reduziert ja

00:05:22.300 --> 00:05:24.420
meistens immer nur irgendwie die Kosten auf einer Kostenstelle.

00:05:25.420 --> 00:05:25.560
Ja.

00:05:26.240 --> 00:05:26.460
Ja.

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

00:05:30.640 --> 00:05:32.480
Aber irgendwie geht es da voran, das ist voll gut.

00:05:32.980 --> 00:05:34.080
Ja, was haben wir noch?

00:05:35.060 --> 00:05:35.740
Oh, genau.

00:05:36.820 --> 00:05:38.440
Bugspython.org, das weiß ich auch

00:05:38.440 --> 00:05:40.300
schon seit Jahren. Versuchen wir da irgendwie zu

00:05:40.300 --> 00:05:41.080
migrieren auf GitHub.

00:05:41.080 --> 00:05:42.480
Ist aber noch nicht.

00:05:42.600 --> 00:05:43.460
Nein, wir haben es verschoben.

00:05:43.460 --> 00:05:45.460
Achso, auch hier darf ich ja durch

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

00:05:47.300 --> 00:05:49.560
bald, nicht übermorgen, aber

00:05:49.560 --> 00:05:51.660
in ein paar Tagen und zwar

00:05:51.660 --> 00:05:53.340
auf Wunsch von GitHub, weil die gesagt haben, oh wir haben

00:05:53.340 --> 00:05:55.460
Schwierigkeiten, wissen nicht ob das

00:05:55.460 --> 00:05:56.880
funktioniert, wird für wir die als alle diese

00:05:56.880 --> 00:05:59.440
Issues erzeugen und so, wartet

00:05:59.440 --> 00:06:00.080
lieber nochmal ein bisschen

00:06:00.080 --> 00:06:03.520
Okay, ja gut, das ist jetzt nicht mehr so lange

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

00:06:05.400 --> 00:06:06.560
vielleicht schon migriert

00:06:06.560 --> 00:06:08.180
oder kurz davor

00:06:08.180 --> 00:06:10.920
Und gestern am 4.4. ist tatsächlich

00:06:10.920 --> 00:06:14.760
20 Jahre.

00:06:15.200 --> 00:06:16.800
Das ist auch ein richtiger

00:06:16.800 --> 00:06:19.380
Meilenstein. Hätte ich jetzt auch nicht gedacht,

00:06:19.520 --> 00:06:21.200
aber das ist natürlich alles

00:06:21.200 --> 00:06:21.580
irgendwie

00:06:21.580 --> 00:06:24.620
Zeitgefühl, komische Sache.

00:06:24.740 --> 00:06:26.460
Schon ein bisschen abgehangen, wie man alt wird.

00:06:26.620 --> 00:06:29.300
Ja, aber Python ist total wichtig, super. Also immer wenn man sich fragt,

00:06:29.680 --> 00:06:29.940
okay,

00:06:31.380 --> 00:06:33.200
Python selber langsam, aber

00:06:33.200 --> 00:06:35.320
macht trotzdem Dinge schnell und so.

00:06:35.320 --> 00:06:36.860
Wie geht denn das eigentlich? Ja, da ist meistens

00:06:36.860 --> 00:06:38.020
Python daran beteiligt und

00:06:38.020 --> 00:06:40.820
ja, tolles Projekt.

00:06:40.920 --> 00:06:42.780
irgendwie, man schreibt so eine Python-ähnliche

00:06:42.780 --> 00:06:44.900
Syntax und das wird dann

00:06:44.900 --> 00:06:46.180
halt in C

00:06:46.180 --> 00:06:48.780
Cross-Conviled sozusagen und dann... Man kann auch die Funktion

00:06:48.780 --> 00:06:50.860
direkt laden, glaube ich, wenn man das möchte. Ja, genau.

00:06:51.120 --> 00:06:52.700
Und dann kann man es wieder einbinden als

00:06:52.700 --> 00:06:54.700
Python-Modul und dann gibt es sogar

00:06:54.700 --> 00:06:56.600
sowas wie ein Cell Magic

00:06:56.600 --> 00:06:58.800
in Jupyter Notebooks oder Jupyter Lab

00:06:58.800 --> 00:07:00.800
und da kann man einfach sagen, Prozent, Prozent

00:07:00.800 --> 00:07:02.720
Zeiten und dann wird

00:07:02.720 --> 00:07:04.660
das halt mit der Funktion

00:07:04.660 --> 00:07:06.440
einfach so wieder reimportiert und dann

00:07:06.440 --> 00:07:07.940
wird die halt tausendmal schneller oder so.

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

00:07:09.560 --> 00:07:10.780
Ja

00:07:10.780 --> 00:07:13.380
Ja, okay

00:07:13.380 --> 00:07:15.660
Kennst du V, die Language

00:07:15.660 --> 00:07:16.640
V-Lang

00:07:16.640 --> 00:07:20.780
Bin ich irgendwie letztens drüber gestolpert, weil ein Kollege mich draufbrachte

00:07:20.780 --> 00:07:22.400
und hab ich mal geguckt

00:07:22.400 --> 00:07:24.180
kannte ich noch nicht, ist nur noch in so einer Beta-Version

00:07:24.180 --> 00:07:25.540
Sieht irgendwie witzig aus

00:07:25.540 --> 00:07:28.400
so eine Kombination von Rust und Go

00:07:28.400 --> 00:07:29.060
irgendwie

00:07:29.060 --> 00:07:32.080
Momentan ist auch wieder so die Zeit für neue

00:07:32.080 --> 00:07:34.200
Programmiersprachen, ne, letztens hab ich gehört

00:07:34.200 --> 00:07:34.820
von SICK

00:07:34.820 --> 00:07:37.320
SICK? Das ist auch so ein

00:07:37.320 --> 00:07:39.080
ein toller, lustiger Name, dass das wieder so

00:07:39.080 --> 00:07:40.520
drüber fällt, aber den Namen direkt so

00:07:40.520 --> 00:07:45.200
Ja, das sieht auch so ein bisschen aus wie eine Kreuzung

00:07:45.200 --> 00:07:46.760
aus Go und JavaScript

00:07:46.760 --> 00:07:49.260
und irgendwie Rust

00:07:49.260 --> 00:07:50.720
und weiß nicht ganz vielen Dingen.

00:07:51.560 --> 00:07:53.040
Also ich habe es noch nicht reingeguckt, also falls

00:07:53.040 --> 00:07:54.700
ihr darüber was wisst, das könnte auch interessant sein.

00:07:54.920 --> 00:07:55.720
Also wie lang IO?

00:07:56.440 --> 00:07:58.000
Okay, ich muss es mir auch mal angucken.

00:08:00.120 --> 00:08:00.880
Komplett Auto C,

00:08:01.040 --> 00:08:01.880
deswegen kam ich gerade drauf.

00:08:02.280 --> 00:08:05.100
Ach so, ah, okay, das ist auch interessant.

00:08:06.560 --> 00:08:06.720
Ja.

00:08:07.320 --> 00:08:08.680
Witzig.

00:08:09.940 --> 00:08:10.160
Ja.

00:08:11.600 --> 00:08:12.160
Ja.

00:08:12.900 --> 00:08:15.280
Okay, dann sind wir eigentlich schon fast...

00:08:15.280 --> 00:08:16.140
Das war diesmal schnell.

00:08:16.680 --> 00:08:17.940
Ja, wir haben gar nicht viel in den Lügen bleiben.

00:08:18.180 --> 00:08:19.980
Dann sind wir damit eigentlich durch.

00:08:19.980 --> 00:08:21.740
Achso, haben wir eigentlich

00:08:21.740 --> 00:08:23.000
Veranstaltungshinweise oder sowas?

00:08:23.820 --> 00:08:24.540
Ja, das wollten wir...

00:08:24.540 --> 00:08:26.200
Achso, du wolltest zur PyCon, bist du da?

00:08:27.780 --> 00:08:29.320
Momentan sieht es nicht danach aus.

00:08:30.280 --> 00:08:31.280
Ich hätte jetzt zufällig...

00:08:31.280 --> 00:08:32.360
Zuerst hatte ich gedacht,

00:08:33.220 --> 00:08:36.400
das schaffe ich irgendwie nicht,

00:08:36.400 --> 00:09:06.380
und Jochen unterhalten sich über die Programmiersprache Python

00:09:06.400 --> 00:09:08.200
Tickets. Und dann dachte ich, ich hätte keine Zeit.

00:09:08.320 --> 00:09:10.320
Und dann habe ich dann gemerkt, oh, ich habe vielleicht

00:09:10.320 --> 00:09:11.840
doch Zeit und dann waren aber keine Tickets mehr da.

00:09:11.960 --> 00:09:13.240
Insofern, ja.

00:09:14.720 --> 00:09:16.180
Aber vielleicht machen wir auch nochmal

00:09:16.180 --> 00:09:18.420
eine Sendung oder so dazu, wie das da gewesen

00:09:18.420 --> 00:09:20.260
ist und finden noch Leute, die da waren

00:09:20.260 --> 00:09:21.060
und dann davon erzählen können.

00:09:21.060 --> 00:09:21.660
Ja, das werden die mal fragen.

00:09:22.440 --> 00:09:23.500
Genau, den habe ich schon gefragt.

00:09:24.240 --> 00:09:26.040
Hat sich auch schon gemeldet und weiter eigentlich auch.

00:09:26.400 --> 00:09:28.540
Okay, cool. Also gibt es doch irgendwann eine PyCon-Folge.

00:09:28.660 --> 00:09:30.180
Ja. Im Sommer, die

00:09:30.180 --> 00:09:32.920
EuroPython-Tickets sind auch gerade draußen. Da gibt es sogar noch welche von, glaube ich.

00:09:32.940 --> 00:09:34.740
Es war noch nicht so super angelaufen, der

00:09:34.740 --> 00:09:36.400
vorverkauft, obwohl die so schnell immer weg waren.

00:09:37.180 --> 00:09:37.960
Genau, da.

00:09:38.260 --> 00:09:40.240
In Dublin, also wenn ihr mit mir abends in Dublin

00:09:40.240 --> 00:09:42.460
ein Bierchen trinken wollt. Da könnte es auch gut sein,

00:09:42.740 --> 00:09:43.840
dass ich damit komme.

00:09:44.820 --> 00:09:45.860
Würde ich gerne machen.

00:09:46.240 --> 00:09:48.100
Ich bin gespannt. Und dann gibt es noch die,

00:09:48.260 --> 00:09:49.740
also gut, dass jetzt nicht mehr so

00:09:49.740 --> 00:09:52.480
Konferenzcenter in Dublin ist, relativ nah an der

00:09:52.480 --> 00:09:53.820
Brewdog-Außenstelle.

00:09:55.120 --> 00:09:55.840
Brewdog-Brewing.

00:09:55.840 --> 00:09:56.440
Ja, genau.

00:09:57.460 --> 00:10:01.020
Das Angenehme mit dem Nützlichen.

00:10:01.480 --> 00:10:02.900
Ja, super Feminu.

00:10:04.740 --> 00:10:20.740
Genau, und im Herbst, irgendwann im September, gibt es die DjangoCon EU, diesmal auch tatsächlich vor Ort und in Porto. Die sollte ja eigentlich letzten beiden Jahren in Porto stattfinden, aber hat sie ja nicht. Und genau da denke ich ja wahrscheinlich leider nicht, weil irgendwie so viele Konferenzen...

00:10:20.740 --> 00:10:21.520
Ist Johannes da?

00:10:22.960 --> 00:10:25.840
Habe ich noch nicht gefragt, aber wer auf jeden Fall da ist, ist Ronny.

00:10:25.960 --> 00:10:27.480
Ronny, das stimmt, das ganze Team.

00:10:27.760 --> 00:10:30.240
Ja, das finde ich ein bisschen schade, das wäre natürlich nett.

00:10:30.420 --> 00:10:31.080
Das wäre schön, ja.

00:10:31.080 --> 00:10:35.120
Ja, jetzt haben wir doch noch ein bisschen

00:10:35.120 --> 00:10:36.180
News gemacht.

00:10:36.180 --> 00:10:37.280
Okay, gut.

00:10:37.540 --> 00:10:39.920
Dann kommt jetzt wieder der obligatorische Werbeblock, habt ihr schon gehört?

00:10:40.980 --> 00:10:42.240
Und diesmal ist Janis da.

00:10:42.280 --> 00:10:43.140
Janis darf Werbung machen.

00:10:43.320 --> 00:10:45.940
Ich darf Werbung machen als Neuling.

00:10:46.100 --> 00:10:46.980
Ja, wofür mache ich Werbung?

00:10:47.380 --> 00:10:49.300
Ich mache Werbung für meinen Arbeitgeber.

00:10:49.440 --> 00:10:52.080
Ich arbeite bei Elio, wir machen Consulting

00:10:52.080 --> 00:10:54.080
mit Fokus auf

00:10:54.080 --> 00:10:56.040
künstliche Intelligenz und

00:10:56.040 --> 00:10:57.820
den Weg dahin, alles was dazu gehört.

00:10:57.980 --> 00:10:58.820
Und ihr sucht neue Leute?

00:10:59.000 --> 00:11:00.200
Wir suchen neue Leute, genau.

00:11:01.080 --> 00:11:03.020
Wie hieß die Domain nochmal? Ich versuche die gerade.

00:11:03.280 --> 00:11:04.600
Elio? Elio.de

00:11:04.600 --> 00:11:07.320
A-I-L-I-O.de

00:11:07.320 --> 00:11:09.060
Quasi AI

00:11:09.060 --> 00:11:10.840
im Namen. Ist Programm,

00:11:11.140 --> 00:11:12.860
wenn man so möchte. Genau, und

00:11:12.860 --> 00:11:14.880
wir suchen neue Leute, immer. Also

00:11:14.880 --> 00:11:16.700
es ist wahrscheinlich sogar ziemlich egal,

00:11:16.980 --> 00:11:18.040
wann du die Folge hörst.

00:11:18.920 --> 00:11:21.100
Wir suchen dich. Was müssen die Leute

00:11:21.100 --> 00:11:23.020
können, die zu euch kommen? Wir

00:11:23.020 --> 00:11:24.880
haben einen Fokus auf künstliche

00:11:24.880 --> 00:11:26.740
Intelligenz, also Data Science,

00:11:26.860 --> 00:11:28.560
Machine Learning, Deep Learning,

00:11:29.600 --> 00:11:30.940
NLP, das ist natürlich super

00:11:30.940 --> 00:11:33.000
interessant, wenn man

00:11:33.000 --> 00:11:34.460
sich damit schon mal auseinandergesetzt hat.

00:11:35.560 --> 00:11:37.100
Aber auch ganz, ganz normale

00:11:37.100 --> 00:11:38.960
Backend-Tools, sage ich jetzt mal,

00:11:39.040 --> 00:11:41.040
sind sehr herzlich willkommen und sehr gerne

00:11:41.040 --> 00:11:42.920
gesehen. Generell haben

00:11:42.920 --> 00:11:44.900
wir den Ansatz, dass

00:11:44.900 --> 00:11:47.320
man wunderbar in Rollen hineinwachsen

00:11:47.320 --> 00:11:49.060
kann und wir

00:11:49.060 --> 00:11:50.800
jeden dabei unterstützen wollen. Das heißt, wenn Pandas

00:11:50.800 --> 00:11:52.260
ein Lieblings-Tool ist, ist das vielleicht auch interessant?

00:11:52.800 --> 00:11:54.760
Welches Tool? Pandas. Pandas, ja klar.

00:11:55.600 --> 00:11:57.180
Sicher, ist ja Data Science.

00:11:57.400 --> 00:11:58.900
Ja, der Python passt natürlich eigentlich

00:11:58.900 --> 00:12:00.120
schon ziemlich gut zusammen und

00:12:00.120 --> 00:12:01.320
und kann man da dann

00:12:01.320 --> 00:12:03.260
wahrscheinlich auch remote arbeiten oder so?

00:12:03.420 --> 00:12:05.120
Eigentlich sitzt die von meinem Bielefeld, sehe ich gerade.

00:12:05.400 --> 00:12:06.580
Genau, wir sitzen in Bielefeld.

00:12:07.180 --> 00:12:08.800
Remote Arbeit. Ich arbeite

00:12:08.800 --> 00:12:11.320
sehr viel remote. Wir haben immer so

00:12:11.320 --> 00:12:13.460
einen Stammtisch irgendwie, damit man sich doch auch mal in Person

00:12:13.460 --> 00:12:14.900
sieht, aber rein

00:12:14.900 --> 00:12:17.520
optional, sage ich jetzt mal.

00:12:18.480 --> 00:12:18.840
Insofern

00:12:18.840 --> 00:12:21.240
sind wir gespannt. Klingt gut. Also falls ihr

00:12:21.240 --> 00:12:22.460
doch sucht, dann schaut doch mal da vorbei.

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

00:12:25.260 --> 00:12:26.860
und Kollegen. Mindestens einer.

00:12:28.340 --> 00:12:28.740
Mindestens.

00:12:28.740 --> 00:12:32.120
Ja, vielleicht auch mehr, ich habe davon gehört

00:12:32.120 --> 00:12:33.940
Du musst jetzt noch persönliche Coachings

00:12:33.940 --> 00:12:36.260
und Benefits anbieten von dir aus, damit das dann

00:12:36.260 --> 00:12:37.680
Ja, würde ich natürlich machen

00:12:37.680 --> 00:12:39.840
Also wenn du Hörer der Folge bist

00:12:39.840 --> 00:12:41.820
und so begeistert von mir bist

00:12:41.820 --> 00:12:43.160
Genau, Aktionskurs

00:12:43.160 --> 00:12:43.520
Ja

00:12:43.520 --> 00:12:48.220
Schrei mich an, genau, eine E-Mail-Adresse

00:12:48.220 --> 00:12:50.020
und eine Internetseite gibt es auch

00:12:50.020 --> 00:12:51.840
business.lu.de

00:12:51.840 --> 00:12:53.860
da könnt ihr euch gerne hinbewerben, ansonsten

00:12:53.860 --> 00:12:55.760
gibt es bestimmt auch irgendwo so einen Text, wo man

00:12:55.760 --> 00:12:57.160
sowas verlinken kann bei euch im Podcast

00:12:57.160 --> 00:12:58.680
Ja, und vielleicht genau, wenn man sich meldet,

00:12:58.800 --> 00:13:00.980
kann man auf jeden Fall den Link dazu sagen, dass das über

00:13:00.980 --> 00:13:03.440
Python-Podcasts, dass man sich da das gehört hat,

00:13:03.580 --> 00:13:05.080
weil dann kann man das vielleicht so ein bisschen

00:13:05.080 --> 00:13:07.500
irgendwie verfolgen.

00:13:08.020 --> 00:13:08.960
Da haben wir in der Fähigkeit bessere Chancen,

00:13:09.040 --> 00:13:10.260
da wissen wir auch, dass ihr schon das hatte.

00:13:10.560 --> 00:13:11.720
Genau, dass ihr interessiert seid.

00:13:13.140 --> 00:13:14.580
Keine Ahnung, ob das irgendjemand hört,

00:13:14.700 --> 00:13:16.200
der auf der Suche ist.

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

00:13:18.920 --> 00:13:20.600
gefragt in einem Interview,

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

00:13:23.100 --> 00:13:23.820
Das war ganz lustig.

00:13:23.820 --> 00:13:26.300
Python-Podcast ist mir

00:13:26.300 --> 00:13:27.980
vielleicht in den Sinn gekommen, vielleicht auch nicht.

00:13:29.060 --> 00:13:30.160
Ich wurde tatsächlich auch

00:13:30.160 --> 00:13:32.040
im Arbeitskontest von jemandem angesprochen,

00:13:32.480 --> 00:13:34.140
also der Projektmanager war, der für

00:13:34.140 --> 00:13:35.640
ein größeres Projekt irgendwie

00:13:35.640 --> 00:13:38.200
gehört hatte, was da so gibt und der einen Django-Podcast

00:13:38.200 --> 00:13:40.080
von uns gehört hat und da dachte ich so, oh cool, da warst du nicht der Typ

00:13:40.080 --> 00:13:41.520
mit dem Podcast. Ja, interessant.

00:13:41.940 --> 00:13:44.060
Ja, das hilft mir schon. Also das ist schon cool.

00:13:44.780 --> 00:13:45.900
Genau. Ja, schick.

00:13:46.100 --> 00:13:47.340
Super. Hört mal rein.

00:13:47.920 --> 00:13:49.580
Wenn ihr was sucht, wisst ihr jetzt wo.

00:13:49.980 --> 00:13:51.020
Oder nicht sucht und

00:13:51.020 --> 00:13:52.560
doch zu uns wollen.

00:13:53.820 --> 00:14:23.800
und Jochen unterhalten sich über die Programmiersprache Python

00:14:23.820 --> 00:14:53.800
und Jochen unterhalten sich über die Programmiersprache Python

00:14:53.820 --> 00:14:54.220
Services.

00:14:55.200 --> 00:14:56.420
Das ist die Meinung von Jan.

00:14:57.180 --> 00:14:58.180
Ja, okay.

00:14:58.180 --> 00:15:00.000
Da haben wir schon die Seiten

00:15:00.000 --> 00:15:01.960
geklärt.

00:15:03.160 --> 00:15:05.420
Ja, das ist ein bisschen plakativ.

00:15:06.040 --> 00:15:07.420
Wir werden mal noch sehen, ob das wirklich so ist

00:15:07.420 --> 00:15:07.820
am Ende.

00:15:08.820 --> 00:15:10.960
Ja, aber das ist doch genau spannend jetzt. Also du sagst,

00:15:11.060 --> 00:15:12.560
Microsoft Services sind quasi

00:15:12.560 --> 00:15:14.200
eine isolierte

00:15:14.200 --> 00:15:16.280
Funktionalität.

00:15:16.640 --> 00:15:16.960
Genau.

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

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

00:15:21.920 --> 00:15:23.400
Vielleicht ist das am einfachsten zu verstehen.

00:15:23.820 --> 00:15:37.600
Das heißt, es gibt ein Frontend und die bezieht dann ihre Quellen aus unterschiedlichen, ja, also ihre Bestandteile, ihre Logik aus unterschiedlichen Quellen. Aus dem jeweils einzelnen Microservice. Würdest du sagen, das ist eine gute Idee?

00:15:37.600 --> 00:15:42.580
Es gibt verschiedene Ansätze. Das ist das Thema Best Practice, sage ich jetzt mal.

00:15:43.120 --> 00:15:45.540
Und auch immer so ein bisschen ein Thema der Architektur.

00:15:45.720 --> 00:15:51.120
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.180 --> 00:15:55.960
Man kann sich natürlich verschiedene API-Endpunkte suchen und alle einzelnen anfragen.

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

00:15:58.300 --> 00:16:04.180
Da gibt es dann meistens API-Gateways, beziehungsweise eine Schnittstelle, die man anfragt, die verschiedene Endpunkte sammeln.

00:16:04.180 --> 00:16:07.840
Darüber hatte ich eben auch schon mal, glaube ich, ganz kurz mit Jochen

00:16:07.840 --> 00:16:09.880
gesprochen, weil es ja genau darum geht, also wer ist

00:16:09.880 --> 00:16:12.020
da nicht im Netz, wovon bekommt man das, wenn man jetzt ein Frontend

00:16:12.020 --> 00:16:13.960
hat, sollte das Frontend die einsammeln, einzeln

00:16:13.960 --> 00:16:15.620
oder holt man das von so einem Gateway ab oder

00:16:15.620 --> 00:16:17.020
wie macht man das am liebsten?

00:16:17.200 --> 00:16:19.900
Ja, keine Ahnung, also ich glaube

00:16:19.900 --> 00:16:21.900
wenn man das wirklich konsequent machen wollen würde

00:16:21.900 --> 00:16:23.820
dann müsste man ja auch ein Frontend, das sozusagen

00:16:23.820 --> 00:16:26.160
Mikrofrontends

00:16:26.160 --> 00:16:26.780
müsste man machen

00:16:26.780 --> 00:16:31.980
Da muss ich halt ehrlich sagen, ich mag kein Frontend

00:16:31.980 --> 00:16:34.160
Wer liefert denn das Mikrofrontend?

00:16:34.180 --> 00:16:36.320
aus. Also wenn man zum Beispiel in HTMLX das ausliefert,

00:16:36.400 --> 00:16:38.380
dann wäre ein Django ein sogenannte Spinne

00:16:38.380 --> 00:16:40.520
oder so ein Aggregator, ein Gabi-Gateway,

00:16:40.880 --> 00:16:42.400
obwohl ich jetzt das Wording da immer nicht ganz

00:16:42.400 --> 00:16:43.320
treffen finde, ehrlich gesagt.

00:16:44.900 --> 00:16:46.540
Das spielt dann letztlich ja

00:16:46.540 --> 00:16:48.260
keine große Rolle mehr,

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

00:16:50.360 --> 00:16:52.360
Seite. Also was ich mir jetzt halt da kompliziert drin

00:16:52.360 --> 00:16:54.180
vorstelle, ist, wenn ich so ganz viele verschiedene Zeug habe,

00:16:54.260 --> 00:16:56.260
aber ich habe ja eigentlich nur eine Anwendung, warum mache ich das nicht

00:16:56.260 --> 00:16:58.460
in der einen Anwendung direkt und habe dann diesen ganzen

00:16:58.460 --> 00:16:59.920
Gefummel mit dem ganzen

00:16:59.920 --> 00:17:02.420
drumherum nicht. Darüber wollen wir ja

00:17:02.420 --> 00:17:06.480
reden. Ja. Also, das ist ja das Ziel der Folge. War eine kurze Folge, wenn man das jetzt so einfach

00:17:06.480 --> 00:17:09.820
und so schnell... Ein Satz fertig, ja, danke schön. Heute haben wir euch nicht so lange...

00:17:09.820 --> 00:17:14.300
Nee, ganz so ist es natürlich nicht. Man muss halt auch mal sehen, welche verschiedenen Funktionalitäten

00:17:14.300 --> 00:17:18.120
man haben möchte. Wir sind jetzt im Bereich Web unterwegs, von deinem Beispiel.

00:17:18.580 --> 00:17:22.500
Das klingt erstmal sehr, sehr einfach. Web-Anwendung, ich meine, so eine Standard-Firmen-Webseite

00:17:22.500 --> 00:17:25.620
meinetwegen mit einem Kontaktformular, da braucht man keine Microservices für, das stimmt schon.

00:17:26.200 --> 00:17:30.120
Aber wenn wir jetzt zum Beispiel mal eine Kurs-Webseite meinetwegen sehen, wo wir

00:17:30.120 --> 00:18:00.100
und Jochen unterhalten sich über die Programmiersprache Python

00:18:00.120 --> 00:18:02.120
Hake ich an der Stelle mal ein und sage mal so,

00:18:02.200 --> 00:18:04.340
was ich denken würde, was Microservice ist

00:18:04.340 --> 00:18:06.200
und ich würde denken, der entscheidende

00:18:06.200 --> 00:18:07.920
Punkt dabei ist eben die Einheit,

00:18:08.120 --> 00:18:09.920
wie deployed man das. Also alles, was man

00:18:09.920 --> 00:18:11.900
wenn man es insgesamt,

00:18:12.060 --> 00:18:14.200
wenn man es halt getrennt deployt, dann ist es halt ein Microservice,

00:18:14.600 --> 00:18:15.540
würde ich jetzt mal so sagen.

00:18:17.160 --> 00:18:18.280
Oder getrennt

00:18:18.280 --> 00:18:20.100
deployen kann und also wenn es

00:18:20.100 --> 00:18:22.360
halt irgendwie, wenn die gesamte

00:18:22.360 --> 00:18:24.020
Applikation etwas ist, was man insgesamt deployt,

00:18:24.060 --> 00:18:25.660
dann ist es halt irgendwie eher ein Monolith.

00:18:26.360 --> 00:18:28.060
Und eben, Microservice hat halt den Vorteil,

00:18:28.060 --> 00:18:58.040
und Jochen unterhalten sich über die Programmiersprache Python

00:18:58.060 --> 00:18:58.440
von Texas.

00:19:00.160 --> 00:19:00.560
Hilfe!

00:19:01.580 --> 00:19:03.960
Das ist quasi so, ja, also Dinge, die

00:19:03.960 --> 00:19:05.940
halt irgendwie so zusammengehören und nur

00:19:05.940 --> 00:19:06.940
gemeinsam verändert werden sollen.

00:19:07.380 --> 00:19:09.320
Ich glaube, das Standardbeispiel auch eben aus dem

00:19:09.320 --> 00:19:10.980
Designbuch ist halt sowas wie

00:19:10.980 --> 00:19:13.540
eine Bestellung

00:19:13.540 --> 00:19:16.080
und die Punkte, die einzelnen Positionen

00:19:16.080 --> 00:19:17.980
auf einer Bestellung oder so, will man vielleicht

00:19:17.980 --> 00:19:20.060
das Ding will man immer zusammen

00:19:20.060 --> 00:19:22.060
verändern. Das heißt, man holt das insgesamt aus der Datenbank,

00:19:22.380 --> 00:19:23.960
macht irgendwelche Änderungen und streibt es halt

00:19:23.960 --> 00:19:26.020
in einer Transaktion wieder irgendwie in die Datenbank rein oder so.

00:19:26.480 --> 00:19:27.240
Und das ist halt sozusagen ein,

00:19:27.240 --> 00:19:28.960
im Baune-Kontext eben.

00:19:29.440 --> 00:19:30.700
Ja, das ist aber eine spannende Frage.

00:19:30.860 --> 00:19:33.020
Was gehört halt dazu oder nicht? Also bei einer Bestellung

00:19:33.020 --> 00:19:34.640
und deren Position geht es vielleicht noch,

00:19:35.020 --> 00:19:36.980
aber wenn du jetzt an den zuständigen Sachbearbeiter

00:19:36.980 --> 00:19:39.000
beispielsweise denkst, der irgendwie im Innen- oder

00:19:39.000 --> 00:19:41.060
Außendienst hängt, ist die Frage, gehört das dann

00:19:41.060 --> 00:19:43.100
zum Baune-Kontext da dazu oder holt man das

00:19:43.100 --> 00:19:43.800
aus einem CRM?

00:19:44.440 --> 00:19:47.060
Ich glaube auch, der Grund, vielleicht der Name,

00:19:47.260 --> 00:19:48.860
das kommt daher, dass es halt unterschiedliche

00:19:48.860 --> 00:19:50.700
Dinge in unterschiedlichen Kontexten bedeuten kann.

00:19:50.940 --> 00:19:52.980
Also zum Beispiel User ist halt was anderes, wenn du dich

00:19:52.980 --> 00:19:54.660
auf einer Webseite einloggen möchtest

00:19:54.660 --> 00:19:56.840
oder kann halt was anderes sein, als

00:19:56.840 --> 00:19:59.060
User oder Personen,

00:19:59.200 --> 00:20:00.820
an die irgendwas geschickt wird im Kontext

00:20:00.820 --> 00:20:01.560
einer

00:20:01.560 --> 00:20:04.500
Bestellung oder so.

00:20:04.700 --> 00:20:06.760
Und in dem einen Fall hat man halt da komplizierte

00:20:06.760 --> 00:20:08.720
Adressgeschichten und weißer Teufel irgendwie Zeugs

00:20:08.720 --> 00:20:11.020
und im anderen Fall braucht man das gar nicht, weil da muss man nur überprüfen,

00:20:11.460 --> 00:20:12.600
stimmt der Passwort-Hash oder so.

00:20:13.600 --> 00:20:14.740
Und ja,

00:20:14.820 --> 00:20:16.780
je nachdem, welchen Kontext man unterwegs

00:20:16.780 --> 00:20:18.400
ist, ist das halt

00:20:18.400 --> 00:20:20.580
unterschiedlich und man erlaubt dann halt auch

00:20:20.580 --> 00:20:22.920
unterschiedlichen Kontexten die Daten unterschiedlich

00:20:22.920 --> 00:20:24.880
zu halten und unterschiedliche Sachen zu speichern und so.

00:20:24.880 --> 00:20:26.480
Okay, interessant. Also Bounded Context

00:20:26.480 --> 00:20:30.180
abstrahiert das so ein bisschen. Was aber jetzt dafür sprechen würde, in dem Beispiel, was du gesagt hast,

00:20:30.320 --> 00:20:32.940
braucht man ja irgendwie eine Wahrheit der Daten.

00:20:34.580 --> 00:20:36.980
Ja, das ist dann glaube ich, dann wird es ein bisschen schwieriger.

00:20:37.840 --> 00:20:41.060
Single point of truth. Das ist eine Herausforderung.

00:20:41.720 --> 00:20:46.060
Also ich sage jetzt mal, das ist eine ganz gängige Frage.

00:20:46.060 --> 00:20:50.200
Wer lässt man den in Microservices? Und eine Frage,

00:20:50.280 --> 00:20:52.520
die damit einhergeht, ist immer das Datenmanagement.

00:20:52.520 --> 00:20:57.860
Vielleicht noch mal kurz, Entschuldigung, dass ich euch gerade direkt eingreife, aber was heißt Datenmanagement?

00:20:58.780 --> 00:21:03.840
Ein Microservice, beziehungsweise Microservices allgemein zeichnen sich ja dadurch aus, dass das isolierte Systeme sind.

00:21:04.040 --> 00:21:08.200
Also im Idealfall hält jeder Microservice genau die Daten, die er braucht oder eben nicht.

00:21:08.480 --> 00:21:14.520
Und wenn er die Daten nicht hält, muss er natürlich überlegen, woher kriege ich meine Daten eigentlich und wie kriege ich sie.

00:21:15.140 --> 00:21:18.160
Und dann gibt es eben verschiedene Möglichkeiten, damit umzugehen.

00:21:18.160 --> 00:21:19.460
Ich könnte zum Beispiel mal irgendwie hier

00:21:19.460 --> 00:21:21.860
AP-Request gegen irgendeinen anderen Microservice

00:21:21.860 --> 00:21:23.860
machen, meinetwegen, und hole von da meine Daten.

00:21:24.280 --> 00:21:26.100
Habe dann aber den Nachteil, okay, das ist langsam

00:21:26.100 --> 00:21:27.780
und irgendwie kopple ich meine Microservices

00:21:27.780 --> 00:21:28.500
dann wieder zusammen.

00:21:28.700 --> 00:21:32.020
Wenn es hinterher dieselbe Datenbank liegt, dann ist da die Frage,

00:21:32.140 --> 00:21:33.620
warum macht man da eine unterrichtliche Akzeptur?

00:21:34.040 --> 00:21:35.700
Aber vielleicht kann auch das man machen, wenn

00:21:35.700 --> 00:21:38.180
ich halt irgendwie hingehe und möchte aus derselben Datenbank

00:21:38.180 --> 00:21:39.940
Dinge erzeugen mit unterschiedlichen Sprachen

00:21:39.940 --> 00:21:40.740
und die dann...

00:21:40.740 --> 00:21:44.080
Und dieselbe Datenbank wird schwierig,

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

00:21:46.000 --> 00:21:47.440
Also wenn jetzt zum Beispiel auf der, wenn es

00:21:47.440 --> 00:21:49.900
und gemeinsamen Datenbank hast und du änderst die jetzt?

00:21:50.260 --> 00:21:51.940
Na gut, er kann ja einfach den Datenbank-Ding deployen.

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

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

00:21:56.020 --> 00:21:58.220
Ja, aber da kannst du es nicht mehr unabhängig deployen,

00:21:58.300 --> 00:21:59.940
weil wenn du jetzt die Datenbank änderst,

00:22:00.040 --> 00:22:01.300
dann hat das ja Auswirkungen auf den anderen.

00:22:01.600 --> 00:22:03.320
Hat das ja auch Auswirkungen auf die anderen Services.

00:22:03.740 --> 00:22:06.280
Ja, und es ist ein Single-Pointer-Failure.

00:22:06.480 --> 00:22:09.840
Also da rede ich aus ganz, ganz schmerzhafter Erfahrung.

00:22:10.260 --> 00:22:12.400
Wenn verschiedene Services an einer Datenbank hängen,

00:22:12.600 --> 00:22:14.720
verschiedene Microservices, und die Datenbank kippt um,

00:22:14.720 --> 00:22:16.260
dann kippen dir die Microservices auch um.

00:22:16.260 --> 00:22:18.600
weil irgendjemand Stuss gemacht hat.

00:22:19.000 --> 00:22:20.260
Das will man eigentlich auch vermeiden.

00:22:20.480 --> 00:22:23.120
Also das ist so ein Shared-Datenbank-Anti-Pattern

00:22:23.120 --> 00:22:23.440
heißt das.

00:22:24.720 --> 00:22:26.560
Das macht man manchmal,

00:22:26.980 --> 00:22:28.520
weil es einfach schnell ist, weil es einfach

00:22:28.520 --> 00:22:30.380
einfach ist. Aber wenn man wirklich

00:22:30.380 --> 00:22:32.300
Microservice macht und sie wirklich braucht, dann ist das

00:22:32.300 --> 00:22:34.360
eigentlich mal eine relativ schlechte Idee, wenn man sich

00:22:34.360 --> 00:22:36.080
da doch, wie gesagt, den

00:22:36.080 --> 00:22:37.380
Single-Point-of-Fail reinholt.

00:22:38.800 --> 00:22:40.540
Aber ja, eigentlich hat jeder Service

00:22:40.540 --> 00:22:42.380
seine eigene Daten, seine eigene Datenbank

00:22:42.380 --> 00:22:43.560
und du musst halt überlegen, okay,

00:22:43.560 --> 00:22:47.540
Will ich jetzt mehrfach die gleichen Daten in verschiedenen Microservices verteilen?

00:22:47.880 --> 00:22:53.280
Oder will ich dafür sorgen, dass sich die einzelnen Microservices die Daten von anderen Microservices holen

00:22:53.280 --> 00:22:56.440
und erzeuge damit eine Kopplung und mache die Sache vielleicht ein bisschen unübersichtlicher,

00:22:56.560 --> 00:22:57.280
vielleicht ein bisschen langsamer?

00:22:57.920 --> 00:22:59.760
Und das beschreibt eben das Datenbankmanagement.

00:23:00.040 --> 00:23:04.720
Das heißt, wir haben viele Datenreplikationen an unterschiedlichen Stellen

00:23:04.720 --> 00:23:08.720
und das macht natürlich den Punkt der Wahrheit, wie es so schön sagt, extrem schwierig.

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

00:23:10.860 --> 00:23:12.680
also wo kommen die Daten überhaupt her

00:23:12.680 --> 00:23:13.920
und wo sollen die hin

00:23:13.920 --> 00:23:16.820
und dann, ja, also ist ja die Frage, ist das eine

00:23:16.820 --> 00:23:18.180
Architekturentscheidung, wenn du jetzt sagst,

00:23:18.300 --> 00:23:19.800
Design, Domain dürfen Design

00:23:19.800 --> 00:23:21.780
was würde denn da?

00:23:21.900 --> 00:23:24.860
Damit sind noch keine Architekturentscheidungen

00:23:25.880 --> 00:23:26.740
gefallen quasi

00:23:26.740 --> 00:23:28.860
damit ist es halt einfach nur so ein

00:23:29.400 --> 00:23:31.060
Konzept, wie man Dinge angehen könnte

00:23:31.060 --> 00:23:31.760
aber...

00:23:31.760 --> 00:23:34.680
Stell das ja so ein bisschen in den Raum dann vielleicht, also die Wahl

00:23:34.680 --> 00:23:35.920
Ja, also

00:23:35.920 --> 00:23:38.680
ich weiß es nicht, ich meine, es ist halt die Frage

00:23:40.860 --> 00:23:41.380
und

00:23:41.380 --> 00:23:42.780
ob man

00:23:42.780 --> 00:23:45.200
tja, also

00:23:45.200 --> 00:23:47.580
in der Vorbereitung habe ich jetzt mal

00:23:47.580 --> 00:23:49.300
so einen Podcast auch gehört,

00:23:50.560 --> 00:23:51.580
wo da gibt es

00:23:51.580 --> 00:23:53.260
irgendwie ein Buch, das immer empfohlen wird

00:23:53.260 --> 00:23:54.720
zu Microsoft Services von Sam Newman

00:23:54.720 --> 00:23:57.380
und der ist auch in diversen Podcasts schon zu Gast

00:23:57.380 --> 00:23:59.600
gewesen und der sagte

00:23:59.600 --> 00:24:00.860
dann dazu quasi so

00:24:00.860 --> 00:24:02.460
naja,

00:24:03.660 --> 00:24:03.880
also

00:24:03.880 --> 00:24:07.460
das mit den Datenbanken ist ja so eine Sache, also wenn

00:24:07.460 --> 00:24:09.280
das funktioniert, wenn man halt eine Datenbank haben kann

00:24:09.280 --> 00:24:11.240
und so und dann sollte man das schon machen, weil

00:24:11.240 --> 00:24:13.380
es gibt ja Grundformen, die so verbreitet sind

00:24:13.380 --> 00:24:15.520
und sich so lange gehalten haben und alle die benutzen.

00:24:17.140 --> 00:24:17.680
Und wenn man

00:24:17.680 --> 00:24:18.100
das halt

00:24:18.100 --> 00:24:21.240
nicht kann, gut, weil man halt

00:24:21.240 --> 00:24:23.260
Microsoft das machen muss, dann okay.

00:24:23.680 --> 00:24:25.360
Da muss man sich halt was überlegen, dann wird es halt schwierig.

00:24:26.880 --> 00:24:27.180
Und dann

00:24:27.180 --> 00:24:29.420
derjenige, der in den Interview mit hatte, fragte

00:24:29.420 --> 00:24:31.500
dann halt auch so, ja kann man denn dann irgendwie was tun,

00:24:31.740 --> 00:24:33.420
um Datenbanken schon

00:24:33.420 --> 00:24:35.280
drauf auszulegen, dass man die dann vielleicht trennen kann oder

00:24:35.280 --> 00:24:37.520
kann man das irgendwie Architektur, und dann meinte er so, ja das kann man,

00:24:37.600 --> 00:24:38.320
warum sollte man das tun?

00:24:38.320 --> 00:24:40.460
ist. Man muss der Datenbank schreckliche

00:24:40.460 --> 00:24:41.820
Dinge antun, damit das geht.

00:24:42.280 --> 00:24:43.600
Das muss einem halt klar sein.

00:24:44.520 --> 00:24:46.300
Also, ja, es geht schon,

00:24:46.460 --> 00:24:48.360
aber die Frage wäre, würde

00:24:48.360 --> 00:24:50.260
man so anfangen wollen? Und da denke ich, ja,

00:24:51.480 --> 00:24:52.640
warum nicht einfach mit einem ganz normalen

00:24:52.640 --> 00:24:54.340
Datenbankschema anfangen? Genau, ja, aber

00:24:54.340 --> 00:24:56.360
das würde ja nicht für Microsoft versprechen,

00:24:56.500 --> 00:24:58.240
sondern für einen Monolithen oder einen Service, der

00:24:58.240 --> 00:24:59.800
es würde nicht dafür sprechen, damit anzufangen.

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

00:25:02.400 --> 00:25:04.300
warum man das macht. Also, ich würde jetzt auch so intuitiv

00:25:04.300 --> 00:25:06.340
sagen, du baust halt jetzt einmal dein Deployment

00:25:06.340 --> 00:25:08.020
für ein Tool, für eine Webman-Winne,

00:25:08.320 --> 00:25:10.180
und hast halt dann eine Datenbank dahinter und

00:25:10.180 --> 00:25:12.100
arbeitest dann damit

00:25:12.100 --> 00:25:14.280
und erweiterst sie halt. Und die Frage ist halt,

00:25:14.360 --> 00:25:16.460
wann komme ich denn überhaupt in diese

00:25:16.460 --> 00:25:18.000
Sphäre, dass ich sage,

00:25:18.120 --> 00:25:19.960
Microsoft ist jetzt eine gute Idee oder das

00:25:19.960 --> 00:25:21.400
hilft mir irgendwo bei?

00:25:23.540 --> 00:25:24.200
Das ist

00:25:24.200 --> 00:25:26.280
unterschiedlich. Vielleicht erstmal eingehakt

00:25:26.280 --> 00:25:28.220
noch bei diesem Datenbank-Auseinanderschneiden,

00:25:28.360 --> 00:25:29.860
das stelle ich mir sehr, sehr kompliziert vor.

00:25:30.300 --> 00:25:32.300
Das, was wesentlich einfacher ist, sich vorzustellen,

00:25:32.300 --> 00:25:34.140
ist, dass jeder Service tatsächlich seine eigene, echte

00:25:34.140 --> 00:25:36.280
Datenbank hat und man verteilt die Datenbank quasi

00:25:36.280 --> 00:25:38.200
auf verschiedene Microservices.

00:25:38.320 --> 00:25:39.440
in ganz normalen Datenbanken.

00:25:39.820 --> 00:25:42.380
Was du gesagt hast, das kam relativ

00:25:42.380 --> 00:25:42.900
kompliziert.

00:25:43.580 --> 00:25:47.360
Du hast ja das Problem, du hast ja eine verteilte

00:25:47.360 --> 00:25:48.480
Datenhaltung,

00:25:48.580 --> 00:25:50.900
wo du nicht einfach einen Join machen kannst, sondern du musst dann halt...

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

00:25:52.600 --> 00:25:54.680
selbst ist wesentlich komplizierter geworden,

00:25:54.820 --> 00:25:56.520
aber die Datenhaltung pro Service,

00:25:56.520 --> 00:25:57.680
die ist immer noch relativ einfach.

00:25:58.560 --> 00:26:00.020
Das muss man halt ganz klar sagen.

00:26:00.220 --> 00:26:02.420
Die einzelnen Microservices in sich,

00:26:02.460 --> 00:26:03.460
die sind unglaublich einfach.

00:26:04.140 --> 00:26:06.460
Wenn du zum Beispiel Monolithen hast, und da kommen wir direkt zu

00:26:06.460 --> 00:26:36.440
und Jochen unterhalten sich über die Programmiersprache Python

00:26:36.460 --> 00:26:38.920
und das würden jetzt, also Dinge, die halt

00:26:38.920 --> 00:26:40.860
eine Seite kaputt machen, andere Apps kaputt machen

00:26:40.860 --> 00:26:42.860
und wenn man jetzt beispielsweise in Django-Apps

00:26:42.860 --> 00:26:44.760
jetzt denkt, wenn man das parallel

00:26:44.760 --> 00:26:46.720
entwickelt, dann könnte man die ja voneinander

00:26:46.720 --> 00:26:47.180
trennen.

00:26:48.220 --> 00:26:49.740
Im besten Fall tut man das, ja.

00:26:50.660 --> 00:26:52.760
Also wenn die sich gegenseitig differenzieren, kommt man natürlich

00:26:52.760 --> 00:26:54.340
in so ein Dependency-Problem vielleicht.

00:26:55.840 --> 00:26:56.660
Ja, ja, ich glaube,

00:26:56.900 --> 00:26:58.740
also ich meine, das ist

00:26:58.740 --> 00:26:59.640
auch immer was, wo

00:26:59.640 --> 00:27:02.500
es geht eigentlich im Grunde,

00:27:02.560 --> 00:27:04.660
das zentrale Problem bei der Softwareentwicklung ist eben

00:27:04.660 --> 00:27:06.580
dieses Modularisierungsproblem. Das ist halt

00:27:06.580 --> 00:27:08.600
irgendwie so das Ding, was jeder hat und was

00:27:08.600 --> 00:27:10.660
irgendwie ganz einfach aussieht, wo alle sagen, ah, dann muss man

00:27:10.660 --> 00:27:12.120
halt ein bisschen modularisieren, kein Problem.

00:27:12.680 --> 00:27:14.220
Das ist aber tatsächlich sehr schwierig.

00:27:14.560 --> 00:27:16.300
Ja, User musst du sehr oft importieren.

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

00:27:18.160 --> 00:27:19.920
das ist schon doof dann wahrscheinlich.

00:27:20.940 --> 00:27:21.980
Ja, aber du kannst ja trotzdem

00:27:21.980 --> 00:27:24.400
sozusagen die Dinge irgendwie

00:27:24.400 --> 00:27:26.300
auseinanderhalten, die nichts miteinander

00:27:26.300 --> 00:27:28.420
zu tun haben. Wenn es nicht geht, dann geht es halt

00:27:28.420 --> 00:27:30.300
nicht. Aber dann kannst du immer noch die Abhängigkeiten

00:27:30.300 --> 00:27:32.440
explizit machen. Also man kann da schon

00:27:32.440 --> 00:27:34.020
was tun und man kann das richtig und falsch machen.

00:27:34.020 --> 00:27:35.700
und meistens machen sie es total falsch.

00:27:37.320 --> 00:27:37.720
Und

00:27:37.720 --> 00:27:40.120
die allerschlimmsten Geschichten sind dann halt,

00:27:40.240 --> 00:27:42.000
wenn man es halt verteilt falsch macht.

00:27:42.160 --> 00:27:42.500
Das ist halt,

00:27:43.920 --> 00:27:45.680
ja, insofern, ich bin auch so ein bisschen

00:27:45.680 --> 00:27:47.440
immer, also

00:27:47.440 --> 00:27:50.160
vorsichtig, weil häufig,

00:27:50.520 --> 00:27:52.100
was ich halt schon

00:27:52.100 --> 00:27:54.060
häufiger gesehen habe, ist, dass Leute dann sagen,

00:27:54.420 --> 00:27:56.260
also sie haben halt dieses Problem, das Standardproblem

00:27:56.260 --> 00:27:58.380
irgendwie, das alle haben in der Softwareentwicklung,

00:27:58.600 --> 00:28:00.360
irgendwie, sie kriegen ihren Kram halt nicht organisiert,

00:28:01.120 --> 00:28:01.720
so richtig

00:28:01.720 --> 00:28:03.820
strukturiert und nicht modularisiert.

00:28:04.020 --> 00:28:05.820
und dann

00:28:05.820 --> 00:28:08.540
nehmen sie halt irgendwie Teile, die kompliziert sind

00:28:08.540 --> 00:28:10.460
und machen daraus Mikroservices, weil sie

00:28:10.460 --> 00:28:11.860
sagen, ja, dann haben wir das irgendwie modularisiert.

00:28:12.040 --> 00:28:14.380
Das ist ja nicht so. Dann hat man es einfach nur verteilt.

00:28:14.700 --> 00:28:16.200
Das heißt, man hat ein Ding, was man nicht modularisiert hat,

00:28:16.240 --> 00:28:18.240
verteilt und dann hat man halt einen verteilten Monolithen

00:28:18.240 --> 00:28:19.680
und das ist halt...

00:28:19.680 --> 00:28:21.820
Das passiert leider sehr oft.

00:28:23.560 --> 00:28:24.280
Ja, insofern,

00:28:24.660 --> 00:28:26.560
genau. Aber ich glaube, dem kann man

00:28:26.560 --> 00:28:28.400
so ein bisschen entgehen, wenn man sich überlegt, am Anfang

00:28:28.400 --> 00:28:29.960
so, wofür will ich das eigentlich bauen?

00:28:30.300 --> 00:28:32.340
Warum mache ich das? Und dann geht das

00:28:32.340 --> 00:28:33.000
wahrscheinlich schon besser.

00:28:34.020 --> 00:28:36.340
Die Frage ist auch immer, ob man es besser oder schlimmer

00:28:36.340 --> 00:28:38.120
macht oder ob man überhaupt was am Zustand ändert.

00:28:38.300 --> 00:28:40.300
Ich meine, wenn man innerhalb seiner Architektur

00:28:40.300 --> 00:28:42.260
beziehungsweise innerhalb seines Codes Referenzen

00:28:42.260 --> 00:28:44.100
hat, dann hat man die ja automatisch nicht mehr nur,

00:28:44.200 --> 00:28:45.600
wenn man auf einmal Microsoft verwendet.

00:28:45.920 --> 00:28:47.640
Man verlagert das Problem.

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

00:28:50.420 --> 00:28:52.060
die Codebasis selbst wesentlich einfacher

00:28:52.060 --> 00:29:07.320
und manchmal l man auch einfach in eine Situation wo man feststellt okay die Funktion die ich jetzt hier machen m die ist in dem Umfeld in dem ich mich gerade bewege einfach super schwierig zu implementieren Das hei ich finde gar keinen geeigneten technischen Ansatz da mal ein Ding was einzubauen

00:29:07.320 --> 00:29:09.580
vielleicht ein ganz einfaches Beispiel.

00:29:09.700 --> 00:29:11.600
Wir haben jetzt eine Django-Anwendung und wir haben jetzt

00:29:11.600 --> 00:29:13.020
irgendwo, weiß ich nicht,

00:29:13.560 --> 00:29:15.340
RabbitMQ, Kafka, irgendwas rumliegen,

00:29:15.420 --> 00:29:17.540
irgendeine Queue, irgendein Topic und das

00:29:17.540 --> 00:29:19.360
will ich konsumieren. Und dann muss ich mal

00:29:19.360 --> 00:29:21.400
überlegen, gut, wie baue ich das möglichst elegant

00:29:21.400 --> 00:29:22.620
in eine Django-Anwendung ein?

00:29:23.120 --> 00:29:25.220
Dann habe ich da irgendwie permanent etwas

00:29:25.220 --> 00:29:26.680
parallel Laufenes, kann man machen.

00:29:27.240 --> 00:29:29.200
Die Frage ist, ob es sich natürlich anfühlt,

00:29:29.300 --> 00:29:31.460
ob es cool ist, ob man es wirklich so machen will.

00:29:31.540 --> 00:29:33.280
Also du willst eine Topic-Anwendung

00:29:33.280 --> 00:29:35.080
aufmachen zu einem Kafka oder

00:29:35.080 --> 00:29:36.600
einer anderen Queue?

00:29:37.320 --> 00:29:39.400
und ich würde es gar nicht mal so ausdrücken.

00:29:39.540 --> 00:29:41.960
Ich würde einfach mal den Sachverhalt an sich in den Raum stellen,

00:29:42.060 --> 00:29:45.280
dass ich einen Umstand habe, der sich einfach nicht natürlich fühlt,

00:29:45.300 --> 00:29:49.020
in die aktuelle Anwendung einzubinden und die man dann reinhackt unter Umständen

00:29:49.020 --> 00:29:55.600
oder wo man meinetwegen sagt, okay, ich finde jetzt in meiner jetzigen Architektur

00:29:55.600 --> 00:29:58.740
einfach allgemein keinen schönen Ansatz für das, was ich vorhabe.

00:30:00.100 --> 00:30:03.660
Weiß ich nicht. Es kann auch andere Gründe haben.

00:30:03.660 --> 00:30:11.940
Du hast einen riesen Monolithen, Django, und du hast meinetwegen einen Java-Entwickler,

00:30:12.060 --> 00:30:15.940
der eine andere Funktion in Java super cool machen kann, findet sich aber nicht im Django zurecht

00:30:15.940 --> 00:30:19.200
und überlegst, okay, macht es Sinn, für den jetzt einen eigenen Service aufzumachen oder nicht?

00:30:22.000 --> 00:30:26.080
Vielleicht geht das mehr so in die Richtung politische Entscheidung oder auch nicht,

00:30:26.960 --> 00:30:30.600
aber manchmal ist auch so das Skillset der Mitarbeiter, die du gerade hast,

00:30:30.600 --> 00:30:32.200
verleiten dich einfach dazu,

00:30:32.680 --> 00:30:34.640
zu sagen, okay, ich kann nicht alles in dieser

00:30:34.640 --> 00:30:36.600
einen Codebase lösen, ich kann nicht alles mit

00:30:36.600 --> 00:30:38.640
diesem einen Deployment lösen, vielleicht

00:30:38.640 --> 00:30:40.640
lagern wir das aus und vielleicht ziehen wir dadurch wirklich unsere

00:30:40.640 --> 00:30:41.140
Vorteile.

00:30:42.360 --> 00:30:43.600
Was ich halt da wieder

00:30:43.600 --> 00:30:46.700
an Problemen sehe, ist halt, wenn ich das jetzt

00:30:46.700 --> 00:30:48.520
tue, dann habe ich ja irgendwo

00:30:48.520 --> 00:30:50.600
den Hut nicht auf. Oder ich muss den

00:30:50.600 --> 00:30:52.820
Hut an einer Stelle aufsetzen und muss das dann dann wieder aggregieren,

00:30:53.140 --> 00:30:54.920
wo du jetzt vom API-Gateway sprachst.

00:30:55.280 --> 00:30:56.800
Also wenn ich diese Spinne im Netz sein will,

00:30:56.800 --> 00:30:58.360
die halt die Informationshoheit hat,

00:30:58.740 --> 00:31:00.280
die die Single Source of Truth irgendwie

00:31:00.280 --> 00:31:02.100
bereitstellen möchte.

00:31:02.680 --> 00:31:03.900
Das ist ja kein API-Gateway.

00:31:04.600 --> 00:31:06.500
Nein, gut, aber du hast halt andere Services,

00:31:06.640 --> 00:31:08.600
andere Teile der Applikation arbeiten

00:31:08.600 --> 00:31:10.600
irgendwo auf einer ganz anderen Maschine

00:31:10.600 --> 00:31:12.620
mit einem ganz anderen Deployment und die

00:31:12.620 --> 00:31:13.380
liefern mir irgendwas.

00:31:18.300 --> 00:31:19.900
Ich kann die auch schwer testen oder sowas.

00:31:20.140 --> 00:31:22.420
Wenn ich das aus meiner Seite, das muss halt eigentlich auf deren Seite

00:31:22.420 --> 00:31:24.440
getestet sein. Das heißt, ich gebe quasi

00:31:24.440 --> 00:31:25.640
die ganze Verantwortung

00:31:25.640 --> 00:31:27.000
weg.

00:31:27.240 --> 00:31:30.060
Du hast wahrscheinlich wesentlich mehr Integration-Tests

00:31:30.060 --> 00:31:32.140
erstmal, als du Monolithen hättest.

00:31:32.740 --> 00:31:33.880
Auf der anderen Seite sagt man ja,

00:31:34.100 --> 00:31:35.800
die einzelnen Services, die sind

00:31:35.800 --> 00:31:38.020
entkoppelt voneinander. Das heißt, wenn deiner läuft,

00:31:38.080 --> 00:31:39.700
hast du deinen Job gemacht und das ist erstmal alles gut.

00:31:40.180 --> 00:31:41.880
Und der andere muss dafür sorgen, dass sein Microservice

00:31:41.880 --> 00:31:43.960
läuft. Das heißt, man verlässt sich irgendwie aufeinander.

00:31:44.520 --> 00:31:45.800
Und ich habe so ein bisschen das Gefühl,

00:31:45.980 --> 00:31:48.520
dass das Problem, worauf du dich so ein bisschen einschießt,

00:31:48.640 --> 00:31:50.000
ist das größte Problem

00:31:50.000 --> 00:31:52.000
in Microservices allgemein. Das ist immer so

00:31:52.000 --> 00:31:54.000
eine Sache, die kann man unglaublich gut machen oder unglaublich schlecht

00:31:54.000 --> 00:31:56.060
machen. Oder man macht es einfach, wie man

00:31:56.060 --> 00:31:57.600
es macht. Also man bewegt sich irgendwo in der Mitte

00:31:57.600 --> 00:32:00.060
und mal funktioniert es richtig gut und mal nicht.

00:32:00.200 --> 00:32:02.300
Also das ist eine riesen Herausforderung, worüber du sprichst

00:32:02.300 --> 00:32:04.380
beim Single Point of Truth

00:32:04.380 --> 00:32:06.300
beziehungsweise auch das ganze

00:32:06.300 --> 00:32:08.200
Monitoring. Das ist ja wesentlich komplizierter

00:32:08.200 --> 00:32:09.120
in der Microservice-Welt.

00:32:10.840 --> 00:32:12.240
Weiß ich nicht, wenn du...

00:32:12.240 --> 00:32:14.240
Ja, wenn das meine eigene

00:32:14.240 --> 00:32:15.780
Organisation ist, die die Microservices macht,

00:32:16.120 --> 00:32:18.060
dann muss ich ja irgendwo dann trotzdem irgendeine Form

00:32:18.060 --> 00:32:19.860
von Infrastruktur einziehen jeweils,

00:32:20.260 --> 00:32:21.900
die dann irgendwie aggregiert bei mir halt,

00:32:21.960 --> 00:32:24.080
wie du sagst, Monitoring macht und da halt irgendwie die Logfiles raus

00:32:24.080 --> 00:32:25.860
passt oder irgendwie... Ja, du musst überhaupt mit sowas

00:32:25.860 --> 00:32:28.080
erst mal anfangen und wir haben das möglicherweise eben noch nicht.

00:32:28.340 --> 00:32:30.700
Das ist auch das erste Projekt,

00:32:30.760 --> 00:32:32.020
was er vorschlägt, wenn man sich dann tatsächlich

00:32:32.020 --> 00:32:33.660
doch mal dazu durchgekommen hat, das dann zu machen.

00:32:34.260 --> 00:32:36.220
Ein gutes Startprojekt ist halt

00:32:36.220 --> 00:32:37.940
zu sagen, okay, dann machen wir doch mal irgendwie

00:32:37.940 --> 00:32:40.440
als ersten Microservice

00:32:40.440 --> 00:32:42.120
irgendwie zentrales

00:32:42.120 --> 00:32:42.560
Log

00:32:42.560 --> 00:32:45.820
so Elk-Stack oder sowas,

00:32:45.880 --> 00:32:48.120
Log-Management, weil

00:32:48.120 --> 00:32:49.660
das ist halt relativ einfach,

00:32:49.920 --> 00:32:51.820
das ist eigentlich nicht so schwierig, aber man

00:32:51.820 --> 00:32:53.460
muss halt trotzdem irgendwie

00:32:53.460 --> 00:32:55.720
Sachen irgendwo hindeployen können

00:32:55.720 --> 00:32:57.160
und hat unterschiedliche Sprachen.

00:32:58.060 --> 00:32:59.420
Man muss es irgendwie konfigurieren

00:32:59.420 --> 00:33:01.780
und diese ganzen unterschiedlichen

00:33:01.780 --> 00:33:03.680
Aspekte irgendwie müssen

00:33:03.680 --> 00:33:05.320
alle zusammen funktionieren, sonst geht es halt nicht.

00:33:05.420 --> 00:33:07.640
Und wenn man da schon feststellt, okay, das ist mit der

00:33:07.640 --> 00:33:09.380
Organisation, weil das oft hat man ja so

00:33:09.380 --> 00:33:11.600
Organisationsproblem, schwierig

00:33:11.600 --> 00:33:13.540
zu machen, dann weiß man halt, okay, alles andere danach wird

00:33:13.540 --> 00:33:15.700
noch viel schwieriger, daher sollte man vielleicht nochmal überlegen,

00:33:15.800 --> 00:33:17.480
wie man das organisatorisch löst.

00:33:18.520 --> 00:33:18.800
Aber

00:33:18.800 --> 00:33:21.160
ja, genau, genau, das ist eigentlich,

00:33:21.380 --> 00:33:23.480
du brauchst dann halt irgendwas, wo du dann halt zentral

00:33:23.480 --> 00:33:25.420
deinen Logfile sehen kannst und gucken kannst,

00:33:25.420 --> 00:33:27.620
was passiert ist, über deine unterschiedlichen

00:33:27.620 --> 00:33:28.220
Services hinweg.

00:33:28.480 --> 00:33:31.940
Das meinte ich mit dem

00:33:31.940 --> 00:33:33.440
Hut auf Farben. Ich muss halt immer irgendwie so ein

00:33:33.440 --> 00:33:34.300
Admin haben oder so.

00:33:35.220 --> 00:33:36.940
Du hast dann ein Ding für

00:33:36.940 --> 00:33:39.360
Log-Geschichten, du hast aber dann vielleicht auch ein anderes Ding für

00:33:39.360 --> 00:33:41.040
Monitoring, du hast wieder ein anderes Ding für

00:33:41.040 --> 00:33:42.660
dein

00:33:42.660 --> 00:33:45.040
Live-Dashboard oder so.

00:33:45.200 --> 00:33:46.860
Das müsste ja nicht alles das gleiche sein.

00:33:48.480 --> 00:33:49.680
Aber das Problem,

00:33:49.760 --> 00:33:51.460
was ich jetzt habe, ist dann wahrscheinlich niemand den Hut über

00:33:51.460 --> 00:33:53.540
alle diese Dinge auf hat und es dann schwerfällt,

00:33:53.540 --> 00:33:55.040
die halt in der Bar

00:33:55.040 --> 00:33:55.660
Das muss, ne?

00:33:55.800 --> 00:33:56.620
Ja, wir haben das auch gemacht.

00:33:57.300 --> 00:34:00.900
Ich meine, am Ende, ich meine, das, worauf der Jochen hingewiesen hat,

00:34:01.040 --> 00:34:02.300
wir haben ja unsere Tools, ne?

00:34:02.320 --> 00:34:05.680
Also der Elkstack für Logging, meinetwegen Sentry, für Fehlermeldungen,

00:34:05.760 --> 00:34:08.540
dann hast du vielleicht noch Grafana, Prometheus für Metric Monitoring.

00:34:09.000 --> 00:34:10.920
Das sind ja alles standardisierte Ansätze,

00:34:10.980 --> 00:34:13.400
die du relativ einfach in deine Services einbauen kannst, ne?

00:34:13.440 --> 00:34:15.500
Also Filebeat-Logging geht zum Elkstack.

00:34:15.920 --> 00:34:17.820
Und das ist halt etwas, wo man sich auch in einem Monolithen

00:34:17.820 --> 00:34:18.980
durchaus Gedanken drüber machen muss,

00:34:19.040 --> 00:34:21.620
um da einen einfachen Zugang zu seinen Logs zu kriegen, zum Beispiel.

00:34:22.120 --> 00:34:23.940
Gerade dann, wenn du in einem Team bist,

00:34:23.940 --> 00:34:26.040
dann finde ich schon, dass man sich relativ früh

00:34:26.040 --> 00:34:27.740
die Gedanken über genau diese

00:34:27.740 --> 00:34:30.060
Fragestellungen machen sollte, damit einfach jedes Teammitglied

00:34:30.060 --> 00:34:31.680
ohne Serverzugriff oder irgendwas

00:34:31.680 --> 00:34:33.920
anderes komisches eben an seine Logs

00:34:33.920 --> 00:34:35.820
kommt und diese möglichst schön filtern kann.

00:34:36.920 --> 00:34:38.160
Elk-Stack, ist doch wunderbar.

00:34:38.320 --> 00:34:40.100
Das heißt, diesen Stack, den hast du

00:34:40.100 --> 00:34:41.840
unter Umständen auch in einer guten monolithischen

00:34:41.840 --> 00:34:43.840
Struktur schon. Vielleicht könnt ihr ja mal noch kurz den Elk-Stack

00:34:43.840 --> 00:34:45.460
beschreiben, weil den hatten wir glaube ich noch nicht.

00:34:46.700 --> 00:34:48.020
Das ist einfach nur, ich weiß

00:34:48.020 --> 00:34:49.920
jetzt gar nicht, ob ich das richtig, ich habe mit dem

00:34:49.920 --> 00:34:51.740
gar nicht so viel, das ist irgendwie Elasticsearch,

00:34:51.740 --> 00:34:53.560
um die Logfiles durchsuford zu machen.

00:34:53.940 --> 00:35:23.920
und Jochen unterhalten sich über die Programmiersprache Python

00:35:23.940 --> 00:35:26.440
um sie ein bisschen schöner, JSON-tauglicher

00:35:26.440 --> 00:35:27.760
zu machen und durchsuchbarer zu machen

00:35:27.760 --> 00:35:29.480
einzelne Felder zu indizieren

00:35:29.480 --> 00:35:32.180
und dann wird das eben auf Elasticsearch

00:35:32.180 --> 00:35:34.100
gespeichert und mit Kibana durchsuchst du es einfach

00:35:34.100 --> 00:35:36.180
dann kriegst du so ein Dashboard, dann kannst du

00:35:36.180 --> 00:35:38.120
relativ nutzerfreundlich mit

00:35:38.120 --> 00:35:39.800
schön viel Clicky Bunti

00:35:39.800 --> 00:35:42.040
deine Logs durchsuchen und dann hast du

00:35:42.040 --> 00:35:43.660
deine Graphen, kannst dir auch Dashboards bauen

00:35:43.660 --> 00:35:46.460
Freitextsuche

00:35:46.460 --> 00:35:48.160
das ist sehr schön

00:35:48.160 --> 00:35:49.920
macht Spaß

00:35:49.920 --> 00:35:51.000
Okay

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

00:36:21.000 --> 00:36:22.200
vertikal aufzutrennen.

00:36:22.700 --> 00:36:24.980
Und was man klassischerweise vielleicht eher

00:36:24.980 --> 00:36:26.780
macht, sind Sachen horizontal aufzuteilen.

00:36:27.240 --> 00:36:29.020
Das heißt, du teilst normalerweise, sag ich mal,

00:36:29.140 --> 00:36:30.440
eben dann vielleicht eher auf in

00:36:30.440 --> 00:36:33.060
Frontend irgendwie so Service Layer

00:36:33.060 --> 00:36:34.620
und Backend und Datenhaltung.

00:36:35.960 --> 00:36:37.180
Und sozusagen

00:36:37.180 --> 00:36:38.920
bei Microservices halt eher vertikal. Das heißt,

00:36:38.920 --> 00:36:40.700
pro Projekt irgendwie oder pro

00:36:40.700 --> 00:36:43.160
irgendeine Organisationsstruktur halt.

00:36:43.900 --> 00:36:45.080
Und das

00:36:45.080 --> 00:36:46.860
Problem bei dem horizontalen Ding, was halt man da

00:36:46.860 --> 00:36:48.980
vielleicht weg möchte von, ist

00:36:48.980 --> 00:36:49.860
halt, dass

00:36:49.860 --> 00:36:54.700
du halt, wenn du jetzt viele Leute hast, die daran arbeiten, an deinem Produkt,

00:36:54.900 --> 00:36:58.680
dann stehen sie halt gegenseitig auf den Füßen unter Umständen. Also du hast dann

00:36:58.680 --> 00:37:04.080
vielleicht halt eben schon ein Datenbank-

00:37:04.080 --> 00:37:06.980
Team oder so, wo sich die Leute sehr, sehr gut mit Datenbanken auskennen.

00:37:08.400 --> 00:37:12.520
Und du brauchst sie halt auch deswegen, weil du halt eventuell fiese Datenbank-Probleme hast,

00:37:12.640 --> 00:37:16.560
wo Leute irgendwie Queries optimieren müssen oder sich überlegen müssen, wie sie da halt irgendwie

00:37:16.560 --> 00:37:17.920
und die möglich schnell neue

00:37:17.920 --> 00:37:20.660
irgendwie Replikas von irgendwelchen Datenmarken

00:37:20.660 --> 00:37:22.740
hochziehen können und die Daten da und so weiter.

00:37:24.460 --> 00:37:26.340
Dieses ganze Zeugs, was man halt so machen muss.

00:37:28.140 --> 00:37:28.480
Und

00:37:28.480 --> 00:37:30.460
das sind dann halt so die Sachen, für die du tatsächlich

00:37:30.460 --> 00:37:32.540
Spezialisten brauchst, aber du hast

00:37:32.540 --> 00:37:34.200
halt oft auch das Problem, du hast jetzt

00:37:34.200 --> 00:37:36.280
irgendwie ein Projekt und da muss halt irgendwie jetzt

00:37:36.280 --> 00:37:38.220
eine Spalte zusätzlich irgendwo in der Tabelle.

00:37:39.020 --> 00:37:40.480
Und das ist jetzt eigentlich nichts, was so

00:37:40.480 --> 00:37:42.340
sonderlich schwierig ist vielleicht. Sollte man sich überlegen,

00:37:42.420 --> 00:37:43.940
ob man das machen will oder nicht oder keine Ahnung, aber

00:37:44.340 --> 00:37:45.880
letztlich das zu tun ist gar nicht so schwer

00:37:45.880 --> 00:37:48.220
und dein Datenbankteam ist

00:37:48.220 --> 00:37:50.400
zum Beispiel gerade mit irgendeinem anderen Projekt beschäftigt

00:37:50.400 --> 00:37:52.300
oder so. Und dann kommst du nicht weiter

00:37:52.300 --> 00:37:54.260
mit deinem eigentlich Projekt,

00:37:54.380 --> 00:37:56.300
das nur eine blöde Spalte zusätzlich haben

00:37:56.300 --> 00:37:58.180
muss. Es gibt halt eine Menge Anforderungen, die sehr

00:37:58.180 --> 00:38:00.120
einfach sind. Also entweder du

00:38:00.120 --> 00:38:02.100
beschäftigst dann halt deine teuren Spezialexperten

00:38:02.100 --> 00:38:03.960
mit sehr simplen Geschichten

00:38:03.960 --> 00:38:05.220
oder

00:38:05.220 --> 00:38:08.180
du kannst die nicht auslasten,

00:38:09.200 --> 00:38:09.380
weil

00:38:09.380 --> 00:38:11.980
die halt

00:38:11.980 --> 00:38:13.760
oder du kannst halt

00:38:13.760 --> 00:38:15.660
mit deinen Projekten nicht weiter, weil die halt mit

00:38:15.660 --> 00:38:16.860
und irgendwelchen anderen Kram ausgelastet sind.

00:38:17.800 --> 00:38:19.860
Und das blockiert sich halt gegenseitig.

00:38:19.940 --> 00:38:22.080
Du hast halt sehr viel Hand-off-Zwischendurch, viel Kommunikation,

00:38:22.560 --> 00:38:23.680
weil viele Leute miteinander

00:38:23.680 --> 00:38:25.720
reden müssen, damit irgendwas am Schluss

00:38:25.720 --> 00:38:27.940
deployed werden kann. Und wenn du es jetzt anders machst

00:38:27.940 --> 00:38:29.580
und machst es halt vertikal und sagst, ein Team ist

00:38:29.580 --> 00:38:31.760
im Grunde dafür zuständig, das komplett zu deployen

00:38:31.760 --> 00:38:33.760
in ein Produkt, Projekt,

00:38:34.060 --> 00:38:34.460
Microservice,

00:38:35.260 --> 00:38:37.960
und die anderen sind halt bloß,

00:38:38.420 --> 00:38:39.720
die beraten dich

00:38:39.720 --> 00:38:41.500
dann halt, wenn es irgendwie

00:38:41.500 --> 00:38:43.040
kompliziert wird oder so und

00:38:43.040 --> 00:38:46.120
und enablen dich halt irgendwie da eine Lösung zu finden,

00:38:46.460 --> 00:38:50.860
dann kannst du halt sehr viel schneller halt Sachen tatsächlich raus aus der Tür kriegen.

00:38:52.200 --> 00:38:57.420
Und du machst bestimmte Teile deiner Organisation halt auch handlungsfähig,

00:38:57.500 --> 00:38:59.420
ohne dass sie halt sich mit allen anderen abstimmen müssen.

00:39:00.240 --> 00:39:03.580
Und dann, also das sind vor allen Dingen zwei Teile, die da halt ein Problem sind.

00:39:03.680 --> 00:39:08.080
Das ist halt einmal die Infrastruktur ganz unten, das sind halt Datenbank und so und IT-Geschichten.

00:39:08.220 --> 00:39:11.120
Und dann oben halt aber UI und UX ist auch immer problematisch.

00:39:11.120 --> 00:39:13.120
und der

00:39:41.120 --> 00:39:42.140
von Rügen.

00:39:43.160 --> 00:39:44.520
Ja, aber du bist halt unter Umständen schneller.

00:39:45.160 --> 00:39:46.020
Und ich finde,

00:39:46.380 --> 00:39:48.420
in einer Firma gibt es das auch sehr schön,

00:39:49.060 --> 00:39:51.160
sowohl, dass das einen Vorteil bringen kann,

00:39:51.300 --> 00:39:53.260
sieht man da, und auch was an Nachteilen, nämlich bei Amazon.

00:39:53.760 --> 00:39:55.080
Die haben ja eigentlich früher schon angefangen mit

00:39:55.080 --> 00:39:56.880
Service-Oriented Architecture,

00:39:57.000 --> 00:39:58.540
was vielleicht auch so ein bisschen Vorderteil ist von

00:39:58.540 --> 00:40:01.600
Microservices. Und auf der Amazon-Shopping-Seite,

00:40:01.700 --> 00:40:03.020
da funktioniert das, finde ich, ganz gut.

00:40:03.140 --> 00:40:04.940
Also ich meine, die sieht auch immer so ein bisschen inkonsistent aus

00:40:04.940 --> 00:40:06.220
und komisch und altbacken und so.

00:40:07.500 --> 00:40:08.920
Aber das geht irgendwie.

00:40:08.920 --> 00:40:11.080
Also man kann einkaufen und meistens funktioniert es sogar besser,

00:40:11.120 --> 00:40:13.120
als anderswo vom Prozess her.

00:40:14.020 --> 00:40:15.020
Aber, also das

00:40:15.020 --> 00:40:16.920
geht. Das ist zwar nicht so komplett konsistent, aber

00:40:16.920 --> 00:40:19.060
das funktioniert insgesamt. Und wo

00:40:19.060 --> 00:40:20.840
ich finde, wo es eine ziemliche Katastrophe ist,

00:40:20.900 --> 00:40:23.000
ist halt sowas wie AWS oder so. Wo man auch sieht,

00:40:23.100 --> 00:40:24.680
dass jedes einzelne Team, also einmal es gibt

00:40:24.680 --> 00:40:26.680
hunderte und dann jedes Team

00:40:26.680 --> 00:40:28.580
macht das halt irgendwie anders, so wie sie es halt denken.

00:40:29.080 --> 00:40:30.800
Und das macht es für mich als Benutzer halt total

00:40:30.800 --> 00:40:32.140
schwierig, irgendwie das

00:40:32.140 --> 00:40:35.000
zu bedienen, weil ich nie

00:40:35.000 --> 00:40:36.160
Sachen finde und immer

00:40:36.160 --> 00:40:38.780
suchen muss nach Sachen und so.

00:40:39.020 --> 00:40:40.760
Naja, also auch die Konfiguration, wenn man das irgendwie

00:40:40.760 --> 00:40:43.560
automatisiert, ist ja jedes Mal total anders und das ist ein bisschen nervig.

00:40:43.700 --> 00:40:45.420
Ja, also ich meine, es geht schon, aber es ist halt schon,

00:40:45.520 --> 00:40:47.280
das macht es echt da, an der Stelle macht die

00:40:47.280 --> 00:40:49.120
fehlende Konsistenz einem das Leben halt echt schwer.

00:40:49.560 --> 00:40:50.920
Und ja, aber

00:40:50.920 --> 00:40:53.320
ich glaube, das sind halt so Trade-offs, da muss man sich

00:40:53.320 --> 00:40:55.420
entscheiden, ist einem die Konsistenz wichtiger oder die Geschwindigkeit?

00:40:56.080 --> 00:40:56.240
Ja.

00:40:58.340 --> 00:40:58.620
Ja.

00:40:59.700 --> 00:40:59.920
Ja.

00:41:02.320 --> 00:41:02.940
Naja, naja.

00:41:03.980 --> 00:41:05.480
Wenig Begeisterung für Microservices

00:41:05.480 --> 00:41:07.160
habe ich das Gefühl. Ja, ich weiß nicht, also

00:41:07.160 --> 00:41:09.040
ich habe noch nicht so herausgefunden, wofür ich

00:41:09.040 --> 00:41:11.720
dann jetzt ein Microservice gut einsetzen können.

00:41:11.980 --> 00:41:13.180
Also wenn ich mir jetzt vorstelle, ich möchte jetzt

00:41:13.180 --> 00:41:14.360
irgendwie so ein Projekt implementieren,

00:41:14.960 --> 00:41:16.780
irgendwie so eine gewisse Größe und dann

00:41:16.780 --> 00:41:19.640
muss ich ja,

00:41:20.220 --> 00:41:21.320
wie Jochen so schön sagte,

00:41:21.420 --> 00:41:23.220
enablen die Leute, dass sie

00:41:23.220 --> 00:41:25.200
selber klarkommen mit den ganzen

00:41:25.200 --> 00:41:27.380
Regeln, die ich irgendwie haben will.

00:41:27.880 --> 00:41:29.700
Ich glaube, das ist noch viel zu kompliziert.

00:41:30.080 --> 00:41:31.220
Ich glaube, erstmal muss man

00:41:31.220 --> 00:41:33.200
überlegen, brauche ich das überhaupt? Also macht das für mich

00:41:33.200 --> 00:41:35.300
überhaupt Sinn? Habe ich die Größe, wie viele Mitarbeiter

00:41:35.300 --> 00:41:37.000
habe ich? Bin ich jetzt zu fünf, dann mache ich keinen

00:41:37.000 --> 00:41:39.060
Microservices auf. Aber habe ich meinetwegen

00:41:39.060 --> 00:41:40.620
20, 30, 40 Mitarbeiter,

00:41:41.240 --> 00:41:42.660
das macht schon super viel Sinn, da über

00:41:42.660 --> 00:41:45.040
Microservices nachzudenken, weil ich kann

00:41:45.040 --> 00:41:46.900
jetzt eigentlich Teams machen, diese Teams haben

00:41:46.900 --> 00:41:48.320
verschiedene Verantwortlichkeiten

00:41:48.320 --> 00:41:51.060
und natürlich habe ich hinterher den Trade-off

00:41:51.060 --> 00:41:52.860
mit Konsistenz

00:41:52.860 --> 00:41:54.580
meinetwegen im Frontend.

00:41:54.940 --> 00:41:56.860
Frontend ist halt immer so, ich bin nicht

00:41:56.860 --> 00:41:58.880
im Frontend drin, ich persönlich. Also ich

00:41:58.880 --> 00:42:01.000
halte mich davon so weit fern wie nur möglich

00:42:01.000 --> 00:42:03.140
und so Backend-Prozesse,

00:42:03.580 --> 00:42:04.660
da sind so Guidelines

00:42:04.660 --> 00:42:05.340
total egal.

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

00:42:23.580 --> 00:42:41.720
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.720 --> 00:42:43.900
und wenn die Standards jetzt so sind,

00:42:44.020 --> 00:42:45.920
dass sie jetzt irgendwo im Pazifikraum

00:42:45.920 --> 00:42:47.140
funktionieren, aber für uns

00:42:47.140 --> 00:42:49.600
nicht lesbar,

00:42:50.000 --> 00:42:51.880
dann habe ich ein Problem, weil dann kann

00:42:51.880 --> 00:42:53.840
ich keine Synergieeffekte daraus

00:42:53.840 --> 00:42:54.060
ziehen.

00:42:55.200 --> 00:42:57.820
Ja, die Frage ist dann auch immer, welche Prozesse

00:42:57.820 --> 00:42:59.840
werden durchlaufen, um etwas zu

00:42:59.840 --> 00:43:00.380
veröffentlichen.

00:43:01.440 --> 00:43:03.020
Ja, genau, aber das ist die Frage,

00:43:03.640 --> 00:43:05.760
erschlage ich das dann mit irgendwelchen Prozessen? Weiß ich nicht, das macht es

00:43:05.760 --> 00:43:07.700
ja nicht besser. Dann habe ich den Vorteil

00:43:07.700 --> 00:43:09.780
von Microsoft, das habe ich dann nicht mehr, weil dann muss

00:43:09.780 --> 00:43:11.560
ich durch so ein Prozessgateway

00:43:11.560 --> 00:43:13.400
durchkommen und habt dann einen

00:43:13.400 --> 00:43:14.920
Doorkeeper nach dem anderen.

00:43:16.280 --> 00:43:16.780
Ja gut,

00:43:17.240 --> 00:43:19.320
aber auch um auf deine Frage zu kommen,

00:43:19.400 --> 00:43:21.000
die Frage ist dann am Ende auch, wie schlimm ist das?

00:43:21.240 --> 00:43:23.480
Also wenn ich jetzt zum Beispiel in Tokio

00:43:23.480 --> 00:43:25.160
das eine Team habe und in Berlin das andere,

00:43:25.900 --> 00:43:27.580
die backen beide

00:43:27.580 --> 00:43:29.060
ihren eigenen Kuchen, dann

00:43:29.060 --> 00:43:31.140
das ist ja gerade der Sinn von Microservices auch,

00:43:31.200 --> 00:43:33.380
dass jedes Team eigentlich nach Lust und Laune so arbeiten kann,

00:43:33.460 --> 00:43:35.120
wie es will, solange es zum richtigen Produkt führt.

00:43:35.660 --> 00:43:37.520
Weil das Team in Berlin wird relativ

00:43:37.520 --> 00:43:39.540
wenig Berührungspunkte mit dem Code zum Beispiel

00:43:39.540 --> 00:43:41.400
vom Team in Tokio haben. Und umgekehrt

00:43:41.400 --> 00:43:43.340
natürlich auch, weil Microservice-Teams,

00:43:43.360 --> 00:43:45.420
die stehen ja für sich alleine. Das heißt,

00:43:45.580 --> 00:43:47.360
wir haben ein Team, das arbeitet an einer Sache,

00:43:47.900 --> 00:43:49.500
das deployed ein Service für sich alleine

00:43:49.500 --> 00:43:51.400
und der muss natürlich integrativ mit den

00:43:51.400 --> 00:43:52.400
anderen irgendwie funktionieren.

00:43:53.120 --> 00:43:55.100
Ich würde auch denken, dass das Problem

00:43:55.100 --> 00:43:57.020
eher tatsächlich andersrum ist,

00:43:57.300 --> 00:43:58.720
also was dann tatsächlich auftritt.

00:43:59.240 --> 00:44:01.120
Ja, es kann auch sein, dass es schwierig ist,

00:44:01.160 --> 00:44:02.760
das zu koordinieren, keine Ahnung.

00:44:03.480 --> 00:44:05.260
Kann man sich ja vielleicht

00:44:05.260 --> 00:44:07.220
irgendwas überlegen. Aber das habe ich jetzt noch gar nicht zugehört,

00:44:07.320 --> 00:44:08.260
also das ist ein Riesenproblem.

00:44:08.920 --> 00:44:10.580
Aber schon ein Riesenproblem ist halt,

00:44:10.580 --> 00:44:35.740
Also wenn du jetzt so etwas hast, wie ich weiß jetzt nicht, was das Beispiel war, das kam auch in der Prozessreise. Du hast halt irgendwie einen Konzern, der hat halt hunderte Marken und jede Marke hat irgendwie eigene Dienste, die sie irgendwie anbieten und die sind alle in unterschiedlichen Teams und so und auch weltweit verteilt und so. Wie stellst du denn sicher, dass du irgendwas über einen bestimmten Kunden weißt zentral? Das kriegst du halt dann nicht mehr hin.

00:44:35.740 --> 00:44:39.820
oder halt über die Produktion, wenn du halt da, wenn du derjenige bist, der das produziert und das dann verteilt an Unterrichtsgemeinschaften,

00:44:40.160 --> 00:44:41.060
das ist genau das, was ich meine.

00:44:41.520 --> 00:44:43.420
Ja, das ist der Nachteil, das geht halt nicht mehr.

00:44:43.780 --> 00:44:50.200
Aber das, was ich zentral, das sind wir vielleicht wieder, was man bei Single Porn oder Fools irgendwie überschreiten kann.

00:44:50.380 --> 00:44:51.080
Das ist eine Herausforderung.

00:44:51.100 --> 00:44:55.580
Ich muss halt irgendwie sicherstellen, dass die Wahrheit, ich will die Wahrheit haben, damit ich das menschen kann,

00:44:55.660 --> 00:44:58.920
damit ich die Entscheidung richtig treffen kann, damit ich die Steuerung...

00:44:58.920 --> 00:45:03.340
Ist halt die Frage, also es geht halt manchmal, ich meine, ich kenne es halt zum Beispiel,

00:45:03.340 --> 00:45:06.280
ein Beispiel als zweitgrößte E-Commerce-Konzern der Welt.

00:45:06.980 --> 00:45:07.760
Wisst ihr, wer das ist?

00:45:09.200 --> 00:45:09.940
Nach Amazon?

00:45:12.120 --> 00:45:12.520
Otto?

00:45:13.120 --> 00:45:15.440
Ja, das ist Otto, aber tatsächlich, ich weiß nicht,

00:45:15.540 --> 00:45:17.500
ob das noch stimmt. Es kann sein, dass

00:45:17.500 --> 00:45:19.780
AliExpress

00:45:19.780 --> 00:45:21.080
oder so größer ist.

00:45:22.000 --> 00:45:22.880
Oder Alibaba.

00:45:22.880 --> 00:45:23.900
Da macht man kein Wettbewerb draus.

00:45:25.040 --> 00:45:26.300
Otto auf jeden Fall sehr, sehr groß.

00:45:27.340 --> 00:45:28.800
Damals, das ist jetzt aber auch schon wieder

00:45:28.800 --> 00:45:30.060
lange her, haben sie

00:45:30.060 --> 00:45:32.460
das auf die Fahnen geschrieben,

00:45:32.460 --> 00:45:34.060
der Zeitgröße nach Amazon zu sein.

00:45:34.860 --> 00:45:36.800
Und die haben halt zum Beispiel genau dieses Problem,

00:45:36.940 --> 00:45:38.820
weil es gibt ja nicht die eine Seite,

00:45:38.960 --> 00:45:40.340
auf der dann alle irgendwie Zeugs einkaufen,

00:45:40.480 --> 00:45:42.420
sondern die haben halt hunderte Shops.

00:45:42.660 --> 00:45:45.140
Also jeder dritte Shop, auf dem du irgendwie landest,

00:45:45.220 --> 00:45:46.740
gehört zum Autokonzern.

00:45:46.980 --> 00:45:48.960
Du weißt das aber gar nicht, weil das steht da ja auch nicht dran.

00:45:49.760 --> 00:45:51.040
Die haben jetzt genau dieses Problem.

00:45:52.000 --> 00:45:54.700
Jeder einzelne Shop hält halt User-Daten.

00:45:56.740 --> 00:45:58.360
Wie machst du das denn jetzt eigentlich,

00:45:58.500 --> 00:46:01.120
wenn du quasi Dinge wissen willst über deine User?

00:46:01.120 --> 00:46:03.180
Also andersrum, also wie kriegen die ganzen Microservices

00:46:03.180 --> 00:46:04.060
wieder alle zusammen?

00:46:04.380 --> 00:46:06.380
Ja, und die Antwort ist eigentlich gar nicht.

00:46:06.780 --> 00:46:08.600
Ich glaube, da kommen so Leute auf die Idee, wie

00:46:08.600 --> 00:46:10.980
Data Lake wird dann eher Data Swamp oder so.

00:46:11.540 --> 00:46:12.240
Irgendwas zu Säkertreuen.

00:46:12.980 --> 00:46:14.960
Das schlimmste Problem

00:46:14.960 --> 00:46:17.060
ist gar nicht unbedingt die technische Lösung,

00:46:17.240 --> 00:46:18.960
sondern das schlimmste Problem sind halt die

00:46:18.960 --> 00:46:21.360
politischen Geschichten, die du halt auch kriegst automatisch.

00:46:21.840 --> 00:46:22.980
Dass halt Leute sagen so,

00:46:23.960 --> 00:46:25.180
wir haben hier gerade

00:46:25.180 --> 00:46:27.000
einen Vorteil, sie sind ja untereinander im Wettbewerb,

00:46:27.260 --> 00:46:28.980
wir haben hier gerade einen Vorteil, weil

00:46:28.980 --> 00:46:31.540
wir irgendwas wissen, was die anderen nicht wissen.

00:46:31.800 --> 00:46:33.180
Und jetzt sollen wir die Daten, das, was

00:46:33.180 --> 00:46:35.480
uns dazu verhilft, dass wir irgendwie besser

00:46:35.480 --> 00:46:37.480
sein können als unsere interne Konkurrenz,

00:46:37.840 --> 00:46:39.440
das sollen wir denen jetzt irgendwie freiwillig zur Verfügung

00:46:39.440 --> 00:46:41.380
stellen. Dann haben wir halt irgendwie

00:46:41.380 --> 00:46:43.420
einen leicht kaputten Export, wo die Daten

00:46:43.420 --> 00:46:45.380
so ein bisschen... Ja, aber mit der Konzernbrille,

00:46:45.440 --> 00:46:47.280
die du dann aufhast, dann musst du da hingehen, musst den gotischen

00:46:47.280 --> 00:46:49.120
Knoten dann kaputt hauen. Dann musst du sagen, gib uns die Daten,

00:46:49.240 --> 00:46:51.300
wir sind der Chef. Ja, schwierig.

00:46:51.620 --> 00:46:52.560
Sehr schwierig. Also,

00:46:52.860 --> 00:46:55.320
ja. Aber auch

00:46:55.320 --> 00:46:57.240
da, ich meine, das ist jetzt ein sehr, sehr schönes Beispiel,

00:46:57.240 --> 00:47:27.220
und Jochen unterhalten sich über die Programmiersprache Python

00:47:27.240 --> 00:47:29.320
oder wie auch immer. Oder will ich

00:47:29.320 --> 00:47:31.400
jetzt einfach alles wissen und will ich die totale Kontrolle

00:47:31.400 --> 00:47:33.500
haben? Ja, das ist halt genau das klassische Problem

00:47:33.500 --> 00:47:35.520
eigentlich. Machst du halt irgendwie Diversifizierung

00:47:35.520 --> 00:47:37.300
oder machst du Fusionierung

00:47:37.300 --> 00:47:38.820
irgendwie. Das ist

00:47:38.820 --> 00:47:41.060
in der Softwareseite und die Frage,

00:47:41.320 --> 00:47:43.420
die irgendwie die Consultants immer geben, ist immer genau das Gegenteil

00:47:43.420 --> 00:47:44.400
von dem, was gerade da ist.

00:47:45.360 --> 00:47:47.160
Dann kannst du halt so ein Projekt consulten, kannst du

00:47:47.160 --> 00:47:49.340
und dann geht es halt immer raus und zusammen.

00:47:49.560 --> 00:47:51.300
Ich meine, das macht natürlich auch Sinn. Also wenn du irgendwas

00:47:51.300 --> 00:47:53.220
hast, was total verfüllt ist, dann musst du das

00:47:53.220 --> 00:47:55.280
erstmal auseinanderspalten, dann hast du kleine

00:47:55.280 --> 00:47:58.860
einzelne Services, die untereinander so ein bisschen Wettbewerb haben, die guten Sachen,

00:47:59.240 --> 00:48:03.220
muss dann irgendwie wieder konsolidieren und zentralisieren, um dann wieder den guten Benefit rauszubekommen.

00:48:03.540 --> 00:48:06.080
Du merkst, dass du wieder doof bist, dann fängst du wieder an, das auseinanderzudröseln.

00:48:06.160 --> 00:48:09.800
Das ist ja genau wie bei den Ländern. Mal sind Länder zusammengefasst, dann sind sie auseinander.

00:48:10.620 --> 00:48:17.040
Aber das ist ja vielleicht auch dieser natürliche Lebenszyklus von so einem Ding.

00:48:18.920 --> 00:48:23.360
Wenn ich jetzt zum Beispiel das Otto-Beispiel nehme und ich möchte diese User-Daten haben,

00:48:23.360 --> 00:48:26.820
Ich würde jetzt als Otto hingehen und sagen, ich will wissen, wer sind meine Kunden, wie viele Kunden sind überhaupt irgendwo.

00:48:27.020 --> 00:48:28.980
Dann muss ich hingehen und sagen, gebt mir alle eure Daten.

00:48:29.340 --> 00:48:32.840
Dann baue ich einen zentralen Service dann zusätzlich, der halt von allen die Daten abholt.

00:48:32.900 --> 00:48:35.060
Dann kann es sein, dass ich jeden einzelnen dieser Shops einzeln integrieren muss.

00:48:35.140 --> 00:48:37.160
Kann irgendwie sein, dass das relativ viel Aufwand macht.

00:48:37.220 --> 00:48:42.020
Aber dann hole ich mir die alle irgendwann ab und dann weiß ich, okay, zumindest in der Historie gesehen,

00:48:42.100 --> 00:48:44.480
ist das vielleicht ein Tag alt oder so oder eine Woche, ist ja egal.

00:48:44.580 --> 00:48:46.520
Aber da sind die Daten einigermaßen echt.

00:48:46.840 --> 00:48:49.240
Und da habe ich einen vollen Überblick, was da meine Leute sind.

00:48:49.240 --> 00:48:52.460
Und da kann ich dann bestimmte Analysen fahren, die ich vielleicht fahren möchte.

00:48:53.360 --> 00:48:55.100
Aber das ist ja das, was man vielleicht dann braucht.

00:48:55.400 --> 00:48:57.420
Und dann kann man damit vielleicht dann wieder sagen, ah, aber dafür

00:48:57.420 --> 00:48:59.360
machen wir jetzt wieder so kleine Services, weil dann...

00:48:59.360 --> 00:49:00.920
Vielleicht, ne? Aber du kannst auch überlegen,

00:49:01.360 --> 00:49:03.300
ob du, finde ich, im Vorfeld einen gewissen

00:49:03.300 --> 00:49:04.840
Standard etablierst, wo du sagst,

00:49:05.420 --> 00:49:06.940
da sind wir wieder beim Standard natürlich, ne?

00:49:07.020 --> 00:49:07.700
Und bei den Gateways, ja.

00:49:09.240 --> 00:49:11.380
Nicht nur bei den Gateways. Ich bin ein Backend,

00:49:11.480 --> 00:49:13.360
ich interessiere mich nicht so für die... Ja, doch, auch.

00:49:13.500 --> 00:49:15.120
Ja, das ist mein Problem mit der Gatekeeper.

00:49:15.260 --> 00:49:17.180
Ich musste gerade, weil du gesagt hast Standards, musste ich an

00:49:17.180 --> 00:49:19.120
Infrastrukturstandards denken und

00:49:19.120 --> 00:49:21.180
auch dann, du sagst das ja, unheimlich schwierig,

00:49:21.180 --> 00:49:23.060
wenn du die gleichen Standards

00:49:23.060 --> 00:49:24.760
einführst für Teams, die

00:49:24.760 --> 00:49:26.080
auf der Welt irgendwo sitzen.

00:49:26.180 --> 00:49:27.680
Damit verlierst du die Vorteile von Microsoft.

00:49:27.940 --> 00:49:31.360
Die Frage ist halt, was der Standard ist.

00:49:31.560 --> 00:49:32.860
Möchte ich jetzt einfach so ein Plug-in

00:49:32.860 --> 00:49:35.040
auf jedem Shop haben, welches meinetwegen

00:49:35.040 --> 00:49:36.320
in verschiedenen Programmiersprachen

00:49:36.320 --> 00:49:39.260
vorhanden ist, damit die Shops autonom sind?

00:49:39.360 --> 00:49:41.200
Ist es für mich ein vertretbarer Aufwand,

00:49:41.280 --> 00:49:42.580
das zu gewährleisten, meinetwegen?

00:49:42.640 --> 00:49:44.760
Es fängt ja schon bei kleineren Sachen an,

00:49:44.760 --> 00:49:46.860
wie jeder Dev kriegt einen Windows-Klip-Top

00:49:46.860 --> 00:49:47.640
mit AD zugeführt.

00:49:47.660 --> 00:49:49.160
Aber das hat er nicht.

00:49:50.480 --> 00:49:52.660
Das ist der Punkt. Wenn du Microsoft was machst,

00:49:52.660 --> 00:49:54.860
musst du erkennen, dass das unabhängig sein muss

00:49:54.860 --> 00:49:56.640
von dem Rest und du kannst das

00:49:56.640 --> 00:49:58.240
da nicht zentralisieren. Und wenn du das machst,

00:49:58.680 --> 00:50:00.520
ist es halt kontraproduktiv, weil dann hast du den

00:50:00.520 --> 00:50:02.440
Monolithen irgendwo dazwischen sitzen,

00:50:02.560 --> 00:50:04.580
der wie eine Krake versucht, seine einzelnen Sachen

00:50:04.580 --> 00:50:06.660
noch festzuhalten und dann ist das völlig

00:50:06.660 --> 00:50:08.660
absurd. Wie gesagt, also für

00:50:08.660 --> 00:50:10.200
mich muss man da so ein bisschen

00:50:10.200 --> 00:50:12.360
von loslassen, dass man die

00:50:12.360 --> 00:50:14.060
Kontrolle, die totale Kontrolle haben will.

00:50:14.700 --> 00:50:16.680
Und wenn man das kann und wenn man dann die Vorteile

00:50:16.680 --> 00:50:18.780
für die Flexibilität

00:50:18.780 --> 00:50:20.140
sieht, die man dabei gewinnt,

00:50:20.140 --> 00:50:22.940
und dann sind Microservices schon sehr vorteilhaft.

00:50:23.060 --> 00:50:24.800
Ja, genau, aber das ist genau der Punkt,

00:50:24.920 --> 00:50:26.840
weil wenn ich jetzt sage, ich möchte den Hut aufhaben,

00:50:26.980 --> 00:50:27.900
wird das so nicht funktionieren.

00:50:28.100 --> 00:50:30.840
Sonst wird nur dann funktionieren, wenn ich Verantwortung abgeben kann.

00:50:31.040 --> 00:50:32.040
Ja, dann nimmst du Microservices.

00:50:32.460 --> 00:50:32.620
Ja, genau.

00:50:32.840 --> 00:50:34.740
Aber da hast du ja schon eine Antwort.

00:50:34.960 --> 00:50:36.920
Also willst du den Hut aufhaben, wie du es so schon sagst,

00:50:37.640 --> 00:50:38.660
dann mach keinen Microservice

00:50:38.660 --> 00:50:41.340
oder überleg dir halt sehr, sehr gut, wie du das gewährleisten kannst,

00:50:41.460 --> 00:50:42.180
wie viel willst du wachsen.

00:50:42.280 --> 00:50:44.240
Vielleicht geht das ja so, wenn Microservices verweist.

00:50:45.700 --> 00:50:47.240
Oder willst du die Verantwortung abgeben,

00:50:47.400 --> 00:50:49.040
dann kannst du Microservices nehmen.

00:50:49.040 --> 00:50:51.420
Die Frage am Ende ist, wenn du einen riesen Konzern hast,

00:50:51.980 --> 00:50:53.440
hat da überhaupt noch jemand den Hut auf?

00:50:53.560 --> 00:50:54.420
Egal welchen Ansatz du nimmst.

00:50:54.420 --> 00:50:55.760
Die Frage am Ende ist dann ganz einfach,

00:50:55.860 --> 00:50:58.700
auf welcher Kostenstelle wird denn das gebucht und wer hält dann wo die Hand auf?

00:50:59.580 --> 00:51:00.960
Ja, aber ich glaube,

00:51:01.340 --> 00:51:03.240
wenn man nochmal einen Schritt

00:51:03.240 --> 00:51:05.260
mehr Richtung Organisation

00:51:05.260 --> 00:51:06.780
oder allgemein oder abstraktes Problem geht,

00:51:07.280 --> 00:51:09.280
ich denke, ich würde irgendwie diesen Trend

00:51:09.280 --> 00:51:10.780
zu Microsoft halt so verorten

00:51:10.780 --> 00:51:14.300
in einer Reihe von Trends,

00:51:14.340 --> 00:51:15.700
die halt alle in eine ähnliche Richtung laufen.

00:51:15.820 --> 00:51:17.060
Ich glaube, DevOps ist auch so ein Ding,

00:51:17.060 --> 00:51:18.280
was in eine ähnliche Richtung läuft,

00:51:18.280 --> 00:51:21.540
weil bei all diesen Dingen geht es im Grunde darum,

00:51:22.800 --> 00:51:26.260
dass man halt in so einer klassischen Organisation,

00:51:26.560 --> 00:51:29.360
dass da die Incentives irgendwie pervers sind, so ein bisschen.

00:51:30.360 --> 00:51:33.600
Und das sind alles Versuche, das zu lösen, dieses Problem,

00:51:33.880 --> 00:51:35.400
dass die Incentives eigentlich nicht korrekt sind.

00:51:35.860 --> 00:51:37.520
Also was ich damit meine, ist einfach nur,

00:51:37.760 --> 00:51:39.000
ist eigentlich ein total simples Problem.

00:51:39.200 --> 00:51:40.540
Nehmen wir an, du hast halt irgendwie,

00:51:40.980 --> 00:51:45.520
früher hast du halt Entwicklungen und Betrieb

00:51:45.520 --> 00:51:47.940
oder IT und Operations

00:51:47.940 --> 00:51:49.340
und auf der anderen Seite Entwicklung.

00:51:49.640 --> 00:51:51.080
Das ist vielleicht auf unterschiedlichen

00:51:51.080 --> 00:51:53.600
Seiten deiner Bilanz auch. Das eine sind

00:51:53.600 --> 00:51:55.700
Kosten und das andere sind

00:51:55.700 --> 00:51:57.280
Investitionen.

00:51:57.520 --> 00:51:59.960
Dann siehst du

00:51:59.960 --> 00:52:01.720
wenn da Features entwickelt werden,

00:52:01.800 --> 00:52:03.680
siehst du das als Investition und

00:52:03.680 --> 00:52:05.740
denkst halt, je mehr Features entwickelt werden, voll gut,

00:52:05.880 --> 00:52:07.820
gibt mir in der Zukunft mehr Einnahmen, total super.

00:52:09.720 --> 00:52:11.920
Das heißt, deine Entwicklung

00:52:11.920 --> 00:52:13.640
misst du daran, wie viele Features kriegen die eigentlich

00:52:13.640 --> 00:52:15.660
Pro Quartal irgendwie raus oder keine Ahnung, irgendwie sowas.

00:52:16.220 --> 00:52:17.500
Und dann geht das Ganze

00:52:17.500 --> 00:52:18.040
in den Betrieb.

00:52:19.560 --> 00:52:21.560
Woran misst du deinen Betrieb? Den misst du an den Kosten

00:52:21.560 --> 00:52:23.620
und daran, dass es halt funktioniert.

00:52:24.160 --> 00:52:24.400
Aber

00:52:24.400 --> 00:52:27.660
sozusagen die Leute, die da

00:52:27.660 --> 00:52:29.080
arbeiten, die haben nichts davon,

00:52:29.760 --> 00:52:31.060
dass da mehr Features rausgehen.

00:52:31.440 --> 00:52:33.740
Die kriegen

00:52:33.740 --> 00:52:35.240
nicht mehr Geld dafür, dass sie halt

00:52:35.240 --> 00:52:37.580
dafür sorgen, dass sie in den Verkleinern

00:52:37.580 --> 00:52:39.520
mehr Features veröffentlichen. Was ist deren

00:52:39.520 --> 00:52:41.420
sozusagen rational

00:52:41.420 --> 00:52:43.880
der beste Strategie in diesem

00:52:43.880 --> 00:52:46.200
Setting ist halt tatsächlich zu sagen

00:52:46.200 --> 00:52:48.600
Never change a running system

00:52:48.600 --> 00:52:49.940
Ja, irgendwie

00:52:49.940 --> 00:52:52.380
ich werde nicht belohnt dafür

00:52:52.380 --> 00:52:54.380
ich bin ein Kostenfaktor, ich werde nur bestraft

00:52:54.380 --> 00:52:56.500
wenn irgendwas nicht geht, solange das Wasser läuft

00:52:56.500 --> 00:52:57.720
und der Strom an ist, alles gut

00:52:57.720 --> 00:53:00.020
sobald der Strom ausfällt, kriege ich

00:53:00.020 --> 00:53:01.820
ein paar Probleme

00:53:01.820 --> 00:53:04.320
das heißt, mein Ding ist

00:53:04.320 --> 00:53:06.360
ich meine klar, eine Änderung kann sein

00:53:06.360 --> 00:53:08.540
dass die gut ist für andere, aber ich habe ja nichts davon

00:53:08.540 --> 00:53:09.780
oder sie ist schlecht

00:53:09.780 --> 00:53:11.500
dann trifft mich das.

00:53:11.940 --> 00:53:13.920
Das heißt, ich versuche möglichst Änderungen

00:53:13.920 --> 00:53:15.900
zu verhindern. Dann, das ist

00:53:15.900 --> 00:53:17.940
sozusagen für mich am besten, weil dann kann ich

00:53:17.940 --> 00:53:19.360
sicherstellen, dass möglichst wenig kaputt geht.

00:53:20.040 --> 00:53:21.780
Und na gut, für die anderen ist das halt nicht so toll,

00:53:21.840 --> 00:53:23.840
dass sie halt nicht so viele Features rauskriegen, aber ist ja ehrlich gesagt

00:53:23.840 --> 00:53:24.340
nicht mein Problem.

00:53:25.460 --> 00:53:27.780
Das ist halt etwas, in das

00:53:27.780 --> 00:53:29.720
Unternehmen dann halt früher oder später irgendwann reinlaufen

00:53:29.720 --> 00:53:31.800
und überlegen sie sich, wie sie damit irgendwie umgehen, dass das

00:53:31.800 --> 00:53:33.760
jetzt irgendwie problematisch ist und das halt irgendwie

00:53:33.760 --> 00:53:35.920
ein Maß dafür. Man sich fragt so,

00:53:36.300 --> 00:53:37.880
also dann macht man dann eine Kostenschwellung, keine Ahnung

00:53:37.880 --> 00:53:42.160
und dann sagt man intern so, man kostet das unfassbare Beträge, irgendwas sehr simples zu tun.

00:53:42.420 --> 00:53:46.000
Dann fragt man sich, ja, wie kommt denn das zustande, dass das plötzlich so wahnsinnig viel kostet?

00:53:46.040 --> 00:53:47.140
Ein Server 50.000 Euro.

00:53:47.320 --> 00:53:47.940
Ja, irgendwie sowas.

00:53:48.000 --> 00:53:51.800
Und die Antwort ist einfach so, ja, das ist halt deswegen, damit du das nicht machst,

00:53:52.120 --> 00:53:53.700
damit du nichts änderst, ja, das ist der Grund.

00:53:54.320 --> 00:53:56.300
Das ist halt der Preis für die Änderung, dass jemand sagt so,

00:53:56.480 --> 00:53:59.400
irgendwie ich gehe ja für dich das Risiko, dass sich irgendwie das Sachen kaputt gehen.

00:53:59.840 --> 00:54:01.460
Ich will möglichst, dass du nichts änderst, ja.

00:54:02.040 --> 00:54:02.940
Und deswegen ist das so teuer.

00:54:02.940 --> 00:54:09.400
und ja, DevOps ist halt dann so ein, also die Lösung dafür ist halt dann sozusagen die Verantwortung für das,

00:54:10.160 --> 00:54:16.420
für diese Dinge halt auch mit in den Bereich zu packen, der halt davon profitiert, wenn was deployed wird.

00:54:16.440 --> 00:54:18.100
Ja, mit in den agilen Sprinter zu packen.

00:54:18.100 --> 00:54:23.840
Genau, Agile, auch so ein Ding, wo man sagt, okay, genau, wir packen das alles zusammen.

00:54:25.120 --> 00:54:29.860
Ja, oder halt eben DevOps, wo man sagt, okay, die Leute, die das deployed haben wollen,

00:54:29.920 --> 00:54:31.540
deployen es dann halt auch selber und betreiben es auch selber.

00:54:31.680 --> 00:54:32.540
DevSecOps jetzt, ne?

00:54:32.540 --> 00:54:37.660
Full-Stack-Microservice

00:54:37.660 --> 00:54:39.020
DevOps

00:54:39.020 --> 00:54:41.400
im agilen Prozess

00:54:41.400 --> 00:54:43.360
ja, das ist unglaublich

00:54:43.360 --> 00:54:44.600
aber ja

00:54:44.600 --> 00:54:47.500
genau, es geht halt darum

00:54:47.500 --> 00:54:48.220
irgendwie, dass

00:54:48.220 --> 00:54:51.480
einzelne Teams halt möglichst

00:54:51.480 --> 00:54:52.760
autark Dinge machen können

00:54:52.760 --> 00:54:55.520
dass man halt sozusagen da, wo man investiert

00:54:55.520 --> 00:54:57.500
halt auch tatsächlich, dass die auch dann

00:54:57.500 --> 00:54:59.580
die Möglichkeit haben

00:54:59.580 --> 00:55:01.220
das umzusetzen, aber

00:55:01.220 --> 00:55:31.200
und Jochen unterhalten sich über die Programmiersprache Python

00:55:31.220 --> 00:55:33.020
dazu, dass diese Idee, Microsoft ist

00:55:33.020 --> 00:55:34.840
ganz groß geschrieben, du willst ganz viel

00:55:34.840 --> 00:55:36.860
Microsoft machen, aber hast

00:55:36.860 --> 00:55:38.820
eigentlich da die ganze Zeit diese Krake, die das

00:55:38.820 --> 00:55:41.080
festhält. Und das funktioniert, glaube

00:55:41.080 --> 00:55:41.920
ich, überhaupt nicht.

00:55:43.820 --> 00:55:44.880
Weiß ich gar nicht.

00:55:45.160 --> 00:55:46.260
Also ich meine, das Problem,

00:55:47.340 --> 00:55:48.900
also vielleicht kann man

00:55:48.900 --> 00:55:50.560
das ja an einzelnen Projekten irgendwie,

00:55:50.780 --> 00:55:52.620
also ich würde ja auch denken, dass eine schlaue

00:55:52.620 --> 00:55:54.740
Art irgendwie, wenn man jetzt migrieren

00:55:54.740 --> 00:55:56.820
wollte von Modulit auf Microsoft, wäre halt,

00:55:57.120 --> 00:55:58.820
man fängt halt klein mit kleineren Teilen

00:55:58.820 --> 00:56:01.020
an und macht das da. Und man macht nicht alles auf einmal.

00:56:01.220 --> 00:56:03.220
weil das wird wahrscheinlich nicht gut funktionieren.

00:56:04.840 --> 00:56:05.740
Warum denn überhaupt?

00:56:05.800 --> 00:56:06.660
Also ich verstehe es immer noch nicht.

00:56:07.220 --> 00:56:08.640
Also irgendwie denke ich immer noch so,

00:56:08.680 --> 00:56:10.940
warum hält man das dann nicht an einer Stelle fest

00:56:10.940 --> 00:56:13.780
und sorgt dann dafür, dass die

00:56:13.780 --> 00:56:15.340
alle dann an eine Stelle

00:56:15.340 --> 00:56:16.920
kommen, dass sie sich alle gut verstehen,

00:56:17.220 --> 00:56:19.160
dass sie alle dieselbe Text-Stack benutzen,

00:56:19.300 --> 00:56:21.260
dass sie die Infrastruktur standardisiert benutzen,

00:56:21.340 --> 00:56:23.420
dass sie nur die standardisierte Infrastruktur benutzen, keine andere

00:56:23.420 --> 00:56:25.400
und dass halt dieses ganze Distributed

00:56:25.400 --> 00:56:26.500
Quatsch, Entschuldigung,

00:56:26.780 --> 00:56:28.980
dass alles weg ist.

00:56:28.980 --> 00:56:30.540
Ich habe die Things of Tuesday,

00:56:30.540 --> 00:56:32.180
Ich kann ja von mir verschiedene Rechenzentren

00:56:32.180 --> 00:56:34.680
parallel an verschiedenen Orten halten. Das ist ja okay, das kann ja

00:56:34.680 --> 00:56:36.560
ein Server-Team mitmachen. Aber warum muss ich, also

00:56:36.560 --> 00:56:38.740
die Abhängigkeiten werden dann von mir

00:56:38.740 --> 00:56:39.960
aus schwieriger, ja,

00:56:40.500 --> 00:56:42.760
so ein bisschen zu managen, weil ich habe halt dann das Problem,

00:56:42.900 --> 00:56:43.940
wie Jochen gerade sagte, dass

00:56:43.940 --> 00:56:46.440
hochspezialisierte, hochgutbezahlte

00:56:46.440 --> 00:56:48.440
Spezialkräfte sich teilweise um trivialen

00:56:48.440 --> 00:56:50.640
Scheiß kümmern müssen, bis die Sachen halt mal

00:56:50.640 --> 00:56:51.300
integriert sind.

00:56:52.360 --> 00:56:54.400
Aber dafür konnte man ja einen Service schreiben, also keinen

00:56:54.400 --> 00:56:56.660
Microservice, sondern einen, der halt

00:56:56.660 --> 00:56:58.000
in den Monolithen drin hängt, ja.

00:57:00.020 --> 00:57:00.420
Ja,

00:57:00.540 --> 00:57:04.620
Also ich, ganz grundsätzlich, ich habe so ein bisschen das Gefühl, du bist so ein bisschen biased.

00:57:05.920 --> 00:57:08.020
Weitere, das ist mir eine meine Meinung.

00:57:08.520 --> 00:57:10.220
Nee, es ist ja alles gut.

00:57:10.720 --> 00:57:13.960
Also grundsätzlich muss man halt die Ausgangslage erstmal in Frage stellen.

00:57:14.100 --> 00:57:15.760
Habe ich denn überhaupt die gleichen Kompetenzen?

00:57:15.860 --> 00:57:17.020
Ich meine, darüber hatten wir ja schon geredet.

00:57:17.340 --> 00:57:20.860
Es ist auch nicht immer ganz leicht, die gleichen Kompetenzen überall zu finden für alles.

00:57:20.980 --> 00:57:25.720
Wenn du eine große Firma bist, dann hast du vielleicht irgendwie einen Java-Entwickler,

00:57:25.720 --> 00:57:29.660
der ist Querensteiger in Python oder C-Sharp in C++, was weiß ich.

00:57:29.820 --> 00:57:30.420
So was gibt es.

00:57:30.540 --> 00:57:36.200
und dann verlangst du halt von dem einen Entwickler, dass er seinen Stack zum Beispiel umstellt, das willst du ja auch nicht unbedingt.

00:57:36.380 --> 00:57:44.440
Also du hast halt grundsätzlich erstmal verschiedene Kompetenzen, dann ist die Frage, brauche ich diesen einen globalen Tagstack überhaupt, will ich den überhaupt haben, bringt er mir überhaupt was.

00:57:46.120 --> 00:57:52.700
Es gibt halt so wenig gute Leute, dass man wahrscheinlich schon Tagstack multiplexen muss, damit man überhaupt genug Leute findet.

00:57:52.700 --> 00:58:03.180
Ah siehst du also Microsoft nein Aber grunds musst du dir ja auch die Frage stellen erstmal vielleicht um von dieser Ebene mal ein bisschen zur zum Code zu kommen Ein Monolith der hat nat

00:58:03.180 --> 00:58:04.920
eine riesen Codebasis, die unter Umständen

00:58:04.920 --> 00:58:07.180
relativ komplex ist. Das heißt, du musst viel Aufwand

00:58:07.180 --> 00:58:09.320
in den Deployment-Prozess an sich stecken.

00:58:09.680 --> 00:58:10.340
Also bist du

00:58:10.340 --> 00:58:13.100
ein einzelnes Feature, ein neues Feature deployst

00:58:13.100 --> 00:58:15.340
oder ein Bug fixst, musst du dich mit relativ vielen Leuten

00:58:15.340 --> 00:58:17.080
wie der Jochen schon gesagt hat, abgesprochen haben.

00:58:17.160 --> 00:58:19.220
Du bist insgesamt ein bisschen langsamer und

00:58:19.220 --> 00:58:20.980
vor allem auch fehleranfälliger insgesamt.

00:58:20.980 --> 00:58:27.560
Wenn irgendein Integration-Test irgendwie fehl geht und der irgendwie der Imposition durchrutscht, dann ist im Zweifel rausch ein ganzes System ab und hat eine Daumenteile.

00:58:28.100 --> 00:58:33.780
Genau, der Monolith ist so ein klassisches Beispiel für Single-Point-of-Failure.

00:58:34.040 --> 00:58:38.380
Auch das kannst du irgendwie umgehen, indem du hast ein Backup-System, du hast das parallelisiert, was weiß ich.

00:58:38.640 --> 00:58:45.460
Also du kannst die Chance minimalisieren, dass du genau an solche Punkte läufst, mit Rollback, mit AB-Tests und so weiter.

00:58:45.720 --> 00:58:48.700
Also du hast eine Möglichkeit, aber auch das musst du dir halt erstmal aufbauen.

00:58:48.700 --> 00:58:50.660
Das heißt, du musst dir mit der Zeit erstmal

00:58:50.660 --> 00:58:52.600
aufbauen, mit dieser Komplexität umzugehen und

00:58:52.600 --> 00:58:54.720
am Ende stellt sich die Frage, wie gut

00:58:54.720 --> 00:58:56.660
gehst du eigentlich gerade mit der Komplexität um und

00:58:56.660 --> 00:58:58.320
kann das mein Team zum Beispiel sehr, sehr gut

00:58:58.320 --> 00:59:00.740
und bin ich mit der Geschwindigkeit so zufrieden,

00:59:00.840 --> 00:59:02.820
weil ich habe die Erfahrung gemacht,

00:59:03.040 --> 00:59:05.040
dass sich bei einem Monolithen

00:59:05.040 --> 00:59:06.560
irgendwann viele Entwickler darüber

00:59:06.560 --> 00:59:08.680
beschweren, dass das Deployment

00:59:08.680 --> 00:59:10.600
zu langsam ist insgesamt, dass die Features teilweise

00:59:10.600 --> 00:59:12.760
zu lang rumliegen, weil zu viele Leute

00:59:12.760 --> 00:59:14.760
dann denken, wenn ich so zwei, drei

00:59:14.760 --> 00:59:16.140
im Tag rausschrauben will, ist das schon ein bisschen doof.

00:59:16.560 --> 00:59:18.640
Ja, nicht nur, wir reden ja nicht über Stunden, wir reden teilweise

00:59:18.640 --> 00:59:20.680
über Tagen, Wochen. Also das ist schon nicht so

00:59:20.680 --> 00:59:22.000
einfach. Und dann kippt auf einmal was um.

00:59:22.480 --> 00:59:24.960
Du musst das

00:59:24.960 --> 00:59:26.500
irgendwie organisieren, dass du einzelne Sachen

00:59:26.500 --> 00:59:28.540
deployst. Und dann ist es natürlich schon cooler, wenn du

00:59:28.540 --> 00:59:30.660
einen einzelnen Microservice hast. Und wenn der mal umkippt,

00:59:30.680 --> 00:59:32.660
dann ist das nicht so schlimm für die Gesamtanwendung.

00:59:32.960 --> 00:59:34.680
Du gefährdest dadurch relativ wenig andere

00:59:34.680 --> 00:59:36.520
Sachen durch das Deployment. Also erstmal wirst du

00:59:36.520 --> 00:59:38.500
durch einen Microservice, wie wir schon gesagt haben,

00:59:38.540 --> 00:59:40.480
unter Umständen auch nicht zwingend. Du musst es natürlich

00:59:40.480 --> 00:59:41.300
auch erstmal gut machen.

00:59:42.200 --> 00:59:44.960
Aber du kannst gewisse bürokratische

00:59:44.960 --> 00:59:46.500
Randeffekte dadurch durchaus

00:59:46.500 --> 00:59:48.360
vermeiden erstmal. Also dass wir zum Beispiel

00:59:48.360 --> 00:59:50.340
ein Grund zu sagen, ich will das jetzt aufsplitten.

00:59:51.240 --> 00:59:52.240
Ein anderer Grund ist,

00:59:52.860 --> 00:59:54.200
dass wir reden über

00:59:54.200 --> 00:59:56.220
große Codebasen. Also das muss man halt

00:59:56.220 --> 00:59:58.460
immer erwähnen. Wir reden über große Teams.

00:59:59.160 --> 01:00:00.240
Und niemand kennt

01:00:00.240 --> 01:00:02.360
den ganzen Code. Also was bringt

01:00:02.360 --> 01:00:04.320
dir ein einheitlicher Text

01:00:04.320 --> 01:00:05.740
weg, wenn du dich eh nicht mit

01:00:05.740 --> 01:00:07.420
Sachen in den

01:00:07.420 --> 01:00:10.160
Core-Geschichten auseinandergesetzt hast, weil du

01:00:10.160 --> 01:00:12.080
meinetwegen, weiß ich nicht,

01:00:12.180 --> 01:00:14.100
im krassesten Beispiel, du bist Frontend-Entwickler in einer

01:00:14.100 --> 01:00:15.760
Django-Anwendung und du nutzt noch

01:00:15.760 --> 01:00:18.060
kein Vue.js oder sowas,

01:00:18.060 --> 01:00:19.960
sondern du schreibst irgendwie dein Frontend-Code

01:00:19.960 --> 01:00:21.900
in die Django-Anwendung rein

01:00:21.900 --> 01:00:24.460
als JavaScript-Entwickler

01:00:24.460 --> 01:00:26.200
hast du auch nichts mit Python

01:00:26.200 --> 01:00:28.180
am Hut. Da macht es schon

01:00:28.180 --> 01:00:30.200
Sinn, dass du sagst, okay gut, ich baue jetzt mein eigenes Frontend

01:00:30.200 --> 01:00:31.780
irgendwo anders. Ist jetzt nicht wirklich ein

01:00:31.780 --> 01:00:33.560
Microservice, aber das verhandelt einfach

01:00:33.560 --> 01:00:36.000
das Problem so ein bisschen, dass dieser Entwickler

01:00:36.000 --> 01:00:38.040
nicht den ganzen Stack kennt und auch überhaupt nicht

01:00:38.040 --> 01:00:38.460
kennen muss.

01:00:41.700 --> 01:00:41.980
Gut.

01:00:45.260 --> 01:00:46.040
Ich frage mich halt,

01:00:46.040 --> 01:00:46.400
ob das

01:00:46.400 --> 01:00:48.620
einen Unterschied macht.

01:00:48.740 --> 01:00:50.840
Also es ist ja egal, ob jetzt jemand an seinem Feature-Branch

01:00:50.840 --> 01:00:51.780
irgendwie eine App baut.

01:00:53.220 --> 01:00:54.520
Süßer, wenn es keinen Unterschied macht,

01:00:54.580 --> 01:00:55.380
ist es doch doppelt egal.

01:00:55.580 --> 01:00:58.360
Nein, aber das ist ja dann trotzdem im Monolithen.

01:00:58.800 --> 01:01:00.820
Ja gut, aber also mindestens

01:01:00.820 --> 01:01:02.720
habe ich Komplexität draus.

01:01:02.860 --> 01:01:04.960
Sowohl im Code, Microservices ist ein kleinerer Code,

01:01:05.040 --> 01:01:06.680
der ist ein bisschen leichter zu lesen, du kannst dich ein bisschen

01:01:06.680 --> 01:01:08.780
schneller einarbeiten, weil du nicht vor einer Wand aus Code stehst.

01:01:09.120 --> 01:01:10.840
Du stehst vor einer Wand aus Guidelines

01:01:10.840 --> 01:01:12.800
und Jira-Pages

01:01:12.800 --> 01:01:13.700
und was weiß ich.

01:01:13.700 --> 01:01:43.680
und die Programmiersprache Python.

01:01:43.700 --> 01:01:45.100
Da musst du die Reihenfolge festlegen.

01:01:45.320 --> 01:01:47.340
Auch das hast du in Microservices, wenn sie unabhängig

01:01:47.340 --> 01:01:48.660
voneinander sind, teilweise nicht.

01:01:49.040 --> 01:01:50.520
Aber klar, Breaking Changes ist immer ein Thema.

01:01:50.840 --> 01:01:52.420
Das hast du jetzt auch sehr schön geredet.

01:01:52.740 --> 01:01:54.180
In meinem Kopf ploppt gerade wieder aus,

01:01:54.180 --> 01:01:56.920
wenn ich das dann warten möchte und wenn ich das

01:01:56.920 --> 01:01:59.260
ausbauen möchte, wenn das Team weg ist,

01:01:59.320 --> 01:02:01.160
was die Microsoft entwickelt hat, dann muss ich ja wieder

01:02:01.160 --> 01:02:03.320
Experten suchen, sich dann mit dem anderen TechSec auskennen,

01:02:03.380 --> 01:02:04.100
den ich jetzt gar nicht kenne.

01:02:04.340 --> 01:02:07.340
Der Microservice an sich, der soll relativ schnell

01:02:07.340 --> 01:02:09.340
entwickelt sein. Ich meine, das ist jetzt auch wieder

01:02:09.340 --> 01:02:11.200
Theorie, aber rein theoretisch soll auch

01:02:11.200 --> 01:02:12.760
ein Microservice austauschbar sein.

01:02:12.760 --> 01:02:14.240
Ja, okay, das heißt

01:02:14.240 --> 01:02:16.940
das ist ein Wegwerfding, das heißt, wenn es nicht mehr läuft

01:02:16.940 --> 01:02:18.880
dann würde ich halt jemand aus einem anderen TechSec den

01:02:18.880 --> 01:02:20.880
gleichen Microservice neu baut irgendwie und das dann

01:02:20.880 --> 01:02:22.360
günstiger, als den anderen

01:02:22.360 --> 01:02:24.100
neu zu warten, ja, okay

01:02:24.100 --> 01:02:26.860
Ja, ja, könntest du natürlich

01:02:26.860 --> 01:02:28.820
machen, aber ja, ich meine, ja, ehrlich gesagt

01:02:28.820 --> 01:02:30.980
ich würde, also ich meine, ich würde

01:02:30.980 --> 01:02:32.660
schon sagen, natürlich, das ist klar, dass

01:02:32.660 --> 01:02:34.860
Situationen in den Microservices halt voll gut sind

01:02:34.860 --> 01:02:36.880
würde ich

01:02:36.880 --> 01:02:38.340
jetzt gar nicht bestreiten wollen, aber

01:02:38.340 --> 01:02:40.700
auch, also, würde man damit anfangen

01:02:40.700 --> 01:02:42.100
wollen. Wenn man jetzt noch nichts

01:02:42.100 --> 01:02:44.540
gebaut hat, da wäre ich auch eher skeptisch, glaube ich.

01:02:45.080 --> 01:02:46.120
Aber genau,

01:02:46.900 --> 01:02:48.140
das ist halt die Frage,

01:02:48.360 --> 01:02:49.940
gibt es irgendwie einen Grund, warum man das machen sollte?

01:02:51.780 --> 01:02:52.500
Was ich dann,

01:02:52.660 --> 01:02:54.560
was der Autor

01:02:54.560 --> 01:02:56.100
von dem Buch da meinte, ist so, naja,

01:02:56.300 --> 01:02:58.300
eigentlich eher so, Microsoft, das macht man halt dann,

01:02:58.380 --> 01:03:00.040
wenn sonst nichts mehr funktioniert.

01:03:00.500 --> 01:03:01.420
Also wenn halt sozusagen,

01:03:01.980 --> 01:03:04.060
wenn alle anderen Ansätze halt nicht funktionieren,

01:03:04.060 --> 01:03:05.860
dann muss man halt irgendwie, ne, aber

01:03:05.860 --> 01:03:08.200
ja,

01:03:08.440 --> 01:03:09.700
also, und

01:03:09.700 --> 01:03:24.940
und der sagt halt, der Hauptgrund, der wichtigste Grund, der tatsächlich irgendwie valide ist, ist halt, dass man Teile der Organisation halt unabhängig machen will vom Rest, eben dadurch, dass sie halt selber deployen können und genau, wenn das halt anders nicht geht, dann muss man das halt so machen.

01:03:25.360 --> 01:03:35.640
Aber, und ja, das kann natürlich sein, wenn du halt einen großen Monolithen hast, den du schlecht deployen kannst und dann halt einzelne Teams halt sagen, so, wir würden gerne, aber wir kommen, das wird nicht live, das, was wir machen, dann geht es halt vielleicht nicht anders.

01:03:35.640 --> 01:03:36.500
aus der Ausbildung machen.

01:03:36.800 --> 01:03:39.300
Wir können vielleicht auch sogar in Richtung

01:03:39.300 --> 01:03:41.000
Use Cases gehen. Ich meine, wir hatten ja schon

01:03:41.000 --> 01:03:43.040
Beispiel der Bestellservice meinetwegen oder IoT,

01:03:43.180 --> 01:03:44.760
wäre auch noch so ein Bereich, wo es

01:03:44.760 --> 01:03:47.380
prinzipiell durchaus auch natürlich wirken kann,

01:03:47.480 --> 01:03:49.260
Microservices zu etablieren. Ich meine,

01:03:49.700 --> 01:03:51.300
nehmen wir jetzt mal an, wir haben einen sehr, sehr

01:03:51.300 --> 01:03:53.660
großen Datendurchsatz. Also wir haben irgendwo eine Nutzerplattform,

01:03:53.760 --> 01:03:55.180
da machen Nutzer irgendwelche Sachen und

01:03:55.180 --> 01:03:57.560
parallel davon kommen meinetwegen aus dem IoT-Bereich

01:03:57.560 --> 01:03:59.720
irgendwelche Temperaturdaten

01:03:59.720 --> 01:04:00.900
von Heizung rein oder

01:04:00.900 --> 01:04:02.860
Geodaten vom Auto, was weiß ich.

01:04:03.320 --> 01:04:04.860
Also du schreibst ja viele Daten.

01:04:05.640 --> 01:04:21.440
Dann willst du natürlich dafür sorgen, dass dieser Schreibprozess, der die ganze Zeit irgendwo hinschreibt, von deinem User-Dashboard irgendwie entkoppelt ist. Du hast ja keinen Bock, dass die Datenbank dadurch langsamer wird. Unter Umständen ist die Datenbank da auch gar nicht die richtige für, um diese Art von Daten da reinzuschreiben.

01:04:21.440 --> 01:04:51.440
Das heißt, wir haben auf einmal mit diesem Beispiel einen Kontext geschaffen, wo wir sagen müssen, okay, wir haben zwei komplett unterschiedliche Anforderungen geschaffen. Wir haben einmal irgendein Dashboard, das ist so klassisch HTML, kannst in der SKL-Datenbank hinterhängen, ist alles toll. Und wir haben auf einmal irgendwie meinetwegen IoT-Daten, Geodaten, irgendwas, die in hoher Frequenz beschrieben werden. Da müssen wir uns überlegen, gut, wie verwalten wir den ganzen Spaß eigentlich? Eignet sich dafür meine...

01:04:51.440 --> 01:04:53.280
der SQL-Datenbank. Da kommen die Sachen von

01:04:53.280 --> 01:04:55.600
der IoT-Sache einfach rein und der User

01:04:55.600 --> 01:04:57.700
liest halt auch sehr. Ja, ich

01:04:57.700 --> 01:04:59.540
fülle das erstmal weiter aus noch. Also ich kann

01:04:59.540 --> 01:05:01.640
überlegen, schreibe ich das jetzt gleichzeitig damit rein.

01:05:02.020 --> 01:05:03.300
Aber irgendwann stelle ich halt fest, okay,

01:05:04.280 --> 01:05:05.520
zu Lastzeiten wird

01:05:05.520 --> 01:05:07.120
auf einmal meine Internetseite langsamer,

01:05:07.520 --> 01:05:09.440
weil ich auf einmal zu viele Daten schreibe von

01:05:09.440 --> 01:05:11.520
diesem IoT-Prozess. Und die User,

01:05:11.600 --> 01:05:13.240
die kriegen eine schlechte

01:05:13.240 --> 01:05:15.120
Nutzererfahrung dadurch. Also

01:05:15.120 --> 01:05:17.140
die Schreiblast, die steigt,

01:05:17.380 --> 01:05:19.460
dadurch wird die Internetseite unter Umständen langsamer,

01:05:19.460 --> 01:05:21.880
weil ich alles ineinander verwurschtelt habe

01:05:21.880 --> 01:05:23.840
und dann muss ich überlegen, gut, wie gehe ich

01:05:23.840 --> 01:05:24.340
jetzt damit um?

01:05:27.140 --> 01:05:28.100
Normalerweise sollte

01:05:28.100 --> 01:05:29.940
das gar nicht

01:05:29.940 --> 01:05:30.680
so viel langsamer werden, oder?

01:05:31.680 --> 01:05:33.600
Wenn du schreibst, klar

01:05:33.600 --> 01:05:34.840
aber gut

01:05:34.840 --> 01:05:37.720
Also zum Beispiel Postgres lockt jetzt

01:05:37.720 --> 01:05:39.640
nur die Zeile, wenn du schreibst und wenn du jetzt

01:05:39.640 --> 01:05:41.480
ein neues IoT hast, dann hat der neue Zeile drauf

01:05:41.480 --> 01:05:43.660
das heißt der Nutzer kann ja alle anderen Zeilen zum Beispiel

01:05:43.660 --> 01:05:45.340
lesen

01:05:45.340 --> 01:05:47.160
Ja, also ich meine

01:05:47.160 --> 01:05:49.440
Aber es kann natürlich schon passieren,

01:05:49.520 --> 01:05:50.340
dass Schreiblast irgendwann

01:05:50.340 --> 01:05:53.220
dein System langsam macht.

01:05:53.740 --> 01:05:54.840
Aber auch meine Frage wäre halt,

01:05:54.980 --> 01:05:56.760
wie häufig kommt das denn vor,

01:05:56.980 --> 01:05:59.020
dass man so skalierbar, oder ich würde sagen,

01:05:59.160 --> 01:06:00.880
ja, es gibt einen validen Grund, Microservices

01:06:00.880 --> 01:06:03.200
aus Skalierbarkeitsgründen einzusein, aber wie häufig kommt denn das vor?

01:06:03.240 --> 01:06:04.460
Nein, aber nochmal kurz zu

01:06:04.460 --> 01:06:07.000
fragen, was wäre denn jetzt die Lösung

01:06:07.000 --> 01:06:09.000
davon? Dann habe ich Sachen, die IoT

01:06:09.000 --> 01:06:10.580
schreibt in eine Datenbank rein und

01:06:10.580 --> 01:06:13.020
dann habe ich ja, der in Flaschen heißt

01:06:13.020 --> 01:06:15.100
bei dem Prozess, der von der einen Datenbank

01:06:15.100 --> 01:06:16.840
in die andere Datenbank das übertragen muss, dann

01:06:16.840 --> 01:06:19.840
Ist ja der Stand alt, beispielsweise, weil die Verbindung...

01:06:19.840 --> 01:06:22.600
Ja, die Frage ist, ob wir das überhaupt übertragen müssen.

01:06:23.020 --> 01:06:24.200
Also Microservices.

01:06:25.360 --> 01:06:29.420
Als erstes stelle ich fest, okay, das passt jetzt nicht irgendwie in die SQL-Datenbank.

01:06:29.500 --> 01:06:30.280
Die wächst mir zu schnell.

01:06:30.420 --> 01:06:33.620
Das sind Zeitreihen zum Beispiel.

01:06:34.060 --> 01:06:36.600
Dann schreibe ich das in eine Datenbank, die extra dafür vorgesehen ist.

01:06:38.240 --> 01:06:40.540
Prometheus ist auch eine, aber die ist eher so für Metrikdaten.

01:06:41.160 --> 01:06:42.180
Dann schreibe ich das da rein.

01:06:42.240 --> 01:06:45.040
Dann überlege ich, gut, wie ziehe ich mir die jetzt in dieses monolithische Ding?

01:06:45.040 --> 01:06:47.120
aber es macht für mich erstmal überhaupt keinen Sinn, diese Art

01:06:47.120 --> 01:06:48.880
von Daten in die SQL-Datenbank vielleicht zu schreiben.

01:06:49.540 --> 01:06:51.260
Das heißt, ich habe diesen Prozess mal getrennt

01:06:51.260 --> 01:06:53.000
und auf einmal habe ich

01:06:53.000 --> 01:06:53.380
Möglichkeiten.

01:06:55.640 --> 01:06:57.020
Auf einmal habe ich es geschafft,

01:06:57.100 --> 01:06:58.780
diesen Prozess zu trennen und jetzt kann ich überlegen, gut,

01:06:59.820 --> 01:07:00.940
zu Lastzeiten zum Beispiel

01:07:00.940 --> 01:07:02.620
haben wir immer höhere Peaks.

01:07:03.480 --> 01:07:05.060
Wie kann ich die Architektur jetzt vielleicht

01:07:05.060 --> 01:07:05.920
sogar günstig halten?

01:07:06.960 --> 01:07:09.260
Dann kann ich auf einmal überlegen, weil ich jetzt meine Datenbanken

01:07:09.260 --> 01:07:10.940
getrennt habe, ich habe jetzt eingesehen, okay, ich habe

01:07:10.940 --> 01:07:13.120
einen getrennten Schreibprozess von diesem Dashboard-Prozess.

01:07:13.120 --> 01:07:43.100
und Jochen unterhalten sich über die Programmiersprache Python

01:07:43.120 --> 01:07:46.720
abarbeiten. Also von diesem Ticketsystem kann ich mir dann meinetwegen

01:07:46.720 --> 01:07:50.900
10 Minuten verzögert Nachrichten rausziehen und die dann erst in die Datenbank

01:07:50.900 --> 01:07:55.280
reinschreiben und dann habe ich nicht das Problem, dass ich meinen Server unter Umständen dynamisch skalieren muss.

01:07:57.240 --> 01:07:58.600
Oder generell hochskalieren muss.

01:07:59.580 --> 01:08:03.320
Ja, aber gut, da wäre halt die Frage, was ist...

01:08:03.320 --> 01:08:06.760
Ja, also ja, ist alles valide, aber

01:08:06.760 --> 01:08:10.900
was ist teurer? Die Architektur aufzuteilen oder

01:08:10.900 --> 01:08:12.320
einen dickeren Server zu kaufen.

01:08:13.000 --> 01:08:15.080
Ja, aber auch da

01:08:15.080 --> 01:08:16.560
gibt es so sehr, sehr schöne Graphen.

01:08:16.680 --> 01:08:17.380
Das ist natürlich

01:08:17.380 --> 01:08:21.060
ein Monolith. Das ist sehr, sehr lange günstiger

01:08:21.060 --> 01:08:23.000
als Microsoft. Das stimmt. Aber irgendwann,

01:08:23.280 --> 01:08:25.080
irgendwann kann man zu diesem Punkt

01:08:25.080 --> 01:08:27.320
kommen, wo es überproportional

01:08:27.320 --> 01:08:28.880
teurer wird, sich größere

01:08:28.880 --> 01:08:30.980
Hardware zu kaufen. Also erstmal steigt das

01:08:30.980 --> 01:08:32.420
irgendwie sehr, sehr gradlinig.

01:08:33.620 --> 01:08:35.140
Ich gestikuliere hier immer so rum,

01:08:35.200 --> 01:08:35.740
aber es ist ja Podcast.

01:08:37.020 --> 01:08:37.500
Also,

01:08:37.500 --> 01:08:39.040
anschauen.

01:08:41.140 --> 01:08:42.240
Erstmal steigt das relativ

01:08:42.240 --> 01:08:44.080
geradlinig, also irgendwie f von x

01:08:44.080 --> 01:08:45.900
gleich x, kann man sich sehr schön vorstellen.

01:08:46.440 --> 01:08:48.480
Und hinten raus wird es dann auf einmal exponentiell.

01:08:49.600 --> 01:08:50.040
Dann

01:08:50.040 --> 01:08:51.700
explodieren die Kosten, weil

01:08:51.700 --> 01:08:53.400
die Maschinen dann einfach wirklich

01:08:53.400 --> 01:08:56.260
sehr, sehr teuer sind.

01:08:56.940 --> 01:08:58.320
Also ich finde, das Problem,

01:08:58.360 --> 01:09:00.020
was du gerade gesprochen hast, müsste man eigentlich nochmal mit

01:09:00.020 --> 01:09:01.980
Leuten, die noch ein bisschen mehr Spezialwissen

01:09:01.980 --> 01:09:03.280
in Datenbank haben, sprechen, weil

01:09:03.280 --> 01:09:06.100
für mich hört sich das nicht so an, als wäre da der Flaschenhals

01:09:06.100 --> 01:09:07.260
an der richtigen Stelle.

01:09:07.500 --> 01:09:09.880
und das gibt es alles schon.

01:09:10.100 --> 01:09:11.560
Also es ist halt die Frage, ob es so häufig ist.

01:09:11.840 --> 01:09:13.780
Ich meine, das Problem ist halt, also was du dafür

01:09:13.780 --> 01:09:15.240
aufgibst, ist natürlich die Konsistenz.

01:09:16.780 --> 01:09:17.920
Ja, das stimmt halt

01:09:17.920 --> 01:09:19.740
einfach nicht mehr. Und ich habe halt dazwischen noch so ein extra Layer,

01:09:19.820 --> 01:09:21.420
wenn ich jetzt einen Kafka dazwischen mache. Warum?

01:09:21.600 --> 01:09:23.740
Also wenn ich jetzt eigentlich direkt aus der Datenbank lesen könnte

01:09:23.740 --> 01:09:25.940
und du sagst halt, die Datenbank wird langsam, das verstehe ich nicht so genau,

01:09:26.360 --> 01:09:26.620
weil

01:09:26.620 --> 01:09:29.260
wie viele Verbindungen hat die denn dann offen?

01:09:29.900 --> 01:09:30.400
Nein, aber

01:09:30.400 --> 01:09:31.960
zum Beispiel,

01:09:32.520 --> 01:09:35.300
du hast ja nur eine bestimmte Bandbreite zu deinen

01:09:35.300 --> 01:09:37.280
Platten, wenn du es wirklich schreiben musst.

01:09:37.280 --> 01:10:07.260
und Jochen unterhalten sich über die Programmiersprache Python

01:10:07.280 --> 01:10:08.480
viel langsamer als sowas wie Redis.

01:10:09.300 --> 01:10:10.980
Aber bei Redis ist halt auch, wenn du dann

01:10:10.980 --> 01:10:13.160
das Ding ausmachst, dann sind deine Daten

01:10:13.160 --> 01:10:14.860
halt weg. Bei Postgres nicht.

01:10:15.000 --> 01:10:17.040
Da sind die Daten halt noch da. Das ist der große Unterschied.

01:10:17.660 --> 01:10:19.000
Ja, aber die Frage ist halt, was halt dann

01:10:19.000 --> 01:10:20.960
schreiben und so weiter, wann wird das halt überhaupt freigegeben?

01:10:21.120 --> 01:10:21.900
Also das ist ja egal.

01:10:22.220 --> 01:10:24.980
Wenn die Datenmarkt sagt, deine Transaktion ist durch, dann ist das wirklich

01:10:24.980 --> 01:10:26.840
das Klassikland. Ja, aber das macht aber die Postgres nicht langsamer,

01:10:26.960 --> 01:10:29.300
sondern das ist halt nur so, dass das nur schreiben langsamer.

01:10:30.240 --> 01:10:31.160
Ja, aber das macht die langsamer.

01:10:31.180 --> 01:10:32.980
Ja, aber das macht schreiben langsamer, aber das heißt nicht, dass das

01:10:32.980 --> 01:10:35.060
Lesen langsamer wird. Ja, doch.

01:10:35.060 --> 01:11:05.040
und Jochen unterhalten sich über die Programmiersprache Python

01:11:05.060 --> 01:11:06.320
kannst als Schreiben. Und dann

01:11:06.320 --> 01:11:08.500
die Bandbreite zu deinen Platten halt

01:11:08.500 --> 01:11:10.100
oder SSDs heute halt irgendwie

01:11:10.100 --> 01:11:12.660
ausgefüllt ist mit Schreibvorgängen.

01:11:13.180 --> 01:11:14.320
Dann kannst du nicht mehr viel lesen.

01:11:14.620 --> 01:11:16.660
Nein, wieso? Also lesen lässt du ja eh noch auf dem Speicher. Das ist ja egal.

01:11:18.280 --> 01:11:19.240
Das I.O. ist ja nur

01:11:19.240 --> 01:11:19.700
das CPU.

01:11:19.840 --> 01:11:22.460
Ja, das ist sowieso immer

01:11:22.460 --> 01:11:23.020
im Hauptspeicher.

01:11:24.440 --> 01:11:26.040
Das ist immer im Hauptspeicher. Das ist wirklich so.

01:11:26.320 --> 01:11:28.160
Und das Einzige, was halt da dein

01:11:28.160 --> 01:11:30.100
Konzern ist, ist dann die CPU-Kerne, die halt damit

01:11:30.100 --> 01:11:32.380
beschäftigt sind. Wie viele Prozesse

01:11:32.380 --> 01:11:34.340
du offen hast. Das heißt, wie viel Gleichzeitverbindung

01:11:34.340 --> 01:11:35.280
und ihr dürft dann in der Datenbank stehen.

01:11:36.460 --> 01:11:38.480
Ja, also sagen wir mal so, in der Praxis

01:11:38.480 --> 01:11:40.440
das, wo dir häufig

01:11:40.440 --> 01:11:42.400
das System platzt, ja, ich sag mal so,

01:11:42.500 --> 01:11:44.060
also das ist also Erfahrungswert aus der Praxis,

01:11:44.460 --> 01:11:46.700
das, wo du dann merkst, okay, ich hab hier ein Problem,

01:11:47.160 --> 01:11:48.400
wo ich irgendwie mit der Architektur

01:11:48.400 --> 01:11:50.000
anfangen muss, was zu machen, ist,

01:11:50.640 --> 01:11:51.820
dass irgendwann

01:11:51.820 --> 01:11:54.460
deine Slaves mit der Schreiblast nicht mehr klarkommen.

01:11:54.680 --> 01:11:56.120
Also deine Replikas, ja.

01:11:56.460 --> 01:11:57.980
Wenn du das nicht mehr hinkriegst,

01:11:58.040 --> 01:12:00.280
wenn dein Replikations-Lag immer größer wird,

01:12:00.620 --> 01:12:02.440
weil du das nicht mehr weggeschrieben bekommst,

01:12:02.440 --> 01:12:03.400
was du an Schreiblast hast.

01:12:03.400 --> 01:12:33.380
und Jochen unterhalten sich über die Programmiersprache Python

01:12:33.400 --> 01:12:35.040
und dann lesen die halt aus dem anderen Teil.

01:12:35.540 --> 01:12:36.980
Ja, aber was ist, wenn deine Slaves das nicht mehr

01:12:36.980 --> 01:12:38.360
wegschreiben können? Das passiert.

01:12:38.840 --> 01:12:41.360
Das ist so. Das ist halt bis an den Punkt,

01:12:41.420 --> 01:12:42.440
wo es nicht mehr geht. Noch mehr Slaves?

01:12:43.300 --> 01:12:45.100
Nein, die können es nicht mehr schnell genug

01:12:45.100 --> 01:12:46.120
wegschreiben. Das ist vorbei.

01:12:46.900 --> 01:12:49.120
An der Stelle, also ich meine, das ist heutzutage,

01:12:49.240 --> 01:12:50.860
also wer kommt an diese Punkte? Also das ist halt,

01:12:51.540 --> 01:12:53.320
ja, das ist nicht so häufig, denke ich.

01:12:53.400 --> 01:12:55.240
Aber das kann schon passieren

01:12:55.240 --> 01:12:56.580
und dann musst du schaben.

01:12:56.680 --> 01:12:59.400
Wenn man den Rest dann vorher richtig gemacht hat,

01:12:59.400 --> 01:13:01.180
die Frage wäre halt, wenn du das sowieso nicht schnell genug

01:13:01.180 --> 01:13:04.300
wegschreiben kannst, dann musst du ja eh warten irgendwo.

01:13:04.600 --> 01:13:07.160
Ja, und da hilft dann noch Kafka. Da hast du die Nachrichten

01:13:07.160 --> 01:13:09.120
schön in einem Topic und holst sie dir später nochmal ab.

01:13:09.760 --> 01:13:13.260
Die Frage ist natürlich, wie lange soll er drinbleiben, aber da brauchst du halt genug Worker.

01:13:13.360 --> 01:13:16.140
Also diesen Prozess, den müsstest du dann gewährleisten können, aber auch da hast du Möglichkeiten.

01:13:17.040 --> 01:13:19.180
Dann kannst du sagen, irgendwie bis zu so und so viel Speicher

01:13:19.180 --> 01:13:21.140
soll vorgehalten werden oder so und so lange.

01:13:21.780 --> 01:13:24.520
Und dann kannst du dir das wegschmeißen und du musst auch überlegen, brauche ich alles?

01:13:24.940 --> 01:13:25.580
Brauche ich alles, alles?

01:13:26.720 --> 01:13:28.320
Du hast halt eine Latenz dann, ne?

01:13:28.320 --> 01:13:29.920
oder nicht nur Latenz.

01:13:30.100 --> 01:13:32.000
Vielleicht hast du auch einen Datenverlust unter Umständen.

01:13:32.100 --> 01:13:34.800
Aber die Frage ist, kann ich vielleicht Daten verlieren?

01:13:35.360 --> 01:13:36.760
Ich meine, gerade im Bereich

01:13:36.760 --> 01:13:38.360
von Zeitreihen ist es auch oft so, dass Daten

01:13:38.360 --> 01:13:40.040
über einen gewissen Zeitraum hinweg

01:13:40.040 --> 01:13:42.600
zusammengefasst werden und einfach irgendwie gemittelt werden.

01:13:44.000 --> 01:13:45.080
Und dann ist das Problem,

01:13:45.200 --> 01:13:46.440
worüber wir uns gerade streiten,

01:13:46.680 --> 01:13:48.660
gar nicht mehr so schlimm. Aber das Problem ist

01:13:48.660 --> 01:13:50.680
in dem Zeitpunkt schlimm, wenn du es auf einmal

01:13:50.680 --> 01:13:52.780
in einer monolithischen Struktur vielleicht hast

01:13:52.780 --> 01:13:54.600
und einzelne Services dadurch umkippen

01:13:54.600 --> 01:13:56.760
und du hast es jetzt irgendwie so ein bisschen entlastet

01:13:56.760 --> 01:13:57.240
und

01:13:57.240 --> 01:13:59.680
dass das

01:13:59.680 --> 01:14:02.780
Replikations-Lag, wie Jochen sehr schön

01:14:02.780 --> 01:14:04.320
gesagt hat, das wächst und wächst.

01:14:04.660 --> 01:14:06.760
Dann stoppst du halt eine gewisse Zeit lang mal den Schreibprozess

01:14:06.760 --> 01:14:08.340
und hast dann meinetwegen ein Consumer-Lag

01:14:08.340 --> 01:14:11.000
im Kafka, aber das kannst du ja irgendwie so zurechtschrauben,

01:14:11.080 --> 01:14:13.040
dass es funktioniert, dass es deine Architektur verkraftet.

01:14:13.240 --> 01:14:14.460
Aber das ist natürlich ein sehr, sehr,

01:14:14.620 --> 01:14:16.520
und das muss man auch sagen, das ist ein

01:14:16.520 --> 01:14:18.680
extrem spezielles Problem, welches echt

01:14:18.680 --> 01:14:20.560
nicht jeder hat. Aber das ist ein Problem,

01:14:20.660 --> 01:14:21.640
welches man bekämpfen kann.

01:14:22.580 --> 01:14:24.920
IT-Geräte müssen denn da gegeben haben,

01:14:25.080 --> 01:14:25.800
damit das ein Problem wird?

01:14:26.760 --> 01:14:29.020
Keine Ahnung, das muss man schon ganz genau wissen

01:14:29.020 --> 01:14:31.900
Kommt drauf an, wie du das machst, wenn du am Ende auch arbeitest

01:14:31.900 --> 01:14:33.740
Ja, aber letztendlich

01:14:33.740 --> 01:14:35.420
diese Art von Problemen hast du natürlich immer

01:14:35.420 --> 01:14:37.580
Chris Künthopp

01:14:37.580 --> 01:14:39.200
für Datenbank

01:14:39.200 --> 01:14:41.840
der hat das mal irgendwie so schön genannt

01:14:41.840 --> 01:14:43.760
es gibt ja im Grunde zwei unterschiedliche Arten von Datenbanken

01:14:43.760 --> 01:14:44.660
es gibt halt die

01:14:44.660 --> 01:14:48.120
OLTP, Online Transaction Processing

01:14:48.120 --> 01:14:49.400
Datenbanken, das sind halt so die

01:14:49.400 --> 01:14:51.520
wenn du jetzt auf einen Kaufen-Button klickst

01:14:51.520 --> 01:14:53.300
die dann halt die Kauf-Transaktionen machen

01:14:53.300 --> 01:14:55.240
und es gibt halt

01:14:55.240 --> 01:14:56.940
OLAP, also Online

01:14:56.940 --> 01:14:59.300
Logistical Processing, das ist also

01:14:59.300 --> 01:15:01.440
ein Data Warehouse irgendwie und

01:15:01.440 --> 01:15:03.420
er sagte das mal sehr schön, also wenn jetzt die Leute

01:15:03.420 --> 01:15:05.100
irgendwas machen und du schreibst halt Sachen, also

01:15:05.100 --> 01:15:07.300
OLTP ist zum Schreiben gedacht und OLAP eher

01:15:07.300 --> 01:15:07.740
zum Lesen,

01:15:08.640 --> 01:15:10.860
wenn die jetzt irgendwie die ganze Zeit

01:15:10.860 --> 01:15:13.520
diese Geschichten generieren, dann also im Grunde

01:15:13.520 --> 01:15:15.080
jede OLTP-Datenbank

01:15:15.080 --> 01:15:17.280
hat in sich so ein Data Warehouse,

01:15:17.360 --> 01:15:17.960
das raus möchte.

01:15:19.960 --> 01:15:21.400
Das fand ich gerade ein sehr schönes Bild.

01:15:21.500 --> 01:15:23.260
Ja, das ist halt so. Irgendwann willst du das halt

01:15:23.260 --> 01:15:24.440
vielleicht da raustrennen.

01:15:25.240 --> 01:15:26.360
Ja.

01:15:27.720 --> 01:15:28.320
Aber spannend.

01:15:28.600 --> 01:15:30.880
Dass es dann doch wieder um Datenbank ging

01:15:30.880 --> 01:15:33.080
am Ende, bei der Frage, ob man

01:15:33.080 --> 01:15:34.180
Microsoft an der Stelle macht.

01:15:34.320 --> 01:15:35.740
Nein, das weiß ich ja gar nicht.

01:15:35.740 --> 01:15:37.740
Es kann doch sein, dass die Datenhaltung,

01:15:37.780 --> 01:15:39.020
da haben wir ja auch fast mit angefangen,

01:15:39.180 --> 01:15:41.260
dass das Datenmodell, die Datenhaltung dafür sehr relevant ist.

01:15:41.440 --> 01:15:42.540
Das ist einfach ein Problem.

01:15:42.820 --> 01:15:44.360
Das Schöne ist, dass du quasi,

01:15:45.000 --> 01:15:46.840
und das ist vielleicht eher der Knackpunkt,

01:15:46.900 --> 01:15:48.420
das Schöne ist, dass man erkannt hat,

01:15:48.520 --> 01:15:51.080
wir haben jetzt IoT-Daten, die ich vielleicht anders behandeln möchte,

01:15:51.180 --> 01:15:53.440
als meine Nutzerdaten, die ich vielleicht anders

01:15:53.440 --> 01:15:54.180
ablegen möchte.

01:15:54.180 --> 01:15:56.380
und will ich das in einem Monolithen machen

01:15:56.380 --> 01:15:58.360
oder erkenne ich, dass ich vielleicht dafür auch

01:15:58.360 --> 01:16:00.440
einfach ein ganz, ganz anderes Know-how brauche.

01:16:00.560 --> 01:16:02.380
Ich habe jetzt meinetwegen eine SQL Django Anwendung,

01:16:02.820 --> 01:16:04.580
erkenne aber, dass das kein SQL Kontext

01:16:04.580 --> 01:16:06.540
ist. Habe ich jetzt die Leute bei mir,

01:16:06.640 --> 01:16:08.580
die sich mit dieser Art von Daten auskennen

01:16:08.580 --> 01:16:10.460
oder brauche ich dafür vielleicht neue Daten?

01:16:10.980 --> 01:16:12.260
Äh, sorry, neue Leute.

01:16:12.520 --> 01:16:14.440
Und kriege ich diese neuen Leute in das bestehende

01:16:14.440 --> 01:16:16.360
Team rein oder baue ich dafür ein

01:16:16.360 --> 01:16:18.540
separates Team mit einem separaten Service auf,

01:16:18.620 --> 01:16:20.460
der da einfach parallel läuft, weil

01:16:20.460 --> 01:16:22.220
es halt besser ist in diesem Moment.

01:16:22.220 --> 01:16:24.380
für das Problem, welches ich jetzt gerade versuche

01:16:24.380 --> 01:16:26.220
zu lösen.

01:16:27.060 --> 01:16:28.220
Ich meine, das ist jetzt

01:16:28.220 --> 01:16:30.580
eine sehr, sehr schöne Wendung.

01:16:30.880 --> 01:16:32.380
Aber das ist jetzt wirklich so ein Punkt,

01:16:32.460 --> 01:16:34.280
wo man sieht, okay, jetzt auf einmal auf ganz

01:16:34.280 --> 01:16:36.420
natürliche Weise macht es auf einmal Sinn,

01:16:36.420 --> 01:16:38.680
darüber nachzudenken.

01:16:39.220 --> 01:16:40.080
Ja, das kann

01:16:40.080 --> 01:16:42.060
cost-efficient sein an der Stelle vielleicht.

01:16:43.920 --> 01:16:44.000
Ja,

01:16:44.420 --> 01:16:45.520
das ist halt mehrere Trade-offs.

01:16:46.500 --> 01:16:48.240
Auch ein anderes Beispiel, nicht unbedingt

01:16:48.240 --> 01:16:50.260
aus IoT, aber meinetwegen, du hast eine

01:16:50.260 --> 01:16:52.220
Java-Anwendung und du möchtest

01:16:52.220 --> 01:16:54.140
auf einmal eine Recommendation-Engine einbauen.

01:16:54.640 --> 01:16:55.900
So, und dann erkennst du, okay,

01:16:56.580 --> 01:16:58.140
das ist im Bereich Machine Learning,

01:16:58.980 --> 01:17:00.240
das ist in Python mehr

01:17:00.240 --> 01:17:02.340
vertreten, da hast du in Python eine größere Community,

01:17:02.840 --> 01:17:04.320
hast vielleicht auch bessere Lösungen für,

01:17:04.800 --> 01:17:06.180
dann suchst du dir ein Python-Team aus,

01:17:06.220 --> 01:17:08.000
welches dir dafür ein Model baut, welches dir dafür

01:17:08.000 --> 01:17:10.060
eine API bereitstellt. Kriegst du das

01:17:10.060 --> 01:17:12.080
jetzt unbedingt in deinen Java-Monolithen

01:17:12.080 --> 01:17:13.800
rein oder stellst du deinen Service-Indent nehmen?

01:17:15.040 --> 01:17:15.940
Nimmst du den hoch, ne,

01:17:16.000 --> 01:17:17.980
und versuchst du das vielleicht zu

01:17:17.980 --> 01:17:19.860
integrieren. Das Problem, welches dann natürlich

01:17:19.860 --> 01:17:22.100
aufkommt. Wenn du von Monolithen kommst,

01:17:22.280 --> 01:17:23.960
ist, dass du von einer

01:17:23.960 --> 01:17:25.880
konsistenten Struktur unter Umständen in eine

01:17:25.880 --> 01:17:28.120
inkonsistente reinläufst. Ja, du kannst vielleicht gar nicht warten.

01:17:28.220 --> 01:17:29.940
Du musst halt immer wieder auf das externe Team zugreifen.

01:17:30.020 --> 01:17:32.060
Ja, es muss ja nicht mal ein externes Team sein. Das kann ja auch

01:17:32.060 --> 01:17:33.320
ein neues internes Team sein.

01:17:33.880 --> 01:17:35.100
Oder dann halt intern.

01:17:35.960 --> 01:17:38.080
Klar, dieses Problem hast du dir jetzt geschaffen.

01:17:38.260 --> 01:17:39.780
Das ist irgendwo ein selbst geschaffenes Problem.

01:17:39.900 --> 01:17:41.760
Die Frage ist natürlich, komme ich da drum herum?

01:17:41.860 --> 01:17:44.000
Wie ist der Trade-off? Also man hat einfach

01:17:44.000 --> 01:17:45.840
effektiv immer einen Trade-off.

01:17:45.840 --> 01:17:47.840
Die Frage ist immer, was ist das größere

01:17:47.840 --> 01:17:48.480
Übel am Ende?

01:17:48.480 --> 01:17:51.440
und was bringt mich jetzt schneller vorwärts?

01:17:54.480 --> 01:17:55.720
Ja, insofern, also

01:17:55.720 --> 01:17:57.960
würde ich auch so sagen, also ich denke auch, es gibt

01:17:57.960 --> 01:18:00.080
gerade, also wenn man

01:18:00.080 --> 01:18:02.160
halt ganz viele Leute hat

01:18:02.160 --> 01:18:03.360
und das sehr große, dann

01:18:03.360 --> 01:18:06.200
wird Microservices immer attraktiver.

01:18:07.320 --> 01:18:07.680
Aber

01:18:07.680 --> 01:18:09.280
auf der anderen Seite,

01:18:09.860 --> 01:18:12.140
das ist halt irgendwie jetzt heutzutage

01:18:12.140 --> 01:18:14.060
oft irgendwie so, das macht man halt so

01:18:14.060 --> 01:18:15.240
und das ist halt jetzt irgendwie so.

01:18:16.060 --> 01:18:17.820
Das ist so ein bisschen, da würde ich mir denken,

01:18:17.820 --> 01:18:19.060
und so, na, ich weiß nicht.

01:18:19.780 --> 01:18:21.100
Und ich meine, da gibt es ja auch

01:18:21.100 --> 01:18:23.860
so einen schönen Begriff von

01:18:23.860 --> 01:18:25.960
David Hanemeyer-Hansen,

01:18:26.360 --> 01:18:27.120
den Rural Rails

01:18:27.120 --> 01:18:29.860
Menschen, der sagte, der versuchte

01:18:29.860 --> 01:18:31.780
den Monolith-Begriff

01:18:31.780 --> 01:18:33.900
halt aufzuwerten, indem er dann noch ein Adjektiv

01:18:33.900 --> 01:18:35.800
vorgestellt hat und nennt das

01:18:35.800 --> 01:18:37.500
jetzt immer Majestic Monolith

01:18:37.500 --> 01:18:39.520
sozusagen, weil

01:18:39.520 --> 01:18:41.820
ich meine, wenn man jetzt halt ein kleines Team hat und

01:18:41.820 --> 01:18:43.580
irgendwie etwas macht, was halt dann

01:18:43.580 --> 01:18:45.800
ist halt das unter Umständen

01:18:45.800 --> 01:18:47.700
halt deutlich effizienter, weil

01:18:47.700 --> 01:18:50.780
auch einfach was bauen willst.

01:18:50.960 --> 01:18:51.120
Genau.

01:18:52.460 --> 01:18:53.840
Das ist ja auch sehr, sehr bekannt.

01:18:54.120 --> 01:18:56.700
Wenn du jetzt gerade anfängst, dann fängst du

01:18:56.700 --> 01:18:58.280
natürlich nicht mit Microservices an.

01:18:58.500 --> 01:19:00.360
Du ziehst jetzt von null auf einen Code hoch,

01:19:00.740 --> 01:19:02.540
hast ein kleines Team, vielleicht sogar ein großes Team,

01:19:02.600 --> 01:19:04.720
das ist komplett egal, aber eigentlich

01:19:04.720 --> 01:19:06.360
denkt man da erstmal monolithisch nach.

01:19:06.640 --> 01:19:08.720
Einfach um vorwärts zu kommen, um wenig Komplexität

01:19:08.720 --> 01:19:10.940
erstmal zu haben, weil die Komplexität, die kommt erst mit der Zeit.

01:19:10.960 --> 01:19:12.700
Du bist halt jedes Mal noch einen neuen Klotz ans Bein irgendwie.

01:19:12.860 --> 01:19:14.600
Und auch noch weitere Komplexität und

01:19:14.600 --> 01:19:16.480
weitere Abhängigkeiten und Dependencies,

01:19:16.480 --> 01:19:46.460
Wenn du halt einen neuen Service hast.

01:19:46.480 --> 01:19:48.360
ist mitunter, auch dass die

01:19:48.360 --> 01:19:49.840
nicht immer unbedingt leicht sind,

01:19:50.400 --> 01:19:52.220
alle Prozesse zu parallelisieren.

01:19:52.360 --> 01:19:54.780
Du kannst einen Monolithen sehr schwer teilweise

01:19:54.780 --> 01:19:56.600
parallel laufen lassen

01:19:56.600 --> 01:19:58.380
auf verschiedenen Instanzen. Du musst es

01:19:58.380 --> 01:19:59.540
nicht immer unbedingt, aber

01:19:59.540 --> 01:20:02.080
das ist bei einer großen, komplexen

01:20:02.080 --> 01:20:04.060
Struktur mit vielen verschiedenen States

01:20:04.060 --> 01:20:06.340
ein bisschen schwieriger und manchmal ist es

01:20:06.340 --> 01:20:08.720
leichter, wenn du dir dann einzelne Teile da rausnimmst

01:20:08.720 --> 01:20:10.500
und damit schon mal anfängst,

01:20:10.940 --> 01:20:12.520
die auszulagern und dann findest

01:20:12.520 --> 01:20:14.400
du vielleicht so ein Stückchen, wo es sich lohnen würde, das Teil

01:20:14.400 --> 01:20:16.200
zu parallelisieren. Da würdest du dir vielleicht wünschen,

01:20:16.200 --> 01:20:20.180
okay, ich will meinen Server jetzt nicht mehr RAM geben, eigentlich hätte ich

01:20:20.180 --> 01:20:23.460
lieber einen weiteren dazugebucht für diesen Service, weil es vielleicht günstiger ist,

01:20:23.940 --> 01:20:28.140
weil es vielleicht leichter zu machen ist. Dann ziehst du einfach parallel noch eine

01:20:28.140 --> 01:20:32.300
Node hoch. Das wünscht man sich ja auch manchmal. Und das ist zum Beispiel, ein Microservice ist einfach

01:20:32.300 --> 01:20:36.200
natürlicherweise leichter als ein Monolithen.

01:20:40.060 --> 01:20:42.160
Wären wir ein bisschen positiver. Ist auch schön.

01:20:44.020 --> 01:20:46.040
Ja, nicht negativ.

01:20:46.200 --> 01:20:48.260
Es geht halt ein bisschen darum, wann das der Fall ist

01:20:48.260 --> 01:20:50.360
und welcher Use Case dann wirklich

01:20:50.360 --> 01:20:50.900
da für sorgen muss.

01:20:50.900 --> 01:20:54.300
Ich denke auch, wenn man das dazu bringen will,

01:20:54.380 --> 01:20:55.460
dass es ein

01:20:55.460 --> 01:20:58.200
Ding, wie das helfen kann,

01:20:58.280 --> 01:20:59.240
wenn man jetzt drüber nachdenkt,

01:20:59.900 --> 01:21:01.680
ist halt auch so,

01:21:01.960 --> 01:21:03.960
wenn man einen Microservice aufteilen will,

01:21:04.360 --> 01:21:05.740
dann ist das ja auch ein sehr schöner Anlass,

01:21:05.920 --> 01:21:07.940
darüber nachzudenken, wie sind denn eigentlich die

01:21:07.940 --> 01:21:09.700
Schnittstellen und so, wie würde man dann

01:21:09.700 --> 01:21:11.260
modularisieren wollen?

01:21:11.860 --> 01:21:13.920
Also sozusagen, eigentlich würde man dann

01:21:13.920 --> 01:21:16.040
anfangen und sagen, okay, machen wir es doch mal

01:21:16.040 --> 01:21:36.200
Modularität, also keine Ahnung, ich habe jetzt irgendwie einen Moduliten und der notifiziert irgendwie User für irgendwas und jetzt möchte ich das da raustrennen, weil irgendwie dieses ganze Handling von unterschiedlichen Wegen, wie ich User notifiziere, ist halt problematisch und ich will das gerne da raustrennen.

01:21:36.200 --> 01:21:37.720
dann wäre halt eine gute,

01:21:38.120 --> 01:21:39.820
die schlechte Strategie wäre halt

01:21:39.820 --> 01:21:40.720
irgendwie sozusagen

01:21:40.720 --> 01:21:44.360
einen JSON oder HTTP-API

01:21:44.360 --> 01:21:46.380
irgendwie jetzt vor die Funktion, die die Notifizierung

01:21:46.380 --> 01:21:48.240
gemacht, zu klemmen und das

01:21:48.240 --> 01:21:50.200
halt auf einen anderen, irgendwo anders hinzulegen

01:21:50.200 --> 01:21:52.440
und dann rufen halt aus einem Monolith

01:21:52.440 --> 01:21:54.320
die Sachen halt dann diese JSON-API auf

01:21:54.320 --> 01:21:56.220
oder so. Das ist leider

01:21:56.220 --> 01:21:58.320
halt das, was oft gemacht wird und das wird dann halt sehr schrecklich.

01:21:58.780 --> 01:22:00.100
Aber, was man ja durchaus

01:22:00.100 --> 01:22:01.820
tun könnte, ist halt, okay, man

01:22:01.820 --> 01:22:04.080
versucht das jetzt sauber zu machen, man macht halt irgendwie ein

01:22:04.080 --> 01:22:06.020
Interface, sagt, okay, so sehen

01:22:06.020 --> 01:22:07.480
die Notifizierungen aus

01:22:07.480 --> 01:22:10.160
irgendwie und die haben wir, das klassische

01:22:10.160 --> 01:22:12.000
Ding, was halt immer benutzt wird und jetzt machen wir einfach

01:22:12.000 --> 01:22:14.020
eine neue Implementation,

01:22:14.520 --> 01:22:16.140
die halt über einen Microservice

01:22:16.140 --> 01:22:17.660
geht und

01:22:17.660 --> 01:22:20.060
wir können das halt auch hinterher

01:22:20.060 --> 01:22:22.100
gucken, dann machen wir das ganz hinterher

01:22:22.100 --> 01:22:23.780
in Feature-Flag oder so und sagen, okay, jetzt schicken wir mal

01:22:23.780 --> 01:22:25.860
1% des Traffics halt irgendwie über den Microservice,

01:22:26.240 --> 01:22:28.100
dann gucken wir an, wie sehen die Fehler hinterher

01:22:28.100 --> 01:22:30.020
aus, sind die irgendwie mehr geworden oder hat das

01:22:30.020 --> 01:22:30.880
genau das gleiche getan,

01:22:31.680 --> 01:22:33.960
oder wir schicken es gar nicht raus, wir gucken einfach

01:22:33.960 --> 01:22:35.940
nur, wir schicken es an beide,

01:22:36.240 --> 01:22:37.920
wie verhält sich das denn unter

01:22:37.920 --> 01:22:39.420
Last und so, und dann kann man das schön,

01:22:39.860 --> 01:22:41.960
denke ich, machen, aber die Voraussetzung

01:22:41.960 --> 01:22:43.760
ist eigentlich, dass man das halt schon ordentlich

01:22:43.760 --> 01:22:45.740
modularisiert hat, dass man ordentlich Interfaces hat,

01:22:45.860 --> 01:22:47.820
dass man das irgendwie schon halbwegs gut

01:22:47.820 --> 01:22:48.500
strukturiert hat.

01:22:50.040 --> 01:22:50.440
Und ja,

01:22:50.600 --> 01:22:53.780
und das ist vielleicht auch so eine Möglichkeit, dann

01:22:53.780 --> 01:22:55.940
an der Stelle nochmal irgendwie drüber nachzudenken, wie

01:22:55.940 --> 01:22:57.660
modularisiert man eigentlich

01:22:57.660 --> 01:22:58.380
ordentlich.

01:22:58.380 --> 01:22:59.040
Ja, auf jeden Fall.

01:23:00.760 --> 01:23:02.480
Auch um noch eine positive

01:23:02.480 --> 01:23:03.940
und weitere Sachen aufzugreifen,

01:23:04.060 --> 01:23:04.840
wenn man gerade in den Sinn kommt.

01:23:05.940 --> 01:23:06.900
Oft ist es ja so, dass

01:23:06.900 --> 01:23:10.420
ein Datensatz, eine Row,

01:23:11.240 --> 01:23:12.360
sehr viele verschiedene Prozesse

01:23:12.360 --> 01:23:13.500
durchläuft, um

01:23:13.500 --> 01:23:15.420
in die Datenbank zu kommen.

01:23:15.940 --> 01:23:18.240
Die wird von verschiedenen Prozessen genutzt,

01:23:18.320 --> 01:23:20.020
manchmal transformiert, also die wird sehr, sehr oft

01:23:20.020 --> 01:23:20.620
durchgereicht.

01:23:22.820 --> 01:23:23.960
Das fiel mir jetzt gerade ein,

01:23:24.020 --> 01:23:26.000
als Jochen gesprochen hat, wenn du das

01:23:26.000 --> 01:23:28.120
jetzt auf einmal anfängst, den Microservices aufzuteilen,

01:23:28.200 --> 01:23:29.080
dann musst du dir natürlich überlegen,

01:23:29.080 --> 01:23:30.840
okay, wie gestalte ich jetzt den Weg

01:23:30.840 --> 01:23:32.800
von Anfang bis zum Ende durch.

01:23:34.880 --> 01:23:35.360
Und

01:23:35.360 --> 01:23:37.520
du bekommst auf einmal wesentlich mehr Möglichkeiten.

01:23:38.120 --> 01:23:39.320
Also üblicherweise ist es ja so,

01:23:39.420 --> 01:23:41.440
dass dieser Prozess in irgendeiner Form

01:23:41.440 --> 01:23:42.520
sehr, sehr synchron ist.

01:23:43.000 --> 01:23:45.120
Also geht von A nach B. Und im Prinzip

01:23:45.120 --> 01:23:47.500
wartet der Client darauf, dass der hinten angekommen ist.

01:23:47.940 --> 01:23:49.140
So wird es halt sehr oft

01:23:49.140 --> 01:23:49.780
strukturiert.

01:23:51.400 --> 01:23:53.560
Oder die Anwendung wartet auf eine Antwort,

01:23:53.560 --> 01:23:54.800
die sie nicht unbedingt braucht.

01:23:55.580 --> 01:23:57.640
Und in einer Microservice-Welt kannst du

01:23:57.640 --> 01:23:59.260
eben sehr, sehr schön darüber überlegen,

01:23:59.260 --> 01:24:01.540
wie Kommunizieren-Services allgemein miteinander.

01:24:01.780 --> 01:24:03.700
Und auf einmal stellt man eben fest,

01:24:03.760 --> 01:24:06.280
dass sie überhaupt nicht synchron miteinander kommunizieren müssen,

01:24:06.380 --> 01:24:09.180
sondern zum Beispiel auch über Queues und Topics.

01:24:09.700 --> 01:24:11.020
Und dann schickst du da ein Event hin

01:24:11.020 --> 01:24:12.760
und dann ist das so ein Write-Only-Ding.

01:24:12.960 --> 01:24:15.220
Dann schicke ich diesen einen Datensatz an diesen Endpunkt,

01:24:15.700 --> 01:24:16.800
der schreibt das Richtung Topic

01:24:16.800 --> 01:24:18.840
und von diesem Topic kann das dann

01:24:18.840 --> 01:24:23.160
von verschiedenen Microservices gleichzeitig konsumiert werden,

01:24:23.520 --> 01:24:24.780
ohne dass ich jetzt irgendwie

01:24:24.780 --> 01:24:27.260
ein Async bei mir im Code einbauen musste,

01:24:27.260 --> 01:24:29.360
um das darzustellen.

01:24:30.820 --> 01:24:31.320
Und

01:24:31.320 --> 01:24:33.460
der Nutzer, der kann sofort

01:24:33.460 --> 01:24:35.060
weitermachen. Der muss nicht unbedingt auf die

01:24:35.060 --> 01:24:37.220
Antwort warten, wenn das ein Write-Only-Prozess ist.

01:24:38.700 --> 01:24:39.620
Auch ein Vorteil.

01:24:40.040 --> 01:24:41.180
Oder auch sehr schön teilweise

01:24:41.180 --> 01:24:42.420
zu designen.

01:24:43.820 --> 01:24:44.300
Ja,

01:24:44.920 --> 01:24:46.600
wobei ich denken würde, also die

01:24:46.600 --> 01:24:48.740
Voraussetzung wäre, dass man das halt erstmal intern gemacht hat,

01:24:48.800 --> 01:24:50.680
dass man erstmal intern irgendwie so eine Art

01:24:50.680 --> 01:24:52.140
Service-Bus hat und

01:24:52.140 --> 01:24:54.900
dann kann man das halt auch

01:24:54.900 --> 01:24:56.420
vielleicht nach außen verlagern, aber

01:24:56.420 --> 01:24:58.760
Ja, also ich meine, das ist halt auch sowas,

01:24:59.620 --> 01:25:01.220
ja,

01:25:01.460 --> 01:25:03.700
wo man dann vielleicht mal drüber nachdenken kann,

01:25:03.800 --> 01:25:06.120
wie strukturiert man die Applikationen

01:25:06.120 --> 01:25:07.360
eigentlich so, dass das halt irgendwie

01:25:07.360 --> 01:25:08.500
so funktioniert.

01:25:11.460 --> 01:25:12.040
Ja, weil,

01:25:12.240 --> 01:25:13.060
ja.

01:25:13.320 --> 01:25:15.500
Es ist halt saukomplex, ne? Also das muss man halt

01:25:15.500 --> 01:25:16.420
einfach sagen.

01:25:16.440 --> 01:25:18.620
Braucht man diesen Service-Bus, also diesen Message-Queue,

01:25:18.680 --> 01:25:20.460
oder diesen Message-Booker dann halt, und wenn man den halt hat,

01:25:20.980 --> 01:25:22.080
braucht man ihn, will man ihn.

01:25:22.260 --> 01:25:24.220
Ja, also,

01:25:24.580 --> 01:25:26.080
also, weil das ist ja auch die Independence-City,

01:25:26.080 --> 01:25:56.060
und Jochen unterhalten sich über die Programmiersprache Python

01:25:56.080 --> 01:26:26.060
und die Programmiersprache Python.

01:26:26.080 --> 01:26:28.480
mehr, die wir in einer Anwendung

01:26:28.480 --> 01:26:29.260
einbauen.

01:26:29.740 --> 01:26:31.880
Du kannst ja auch in die Anwendung einbauen.

01:26:32.100 --> 01:26:33.640
Ja, aber ist das immer so geil?

01:26:34.500 --> 01:26:36.100
Ja, also ich würde sagen, das ist halt so ein bisschen

01:26:36.100 --> 01:26:38.000
die Voraussetzung dafür, dass man das überhaupt dann

01:26:38.000 --> 01:26:39.180
auftrennen kann, weil

01:26:39.180 --> 01:26:41.340
ich kenne,

01:26:41.660 --> 01:26:43.960
das ist halt die Frage, also ich kenne das halt so, dass man das intern

01:26:43.960 --> 01:26:45.280
in der Applikation vor allen Dingen macht.

01:26:45.760 --> 01:26:47.880
Also das ist halt dann auch teils, die Dinge, die man

01:26:47.880 --> 01:26:49.260
tut, teilt man halt auch in

01:26:49.260 --> 01:26:50.920
Commands, Events und

01:26:50.920 --> 01:27:02.720
vielleicht Dokumente gibt es halt auch Da gibt es den ganzen Enterprise Service wo es irgendwie wei ich nicht irgendwas Patterns seit die Frage ob man das braucht keine Ahnung Ich habe letztens mich da so ein bisschen mit besch weil ich mich da einfach mal interessiert hat

01:27:03.660 --> 01:27:04.520
wie man denn sowas baut.

01:27:04.660 --> 01:27:06.520
Da gibt es ja auch, das buche ich irgendwie auch in jeder

01:27:06.520 --> 01:27:08.300
Episode irgendwie, oh,

01:27:08.520 --> 01:27:10.380
hier liegt es rum, Architecture Patterns

01:27:10.380 --> 01:27:12.520
bloß Python. Die bauen halt,

01:27:12.560 --> 01:27:14.380
die fangen halt an und mit irgendwie auch,

01:27:14.480 --> 01:27:16.620
das ist auch, glaube ich, ein Allokations,

01:27:16.940 --> 01:27:18.280
also das, womit die sich beschäftigen,

01:27:18.360 --> 01:27:18.880
ist halt sozusagen

01:27:18.880 --> 01:27:22.600
Bestellungen

01:27:22.600 --> 01:27:25.220
irgendwelchen Lagerbeständen zuordnen sozusagen

01:27:25.220 --> 01:27:27.520
und die fangen halt an, naiv mit so einer Flask-Applikation

01:27:27.520 --> 01:27:29.160
und bauen das dann halt immer weiter um, sodass

01:27:29.160 --> 01:27:31.340
am Schluss bleibt halt auch so ein Service-Bus

01:27:31.340 --> 01:27:33.380
übrig und das könnte

01:27:33.380 --> 01:27:35.300
man dann theoretisch auch in Microservices

01:27:35.300 --> 01:27:37.220
dann halt alles dann auslagern,

01:27:37.280 --> 01:27:39.100
was man da so tut. Aber

01:27:39.100 --> 01:27:41.300
das eigentlich, würde ich sagen, so ein bisschen

01:27:41.300 --> 01:27:43.240
die Voraussetzung dafür, dass man das überhaupt kann, ist,

01:27:43.360 --> 01:27:44.580
dass man es intern schon so macht.

01:27:44.940 --> 01:27:47.520
Oder ich weiß es nicht genau,

01:27:47.520 --> 01:27:49.400
aber wenn man das jetzt von außen

01:27:49.400 --> 01:27:51.500
dran, aber

01:27:51.500 --> 01:27:53.360
nochmal zu dem, warum macht man das überhaupt

01:27:53.360 --> 01:27:55.720
mit diesen Queues und so, denke ich, der Vorteil

01:27:55.720 --> 01:27:57.260
ist halt einfach, wenn du

01:27:57.260 --> 01:27:59.620
HTTP oder JSON-RPs hast, dann machst du halt

01:27:59.620 --> 01:28:01.540
jedes Mal zum Beispiel so ein TLS-Handshake oder

01:28:01.540 --> 01:28:02.720
sowas, das ist natürlich extrem

01:28:02.720 --> 01:28:05.180
also es verbraucht immer CPU

01:28:05.180 --> 01:28:07.680
Ja, du kannst halt ein Socket aufhaben

01:28:08.360 --> 01:28:09.220
oder so. Ja, wie

01:28:09.220 --> 01:28:11.900
bei HTTP? Nein, nein

01:28:11.900 --> 01:28:13.540
einfach kein HTTP, sondern du hast halt

01:28:13.540 --> 01:28:14.740
ein Socket auf, irgendwo in der Verbindung

01:28:14.740 --> 01:28:17.040
Ja, okay, und wie sicherst du die

01:28:17.040 --> 01:28:19.020
irgendwie ab und welchen Standard

01:28:19.020 --> 01:28:20.900
wie machst du das? Keine Ahnung, also wie

01:28:20.900 --> 01:28:23.140
WebSocket genau und drunter funktioniert, aber der hat ja am Anfang

01:28:23.140 --> 01:28:24.980
beispielsweise auch seinen Handshake, aber der

01:28:24.980 --> 01:28:26.960
bleibt halt offen, der muss dann nicht jedes Mal den neuen Handshake machen, oder?

01:28:27.360 --> 01:28:29.040
Ja, bei HTTP geht das

01:28:29.040 --> 01:28:31.020
nicht. Bei HTTP

01:28:31.020 --> 01:28:32.840
gibt es immer nur Request-Response, das war auch so.

01:28:32.840 --> 01:28:34.940
Genau, ja, aber ich kann jetzt ein Socket auch machen, wenn ich

01:28:34.940 --> 01:28:35.980
jetzt auch so ein Queue-Ding habe,

01:28:36.660 --> 01:28:38.720
beispielsweise. Genau, das ist der Vorteil bei der Queue,

01:28:38.840 --> 01:28:40.820
da steht deine Verbindung und die bleibt halt

01:28:40.820 --> 01:28:43.140
und du kannst halt mehr Sachen drüber schicken, genau. Das ist halt der Riesenvorteil.

01:28:43.140 --> 01:28:45.180
Ja genau, aber ich verstehe jetzt nicht, wo der Unterschied ist.

01:28:45.220 --> 01:28:46.640
Also warum brauche ich dafür einen Microservice?

01:28:46.960 --> 01:28:49.000
Also das hat für mich jetzt nicht so viel miteinander zu tun.

01:28:49.660 --> 01:28:51.240
Nee, aber die Frage ist jetzt, wenn du jetzt

01:28:51.240 --> 01:28:53.140
Microservices hast, wie

01:28:53.140 --> 01:28:54.060
vermindest du die miteinander?

01:28:55.620 --> 01:28:57.060
Oder vielleicht habe ich die Frage einfach nicht verstanden.

01:28:57.160 --> 01:28:59.360
Ich dachte, das wäre die Frage, warum nimmt man denn da so einen Bus

01:28:59.360 --> 01:29:01.260
oder so eine Queue? Warum nimmt man nicht einfach

01:29:01.260 --> 01:29:03.140
HTT oder so? Nee, also die Frage wäre,

01:29:03.260 --> 01:29:05.180
wenn ich jetzt so einen Bus nehme, also warum mache ich das

01:29:05.180 --> 01:29:07.120
bei Microservice? Also warum mache ich das nicht trotzdem in meinem

01:29:07.120 --> 01:29:08.840
Monolithen oder so? Ja, genau, da würde ich sagen,

01:29:08.840 --> 01:29:10.540
so würde ich anfangen.

01:29:10.680 --> 01:29:12.680
Ich würde es so anfangen, dass man das zuerst so baut,

01:29:12.680 --> 01:29:42.660
und Jochen unterhalten sich über die Programmiersprache Python

01:29:42.680 --> 01:29:44.540
Das brauchst du ja nicht.

01:29:44.580 --> 01:29:46.940
Wenn du es intern machst, brauchst du das ja nicht. Das ist einfach nur ein Funktionsaufruf.

01:29:47.100 --> 01:29:48.140
Da ist eine Queue. Einfach zum Beispiel

01:29:48.140 --> 01:29:50.280
in Python ist das halt einfach nur eine Queue-Modell.

01:29:51.480 --> 01:29:51.800
Also

01:29:51.800 --> 01:29:54.380
von Queue über Queue sozusagen oder so.

01:29:54.520 --> 01:29:56.580
Und dann machst du halt, solange irgendwas in der Queue

01:29:56.580 --> 01:29:58.340
drin ist, rufst du Funktionen auf.

01:29:58.520 --> 01:30:00.280
Das war's. Das ist auch nicht...

01:30:00.280 --> 01:30:01.140
Kann man durchaus machen.

01:30:01.380 --> 01:30:04.000
Habe ich zum ersten Mal von tatsächlich.

01:30:04.180 --> 01:30:05.880
Das ist so ein Python-Ding.

01:30:06.040 --> 01:30:06.960
Genau. Queue.

01:30:07.980 --> 01:30:09.700
Es hat aber nichts mit Netzwerkverbindung oder so.

01:30:09.700 --> 01:30:10.260
Nein, nein, nein. Genau.

01:30:10.260 --> 01:30:12.160
Ist das dann einfach irgendwie so ein State, der

01:30:12.160 --> 01:30:14.480
existiert global und

01:30:14.480 --> 01:30:15.240
Ja, genau.

01:30:16.580 --> 01:30:17.020
Cool.

01:30:17.420 --> 01:30:20.500
Man kann diese Muster ja durchaus auch

01:30:20.500 --> 01:30:22.420
einfach so, deswegen meine ich

01:30:22.420 --> 01:30:23.560
also, wie man das

01:30:23.560 --> 01:30:26.320
die Struktur aufteilt und die Architektur von

01:30:26.320 --> 01:30:28.600
dem Ding baut, das kann man

01:30:28.600 --> 01:30:30.360
ja auch schon vorher richtig machen quasi

01:30:30.360 --> 01:30:32.300
und dann kann man es halt auch aufteilen

01:30:32.300 --> 01:30:34.440
oder es ist sehr einfach das aufzuteilen, während wenn man jetzt

01:30:34.440 --> 01:30:36.520
Moduliten hat und das ist tatsächlich

01:30:36.520 --> 01:30:37.120
ich fürchte,

01:30:37.400 --> 01:30:39.780
das ist halt das, was ich in der Praxis oft sehe.

01:30:39.780 --> 01:30:41.660
Ja, dass Leute halt eigentlich

01:30:41.660 --> 01:30:43.680
in so einer Situation sind,

01:30:43.740 --> 01:30:45.660
sie haben einen Big Ball of Mud,

01:30:45.980 --> 01:30:47.780
der halt irgendwie kompliziert und komisch

01:30:47.780 --> 01:30:48.880
ist und wo sie nicht weiterkommen.

01:30:50.220 --> 01:30:51.660
Und jetzt suchen sie nach irgendeiner Lösung für

01:30:51.660 --> 01:30:53.520
dieses Problem. Und dann kommen sie auf

01:30:53.520 --> 01:30:55.500
Microsoft und stürzen sich auf Microsoft und sagen so

01:30:55.500 --> 01:30:57.740
Ja, okay. Ich hänge weiter

01:30:57.740 --> 01:30:59.740
vorne. Ich will wissen,

01:30:59.860 --> 01:31:01.520
was passiert denn mit dieser Queue, wenn der Service

01:31:01.520 --> 01:31:03.740
eine Downtime hat? Nein, das ist einfach

01:31:03.740 --> 01:31:05.660
nur ein Prozess. Das ist einfach ein Prozess, ne?

01:31:05.700 --> 01:31:07.300
Also die anderen funktionieren irgendwie weiter,

01:31:07.300 --> 01:31:09.120
da ist dann irgendwie, weiß ich nicht, läuft in einer separaten

01:31:09.120 --> 01:31:10.560
in einem gleichen...

01:31:10.560 --> 01:31:12.840
Alles in einem Thread im gleichen Prozess.

01:31:16.340 --> 01:31:17.160
Das Einzige,

01:31:17.340 --> 01:31:18.800
was es halt sozusagen bringt, ist,

01:31:19.440 --> 01:31:20.940
dass ich die Sachen halt sauber

01:31:20.940 --> 01:31:22.240
voneinander getrennt habe. Ich mache halt auch

01:31:22.240 --> 01:31:25.240
immer, wenn ich irgendwas schreiben möchte,

01:31:25.320 --> 01:31:26.440
mache ich halt ein Command und

01:31:26.440 --> 01:31:28.940
ich habe halt dann meine Event-Händler, die alles mögliche machen.

01:31:29.440 --> 01:31:31.320
So zum Beispiel habe ich halt einen Event-Händler,

01:31:31.400 --> 01:31:33.260
der schickt das Event dann auf den Websocket raus

01:31:33.260 --> 01:31:35.560
für irgendeinen Client, einen anderen Event-Händler,

01:31:36.120 --> 01:31:37.260
der tritt

01:31:37.260 --> 01:31:38.540
irgendwie einen Prozess los, einen anderen

01:31:38.540 --> 01:31:40.580
so. Und das kann ich ja,

01:31:40.760 --> 01:31:42.580
aber das ist alles nur Funktionsaufrufe, die

01:31:42.580 --> 01:31:44.680
nacheinander passieren. Das ist aber alles im gleichen Prozess.

01:31:45.220 --> 01:31:46.700
Okay, also für mich so zum

01:31:46.700 --> 01:31:48.520
Verständnis. Vielleicht ergibt sich ja dann so

01:31:48.520 --> 01:31:50.440
die Möglichkeit, dass wir alle erkennen, okay, wir brauchen unbedingt

01:31:50.440 --> 01:31:50.840
Kafka.

01:31:52.760 --> 01:31:53.120
Yay!

01:31:54.300 --> 01:31:56.540
Nein, aber nur, damit ich das

01:31:56.540 --> 01:31:58.480
verstehe, nehmen wir jetzt mal an, wir sind jetzt in der Django-Anwendung

01:31:58.480 --> 01:32:00.380
unterwegs und wir schicken

01:32:00.380 --> 01:32:02.500
einen Request rein. So, und der kommt jetzt in die

01:32:02.500 --> 01:32:04.460
Queue. Die erste Frage ist, was

01:32:04.460 --> 01:32:06.460
passiert beim User? Bekommt er sofort die Antwort zurück

01:32:06.460 --> 01:32:08.420
oder wartet er darauf, dass der Prozess von

01:32:08.420 --> 01:32:09.840
und Q komplett verarbeitet wurde.

01:32:10.200 --> 01:32:11.800
Der bekommt sofort, also da ist es so,

01:32:12.220 --> 01:32:14.460
der bekommt sofort

01:32:14.460 --> 01:32:15.080
eine Antwort zurück

01:32:15.080 --> 01:32:18.120
und

01:32:18.120 --> 01:32:20.480
sozusagen die Event-Händler bearbeiten

01:32:20.480 --> 01:32:21.640
das dann halt später weiter.

01:32:21.920 --> 01:32:24.540
Die bearbeiten das später weiter, das heißt, wenn jetzt der nächste User

01:32:24.540 --> 01:32:26.760
kurz danach, bevor das alles abgearbeitet

01:32:26.760 --> 01:32:27.680
wurde, wieder ein Request reinpickt.

01:32:27.680 --> 01:32:30.380
Was man schon zurückbekommt, ist,

01:32:30.540 --> 01:32:32.440
dass das Command durchgegangen ist.

01:32:33.140 --> 01:32:34.200
Also sozusagen man wartet bis,

01:32:34.200 --> 01:32:36.500
also ein Request kommt rein

01:32:36.500 --> 01:32:38.360
und dann erzeugt

01:32:38.360 --> 01:33:08.340
und

01:33:08.360 --> 01:33:09.680
Events abgearbeitet wurden.

01:33:10.320 --> 01:33:11.640
Wenn das ganze Ding fresh ist, ist es vorbei.

01:33:12.540 --> 01:33:15.060
Dann ist es weg.

01:33:15.240 --> 01:33:16.780
Das heißt, wir haben jetzt nicht irgendwie...

01:33:16.780 --> 01:33:18.760
Okay. Ja gut, aber wenn...

01:33:18.760 --> 01:33:20.500
Wir brauchen

01:33:20.500 --> 01:33:22.320
irgendwas. Also wenn ich mich

01:33:22.320 --> 01:33:24.500
jetzt dafür entscheiden würde, dass es unglaublich wichtig ist,

01:33:24.520 --> 01:33:26.300
weil dieser Prozess vielleicht eine Minute dauert,

01:33:26.360 --> 01:33:28.000
weil der irgendwie verschiedene Stages durchläuft.

01:33:28.400 --> 01:33:30.360
Es gibt Gründe. Keine Ahnung, du hast

01:33:30.360 --> 01:33:32.520
eine unglaublich langsame API irgendwo dranhängen.

01:33:32.880 --> 01:33:34.500
Die braucht einfach ewig lang zum Antworten,

01:33:34.500 --> 01:33:36.380
aber der Nutzer soll nicht so lange auf diese API

01:33:36.380 --> 01:34:06.360
und Jochen unterhalten sich über die Programmiersprache Python

01:34:06.380 --> 01:34:18.620
Also ich weiß nicht, ob man damit wirklich das Problem löst, aber erstmal wird es dann so sein, dass der Prozess weg ist und dass man dort, wenn man diesen Lösungsvorschlag...

01:34:18.620 --> 01:34:22.680
Wenn du es weggeschrieben hast, dann hast du zwar noch nicht die Queue durch, aber du hast ja den Daten, dass der gekommen ist.

01:34:23.120 --> 01:34:27.980
Aber das macht natürlich den Prozess dann minimal langsamer, weil ich erst was in die Datenbank schreiben muss.

01:34:28.000 --> 01:34:28.600
Das dauert nicht lang.

01:34:28.780 --> 01:34:30.220
Ja, aber vielleicht doch zu lang.

01:34:30.480 --> 01:34:31.360
Na, glaube ich nicht.

01:34:31.360 --> 01:34:32.420
Also wenn du irgendwie...

01:34:32.420 --> 01:34:35.960
Ich habe gerade 30 Millionen Nutzer, die da draufschreiben.

01:34:36.380 --> 01:34:39.220
Ja gut, aber das soll ja nicht so lange dauern.

01:34:40.120 --> 01:34:56.420
Aber wie gesagt, ich fühle mich dabei dann so ein bisschen unwohl, dass ich das innerhalb dieses Python-Prozesses habe, weil ich eben sicher gehen muss, dass ich diese Information nicht verliere, wenn ich sie denn nicht verlieren muss. Und da hilft dann natürlich irgendwie so ein Sonderprozess.

01:34:56.420 --> 01:35:02.560
Ich würde ja sagen, man kann das ja auch mal, aber ich meine,

01:35:04.280 --> 01:35:05.720
ja, also

01:35:05.720 --> 01:35:06.580
ja,

01:35:07.740 --> 01:35:12.500
ich würde eher denken, also wie man das dann macht,

01:35:12.620 --> 01:35:15.720
ist letztlich eigentlich, ist ja dann keine Architekturfrage mehr,

01:35:15.720 --> 01:35:18.000
ob man dann auch wieder einen Kafka verwendet oder Rabbit und Q oder

01:35:18.000 --> 01:35:21.940
irgendwas anderes ist ja letztlich, fand ich einfach nur interessant gerade.

01:35:22.480 --> 01:35:22.540
Ja.

01:35:22.660 --> 01:35:25.540
Also, wie gesagt, das war mir jetzt neu.

01:35:25.540 --> 01:35:29.040
Ich meine, da tun sich viele Fragen auf, die mit dem eigentlichen Thema nichts zu tun haben.

01:35:29.280 --> 01:35:30.520
Also wie gehe ich mit Exception um?

01:35:30.860 --> 01:35:35.520
Azure Service Bus hat zum Beispiel einen Exception-Deadletter-Queue.

01:35:36.840 --> 01:35:39.300
Das muss ich mir natürlich relativ umständlich dann da reinbauen.

01:35:40.140 --> 01:35:43.000
Also ich brauche ein vergleichsweise umständlicheres Fehlerhandling,

01:35:43.060 --> 01:35:45.920
wenn ich das dann auch irgendwie über diese Queues abbauen möchte.

01:35:46.500 --> 01:35:47.760
Das kann ich mir natürlich anders ein bisschen leichter machen.

01:35:47.780 --> 01:35:50.340
Du brauchst ja für jeden Microservice eigentlich so ein eigenes Fehlerhandling auch.

01:35:51.060 --> 01:35:51.900
Ja, ein bisschen.

01:35:51.900 --> 01:35:53.660
also wenn du, ja,

01:35:54.080 --> 01:35:54.860
oder ein Standard,

01:35:56.060 --> 01:35:57.380
wie man es dann am Ende sieht.

01:35:57.760 --> 01:35:59.740
Also klar, das bringt einen dann wieder zurück

01:35:59.740 --> 01:36:01.740
zu den Microservices und

01:36:01.740 --> 01:36:03.220
wieder zu einem generellen Problem

01:36:03.220 --> 01:36:05.780
und das Fehlerhandling entscheidet dann der Service

01:36:05.780 --> 01:36:07.400
selbst oder das Team in dem Fall.

01:36:07.880 --> 01:36:09.800
Also ich meine, ja, beim Konsumenten

01:36:09.800 --> 01:36:10.140
meinte ich jetzt,

01:36:10.600 --> 01:36:13.340
wenn du eh die Dependency hast,

01:36:13.460 --> 01:36:15.820
dass du irgendwie einen hast, der das konsumieren will und dann halt Sachen macht,

01:36:16.260 --> 01:36:17.300
gut, das Fehlerhandling brauchst du sowieso,

01:36:17.480 --> 01:36:19.600
je nachdem, was da drinsteckt, aber du hast natürlich

01:36:20.480 --> 01:36:21.540
meiner Meinung nach, wenn du

01:36:21.540 --> 01:36:23.200
Microservices hast du eine größere

01:36:23.200 --> 01:36:25.060
Anzahl an Fehlerquellen.

01:36:25.060 --> 01:36:26.820
Es wird halt viel komplizierter. Du musst dich halt

01:36:26.820 --> 01:36:28.700
über all diese Dinge Gedanken machen im einzelnen Prozess.

01:36:28.860 --> 01:36:30.320
Musst du das nicht. Da ist das alles egal.

01:36:30.600 --> 01:36:32.720
Da machst du halt ganz normales Exception Handling

01:36:32.720 --> 01:36:34.920
und da brauchst du all diese Dinge nicht.

01:36:36.780 --> 01:36:38.680
Was passiert denn mit Retry und gucken?

01:36:38.980 --> 01:36:40.500
Das hast du auch da und lebst du noch.

01:36:41.040 --> 01:36:42.320
War der nur kurz weg? War die Verbindung weg?

01:36:42.440 --> 01:36:42.960
War der Server weg?

01:36:43.740 --> 01:36:45.900
Ja, aber ich meine,

01:36:46.400 --> 01:36:48.560
wenn sich darum jeder Service selbst kümmern muss,

01:36:48.640 --> 01:36:50.720
dann ist es natürlich auch wieder nicht so kompliziert.

01:36:50.720 --> 01:36:53.140
Also wenn ich immer nur auf meinen Punkt gucke

01:36:53.140 --> 01:36:55.080
und ich schaue, welche Möglichkeiten

01:36:55.080 --> 01:36:57.060
gibt es. Also im gesamten Prozess gibt es immer

01:36:57.060 --> 01:36:58.880
mehr Fehlerpunkte. Also du glaubst einfach

01:36:58.880 --> 01:37:00.920
eben, was dann da in deiner Queue steht.

01:37:01.900 --> 01:37:02.480
Ich beispielsweise.

01:37:03.120 --> 01:37:04.680
Ja, das muss natürlich validiert werden.

01:37:04.840 --> 01:37:06.780
Und wenn da was Falsches drinsteht, dann weiß ich, dass irgendwas

01:37:06.780 --> 01:37:08.900
vorher falsch war. Klar, diese Art von

01:37:08.900 --> 01:37:10.080
D-Bagging ist schon super schwer.

01:37:10.660 --> 01:37:12.200
Weißt du, dass da was Falsches drinsteht?

01:37:12.780 --> 01:37:14.900
Also, weiß ich nicht. Wenn wir jetzt

01:37:14.900 --> 01:37:16.900
zum Beispiel, wir erwarten

01:37:16.900 --> 01:37:18.800
jetzt ein bestimmtes

01:37:18.800 --> 01:37:21.000
JSON in deiner

01:37:21.000 --> 01:37:22.880
Queue. Und dieses JSON entspricht

01:37:22.880 --> 01:37:24.800
nicht dem richtigen Format, dann weiß ich, dass da vorher irgendwas

01:37:24.800 --> 01:37:25.280
falsch war.

01:37:25.560 --> 01:37:28.940
Das ist jetzt

01:37:28.940 --> 01:37:30.720
so ein sehr, sehr einfacher Fehler. Es kann natürlich sein,

01:37:30.900 --> 01:37:32.600
dass ein falscher Nutzer

01:37:32.600 --> 01:37:34.740
in deinem Datensatz drin steht und dein Service kann das

01:37:34.740 --> 01:37:36.660
nicht überprüfen. Aber da sind wir dann wieder

01:37:36.660 --> 01:37:38.340
bei der Herausforderung

01:37:38.340 --> 01:37:40.780
des Datenmanagements. Also wie gestalte ich

01:37:40.780 --> 01:37:42.120
das richtig? Wie gestalte ich das gut?

01:37:42.740 --> 01:37:44.720
Wie kann ich solche Sachen vermeiden? Wie synke

01:37:44.720 --> 01:37:46.100
ich vielleicht meine verschiedenen Datenbanken?

01:37:46.420 --> 01:37:48.060
Das ist dann wieder so ein eigenes Problemchen.

01:37:48.060 --> 01:37:49.020
oder großen Problemen.

01:37:49.020 --> 01:37:50.160
Ja, aber das ist wie bei Dependencies.

01:37:50.840 --> 01:37:53.240
Ja, wie sagt man so schön,

01:37:53.320 --> 01:37:54.360
irgendein Tod muss man sterben.

01:37:55.800 --> 01:37:57.220
Das ist halt leider so.

01:37:57.580 --> 01:37:58.560
Aber die Frage ist halt,

01:37:58.800 --> 01:38:00.780
ich glaube, das hat halt so ein Overhead,

01:38:01.480 --> 01:38:02.980
wenn man mit vielen, vielen Microstores arbeitet

01:38:02.980 --> 01:38:04.680
und den muss man irgendwie hinhören können

01:38:04.680 --> 01:38:07.220
und den trade-offen gegen den Overhead

01:38:07.220 --> 01:38:09.140
von, ist das jetzt kompliziert

01:38:09.140 --> 01:38:11.200
oder

01:38:11.200 --> 01:38:12.980
die Sachen weiterzubauen

01:38:12.980 --> 01:38:15.100
in diesem Monolithen, weil halt dann es schwierig

01:38:15.100 --> 01:38:17.100
wird, das zu beherrschen und das ist vielleicht so ein bisschen

01:38:17.100 --> 01:38:19.840
Ja, es ist immer so ein bisschen trickreich.

01:38:20.180 --> 01:38:25.540
Aber vielleicht, ja, ich frage mich immer, ob das jetzt wirklich schlimm ist.

01:38:25.740 --> 01:38:29.400
Klar, als Unternehmen möchte ich natürlich so viel wie möglich wissen,

01:38:29.560 --> 01:38:31.640
aber als einzelner Entwickler, wie ich jetzt einer bin,

01:38:31.720 --> 01:38:32.940
interessiert mich das eigentlich gar nicht so.

01:38:33.220 --> 01:38:35.280
Also es ist mir eigentlich relativ egal,

01:38:35.400 --> 01:38:37.940
ob ich jetzt in einem Monolithen entwickle oder in einem Microservice.

01:38:38.400 --> 01:38:40.820
Das ist auch so das, was meine persönliche Erfahrung ist.

01:38:42.480 --> 01:38:45.280
Ich komme in ein Projekt rein, wo meinetwegen Microservices drin sind

01:38:45.280 --> 01:38:47.220
und dann bin ich damit total fein.

01:38:47.660 --> 01:38:49.500
Dann gucke ich auf meine Sachen, klar, ich habe mehr Abstimmungen

01:38:49.500 --> 01:38:51.240
mit anderen Leuten, aber am Ende

01:38:51.240 --> 01:38:53.160
ist das, das kann ich jetzt,

01:38:53.260 --> 01:38:54.760
ist jetzt auch nur eine gefühlte Sache,

01:38:55.160 --> 01:38:57.220
sozusagen so kompliziert,

01:38:57.340 --> 01:38:58.840
wie wir hier gerade reden,

01:38:59.300 --> 01:39:00.700
ist das in der Realität gar nicht.

01:39:02.660 --> 01:39:03.060
Also

01:39:03.060 --> 01:39:05.240
wenn du jetzt überlegst, ich will jetzt

01:39:05.240 --> 01:39:07.120
zu Microservices rüber migrieren, ich habe einen

01:39:07.120 --> 01:39:09.060
funktionierenden Monolithen, will ich das eigentlich,

01:39:09.180 --> 01:39:09.920
klar, für dich

01:39:09.920 --> 01:39:12.280
ist das super kompliziert,

01:39:12.780 --> 01:39:14.900
aber für mich, der als Neuer,

01:39:15.280 --> 01:39:17.340
vielleicht in ein Projekt reinkommt, noch nicht alles

01:39:17.340 --> 01:39:19.480
kennt, noch nicht weiß, wie es zu diesem Punkt kam,

01:39:20.140 --> 01:39:21.060
ist der Umstand

01:39:21.060 --> 01:39:23.220
Microservice gar nicht mal so das große Thema.

01:39:25.620 --> 01:39:27.180
Und man lernt halt

01:39:27.180 --> 01:39:29.300
wirklich auch viele

01:39:29.300 --> 01:39:31.380
Dinge, weil man sich mit Sachen

01:39:31.380 --> 01:39:33.300
intensiver auseinandersetzen muss, mit denen man sich vorher

01:39:33.300 --> 01:39:35.100
nicht so wirklich intensiv auseinandergesetzt hat,

01:39:35.200 --> 01:39:37.700
wie zum Beispiel Logging, wie zum Beispiel Metric Monitoring,

01:39:38.360 --> 01:39:39.680
wie zum Beispiel...

01:39:39.680 --> 01:39:41.580
Ja, aber das kann auch wieder eine Gefahr sein.

01:39:41.820 --> 01:39:42.920
Ja, okay, komm.

01:39:42.920 --> 01:39:45.860
Technischen Appiel, aber für den Kunden bringt das ja jetzt erstmal nichts.

01:39:46.260 --> 01:39:47.780
Aber gut, ich verstehe schon.

01:39:48.840 --> 01:39:52.840
Das, was ich vielleicht finde, ist, dass wir relativ kompliziert wurden,

01:39:53.400 --> 01:39:54.440
habe ich so das Gefühl.

01:39:54.900 --> 01:39:58.740
Aber der Sachverhalt an sich, der ist gefühlt gar nicht so komplex.

01:39:59.260 --> 01:40:01.780
Und die Probleme, die wir aufgezählt haben, die sind schon da,

01:40:02.180 --> 01:40:03.860
aber die müssen nicht immer ein Problem sein.

01:40:03.860 --> 01:40:06.140
Ich bin da mal ein bisschen neben, was Jochen gesagt hat.

01:40:06.220 --> 01:40:07.500
Die Frage ist, wann braucht man das überhaupt?

01:40:07.680 --> 01:40:10.180
Du brauchst halt wirklich einen Fall, wo du dich auskennst und wirklich weißt,

01:40:10.180 --> 01:40:11.840
Braustest, das kannst du nicht anders lösen,

01:40:12.620 --> 01:40:14.240
bevor du überhaupt die Entscheidung treffen

01:40:14.240 --> 01:40:16.020
würdest, da machen wir jetzt ein Microsoft-Draus, weil ich glaube,

01:40:16.280 --> 01:40:18.180
vorher muss man erstmal andere Sachen

01:40:18.180 --> 01:40:19.820
korrigieren oder so. Ja, also

01:40:19.820 --> 01:40:22.240
ich meine, das klingt

01:40:22.240 --> 01:40:24.000
jetzt alles schrecklich oder klingt jetzt, wenn ich

01:40:24.000 --> 01:40:26.180
ähm, alter Sack.

01:40:27.160 --> 01:40:28.140
Irgendwie, ich habe aber früher,

01:40:28.440 --> 01:40:29.960
wenn Leute sowas gesagt haben, war ich immer so, ja, ja.

01:40:30.400 --> 01:40:32.180
Aber tatsächlich, so Erfahrungen

01:40:32.180 --> 01:40:33.940
zu, also oft ist es irgendwie,

01:40:34.420 --> 01:40:34.900
dass, also ich

01:40:34.900 --> 01:40:38.100
habe das Gefühl, dass das Problem in der

01:40:38.100 --> 01:40:38.940
Praxis oft

01:40:38.940 --> 01:40:42.180
Kompetenz.

01:40:42.600 --> 01:40:44.880
Da weiß ich nicht, ob Leute das irgendwie hinkriegen oder nicht.

01:40:45.060 --> 01:40:46.200
Kann man das essen?

01:40:46.780 --> 01:40:48.820
Und die Sachen

01:40:48.820 --> 01:40:50.420
selber sind gar nicht so kompliziert. Da würde ich

01:40:50.420 --> 01:40:51.180
vollkommen recht geben.

01:40:52.100 --> 01:40:54.440
Ich würde es so ausdrücken,

01:40:54.720 --> 01:40:55.400
es gibt einen

01:40:55.400 --> 01:40:58.280
nicht unerheblichen handwerklichen Teil

01:40:58.280 --> 01:41:00.500
bei dieser ganzen Geschichte und der ist

01:41:00.500 --> 01:41:02.080
gar nicht so gut in theoretischer,

01:41:02.580 --> 01:41:04.500
also sagen wir so, das ist halt nicht so viel,

01:41:04.560 --> 01:41:05.560
da ist gar nicht so viel Theorie.

01:41:06.500 --> 01:41:08.140
Vielleicht die falsche Analogie,

01:41:08.140 --> 01:41:38.120
und Jochen unterhalten sich über die Programmiersprache Python

01:41:38.140 --> 01:41:41.000
Ja, das ist halt

01:41:41.000 --> 01:41:43.200
ein Problem, mit dem Organisationen

01:41:43.200 --> 01:41:44.500
dann auch oft konfrontiert sind

01:41:44.500 --> 01:41:47.020
und das nicht

01:41:47.020 --> 01:41:48.600
so richtig gelöst kriegen. Und dann

01:41:48.600 --> 01:41:50.840
probiert man das halt mit so komplizierten Geschichten irgendwie.

01:41:51.320 --> 01:41:52.780
Also ja, okay, aber

01:41:52.780 --> 01:41:54.880
eigentlich... Und das Dumme ist, da gibt es

01:41:54.880 --> 01:41:56.120
halt auch keinen einfachen Weg raus.

01:41:56.320 --> 01:41:58.940
Die Lösung dafür ist halt,

01:41:59.040 --> 01:42:00.920
weiß ich nicht, Leute schulen oder

01:42:00.920 --> 01:42:02.900
abwarten, bis sie so gut geworden sind, dass das dann

01:42:02.900 --> 01:42:04.880
funktioniert oder so viele Sachen kaputt gegangen

01:42:04.880 --> 01:42:06.820
sind, dass sie dann irgendwann gemerkt haben, wie es richtig funktioniert.

01:42:06.820 --> 01:42:08.980
und das ist halt dann vielleicht so ein Zeithorizont

01:42:08.980 --> 01:42:10.080
mehrere Jahre oder so.

01:42:10.780 --> 01:42:13.080
Und dann ist noch nicht mal sichergestellt,

01:42:13.160 --> 01:42:14.360
dass es dann hinterher wirklich funktioniert.

01:42:15.080 --> 01:42:16.940
Sondern da kann man nur die Hoffnung drauf haben,

01:42:17.020 --> 01:42:18.540
dass es dann vielleicht funktioniert. Das ist ja

01:42:18.540 --> 01:42:20.900
ganz schrecklich. Wenn ich jetzt ein Projekt habe,

01:42:21.020 --> 01:42:23.020
wo meine Karriere dann hängt, ob das jetzt gut wird oder

01:42:23.020 --> 01:42:24.840
nicht, das kann mir ja niemandem erzählen.

01:42:25.340 --> 01:42:27.160
Und dann versuchen wir halt

01:42:27.160 --> 01:42:28.880
irgendwie andere Sachen um das. Aber das ist halt

01:42:28.880 --> 01:42:30.300
alles nur...

01:42:30.300 --> 01:42:32.940
Ohne mal zu der Barth-Analogie zurückzukommen, dann hast du

01:42:32.940 --> 01:42:34.980
halt entweder eine Mosaikwand oder

01:42:34.980 --> 01:42:36.600
du klebst halt alles mit einem Kleber drüber,

01:42:36.600 --> 01:42:40.500
und dann hast du eine glatte Wand, das ist auch, glaube ich, modisch gerade.

01:42:41.140 --> 01:42:42.300
Ich glaube, das ist nicht so schlimm.

01:42:44.180 --> 01:42:45.100
Ja, ich weiß nicht.

01:42:45.340 --> 01:42:46.940
Wichtig ist, was kannst du in dem Bad machen?

01:42:47.040 --> 01:42:48.460
Kannst du da dich duschen zum Beispiel?

01:42:49.040 --> 01:42:51.900
Ja, ja, aber ich glaube, das ist halt tatsächlich gar nicht so einfach,

01:42:52.020 --> 01:42:53.620
das hinzukriegen, dass es wirklich gut funktioniert.

01:42:53.760 --> 01:42:55.400
Das ist halt irgendwie schwierig.

01:42:56.600 --> 01:42:57.100
Ja, okay.

01:42:57.640 --> 01:42:59.780
Die Handwerksgrund ist natürlich schon sehr wichtig.

01:42:59.800 --> 01:43:01.500
Ja, oder ich weiß nicht, vielleicht ist das auch ein blödes Beispiel,

01:43:01.620 --> 01:43:03.960
oder Musikinstrument spielen ist vielleicht auch theoretisch gar nicht so,

01:43:04.460 --> 01:43:05.600
Gitarre gibt nicht so viele Seiten,

01:43:05.600 --> 01:43:07.400
aber trotzdem irgendwie muss man lange üben

01:43:07.400 --> 01:43:09.400
bevor das irgendwie funktioniert und manche

01:43:09.400 --> 01:43:11.640
Bereiche, vielleicht nicht alle, aber manche Bereiche beim Programmieren

01:43:11.640 --> 01:43:14.100
sind halt auch so, sozusagen dieser Modellisierungsbereich

01:43:14.100 --> 01:43:14.800
da habe ich das Gefühl

01:43:14.800 --> 01:43:17.680
Es gibt schon die kleinen Kinderkunden, die relativ viel

01:43:17.680 --> 01:43:18.520
Kraft machen und nennen das so

01:43:18.520 --> 01:43:22.720
Naja

01:43:22.720 --> 01:43:24.280
Okay

01:43:24.280 --> 01:43:27.380
Haben wir eine Quintessenz gefunden damit?

01:43:28.040 --> 01:43:29.060
Es kommt drauf an

01:43:29.060 --> 01:43:31.340
Genau, das gibt es auch

01:43:31.340 --> 01:43:32.300
hat jemand schön

01:43:32.300 --> 01:43:35.080
die Lösung aller IT-Probleme

01:43:35.080 --> 01:43:37.220
irgendwie so ein O'Reilly-Buch, wo drauf steht

01:43:37.220 --> 01:43:37.800
It Depends.

01:43:38.880 --> 01:43:39.320
Absolut.

01:43:42.380 --> 01:43:43.180
Ich bleibe

01:43:43.180 --> 01:43:44.780
dabei, es ist prinzipiell cool erstmal.

01:43:45.220 --> 01:43:46.980
Das muss man halt sagen. Es klingt

01:43:46.980 --> 01:43:49.040
natürlich cooler, auch wenn das natürlich

01:43:49.040 --> 01:43:50.700
niemals ein Entscheidungspunkt sein sollte

01:43:50.700 --> 01:43:52.620
und auch sehr, sehr subjektiv ist.

01:43:53.080 --> 01:43:55.000
Aber ich glaube, am Ende kommt es immer einfach drauf an,

01:43:55.080 --> 01:43:56.900
ob man es haben will, ob man es braucht.

01:43:59.100 --> 01:44:00.900
Da haben wir wieder, es ist ein gutes Sales-Argument.

01:44:01.020 --> 01:44:03.140
Wir machen Microservices, das ist wunderbar.

01:44:03.140 --> 01:44:04.080
Das klingt erstmal immer gut.

01:44:05.080 --> 01:44:06.300
Das ist auf jeden Fall ein gutes Argument,

01:44:06.380 --> 01:44:07.240
wenn man Geld für mich verdienen kann.

01:44:09.980 --> 01:44:11.420
Rein technisch natürlich immer schwer.

01:44:11.760 --> 01:44:12.860
Da sind wir wieder bei den Dingen,

01:44:13.060 --> 01:44:14.840
wo die Infra sagt, da bewegen wir uns gar nicht,

01:44:15.180 --> 01:44:15.820
sagt dann halt,

01:44:16.120 --> 01:44:18.780
wir müssen nichts neu durchsortieren,

01:44:19.020 --> 01:44:20.600
wie der ein bisschen Sales und Marketing machen kann.

01:44:21.200 --> 01:44:22.280
Ja, aber das ist halt so ein bisschen,

01:44:22.360 --> 01:44:23.720
das ist halt auch das gleiche Problem wie,

01:44:24.100 --> 01:44:26.280
ich versuche immer das noch auf den Punkt zu kriegen,

01:44:26.360 --> 01:44:27.500
ich kriege es nicht so richtig gut formuliert,

01:44:27.880 --> 01:44:30.900
das ist halt so Probleme, die schwer lösbar sind,

01:44:31.120 --> 01:44:32.920
die produzieren im Grunde irgendwie

01:44:32.920 --> 01:44:33.940
so Scheinlösungen.

01:44:35.080 --> 01:44:37.860
Gesundheit ist schwierig

01:44:37.860 --> 01:44:40.580
wenn man eine schwere Krankheit

01:44:40.580 --> 01:44:42.260
bekommt oder so, dann hat man ein Problem, das sehr schwer

01:44:42.260 --> 01:44:43.340
lösbar ist, wo man nicht viel machen kann

01:44:43.340 --> 01:44:45.760
das produziert halt den ganzen Markt von

01:44:45.760 --> 01:44:48.300
Pseudo-Snack-Oil, weiß ich nicht

01:44:48.300 --> 01:44:48.920
Quacksalbern

01:44:48.920 --> 01:44:51.820
Computersicherheit, schwieriges Problem

01:44:51.820 --> 01:44:53.760
auch da

01:44:53.760 --> 01:44:55.580
entsteht so eine Branche von

01:44:55.580 --> 01:44:58.040
etwas halbwegs

01:44:58.040 --> 01:44:59.520
zielrichtigen, weiß ich nicht genau

01:44:59.520 --> 01:45:01.240
manche sind gut, manche sind nicht so gut

01:45:01.240 --> 01:45:07.600
Also habe ich schon gesagt, dass du ja durch eine Firma betreibende Organenergie auf Telefon anrufen kannst und ich schicke dir dann positive Energie durch das Universum zurück.

01:45:08.900 --> 01:45:13.740
Ja, also jetzt musst du nur noch das entsprechende Problem suchen, was die Leute gerne gelöst haben.

01:45:14.000 --> 01:45:17.160
Ja, Stundenbesatz aufzählen oder halt so eine 0109-Hängernummer oder sowas.

01:45:18.100 --> 01:45:18.260
Ja.

01:45:20.340 --> 01:45:21.620
Wir schweifen schon wieder ab.

01:45:22.840 --> 01:45:30.600
Ja, und da muss man halt, ich meine, ja, und es gibt dann halt so Dinge, die sind so, ja, vielleicht schon sinnvoll, aber man kann sie halt auch so benutzen.

01:45:30.600 --> 01:45:33.020
das ist halt wie, weiß ich nicht, gibt es die ganzen

01:45:33.020 --> 01:45:35.400
Big Data Blockchain, weiß ich nicht

01:45:35.400 --> 01:45:37.300
und Microservices ist halt auch irgendwie

01:45:37.300 --> 01:45:39.120
so ein bisschen, irgendwie zumindest

01:45:39.120 --> 01:45:41.100
irgendwie man hatte so das Gefühl, das wird immer so

01:45:41.100 --> 01:45:43.260
als Lösung verkauft für Sachen, die schwer sind

01:45:43.260 --> 01:45:44.700
ja

01:45:44.700 --> 01:45:46.980
aber ich will gar nicht sagen, dass das jetzt

01:45:46.980 --> 01:45:48.720
irgendwie Unsinn wäre oder so, sondern

01:45:48.720 --> 01:45:50.620
nee, es gibt da schon durchaus

01:45:50.620 --> 01:45:52.340
und das ist auch vielleicht eine gute Idee

01:45:52.340 --> 01:45:55.020
Sie machen nicht immer alles leichter

01:45:55.020 --> 01:45:56.520
Sie machen manchmal auch Sachen schwerer

01:45:56.520 --> 01:45:58.980
aber Sie machen dabei andere Sachen leichter, aber nicht alles

01:45:58.980 --> 01:45:59.260
alles.

01:46:01.000 --> 01:46:02.860
Man hat einfach wirklich diesen,

01:46:03.120 --> 01:46:04.940
also das ist, ich glaube, das ist auch immer

01:46:04.940 --> 01:46:06.760
ganz wichtig zu sagen dabei, man hat halt

01:46:06.760 --> 01:46:08.820
wirklich einen Trade-off und der ist nicht ohne, der ist

01:46:08.820 --> 01:46:10.820
niemals ohne. Ja, vielleicht wollte mal jemand fragen, der sich damit

01:46:10.820 --> 01:46:12.760
auskennt, bevor man

01:46:12.760 --> 01:46:13.780
zum Beispiel mehr Änderungen macht.

01:46:16.180 --> 01:46:16.960
Genau, ja.

01:46:18.140 --> 01:46:19.040
Ja, keine Ahnung.

01:46:19.640 --> 01:46:20.960
Wir hätten, also ich hätte auch noch

01:46:20.960 --> 01:46:22.560
Pics, also wir können auch noch, ich weiß nicht genau,

01:46:22.640 --> 01:46:24.420
wie es aussieht, wollen wir noch irgendwie,

01:46:25.180 --> 01:46:26.740
gibt es noch irgendwie Themen oder haben wir schon

01:46:26.740 --> 01:46:28.880
alles gesagt, was wir sagen? Haben wir alles gesagt von Microservices?

01:46:28.980 --> 01:46:30.160
Fällt euch noch was ein?

01:46:30.160 --> 01:46:30.580
Bestimmt nicht

01:46:30.580 --> 01:46:35.060
Ich habe noch eine andere Frage, aber das hat nichts mit dem Pix zu tun

01:46:35.060 --> 01:46:35.680
aber ist an Jochen

01:46:35.680 --> 01:46:38.680
Aber haben wir noch irgendwas zu Microservices?

01:46:39.000 --> 01:46:41.060
Sonst würden wir das Thema einfach zumachen

01:46:41.060 --> 01:46:42.160
No, machen wir es so

01:46:42.160 --> 01:46:45.060
Du hast irgendwas mit File-Benchmarks gemacht, Jochen, was waren das?

01:46:46.060 --> 01:46:46.740
Ah, okay

01:46:46.740 --> 01:46:49.240
Ja, also das ist etwas

01:46:49.240 --> 01:46:51.060
das mich ja auch

01:46:51.060 --> 01:46:52.420
eine ganze Zeit lang umtreibt

01:46:52.420 --> 01:46:54.260
Sollen wir das beim nächsten Mal sonst erzählen?

01:46:54.400 --> 01:46:55.780
Nö, wir können das gerne

01:46:55.780 --> 01:46:58.440
kurz darauf eingehen

01:46:58.440 --> 01:47:00.320
Ja, also

01:47:00.320 --> 01:47:03.020
die Frage, die mich beschäftigt hat, ist

01:47:03.020 --> 01:47:05.900
weil ich würde ja gerne

01:47:05.900 --> 01:47:06.340
ins

01:47:06.340 --> 01:47:08.880
Hosting-Geschäft einsteigen

01:47:08.880 --> 01:47:10.320
Ja, ganz sicher

01:47:10.320 --> 01:47:12.440
Ja, genau

01:47:12.440 --> 01:47:14.880
und eine Frage, die mich dann beschäftigt hat

01:47:14.880 --> 01:47:16.580
also gerade Podcast-Hosting, ich meine, wir betreiben

01:47:16.580 --> 01:47:19.040
unsere eigene Podcast-Hosting

01:47:19.040 --> 01:47:20.400
tatsächlich und

01:47:20.400 --> 01:47:22.620
da sind etwas spezielle Anforderungen

01:47:22.620 --> 01:47:23.500
die Files sind groß

01:47:23.500 --> 01:47:25.420
Ja, Files dürfen schnell Files dürfen

01:47:25.420 --> 01:47:28.120
und genau, und die Frage ist jetzt, okay, wir können...

01:47:28.120 --> 01:47:31.440
Mit Python oder nicht? Ja, mich ärgert, dass wir da so eine Abhängigkeit haben, wir machen das über

01:47:31.440 --> 01:47:34.220
ein CDN, über CloudFront und

01:47:34.220 --> 01:47:36.120
das ist auch teuer irgendwie.

01:47:38.000 --> 01:47:39.660
Erstaunlich teuer. Und

01:47:39.660 --> 01:47:43.240
die Frage wäre, kann man das nicht selber machen, weil wenn man irgendwie... Ich miete ja sowieso

01:47:43.240 --> 01:47:45.720
Server, auf denen ich den Hum deploye und da ist der Traffic

01:47:45.720 --> 01:47:49.240
frei, warum kann man dann nicht die Server auch mit

01:47:49.240 --> 01:47:52.120
ausliefern, mit Minio oder sowas. Ja, oder einfach

01:47:52.120 --> 01:47:55.140
im einfachsten Fall ein statischer Web-Server, das geht natürlich, das Problem

01:47:55.140 --> 01:47:55.900
dabei ist halt,

01:47:57.120 --> 01:47:58.800
naja, also solche Dinge wie

01:47:58.800 --> 01:48:00.820
Authentifizierung und so ist halt schwierig.

01:48:01.180 --> 01:48:03.180
Wie ist das denn halt? Also ich meine, das ist natürlich

01:48:03.180 --> 01:48:04.900
viele würden sagen,

01:48:04.960 --> 01:48:06.880
das ist doch egal, wenn da jemand

01:48:06.880 --> 01:48:08.940
deine, also hier geht es um den Fall

01:48:08.940 --> 01:48:10.880
zum Beispiel, man editiert halt irgendwie

01:48:10.880 --> 01:48:12.680
eine neue Podcast-Episode zum Beispiel

01:48:12.680 --> 01:48:14.960
und dann sollte das ja, sollte zum Beispiel

01:48:14.960 --> 01:48:16.780
die Audio-Inhalte nicht für jeden sofort

01:48:16.780 --> 01:48:19.100
verfügbar sein, sondern erst, wenn das frei veröffentlicht

01:48:19.100 --> 01:48:20.940
ist, ja, sozusagen. Also nur wenn man

01:48:20.940 --> 01:48:22.620
authentifiziert ist. Wie macht man das denn?

01:48:22.920 --> 01:48:24.940
Das geht ja quasi gar nicht, wenn ich

01:48:24.940 --> 01:48:26.980
auf dem statischen Files-Server hätte, dann sobald die Files

01:48:26.980 --> 01:48:27.560
verfügbar sind.

01:48:28.140 --> 01:48:29.780
Von dem Link dann, ja.

01:48:31.380 --> 01:48:33.040
Ist jetzt ein Detailproblem eigentlich,

01:48:33.240 --> 01:48:35.000
aber mir geht's, also wie wäre das denn,

01:48:35.080 --> 01:48:36.980
wenn ich das für andere machen wollen

01:48:36.980 --> 01:48:38.680
würde? Die haben ja eventuell auch noch

01:48:38.680 --> 01:48:40.960
irgendwie so Anwendungsfälle, wo

01:48:40.960 --> 01:48:43.040
sie Sachen vielleicht nur nicht öffentlich

01:48:43.040 --> 01:48:45.100
veröffentlichen wollen, also eine ausgewählte

01:48:45.100 --> 01:48:45.560
Gruppe von Leuten.

01:48:46.900 --> 01:48:48.420
Also wie soll denn Authentifizierung funktionieren?

01:48:48.540 --> 01:48:50.240
Dann gibt's dann halt diese ganzen Geschichten mit,

01:48:50.400 --> 01:48:51.680
man schickt halt

01:48:51.680 --> 01:48:54.620
sozusagen ein Request an den

01:48:54.620 --> 01:49:04.000
Fileserver, und da ist halt irgendwie ein Cookie gesetzt oder halt ein Token oder da ist irgendwas in der URL, was signiert ist, und dann der fragt nochmal einen anderen Service und guckt halt nach, ist der jetzt authentifiziert?

01:49:04.120 --> 01:49:04.620
Fragt der Microservice?

01:49:05.180 --> 01:49:05.280
Bitte?

01:49:05.500 --> 01:49:06.160
Fragt der Microservice?

01:49:06.580 --> 01:49:23.940
Ja, genau, da hat man dann auch schon so eine Art Microservice oder man schickt halt den Request zum Applikationsserver, der Applikationsserver schickt aber nicht die File-Response zurück, sondern er schickt nur eine Response zurück, wo ein Header gesetzt ist, in dem drin steht, ja, dieses File darf ausgeliefert werden, und dann der Reverse-Proxy vorne dran tauscht dann halt diese Response, die echte File-Response aus.

01:49:23.940 --> 01:49:25.700
Engine X macht? Ja, genau.

01:49:25.860 --> 01:49:27.280
Das gibt's, wie heißt das?

01:49:27.980 --> 01:49:28.860
X-Send-File?

01:49:29.760 --> 01:49:30.740
Irgendwie so. Ja, genau.

01:49:32.820 --> 01:49:33.760
Also das gibt's alles

01:49:33.760 --> 01:49:35.900
sehr hässlich und funktioniert auch alles nicht so

01:49:35.900 --> 01:49:37.940
richtig gut. Und deswegen wäre es auch viel schöner,

01:49:38.000 --> 01:49:39.780
wenn man das direkt über einen Applikationsserver ausliefern würde.

01:49:39.960 --> 01:49:41.780
Und ich dachte eigentlich, geht doch. Django Static

01:49:41.780 --> 01:49:43.700
Files quasi. Ja,

01:49:44.060 --> 01:49:45.300
das gibt's schon. Also wenn

01:49:45.300 --> 01:49:47.940
die Assets gemeint sind, also sowas wie

01:49:47.940 --> 01:49:49.420
CSS und JavaScript und so,

01:49:49.560 --> 01:49:50.640
da gibt's schon was für.

01:49:50.860 --> 01:49:53.380
Nicht die Assets, sondern wirklich dann halt mit

01:49:53.380 --> 01:49:54.880
Einzel-Single-Permission und

01:49:54.880 --> 01:49:56.820
File-Off-Check-Level. Genau, da gibt es nichts.

01:49:57.200 --> 01:49:58.980
Und das wäre aber interessant. Und eigentlich

01:49:58.980 --> 01:50:01.080
dachte ich irgendwie, das müsste mit Python auch gehen.

01:50:01.160 --> 01:50:02.960
Python-Icing-AO, da gibt es ja auch alles irgendwie.

01:50:03.940 --> 01:50:04.160
Und

01:50:04.160 --> 01:50:06.920
UV-Loop

01:50:06.920 --> 01:50:09.120
ist ja auch sehr schnell und so.

01:50:10.360 --> 01:50:11.260
Und das müsste man doch eigentlich

01:50:11.260 --> 01:50:12.440
machen können und es geht auch.

01:50:13.040 --> 01:50:14.700
Dein Benchmark hat festgestellt, Keddy ist viel schneller.

01:50:15.600 --> 01:50:16.880
Ja, genau.

01:50:17.180 --> 01:50:18.880
Dann habe ich irgendwie jetzt ein anderes,

01:50:18.880 --> 01:50:20.600
weil ich mich interessiere für Kochen und so.

01:50:20.740 --> 01:50:22.260
Dann gibt es so einen Rezeptmanager, Mili.

01:50:22.260 --> 01:50:25.100
kann man sich auch mal angucken, ist ja nett.

01:50:25.300 --> 01:50:27.020
Und das habe ich dann irgendwie auf meiner Infrastruktur deployed

01:50:27.020 --> 01:50:28.300
und da gibt es auch viele Bilder und so.

01:50:28.520 --> 01:50:30.680
Und dann dachte ich, ah, das mache ich bei Ubicorn, weil

01:50:30.680 --> 01:50:32.740
wozu haben die dann noch extra

01:50:32.740 --> 01:50:33.580
einen Caddy laufen?

01:50:34.500 --> 01:50:36.760
Und dann habe ich dann auch in ihrem Discord Bescheid gesagt,

01:50:37.040 --> 01:50:38.920
so, ja, warum macht ihr denn

01:50:38.920 --> 01:50:40.640
da nochmal ein Caddy zusätzlich?

01:50:40.780 --> 01:50:42.560
Das ist doch Quatsch, ihr macht das doch einfach über den Ubicorn.

01:50:43.020 --> 01:50:44.580
Und dann hieß es, ja, aber wir haben die Erfahrung gemacht,

01:50:44.620 --> 01:50:46.800
das ist dann irgendwie schneller und irgendwie sonst ist es langsam.

01:50:47.220 --> 01:50:48.320
Der so, das kann gar nicht sein.

01:50:48.560 --> 01:50:49.520
Dann muss ich mal einen Matchmark machen.

01:50:49.520 --> 01:50:51.480
Ich hab ein Benchmark gemacht und gesehen,

01:50:52.400 --> 01:50:54.440
stimmt doch, sie haben recht, ich liege falsch.

01:50:57.720 --> 01:50:58.600
Auf jeden Fall

01:50:58.600 --> 01:51:00.060
tatsächlich Nginx Caddy

01:51:00.060 --> 01:51:01.160
viel schneller als

01:51:01.160 --> 01:51:03.660
Ubicorn, beziehungsweise die

01:51:03.660 --> 01:51:04.780
Fallresponsion von Starlet,

01:51:05.680 --> 01:51:07.260
was halt unter FastAPI unterliegt.

01:51:08.020 --> 01:51:09.740
Und das ist halt FastAPI Backend.

01:51:10.920 --> 01:51:11.900
Ja, keine Ahnung, wo ans liegt,

01:51:11.960 --> 01:51:13.720
ich weiß es nicht. Also sagen wir so, es ist immer noch schnell genug

01:51:13.720 --> 01:51:16.000
für Gigabit Ethernet

01:51:16.000 --> 01:51:18.100
Interface, aber wenn es

01:51:18.100 --> 01:51:19.880
also 10 Gigabit schafft man damit nicht.

01:51:20.760 --> 01:51:22.000
Und Caddy und

01:51:22.000 --> 01:51:23.800
Nginx schaffen das schon. Also

01:51:23.800 --> 01:51:26.180
irgendwas ist da nicht richtig. Ich weiß aber nicht was.

01:51:26.560 --> 01:51:27.960
Kommen wir wieder zu UV-Con macht das

01:51:27.960 --> 01:51:29.780
ganze Jahr oder UV-Loop ist halt Zeiten

01:51:29.780 --> 01:51:31.800
vor allen Dingen und denken wir, das kompiliert ja nach 10,

01:51:31.900 --> 01:51:34.060
das muss doch eigentlich schnell sein. Keine Ahnung.

01:51:34.180 --> 01:51:35.780
Also eine mögliche

01:51:35.780 --> 01:51:37.880
Grundführung, warum das

01:51:37.880 --> 01:51:39.360
so ist, den ich

01:51:39.360 --> 01:51:41.300
denke, das könnte es sein, ist

01:51:41.300 --> 01:51:43.000
es liegt daran, dass

01:51:43.000 --> 01:51:45.820
irgendwie Caddy und Nginx

01:51:45.820 --> 01:51:47.740
irgendeine Art von Serial-Copy-TCP verwenden.

01:51:48.100 --> 01:51:50.360
wo halt nicht nochmal durch den User-Space kopiert werden muss

01:51:50.360 --> 01:51:52.280
die Daten und das macht

01:51:52.280 --> 01:51:54.080
Ubiquon halt nicht, sondern

01:51:54.080 --> 01:51:56.140
weil das kann es halt noch nicht, also es gibt

01:51:56.140 --> 01:51:57.340
ein Pull-Request, ist aber noch nicht durch

01:51:57.340 --> 01:52:00.120
das heißt, da wird immer alles nochmal kopiert

01:52:00.120 --> 01:52:01.840
also es wird vom Filesystem, vom Hauptspeicher

01:52:01.840 --> 01:52:03.400
von der Anwendung kopiert und dann nochmal

01:52:03.400 --> 01:52:06.100
in den Netzwerkspeicher und dann erst raus

01:52:06.100 --> 01:52:08.200
das ist natürlich viel ineffizienter

01:52:08.200 --> 01:52:09.840
als wenn man es halt, als wenn der Colonel direkt

01:52:09.840 --> 01:52:11.900
mal mal den Pull-Request kann, mal mal cherrypicken

01:52:11.900 --> 01:52:13.000
mal gucken, ob dann...

01:52:13.000 --> 01:52:15.840
Also das könnte noch ein Unterschied sein

01:52:15.840 --> 01:52:17.620
das wäre dann halt ein relativ langweiliger Grund

01:52:17.620 --> 01:52:18.620
und dann muss man sagen, ja gut,

01:52:19.240 --> 01:52:21.900
und das wäre halt so, ich weiß nicht, ob das dann mit Minio auch einfach so geht,

01:52:22.020 --> 01:52:23.440
wenn man die Files nicht im Filesystem liegen hat,

01:52:23.480 --> 01:52:25.540
sondern halt irgendwo anders, was man ja vielleicht will

01:52:25.540 --> 01:52:27.520
heutzutage, dann geht es vielleicht

01:52:27.520 --> 01:52:29.600
alles nicht mehr, aber dann ging es

01:52:29.600 --> 01:52:30.800
auch mit Nginx und so nicht mehr,

01:52:31.000 --> 01:52:32.100
auch mit Kelly nicht,

01:52:32.280 --> 01:52:35.720
weil die könnte man nicht sein File einfach verwenden,

01:52:35.820 --> 01:52:37.220
das geht halt nicht, das geht halt nur, wenn es

01:52:37.220 --> 01:52:38.780
tatsächlich ein File im Filesystem ist, glaube ich.

01:52:39.520 --> 01:52:41.420
Auch da wäre interessant, wenn sich das jemand,

01:52:41.700 --> 01:52:43.520
wenn jemand mir damit Bescheid sagen könnte, der sich damit auskennt,

01:52:43.580 --> 01:52:44.280
ob das so ist oder nicht.

01:52:44.280 --> 01:52:45.420
Hallo, Herr Paisenbocker.

01:52:46.160 --> 01:52:46.600
Genau.

01:52:47.620 --> 01:52:49.920
Ja, genau.

01:52:50.060 --> 01:52:52.060
Damit habe ich mich so ein bisschen beschäftigt.

01:52:52.340 --> 01:52:52.880
Und ja,

01:52:53.500 --> 01:52:55.460
auf jeden Fall scheint es so zu sein, dass

01:52:55.460 --> 01:52:57.900
Caddy viel effizienter ist als

01:52:57.900 --> 01:52:59.860
Ubiquon oder Ubiloop

01:52:59.860 --> 01:53:01.500
beim serbischen Pals.

01:53:01.720 --> 01:53:03.140
Und ich weiß nicht warum. Keine Ahnung.

01:53:03.660 --> 01:53:06.120
Aber es war interessant. Mal gucken, ob ich das irgendwie rauskriege.

01:53:06.240 --> 01:53:07.860
Ja, das werden wir euch

01:53:07.860 --> 01:53:09.720
weiter informieren irgendwann am Ende von irgendeiner weiteren

01:53:09.720 --> 01:53:11.780
Zukunftsfolge. Also hört alle unsere Folgen mal bis ganz

01:53:11.780 --> 01:53:13.880
zum Ende durch. Selbst wenn es langweilig wird.

01:53:14.020 --> 01:53:14.720
Nicht schlafen.

01:53:16.800 --> 01:53:16.960
Ja.

01:53:17.620 --> 01:53:19.040
Dann pickt ihr Woche, Jochen.

01:53:20.560 --> 01:53:22.640
Genau, picken würde ich

01:53:22.640 --> 01:53:23.940
diesmal tatsächlich

01:53:23.940 --> 01:53:26.440
Wo habe ich das gesehen?

01:53:26.520 --> 01:53:28.320
Ich weiß gar nicht mehr genau. Das Ding nennt sich

01:53:28.320 --> 01:53:32.180
bpytop

01:53:32.180 --> 01:53:35.000
Ah, da.

01:53:35.100 --> 01:53:35.620
Ich habe es hier laufen.

01:53:36.360 --> 01:53:37.900
Oh, das ist hübsch. Das ist ziemlich hübsch, ne?

01:53:38.280 --> 01:53:40.880
Ich weiß nicht, ob das Textual verwendet oder Rich oder irgendwas in der Richtung.

01:53:41.300 --> 01:53:42.580
Aber genau.

01:53:42.580 --> 01:53:43.220
Was ist das oder so?

01:53:43.820 --> 01:53:45.820
Ja, das gibt einem so ein bisschen

01:53:45.820 --> 01:53:47.980
Daten zu den, also

01:53:47.980 --> 01:53:48.700
es ist halt top.

01:53:49.220 --> 01:53:49.500
Ja.

01:53:51.920 --> 01:53:54.200
Es gibt da so ähnliche Sachen.

01:53:54.280 --> 01:53:55.320
Glances gibt es auch.

01:53:55.320 --> 01:53:56.240
Ja, Glances gibt es auch.

01:53:57.100 --> 01:53:57.980
Gtop, Htop.

01:54:00.000 --> 01:54:01.440
Aber das ist mir so letztens

01:54:01.440 --> 01:54:03.120
über den Weg gelaufen und fand ich, sieht echt

01:54:03.120 --> 01:54:03.760
ziemlich gut aus.

01:54:05.020 --> 01:54:06.960
Ist jetzt hier langweilig, der Rechner macht überhaupt nichts.

01:54:07.300 --> 01:54:08.460
Ja, das hat keine Last drauf.

01:54:09.640 --> 01:54:11.120
Ich picke iJSON.

01:54:11.820 --> 01:54:12.820
Habe ich auch noch nicht so viel

01:54:12.820 --> 01:54:14.580
benutzt, aber es macht so große

01:54:14.580 --> 01:54:16.900
JSON-Objekte irgendwie vernünftig.

01:54:19.480 --> 01:54:20.740
Hast du noch einen Pick, Hannes?

01:54:22.380 --> 01:54:23.640
Was genau soll ich denn picken?

01:54:23.740 --> 01:54:25.080
Muss das einen Python-Kontext haben?

01:54:25.600 --> 01:54:27.820
Nö, irgendwas Cooles,

01:54:27.940 --> 01:54:29.540
was man vielleicht noch nicht kennt.

01:54:30.660 --> 01:54:31.240
Ah, okay.

01:54:31.420 --> 01:54:33.040
Ich weiß nicht, ob man es heute gehört hat.

01:54:33.200 --> 01:54:35.200
Ich habe so eine gewisse Präferenz zu Kafka.

01:54:36.180 --> 01:54:37.420
Das, was ich da picken würde,

01:54:37.760 --> 01:54:39.780
ist Kafka Connect

01:54:39.780 --> 01:54:40.840
tatsächlich.

01:54:42.300 --> 01:54:43.440
Kann man mal nachgoogeln.

01:54:43.440 --> 01:54:45.520
das sorgt letztlich

01:54:45.520 --> 01:54:47.280
dafür, dass man sich Sachen

01:54:47.280 --> 01:54:49.280
automatisch aus Datenbanken holen kann

01:54:49.280 --> 01:54:50.700
wenn sie reingeschrieben wurden

01:54:50.700 --> 01:54:53.380
zum Beispiel Write-Only-Prozesse und die werden

01:54:53.380 --> 01:54:55.540
dann ganz ganz automatisch in einen Topic

01:54:55.540 --> 01:54:57.340
reingeschoben, das nennt sich dann

01:54:57.340 --> 01:54:59.400
Source-Connector ohne Code

01:54:59.400 --> 01:55:01.140
Also quasi so eine Duplikation von der

01:55:01.140 --> 01:55:02.840
Realität in der Datenbank in das Kafka

01:55:02.840 --> 01:55:05.360
Ja, wir haben ja über Datenkonsistenzen

01:55:05.360 --> 01:55:07.520
heute geredet und im Prinzip ist das

01:55:07.520 --> 01:55:09.160
so ein Ansatz, wie du dir die Daten

01:55:09.160 --> 01:55:11.600
quasi aus einer Datenbank ohne den

01:55:11.600 --> 01:55:13.280
Service selbst da

01:55:13.280 --> 01:55:15.220
beeinflussen zu müssen, rausziehen kannst,

01:55:15.260 --> 01:55:16.980
in ein Topic schreiben kannst und über einen

01:55:16.980 --> 01:55:19.480
Sync-Connector in andere Datenbanken reinschreiben kannst.

01:55:19.540 --> 01:55:21.020
Und das wirklich coole an der Sache ist,

01:55:21.040 --> 01:55:23.180
es gibt Konnektoren für alle möglichen Datenbanken.

01:55:23.540 --> 01:55:24.120
Also Postgres,

01:55:26.040 --> 01:55:26.880
Elasticsearch,

01:55:27.160 --> 01:55:29.060
Neo4j, das ist relativ interessant.

01:55:29.220 --> 01:55:29.940
Kann man sich mal angucken.

01:55:30.620 --> 01:55:33.140
Ja, das klingt gut. Also Next Level Kafka.

01:55:34.060 --> 01:55:34.440
Mindestens.

01:55:34.440 --> 01:55:34.940
Mindestens, ja.

01:55:36.580 --> 01:55:37.420
Okay, cool.

01:55:38.180 --> 01:55:39.600
Ja, vielen Dank, Janis, dass du hier warst heute.

01:55:39.940 --> 01:55:40.480
Sehr gerne.

01:55:40.480 --> 01:55:44.220
Microservices. Ich hoffe, es hat dir ein bisschen Spaß gemacht, genauso viel wie uns.

01:55:45.560 --> 01:55:46.420
Bleibt uns gewogen.

01:55:47.080 --> 01:55:47.780
Schaltet uns wieder ein.

01:55:48.560 --> 01:55:49.940
Wie auch immer. Montag, Tag.

01:55:50.240 --> 01:55:53.160
Dann bis demnächst.

01:55:53.640 --> 01:55:54.040
Tschüss.