Ja, hallihallo, herzlich willkommen zum Python-Podcast.
Heute haben wir ein Jubiläum und wir haben die zehnte Episode.
Das ist ja hervorragend, cool, ne?
Hurra!
Zehn Stück schon geschafft.
Ja, und es ist noch eine kleine andere Premiere.
Und zwar haben wir heute das erste Mal eine Remote-Sitzung,
einen Studiogast quasi, der nicht bei uns im Garten sitzt.
Wo sitzt du denn, Christian? Hi!
Hi, ich sitze, ihr sitzt im Garten.
Das hat sich gar nicht so angehört.
Ah, okay.
Ich gucke in meinem Garten, ich sitze in meinem Homeoffice,
Ich sitze in der Nähe von Stuttgart.
Ah ja, diese ganz schöne Remote-Verbindung
hier von Düsseldorf nach Stuttgart, durch die Heimrepublik.
Wundervoll.
Was machen wir heute? Wir machen heute DevOps ein bisschen
und wie man Python so
ausschickt.
Wenn man irgendwie Python-Applikationen
entwickelt hat, dann möchte man ja auch irgendwie die
sozusagen dann
produktiv benutzen können, dass andere Leute die sehen und so
und dann, genau, muss man da auch noch Dinge tun,
damit das geht und ja.
Ja, so ein Zirkus.
Genau, dann
Ja, genau, vielleicht
am besten
stellst du dich einfach mal vor, Christian, und dann
genau. Genau.
Ja, kann ich gerne machen. Also ich bin
Christian, auch bekannt als Toini.
Das ist dann auch mein
Twitter-Handle. Und
ich müsste mich jetzt eigentlich fast als
Urgestein in der Python-Szene sozusagen
bezeichnen.
Deswegen bist du auch in unserer Jubiläumsausgabe
dabei.
Mein Herz wird warm. Ich mache Python jetzt seit 99, glaube ich, in der Größenordnung. Ich weiß sogar, dass ich irgendwann 95, 96 als erstes mal Internet hatte, hat mich in irgendeinem obskuren Chatraum damals, das war noch mit AOL oder so, hat irgendwer schon mal Python gesagt. Insofern, mein frühester Kontakt war, glaube ich, mit 14 oder so.
Ja, also relativ viel mitgemacht. Ich habe die Python User Group aufgebaut, die ja aus der deutschen SOAP User Group damals hervorgegangen ist. Ich habe lange SOAP gemacht, da Kernentwicklung, viel mit den Amerikanern zusammen, habe mal auf diversen Sprints so um die Jahrtausendwende rum mit Guido rumgemacht. Wir haben irgendwelche komischen SOAP Sachen geschrieben, die heutzutage nicht mehr existieren.
Der war ja auch bei SOAP bei der Firma irgendwie beschäftigt.
Genau, genau. Soap hat damals tatsächlich eine ganze Zeit lang die Python-Labs bezahlt.
Die waren komplett von der Soap über zwei oder drei Jahre bezahlt worden.
So mit Barry Warsaw, der das Mailman macht und diversen anderen Leuten.
Genau, nee, und da habe ich also jetzt viel in der Python-Szene gemacht,
selber Software entwickelt für gute 15 Jahre im Sinne von Anwendungsentwicklung
und ich mache aber seit Ewigkeiten
halt auch schon, ja, Serverbetrieb
nebenbei und die Firma, wo ich jetzt
bin, die verdient, also die ist
jetzt auch meine Brötchen,
aber die lassen wir jetzt hier einfach mal fröhlich
vor, weil wir keine Werbung haben.
Bei der Python Software Foundation bist du noch, das hat mich noch ein bisschen interessiert,
was ihr denn da noch so macht, vielleicht kannst du die noch mal
kurz so ins Spiel bringen und vorstellen.
Achso, ja, ich habe ja zwei, also es gibt jetzt sozusagen
zwei, es gibt den Python Software Verband,
das ist ein
deutscher Verein und
wir fördern
Python im deutschsprachigen Raum, also
unter anderem durch
Veranstaltungen, also die
PyCon.de,
die richten wir aus. Ich glaube, die PyData
ist unter unserem
Schirm, die wandert aber durch Europa
und wir haben jetzt seit einem
Jahr, seit einem guten Jahr, ein Förderprogramm.
Das ist eigentlich auch was, was man
in dem Podcast hier mal ganz gut platzieren
kann, weil
das Förderprogramm ist im Prinzip dafür da,
dass mehr Leute in der Community
mal Sachen ausprobieren, wie sie Python
in Anführungszeichen unters Volk
bringen. Besser
eigentlich eher ausgerichtet an so einem
Diversity-Gedanken, dass wir
Python selber ist im Mainstream ja
präsent und angekommen. Also vor
fünf Jahren, vor zehn Jahren sah das alles noch ganz anders aus,
aber heutzutage muss man sich ja nicht rechtfertigen
dafür, dass man Python verwendet oder
irgendwo einsetzt, sondern das ist dann eher das, was man unter
Best Practice, so sehr
ich dieses Wort hasse,
abhaken kann und dann ist das irgendwie
erledigt, das ist Chef-approved.
In den letzten Auswertungen über den Jahreswechsel, was die Beliebtheit von Programmiersprachen angeht,
ist Python halt weltweit im Prinzip immer unter den Top 5, wenn nicht sogar auch auf Platz 1.
Deswegen haben wir vom Python-Software-Verband irgendwann gesagt,
Python einfach nur an sich zu pushen, das braucht es gerade gar nicht mehr, das läuft.
Was ich aber spannend fände, ist halt tatsächlich neue Zielgruppen und neue Vernetzungen aufzumachen.
Also zum einen Leute, die mit bestimmten Spezialthemen zu tun haben.
Da hat jetzt als ein großes Gewicht, früher war es viel Web, jetzt ist es Data Science, aber tatsächlich halt auch in den Embedded-Bereich, in den Bastel-Bereich, in der Maker-Szene, rüber hin zu anderen Gruppen wie Jugendlichen.
Denn Diversität zum Thema Frauen in die Informatik ist in Python eh so ein großes Feld.
Die PyCon US war eine der ersten Konferenzen, die über 30 Prozent Frauenbeteiligung sowohl an den Teilnehmern als auch bei den Vortragenden hatte.
Und unter diesem Rahmen gibt es in diesem Gedanken, Python halt sozusagen in so viele kleine Nischen auch reinzubringen und nicht nur durch den Mainstream.
Da gibt es jetzt das Förderprogramm, beziehungsweise gibt es seit einem Jahr und man kann dort zum einen einfach mal kleine Veranstaltungen ausprobieren
Wenn man sagt, ich würde gerne, da haben wir ein paar Leute, die machen an Schulen immer mal was, wo sie Kindern dann Raspberries oder andere kleinere Embedded-Python-Geräte bei einem Workshop in die Hand drücken.
Ja, das ist cool, das habe ich sogar auch schon mal gemacht.
Tatsächlich für Kinderkurse mit dem Raspi und dann in Python mit Minecraft oder so Coden.
Genau, genau.
Und was halt schön wäre, wäre, wenn man den Kindern das halt auch mitgeben kann, damit sie dann halt zu Hause weitermachen und nicht nur mit hier hast du mal was und in zwei Stunden ist es wieder weg.
Und für solche Veranstaltungen sponsern wir dann, ich glaube, so eine Pauschale von 400 Euro pro Veranstaltung, beziehungsweise wir brechen das auch runter auf pro Kopf, pro Kopf gibt es 20 Euro und wenn du abwende 10 Leute hast, kannst du die 400 Euro haben und wir machen das ohne groß Formalismus, da kann man einfach an die E-Mail-Adresse, da gibt es eine, habe ich gerade nicht im Kopf, kann man auf der Webseite nachschlagen.
Ich sage jetzt mal so schön, wie es beim Podcast immer heißt, findet ihr in den Shownotes, können wir da reinpacken, da schreibt ihr eine E-Mail hin, sagt, was ihr machen wollt und dann wird das im Vorstand innerhalb von ein, zwei Wochen beschlossen und dann geht es los und ihr könnt das Geld kriegen, entweder indem ihr uns ein paar Quittungen schickt oder indem wir einen kleinen Sponsoring-Vertrag machen, dann braucht man nicht über irgendwie Kleingruch-Quittungen zu reden.
Genau, das ist die eine Variante. Die andere Variante ist noch, dass wir auch größere Veranstaltungen ab 50 Personen sponsern. Das ist dann typischerweise sowas wie die JungleCon-Sponsorware. Da gibt es dann irgendwie 1000 Euro einmal glatt, um anderen Leuten halt den Zugang zu Veranstaltungen zu erleichtern. Das geht dann typischerweise in Financial Aid oder Reisekosten oder irgendwie solche Töpfe.
Und das dritte, was wir noch sponsern, sind dann tatsächlich auch Feature-Entwicklungen oder allgemeine Entwicklungen für Open-Source-Python-Projekte.
Wenn ihr sagt, wir wollen mal einen Sprint machen und dafür brauchen wir Reisekosten oder wir wollen es mal am Wochenende wegschließen oder ich würde eigentlich gerne mal zwei Tage was machen, aber dann habe ich irgendwie Arbeitsausfall, weil ich keinen Urlaub dafür nehmen kann, dann gibt es dafür Projekte für jede Aktion 500 Euro.
Genau, und die verteilen wir jetzt. Das ist so ein bisschen nämlich das Thema, wir haben über den Verband halt die Möglichkeit, über Sponsoren und über alles andere eben Geldmittel einzusammeln und haben gesagt, naja, wir wollen jetzt eigentlich, dass die Leute, die in der Community aktiv sind und gerade das Thema Sustainability ist ja auch so ein großes Ding, da wollen wir jetzt nicht, dass die Leute, die Zeit mitbringen, auch noch das Geld mitbringen, sondern dass man das ein bisschen einfach nur als, man nimmt den Leuten ein bisschen Druck weg und lässt sie halt experimentieren.
mehr Dinge ausprobieren, mehr schauen,
was funktioniert, was funktioniert nicht
und ganz ohne den Druck sich irgendwie
rechtfertigen zu müssen, ob das jetzt wirtschaftlich war oder nicht.
Klingt super, klingt echt
toll. Das macht ja echt viel
Lust, das klingt echt interessant. Also bestimmt
noch ein paar Interessenten, die das
zu schätzen wüssten. Genau, definitiv. Also gerade bei
den Entwicklungs
Sponsorings ist die
Soap-Plone-Welt irgendwie sehr
stark, weil die halt in der ganzen
Vereins-Community sehr stark vertreten ist.
Die machen halt viel so Sprints, wo sie
sich treffen, wo sie halt an
den Open-Source-Projekten entwickeln
und die fordern
das immer mal ein, die muss man eher mal
bremsen. Dummerweise haben wir niemanden anders,
auf den wir zeigen können mit, hier, die rufen auch Geld
ab, aber komm, nicht dran.
Momentan ist es echt so, dass wir uns eigentlich wünschen würden, dass
mehr Leute auf uns zukommen, dass wir da mehr Gutes tun können.
Umgekehrt kann ich natürlich auch
sagen, jetzt wo ihr wisst, was der
Verband mit dem Geld macht,
werdet Mitglied.
Euer Geld ist gut angelegt.
Genau, das ist so was,
so ein bisschen was wie eine organisierte
Patron-Variante sozusagen dann.
Aber es ist auch für Unternehmen halt ganz schön.
Das andere wäre natürlich,
wenn man sonst sagen kann,
dann mache ich den Kreis
mit diesen ganzen Organisationen zu,
die PSF, die Python Software Foundation,
das ist die amerikanische,
wo auch, ich glaube,
der gehören inzwischen die Copyrights für Python.
Ich glaube, da sind die hingewandert.
Die sind natürlich ziemlich groß,
die haben halt die ganzen Großsponsoren auch,
die koordinieren halt eher so Sachen mit Google
und Microsoft etc.
Die veranstalten ja hauptsächlich auch die große
PyCon US, haben aber eben auch, die haben auch so ein Förderprogramm
und da sind wir aber auch dabei
zuzusehen, dass wir
die Sachen halt mit koordinieren, dass wir
dann, wenn jemand sagt, okay, das Förderprogramm,
was wir haben, das ist eigentlich zu klein,
ich würde gerne von der PSF noch was holen, dann
haben wir da halt auch die Kontakte,
um dann zu sagen, man kennt sich schon und man
muss es nicht groß ausverhandeln, wer da welchen Papierkrieg
über den großen Teich schiebt.
Genau, ja.
Cool, kurze Leitung, also falls ihr den habt,
meldet euch da direkt, könnt natürlich auch das alles kommentieren.
Genau, immer her damit.
Ja, ich habe es letztens nur gehört,
dass es bei Django gibt es da auch sowas,
es gibt halt die Django Software Foundation
und die bezahlen ja jetzt auch, glaube ich,
ein oder zwei Vollzeitstellen.
Aber im Grunde ist das immer so ein Problem,
dass halt Software die wichtige Infrastruktur
für ganz viele Projekte ist.
Dann halt irgendwie so, wo dann, naja, vielleicht so,
Also bei Django ist es so, dass er, glaube ich,
ein halbes Dutzend Leute irgendwie so wirklich aktiv
dran entwickelt und das ist halt eines der
größten Projekte, aber
eigentlich ist das ziemlich wenig, wenn man sich überlegt,
wo das überall eingesetzt wird und
wie viele Webseiten ja
darauf angewiesen sind, dass das irgendwie
weiterentwickelt wird,
Sicherheitsgeschichten irgendwie
gehändelt werden und so.
Das ist,
das berührt ein total interessantes Thema,
was jetzt nicht heute mit unserem Tagesthema zu tun hat,
aber ich habe in der letzten Zeit halt viel
Gedanken mir gemacht,
gerade um die sind,
wie ich an dem Begriff Digitalisierung
irgendwie
einen Griff, also wie ich da irgendwie einen Griff dran
kriege ohne
bla bla.
Keiner kann das Wort eigentlich mehr hören
und wahrscheinlich ist es vom Hype-Cycle her so langsam
durch und ich habe mich immer gewehrt, es überhaupt einzusetzen.
Und aber
dieses, da sind
so wenig Leute teilweise an so kritischen Sachen dran.
Aus einer Open-Source-Perspektive
oder freien Software-Perspektive finde ich das
überhaupt nicht schlimm. Das eigentliche
Thema ist nur, es müssen alle, die
so ein Zeug einsetzen, im Prinzip wissen, sie
zahlen weniger Geld, als man
früher in Lizenzkosten in sowas reingesteckt
hat oder Pflege- und Wartungsverträge.
Das heißt aber im Prinzip,
wenn man dann die Sicherheit haben möchte,
dass einem das nicht unter dem Hintern wegschimmelt,
muss man halt, muss man eigene
Kompetenz aufbauen und das
greift aber genau an dieses Thema ran, was bedeutet
es eigentlich, wenn immer mehr Dinge
digitalisiert werden, dann heißt das halt eigentlich,
ich muss dort mehr Kompetenzen
selber entwickeln, anstatt das Zeug
einfach nur blind einzusetzen, blind zu kaufen,
also fast egal, ob ich es kaufe oder
als Open Source
oder freie Softwarelösung habe.
Ich bin eigentlich darauf angewiesen, wenn das mein Kerngeschäft
so dermaßen berührt, dass ich genügend
Kompetenz habe, um wenigstens zu wissen,
wo meine Risiken sind,
wenn ich es schon nicht selber
lösen kann.
Das ist aber schon wieder so technisches Detailwissen,
das hat der meiste normale Vorstand
wahrscheinlich gar nicht mehr auf dem Schirm.
Der denkt sich dann so, ja, erst Geld ausgeben
für Software, die wir gar nicht brauchen, also
wir kaufen ja nicht, warum?
Ist ja umsonst.
Ich hab da momentan
eine Metapher für,
das ist, Digitalisierung
wird an der Stelle, also die ist ja total relevant,
weil
im Prinzip die alten
Sprüche, die wir jetzt wahrscheinlich schon seit 20 Jahren
kennen, sowas wie Marc Andreessen mit
Software eats the world,
das heißt, alles wird irgendwie Software sein.
In einer positiven
Variante bedeutet
dass Software ist als so Augmentierungshilfsmittel ständig dabei.
Nicht im Sinne von verdrängt den Menschen oder ersetzt ihn,
sondern es wird immer mehr Stellen geben, wo so ein organisches Zusammenwachsen bei Prozessen ist,
wo ich auf unterschiedliche Teile von Software angewiesen bin,
mit der ich interagiere und die sich miteinander verbindet.
Das wird aber so integral sein, dass es tatsächlich im Prinzip wie eine Sprache zu behandeln ist.
Und ich habe momentan immer den Eindruck, wenn jemand in einem Unternehmen,
Wenn du jetzt Vorstand sagst, wir machen jetzt irgendwas mit Digitalisierung, dann klingt es in meinen Ohren so, wie der Vorstand kommt daher und sagt, wir stellen jetzt die Unternehmenssprache von Deutsch auf Englisch um und um das richtig hinzukriegen, haben wir jetzt einen Übersetzer und zwei Wörterbücher angeschafft.
So ungefähr ist es auch. Wir wollen digitalisieren, deswegen kaufen wir jetzt mehr Software ein oder so. Das ist aber ja ein Unternehmen, das im Prinzip wirklich atmen muss. Ich trage da momentan viel mit mir rum und das ist jetzt extrem Python-unspezifisch.
Ja, echt interessant. Das ist auch überhaupt nicht so richtig, es gibt da auch keine gute Kultur für. Also ich habe da auch schon in diversen Unternehmen, die ja dann oft diese ganzen Sachen einsetzen, also am Anfang war es immer noch schwer, das irgendwie durchzusetzen, dass überhaupt irgendwie Open Source verwendet wird und wieso, wenn das nichts kostet, ist ja doof und so, war diese Haltung noch sehr weit verbreitet.
Und dann teilweise wurden so Dinge gemacht, wie Weihnachten, als alle im Urlaub waren,
hat man halt dann die Netscape-Webserver ersetzt durch Linux-Webserver und so.
Und als dann sichtbar wurde, dass das sehr gut funktioniert und auch besser halt oft als die kommerziellen Varianten,
dann hat sich das durchaus etabliert, dass man das so macht.
Aber irgendwie, dass es eine gute Idee wäre, da halt auch selber mit an der Infrastruktur zu arbeiten und dass das natürlich auch Geld kostet oder dass man zumindest Selbstkompetenz aufbauen muss, das ist auch immer noch schwer.
Die ganzen Unternehmen haben das nicht verstanden, was das bedeutet, was Digitalisierung ist. Das bedeutet für jeden irgendwas anderes und die meisten sind so fern von jeder Digitalisierung, schleppen dann die E-Mails ausgedruckt im Koffer mit sich rum, das funktioniert halt dann noch nicht.
Und wenn das die Entscheider noch manchmal sind, leider, dann braucht das länger.
Ja, ich würde mal behaupten, wie war das jetzt mit der PDF-CDU?
Ich würde jetzt halt behaupten, die E-Mails werden nicht mehr ausgedruckt, sondern es werden PDFs draus gemacht, die kann man sich dann aufs iPad legen.
Ja, und dann da drinnen irgendwie rummalen.
Ja, genau.
Ja, alles andere wird dann einfach verboten.
Ich meine, genau das, was du beschrieben hast mit den Netscape-Servern, das ist halt auch der Punkt, wo ich es spannend finde. Meine Erfahrung, würde ich halt sagen, ist jetzt auch 20 Jahre Digitalisierung. Das ist mein ganzes Berufsleben im Prinzip seit 99 und der eigentliche Effekt, den wir gesehen haben, das, was man jetzt Digitalisierung nennt, passiert ja seitdem. Das passiert schon seit Ewigkeiten.
Ich würde sagen, die Jahrtausendwende war tatsächlich so ein Knackpunkt mit Internet, ist explodiert und wir haben damals immer schon Projekte gemacht, wo wir gemerkt haben, du musst Digitalisierung im ganz, ganz, ganz Kleinen umsetzen.
Und die eigentlich großen Effekte, wenn es halt immer heißt, es ist Time to Market oder alles billiger oder schneller oder effizienter oder individueller, die eigentlichen großen Effekte sind nie aus der Planung heraus entstanden, sondern die sind dann entstanden, wenn wir bei den Projekten beim Kunden vor Ort waren und dann zufällig eine Dame, die da Sachbearbeiterin ist, überhören, wie sie gerade unser Projekt benutzt und sie irgendwie über Excel flucht.
Und man dann feststellt, okay, was machst du gerade mit Excel? Ja, da hat sie halt so eine Tabelle gehabt, wo sie so eine Statistik mitführen musste, einmal pro Monat. Und da das ja niemand auf die Idee kam, dass das irgendwas mit unserer Software zu tun haben könnte, mündete es darin, dass diese Dame als halbe Stelle, die hat eine halbe Stelle damit verbracht, 20 Stunden pro Woche, eine Zählliste zusammen zu klicken, indem sie sich durch unsere Software durchgeklickt hat.
Um dann in dieser Excel-Tabelle zu erfassen, wie viele Personen dieses Kriterium, wie viele Personen dieses und wie viele Personen dieses Kriterium hat.
Und nur weil wir neben ihr saßen, immer über die Schulter geschaut hatten, konnten wir mal mit ihr reden und sagen, du, das kann ich dir da rauslassen.
Das merkt man dann so, das ist ja alles relativ komplex.
Und so in Excel kannst du, wenn die Stadt dir so eine Statistik gibt mit tausend Makros drin, dann generierst du das nicht.
Aber wenn du mit den Leuten ein bisschen Ping-Pong spielst mit, zeig mir mal, was du machst.
Und siehst, ah, guck mal, die füllt die Daten immer nur in so einem Rechteck aus.
dann generiere ich dir jetzt eine HTML-Tabelle, die kannst du per Copy & Paste in diese andere Tabelle von der Stadt reinpacken
und plötzlich ist dein 20-Stunden-Job, also 80 Stunden pro Monat auf 5 Minuten eingedampft.
Ich hoffe, die Arme hat dann noch da arbeiten dürfen für irgendwas anderes.
Natürlich, also ihre Vorgesetzte waren halt super glücklich, weil die so viele Themen auf der Pfanne hatten, zu denen sie nie gekommen sind,
aber Bürokratie drückt dir halt immer die Prioritäten weg.
Also Bürokratie
kann ja immer sagen, ich muss gemacht werden,
zum Termin. Und dann hast du die Leute
beschäftigt. Und eigentlich wollen die noch tausend andere
Sachen machen, kommen aber nicht dazu, weil die Bürokratie
das wegfrisst.
Das ist halt dann dringend, aber nicht wichtig eigentlich.
Und die wichtigen Sachen werden dann nicht mehr gemacht.
Genau.
Ich habe viel Komplexitätstheorie
gemacht in den letzten Jahren. Dave Snowden,
Kenevan und so. Und es gibt
ein wichtiges
Ding
aus der Komplexitätstheorie, was da
reinspielt, ist, das sind
die unarticulated needs.
Das ist, die Welt ist so komplex,
dass Anwender
schrägstrich Betroffene
schrägstrich Bürger, schrägstrich
Patienten, egal welche
Teilgesellschaft wir nehmen,
die haben gar keine Vorstellung mehr
davon, was überhaupt möglich ist
oder geschweige denn,
in welcher Sprache müssten sie ihren Bedarf,
den sie haben, überhaupt formulieren, dass jemand
anders angreifen kann, sagen kann,
hier, da kann ich dir helfen. Die Dame hat das
halt in völliger Zufriedenheit
gemacht, sich da monatelang durchzuklicken,
weil ihr nicht bewusst war,
dass es da überhaupt
eine Möglichkeit gibt, das zu lösen.
Die wusste gar nicht, dass es ein Problem war
und deswegen ist das nie in der Planung aufgetaucht.
In Digitalisierungsprojekten musst du im Prinzip
im ganz Kleinen alle Leute im Unternehmen
zu befähigen,
diesen Übersprung zu haben von, hey, Moment,
das hier ist ein Problem,
das müsste sich doch in Software erschlagen lassen.
Und zwar nicht im Sinne eines, oh, wir machen mal
den großen Aufschlag und dieses ganze
Unternehmen wird durch KI ersetzt, sondern tatsächlich
über so ganz völlig blöde
kleine Teilchen
und der Herr Wolfram
von Wolfram Alpha, der hat jetzt
ein paar Artikel geschrieben, wo er meinte halt
Computational Thinking,
wenn wir sagen, in der Schule wird ja Mathematik
gelehrt, aber da lernst du halt nur rechnen.
Und Computational Thinking
wäre tatsächlich total spannend
aus einer Perspektive zu wissen, wann
sind so Zahlen
oder Datenmengen eigentlich für
Computer zugänglich?
Also ich habe jetzt so ein Bauprojekt an der Backe,
weil ich ein privates Haus baue und da fliegen natürlich
tausend Excel-Tabellen rum und wenn ich,
dann habe ich es mehrfach gehabt, dass dann Excel-Tabellen
rausfallen, wo in einer Spalte
irgendwelche Zahlen drinstehen, aber dann gleichzeitig
auch noch irgendwelche Worte mit
entweder einem Kommentar dran oder
irgendwie unterschiedliche Maßeinheiten,
wo ich dann auch drauf gucke und sage so, ja gut,
die kann ich jetzt halt nicht mehr benutzen, um da Formeln drüber zu jagen.
Das geht so nicht.
Aber dieses Gefühl halt, wann
sind Sachen für Rechner zugänglich, das musst du im Prinzip
kulturell in so ein Unternehmen reinkriegen,
wenn du Digitalisierung machen möchtest. Und damit
schlagen wir uns halt seit 20 Jahren rum. Das ist das
ganze 90er Jahre Schulen ans Netz
und das ist Neuland und das ist
Ja, ja, klar. Das ist
ein großer kultureller Wandel, der
da nötig ist und die Leute
müssen, ja, ich meine, es gibt halt so ein paar
Verrückte irgendwie, die das
vielleicht dann vorher schon oder
machen oder sich selber damit so lange beschäftigt
haben, bis sie es irgendwie können. Aber
für viele wird es halt so sein, das ist nur dann natürlich,
wenn man da reingeboren wird.
Ich glaube, das ist auch gar nicht so, weil ich glaube,
gerade durch diese Vereinfachung, die man hat,
man hat jetzt nur noch so ein Pad in der Hand, wo man links und rechts
wischt, ist das nicht unbedingt zugänglich.
Also dadurch, dass du diese tollen User-Interfaces hast
und so, das ist ja... Ja, aber ich glaube, du
kannst nicht ohne die
Sicht der Benutzer oder der
Leute, die sich mit dem
Bereich, mit der Domäne irgendwie auskennen,
ohne die kommst du nicht aus.
Die müssen halt auch sozusagen verstehen,
wie das, was sie tun... Ja, aber die wachsen ja nicht automatisch
mit nach, sondern du musst sie ausbilden. Ich glaube
nicht, dass nur, weil du Digital Native irgendwie bist,
reingebunden wirst, dass das
funktioniert, sondern ich glaube, du musst tatsächlich
mit dieser Brille draufgehen, du wirst jetzt da
Tech-Experte sein.
Ich glaube vor allem auch, es gab einen massiven Bruch durch
die Systeme Android
und iOS, weil
bisher, wir können es natürlich sozusagen
Opa erzählt vom Krieg
spielen.
Ein Chapter Mark, Opa erzählt vom Krieg.
Okay, warte mal, ich mache.
Das ist mir vorgeworfen
worden, nein, das ist mir nicht vorgeworfen worden, aber es ist
irgendwie mit einem zwinkernden Auge auf ein PyCamp
in Köln konfrontiert
wurden, wo ich halt auch meinte, guck mal, die Historie,
ging es um irgendein Stück Technik, wo ich
nochmal irgendwie nachgezeichnet habe, wie das die letzten 15
Jahre halt entstanden ist. Und ich meine, ich bin jetzt
Mitte 30 und werde dann halt von Leuten,
die gerade im Studium stecken, angeguckt mit, Opa erzählt vom
Krieg.
Und es ist aber witzig, weil
klar, wir haben uns, oder also ich mich,
ich glaube, wir sind so eine Liga, glaube ich, vom Alter.
Ich habe
mich so über die 90er Jahre halt durch Sachen durchgequält,
wo ich da sagen muss,
es gab halt nie dort eine Trennung
zwischen Konsument und Produzent.
Ich bin, egal ob auf DOS oder Windows,
dann Mitte der 90er irgendwann Richtung Linux,
da war halt immer ein, du interagierst mit dem Ding
und du versuchst irgendwie rauszukriegen selber,
dass das irgendwie tut, was du willst.
Und jetzt aber in dem ganzen Umfeld iOS, Android
hast du fast reine Konsumentengeräte.
Zumindest auf einer Ebene, wo diese Rekursivität von Rechnern,
Also von Neumann-Maschine, Daten und Programme sind ja im gleichen Speicher und es ist sozusagen eine Wandelgestalt, ob etwas als Datum oder als Programm interpretiert wird, weswegen wir halt auch solche Dinge wie Viren haben.
Und das ist ja was, was damals halt dazu geführt hat, dass man ständig, das war wahnsinnig aufwendig, das willst du nicht für jeden. Wir können ja sagen, okay, wir haben uns da durchgekämpft und was einen nicht umbringt, macht einen stärker.
Aber das ist natürlich nicht die Zugänglichkeit.
Ich sehe aber tatsächlich, dass Tablets und ganz einfache Systeme,
eben auch, dass zum Beispiel das Dateisystem sich ja als Metapher aufgelöst hat im Prinzip,
das macht, dass die Leute diese Universalität der Rechner nicht mehr wahrnehmen,
sondern es ist nur noch eine Sammlung von Apps,
die irgendwie, entweder sind sie miteinander integriert oder sie sind es nicht.
Ja, aber sind wir da nicht vielleicht noch einfach ein bisschen früh dran?
also wenn man sich jetzt sowas anguckt wie Shortcuts
oder so auf iOS,
das geht ja schon so ein bisschen in die
Richtung, dass man damit dann halt auch Dinge tun kann,
wie, ja, ich meine, ich übertreibe jetzt ein bisschen,
aber mit Pipes auf der
Kommandozeile oder so,
nur halt in grafisch und mit einem schönen Interface.
Halt nicht, weil
das ist halt nicht mehr universal. Es geht halt nur das,
was dir zugelassen wird, was geht.
Gut,
okay, ja, man kann natürlich noch einige
Sachen selber schreiben, aber das
ist natürlich dann auch wieder,
da ist man dann sofort in so einem Profibereich,
wo man dann irgendwie
sich registrieren muss bei Apple und so.
Ja genau und das Modell ist halt nicht
sehr stark an der Stelle, sondern das ist halt sehr
darauf angelegt, dass es halt, ich meine,
Sachen einfach zu machen ist ein schwieriges Problem
und Computing
ist ein schwieriges Problem.
Das wird so nicht halt für jeden zugänglich sein,
aber es ist halt, wenn ich die Sprachmetapher
nochmal bemühe, wenn du halt das Unternehmen umstellst
von Deutsch auf Englisch, dann erwartest
du ja auch nicht, dass jeder danach
ein englischer Schriftsteller ist.
Sondern der Wort ist, dass die Leute halt so ein gewisses
robustes Set an Sprache halt
können, mit dem sie halt
wissen, ah, der Empfang kann zumindest mal sagen,
wo die Toilette ist und wo es in die Chefetage geht
und kann dir ein Taxi rufen.
Kantine. Ja, Kantine,
auch noch wichtig, genau.
Aber es ist halt was anderes,
als wenn du dann sagst, wir bringen jetzt das Unternehmen
auf Englisch, indem wir halt überall Wörterbücher auslegen.
Ja.
Das ist halt. Das funktioniert
halt einfach nicht, ja.
Okay, spannend, spannend.
Ja, aber ich glaube, von diesem generellen Problem der Digitalisierung würde ich uns jetzt mal so ein bisschen wieder wegführen, weil wir können das, glaube ich, heute auch nicht mehr reden oder wir können zumindest noch mindestens zwei Stunden darüber reden, was das alles für Fragen ist.
Okay, dann mache ich jetzt hier direkt mal eine Kapitelmarke, aber ich würde auch noch gerne eine Sache ansprechen, wo es, ich glaube, da ging es kurz eben drum, aber ich habe es nicht geschafft, da reinzugrätschen.
Aber nur ganz kurz, weil wir wollen dann auch erklären tatsächlich, wie man das mit Python so machen kann.
Ja, und zwar ging es da um die Bereiche, in denen Python eingesetzt wird. Ich weiß nicht, habt ihr das mitbekommen, die PyCon US war jetzt erst vor kurzem und die Keynote hat da, glaube ich, Russell Keyes McGee oder so gehalten.
Ich weiß nicht, ob ihr den Vortrag gehört habt.
Ich war im Urlaub.
Achso.
Nee.
Nee. Ich hab Kinder.
Ganz gute Entschuldigung.
Immer.
Was ich ja jetzt mittlerweile häufig mache,
ist, ich,
die laden ja meistens auf YouTube
und es gibt in meinem Podcast-Player irgendwie
so ein, der hat so ein Zeit-Loading
Share-Sheet-Extension-Dings
für iOS und dann sage ich auf dem
YouTube, auf der YouTube-Seite so
irgendwie, share das mal mit meinem
Podcast-Player und dann kriege ich das Audio halt dann als
normale Podcast-Folge sozusagen rein.
Und das ist ganz, ganz angenehm, wobei man dann halt auch merkt, dass die Audioqualität bei so Vorträgen oft auch nicht so toll ist.
Und naja, wenn man das Bild halt nicht sieht und die Folien, ist auch schon ein bisschen Information weg.
Also ganz toll ist es nicht.
Aber seitdem höre ich mehr Talks, weil ansonsten die Zeit irgendwie vorm Rechner zu sitzen und ein Video zu gucken, das ist einfach nicht.
Ich kriege das immer nur dann hin, wenn ich noch nebenbei was anderes mache.
Ansonsten funktioniert das irgendwie nicht.
Aber zum
Thema, das war ganz
interessant und zwar hatte der etwas angesprochen,
was man halt auch so als,
der kommt irgendwie aus Australien,
nach dem Taleb hat man ein Buch geschrieben,
The Black Swan, und
genau, das mit den schwarzen
Schwänen ist auch so ein Ding, was in Australien halt da mal
aufgefallen ist, man dachte halt bis irgendwie
vor ein paar hundert Jahren, also bis halt Australien
irgendwie so richtig entdeckt war, dass es nur
weiße Schwäne gäbe, weil man hatte noch nie einen schwarzen
gesehen, aber in Australien
gibt es tatsächlich wohl schwarze
schwarze Schwäne und
ja, dann, als die
zum ersten Mal jemand gesehen hat, dann
war sozusagen diese Theorie, dass das
dass alle Schwäne weiß sind
halt auf einen Schlag erledigt und
das sind solche Sachen, die passieren halt
ab und zu und die kann man sehr schlecht
vorhersagen und das, ja,
solche Ereignisse gibt es ja halt nicht nur in der Natur,
wenn man Natur beobachtet, sondern halt auch
in diversen anderen Bereichen, es gibt halt irgendwelche
Finanzkrisen oder so, die auftreten können,
wo man halt vorher gedacht hat, das geht jetzt immer
so weiter und
naja,
der sprach halt über
diese Ereignisse, die halt passieren können
und was das für Ereignisse
sein könnten, die
Python, ja, sozusagen
vielleicht obsolet machen oder schwer
sozusagen, ja,
beeinflussen könnten und die man momentan
nicht so richtig kommen sieht, weil
auch im IT-Sektor ist das natürlich
schon ganz oft passiert, irgendwie so der
PC, der irgendwie aufgetaucht ist, war wahrscheinlich
für viele Unternehmen, die vorher ganz gut mit
Ningen gelebt haben,
so ein schwarzer Spahn, der
aufgetreten ist und dann plötzlich die ganze Märkte kaputt gemacht hat
oder irgendwie, ja,
Smartphones sind halt auch sowas,
die den ganzen
PDA-Markt irgendwie aufgerollt
haben und Nokia irgendwie
sozusagen in die, naja,
in den, ja, wie soll man,
Microsoft-Vorruhestand geschickt haben und
dass der sagte, also man
kann inzwischen sehen, was das sein könnte
und für ihn ist halt interessant rauszukriegen,
was man dagegen tun kann und
er meint, dass wäre halt zum Beispiel
eine ganz schlechte Geschichte
ist, dass halt eben auf solchen Geräten wie Tablets,
irgendwie Telefonen oder so, halt
Python nicht wirklich läuft
und dass wenn jetzt aber der
Markt so umkippt, dass halt irgendwie
Desktop-Computer und auch Laptops nur noch was für
Profis sind und
ja, die ganze
Konsumenten, der ganze Konsumentenmarkt halt
auf irgendwelchen
Tablet- oder Smartphone-mäßigen Endgeräten
ist, dann kann es sein, dass das
ein sehr großes Problem wird, dass da
Python halt überhaupt, dass man mit Python überhaupt
nichts machen kann.
Und dass es halt auch ein Riesenproblem ist, dass das halt auch nicht
sich überbrücken lässt durch irgendwie solche Sachen wie
Web oder so, weil JavaScript wird das
wahrscheinlich überleben. JavaScript läuft
halt in Browser, Browser sind auch von den Geräten
nicht wegzudenken, aber
Python läuft weder im Browser noch.
Ja, wobei, was
mir da mehr durch den Kopf geht, ist, dass
ich glaube, wir werden dann eher sehen,
dass es noch
tatsächlich diese agnostischen Runtimes
geben wird. Also bei Web
fällt mir gerade eben WebAssembly ein.
Das
finde ich blöd aus einer anderen
Perspektive, weil dann ist halt ViewSource
endgültig kaputt.
Das ist was, womit
ich halt
auch wieder aufgewachsen bin. Allein das
hat es mir ermöglicht, irgendwie vernünftig
das Zeug überhaupt zu lernen, dass man in Sachen
reingucken kann. Aber
sei es mal gespenkt.
Man kann in jede Webseite reingucken
und sich angucken, wie das geschrieben ist.
Ja, genau.
Das war halt, wobei das auch heute eigentlich,
es ist praktisch
tot durch
Minifizierung etc. Ich meine,
mit dem Inspector kriegst du dann halt, wenn Mappings da sind,
beziehungsweise auch noch die Minifier
und so ein Zeug, aber es ist praktisch
eh tot, weil die Komplexität zu groß ist. Früher war es
so, da hast du halt mal deine 10K, 20K
HTML-Code, bloß ein bisschen JavaScript
angeguckt und, ah, guck mal, der benutzt das so und so.
Die Doku war früher auch
schlechter, heute ist die Doku besser, dadurch
dämpft das halt vieles wieder.
Ich glaube aber, dass solche agnostischen Runtimes, also
zum einen, naja, Profi
ist halt jetzt wieder, machen wieder die Schleife.
Wenn nur
die Profis Software entwickeln sollen
und Python kommt eigentlich eben aus der Ecke,
dass nicht nur die Profis das können sollen,
weil ansonsten haben wir
ja als Gegenentwurf eben
in der Android-Ecke haben wir Java und Java
kommt halt aus diesem extrem ingenieursartigen
Ansatz für, da ziehst du dir
bitte einen Laborkittel an, bevor du anfängst zu programmieren
oder sonst hältst du das nicht aus.
Du hast doch keinen Kittel angefangen, bevor du angefangen hast.
Ja.
Also das ist ja so
Business-Programmieren, ja. Da stellt man sich
die Leute vor, die im Laborkittel programmieren und jetzt
halt mal ordentlich hier, das ist der deutsche Ingenieur,
jetzt kriegst du gleich Qualitätssoftware, wenn du nicht aufpasst.
Die, ähm, und Python
kommt ja von einem anderen Ende und Python kommt eigentlich von
einem sehr charmanten Ende, nämlich, dass es halt so zugänglich
ist für Leute, die halt Quereinsteiger sind, die
noch selber Schüler sind und
auch da wieder in einer komplexen Welt ist,
lernen durch Experimentieren, durch
Experimentieren halt eigentlich genau das
Richtige, Grenzen austesten. Und dafür
musst du dir aber sozusagen eine Umgebung,
einen Weg bereiten und sagen, hier ist
irgendwie erstmal so grüne Wiese,
lauf mal los, guck mal. Systeme
wie Java sind halt wenig ein, hier ist grüne
Wiese, sondern es sein, so hier kommt jetzt erstmal
das große Konstruktionstemplate und
ohne das kannst du nichts tun.
Mir fällt gerade auf, dass der Christian gerade zum ersten Mal
den Java Bash gemacht hat, auf den ich die ganze Zeit gewartet
habe, den wir in Zeitfolge 1 vorgenommen haben.
Ah, bitteschön. Danke.
Es ist die zehnte Episode.
Und ich meine, Java
leidet an der Stelle, also die leiden ja
selber unter ihrem Erfolg an der Stelle,
weil es war ja
gemacht von
Sun mit ein bisschen IBM-Unterstützung
damals, mit
der Idee, dass Entwickler
zu teuer waren.
Ja, also es gibt die eine Story, das ist eine, also es gibt ja mehr Perspektiven da drauf. Das eine ist, es sollte mal dieses Set-Top-Boxen-System sein, Mitte der 90er. Dann wurde es irgendwann zu so einem Server-System, dann wurde es irgendwann zu der Universalen.
Ja genau, das was heute ein Apple TV ist, wo man halt sich in den 90er Jahren das erste Mal die Finger dran verbrannt hat. Das sind ja häufig so Embedded-Geräte, wo jeder den kompletten Software-Stack mit Betriebssystem selber gebaut hatte und Sun hatte damals mit Java versucht eine Sprache zu bauen, wo ich die gleiche Programmiersprache halt über unterschiedliche Geräteklassen hinweg eben von Mobiltelefonen zu Servern zu Desktop-Rechnern zu Set-Top-Boxen anwenden kann, um die zu programmieren.
Und ja gut, also jeder, die mal gesehen hat, irgendwie auch dieses Ding von der Telekom hier, diese komische Fernsehgeschichte, die die haben, da kriege ich immer das Gruseln, wenn ich sehe, wie das UI aussieht dazu, weil es halt, ja, weil dort das ganze Ökosystem ist durchdrungen von diesem Ingenieursansatz, ja, von diesem, du musst alles ausdefinieren und aber die wirklich interessanten Sachen, sowas wie, dass das UI geschmeidig ist, das kommt als letztes.
Und dann stellst du fest, oh, unser UI-Toolkit kann gar keine schönen Übergänge, sondern das geht bloß so hackelig.
Warte mal, wir kamen von, was hat Python für eine Zukunftsperspektive?
Python ist ja als Sprache eh darauf angelegt,
eine Sprachspezifikation zu sein und
sich unterschiedlichen Runtimes
gut halt anzudienen und ich würde
vermuten, dass irgendwann
der Zeitpunkt, also wir haben halt eben zum
einen, Web könnte für Python
halt mit WebAssembly durchaus interessanter werden
und auf der anderen Seite
werden wir
eine Lösung brauchen, wie
solche Endgeräte,
die sich ja zum Programmieren auch gar nicht
eignen,
Und das ist sozusagen auch eine ganz eigene Schleife zum Thema Digitalisierung und Selbstständigkeit von Anwendern. Da ist ja auch die freie Softwarebewegung als Ganzes im Prinzip dran, dass du sagst, hey, ich will eigentlich, dass die User emanzipiert sind und dass ich nicht um Erlaubnis fragen muss, um Software zu modifizieren oder Software zu verstehen, sondern dass ich halt eben genau Emanzipation mit Kompetenz auch gleichsetze an der Stelle.
Ja, interessanter Gedanke.
Ja, das wäre auf jeden Fall sehr schön.
Momentan geht es leider so ein bisschen in eine andere Richtung.
Ja, aber ich glaube,
dass Python da definitiv halt massive
Chancen hat, aufgrund der Größe,
aufgrund der Erfahrung auch und aufgrund
dem Fokus halt als eine freie Sprache,
die sich so flexibel
halt in unterschiedlichen Kontexten halt
einsetzen lässt.
So, aber jetzt endgültig,
und jetzt fangen wir an zu erklären,
wie man das mit Python alles so
insgesamt machen möchte, wenn man sowas
DevOps'en
möchte.
Was macht man denn da? Was ist das überhaupt?
Vielleicht fangen wir damit nochmal ganz kurz an, aber diesmal
jetzt so vielleicht ein bisschen kompakt.
Wer möchte zuerst?
Ja, ich kann ja einfach mal
genau,
ich habe eben schon mal so kurz überlegt,
wie man das irgendwie
anfangen
könnte und ich dachte, naja, also
vielleicht einfach
in der Differenz
zu anderen Geschichten, die es halt schon lange gab, die Leute
vielleicht auch kennen, ich weiß nicht so genau.
Aber so früher war das ja
so, dass wenn man jetzt, also
ich nehme jetzt mal den Bereich,
man möchte jetzt eine Webseite irgendwie haben,
die irgendwo online
zu sehen ist, die man nicht nur lokal irgendwie
anguckt, da kann man auch einfach ein HTML-File
von einem Editor hinschreiben und dann
guckt man sich das mal um. Webseite mit Service, also jetzt nicht nur
meine Visitenkarte. Das kann auch
einfach nur ein HTML-Datei sein, aber die
kann ja jemand anders noch nicht sehen, nur wenn
ich sie auf meinem Rechner mit dem Editor
abgesorgt habe, dann sollten
andere Leute die ja hoffentlich erstmal so nicht sehen können.
Die Frage ist halt, wie kriege ich das hin, dass das Ding
zum Beispiel weltweit dann halt
sichtbar ist. Und
wenn man jetzt
die ersten Geschichten, die es da gab,
auch Ende der 90er
irgendwie PHP und
irgendwie FTP-Server oder so, da haben
Leute irgendwie
quasi so eine Web-Route in einem
Apache gehabt und dann haben sie da irgendwie
PHP-Sachen per FTP hochgeladen und dann war das
irgendwie dann deployed,
sozusagen. Vielleicht kennt man das.
Ich war sehr überrascht, als ich letztens gesehen habe, dass Leute
das heutzutage immer noch so machen.
Ja, sie machen es.
Es ist immer wieder...
Also, ja.
Sie sterben nicht aus.
Ja, auf der anderen Seite muss man halt sagen,
dass es halt so, auch wenn es
aus diversen
unterschiedlichen Gründen halt eine sehr problematische
Geschichte ist, das so zu machen, es ist
halt irgendwie so ein definierter Weg. Die Leute haben sich
irgendwie reingewöhnt. Es gibt viele, die kennen überhaupt nichts anderes.
Und es ist halt so ein Standardweg,
wie deployed man jetzt irgendwie
Software mit PHP
irgendwie, wenn man das jetzt... Funktioniert.
Ja, naja, für
bestimmte Werte von
Funktionieren.
Und diese
Geschichte so, wie macht man das jetzt eigentlich,
wenn man das tun will, gab es für Python
sozusagen nie. Und das ist
jetzt halt für Python dann irgendwie, gibt es
halt sehr viele unterschiedliche Arten,
das zu tun. Und
ja, den Leuten ist nicht so richtig bewusst, wie das
dann überhaupt gehen soll und was irgendwie
dann so ein bisschen dazu führt, dass sie oft gar keine
Vorstellungen davon haben, wie man das dann
macht und
das dann halt auch nicht so richtig tun.
Das Schmeinende daran ist, man kann
jetzt sozusagen mal den Bogen, du hast jetzt wirklich
das abschreckende
90er-Jahre-Beispiel ins eine Ende gestellt.
Ich meine, der Extremwert von dem, was du
beschrieben hast, ist ja noch, ich kenne auch die Leute,
die haben das FTP gemountet und editieren
halt dann mit ihrem Editor direkt
auf dem, ja genau.
auch die existieren noch und
ich durfte auch schon, ich glaube, wir durften
letztes Jahr auch schon mal aufstehen und
irgendwie kaputtgegangene Seiten reparieren, weil
irgendwie sein Editor nicht ordentlich zugemacht hat.
Das andere Ende davon ist ja jetzt sozusagen,
wenn man sich heutzutage fragt,
wenn man das Thema abhaken will,
dann sage ich jetzt Docker und dann ist irgendwie
alles vorbei.
Also das würdest du sagen, also eben das Best Practice,
dass wir jetzt die Antwort hätten.
Nee, überhaupt nicht. Nein, gar nicht.
Weil das halt,
weil Docker jetzt erstmal ja nur
ein, auf der einen Seite
hast du eine Lösung, die ist sozusagen so
grottig auf so vielen Enden, dass
die Leute, die sie einsetzen, noch nicht mal verstehen,
warum es schlecht ist.
Und am anderen Ende hast
du ein Ding, das als Totschlag
Variante macht, dass man auch
nicht mehr versteht, warum es jetzt gut ist.
Also Docker hat halt
löst wahnsinnig viele Probleme, die es da
so gibt und hat, bringt halt
eigene große Komplexität mit
und
was ich halt spannend finde, wenn wir das Wort
DevOps eigentlich nehmen, dann kommen wir
halt in so einen
auch mit agil, ich muss jetzt meine Buzzword-Matrix
irgendwo aufmachen,
dann kommst du halt aber in
dieses Thema von, wie arbeitet man eigentlich
in Teams gut zusammen, weil
wenn ich meine Software alleine baue und ich habe
meine drei, vier Privatprojekte,
dann kann ich halt irgendeine technische
Lösung nehmen, die mir für mich
alleine löst, dass ich mir
nicht auf die Füße trete. Die kann so klein oder so
groß sein, wie ich es halt gerade vertrage.
Wenn ich aber das Thema habe,
dass ich eben nicht mehr alleine bin, sondern
dass ich halt mehrere Leute habe, die
entwickle oder halt unterschiedliche Zuständigkeiten,
dass ich mir vielleicht auch mal für
bestimmte Themen, gerade
ich mache die kurze Schleife zur Digitalisierung,
wenn ich halt eben auch Software für mich
entwickeln lasse, das heißt, ich habe halt irgendwem,
dem gehört die Software vielleicht nachher, aber
irgendwer anders, irgendeine Agentur oder irgendein Freelancer
oder ein Team entwickelt das für mich und dann
habe ich noch irgendwen, der soll das
irgendwo betreiben und
Das wird halt alles relativ schnell komplex und dann ist halt die eigentlich interessante Frage von, was sind denn für solche Szenarien interessante Arten, wie man da zusammenarbeiten kann.
Weil, wenn man jetzt mal das FTB-Beispiel weglegt und sagt, wie war es sonst im großen Umfeld vielleicht, im professionellen und nicht so in diesem semi-professionellen Umfeld, dann gab es da früher immer diese Metapher des Software-über-den-Zaun-Werfens.
Das sah dann ungefähr so aus, du programmierst dein Kram runter, packst das alles in eine kleine Kiste, also zum Beispiel ein Tarball oder CVS und danach schreibst du ein Readme und das Ding zusammen, also der Lieferschein und diese kleine Kiste, wirfst du über den Zaun, am anderen Ende steht schon irgendein Admin, der sammelt das dann ein, packt das wieder auseinander, geht dieses Readme durch, stellt fest, dass das vorne und hinten nicht funktioniert.
Und der Prozess war aber definiert, siehe Wasserfall-Methodik und so, von, wenn ihr fertig mit dem Entwickeln seid, dann gibt es halt den Admins. Und in einer komplexen Welt hast du halt eben nicht mehr solche ganz klaren, harten Interfaces zwischen Leuten.
Hat der gerade Agile gesagt oder was?
Oder warst du ja gerade beim Buzzword-Bingo?
Ja, ja.
Agile ist schon eine Weile her.
In einer komplexen Welt hast du halt das Problem,
dass du die Schnittstellen zwischen unterschiedlichen Leuten,
unterschiedlichen Teams, unterschiedlichen Prozessen
halt nicht mehr so glatt definieren kannst à la
ihr arbeitet bis hierhin und das Werkstück, was da rausfällt,
gebt ihr dann dem Nächsten.
Also das kannst du machen, wenn du Auto baust.
Und Autobauen ist halt tatsächlich ein Ding,
das können wir heutzutage ingenieursmäßig machen
eben, dann weißt du, es gibt die
Station, der dreht die Schrauben rein, dann wandert das
Auto selbstständig zur nächsten Station,
der dreht die anderen Schrauben rein, der nächste macht den
Spiegel dran und so, alle,
da muss keiner mehr miteinander reden.
Ja, wobei, wenn ich
dann noch mal so kurz abschweifen darf, ich
Bitte, bitte.
Also das, was wir sozusagen
dann als Agile
Methoden ja dann in der Softwareentwicklung
irgendwie gesehen haben, das kommt ja ursprünglich
daher. Ich fand das
letztens beim Abendessen
haben wir dann mit
bekannten
Freunden gesprochen und einer von denen kam
halt aus der
Automobilindustrie und beschwerte sich bitterlich,
was denn dieser komische neue Trend
sei, der da irgendwie jetzt über sie
hereinbräche. Irgendwie dieses
ganze komische Agile-Zeugs
und dass es da irgendwie, dass
jetzt plötzlich irgendwie eine tausendmal
Entwicklungsabteilung irgendwie Agile-Dinge
machen sollte und dann machen halt alle,
wird die in Teams aufgeteilt und die machen dann halt alle
irgendwie Dinge in unterschiedliche Richtungen
und es passt nichts mehr zusammen, alles ganz furchtbar.
Und das fand ich irgendwie
witzig, weil eigentlich kommt das ja
aus der Automobilindustrie.
Ja, Toyota.
Ja, nee, nee, Moment.
Nein, da muss ich reingrätschen.
Nein.
Du hast zwei Sachen. Du hast Agile auf der einen Seite
und du hast Kanban auf der anderen.
Und Kanban, das sind
ähnliche Konzepte. Kanban ist das, was
Toyota stark gemacht hat.
Das ist tatsächlich, es kam aus
so einem produktionsorientierten Thema
und Produktion hieß
an der Stelle tatsächlich eine Flussoptimierung,
dass du machst,
dass das, also
wenn du so eine Werkshalle hast mit
Autos und dieser
Straße, dieser Fertigungsstrecke,
dann wandern die Autos
halt schön durch und ein Thema ist immer,
dass wenn da irgendwas blockiert,
dann bleibt halt dieses ganze Band stehen.
Dann hast du ein sogenanntes
Stop-the-Line, Head-of-Line-Blocking auch,
es geht hier hinten nicht weiter, bevor es da vorne nicht
weitergeht. Und
Toyota hat ja tatsächlich
sich Methodiken zurechtgelegt,
um
die Planung
von diesen Abläufen
möglichst gut zu machen.
Da gehört Can-Band unter anderem mit dazu.
Can-Band ist eine Abstraktion von so einem
Fertigungsstraßending,
wo du halt sowas hast wie, du hast bestimmte Schritte,
die werden nacheinander durchlaufen und in jedem
Schritt dürfen nur maximal so und so viel gleichzeitig
sein, weil ansonsten verlieren die Leute sich
halt im Threshing, weil sie ständig Kontextwechsel machen müssen
und so. Das ist halt mehr das
Thema, wie kann ich Durchfluss optimieren und das
geht aber nur, wenn ich möglichst
einheitliche, möglichst gleichförmige Arbeitsschritte
habe.
Wenn ich zu viel unterschiedliche
Arbeitsschritte habe und deswegen ist Softwareentwicklung
Agile im Prinzip anders, weil du hast
völlig unterschiedliche Sachen, die du zwischendurch machst.
Auf der einen Seite von UIs
zu Features, zu Bugs, zu einem
großen Architekturthema, zu einem kleinen
Usability-Thema. Das geht so alles quer durcheinander
und bei Canban willst du aber eigentlich, dass
jedes Teilchen möglichst
eine einheitliche Größe hat,
damit du darauf, auch über diese,
ansonsten würde nämlich die Regulierung
der Work-in-Progress-Anzahl von Kärtchen
gar nicht helfen,
wenn du gar nicht weißt, wie groß das Kärtchen ist.
Klar, okay, ja.
Deswegen sind das so zwei, die sind nicht unabhängig,
also die kann man unabhängig
und zusammen komplementär einsetzen, aber die haben
unterschiedliche Eigenschaften. Agile
war ja eher dafür gedacht,
um
die User und die Entwickler
näher aneinander zu bringen,
also das ist eher ein Thema von Disintermediation,
dass du nicht möchtest,
dass die so weit auseinander sind,
dass sie keine gemeinsame Sprache sprechen.
Und das Interessante bei Agile ist,
weil ich habe das in letzter Zeit auch mal wieder da gehabt,
dass du, wenn man das Manifest nochmal rausholt
und diese ur-ur-ur-alte Seite
und die haben ihr HTTPS nicht im Griff,
dann ist es halt sehr knapp.
Es ist halt People over, jetzt muss ich es selber halt raussuchen,
das war People over Processes, Working Software over Comprehensive Documentation,
Collaboration over Contract and Negotiation, Responding to Change over Following a Plan.
Und das Dumme ist, das sind Techniken, die waren entwickelt worden,
ich glaube, das war ein Chrysler-Projekt und das ist eigentlich gar nicht so gut,
aber die Techniken an sich haben sich halt durchaus als hilfreich bewiesen,
dass diese vier Grundsätze ja die Entwickler und die User enger aneinander bringen sollten,
um die Realität schneller sichtbar zu machen.
Ansonsten kannst du halt über Dokumentationen, Prozesse und Vertragsverhandlungen und Plangestaltung
kannst du die Realität dermaßen verzerren, weil du hast halt so viele Ebenen von mittlerem Management
und halt eben Mediation dazwischen, dass du hast halt stille Post vom Anwender bis zum Entwickler.
Und damals wurde ja auch immer gesagt, die Anwender sollen nicht
mit den Entwicklern reden. Und ein
großes Problem, was die Agile-Community
hat, meiner Meinung nach, ist, es war eine
Team-Methode, die war nie dafür
gedacht, auf ganze Unternehmen angewendet
zu werden. Also die war
gedacht für so 10 bis 15 Leute.
Ja, genau.
So man sagt auch oft,
bei neun Leuten ist bei einem Team dann irgendwie Schluss.
Und irgendwie so eine überzeugende Antwort darauf,
was man denn jetzt macht, wenn man Projekte hat,
die sich mit neun Leuten halt nicht
stemmen lassen,
habe ich auch nie so wirklich gehört.
Ja, aber ich meine...
Mach es kleiner.
Genau, du musst es halt...
Mach es kleiner.
Du teilst dann die einzelnen Teams auch, ne?
Du machst dann ein Team,
was für das spezielle Projekt ist.
Du machst dann ein eigenes Team,
einen eigenen Raum.
Die haben ihre eigene Peergroup,
ihre eigenen Stakeholder.
Du musst dann gucken,
wie sich damit klarkommt irgendwie, ne?
Aber das Interessante an der Stelle ist,
jetzt hat man halt versucht,
dann irgendwie da drumherum
ein Gesamtframework,
das heißt dann entweder Scaling Agile
oder Scrum oder was auch immer,
ein Gesamtframework zu bauen,
was Unternehmen halt kaufen können.
Und es ist aber ein massiver Unterschied, ob ich ein Team habe, was aufgrund so einer Methodik, Methodology mit kleinem M, arbeitet und verstanden hat,
dass diese Aussage zum Beispiel ist, wenn man das Manifest noch eins runterkochen will und sagt, diese vier Sätze sind mir zu viel,
dann ist die eigentliche Ansage, liebes Team, du hast nicht nur eine Verantwortung, Software abzuliefern,
sondern du hast auch eine Verantwortung dafür,
den Prozess zu guter Software zu kommen,
selbst zu gestalten.
Und wenn ich dann aber im Gegensatz dazu
heutzutage immer mal in irgendwelchen Runden bin,
wo irgendwelche Entwickler sich selbst als,
ja, ich bin ja nur ein Entwickler,
bezeichnen, denke ich mir so,
ey, mein Kindheitsherz bricht gerade,
weil die Softwareentwicklung selber war das,
was, als ich groß geworden bin, war mit,
hey, da ist doch die ganze Power,
das ist doch was, was attraktiv ist,
da ist die Gestaltung
und nicht in irgendwelche Leute
lassen dich nur noch Tickets abarbeiten.
Ja, ich
finde das auch immer total seltsam, wenn Leute da so
sich so zurückziehen
auf so eine
ganz, ganz enge Funktion.
Ich kann
das auch nicht so richtig, aber es gibt das natürlich durchaus
und es gibt auch Leute, die sich total unsicher fühlen,
wenn sie dann halt da irgendwie
mit Fragen konfrontiert werden,
die sie jetzt nicht kompetent
fühlen.
Und dann probieren wir mal die Schleife zum DevOps zu machen. Jetzt hast du also mit agilen Methoden eigentlich eine Ansage von, hey Jungs, ihr müsst euch halt Gedanken machen, wie man vernünftig zusammenarbeitet.
Ich komme immer mal wieder jetzt mit diesem komplexe Welt Thema und ich mache einen kurzen Aufschlag zu, was heißt komplexe Welt. Komplexe Welt heißt, wir haben Beziehungen zwischen Dingen, die wir nicht vorhersagen können.
Du kannst die Welt einteilen, kannst Systeme einteilen.
Das ist halt wieder das Kinevin von Dave Snowden.
Ja, der macht irgendwie Unterschiede zwischen kompliziert, komplex und chaotisch.
Genau, genau.
Das ist deine Theorie, an der er seit 30 Jahren arbeitet.
Und die nimmt jetzt gerade auch ganz gute Formen an, dass er sie finalisiert.
Der unterscheidet Systeme in Unterschied.
Du kannst es als Typologie benutzen, du kannst es als Klassifikationssystem benutzen,
Du kannst es aber auch als exploratives Werkzeug benutzen.
Und er sagt halt, es gibt zum einen geordnete und ungeordnete Systeme.
Und geordnete Systeme sind die, wo Ursache-Wirkungs-Prinzipien halt vorhersagbar sind für uns Menschen.
Die kannst du nochmal unterteilen in offensichtliche Systeme.
Das heißt, du brauchst kein Fachwissen, um eine Vorhersage zu treffen.
Beispiel, ich lasse mein Glas runterfallen und dann ist da eine Pfütze auf dem Boden.
Da weiß ich halt auch ohne Fachwissen, ich hebe das jetzt auf, wische das weg.
wenn es gesplittert hat, hole ich noch einen Staubsauger.
Da brauche ich nicht groß irgendwie
Analyse betreiben.
In solchen Umgebungen
kannst du halt auch zum Beispiel... Es gibt Unternehmen, die machen
genau sowas. Die kaufen sich da ein neues Glas und
auf dem Boden stammeln sich immer mehr Scherben an.
Ja, genau. Kann man machen.
Denn dann
kompliziert ist, wenn du
für Vorhersagen
in einem System
Analyse betreiben musst. Wenn du sozusagen
einen Fachmenschen brauchst,
Der sich ein Problem nimmt und sagt, okay, was sind denn hier jetzt die Parameter, da gehören zum Beispiel sowas wie, jetzt beim Hausbau ein Statiker, ein deutscher Ingenieur, die sind genau für sowas gut.
Den gibt es ein Problem, was man nicht auf den ersten Blick erkennt, aber wo du weißt, der setzt sich jetzt hin, das dauert dann 10 Stunden, dann rechnet er das durch und dann kommt dein Ergebnis raus.
Der kann dir das Ergebnis nicht vorab sagen, aber er weiß, wenn er das jetzt macht, dann kommt er halt am Ende raus.
Und er weiß, wie wird die Tragfähigkeit von dem System sein, bevor ich es baue.
Kompliziert wiederum ist der Fall, wenn ich Ursache-Wirkungs-Prinzipien eben nicht vorhersagen kann, aber zumindest die Chance hätte, es im Nachhinein zu erklären. Wenn ich nicht mal die Ursache-Wirkungs-Prinzipien im Nachhinein erklären kann, dann sind wir in den sogenannten chaotischen Systemen. Dann habe ich gar keine für Menschen entdeckbaren Zusammenhänge mehr.
Und es gibt unterschiedliche Handlungsstrategien für diese unterschiedlichen Systeme. Und im komplexen, jetzt muss ich versuchen die Schleife wieder hinzukriegen, wo ich gerade abgeschwiffen bin, in der komplexen Welt ist es eben so, dass ich diese Ursache-Wirkungs-Prinzipien eben nicht vorhersehen kann.
Und deswegen ist das der Grund, warum starre Methodiken, starre Formen der Zusammenarbeit, starre Formen der Planentwicklung dort niemals funktionieren werden. Und die Leute wundern sich immer, die wenden Techniken an aus einer analytischen Perspektive und sagen, das musst du ja einmal runter definieren, hab aber ein komplexes System und wundern sich dann, warum es nicht funktioniert.
Und die typische Antwort ist dann ja, wir müssen das nächste Mal einen besseren Plan machen, wir müssen das nächste Mal noch genauer hingucken. Und dabei ist die Aussage, nein, die Welt ändert sich um dich drumherum, während du mit ihr interagierst und sie zeigt sich dir nicht in ihrer Fülle.
Und das ist so ein massiver Unterschied, weswegen dann nämlich agile Methoden oder DevOps immer mitbringen, du musst die für deinen Kontext, also Kontext ist ein angemessene Kombination herstellen und dafür brauchst du aber eine Auswahl an unterschiedlichen Methodiken, eine Auswahl an unterschiedlichen Fertigkeiten, unterschiedlichen Werkzeugen.
Und deswegen ist sozusagen beide Extreme, wenn wir drüber reden, FTP-Deployments oder Docker oder Kubernetes eats the world, beide Extreme sind nicht gesund. Beides sind halt Werkzeuge, die kontextabhängig sind. Docker und Kubernetes ist, also gerade Kubernetes ist halt ein riesengroßes Tier. Das ist halt vielleicht nicht angemessen, wenn ich Embedded-Systeme mache, weil ich halt nicht 20 Gigabyte in meinen armen kleinen Raspberry Pi reinkriege.
Und dafür aber dann halt zu wissen, was sind denn auch die Grundlagentechniken, damit alle, die beteiligt sind, halt Entwickler, User, Businessleute, Opsleute, dass die halt sich in einem Projekt auch zusammenfinden und sagen, so, was ist denn hier jetzt die richtige Kombination für jetzt?
Weil auch die Zeit ist ja wieder ein Faktor
da dran. Man fängt ja mit Projekten an und will
erstmal was basteln und
das ist eben wieder dieses Thema im Komplexen.
Du willst so schnell wie möglich experimentieren,
Ende, Ende, sehen, was tut meine Software
eigentlich? Kann mein User damit
irgendwas anfangen? Und da sind wir wieder beim Agilen.
Warum machen wir eigentlich kleine Zyklen?
Naja, weil ich so schnell wie möglich vom User
rausfinden möchte, ob ich überhaupt in die richtige
Richtung entwickle. Ja, Learn, Process, Learn, Process.
Genau. Ja, genau. So ein bisschen
Trial and Error halt.
Ja, ja, auch Sachen wegwerfen.
Und ein ganz interessantes Thema halt aus der Komplexität dabei ist wieder, wenn du nicht an die Grenzen kommst, wenn du keine Fehler machst, und das erklärt sich für mich, was bedeutet Fehlerkultur eigentlich, das ist nämlich völlig fehlverstanden, das heißt nicht, ah, man macht was falsch und dann geht was kaputt und deswegen sind wir jetzt alle nicht sauer auf dich, sondern wir müssen eigentlich vorher einen Plan machen, in einer Umgebung, die wir noch nicht vollständig erfasst haben, die Grenzen zu finden.
Und wie finde ich eine Grenze? Indem man was kaputt gehen lässt. Indem ich was kaputt gehen lasse, weil dann weiß ich nämlich, ah, bis hierher und nicht weiter. Wenn ich die nur nie austeste, dann haben Menschen auch einen, die Menschen, ich bin kein Roboter, dann haben Menschen das Problem, dass sie gerne linear denken und dass sie denken, ah, guck mal, das ging jetzt mit 5, das ging jetzt mit 10, ja, dann geht es halt auch mit 20, 40 und 100.
dass dann aber vielleicht bei
elf
eine abrupte Grenze kommt, wo es halt gar nicht mehr geht,
das können wir eben nicht vorhersagen. Das ist wieder der Black Swan
auch, den du halt hattest.
Und auch
Taleb im
Black Swan argumentiert ja für
den Longtail. Die Menschen
unterschätzen den Effekt der Risiken
eines Longtails. Die Fläche
in dem Rattenschwanz,
der nur sehr selten kommt,
ist in Summe aber sehr groß.
Und deswegen sind die Wahrscheinlichkeiten, dass
eins dieser unwahrscheinlichen Ereignisse
eintreten wird, auch extrem hoch.
Kann ja trotzdem einfach mal irgendwas twittern.
Ja, ja, ich finde dann auch die
Arten, damit umzugehen, interessant.
Also gerade bei Infrastruktur gibt es
da zum Beispiel bei Netflix gibt es da
den
Chaos Monkey. Genau.
Der halt dann einfach mal irgendwie
einen Dienst, der halt
irgendwie den Stecker bei Maschinen zieht
oder die einfach vom Netz trennt und dann
guckt man halt, ob die Infrastruktur
weiterhin lebt. Und wenn sie das nicht tut, dann hat man da irgendwas nicht
ordentlich gebaut, sozusagen.
Ja, und das Interessante bei, das unterstützt
ja diesen psychologischen Effekt. Das unterstützt
ja dieses, ja, wann kommt denn das schon mal
vor, dass so eine VM ausgeht? Und wann kommt denn das schon mal
vor, dass da eine Netzwerkverbindung hakelig ist?
Und wenn du das umdrehst und sagst,
das ist nächsten Dienstag,
dann
haben die Leute halt ein anderes Händel da dran.
Dann hast du nicht mehr dieses psychologische, ah, da kann ich
mich drum rum wickeln. Das ist DevOps.
Also dann solche Situationen herzustellen und
die ganze Zeit die Leute zu nerven mit
Szenarien, die in der Realität irgendwie
im Wahnsinn auftreten könnten und die man dann realisiert?
Nee, es ist eher, dass man
diese Dinge nicht so klar
voneinander trennen kann. Also auf der einen
Seite Softwareentwicklung, auf der anderen Seite
Betrieb
des Systems. Also früher,
klassisch war das halt so, Entwicklungsabteilung hat halt
die Software nach Spezifikationen
entwickelt, wie auch immer die aussah.
Und dann
eine IT-Abteilung war dann halt dafür zuständig,
also für Sicherheit, Skalierbarkeit
und dafür, dass das letztendlich irgendwo
dann läuft, zuständig.
Ja, die sogenannten nicht-funktionalen Anforderungen.
Ja, genau. Und
das ist aber schwer voneinander zu trennen.
Das ist halt...
Vor allem, wenn der Manager dann irgendwie kein
ITler ist wahrscheinlich.
Bei nicht-funktionalen Anforderungen denke ich mir halt
auch immer, zum Beispiel Performance,
da hieß es dann halt, wie groß
muss die CPU sein, wo das läuft.
Der Trick ist, wenn ich halt Blödsinn baue am anderen Ende
und eine Endlosschleife baue, dann kann die CPU
halt so schnell sein, wie sie will.
Das wird nicht funktionieren, genau.
Ja, genau, aber wenn man jetzt Systeme bauen will, die damit umgehen können, dass jetzt so irgendwie so ein Chaos Monkey ab und zu mal da irgendwie nicht deterministische Dinge ausfallen lässt, dann muss man sich halt auch nicht nur, dann reicht es nicht, sich sozusagen auf der IT-Ebene sozusagen damit zu beschäftigen, sondern dann muss man vielleicht auch die Software schon so bauen, dass sie damit irgendwie klarkommt.
Es ist vor allem extrem teuer, wenn du Sachen, also wie es halt immer auch ist mit dem Thema, wie teuer sind Bugs, je später du sie findest, desto teurer werden sie halt. Und so ähnlich ist es halt auch, wenn ich bestimmte Probleme wie Verfügbarkeit, Performance, Ressourcennutzung, wenn ich die versuche dann erst spät im Prozess, also irgendwo im Betrieb zu lösen, dann bin ich eigentlich nur noch dabei, Duct Tape rauszuholen.
Also das halt alles wieder zusammenzubinden, was vorne schon mal verrissen wurde. Das sehe ich relativ häufig. Also wir sehen halt immer wieder Anwendungen, die verbraten Unmengen an CPUs und RAM. Und wenn man dann halt feststellt, das hat irgendein Java-Entwickler gemacht, Java-Bashing, der tatsächlich nur irgendwie als Quereinsteiger mal so ein bisschen reingeguckt hat und von algorithmischer Komplexität keine Ahnung hat und sich da ein ON hoch 5 gebaut hat,
Dann kannst du schon sagen, ja, logisch, dass das explodiert, da brauche ich auch nicht noch mehr Hardware draufwerfen. Und beim DevOps dreht es sich jetzt eher darum, dass du zwischen Leuten, die halt operative Erfahrung haben und Leute, die Entwickler sind und diese beiden als Tagesgeschäft, also diese beiden als unterschiedliche Disziplinen wahrzunehmen, hat jetzt erstmal Wert. Häufig wird DevOps auch so aufgegriffen, dass man sagt, oh, jetzt machen die Devs irgendwie alles. Auch bekannt als NoOps.
Und die, ich fände es ja, diese Begriffe fallen ja gerne so aus einem von diesen Open-Source-Treffen raus.
Das Dumme ist, das nimmt irgendein Manager dann halt noch ernst.
Das sind eigentlich bloß immer irgendwelche Biersprüche.
Weshalb es so macht, die zu trennen ist, die haben völlig unterschiedliche Tagesabläufe, die Leute.
Also als Entwickler ist es schon so, ich brauche extrem hohe Konzentration
und will mich halt auf bestimmte Sachen, die ich entwickeln möchte, konzentrieren.
Und aus einer Ops-Perspektive hast du aber eher das Thema,
dass du eben reaktiv, auch Echtzeit-reaktiv,
auf das Verhalten der Anwendung reagieren können möchtest.
Und das sind zwei Sachen, die funktionieren nicht gut
an einem Tag in der gleichen Person, sagen wir es mal so.
Also du kannst es schon so machen, wenn ich einen Tag mache,
wo ich sage, ich entwickle jetzt wieder Software bei uns,
dann versuche ich es möglichst zu vermeiden,
dass ich irgendwie so OBS-Sachen mache, weil
OBS-Sachen sind Dinge, die können gerne
mehrere Stunden dauern, wo du immer mal nochmal hingucken
musst. Und irgendwie...
Und dann die grüne und dann bringt die blaue die ganze Zeit
und dann oh oh. Genau, genau.
Ja, ja.
Genau, genau. Und allein deswegen
macht es Sinn, das als unterschiedliche Rollen halt
auch aufzufassen.
Das muss ja noch nicht mal dann sein, dass eine Person
immer OBS ist, aber dass du halt zum Beispiel weißt,
das sind unterschiedliche Zuständigkeiten und ich muss mir das halt auch
unterschiedlich zurechtlegen. Insofern ist eine
mentale Separierung dieser zwei Rollen und die
auch so ein bisschen zu klären,
was haben die eigentlich zu tun? Erstmal
ganz sinnvoll. Und wenn du es jetzt über
DevOps als Portmanteau wieder zusammenklatscht,
bedeutet es halt nur, die beiden müssen
trotzdem in einem ständigen Austausch miteinander stehen,
im konstruktiven Austausch miteinander stehen. Auf der einen
Seite möchtest du, dass operatives Wissen
in Projekte reinfließt, während die anfangen.
Und auf der anderen Seite möchtest
du auch, dass Entwicklung,
es sind vier Sachen, also auf der einen Seite
willst du operatives Wissen in Richtung Entwickler
bei Projektbeginn haben, à la
okay, was wollten ihr machen, was wollten ihr für Tools
nehmen, ah, könnt ihr vielleicht statt der MySQL
über eine Postgres nehmen, könnt ihr vielleicht, was, wofür
nehmt ihr den Memcache, komm, nehmt ihr den Redis.
Da wundere ich mich auch schon manchmal, dass
das eine Ops-Aufgabe
ist, sowas zu unterstützen, weil eigentlich denke ich
mir so, hallo, liebe Entwickler, ihr müsst eure
Tools halt auch kennen, ja.
Aber anyway, die
war zumindest mein Entwickleranspruch
immer. Umgekehrt möchte ich, dass
Entwickler wissen, von wie tickt diese
Anwendung intern eigentlich, und da finde
ich auch so Sprachen wie Python zum Beispiel angenehm, wo
du den Source-Code eigentlich immer gleich zur Hand hast,
dass die Ops halt mehr Einsicht kriegen in
was macht die Anwendung hier eigentlich? Ist das hier
gerade ein Bug? Ist das Absicht? Was tut denn das?
Also wir holen da halt gerne dann auch mal gleich den
Code raus, um zu sehen, warum rechnet
der hier? Ah, guck mal da drüben.
Und dass diese Form von Austausch halt
dann auch macht, dass Ops zum Beispiel mehr lernen,
okay, was brauchen Entwickler eigentlich aus der
operativen Perspektive? Und wenn die Entwickler
das dann halt mitgekriegt haben,
wie ist denn das mit dem Ops, dass die dann halt besser wissen,
ah, guck mal, wenn wir folgende Dinge tun, dann bauen
wir uns halt schon unser eigenes Grab und ich
vermeide jetzt halt wieder bestimmte...
Ja, ein beliebtes Beispiel ist halt
irgendwie, du renderst irgendeine Page raus,
wenn man halt serverseitiges HTML-Rendering
macht, du willst irgendeinen Twitter-Feed einbinden
und redest halt mit der Twitter-API.
Programmierfehler für
10 Euro,
du gehst halt mit einem synchronen
Socket per HTTP an diese Schnittstelle ran
und wenn Twitter in dem Moment meint, ich hab keinen Bock, dann bleibt
halt deine Frontpage stehen. Dann läuft dir dein
Threadpool für den Anwendungs-Server voll und dann bist du
halt komplett down. Und das dauert
halt so ungefähr 30 Sekunden, bis das der Fall ist.
Es passiert halt
immer wieder und das
kriegst du auch nicht raus, weil die Welt halt so komplex
ist, dass auch Entwickler, die zwar entwickeln gelernt
haben und selbst die halt
schon 10, 20 Jahre dabei sind, auch die machen da
immer mal Fehler dabei und müssen sich ein bisschen mit
obs reiben, mit was sind denn die
Fehler, die jetzt halt momentan typischerweise auftreten.
Es gibt halt bestimmte Fehler, das ist auch
wieder so ein Thema aus der komplexen Welt,
die gleichen Fehler treten die zweimal auf
und bestimmte Probleme,
die wir dann über sowas wie Root-Course-Analysis
oder so erschlagen wollen.
Da kommt immer ein Root-Course-Analysis.
Das musst du einmal noch mal kurz erklären.
Das sind einige Hörer, die sind genauso doof wie ich
und die wissen nicht, was das ist.
Die Wurzel-Grundanalyse.
Jetzt weiß ich mehr.
Was war, du hast halt bei Fehlern,
wenn Probleme auftreten, hast du ja irgendwann mal ...
Also welche Zeile, wo das steht.
Sozusagen.
Oder halt auch, welche Komponente ist kaputt gegangen,
Welche Festplatte ist kaputt gegangen? Hat die Putzfrau gerade irgendwie den Server ausgesteckt?
Okay, also wo ist die Lampe an und warum ist die an vor allen Dingen?
Ja, genau. Es kann ja so eine Kausalitätskette geben, so eine Kette von mehreren Gründen, die aufeinander aufgelaufen sind, warum dann am Ende irgendwie vorne was umgefallen ist.
Und diese Kette nachzuverfolgen, das nennt sich halt Root Cause Analysis.
Und die ist halt aus einer auch wieder sehr analytischen Perspektive von, finde bitte raus, wer schuld ist, erschieß ihn und schaff was Besseres an. Und das Dumme ist aber, wenn du halt eben in sowas wie die Black Swan Theorie reingehst oder in die Komplexität, dann wirst du feststellen, im Prinzip ist im Komplexen der Normalzustand, dass ständig irgendwelche Sachen außerhalb des Optimums laufen.
Das ist halt der Normalzustand und dein System so zu designen und auch dieses Feedback auf Team-Ebene zu haben von, was ist eigentlich normal und wann darf ich mich nicht zu weit aus dem Fenster lehnen, dafür ein Bauchgefühl zu entwickeln und die Praktiken, die halt heute relevant sind, ich kann nicht alle Praktiken, die es jemals gab, aufaddieren.
Und so wird aber dieser analytische Ansatz gemacht mit, wir machen jedes Mal, wenn was schief geht, eine Root Cause Analysis und wenn wir alle davon dann fixen, dann kann nie wieder was schief gehen.
Und die Leute wundern sich dann, warum trotzdem halt regelmäßig was schief geht. Und das ist dann halt eine Technik, ja, aus dem Ops-Bereich gibt es noch die, erkläre ich dann auch gerne, Meantime Between Failure und die Meantime to Recovery.
Dominik, sagst du bitte, dass ich es erklären soll?
Ja, ja, müsstest du bitte erklären, wann genau, wie lange man, wie viel Zeit braucht.
Ja, genau, genau, genau. Also das eine ist, ich kann halt mein System darauf auslegen, möglichst selten kaputt zu gehen. Und das andere ist, ich kann es halt darauf auslegen, möglichst schnell wieder reparierbar zu sein.
Und Extremwerte sind halt ungünstig.
Also, wenn man sich die Extremwerte anguckt,
sage ich, ich will, dass es nie kaputt geht.
Da wissen wir alle,
dann musst du so viel Energie vorab reinstecken,
dass du die Kosten nie wieder reinkriegst.
Und der Black Swan sagt uns,
es wird trotzdem auf eine Art kaputt gehen,
die du nicht vorhergesehen hast.
Das wäre dann sowas wie Full-Test-Coverage.
Ja, genau, Full-Test-Coverage mit allen Loops,
mit allen Grenzbedingungen, mit allen...
Also formale Verifikationen irgendwie.
Ja, genau, genau, genau, genau.
Und das ist halt, das ist halt, jeder Praktiker guckt dich dann halt an und sagt, das geht halt nicht.
Und das Dumme ist sozusagen, es wird halt sogar irgendwann kontraproduktiv.
Du steckst dann irgendwann so viel Energie und Zeit rein, Sachen starr zu machen, damit sie nicht kaputt gehen,
während aber Starrheit gegenüber einer flexiblen Umwelt eine schlechte Idee ist.
Also das hält halt relativ lange, so lange, bis es dann so richtig gar nicht mehr hält.
Du willst halt Methodiken haben, die so flexibel sind, dass du frühe Warnsignale kriegst von,
das ist hier eigentlich nicht mehr okay, aber ich
explodiere noch nicht,
damit du dann nämlich die Möglichkeit hast, aus diesen
kleinen, schwachen Signalen
schon mal was zu lernen und dein System dann schon mal
in die richtige Richtung zu bewegen. Das andere
Ende ist, statt sozusagen die Häufigkeit
der Fehler zu
reduzieren, ist zu sagen, naja,
ich mache mir den Fehlerfall ganz,
ganz einfach. Das sind dann solche
Sachen wie Clean Crash Restart,
also im Sinne von,
ich mache, dass meine Anwendung extrem schnell starten
kann. Ich weiß jetzt nicht, wie lange
Django zum Hochfahren braucht. Soap hat immer
urlange gebraucht, bis es mal
einen Port aufgemacht hat.
Während dann halt neuere Tools,
also ich habe halt immer viel mit Pyramid zu tun,
die machen halt nach
500 Millisekunden oder so den Port auf
und fangen an, wieder zu arbeiten.
Was bedeutet, im Ernstfall kann ich so eine
Anwendung auch einfach abstürzen lassen,
wenn es in einen unbekannten Zustand kommt,
weil ich weiß, die ist in 500 Millisekunden
eh wieder am Start.
Und wenn ich dann einen Pool von 10 oder so
davon habe, dann
mit einem vernünftigen Loadbalancer, dann denke
ich mir so, klar, die kann jede Nacht einmal abstürzen,
ist mir völlig egal, weil merkt keiner.
Merkt keiner.
Und dann kriege ich aber solche Infos mit,
oh du, übrigens gestern Nacht sind zwei Sachen
kaputt gegangen, hier ist der Stacktrace.
Geh mal gucken.
Versus, hm, wir haben jetzt ganz
lange alle Fehler unterdrückt und jetzt ist das ganze
System stehen geblieben. Viel Spaß.
Jetzt aber nochmal so eine ganz doofe Frage wieder.
Was ist denn jetzt eigentlich der Unterschied zu einem
Administrator dann?
Ich habe keine Ahnung, Namen sind schon alle drauf.
Das weiß ich nicht, naja, genau, ich glaube,
ob es ist nochmal ein bisschen älter,
irgendwie wurden teilweise auch Opis
genannt, was ist Opis, oder weiß nicht,
ja, oder Leute, die dann tatsächlich
im Rechenzentrum rumlaufen.
oder so. Und Admin ist schon so ein bisschen
so, der sitzt dann schon im
Bürostuhl.
Naja, ein Admin war
ja. Auf was sitzt du da gerade, Christian?
Ich sitze auf einem
schönen Bürostuhl.
Ja, also auch da
wieder, ich rede schon erstmal
wieder zur Komplexität drüber. Menschen
haben halt unterschiedliche Facetten.
Also Leute in
so eine eindimensionale Perspektive
zu schieben, macht den Menschen halt
eher weniger Spaß, also auch
weniger als Mensch.
Ich bin gerne mal im Rechenzentrum
in Arbeitshose unterwegs, weil ich halt
irgendwie wissen will, wie ist denn das mit diesen blöden Kabeln
und ach guck mal, da sind immer diese komischen
Nasen, die da abbrechen, ja genau und wenn du das nicht
ordentlich machst, dann hast du nach einem halben Jahr plötzlich ein Kabel,
das rausrutscht und umgekehrt
weil daraus
entwickelst du ja auch ein Gefühl zum Beispiel
von, wie stabil ist
so ein Kram eigentlich, anstatt ständig nur
über Abstraktionen zu reden und deswegen ist
Multidimensionalität und mehr Facetten
den Menschen
in ihrem Alltag
zu erlauben, ja, total wichtig.
Operator
ist der ältere Begriff, der
stammt dann wirklich schon aus
dem
Zweiten Weltkrieg.
Nee, Industrialisierung
tatsächlich schon. Also du hast halt,
das war dann eher so Engineering versus Operator.
Du hast halt Leute, die
entwerfen eine Maschine und Leute,
die die Maschine im Tagesbetrieb am Laufen
halten. Aber auch
das sind halt immer so ineinandergreifende
Tätigkeiten gewesen. Also die hatten
halt ihr begrenztes Feld von, ja, ich weiß,
hier, die und die Sachen kann ich machen, da hört irgendwo
meine Kompetenz auf, dann hole ich halt den Ingenieur
dazu und dann ist der Ingenieur halt auch vom Reißbrett weg
und muss dann halt mit der Ölkanne an das Ding ran.
Der kann aber in dem Moment
überlegen, was gerade die Konstruktionsprinzipien sind.
Der andere weiß halt, ja, komm,
das knarzt jeden Dienstag, da rufe ich jetzt nicht an.
Ja, da würde
der Ingenieur, dem würde irgendwie der Hut platzen,
das darf da nicht knarzen und der andere so,
Das knarzt seit 20 Jahren, das war wurscht.
Und das ist halt genau dieses Thema, so Alltags-Know-how, wie die Systeme, die designt wurden, sich dann real verhalten.
Das ist so das, was ich einem Op angeben würde.
Und ein Admin war immer auch eher einer, der halt aus so einer Systemmanagement, Systemkonfigurationssicht als ein Ingenieur tätig war.
Als überleg mir das hier einmal und dann tut das irgendwie.
Ich neige heute mehr zu dem Ops-Begriff, weil es halt so ein bisschen umfassender den gesamten Lebenszyklus auf der Server-Seite dann widerspiegelt.
Ja, ich meine,
in der FOPs hat man das ja sowieso dann schon im Namen
irgendwie mit drin.
Was ich an der Stelle noch ganz interessant finde, ist, dass halt auch
wenn man
jetzt sozusagen das komplett
voneinander getrennt hat, auch dieses Problem bekommt, dass
die unterschiedlichen
ja, sozusagen
Facetten da
halt unterschiedliche, also
der Erfolg wird halt unterschiedlich gemessen.
Das war halt also, sozusagen, ich war auch
eine Zeit lang Admin
und im Rechenzentrum unterwegs und so
und das Interessante
ist halt, dass
sich das halt gegenseitig blockiert, deswegen
ist es vielleicht auch nicht so eine gute Idee, das voneinander
zu trennen, weil
sozusagen der ganze Betriebsbereich,
also eben
Administration, die ganzen Infrastruktur-Kram,
Rechenzentrumsbetrieb, das wird halt
daran gemessen, dass es halt nicht kaputt geht,
sozusagen, also
ja, also ich meine
über, dass der Strom
da ist, das feiert niemand, aber wenn er
ausfällt, ist halt blöd.
Das heißt, wenn der ganze Kram funktioniert,
dann wird man nicht wahrgenommen.
Wenn es kaputt geht, dann ist es blöd.
Haha.
Genau.
Und bei den Entwicklern ist es halt so,
bei denen schlägt das ja gar nicht so sehr auf,
wenn das System irgendwie insgesamt nicht mehr funktioniert.
Und die werden halt daran gemessen,
wie viele Features sie halt rauskriegen irgendwie.
Und ob das jetzt irgendwie irgendwas verbessert oder so.
Das heißt, wenn man dann eine klare Trennung
zwischen den beiden Geschichten hat,
sind halt sozusagen
die optimalen Strategien möglicherweise für Entwickler
halt möglichst kaputtes Zeug
einfach raus damit, egal.
Die werden das schon irgendwie am Laufen
halten. Vielleicht steht ja nicht mein Name dran oder keiner.
Genau, weil ich meine, ich werde halt
nicht dafür bestraft sozusagen, wenn es kaputt geht
und aber belohnt, wenn
ich genug Features rausdrücke
und auf der anderen Seite optimiert
man halt darauf, möglichst keine Änderungen zuzulassen,
weil ein System, das
sich überhaupt nicht ändert, das ist auch relativ stabil
und dann blockiert man
einfach alle Anforderungen sozusagen oder
alle neuen Geschichten so lange,
ja, bis halt der Strom dann
nicht ausgefallen ist und man seinen Job erledigt hat
und, ja,
hat aber das Problem, dass es insgesamt auch für die
Firma nicht funktioniert und das war halt...
Solche neuen modischen Scheiße machen wir nicht.
Ja.
Ich meine, die,
das ist halt auch da wieder,
zum einen, spannend,
man, DevOps ist im Prinzip
in der Lage, dort diese Anreize einmal umzukehren
Im Prinzip kannst du
dann halt nämlich sagen,
erst mal messen
ist zwar eine gute Sache, aber auch da
Menschen haben halt so den Vorteil, die können so Systeme
gut austricksen.
Und wenn du,
das Schlimmste, was du eben machen kannst, ist, wenn du halt so
harte Metriken einführst, weil, was werden die
Leute machen? Die optimieren da drauf hin
gnadenlos.
Gnadenlos. Das ist das Problem,
warum halt Systeme sich dann immer
ad absurd führen, weil sie
versuchen, eine komplexe Welt reduktionistisch
zu betrachten im Sinne von
Uptime. Das ist
unsere Welt, danke.
Und was man
tatsächlich, manchmal kann man damit spielen, in so einem System kannst du
zum Beispiel dann sagen, naja, liebe Admins,
wir messen euch dran, wie viele Features rausgehen
und liebe Devs, wir messen euch dran, wie stabil
das Rechenzentrum ist.
Sondern wie stabil halt
die Anwendung draußen ist.
Und dann kriegst du nämlich plötzlich
eine ganz andere Bewegung da rein.
Ja, das wird dann auf jeden Fall dynamisch.
Dann jagen nämlich die Devs den Admin durchs Haus,
wenn der Server abgerottet ist.
Das willst du. Du willst Reibung.
Du willst Reibung, du willst Dynamik,
du willst nicht Complacency haben.
Du willst nicht, dass die Leute zufrieden in ihrer Ecke sitzen
mit, ah, der Strom ist an.
Sondern du willst sagen,
ist ja schön, dass hier der Strom an ist, wo bleiben
die Features?
Und das ist halt,
das ist tatsächlich was, wo DevOps
eigentlich sich ganz gut positioniert
an der Stelle. Da sind auch viele Tools
jetzt eigentlich gut darauf ausgerichtet,
das eben so zu überlagern, dass man
dann eben nicht mehr klar trennen kann.
Okay. Ich würde jetzt sagen,
der nächste Marker würde jetzt ganz gut passen, weil die
nächste Frage wäre nämlich, wie macht man das Ganze denn jetzt mit
Python am besten?
Mit Python? Okay. Tja.
Wie macht man das denn?
Hm. Ja.
Achso. Ich meine, wenn man
jetzt über komplette Systeme redet, da ist es
ja so, dass da gibt es dann halt so, ja,
diverse Stacks, die man verwenden kann, um halt
zu komplette Infrastrukturen aufzuziehen.
Ich weiß aber nicht, ob wir das, also sowas wie
Ansible oder halt SaltStack oder
OpenStack oder was auch immer.
Tja.
Und einiges davon ist ja auch
in Python tatsächlich geschrieben. Ja, das wäre, möglicherweise
ist das halt auch so ein Feld, wo Python relativ stark ist.
Ich glaube,
viele der, es gibt irgendwie noch
ChefPuppet,
das ist... Chef, Puppet?
Ja, das sind zwei unterschiedliche
Geschichten.
Das ist irgendwie Ruby oder sowas, ich weiß es nicht mehr so genau.
Ja, Chef und Puppet sind Ruby und
ich glaube, Salt ist Python
und der Enzebel ist definitiv auch Python.
Ist auch Python und OpenStack ist auch Python.
Also...
Aber ja, OpenStack ist wahrscheinlich alles mögliche.
Was ist denn sowas drin? Also für jemand, der es noch nie gehört hat,
was wäre jetzt in so einem Enzebel denn jetzt drin?
Ich würde es vielleicht tatsächlich nochmal von einem anderen Ende her holen, weil Ansible ist sozusagen schon ziemlich weit drin. Auf der einen Seite ist Python in diesem ganzen Umfeld erstmal an sich, wir haben jetzt ja zwei Enden, auf der einen Seite können wir darüber reden, dass wir Anwendungen haben, die in Python geschrieben sind, von denen ich irgendwie möchte, dass die raus in die Welt kommen und das andere wiederum ist, dass Python ja selber so eine gute Sprache ist, um Tools zu schreiben, die Dinge automatisieren.
Und damit habe ich sozusagen so eine kleine Janusköpfigkeit von dem Ökosystem.
Ja, es ist halt die Frage, von welchem Ende man anfangen möchte.
Die so große Systeme, ich tue mich schwer, bei so großen Systemen anzufangen.
Selbst Ansible ist da mental bei mir ein großes System.
Eher so ein bisschen die Grundlagen anzugucken,
ein bisschen die kleinsten Einheiten, in die es sich eigentlich verlegt.
weil ansonsten glauben unsere Hörer,
glauben die Menschen da draußen halt,
um den Post zu machen, muss ich irgendwie Kubernetes rausholen.
Das stimmt halt nicht.
Das ist halt kontextabhängig.
Ich meine, man kann vielleicht mal so ein bisschen skizzieren.
Auf der einen Seite gibt es halt das Problem der Runtime-Umgebung.
Ich habe halt mein Python-Skript und brauche dann irgendwie einen Interpreter,
der die richtigen Dependencies alle so hat.
das ist so ein
Spielfeld
und das andere ist dann halt tatsächlich auch
so diese Mechanik von, wie
verteile ich das dann halt von meinem
Entwicklung, wie mache ich das auf meinem Entwicklungssystem,
wie mache ich das auf dem Staging-System, wie mache ich das
dann draußen in der Produktion,
da kann man so die unterschiedlichen,
das wären also mindestens mal so zwei Perspektiven, aus denen
man das mal andiskutieren kann.
Ja,
ne, finde ich
im Grunde auch genauso richtig, weil
ja, also das ist ja auch vielleicht dann tatsächlich das,
was Leute praktisch als Problem
haben, wenn sie jetzt
sich überlegen, okay, ich würde gerne, weiß ich nicht,
Pyramid oder Django oder Flask oder was auch immer
anwendigen, würde ich gerne eine Webseite
oder so bauen und wie kriege ich die jetzt
sozusagen live?
Ja, also
das eine ist natürlich, dass
Python ein standardisiertes
Umfeld hat mit den Interpretern.
Ich meine, die Versionsunterschiede zwischen
2 und 3,
ich glaube, das ist jetzt eh gegessen, zumal
dann machen wir
ein Begräbnis-Podcast
Ende des Jahres für Python 2.7?
Könnte man auf jeden Fall
machen, ja.
Ein Python 2.7
Gedächtnis-Podcast
zum Jahresausklang.
Aber auch innerhalb von Python 3 sind die
Sprachfeatures nochmal so weiter, dass man halt auch da
zum ersten Mal wissen muss, ah, okay, ich habe eine Anforderung
von, welche Version vom Interpreter
brauche ich eigentlich? Da ist die
Spreizung zwischen 3.3,
was so die erste vernünftig einsetzbare
Version war, bis jetzt hoch zu 3.7, in demnächst
3.8, ja, schon relativ
heftig, zumal ich auch merke, da waren für mich immer
wieder Features dabei, die ich
einsetzen möchte. Also die F-Strings waren
mit die neuesten Sachen, wo ich sagte,
oh ja, die will ich unbedingt haben.
Das Coolen ist sogar schneller als String-Off, ne?
Das kann sein.
Und das ist sozusagen schon mal so das erste Thema von,
okay, ich brauche also irgendwie ein Zielsystem, wo die richtige Version
von diesem Interpreter vorliegt.
Das ist dann häufig damit gekoppelt, dass
ich bestimmte Versionen
von einem Betriebssystem irgendwo habe.
Genau. Wenn ich
Docker nehme, dann ist da typischerweise die Auswahl
nimm dir irgendwie so ein Basis-Image, wo jemand draufgeschrieben
hat, das hier ist das mit Python-Version
so und so oder wo alle Python-Versionen drin sind
oder was auch immer.
Aber im Prinzip läuft es halt darauf hinaus, naja,
ich habe erstmal die Frage, welchen Python-Interpreter
würde ich gern haben. Ich mache es in letzter
Zeit so, wenn ich kleinere Projekte mache
und tatsächlich im Sinne von mal so Command-Line-Skripte,
das ist bei mir relativ viel dran,
dann gebe ich mir
Mühe, dass ich am Anfang
wenn ich noch rumexperimentiere
und das teilweise auch verteilte Systeme sind
dann habe ich meinen Editor
bei mir ist es dann zufällig der Sublime
mit einem rsync-Plugin
mache ein einziges Python-File
und das kann gerne mal für
den Anfang bei der Entwicklung 1000, 2000
4000 Zeilen lang werden
und habe ein rsync-Plugin
was mir bei jedem Speichern das auf
7, 8, 9 Kisten verteilt
und gebe mir Mühe, dass ich nichts anderes
außer der Standard-Library benutze
dann brauche ich mir nämlich
keine Gedanken machen
und ich meine
die Standard Library hat einen Haufen Kram drinnen
da ist halt
damit machst du dann keine Webentwicklung mit Django in dem Moment
aber
oh ja
Entschuldigung, ich glaube das war diesmal
weg da, halben Meter weggeworfen
lag zu nah am Kabel
die
Standard Library bietet ja schon so viele
Sachen
von
JSON zu, hast du nicht
gesehen, typische Dinge, die dann bei
mir relativ schnell dazukommen, als Dependencies sind dann halt
irgendwie Requests oder irgendwas in der
Art. Aber
ich baue selbst bei mir die
Projekte dann immer erstmal von so einem
ganz kleinen, minimalen Punkt auf und
ich mache nicht so dieses, oh, ich habe hier mein Projekt-Template
und jetzt schütte ich erstmal
ein Megabyte-Template ins
Repository, sondern
fange halt gegebenenfalls wirklich mit einer einzelnen Datei
an.
blank, völlig blank und kann auf dem Zielsystem
auch einfach sagen, hier, Python 3.6, da die
Datei, poof, mach mal.
Und kann halt, weil
ich bin immer der Freund von diesem, ich nerv
meine Kollegen, mit denen ich
arbeite, auch an der Stelle, ich will eigentlich
so schnell wie möglich, eigentlich innerhalb von einer Stunde
oder zwei, irgendeine Ahnung haben,
wie das, was ich gerade mache, von Ende zu Ende
funktioniert, ja.
Also dich interessieren die Knoten dann dazwischen, oder?
Nee, mich interessiert halt, okay,
ich will irgendwie x erreichen
und dann kann man halt entweder sagen, ah, für x muss ich
erstmal A, B, C und D machen und dann
fängt jemand an und macht A total hübsch und
definiert das durch und macht B total hübsch und definiert
das durch. Am dritten Tag macht er C
und am vierten Tag macht er D.
Dann läuft das Skript zum ersten Mal und er stellt
fest, nee, das brauche ich alles ja auch nicht.
Und was ich eher haben will,
ist, ich rotze da A, B, C
und D einmal so, gerade mal so hin
in den
so wenig Zeilen wie nur möglich mit
auch wenig
Fehlerbehandlung, also nur den
der Happy Path im Prinzip.
So der Idealfall.
Der Happy Path, war schön.
Der Happy Path, ja, genau.
Um tatsächlich zu sehen, ist das, was ich hier baue,
gerade überhaupt das, was ich will?
Oder fange ich schon mal an, Zeug zu polieren,
was ich gleich in zwei Tagen eben wieder wegwerfe?
Happy, happy, happy.
Happy, ja, genau.
Und das erleichtert,
dadurch kann ich halt auch mit wenig Dependencies anfangen,
dadurch kann ich halt, oder auch ohne Dependencies,
und baue das halt komplett inkrementell auf.
Und das ist wieder für mich auch so ein Ausdruck von,
Ich beschäftige mich die ganze Zeit mit meinen Tools,
um zu merken, brauche ich das hier überhaupt?
Das muss ich halt im Prinzip jedes Mal validieren.
Kannst du nochmal vielleicht einmal ganz kurz so erklären,
so einen Abstraction-Layer so drunter,
was steht denn dann da in dem Skript so konkret da drin?
Klar, das ist nur die Standard-Library, irgendwelche Sachen,
aber was macht das?
Also ich habe zum Beispiel ein Skript,
mit dem wir bei uns Ceph-Server managen.
Ceph ist so ein verteiltes Storage-System
und da hat jede Festplatte, die du in deinem Cluster hast,
einen Daemon, der da läuft und die Config
zu generieren und die Teile aufzusetzen
ist halt nicht so ganz trivial
und die Tools, die es dafür schon vordefiniert
gibt, die haben alle so ihre Meinung darüber, wie
die Umgebung aussehen soll, wo wir leider
eine andere Meinung haben und
deswegen habe ich dann halt irgendwann
ein Tool geschrieben, wir schreiben gerne Tools,
die andere Tools
integrieren, wir machen Glue-Code gern selber,
so Policy-Code
und versuchen eigentlich Werkzeuge einzusetzen,
die Standalone für sich irgendeinen
konkreten Job haben und wir integrieren uns die dann
halt und dann habe ich halt so ein Tool, der kann
dann halt irgendwie die Festplattenkontrolle
angucken und kann sagen, machen wir mal eine
neue Partition, machen wir diesmal jenes, bauen das
mal wieder ab, aber eben mit so Policy
Entscheidungen wie, ja, da
musst du vorher mal gucken, ob da drüben in den Logs komische Dinge
auflaufen, weil das ist ein Indikator dafür, dass gerade
der Cluster überlastet ist und darfst du das so nicht machen
und solcherlei Dinge und dann ist das halt
was, da ist dann der ArcParse mit drin und
da wird dann mit irgendwie so Prozessen geredet,
da ist JSON-Depoding drin, da ist so
Glue-Code, um 5, 6
unterschiedliche Tools und Prozesse aneinander anzubinden
und den baue ich halt meistens immer wieder erst mal nackt auf
und erst wenn der eine gewisse Größe hat, setzt dann das Refactoring ein
und natürlich hat man so eine Standard-Library im Hinterkopf von
wie abstrahiere ich mir eine bestimmte API, um Subprozesse aufzurufen,
wie abstrahiere ich mir eine bestimmte API, um HTTP-APIs anzusprechen,
aber selbst denen gebe ich eigentlich immer wieder die Chance,
sich nochmal neu zu beweisen, weil Python nun mal eigentlich so einfach ist,
um den Happy Path mal schnell runterzuschreiben.
um dann später nochmal mit der
Zahnbürste hinterher zu gehen und das irgendwie
blank zu machen und hübsch zu machen.
Genau.
Und das heißt, also im ersten Fall bei mir
habe ich sogar ein Deployment, da
passiert nichts außer aus meinem Editor raus
ein R-Sync irgendwo in die Umgebung rein.
Und ich nehme den Standard
Interpreter, der vom System halt mir entgegengeworfen wird.
Das hört sich so ein bisschen an,
also hast du gar nicht so viele Klassen, die haben los,
ist das mehr funktional alles?
Nö, das geht quer durcheinander.
Also Klassen ziehe ich mir halt dann rein, wenn es halt nötig ist, wenn ich merke, da kristallisieren sich Strukturen raus, die sich halt in Klassen gut abbilden lassen.
Machst du dann auch ein extra Modul dafür oder packst du das dann trotzdem alles in die?
So und das ist halt spannend, also wenn ich dann einen gewissen Reifegrad erreicht habe und merke, ich laufe in die richtige Richtung und das, was ich hier baue, fliegt nicht morgen wieder über den Jordan, dann fange ich an, das halt zu systematisieren.
Und dann mache ich dann aus dem Repository
halt mal ein gescheites Package
in Richtung halt, dass da ein Egg rausfallen
könnte.
Beziehungsweise Eggs macht man ja nicht mehr.
Also eine Sauce Dist oder ein Wheel
oder was auch immer.
Aber eben irgendwas, wo eine Setup-Pi drin ist
und wo man diese ganze Kram, dass man es paketieren kann,
dass man es auf dem Pi-Pi laden kann, etc.
Und das Zweite ist, dann fängt es
halt meistens auch an, dass da die ersten Dependencies
dazukommen.
Weil das kommt meistens sogar früher, als dass ich ein Package
draus mache, wenn ich so kleine Sachen habe.
Was aber mit den Dependencies halt auf jeden Fall kommt, ist, Jochen kann es bestimmt auch aussprechen, was ich jetzt denke.
Ja, natürlich, Virtual Environments oder irgendeine Art zu isolieren halt die Begebung, die man auch schafft.
Genau, also verlockende Falle ist halt, aber das ist eigentlich auch schon so eine alte Technik, dass die eigentlich nicht mehr vorkommen sollte, ohne irgendwem von unseren Hörern zu nahe zu treten.
Man kann natürlich jetzt dem System-Python-Interpreter über Debian-Packaging oder über YAML oder was auch immer
dann noch zusätzliche Libraries mit rein installieren.
Aber das Problem ist, dann haben halt alle Programme auf diesem System die gleichen Dependencies.
Ich meine, das ist so ein altes Problem von Paketierung halt an sich, also auch bei Debian.
Wenn Debian halt sagt, ich paketiere Version 7 und deine Anwendung braucht Version 8, dann hast du halt verloren.
Und deswegen macht man sowas nicht, dass man Sachen in den Systeminterpreter rein installiert, sondern dafür gibt es halt die sogenannten Virtual-Envs, die sind seit Python 3 auch kein extra zu installierendes Tool mehr, sondern du kannst ja über Python 3-mv-env und dann Verzeichnisname oder wenn du es in deinem Repo direkt machen willst mit Punkt, erzeugst du dir eine virtuelle neue Python-Installation, in der du dann beliebig Dependencies installieren kannst.
Und dann installierst du die da halt rein.
Das kannst du mitmeißeln, also das kannst du imperativ machen,
indem du dann aufrufst bin-pip-install-requests
oder du kannst auch ein Requirements-File schreiben,
was sowas dann deklarativ erfasst, wo du sagst,
hier, ich hätte gerne Requirements und ich hätte es gerne in folgender Version
oder ich hätte es gerne zumindest größer als Version X.
Solche Sachen kannst du dann da ausdrücken.
Das ist dann ein bisschen ergänzend dazu, dass du dein eigenes,
wenn du dein Skript selber paketierst und sagst, ich habe einen Package, wo auch Dependencies in der Setup-Pi deklariert sind, dann kannst du die über binpip-e. zum Beispiel installieren, dann zieht er die Dependencies auch, wobei da gibt es halt auch so eine Unterscheidung von, wie drücke ich Versionen in einem Paket aus, da gibt es eigentlich die Heuristik, dass man sagt, dass man nur dort Mindestversionen angibt,
Dass man sagt, ich brauche mindestens Version XY von der Dependency, weil da gibt es ein Feature drin, was ich halt unbedingt brauche ab der Version, aber ich lasse es dir nach oben hin offen, auch neuere zu nehmen und man macht dann gegebenenfalls noch als zweites dazu einen Requirements-Text-File, wo man dann sagt, okay, aber jetzt für dieses konkrete Release legen wir uns einmal auf einen exakten Satz an Versionen fest, das nennt man dann Version Pinning und dort schreibt man dann nur noch rein, okay, jetzt die Requests in exakt Version 2, 3, 4.
hier oder was auch immer.
Genau. Das ist so ein bisschen
hakelig
im Sinne von
das gibt dir kein
garantiert pures Environment, weil
du kannst das halt vermixen, dass du sagst, du installierst
Sachen, Dependencies per Requirements Text
und kannst dann gleichzeitig
trotzdem noch mit binpip install dazwischen rum
vorwerken. Ist da nicht jetzt sogar so eine
Neuerung geplant, irgendwie in 3.8, dass man das irgendwie
mit in die Verzeichnisse irgendwie direkt reinkriegen
kann oder sowas?
Ja, das wäre jetzt mal interessant, das habe ich jetzt noch nicht auf dem Schirm.
Ja, das hatten wir irgendwie,
ich habe es jetzt aber auch nicht mehr so wirklich genau,
also da ist es auf jeden Fall so, dass man
PIP irgendwie sagen kann,
war das
PIP oder ist das?
Man kann ja die Version aussuchen, ob der irgendwie
Versionen nimmt, die irgendwie im System hängt oder halt die
Das ist halt lokal, also das
macht halt automatisch ein Environment, das halt
lokal in dem Verzeichnis ist, das ist quasi genauso wie
wie bei
ja, NPM auch
Ja, okay. Das mit dem System-Byte ist noch ein, es gab früher, also die Option gibt es immer noch als Abwärtskompetenz, früher gab es noch die Variante, dass du dir ein Virtual-Env machst, was aber sozusagen alle Nicht-Standard-Library-Pakete aus dem System miterbt und das ist genau das, was du aber nicht willst.
Deswegen heißt das auch momentan der Default und ich glaube, das fliegt vermutlich auch irgendwann weg oder es wird zumindest so wenig dokumentiert, dass keiner mehr aus Versehen drüber stolpert und meint, das wäre eine gute Idee.
Und das Problem, was ich habe, ist eher, dass diese Virtual Envs, wenn du dann, keine Ahnung, dann entwickelst du ein Team und die Requirements-Text entwickelt sich weiter und du sagst dann bin-pip-insta-r-requirements-text, dann kriegst du halt nur die Änderungen.
Und wenn du aber schon irgendwelche Sachen, keine Ahnung, dann gibt es irgendwas, das ist keine Dependency mehr, dann ist die aber trotzdem noch drin, weil etwas, was in der Requirements-Text nicht drin steht, wird halt nicht rausgeworfen in dem Moment.
Du hast halt also keine abgeschlossene Hülle von dem, was da drinnen definiert ist
und kannst dich nicht darauf verlassen, dass nicht noch zufällig mehr Zeug da ist.
Und das kann aber tricky sein, weil es gibt halt Mechanismen, zum Beispiel in Setup-Tools,
die haben halt Auto-Discovery für irgendwelche Entry-Points
und dann werden da Entry-Points aktiviert, von denen du nicht wusstest, dass sie da sind
und dann geht dir irgendwie alles den Bach runter.
Das will man halt einfach nicht.
Und auch das ist so ein Black-Swan-Ding im Sinne von, ja, in vielen Fällen funktioniert das sehr gut,
Aber nächsten Dienstag geht deswegen halt irgendein Server baden.
Weil wir haben halt so viel Code,
der so viel Autodetection für bestimmte Dinge macht.
Dann kann es halt sein,
dass nächsten Dienstag tritt halt irgendein Exception auf
und dann gibt es halt irgendein Tool,
das hat so Exception-Handling.
Der geht dann wieder auf die Suche,
ob es für das Exception-Handling noch irgendeinen Entry-Point gibt,
der da irgendwie deklariert ist.
Und deswegen kommt da plötzlich irgendwie Code zum Tragen,
wo du dachtest, das haben wir doch nie definiert.
Ja, der war halt noch von vor zwei Wochen da.
Auch das ist ein Problem, was Docker ja löst.
Ja, löst Docker das Problem?
Ja, weil bei Docker bei einem Release fängst du halt immer mit deinem leeren Basis-Image an und baust das halt wieder komplett auf.
Während wenn du einen Virtual-Env sozusagen zweitverwendest, was ich völlig okay finde, was man machen kann, man muss halt wissen, was die Konsequenz daraus dann halt ist.
Ja, naja gut, bei Docker, also so wirklich weißt du ja nicht, was in deinem Basis-Image alles drin ist.
Also, wenn du es selber baust, ja klar.
Jetzt macht mich diese schöne Welt nicht kaputt.
Ja, also klar.
Ich meine, war jetzt ja auch bei Heise gerade wieder das Thema,
dass ein Haufen von den Top 500 Docker-Images
halt keine Root-Passwörter gesetzt hatte.
Ja, ja.
Das ist halt, genau, ich meine,
das ist das ganze Thema Dependency Management, Vendoring.
Wo kommen meine Sachen her, die ich jetzt irgendwie
als Route irgendwo in das System reinschieße?
Es gab
noch ein Tool, was ich eigentlich jetzt hier noch mit
einbringen wollte, falls euch das was
sagt, das ist CC Buildout.
Buildout, habe ich schon mal
irgendwie gehört, aber glaube ich habe es noch nicht verwendet.
Das ist ein Tool, das stammt
halt auch so aus der Zeit, wo die Virtual Env sich gerade
etabliert haben. Der kann zum einen, kann er das, was
Virtual Env
macht, auch machen, nämlich dir
vom System Python
entkoppelte Pfade zu liefern,
wo die Dependencies
klar ausgesteuert sind. Und was
ich am Buildout aber spannend finde, ist, der hat
eben diese Option, dass du über die
Buildout-Config explizit
sagst, auf der einen Seite, du
darfst nur Pakete
mit folgenden Versionsnummern anziehen
und wenn die
wiederum rekursiv Dependencies anziehen, die ich
nicht dokumentiert habe, hier explizit in meinem
Version-Pinning, dann fall bitte aufs Maul.
Und das ist total spannend,
weil der putzt auf der
einen Seite sozusagen nach hinten hinweg Sachen, die
du nicht mehr verwendest. Das heißt,
das ist immer automatisch garantiert clean.
Und auf der anderen Seite kannst du halt dich darauf verlassen, dass wirklich nur exakt das Versionsset da ist, was du halt brauchst.
Und das Ding ist relativ leichtgewichtig in dieser Hinsicht.
Und ich benutze es halt an vielen Stellen genau dafür, dass ich sage, ich mache mir auf der einen Seite ein Virtual Env, um die Systemtrennung zu erreichen, das ist der Bequemlichkeit halber,
und installiere darin CC Buildout und mache dann eine kleine Buildout-Config, wo ich sage, ich möchte gerne bitte eine Interpreterumgebung für folgende Packages haben
Und deren kompletter Dependency-Tree
muss übrigens durch folgende abgeschlossene Liste
komplett gedeckt sein
oder du darfst sie nicht installieren.
Und das ist tatsächlich was,
das garantiert dir so reproducible Builds halt sehr gut.
Okay, cool, muss ich mir mal angucken.
Habe ich bisher noch nicht so gemacht.
Ja, das ist so ein typisches Tool aus der Soap-Welt,
was es über die Soap-Welt raus nie geschafft hat.
und es hat eigentlich, da hängt
so ein bisschen mein Open-Source-Herz
von vor zehn Jahren halt dran,
das hat eigentlich das bessere
Engineering. Es hat sich
halt nur nicht durchgesetzt, das ist so ein bisschen
Krokodil-Trainer.
Genau.
So,
ja, jetzt haben wir
so Virtual-Env und...
Ja, dann machen wir auch deinen Rap nochmal drum
und machen nochmal weiter. Also was habt ihr denn noch?
Wie macht man denn dann, wenn jetzt so das
Umgebungssetting so gebaut ist.
Jetzt haben wir
erstmal die Möglichkeit, dass wir in Projekten
überhaupt Umgebungen
mehrfach bauen können. Also du checkst
ja jetzt die Requirements-Texte oder das Buildout
checkst du halt mit ein.
Und da kommt eine interessante
Frage, nämlich checkst du zusammen mit deinem
Code ein oder machst du ein neues Repo?
Ja, also ich check das immer
zusammen mit allem anderen ein, aber
ja.
Man könnte natürlich
das so machen, dass man den Code
in andere Repositorien packt und dann
in die ganze Infrastruktur,
wie deployed man
das Projekt
halt in eine andere Geschichte reinpackt.
Ja, hm.
Das machen wir
eigentlich, das machen wir sehr gerne, ja.
Also zieht sich dann die Maschine selber immer den Code
von Remote und andersherum musst du den mal
pushen oder was war jetzt der Unterschied?
Ah, das ist noch ein interessanter Vorschlag.
Genau. Hm, hm,
interessant. Also weißt du,
klar, was du halt machen kannst, ist, du kannst
jetzt solche Dinge spielen, wie
auf deinen Zielmaschinen
machst du dir einen Con-Job,
der zieht das Repo
selbstständig alle,
entweder per Trigger oder irgendwie
alle fünf Minuten oder was auch immer,
von einer Production-Branch und
führt dann irgendwie so ein Build-Skript aus.
Das kannst du machen.
Das machen wir auch an ein paar
Stellen.
Kommt ja immer darauf an, wovon man es braucht.
Und ja, genau. Und selbst da kann man eben diese Auftrennung machen, wenn du davon ausgehst, dass deine Anwendung zum Beispiel von unterschiedlichen Leuten mal deployed werden soll, dann macht es halt Sinn, das in unterschiedliche Repos zu legen.
Oder wenn du es über Teams trennst. Also wir haben es halt häufig, weil wir ja als Dienstleister in Projekten drinnen hängen, wo jemand anders die Software entwickelt, dann haben die halt ihre Repo für die eigentliche Software.
Und wir haben das Repo
für das Deployment.
Wir haben meistens gegenseitig
auch Schreibzugriffe drauf, aber es ist so mehr ein
man tritt sich halt nicht unnötig auf den Füßen rum.
Ja, das ist
ich meine, ich weiß nicht, also das, was
man da vielleicht, also mache ich jetzt für meine
also so privaten, kleineren
Geschichten auch nicht, aber wenn man jetzt
irgendwie eine größere Sache hat, was man ja
vielleicht dann haben will, ist halt
Continuous Integration oder Delivery sogar,
dass man dann, wenn halt
man sozusagen
Code, den man irgendwie geändert hat, dann
in einen Masterbranch oder so reinpusht,
dass das dann halt automatisch irgendwie
in einem neuen Bild lostritt und das auch ausrollt
automatisch alles, wenn man halt
irgendwie so einen CI-Server
da irgendwo stehen hat, der das dann macht.
Du musst ja einmal vielleicht nochmal für die Leute, die
es auch gar nicht kennen, erklären, was ist der Unterschied zwischen Continuous
Integration und Delivery und
ist das einfach so ein Prozess, der automatisch
angestoßen wird, wenn man einen Entwicklungsschritt
abgeschlossen hat oder
Feature-Entwicklung oder
irgendwie Fixes oder worum geht es?
Ja, es geht halt
im Grunde darum, dass, also was man ganz
früher gemacht hat, ist, dass man halt
baut die Software irgendwie zu periodischen
Zeiten oder halt wenn man
mit einer Release fertig ist und
dann baut man die halt einmal und dann
presst man die auf
eine CD oder speichert die auf
Disketten und verschickt die mit der Post oder irgendwie sowas.
Aber
was man ja jetzt eigentlich tun kann, wenn das Ganze
sowieso alles mit
Netz verbunden ist,
dass man das ja auch in kleineren
Intervallen macht, was halt den Vorteil hat, dass man
nicht sozusagen
vor dem Problem steht, das man
bekommt, wenn man jetzt so fixe Releases
machen möchte, dass man halt,
wenn man jetzt, also klassische
Geschichte dabei ist halt so,
man hat halt
so Milestones und dann irgendwann ist man fertig und dann
sagt man, okay, jetzt machen wir noch irgendwie eine Woche
testen hintendran und dann liefern wir das
aus. Und dann fällt an Tag 3
irgendwie beim Testen fällt halt auf,
oh, wir haben hier ein großes Problem gefunden.
Was macht man denn dann? Dann ist es halt irgendwie doof.
Dann kann man halt entweder
das irgendwie Ducktape auspacken,
was diverse Nachteile hat,
oder man kann halt
irgendwie, ja, sagen, okay,
wir können doch nicht releasen,
was dann halt auch wieder Nachteile hat. Also man ist in einer Situation,
wo man keine guten Optionen mehr hat
eigentlich. Und das ist natürlich ein bisschen
dumm. Oder man hat halt das
Problem, dass man die Arbeit von anderen Leuten,
die dann vielleicht auf anderen Branches irgendwie gearbeitet haben,
irgendwie integrieren muss und das dann auch
nicht richtig funktioniert und einem erst zum Schluss
auffällt, dass das alles so nicht
funktionieren kann, wie man das geplant hatte.
Und das ist halt blöd
und das kann man so ein bisschen loswerden
oder diese
Geschichten sind halt der Versuch,
dass sozusagen dadurch, dass man das Release
jetzt nicht einmal so ein großes, riesenbrocken Ding
macht, sondern man zerteilt das halt in viele
kleine Geschichten,
das dann halt so undramatischer zu machen.
Und damit dann dahin zu kommen, dass das dadurch, dass das halt häufig passiert und alles durchautomatisiert ist, ist ja auch so etwas, was man früher hat man dann viele dieser Prozesse, die nötig sind, um irgendwas zu releasen, hat man dann manuell gemacht.
Dann hat man dann mit Chatlisten gearbeitet, weil man sich das nicht alles merken kann und trotzdem passieren dann immer wieder Fehler und alles nicht so toll.
wenn man das halt ganz oft macht, dann ist auch
ein gewisser Druck da, das halt so
zu automatisieren, dass man da im Grunde nur noch auf den Knopf
drücken muss.
Also das ist jetzt, was man jetzt hat, wenn man jetzt so ein
Git-Flow sich eingerichtet hat und das dann irgendwie
in so ein Framework reinlädt, dann wird das automatisch
getestet, dass man bei Git,
Travis oder was habe ich da meint?
Travis.ji ist halt so ein Continuous Integration
Bar.
Oh.
Ja, also man hört da so manchmal
so komische Geschichten, dass da irgendwie Leute
plötzlich irgendwie
arbeitslos werden und so in letzter Zeit, ja.
Aber ich weiß da halt nichts drüber, keine Ahnung.
Ich verwende es immer noch für meine GitHub-Geschichten,
weil da gibt es halt eine sehr schöne Integration.
Ah, die läuft noch?
Ich dachte, die haben sie auch zugemacht schon.
Die läuft noch.
Travis ist eigentlich durch.
Was gibt es jetzt?
Naja, du hast halt, GitHub kannst du
ja inzwischen selber machen,
Bitbucket kann Pipelines, du hast
GitLab, gibt schon noch einiges.
Ja. Okay, die Pipelines werden
dann eigentlich integriert. Ich habe das bei Azure mal gesehen.
Dann wird dann einfach direkt getestet.
Dann kann man sich da was schreiben und dann testet der das
direkt durch, also ob es läuft.
Einfach auf dem Server integriert insgesamt.
Ja, ob die Tests durchlaufen, kann man natürlich
machen. Und das kann man halt dann auch nicht nur
so machen, dass es halt irgendwie findet speziell,
sondern man kann dann auch...
Man kann so eine Maschine spawnen, die dann halt auch irgendwo stehen sollte, oder?
Ja, könnte man. Aber das
kann man im Grunde machen, wie man möchte.
Also üblicherweise wird irgendwie
eine virtuelle Maschine wahrscheinlich hochgezogen und dann werden
halt da die unterschiedlichen Environments,
da gibt es so Talks, mit denen kann man
sagen, welchen Dingern
das halt funktionieren sollte
und dann werden Interpreter in unterschiedlichen Versionen
installiert und Software in unterschiedlichen
Versionen und dann wird das halt, wenn die Tests
laufen gelassen und wenn die halt durchlaufen, dann ist halt gut.
Aber man
kann halt nicht nur das machen, sondern man kann halt beliebige Dinge tun,
wie auch irgendwie dann halt
ein Deployment lostreten,
wenn das dann halt alles funktioniert hat
und so, dass das halt im Grunde dann komplett
durchautomatisiert ist von
irgendwie Entwickler
sagt jetzt, okay, ich bin mit dem Feature fertig,
macht eine Release,
oder macht einfach nur Push auf Master
und ja, irgendwie
weiß ich nicht, ein paar Minuten später ist es dann halt
im Produktionssystem live.
Aber
zwischen irgendwie, man macht halt irgendwie alle paar
Wochen Release und
eben so etwas,
man checkt Code ein und es geht dann sofort
live, gibt es halt alle möglichen Zwischenstufen
und die dann, ich weiß
gar nicht genau, wie die genauen Definitionen
jetzt für die unterschiedlichen Sachen da sind.
Hätte ich jetzt auch keine, die irgendwie
formal wären.
Ich finde es
spannend, dass auch da wieder diese beiden Extreme
nur zu betrachten
eben genau nicht hilfreich ist.
Wir haben so viele Projekte, wo wir
ganz unterschiedlich eben diese Zwischentöne eher sehen,
wo auch Entwickler
dann teilweise sagen, ich finde es eigentlich ganz gut,
wenn ihr
bestimmte Sachen auch nochmal mit anschaut.
Und das ist halt genau dieses Thema von, warum
will man denn enger zusammenarbeiten?
Weil man ja möchte, dass Menschen
miteinander Wissen austauschen.
Und dann ist sozusagen dieser, so das geht jetzt hier blind raus, das kannst du schon machen und das funktioniert auch, das hat halt andere Konsequenzen und ich muss mich da anders aufstellen.
Wir haben halt auch so Flows, wo die Leute sagen, wir können beide auf den Knopf drücken und ich komme nur an, wenn ich mir nicht sicher bin und dann bitte ich dich mal irgendwie noch bestimmte Sachen mit mir gemeinsam anzuschauen.
Oder einige sagen, hier komm, du kümmerst dich drum, mach einfach wie du willst, drück selber auf den Knopf, wenn du soweit bist.
Da gibt es halt tatsächlich diese ganzen, wenn du es durchautomatisiert hast, kannst du die ganzen kleineren Varianten davon halt automatisch auch spielen.
Ja, zu sagen, okay, das läuft jetzt halt nicht vollautomatisch, sondern es läuft jetzt halt nur bis hierhin und dann muss man mal draufdrücken oder dann schicke ich hier nur eine Nachricht ab in irgendein Channel.
Das lässt sich halt besser erreichen und du musst dich im Prinzip halt auf diese, da auch annähern.
ich meine, jeden Commit sofort rauszublasen,
das kommt dann halt auch drauf an,
wie, was für ein Impact so ein
Deployment halt hat.
Wenn wir sind bei,
okay, das dauert halt nur 500
Millisekunden, um mal neu zu starten,
ja, das kannst du fast immer überall machen.
Wenn du halt Rolling
Releases kannst, wenn du also sozusagen in der Lage bist,
alte und neue Versionen deiner Software parallel zu betreiben,
dann versteckst du das hinter einem
Loadbalancer, hast irgendwie 10 Instanzen und dann
updatest du die erste, startest du die neue, updatest du die zweite,
dann müssen aber halt die Software-Versionen
mit den unterschiedlichen Datenbankständen
halt auch zumindest adäquat
klarkommen. Und das ist halt
was, was man dann halt bauen muss. Oder du sagst halt
nee, das will ich nicht bauen, weil
ich hab halt auch noch irgendwelche Dependencies auf Sachen,
wo ich das nicht unter Kontrolle habe. Ich brauche
ein Black Deployment, dann
musst du halt irgendwas machen, was halt vielleicht nachts losläuft
oder um drei.
Ja, genau. Der Trick ist, das kannst du ja
machen, wenn du dir im Prinzip sicher bist, weil
das alles so eingespielt ist, dass das halt nicht kaputt geht.
wie du vorhin meintest, wenn es halt weh tut,
dann, weil du es halt ständig machst, dann
optimieren die Leute halt darauf hin, dass man es ständig macht.
Die alte
Leier dazu ist doch,
if something hurts, do it more.
Genau.
Je nach Präferenz.
Ja, genau.
Nee, aber der Mensch neigt ja dazu, halt
irgendwie Schmerzen abzustellen, insofern wenn du
Genau, man muss das halt irgendwie
wegkriegen von dem, es ist irgendwas Außergewöhnliches,
schreckliches, wovor alle Angst haben
und dann so zu etwas,
was halt vielleicht ein bisschen weh tut, aber das
man regelmäßig machen muss,
wie sie Zähne putzen, keine Ahnung, dann geht das.
Genau,
also das ist halt so
die Idee dahinter und dann
genau, wie das dann
auf die Maschinen kommt,
ja genau, so große Systeme mit
Low Balancern oder so, das ist ja
auch schon dann etwas, ja, da würde man
eben Ansible nehmen oder so und dann
das hätte ein Inventory von den ganzen Maschinen
und dann könnte man irgendwie so Rolling
Updates machen oder so.
Ja.
Also für so private
kleine Geschichten. Also was ich
momentan tatsächlich irgendwie selbst
am liebsten mache,
ist, ich benutze tatsächlich
Docker.
Also aus Entwicklersicht hat das einige
Vorteile. Ich habe früher auch mal
das dann irgendwie mit Vagrant gemacht
und dann immer komplette Maschinen
hochgezogen und so. Aber
das dauert halt alles so ewig, wenn man
irgendwas ändern möchte an der Maschine, dann muss man
da irgendwie, dann ist das
gerade wenn man sie dann per Ansible
oder so hochzieht, das ist
alles ziemlich mühselig
und natürlich
ist mir auch klar, dass das irgendwie problematisch ist,
aber bei Docker ist das halt viel, viel schneller.
Da ist die Maschine halt innerhalb
von, ja, sagen wir mal, wenigen Sekunden
da oder noch weniger und
man kann sofort damit was machen.
Klar, wenn man was ändern muss,
dauert es auch ein bisschen länger, aber das ist alles nicht so schlimm
wie das, was man davor hatte.
Und es ist vor allem
robuster halt,
weil es halt die Stände ein bisschen besser
definiert, dass du halt nicht
mit einem Basis-Image anfängst, was du, also gerade
beim Vagrant, da sind wir auch noch
ein bisschen dran. Wir haben für uns
ja, wir haben ja NixOS als
Linux-Derivat,
was dieses ganze Thema wie
manage ich Runtimes sauber
gelöst hat. Da ist eher die Frage,
wie kann ich dann da drinnen wieder unsauber rumpanken.
Und dann haben wir da halt auch so
Vagrant-Images und die sind schon relativ gute
Zustände immer als Basis-Images, dass ich weiß,
wo ich bin und aber tatsächlich
NixOS kann halt auch
solche, installier jetzt mal bitte
x, y, z, das haben die in dieser Sprache
drinnen schon verwusst, das ist eigentlich eine schöne Alternative
zu dem, wie Docker das macht.
Aber auch das
ist tatsächlich immer wieder so relativ
fragil, weil es dann doch noch darauf ankommt,
wie das Vagrant genau aussieht und
nervt gerade auch noch ein bisschen.
An der Stelle ist das
Docker-Konzept halt zumindest so,
dass man halt relativ gut produktiv sein kann.
Ja.
Ja, und vor allen Dingen, also es hat
halt, also was ich, ich kann ja einfach vielleicht,
also ich mach das so,
ist auch interessant, weil es vielleicht so ein bisschen
Der umgekehrte Ansatz ist zudem, man macht halt ein Skript, das man irgendwie remote direkt vielleicht schon sogar entwickelt, um sofort sehen zu können, ob das irgendwie funktioniert oder nicht. Wenn man jetzt irgendwie so eine Webseite zusammenbaut, dann hat man da enorm viel komische Abhängigkeiten auch noch zu anderen Systemen hin, blöderweise.
Das ist auch so etwas, was ich irgendwie so ein bisschen schrecklich finde, aber wo ich nicht genau weiß, wie man das irgendwie besser hinkriegt. Und ich fange tatsächlich oft so an, selbst für kleine Geschichten, dass ich halt so ein Cookie-Cutter-Django-Template oder so halt ausführe und dann erstmal so ein riesen Ding da ausrolle.
Also ein selbst geschriebenes Template?
Nein, nein, ich nehme das, das, das, irgendwie, ja, kriegt man mal nach Django-Cookie-Krater, googelt, ist von den Leuten, die halt auch das Two-Scoops-of-Django-Buch geschrieben haben und, ja, das macht dann halt schon eine ganze Menge Sachen, unter anderem halt, legt es halt auch schon so Docker-Config-Files, also Docker-Compose-YAML-Files an
ein großer Vorteil
jetzt, wenn man damit arbeitet, ist, man kann es sofort hochfahren,
kann Dinge
damit tun und vor allen Dingen kann man halt auch lokal
das Produktionssystem halt mal
hochfahren und dann gucken, weil
oft, also es wäre natürlich schön, wenn das
identisch wäre, aber
lässt sich oft nicht
so wirklich komplett
durchziehen und dann hat man schon Unterschiede
zwischen lokalem Entwicklungssystem,
also wenn ich jetzt irgendwas...
Hightech-Mac gegen 486er schmeißen?
Also genau, und dann auf dem Server sieht es dann doch anders aus.
Also die Unterschiede sind halt vor allen Dingen sowas wie,
naja, wenn ich halt lokal entwickle,
dann ist das halt eher das lokale Filesystem.
Einfach, weil ich auch lokal nicht so toll ans Netz angebunden bin
und produktiv ist es dann halt irgendwie Google Computer Engine
oder AWS oder S3 Buckets oder sowas.
Und das verhält sich dann manchmal doch subtil anders
oder auch ganz, ganz krass anders.
Und dann treten halt Dinge auf, die man halt lokal einfach nicht sieht. Da funktioniert das Problem los. Und dann, naja, wenn man das aber trotzdem mal lokal reproduzieren möchte, weil das halt auch blöd ist, man kann ja auch irgendwie das Debug-Flag sozusagen auf Produktionsmaschinen nicht einschalten, weil ansonsten reicht man halt diverse Sachen, die eigentlich vertraulich bleiben sollten nach außen.
Daher ist das halt schon mal, aber das ist halt alles mit dabei und das ist dann natürlich eine ganz, ganz schöne Geschichte, dass es da halt eben über Docker gelöst. Wenn ich das anders machen wollte, wäre das relativ schwierig. Also über Vagrant wäre das dann schon so, geht wahrscheinlich auch noch irgendwie, aber dann wird es halt schon sehr, sehr schwergewichtig.
ja, natürlich funktioniert das
auch nur, solange die Systeme halbwegs
klein sind, wenn das dann irgendwie
sehr, sehr viele unterschiedliche
Services werden. Also bei mir ist es halt meistens
nur in Postgres-Datenbank,
es ist irgendwie ein Riddes, es ist irgendwie vielleicht ein bisschen
Celery oder so.
Das ist sozusagen
der Applikations-Server
vorne dran meistens, den ich
meistens benutze.
Der Web-Server
einfach vorne dran, der halt
so ein Reverse-Proxy auch ist für
die Applikationsserver. Applikationsserver
ist Unicorn meistens.
Und
ja, das sind halt vier, fünf
unterschiedliche Container-Typen, das war's.
Und das kann man auch lokal
problemlos noch handeln.
Eigentlich.
Genau, und
ja, meistens
mache ich das dann einfach so, dass
ich
habe halt so Skripte,
die, also ich habe
zum Beispiel einen Deploy-Skript, mit dem ich
das halt, also ich mach das dann halt
per SSH und
benutze aber auch Python dafür, damit ich einfach
nur Python-Skripte ausführen muss.
Das lockt sich halt dann irgendwie
auf einer Produktionsmaschine ein oder so,
checkt halt den Code aus, baut
irgendwelche Container neu und startet dann alles
neu oder so. Das ist halt so
das, was es an der Stelle
macht und dann halt auch noch irgendwelche Skripte, die halt
lokal und produktiv
Systeme komplett abgleichen, also
Datenbank-Backups ziehen, das
kopieren, irgendwie die
vielleicht Daten, die aus
irgendwelchen Buckets benötigt werden, ziehen
und synchronisieren.
Und das funktioniert für mich
eigentlich ganz gut.
Hat halt so ein bisschen das Problem, dass ich jetzt
auf dem Server sozusagen auch
Docker laufen lassen muss, was
natürlich so ein bisschen ätzend ist.
Aber da komme ich
natürlich nicht so wirklich drum rum, weil wenn ich das
lokal genauso nachstellen
können möchte, wie es halt produktiv läuft,
dann muss ich das halt so machen,
weil ich kann ja den Produktionsverwahr nicht,
also wenn das jetzt halt
irgendwie, keine Ahnung, das ist halt
wahrscheinlich irgendein Debian Stable
oder sonst irgendwas, das kriege ich ja lokal
irgendwie nur schwer reproduziert,
irgendwie in all der,
also ja, außer wiederum mit Vagrant und
Ansible oder so, aber ja.
Ich meine, das ist halt
ein ungelöstes Problem, so ein bisschen da dran.
Was mir immer
negativ auffällt, ist, dass die TechSecs
immer größer werden, ohne dass wir die eigentlichen Probleme
gelöst haben.
Also dieses, wenn du jetzt halt
einen Docker hast, dann hast du jetzt sozusagen das ganze Thema,
ja, die Security-Updates für dein
Zeug musst du halt selber machen.
Du musst halt das Basis-Image
nachziehen, musst halt hoffen,
also du kannst es unterschiedlich machen, du kannst es,
es gibt welche, es gibt Leute, die machen das
irgendwie so, dass sie sagen, okay,
da, wo ich das Docker-Image betreibe,
rebuilde
ich den Container
jeden Tag nochmal
in dem ich halt noch einen Layer drüber jage,
der sagt, Upget, Upgrade, Upget,
Upgrade.
Ja, genau, so mache ich das auch. Das habe ich ja auch
da drin sozusagen in meinem Docker-File
und ich habe halt irgendwie, ich mache das dann
Build No Cache und dann muss das halt nochmal neu
gebaut werden alles, ja. Ja, genau.
Aber das ist halt, ich finde das halt so von der,
von dem konzeptionellen Layering
eher,
sagen wir mal, holzklasse. Ja, ja.
Die,
die,
das andere, was du meintest
von wegen Produktiv-Server und dem Debug, das ist halt
spannend, weil du kannst dir
ja natürlich schon
das über einen Loadbalancer zum Beispiel aussteuern.
Also ich mache sowas gerne mal, wenn es wirklich völlig
abstruse Sachen sind, die halt
auch zum Beispiel eben temporal
davon abhängen,
dass momentan im Internet
irgendwas komisch ist.
Wir hatten zum Beispiel mal ein Problem, dass
Der Satz war super.
Ja, wir hatten zum Beispiel mal das Problem, dass Leute bei uns nicht deployen konnten und die kamen an und meinten, bei uns im Netzwerk wäre irgendwas kaputt, weil GitHub geht nicht mehr.
So, und dann gehst du halt irgendwie auf die Suche und dann stellst du irgendwann fest...
Oh, GitHub offline.
Nee, GitHub ist online.
Geht bei uns im RZ aber nur jedes zweite Mal.
So, also damit bist du schon mal in so einer Art von Problem, die du halt nicht lokal nachstellen kannst.
Und das muss halt nicht GitHub sein, das kann halt auch irgendwas anderes sein.
Und da haben wir damals festgestellt, dass GitHub halt über Fastly ausliefert.
Und unser RZ sitzt netztypologisch so genau in der Mitte zwischen Amsterdam und Frankfurt.
Das sind so zwei der großen Netzknoten in Europa.
Und da war es halt so, dass eben...
Er kann sich entscheiden, wen er will.
Ja, genau. Es ist manchmal nach Frankfurt und manchmal nach Amsterdam gegangen zu einem Fastly-Knoten.
Und das Problem war, der Fasti-Knoten in Frankfurt war anders konfiguriert als der in Amsterdam
und hat auf ein ganz bestimmtes TCP-Flag, was bei uns gesetzt war, allergisch reagiert.
Out.
Habt ihr das Schiebel mitgesetzt?
Naja, ich weiß ja gar nicht mehr, welches das war.
Und es mündete halt darin, das ist ja auch die Frage von der Internetarchitektur mit diesen Greyboxes, es mündete halt am Ende darin, dass wir halt irgendwo im Fasti-Support aufgeschlagen sind, um ihnen klarzumachen, dass sie dort ein Netzkonfigurationsproblem haben.
Das ist sozusagen so, das ist das
Ops-Ende von diesem Thema von
was gibt es da an Zeug zu debuggen, ja.
Oder eben, wenn halt die Webseite
steht still, warum? Und dann
gehst halt her und stracest den Python-Prozess
um festzustellen, guck mal,
der macht dauernd Sockets zu Twitter auf, aber die
gehen nie wieder zu, ich glaube, die bleiben hängen.
Dann stellst du dir fest, ah, Twitter ist die API gerade kaputt.
Und
das ist halt, da sind, da ist
Docker an der Stelle für uns manchmal so ein,
so ein, ja.
Kann man nicht gut reingucken, das stimmt, ja.
kann man nicht gut reingucken und
das Tooling ist, also man kann
ja schon, also man kann
ja schon, man sieht ja die Subprozesse typischerweise
im Host
beziehungsweise bei uns wird das
Docker-Schwester halt erstmal eine VM und dann
läuft die VM halt irgendwo auf so einer Infrastruktur
und du kannst ja die Subprozesse schon
sehen, das heißt du kannst deine Tools
wie ein S-Trace da von außen drauf jagen,
aber es ist so ein bisschen, ah, dann schnell
zu suchen, wo ist denn jetzt das Dateisystem von dem Ding,
wo ist denn der Socket, wo ist denn das, das
ist halt alles viel, viel verdröselt
und
ja, was bei uns
häufiger passiert vom Workflow ist, dass Entwickler tatsächlich
das Zeug erstmal in Docker bauen, das
macht sie produktiv und
wir gehen dann aber wieder her und sagen, super,
das Docker ist jetzt erstmal die Grundlage, auf der wir das
auseinanderreißen.
Dann nehmen wir das alles auseinander und sagen, okay, was
habt ihr denn hier da? Okay, ihr habt irgendwie die
russische Postgres, das ist aber nett, das nehmen wir mal
nicht.
Oder was halt auch manchmal
vorkommt, ist, dass Entwickler sich dann sehr
große Basis-Images bauen,
wo sie dir nachher nicht mehr erklären können,
was davon eigentlich in Benutzung
ist.
Ja, das heißt, da hast du dann halt so, ich kenne das
selber, wir hatten früher so 2004,
2005 rum auch immer mal für irgendwelche
Web-Projekte dann
Hilfspackages geschrieben, die dann
alles konnten, weil das braucht man ja in jedem
Projekt. Das Dumme war nur, wenn du
das jemals aktualisieren wolltest, musstest du alle
deine Projekte anfassen,
weil dir alle von diesem Ding abhängen, wo alles
drin ist. Das war
so ein Nexus an Dependencies
ist immer schwierig.
Und vor allem, wenn du halt implizite Dependencies hast,
die einfach nur von, ja, ich benutze halt das Basis-Image.
Und wenn das aber dann eine Dependency war,
die nie gewollt war, und die schaltet
jemand ab, dann fliegt es dir plötzlich um die Ohren und du weißt
noch nicht mal warum. Da kommen dann teilweise
ganz obskure Fehlermeldungen. Wir hatten das, glaube ich, beim
Thema, da hatte jemand eine Postgres mit
17.000 Extensions
und
unser, also übertriebenermaßen,
das ist schon das dritte alkoholfreie
Bier hier,
die hat dann auch nur das noch quittiert beim Einspielen von einem Dump mit einer völlig obskuren Fehlermeldung,
die auch kein Postgres-Expert mal so richtig lesen konnte, bis irgendwer meinte,
ah, wir benutzen ja noch die Extension, so, ah, okay, alles klar, gut.
Und da merke ich, da ist halt genau diese Klärung dann auch für Ops-Leute,
was ist hier eigentlich im Einsatz, brauche ich das eigentlich?
Wenn du halt immer nur die Weihnachtsbaum-Variante hast mit All Features On,
Dann läuft dir irgendwann weg, dass du keine Handlungsfähigkeit mehr hast, weil du davon ausgehen musst, okay, hier ist alles installiert, kann alles, was hier installiert ist, kann auch noch in Benutzung sein, ich habe keine Ahnung, was ich jetzt tun soll.
Läuft das noch oder kann das weg?
Ja, genau. Und das ist so ein bisschen dieses, wir hatten, ich habe eine Zeit lang für Soapcorp consultet und Benji York, der war auch ein guter Ingenieur da, der hatte so einen Spruch, der hieß, test what you fly, fly what you test.
Und das war nämlich die Frage von, was ist denn die richtige Anzahl von Paketen,
die ich, also egal ob auf Python-Ebene oder Betriebssystem-Ebene oder was auch immer,
in Produktion haben sollte.
Und das ist ein bisschen abseits dessen, was viele für besser halten.
Der sagt halt, naja, natürlich ist die ganze Test-Suite und die Test-Tools auch in der Produktion installiert.
Weil du hast es ja mit der Test-Suite getestet.
Du kannst es ja nicht testen, wie es läuft, wenn die Test-Suite nicht dabei ist.
Du kannst natürlich ein Abstraktionsargument sagen und machen, diese Testsuite ist nicht das Problem. Also ich mache hier gerade diesen Podcast-Move von, das sind nicht die Roboter, die ihr sucht. Aber nichtsdestotrotz hast du eigentlich eine ungetestete Konfiguration in Produktion.
Das Gegenargument dazu
ist immer, oh, du hast den Testcode installiert,
wenn jetzt zufällig jemand den Testcode anträgt
und er dann mit deiner Live-Datenbank redet,
dann ist alles platt.
Aber da muss ich ganz ehrlich sagen, da ist der Pragmatiker
bei mir, ich habe mehr Sachen kaputt
gehen sehen, weil zum Beispiel
ich eine Dependency hatte, auf die ich mich verlassen
habe, die nur um die Ecke über die
Test-Suite kam.
Und dann ging es
draußen nicht mehr, weil die Test-Suite und ihre
Dependency nicht mehr da waren.
Das ist mir schon öfter mal vorgekommen,
das Umgekehrte, dass da aus Versehen
der Testcode aktiviert wird, das habe ich noch nie gehabt.
Noch nie. Und deswegen ist so meine
persönliche Historie, dass ich sage, ich
will halt immer die komplette Umgebung, die
der Entwickler hatte, nicht mehr
und nicht weniger, so gut es geht.
Und deswegen sind so fette Basis-Images
für uns dann immer so ein bisschen so ein
rotes Tuch, weil sich dann
rauszusuchen, was ist da jetzt eigentlich das, was hier benutzt
wird, woraufhin müssen wir,
weil dann kommt ja das Nächste, dann will man das
wie du produktiv und gemütlich auch getunt haben, dass du
sagst, okay, ich hole hier aus den Ressourcen,
die ich habe, das Beste raus.
Wenn da aber irgendwie tausend unbenutzte
Dinge rumgeistern, weißt du gar nicht, was du anfassen
sollst.
Ja.
Das ist, ich meine,
das hat natürlich halt auch einen Vorteil,
wenn man das halt alles schön sauber durchspezifiziert
hat. Ja, dann
weiß man auch, warum man das,
also das macht man dann auch nicht, wenn man es gar nicht braucht.
Während, wenn man einfach ein Image
von irgendwo zieht, dann ist halt da per
Unfall schon ganz viel Zeug drin und man weiß halt gar nicht.
Ja, genau.
Wie gesagt, wir nehmen das ja, wir reißen es auseinander
und wir
versuchen ja so ein Modell zu machen, wo wir
die
ständig
wieder gebrauchten Sachen, wie so ein Postgres
oder ein Webserver, die managen
wir auf eine Art, wo
man dann trotzdem natürlich lokale Config von
einem Projekt reinschießen kann und Entwickler
sehen das im Prinzip auch alles und können sich
auf diesen Maschinen anmelden und
an die Teile ran pieksen, aber
wir bringen da halt diesen ganzen Ballast an Ops-Kram
dann rein und sagen, okay, wie muss ich das
jetzt eigentlich ins Monitoring integrieren, wie muss ich das
dann ins Backup integrieren, wie muss ich das in
Upgrade-Pfade integrieren, wie muss ich
dieser ganze Kram,
dass das halt auch ausdefiniert ist
und eben nicht nur, ja, ich habe dieses Image
genommen, weil da ist halt das Postgres mit dem Plugin drin,
sondern halt, wie
monitore ich jetzt, dass das Ding ab ist, wie mache ich das
Backup, etc.
Das muss man ja mit einem anderen verheiraten und deswegen finde
ich, ist Docker häufig für mich so ein Tool,
das hat die Neigung, wenn man das halt
einfach nur blind Ende-Ende einsetzt,
dann wird es wieder zum Software
über den Zaun werfen.
Ich habe hier was zusammengebaut, du bist bloß
dafür zuständig, dass der Strom läuft
und damit machen wir jetzt gerade so ein bisschen
so einen Kreis zum Anfang.
Dann haben wir wieder das Problem,
die Ops sind die, die es über den Zaun
geworfen kriegen, die sollen machen, dass es nicht
ausgeht und dass der Strom da ist, haben aber
keine Chance zu verstehen, was da drinnen eigentlich
abläuft und ihr eigentlich operatives
Wissen ins Spiel zu bringen.
Ja, ja,
wobei aus meiner Perspektive der Trend,
der da momentan
so ein bisschen nicht da sehe, ist halt,
das ist ja auch das, was einem
dann dadurch ermöglicht wird, wenn man jetzt
quasi so ein System auch lokal
komplett hochziehen kann, dass man halt
eben so AWS
oder Google Computer Engine,
da kriegt man halt irgendwie,
kann man auch per API-Maschinen hochfahren,
dann schmeißt man da die Container drauf
und dann, naja, funktioniert das halt
in einem Durchschnitt mehr oder weniger.
Genau, und da hat man dann schon eine harte Trennung.
Aber sozusagen die Trennung ist halt an der, man bekommt halt Maschine und kann da per Rout und SH drauf.
Aber das ist jetzt auch nicht viel besser als das mit dem FDP und dem PHP.
Ja, genau, das stimmt natürlich auch.
Und dann auf der anderen Seite gibt es dann halt so Dienstleister, so was wie Heroku oder so,
die dann halt schon sehr viel selber betreiben.
Da hat man dann das Problem sozusagen nicht, dass man sich auch um die Datenbank und so selber kümmern muss, sondern man, im Wesentlichen schiebt man da so den Code hin und der läuft dann in der Heroku-Infrastruktur irgendwie.
Auch bei AWS dann?
Wahrscheinlich auch bei AWS.
Es ist AWS, Heroku ist ja nur AWS.
Naja gut, das sind ja auch diese unterschiedlichen Konzepte dann, auf was für Infrastruktur möchte ich aufsetzen, von Infrastructure-as-a-Service, Plattform-as-a-Service zu whatever-as-a-Service.
Da ist halt auch spannend, diese Frage danach, habe ich halt diese Magic-Services im Sinne von die Postgres, ist da irgendwie Magic irgendwo gemanagt?
Das heißt, ich weiß auch gar nicht so richtig, was ist da noch an Sachen drinne. Ich habe dann teilweise auch keinen Überblick, wie sind eigentlich jetzt die Latenzen, wie ist denn der Netzwerkpfad zu diesem Ding.
Bei Heroku kann einem das passieren, wenn man so Add-ons dazu bestellt, dann sind die zwar eine gut integrierte API, die lebt aber irgendwie in einem Rechenzettel am anderen Ende des Erdballs.
Und wenn man dann halt den Datenschutz irgendwie reinholt, ist so ein bisschen die Frage, weißt du wirklich, wo deine Daten gerade sind?
Die sind bei Heroku, okay, das heißt, die sind bei Amazon. Das heißt, die sind bei Amazon in Nordamerika.
Das heißt, ach, da hast du noch die MongoDB geklickt? Ja, nee, dann ist die bei Amazon in da drüben.
Okay, und ich finde halt an der Stelle, es ist halt so verlockend, sich so Zeug zusammenzuklicken und ich finde das cool zum Experimentieren und was mir so ein bisschen, aber dieser Übergang zu, wann muss man mal den Besen rausholen und dieses Experimentieren ordentlich aufräumen und kriegt man das dann überhaupt noch eingefangen oder ist es dann wirklich eigentlich aus der Hand?
Und dieses große Argument von, naja, Amazon wird irgendwann der einzige RZ-Betreiber der Welt sein, das widerstrebt mir so massiv, weil das ist aus einem Gedanken der auch informationellen Selbstbestimmung und diesem macht Dinge selber und macht die Fehlerdomänen auch kleiner. Also Amazon wird ja am Ende zu einer einzigen großen Fehlerdomäne.
Ja, ja, da ist ja auch, das ist auch gar nicht so lange her, dass da, irgendwo war das in das Virginia-Rechenzentrum oder so, war weg und dann war irgendwie so, na gut, vielleicht ist es auch schon fast, ist schon zwei Jahre her oder so, aber da erinnere ich mich noch gut, da war 80% des Webs war plötzlich irgendwie tot, weil das, weil da ein Rechenzentrum wegen einem Blitzschlag nicht mehr funktioniert hat.
Witzigerweise auch die eigene Amazon-Statusseite, also die AWS-Statusseite, die sagen sollte, ob das noch alles funktioniert oder nicht, die war auch kaputt.
Nee, nee, nee, das war subtiler, das war viel subtiler.
Ach so, okay.
Die Amazon-Statusseite ging und hat grün angezeigt, weil das grüne Icon war in der Statusseiten-Software hart kodiert und das rote Icon haben sie aber aus dem S3 gezogen und das S3 war kaputt und dann blieb das grüne Icon da stehen.
Ach so, ja, okay.
Das ist schön.
Da hatte ich ja nicht mal ein anderes Tennis gehabt.
Nur grüne Lämpchen, bitte.
Ja, genau.
Ich merke so, die Themen, die mich halt umtreiben,
deswegen habe ich ja vorhin auch mit der Komplexität so ausgeholt,
ist halt die Frage,
und damit sind wir auch ins DevOps eingestiegen,
wie macht man aber, dass die Leute halt besser zusammenarbeiten können
und dass man diesen Know-how-Transfer halt hinkriegt.
Wie macht man sich happy, happy.
Wie macht man sich happy, happy, happy.
Ja, genau.
weil, das war unsere Schleife zur Digitalisierung,
diese Erkenntnisse finden ja an vielen Stellen im Kleinen statt
und das wird jetzt momentan so,
es hat so Entwicklungen,
das wird mit so Pinselstrichen werden,
ganze Systemarchitekturen,
ganz breit mal auf irgendeinem Gebiet geschrieben
und dass aber die eigentlichen Schwierigkeiten
und das wissen die Ops-Leute von den großen Anbietern
wie von AWS und von Google,
wenn man sich die Google System Reliability Engineering Dokumente anguckt,
und so, die wissen, der Teufel
liegt im Detail. Du kannst es halt nicht
sagen mit, naja, ich hab's jetzt halt in der Cloud
und dann ist das halt alles super.
Im Gegenteil, du hast jetzt halt noch eine
Abstraktionsebene mehr und
wir wissen ja alle, also
jedes Problem kann dadurch gelöst werden,
dass ich halt noch ein Layer oben drüber ziehe.
Und
ja, also ich merke so,
für mich sind die Lösungen immer an so Stellen, wo ich
gucke, ich such sie ja eher immer
im Kleinen und an den
etwas nicht so ausgetretenen Pfaden,
um zu gucken, wie kann man das denn so
zurechtschneiden,
dass man mit Entwicklern so einen konstruktiven
Alltag hinkriegt auch an der Stelle.
Weil eben,
jetzt haben wir ja gesagt, diese zwei Rollen,
die etwas diskret sind,
ob es halt eben auch
einen anderen Rhythmus, dass man sagt, okay, wir würden
gerne ein paar Updates ausrollen, wir würden gerne ein paar
alte Versionen sanieren, wir würden gerne ein bisschen
dies und jenes machen, das würde ich gerne unabhängig von dir
können. Ich will das nicht ohne
einen Entwickler können. Ich will nicht einfach nur
sagen, so halt, jetzt updaten wir die MySQL
auf die neuesten Major oder auf die oder das, sondern
ich will da halt eher so ein
vernünftiges Verständnis haben von,
warum sind zum Beispiel welche Komponenten
für einen Entwickler eher so mit Feingefühl
zu updaten, während andere
irgendwie völlig egal sind, die updatest du halt
durch und da geht nie irgendwas kaputt.
Um da dann halt auch mal die Augen
offen halten zu können, was sind denn möglicherweise bessere
andere Tools für bestimmte
Probleme oder wo muss man irgendwie eine Integrationsleistung
noch erbringen oder wo lohnt es sich
aus beiden Perspektiven zu sagen, hey,
würdest du die Anwendung da drüben so ein bisschen umbauen,
dann wäre hier vorne
alles viel einfacher und
es fällt weniger Seiten um.
Naja, ganz herrlicher
Blick auf die ganze Mikroarchitektur.
Ja,
richtig. Ja, im Grunde
brauchst du halt, um ein Projekt
wirklich komplett machen zu können,
brauchst du halt in dem Team, das das Produkt baut,
halt all diese Kompetenzen irgendwie drin.
Ja, das Problem ist ja, deine Teamgröße ist beschränkt.
Ja, das ist dann halt auch das, was einem dann passieren kann, dass man dann irgendwie alles selber macht.
Ja, genau, NEH.
Aber NEH ist halt der Trick,
manchmal geht es beim Neuerfinden des Rades
ja auch nicht darum,
das bessere Rad zu erfinden,
sondern zu verstehen, wie so ein Rad
funktioniert. Also da
muss man halt auch der Maker-Szene an der Stelle
ja noch eine Lanze brechen und sagen,
viel von diesen
großen Architekturen, ob das jetzt Kubernetes
oder halt so diese
Amazon Magic Elastic Services sind,
Die versuchen dich ja zum reinen Konsumenten zu degradieren und sagen, benutze mich einfach, dann ist alles gut. Die kochen und drücken halt auch nur mit Wasser. Also in Amazon, irgendwie hast du nicht gesehen, MySQL ist halt immer noch MySQL, vermutlich noch mit irgendwelchen obskuren Patches drin. Aber das läuft dann auch bloß in einer EC2-Instanz irgendwo. Da ist jetzt nicht irgendwie was groß anders. Der einzige Unterschied ist, du siehst es halt nicht.
Anekdote am Rand, MongoDB hat irgendwie
das, hat irgendwie
Lizenz geändert,
weil ihnen das ein Dorn im Auge war,
dass die ganzen Plattformen jetzt da
irgendwie Geld mit verdienen,
dass sie... Redis, Redis, nicht Mongo, Redis
war es. Ja, aber MongoDB hat das auch irgendwie
gemacht. Auch? Oh, okay.
Und hat sozusagen dann qual Lizenz
Amazon verboten,
irgendwie MongoDB anzubieten,
woraufhin
Amazon irgendwie
einen quasi
komplett kompatibles, eigenes, selbstgeschriebenes
Ding an die Stelle gesetzt hat.
Ja, krass.
Und jetzt kannst du darauf warten, dass
das sich inkompatibel weiterentwickeln
wird, damit die Leute halt nicht mehr in der Lage sind, davon
wegzugehen.
Also dieser Lock-In
an der Stelle ist halt auch
unglaublich.
Und dafür finde ich
halt teilweise dann eben der
klar, bei allem, was
Flexibilität in Richtung
Investkosten, also CapEx versus
Opex und so angeht, ist das alles
super und du musst halt nicht um Erlaubnis
fragen, wobei das halt auch...
CapEx, Opex, ich bin gerade wieder rausgeflogen.
Ja, unternehmerisch,
wenn du halt deine Kosten betrachtest,
dann ist die CapEx, Opex-Trennung
ganz spannend. CapEx bedeutet,
du gibst Geld einmal aus,
um ein Gerät zu kaufen,
sogenannte Capital Expenditure,
also Investitionsgüter.
Da wird der Wert
des Gutes, also wenn du zum Beispiel ein Auto
kaufst, dann hast du deine da 30.000 Euro,
50.000 Euro, die du ausgegeben hast, die gehen
auf einmal von deinem Konto runter.
Jetzt bin ich, glaube ich, dran, dass du
baust es dann so ein bisschen und guckst,
wie du es... Genau, du brauchst
das, der Wert des Autos wird wieder in deinen Büchern
geschrieben, da ist sozusagen das Geld nicht
einfach nur weg, sondern du hast ja einen Gegenwert dafür bekommen.
Dafür musst du es halt abschreiben,
das hat eine bestimmte steuerliche Behandlung etc.
Und OPEX ist das sogenannte
Operative Expenditure,
das sind sowas wie Miete.
das Geld ist halt in dem Moment weg,
dafür hast du dir aber erspart,
einmalig große Investitionen zu tätigen
und machst halt viele kleine,
beziehungsweise viele kleine Ausgaben, die sind steuerlich
halt sofort gültig und
Amazon erlaubt dir halt, dass du, wo du
früher mal Millionen in der RZ stecken musstest,
was du dann runterwohnen musst,
was dann entsorgt werden muss, etc.,
kannst du halt ein reines OPEX draus
machen, hast halt auch kurze Kündigungsfristen
und so, das ist halt, das
macht es wirtschaftlich extrem attraktiv an den Stellen.
Das ist ja super, weil du erst mal
auf die Idee kommst, irgendwie die Kosten
selber zu investieren.
Ja, genau. Ich glaube, Netflix hatte das dann irgendwann auch mal
gemacht. Netflix hat jetzt auch wieder eigene Adsets mit
im Mix, weil sie gesagt haben, auf Dauer ist
Amazon halt zu teuer. Also Amazon ist ja nicht billig
an der Stelle. Du kannst natürlich viel
Sachen optimieren, aber da ist
so für mich als Person auch
in der ganzen Komplexität, die Amazon selber mitbringt,
ist mir dann einfach
teilweise die Lebenszeit zu schade.
Wenn ich dann höre,
es gibt Leute, die bezahle ich dafür, um bei Amazon
um weniger zu betalen, denke ich mir so, jetzt
reizt es mir.
Ja.
Genau.
Ja, da haben wir
jetzt quasi ja die Kurven alle wieder zum
Ende gekriegt. Alle losen Endpunkte wieder zusammen.
Genau. Das ist ja die Aufgabe,
die der Admin dann ja hat.
Alles zusammenhängen, der Operator.
Fix it twice.
Irgendwann mal hatte ich mal so ein Obzeichnen zum
ERC-Channel.
Wollte ich gerade auch loswerden.
Ja, schön, dass ihr
wieder so schön viel erzählt habe. Ich glaube, das war die
Folge, in der Jochen am wenigsten gesagt hat.
Bisher. Also so im Vergleich jetzt
zu unserem Gast. Ich nehme das jetzt nicht als Ehre,
weil das ist mein Fluch.
Ja, großartig.
Das ist ja auch beim Zuhören
sehr interessant. Ja, genau.
Das hat mega Spaß gemacht und wieder ganz viel gelernt.
Ich hoffe, euch hat es genauso viel Spaß
gemacht. Vielleicht, ich weiß nicht, ob wir uns entschuldigen müssen
für die Voice-Qualität diesmal oder ob das
genauso gut geworden ist wie sonst.
Ja. Schreibt uns das in die Kommentare,
falls ihr noch nicht wusstet, wir kriegen jetzt Kommentare
bei uns. Ja, ich habe die letzte
Folge heute mal angehört.
Oh, ja. Ja, genau. Da ging es um die Kommentare,
genau. Ich habe auch gesehen, es gab einen sehr guten Kommentar.
Ah, ja.
Ja.
Ja, das war irgendwas, was? Feedback?
Hallo at peisenpodcast.de
Jo. Jo.
Ich glaube, für heute sind wir sonst weit durch, oder?
Wir sind auch schon relativ lang dran, ja.
Ja, super, Christian, dass du da warst heute. Das war echt toll.
Alles gut. Sehr gerne, jederzeit wieder.
Alles klar, ja dann.
Okay, bis zum nächsten Mal. Ja, bis zum nächsten Mal.
Tschüss. Tschüss.