Wikipaka Intro Musik F: Hallo und willkommen zu meinem Talk, wie man zum System Ingenieur wird. Der Talk basiert auf der Erkenntnis, dass große Teile der Infrastruktur, die wir heute haben, das World Wide Web, die Cloud und Internet of Things und alles auf Open- Source-Software basieren. Insofern ist es absolut möglich, sich die Kenntnisse, mit der man solche Infrastruktur betreibt, zu Hause durch Basteln am Computer beizubringen. Der Talk ist zwei Teilen: Zuerst will ich euch erzählen, warum ich denke, dass man System Ingenieur werden will. Und der zweite Teil ist, wie ich denke oder wie ich vorschlage, dass man das angeht, wie man zum System Ingenieur wird, generell der Pfad dahin. Zur Begriffsklärung. Erstens, wenn ich sage System Ingenieur, dann meine ich auch immer System Ingenieurin. Wie im regulären Ausdruck oben im Titel angedeutet. Aber ich werde wahrscheinlich trotzdem den Talk über weiter System Ingenieur sagen. Aber bitte fühlt euch doch alle angesprochen dabei. Wikipedia sagt: Der System Ingenieur ist für die Analyse der Kundenanforderungen, der Architektur und des Designs von komplexen integrierten Systemen verantwortlich. Das klingt jetzt erstmal relativ langweilig, aber was ich mit dem Wort meine, der Bezeichnung, ist ein System Ingenieur baut und betreibt Infrastruktur. D.h. Netzwerke, also Internet, WiFi, VPN- Tunnel und sowas. Und er betreibt Dienste, also z.B. Mail-Server oder Webserver, Datenbankserver oder Chat-Server, all dieses. Und das erfordert natürlich auch immer, die darunterliegende Hardware zu betreiben. Es gibt auch andere Worte: Systemadministrator, Systemoperator, Systemarchitect. Das ist aber zumindest, was diesen Talk angeht, eigentlich alles erstmal genau dasselbe. Mein Name ist Folkert und ich bin Systemingenieur, hab lange Zeit in Hongkong gewohnt, jetzt in Berlin und hab in meinem Leben schon ne ganze Menge Infrastruktur mit aufgebaut: Webportale, Payment Processing, Dienste wie Kreditkartenabrechnung und sowas, Musikfestival, für Musikfestivals hab 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 Bio-IT-Branche, Genforschung, Gentechnik. Die brauchen auch erstaunlich viel Infrastruktur dort. Zum Teil 1: Warum man System Ingenieur werden will? Meiner Meinung nach alles gibt's vier gute Gründe dafür. Es erschafft eine bestimmte Jobsicherheit, es gibt extrem viel Autonomie. Es hilft einem, die Daten zu schützen und es hat eine bestimmte ethische Komponente. Zur Jobsicherheit. Es gibt sehr viele Computer mittlerweile, überall auf der Welt. Und es gibt sehr viele Menschen, die wollen, dass diese Computer bestimmte Dinge tun. Aber die Menschen können meistens den Computern 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, solange es Computer gibt und überall wo es Computer gibt, wird es jemanden geben, der gerne hätte, das diese Computer bestimmte Sachen machen, aber nicht genau weiß, wie er das den Computern sagen kann. Und da kommt halt der System Ingenieur 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 Computern zu sagen, was sie zu machen haben. Der zweite Teil, warum man System Ingenieur 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 Computern müssen die Dienste ja laufen. Diese Infrastruktur erzeugt ein Abhängigkeit. Wenn ein Dienst auf Amazon läuft oder auf Google, dann ist der Betreiber dieses Dienstes von Amazon oder Google abhängig. Das heißt, man kann halt bestimmte Sachen nicht machen, wenn Amazon/Google das so nicht wollen, weil man in Konkurrenz zu denen steht oder vielleicht politisch gegen die argumentieren will oder so.. Wenn man seine eigene Infrastruktur hat, schafft das Unabhängigkeit, dann kannst du erstmal machen, was du willst. Du bist nicht direkt von nem Infrastruktur Betreiber abhängig. Und je nachdem, zu welchem Level man das führt, wie viel der eigenen 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. Genauso wichtig ist der Datenschutz. Alle Netzwerkdienste erzeugen Nutzerdaten, per Definition. Der Schutz dieser Daten, die Vertraulichkeit, dass niemand die Daten sieht, der nicht soll, erfordert, dass du der Infrastruktur vertraust, auf der die Dienste laufen. Und damit du deiner Infrastruktur vertrauen kannst, musst du den Menschen vertrauen, die den Zugang zu den Maschinen haben. Damit fängt das alles an. Wer 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 mal angefasst hast, wo nur du physisch oder nur deine Vertrauten physischen Zugang zu haben und nicht irgendein Cloudserver. Ansonsten ist das mit dem Datenschutz schwer. Und der vielleicht wichtigste Punkt: Es gibt eine ethische Dimension, weswegen bestimmte Leute System Ingenieur 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 der Menschen direkt damit interagieren. Aber auch Systeme, die jetzt für die Supermarktbelieferung oder den Bus- Fahrplan zuständig sind, haben direkte oder indirekte Auswirkungen auf die Gesellschaft und auf Menschen um uns herum. Insofern ist da eine große Verantwortung, diese Systeme zu betreiben, je nach System. Und kein System ist ethisch komplett neutral. Systeme sind immer Ausdruck von bestimmten Willen, von Menschen, die irgendwas erreichen wollen, bestimmte 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 System Ingenieure ihnen sagen, das ist wichtig zu erkennen. Die Leute, die das System besitzen, die dafür 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 mit der Technologie auskennt. Das ist der System Ingenieur. System Ingenieure machen hoffentlich nicht alles, was man ihnen sagt. Weil Systeme so mächtig sind, so viel Einfluss auf Menschen haben, ist es wichtig, dass die Leute, die schlussendlich sagen, was das System zu machen hat und was nicht, schlaue und nette Menschen sind, die sich über Gesellschaft Gedanken machen usw.. Man darf das halt nicht irgendwelchen Langweilern und Spießern überlassen, das ganze Thema. Die DAP Bewegung in Jamaika hat schon vor langer Zeit rausgefunden: "The only good system is a sound system", und das, denke ich, sollte als Warnung für alle System Ingenieure gelten. So viel zum ersten Teil. Wie gesagt, es gibt da vier, meiner Meinung nach wichtige Gründe, weswegen ein System Ingenieur so wichtig ist: Zur eigenen Jobsicherheit ist das sehr hilfreich. Es gibt dir ein erstaunliches Maß an Autonomie. Es ist notwendig, um deine Daten zu schützen, deine Nutzerdaten 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 2. Wie wird man System Ingenieur? Es ist eine komplexe Welt und es gibt sehr viel Technologie, sehr viele Stacks, verschiedene Hardware und Softwaresysteme und Dienste und Anbieter. Und es ist schon sehr, sehr schwer, das zu navigieren. Und die Idee ist: Mach so viel wie möglich selbst, mach es dir dabei nicht zu einfach und lerne die Kultur der entsprechenden Software. Was ich damit meine: Du solltest alle Dienste... also in deinem Leben benutzt du eine ganze Menge Dienste schon, sowieso. Du hast eine Mailadresse wahrscheinlich, du benutzt ein oder mehrere Chat-Services du hast vielleicht eine eigene Website und nutzt vielleicht sowas wie GitHub oder GitLab, um dein SourceCode mit anderen Menschen zu teilen. Und als System Ingenieur will man das eigentlich alles selber machen. Wenn man selber die Dienste betreibt, die man auch benutzt, soviel das möglich ist, hat man automatisch in seinem Leben die Infrastruktur und die Kenntnisse, die einem zum System Ingenieur machen. D. h. das Ziel sollte sein, wenn du System Ingenieur 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 Single Board Computers - Raspberry PI kennt ihr alle. Es gibt von PC Engines die APU Serie, ist auch nicht viel größer. Das kostet auch 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 Datenzentren für für globale Infrastruktur auch aussieht. Also was ich meine ist: Wenn du deine eigene Website haben willst, hast du ja verschiedene Optionen. Du kannst entweder dir eine Website bei WordPress klicken und dann lernst du halt WordPress, sonst nicht viel. Du kannst aber auch dir ein Cloudserver klicken, bei Amazon oder DigitalOcean, vorkonfiguriert. Da ist dann der Webserver schon dabei und die Datenbank 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 kannst, mit SSH, und du lernst ein bisschen was über die Konfiguration, weil du ja z.B. den Namen, den Inhalt einer Website durchaus noch anpassen musst. Aber das meiste wurde halt schon fertig gemacht. Du kannst deswegen auch einfach den Raspberry PI kaufen, darauf Linux installieren und dann dieses Linux so konfigurieren, dass dein Website drauf läuft. Das heißt, du installierst dann... musst erst einmal verstehen, wie du Linux oft dem Raspberry Pi installierst. Dann musst du verstehen, wie du dich überhaupt da drauf verbindest. Und dann musst du den Webserver und 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 dein Webserver auf deinem Raspberry PI. Das heißt deine eigene Infrastruktur. Und du hast auch verstanden, wie du das nochmal machen kannst. Oder anderes Beispiel. Jeder hat ja ein Home Router zu Hause, der über DSL im Internet hängt und über den sich dann alle deine Telefone und Fernseher und Laptops ins Internet verbinden. Und da gibt es auch wieder verschiedene Optionen. Du kannst dir entweder eine Fritzbox kaufen und dann die Fritzbox-Software benutzen und dann kannst du halt Fritzbox. Das ist auch nicht schlecht, das ist alles recht stabil gemacht und bisschen was lernt man ja schon noch übers Netzwerk, wenn man sich damit beschäftigt. Man kann allerdings auch sagen, man installiert OpenWRT auf der Fritzbox. OpenWRT ist ein Open Source Netzwerk Stack, der für solche Home Router entwickelt ist. Wenn man das macht, lernt man OpenWRT und nicht die Fritzbox. Und ebenfalls eine Menge über TCP/IP Netzwerke. Und das hat dann den Vorteil, dass OpenWRT auch auf anderer Hardware läuft, nicht nur auf Fritzbox, sondern auch auf LinkSys oder Netgear oder anderen Routern. Ist halt Open-Source- Software. Das heißt, du kannst es auch in zukünftigen Projekten kommerziell oder für gemeinnützige Sachen verwenden. Oder du kaufst dir einen dieser PC Engine APU2 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 Tastatur. Du lernst, wie du BSD installierst. Du lernst, wie du Interfaces konfiguriert ist und ein Wifi Access Point. Du lernst, wie die Firewall funktioniert und dein DHCP-Server und dein DNS Server und auch noch den ganzen Kram über Netzwerk, d.h. 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 haste halt eine ganze Menge Sachen gelernt, die wohl über die Fritzbox nie hättest lernen müssen, weil das alles schon automatisch von Hause aus funktioniert. Der zweite wichtige Punkt ist: Mach es dir nicht zu 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. Benutz die Kommandozeile statt dem grafischen Benutzerinterface, weil das später die Automatisierung erleichtert. Und die Kommandozeile hat auch viel mehr Optionen als die GUI meistens. Das ist auch einfacher, in der Kommandozeile Fehlermeldungen zu sehen und die dann zu googeln. Und Web-GUIs sind generell... gehen auch sehr häufig kaputt, irgendwann ist dann die Java Version out of date und dann funktioniert die Web GUI gar nicht mehr. Eine weitere Challenge wäre: Wenn du einen Raspberry PI auf dem Tisch stehen hast, versuch den einfach ohne Tastatur und Monitor zu betreiben, sondern einfach nur über Text. Über die serielle Konsole oder über SSH. Aber halt einfach mal so tun, als hättest du gar kein Tastatur und Bildschirm für den Raspberry PI. Das ist dann so ähnlich, wie wenn der schon im Datencenter steht. Andere Sache sind Config files. Viel Software kannst du einfach ohne viel zu machen installieren, weil es Konfigurationsassistenten gibt. Man wird dann immer gefragt oder aufgefordert, einfach eine Datei aus dem Internet zu laden, die dann direkt mit Bash auszuführen und danach ist dein Jitsi Server fertig konfiguriert oder so. Da lernst du aber auch nichts bei. Guck dir lieber die Config-Files an, selber, und setzt da die Optionen, die du willst. Das erleichtert dir die Wiederverwendung. Wenn du einmal ein Config File verstanden hast, kannst du dasselbe als Vorlage nehmen für alle zukünftigen Projekte, wo du dieselbe Komponente wieder brauchst. Config files haben auch wieder deutlich mehr Optionen als solche Konfigurationsassistenten. Das heißt, du kannst viel mehr tweaken, viel mehr customizen und ebenfalls wieder einfacher da auf Google oder Stack Overflow Beispiele für zu finden, weil du halt nach den Texten im Config file suchen kannst. Und wenn du das alles so machst, wenn du die Kommandozeile benutzt und Config files, wirst du feststellen, dass manche Sachen dauern und manche Sachen gehen relativ schnell. Und das Ziel sollte immerzu immer sein, dass du alles automatisiert, was zu viel Zeit kostet oder zu viel Aufmerksamkeit. Das heißt, du solltest die Kommandos, die du machst, solltest du versuchen, zu skripten. Und es gibt auch Toolings, so z.B. Ansible und Saltstack, das dir dabei hilft. Du willst prinzipiell vermeiden, dass du dieselbe Sache immer wieder selber händisch machen musst. Du willst prinzipiell alles nur einmal machen und danach ist es automatisiert und du kannst es, ohne dich darum zu kümmern, jederzeit nochmal ausführen. Genauso sollte es dir wichtig sein, dass du skalieren kannst, dass es egal ist, ob du einen Computer hast oder ganz viele, auf der deine Website laufen soll oder egal ist, ob du einen Benutzer hast oder ganz viele, die da Zugriff haben sollen. Das ist jetzt erst einmal, 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 Nutzer für dich selbst anzulegen , auf deinem eigenen Raspberry PI, das geht schneller, wenn du es nicht automatisch machst und nicht skalierbar. 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. Der dritte wichtige Punkt 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 Textstacks, Zertifikat Authorities und Monitoring Systeme und Datenbanken und Betriebssysteme, Hypervisors und Webservers, verschiedene Arten von Tooling und Containerisation. Das ist alles sehr verwirrend, aber es ist so wichtig zu erkennen: All diese Software ist von Menschen, Gruppen von Menschen geschaffen, und diese Gruppen von Menschen haben ihre eigene Kultur und ihre eigene Sprache, d.h. sie haben spezifische Art und Weise, wie sie abstrakte Konzepte wählen, und sie haben eine spezifische Wahl von Namen in ihrem Projekt und natürlich eine unterschiedliche Art von Syntax, weil die Raute bei Python etwas anderes ist als die Raute bei C++. Und wenn man jetzt die Sprache und die Kultur versteht, dann versteht man die Software dahinter deutlich einfacher. Also z.B. jede Komponente, jedes Betriebssystem, OpenBSD oder Ubuntu oder Tooling wie Docker oder Git oder Ansible oder halt auch sowas der TCP/IP Standard, haben alle ihr eigenes Vokabular, ihre eigene Terminologie, mit der sie daherkommen. Und die Wörter sind begrenzt. Es gibt nicht so viel verschiedene Wörter im Englischen, dass jedes Tool seinen eigenen Wörter hat, die sonst nirgends verwendet wurden. Das Problem ist: Manchmal benutzen die Tools dieselben Wörter und meinen auch prinzipiell oder bedeuten 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 z.B. Docker pull 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 tags und docker tags sind prinzipiell dasselbe. Du machst halt einen Namen, du gibt's einen Namen für einen Docker Image Layer oder ein Git Commit, einen menschen-lesbaren Namen. Das ist schon vergleichbar. Ansible tags wiederum sind etwas komplett anderes, das hat überhaupt nichts damit zu tun, das sind eher sowas wie Gruppen oder Rollen, die du in Ansible als Tag beschreibst. Hat aber denselben Namen wie docker tag und git tag, deswegen recht verwirrend. Anderes Beispiel ist die TCP/IP. Gibt's das Konzept von einem Port als Teil der Netzwerk Adresse 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. Aber Port ist nicht dasselbe wie bei TCP/IP. 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 und uns sehr viel hilft zu verstehen, aus welcher Kultur Menschen kommen, um zu verstehen, was Sie jetzt gerade meinen, wenn Sie Port sagen. Das waren meine drei Vorschläge, wie man generell es angehen sollte, wenn man System Ingenieur werden will. Man sollte seine eigenen Dienste hosten und möglichst viel davon selber machen. Man sollte es sich nicht so einfach machen, sondern halt alles automatisieren und skalieren. Und man sollte sich mit der Kultur beschäftigen, damit man einfacher versteht und zuordnen kann, was einzelne 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 du deine Website automatisch auf viele verschiedene, mehrere Raspberry Pis ausrollen kannst, dann ist das nicht so viel anders, als das im Datencenter auch läuft, da läuft auch nur Unix. Und wenn das Tooling stimmt, wenn deine Scripte stimmen und deine Prozesse, dann ist der Vorgang, das auf RaspberryPi zu machen, sehr ähnlich zu dem, wie du das halt in einem Datencenter machst. Egal ob es dann ein Server ist oder viele oder ein Rack oder viele. Das ist dasselbe Problem wie von einem auf mehrere Raspberry Pis zu gehen. Das ist alles nur Unix und was man zu Hause mit Raspberry PI macht oder mit APU, kann man sehr gut verwenden - dieselben Skills, dieselben Techniken - um Datencenter-Server zu betreuen. Soviel zu meinen Talk. Wir machen jetzt glaub ich noch eine kurze Fragerunde. Dankesehr. Herald: Hi Folkert, schön, dich hier quasi live im Studio begrüßen zu können. Vielen Dank für deinen Vortrag. Da hab ich ja gleich fast selbst Lust gekriegt, auch noch Systemingenieurin zu werden. Was denkst du denn? Was braucht man da so für Fähigkeiten, Kenntnisse, Interessen? Folkert: Gute Frage, war 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 halt immer ein Computer vor mir hatte, mit dem es dann irgendwas zu machen gab. Also auch wenn ich mich über irgendetwas anderes informieren wollte oder irgendetwas anderes machen wollte, war immer der Computer noch dazwischen, zwischen mir und dem Ding. Und dann hab ich erstmal mich immer um den Computer gekümmert und den er erst mal richtig konfiguriert, dass er genau das macht, was man will. Insofern ist es weniger eine Fähigkeit als vielmehr die Unfähigkeit, den Computer zu vergessen, sondern halt immer das Bedürfnis, da immer weiter weiter zu drehen und alles noch ein bisschen besser, noch ein bisschen idealer zu machen, die am meisten hilft, denke ich. H: Verstehe. Da gibt's direkt auch eine Anschlussfrage, von unseren ZuschauerInnen. 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 dann wohl ein guter Ansatz, um da ein bisschen tiefer einzusteigen dann? F: Gute Frage, also prinzipiell immer Leute, andere Leute. Hoffentlich. Also idealerweise Leute im selben Alter mit demselben Erfahrungsstand, die also quasi auf demselben Level sind, mit denen man dann gegenseitig lernt und fordert und so. Also generell eine Gruppe zu finden, die dieselben Interessen hat, ist denke ich das Wichtigste. Das macht dann meistens Spaß und bringt auch am meisten und dafür ist natürlich der Remote Chaos Congress eine sehr gute Sache oder der Chaos Treff, der CCC bei euch in der Nähe oder, was auch immer, der Hackerspace, aber generell halt ähnlich gesinnte Menschen, die da auch die genau dieselben Interessen haben und auf dem selben Level sind, dass man zusammen lernt. Und natürlich dann auch noch genug Leute, die das auch schon alles ein bisschen länger machen, die ebenfalls z.B. auf dem Kongress ansprechbar und aufzufinden sind und die sich auch, denke ich, immer freuen, Fragen zu beantworten, gerade von jüngeren Leuten, die vielleicht gern auch dieselben Sachen lernen würden. H: Dann haben wir noch eine Wording- Frage: Ist Software-IngenieurIn das gleiche wie DevOps oder gibt es da noch Unterschiede? F: Gute Frage. Das DevOps hab ich und Full Stack Engineer - oder Full Stack Developer, gibts ja beides - sind beide in letzter Zeit... sieht man die häufiger in irgendwelchen Job anzeigen? Prinzipiell dasselbe, aber DevOps ist ein bisschen... also DevOps, das sind meiner subjektiven Auffassung nach auch immer Leute, die dann gleichzeitig noch die Website programmieren, aber trotzdem irgendwie für die Server-Konfiguration zuständig sind. Das heißt, du muss halt programmieren und administrieren gleichzeitig. Das sind aber eigentlich ganz unterschiedliche Sachen. Insofern würde ich mich selber nicht als DevOps bezeichnen. Auf der anderen Seite könnte ich jetzt auch jederzeit irgendeinem Jobangebot, wo DevOps drauf steht, mich einfach melden, weil die Hälfte von dem Job auf jeden Fall irgendwie mit System Engineering zu tun hat. Insofern: Kommt immer drauf an, wer das Wort wie verwendet. Meistens ist es nur eine Ausrede vom zukünftigen Arbeitgeber, dass sie halt nur eine Person bezahlen wollen für zwei oder drei Jobs. Deswegen nennen sie das dann DevOps oder FullStack. H: Das klingt nicht so richtig attraktiv. Zum Job-Einstieg gibt's auch noch eine Frage: Hast du Tipps, wie man das mit Praktika am besten angeht? Wen man da wo am besten anquatscht? Irgendwelche Erfolgstipps? F: Nee, leider, leider nichts Konkretes, aber ich sag mal, das ist eine gute Frage, die man vielleicht auch im Rahmen des Kongresses nochmal irgendwie klären kann, weil es in der Tat auch in meinem direkten Freundeskreis und bei Wikipaka genug Leute gibt, die sehr viel Spaß an sowas haben und auch die Infrastruktur haben, wo man dann Praktikas anbieten könnte, ohne jetzt etwas versprechen zu wollen. Aber das ist schon da. Da arbeiten Leute schon dran. Insofern am besten mit Wikipaka in Verbindung setzen, würde ich sagen. Oder halt mich ansprechen oder irgendwen auf dem Kongress. H: Vielleicht ja bei uns in der 2D Welt. Wir haben ja auch die WikipakaWG abgebildet. Vielleicht findet man dich da ja nochmal. F: Ja, ich werd auf jeden Fall da auch rumhängen. H: Ich hab noch eine Frage aus dem Publikum und ich hoffe, dass ich das jetzt richtig ausspreche. Was hältst du von Kubernetes und Konsorten? Ist das die Zukunft oder eher sowas mittelfristig gehyptes? F: Das kann durchaus beides gleichzeitig sein. Also generell, also Containerization ist auf jeden Fall eine praktische Sache, das sind ja prinzipiell ein ähnliches Konzept wie Jails, also Chroot-Jails unter Linux oder Jails unter 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 Microservices über verschiedene Computer einfach deployen kann. Also wenn ihr jetzt nicht Erlang programmiert oder so, sondern halt so einen typischen Linux und nginx und LAMP und PHP und Python Stack hat, dann braucht man schon irgendein Containersystem, um mehrere Services, die zueinander abhängig sind, zu deployen. Insofern sollte man sich Container auf jeden Fall anschauen. Aber halt vielleicht nicht nur Docker, sondern Kubernetes auch auf jeden Fall. H: Eine Frage habe ich noch. Was hältst du davon, sich alle RFCs runterzuladen und einfach mal drauf loszulernen? F: Das hätte ich eigentlich sagen wollen, das ist eine gute Frage, danke! Da hätte ich fast im Vortrag eine extra Folie für gemacht. Das Schöne an der Technologie ist: A, es ist alles OpenSource oder sehr sehr sehr sehr viel. Das heißt, man kann den Source Code durchlesen und die Kommentare und so. Und die Protokolle sind halt per Definition offen. Also das allermeiste. Und in der Tat gibt's das bei IETF als RFC im schönen Text Format zum runterladen und durchlesen und das hab ich auch gemacht irgendwann. Nicht als erstes. Dann ist es doch sehr verwirrend und einschüchternd. Aber irgendwann ist man auf einem Level, wo man keine Bücher mehr lesen will, sondern halt direkt die Spezifikationen, wo das alles herkommt. Und da das... vielleicht nicht alle lesen, sind ein bisschen viele mittlerweile aber so ein paar, also IPv4 und so. Auf jeden Fall zu empfehlen. Das muss man mal gemacht haben. H: Okay. Ich habe jetzt aus dem Publikum keine weiteren Fragen und ich hab auch keine mehr - meine Frage hast du schon beantwortet. Es gibt aber die Möglichkeit, wenn es noch weitere Fragen gibt, das auch noch in einem weiteren BigBlueButton mit dir zu besprechen, falls man dich nicht in der 2D Welt suchen möchte. 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 Folkert. F: Dankeschön! Danke auch, schönen Congress! Abpspannmusik Untertitel erstellt von c3subtitles.de im Jahr 2021. Mach mit und hilf uns!