[0:00] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker

[0:09] für Anwendungsentwicklung. In dieser Episode gibt es ein spannendes Interview mit Martin

[0:13] Helmig über das Thema Docker. Viel Spaß!

[0:20] Hallo und herzlich willkommen zur 121. Episode des Anwendungsentwickler-Podcasts. Mein Name

[0:28] ist Stefan Macke und heute gibt es ein richtig cooles Interview und zwar zu einem super geilen

[0:33] Hype-Thema, was die Softwareentwicklung und die IT insgesamt schon sehr lange beschäftigt

[0:38] und zwar die Containerisierung. Heute soll es hier endlich mal um Docker gehen. Bislang

[0:44] habe ich ja noch nie über das Thema gesprochen. Ich habe zwar in den letzten Episoden so

[0:47] ein bisschen über Cloud-Computing angefangen, aber Docker habe ich ja bewusst ausgenommen,

[0:51] weil ich wusste, dass ich da noch einen richtig coolen Interviewpartner finde und zwar Martin

[0:55] Helmig. Der ist Software-Architekt bei MITWALD und auch einer meiner Dozenten-Kollegen an

[1:01] der PHWT in Vechta. Und bevor ich jetzt noch weiter sabbele, leite ich einfach über zum

[1:07] Interview, denn das wird schon mehr als lang. Und deswegen viel Spaß und los geht's!

[1:12] Ja, hallo Martin. Schön, dass das heute geklappt hat. Schön, dass wir uns so ein bisschen über

[1:18] ein super cooles Hype-Thema, nämlich Docker, unterhalten können. Und ja, wie immer fange

[1:23] ich eigentlich mit so einer kleinen Vorstellung an. Vielleicht sagst du eben ein, zwei Sätze

[1:26] zu dir. Wer bist du? Was machst du so? Genau, ja, ich bin Martin. Ich arbeite als Systemarchitekt

[1:32] bei MITWALD. Das ist ein IT-Dienstleister aus Ostwestfalen, aus Esbekamp. Das liegt

[1:38] ein bisschen abgelegen. Wer jetzt nicht aus der Gegend kommt, kennt das wahrscheinlich

[1:42] nicht. Und ich mache im Moment sehr, sehr viel mit Container-Infrastrukturen, weil wir

[1:49] überlegen für uns, wie man da schöne Produkte drauf aufbauen kann. Und da sind wir natürlich

[1:54] auch an Docker nicht vorbeigekommen. Und ja, deswegen freue ich mich drauf, da heute ein

[2:02] bisschen mit dir drüber quatschen zu können. Okay, ja, das finde ich auf jeden Fall auch

[2:06] cool. Vor allem mit jemandem, der sich auch in der Praxis einsetzt. Denn ja, ich weiß

[2:11] zwar auch so ein bisschen, was Docker ist und wofür man das wohl braucht, aber so richtig

[2:15] jetzt für meinen persönlichen Tagesschopp hat sich da noch nicht so der Vorteil herausgebildet.

[2:19] Ich bin eigentlich ganz interessiert, zu hören, was ihr denn da so mit macht. Bevor

[2:22] wir da einsteigen, vielleicht noch ein bisschen was zu dir. Wie bist du zur IT oder zur Softwareentwicklung

[2:27] sogar gekommen? Hatte das irgendwie einen Auslöser? Fandest du das schon immer toll

[2:30] oder wie war das bei dir? Ich habe das gemacht, was wahrscheinlich viele

[2:35] gemacht haben, die irgendwie in diese Branche reingerutscht sind. Und zwar habe ich mein

[2:39] Hobby zum Beruf gemacht. Ich habe relativ früh angefangen mit Programmieren, so mit

[2:46] zehn, elf, zwölf Jahren, einfach so aus Neugier, weil mein Vater auch irgendwie viel am Computer

[2:52] gemacht hat und ich irgendwie verstehen wollte, was er da so treibt. Und dann habe ich immer

[2:56] so nebenbei hobbymäßig so an verschiedenen Projekten gearbeitet und habe dann irgendwann

[3:01] so bei erstbester Gelegenheit, die sich geboten hat, dann auch eine einschlägige Ausbildung

[3:05] und Studium ergriffen. Und welche Ausbildung oder Studium oder beides

[3:12] hast du da genau gemacht? Welche Richtung? Ich habe ein duales Studium gemacht mit einer

[3:20] Berufsausbildung zum Fachinformatiker mit Fachrichtung Anwendungsentwicklung und gleichzeitig

[3:25] ein Studium in Wirtschaftsinformatik, was dir ja wahrscheinlich bekannt sein müsste.

[3:31] Daher kennen wir uns ja auch. Und dann habe ich im Anschluss noch den Master in Informatik

[3:36] obendrauf gesetzt.

[3:37] Hattest du da irgendwie eine Vertiefung oder irgendwie sowas im Master oder?

[3:42] Das war ein Studiengang der Hochschule Osnabrück, der nannte sich Informatik mit Schwerpunkt

[3:49] verteilte und mobile Anwendungen.

[3:51] Das ist ja, deutet ja schon auf die Richtung vielleicht hin, Web und so weiter und hier

[3:57] noch ein Container und da noch einer. Oder konntest du da irgendwie was mitnehmen, Tasselli?

[4:01] Es ist ein Trend erkennbar, auf jeden Fall. Ich muss gestehen, als ich selber mein Masterstudium

[4:07] gemacht habe, da ist dieser Container-Hype an den Hochschulen noch gar nicht so angekommen.

[4:12] Ich bin selber auch erst, ich bin in meiner Masterarbeit angefangen, mich mit Docker zu

[4:18] beschäftigen. Genau. Da habe ich auch erforscht, wäre jetzt zu viel gesagt, aber mich so ein

[4:27] bisschen mit Microservice-Architekturen beschäftigt. Das war da auch noch ein relativ neues Thema.

[4:32] Der Prof, bei dem ich die Arbeit geschrieben habe, der war da auch erst noch recht frisch

[4:37] in Kontakt mit dem Thema und bin dann so in demselben Zuge auch auf Docker gekommen, weil

[4:42] das einfach so zwei Themen sind, die ganz gut miteinander Hand in Hand gehen.

[4:46] Und dann konntest du tatsächlich was aus dem Master mit in den Beruf nehmen oder hast

[4:52] du sogar ein Thema für die Masterarbeit aus dem Berufsumfeld gesucht oder wie hat sich

[4:56] da das Zusammenspiel dann ergeben?

[4:57] Genau, das Thema der Masterarbeit, das war auch ein rein betriebliches Thema. Da ging

[5:02] es um ein Migrationsprojekt für eine etwas größere Alt-Applikation und das Thema der

[5:08] Arbeit war im Grunde, wie man so diese über Jahrzehnte gewachsene PHP-Applikation irgendeine

[5:16] Art moderne Software-Architektur überführen kann.

[5:18] Ah, okay. Ja, das ist auch schon mal ein guter Hinweis. PHP, ja, das ist gut. Damit habe

[5:23] ich früher auch mal viel gemacht und PHP und Docker, wie das zusammenhängt, da können

[5:26] wir gleich auch nochmal einmal einsteigen, glaube ich. Heißt das denn, dass du dann

[5:29] im Alltag auch mit PHP hauptsächlich entwickelst oder welche PoAmi-Sprachen setzt du da selber

[5:35] ein?

[5:36] Ich habe früher viel PHP gemacht. Wir haben auch bei uns im Unternehmen früher viel PHP

[5:42] eingesetzt. Mittlerweile arbeite ich eigentlich nur noch mit PHP, wenn es sich gar nicht mehr

[5:48] vermeiden lässt. Da mag jetzt so eine leichte Wertung durchschwingen. Ich weiß nicht, ob

[5:55] man das jetzt so raushört. Nee, also ich habe natürlich viel mit PHP zu tun, weil

[6:02] wir halt für unsere Kunden auch diese ganzen typischen PHP-basierten Open-Source-Content-Management

[6:07] und E-Commerce-Systeme einsetzen. Deswegen bin ich so in dieser ganzen PHP-Welt natürlich

[6:12] immer noch so ein bisschen drin. Für mich selber, so das, was ich selber so programmiere,

[6:19] bin ich in den meisten Fällen ja so ein bisschen vom PHP-Zug abgesprungen. Das meiste,

[6:27] was ich im Moment mache, ist hauptsächlich Node.js mit TypeScript oder Go. So eins von

[6:32] beidem, je nachdem, was für den Anwendungsfall am besten passt.

[6:35] Gibt es da irgendwie eine Präferenz, dass zum Beispiel jetzt gerade zum Beispiel JavaScript

[6:40] oder Go besonders gut zum Beispiel mit Containern zusammenarbeitet oder ist das jetzt nur Zufall?

[6:44] Das ist eigentlich nur Zufall. Also Node.js funktioniert so in Container-Umgebungen

[6:53] eigentlich echt gut. Und ja, bei Go hat man den Nutzen jetzt gar nicht so unmittelbar,

[7:01] weil Go sowieso eigentlich sehr, sehr gut darauf ausgelegt ist, dass die Softwareprodukte,

[7:06] die am Ende rauskommen, halt möglichst überall lauffähig sind und man sich jetzt da keine

[7:11] großen Sorgen um Abhängigkeiten machen muss. Also so viele Probleme, die Docker löst,

[7:15] löst Go sowieso auf seine eigene Art und Weise auch schon. Von daher, wenn man mit Go arbeitet,

[7:21] kommt man eigentlich sogar noch häufig ohne irgendwelche Container-Lösungen aus.

[7:25] Mit Go arbeite ich tatsächlich eigentlich tendenziell am liebsten, weil mir die Sprache

[7:32] einfach gut gefällt. Da steckt ja auch immer viel persönliche Präferenz, viel persönliche

[7:39] Vorlieben drin und wie produktiv man auch damit arbeiten kann. Das ist ja eigentlich das

[7:43] Wichtigste bei einer Programmiersprache. Ja, das finde ich auch so. Also sozusagen,

[7:48] eine Programmiersprache ist besonders gut oder schlecht. Das hängt, glaube ich,

[7:51] auch immer vom Anwendungsfall ab. Das sehe ich auch so. Aber bei PHP kann man, glaube ich,

[7:55] insgesamt sagen, das ist eher tendenziell negativ. Nein, Quatsch. Jede Programmiersprache ist irgendwie

[8:02] gut für das geeignet, für das sie gedacht war. Also hast du quasi meine nächste Frage schon

[8:07] mitbeantwortet? Wenn du dich entscheiden dürftest, irgendwas zu machen, würdest du vielleicht auch

[8:10] Go wählen? Kann man das sagen? Ist das so eine Lieblingsprogrammiersprache von dir?

[8:14] Das kann man so sagen. Kannst du sagen, warum? Gibt es da vielleicht besonders tolle Features,

