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.