*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!