[8:22] die du in anderen Sprachen vermisst? Was macht dich da zum Beispiel besonders produktiv? Warum

[8:26] findest du die Sprache so interessant? Ich finde es erst mal sehr, sehr schön,

[8:32] weil es eine statisch typisierte Sprache ist. Wie gesagt, ich bin ja so aus der PHP-Welt

[8:36] gekommen, was ja eine Sprache ist, die dich im Grunde so tun und lassen lässt, was du möchtest.

[8:43] Und bei Go, genauso wie auch wenn du mit TypeScript zum Beispiel arbeitest, hast du halt eine viel,

[8:53] viel, viel stärkere Typsicherheit in der ganzen Sprache. Das heißt, du hast einen Compiler,

[8:56] der dir unter die Arme greift, sodass dir, wenn du im Java-Umfeld unterwegs bist, wird dir das

[9:01] wahrscheinlich auch bekannt vorkommen. Das heißt, du hast erst mal eine viel höhere Qualität in der

[9:07] Software, die am Ende hinten bei rauskommt. Du hast bei Go dann noch den Vorteil, dass die Software,

[9:15] die am Ende bei rauskommt, sehr performant funktioniert, weil es auf nativen Maschinencode

[9:19] kompiliert. Du hast einen sehr geringen Footprint, wenn es jetzt irgendwie um Speicherverbrauch geht

[9:25] und sowas. Und das Ökosystem ist einfach klasse. Wenn du auf GitHub gehst, findest du

[9:30] unglaublich viele Bibliotheken für jedweden Kram. Und du musst eigentlich fast kaum noch Probleme

[9:39] selber lösen, weil es für viele Anwendungsfälle, die jetzt nicht ultraspeziell sind, einfach schon

[9:43] fertige Bibliotheken gibt.

[9:45] Okay. Hätte ich jetzt irgendwie gar nicht gedacht, weil Go ist jetzt ja noch nicht so alt,

[9:49] dass es inzwischen schon doch so eine Community gibt, die da auch Projekte bereitstellt. Hätte

[9:53] ich jetzt irgendwie gar nicht erwartet.

[9:54] Ja, Google steckt ja ganz massiv dahinter. Die haben ja auch ursprünglich angefangen,

[10:00] die Sprache irgendwie zu entwickeln und auch in der Open-Source-Community so ein bisschen zu pushen.

[10:06] Es gibt irgendwie die Anekdote, die ist irgendwie mal durch das Internet kursiert. Ich habe sie

[10:10] allerdings bisher weder bestätigen noch widerlegen können, dass der erste Go-Compiler entstanden ist,

[10:19] während ein C++-Entwickler darauf gewartet hat, dass sein Programm kompiliert wird.

[10:23] Das war auch eines der Ziele, dass man irgendwie schnellere Entwicklungszyklen

[10:31] als mit C++ erreichen kann.

[10:34] Ja, so ist mir die Sprache irgendwie auch so bekannt, als besseres C++. Also maschinennahes

[10:41] Zeug kann man damit wohl anscheinend ganz gut machen.

[10:43] Ja, das funktioniert eigentlich ganz gut. Aber auch der ganze Webgraben, das funktioniert auch

[10:50] gut. Ich finde, wenn ich gebeten werde, Go in einem Satz zusammenzufassen, dann verwende ich

[10:58] häufig das Schlagwort C ohne die Schmerzen.

[11:02] Das ist schon viel wert.

[11:05] Ja, du sparst dir halt dieses ganze Speichermanagement-Kram. All die 10.000

[11:12] verschiedenen Wege, die C++ dir anbieten, dir selbst in den Fuß zu schießen, die hast du bei

[11:17] Go halt einfach nicht.

[11:19] Das ist gut, weil gerade so für Einsteiger, die können sich da heftig in den Fuß schießen.

[11:24] Ja, das weiß ich noch. Sehr gut. Ich habe tatsächlich auch auf meinem Server eine Anwendung in Go

[11:28] laufen. Zwar habe ich so einen kleinen Git-Hosting-Dings, der heißt Gox und der läuft auf Go.

[11:34] Das war tatsächlich einfach Download. Ich glaube, das ist eine Riesen-Executable, die man einfach

[11:38] startet und dann läuft das einfach.

[11:39] Genau, genau.

[11:40] Gut. Okay, dann würde ich sagen, dann können wir doch mal zum eigentlichen Thema kommen.

[11:47] Zu Docker. Vielleicht fange ich mal mit einer ganz, ganz breiten Frage an.

[11:51] Was ist denn überhaupt Docker?

[11:55] Das ist schon gleich die beste Frage von allen.

[12:00] Wenn man jetzt irgendwie in der Wikipedia nachflecht oder sowas für das Thema, dann wirst du von

[12:04] einer ganzen Batterie an Buzzwords erschlagen.

[12:08] Da steht dann sowas wie Containerisierung und DevOps und irgendwie noch 14 andere Buzzwords,

[12:14] die im Moment so kursieren.

[12:20] Im Grunde kann man sagen, Docker ist eine Container-Lösung.

[12:26] Container im Sinne von sowas Ähnliches wie virtuelle Maschinen.

[12:30] Also eine Möglichkeit, mit der du einzelne Prozesse voneinander isolieren kannst, die irgendwie auf

[12:36] demselben Server laufen. Nur dass ein Container im Unterschied zu einer virtuellen Maschine, wie man

[12:42] sie so klassischerweise irgendwie kennt, viel, viel, viel schlanker ist.

[12:47] Du hast jetzt nicht, wie bei einer VM, ein komplettes Betriebssystem darin virtualisiert mit

[12:54] eigenem Kernel und allem, was so zum Betriebssystem sonst noch dazugehört mit den ganzen

[13:00] System-Services und allem drum und dran.

[13:05] Bei Docker ist es so, du hast eine isolierte Umgebung, in der du in der Regel einen

[13:11] einzelnen Service laufen lassen kannst, wie zum Beispiel einen Web-Server oder irgendeinen

[13:16] Applikations-Server oder so, je nachdem.

[13:19] Das ist nur durch die Fantasie begrenzt und dieser einzelne Prozess, der kriegt dann seine

[13:24] isolierte Umgebung, in der er sich im Grunde frei bewegen kann innerhalb des Rahmens, den er

[13:31] gesetzt bekommt. Und das ist im Grunde der Container.

[13:36] Das, was Docker dann noch obendrauf anbietet, ist eine relativ coole Toolchain, die es dem

[13:42] Entwickler, der damit arbeitet später, einfach macht, effizient zu arbeiten mit dem ganzen

[13:47] System. Es gibt Werkzeuge dabei, mit denen du Images bauen kannst.

[13:52] Jeder Container hat sein eigenes File-System, die dann aus Images wieder erstellt werden.

[13:56] Du hast die Möglichkeit, diese Images einfach zu bauen.

[13:58] Du hast eine Beschreibungssprache, mit der du diese Images beschreiben kannst und du kannst

[14:02] alles automatisieren.

[14:04] Und grundsätzlich, dieser ganze Automatisierungs-Fokus, der steht bei Docker auch noch viel,

[14:08] viel, viel weiter oben als bei diesen ganzen Virtualisierungslösungen, die man sonst so am

[14:14] Markt findet bisher.

[14:16] Das hast du schon gesagt, es ist so ähnlich wie virtuelle Maschinen.

[14:19] Kann man so ganz platt sagen, Docker ist sowas ähnliches wie VMware oder Virtualbox?

[14:28] Wenn man es ganz stark runterbrechen will, kann man das sagen, aber an den entscheidenden

[14:33] Stellen gibt es dann ein paar Unterschiede.

[14:38] So, der wichtigste von allem ist, Docker virtualisiert kein ganzes Betriebssystem.

[14:43] Das heißt, ich habe zum Beispiel keine Kernel-Virtualisierung.

[14:48] Das heißt, auch ein Docker-Container läuft mit demselben Betriebssystemkern wie das

[14:53] Virtualisierungs-System.

[14:54] Das heißt, ich kann jetzt auch zum Beispiel keinen Windows-Container auf einem Linux-Server

[14:58] betreiben, weil die sich halt den Betriebssystemkern teilen.

[15:02] Ein zweiter wichtiger Unterschied ist, in einem Docker-Container läuft üblicherweise

[15:11] nur der eine Service, von dem du willst, dass er darin läuft, wie zum Beispiel dein Web-Server,

[15:18] dein Applikations-Server.

[15:19] Du hast jetzt nicht, wie bei einem Standard-Linux, keinen Log-In-Dienst dabei, keinen Logging-Dienst,

[15:26] keine Ahnung, was Linux sonst noch alles hat, kein System-Deal, kein UDEF.

[15:32] Diese ganzen Betriebssystem-Services, kein SSA-Server ist in einem Docker-Container üblicherweise

[15:38] zumindest erst mal nicht drin.

[15:39] Also quasi wirklich ein ganz, ganz reduziertes Betriebssystem, sodass ich mich also fokussieren

[15:44] kann auf den, ich sag mal, den fachlichen Dienst, den ich eigentlich in dem Ding laufen

[15:48] lassen will.

[15:49] Genau.

[15:50] Genauso ist es.

[15:52] Und warum finden das jetzt alle so cool?

[15:55] Ich meine, gut, wenn ich vorher eine virtuelle Maschine hatte, die vielleicht ein paar Gigabyte

[15:59] groß war und die muss ich erst hochfahren, damit überhaupt was gestartet wird, ist wahrscheinlich

[16:02] irgendwie ein bisschen schneller und braucht weniger Speicherplatz, aber ist das jetzt

[16:05] irgendwie so eine krasse Neuerung, dass da alle drauf anspringen?

[16:08] Ich glaube, das Thema hat, ich glaube, Docker hat einfach so einen Nerv getroffen, der beziehungsweise

[16:18] so einen Bedarf erfüllt, der irgendwie, wo lange Zeit da war und durch diese klassischen

[16:24] VMs, die man halt am Markt hatte, einfach nicht wirklich gedeckt werden konnte.

[16:27] Du hast gerade schon gesagt, du hast erst mal viel, viel, viel kürzere Zyklen dabei.

[16:33] So, einen Docker-Container, wenn ich ein Image habe, kann ich daraus innerhalb von, lass mich

[16:39] jetzt irgendwie nicht lügen, aber irgendwie von ein, zwei Sekunden einen neuen Container

[16:42] starten.

[16:43] So, und in der Zeit ist meine VM ja noch lange nicht gebootet aus irgendeinem Image.

[16:48] Und was, glaube ich, der zweite Punkt ist, weshalb Docker auch so beliebt geworden ist,

[16:56] ist einfach der Grad an Automatisierung, der möglich ist.

[16:59] Ich habe mich vor einer Zeit mal irgendwie so ein bisschen damit beschäftigt, irgendwie

