 Zurück aus einer kleinen Pause und jetzt leuchten wir das hier berechnete Welt mal von der anderen Seite, denn berechnete Welt ist ja, habe ich ja sofort Assoziation Compute, wie es heutzutage heißt, also die Rechenkapazität, wie man sie auch z.B. in der Cloud findet, siehe deinen T-Shirt hier bei Astro da drüben. Astro würden uns was erzählen über Mikrofeinpunkt nix, flexible Virtualisierung mit nixOS, ein herzliches Willkommen an Astro. Hallo, ich will euch was über ein eigenes Projekt erzählen, was ich hier seit einem Jahr mache, wo auch ganz viel C3D-2-Infrastruktur schon draufläuft. Und die kommt ja ein bisschen aus der Richtung, dass man sich überall heutzutage Rechenzeit, also Cloud-Computer einkaufen kann. Und das ist natürlich isoliert stattfinden soll und ihr habt vielleicht schon mitbekommen, wir sind hier ganz groß auf nixOS und der Einsteigervortrag ist leider erst morgen, deswegen fange ich mit ein paar ganz kleinen Grundlagen an, also nix ist nicht nur so die Befehle, sondern auch eine Programmiersprache dahinter und so sehen Daten nix aus, da haben wir ein sogenanntes Attribute Set mit einem Schlüssel Server, der auf die Zeichenkette Example net zeigt und einem Schlüssel Report, der den Wert die Nummer 443 hat. Es gibt also irgendwie Nummern und Zeichenketten und Attributsets, also Schlüsselwertpaare und Listen und die kann man auch verarbeiten. Man kann mit den Nummern rechnen, man kann die Zeichenketten verarbeiten, man kann diese Attributesets und Listen, kann man verarbeiten mit den ganz gewöhnlichen Map- und Filtermethoden bekannt aus vielen funktionelleren Programmiersprachen natürlich kann man auch eigene Funktionen definieren und kann damit INCO ziemlich gut seine Infrastruktur beschreiben und das coole ist, man baut vor allem erstmal so Pakete und diese Pakete, die laufen in den sogenannten Sandkasten, die können also nicht aufs komplette System zugreifen, sondern die kriegen nur Zugriff darauf, worauf sie abhängen. Also zum Beispiel in Lib C benutzen viele Programme, davon das ist eine Abhängigkeit. Und das wird so sichergestellt, dass jedes Paket darf nur so Pfade in diesem Nix-Store-Pfad erstellen? Jetzt? Ah, genau. Also alle Nix-Definitionen haben Auswirkungen auf diese Prüfzumme, die man hier in diesem Nix-Store-Pfad sieht und die Effekte sind, dass eben die Abhängigkeiten erzwungen werden. Ich muss, wenn ich mein Nix-Code ändere, muss ich nichts, was sich nicht geändert hat, noch einmal bauen und da hier so einen langendeutigen Pfad hat, kann ich das selbe Paket auch in ganz vielen Variationen oder auch Versionen haben und das gibt einem ziemlich viel Mächtigkeit und Reproduzierbarkeit und die meisten dieser Pakete sind in den Nix-Packages drinnen. Das ist eine riesige Paketsammlung, da finden sich nicht nur die Nix-Packages, sondern auch das ganze Nix-OS und das ist ein Repositori aufgetappt. Da kann man ruhig mal reinschauen, also ich schau da ständig rein um was nachzulesen. Code ist eben die beste Dokumentation. Ja und dieses Nix-OS, das baut ein ganzes Linux aus diesen deklarativen Deklarationen auf und da hat man neben der üblichen Nix-Funktionalität, dass man eben Listen und so was verarbeiten kann, auch noch die Funktionalität der Module und so eine Nix-OS-Konfiguration sieht immer so aus, die gibt hier so ein Attribute Set an deklarationen zurück und was ja aber eigentlich ist, ist eine Funktion, die noch ein paar Sachen mitbekommt, die Pakete zum Beispiel, wenn man die braucht oder auch die Konfiguration und an dieser Stelle kann man auf die Konfiguration aus anderen Modulen zugreifen und das macht das Ganze sehr, sehr mächtig, weil man eben die Dinge gut miteinander kombinieren kann. Ja und das allerneuste und allerletzte im Einsteigerteil sind die Nix-Flakes. Da ist jetzt nochmal eine neue Entwicklung bei Nix, da hat man einfach so ein einheitliches Format. In einem Repository muss da eine Flake Nix liegen und die hat ganz wohl definierte, eine wohl definierte API für wie heißen die Pakete, wo finden sich die Nix-OS-Konfiguration und solche Dinge und außerdem vereinheitlicht es den Umgang mit externen Inputs, also Dependencies-Abhängigkeiten, indem es die Prüfung dieser in die Flake Lock schreiben kann. Gut, so viel zu Nix und Nix-OS, fangen wir an mit den Micro-WM-Nix. Warum würde man überhaupt virtualisieren? Da habe ich für mich die folgenden Gründe. Das erste ist die Konsolidierung. Ich will natürlich nicht für jeden Dienst einen einzelnen Computer, einen einzelnen Server aufstellen, sondern möchte möglichst auf der gleichen Hardware die Ressourcen teilen. Dann im Intro schon angesprochen, heutzutage will man, wenn man fremde Leute auf Infrastruktur hat, will man die voneinander unbedingt isolieren. Und tatsächlich ist es ja so, wenn ich jetzt ein Linux-Update, so auch so ein konventionelles Linux wie ein Debian, dann update ich vielleicht Python für den einen Dienst und ein anderer Dienst, der auch in Python geschrieben ist, der geht dabei kaputt. Das selbe Problem hat man in Nix-OS auch, weil das ja trotzdem alles aus einer einheitlichen Quelle kommt. Und mein Ziel ist es, die Micro-WMs, diese Gastsysteme vom Horstsystem zu entkoppeln, individuell updatebar zu machen. Das ist der eigentliche Isolationsgrund, die Sicherheit, dass man eben verschiedene Tenants, also Bewohner voneinander abtrennen will. Und heutzutage hat man ja ganz viel Containerisierung mit Docker. Und bei der Containerisierung hat man aber trotzdem noch diesen einen Linux-Körner laufen, der sich um alles kümmert und dabei eine riesige Angriffsoberfläche bietet. Und wenn man virtuelle Maschinen benutzt, dann ist die Angriffsoberfläche eigentlich nur noch dieser Hypervisor, also das, was die virtuelle Maschine ausführt. Und die Hoffnung ist, dass diese Angriffsoberfläche wesentlich kleiner ist. Vier der Grund zu virtualisieren ist, dass man die Dinge einfach mitnehmen kann. Also ich habe zum Beispiel schon seit 20 Jahren zu Hause ein Heimserver, wo ich meine E-Mails laufen habe. Und wenn ich jetzt doch mal verreise, dann habe ich die Option, meinen E-Mail-Container oder virtuelle Maschinen einfach mit auf mein Laptop auf Reisen zu nehmen. Und habe sie da immer mal verfügbar, auch wenn ein Riesenstromausfall ist, wie letztes Jahr. Und bei NixOS ist die Entwicklung auch ganz großartig, weil ich kann V-Code, kann ich meine Infrastruktur lokal entwickeln, kann sie virtuellen Maschinen testen. Und erst am Ende, wenn ich zufrieden bin, mache ich einen Getusch auf die Produktivinfrastruktur und habe dann ziemlich hohe Sicherheit, dass das da richtig laufen wird. Denn ich habe es ja lokalen virtuellen Maschinen getestet. So, Virtualisierung kennt ihr ja vielleicht alle schon von Virtualbox oder Vmware. Jetzt gibt es so einen neuen Trend, der heißt Micro VMs. Bisher wurde bei Virtualisierung ja immer versucht, einen richtigen PC nachzubilden. Also es geht nicht nur um die Insulationen-Sicherheit, sondern es geht auch darum, dass man möglichst alte Geräte emuliert. Und bei dem Micro VM-Trend fängt man an, darauf jetzt zu verzichten. Namensgeber ist das Micro VM-Hardware-Modell MQ-EMO. Also bei der QEMO kann man irgendwie den IE440 PC nehmen, das ist zum Pentium II oder den Q35. Das ist irgendein so moderner Core mit EFI. Aber jetzt die Micro VMs, die schmeißen möglichst alles Mögliche raus, bieten dafür diese Geräteschnittstellen, die optimiert dafür sind, dass sie eben nicht an richtigen Geräten hängen, sondern an einem virtualen Gerät, was von einem Hypervisor bereitgestellt wird. Und damit ist das schon mal wesentlich schneller. Und man verliert nicht mehr so viel, wenn man virtualisiert gegenüber der Containerisierung. Trotzdem gibt es natürlich immer noch ein bisschen Performance trade-off. Da gibt es das Projekt, auch auf GitHub habe ich letztes Jahr gestartet. Und der Zweck ist, dass man einfach sich eine virtuelle Maschine auf den XOS starten kann. Und wenn ich das einmal mache, mache ich das natürlich gleich wiederverwendbar. Ich habe vorhin im Einführungsteil die Flakes erwähnt. Dieses Projekt setzt komplett auf Flakes. Theoretisch wäre das möglich, auch so auf die alten XOS Art das zu machen. Aber da müssen wir jetzt noch ein bisschen was refaktoren. Ich finde die Flakes eigentlich ganz cool, weil sie eben die Reproduzierbarkeit wirklich nochmal um ein ganzes Stück verbessern. Das Projekt kommt mit einem Handbuch. Das ist auch gleich oben in der Rhythmie verlinkt. Wenn ihr da, wenn euch da was fehlt, könnt ihr mir gerne Feedback geben. Da freue ich mich sehr. Die unterstützten Hypervisors. Ich habe mit Qimo begonnen. Qimo gibt es schon richtig lang, ist das schon richtig sehr nützlich. Da habe ich entdeckt, da gibt es mittlerweile noch mehr. Da gibt es den Cloud-Hypervisor von Intel. Und da gibt es den Firecracker, der hinter Amazon's Serverless Computing steht. Da gibt es Cross-VM von Google Chromebooks. Und das KVM-Tool, was so ein bisschen eine kleinere Qimo-Alternative ist. Ja, und die simulieren nicht alle einen kompletten PC. Also eher die wenigsten, sondern die bieten eben diese Wirterei-O-Schnittstellen. Und das sind alles sogenannte Typ 2-Hypervisors. Die werden also wie ein normales Programm auf jenuchs gestartet. Starten dann in diesem Programm des Gastsystems. Das ist ein Unterschied zu den Typ 1-Hypervisors, die gleich beim Buten gestartet werden vor so einem Linux-Hosystem. Das kennt ihr vielleicht von Xen. Das gibt es schon eine ganze Weile. Bei Xen gibt es immer die Domain 0, die Zugriff über den ganzen Rechen hat und alles steuern kann. Aber hier machen wir die Typ 2-Hypervisors und die laufen auf Linux. Und ja, das ist die Wahl, die euch die Flake gibt. Und dazu mit einer einheitlichen Konfiguration, sodass ihr mit einer Einstellung zwischen diesen fünf Hypervisors wechseln könnt. Natürlich mit ein paar kleinen Einschränkungen, denn nicht alle Hypervisors können alle Features. Und wie funktioniert das? Man bindet das Micro-VM-Modul aus der Pflege ein. Das greift auf das von euch definierte NixOS-System zu. In dem NixOS-System gibt es das Datei-System an sich und das Kernelpaket. Und all das wird miteinander kombiniert in ein Paket, das ich einfach Runner genannt habe, weil es wirklich einfach nur ein ShareScript, das dann diesen Hypervisor startet mit Angabe des Kernels und des Route-Datei-Systems. So, wie beginne ich so eine Micro-VM? Da habe ich schon ein Template, also eine Vorlage angelegt, die man einfach so starten kann. Und das sieht dann ungefähr so aus. So sieht so eine Pflege aus. Da habe ich die Inputs, die dann in der Lockfile landen. Und ich habe die Outputs. In den Outputs definiere ich eine NixOS-Konfiguration, also ein Betriebssystem, das ich hier myMicro-VM nenne. Ich importiere das Modul von der Micro-VM-Pflege und dann setze ich nach einzelner Einstellung, wie es soll ein Hostname geben, also das System hat einen Namen. Es soll in einem Q-Emulaufen, also 4 rituelle Kerne haben und 2 Gigabyte RAM. Ja, und das ist schon mal eine minimale Konfiguration. Das sind übrigens alles diese NixOS-Module, also das ist ein einzelnes Modul und das ist ein einzelnes Modul. Und ich könnte noch weiteren zufügen und die können auch auf sich zugreifen, indem sie eben diesen Konfig-Parameter auswerten, den ich hier aber ausgelassen habe, denn er ist nicht benötigt. So, und das bietet mir, das baut mir dann, was ich hier importiert habe, so ein Rannerpaket, um den Hypervisor zu starten. Das werde ich auch gleich zeigen, aber vor und nach ein paar kleine Details. Ich kann virtuell Festplatten, also Dateien, Blogs, Devices, kann ich reinreichen. Die können dann wie eine normale Festplatte in dieser Micro-VM gemountet werden, um pesitente Daten zu haben. Das ist aber ganz schön unflexibel, weil man eben die Größe vorher angeben muss bei so einem Blog-Device. Dafür hat man aber alle Data-System-Features und es ist ziemlich schnell durch diese Word.io-Blog-Schnittstelle. Eine Alternative dazu sind die shares. Da kann ich einfach die Verzeichensbäume reinhängen. Das geht zum einen über das neuen P-Protokoll, was einige Hyper-Weises auch schon implementieren, so im Prozess. Und alternativ gibt es auch das Word.io-FS, das ist schneller. Dafür braucht man aber einen extra Diemen, der wird auch mitgeliefert. Der wird aber nur gestartet, wenn man die Micro-VMs per System die startet und nicht als Paket, wie ich das gleich vorführen werde. Und es gibt auch die Option, dass man den Slash-Nix-Slash-Store vom Host reinmountet. Dann muss nicht mehr als guter Teilsystem ein großes Scrash-FS oder ROFS gebaut werden, was mehr als 100 Megabyte groß ist bei NixOS, sondern dann wird nur ein kleines Scrash-FS mit dem Inlet-RAM-FS, also kein Inlet-RAM-FS, mit der Boot-Disk gebaut, das sind dann nur 10 Megabyte. Netzwerk kann man natürlich auch haben, indem man Netzwerkschnittstellen spezifiziert. Am bequemsten ist das User-Networking. Das sieht man ja im Type User. Das können aber leider nur QEMO und KVM. Das ist diese coole Funktionalität, dass der Hyper-Weise den Netzwerkverkehr entgegen nimmt, versteht, also die Verbindungen akzeptiert und dann in Sockets auf dem Host-System übersetzt. Was aber alle haben, sind die Tab-Devices, die als Tunetab kennt, vielleicht von OpenVPN, das sind eben virtuelle Ethernet-Schnittstellen. Und das Handbuch zur Pflege beinhaltet auch ein Beispiel-Setup auf Netzwerke basierend. Gut, kommen wir zur Demo. Ich habe mich vertippt, ich habe gerade noch ein leeres Verzeichnis. Die Pflege wird runtergeladen. Genau, da sind auch Cash-Einstellungen drin, das brauche ich jetzt fürs Template nicht. Aber bevor ihr euch einen eigenen Kernel bauen müsst, könnt ihr auf diesen Cash-by-Cash-X zugreifen. Jetzt habe ich hier eine Pflege-Nix, die so aussieht wie gerade im Beispiel und die kann ich jetzt auch gleich ausführen. Dann wird ein bisschen was runtergeladen. Ich hoffe, ich habe jetzt schon alle Bineries auf meinem Laptop, sodass das nicht so lange dauert. Ansonsten können wir das auch einfach laufen lassen. Ich zeig das mal, wie das Cash-Doss sieht. Genau, das ist aus meinem lokalen Check-Out der Pflege. Da gibt es eben schon die Pflege-Log von all den Paketen, die ich schon auf meinem System habe. Und jetzt wird hier noch ein bisschen was zusammengebaut und gleich wird gel-startet. Und da haben wir eine viertelte Maschine in einem QEMU. So, das war als Paket, was einem schon mal ein bisschen Flexibilität bietet. Aber es gibt noch mehr Möglichkeiten, die Micro-VMs zu benutzen. Wir hatten das Micro-VM-Modul, was in den Micro-VMs selbst importiert wird. Wenn man das Micro-VMs ausführen soll, gibt es das Host-Modul. Und da kann man im Host, kann man die Micro-VMs auch so deklarativ bestimmen, was ein bisschen meinem eigentlichen Ziel widerspricht. Das sehe ich eigentlich nur vor für besonders wichtige VITL-Maschinen, die zum Beispiel die Netzwerkverbindung bereitstellen sollen. Denn tatsächlich ist es so, wenn ich jetzt irgendwie 20 Micro-VMs in meinem Hostsystem mit deklariert habe, dann braucht eben das bauen des Hostsystems bis zu 20-mal so lange. Und braucht auch ganz viel Speicher. Und das ist ganz schön umtraktisch. Deswegen gibt es den Micro-VM-Komand. Dazu gleich, wenn ich dieses Host-Modul hab, dann bekomme ich System-Deservices, das sind Templates-Services, die können für jede Micro-VM, können gestartet werden. Und was sie einfach noch tun ist, die lesen den Zustand in Valib Micro-VM, die abgelegt werden. Und damit entkoppel ich den Zustand der Micro-VMs vom Host. Also, wenn ich dann den Host neu baue, die Services ändern sich nicht groß, dann müssen auch die Micro-VMs nicht neu gestartet werden. Genau. Und wenn ich das nicht deklarativ vom Host angeben will, dann habe ich so ein Chess-Grid geschrieben, dass ich den Micro-VM-Komand nenne. Und da kann ich einfach zur Laufzeit dann Micro-VMs erstellen, updaten, mehr anzeigen lassen. Hier zum Beispiel, das ist auch unsere Infrastruktur. Da habe ich jetzt hier Micro-VM-L gemacht. Standard-Fehlausgabe habe ich mir umgeleitet, weil es da ein paar Warnungen noch gibt in unseren NextOS-Konfigurationen. Es sind eben viele Systeme. Und hier siehst du ein bisschen, was gerade aktuell ist, auf welcher Version, was neu gebaut werden muss und was auch neu gestartet werden muss. Und ja, ich finde es schon ganz schon übersichtlich, leider braucht das eine ganze Weile, um diese Liste zu bringen, um einander all diese Micro-VMs evaluiert. Noch nicht gebaut, aber zumindest die Nix-Sprache evaluiert. Genau, kommen wir zum nächsten Demo. Meine Pflege hat auch so ein Beispiel drin. Genau, ich fahre die Micro-VM mal wieder runter. Achtung, nur der Cloud-Hyperweise unterstützt so einen Power-Off. Alle anderen müssen mit Reboot abgeschaltet werden. Und statt meinem QEMO-Example habe ich hier das VM-Example. Also vor der Route, das ist die Pflege im aktuellen Verzeichnispunkt. Nach der Route ist, was in der Pflege drin ist und da habe ich eine App VM. Und diese startet mir ein QEMO gleich, jeden Moment. Und jetzt zeige ich die ganze Zeit QEMO und das ist ja langweilig. Hier seht ihr schon, in diesem QEMO laufen nested fünf andere Hypervisors, nämlich die fünf verschiedenen. Genau, hier laufen die fünf und die haben auch Netz. Und die haben sich bei mir eine DHCP-Adresse geholt, genau. Und jetzt können wir uns darauf einloggen, zum Beispiel die 110. Und das ist das NextOS im KVM-Tool. Und das können wir jetzt mit jedem dieser nested Virtual Machines machen. Das ist der Firecracker. Gut, zurück zum Vortrag. Es gibt also verschiedene Wege, eine Micro-VM auszuführen mit der Pflege. Um ein bisschen die Vielseitigkeit und Wiederverwendbarkeit von NextOS zu reflektieren. Also der erste Weg ist, aus einem Paket das auszuführen. Vorhin habe ich mit nix ran gemacht, mit nix Bild kriege ich diesen Resalt im aktuellen Verzeichnis, worauf ich denn zugreifen kann. Wenn man einen Server betreibt und das Host-Modul importiert in seine NextOS-Konfiguration, dann hat man die Möglichkeit, das deklarativ zu machen. Aber wie gesagt, das kann eben unter Umständen zu langen Bauzeiten führen. Man kann imperativ den Micro-VM-Komand benutzen, um eben die Micro-VMs entkoppelt zu behandeln. Und letztens habe ich noch so einen Bild-VM-Komand geschrieben, mit dem Ziel mal zu zeigen, dass man diese NextOS-Systeme von den Micro-VMs auch bauen kann und dann trotzdem den Hypervisor benutzen. Denn der Hypervisor ist ja ein Programm, das auf dem Host ausgeführt wird, das wird man auf keinen Fall aus einer unvertrauten Quelle haben. Mir ging es also um die Wiederverwendbarkeit und tatsächlich kann man damit auch noch mehr bauen und das kann ich euch auch gleich mal ein bisschen zeigen. Zum Beispiel haben wir ein Setup für Hochverfügbarkeit hier. Zumindest habe ich das mal ein bisschen gestartet und es läuft immer besser, komplett rund. Genau. Für die Hochverfügbarkeit will man die Micro-VMs auf beliebigen Servern starten. Dazu muss natürlich das Netzwerk auf den Servern gleich aussehen. Das machen wir einfach mit Bridges und der Storage für die persistenten Daten synchronisiert werden, also mit einem Netzwerk-Datei-System, so dass, wenn die Micro-VM auf einem anderen Server gestartet wird, nicht die Daten alle weg sind, aber dafür nutzen wir ClusterFS, weil das wirklich schön einfach war. Das ist die Software Nomad. Das ist so ein Cluster-Major. Hier haben wir jetzt schon zwei Micro-VMs, die nicht so wichtig sind in dem Cluster laufen. Mach ich nochmal Vollbild hier. Bei dem Nomad gibt es die Server. Das sind die, die sich vor allem untereinander koordinieren, dass eben nichts ausfällt. Das sollten natürlich drei sein. Wenn es zwei sind und einer ausfällt oder das Netzwerk getrennt wird, dann weiß der eine nicht, ob der andere jetzt ausfällt oder ob er selber vom Netzwerk getrennt worden ist. Deswegen mindestens drei oder eine ungerade Anzahl. Und die Kleinen sind die, die die Sachen tatsächlich ausführen. Da haben wir jetzt auf beiden Servern jeweils eine Allocation, also eine Micro-VM läuft da. Da können wir jetzt auch gucken. Hier läuft es die Aweb. Das ist wirklich ganz hübsch gemacht. Wir haben eine schöne Visualisierung, welche Teile dieses Jobs gelaufen sind. Also erst mal wurden die Tab-Interferences angerichtet dann wurden die wird IOFS-Demons für die Chairs gestartet und schließlich noch der Haupthyperweise. Und um das jetzt ein bisschen zu demonstrieren, könnte ich jetzt einfach mal sagen, einer dieser Server ist jetzt nicht mehr verfügbar. Den will ich jetzt irgendwie runterfahren. Dann drücke ich auf Drain und dann ist der wirklich gleich leer. Das kann ich hier nochmal auf Jobs schauen. Wo die laufen. Hier sehe ich das nicht. Dann soll der eigentlich hier auf Server 10 hoch kommen. In die eine Richtung hat es vorhin funktioniert. In dem Moment vorhin hat es in beide Richtungen funktioniert. Braucht vielleicht ein paar Sekunden, aber ich hoffe, das ist dann gleich wieder verfügbar. Schade. Ah, da ist er wieder. Oh, ja, es ist natürlich ganz ausgereift, aber durchaus etwas, was man mehr Micro-WM-Nix-Flake basteln kann. Ich kann hier nochmal verfügbar klicken und dann den anderen Serverlehrräumen. Funktioniert hoffentlich, ah, jetzt ist zumindest einer auf Server 9. Gut, also so prinzipiell funktioniert das. Genau, die Zukunft, also man kann das schon ganz gut verwenden. Ich überlege, es gibt Nix Flakes, um Windows zu installieren und deklarativ auszuführen. Es gibt Nix-Code, um zu installieren, ob ich sowas unterstütze. Natürlich gibt es auch immer den großen Wunsch nach anderen Ubuntu's und Debian's, aber die lassen sich eben nicht deklarativ managen. Genau, da habe ich angefangen, mal dieses ShareScript Micro-WM mal ein bisschen neu zu implementieren, dass es nach Schicker und schneller wird. Danke fürs Zuhören, habt ihr Fragen? Genau, vielen Dank, Astro. Gibt es Fragen in der Runde? Vielleicht unsere Nix-Experten sind ja da drüben, die jetzt gern alles auseinanderheben möchten. Nee? Ich glaube, das war ein zu technisches Thema. Das müssen die Leute erstmal verdauern. Ich hatte ja auch schon überlegt zu fragen und es hat sich dann so am Ende so ein bisschen beantwortet, weil wenn ich so auf dieses Thema Container Micro-WM und überhaupt Virtualisierung raufgucke, ich möchte ja eigentlich noch gerne so von unten den Kubernetes-Killer irgendwo haben, weil ich mit dieser Technologie ja doch vertraut bin und das ist ja doch eine nicht unüberschaubare Komplexität. Das ist mir zu viel jammel. Ja, gut, das ist noch mal eine andere Frage. Und da ist ja die interessante Frage, weil wir das mit dem Orchestrieren, das hast du jetzt gerade schon gezeigt mit den Nomads. Deswegen habe ich jetzt keine weitere Frage parat.