 Und wir kommen zu meinem Talk, wie man zum System Engineer wird. Der Talk basiert auf der Erkenntnis, das große Teil der Infrastruktur, die wir heute haben, das World Wide Web, die Cloud und Internet of Things und alles, auf Open Source Software basieren von sofern. Es ist absolut möglich, sich die Kenntnisse, mit der man solche Infrastruktur betreibt, zu Hause durch Bastel am Computer beizubringen. Der Talk ist in zwei Teilen. Zuerst, wie ich euch erzählen, warum ich denke, dass man System Engineer werden will. Und der zweite Teil ist, wie ich denke oder wie ich vorschlage, dass man das angeht, wie man zum System Engineer wird, dann generell der Pfad dahin zur Begriffsklärung. Erstens, wenn ich sage System Engineer, dann meine ich auch immer System Engineerin, wie in einem regulären Ausdruck oben im Titel angedeutet. Ich werde wahrscheinlich trotzdem im Talk über weiter System Engineer sagen, aber bitte fühlt euch doch alle angesprochen dabei. Wikipedia sagt, der System Engineer ist für die Analyse der Kundenanforderungen, der Architektur und des Designs von komplexen integrierten Systemen verantwortlich. Das klingt jetzt erstmal relativ langweilig. Was ich mit dem Wort meine, der Bezeichnung, ist ein System Engineer baut und betreibt Infrastruktur. Das heißt, Netzwerke, also Internet, Wi-Fi, VPN Tunnel und so was. Und er betreibt Dienste, als zum Beispiel Mailserver oder Webserver, Datenbankserver, Chat-Server, all dieses. Und das erfordert natürlich auch immer die Hardware, darunter liegende Hardware zu betreiben. Es gibt auch andere Worte, System Administrator, System Operator, System Architekt. Das ist aber zumindest, was diesen Talk angeht, eigentlich alles erstmal genau dasselbe. Mein Name ist Volkert. Ich bin System Engineer, lange Zeit in Hongkong gewohnt, jetzt in Berlin. Und ja, in meinem Leben schon eine ganze Menge Infrastruktur mit aufgebaut. Wettportale, dann Payment Processing, Dienste, die Kreditkartenabrechnung und so was. Musikfestivals, für Musikfestivals habe ich Netzwerke gebaut. Hier rechts im Bild sieht man mich mit 800 Meter Glasfaserkabel auf den Schultern. Das hat sehr viel Spaß gemacht. Und im Augenblick arbeite ich in der BioIT Branche, Genforsche und Gentechnik. Die brauchen auch erst auch nicht viel Infrastruktur dort. Zum Teil eins, warum man System Engineer werden will. Meiner Meinung nach alles. Es gibt vier gute Gründe dafür. Was erschafft eine bestimmte Job-Sicherheit. Es gibt einem extrem viel Autonomie. Es hilft einem, Daten zu schützen. Es hat eine bestimmte ethische Komponente zur Job-Sicherheit. Es gibt sehr viele Computer mittlerweile, überall auf der Welt. Es gibt sehr viele Menschen, die wollen, dass diese Computer bestimmte Dinge tun. Aber die Menschen können meistens den Computer nicht selber genau sagen, was genau sie denn von ihnen wollen. Das heißt, es werden immer Menschen gebraucht, die das übersetzen. Es wird immer so ans Computer gibt und überall, wo es Computer gibt, wird es jemanden geben, der gerne hätte, dass diese Computer bestimmte Sachen machen, aber nicht genau weiß, wie er das den Computer sagen kann. Und da kommt das System Engineer ins Spiel. Das ist genau die Rolle, die Position, in der man sich da findet. Das heißt, solange es Computer gibt und überall, wo es Computer gibt, ist man in einer ganz guten Position, wenn man der Lage ist, diese menschlichen Anforderungen zu übersetzen, den Computer zu sagen, was sie zu machen haben. Der zweite Teil, warum ein System Engineer werden will, ist die Autonomie, ein ganz wichtiger Punkt. Egal, was man jetzt von Bitcoin oder Wikileaks oder Silk Road hält, aber diese Services haben oder sind noch dabei, die Welt zu verändern. Die haben ganz klar messbare Effekte auf die Gesellschaft und auf die Welt um uns herum. Und diese Netze und Dienste erfordern Infrastruktur. Auf irgendwelchen Computer müssen die Dienste ja laufen. Diese Infrastruktur erzeugt eine Abhängigkeit. Wenn ein Dienst auf Amazon läuft oder auf Google, dann ist der Betreiber des Dienstes von Amazon oder Google abhängig. Das heißt, man kann bestimmte Sachen nicht machen, wenn Amazon und Google das so nicht wollen, wenn ein Konkurrenz zu denen steht oder vielleicht politisch gegen die argumentieren will oder um seine eigene Infrastruktur hat und schafft das Unabhängigkeit, dann kannst du erst mal machen, was du willst. Du bist nicht direkt von dem Infrastrukturbetreiber abhängig. Und je nachdem, bei welchem Level man das führt, wie viel der eigene Infrastruktur man selber betreibt, kann man immer noch ein erstaunliches Maß an Unabhängigkeit erreichen. Und das ist schon ein erstaunlicher und erstaunlich wichtiger Aspekt. Denose wichtig ist der Datenschutz. Alle Netzwerkdienste erzeugen Nutzerdaten bei Definitionen. Und der Schutz dieser Daten, die Vertraulichkeit, dass niemand die Daten sieht, der nicht soll, erfordert, dass du deine Infrastruktur vertraust, auf der die Dienste laufen. Und damit du deine Infrastruktur vertrauen kannst, musst du den Menschen vertrauen, die den Zugang zu den Maschinen haben. Damit fängt das alles an. Wer halt physischen Zugang zu einer Maschine hat, hat wahrscheinlich auch Zugang zu den Daten. Man kann dann noch mit Krypto ein bisschen was dagegen machen und so. Aber schlussendlich kannst du einem System nur vertrauen, wenn du das selber aufgesetzt hast. Das heißt, es muss ein System sein, das du schon angefasst hast. Das wurde nur du physisch oder deine vertrauten physischen Zugang zu haben und halt nicht in den Cloud Server. Ansonsten ist das mit dem Datenschutz schwer. Und der vielleicht wichtigste Punkt, das gibt auch eine ethische Dimension. Deswegen, dass bestimmte Leute Systemingenieur werden sollten, jedes System betrifft direkt oder indirekt Menschen. Das kann sein, dass die Menschen direkt den Service nutzen, weil es halt Gmail ist oder Facebook und die Menschen direkt damit interagieren. Aber auch Systeme, die jetzt für die Supermarkt-Belieferung oder den Busverplant zuständig sind, haben direkt oder indirekte Auswirkungen auf die Gesellschaft und auf Menschen um uns herum. Sofern ist da eine große Verantwortung, diese Systeme zu betreiben, je nach System. Und kein System ist ethisch komplett neutral. Ihr Systeme sind immer Ausdruck von bestimmten Willen, von Menschen, die irgendwas erreichen wollen, die irgendwas im bestimmten Ziele haben. Diese Ziele sind entweder gut oder schlecht oder halt eigennützig oder altruistisch, haben aber auf jeden Fall bestimmte ethische Qualität. Und die Systeme machen nur, was Systemingenieure ihnen sagen, dass es wichtig zu erkennen. Die Leute, die das System besitzen, die das Geld ausgegeben haben, die können dem System schlussendlich nicht sagen, was es zu tun hat. Das kann nur der Mensch, der sich wirklich, wirklich mit der Technologie auskennt. Das ist der Systemingenieur. Systemingenieure machen hoffentlich nicht alles, was man ihnen sagt, weil Systeme so mächtig sind, so viel Einfluss auf Menschen haben. Es ist wichtig, dass die Leute die schlussendlich sagen, was das System zu machen hat und was nicht schlaue, nette Menschen sind, die sich über Gesellschaft Gedanken machen und so weiter. Man darf das halt nicht irgendwelchen langweiligen Spießern überlassen, das ganze Thema. Die DAP Bewegung in Jamaica hat schon vor langer Zeit rausgefunden. Der Unico-System ist das Sound-System. Und das, denke ich, sollte als Warnung für alle Systemingenieure gelben. So viel zum ersten Teil. Wie gesagt, es gibt dafür meiner Meinung nach wichtige Gründe, weswegen ein Systemingenieur so wichtig ist. eigene Job-Sicherheit, das ist sehr hilfreich. Es gibt dir ein erstaunliches Maß an Autonomie. Es ist notwendig, um deine Daten zu schützen, deine Mutzerdaten zu schützen. Und es hat eine ethische Komponente, weil man nicht irgendwelche Leute an den Maschinen sitzen lassen will, schlussendlich. Dann kommen wir zu Teil zwei. Wie wird man ein Systemingenieur? Er ist ja eine komplexe Welt. Es gibt sehr viele Technologie, sehr viele Stacks, verschiedene Hardware und Software-Systeme und Dienste. Es ist auch sehr schwer, das zu navigieren. Und die Idee ist, mach so viel wie möglich selbst. Machst dir dabei nicht zu einfach. Und lerne die Kultur der entsprechenden Software. Das ist damit meine. Du solltest alle Dienste, also das in deinem Leben, benutzt eine ganze Menge Dienste schon sowieso. Du hast eine Mail-Adresse wahrscheinlich, du benutzt einen oder mehrere Chat-Services. Du hast vielleicht deine eigene Website und du nutzt vielleicht sowas wie GitHub oder GitLab und dann SoScout und dann den Menschen zu teilen. Und als Systemingenieur will man das eigentlich alles selber machen. Wenn man selber die Dienste betreibt, die man auch benutzt, so viel das möglich ist, hat man automatisch in seinem Leben die Infrastruktur und die Kenntnisse, die einem ein Systemingenieur machen. Das heißt, das Ziel sollte sein, wenn du Systemingenieur werden willst, das Ziel sollte sein, alle Dienste, die du nutzt, so viel wie möglich selber zu betreiben. Und das kann man heutzutage sehr gut machen. Es gibt sehr viele schöne kleine Singleboard-Computers. Raspberry Pi kennt ihr alle. Es gibt von PC-Engines die APU-Serie. Es ist auch nicht viel größer. Es kostet doch alles nicht so viel Geld. Das sind Systeme, Computer, mit denen man schon sehr viel machen kann, was dann auch gar nicht so anders ist, als wie das im Datencenter für globale Infrastruktur auch aussieht. Also was ich meine ist, wenn du deine eigene Website haben willst, hast du ja verschiedene Optionen und kannst entweder dir eine Website bei WordPress klicken und dann lernst du halt WordPress, sonst nicht viel. Du kannst aber auch dir ein Cloud-Server klicken bei Amazon oder bei DigitalOcean. Vorkonfiguriert, da ist dann der Web-Server schon dabei und die Datenband und die Zertifikate funktionieren schon und alles. Das ist schon ein bisschen besser als WordPress, weil dann lernst du immer noch, wie du dich auf diesen Server connecten musst, kannst mit SSR. Und du lernst ein bisschen was über die Konfigurationen, weil du jetzt z.B. den Namen, die Webseite durchaus noch anpassen musst. Aber das meiste wurde halt schon fertig gemacht. Du kannst deswegen auch einfach der Raspberry Pi kaufen, darauf Linux installieren und dann dieses Linux so konfigurieren, dass deine Webseite draufläuft. Das heißt, du installierst dann, du musst erstmal verstehen, wie du in Linux auf dem Raspberry Pi installierst. Da musst du verstehen, wie du dich überhaupt darauf verbindest und dann musst du den Web-Server oder die Zertifikate und die Datenbank alles installieren und konfigurieren. Das ist natürlich deutlich mehr Arbeit. Aber wenn du das gemacht hast, dann läuft deine Webseite auf deinem Raspberry Pi. Das heißt deine eigene Infrastruktur. Und du hast auch verstanden, wie du das nochmal machen kannst. Oder ein anderes Beispiel. Jeder hat ja ein Home-Router zu Hause, der über DSL im Internet hängt und über den sich dann alle deinem Telefone und Laptops ins Internet verbinden. Und da gibt es auch wieder verschiedene Optionen. Du kannst ja entweder eine Fritzbox kaufen und dann die Fritzbox-Software benutzen. Und dann kannst du halt Fritzboxes auch nicht schlecht, das ist alles recht stabil gemacht und ein bisschen was lernt man ja schon noch über das Netzwerk, wenn man sich damit beschäftigt. Man kann allerdings auch sagen, installiert OpenWRT auf der Fritzbox. OpenWRT ist ein Netzwerkstack, OpenSource-Netzwerkstack, der für solche Home-Router entwickelt ist. Wenn man das macht, lernt man OpenWRT und nicht die Fritzbox und halt ebenfalls eine Menge über TCP-IP-Netzwerke. Und das hat dann den Vorteil, dass OpenWRT auch auf andere Hardware läuft, nicht nur auf Fritzboxen, sondern auch auf Linksys oder Netgear oder anderen Routern. Das ist halt OpenSource-Software. Das heißt, du kannst es auch dann in zukünftigen Projekten kommerziell oder für gemeinnützige Sachen verwenden. Oder du kaufst ja diese APC-Engine APU 2 und installierst da BSD drauf und konfigurierst dein Netzwerk einfach selber. Dann lernst du halt, wie du dich überhaupt mit der seriellen Konsole auf die APU connectest, weil die haben keinen Monitor und keine Tostatur. Du lernst, wie du BSD installierst. Du lernst, wie du Interfaces konfigurierst und dein Wi-Fi Access Point und du lernst, wie die Firewall funktioniert und dein DHCP Server und dein DNS Server und auch noch den ganzen Kram über Netzwerk. Das heißt auch wieder, nicht so einfach wie die Fritzbox, dauert deutlich länger. Aber wenn du das machst und danach betreibst und auch am Laufen hältst, dann hast du halt eine ganze Menge Sachen gelernt, die du über die Fritzbox nie hättest lernen müssen, weil das alles schon automatisch von haus aus funktioniert. Der zweite wichtige Punkt ist, machst dir nicht so einfach. Wenn du irgendwas konfigurierst, nicht immer den einfachsten Weg wählen, sondern den Weg, wo du am meisten lernst und verstehst. Das heißt spezifisch, Text ist immer besser. Benutzt die Kommandozeile statt dem kraftlichen Wunsch zu Interface, weil das später die Automatisierung erleichtert. Und die Kommandozeile hat auch viel mehr Optionen, als die GUID meistens. Das ist auch einfacher in der Kommandozeile Fehlermeldungen zu sehen und die dann zu googeln. Und Webguards generell gehen auch sehr häufig kaputt. Irgendwann ist dann die Java-Version out of date und dann funktioniert die Webgui gar nicht mehr. Eine weitere Challenge wäre, wenn du ein Raspberry Pi auf dem Tisch stehen hast, versuch, den einfach ohne Tastatur und Monitor zu betreiben. Einfach nur über Text, über serielle Konsole oder über SSH, aber halt einfach mal so tun, als hättest du gar keinen Tastatur in deinem Internet gehen. Und mit dem Raspberry Pi, das ist dann so ähnlich wie, wenn der schon im Datencenter steht. Andere Sachen sind Konfig-Files. Viel Software kannst du einfach ohne viel zu machen, installieren, weil es Konfigurationsassistenten gibt. Man wird dann immer gefragt, ob er aufgefordert, einfach eine Detail aus dem Internet zu laden, die dann direkt mit BESCH auszuführen und danach aus dein JITSI-Server fertig konfiguriert oder so. Da lernst du aber auch nichts bei. Guck dir lieber die Konfig-Files an selber und setz da die Optionen, die du willst. Das erleichtert dir die Wiederverwendung, wenn du einmal ein Konfig-File verstanden hast und kannst du das selber als Vorlage nehmen für alle zukünftigen Projekte, wo du dieselbe Komponente wieder brauchst. Konfig-Files haben auch wieder deutlich mehr Optionen als solche Konfigurationsassistenten. Das heißt, du kannst viel mehr tweaken, viel mehr customisen und ebenfalls wieder einfacher da auf Google oder Stack Overflow Beispiele fürzufinden, weil du nach den Texten im Konfig-File suchen kannst. Und noch, wenn du das alles so machst, wenn du die Kommandezeile benutzt und Konfig-Files, wirst du feststellen, dass manche Sachen dauern und manche Sachen gehen relativ schnell. Das Ziel sollte immer sein, dass alles automatisiert ist, was zu viel Zeit kostet oder zu viel Aufmerksamkeit. Das heißt, solltest du deine die Kommandos, die du in der Form des Skripten hast. Es gibt auch Toolings, z.B. Ansible und Solstack, das dir dabei hilft. Du willst das prinzipiell vermeiden, dass du dieselbe Sache immer wieder, wieder, wieder selber händisch machen musst. Du willst das prinzipiell alles nur einmal machen und danach ist es automatisiert und du kannst es ohne dich drum zu kümmern, jederzeit nochmal ausführen. Und genauso sollte es dir wichtig sein, dass du eskalieren kannst. Dass du deine Computer hast oder ganz viele, auf der dein Website laufen soll oder egal ist, ob du einen Benutzer hast oder ganz viele, die dazu Griff haben sollen. Es ist erst mal, wenn du deine eigenen Dienste für dich selber betreibst, nicht notwendig. Da ist die Automatisierung eher hinderlich, weil es geht schneller, das einfach einmal selbst zu machen und deinen eigenen Benutzer für dich selbst anzulegen auf deinem eigenen Raspberry Pi. Das geht schneller, aber wenn du das alles von Anfang an schon auf Automatisierung und Skalierung auslegst, dann kannst du halt auch ohne Weiteres, was für andere Menschen machen mit anderen Systemen später. Sehr dritte wichtige Punkt. Das ist eine Erkenntnis, die mir leider viel zu spät gekommen ist. Das ist etwas, was ich viel lieber früher verstanden hätte, weil es doch sehr viel hilft. Es gibt sehr viel Software. Erstaunlich viele. Textex, Zertifikat Authorities und Monitoringsysteme und Datenbanken und Betriebssysteme, Hypervisors und Webservers, verschiedene Arten von Tooling und Containerization. Das ist alles sehr verwirrend, aber es ist so wichtig zu erkennen, all diese Software ist von Menschen, von Gruppen von Menschen geschaffen. Und diese Gruppen von Menschen haben ihre eigene Kultur, ihre eigene Sprache. Das heißt, die haben spezifische Artenweise, wie sie abstrakte Konzepte wählen und sie haben spezifische Wahl von Namen in ihrem Projekt. Und sie haben natürlich unterschiedliche Arten von Sintarts. Die Raute bei Python was anderes ist als die Raute bei C++. Und dann mehr ist die Sprache und die Kultur versteht. Versteht mir die Software dahinter deutlich einfacher. Also zum Beispiel jede Komponente an Betriebssystemen wie BSD oder Ubuntu oder Tooling wie Docker oder Git oder Ansible. Oder halt auch so was wie der TCPIP-Standard. Haben alle ihre eigene, ihre eigene Terminologie mit der sie daherkommen. Und die Wörter sind begrenzt. Es gibt nicht so viele verschiedene Wörter im Englischen, dass jedes Tool seine eigene Wörter hat, die sonst nirgendwo verwendet wurden. Das Problem ist, manchmal benutzen die Tools dieselben Wörter und die meinen auch prinzipiell dasselbe. Manchmal benutzen sie unterschiedliche Wörter, prinzipiell aber für dieselbe Sache. Und manchmal benutzen sie auch dasselbe Wort, meinen aber komplett unterschiedliche Sachen damit. Also zum Beispiel Docker pull, das ist schon dasselbe wie Git pull. Du ziehst dir halt ein Docker Image oder ein Git Repository Update von dem Server, wo du das ursprünglich her hast. Oder Git tag und Docker tag. So ein Prinzipiell dasselbe. Du machst halt, vergibst einen Namen für ein Image Layer oder für ein Git commit einen menschelesbaren Namen. Das ist schon vergleichbar. Enzybil tags wiederum sind was komplett anderes. Das hat überhaupt nichts damit zu tun. Das sind eher sowas wie Gruppen oder Rollen, die den Enzybil als tag beschreibst. Hat aber denselben Namen wie Docker tag und Git tag. Deswegen recht verwirrend. Anderes Beispiel ist die TCP IP. Gibt es das Konzept von einem Port, also Teil der Netzwerkadresse einer TCP-Verbindung. Das hat aber nichts mit einem OpenBSD-Port zu tun. Ein OpenBSD-Port ist eher sowas wie ein Ubuntu Package. Heißt aber nicht Package, sondern Port. Insofern alles sehr verwirrend und die beste Art und Weise das zu navigieren, meiner Meinung nach ist, zu verstehen, dass das alles Gruppen von Menschen sind und innerhalb dieser Kultur Port dann was anderes bedeutet, als in der anderen Kultur. Es ist sehr viel Hilf zu verstehen, aus welcher Kultur Menschen kommen und zu verstehen, was sie jetzt gerade meinen, wenn sie Port sagen. Das waren meine drei Vorschläge die ich jetzt machen will. Man sollte seine eigenen Dienste hosten und möglichst viele davon selber machen. Man sollte sich nicht so einfach machen, sondern halt alles automatisieren und skalieren. Man sollte sich mit der Kultur beschäftigen, damit man einfache versteht, zuordnen kann, was die einzelnen Projekte meinen. Aber wenn man das alles macht, dann kommt man auch, dann ist man eigentlich schon fast da. Wenn dein Website auf Raspberry Pi läuft und dir dein Website automatisch auf viele verschiedene mehrere Raspberry Pi ausrollen kannst, dann ist das nicht so viel anders, als was im Datencenter auch läuft. Das läuft auch nur UNIX. Und wenn das Tooling stimmt, wenn man das Gipfel stimmt und eine Prozesse, dann ist der Vorgang, das auf Raspberry Pi zu machen, sehr ähnlich zu dem, wie du das halt in einem Datencenter machst. Egal, ob es dann ein Server ist oder auch ein Problem, wie von einem auf mehrere Raspberry Pi zu gehen. Das ist alles nur UNIX. Und was man zu Hause mit Raspberry Pi macht oder mit APU, kann man sehr gut als Verwendung geselben Skills, geselben Techniken um dann im Datencenter ein Servers zu betreuen. So viel zu meinem Talk. Wir machen jetzt, glaube ich, noch eine kurze Fragerunde. Danke sehr. Ich würde gerne live im Studio begrüßen zu können. Vielen Dank für deinen Vortrag. Da habe ich ja gleich fast selbst Lust gekriegt, auch noch System Managerien zu werden. Was denkst du denn, was braucht man da so für Fähigkeiten, Kenntnisse, Interessen? Gute Frage, weil ich nicht darauf vorbereitet. Ich würde prinzipiell sagen, Spaß und Faszination an Computern hilft natürlich. Das ist aber für viele andere Sachen auch der Fall. Bei mir war es eher so, ich bin da auch automatisch reingekommen, weil ich immer ein Computer vor mir hatte, mit dem es dann irgendwas zu machen gab. Auch wenn ich mich über irgendetwas anderes informieren wollte, war immer der Computer noch davor, dazwischen mir und dem Ding. Dann habe ich erst mit mich immer im Computer gekümmert und den dann erstmal richtig konfiguriert. Das macht, was ich will. Insofern ist es weniger eine Fähigkeit, als vielmehr so die Unfähigkeit, als immer das Bedürfnis, da immer weiter zu drehen und immer alles noch ein bisschen besser, noch ein bisschen idealer zu machen. Die am meisten hilft, denke ich. Verstehe. Da gibt es direkt auch eine Anschlussfrage von unseren Zuschauerinnen, nämlich, wie geht man denn wohl am besten tiefer in die Materie? Wenn man sich schon so ein bisschen mit Sachen beschäftigt hat, was ist denn wohl ein guter Ansatz und ein bisschen tiefer einzusteigen? Gute Frage. Also prinzipiell immer Leute, andere Leute hoffentlich, also idealerweise Leute im selben Alter mit dem selben Erfahrungsstand, also quasi auf dem selben Level sind, mit dem man dann gegenseitig sich gelernt und fordert und so, also generell eine Gruppe zu finden, die im selben Interessen hat. Das ist, denke ich, das Wichtigste. Das macht dann meistens Spaß und bringt auch am meisten. Dafür ist natürlich Remote Chaos Congress eine sehr gute Sache für die STC bei euch in der Nähe oder was immer der Hacker Space, aber generell halt ähnlich gesündete Menschen, die da genau dieselben Interessen haben und auf dem selben Level sind, was man zusammenlernt und natürlich dann auch mit Leuten, die das auch schon alles ein bisschen länger machen, die ebenfalls zum Beispiel auf dem Congress ansprechbar und aufzufinden sind und die sich auch, denke ich, immer freuen, Fragen zu beantworten, gerade von jüngeren Leuten, die vielleicht gerne auch dieselben Sachen lernen würden. Dann haben wir noch eine Wording-Frage. Ist Software-Engineering das Gleiche wie DevOps oder gibt es da noch Unterschiede? Gute Frage. DevOps habe ich und Full-Stack-Engineer oder Full-Stack-Developer, gibt es ja beides, sind beide in letzter Zeit, das sieht man, die häufige, einen richtigen Job anzeigen. Prinzipiell dasselbe, aber DevOps ist ein bisschen, also DevOps müssen sich das in meiner Technik zu beginnen auffassen, nach auch immer Leute, die dann gleichzeitig noch die Website programmieren, aber trotzdem irgendwie für die Serverkonfiguration zuständig sind, das heißt, die müssen halt programmieren und administrieren. Gleichzeitig sind aber eigentlich ganz unterschiedliche Sachen, insofern wirklich mich selber nicht als DevOps bezeichnen. Auf der anderen Seite könnte ich jetzt auch jederzeit einen Job angeboten, wo DevOps drauf steht, mich einfach melden, wer das Wort wie verwendet. Meistens ist es nur eine Ausrede vom zukünftigen Arbeitgeber, dass die halt nur eine Person bezahlen wollen für zwei oder drei Jobs, deswegen sind das DevOps oder Full-Stack. Das klingt nicht so richtig attraktiv. Zum Job einsteht, gibt es auch noch eine Frage. Hast du Tipps, wie man das mit Praktika an geht, wie man da so anbesten angepatscht, irgendwelche Erfolgrechts-Tipps? Nein, leider nichts Konkretes, aber das ist eine gute Frage, die man vielleicht auf dem Rahmen des Konkretzes noch mal irgendwie klären kann, weil es in der Tat auch in meinem direkten Freundeskreis und bei Wikipaker genug Leute gibt, die sehr viel Spaß und so was haben und auch die Infrastruktur haben, wo man dann Praktikas anbieten könnte und jetzt was versprechen zu wollen, aber da arbeiten Leute schon dran, insofern anbesten mit Wikipaker in Verbindung setzen, oder halt mich ansprechen in der ID-Welt, wir haben ja auch die Wikipaker-WG abgebildet, vielleicht findet man dich da ja noch mal. Zum Beispiel, ja, ich werde auf jeden Fall auch umhängen. Einfach los sorgen, bitte. Ich habe noch eine Frage aus dem Publikum und ich hoffe, dass ich das jetzt richtig ausspreche. Was sagst du von Kubernetes und Konsorten, ist das die Zukunft oder eher sowas mittelfristig gehyptes? Das kann durch das Beides gleichzeitig sein. Also generell, Containerisation ist auf jeden Fall eine praktische Sache. Das sind ja prinzipiell ähnliches Konzept wie Jails, also Change Rule Jails und der Linux oder Jails und der BSD und Container machen das ganze Konzept noch ein bisschen einfacher. Insofern, das bleibt auf jeden Fall, ob das jetzt Docker ist oder Kubernetes, wird man sehen. Ich hoffe eher auf Kubernetes. Generell ist diese Technologie halt das Einzige, wie man wirklich so Scharen von Mikroservices und Computer einfach deployen kann. Also wenn man jetzt nicht erlang programmiert oder so, sondern halt so einen typischen Linux und Engine X und Lamp und PHP und Python Stack hat, dann brauchen wir schon irgendein Containersystem und mehrere Services, die aufeinander abhängig sind zu deployen. Insofern sollten sich Container auf jeden Fall anschauen. Aber halt vielleicht nicht nur Docker, sondern Kubernetes auch auf jeden Fall. Eine Frage habe ich noch. Was ist das Beste davon, sich alle RFCs runterzuladen und einfach mal drauf loszulernen? Das hätte ich eigentlich wollte. Das ist eigentlich eine gute Frage, danke. Das hätte ich von fastem Vortrag eine extra Folie für gemacht. Das Schöne an der Technologie ist alles Open Source oder sehr, sehr, sehr viel. Das heißt, man kann die Source Code durchlesen und die Kommentare und so. Und die Protokolle sind halt per Definition offen. Also das Allermeiste. Und in der Tat gibt es das bei IETF zum Unterladen und durchlesen. Und das habe ich auch gemacht. Irgendwann nicht als erstes. Dann ist es doch sehr verbirrend und einschichtend. Aber irgendwann ist man auf dem Level, wo man keine Bücher mehr lesen will, sondern halt direkt die Spezifikation, wo das alles herkommt. Vielleicht nicht alle lesen, es sind ein bisschen viele mittlerweile, aber ein paar, also IPv4 und so, auf jeden Fall zu empfehlen. Das muss man mal gemacht haben. Ich habe jetzt aus dem Publikum Fragen und ich habe auch keine mehr meine fragastischen Beantwortung. Es gibt aber die Möglichkeit, wenn es noch weitere Fragen gibt, das auch noch in einem weiteren Big Blue Button mit dir zu besprechen, falls man dich nicht in der 2D-Welt suchen möchte. Und da postet bestimmt mein Kollege Stefan gleich mal den Link für in den Chat. Das heißt, alle, die jetzt noch Fragen haben, können die gerne da loswerden. Und ich würde sagen, wir verabschieden uns hier. Danke. Danke schön.