[17:03] so VM-Images irgendwie automatisiert zu bauen.

[17:05] Und das ist schon echt so, da muss man halt schon echt irgendwie wissen, was man tut,

[17:11] wenn man damit Konfigurations-Management-Systemen dann auf irgendwelchen VM-Templates drauf

[17:16] rumrührt und die dann snapschotten muss.

[17:18] Und das ist echt Arbeit und das macht Docker viel, viel, viel einfacher.

[17:23] Ich habe da auch mal so ein Stichwort gehört, Infrastructure as Code.

[17:28] Ich glaube, das geht so in die Richtung, dass ich irgendwo in meinem Textfall sagen kann,

[17:32] hey, so eine Maschine brauche ich, das und das ist die Ausstattung, das Betriebssystem

[17:34] in der Version und so weiter und dann leg mal los.

[17:37] Ist das damit gemeint?

[17:38] Weißt du das so, Velli?

[17:39] Docker geht da sogar noch ein bisschen weiter.

[17:42] Also, wenn wir jetzt schon dabei sind, mit Buzzwords um uns zu werfen, ist das Buzzword,

[17:49] was bei diesen ganzen Container-Infrastrukturen noch viel stärker ist, glaube ich, der Begriff

[17:53] Immutable Infrastructure.

[17:54] Infrastructure as Code, das ist jetzt kein Thema, was unbedingt jetzt direkt auf dieses

[18:04] ganze Container-Thema abzubilden ist, sondern das hat seinen Hintergrund eher in diesen

[18:12] Konfigurations-Management-Systemen, die irgendwie so vor ein paar Jahren so auf den Markt gedrängt

[18:17] sind.

[18:18] An Puppet und Assault und Ansible ist da ja auch irgendwie ganz groß, wo ich meine Infrastruktur

[18:25] irgendwie in Form von Code beschreibe, wie zum Beispiel als Ansible-Playbook, um sie

[18:32] anhand dieser Beschreibung dann wieder von Grund auf neu aufziehen zu können.

[18:37] Und was jetzt der Ansatz ist, den Docker verfolgt, ist, dass meine eigentliche IT-Infrastruktur

[18:48] im Grunde komplett zustandslos ist und sich nur durch die Container beschreibt, die eben

[18:57] irgendwo auf dieser Infrastruktur laufen, sodass es mir jetzt zum Beispiel auch möglich

[19:02] ist, wenn ich irgendwie ein Stück Blech im Rack stehen habe, das Ding einfach auszutauschen

[19:07] dann mit irgendeinem neuen Stück Blech und dann werden da dieselben Container drauf gestartet

[19:12] und dass die Infrastruktur selbst eigentlich gar keinen eigenen Zustand mehr hat, sondern

[19:16] sich das alles nur noch über diese Container definiert.

[19:18] Das hört sich natürlich für euren speziellen Use-Case jetzt als Web-Poser zum Beispiel

[19:24] nach einer tollen Lösung an, weil ihr ja quasi komplett von der Hardware euch lösen

[19:29] könnt und einfach irgendeine Maschine von A nach B schiebt und dann läuft es da halt

[19:32] weiter, ja?

[19:33] Genau, das ist auch so die große Hoffnung, die wir uns tatsächlich so machen aus dem

[19:40] ganzen Thema, dass einfach der Infrastrukturbetrieb so ein bisschen einfacher wird, weil im Moment

[19:44] haben wir halt so genau dieses, als Kunde kaufst du deinen Server und das ist dann

[19:49] deiner, auf dem du sitzt und diese ganzen Container-Techniken, die machen…

[19:57] Ja, bieten noch tatsächlich einige weitere Möglichkeiten, die man dann nutzen kann.

[20:04] Gerade wenn es jetzt irgendwie darum geht, mal schnell irgendwie einen Container von einem Stück Blech auf ein anderes zu verschieben

[20:10] oder irgendwie das Ganze in die Breite zu skalieren, jetzt auf die Schnelle.

[20:14] Das ist was, wo diese Container-Management-Systeme sehr, sehr, sehr glänzen.

[20:22] In der Management-Systeme, hast du jetzt schon ein paar Mal gesagt, macht auch Docker das dann noch selbst

[20:28] oder braucht man da so andere tolle Tools wie, ich weiß jetzt nicht genau, ob es das ist, Kubernetes?

[20:32] Genau, wenn du mit Docker-Containern arbeitest, ist es üblicherweise so, dass du erstmal auf ein System beschränkt bist.

[20:45] Das heißt, Docker selbst, also die Docker-Engine selbst, bietet jetzt nicht die Möglichkeit, Container über irgendwie einen Cluster von Servern zu verteilen.

[20:55] Und das ist dann genau der Punkt, wo solche Software heißt Container-Orchestrator, wo solche Container-Orchestrator dann zum Spielen kommen.

[21:08] Wie zum Beispiel Kubernetes. Früher gab es noch Docker Swarm, das war ein Produkt von Docker selbst, also quasi so ein Zusatzprodukt zu Docker.

[21:16] Wobei sich auch Docker selbst jetzt mittlerweile auf Kubernetes committed hat.

[21:21] Also Kubernetes scheint irgendwie der große Gewinner in dieser ganzen Nummer gewesen zu sein.

[21:25] Wie kann man sich das vorstellen? Also das ist dann so eine Software-Suite, wo man dann nochmal sowas sagen kann wie,

[21:30] du hast hier so einen Docker-Container und ich will jetzt einfach mal fünf verschiedene Instanzen lastverteilt irgendwie haben oder was macht das Tool dann für mich?

[21:38] Genau, Kubernetes abstrahiert im Grunde nochmal über deine Infrastruktur hinweg und bietet dir jetzt einen Pool aus Rechenkapazitäten, den du vielleicht in deinem Rechenzentrum hast.

[21:51] Das können jetzt drei Server sein, das können 300 Server sein oder so das Größte, was ich mal gehört habe, waren irgendwie 5000.

[21:58] Und bietet das als einheitlichen Pool an, sodass du es als Nutzer gar nicht mehr siehst, ob hinter diesem Cluster jetzt ein oder tausend Server hinterstehen.

[22:07] Das Einzige, was du dann als Nutzer dieser Orchestrierungssoftware noch tun musst, ist zu sagen, starte mir zehn Instanzen von folgendem Container-Image

[22:19] und die Orchestrierungssoftware kümmert sich dann automatisch darum, dass diese zehn Instanzen auf irgendwelchen Hardware-Einheiten gestartet werden, wo eben noch entsprechende Kapazitäten frei sind.

[22:32] Ich stelle mir das jetzt ganz praktisch vor, also ich habe mit Kubernetes selber noch nie gearbeitet, aber angenommen, ich will da mal so einen Web-Server hochfahren, der muss ja auch irgendwo im Internet dann erreichbar sein.

[22:41] Wenn ich jetzt in so einer Engine auf so einen Button drücke und hey, stelle mir mal fünf Container davon hier, die müssen ja irgendwo erreichbar sein, kriege ich dann quasi als Rückgabe wert irgendwelche IP-Adressen oder DNS-Namen oder wie greife ich nachher darauf zu?

[22:57] Das ist ganz stark abhängig davon, wie dein Kubernetes-Cluster aufgebaut ist.

[23:02] Grundsätzlich ist es erstmal so, dass du eine interne Netzwerktopologie hast, die einfach nur dazu da ist, damit deine Container selber irgendwie miteinander reden können.

[23:12] Das kann ja auch notwendig sein, wenn du zum Beispiel einen Datenbank-Container und einen Applikations-Server-Container hast, die müssen ja miteinander auch irgendwie kommunizieren.

[23:20] Und die Aufgabe, Traffic von außen in deinen Container-Cluster reinzukriegen, da gibt es häufig spezielle Komponenten, die vom Anbieter bereitgestellt werden, die einfach nur dafür zuständig sind, Traffic von außen irgendwie in deinen Cluster reinzukriegen.

[23:43] Wenn man so in den großen Cloud-Umgebungen unterwegs ist, hier Amazon oder Google oder sowas, da gibt es dann entsprechend fertige Lösungen dafür, die das anbieten.

[23:54] Wenn man sowas selber hostet, muss man da ein bisschen kreativ werden.

[23:59] Die großen Netzwerk-Hardware-Hersteller, die bieten auch mittlerweile Integrationen für diese ganzen Container-Orchestrierungs-Softwares an, sodass ich zum Beispiel jetzt auch wirklich einen Hardware-Load-Balancer oder eine Firewall irgendwie so automatisch konfigurieren kann, dass wenn du jetzt so einen Container-Cluster erstellst, dass dann dein Traffic irgendwie auf all diese Container irgendwie gleichmäßig aufgeteilt wird.

[24:21] Also das funktioniert so.

[24:23] Okay. Ja, ich hatte so als dummer Anwender immer gedacht so, hä, wie mache ich das denn, weil das war für mich der Standard-Use-Case.

[24:29] Aber klar, wenn ich natürlich erstmal hergehe und meine Anwendung so ein bisschen auch auseinanderreißen will, vielleicht die Datenbank hier, die Anwendung da und irgendwie, keine Ahnung, die Middleware noch woanders, dann ist natürlich erstmal gar kein Traffic von draußen drauf, klar.

[24:40] Das macht es etwas einfacher, ja.

[24:43] Okay. Habe ich verstanden, glaube ich, was ihr damit irgendwie Cooles machen könnt. Aber was mache ich denn jetzt so als einzelner, kleiner Entwickler damit?

[24:50] Bringt mir das auch irgendwie was? Weil ich bin jetzt ja nun kein Web-Poster, der das vielleicht ganz gut einsetzen kann.

[24:55] Trotzdem habe ich den Eindruck, dass auch viele Entwickler halt super auf diesen Docker-Train aufspringen.

[25:00] Und was habe ich da konkret für Vorteile von?

[25:03] Da gibt es mehrere Ansätze, die man fahren kann. Also man kann jetzt erstmal mit der Entwicklungsschiene argumentieren und man kann auch mit der operativen Schiene argumentieren.

[25:18] Ich würde jetzt erstmal mit der Entwicklung selber anfangen, denn einerseits, was jetzt erstmal du persönlich, Stefan, als Entwickler von Docker zum Beispiel hast, ist, dass du die Möglichkeit hast, deinen individuellen Entwicklungsworkflow zum Beispiel mit Docker zu optimieren.

[25:40] Was wir bei uns zum Beispiel früher relativ häufig hatten, war das Problem, dass wir Softwareentwickler da sitzen hatten, die irgendwie Software entwickelt haben und diese Leute unglaubliche Mühe damit hatten, die produktive Umgebung, in der die Software dann am Ende betrieben werden sollte, irgendwie auf ihrem lokalen Rechner nachzubauen.

