#rC3 - Wie man zu[mr] System Ingenieur(in)? wird

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!