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