[26:06] Das war irgendwie noch zu PHP-Zeiten, da musste man die passende PHP-Version bei sich auf dem Arbeitsplatzrechner installiert haben oder man musste sich da mit virtuellen Machinen einen abbrechen, um die richtigen Dependencies an den Start zu kriegen für sein Projekt.

[26:23] Und da hilft Docker schon, weil du jetzt zum Beispiel die Laufzeitumgebung, in der deine Software im Produktivbetrieb später laufen soll, einfach in ein Container-Image packen kannst und das Ding dann einfach bei dir lokal auf dem Rechner starten kannst.

[26:43] Das heißt, du kannst als Betreiber zum Beispiel oder beziehungsweise als Administrator einer Infrastruktur einfach ein Container-Image anbieten, was du deinen Entwicklern gibst und die nutzen das, um bei sich lokal auf dem Arbeitsplatzrechner ein möglichst genaues Abbild des Produktivsystems zu starten.

[27:01] Man kann das Ganze auch andersrum aufziehen, sodass du als Entwickler selbst einfach definierst, wie hat die Laufzeitumgebung für meine Applikation auszusehen.

[27:16] Ich glaube, du bist ja hauptsächlich im Java-Umfeld unterwegs, war das richtig?

[27:35] Wenn du sagst, meine Applikation braucht jetzt unbedingt einen Tomcat und Java 8, könntest du deine Applikation einfach in einem Container-Image ausliefern, wo genau das drin ist, genau die Abhängigkeiten drin sind, die deine Applikation zum Laufen braucht und könntest genau dieses Image jetzt auch im Produktivbetrieb einfach an den Start nehmen.

[27:58] Entweder machst du es selbst, wenn ihr jetzt wirklich DevOps nach Lehrbuch macht oder du übergibst dieses Container-Image an irgendeinen Operator, der das Ding dann in der Produktivinfrastruktur startet und hast auf die Art die Garantie, dass die Software im Produktivbetrieb auch genauso läuft, wie du als Entwickler dir das tatsächlich gedacht hast.

[28:20] Das finde ich auf jeden Fall schon mal sehr cool, Herr Sillig. Wir verbringen auch sehr viel Zeit damit, Produktionsumgebungen nachzubauen. Das kann ich sofort nachvollziehen. Okay, das finde ich gut.

[28:32] Genau, man hört ja häufig so diesen Satz, wenn irgendwas im Produktivsystem nicht funktioniert, dann sagt der Entwickler häufig, ja, works on my machine. Also bei mir läuft's. Im Produktivsystem, ja, da ist halt irgendwas anders. Ja, aber weiß ich auch nicht. Das ist halt blöd. Das verursacht Fehler und letzten Endes sind dann alle sauer auf dich und den Betreiber und das ist halt einfach Ärger, den man ganz gut vermeiden kann mit sowas.

[29:02] Okay, ja, das finde ich auf jeden Fall gut. Also da kann man, also ich fasse es mal so ein bisschen zusammen, auch für mich so ein bisschen Zeit sparen. Es gibt mir auch eine gewisse Sicherheit, wenn ich was entwickelt habe, dass es dann nachher auch so läuft, wie es laufen soll und ich nicht noch irgendwie mich um diesen ganzen Admin-Kram auch noch kümmern muss. Das ist ja vielleicht auch ganz gut.

[29:18] Und wenn ich das Ganze dann auch noch irgendwie so schreiben kann, dass es sogar aussieht wie Code, ja, dann bin ich am Ende ja auch sogar glücklich. Das ist ja cool. Ganz konkrete Frage mal zwischendurch. Kann ich das ganze Docker-Zeug inzwischen schon auf Windows laufen lassen, weißt du das? Oder ist das immer noch so eine Winox-Geschichte?

[29:35] Kannst du tatsächlich. Es gibt zwei, das ist ein bisschen hinterhältig. Wenn man nach Docker und Windows sucht, gibt es zwei verschiedene Schienen, auf die du da geraten kannst.

[29:50] Das Erste ist, ich muss jetzt aufpassen, dass ich da mit den Namen nicht durcheinander komme. Das eine, was du findest, ist eine Lösung, die es dir ermöglicht, Linux-Container unter Windows zu starten. Das Ganze arbeitet dann wieder mit Virtualisierung im Hintergrund.

[30:09] Das heißt, das ist einfach ein Software-Paket, das erstellt dir irgendwie eine Hyper-VVM auf deinem Windows-Rechner, wo dann wieder ein Linux drin läuft mit einer Docker-Engine. Das funktioniert trotzdem relativ gut. Es liegt daran, dass die Docker-Engine selber ja im Grunde auch einfach nur eine Rest-API zur Verfügung stellt, die dann wieder angesprochen werden kann.

[30:28] Das heißt, diese ganzen Kommandozeilen, Tools, die funktionieren dann auch unter Windows, außer du kannst das dann von einer PowerShell bedienen und mit allem drum und dran. Das integriert sich relativ gut, sodass du dann die Möglichkeit hast, unter Windows Linux-Container zu starten, die dann aber in Wirklichkeit in irgendeiner virtuellen Maschine laufen.

[30:46] Das ist die eine Möglichkeit. Du hast seit irgendeiner der letzten Windows-Server-Versionen aber auch tatsächlich die Möglichkeit, Windows-Container zu starten, die dann wirklich im Windows-Kernel laufen und die auch echte Windows-Professe beinhalten. Also Windows hat mittlerweile in den Server-Versionen nativen Docker-Support. Wobei ich ganz ehrlich gestehen muss, dass ich mich dann auch noch nicht das geringste mit beschäftigt habe.

[31:13] Das Einzige, wo ich mal aus Versehen drüber gestolpert bin, dass ich in irgendeinem GitHub-Repository einen Docker-File gefunden habe, wo normalerweise für die Linux-Container die ganzen Bash-Befehle drinstehen, um das Image aufzubauen, dann stand da auf einmal so 10.000 PowerShell-Statements drin. Da habe ich mich total verjagt.

[31:33] Ja, das geht auch gar nicht, wenn man die Bash oder was auch immer gewohnt ist und dann diese ganzen .NET-Quatsch.

[31:38] Aber es funktioniert. Also von daher, alles gut.

[32:08] Meinetwegen sagen wir jetzt Java und Tomcat. Und jetzt möchte ich tatsächlich irgendeine Version, die ich da festgelegt habe, hochziehen. Sei es auch nur die, keine Ahnung, die Linux-Version muss jetzt eine neuere sein oder die Tomcat-Version muss neuer sein oder Java oder was auch immer. Reicht es dann einfach, in einem File irgendwo eine andere Version einzutragen oder muss ich dann die ganzen Images alle irgendwie neu bauen und neu verdrahten?

[32:30] Die Idee bei Docker ist tatsächlich, dass die Container selber möglichst zustandslos sind und sich im Betrieb, also das bedeutet, dass sich der Container selber im Betrieb eigentlich nicht mehr verändert.

[32:46] Man muss sich da nicht dran halten. Das heißt, du kannst jetzt zum Beispiel auch einen Docker-Container starten und kannst dann in diesem Container über die ganz normalen Methoden des Betriebssystems ein Software-Update machen, irgendwie ein Upgrade zum Beispiel.

[33:01] Wobei die eigentliche Idee, das eigentliche Paradigma ist, dass du, wenn du ein Software-Update machen möchtest, innerhalb eines Containers du das Image neu baust mit aktueller Software oder auf Grundlage eines anderen Basis-Images, zum Beispiel eine neuere Ubuntu-Version oder worauf auch immer das Image aufbaut und dann die entsprechenden Container löschst und neu erstellst.

[33:28] Genau, also Software-Update, grundlegende Idee ist, keine Updates im Container, sondern Container-Image neu bauen und daraus dann neue Container erstellen.

[33:38] Also, nur um das nochmal zusammenzufassen, nennt man das Basis-Images, auf denen ich dann basiere oder haben die irgendwie einen anderen Namen?

[33:46] Das nennt man tatsächlich so. Genau, das ist glaube ich auch was, was so ein bisschen einer der Sachen ist, die Docker so ein bisschen zu seiner großen Beliebtheit geholfen haben, dass du halt die Möglichkeit hast, deine eigenen Images auf bestehenden Images, die vielleicht direkt vom Hersteller, vom Betriebssystem-Distributor angeboten werden, dass du deine eigenen Images darauf aufbauen kannst.

[34:12] Dass du zum Beispiel sagen kannst, ich nehme jetzt einen Ubuntu-1804-Basis-Image und baue darauf auf, baue jetzt noch mein eigenes Image obendrauf, wo jetzt noch zusätzlich ein Web-Server mit meiner Applikation drin läuft oder sowas.

[34:26] Das funktioniert doch echt gut, muss man sagen.

[34:31] Ganz grob zum Verständnis, wie kann man sich das vorstellen? Also angenommen, ich habe jetzt so ein fertiges Linux-Image, okay, da kann ich mir noch vorstellen, da ist alles drin, was Linux so braucht.

[34:39] Dann kommt da oben jetzt, fangen wir mal ganz unten an, wirklich einfach, ich sage mal, so ein Apache-Web-Server will ich jetzt da drauf haben.

[34:44] Ist dann in dem zweiten Image tatsächlich einfach, sind dann nur noch alle Dateien, die für den Apache dazukommen müssen? Also ist das so eine Art Delta zu dem Basis-Image oder wie kann man sich das vorstellen?

[34:56] Das Image-Format, mit dem Docker arbeitet, genau, das basiert tatsächlich auf differenziellen Layers.

[35:03] Also das heißt, du hast ein Basis-Image und wenn du jetzt zum Beispiel ein Apache installierst, kommt auf dieses Image einfach noch eine zweite Schicht obendrauf, wo wirklich das Delta zum Basis-Image drauf ist.

[35:18] Und wenn du dann darauf, du kannst darauf aufbauen und dann noch weitere Schichten aufbauen, du kannst dann zum Beispiel in einer zweiten Schicht noch deine eigene Applikation wieder da reinkopieren und auf die Art setzen sich diese Container-Images aus ganz, ganz vielen einzelnen Schichten zusammen.

[35:34] Und das ist auch das Coole, wenn es darum geht, diese Images zu verteilen.

[35:47] Wenn du so ein Image deployen willst zum Beispiel, ist Docker selber intelligent genug, zum Beispiel festzustellen, dass die letzten verschiedenen Deployment-Artefakte, die du hattest, die letzten Container-Images, die du gebaut hast, irgendwie alle auf demselben Basis-Image aufbauen und überträgt dann nur noch, wenn du zum Beispiel in eine Image-Registry deine Images pusht, überträgt dann nur noch die Schichten der Container, die sich tatsächlich verändert haben.

