Transcript: Devops

29. Mai 2019 · Back to episode

Full episode transcript. Timestamps refer to the audio playback.

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?

Ich sitze, ihr sitzt im Garten.

Das wird da gar nicht so angehört.

Ah, okay.

Ich gucke in meinem Garten.

Ich sitze in meinem Homeoffice.

Ich sitze in der Nähe von Stuttgart.

Ah, 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.

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

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.

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

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.

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

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-

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,

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

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

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.

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.

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

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

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.

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ß.

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.

Genau.

Und bei den Entwicklern ist es halt so,

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,

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.

Ich meine,

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.

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.

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?

Wie macht man das denn?

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.

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?

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.

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.

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?

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,

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,

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,

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.

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.

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.

Okay, cool.

Muss ich mir mal angucken.

Habe ich bisher noch nicht so gemacht.

Ja, das ist so ein typisches Tool aus der SOAP-Welt, was 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.

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...

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?

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.

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.

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.

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.

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.

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.

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

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...

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.

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.

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

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.

Ä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.

Ä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.

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.

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.

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.

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,

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.

das war unsere Schleif zur Digitalisierung.

Diese Erkenntnisse finden ja an vielen Stellen

im Kleinen statt und

das wird jetzt momentan

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

wir wissen ja alle, also

jedes Problem kann dadurch gelöst werden, dass ich halt noch

ein Layer oben drüber ziehe.

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.

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

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.

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, das war irgendwas, was?

Feedback, hallo, at peisenpodcast.de.

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.