# Micro-VMs, AI Engineering, and Cloud Infrastructure Strategy

**Podcast:** Engineering Kiosk
**Published:** 2026-08-11

## Transcript

Willkommen zu einer neuen Episode vom Engineering Kiosk Podcast.
Heute geht es um eine Technologie, die du ziemlich sicher ständig benutzt, auch wenn du vielleicht nicht jeden Tag darüber nachdenkst.
Wir sprechen über Container, Micro-VMs und die Frage, was da technisch eigentlich wirklich passiert.
Wie viel Isolation liefern Container tatsächlich?
Wo hört ein Container auf und wo fängt eine virtuelle Maschine an?
Und warum reden alle plötzlich über Micro-VMs?
Firecracker und ultrakurze Bootzeiten.
Dafür haben wir einen Gast, der nicht nur irgendeine Meinung dazu hat, sondern das Thema seit Jahren mitbringt.
Sebastian Pahl, Co-Founder der Firma hinter Docker und arbeitet heute wieder bei Cloudflare an Container-Plattformen.
Mit ihm gehen wir einmal runter bis an die Betriebssystemschicht.
Wir sprechen über Namespaces, C-Groups, LXC, RunC, OverlayFS, Systemd und darüber...
warum Docker damals viel mehr war als nur ein hübsches CLI für bestehende Linux-Features.
Außerdem wird es ziemlich praktisch.
Sepp erzählt, wie er ein eigenes Init-System in Rust gebaut hat, warum AI ihm dabei massiv geholfen hat und wie man Boot-Zeiten von mehreren Sekunden auf wenige hundert Millisekunden drücken kann.
Wenn du also verstehen willst, warum Container nicht einfach nur Container sind, dann bist du hier genau richtig.
Wir springen direkt rein.
Los geht's.
Viel Spaß.
Heute sprechen wir mal über eine Technologie, von der man behaupten kann, dass sie die halbe Cloud antreibt.
Und wenn ich von Cloud spreche, meine ich jetzt nicht nur irgendwelche Server bei Amazon oder Google, sondern sehr wahrscheinlich auch in deinem Home Lab oder auf deiner On-Premise-Software in deinem eigenen Datacenter Co-Location oder von mir aus auch auf deinem Laptop selbst.
Denn wir sprechen mal über Container und da ist der Platzhirsch eigentlich Docker, würde ich mal sagen, seit ein paar Jahren.
Und darüber haben wir auch schon in vorherigen Episoden, wie zum Beispiel in Episode 46, welches Problem löst eigentlich Docker gesprochen?
Oder vielleicht ein Layer tiefer in Episode 48, der Layer unter Docker-Container, die Kubernetes-Container-Runtime-Interface, Cryo und die Open-Container-Initiative.
Das war alles Ende 2022 und seitdem ist natürlich auch noch eine ganze Menge passiert, auch was neue Bereiche wie Micro-VMs und so weiter angeht.
Und da ist halt oft mal die Frage, die ich mir so stelle, wer hat eigentlich tiefes Verständnis von der ganzen Thematik?
Also wie viel Isolation geben Container und Micro-VMs eigentlich?
Und ist ein Container eigentlich gleich ein Container?
Das sind alles so Fragen, die kann man sich natürlich heutzutage mit der KI auch irgendwie durchprompten und dann...
macht man da irgendwie Rechercheaufträge und aber auch dieses ganze Umfeld entwickelt sich so dermaßen schnell.
Und ich bin durch Zufall, das war wirklich Zufall, durch meinen Arbeitgeber auf unseren heutigen Gast gekommen.
Denn in einem internen Chat-Channel wurde announced, dass er wieder bei Cloudflare ist.
Deswegen begrüße ich mit großer Freude Sepp.
Hallo.
Hallo, danke, dass ich da bin.
Jetzt habe ich dich mit Sepp vorgestellt und mein Job in diesem Podcast ist immer, die Gäste vorzustellen.
Du beschreibst dich auf LinkedIn als Founder, Hacker und Bilder.
Finde ich schon mal sehr sympathisch.
Und Founder trifft es wohl und das Wort Docker auch, weil du warst nämlich 2008 Co-Founder von der Firma, die hinter Docker steht, die das Docker-Produkt zumindest rausgebracht hat.
Meines Wissens nach hieß sie damals .cloud, ist das korrekt?
Ja, genau.
Ja, ja, so hieß sie, als wir in Frankreich eingefallen waren.
Da hast du dann natürlich auch den ganzen Containerzyklus mitgemacht.
Und wenn man sich mal deine LinkedIn, wie soll man sagen, professionelle Karriere, wie es da heißt, anschaut, dann habe ich so das Gefühl, du beschäftigst dich dein ganzes berufliches Leben bereits mit Containern und ähnliches.
Denn du hast Docker mitgegründet, warst dann bei Cloudflare, später bei Mesosphere.
Mesosphere, damit habe ich auch schon noch eine ganze Menge gemacht damals.
Dann bei CoreOS Red Hat.
Dann hast du OpsTrace.
Das war so ein bisschen die, ich sage mal.
Mit Ops Trace hast du dann ein bisschen Observability gemacht.
Das wurde dann von GitLab aufgekauft.
Und seit letztem Jahr bist du wieder bei Cloudflare und baust da am Container-Produkt rum.
Und da ist die erste Frage, was reizt dich nach 15 Jahren immer noch an diesem Container-Thema?
Gute Frage.
Ich habe eigentlich immer Entwickler, Tools für Entwickler gerne gemocht.
Alles Mögliche, was das Leben der Entwickler vereinfacht, mein eigenes Leben als Entwickler.
Und Container selbst sind halt eine Technologie.
die sehr interessant ist, weil ich mag es gerne, es zu vereinfachen, Software in Produktion gut laufen zu lassen und auch in einer Form zu laufen lassen, die man auch so einfach wie möglich updaten kann, verändern kann.
Und dafür sind Container ganz praktisch.
Natürlich auch ganz am Anfang war der Reiz, das so zu machen, dass Software in Produktion genauso installiert wird wie auf dem Laptop des Entwicklers.
Das war natürlich auch ein Reiztabü.
Aber ja, es ist eine Technologie, die sehr breit ist im Linux und anderen Unix-Systemen.
Ich mag sehr gerne, wenn ich selber an Sachen arbeite, so tief wie möglich ins Betriebssystem zu gehen und zu schauen, wie es funktioniert, aber dann diese Sachen zu vereinfachen.
für Menschen, die nicht so tief ins System greifen wollen.
Das hat immer Bock gemacht.
Es gab immer mal was Neues.
Außerdem Container sind ja nur eine der Sachen, woran ich gearbeitet habe.
Jetzt arbeite ich 100 Prozent derzeit an Containern und VMs und so weiter und fort.
Es ist halt interessant.
Du hast mir jetzt schon das richtige Stichwort gegeben.
Am Ende hast du VMs gesagt.
Davor hast du immer nur von Containern gesprochen.
Kannst du uns mal eine Einordnung geben?
Was du jetzt überhaupt unter Containern verstehst, ist es der klassische Docker-Container?
Ist eine VM auch ein Container?
Was ist eigentlich ein Container, was man da irgendwo so hoch schießt?
Sprechen wir da vom gleichen Container oder was gibt es eigentlich, um einfach mal eine Einordnung zu haben?
Das ist natürlich etwas, was sich auch über die Jahre sehr verändert, vermischt hat.
Aber sagen wir mal, eine virtuelle Maschine ist eine, wie es im Namen steht.
Es ist...
Eine Virtualisierung der Hardware.
Man baut eine ganze Maschine auf, die RAM hat, die PCI und die ein CPU oder mehrere hat.
Das ist, was eine VM selbst ist.
Und dann startet man den ganzen Linux-Kernel von da.
Das heißt, wenn das Betriebssystem startet, egal ob Linux oder was anderes, man startet das Betriebssystem in einer virtuellen Maschine so wie auf einem Computer.
Es gibt da natürlich...
ganz viele Details, die es machen, dass die Welt sich da auch vermischt, weil Sachen optimiert werden.
Wie kann man eine VM so bauen, dass sie so wenig wie möglich Platz nimmt sozusagen.
Aber ein Container ist da eine Attraktion höher.
In einem Container wird nicht ein ganzes OS gestartet.
Der Linux-Kernel oder der Kernel von Windows, was auch immer der Name ist, die starten da nicht.
Man teilt sich den Kernel, wenn man in einem Container ist.
Das heißt, ein Container ist einfach nur eine Art, das Betriebssystem so abzugrenzen, dass ein Prozess nicht die anderen sieht auf verschiedene Ebenen.
Wir können da noch in die Details gehen.
kann man alles ein- und ausstellen.
Aber das ist der Unterschied.
Wenn man ein Programm startet, kann man das in einem Container starten oder nicht in einem Container starten.
Aber eine virtuelle Maschine ist immer das Booten von einem ganzen Computer.
Ich habe mir immer gemerkt, beim Container sieht man die Cores zum Beispiel, 16 Cores, und bei der virtuellen Maschine sieht man die Cores unter Umständen nicht, wie man es einstellt.
Jetzt wirst du mir wahrscheinlich gleich sagen, it depends.
Das kann man vielleicht bei Container mittlerweile auch machen.
Aber das war zumindest meine Eselsbrücke immer, sehe ich die ganzen Cores, die CPU wirklich direkt oder eben nicht?
Das stimmt zum Teil.
Bei der VM wird das viel früher alles zerschnitten.
Der Computer wird viel früher in Arbeitsspeicher-CPU zerschnitten.
Bei Container ist es so, dass man dann auch diese ganzen Ressourcen wie Arbeitsspeicher und CPU teilen kann.
Und eingrenzen, man kann einem Container nur ein bisschen von CPU.
Und das wird dann alles über den Scheduler vom Kernel gemacht.
Das wird nicht dadurch gemacht, dass der Container nur ein Teil der Maschine sieht.
Natürlich gibt es auch mögliche Tricks, um es so zu machen, dass man das nicht sieht.
Aber das ist dann nicht so wichtig in der Containerwelt.
Hast du gerade geglaubt, irgendwas ist kaputt?
Ja, siehst du, so geht es mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, einen Kaffee.
Und für diese Koffeinenergie die ihr uns durch diese Kaffeespenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel, Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name, Elias, Björn, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Kaffee sponsert oder vielleicht sogar ein Kaffee-Abo wie der Fabian oder einen ganzen Monatsbedarf an Kaffee wie der David, wir schätzen jeden einzelnen Kaffee und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir und jetzt geht es auch schon wieder zurück zur Episode.
Während du gerade gesprochen hast, habe ich die Frage recherchiert, wie nennt man eigentlich den Kernel von Windows?
Und ja, es heißt auch Windows NT-Kernel.
Das ist also immer noch der, der aktuell verwendet wird.
Jetzt haben wir auf der einen Seite, auf dem einen Extrem den Container.
Auf der anderen Seite des anderen Extrem die klassische VM.
Und ich habe es ja schon im Intro gesagt, es gibt auch den Begriff Micro-VM.
Haben da einen Container und eine klassische VM geheiratet und ein Kind gezeugt und das ist die Micro-VM?
Oder was ist eine Micro-VM und wie unterscheidet eine Micro-VM sich von einer klassischen VM und von einem Container?
Also ist das wirklich die Mitte?
Also es ist nicht die Mitte.
Es ist eigentlich nur ein Begriff sozusagen.
Ein Begriff, der bedeutet, ich mache eine virtuelle Maschine, um ein Programm zu starten.
Container braucht da überhaupt nicht zu kommen.
Container ist etwas, was man starten kann.
Aber die Mikro-WM ist einfach nur ein Begriff, den die Industrie gefunden hat.
Keine Ahnung wer, keine Ahnung warum.
Um zu sagen, ich werde jetzt nicht das Betriebssystem mit allen drum und dran starten, sondern ich werde nur genau das starten, was ich brauche, um so schnell wie möglich meinen Workloads zum Laufen zu bringen.
Und natürlich ist es gekommen, parallel zu Containern, weil man dann sagte, okay, ich habe jetzt einen Docker-Container, ich habe jetzt ein Image, was alles hat, um etwas zu starten.
Also will ich drumherum nur so wenig wie möglich starten.
Ein Beispiel von Mikrocontainern, den alle Menschen benutzen, die macOS 10 und Docker benutzen.
Jedes Mal, wenn man auf macOS 10, 10 heißt ja nicht mit 10, ist egal.
Jedes Mal, wenn man diese da startet, startet es eigentlich eine ganze Linux-VM.
Und dann startet der Container drin.
Deswegen fühlt es sich so anders an, Docker auf Mac OS oder sogar auf Windows zu benutzen als auf Linux.
Denn auf Linux wird einfach nur der Prozess, der im Container, direkt gestartet.
Auf Windows und auf Mac OS wird eine sogenannte kleine VM drumherum gestartet.
Und die hat dann nun Kernel nur das, was sie braucht, um halt dieses Container-Image zu starten.
Und nicht den ganzen Rest, nicht den ganzen grafischen Interface oder was auch immer noch Prozesse laufen würden auf einem Server.
Jetzt hattest du gesagt, beziehungsweise habe ich das so rausgehört, bei einer klassischen virtuellen Maschine hat die virtuelle Maschine selbst ihren eigenen Kernel.
Deswegen bootest du ja den ganzen Kladderadatsch mit hoch.
Und in der MicroVM genauso.
Okay, das war nämlich die nächste Frage, weil Container teilen ja den Host-Kernel.
Und bei einer MicroVM, die bringen ihren eigenen Kernel mit.
Welche Sachen hat man denn dann weggelassen?
von der klassischen VM, dass die Boot-Up-Time zum Beispiel relevanter ist oder schneller ist?
Da ist es natürlich kompliziert, weil es tausend verschiedene, vielleicht nicht tausend, aber es gibt ganz viele verschiedene Implementationen davon.
Die ganz berühmte ist die Firecracker und Cloud Hypervisor, sind die zwei großen virtuellen Maschinen.
Die bauen natürlich auch auf Codes.
auf, die es schon in Linux gibt mit KVM und alles.
Aber für diese zwei Hypervisors sozusagen, der Hypervisor ist das, was ein WM zum Laufen bringt, mit dem ganzen Hardware-Tooling, was die Plattformen heute haben und was die Kernels auch haben.
Ich glaube, das will ich jetzt nicht als konkret sagen, also nimmt das so, wie ChatGPT es sagen würde.
Es könnte Fehler drin sein.
Aber Firecracker wurde damals von Amazon gemacht, um Lambda so schnell wie möglich diese Funktion zu starten, die man dann im Cloud aufruft.
Aber die Idee ist, so wenig wie möglich zu booten, um dann nur ein Stück Python zu starten.
Stell dir vor, ein Linux-Betriebssystem, was startet und du reißt alles raus, was nicht gebraucht wird, um eine spezifische Workload zu starten.
Wenn das meiste im Container läuft, dann brauchst du eigentlich nur den Kernel zu starten.
Den brauchst du ja.
Du willst ja in einer virtuellen Maschine sein.
Das ist für die Sicherheit und um das wirklich ganz vom anderen Betriebssystem zu trennen.
Das nächste Ding ist Systemd.
Da kann man schon anfangen, schneller Sachen zu machen, indem man entweder nicht Systemd benutzt oder was anderes oder Systemd so konfiguriert, dass es nur das startet, was man braucht.
Es geht darum, auch den Kernel so zu konfigurieren, dass er so wenig wie möglich drin hat.
Er braucht ja die ganzen Treiber nicht.
Der Kernel braucht ja nur das, was man braucht, um so schnell wie möglich zu starten.
Viele Sachen neben Zeit, sogar ein Keyboard zu entdecken, in 500 Millisekunden oder sowas.
Nicht für alle, aber jetzt ein Beispiel von einem Treiber da.
Und jedes Mal, wenn man die Boot-Time von mehreren Sekunden oder eine Minute runterbringen will auf Hunderte von Millisekunden oder weniger, muss man sich aussuchen, was brauche ich, was brauche ich nicht.
Das ist genauso wie, keine Ahnung, ein Auto, was schnell fahren muss in der Formel 1.
Die Formel 1 hat ja auch tausend Sachen nicht, die für die Sicherheit da sind, zum Beispiel, weil sie das spezifisch getunt haben für eine Sache, da um dem Rennen rumzufahren.
Das war's.
Das ist alles, was die Formel 1 macht.
Ich kenne mich gar nicht mit Formel 1 aus.
Das ist jetzt einfach so als Beispiel.
Und so ist es auch mit Betriebssystemen und Workloads.
Ich habe mir gerade überlegt, okay, wie würde ich denn eine Micro-VM Und da kam mir dieses Projekt Linux from Scratch in den Sinn.
Linux from Scratch ist eigentlich eine Step-by-Step-Instruction, wie du deinen eigenen Custom-Linux-System baust, so nach dem Motto.
Und dann ist es ja eigentlich, sehr simpel gesagt, relativ viel Try and Error, oder?
Ich meine, ich habe einen Kernel und versuche es ans Laufen zu kriegen und dann gucke ich, dann boote ich das Ding, gucke, was fehlt, packe das da rein, repeat und mache so lange weiter, oder?
Ja, das ist genau das.
Es ist sogar noch einfacher als Linux from scratch, weil du, wenn du den Container hast, hast du ja schon ein Image, was alles, was dieser Workload braucht, zum Beispiel, wenn da C-Libraries sind, wo alles zusammen gelinkt ist oder auch, wenn es einfach nur ein statisches Programm ist.
Das ist alles erstmal ein Container-Image.
Deswegen starten MicroVM's oft im Container, jedenfalls in dem Bereich, wo ich arbeite.
Aber dazwischen, da muss man sich halt mit Linux auskennen.
Das Init bootet.
Was braucht das Init?
Das muss...
ein paar Mount-Points aufbauen, zu sagen, hey, hier ist Temp, hier ist ein paar Slash-Dev-Devices, die benutzt werden können.
Und dann muss es die Network-Interfaces, also das Netzwerk konfigurieren, damit das Netzwerk so konfiguriert ist, wie man will.
Vielleicht ein paar PCI-Devices, vielleicht ein GPU, aber halt nur das, was dann dieser Workload dann braucht.
Und das kann man relativ einfach zusammenbauen, wenn man Linux kennt.
Und Linux von Scratch ist da genau so, habe ich es auch gelernt.
Ich meine besonders, wenn du dann deine Umgebung ja auch kennst.
Du hast ja gerade Netzwerk angesprochen.
Also wenn du wirklich weißt, auf welche Hardware du läufst, auf wie deine Umgebung aussieht und so weiter und so fort, dann kannst du es ja richtig tailern.
Und die VM macht es ja noch einfacher, weil die VM sagt ja hier, das ist immer dasselbe.
Wenn Firecracker oder Cloud Hypervisor auf dieser Plattform läuft und du dann eine andere 64-Bit-OS starten kannst, da ist es ja immer dasselbe.
Das heißt, du kannst...
einmal das Ding bauen für das, was du brauchst.
Nicht alle brauchen Micro-VMs.
Das ist ein spannendes Thema und ich mag es und so.
Aber im Endeffekt brauchen das wirklich nur Sachen, die sehr viel Scale brauchen oder sehr viel auf eine Maschine packen wollen und so weiter und so fort.
Es geht darum, weniger RAM, schneller zu starten, weniger alles zu benutzen.
Zum ganzen Workload-Management kommen wir hoffentlich noch, wenn wir das überhaupt noch unterkriegen, weil wir haben irgendwie so viel Content für diese Episode.
Zumindest bin ich sehr neugierig.
Es tut mir leid, dass ich dich jetzt mit Fragen löchern werde.
Das ist alles okay.
Jetzt gibt es in diesem ganzen Space, wenn ich Container oder ähnliches bei Wikipedia eingebe, kommen mir die zwei Buzzwords Namespaces und C-Groups auch relativ schnell auf meinen Screen.
Kannst du mir diese beiden Begriffe jetzt...
fokussieren wir uns einfach mal auf Linux und nicht irgendwie auf FreeBSD oder irgendeinem ähnlichen Betriebssystem.
Die C-Groups und Namespace gibt es sowieso nur auf Linux.
Ich kann keine Ahnung, wie sie woanders heißen.
Wieder was gelernt.
Kannst du mir diese beiden Begriffe einmal einordnen in diesem Ecosystem?
Ja, ich werde es auf Deutsch versuchen.
Also Namespace und C-Groups sind eine Art für den Kernel, den Linux-Kernel, die Maschine so aufzuteilen, wie man will.
Wenn man ein Linux ist zum Beispiel, hat man Zum Beispiel Mount Points.
Was ist ein Mount Point in Linux?
Man steckt irgendein Device rein und dann mountet man dieses Device in gewisse Verzeichnisse.
Und dann sieht man das da, also ein USB-Schlüssel.
Aber es gibt viel mehr Sachen, die Mounts sind in Linux.
Slash ist auch ein Mount Points.
Es ist der erste.
Und dann gibt es Slash Dev, der ist besonders.
Und Slash Sys, der ist auch besonders.
Mount Namespaces sind eine...
ein Weg, ein Programm zu sagen, du siehst nur diese Mounts, die ich will.
Das heißt, ein Namespace ist für Sachen wie Netzwerk, Mounts, es gibt mehrere andere Namespaces, die jetzt plötzlich aus dem Kopf weg sind.
Aber zum Beispiel Mount und Netzwerk sind ganz simpel zu verstehen.
PID ist auch sehr einfach zu verstehen.
PID, was ist ein PID?
Es ist die Nummer vom Prozess, der da läuft es im Linux-Betriebssystem.
Das heißt, jedes Mal, wenn ein Programm startet, kriegt er eine neue PID.
Die PID 1 ist init und dann von da aus gibt es immer eine neue PID.
Ein PID Namespace bedeutet, ich starte ein Programm und ich tue das in einem sogenannten PID Namespace.
Das heißt, wenn er dann PS macht, um zu sehen, welche Programme da auf dem Computer laufen, sieht er nur das, was in seinem Namespace ist, nicht was draußen herum ist.
Dasselbe gilt für Mount, dasselbe gilt für Netzwerk.
Das Netzwerk-Namespace wird so gemacht, dass man ein Netzwerk baut nur für ein oder mehrere Container auf der Maschine.
Und die sehen dann nicht den Rest, wenn man da nichts, außer man baut da etwas so auf, dass man da Routing hat zwischen diesem Netzwerk.
Das heißt, jeder Container in seinem Netzwerk-Namespace kann eine IP-Adresse haben.
Die können sogar dieselbe haben.
Das ist eigentlich egal.
Und wie das in Linux aufgebaut ist, ist, die Namespaces kann man entweder nur für einen Container bauen oder man kann sie teilen mit mehreren.
Da wird es komplex.
Da kann man sich halt wie Lego das so zusammenbauen, wie man will.
Diese Hierarchie von wer sieht was auf dem Computer.
Dann gibt es auch den User Namespace, um zu sagen, Roots in diesem Container ist nicht Roots außerhalb vom Container.
Der hat seine eigene User-ID, die...
drinnen zwar null ist, aber draußen außerhalb des Containers nicht root ist.
Das ist Namespacing.
Und dann C-Groups ist ein bisschen wie Namespaces, nur da geht es darum, die Ressourcen der Maschine zu teilen.
Wie viel Arbeitsspeicher, wie viel CPU, wie viel Network-Quota und so weiter und so fort.
Und wenn man das alles zusammenpackt, kann man Sachen wie Docker bauen.
Oder LXC oder was auch immer an Container-Systemen man will.
Oder man benutzt gar nichts und man ruft diese ganzen C-Groups selber auf und man baut sich selber sein System.
Das machen weniger Menschen, aber warum nicht?
Das heißt, es gibt auch ein Mapping, weil du gesagt hast, im Container gibt es andere Pits als draußen in der Welt.
Das heißt, die werden umbenannt sozusagen oder so wie ein Simlink quasi auf was anderes gemappt.
Genau.
Ungefähr so.
Also der Kernel ist der, der das alles selber managt.
Er weiß dann, in welchem Namespace was ist und was erlaubt ist, mit wem zu sprechen.
Wer darf auf dieses Netzwerk zugreifen?
Welcher User ist wer, wenn man das ummappt?
Man kann sogar viel mehr am Mapping arbeiten.
Man kann zum Beispiel einen Mount machen, der außerhalb einem User gehört und drinnen einem anderen User gehört.
So kann man zum Beispiel sehr einfach lokal indem man zum Beispiel seinen Code und seinen Editor und seinen AI-Agents in einem Verzeichnis hat, was dann geteilt ist mit einem anderen Container zum Beispiel.
Oder andersrum, man kann das Ganze in einem Container laufen lassen, aber es ist geteilt mit dem Post.
Aber ja, das ist alles von Kernel gemanagt.
Wir sind ja nicht in einer VM.
Also es ist viel granularer, sagt man das auf Deutsch?
Du kannst ruhig auch, wir sind hier in der Technik, also ich bin mir nicht sicher, ob es für manche Begriffe auch deutsche Übersetzung wirklich gibt.
Ich versuche es, ich habe immer Bock.
die richtigen Begriffe zu benutzen.
Wir müssen jetzt aber nicht alles Eindeutschen des Eindeutschens wägen.
Also von daher.
Ey, sonst hätte ich für Sea Group Nails nicht sowas gefunden.
Das habe ich jetzt nicht versucht.
Das wäre zu komisch.
Namensräume.
Namensräume, ja genau.
Das wollen wir nicht.
Genauso wie ich werde Sackfolt sagen und nicht Speicherzugrutsfehler.
Der ist mir zu komisch.
Mit Speicherzugriffsfehler müsste ich aber auch immer so, da müsste ich auch in meinem Gehirn wirkliche Sachen verdrahten, um daraus zu kommen auf SegFold.
Okay, da bin ich aufgewachsen mit, bis ich meine Sachen alle auf Englisch getan habe.
Aber wenn ich das jetzt alles richtig verstanden habe, sind die Namespaces also eigentlich die Isolierung, also was darf ich sehen oder wer darf was sehen?
Und die C-Groups ist so das Ressource Management, also wie viel darf ich nutzen, wie viel Zitulierung für RAM und so weiter.
Man kann Namespaces in Namespaces bauen, man kann C-Groups in C-Groups, man kann eine ganze Hierarchie aufbauen, von wer es erlaubt, zu was und dann ist es alles vom Körner gemanagt.
Ich mag dein Lego-Beispiel, das fand ich sehr interessant.
Aber genau dieses Lego-Beispiel, und du hast mir auch schon das nächste Wort in den Mund gelegt, und zwar LXC.
LXC steht meines Wissens nach kurz für Linux-Container oder Container.
Singular Plural, schwierige Thematik.
Aber ich frage mich gerade, diese ganze Technologie, Namespaces, C-Groups, LXC, das war ja nicht neu.
Und dann kam Docker.
Meine Frage ist, was hat Docker anders gemacht?
Also hat Docker die ganze Sache einfacher gemacht?
Provokativ könnte man fragen, war es eine CLI, UI auf dieser ganzen komplexen Technologie?
Also jetzt ist es wahrscheinlich was ganz anderes.
Ich meine, wir sind aber auch schon ein paar Jährchen später.
Wie siehst du das?
Die erste Version von Docker hat LXC benutzt, um Container zu starten.
Nur erst danach wurden RunC und ContainerD und die ganzen anderen Teile des Ecosystems aufgebaut, als Kubernetes auch in die Welt kam und so weiter und so fort.
Am Anfang gab es, ja, C-Groups, Namespaces und LXC war ein Programm, was C-Groups und Namespaces benutzt hat.
Um etwas zu machen, was viel näher an FreeBS DJs ist, und zwar, ich starte jetzt ein Init und starte ein ganzes Sub-OS sozusagen, da ist nur der Kernel derselbe.
Aber im Endeffekt waren es immer noch, wenn du reingehst, sah es aus wie eine VM sozusagen.
Und du musstest dir dieses File System, wo das ganze OS drin ist, zusammenbauen.
Du kannst einfach eine Debian-Image runterladen und die da extrahieren und von da booten.
Aber ein Update würde bedeuten, reinzugehen und App-Update zu machen.
Docker hat zwar Elixit benutzt, aber was wirklich kam, ist nochmal das Docker-File-Format und ein Format, um zu sagen, hier ist ein Rezept, nicht die Endversion, sondern ein Rezept, was Docker nutzen kann, um diesen Container zu bauen.
Natürlich kommt da auch noch die ganze Docker Hub und Caching und Runterladen, das kam danach.
Aber dieses Rezept ist das, was du eigentlich teilst.
Wenn jemand ein Docker-File hat und die ganzen Zugriff auf die ganzen Sachen, die dieser Docker-File benutzt, kannst du dann ganz einfach mit einem einfach nur Docker-Bild dieses File-System aufbauen.
Und nicht nur aufbauen, sondern Docker hat es auch so gemacht, dass zu sagen, hey, brauchen wir überhaupt ein ganzes Init mit Cron?
was auch immer noch, was das startet oder brauchen wir einfach nur die Workload starten, die der Container will.
Und das ist auch der Unterschied zu Sachen wie Alexi.
Alexi wurde zwar am Anfang benutzt, aber es wurde benutzt, um dieses OS zu starten und um genau das zu starten, was man will.
Das heißt...
Klar kannst du ein In-It starten in einem Docker-Container, aber die meisten starten einen Python-Server, eine Datenbank und starten dieses Programm direkt und wollen nur das zum Laufen haben und nicht den Rest.
Und diese Datei und das so zu machen, dass du ganz einfach diese Sachen teilen kannst mit jemand anders, benutzen und dass du zum Beispiel Wenn du lokal entwickeln willst, eine Datenbank wie Postgres benutzen willst oder Redis und du musst nicht mehr nachdenken, wie installiere ich das erstmal jetzt.
So war das ja vorher.
Jetzt muss ich erstmal lesen, wie man das Ding zum Laufen bringt.
Wie lasse ich das hier zum Laufen?
Wie lasse ich das so zum Laufen, dass es mit dem Rest meines Sachen läuft?
Heutzutage macht man das viel weniger mit Sachen wie Docker und Docker Compose.
Man startet einfach den Postgres-Container und fängt an zu arbeiten.
Ist der dann perfekt bereit für Produktion?
Nicht unbedingt.
das soll er ja in diesem Moment nicht.
In diesem Moment soll er dem Entwickler helfen, sofort anfangen zu arbeiten an dem, was er arbeiten will und nicht an dieser ganzen Sidequest-Geschichte, wo man nur plötzlich, ja, jetzt muss ich lernen, wie meine Daten macht.
Und das ist die Config-File, die meine Firma benutzt.
Ja, die Kontrolle, ach, das funktioniert nicht.
Ja, weil lokal müssen wir das ändern und so weiter und so fort.
Das ist einer der Beispiele, warum Docker anders ist.
Es ist so schön, dass du das alles so automatisch erwähnst.
LXC wurde ursprünglich verwendet und die C-Groups, weil ich habe das immer so erlebt, besonders von den Gegnern von Docker, so von den klassischen...
Sys-Admins, muss ich jetzt ganz ehrlich sagen, die das meistens so gebracht hat.
Ja, weil C-Groups gibt es schon seit Jahrzehnten und das Docker macht ja gar nichts besser und LXC ist eigentlich viel besser als Docker.
Also das sind immer so die Streitgespräche.
Es ist schön, dass jetzt von dir das einfach als, ja, schön zusammen in einen Bulk geworfen wird und doch hat man voneinander gelernt und verwendet.
einander und so weiter ist eigentlich ganz cool zu hören, wie das alles zusammenwächst eigentlich dann und dass es nicht entweder oder ist und das ist durchaus andere Sachen.
Für jede Technologie gibt es immer Menschen, die sagen, man muss ja nur das lernen, man muss ja nur das machen.
Ja, aber kann man das?
Ja, ich habe es selber gemacht, weil ich Bock hatte.
Aber nicht alle, der Frontend-Entwickler will doch jetzt nicht diesen ganzen Zeugs machen und es gibt Frontend-Entwickler, die das machen wollen, aber es gibt viele, die es nicht machen wollen.
Also das ist der Unterschied.
So ist es.
Für alle Technologien.
Oh, wieso sollte ich das benutzen?
Einfach einen FTP-Server aufbauen.
Aha, einfach einen FTP-Server.
Na, geil.
Aber wenn wir jetzt mal das Rabbit Hole, das Container Rabbit Hole, ein bisschen weiter nach unten gehen, du hast ja schon erwähnt, Namespaces und da gibt es Filesystem, wird da gemappt.
Jetzt klassisch, wenn ihr jetzt zum Beispiel einen Docker-Container oder so habt, ließe ich ganz oft dieses Overlay-FS-Filesystem.
Warum?
Brauche ich da dazwischen noch überhaupt irgendwas oder ist das nur ein anderer Name für sowieso meinen Namespace?
Was ermöglicht mir so etwas dazwischen noch?
Overlay ist ein Copy-and-Write-File-System.
Das ist eigentlich nur eine Optimierung.
Docker funktioniert mit Overlay, BetaFS, ZFS, DevMapper, alles, was so Copy-and-Write-Möglichkeiten haben.
Da geht es nur darum, es so zu optimieren, dass dieses Docker-Image, was alle immer runterladen, wir haben vom Docker-File gesprochen, aber im Endeffekt benutzen viele Docker, indem sie nicht mal das Ding bauen, sondern sie ziehen ein ganzes Image runter.
Und das Image, das Docker-Image, das ist auch eine Sache, die Docker, sagen wir mal, verfeinert hat, ist es so aufzubauen, dass jede, wenn man einen Docker-Container, falls es denn baut, dann baut man eine Schicht nach der anderen auf.
Das heißt, wenn man einen Docker-File durchliest, um es zu vereinfachen, jede Linie drin ist eine neue Schicht.
Und diese Schicht wird dann installiert und dann wird sie komprimiert und als TAR.
Und diese ganzen File Systems sind dafür da, dass man nicht tausendmal die Sachen überschreibt und dass man einen Unterschied zwischen Read-Writes-Layern und einfach nur Read-Layern hat.
Es ist einfach nur eine Optimierung, um alles schnell zu starten und wenig Platz zu verbrauchen.
Du könntest ohne OverlayFS einfach, so wie bei LXE, alles in einem Verzeichnis tun und dann würde es auch funktionieren.
Aber im Fall von Docker will man ja diese Layer teilen und man will es so machen, dass man so viel wie möglich zwischen den Layern teilt, um weniger Platz zu benutzen und so weiter.
Also das ist nochmal was anderes.
Du hattest ja in dem ganzen Space auch mal init oder initd und systemd angesprochen.
Und das hört man natürlich immer wieder klar, besonders wenn man eben...
Linux-Bereich unterwegs ist.
Ich meine, System.de ist, glaube ich, das Management-Tool des ganzen Betriebssystems inzwischen.
Nach wie vielen Jahren Streit?
Ich glaube, da gab es zwischen System.de und was war das andere?
Weiß nicht.
Wir benutzen schon seit Jahrzehnten oder mehr System.de jetzt.
Vorher gab es halt verschiedene Inits.
Ich frage mich halt, welche Rolle spielt System.de?
Selbst im Ecosystem, weil ich glaube, du hattest auch im Vorgespräch mal erwähnt, dass System.de besser funktioniert, wenn es auf der Prozess-ID 1 läuft oder dass man es halt vielleicht als ersten Prozess starten sollte, nenne ich es mal.
Was steckt dahinter?
Warum ist das wichtig?
Warum ist System.de für ein Container-Ecosystem wichtig versus das ganze Betriebssystem?
Also wenn wir besonders sehr limitierte Ressourcen in dem Container laufen lassen, brauchen wir dann überhaupt ein Management-System obendrauf?
Also Systemd selbst ist ja mehr als nur ein Init-System.
Es ist ein ganzes Userland-Management-System für Linux selbst.
Es macht alles Mögliche.
Es hat sogar eine Implementierung von Containern mit Systemd-Ensporn, was so funktioniert wie LXC.
Hier ist ein Verzeichnis.
Starte das bitte.
Das ist Systemd-Ensporn.
Systemd...
macht auch sehr viel C-Group und Namespace-Management.
Du kannst jeden Prozess, den du mit System.de startest auf einem Linux in verschiedenen Namespaces, verschiedene C-Groups, verschiedene Insolidienungen, kannst du alles feintunen und mit System.de machen.
Natürlich macht System.de noch alles Mögliche.
Alles, was low-level DNS gibt es auch von System.de, muss man nicht, aber gibt es.
Die Zeit einstellen vom Computer.
Cron wurde ersetzt durch System.de und so weiter und so fort.
System.de selbst hat angefangen als Init-System.
Das heißt, es ist das erste Programm, was der Kernel startet.
Wenn man ein Linux-Kernel startet, startet er dann slash as bin init oder was auch immer man dem sagt.
Ja, klar kann man das umbauen.
Aber so war das früher.
Und Init war immer PID 1.
Init ist PID 1, weil Init die ganzen anderen Prozesse von Linux so managt, dass wenn ein Signal kommt, wird es gemanagt durch Init.
Also, Init und System.de managen halt alles, was da läuft.
Auch die, wenn sie zum Beispiel einen Prozess starten und ein Prozess dann stoppt und es neu gestartet werden muss, das wird alles von System.de gemacht.
Und System.de funktioniert eigentlich auch sehr gut, wenn es nicht PID 1 ist.
Man muss nur sehr viel einstellen, damit es auch nicht sozusagen den Rest der Maschine übernimmt.
Aber man kann es sozusagen sehr gut so zusammenbauen, dass man auch System.de in einen Docker-Container startet, wenn man will.
Das geht, das braucht nur Arbeit.
Das wäre jetzt gleich meine Frage gewesen, weil du es gerade angesprochen hast.
Wie blickst du auf diese Grundregel, einen Prozess pro Docker-Container?
Weil System.de würde ja dann mehrere irgendwie losstarten.
Wie handhabst du es?
Du das persönlich oder hast du da irgendwie Grundregel oder einfach, ja, wie man es halt will?
Ich habe, wie man will.
Kommt drauf an, was man machen will.
Manche wollen Mini-VMs bauen, also Mini-Container bauen, die sich so wie VMs verhalten.
Die meisten nicht.
Wenn ich selber etwas zusammenbaue, dann versuche ich, einen Container für eine Sache zu behalten.
Manche Sachen sind komplex und brauchen mehr als nur das eine drin.
Und dann sieht man oft kleine, es gibt viele Docker-Images, die einen kleinen...
Nicht System.de, aber andere Protestmanager benutzen, um mehrere Prozesse zu starten.
Jetzt habe ich mir die Frage gestellt, oder zumindest ist das immer so ein Battle in der Industrie, was man hier und da mal liest, und zwar die Kern-KPIs Start-Up-Time bei Container und bei Micro-VMs und so weiter.
Besonders wenn du sagtest, oder du hast es glaube ich auch erwähnt, Firecracker wurde damals für AWS Lambda entwickelt.
Das glaube ich, ja.
Das ist zumindest auch meine Information, die ich über die Jahre gelesen habe.
Ich habe zumindest nichts Gegenteiliges gelesen.
Ja, auch meine Information, ja.
Ja, das ist gut.
Da sind wir uns schon mal ein.
Da haben wir ja schon Konsens.
Und natürlich, als AWS Lambda rauskam, gab es auch super viel Probleme mit Startup Times, mit kalten Startup Times und so weiter und so fort.
Und jetzt habe ich irgendwie das Gefühl, dass die Bootzeit einer Micro-VM und vielleicht sogar deine Memory-Footprint, ich sage mal so die Kern-KPIs.
da sind.
Würdest du dem zustimmen und wenn ja, was würdest du sagen, warum ist das so?
Wann brauchst du eine Micro VM?
Du willst etwas starten, du willst eine Workload starten, du willst, dass die Workload komplett unabhängig und separat und den Rest der Maschine nicht sehen kann und dass du wirklich einen hyperweise Bug haben musst, um da rauszukommen, nicht nur einen Kernel Bug.
Also das ist, was du willst.
Du willst halt Sicherheit, du willst Ressourcentrennung, die hart ist.
sozusagen, nicht durch einen Scheduler oder sowas, sondern durch hier, das ist die Maschine, die du hast, Punkt.
Obwohl selbst da in der VM-Welt wird es komplex und man kann softer Targets haben.
In manchen Fällen will man so schnell starten, wie möglich.
Ich glaube nicht, dass eine Micro VM in sich selbst als KPI, du musst schnell starten, haben muss.
Es ist nur, das ist oft, was die Menschen brauchen.
wenn sie eine Micro VM machen.
Ein Beispiel, der viel näher dran ist als alles andere, wenn man einen Docker-Container auf macOS startet und es diese Micro VM startet, es würde sich sehr schlecht anfühlen, wenn man jedes Mal 60 Sekunden warten müsste oder sogar 30, bevor man diesen Container benutzen kann.
Das würde bedeuten, dass wenn man es auf Linux benutzt, die Dinge einfach magisch sofort da sind, aber auf macOS müsste man dann warten.
Deswegen ist die KPI natürlich da.
Okay, ich starte so schnell wie möglich, denn was der Kernel da macht, ist uns eigentlich wurscht.
Wir wollen nur eine Sache starten, den Container.
Dasselbe würde ich mal sagen für etwas wie Lambda.
Du willst so schnell wie möglich deine Function Call haben.
Und vergiss erst mal Caching und Boot und WAM.
Das sind noch andere, ganz andere Optimierungen, um es noch schneller zu machen.
okay, mein Kernel startet in 200 Millisekunden, wie kriege ich es runter auf 30 Millisekunden?
Also muss ich sie schon mal vorstarten.
Das wäre dann warm versus cold.
Und für Sachen wie bei Cloudflare oder andere Sachen, so eine Sandbox, die du starten willst für AI-Agents, du willst auch, oder nicht nur AI-Agents, da willst du auch, dass du so schnell starten kannst und so wenig Ressourcen wie möglich.
Deswegen ist das eine wichtige KPIs.
Aber es ist alles am Use Case gebunden.
Und Use Case-technisch frage ich mich natürlich gerade, wurden Micro-VMs und vielleicht auch Container auch so für die Multi-Tenant-Welt erschaffen?
Weil im Endeffekt, weil die halt weniger Memory verbrauchen, Isolation bieten, könnten die natürlich sagen, okay, mit dem ganzen Cloud-Movement und besonders vielleicht sogar jetzt, wo Server halt wirklich teuer sind, beziehungsweise kaum noch verfügbar sind, weil die ganzen AI-Firmen ja irgendwie gefühlt alles aufkaufen oder aufkaufen lassen von den Hyperscalern, ist halt die Frage, Ist Multitenant der Default-Use-Case dafür, dass man die Hardware ordentlich auslasten kann dadurch?
Also Container selbst benutzen und auch selbst eine VM, die ein Container starten würde, benutzen so viel Speicher, wie das Workload einen Speicher benutzt.
Wenn die Datenbank oder ein Python-Programm drin richtig viel benutzt, wird sie so viel benutzen.
Die VM kann es dann, wenn man so eine Micro-VM startet, ist es...
natürlich sicherer für eine Multitenant wird.
Ist doch klar.
Da hast du das Beispiel mit Sachen wie Lambda oder wie andere Plattformen, wie wir bei Cloudflare auch.
Du willst, dass ein Benutzer jeden Container der Welt starten kann, ohne die Sicherheit von anderen Benutzern und der Maschinen, wo diese Container drauflaufen sollen, zu beeinflussen und zu verschlechtern.
Deswegen ist die Micro VM da.
Wenn du nicht ein Multitenant-System aufbaust, wenn du nur alleine bist.
kannst du das auch in MicroVM einbauen, aber brauchst du nicht unbedingt.
Das kommt alles von wie sicher du Sachen haben willst.
Ich meine, Linux selbst für Container ist schon ziemlich sicher.
In Natürlichkeit gibt es Kernel-Bugs und was auch immer, wie man da aus dem Container...
Man kann viel einfacher aus dem Container ausbrechen als aus einer VN.
Das bedeutet aber nicht, dass es einfach ist, aus einem richtig gut konfigurierten Container auszubringen.
Man braucht da schon einen Bug.
Ja, es ist wichtig, um sicher Multitenants zu machen.
und verschiedene Benutzer auf denselben Maschinen zu laufen zu bringen.
Jetzt hattest du Cloudflare schon erwähnt.
Nur nochmal für alle Hörerinnen, das ist jetzt hier keine Cloudflare-Werbung, sondern da wird einfach nur die Erfahrung, die selbst gemacht hat, natürlich auch geteilt und angewandt und so weiter und so fort.
Und zufälligerweise arbeiten wir beide für die gleiche Firma.
Aber du arbeitest jetzt bei Cloudflare am Container-Produkt.
Und im Vorgespräch hattest du mir ein bisschen was erzählt, dass du oder eins deiner letzten Projekte, oder vielleicht sogar ersten, als du wieder da bist, war, dass du ein Custom-Init-System geschrieben hast, um halt auch diese besagte KPI von Bootzeit, ich sag mal, etwas nach unten zu drücken.
Kannst du mal erklären, was du da gemacht hast, beziehungsweise was das Initialproblem war und wie du es angegangen bist?
Weil so ein Custom-Init-System, ich weiß nicht.
Ich habe zwar viel Software geschrieben, würde ich mir aber ehrlicherweise jetzt gerade nicht so zutrauen.
Ja, wir haben eine Container-Plattform und wie alle Container-Plattformen, wollen wir, dass sie so schnell wie möglich starten und so wenig wie möglich rammen und auch Platz auf der Festplatte.
Und eine der Sachen, die gemacht werden konnten, war zu sagen, hey, lass uns nicht System.de benutzen.
Lass uns mal, jedenfalls das war mein Vorschlag, das ist auch keine brandneue Idee von mir, das machen andere auch.
Nur in diesem Fall gibt es wenig, es gibt wenig Open-Source-Init-Systeme, die nur an das angepasst sind, wie du die du willst.
Ich hätte was anderes nehmen können.
Aber in diesem Fall, auch mit der Hilfe von AI sozusagen, du brauchst ein paar Sachen.
Erstmal musst du Linux ziemlich gut kennen.
Du musst wissen, was brauche ich, um jeden Container der Welt zu starten.
Zweitens, du brauchst diesen Verständnis.
Dann brauchst du Zeit.
Zeit und Hilfe.
In meinem Fall, Zeit hatte ich, aber die musste komprimiert werden.
Und da ist da, wo AI mir ziemlich viel geholfen hat.
Denn ich wusste genau, was ich wollte.
Ich wusste genau, was ich brauchte zum Booten.
Ich habe es ein bisschen erwähnt am Anfang vom Podcast.
Du willst deine Mounts, du willst dein Netzwerk, du willst...
In unserem Fall haben wir noch ein paar andere Sachen, die wir da drin laufen haben wollen bei Cloudflare.
Diese ganzen Custom-Sachen will ich...
in einem Paket bauen, das so klein wie möglich und genau nur das macht, was wir brauchen.
Und das habe ich in Rust geschrieben und ich konnte das Team dazu überzeugen, das zu machen, weil es halt nicht mehr ein Jahresprojekt ist, sondern mit AI viel einfacher.
Das bedeutet nicht, dass die AI das einfach rauspumpt und es funktioniert einfach sofort.
So funktioniert eigentlich gar nichts mit AI.
Aber in meinem Fall ist es so, da ich mich da gut auskenne.
Und andere Teile, die so Low-Level sind, schon mal geschrieben hatte, wusste ich, was ich wollte, wusste ich, was ich lesen wollte in Code.
Und ich wusste auch genau, was ich für eine Test-Suite haben wollte.
Um sicherzugehen, das funktioniert.
Es funktioniert jedes Mal.
Es ist nicht kaputt.
Ja, und so haben wir das gebaut.
Vielleicht gerade nochmal zum Verständnis.
Dieses Init passiert dann im Container oder ist da auch ein Teil außerhalb, weil du jetzt erwähnt hast, Namespaces und so.
Also es ist wirklich innerhalb.
Ja.
Es ist innerhalb der VM, es ist der Teil, der nach dem Kernel startet.
Vorher hatten wir da Systemd und das war ziemlich generisch.
100% hätte Systemd bestimmt noch tausendmal getunt werden können, um zu sagen, hey, mach das nicht, mach das so, mach das so effizienter und sowas.
Aber ich wollte es dramatisch ändern.
Und um es dramatisch zu ändern, das heißt, um wirklich auf hunderte von Millisekunden zu gehen, war es einfacher, es zu schreiben.
Was war das davor?
Die Größenordnung der Zeit, wenn es jetzt bei 100 Millisekunden ist?
Naja, das kommt alles darauf an, was warm oder kalt war bei uns in den Cache.
Aber von mehreren Sekunden runter zu unter 300 Millisekunden.
So ein großer Faktor.
Und wir reden auch von einer RAM-Benutzung, die runtergeht auf weniger als 10 Megawai.
Also wenn ich jetzt System D verwenden würde, da bin ich auf jeden Fall bei 5 Sekunden oder länger.
So im Normalfall.
Das bedeutet nicht, dass man System.de nicht tun kann, um es viel schneller zu machen.
Das war nur nicht etwas, was wir brauchen.
Ich wollte etwas haben, was ganz einfach für uns zu managen ist.
Und wir hatten auch andere Ansprüche, die intern sind an Cloudflare, die wir da reinbauen wollten, die System.de nicht machen.
Das kommt natürlich alles zusammen.
Und wie kommt man da hin?
Also was hast du anders gemacht als System.de oder was wirft man da alles weg?
Man fängt von null an und macht nur das, was man braucht.
Anstatt zu sagen, ich gucke nicht rein und sage, ich schmeiße nicht Sachen raus, ich baue neu auf.
Aber ich baue neu auf mit nur das, was ich brauche.
In unserem Fall ist es, wir wollen einen Container starten.
Wir wollen alles runtergehen, damit wir runc rufen können.
Das heißt, man tut im Image nur das, was man braucht.
Ein statisch kompilierter Init, nicht ganz statisch kompiliert, das ist ein Rost geschrieben und hat ein paar C-Libraries, die werden dann alles reingepackt.
so zu machen, dass es ein SquashFS ist, das heißt so ein Read-Only-Filesystem, wo nur drin ist, was man braucht.
Und das heißt, okay, ich will etwas mit Run-C starten und so konfigurieren wir das Netzwerk.
Das hatten wir ja schon.
Ich wusste ja schon, wie das Netzwerk konfiguriert ist.
Und dann habe ich gesagt, okay, ich brauche einen Parser für die Netzwerkkonfiguration von Systemd.
Und ich brauche das und ich brauche, ich muss die, ich muss...
die Mounts, alles, was den Host-Name, Set the Host-Name, Set up the Mounts, alles, was Init macht für dich, um zu starten.
User konfigurieren im Image selbst.
Manche Sachen sind im Init-Code selbst, manche Sachen sind im Image für die VM.
Aber die beste Analogie ist, was ich am Anfang gesagt hatte.
Man schmeißt nicht Sachen raus, in unserem Fall fängt man von Null an und schreibt auf, ich brauche das, ich brauche das, ich brauche das.
indem man sich zurückarbeitet von dem, was man am Ende will.
Am Ende will ich einen Container starten, muss er genauso sich benehmen wie vorher.
Kein Unterschied zum Benutzer.
So kannst du es auch einfach austauschen vom Benutzer.
Du hattest die Testsuit erwähnt.
Und ich frage mich gerade, von welcher Art von Tests reden wir?
Reden wir hier von Unit-Tests?
Reden wir hier von Integration-Tests?
Also was sind so klassische Testfälle, wo du gesagt hast, okay, die will ich haben?
Testfälle selbst ist ein bisschen kompliziert, aber sagen wir mal, du willst diese VM schnell starten und du willst einen Container schnell starten.
Okay, dann machst du eine Integration Test mit Firecracker oder Cloud Hypervisor, für jeden Test aufruft und einen Boot machst.
Du kannst Basistests haben.
Ich boote und habe ich einen, steht das in den Bootlogs drin.
Ich boote, hat es...
funktioniert das Netzwerk.
Ich boote mit einer falschen IP-Adresse, funktioniert es immer noch.
Nein, das funktioniert nicht.
Alles, was man da so einbaut, wird eingebaut und einfach automatisch getestet.
Und das Coole ist, weil man da die ganze VM startet und die so schnell starten, kann man einfach richtig viele auf einmal gleichzeitig starten.
Und dann, die Tests sind nicht nur wie beim normalen Entwickeln, sie sind da, damit du später nicht etwas kaputt machst, wenn du etwas veränderst, wenn du neue Funktionalitäten einbaust.
Und dann willst du natürlich auch testen können, dass der Container selbst startet und dass der Container selbst gewisse Sachen machen kann.
Die Test-Suite ist natürlich wichtig, ob man das mit AI schreibt oder nicht.
Für so ein Projekt braucht man eine ganze Test-Suite.
Ganz sicher braucht man für die meisten.
Für AI braucht man sie sowieso, denn ohne Test-Suite kann AI gar nichts entwickeln.
AI ist ja ein sehr spannendes Thema, weil du das angeschnitten hast und ist ja auch viel in Diskussionen aktuell.
Hilft einem das wirklich weiter und wie viel hilft es weiter und ist es wert?
Aber da möchte ich jetzt gar nicht hin in die Diskussion.
Was du aber erwähnt hast, ist, du hättest dieses Projekt sonst gar nie machen können, im Prinzip von Null starten.
Und hast du so eine Abschätzung oder jetzt auch nachdem du es gemacht hast, wie lange du gebraucht hättest sonst oder wie groß wäre so ein Projekt im Klassischen?
Sinne und wie lange hast du jetzt ungefähr gebraucht?
Das ist nur so größenordnungsmäßig.
Ich hätte definitiv über ein Jahr gebraucht, um sowas zu machen.
Und in diesem Fall war das, ohne zu viele Details zu geben, erster Prototyp in zwei Wochen gemacht und dann vielleicht zwei, drei Monate, bis es dann fertig war.
Fertig bedeutet, es läuft in Produktion.
Gut, aber wenn von etwas...
Code, was man auf deiner Festplatte hat, in Produktion, das sind ja viele Sachen, wo AI, ich sag mal, vielleicht sogar relativ wenig helfen kann.
Ich sag mal, klassische Operations Tasks oder Systems Engineering und so weiter und so fort.
War das dann wirklich, ich sag mal, diese Pareto-Regel, dass du 80% des Codes in 20% der Zeit geschrieben hast und dann die letzten 20% wirklich, ich sag mal, durchgrinden musstest und dann halt die Edge-Case rausholen und Co.?
Genau so.
So funktioniert es für alles, was ich so mache generell.
Aber in diesem Fall war es genau das.
Ungefähr diese Größenordnung.
Am Anfang geht es sehr schnell, oh, hier ist ein Prototyp, hier funktioniert es, das funktioniert, ist sogar eine Test-Suite dabei und Benchmark und cool.
Und dann ist es okay, jetzt wollen wir es aber wirklich zum Laufen bringen und wir wollen, dass die ganze Test-Suite, die wir schon haben, damit läuft und das muss man sich Stück für Stück...
durcharbeiten und dann findet man neue Probleme, dann packt man sie in Produktion, dann muss man es auch Stück für Stück anmachen für die Kunden.
Das dauert natürlich auch.
Es ist jetzt nicht alles nur Codeschreiben.
Aber AI hat tierisch dafür geholfen.
Du brauchst sehr viel Boilerplate für sowas.
Du musst sehr viel schreiben und du musst es testen.
Ehrlich gesagt, da wo die AI am meisten geholfen hat, wenn ich etwas von der Test-Suite brauchte, da habe ich einfach gesagt, ich brauche das, ich brauche das.
Da habe ich mir einen Code durchgelesen.
Sah gut aus, veränder das, veränder das.
Aber so viele Tests zu schreiben, ehrlich gesagt, habe ich vorher ja nicht gemacht.
Ich habe ein paar Tests geschrieben vor der Welt mit AI, aber nicht so viele wie heute.
Ich glaube, das hat nicht nur damit zu tun, dass ich jetzt endlich viele Tests haben kann.
Das hat auch damit zu tun, was ich gesagt habe vorher.
Die AI selbst braucht Tests, sonst zerstört sie alles.
Erstmal weiß sie ja gar nicht, wie sie fertig ist.
Und zweitens zerstört sie alles auf dem Weg, wenn sie nicht die Tests hat.
Aber du hast jetzt keine Tests handmanuell geschrieben, sondern auch dann wieder AI verwendet, um Tests zu schreiben.
Die meiste Zeit zumindest, wenn ich die richtige.
Wie viele Menschen schreibe ich seit Dezember keine Linie Code selber mehr?
Selbst für das Box.
Doch, für Advents of Code.
Das mache ich immer noch old school selber im Dezember.
Ich mache nicht den ganzen Monat durch, danach muss gekocht werden und so.
Aber am Anfang fange ich da immer selber an, mache die ersten 15 Tage oder so.
ist natürlich etwas für sich selbst.
Aber sonst, professionell, mache ich alles mit AI.
Ich mache es in sehr vielen Stücken und lese den ganzen Code, der gemacht wird und verbrauche viel Zeit damit, es zu korrigieren.
Aber korrigieren wird auch mit der AI gemacht, 100%.
Für meine Sache funktioniert das ziemlich gut.
Baut auch viel Müll.
Man muss da viel lernen.
Kein Müll damit zu schreiben.
Das ist kein Thema.
Ich bin sehr froh, dass du sagst, ohne AI hat man nicht so viele Tests geschrieben.
Das finde ich total toll, weil jeder sagt immer, wir schreiben alle super viele Tests.
Und dann bin ich da so, ja, ja, tue ich ja auch so nicht.
Naja, weil die so nervig zu schreiben sind.
Jetzt mal ehrlich, ist doch echt langweilig.
Irgendwas für mich.
Es ist langweilig, aber ich gebe auch immer zu, immer wenn ich mich überwunden habe, habe ich immer ein, zwei Bugs gefunden.
Man braucht sie.
Ich sage nicht, dass ich früher keine Tests brauchte.
Ich sagte nur, dass mein Code jetzt besser getestet ist als früher.
Das ist alles.
Natürlich habe ich auch Sachen zerstört auf dem Weg, wenn da irgendwo auf dem Pfad keine Tests waren.
Aber wir reden hier nicht von jemandem mit einem kleinen Hammer, der was kaputt macht.
Mit der AI reden wir von einem Bulldozer, der da durchgeht.
Und ich finde es unglaublich schön, dass du die Engineering-Ähre aufrecht hältst und sagst bei Advent of Code.
Das finde ich schön.
Ja, ist doch klar.
Wieso sollte ich dir, klar, sonst kann ich Copy-Paste und es funktioniert, da habe ich doch nichts gelernt.
Lass uns mal nochmal ganz kurz auf das Thema Sicherheit beziehungsweise Trade-offs eingehen.
Und zwar hatten wir schon geklärt, okay, geteilter Kernel, Hyperweise-Grenze und so weiter und so fort.
Inwieweit sagst du, okay, sind Container beziehungsweise Micro-VMs beziehungsweise VMs von Sicherheits- wie soll man sagen, Issues betroffen.
Also muss es immer direkt eine Kernelücke sein oder gibt es da, ich sage mal, Level, wo es immer schwieriger wird, je nachdem, wie viel Isolierung man hat?
Ja, das ist eine sehr breite Frage.
Aber sagen wir mal, wenn man da anfängt.
Das Erste ist, sagen wir mal, jemand hat mehrere Container am Laufen lassen und startet Container, die er nicht kennt.
Der größte Fehler ist, wie immer, irgendetwas falsch zu konfigurieren.
Ganz besonders mit LLMs, die sagen, hey, Einfach diese Command, jetzt starte sie und dann funktioniert es.
Ja, aber fehlt da was?
Es gibt Sachen, die du bei Docker konfigurieren kannst, um Sachen sicherer zu machen.
Out of the box ist Docker ziemlich sicher, aber man kann natürlich ein Mögliches machen und sagen, hey, mach mal diese Sicherheit da weg oder ich brauche das oder öffne mal das oder mach mal alle Ports auf.
Kann man einfach sehr schnell einfach machen.
Also natürlich sind die ersten Fehler immer Benutzer.
Danach gibt es auch, sagen wir mal, wenn etwas richtig ist, dicht konfiguriert ist im Docker selbst und du sagst, du kannst keine Root-Processes starten und die Workload ist nur als User und sowas, dann brauchst du schon eine Kernel-Lücke, um da rauszukommen.
Wie gesagt, deswegen sind schlechte Konfigurierungen oder schlechte Images, die schlecht gebaut sind, viel einfacher als Falle, als diese Kernel-Lücken.
Aber Kernel-Lücken...
Es gibt die, die man kennt und die, die man nicht kennt.
Und wenn man dann einfach raus ist aus dem Container, dann ist man sozusagen rot auf der ganzen Maschine.
Deswegen sind diese VMs so wichtig, denn wenn man aus dem Container rausschlüpft, aus einem Micro-VM, dann ist man erstmal in der VM.
Und wenn man da in der VM ist, braucht man tatsächlich einen Hypervisor-Bug, nicht mehr einen Kernel-Bug.
Das heißt, man braucht einen Bug in Firecracker, einen Cloud-Hypervisor oder natürlich...
Der Linux-Kernel selbst ist auch ein Hypervisor.
Sehr viel von diesen Sachen wie Firecracker und Cloud-Hypervisor benutzen, KVM benutzen, da kann natürlich auch, ja, ist es dann ein Hypervisor-Bug oder ein Kernel-Bug oder beides, ist eigentlich wurscht.
Es ist ein Bug, der dir dazu hilft, aus deiner VM rauszustimmen.
Aber das ist dann noch eine ganze Klasse höher.
Bei Sicherheit ist es genauso wie bei physischer Sicherheit.
Man baut mehr und mehr aufeinander, je sicherer man etwas haben will.
Die Burg hat eine Wand und hat einen Graben mit Wasser.
Wer dann extra sicher will, packt nochmal Krokodile rein.
Aber es kommt drauf an, die Burg hat etwas zu verteidigen, weil da eine ganze Stadt drin ist.
Das kleine Haus hat weniger zu verteidigen.
Bedeutet nicht, dass man plötzlich die ganzen Türen auflassen muss.
Aber das heißt, es sind alles Levels der Sicherheit, die man sich aussucht.
Und manchmal ist es nicht einfach zu wissen, welches Level man hat.
Du hast gerade einen wichtigen Punkt angesprochen, auch wie ich den Container laufen lasse.
Ich überlege gerade, okay, was ist, wenn ich einfach mal irgendwas mounte mit Read-Write-Permissions und jemand ist im Container, dann kann man natürlich durch den Mount natürlich auch Dateien auf den Host-System schreiben und so weiter und so fort.
Du kannst auch den Container mit zum Beispiel Dash-P und dann ist ja sozusagen einfach alles erlauben, dann bist du gut drin.
Das hat auch einen Sinn.
Manchmal ist es sehr praktisch.
Ich benutze Container mit.
Privileges selber zum Entwickeln von Systemen, wo Container in Container in Container laufen oder VMs in VMs in Container laufen.
Dafür brauchst du halt mehr als Entwickler, aber das ist dann lokal für mich.
Aber wenn du dann einfach dir einen Workload gut gibst mit einem Dash P, ist klar, dass da ein Problem kommen kann.
Was ist dein Use Case, um Container in Container laufen zu lassen?
Es ist einfach ganz simpel.
Wir bauen ein Container System, was auf Cloudflare läuft.
Diese Container laufen in einer VM.
Diese VMs müssen wir auch lokal irgendwie entwickeln.
Das System, was diese ganzen VMs managt und startet.
Das heißt, wir brauchen ein Developer Environment.
Will ich das jedes Mal wieder aufbauen?
Nein, das Erste, was ich eigentlich gemacht habe, als ich zu Cloudflare gekommen bin dieses Jahr, ist zu sagen, hey, diese VM, die wir benutzen, wir packen das alles in ein Docker.
Deswegen bist du plötzlich mit Docker in der VM, ne, ist nicht Docker, aber mit einem Container in der VM, die selbst in ein paar Namespaces und C-Groups läuft, die dann selber in dieser Sandbox laufen.
Und ganz besonders mit AI ist es jetzt so, okay, und dann habe ich nochmal einen AI-Agent, der in diesem Docker-Container läuft, damit der direkt Zugriff drauf hat.
So wird es gestapelt.
Und es wird auch sehr schnell gestapelt auf Linux.
Denn auf Linux hast du Systemd, der startet.
Und dann sagt er, hey, ich starte Docker.
Docker wird in seinem C-Group und seinem Name-Space gestartet.
Und er selbst kreiert Name-Spaces und C-Groups und so weiter und so fort.
Dieser Fall passiert oft.
Aber in meinem Fall ist es für Diver.
Du musst dann zugeben, das klingt schon echt Meta, oder?
Es ist Meta.
100%.
Deswegen ist es ein Kompliziosystem.
Wenn ich jetzt weiter in das Rabbit Hole hier gehe, über das wir sprechen.
Es geht immer tiefer.
Ja, es geht immer tiefer, das weißt du doch.
Dann gibt es auch, ich würde es mal Hybride-Ansätze nennen, wie zum Beispiel Cutter-Containers oder G-Visor, was meines Erachtens oder meines Verständens nach ein User-Space-Könnel, also ein neuer Kernel im User-Space ist.
Hast du damit schon mal irgendwie Erfahrungen gehabt?
Also mit Cutter-Containern habe ich keine Erfahrung, aber von dem, was ich gelesen habe, ist es eine Art Mikro-WM-Plattform.
Aber ich sage vielleicht was Falsches, weil ich wirklich sage, von was ich so gesehen habe.
Ich bin da nie tief reingegangen.
Vielleicht hätten wir Cutter-Container benutzen können statt unseren eigenen.
Das weiß ich alles nicht.
Und GVisor ist dann auch was anderes.
Ich kenne mich da nicht super aus, aber Google hat GVisor gemacht, um genau das zu machen, was du sagtest, um zu sagen, wir werden einen Linux-Kernel starten, aber wir werden keine VM haben.
Wir werden es alles mit...
User-Space-Syscalls-Abstrahierung bauen.
Warum sie das so gemacht haben, es hat allmögliche Vorteile.
Zum Beispiel am Anfang war es ganz einfach, da mit GPUs zu teilen.
Ich sage nicht, dass sie das dafür gebaut haben.
Das ist ein Beispiel.
Aber G-Weiser selbst ist halt, ich starte den Linux-Kernel nochmal als User-Space-Programm.
Und wie das gemacht wird, da will ich auch nichts Falsches sagen, aber wie ich es verstanden habe, ist es, die ganzen Syscalls, die gemacht werden, werden abstrahiert.
Aber ich könnte es falsch haben.
Deswegen will ich da nicht tiefer reingehen.
Sonst labere ich hier nur wie eine LLM rum, was ich gerade mache.
Jetzt sind wir ja schon voll in der Ecke, was passiert denn rundherum und vielleicht auch in der Zukunft.
Einen Teil, den wir jetzt noch nicht besprochen haben, ist so die Client-Seite, weil wir waren jetzt mehr so auf der Server-Seite.
Zu Hause, Client.
WebAssembly ist ja immer so angetreten, um da in irgendeiner Form sowas im Browser zu ermöglichen.
Meiner Meinung nach nie so richtig durchgestartet.
Es kommt nicht so richtig durch.
Siehst du in Zukunft irgendwie im Browser auch mal so Micro-VMs oder gibt es da irgendwas am Horizont, was uns in der Browser-Welt irgendwas bringen will?
Hast du da eine Sicht darauf?
Du bringst mich wieder zu einer Cloud-Fair-Werbung.
Das ist problematisch, denn wir machen sehr viel mit WebAssembly und im Browser.
Die isolates, die Cloudflare hat, sind natürlich nicht die einzigen, die sowas haben.
Aber es geht darum, so viel wie möglich im Browser, nicht nur im Browser, sondern auch außerhalb des Browsers, zum Laufen zu lassen, was ein noch kleineres Teil ist von einer Maschine sozusagen.
In diesem Fall ist es ein Teil des Prozesses.
Und wie mache ich das?
Sehr sicher.
Das wird sehr viel mit Sachen wie WebAssembly und JavaScript gemacht, also JavaScript Engines.
Ich habe da keine große Sicht.
Ich finde es richtig cool, was man da machen kann.
Und wie alle Technologien, ich glaube, alle haben von WebAssembly und sowas erwartet, dass es plötzlich überall ist.
Aber man sieht es eher da ankommen, wo es gebraucht wird und Stück für Stück.
Es gab natürlich viel Hype, die sagten, du kompilierst einfach dein Ding und dann läuft es einfach im Browser.
Brauchst ein bisschen mehr dafür, damit es da aufbringt.
Aber diese Sachen kommen alle.
Wir sind viel weiter heute als vor fünf Jahren sogar, wo diese Thematik angefangen hat.
Ich habe da nicht viel Technisches zu sagen.
Ich finde es cool und ich sehe immer mehr Sachen, die für sowas benutzt werden.
Aber jetzt im Detail zu sagen, oh, in dieser Welt wird WebAssembly jetzt benutzt, wo sie vorher nicht benutzt wurde, da weiß ich jetzt nicht.
Es zahlt halt auch schon auf diese Isolierungsthematik ein, wie wir jetzt schon durch Konstant durchgesprochen haben, halt nur im Speicher, halt nur auf einer anderen Ebene.
wenn er so möchte.
Das ist halt schon ganz interessant.
Und ich glaube, wenn ich jetzt noch weiter das Rabbit Hole runtergehe, ich bin mir gar nicht sicher, ob wir jemals das Ende erreichen würden.
Deswegen stelle ich einfach mal die Frage, wie würdest du die Zukunft beschreiben.
Und ich weiß, Achtung, Achtung, Achtung.
Eine leichte Frage.
Nein, nein.
Was würdest du dir wünschen vielleicht für die Zukunft?
Es ist vielleicht besser.
Bleibt das alles hier ein Zoo aus Container-Runtimes, Micro-VMs und Pipapo?
Oder denkst du, okay, die ganze Sache konsolidiert sich irgendwann oder fängt jeder an, hey, ich habe eine neue Idee, dann baue ich was, weil es jetzt besonders so einfach ist?
Also, weil ich habe so ein bisschen das Gefühl, Wenn man versucht, in dieses Rabbit Hole hier zu gehen, du bist erstmal, auf Englisch würde ich sagen overwhelmed, überfordert.
Du bist erstmal überfordert mit dem Lernen von Basistechnologien.
Und dann kommen die Apps da drauf, dann kommt Firecracker, dann kommt Kemu, dann kommt das, das, das, das, das.
Und das geht ja nur so weit.
Hast du irgendwie das Gefühl oder zumindest den Wunsch, dass es irgendwann einfacher wird?
Oder sagst du, nee, ich glaube, es geht eher dahin, dass wir weiter spezialisiertere Software bauen, die dann noch mehr narrow auf den Use Case geht?
Erstmal, die ganze Geschichte von Computer ist immer eine Abstraktion aufbauen auf die nächste, auf die nächste, auf die nächste.
Man baut immer und es baut sich und weitet sich so immer mehr aus wie ein Baum.
Ich glaube nicht, dass es einen Weg zurückgeht, wo es plötzlich irgendwo ein System ist, was alle benutzen.
Es gibt ein paar Fälle der Welt wie Linux und andere, die sowas geschafft haben.
Sogar Systemd hat sowas geschafft.
Jetzt im Endeffekt ist es mir selbst persönlich wurscht.
Solange es genug Wege gibt, irgendwo in diesem Stapel von Abstrauierung, wenn du irgendwo einsteigen willst, solltest du eine einfache Tür reinhaben und es einfach benutzen können.
Aber es wird meiner Meinung nach, wenn wir jetzt ein bisschen über die Zukunft denken, ich sehe keinen Weg, wo Sachen nicht noch spezialisierter werden, ganz besonders mit AI.
wo sich dann jeder seine Sachen aufbaut.
APIs sind dann noch wichtiger als vorher und so weiter und so fort.
Das geht ja nicht weg.
Aber Betriebssysteme sind nun mal komplex und werden Stück für Stück leider komplexer.
Ganz besonders diese ganzen Sachen, die wir gerade besprochen haben, die meisten sind alle sehr generische Technologien, die dann benutzt werden, um andere Technologien zu bauen.
Wir reden ja jetzt nicht von End-User-Technologien.
Wir reden von...
Developer-Tools, Betriebssysteme, die ganze Basis, auf denen andere Sachen gebaut werden.
Also nein, ich sehe das nicht, plötzlich zu sagen, oh, guck, wir haben eine Sache, die alles löst.
Nee, glaube ich nicht.
Ich weiß gar nicht, ob ich die ganzen Sachen als Developer-Tools beschreiben würde.
Nein, ich habe gesagt, es ist Developer-Tools, Betriebssysteme und alles sind...
Basisteile auf denen aufgebaut werden, um andere zu machen.
Docker ist ja ein Misch von Developer-Tool und ganz andere Teile.
Da stimme ich dir zu.
Ich glaube auch Leute, die sich ziemlich viel mit, weiß ich nicht, keine Ahnung, nehmen wir mal Kubernetes.
Ich glaube, ich bin der Erste, der das jetzt in diesem Podcast nennt, was mich auch überrascht.
Aber beschäftigt, das ist ja schon für Außenstehende alles wirklich schwer zu konsumieren.
Im Fall von Kubernetes ist es auch, ich würde das nicht unbedingt ein Developer-Tool nennen, aber es ist schon ein Tool, der da ist, um Entwickler einen Service zu geben.
Und dass du das dann tausend verschiedene Arten machen kannst, ist klar, weil es so generisch ist.
Aber es ist da, um Entwicklern, es ist ja nicht für die Endbenutzer einer Plattform, die da zum Beispiel irgendwie im Shop einkaufen, denen ist es ja egal, ob es Kubernetes oder ist.
Aber für sehr viele Entwickler in einer Firma ist das wichtig.
Und das ist dann eine Plattform.
auf der sie aufbauen und Entscheidungen treffen für Technologien.
So ist es für alles.
Docker, Kubernetes und so weiter und so fort.
Wir sind eigentlich jetzt am Ende des Podcasts und ich habe initial die ganze Sache großkotzig angekündigt als Technologie, die die halbe Cloud antreibt.
Und du hast natürlich schon eine ganze Menge Container-Use-Cases gesehen.
Was ist der wildeste Case von Containern, den du mal gesehen hast?
oder der dir erzählt wurde, den du nicht erwartet hast, da wo du sagst, das glaubt dir doch eh keiner.
Während du jetzt nachdenkst, hätte ich noch eine Frage an Andi, warum nur die halbe Cloud treiben Container nicht die ganze Cloud an?
Ja, ich habe keine Zahlen.
Ich habe noch nie bei einem Hyperscaler gearbeitet.
Ich weiß es nicht.
Ich bin nicht bei Amazon, Google und Co.
Ich dachte, du arbeitest bei Cloudflare.
Aber ihr treibt ja schon die halbe Welt an.
Ja, ich weiß nicht, ob das ein Hyperscaler ist.
Keine Ahnung.
Okay, aber was ist der wildeste Use Case?
Ich habe ehrlich gesagt nie viel Wildes gesehen.
Meine Vermutung ist ja, dass du schon so viel gesehen hast, dass das alles für dich einfach normal ist, wo wir sagen würden, das ist cool eigentlich.
Ja, es ist vielleicht meine Welt, aber es ist auch eine Technologie, die normal geworden ist.
Es war vorher was Besonderes zu sagen.
Vorher konntest du gar nicht Docker-Container wirklich gut in Produktion benutzen vor zehn Jahren.
Und seitdem sind wir weit davon entfernt.
Was das Wildeste ist, einfach zu sehen, wie viele Menschen so arbeiten.
Zu sagen, wir benutzen Docker und nehmen die Container runter und das funktioniert.
Das ist wild, so etwas zu sehen.
Zu sehen, dass so viele Menschen einfach aus jeder Industrie damit arbeiten, wie der Rest.
Das ist für mich das Wildeste.
Bist du dir eigentlich, wenn du das jetzt gerade schon so sagst, bewusst, was ihr mit dem ganzen Docker-Movement da für die Industrie losgetreten habt?
Es haben sehr viele Menschen an Docker gearbeitet.
Selbst wenn ich da angefangen habe, ich war nicht der Einzige.
Wir waren mehrere, Salomon und andere.
Und am Anfang haben wir einfach nur rumgespielt, um zu sehen, wir wollen nicht immer tausendmal dieselben Sachen installieren, tausendmal dieselben Pop-It-Skripts.
Damals benutzte man etwas, das hieß Pop-It.
Es muss einen Weg geben, die Sachen einmal zu bauen und dann wieder benutzen zu können.
Ja, es ist uns jetzt bewusst, wenn ich mit den ganzen anderen spreche, die daran gearbeitet ist, oh geil, es ist erstaunlich, aber irgendjemand hätte es gemacht, würde ich mal sagen.
Ich glaube jedenfalls, wir haben es so gemacht.
Aber es ist schon erstaunlich.
Was mich erstaunt ist, dass es einer dieser Sachen ist, wo nicht wirklich, ja, es gibt viele Alternativen, um Docker-Container zu starten und so weiter und so fort, aber im Endeffekt starten die Menschen dieselben Sachen.
in derselben Art und arbeiten alle in derselben Art.
Und wie gesagt, das Coolste für mich, was Docker gelöst hat, ist dieses, ich kann lokal schnell etwas entwickeln.
Ich brauche nicht tausend Sachen zu installieren.
Ich installiere sie, schmeiße sie wieder raus.
Ich glaube, ich spreche für sehr, sehr viele, wenn ich einfach mal Danke sage von der Engineering Community, an dich, aber auch an das ganze Team, an alle Leute, die an Docker gearbeitet haben, weil ich habe das Gefühl, ihr habt natürlich jetzt nicht nur...
Hunderte von Menschen.
Deswegen, also ich sage ja deswegen extra, du darfst dir aber auch mal selbst auf die Schulter klopfen.
Also das darfst du schon noch tun, so ist das nicht.
Klar, Docker ist die eine Sache, aber ich glaube, dieses ganze Movement in der ganzen Industrie wurde dadurch nochmal ein bisschen getriggert.
Besonders weil sowas wie Freebase DJs, also die Idee von Containern ist ja jetzt gerade nicht so super neu.
Die gibt es ja schon ein paar Jährchen.
Aber die ganze Sache, ich nenne es mal massenkompatibel zu machen oder massenkompatibler.
Das ist ja schon ein Movement.
Sowas wie Woodstock damals, würde ich mal sagen.
Woodstock war jetzt ein bisschen heftiger, ein bisschen geiler.
Aber nee, es ist schon cool, muss ich schon sagen.
Und zu sehen, dass sich dadurch Sachen wie Kubernetes entwickelt haben.
Natürlich gab es die Ideen für Kubernetes und sowas, aber es wurde dann möglich gemacht, weil plötzlich, oh, es gibt ein Format.
Alle Menschen haben das selbe Format.
Und wenn man die Sache so startet, können wir das machen.
Ich bin nicht der größte Fan von Kubernetes, obwohl ich sehr viele Male benutzt habe.
Ich war mal ein großer Fan.
Ich bin nicht jemand, der sagt, oh, bla bla bla.
Nein, ich war immer ein großer Fan, jetzt finde ich das alles zu komplex.
Aber allein, dass es das gibt und dass es möglich ist, finde ich...
Richtig cool.
Also ich kann mich auch erinnern, das war damals bei mir bei Stocker Swarm so 2015 oder so, wie ihr zum ersten Mal gesehen habt, dass da dann so automatisch Instanzen hochbooten und parallel und so weiter.
Das war schon, mir ist die Kinnlade runtergefallen.
Das war schon ein cooles Erlebnis.
Ich habe gerade nochmal nachgeschaut, um nochmal auf meine wilde Frage, wo werden Container überall genutzt?
Du sagst ja in selbstfahrenden Autos und so weiter.
Curl fleckt sich damit, dass es bei der Mars-Mission dabei war oder dass Curl selbst auf dem Mars schon gelandet ist.
Das ist schon eine harte Nummer.
Hätte ja sein können, dass es irgendwie, weiß ich nicht, auf der ISS, auf der Raumstation irgendwie vielleicht auch ein Container getrieben wird oder so.
Ich weiß es nicht.
Das stimmt.
Müsste man checken.
Frag der LLM, die sagt ja.
Wir haben ja eine große Community, die kann sich jetzt darum kümmern.
Vielleicht kann jemand mal raussuchen, war Docker oder war ein Container schon am Mars oder zumindest am Mond.
Wenn man jetzt setzt, ich meine, da kommt doch ein Laptop mit nach oben.
Ja, das stimmt.
Ja, Monty ist zu schwach eigentlich, Mars muss schon sein.
Ich kenne mich da nicht aus, aber ich meine diese ganzen Rover und so, die da so am Mars sind, die sind schon ziemlich Low Level.
Ja, viel Rahmen ist da glaube ich nicht verfügbar.
Ja, aber also C-Groups werden da sicherlich verwendet.
Bootet das Linux?
Bestimmt, alles bootet Linux.
Ich weiß es nicht, ich weiß es nicht.
Aber zum Abschluss haben wir natürlich immer, ich sag mal, so eine kleine Hausaufgabe für die Hörerinnen und Hörern.
Und deswegen würde ich dich gerne mal fragen, Sepp, wenn man mit dieser ganzen Thematik jetzt mal selbst anfangen wollen würde, sich in dieses Thema, ich sag mal Firecracker, MicroVM und Co.
mal so ein bisschen einarbeiten möchte, vielleicht auch mal mit einem minimalen Init herumspielen möchte.
Was würdest du jemandem an die Hand legen, wo man startet?
Ohne Use Case ist es natürlich schwierig, aber wenn man einfach Bock hat, das zu lernen, kann man es so machen, wie ich es gemacht habe, wie früher.
Einfach erst mal Source-Code lesen, den es schon gibt, Sachen starten, du kannst Firecracker runterladen, du kannst es starten, du kannst einfach folgen, was es macht.
Der Source-Code ist auch relativ interessant zu lesen.
Dann würde ich etwas Neues sagen, was früher nicht so war, aber ich würde tatsächlich versuchen, mit einem Agent-Lokal ein bisschen nicht unbedingt den ganzen Code zu schreiben, denn dann lernt man ja nicht viel drüber.
Ich weiß immer noch nicht, wie man...
lernt mit einer LLM, ich weiß nur, wie man macht, obwohl, das sage ich so, ich lerne viel damit, aber einfach zu Fragen stellen und sagen, hey, wie funktioniert das?
Aber dann auch die Fragen so zu stellen und zu sagen, zeig mir im Code, wie das funktioniert.
Deswegen nicht nur ChatGPT, sondern lokal mit dem, oh, ich will mal diesen Container in diesen Firecracker starten.
Bau mir etwas Minimales auf, was ich dann lesen kann.
Erklär es mir Stück für Stück.
Das ist der Bonus, den wir heute haben.
Du kannst so lange mit deinem Agent zusammen Fragen stellen, bis du etwas kapiert hast.
Der Fehler ist zu sagen, erklär mir mal, wie es funktioniert.
Ja, ist für Sachen, die sie sehr gut kennen und schon lange da war, sehr gut.
Aber sowas Technisches wie hier ist, lass uns das mal zusammen workshoppen.
Und wie sieht ein Workshop aus und wie lerne ich das?
Du kannst dir dann da zusammenbauen, Linux from scratch, warum nicht?
Ich habe es nur einmal in meinem Leben gemacht und ich habe es dann auch nicht wirklich benutzt.
Aber einfach diese Sachen zu benutzen und ausprobieren, es muss ja nicht Linux from scratch sein.
Aber jeder, der Computer lernt, alle, die ich getroffen habe, die Programmierer sind, heutzutage, die mal jünger waren, als ich sie getroffen habe, habe ich immer gesagt, oh, du willst anfangen?
Okay, installierst mal Linux.
Warum?
Nicht, weil es besser ist, sondern das ist meine Erfahrung.
So habe ich gelernt.
Und ich habe es einfach installiert, benutzt und dann einfach das Benutzen davon, davon habe ich sehr viel gelernt.
Heutzutage lernt man vielleicht nicht dieselben Sachen, wie ich damals.
Deswegen sage ich, okay, such dir vielleicht eine Distro aus, wo du mehr lernst.
Aber das würde ich sagen, einfach wie für jedes Thema rummachen.
Das einzig Neue ist, dass du halt diese LLM hast, mit der du das workshoppen kannst.
Du kannst hier fragen, hey, mach mal ein bisschen ein Stück kurz, dass ich starten kann.
Aber was nur das macht und nur das, nur das, das hilft.
Sepp, vielen lieben Dank, dass du die letzte Stunde mit uns verbracht hast und auch die Zeit dafür geopfert hast.
Wir sehen uns nicht als Selbstverständlichen.
Ich hatte sehr viel Spaß.
Ich habe echt viel gelernt.
Für alle Hörerinnen und Hörer, wir haben in den Shownotes etliche Links mitgeschrieben.
Also wer mal da ein bisschen reinsteigen möchte.
Was Firecracker ist, Cloud Hypervisor hatten wir, glaube ich, genannt.
Linux, From Scratch, LXC, RunC, Systemdn spawn, wer vielleicht mal Container mit Systemd spawnen möchte.
Oder aber auch nochmal Advent of Code, falls ihr nicht wisst, was das ist.
Ich glaube, Advent of Code hat leider jetzt aufgehört, beziehungsweise machst du noch alle zwei Jahre oder sowas.
Da gab es eine Änderung jetzt gerade.
Wirklich scheiße, das ist doch, ich hoffe nicht.
Dezember ist es sonst, ja.
Ja, aber ich glaube, ihm war es irgendwie zu stressig oder irgendwie sowas nach so vielen Jahren.
Irgendwas war da, aber ich muss das nochmal raussuchen.
Die LLM haben es zerstört.
Das glaube ich auch, ja.
Sepp, nochmal vielen lieben Dank und ansonsten wünsche ich dir auch noch eine schöne Zeit und ja, an alle würde ich sagen, wir hören uns nächste Woche wieder.
Bis bald.
Tschüss.
Vielen Dank.
War richtig cool.
Danke sehr.
Ciao.
Ciao.