[36:18] Also ich stelle mir jetzt einfach nur so ganz, ganz platt so vor, ich installiere da irgendwo so ein Apache und der weiß dann zum Beispiel unter slash etc muss irgendwie eine Config-Datei liegen und unter slash bin muss das Binary liegen und dann werden die Images on top irgendwie aufeinander ausgepackt, sodass am Ende im letzten Image ganz oben einfach das Linux mit den zusätzlichen Dateien von Apache drin liegt, mit den zusätzlichen Dateien meiner Applikation und da wird quasi Schicht für Schicht einfach, ich sag mal ganz blöd, das Dateisystem zusammengebaut,

[36:45] um dann am Ende meine Anwendung drin laufen lassen zu können. Richtig?

[36:49] Genau so ist es.

[36:51] Okay, cool. Ja, da würde ich jetzt für mich so ableiten, dass sich dann vielleicht bestimmte Anwendungen oder Sprachen oder wie auch immer für den Einsatz in Docker besser oder schlechter eignen.

[37:01] Denn wenn ich mir jetzt einfach vorstelle, dass alles, was in dem Image drin ist, halt irgendwie im Dateisystem abgelegt werden können muss, dann gibt es da vielleicht irgendwelche, ja ich weiß nicht, Plattformen, wir haben jetzt über Java zum Beispiel geredet oder Go oder PHP oder ich weiß nicht, PHP zum Beispiel könnte ich mir vielleicht sehr einfach vorstellen, weil das sind ja einfach quasi Klartext-Dateien, die einfach auf der Platte liegen, aber bei Go zum Beispiel kommt ja ein riesen Kompilat raus.

[37:24] Gibt es da irgendwie, ja Plattformen, die sich besser oder schlechter für diese Arbeit in Containern eignen oder ist das egal?

[37:31] Also ich muss ehrlich sagen, die Plattform, von der ich sagen würde, das funktioniert überhaupt nicht im Container, die habe ich noch nicht gefunden.

[37:40] Es gibt Umgebungen, wo man merkt, das funktioniert besser in Containern als so in manchen anderen.

[37:51] Bleiben wir zum Beispiel mal beim Beispiel Go.

[37:56] Wenn ich eine Go-Applikation habe, da fliegt am Ende ein statisch kompiliertes Binary raus oder das ist dann irgendwie meine Excel-File, die ist irgendwie 100 Gigabyte groß oder sowas und das Schöne ist, die hat überhaupt keine Abhängigkeiten.

[38:12] Die ist nicht mal von irgendeiner C-Standard-Library abhängig, wenn ich sie richtig kompiliere.

[38:17] Das heißt, es muss auch in dem Container-Image selber außer diesem Binary eigentlich gar nichts mehr drin sein.

[38:25] Das macht das Image-Bauen für solche Go-Applikationen natürlich super einfach, weil ich überhaupt nicht auf irgendwelche Abhängigkeiten Rücksicht nehmen muss.

[38:34] Generell kann man natürlich sagen, je komplexer der Software-Stack ist, den du so drum rumlaufen hast mit deiner Applikation, desto mehr Mühe hast du dann auch damit, das Container-Image zu bauen.

[38:48] Aber andererseits, desto mehr Mühe hättest du auch damit, irgendeine VM so zu konfigurieren, dass deine Applikation da läuft.

[38:54] Also das ist jetzt nicht so, dass man da irgendwie mehr Arbeit mit hätte.

[38:57] Was mir tatsächlich aufgefallen ist, was von den Sachen, die ich bisher gefunden habe, was am meisten Mühe macht, im Container zu betreiben, ist tatsächlich PHP.

[39:10] Weil du bei PHP-Applikationen in der Regel immer mehrere Prozesse hast, die du irgendwie orchestrieren musst.

[39:20] Bei PHP hast du ja grundsätzlich den Web-Server, sei es jetzt ein Apache oder ein Nginx.

[39:27] Und dann hast du ja auch den eigenen PHP-Prozessmanager, das FPM, ja noch dazu.

[39:32] Und es müssen irgendwie beide Prozesse in diesem Container laufen.

[39:35] Und das Ganze muss irgendwie miteinander orchestriert werden.

[39:39] Und das war so bisher das Umständlichste, was mir irgendwie über den Weg gelaufen ist.

[39:44] Also kann man so sagen, ich glaube, das passt ja auch ganz gut zu so einer Microservice-Architektur, dass ich versuche, wirklich isolierte Dinge am besten in so einem Container laufen zu lassen, damit ich genau solche Probleme gar nicht habe.

[39:56] Dass sie sich vielleicht gegenseitig, ich weiß nicht, blockieren oder Abhängigkeiten haben, die Prozesse untereinander.

[40:02] Genau. Im Idealfall hast du ja schon so eine schöne, fertige 12-Factor-App, die sich so nach diesen ganzen Architekturrichtlinien hält, die es eben dafür gibt,

[40:16] sodass deine Applikation dann am Ende tatsächlich auch nur dieser eine Prozess ist, der dann eben so seinen Port aufmacht, auf den er lauschen muss, wenn es eine Web-Applikation ist,

[40:27] sodass du das Ding dann einfach in dem Container-Image starten kannst.

[40:32] Und wenn wir jetzt so gefragt haben, was für Umgebung vielleicht sich gut eignen kann man, weil du es gerade selber angesprochen hast, mit den Web-Anwendungen,

[40:39] ich höre auch eigentlich fast nur im Kontext von Web-Anwendungen von Docker-Containern, ist das darauf beschränkt oder kann man potenziell auch irgendwelche, ich weiß es nicht, Desktop-Anwendungen in einem, also Server-Anwendungen dann natürlich in so einem Container laufen lassen?

[40:54] Desktop-Anwendungen sind, ja, das ist nochmal so eine Sache für sich, ich kann jetzt nur für Linux sprechen, wie das unter Windows, also unter Windows habe ich da überhaupt keine Erfahrungen,

[41:03] aber unter Linux ist das schon kompliziert genug. Das Problem ist ja so, die Applikation, die in einem Container läuft, die ist ja von dem VIRS-System erstmal vollkommen isoliert,

[41:16] das heißt, du siehst jetzt nicht, du hast keinen Zugriff auf das Betriebssystem des VIRS, du hast keinen Zugriff auf irgendwelche Geräte, auf irgendwelche Hardware und genau das ist bei Desktop-Applikationen schon das Problem,

[41:28] weil du ja irgendwie auf den Videospeicher zugreifen musst, du musst vielleicht auf irgendwelche USB-Geräte zugreifen, du willst Mauseingabe haben und so dieser ganze Kram.

[41:36] Da musst du unter Linux zum Beispiel auf alle möglichen Devices zugreifen, die Docker dir erstmal gar nicht gibt und der Trick ist dann, deinen Container, wenn du ihn startest, so zu konfigurieren,

[41:49] dass der Prozess, der im Container läuft, dann auch Zugriff auf alle möglichen Hardware-Devices hat, die er braucht. Das ist so eine Wissenschaft für sich, das ist auch schon echt kompliziert, aber es geht.

[42:02] Am besten wäre es, wenn ich, ich sag fast mal kurz zusammen, am besten habe ich eine Anwendung, die packe ich in den Container, die starte ich einmal und dann läuft die und da muss ich eigentlich nie interaktiv irgendwas machen,

[42:12] sondern es ist am besten einfach eine Server-Anwendung, die auf Requests irgendwie lauscht und das ist eigentlich, ich sag mal, perfekt geeignet für so einen Docker-Container.

[42:20] Genau, was am besten funktioniert ist, wenn es halt wirklich irgendwie Headless ist, also wenn es in einer Server-Applikation ist. Was man auch häufig sieht, ist, dass zum Beispiel irgendwelche Kommandozeilentools als Docker-Image gebaut werden.

[42:35] So, da hast du jetzt nicht diesen typischen Server-Applikations-Use-Case, dass du halt einen Prozess hast, der ständig läuft, der deine Anfragen beantworten muss, aber wenn es zum Beispiel irgendeine Kommandozeilen-Applikation, die in Java geschrieben ist zum Beispiel, da hast du ja grundsätzlich erstmal die gleichen Herausforderungen, weil die auch ihre Abhängigkeiten hat,

[42:53] vielleicht bestimmte Bibliotheken braucht, vielleicht eine bestimmte Laufzeit-Version hat, voraussetzt und auch das kann man über Container zum Beispiel lösen, indem du ein Container-Image baust, was per Kommandozeile einmal gestartet werden kann, dann irgendwie seinen Job macht und dann sich dann wieder beendet. Also so für typische Batch-Jobs oder sowas, das funktioniert auch.

[43:15] Das heißt, also ich starte eigentlich nicht das Programm, sondern ich starte über die Kommandozeile den Container, der dann hochgefahren wird, das Programm ausführt, mir den Output liefert, den Container wieder runterfährt und das sieht so aus, als würde es quasi on the fly laufen, ja?

[43:28] Genau. Und das Schöne ist, so ein Container startet da tatsächlich so schnell, dass du da in der Regel gar nichts vermerkst.

[43:35] Ja, sehr krass. Dann würde ich irgendwie abschließend zu dem Thema nochmal fragen, was machst du denn jetzt selber eigentlich mit Docker? Also ich meine, okay, so für euer Unternehmen sicherlich super hilfreich und ich habe auch schon gelernt, da kann man sich gut Produktionssachen mit nachbauen und so weiter. Sind das auch so die Use Cases, die du so in der täglichen Arbeit damit für dich als positiv bewertest oder hast du noch irgendwie was ganz anderes cooles, was du jetzt mit machst?

[43:59] Genau, also was ich im Moment mit Docker mache, ist das, also wir haben ja die Herausforderung, dass wir bestimmte Applikationen für unsere Kunden betreiben möchten, wie zum Beispiel ja so die ganzen üblichen PHP-verdächtigen, WordPress-Typo 3.

[44:17] Das heißt, was wir uns überlegen müssen, ist, wie sieht überhaupt so eine Container-Landschaft aus, in der ich jetzt zum Beispiel eine Typo 3 betreiben möchte, aus welchen Containern besteht das, weil den kompletten Stack, den kriege ich ja nicht in einem Container untergebracht.

[44:33] Da ist eine Datenbank mit drin, also da ist eine MySQL irgendwo mit drin, da ist ein Caching-Server, ein Redis irgendwo mit drin, da ist vielleicht noch ein Solr Suchindex irgendwo mit drin und das ist eine Applikation, wird dann am Ende so ein recht komplexes Konglomerat aus verschiedenen Containern, die dann irgendwie miteinander sprechen müssen.

[44:54] Dann muss das Ganze irgendwie auch noch horizontal skalierbar sein, weil das muss ja dann auch noch mit zigtausend Requests die Minute klarkommen.

[45:05] Das ist so unsere große Herausforderung im Moment, uns zu überlegen, wie sieht überhaupt so eine Container-Topologie für solche Applikationen aus, wie funktioniert das und was wir im Moment auch machen, ist die Software zu schreiben, die diesen ganzen Kram halt automatisiert.

