Latest / Coding Buddies | Tech & Dev-Mindset / #121 DevOps 8 - Orchestrierung verstehen ohne Kopfschmerzen

Transcript

#121 DevOps 8 - Orchestrierung verstehen ohne Kopfschmerzen · Coding Buddies | Tech & Dev-Mindset

0:00
Container 1 sind wieder hochgefahren, Container 2.
0:01
Ich hab wieder gestartet ja Service 3 ist wieder online, so
0:04
weißt du. Coding Buddies Dein Podcast rund
0:08
um Softwareentwicklung und aktueller Tech News.
0:11
Herzlich Willkommen. Halli Hallo und herzlich
0:25
Willkommen zur neuen Folge des Coding Buddies Podcast.
0:28
Schön, dass du wieder eingeschaltet hast.
0:29
Lieber zuhören, lieber Zuhörer. Und deine Gastgeber, wie soll's
0:32
auch anders sein, meine Wenigkeit, der Tino und der
0:35
fantastische Fabi, der sich wie immer freut über meine Standard
0:38
Anmoderation. Ja Fabi, was geht ab, wie geht's
0:43
dir? Tino, Wie geht's?
0:45
Wie steht's? Ich hab grad so ein bisschen
0:46
blöde die Kamera gegrinst, weil ich so ein paar Faxen gemacht
0:48
hab, ich hoffe gut. Dass wir jetzt das immer mit
0:50
aufnehmen, dann können wir das ja zeigen.
0:52
Ich hoffe, ich hab dich nicht abgelenkt.
0:55
Nein, alles gut, mir geht's ganz gut.
0:59
Würde ich sagen, soweit ich habe.
1:01
Ich habe letztens, das möchte ich ganz kurz zeigen, ich habe
1:03
letztens eine krasse neue Erfahrung gemacht, die gar
1:05
nichts mit Coden zu tun hatte. Hau raus, aber.
1:09
Ich bin jetzt auf jeden Fall offiziell aufgelevelt in meinen
1:12
Skills, in meinen wie sagt man alltagskills Ach nicht mal
1:18
alltagskills nein, es ist, ich habe pass auf, ich habe einen
1:20
Fliesenspiegel selbst gefliest. Krass, da sind deine
1:24
handwerklichen Skills genau genau genau im Crafting.
1:27
Und ich hab, ich hab das noch nie gemacht und ich bin aber
1:30
eigentlich ziemlich zufrieden. Also ich denke mal wenn man
1:33
jetzt so Profi ist, dann denkt man sich vielleicht so, ah hier
1:37
hätte so n keine Ahnung, kreuz weißt du wo das wo die Fuge
1:40
hinkommt, die hätte vielleicht noch n bisschen besser sein
1:42
können oder so. Aber ist n Unikat, ist halt dein
1:46
Werk. Ja, aber es ist nicht schlecht.
1:47
Weißt du also, es könnte doch es ist, es ist so, weißt du, das
1:51
erste Mal gemacht. 95% perfekt, aber nicht 100.
1:56
Das ist aber 95 nicht schlecht. Also ich hab ja ein Bild gesehen
1:59
und es sah auch zumindest auf dem Bild schon gut aus, muss man
2:03
sagen. Ja, das war nur.
2:04
Das ey ich mein, du hast mir ja so ein total verpixeltes Bild
2:07
geschickt. Ja, aber man hat ja eigentlich
2:08
gar nichts erkannt oder so ein Katalog.
2:11
Das war dunkel im Raum. Genau.
2:13
Das ist doch gar nicht. Das ist doch gar nicht dein
2:15
Raum, ja. Ja, aber das.
2:18
Fand ich auf. Jeden Fall also erstmal Chapeau.
2:20
Ne, dass du das in die Hand genommen hast, find ich gut.
2:23
Ja man sagt ja auch Entwicklerinnen und Entwicklern
2:26
oft nach, dass sie 2 linke Hände haben und du warst ja jetzt
2:30
quasi so n Gegenbeweis ja, also Respekt an dich, fabi, ja.
2:34
Ich, ich dachte mir, weißt du, deswegen geht es mir auch ganz
2:36
gut, weil ich einfach zufrieden bin, dass ich so weißt du
2:39
einfach mal. Ehrliche Arbeit gemacht.
2:41
Hab sehr gut, sehr gut. Ich find das ist auch n gutes
2:45
Stichwort, wenn es um erschaffen und bauen geht.
2:49
Aber bevor wir zum heutigen Thema kommen, noch ganz kurz
2:52
eine Anmerkung, Liebe zuhören, lieber zuhören, falls dir dieser
2:54
Podcast gefällt und auch du auch vielleicht mehr wissen möchtest
2:57
über Fabi Fliesenspiegel, dann lass doch gerne ne Bewertung da
3:03
Teile den Podcast kommen. Tier ihn, schreib uns, wir
3:08
würden uns mega freuen, das supported uns extrem und
3:12
deswegen jetzt geht es auch direkt los mit dem Thema und
3:14
zwar klar wie. Follow da das ist.
3:17
N Follow auf jeden Fall. Das hilft uns ungemein und das
3:20
heutige Thema und jetzt kommt Stichwort bauen, wir machen
3:24
heute weiter mit unserer def Ops Reihe Fabi Ich hoffe du hast.
3:27
Sehr schön, wir lieben. Def Ops Wir haben Bock auf def.
3:30
Ops ja, sei Def Ops. Dev Ops, so das heutige Thema,
3:35
ist nämlich, was fehlt noch in unserer Reihe.
3:37
Wir wollen heute mal über Kontinuierisierung sprechen und
3:42
das ist n ganz ganz wichtiges Thema und auch n extrem
3:45
spannendes Thema muss ich sagen und ich hoffe wir kriegen das
3:47
gut rübergebracht, lass uns schauen, dass wir auch wieder so
3:51
Beispiele und Analogien einbauen um das ganze n bisschen zu.
3:55
Ja, bildlich darzustellen sage ich mal.
3:58
Und ich denke, dann wird das eine ganz coole Folge.
4:00
Oder was meinst du? Ja, auf jeden Fall.
4:02
Und Containerisierung containerisation ich weiß gar
4:05
nicht, wie man das so richtig ausspricht, das beide deutsch
4:07
Englisch ist auf jeden Fall auch ein spannendes Thema und auch
4:11
ein wichtiges Thema, gerade im Def Ops Bereich, was natürlich
4:15
jetzt erstmal wichtig ist. Was ist eigentlich ein
4:17
Container? Darüber hatten wir auch schon
4:19
mal eine eigene Podcast Folge gemacht, deswegen wollen wir das
4:21
jetzt nicht zu krass vertiefen, aber.
4:23
Also wenn das jetzt noch mal interessiert, Liebe Zora, lieber
4:26
Zora, dann guck noch mal paar folgen zurück.
4:29
Da gibt es auf jeden Fall ne ausführliche Folge zum Thema
4:31
Container und aber um das vielleicht noch mal so n
4:35
bisschen, ich sag mal abzugrenzen, kurz knapp, also NN
4:42
Container an sich ist ja im Endeffekt ein.
4:45
Ein Image, was keine Operating systemschicht, also kein
4:49
Betriebssystem, sozusagen keine Betriebssystemschicht benötigt.
4:54
Das heißt quasi ein Container ist eine gekapselte Umgebung,
4:59
was auf dem also die Ressourcen des Betriebssystems benutzt,
5:03
wenn man das jetzt noch mal abgrenzt zu einem zu einer VM,
5:06
da ist es ja so, dass im Endeffekt eine VM simuliert noch
5:08
mal komplett. Ein ganzes OS, also ein ganzes
5:12
Betriebssystem mit in der virtuellen Maschine und benutzt
5:17
sozusagen nicht die nicht die Ressourcen des zugrundeliegenden
5:20
Betriebssystems, sondern du kannst ja auf dann zum Beispiel
5:22
dem Windows Betriebssystem kannst du noch mal ein Linux
5:24
Betriebssystem oder andersrum beispielsweise in einer VM
5:29
laufen lassen und dann hast du im Endeffekt.
5:32
Sozusagen 2 Betriebssysteme, die du laufen hast.
5:35
Also einmal auf dem zugrundeliegenden System und
5:38
dann noch mal in der VM. Das ist beim Container eben
5:40
nicht so. Was das Ganze auf jeden Fall
5:42
schlanker macht und auch einfach handlebarer, gerade wenn es
5:46
jetzt zum Beispiel auch bei Containerisation im Def Ops
5:50
Bereich auch um Skalierung und so weiter geht, ne?
5:54
Genau. Also es ist halt nicht so
5:56
schwergewichtig wie eine VM, wie du gerade schon meintest.
5:58
Dadurch, dass halt dieser Hostkernel genutzt wird.
6:01
Und als Beispiel hatten wir ja da Docker genannt.
6:03
Ich denk mal, wir werden heute auch noch mal so auf Docker
6:05
kommen, ist immer n. Gutes Beispiel, ist halt auch
6:06
einfach so der Marktführer. Ja also ich glaub an Docker
6:09
kommt man nicht vorbei bitte. Kannst du auch Potman nehmen
6:12
oder so? Gibt es ja auch.
6:13
Ja, aber wie gesagt ist es halt so.
6:15
Der Marktführer und ich glaube, dass das spätestens nee, nicht
6:19
spätestens eigentlich so, sobald man sich mit dem Thema
6:22
beschäftigt, einem über den Weg läuft.
6:23
Also auf jeden Fall. Genau.
6:26
Aber bevor wir vielleicht noch mal zu Docker kommen und wie man
6:28
vielleicht noch mal so n Container in unserem Kontext
6:32
containerisierung aufbaut, noch mal ganz kurz, warum das denn
6:36
für Def Ops wichtig ist, um das Mal in unsere bisherige Reihe
6:40
einzugliedern. Wir haben ja zum Beispiel über
6:43
Staging gesprochen, ja, dass man halt in der Pipeline
6:47
unterschiedliche Stages hat, ne develop stage, ne Test Stage,
6:51
vielleicht dann die Prot Stage, wo halt wirklich die.
6:54
Der Service oder die Software an sich produktiv läuft und da sind
6:58
halt Container einfach absolut Gold wert um halt dieses
7:01
typische Problem und das hatten wir auch schon oft thematisiert
7:04
in Works on my Machine um dieses Problem einfach zu verhindern
7:08
oder sehr stark zu minimieren, weil du halt.
7:11
Wie du ja so schön meintest, du hast ja diesen Container in
7:14
einer festen Umgebung und der hat halt immer die gleichen
7:17
Bedingungen, wenn ich den laufen lasse sozusagen, und dadurch
7:20
sind wir halt plattformunabhängig.
7:22
Wir können halt auch schnell. Releasen oder Releases erzeugen,
7:28
indem wir halt so standardisierte Images haben für
7:31
diese Container und das ist halt einfach ne grundlegende Basis
7:34
für unser CICD, für unsere Pipeline und das ermöglicht uns
7:39
halt erst überhaupt in der Dev OPS Welt so agil entwickeln zu
7:43
können. Am Ende ja, also das muss man ja
7:44
noch mal ganz klar herauskristallisieren an dieser
7:47
Stelle. Ja, auf jeden Fall.
7:50
Ist auf jeden Fall definitiv wichtig, gerade wenn es jetzt
7:53
zum Beispiel auch um Dependencies und Abhängigkeiten
7:55
geht, wenn man sich vorstellt, man müsste lokal alles
7:59
konfigurieren auf seinem Rechner und dann sozusagen noch den, ich
8:02
sag mal, Server, auf dem die Anwendung läuft, vielleicht
8:06
einmal für Prot konfigurieren und einmal für.
8:10
Weiß nicht dev konfigurieren ne, also ich sag mal im Normalfall
8:13
im Bestfall sollten die Stages gleich aufgebaut sein und die
8:16
gleichen Abhängigkeiten haben, aber Ausnahmen bestätigen die
8:19
Regel. Aber nein, aber was ich meine
8:22
ist, es wäre ja auch zum Beispiel blöd, wenn du sagst, du
8:25
hast jetzt zum Beispiel eine Anwendung auf deinem Server
8:27
laufen nur noch eine andere und hast dann zum Beispiel bei der
8:30
einen Anwendung, hast du Abhängigkeiten ABC und bei der
8:33
anderen hast du AEF oder so ne als Abhängigkeiten um es so ein
8:37
bisschen meta Sprachemäßig zu das Ganze als Beispiel zu
8:42
bringen, aber. Du willst ja nicht dann auf
8:45
deinem Server einmal quasi die einen Abhängigkeiten
8:47
installieren und dann wenn du eine andere Anwendung laufen
8:50
lassen möchtest sozusagen gleichzeitig vielleicht noch wie
8:52
wie willst du das hinkriegen und so kannst du mit den mit den
8:54
Containern das ganze einfach viel viel schöner machen du
8:56
kannst sagen okay Anwendung 1 läuft in Container 1 mit den
8:59
entsprechenden Abhängigkeiten die ich brauche und abhängig
9:02
Anwendung 2 läuft eben im Container 2 mit den
9:05
entsprechenden Abhängigkeiten die ich da brauche und die
9:07
kommen sich eben gegenseitig nicht ins Gehege nutzen aber die
9:10
gleichen Ressourcen von deinem Server beispielsweise und das
9:13
ist ja sozusagen. Genau das, was im Endeffekt
9:16
wichtig ist oder wieso man dann vielleicht auch das ganze, wieso
9:21
das Ganze so wichtig ist. Gerade wenn wir über
9:23
Orchestrierung reden oder Containerisierung, kommt ja
9:26
später noch, dann ist es ja nicht nur so, dass du meistens
9:30
ein Image irgendwie ein, also ein Docker Image laufen lässt
9:33
oder ein anderes nur also 1 auf einem Rechner oder einem Server,
9:37
sondern meistens mehrere und darauf wollen wir ja im
9:40
Endeffekt dann hinaus. Genau.
9:43
Und wenn wir das Beispiel bringen, dann glaube ich, können
9:45
wir noch mal ganz klar herausstellen, warum oder wo der
9:48
große Vorteil gegenüber einer VM dann ist.
9:52
Aber dazu später mehr. Lass uns mal noch so ein
9:54
bisschen drauf eingehen, wie man überhaupt so ein Container baut,
9:58
weil es gibt ja bestimmt auch Zuhörerinnen und Zuhörer, die
10:02
vielleicht noch da sich noch nicht beschäftigt haben und noch
10:05
nicht so eine richtige Vorstellung haben, wie das
10:07
grundsätzlich vom Prinzip her. Abläuft.
10:10
Und ich finde, das kann man so ganz gut in 3 Schritten
10:14
gliedern. Ja also und da würde ich jetzt
10:16
wirklich mal Docker nehmen, weil es halt wirklich wie gesagt sehr
10:19
verbreitet ist und man dann halt so nen direkten Bezug hat und
10:23
der erste Schritt. Ist im Prinzip so ne Art
10:26
Manifest aufzubauen, also eine Beschreibung und das kann man
10:30
ganz gut mit dem Docker File an sich vergleichen.
10:33
Ja also du beschreibst halt, wie sieht mein Basisimage aus, ja
10:38
welche Daten werden benötigt, ich kopiere sie zum Beispiel aus
10:42
meiner Route sozusagen in meinen, in mein Image, sozusagen
10:46
in den Container installier dependencies und so weiter also
10:50
ich beschreib quasi, wie sieht meine Umgebung aus?
10:53
Genau. Also wenn du jetzt zum Beispiel
10:54
sagst Basis. Das Image, das könnte ja
10:56
beispielsweise so was sein wie, sagen wir mal so, ein Node
11:00
image. Es gibt ja auch zum Beispiel
11:02
dann, wenn Du von Docker redest, auch bei Docker Hub gibt es ja
11:05
bestimmte Images, vorgefertigte, wo du dann zum Beispiel sagst,
11:08
du kannst, lass mich jetzt nicht lügen, ein Image von Node 20
11:12
haben, wenn du jetzt zum Beispiel, sagen wir mal,
11:13
irgendeine Anwendung mit Node entwickeln möchtest, dann ist es
11:17
ja unbedingt notwendig, dass du das eben hast, so genau und
11:20
dann. Dann hast du.
11:21
Dann kannst du dir so ein Image ziehen.
11:22
Es gibt verschiedene Images, auch von offizieller Seite sage
11:26
ich jetzt mal, dass zum Beispiel Node selber sagt okay, das sind
11:28
unsere offiziellen Images und die kann man als Basis Image
11:32
nehmen und sich zusätzlich noch eigene Sachen installieren, wie
11:35
du meintest diese dependencies und halt seine eigene Anwendung
11:38
noch sozusagen, also alle Files die man hat rein kopieren in
11:42
dieses Image. Es ist natürlich alles eine
11:43
textliche Beschreibung, was dann also was da passieren soll, aber
11:47
so kann man sich das ungefähr vorstellen, genau.
11:50
Genau, also wir hatten ja auch so n bisschen Infrastructure is
11:52
code, also hat mir ne eigene Folge zugemacht und so ähnlich
11:56
kannst du dir das jetzt hier auch vorstellen in diesem in
11:58
diesem Manifest. Also du schreibst, du Kodierst
12:00
quasi diesen Aufbau deiner Infrastruktur in diesem Docker
12:05
Image dann beispielsweise oder beziehungsweise in deinem
12:07
Container. Und das die Basisimages ist halt
12:11
n sehr wichtiger Punkt den du ansprichst.
12:13
Das geht ja soweit, dass du auch sagen kannst, ich möchte zum
12:15
Beispiel NN, Ubuntu Image oder so.
12:17
Ja also da gibt es halt Tausende Varianten und auch sehr
12:22
spezifische, dass du halt schon gar nicht mehr so viel vorweg
12:24
konfigurieren musst, weil du einfach dir, so sag ich mal
12:27
deine. Grundbedingungen einfach schon
12:29
laden kannst über einen Base Image sozusagen.
12:32
Eine kleine Anmerkung dazu noch, da würde ich glaube ich noch
12:35
sagen, dass auf jeden Fall, man kann sich unglaublich viele
12:37
verschiedene Images holen. Man sollte aber immer
12:39
reingucken, auf jeden Fall, was im Image steht und dass man sich
12:43
vielleicht auch, das ist ja auch der Gedanke dahinter, um
12:46
möglichst oft, also performant zu sein und sage ich jetzt mal
12:50
wenig, möglichst wenig Ressourcen zu verwenden.
12:53
Sollte man vielleicht gucken, dass man auch n Image verwendet,
12:55
wo man wirklich das drin hat was man braucht und nicht noch super
12:58
viel? Ne.
12:58
Also wenn du jetzt zum Beispiel wirklich nur eine bestimmte
13:01
Sache brauchst, dann musst du dir jetzt vielleicht nicht zum
13:03
Beispiel so n ganzes Ubuntu Image holen, kann aber durchaus
13:05
hilfreich und notwendig sein, damit du nicht tausendmal sagst
13:08
so ach ich muss das noch nachinstallieren, ich muss das
13:10
noch nachinstallieren, ne. Genau so.
13:13
Genau. Das ist n sehr guter Aspekt,
13:15
weil es braucht natürlich auch seine Zeit, diese Images
13:18
aufzubauen und die Container später zu starten.
13:21
Das dann kommen wir nämlich auch schon direkt zum zweiten
13:23
Schritt, wenn ich jetzt dieses Manifest hab und ich hab
13:25
beschrieben wieso n Image aussehen soll für meinen
13:28
Container später, da muss ich das natürlich bauen, ne, also
13:31
das enthält dann am Ende den Code ja also im Prinzip den ich
13:35
eigentlich ausführen möchte, mein Programm, mein Projekt so
13:38
gesehen. Ne Runtime die Libraries, da ist
13:42
jetzt alles drin definiert Dank unseres Manifests.
13:44
Ja, also beispielsweise das Stockerfile und dann kann ich
13:47
dieses Image bauen und dann hab ich n fertiges Image was ich
13:50
ausführen kann, laufen lassen kann und im Prinzip meine
13:54
Anwendung beinhaltet. Ja, das stimmt.
13:56
Und. Der dritte Schritt ist ja dann
13:58
eigentlich sozusagen. Jetzt kommt der Container ins
14:01
Spiel, jetzt erstelle ich mir einen Container, der isoliert
14:07
eine Instanz dieses Images laufen lässt.
14:10
Das heißt ich hab ne abgekapselte Umgebung, wo mein
14:12
Image drin ausgeführt wird, wie ich es so beschrieben hab.
14:15
Ja, also im Endeffekt ja meine Anwendung.
14:17
Genau, also du hast im Endeffekt das Image, ist sozusagen dieser
14:22
Bauplan ne und der Container ist sozusagen ein ne, also.
14:26
Wie du schon meintest, das ist jetzt redundant, aber genau die
14:30
Instanz dieses Images. Das heißt du kannst es
14:33
theoretisch auch 5 Mal bauen und 5 mal laufen lassen, ne und dann
14:36
hast du quasi 5 mal dein was weiß ich backend frontend frag
14:40
mich nicht anwendung XY halt laufen wenn du möchtest.
14:45
Genau und dadurch wie du ja meintest du dadurch, dass du es
14:48
mehrfach machen kannst, hast du halt dieses einheitliche Setup
14:51
ne und das kannst du halt für alles immer wieder verwenden,
14:53
zum Beispiel für Deployments. Ja, und dieses Prinzip dahinter
14:57
ist ja grundlegend gleich. Ja, also wir haben jetzt Stocker
15:01
genommen, du hast Potman gesagt, also es ist halt im Prinzip.
15:05
Ist immer der gleiche Ablauf am Ende?
15:07
Ja, das heißt dann vielleicht nicht Docker file
15:10
logischerweise, oder die Syntax ist anders, wie auch immer, aber
15:13
ich sage mal, diese 3 Schritte sind halt so die die
15:15
grundlegenden Schritte die man da durchführen muss.
15:19
Ja, und wenn du jetzt zum Beispiel sagst, OK, du hast
15:21
jetzt eine CICD Pipeline, warum ist es vielleicht auch
15:24
interessant, zum Beispiel auch unterschiedliche Docker
15:27
Container zu nutzen und nicht, dass du beispielsweise sagst,
15:29
OK, ich nehme jetzt aber einfach ein Docker Container und da
15:32
lasse ich alles drin laufen die ganze Zeit.
15:35
Also allein schon wenn du sagst, du hast zum Beispiel eine
15:37
Anwendung mit einem Test Framework und du willst deine
15:40
Anwendung testen, so dann brauchst du natürlich dieses
15:43
Test Framework mit in deinen Dependencies, um sozusagen deine
15:47
Tests laufen zu lassen. Aber in deiner produktiven
15:49
Umgebung brauchst du das Test Framework ja gar nicht, das
15:51
heißt, du kannst es einfach weglassen und das sozusagen raus
15:54
optimieren. Kleines Beispiel aber um das Mal
15:56
zu zeigen, wieso du zum Beispiel vielleicht auch einfach
15:59
innerhalb deines Deployments vielleicht mehrere
16:01
Dockercontainer brauchst, dann der ist ja jetzt 2, aber.
16:04
Ja, ja, und es kann ja auch ne unterschiedliche Konfiguration
16:07
enthalten sein. Ne, dann hast du halt einmal sag
16:09
ich mal n testimage oder prot Image und da sind aber
16:12
unterschiedliche Konfigurationen, zum Beispiel
16:14
gegen welchen Server da gecallt wird, mal so als Beispiel ne,
16:18
also das ist halt n sehr wichtiger Punkt den du da
16:20
genannt hast, dass du damit natürlich gerade dieses Staging
16:23
enorm unterstützen kannst. Am Ende ja genau.
16:28
Ja, aber warum ist denn jetzt kontainerisierung?
16:33
Ich nehm mal das deutsche Wort deutscher Podcast du hast recht,
16:36
es ist eigentlich nicht mal n richtiges deutsches Wort, so
16:38
schön eingedeutscht, warum ist das jetzt so?
16:42
N Death Ofs Game Changer, das würd ich gern noch mal ganz klar
16:45
herauskristallisieren, was wir daran halt so feiern oder
16:48
beziehungsweise die Death ofs Welt ja nicht nur wir beide.
16:52
Du hast halt dieses einheitliche Deployment, das hattest du ja
16:55
glaube ich, eben schon so ein bisschen erwähnt.
16:57
Du kannst eben konsistente Bilds erzeugen über deine
17:00
entsprechenden Umgebungen, was geht noch?
17:04
Schnelle Fehlerfindung und Behebung, weil du ja explizit
17:08
auch in diesen Einzelnen in diesen einzelnen
17:10
Dockercontainern eben deine einzelnen, sagen wir mal stages
17:15
hast oder oder Teile deiner Pipeline, wenn du es denn
17:18
richtig aufteilst. Was ja im Endeffekt auch dazu
17:21
führt, dass du nicht in einer großen Maschine oder auf einem
17:24
großen Server in 1000 logs irgendwie rumsuchst.
17:27
So was ist denn jetzt hier, was ist da, sondern du hast halt in
17:30
in in Container und nicht nur, dass du sagst, du hast n
17:33
Container für zum Beispiel. Weiß nicht deine deine CI oder
17:39
dein CI teil, beispielsweise ne wo vielleicht auch
17:42
beziehungsweise dein CD teil wo auch die Tests laufen.
17:46
Ne was ich gerade eben meinte es ist ja nicht so, dass du dann
17:49
einen Container hast, wo du dann immer wieder den Container
17:51
nimmst und deine Tests da drin sozusagen das erste Mal, das
17:54
zweite Mal das dritte Mal je nach Pipelinedurchlauf laufen
17:56
lässt, sondern du baust ja in jedem Pipeline auf, in jedem
17:59
Pipelinedurchgang wieder einen neuen Container.
18:02
Auf das heißt, du hast ja immer quasi eine kleine kleine
18:05
gekapselte Instanz, mit der du dann am Ende arbeiten kannst
18:10
beziehungsweise arbeiten im Sinne von wenn was schief geht
18:13
oder wenn du irgendwas nachgucken möchtest, dann kannst
18:16
du halt relativ schnell auch eben gucken, was ist denn in
18:19
diesem einzelnen Container passiert und musst jetzt nicht
18:21
quasi noch alles, was vorher passiert ist, auch noch
18:23
durchgucken. Ja, du hast halt genau diese
18:27
isolierte Instanz am Ende ne und du weißt dann genau, an welcher
18:30
Stelle es geknallt hat sozusagen und das kann man halt auch super
18:35
für die ganze Automatisierung einer Pipeline nutzen.
18:39
Ja was ja ne Pipeline erst interessant macht, wenn halt die
18:42
ganzen manuellen Schritte rausfallen und das lässt sich
18:46
halt. Diese Container lassen sich halt
18:48
super integrieren in so ne automatisierte Pipeline ne und?
18:52
Du kannst halt dann am Ende für für das Deployment dann ja auch
18:56
einfach diese Docker Images auch wirklich deployen, sozusagen ne
19:00
und sagen OK, jetzt gibt es n neues Image ne neue Version
19:03
meiner Anwendung und die kann in einem Docker Container
19:05
hochgefahren werden, beispielsweise ne dafür baust du
19:08
das Halt auf, Testest das und dann kannst du das ja deployen
19:11
beispielsweise und. Ja, das ist ja voll integriert.
19:16
Wenn wir zum Beispiel in der github Welt unterwegs sind, hast
19:19
du ja auch die github Registry, wo du quasi in deinem Repo ja
19:24
schon images bereitstellen kannst.
19:26
Am Ende ne mit Github Actions ist das halt super schnell
19:29
aufgesetzt, so eine ganz einfache Pipeline, das ist ja
19:32
wirklich mittlerweile so geil umgesetzt oder umsetzbar Feier
19:37
ich total und man muss natürlich auch sagen, dass das auch eine
19:42
Grundlage ist und. Um überhaupt so Microservices,
19:47
Architekturen, ja wie sehr heutzutage gelebt werden,
19:51
aufsetzen zu können durch Container und man nicht mehr
19:55
halt riesen Monolithen hat. Liebe, zuhören, liebe Zuhörer,
19:58
falls das n Thema für dich ist, dann meld dich doch gerne bei
20:01
uns. Wir können gerne mal ne Folge
20:02
machen zu Monolithen versus Microservices.
20:05
Ja das ist n super spannendes Thema und wovor und Nachteile da
20:09
drin liegen. Und wenn wir schon beim Thema
20:12
Microservices sind, kommen wir eigentlich zum zweiten Punkt der
20:15
heutigen Folge zur Orchestrierung.
20:18
Weil jetzt wird es ja spannend. Was macht man mit den
20:20
Containern? Ja, und vielleicht magst du ja
20:22
mal kurz so ne Einführung geben, Fabi was Orchestrierung ist
20:27
eigentlich. Genau also, wenn man sich das
20:29
jetzt vorstellt. Und du sagst ja OK, also
20:32
Orchestrierung kommt ja erstmal wirklich von.
20:35
Von Orchester. Also du hast ja quasi.
20:38
Surprise. Surprise.
20:41
Da ich, ich weiß nicht, das ist richtig, manchmal ist mein Kopf
20:45
auch so richtig dumm, ne, weil ich ja so früher so redest du da
20:48
drüber und denkst so Orchestrierung, Orchestrierung,
20:50
das klingt irgendwie, es klingt irgendwie wie Orchester so, also
20:53
das ist ja, und da sind du so, ah okay also.
20:56
Leider aber ist ein guter Hinweis ja also, dass man dann
20:59
hat man halt nämlich die perfekte Analogie, schon genau
21:01
also. Du komponierst im Endeffekt, oh
21:04
du, du setzt so. Sozusagen deine
21:05
Gesamtkomposition aus verschiedenen, also deine
21:09
Gesamtanwendungen aus verschiedenen Dockercontainern
21:12
zusammen. So gesehen ne, das ist genauso
21:14
wie ein Orchester, da setzt ja zum Beispiel auch so
21:15
verschiedene Musikinstrumente zusammen, die dann im Endeffekt
21:19
ein großes Ganzes ergeben. Und wenn du jetzt zum Beispiel
21:22
sagst okay, du hast jetzt vielleicht irgendwie so ein 2
21:24
Container, ist es jetzt an sich kein Ding, da musst du jetzt
21:26
nicht mit einer großen Orchestrierung starten und so
21:28
weiter aber wenn du jetzt wirklich in der heutigen Welt
21:33
sagen wir mal eine große Anwendung hast mit
21:37
verschiedenen, also wirklich auch mit so einer Micro Service
21:40
Architektur, das heißt, du hast quasi dein dein Deployment, du
21:43
hast deinen Server, da laufen dann zum Beispiel verschiedene
21:46
Services drauf, wie der Name ja schon sagt, also jeder Service
21:48
macht sein eigenes Ding, also du hast dann vielleicht zum
21:51
Beispiel so was wie ein Authentication Service, das ist
21:53
ein eigener Service, der in einem eigenen Docker Container
21:56
läuft, genauso wie zum Beispiel dann weiß ich nicht das eine der
22:00
eine Teil deiner App und der andere Teil also wie gesagt
22:03
Microsoft ist. Das können wir auch noch mal ein
22:04
bisschen genauer behandeln. In einer eigenen Podcast Folge
22:07
will ich jetzt nicht genau darauf eingehen, aber man muss
22:10
sich das ungefähr so vorstellen, dass wenn du eine Anwendung
22:13
hast, die aus verschiedenen Teilen besteht, kannst du rein
22:16
theoretisch diese Teile auch einfach trennen und nicht in
22:19
einen großen Batzen haben, sondern das wirklich sozusagen
22:23
in einzelne kleine Anwendungen trennen, die du dann aber
22:26
jeweils in einem Docker Container laufen lässt und dann
22:29
sozusagen muss das ganze ja irgendwie zusammen spielen, das
22:32
heißt du brauchst dann. Ja, irgendwie vielleicht
22:35
Connections untereinander, die müssen kommunizieren können, wie
22:37
auch immer, ne. Aber Fakt ist auf jeden Fall, du
22:39
hast dann deine ganzen Container und damit das aber auch alles
22:43
zusammen funktioniert, musst du halt und jetzt kommt genau der
22:46
Punkt das ganze Orchestrieren ne aber Orchestrierung an sich ist
22:52
ja nicht nur, dass du sagst du hast deine ganzen Container
22:55
zusammen, ne die dann vielleicht in einem.
22:58
Großen Cluster laufen ne, hier zum Beispiel auch, Stichwort
23:01
Cubanitis ne cubanitis cubanitis.
23:05
Ist. Jetzt wieder so prädestiniert
23:08
dafür, dass man es falsch ausspricht oder jeder es anders
23:11
ausspricht. Aber es gibt ja auch noch andere
23:14
Sachen, die Halt wichtig sind bei einer Orchestrierung, ne.
23:19
Ja, also im Prinzip. Hast du ja zum Beispiel auch
23:23
dieses Starten und stoppen von Containern, ne?
23:26
Also da noch mal dieses orchesterbeispiel du dirigierst
23:30
das ganze ne, du bist jetzt das System was die Container
23:33
verwaltet und zeigst halt sozusagen jetzt bist du dran,
23:38
jetzt hörst du auf du und so weiter ne jetzt laufen die so
23:42
ich find das ist halt wirklich ne gute Analogie ja also du du
23:45
dirigierst das ganze ne und sagst welcher Container läuft
23:48
und welcher nicht genauso. Hast du ja zum Beispiel auch in
23:52
einem Orchester von einem Instrumententyp, was jetzt mal
23:56
ein spezieller Container in unserem Fall wäre.
23:59
Ne, mehrere Instanzen, du hast ja mehrere Spieler und
24:02
Spielerinnen davon, ja zum Beispiel die Geige, geigen, die
24:06
erste Geige ist Beispiel. Spielst du die erste und die
24:08
zweite Geige? Und das ist nämlich genau der
24:13
nächste Punkt, was bei der Orchesterierung wichtig ist.
24:15
Und zwar Skalierung. Ja, brauche ich von diesem
24:18
Container mehr Instanzen oder weniger, je nach Last?
24:22
Ja, also du hast halt auch im Prinzip N Load balancing.
24:26
Du verteilst die Anfragen dann gleichmäßig.
24:29
Ne, also logischerweise wenn ich jetzt 4 geigenspieler hab, dann
24:32
darf ja der eine nicht alle 4 spielen, oder wie soll er das
24:35
machen, der ist ja sofort überfordert und das geht halt
24:38
nicht, also verteile ich quasi das auf die 4 Geigen zum
24:41
Beispiel und das sind alles so Themen was die Orchestrierung
24:44
beinhaltet, da gibt es natürlich noch spezifische Sachen wie Cell
24:50
Feeling ist ein riesen Punkt, ja wenn zum Beispiel ein Crash
24:54
erkannt wird. Ja, dass du sagst, Oh, den
24:57
Container muss ich mal neu starten, da ist so was
24:58
schiefgelaufen, aber ich muss irgendwie wieder n Zustand n
25:01
heilen Zustand erreichen, dass das Ding wieder läuft, am Ende
25:06
keine Ahnung, der Geigenspieler fällt vom Stuhl.
25:09
Ja und das klingt einmal komisch, aber du musst ja wieder
25:12
n Zustand erreichen, dass es wieder harmonisch klingt am
25:14
Ende, indem du den Stuhl wieder hinstellst und den Geigenspieler
25:17
da drauf setzt beispielsweise ja und dann gibt es natürlich den
25:23
Rollbacks. Ja, das passiert nur
25:25
Geigenspieler. Und wenn das alles nicht hilft
25:28
und der jedes Mal wieder vom Stuhl fällt, dann machst du halt
25:30
n rollback und sagst OK, der neue Geigenspieler, das war
25:34
keine gute Idee, ich nehm die wieder raus, ich nehm wieder den
25:37
alten. Also um das ganze technisch kurz
25:41
zu machen. Wenn ich jetzt ne neue Version
25:44
hab von meiner Software und da läuft irgendwas schief ne und
25:46
das Self Feeling funktioniert nicht, irgendwie crasht das die
25:49
ganze Zeit, dann hab ich natürlich auch über meine
25:52
Orchestrierung die Möglichkeit n Royback zu machen und zu sagen
25:57
ich dreh das Ganze auf die alte Version zurück und hab erst mal
26:00
wieder n sauberen Zustand. Ne, und das sind halt Rollouts.
26:03
Ich kann automatisiert neue Versionen ausrollen, ne und zur
26:07
Verfügung stellen und rollbacks, ich kann sie automatisch wieder
26:10
zurückdrehen, sozusagen und wieder auf ne alte Version gehen
26:14
und das sind so typische Anwendungsfälle, genau also.
26:17
Gerade wenn wir jetzt sagen, Def Ops hat ja natürlich
26:20
logischerweise viel mit Automatisierung zu tun, wie du
26:23
ja auch schon meintest. Man möchte sich ja nicht
26:25
vorstellen. Angenommen, irgendein Service
26:28
Crash bei was weiß ich irgendeinem großen Riesen
26:30
Unternehmen ne vielleicht irgendwas mit Social Media oder
26:33
frag mich nicht oder hier irgendwas im E Commerce Bereich
26:36
und dann gibt's dann irgendwie weißt du dann kommt so die Task
26:39
Force Gruppe setzt sich an die an die Rechner schaltet sich auf
26:42
die Server dann Container 1 sind wieder hochgefahren Container 2
26:45
ich hab wieder gestartet ja Service 3 ist wieder online so
26:48
weißt du und dann so nein sie gehen wieder down sie gehen
26:51
wieder down verdammt. So, da kommt die, da kommt die
26:55
zweite Taskforce Gruppe, die das Ganze dann ne irgendwie
26:58
programmieren Bug fixen muss und so weiter aber in der Zeit
27:01
passiert halt nichts und deswegen kannst du halt zum
27:03
Beispiel mit einem automatisierten Rollback, wo
27:05
jetzt auch wieder Stichwort Monitoring mit dazu kommt, ne du
27:08
musst ja wissen, OK. Geht denn irgendwas die ganze
27:11
Zeit schief, damit du dann automatisiert über deine
27:13
Orchestrierung sozusagen auf so n bestimmtes Signal reagieren
27:16
kannst? Um zu sagen, OK, pass auf, da
27:18
ist jetzt n Problem aufgetreten. Wir müssen jetzt zum Beispiel
27:21
wieder auf die letzte stabile Version zurückrollen, das was
27:23
wir jetzt gerade neu gemacht haben, das funktioniert nicht
27:25
und dann läuft wieder alles Punkt 1 und Punkt 2 ist das Team
27:29
was die Bugs dann fixt sag ich jetzt mal dem was ich gerade
27:32
gesagt hab, das kann sich dann vielleicht bisschen mehr Zeit
27:35
lassen oder ist nicht ganz so hektisch.
27:39
Ne. Ja, ich mein, da braucht man
27:41
sich ja nur wieder die Analogien nehmen mit dem echten Orchester.
27:45
Ne, also der Dirigent vorne, der hat ja n unfassbar schwierigen
27:48
Job. Ja, also er muss ja absolut
27:50
akkurat sein, er muss genau wissen wer was macht, jetzt muss
27:54
das richtig signalisieren, damit das ganze Orchester das genauso
27:58
spielt, wie es gedacht ist. Das Werk, ja und?
28:02
Und jetzt macht er das ja manuell, in dem Fall.
28:05
Wie lange macht er das? Keine Ahnung wie lange sowas
28:08
geht, er hat ja Pausen dazwischen, aber sagen wir mal
28:11
so er muss nicht wie in unseren Anwendungsfallen 24 7 jetzt so
28:17
ein Orchester da leiten, weil das würde einfach zwangsläufig
28:21
zu Fehlern führen und genau das ist nämlich der Punkt, wie du ja
28:24
schon meintest, das geht manuell nicht, wir brauchen irgendwie
28:27
toolische Unterstützung um das automatisiert hinzukriegen und
28:30
ich finde da kann man die Analogie halt auch.
28:32
Hochziehen, weil wie lange würde das n Dirigent wirklich
28:35
durchhalten am Stück ja ohne Fehler zu machen.
28:38
Ja, richtig, also ab jetzt Dirigenten immer automatisieren.
28:43
Immer Props raus, ihr macht n geilen Job.
28:46
Ja, aber auf jeden Fall. Wenn ihr das jetzt nimmst, dann
28:49
ist es natürlich so, dass wenn wir jetzt von Containern reden,
28:52
dann ist n Container im Endeffekt ein Spieler im
28:54
Orchester oder eine Spielerin und die Orchestrierung an sich
28:59
sozusagen, das ist dann sozusagen der Dirigent, ne, also
29:01
der. Übernimmt dann die
29:02
Orchestrierung. So, dann haben wir es noch mal.
29:04
Nicht ich finde, das ist auch ein schönes Beispiel, weil der
29:06
Klassiker, den können wir ja auch nennen, ist natürlich der
29:08
Container. Ist so ein Schiff, ja oder so
29:12
ein Container am Hafen und die Orchestrierung ist dann
29:15
sozusagen der Hafenmeister, der gesagt, sagt Okay Schiff dahin,
29:18
Schiff dahin oder keine Ahnung, den Container stellst du da
29:21
drauf, den da drauf, also man kann das natürlich auch auf die
29:25
schiffsfahrten mappen, sage ich. Mal wegen Container ganz genau.
29:31
Warte mal. Bei Docker gab es doch auch, ist
29:33
doch sogar das Ganze in dem in dem in dem Bild drin von Docker.
29:37
Ja, stimmt. Der war mit dem Container.
29:41
Genau. Ja, es ist.
29:42
Es ist einfach naheliegend. Deswegen finde ich es gut, dass
29:44
wir das mit dem Orchester machen, aber kommen wir mal zu
29:49
weiteren Analogien und Beispielen.
29:53
Und zwar möchte ich sehr gerne eine Analogie noch mal
29:56
aufgreifen. Die haben wir einfach schon
29:58
gebracht, die ist bekannt in unserem Podcast.
30:00
Und zwar möchte ich wieder in die Welt der Restaurants mit dir
30:03
eintauchen, jetzt wird es wieder kulinarisch, es wird kulinarisch
30:07
hier im Coding Buddies Podcast. Hol dir was denn genau?
30:12
Kurze Snackpause und zwar um einfach noch mal klarzustellen,
30:18
wie sieht die VM Welt aus und. Und wie sieht jetzt unsere neu
30:21
beschriebene Kontinuierisierungswelt aus?
30:24
Ja, hau raus und wenn wir jetzt noch mal so in der
30:26
Restaurantwelt sind und wir gehen noch mal in die VM Welt,
30:28
wie du meintest eigenes OS ne und schwergewichtig jetzt stell
30:33
dir vor du hast n Restaurant, du hast ja viele Gerichte ja also
30:36
du hast ja ne Karte, da ist wieder unser Menü sagen wir mal
30:39
du hast ne feine aber gute Auswahl so ne ne kleine 20
30:43
Gerichte so. In der VM Welt so gesehen würde
30:49
das bedeuten, ich muss jetzt für jedes Gericht ne eigene
30:53
komplette Küche aufbauen. Ja, also ich muss mir jetzt ne
30:56
Welt schaffen wo ne Küche drin ist um dieses Gericht quasi.
31:00
Herstellen zu können, und das ist logischerweise teuer und
31:03
Ressourcenverschwendung einfach am Ende, weil ich kann jetzt
31:07
nicht getrennte Gerichte machen, sondern entweder ich mach alle
31:10
Gerichte auf einmal in einer, also weißt du in einer Umgebung
31:14
oder ich muss mir halt wirklich mehrere Küchen aufbauen und das
31:18
ist natürlich einfach Quatsch und deswegen kontinuierisierung
31:22
bedeutet, ich habe ne Großküche wie in einem Restaurant mit
31:26
geteilten Ressourcen. Zum Beispiel?
31:28
Ich habe einen Herd, ich habe einen Kühlschrank und so weiter.
31:31
Aber da kann ich noch mal gleich einhaken, weil das ist.
31:33
Das zeigt nämlich auch noch mal, dass du ja zum Beispiel, wenn
31:36
gerade wenn du jetzt zum Beispiel sagst, du hast eine
31:38
Küche, wo du alles kochen willst, kann es natürlich sein,
31:41
dass es vielleicht in der einen Küche eventuell nicht unbedingt
31:44
auch immer das gibt, was du auch wirklich brauchst für das
31:47
entsprechende Gericht. Also du kannst vielleicht nicht
31:48
alle Gerichte wirklich in einer Küche kochen, so ne.
31:52
Ja. Und genau, wenn du dir jetzt
31:56
vorstellst, wenn ich so n Gericht herstelle, dann hab ich
31:59
ja verschiedene Stationen. Ja die die irgendwie notwendig
32:04
sind dafür oder halt Stichwort Manifest noch mal unsere
32:07
Umgebung, die ich dafür brauche für das eine Gericht brauch ich
32:11
n Topf für das andere brauch ich ne Pfanne und so weiter für
32:14
manche vielleicht auch Topf und Pfanne.
32:16
OK, aber. Aber am Ende hab ich ne saubere
32:19
Trennung. Ne, das heißt ich hab nur meine
32:20
Zutaten und ich hab diese Station und dann kann ich halt
32:23
meine Gerichte herstellen und der Vorteil dabei ist Stichwort
32:28
Skalierbarkeit was wir gezeigt haben ey wir müssen jetzt
32:32
mehrfach mehrfach dieses Gericht kochen.
32:35
Ja OK ist ja kein Problem weil ich muss ja jetzt nicht jedes
32:38
mal ne neue Küche aufbauen, gib mir einfach mehr Töpfe und das
32:41
ist nämlich genau der Knackpunkt dabei, ich setz einfach mehr
32:44
Töpfe damit auf. Und habe am Ende quasi mehrere
32:48
Instanzen, wo dieses Gericht gekocht wird.
32:51
Richtig, gehen wir jetzt mal davon aus, dass man auch auf dem
32:55
gleichen Herd mehr Töpfe platzieren kann.
32:58
Das gibt mir einen weiteren Herd, aber gibt mir nicht eine
33:01
neue. Küche nee, aber das ist eine
33:05
gute Analogie, weil im Endeffekt hast du ja dann die Möglichkeit.
33:10
Ne ohne diese riesen Ressourcen die du aufwenden müsstest um
33:14
sozusagen jetzt zu sagen, ey ich brauch noch n zweiten Herd OK
33:17
für n zweiten Herd nehm ich noch ne zweite Küche dazu.
33:20
Super Sache passt ja, das wär natürlich genau Quatsch und
33:24
jetzt kommt natürlich jetzt zum Beispiel die Orchestrierung mit
33:26
rein ne oder beziehungsweise ne unsere unsere wie sagt man
33:33
containerfizierung was ist das das deutsche Wort?
33:39
Oder also, wenn wir jetzt solche Cubanitis nehmen, und das wäre
33:43
ja dann im Endeffekt so der Vergleich zum Küchenchef.
33:46
Ne, weil genau. Der Küchenchef weiß ja dann zum
33:50
Beispiel, wie zum Beispiel auch der Dirigent im im Orchester,
33:54
wieviel Töpfe werden denn benötigt.
33:56
Ne, also weil zum Beispiel der es man weiß ja dann OK wieviel
34:00
Bestellung kommen überhaupt rein, was muss denn überhaupt
34:02
gekocht werden, ne Stichwort Load balancing zum Beispiel, das
34:05
heißt du kannst dann im Endeffekt genau dirigieren und
34:08
sagen das. Als Küchenchef.
34:10
So jetzt bitte, wir brauchen so und so viel Töpfe, wir brauchen
34:13
so und so viel Leute, die jetzt zum Beispiel die Nudeln kochen
34:16
oder die und die Soße zubereiten und so weiter ne.
34:19
Und zwar so, dass du dann im Endeffekt auch zum Beispiel
34:21
sowas wie Überlast Verhinderst, weil es bringt ja auch nichts,
34:24
wenn du keine Ahnung, sagen wir mal, du hast n Restaurant ne und
34:28
willst jetzt für ne kleine Gruppe für ne Geburtstagsgruppe,
34:31
die einfach sehr exquisit sagen, wir wollen jetzt den ganzen
34:34
Laden mieten, weil wir sind jetzt hier 12 Leute und das soll
34:37
jetzt wirklich, es ist der 90. Geburtstag und das ist richtig
34:40
super ne so keine Ahnung. Und dann gibt's jetzt aber ne
34:43
Großveranstaltung, ne. Ich meine, das liegt auf der
34:46
Hand, dass man da vielleicht ein Paar mehr, ich nenne es jetzt
34:48
mal extra Instanzen braucht für, sagen wir mal,
34:53
kochunterstützung. Ja genau, es ist ja, es ist.
34:57
Kann man sich wirklich ganz klassisch vorstellen, ne, also
35:00
der Küchenchef deren Aufgabe ist es ja einfach zu sagen, wann
35:06
brauche ich denn mehr küchenhilfen oder mehr
35:09
Köchinnen, wie auch immer mehr Köche aber.
35:12
Einfach nur zum Beispiel anhand von Veranstaltungen oder von von
35:18
Wochentagen abhängig. So ist es ja am Ende bei einer
35:21
normalen kleinen Server Anwendung zum Beispiel auch.
35:24
Ja wenn du sagst ey, weißt du, am Wochenende haben wir einfach
35:28
eine höhere Last als Montag, genauso ist es im Restaurant, am
35:31
Wochenende kommen mehr die Lust haben Essen zu gehen als Montag,
35:34
wobei vielen Ruhetag ist. Und genau das ist der Punkt ne
35:38
diese. Effiziente Verteilung von
35:40
bestellen, verhindern von Überlastung was du gerade
35:42
meintest und das kann man halt mit diesem Küchenbeispiel mit
35:45
dem Restaurantbeispiel einfach auch gut verdeutlichen.
35:48
Am Ende ja. Ja, ich mein, wenn du das ganze
35:50
jetzt noch mal ein bisschen auf, auch auf auf was technischeres
35:53
münzt und ich hatte ja vorhin zum Beispiel E Commerce gesagt,
35:58
es gibt ja auch bei einem riesengroßen E Commerce
36:00
Anbieter, gibt es ja auch so Special Tage ne wo dann eben
36:04
besondere Angebote über den Tisch gehen.
36:09
Und da ist ja auch selbst bei bei denen selber.
36:13
Sozusagen ist es ja bekannt, dass einfach die Last, also dass
36:17
einfach viel mehr Leute dann auf die Seite gehen, auf der Seite
36:21
kaufen und so weiter und das ist ja genau zum Beispiel, das kann
36:23
man sich gut vorstellen, weil du hast beispielsweise als Service
36:26
hast du zum Beispiel als als als Micro Service hast du zum
36:30
Beispiel die Website, wo du nach den Produkten gucken kannst.
36:35
Wenn du es jetzt aber zur Bezahlung geht, hast du ein
36:37
Bezahlservice. Das heißt, du musst dann immer
36:39
gucken und wenn du es richtig stark machst, dann hast du ja
36:42
zum Beispiel in der Zeit, wo du auf einmal vielleicht sehr, sehr
36:45
viele User auf deiner Seite hast, die Sachen in den
36:49
Warenkorb packen und so weiter aber noch nicht bezahlen, weil
36:52
sie sich denken, ich gucke erstmal noch mal.
36:54
Ich packe mir schon mal was rein, vielleicht packe ich
36:55
hinterher wieder was raus, dann hast du vielleicht erstmal zu
36:58
einem bestimmten Zeitpunkt am Tag hast du eine richtig eine
37:01
richtig große Last auf deiner Website beispielsweise
37:03
sozusagen, ich nenne es jetzt mal Produkte.
37:05
Produkte anschauen, so dieser Service ne und dann musst du in
37:10
der Stelle ne. Bei deiner Orchestrierung siehst
37:13
du OK load balancing, ich muss quasi mehr Instanzen von meiner
37:16
Website hochfahren, damit genügend Leute auch flüssig sich
37:19
diese Produkte angucken können. Wenn du jetzt aber an einem
37:22
anderen Tageszeitpunkt zum Beispiel ne keine Ahnung
37:25
Feierabend bei vielen Leuten die denken sich so so und jetzt
37:28
kaufe ich mal ne Runde. Da musst du vielleicht den
37:30
Bezahlservice hochskalieren und mehr Instanzen von deinem
37:33
Bezahlservice machen, damit auch wirklich nicht irgendwie eine,
37:36
sagen wir mal, eine Zahlung untergeht, weil es ist ja nichts
37:39
schlimmer, als wenn du sagst, okay, jetzt möchte ich bezahlen,
37:42
Herr lädt, was passiert hier gerade, habe ich jetzt bezahlt,
37:44
habe ich nicht bezahlt, kriege ich mein Produkt oder kriege ich
37:46
es nicht so ne und damit so was halt eben nicht auftritt, kannst
37:49
du dann halt genau durch deine Orchestrierung ne genau diese.
37:54
Verschiedenen zu verschiedenen Zeiten verschiedene
37:56
Microservices halt eben. Balancen beispielsweise.
38:00
Genau, ja, sehr gutes Beispiel. Ich mein ich, man kann das ja
38:06
auch, um noch mal diesen VM vergleich zu machen, ne also
38:09
wenn du jetzt zum Beispiel sagst lass uns n ganz einfaches
38:14
Beispiel nehmen, also zum Beispiel E Commerce ja OK.
38:18
Gehen wir mal das. Also du hast sag ich mal n
38:20
Webserver irgendwo. Ja, also jetzt zum Beispiel NOJA
38:22
SN ganz simplen Webserver E Commerce hast vielleicht jetzt
38:26
noch ja n Angular Frontend oder oder irgendwie was in Python
38:30
auch sehr beliebt und in dem Fall um das Skalieren zu können
38:35
mit der Orchestrierung wie du meintest wenn wir uns das jetzt
38:37
mal in der VM noch mal vorstellen, ne um das noch mal
38:39
klar zu herauszukristallisieren, in der VM würde das ja bedeuten,
38:46
dass. Beide Apps, ja, also der
38:48
Webserver als auch das Frontend ja in einer VM in einer großen
38:52
VM laufen müssen zwangsläufig und du ne superenge Kopplung
38:57
dadurch erzeugst. Ja, weil die immer voneinander
39:00
abhängig sind von ihren Umgebungen, auch das heißt du
39:03
kannst es nicht unabhängig skalieren, du kannst da nicht so
39:06
was machen wie. Ja, warte mal.
39:08
Jetzt sind aber viele auf dem Shop.
39:09
Ja, also viele auf unserem Frontend unterwegs.
39:11
Wir brauchen jetzt mehr Instanzen, ja und dadurch hast
39:14
du halt diesen hohen Overhead oder einfach das Küchenbeispiel,
39:18
ja der der der Workload geht hoch von keine Ahnung, Spaghetti
39:24
Bolognese wird ganz ganz viel bestellt gerade, aber ich hab
39:26
jetzt noch ne Pizza da drin scheißegal schmeiß die Nudeln
39:28
drauf die du warm. Gemacht hast.
39:31
Das das funktioniert ja nicht am Ende.
39:33
Deswegen hast du es da, Pizza. Genau, stimmt genau, dann musst
39:37
du einfach die Karte kurz und mit Containern kannst du das
39:41
halt machen, weil dann hast du halt um das Beispiel noch mal
39:43
von dir aufzugreifen, denn separates Image für zum Beispiel
39:46
den No JS Server und für die Engula für das Frontend oder
39:49
Python, wie auch immer, so kann man sich ja aussuchen und du
39:52
kannst sie unabhängig voneinander deployen, du kannst
39:55
sie unabhängig voneinander skalieren und kubanet ist jetzt
39:58
als Beispiel für deine Orchestrierung, erkennt dann zum
40:01
Beispiel die Last und kann dann in dem Fall Pods mehr Pods
40:05
starten für. Frontend beispielsweise und du
40:07
hast halt dieses automatische Management dann und das ist halt
40:10
ne unfassbar geile Sache, die es wert ist sich anzugucken und wo
40:17
halt unfassbar viel auch drauf basiert, einfach heutzutage,
40:19
damit es überhaupt so läuft wie wir es kennen.
40:22
Ja ja genau. Also wenn man das jetzt ganze
40:25
das Ganze noch mal zusammenfasst, wir haben es ja
40:27
jetzt auch relativ. Ausführlich beleuchtet das
40:30
Ganze. Genau machen wir einen Rapper
40:32
jetzt hier. Und wenn man sich jetzt mal
40:34
anguckt, okay, was sind eigentlich so denn am Ende die
40:37
Vorteile von containerisierung containerisation nenn es wie du
40:41
magst. Also einmal hast du einheitliche
40:44
deployments, weil du halt eben immer die gleiche Konfiguration
40:47
für dein Image beispielsweise hast.
40:49
Für dein nennen wir es mal Docker Image.
40:53
Es ist auf jeden Fall plattformunabhängig.
40:56
Du hast ne riesengroße Ressourcenersparnis.
40:59
Der Start deiner Anwendung, deines Microservices, was auch
41:04
immer geht es sehr sehr schnell vonstatten.
41:06
Du hast ne oder kannst ne bessere Auslastung gewährleisten
41:10
durch deine Orchestrierung und wie ich schon meinte,
41:14
Microservices unterstützt halt eben auch Microservices und
41:17
ermöglicht eigentlich auch ne effiziente sagen wir mal CICD
41:22
Pipeline im. Gerade im def Ops Kontext also
41:25
auch eine hohe Automatisierung, was natürlich auch im Def Ops
41:29
Bereich sehr wichtig ist, sollte man sich quasi immer Fragen im
41:32
Def Ops Bereich, was kann ich automatisieren wenn ich das
41:36
schon mehrmals manuell gemacht habe oder wie kann ich es
41:40
automatisieren und ist halt einfach mal wenn man es so sieht
41:44
eine Grundlage für diese ganzen Cloud native Architekturen.
41:48
Ich glaube ohne wird es schwierig.
41:53
Ja. Und es verhindert die Spaghetti
41:56
auf der Pizza, haben wir festgestellt.
41:57
Ja, aber manche mögen. Manche, manche wollen sowas ja,
42:05
ja, ich glaub dann haben wir das Thema echt gut abgehakt.
42:08
Hat mir mega Spaß gemacht fab ich find das auch super
42:10
spannend, ich steh total auf das Thema.
42:14
Sehr spannend, hat Spaß gemacht. Vielen Dank dafür.
42:15
Danke dir auch Tino und dann würde ich sagen, kommen wir zum
42:18
Ende, wenn es noch Themenwünsche gibt, wie zum Beispiel auch
42:22
Gegenüberstellungen, was wir schon meinten im Micro Services
42:24
gegen Monolithen, neue versus alte Infrastrukturen, dann
42:30
schreibt uns ganz gerne einfach über die Mail Instagram,
42:33
Discord, wie auch immer, die Links dazu gibt es auf jeden
42:36
Fall den Show Notes. Auch wenn ihr andere Themen
42:39
habt, die Euch irgendwie interessieren, immer raus damit.
42:41
Wir können auf jeden Fall gerne ne Podcast folge drüber machen.
42:45
Ja und ansonsten wird es uns mega mega mega freuen wenn ihr n
42:49
kleines Feedback, also ne Bewertung für den Podcast da
42:52
lässt und vielleicht auch einfach den Podcast empfiehlt
42:56
einfach 2 Freunden oder Freundinnen und denkt natürlich
42:59
daran um keine Folge zu verpassen, den Podcast natürlich
43:02
auch zu abonnieren. Ansonsten bleibt mir nichts
43:06
anderes zu sagen als Tino. Ich werde mir jetzt erst mal was
43:09
zu essen gönnen, ne schöne Pasta Pizza.
43:13
Ne schöne Pasta Pizza. Also ich hoffe ihr habt jetzt.
43:19
Auch. Ordentlich Hunger und könnt was
43:20
essen und wir hören uns einfach nächste Woche wieder in der
43:23
neuen Folge deine Coding war das.
43:25
Gemeinsam besser.