Ja, hallihallo, herzlich willkommen zum Python-Podcast.
Heute haben wir ein Jubiläum und hier haben wir die zehnte Episode.
Das ist ja hervorragend.
Cool, ne?
Hurra!
Zehn Stück schon geschaffen.
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!
Ich sitze, ihr sitzt im Garten.
Das wird da gar nicht so angehört.
Ja.
Ah, okay.
Ich gucke in meinem Garten.
Ich sitze in meinem Homeoffice.
Ich sitze in der Nähe von Stuttgart.
Ah, okay.
Das ist eine ganz schöne Remote-Verbindung hier von Düsseldorf nach Stuttgart durch die
heimische Republik.
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 sie sehen und so.
Und dann, genau, muss man da auch noch Dinge tun, damit das geht.
Und ja.
Ja, so ein Zirkus.
Genau.
Dann.
Danke.
Ja, genau.
Vielleicht ein bisschen.
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.
Ja, 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 erster 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 der Soap bei der Firma
irgendwie beschäftigt
Soap hat damals
tatsächlich eine ganze Zeit lang die Python Labs
bezahlt, die waren
komplett von der Soap über
2-3 Jahre bezahlt worden
So mit Barry Warsaw, der
das Mailman macht und
diversen anderen Leuten
Genau, ne 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
Serverbetrieb nebenbei und
die Firma wo ich jetzt bin, die
verdient, also die ist ja jetzt auch meine Brötchen
aber die lassen wir jetzt hier einfach mal
fröhlich außen vor, weil wir keine Werbung machen
Ja, also bei der Python Software Foundation bist du noch
das hat mich noch ein bisschen interessiert, was
was ihr denn da noch so macht, vielleicht kannst du die noch mal
kurz so ins Spiel bringen und vorstellen
Also 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
PyDelta 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 unter das 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 sei 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
die
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 und deswegen haben wir von Python
Softwareverband 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, Diversität,
zum Thema
Frauen in der Informatik ist in Python
eh so ein großes Feld, die PyCon
US war eine der ersten Konferenzen,
die über 30% Frauenbeteiligung sowohl
an den Teilnehmern als auch bei den
Vortragenden hatte
und unter diesem Rahmen gibt es
diesen 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 mit
bei einem Workshop in die Hand drücken.
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
aber halt, findet ihr in den Shownotes.
Ja, klar.
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 Jungle-Coin-Sponsorung.
Da gibt es dann irgendwie 1000 Euro einmal glatt, um
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
Arbeitsauswahl, 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 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 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 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 klingt echt interessant.
Bestimmt noch ein paar Interessenten, die
das schätzen müssten. Genau, definitiv.
Also gerade bei den
Entwicklungssponsorings
ist die Soap-Plone-Welt
irgendwie sehr stark, weil die halt in der ganzen
Vereins-Community sehr stark
vertreten ist. Die machen halt viel
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.
Nee, 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.
Das ist 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, was 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 Python 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 Papier kriegt, über einen großen Teich
schiebt. Genau.
Eine cool kurze Leitung, also
falls ihr Ideen habt, meldet euch da direkt,
können natürlich auch das alles. 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
und, aber im Grunde ist das immer
so ein Problem, dass halt Software, die
irgendwie wichtige Infrastruktur für ganz viele
Projekte ist, dann halt
irgendwie so, wo dann, naja, vielleicht so,
also bei Django ist es so, dass da, 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
gehandelt werden und so, also, ja.
Ich meine, 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 diese, wie ich
an dem Begriff Digitalisierung
irgendwie
einen Griff, also wie ich da irgendwie einen Griff dran kriege
ohne
Blablabla
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
Software-Lö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. Ja, das ist aber doch schon wieder
so technisches Detailwissen,
das hat der meiste normale Vorstand wahrscheinlich
gar nicht mehr auf dem Schirm. Der denkt
dann so, ja, ach, jetzt Geld ausgeben für Software, die wir
gar nicht brauchen, also wir kaufen ja
nicht, warum? Also, ist ja umsonst.
Genau. Ja, ja, ja, genau, aber
ich habe 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, so was
wie Marc Andreessen mit Software
eats the world, ja, das heißt
alles wird irgendwie Software sein.
In der positiven
Variante bedeutet das, Software
ist als so Augmentierungshilfsmittel
ständig dabei, ja,
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 und 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, sagt, wir machen jetzt irgendwas mit
Digitalisierung, dann klingt es
in meinen Ohren so, wie der Vorstand kommt,
daher und sagt, wir stellen jetzt
die, wir stellen das Faxgerät ab,
nee, wir stellen die
Unternehmenssprache, als Metapher,
wir stellen die Unternehmenssprache von
Deutsch auf Englisch um und
um das richtig hinzukriegen, haben wir jetzt
einen Übersetzer und zwei Wörterbücher angeschafft.
Ja.
So ungefähr ist es auch, wir wollen
digitalisieren, deswegen kaufen wir jetzt mehr Software
ein oder so und das aber
ja ein Unternehmen, das im Prinzip wirklich atmen
muss und ich trage da momentan
viel mit mir rum und das ist jetzt extrem Python
spezifisch, aber echt
interessant, also ja.
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 oben
im Urlaub waren, hat man halt dann die
Netscape-Web-Server
ersetzt durch Linux-Web-Server 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 jetzt immer noch
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.
Aber 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 raus 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 denn 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ähl-
Liste
zusammenzuklicken, 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 ein Excel-Katze,
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 war halt
super glücklich, weil die so viele Themen aus 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.
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, dass
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
und 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. Und 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 müsste sich doch eigentlich,
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 im
Bauprojekt an der Backe, weil ich ein privates Haus baue,
und da fliegen natürlich tausend Excel-Tabellen rum,
und 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 so 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
eine Formel drüber zu jagen, das geht doch 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
Schulens 1 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 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, ne, 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, sondern damit das... Die müssen
halt auch sozusagen verstehen, wie das, was wir 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, also reingeboren
wirst, dass das funktioniert, sondern
ich glaube, du musst tatsächlich da zur Perspektive
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 IOS,
weil bisher...
Wir können es natürlich sozusagen
Opa erzählt vom Krieg spielen,
die...
Chat der Mark, Opa erzählt vom Krieg. Okay, warte mal,
ich mach das. Ja, genau.
Das ist mir vorgeworfen worden,
nein, das ist mir nicht vorgeworfen worden, aber es ist irgendwie mit
einem zwinkernden Auge auf dem PyCamp in Köln
konfrontiert worden, wo ich
halt auch meinte, guck mal, die Historie,
ging es um irgendein Stück Technik, wo ich nochmal irgendwie
nachgezeichnet habe, wie das über die letzten 15 Jahre halt
entstanden ist und ich bin jetzt Mitte 30
und werde dann halt von Leuten, die gerade im
Studium stecken, angeguckt mit Opa erzählt vom Krieg.
Ja, ja.
Und es ist aber witzig, weil, klar, wir haben
uns, 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 ja sagen muss, es gab
halt nie dort eine Trennung zwischen
Konsument und Produzent.
Ja, 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, wo
also von Neumann-Maschine,
Daten und
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 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
und ich sehe aber tatsächlich, dass das
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
naja, 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, ja.
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 hier
registrieren muss bei Apple und so, ja.
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 du erwartest, 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 richtig, genau.
Ich bin nicht Hunger, ja.
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 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 da alles für Fragen gibt.
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 Preisen 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.
Ich habe Kinder.
Ganz gute Entschuldigung.
Immer.
Was ich da jetzt mittlerweile
häufig mache, ist,
die laden ja meistens auf YouTube
und es gibt in meinem Podcast-Player
irgendwie so ein Zeit-Loading-Share-Sheet-Extension-Dings
für iOS und dann sage ich
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 angenehm, wobei
man dann halt auch merkt, dass die
Audio-Qualitä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 so ein bisschen
Informationen weg, also ganz toll ist es nicht.
Aber seitdem höre ich mehr
Talks, weil es ansonsten
die Zeit irgendwie vom 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 Schwäne
und ja,
als die zum ersten Mal jemand gesehen hat,
dann war sozusagen diese Theorie,
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,
sehr schlecht vorhersagen.
Und das, ja, solche Ereignisse
gibt es halt nicht nur, 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 irgendwelchen Dingen gelebt haben,
so ein schwarzer
Schwan, der aufgetreten ist und dann plötzlich irgendwie 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-Pro-Ruhestand geschickt haben
und
was 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 der 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 ganzen Konsumenten, der ganze Konsumentenmarkt
halt auf irgendwelchen
ja, 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 damit 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
Ja, wobei,
was mir da mehr durch den Kopf geht,
ist, dass ich glaube, wir werden dann
eher sehen, dass es noch
und Jochen unterhalten sich über die Programmiersprache Python
und Jochen unterhalten sich über die Programmiersprake Python
und will mich halt auf bestimmte Funktionen, bestimmte Sachen, die ich entwickeln möchte, halt konzentrieren.
Und aus einer Obstperspektive hast du aber eher das Thema, dass du eben reaktiv, auch Echtzeitreaktiv 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 Obstsachen mache,
weil Obstsachen sind Dinge, die können gerne mehrere Stunden dauern, wo du immer mal nochmal hingucken musst.
Und dann die grüne und dann bringt die blaue die ganze Zeit, dann oh oh, dann kommt jetzt der Bruder auf.
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 Obst ist, aber dass du halt zum Beispiel weißt,
das sind unterschiedliche Zuständigkeiten und ich muss mir das halt auch unterschiedlich zurechtlegen.
Und dann 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 Fortmantur wieder zusammen klatscht, bedeutet es halt nur,
die beiden müssen trotzdem in einem ständigen Austausch miteinander stehen,
in einem 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 Entwicklungen, es kann man in vier Sachen,
also auf der einen Seite willst du operatives Wissen in Richtung Entwickler bei Projektbeginn haben,
a la, okay, was wollten ihr machen, was wollten ihr für Tools nehmen,
ah, könnt ihr vielleicht statt der MySQL lieber eine Postgres nehmen,
könnt ihr vielleicht, wofür nehmt ihr den Memcache, komm, lindet 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.
Aber anyway, die war zumindest mein Entwickleranspruch immer.
Umgekehrt möchte ich, dass Entwickler wissen, 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 rechnen die denn 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,
dann vermeide, 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 Ops 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-Core,
Root-Core-Analysis oder so erschlagen wollen, da kommt immer eins, Root-Core-Analysis.
Das muss ich einfach nochmal kurz erklären, das sind einige Hörer, die sind genauso doof wie ich und die wissen nicht, was das ist.
Die Wurzel-Grund-Analyse.
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 irgendwer, hat die Putzfrau gerade irgendwie den Server ausgesteckt und die...
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-Core-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.
Also die Praktiken, die halt heute relevant sind.
Ich kann nicht alle Praktiken, die es jemals gab, aufaddieren.
So wird aber dieser analytische Ansatz gemacht mit
wir machen jedes Mal, wenn was schief geht, eine Root-Core-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 aus dem Ops-Bereich.
Gibt es noch die, erkläre ich dann auch gleich gerne,
Meantime-Between-Failure und die Meantime-to-Recovery.
Und Dominik, sagst du bitte, dass ich es erklären soll?
Ja, ja, du müsstest 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, ja, genau, genau, genau, genau, genau.
Und 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 hatte 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,
und einen vernünftigen Loadbalancer, dann denke ich mir so,
klar, die kann jede Nacht einmal abstürzen, das 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 Stack Trace.
Hm.
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 haben wir nochmal so eine ganz doofe Frage wieder.
Was ist denn jetzt eigentlich der Unterschied zu einem Administrator dann?
Ich habe keine Ahnung, Namen sind schade drauf.
Das weiß ich nicht.
Naja, genau, ich glaube, ob es ist nochmal ein bisschen älter,
irgendwie wurden teilweise auch OPs genannt, was ist OPs 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 bist du da gerade, Christian?
Ich sitze auf einem schönen Bürostuhl.
Ja, also auch da wieder, ich rede jetzt erstmal wieder zur Komplexität rüber.
Menschen haben halt unterschiedliche Facetten, ja.
Also Leute in so eine eindimensionale Perspektive zu schieben,
macht den Menschen halt eher weniger Spaß.
Ja.
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 ihren,
äh, in ihrem Alltag zu erlauben, ja, total wichtig.
Ähm, ein Operator stand tatsächlich, ist der ältere Begriff,
der stammt dann wirklich schon aus der, aus der, aus dem, äh,
ja, ich weiß nicht, Zweiter Weltkrieg.
Aus dem Tiefen der Matrix, oder?
Nee, Industrialisierung tatsächlich schon.
Also du hast halt, das war dann eher so Engineering versus Operator.
Ähm, du hast halt Leute, die entwerfen eine Maschine
und Leute, die die Maschine im Tagesbetrieb am Laufen halten.
Ähm, 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.
Äh, der kann aber in dem Moment überlegen,
was gerade die Konstruktionsprinzipien sind.
Und der andere weiß halt, ja, komm, das knarzt jeden Dienstag,
da rufe ich jetzt nicht an.
Ja, der Ingenieur, dem würde irgendwie der Hut platzen,
fand, das darf doch nicht knarzen.
Und der andere so, das knarzt seit 20 Jahren, das war wurscht.
Ähm, 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 auch so eine Systemmanagement,
Systemkonfigurationssicht als ein Ingenieur tätig war.
Also, ü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 Serverseite dann widerspiegelt.
Ja, ja, ich meine,
der Ops, da hat man das ja sowieso dann schon im Namen irgendwie mit drin.
Ähm, 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,
ich war auch eine Zeit lang Admin
und ich bin auch im Rechnen,
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, ja,
Administration und die ganzen Infrastruktur-Kramen,
Rechenzentrumsbetrieb,
das wird halt daran gemessen,
dass es halt nicht kaputt geht, sozusagen.
Also, ja,
also, ich meine,
dass der Strom da ist,
das feiert niemand,
aber wenn er ausfällt, ist halt blöd.
Also, 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,
dass,
na ja, 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,
jetzt,
wenn man dann eine klare Trennung
zwischen den beiden Geschichten hat,
dann ist es,
sind halt sozusagen
die optimalen Strategien
möglicherweise für Entwickler halt
möglichst kaputtes Zeug einfach raus,
dann wird es egal.
Die werden das schon irgendwie am Laufen halten.
Vielleicht steht ja nicht mein Name dran
oder keiner kann das.
Genau.
Weil, ich meine,
ich werde halt nicht dafür bestraft,
sozusagen, wenn es kaputt geht.
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...
Ja, also solche neuen modischen Scheiße
machen wir nicht.
Ja.
Ich meine,
die,
das ist halt auch da wieder,
zum einen spannend,
mein DevOps ist im Prinzip in der Lage,
dort diese Anreize einmal umzukehren.
Im Prinzip kannst du
dann halt nämlich sagen,
Devs, ihr, also,
erst mal messen ist zwar eine gute Sache,
aber auch da,
Menschen haben halt so den Vorteil,
die können so Systeme gut austricksen.
Ja.
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 daraufhin
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.
Beziehungsweise nicht das Rechenzentrum,
sondern wie stabil halt die Anwendung draußen ist.
Und dann kriegst du nämlich plötzlich
eine ganz andere Bewegung da rein.
Das wird auf jeden Fall dann dynamisch.
Dann jagen nämlich die Devs den Admin
durchs Haus,
wenn das so 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
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 tatsächlich was,
wo DevOps eigentlich sich ganz gut positioniert
an der Stelle.
Da sind auch viele Tools
eigentlich gut drauf 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?
Ja.
Achso.
Ich meine,
wenn man jetzt über komplette Systeme redet,
da ist es ja so,
dass da gibt es halt so
diverses Text,
die man verwenden kann,
um halt so komplette Infrastrukturen
aufzuzeigen.
Ich weiß aber nicht,
ob man das,
also sowas wie Ansible
oder halt Solstack
oder OpenStack
oder was auch immer.
Tja.
Und einiges davon ist ja auch
in Python tatsächlich geschrieben.
Ja, das wäre möglicherweise,
dass das halt auch so einfällt,
wo Python relativ stark ist.
Ich glaube,
viele der,
es gibt irgendwie noch
ChefPuppet,
das ist...
ChefPuppet?
Ja,
das ist zwar unterschiedlich hier,
aber es gibt auch
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 Ansible ist definitiv auch Python.
Ist auch Python
und OpenStack ist auch Python.
Also...
Aber ja,
OpenStack ist wahrscheinlich
alles mögliche.
Ja.
Was ist denn sowas drin?
Also für jemanden,
der es jetzt noch nie gehört hat,
was wäre jetzt in so einem Ansible
denn jetzt drin?
Ich würde es vielleicht tatsächlich
nochmal von einem anderen Ende her holen,
weil Ansible ist sozusagen schon
ziemlich weit weg,
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, das 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,
A, um das 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, wie mache ich das
auf meinem Entwicklungssystem,
wie mache ich das auf meinem
Staging-System, wie mache ich das
dann draußen in der Produktion.
Da kann man so die unterschiedlichen,
das wäre also mindestens mal so zwei Perspektiven,
aus denen man das mal andiskutieren kann.
Ja.
Nee, 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,
anwendig würde ich gerne eine Webseite oder so
bauen und wie kriege ich denn die jetzt,
sozusagen, ja, 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 Gedächtnis-Podcast.
Ein Python 2.7
Gedächtnis-Podcast, so,
zum Jahresausklang.
Aber auch innerhalb von Python 3 sind die
Sprachfeatures nochmal so weiter, dass man halt auch da
zumindest erstmal 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 und 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,
so, oh ja, die will ich unbedingt haben.
Die Spreizung ist sogar schneller als String-Off, ne?
Ja. Das kann sein.
Die, ähm,
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.
Ähm, das ist dann häufig, äh,
damit gekoppelt, dass ich, äh,
bestimmte Versionen von einem Betriebssystem irgendwo habe.
Ähm, genau.
Wenn ich, 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.
Ähm, aber im Prinzip läuft es halt
darauf hinaus, naja, ich habe erstmal die Frage,
welchen Python-Interpreter würde ich gerne haben.
Ich mache es in letzter Zeit so, wenn ich kleinere
Projekte mache und, äh, tatsächlich im Sinne von
mal so Command-Line-Skripte, das ist bei mir relativ
viel dran, ähm, 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 das dann zufällig der Sublime,
ähm, mit einem R-Sync-Plugin,
mache ein einziges
Python-File, und das kann gerne mal
für den Anfang bei der Entwicklung
1000, 2000, 4000 Teilen lang werden,
ähm,
um,
und habe ein R-Sync-Plugin, was mir bei jedem Speichern
das auf 7, 8, 9 Kisten verteilt,
äh, und gebe mir Mühe, dass ich
nichts anderes außer der Standard-Library
benutze.
Mhm. Dann brauche ich mir
nämlich keine Gedanken machen.
Und ich meine,
die Standard-Library hat einen Haufen Kram
drin, ähm, da ist halt,
damit machst du dann keine Web-Entwicklung mit Django,
in dem Moment, aber, äh, du hast...
Interferenz, Interferenz, äh, sorry.
Oh ja, Entschuldigung, ich glaube, das war diesmal, ich,
ah, weg da, halben Meter weggeworfen.
Ähm, lag zu nah am Kabel.
Die, äh,
die Standard-Library bietet ja schon so viele
Sachen, ähm,
von, von JSON zu,
hast du nicht gesehen, typische Dinge,
die dann bei mir relativ schnell dazukommen, als Appendances,
sind dann halt irgendwie Requests, oder
irgendwas in der Art, ähm, aber
ich baue selbst bei mir
die Projekte dann immer erstmal von so einem,
ähm,
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, ähm,
sondern fange halt gegebenenfalls wirklich mit einer einzelnen
Datei an. Blank, quasi.
Blank, völlig blank, und kann auf dem
Zielsystem auch einfach sagen, hier, Python 3.6,
da die Datei, puh, mach mal.
Ähm, und kann halt, äh, weil
ich bin immer der Freund von diesen,
ich nerv meine, 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? Von...
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 eigentlich auch nicht.
Was ich
eher haben will, ist, ich rotz 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, wenig, also
nur den, der Happy Path im Prinzip,
so der Idealfall,
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
wieder wegwerfe.
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 erkennen,
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
das 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,
aber 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 Festplatten-Controller
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 die Karte dafür, dass gerade der Cluster
überlastet ist, dann darfst du das schon nicht machen, und
solcherlei Dinge, und dann ist das halt was,
da ist dann der Arc-Parsen 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 erstmal 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 in
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 hier im Loss,
das ist mehr funktional alles, oder?
Das geht quer durcheinander.
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...
Das ist halt spannend, also wenn ich dann
einen gewissen Reifegrad erreicht habe,
und merke, ah, 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,
bzw. Eggs macht man ja nicht mehr,
also eine Sauce-List oder ein Reel
oder was auch immer,
aber eben irgendwas, wo eine Setup-Pie drin ist,
und wo man diese ganze Kram, dass man es paketieren kann,
dass man es auf dem Pipe-Pie laden kann, etc.
Und das Zweite ist, dann fängt es halt
meistens auch an, dass da die ersten Dependencies
dazukommen, und
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 Prägung, 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.
Deswegen macht man sowas nicht
dass man Sachen in den System-Interpreter
rein installiert, sondern
dafür gibt es halt die sogenannten Virtual-Env, die sind
seit Python 3 auch kein extra zu installierendes
Tool mehr, sondern du kannst ja über
Python 3
minus mv-env
und dann Verzeichnisname oder
wenn du es in deinem Repo direkt machst, willst du 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
dein Skript selber paketierst und sagst,
ich habe einen Package, wo auch
Dependencies in der Setup-Pi deklariert sind, dann kannst
du die über bin-pip
minus 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 Mindest-Versionen angibt,
dass man sagt, ich brauche mindestens
Version XY von einer 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 Versionen
2, 3, 4 oder was auch immer.
Genau. Das ist
so ein bisschen hartelig
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 bin-pip-install dazwischen
rumfuhrwerken. Ist da nicht jetzt sogar
so eine Neuerung geplant, irgendwie in 3.8,
dass man das irgendwie mit in die Verzeichnisse
direkt reinkriegen kann oder sowas?
Ja, das wäre 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?
Ja, man kann ja irgendwie die Versionen
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, das ist quasi genauso wie bei, ja, npm auch.
Ja, okay. Das mit dem System-Byte ist noch ein, es gab früher, 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.
Das Problem, das 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 install-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 mir...
...die Requirements-Text nicht drin steht, wird halt nicht rausgeworfen in dem Moment.
Du hast halt also keine abgeschlossene Hülle von dem, was da drin 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...
...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 Auto-Detection 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.
Hm, 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 du 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.
Machst du 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 ich glaube, ich habe es immer noch nicht verwendet.
Ja, 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,
die...
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 Versions-Set da ist, was du halt
brauchst.
Und das ist halt relativ...
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 einen Virtual-Env, um die Systemtrennung zu erreichen.
Das ist da bequemlichkeithalber.
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.
Hm.
Okay, cool.
Muss ich mir mal angucken.
Habe ich bisher noch nicht so gemacht.
Ja.
Ja, das ist so ein typisches Tool aus der SOAP-Welt, was sozusagen dann halt es über
die SOAP-Welt raus nie geschafft hat.
Und es hat eigentlich...
Da hängt so ein bisschen mein...
Da hängt so ein Open-Source-Herz von vor 10 Jahren halt dran.
Das hat eigentlich das bessere Engineering.
Es hat sich halt nur nicht durchgesetzt, das ist so ein bisschen, ach, Krokodil-Trainer.
Genau.
Ja.
So, ja, jetzt haben wir so Virtual-Env und...
Genau.
Ja, dann machen wir doch da einen Web-Summer drum und machen auch mal weiter.
Also habt ihr...
Was habt ihr denn noch?
Wie macht man denn dann, wenn jetzt so das Umgebung-Setting so gebaut ist?
Ja, jetzt...
Okay.
Jetzt haben wir erst mal die Möglichkeit, dass wir in Projekten überhaupt Umgebungen
mehrfach bauen können.
Ja, also du checkst ja jetzt die Requirements-Texte, das Build-Out 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 einen Repository packt und dann die ganze Infrastruktur, wie,
ja, 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 mal ein interessanter Vorschlag, genau.
Hm.
Interessant.
Also, weißt du, klar, was du halt machen kannst, ist, du kannst jetzt solche Dinge
spielen wie...
Du gehst...
Auf deinen Zielmaschinen...
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.
Es kommt ja immer drauf an, wofür man es braucht.
Ja, genau.
Und selbst da kann man eben diese Auftrennung machen.
Also, 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.
Hm.
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 anderes die Software entwickelt, dann haben die halt ihre Repo für die eigentliche
Software.
Hm.
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.
Naja, 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, ja, sozusagen Code, den
man irgendwie geändert hat, dann in den Master Branch oder so reinpusht, dass das dann halt
automatisch irgendwie in einem neuen Bild lostritt und das auch ausrollt.
Das rollt automatisch alles, wenn man halt irgendwie so einen CI-Server da irgendwo stehen hat, der
das dann macht.
Du musst 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 geht es um Feature-Entwicklung oder um 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 irgendwie mit einer Release fertig ist und
dann baut man die halt einmal und dann presst man die auf eine CD oder schmeichelt 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 irgendwie mit
dem 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, dass 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 drei irgendwie beim Testen fällt halt auf, oh, wir haben
ja ein großes Problem gefunden.
Was macht man denn dann?
Dann ist halt irgendwie doof.
Dann kann man halt entweder das irgendwie Duct Tape auspacken.
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 gute, 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, riesenbrockenes 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 Chat.
Dann hat man dann mit Chat Listen gearbeitet, weil man sich das nicht alles merken kann.
Und trotzdem passieren dann immer wieder Fehler und alles nicht so toll.
Aber 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 Knapp 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, ich weiß nicht, Travis oder was habe ich da gemeint?
Ja, Travis CI ist halt so ein Continuous Integration.
Ja, also man hört ja 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.
Nö, die läuft noch.
Also die Travis ist eigentlich durch.
Oh.
Was gibt es jetzt?
Naja, du hast halt GitHub.
Kannst du es ja auch so nennen?
Kannst du es inzwischen selber machen?
Bitbucket kann Pipelines, du hast GitLab.
Es 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 oder?
Ja, ob die Tests durchlaufen, kann man natürlich machen.
Und das kann man halt dann auch nicht nur so machen, dass das halt irgendwie für eine
Spezies, sondern man kann dann auch, ja.
Man kann so eine Maschine spawnen, die dann halt auch irgendwo stehen sollte, oder?
Ja, könnte man.
Aber das kann man auch nicht.
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.
Das dann halt alles funktioniert hat und so, dass es 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 eine 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, wie die genauen Definitionen jetzt für die, für die unterschiedlichen Sachen da
sind.
Hätte ich jetzt auch keine, die irgendwie formal wären.
Ich finde es, ich finde es eher spannend, dass auch da wieder diese beiden Extreme nur
zu betrachten eben genau nicht, 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, 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ümmer du dich drum, mach einfach, wie du willst, drück
selber auf den Knopf, wenn du soweit bist, da gibt man halt tatsächlich diese, die ganzen,
wenn du es durchautomatisiert, es ist halt, 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 hier hin und dann muss man mal draufdrücken oder dann schicke ich hier nur eine Nachricht
ab in irgendeinem Channel, das lässt sich halt besser erreichen und du musst dich im
Moment da auch annähern und ich meine, jeden Commit sofort rauszublasen, das kommt dann
halt auch drauf an, wie, was für einen Impact so ein Deployment halt hat.
Wenn du, 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 zehn Instanzen und dann updatest du die.
Die erste startest du neu, updatest du die zweite, startest du neu, jada, jada, dann müssen
aber halt die Softwareversionen 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 habe 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.
Wenn es 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...
Ja.
Genau.
Man muss das halt irgendwie wegkriegen.
Von dem, es ist irgendwas Außergewöhnliches, Schreckliches, wovor alle Angst haben und
dann zu etwas, was halt vielleicht ein bisschen weh tut, aber das, was man regelmäßig machen
muss, wie die Zähne putzen, keine Ahnung, dann geht das.
Ja.
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 Lobbalancern
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, kleine Geschichten.
Also, was ich momentan tatsächlich irgendwie selbst am liebsten mache, ist, ich benutze
tatsächlich Docker.
Ja.
Also, aus Entwicklersicht hat das einige echt...
Ich habe schon schicke Vorteile.
Ich habe früher auch mal das dann irgendwie mit Vagrant gemacht und dann immer komplette
Maschinen hochgezogen und so.
Aber das ist, das dauert halt alles so ewig, wenn man irgendwas ändern möchte an der Maschine,
dann muss man da irgendwie dann, ist das, dann, gerade wenn man sie dann per Ansible
oder so hochzieht, das ist alles, 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 hat man halt irgendwie, 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 von davor hatte.
Und es ist vor allem, 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 rumpunken?
Die, ähm, und dann haben wir da halt auch so Vagrant-Images und die sind schon relativ
gut, gute Zustände immer als Basis-Image, dass ich weiß, wo ich bitten und aber tatsächlich
NixOS kann halt auch so hier, installiere jetzt mal bitte xyz, das haben die in dieser Sprache
drinnen schon verwusst, das ist eigentlich eine schöne Alternative zu dem, wie, wie Docker
das macht.
Ähm, aber auch das ist tatsächlich immer wieder so...
...relativ fragil, weil es dann doch noch darauf ankommt, wie das Vagrant genau aussieht
und, ähm, nervt gerade auch noch ein bisschen, ähm, an der Stelle ist das, ist das Docker-Konzept
halt zumindest so, dass man halt relativ gut produktiv sein kann, ähm, ja, ja und vor allen
Dingen, also es hat halt, also was ich, ich kann ja einfach vielleicht, also ich mach
das so, äh, ist auch, auch, auch interessant, weil das vielleicht so ein bisschen der, der
umgekehrter Ansatz ist zu dem, man macht halt ein, ein, ein Skript, ähm, dass man, äh, irgendwie,
die Remote direkt vielleicht schon sogar entwickelt, um sofort sehen zu können, ob das irgendwie
funktioniert oder nicht, äh, wenn man jetzt irgendwie so eine Webseite, ähm, zusammenbaut,
dann hat man da enorm viel komische, äh, 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, äh, so ein Cookie-Cutter-Django-Template
oder so halt ausführe und dann erstmal...
äh, wie ich so ein riesen Ding da ausrolle, ähm...
Ist das ein selbstgeschriebenes Template oder nimmst du...
Nein, nein, ich nehme das, äh, das, das, äh, irgendwie, ja, kriegt man immer nach Django-Cookie-Cutter,
googelt, ist von den Leuten, die halt auch das, äh, Two-Scoops-of-Django-Buch geschrieben
haben und, ähm, ja, das macht dann halt schon eine ganze Menge, äh, Sachen, unter anderem
halt, äh, äh, legt es halt auch schon so, äh, äh, Docker-Config-Files, also Docker-Composed-YAML-Files
an.
Und, ähm, äh, ein, ein, ein großer Vorteil jetzt, wenn man damit arbeitet, ist, man kann
sofort hochfahren, äh, kann Dinge damit tun und vor allen Dingen kann man halt auch lokal
das Produktions, äh, Produktionssystem halt mal hochfahren und dann gucken, weil oft, also
es wäre natürlich schön, wenn das, äh, identisch wäre, aber, äh, lässt sich oft
nicht so wirklich, äh, komplett durchziehen und dann hat man schon Unterschiede zwischen,
äh, lokalem Entwicklungssystem, ja, also wenn ich jetzt irgendwas...
86er schmeißen.
Ähm, also, äh, genau, und dann auf dem Server ist es halt, dann sieht es dann doch anders
aus, also die Unterschiede sind halt vor allen Dingen sowas wie, naja, wenn ich halt lokal
entwickle, äh, dann, dann ist das halt eher das lokale Fallsystem, äh, äh, einfach, weil,
weil, weil ich auch lokal nicht so toll ans Netz angebunden bin und produktiv ist es dann
halt irgendwie, äh, äh, Google Computer Engine oder, oder, äh, AWS oder S3 Buckets
oder sowas und das verhält sich dann manchmal dann doch subtil anders.
Oder auch ganz, ganz krass anders.
Und, äh, äh, dann treten halt Dinge, äh, auf, die man halt lokal einfach nicht sieht.
Da funktioniert das Problem los und dann, naja, dann, wenn man das aber trotzdem mal lokal
reproduzieren möchte, weil man halt, äh, weil das halt auch blöd ist, äh, man kann
ja auch, äh, irgendwie Debug, äh, das Debug-Flag sozusagen auf Produktionsmaschinen nicht,
nicht einschalten, weil, äh, ansonsten reicht man halt diverse, äh, äh, äh, Sachen, die
eigentlich vertraulich bleiben sollten nach außen.
Daher, ja, 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, uh, geht wahrscheinlich auch noch irgendwie,
aber dann wird es halt schon sehr, sehr schwergewichtig.
Und, ähm, ja, natürlich funktioniert das auch nur, solange die Systeme halbwegs klein
sind, ja, wenn das dann, äh, irgendwie, äh, sehr, sehr viele unterschiedliche Services
werden.
Bei mir ist es halt meistens nur eben Postgres-Datenbank, ist irgendwie ein Redis, ist irgendwie vielleicht
ein bisschen Celery oder so.
Das ist so was, was mir Teddy erzählt, als bei Instagram.
Das ist, äh, das ist sozusagen der, der Applikations-Server vorne dran meistens, den ich, äh, meistens
benutze.
Äh, der, der, der, der, ähm, der, der Web-Server einfach vorne dran, der halt, äh, so ein Reverse-Proxy
auch ist für die Applikations-Server.
Applikations-Server ist, äh, Junicorn meistens.
Ähm, und, äh, ja, das sind halt vier, fünf unterschiedliche Container-Typen, das war's.
Und das, äh, kann man auch lokal problemlos noch, äh, handeln.
Eigentlich.
Ähm, genau.
Und, ähm, ja, äh, meistens mache ich das dann einfach so, dass ich, äh, ich hab halt
so, äh, Skripte, die, äh, also ich hab zum Beispiel einen Deploy-Skript, mit dem ich
das, also ich mach das dann halt per, äh, per SSH und, ähm, benutze aber auch Python
dafür, damit ich einfach nur Python-Skripte aus, ausführen muss, äh, das, äh, lockt
sich halt dann irgendwie auf.
Dann kommt man auf Produktionsmaschine ein oder so, checkt halt den Code aus, äh, baut
irgendwelche Container neu und startet dann alles, äh, neu oder so.
Das ist halt so das, was es, äh, was es, äh, an der Stelle macht.
Und dann halt auch noch irgendwelche Skripte, die halt, äh, lokal und produktiv Systeme
komplett abgleichen.
Also Datenbank-Backups ziehen, das Kopieren, irgendwie die, äh, äh, vielleicht Daten,
die aus irgendwelchen Buckets benötigt werden, äh, ziehen und synchronisieren.
Ja.
Ähm, und das funktioniert.
Das funktioniert für mich eigentlich ganz gut.
Hat halt so ein bisschen das Problem, dass ich jetzt auf, auf, auf dem Server sozusagen
auch, äh, Docker laufen lassen muss, was natürlich so ein bisschen ätzend ist.
Aber das, da komme ich natürlich nicht so wirklich drum rum, weil wenn ich das, äh,
äh, lokal genauso nachstellen können möchte, wie es halt produktiv läuft, dann muss ich
das halt so machen, weil, äh, ich kann ja den Produktions-Server nicht, äh, also wenn
das jetzt halt irgendwie, keine Ahnung, das ist halt wahrscheinlich irgendein Debian-Stable
oder sonst irgendwas.
Das kriege ich halt so.
Der ist ja lokal irgendwie nur schwer, äh, reproduziert, irgendwie in all der, also, ja,
außer wiederum mit Vagrant und, und, und Ansible oder so, aber, ja.
Ich meine, das, das ist halt ein, das ist ein ungelöstes Problem, so ein bisschen da dran.
Ähm, was mir immer, äh, negativ auffällt, ist, dass die Tech-Stacks immer größer werden,
ohne dass wir die eigentlich Probleme gelöst haben.
Ja.
Ähm, also dieses, äh, wenn du jetzt halt einen Docker hast, dann hast du jetzt sozusagen
das ganze Thema, ja, die Security-Updates für, äh, dein Zeug musst du halt selber machen.
Ja.
Du musst halt das Basis-Image, äh, 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, ähm, da, wo ich den Docker, das Docker-Image betreibe, ähm, rebuilde
ich den Container jeden Tag nochmal, indem ich halt noch einen Layer drüber jage, der
sagt, upget, upgrade, upget, äh, äh, upgrade.
Ja, genau, genau, so macht sich das auch.
Das habe ich ja auch da drin, sozusagen in meinem Docker-File und ich habe halt, äh,
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,
pff, sagen wir mal, Holzklasse.
Ja, ja.
Ähm, die, ähm, die, die, ähm, das andere, was du meinst von wegen Produktiv-Server und
dem Debug, das ist halt spannend, weil, ähm, du kannst dir ja natürlich schon, ähm, das
über einen Load-Balancer zum Beispiel aussteuern, also ich mache sowas gerne mal, wenn es wirklich
völlig abstrus ist.
Sachen sind, die halt auch zum Beispiel
eben temporal
davon abhängen,
dass momentan im Internet irgendwas komisch
ist. Ich hatte zum Beispiel, 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
typologisch so genau in der Mitte zwischen
Amsterdam und Frankfurt. Das sind so zwei der
großen
Netzknoten in Europa.
Und
da war es also...
Ja, genau,
es ist manchmal nach Frankfurt
und manchmal nach Amsterdam gegangen zu einem Fastly-Knoten.
Und das Problem war, der Fastly-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 so?
Habt ihr das Schiebel mitgesetzt?
Naja, ich weiß ja gar nicht mehr, welches das war.
Und der
mündete halt darin,
das ist ja auch die Frage von der
Internet-Architektur mit diesen Greyboxes,
das mündete halt am Ende darin, dass wir halt
irgendwo im Fastly-Support aufgeschlagen sind,
um ihnen klar zu machen, dass sie dort
ein Netz-Konfigurationsproblem
haben.
Das ist sozusagen so,
das ist das Ops-Ende von diesem
Thema von, was gibt es da an Zeug
zu debuggen. Oder eben, wenn
halt die Webseite steht still,
warum? Und dann gehst du halt her
und stracest den Python-Prozess,
um festzustellen, guck mal, der macht dauernd
Twitter auf, aber die gehen nie wieder zu.
Ich glaube, die bleiben hängen. Dann stellst du dir fest,
Twitter ist die API gerade kaputt.
Und das ist halt,
da ist Docker an der Stelle für uns
manchmal so ein...
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, also, das Docker-Structure
halt erstmal in der 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
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öselter.
Ähm, und, ähm,
äh,
ja, was bei uns
häufiger passiert vom Workflow ist, dass Entwickler
tatsächlich das Zeug erstmal in Docker bauen,
das macht sie produktiv, äh, 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, dann habt ihr 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 kenn das selber, wir hatten früher so
2004, 2005 rum auch immer mal
für irgendwelche, äh, Web-Projekte
dann und so 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.
Ähm, das war so ein bisschen, du warst so ein
Nexus an Dependencies, das ist immer
schwierig, ähm, und vor allem, wenn du halt
implizite Dependencies hast, die einfach nur von
ja, ich benutze halt das Basis-Image, äh,
und wenn das aber dann eine Dependency war, die nie gewollt
war, und die schaltet jemand ab, dann
fliegt sie plötzlich um die Ohren und du weißt noch nicht mal, warum.
Äh, da kommen dann teilweise ganz obskure
Fehlermeldungen, wir hatten das, glaube ich, beim Thema, da hatte jemand
eine Postgres mit 17.000
Extensions,
und, äh, unser,
also übertriebenermaßen, ähm,
schon das dritte alkoholfreie Bier hier,
ähm, die,
ähm, 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 Extensions, so, ah, okay,
alles klar, gut, ähm,
und, äh,
und Jochen unterhalten sich über die Programmiersprache Python
und 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 ist, 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 einer wissenschaftlichen Menge weniger.
Genau.
Da hat man halt schon.
Das ist auch eine harte Trennung, aber die, die, sozusagen die Trennung ist halt an der, man bekommt halt Maschine und kann da per RUT und SH drauf.
Genau, aber das ist jetzt auch nicht viel besser als das mit dem FTP und dem PHP.
Ja, genau, das ist natürlich so, ja, das stimmt natürlich auch, ja, und dann, auf der anderen Seite gibt es dann halt so Dienstleister, wie jetzt sowas 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 Daten,
Bank 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.
Heroku ist ja nur AWS.
Naja gut,
das sind ja auch diese unterschiedlichen Konzepte,
auf was für Infrastruktur möchte ich
aufsetzen, von Infrastructure-as-a-Service
zu Plattform-as-a-Service zu
whatever-as-a-Service.
Da ist halt auch spannend,
dieses
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 laufen die
Add-ons, sind die zwar eine gut integrierte API,
die lebt aber irgendwie in einem Rechenzehr
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? So, ja, 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. Dann ist...
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
mach Dinge selber und
mach 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
von zwei Jahren her oder so, aber da erinnere ich mich noch gut,
da war 80% des Webs war plötzlich irgendwie
tot, weil
da ein Rechenzentrum
wegen einem Blitzschlag nicht mehr
funktioniert hat. Lustigerweise auch die eigene
Amazon-Statusseite war
also die AWS-Statusseite, die sagen sollte, ob
das noch alles funktioniert oder nicht, die war auch kaputt.
Nee, nee, nee, das war so
subtiler, das war viel subtiler.
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 doch schön.
Da hatte ja niemand anderes ein Tennis gehabt, dann nur grüne Lämpchen, bitte.
Ja, genau.
Nee, und
ja, ja.
und 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 sie? Happy, happy.
Wie macht man sie? Happy, happy, happy.
Ja, genau.
Weil
das war unsere Schleif zur Digitalisierung.
Diese Erkenntnisse finden ja an vielen Stellen
im Kleinen statt und
das wird jetzt momentan
so
Entwicklungen, das wird mit so Pinselstrichen
werden, ganze Systemarchitekturen
ganz breit mal auf irgendein Bier
geschrieben und das aber die eigentlichen
Schwierigkeiten und das wissen
die Ops-Leute von den großen Anbietern
wie von AWS und von Google, die
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 habe es 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, wo
ich suche sie ja eher immer im
Kleinen und an den
etwas nicht so ausgetretenen Faden,
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 hat 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
dieses 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ühlung,
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, ganzheitlicher Blick
auf die ganze Mikroarchitektur.
Ja, ja.
Richtig. Ja, im Grunde brauchst
du halt, um halt 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.
Die Dünge.
Das Problem ist ja,
dein Teamgröße ist gespenkt.
Ja, ja, ja.
Das ist dann halt auch das, was
einem dann passieren kann, dass man dann irgendwie alles selber macht.
Das ist natürlich auch eine Situation, wo man dann kann.
Ja, genau.
Aber NIH 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 in 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
eine Lizenz geändert.
Weil ihnen das ein Dorn im Auge war,
dass die ganzen Plattformen
jetzt da irgendwie Geld mit verdienen.
Redis, Redis, nicht Mongo.
Redis war es.
Ja, aber MongoDB hat das auch irgendwie gemacht.
Und hat sozusagen
eine Qualizenz Amazon
verboten, irgendwie MongoDB anzubieten, woraufhin Amazon irgendwie ein 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 Login an der Stelle ist halt auch unglaublich.
Ja, das ist, ja, die, 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 kannst, musst halt nicht um Erlaubnis fragen, wobei das halt auch,
Ich heiße CapEx, OpEx, ich bin gerade wieder rausgeflogen.
Ja, unternehmerisch, wenn du halt deine Kosten betrachtest, dann ist die CapEx, OpEx-Trennung
ganz spannend.
Und 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.
Ich bin nicht, glaube ich, dran, du baust es dann so ein bisschen und guckst, wie du es...
Genau, du brauchst das, der Wert des Autos wird wieder in deine Bücher 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 geht ja nicht mal...
Das ist halt super, ne?
Weil du erst dann bestimmt das Geld irgendwie dann auf die Idee kommst, irgendwie die Kosten
selber zu investieren dann.
Ja, genau.
Ich glaube, Netflix hatte das dann irgendwann auch mal gemacht.
Netflix hat jetzt auch wieder eigene Ersätze mit im Mix, weil sie gesagt haben, auf Dauer
ist ihnen Amazon halt zu teuer.
Also Amazon ist ja nicht billig an der Stelle, du kannst natürlich viele 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 weniger zu bezahlen,
denke ich mir so, jetzt...
Ja, dann haben wir jetzt quasi ja die Kurven alle wieder zum Ende gekriegt.
Alle losen wieder zusammen, genau.
Das ist ja die Aufgabe, die der Admin dann ja hat, ne?
Alles das zusammenhängen, der Operator.
Kriegst du ja twice.
Ja, ich war auch, irgendwann mal hatte ich mal so ein Obzeichnen zum EZ-Channel.
Wollte ich gerade noch loswerden.
Ja, schön, dass ihr wieder so schön viel erzählt habt.
Ich glaube, das war die Folge, in der Jochen am wenigsten gesagt hat, bisher.
Also so im Vergleich jetzt, ne, zu unserem Gast.
Ich nehme das jetzt nicht als Ehre, weil das ist immer mein Fluch.
Ja, großartig.
Ja, auch beim Zuhören sehr interessant.
Ja, genau.
Das hat mega Spaß gemacht und wieder ganz viel gelernt und 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.
Ich glaube, für heute sind wir sonst gleich durch, oder?
Ja, das ist auch schon relativ lang dran, ja.
Ja, so war es das ja, dass du da warst heute.
Das war echt toll.
Ja, war echt gut.
Sehr gerne, jederzeit wieder.
Alles klar, ja, dann.
Okay, bis zum nächsten Mal.
Ja, bis zum nächsten Mal.
Tschüss.