[45:22] Wir setzen ja relativ viel auf Kubernetes auf und was wir im Moment recht intensiv machen, ist eigene Software zu schreiben, die wiederum Kubernetes erweitert und zusätzliche Features, um quasi auf einfache Art und Weise das zu machen, was wir wollen von Kubernetes.

[45:43] Ja, das hört sich auf jeden Fall aus einem sehr komplexen Use-Case an und ich kann das völlig nachvollziehen, dass man da nach Lösungen für die bisherigen Probleme sucht, also da sehe ich definitiv auch die Benefits.

[45:53] Was mir jetzt gerade noch eingefallen ist, weil du es auch gerade gesagt hast, wir hatten jetzt gesagt, solche Container funktionieren am besten, wenn sie nichts irgendwie an Daten ändern oder ablegen, jetzt habe ich aber so eine Datenbank in dem Container drin, du sagtest gerade Redis, wo speichert Redis jetzt seine Daten?

[46:08] Kubernetes bietet Integrationen für verschiedene Netzwerkstorages an.

[46:16] Das ist dann so ein Punkt, wo Theorie und Praxis häufig auseinanderlaufen, weil wenn du jetzt wirklich Microservices nach Lehrbuch machst, heißt es halt ja, deine Container müssen zustandslos sein und persistente Daten sind schlecht und böse und in der Praxis sieht es dann halt doch wieder anders aus, weil so Hand aufs Herz, irgendwo müssen die Daten ja gespeichert werden.

[46:38] Und Kubernetes wählt da auch so ein bisschen den pragmatischen Ansatz und bietet dir als Nutzer auch tatsächlich die Möglichkeit, persistenten Speicher zu integrieren in deine Infrastruktur.

[46:52] Die Herausforderung dabei ist, dass du dich in so einer Container-Infrastruktur ja in einem sehr, sehr dynamischen Umfeld bewegst, das heißt auch einen Datenbank-Container, der jetzt in diesem Moment auf einem ganz bestimmten Stück Blech gerade läuft.

[47:11] Das kann sein, dass der in einer halben Stunde auf einmal woanders läuft und dann musst du natürlich zusehen, dass die Daten für diese Datenbank dann auch irgendwie mitkommen, was dann tatsächlich der Weg ist, um sowas zu lösen, ist, dass du mit irgendwelchen Netzwerkstorages arbeitest.

[47:27] Das kann im einfachsten Fall irgendwie irgendein NFS-Share sein, auf dem deine Daten zum Beispiel liegen, wobei ich das jetzt nicht empfehlen möchte, also man sollte keine MySQL-Datenbank aus einem NFS-Volume betreiben, das macht keinen Spaß.

[47:41] Aber das kann zum Beispiel sowas sein, wie irgendwie ein Netzwerk-Block-Device, so wenn du in der Cloud bist, zum Beispiel irgendwie ein EBS-Block-Device oder wenn du es selber hostest, ein Ceph-Device oder ein Ceph-File-System, also Kubernetes hat irgendwie eine Liste von allen Storage-Anbietern, die es irgendwie unterstützt, sei es jetzt Cloud-basiert oder zum selber hosten.

[48:01] Das sind irgendwie 20 verschiedene Storage-Lösungen, die da unterstützt werden. Also das ist tatsächlich ganz sehr vielfältig.

[48:11] Und wie kann ich mir das in dem Container vorstellen? Ich habe jetzt angenommen, so ein Container, da ist jetzt diese Redis-Datenbank drin und sage ich dir dann quasi einfach über irgendein Docker-Skript, Mensch, wenn du deine Daten speicherst, dann nutze aber bitte diesen externen Speicher, den ich dir noch irgendwie ins File-System mounte oder wie sieht das dann aus?

[48:28] Oh, das ist schön, das ist für den, also wenn du einem Container ein Netzwerk-File-System unterschiebst über Kubernetes, ist das für den Container selber total transparent.

[48:39] Der sieht das als Dateisystem, was jetzt genau wirklich dahinter steht, kann der Applikation, die im Container läuft, eigentlich relativ egal sein.

[48:50] Ja, jetzt, also du hast gerade schon so ein paar Sachen angesprochen, so Zustandslosigkeit dieser Services wäre irgendwie ganz cool und ja, so persistenter Speicher ist zumindest auch eine Herausforderung, muss man sich auf jeden Fall drum kümmern.

[49:01] Gibt es noch irgendwie andere, ich sage mal jetzt, ich will nicht sagen Nachteile, aber vielleicht irgendwie Probleme, die sich in der Praxis ergeben, wenn man jetzt einfach mal eben auf Docker umsteigen will?

[49:09] Genau, gerade wenn du im verteilten Umfeld arbeitest, also wenn du jetzt wirklich ein Kubernetes-Cluster zum Beispiel an den Start kriegen willst, das ist, die ersten Schritte sind da relativ einfach gemacht, weil es halt auch fertige Setup-Skripte gibt, die dir irgendwie so ein Cluster aus dem Boden stampfen.

[49:28] Nichtsdestotrotz gibt es natürlich dann viele Fragen, die du irgendwie klären musst, so im weiteren Verlauf so eines Projektes.

[49:35] Storage ist eins davon, das heißt, du musst dich irgendwie um eine effiziente Storage-Architektur kümmern, so damit du halt auch einen persistenten Datenspeicher für deine ganze Infrastruktur irgendwie vorhalten kannst.

[49:45] Netzwerk ist das zweite Thema, geht so ein bisschen mit Storage einher.

[49:50] Netzwerk mit geringen Latenzen, damit das Ganze irgendwie so funktioniert.

[49:58] Was dann noch die nächste große Frage ist, ist wie kriegst du, wo wir vorhin schon kurz drüber gesprochen haben, wie kriegst du Traffic in dein Cluster rein, also so dieses typische Ingress-Routing?

[50:08] Machst du das über irgendeinen Software-Load-Balancer, kaufst du irgendeinen Hardware-Load-Balancer ein, den du jetzt mit Kubernetes integrierst?

[50:15] Machst du das über einen Cloud-Provider, wenn du in der Public Cloud unterwegs bist?

[50:19] Das sind alles Sachen, um die man sich tatsächlich kümmern muss, weil Kubernetes da nicht unbedingt jetzt die festen Antworten bietet, weil Kubernetes jetzt nicht auf eine bestimmte Plattform zum Beispiel zugeschnitten ist.

[50:33] Das heißt, Kubernetes ist schon so gedacht, dass es auf eine gewisse Art pluggable ist, dass du deine eigenen Komponenten dazuschalten kannst, aber du musst das dann halt auch machen.

[50:47] Du musst dich selber um Storage kümmern, du musst dich um Networking kümmern, du musst dich um Ingress-Routing kümmern, weil da sagt Kubernetes, lieber Nutzer, das ist jetzt echt dein Problem.

[50:57] Also so eine grobe Zahl, also für mich hört sich das jetzt als zentraler Nachteil an, ich muss mich erstmal in den ganzen Kram einarbeiten.

[51:05] Okay, das hat man bei jeder neuen Technologie, aber wenn ich jetzt wirklich mal mit so einem Ding starten will, hast du da irgendwie so eine Zahl aus dem Bauch heraus, wie lange man sich damit beschäftigen muss, um den ganzen Kram auch zu verstehen, den man da tut?

[51:17] Oh, das ist eine gute Frage. Wir selber beschäftigen uns jetzt schon so lange damit, dass ich gar nicht mehr genau auseinander friemeln kann, wie lange wir jetzt für Einarbeitung und für tatsächlich produktive Entwicklungen benötigt haben.

[51:32] Wenn man einfach nur in Kontakt kommen will mit dem ganzen Thema, das ist tatsächlich schnell gemacht.

[51:38] Das ist jetzt für den Produktivbetrieb natürlich komplett ungeeignet, aber was es zum Beispiel gibt, ist ein Projekt namens Minikube, was du nutzen kannst, um einfach lokal bei dir auf dem Entwicklungsrechner irgendwie so ein voll funktionales Kubernetes-Cluster an den Start zu kriegen.

[51:53] Was du auch machen kannst, ist, es gibt verschiedene Setup-Tools, die dich unterstützen bei dem Setup von so einem Cluster, von denen allerdings die meisten voraussetzen, dass du in irgendeiner Cloud-Umgebung unterwegs bist.

[52:09] Sei es jetzt eine Public Cloud wie AWS oder Azure oder eine Hosted Private Cloud, OpenStack oder was es da sonst noch alles so gibt.

[52:17] Das heißt, die setzen dann schon ein bisschen was an Infrastruktur voraus.

[52:22] Wenn man das hat, ist das gut, dann kann man darauf aufbauen.

[52:26] Wenn man wirklich vom Scratch anfängt, muss man da schon ein bisschen Vorarbeit leisten.

[52:31] Gibt es dann auch bezüglich meiner Anwendungsentwicklung, meiner Programmierung irgendwas, woran ich denken muss?

[52:38] Also wenn ich jetzt zum Beispiel weiß, dass meine Anwendung später in einem Docker-Container läuft, muss ich dann bei der Programmierung irgendwas Besonderes beachten?

[52:46] Jetzt kann so ganz einfache Sachen sein wie zum Beispiel, verlasse dich nie auf eine IP-Adresse, sondern immer nur auf einen DNS-Namen, was man natürlich auch sonst machen sollte, aber davon mal abgesehen.

[52:54] Also gibt es da irgendwie sowas, wo ich auch als Programmierer wirklich anders entwickeln muss?

[52:58] Anders entwickeln muss, nicht unbedingt.

[53:02] Du solltest natürlich grundsätzlich irgendwie so diese ganzen üblichen Architektur-Paradigmen einhalten.

[53:08] Ich denke jetzt hier an 12-Factor-App und was es da sonst noch alles gibt.

[53:13] Schwierig ist es zum Beispiel immer genau, wenn du dich erstmal auf irgendwelche Eigenarten deiner Umgebung verlässt, wenn du zum Beispiel Annahmen über IP-Adressen triffst oder sowas.

[53:23] Das sollte man sowieso nicht machen.

[53:25] Was auch immer gefährlich ist, ist Zugriff ins lokale Dateisystem, weil du halt nicht genau weißt, läuft das Ganze jetzt verteilt, wird dieser Container später mal horizontal skaliert?

[53:38] Habe ich am Ende irgendwelche Inkonsistenzen, wenn ich da jetzt im lokalen Dateisystem rumschreibe und das ist nicht irgendwie übers Netzwerk synchronisiert?

[53:46] Da sollte man im Zweifel vorsichtig mit sein.

[53:49] Was gibt es sonst noch? Am besten keine Applikationen schreiben, die unbedingt als Root laufen müssen, aber das sollte eigentlich auch selbstverständlich sein.

[53:58] Ansonsten sollte es das eigentlich schon fast gewesen sein.

[54:03] Diese Container-Umgebungen, die sehen vieles nach.

[54:08] Das ist ja tatsächlich auch ein Ansatz, den man relativ häufig findet, dass Leute versuchen, Altapplikationen mit möglichst geringen Anpassungen irgendwie zu containerisieren.

[54:20] Und in vielen Fällen funktioniert das tatsächlich auch ganz gut, weil du halt im Container die Möglichkeit hast, viele Eigenarten der Laufzeitumgebung, in der so ein Altprogramm vielleicht vorher gelaufen ist oder sowas, irgendwie gut abbilden zu können.

[54:34] Jetzt mal losgelöst von irgendwelchen IPs oder sowas.

[54:38] Ich hätte jetzt eigentlich erwartet, jetzt kommt das Antwort, na klar, du musst als Microservice-Architektur jetzt von nun an nur noch arbeiten, aber das ist offensichtlich dann nicht so.

[54:47] Das ist natürlich am besten, aber das ist jetzt nicht unbedingt ein Muss, wenn du mit Containern arbeiten möchtest.

[54:55] Unabhängig davon sind Microservices und Container natürlich zwei Sachen, die ganz gut miteinander funktionieren.

[55:04] Oder anders formuliert, wenn du jetzt mit Microservices arbeitest, machst du dir meistens auch eine große Freude damit, wenn du auch das Ganze irgendwie in Containern deployst am Ende.

[55:16] Aber der Umkehrschluss ist jetzt nicht unbedingt immer gültig.

[55:20] Okay, ja, das war für mich schon relativ viel Input. Das fand ich schon mal sehr spannend.

[55:25] Eine Frage habe ich aber noch. Docker ist jetzt so der Platzhirsch bei den Containern.

[55:28] Gibt es überhaupt realistisch eine Alternative? Ich weiß, dass es noch andere Containerdienste gibt, aber wenn ich jetzt in das Thema einsteigen will, sollte ich lieber gleich auf Docker setzen oder gibt es ernstzunehmende Alternativen?

[55:40] Genau, Docker ist ja so ein bisschen der de facto Standard im Moment.

[55:45] Es gab vor einer Zeit nochmal ein alternatives Produkt, das hieß Rocket.

[55:50] Geschrieben einfach nur RKT, wobei ich jetzt auch gestehen muss, ich habe da jetzt länger nichts mehr von gehört.

[55:56] Das ist aus der öffentlichen Präsenz so ein bisschen verschwunden.

[56:01] Deswegen bin ich mir da nicht ganz sicher, ob das Projekt noch am Leben ist.

[56:08] Was es ansonsten noch gibt in Richtung Container sind solche Lösungen wie LXC, LXD.

[56:16] Wobei die tatsächlich auch einen anderen Architekturansatz verfolgen.

[56:20] Ich habe ja vorhin gesagt, Docker verfolgt ganz stark dieses Ein-Service-Pro-Container-Prinzip, dass du zum Beispiel nur deinen Webserver oder nur deinen Applikationsserver im Container laufen hast und sonst nichts.

[56:34] Bei LXC ist das Ganze ein bisschen anders, weil LXC tatsächlich versucht, im Grunde ein komplettes Betriebssystem minus dem Kernel im Container zu betreiben.

[56:45] Da hast du dann wirklich einen System D und einen Downloading-Server und einen Logging-Dienst und einen SSH-Server und alles Mögliche im Container laufen.

[56:55] Die Dinger verhalten sich dann noch eine ganze Ecke mehr wie eine VM, als das zum Beispiel ein Docker-Container tut.

[57:01] Die meisten davon habe ich auf jeden Fall noch nie gehört. Scheint Docker das wichtigste zu sein. Das ist schon mal gut.

[57:06] Ja, super. Von meiner Seite aus haben wir das Thema Docker hervorragend bearbeitet.

[57:10] Also meine Fragen wurden komplett geklärt. Das fand ich schon mal sehr hilfreich und vor allem haben mir auch die Tipps gefallen, was ich persönlich mit Docker tatsächlich dann auch noch anstellen kann, auch wenn das Unternehmen das vielleicht noch nicht eingeführt hat oder keinen Sinn darin sieht.

[57:23] Also von daher erstmal vielen Dank. Hat mir viel Spaß gemacht und ich habe da einiges mitgenommen.

[57:27] Ich habe jetzt zum Abschluss des Gesprächs nochmal so ein paar allgemeine Fragen.

[57:31] Ich mache ja hier so einen Podcast für Auszubildende und von daher ist meine Frage auch an jeden Gast immer, ob du selber irgendwas mit der Ausbildung von Entwicklern Nachwuchs zu tun hast oder ob du eher so der Architekt im Elfenbeinturm bist.

[57:47] Das ist jetzt schon sehr suggestiv gestellt, die Frage. Ja, so eine Selbsteinschätzung ist immer schwierig. Ich glaube, wahrscheinlich behauptet keiner von sich jetzt im Elfenbeinturm zu sitzen.

[57:58] Nee, tatsächlich, also Ausbildung ist bei uns schon irgendwie so ein bisschen so Gemeinschaftsaufgabe.

[58:05] Ich bin da jetzt in der wirklich strukturierten Ausbildung von Auszubildenden gar nicht so tief integriert bei Mittwald.

[58:14] Was aber jetzt natürlich nicht heißt, dass ich jetzt nicht ab und an mal irgendwie einzelne Trainingsblöcke so innerbetrieblich mache, die jetzt aber nicht unbedingt nur auf Auszubildende zugeschnitten sind, sondern das ist eher so auf das gesamte innerbetriebliche Weiterbildungsprogramm zugeschnitten.

[58:32] Also ihr macht auch intern mal so Sachen, das interessiert mich persönlich auch immer, wie man sich so austauscht mit auch unter den Kollegen und so, dass ihr mal so einen, ich weiß nicht, ich hab mal so einen Begriff gehört, Lunch and Learn, da setzt man sich mal eben für eine Stunde zusammen, hält so ein paar Vorträge oder tauscht sich über ein Thema aus. Macht ihr sowas auch bei Mittwald?

[58:48] Das ist witzig, dass du fragst danach tatsächlich. Wir haben gerade, wann war es, heute ist Dienstag, gerade vorgestern, am Samstag, einen Barcamp gemacht intern.

[58:59] Wir sind als Unternehmen ja auch relativ viel auf allen möglichen Konferenzen und sowas unterwegs, um auch in Kontakt mit den ganzen Open-Source-Communities zu bleiben.

[59:09] Und was man da relativ häufig findet, ist, dass die Leute halt irgendwelche Barcamps veranstalten, wo ja Leute einfach zusammenkommen und sich dann im Grunde in Selbstorganisationen irgendwie dann spontan irgendwie so ein kleines Konferenzprogramm zusammenzustellen.

[59:24] Und wir haben uns irgendwann mal gesagt, ja, das ist ja ganz cool, jetzt irgendwie auf dem WordPress-Camp so zu sein und da irgendwie mitzumachen, aber könnte man das nicht auch mal selber machen, weil wir jetzt ja auch schon 150 Leute sind.

[59:34] Und wir haben da von der Zeit mit angefangen und fanden das dann auch dann tatsächlich ganz cool, als wir das durchgezogen haben. Und seitdem machen wir das regelmäßig.

[59:42] Ich hab das auch schon mal vorgeschlagen bei meinen Kollegen, da ist immer so ein bisschen die Befürchtung, ja Mensch, und was ist, wenn wir keine Themen finden? Hat das gut funktioniert bei euch, oder?

[59:52] Man findet immer irgendwas. Ja, also selbst erfahrungsgemäß, wenn es halt sonst wirklich nichts Neues gibt, ich hab mittlerweile auch so ein relativ vielfältiges Repertoire an Themen, die ich einfach so spontan mal irgendwie raushauen kann.

[1:00:10] Und falls halt sonst keiner was hat, dann gräbst du halt irgendeine alte Klotte aus deiner PowerPoint-Kiste nochmal wieder aus und es finden sich immer noch 30 Leute, die es noch nicht gehört haben. Also du kriegst so einen Tag schon voll, auf jeden Fall.

[1:00:23] Ja, ich glaube, ich nehme das auch nochmal mit als Anregung und das wirst du auch nochmal immer probieren. Ich weiß jetzt gar nicht, ob du das schon erzählt hast, aber wie viele Software-Entwickler habt ihr überhaupt bei Mittwald? Wovon reden wir da?

[1:00:35] Das müsste sich so in der Größenordnung insgesamt 20 bewegen. 20, 25.

[1:00:42] Da hat man natürlich auch schon einen gewissen unterschiedlichen Erfahrungsschatz und kann sich auch über solche Themen austauschen.

[1:00:47] Das ist ja schon, ich sag mal, so eine kritische Menge nicht, aber auf jeden Fall genug, wo man sich untereinander austauschen kann.

[1:00:52] Das ist ja schon mal cool.

[1:00:54] Wobei, wenn wir jetzt so ein Barcamp oder sowas intern machen, das ist dann wirklich fürs Gesamtunternehmen.

[1:00:59] Also das ist jetzt nicht, das ist komplett offen.

[1:01:02] Ah, okay, gut. Also auch mit Fachlichkeit und allem, was dazugehört und ich weiß nicht, Support oder…

[1:01:08] Mit allem, was dazugehört, genau.

[1:01:11] Also das WIC ist so eine, ich sag mal, so eine offizielle Firmenveranstaltung, wo man dann so ein bisschen mal über alles redet, wofür man im Arbeitsalltag vielleicht keine Zeit findet.

[1:01:20] Genau, deswegen auch am Wochenende, das ist halt immer so, das ist natürlich dann immer so die Sache, ob die Leute dazu bereit sind.

[1:01:26] Hat sich bei uns herausgestellt, sie sind's, also das klappt.

[1:01:30] Kommt natürlich dann auch so ein bisschen auf die Firmenkultur an, wie sowas ankommt.

[1:01:34] Erfahrungsgemäß, wir hatten irgendwie so ein bisschen Sorge, wenn man das am Wochenende macht, kommen die Leute dann auch tatsächlich oder sagen die, bleib mir weg mit sowas.

[1:01:43] Das hat sich als unberechtigt herausgestellt, die Sorge, so im Nachhinein, weil sich das eigentlich bisher immer ganz solider Teilnahme erfreut hat, solche Veranstaltungen.

[1:01:52] Aber das kommt wahrscheinlich auch so ein bisschen auf die Firmenkultur an, ob und wie gut sowas dann funktioniert, gerade am Wochenende.

[1:01:58] Ja, ganz bestimmt, das glaube ich sofort. Es gibt bestimmt Unternehmen, wo das einfach so ganz normal ist, dass man auch nochmal ein bisschen Spaß zusammen hat.

[1:02:08] Ich glaube, das passt ganz gut, weil so ein Barcamp ist ja jetzt nicht unbedingt so das Tagesgeschäft, was man abarbeiten muss.

[1:02:13] Das ist irgendwie eine lockere Runde, sage ich jetzt mal und kann ja auch Spaß machen.

[1:02:17] Auf jeden Fall, das ist ja auch eines der viele dabei.

[1:02:21] Wir haben auch immer so einen gewissen Anteil an Off-Topic-Themen dabei, die jetzt irgendwie so mit dem Handwerk an sich gar nichts zu tun haben.

[1:02:29] Irgendwie auf dem letzten Barcamp hatten wir einen Kollegen dabei, der einfach Fotos von seinem letzten Urlaub gezeigt hat in großer Runde und irgendwie ein bisschen davon erzählt hat.

[1:02:40] Ja, und für sowas ist dann halt auch Luft. Das lockert das Ganze dann nochmal ein bisschen auf.

[1:02:44] Ja, dann geht es noch ein bisschen in die Richtung Fort- und Weiterbildung.

[1:02:48] Das soll ja auch so dienen, dass die Leute sich untereinander ein bisschen austauschen und ja, letztlich auch vielleicht ein bisschen was da für das eigene Tagesgeschäft auch wieder mitnehmen.

[1:02:55] Hast du sonst irgendwie Empfehlungen, beziehungsweise wie bildest du dich zum Beispiel selbst weiter?

[1:02:59] Mein persönlicher Hintergrund ist natürlich immer, hast du zum Beispiel auch mal irgendwie so ein Buch gelesen, was du weiter empfehlen kannst?

[1:03:05] Ich finde es ja immer ganz wichtig, dass man sich zum Beispiel, gerade wenn man so ein komplexes Thema hat, wie vielleicht Docker oder so, sich erstmal mit so einem schönen, dicken Wälzer hinsetzt und das mal schön durcharbeitet.

[1:03:14] Ich weiß nicht, wie gehst du da vor?

[1:03:16] Komplett anders tatsächlich. Ich muss jetzt leider gestehen, jeder Mensch lernt ja irgendwie anders am besten.

[1:03:25] Und ich bin selber überhaupt nicht der Buchlerner. Was ich mache, wenn ich mich in irgendein neues Thema einarbeiten möchte, ist, dass ich einfach anfange irgendwo mit.

[1:03:36] Und das fängt meistens irgendwie damit an, dass ich vielleicht mal irgendwie das Tutorial durchklicke, irgendwie so vom offiziellen Projekt.

[1:03:44] Und dann versuche ich von da an irgendwie auf eigenen Beinen weiter zu humpeln dann meistens und versuche dann quasi hands on mich irgendwie in so ein Thema einzuarbeiten.

[1:03:58] Ich habe für mich selber gemerkt, das funktioniert für mich besser, als wenn ich jetzt irgendwie ein Buch durchexerziere.

[1:04:04] Also dann wird mir irgendwann langweilig und dann lege ich das beiseite und dann ist auch wieder nichts draus geworden.

[1:04:11] Aber wie gesagt, das ist halt für jeden unterschiedlich.

[1:04:14] Ja, absolut. Aber ich hatte ja auch schon ein paar Gäste, die das genauso sehen, die gesagt haben, ja, gehen wir bloß weg mit Büchern, hier, ich weiß nicht, YouTube-Tutorials oder wie.

[1:04:22] Und das finde ich auch völlig richtig. Also ich sehe es auch bei meinen eigenen Azubis, die haben auch ganz unterschiedliche, ich sag mal, Vorlieben.

[1:04:27] Der eine liest eher, der andere hört sich vielleicht wirklich Videos an oder guckt sich Videos an.

[1:04:32] So, absolut. Ich will das gar nicht in Frage stellen, sonst was. Ich bin eher so der klassische, da muss man doch mal ein Buch drüber gelesen haben, dann kennt man sich auch aus.

[1:04:40] Für mich funktioniert das immer ganz gut. Ja, war schön zu hören, dass das auch anders geht auf jeden Fall.

[1:04:44] Sehr gut. Aber trotzdem noch eine konkrete Frage zu einem Buch. Ich weiß nicht, vielleicht hast du ja irgendwann mal ein Buch über IT gelesen, vielleicht wurdest du im Studium gezwungen.

[1:04:52] Hast du vielleicht irgendein All-Time-Favorite, wo du sagst, Mensch, hier, jeder IT-Azubi oder Anwendungsentwickler-Azubi muss das Buch gelesen haben.

[1:05:00] Wenn ich mich auf eins festlegen müsste, dann würde ich fast sagen Clean Coder von Robert Martin.

[1:05:06] Aber Clean Coder, nicht Clean Code, sondern dieses zweite Ding von ihm.

[1:05:10] Genau. Das fand ich tatsächlich ein sehr schönes Buch, gerade weil es sich nicht auf irgendwelche fachlichen Kenntnisse oder sowas bezieht, sondern einfach so auf die persönlichen Eigenarten, die man als professioneller Softwareentwickler irgendwie an den Tag legen sollte.

[1:05:26] Kennst du das Buch?

[1:05:28] Ja, ich habe es tatsächlich auch gelesen. Ich habe jetzt gerade Clean Code, dann Clean Coder und jetzt gibt es da noch Clean Architecture, hat er jetzt gerade rausgebracht vor zwei, drei Monaten oder so.

[1:05:38] Das ist eigentlich runtergeladen, aber noch nicht gelesen. Aber das steht als nächstes dann an.

[1:05:44] Ansonsten von Uncle Bob lese ich grundsätzlich alles. Das ist ja hier der Meister. Würde alles weiterempfehlen.

[1:05:50] Auf jeden Fall. Auf jeden Fall.

[1:05:52] Sehr schön. Okay, dann hätte ich so als letzte Frage eigentlich nur noch, ob wir vielleicht irgendwas vergessen haben. Willst du noch irgendwas erzählen zu Docker, zu ich-weiß-es-nicht, Clean Coder oder sonst was? Oder sind wir sonst durch mit den Themen?

[1:06:03] Ich glaube, wir haben das Thema ganz gut erschlagen. Also ich habe jetzt zumindest nicht das Gefühl, dass irgendwas total Wichtiges auf der Strecke geblieben wäre.

[1:06:11] Okay, das freut mich. Sehr gut. Ja, dann zuletzt die wichtige Frage, wenn Leute mit dir Kontakt aufnehmen wollen, weil sie noch mehr über Docker lernen wollen oder sich beim Mitwalt bewerben oder wie auch immer, wie können sie dich am besten erreichen?

[1:06:26] Genau, ich habe eine Webseite. Da würde ich dir etwa nochmal den Link schicken, dass du das irgendwie beim Podcast oder so mit verlinken kannst. Genau, ich habe ansonsten noch ein Gitterprofil, falls die Leute mal schauen wollen, was ich irgendwie so programmiere, wenn ich irgendwie gerade nicht bei Mitwalt sitze. Da sind irgendwie so ein paar Hobbyprojekte drauf.

[1:06:45] Und genau, falls jemand jetzt sagt, Mitwalt klingt total geil, da will ich unbedingt mal reinschauen, kann ich da natürlich auch noch einen entsprechenden Link zur Verfügung stellen.

[1:06:54] Perfekt. Magst du trotzdem nochmal einmal die Websites nennen? Denn es gibt auch viele Leute, die hören das bestimmt nur und gehen dann gar nicht auf die Shownotes. Aber wenn sie das trotzdem dann eintippen wollen, wie lauten denn die Links?

[1:07:06] Genau, da kannst du gucken auf www.martin-helmig.de und dann auf github.com slash martin-helmig. Und für die Leute, die sagen, Mitwalt klingt total geil, ich will mehr wissen, karriere.mitwalt.de.

[1:07:21] Okay, dann haben wir eigentlich alles, was wir wissen müssen. Ich hoffe, du kriegst noch ein bisschen Feedback vielleicht zum Podcast. Also ich habe mich sehr gefreut, dass wir uns so lange, so intensiv über Docker unterhalten haben und auch die ganzen anderen Themen.

[1:07:32] Also für mich war es wirklich sehr spannend. Ich habe viel mitgenommen. Ich hoffe, das geht den Zuhörern auch so. Und ja, da bleibt mir eigentlich nur noch zu sagen, vielen Dank, dass du dir die Zeit genommen hast. Und ja, danke für das interessante Gespräch.

[1:07:42] Ja, dafür nicht. Sehr gerne, Stefan.

[1:07:44] So, das war mein Interview mit Martin Helmig. Ich hoffe, es hat dir genauso gefallen wie mir. Ich habe einiges mitgenommen rund um Docker. Ich habe es bislang noch nicht selber in der Praxis eingesetzt und mir einfach auch nur theoretisches Wissen dazu angeeignet.

[1:08:01] Und ich fand es sehr interessant zu hören, was ein Mann der Praxis damit denn im täglichen Geschäft macht. Also mich persönlich hat es viel weitergebracht und ich fand, es war ein sehr angenehmes Gespräch. Ich hoffe, du konntest auch einiges mitnehmen.

[1:08:14] Natürlich weiß niemand, wann das Thema Docker und Containerisierung denn vielleicht auch mal Einzug in die IHK-Prüfung hält. Aber das ist definitiv ein Thema, was uns allein in der Praxis ja auf jeder Konferenz begegnet. Und das ist schon fast zum Standard geworden.

[1:08:27] Zumindest auch gerade im Java-Umfeld wird die Containerisierung sehr stark, auch gerade in Bezug auf Microservices eingesetzt. Von daher, es war an der Zeit, dass wir hier uns darüber mal intensiv unterhalten.

[1:08:38] Und ich finde, das hat heute sehr gut geklappt. Wir freuen uns natürlich auf dein Feedback. Also wenn du noch irgendwelche Fragen hast, Anregungen, egal ob an mich oder an Martin, dann schreib uns gerne an.

[1:08:48] Die Shownotes zur Episode, wo du uns auch kontaktieren kannst und die Kontaktdaten auch findest, die sind wie immer zu erreichen unter anwendungsentwicklerpodcast.de slash 121 für die 121.

[1:09:03] Wir würden uns über dein Feedback freuen. Also hau in die Tasten und schreib uns deine Kommentare. Wir freuen uns darüber.

[1:09:11] Da wir meine angepeilte Zeit von einer halben Stunde heute weit überschritten haben, was auch überhaupt nicht schlimm ist, denn das Thema ist ja wirklich super spannend, höre ich jetzt aber auf zu quatschen und wir hören uns dann beim nächsten Mal.

[1:09:22] Also vielen Dank fürs Zuhören und bis zum nächsten Mal. Tschüss!

[1:09:32] Untertitel der Amara.org-Community