Transcript: Devops

Ja, hallihallo, herzlich willkommen zum Python-Podcast.

Heute haben wir ein Jubiläum und wir haben die zehnte Episode.

Das ist ja hervorragend, cool, ne?

Hurra!

Zehn Stück schon geschafft.

Ja, und es ist noch eine kleine andere Premiere.

Und zwar haben wir heute das erste Mal eine Remote-Sitzung,

einen Studiogast quasi, der nicht bei uns im Garten sitzt.

Wo sitzt du denn, Christian? Hi!

Hi, ich sitze, ihr sitzt im Garten.

Das hat sich gar nicht so angehört.

Ah, okay.

Ich gucke in meinem Garten, ich sitze in meinem Homeoffice,

Ich sitze in der Nähe von Stuttgart.

Ah ja, diese ganz schöne Remote-Verbindung

hier von Düsseldorf nach Stuttgart, durch die Heimrepublik.

Wundervoll.

Was machen wir heute? Wir machen heute DevOps ein bisschen

und wie man Python so

ausschickt.

Wenn man irgendwie Python-Applikationen

entwickelt hat, dann möchte man ja auch irgendwie die

sozusagen dann

produktiv benutzen können, dass andere Leute die sehen und so

und dann, genau, muss man da auch noch Dinge tun,

damit das geht und ja.

Ja, so ein Zirkus.

Genau, dann

Ja, genau, vielleicht

am besten

stellst du dich einfach mal vor, Christian, und dann

genau. Genau.

Ja, kann ich gerne machen. Also ich bin

Christian, auch bekannt als Toini.

Das ist dann auch mein

Twitter-Handle. Und

ich müsste mich jetzt eigentlich fast als

Urgestein in der Python-Szene sozusagen

bezeichnen.

Deswegen bist du auch in unserer Jubiläumsausgabe

dabei.

Mein Herz wird warm. Ich mache Python jetzt seit 99, glaube ich, in der Größenordnung. Ich weiß sogar, dass ich irgendwann 95, 96 als erstes mal Internet hatte, hat mich in irgendeinem obskuren Chatraum damals, das war noch mit AOL oder so, hat irgendwer schon mal Python gesagt. Insofern, mein frühester Kontakt war, glaube ich, mit 14 oder so.

Ja, also relativ viel mitgemacht. Ich habe die Python User Group aufgebaut, die ja aus der deutschen SOAP User Group damals hervorgegangen ist. Ich habe lange SOAP gemacht, da Kernentwicklung, viel mit den Amerikanern zusammen, habe mal auf diversen Sprints so um die Jahrtausendwende rum mit Guido rumgemacht. Wir haben irgendwelche komischen SOAP Sachen geschrieben, die heutzutage nicht mehr existieren.

Der war ja auch bei SOAP bei der Firma irgendwie beschäftigt.

Genau, genau. Soap hat damals tatsächlich eine ganze Zeit lang die Python-Labs bezahlt.

Die waren komplett von der Soap über zwei oder drei Jahre bezahlt worden.

So mit Barry Warsaw, der das Mailman macht und diversen anderen Leuten.

Genau, nee, und da habe ich also jetzt viel in der Python-Szene gemacht,

selber Software entwickelt für gute 15 Jahre im Sinne von Anwendungsentwicklung

und ich mache aber seit Ewigkeiten

halt auch schon, ja, Serverbetrieb

nebenbei und die Firma, wo ich jetzt

bin, die verdient, also die ist

jetzt auch meine Brötchen,

aber die lassen wir jetzt hier einfach mal fröhlich

vor, weil wir keine Werbung haben.

Bei der Python Software Foundation bist du noch, das hat mich noch ein bisschen interessiert,

was ihr denn da noch so macht, vielleicht kannst du die noch mal

kurz so ins Spiel bringen und vorstellen.

Achso, ja, ich habe ja zwei, also es gibt jetzt sozusagen

zwei, es gibt den Python Software Verband,

das ist ein

deutscher Verein und

wir fördern

Python im deutschsprachigen Raum, also

unter anderem durch

Veranstaltungen, also die

PyCon.de,

die richten wir aus. Ich glaube, die PyData

ist unter unserem

Schirm, die wandert aber durch Europa

und wir haben jetzt seit einem

Jahr, seit einem guten Jahr, ein Förderprogramm.

Das ist eigentlich auch was, was man

in dem Podcast hier mal ganz gut platzieren

kann, weil

das Förderprogramm ist im Prinzip dafür da,

dass mehr Leute in der Community

mal Sachen ausprobieren, wie sie Python

in Anführungszeichen unters Volk

bringen. Besser

eigentlich eher ausgerichtet an so einem

Diversity-Gedanken, dass wir

Python selber ist im Mainstream ja

präsent und angekommen. Also vor

fünf Jahren, vor zehn Jahren sah das alles noch ganz anders aus,

aber heutzutage muss man sich ja nicht rechtfertigen

dafür, dass man Python verwendet oder

irgendwo einsetzt, sondern das ist dann eher das, was man unter

Best Practice, so sehr

ich dieses Wort hasse,

abhaken kann und dann ist das irgendwie

erledigt, das ist Chef-approved.

In den letzten Auswertungen über den Jahreswechsel, was die Beliebtheit von Programmiersprachen angeht,

ist Python halt weltweit im Prinzip immer unter den Top 5, wenn nicht sogar auch auf Platz 1.

Deswegen haben wir vom Python-Software-Verband irgendwann gesagt,

Python einfach nur an sich zu pushen, das braucht es gerade gar nicht mehr, das läuft.

Was ich aber spannend fände, ist halt tatsächlich neue Zielgruppen und neue Vernetzungen aufzumachen.

Also zum einen Leute, die mit bestimmten Spezialthemen zu tun haben.

Da hat jetzt als ein großes Gewicht, früher war es viel Web, jetzt ist es Data Science, aber tatsächlich halt auch in den Embedded-Bereich, in den Bastel-Bereich, in der Maker-Szene, rüber hin zu anderen Gruppen wie Jugendlichen.

Denn Diversität zum Thema Frauen in die Informatik ist in Python eh so ein großes Feld.

Die PyCon US war eine der ersten Konferenzen, die über 30 Prozent Frauenbeteiligung sowohl an den Teilnehmern als auch bei den Vortragenden hatte.

Und unter diesem Rahmen gibt es in diesem Gedanken, Python halt sozusagen in so viele kleine Nischen auch reinzubringen und nicht nur durch den Mainstream.

Da gibt es jetzt das Förderprogramm, beziehungsweise gibt es seit einem Jahr und man kann dort zum einen einfach mal kleine Veranstaltungen ausprobieren

Wenn man sagt, ich würde gerne, da haben wir ein paar Leute, die machen an Schulen immer mal was, wo sie Kindern dann Raspberries oder andere kleinere Embedded-Python-Geräte bei einem Workshop in die Hand drücken.

Ja, das ist cool, das habe ich sogar auch schon mal gemacht.

Tatsächlich für Kinderkurse mit dem Raspi und dann in Python mit Minecraft oder so Coden.

Genau, genau.

Und was halt schön wäre, wäre, wenn man den Kindern das halt auch mitgeben kann, damit sie dann halt zu Hause weitermachen und nicht nur mit hier hast du mal was und in zwei Stunden ist es wieder weg.

Und für solche Veranstaltungen sponsern wir dann, ich glaube, so eine Pauschale von 400 Euro pro Veranstaltung, beziehungsweise wir brechen das auch runter auf pro Kopf, pro Kopf gibt es 20 Euro und wenn du abwende 10 Leute hast, kannst du die 400 Euro haben und wir machen das ohne groß Formalismus, da kann man einfach an die E-Mail-Adresse, da gibt es eine, habe ich gerade nicht im Kopf, kann man auf der Webseite nachschlagen.

Ich sage jetzt mal so schön, wie es beim Podcast immer heißt, findet ihr in den Shownotes, können wir da reinpacken, da schreibt ihr eine E-Mail hin, sagt, was ihr machen wollt und dann wird das im Vorstand innerhalb von ein, zwei Wochen beschlossen und dann geht es los und ihr könnt das Geld kriegen, entweder indem ihr uns ein paar Quittungen schickt oder indem wir einen kleinen Sponsoring-Vertrag machen, dann braucht man nicht über irgendwie Kleingruch-Quittungen zu reden.

Genau, das ist die eine Variante. Die andere Variante ist noch, dass wir auch größere Veranstaltungen ab 50 Personen sponsern. Das ist dann typischerweise sowas wie die JungleCon-Sponsorware. Da gibt es dann irgendwie 1000 Euro einmal glatt, um anderen Leuten halt den Zugang zu Veranstaltungen zu erleichtern. Das geht dann typischerweise in Financial Aid oder Reisekosten oder irgendwie solche Töpfe.

Und das dritte, was wir noch sponsern, sind dann tatsächlich auch Feature-Entwicklungen oder allgemeine Entwicklungen für Open-Source-Python-Projekte.

Wenn ihr sagt, wir wollen mal einen Sprint machen und dafür brauchen wir Reisekosten oder wir wollen es mal am Wochenende wegschließen oder ich würde eigentlich gerne mal zwei Tage was machen, aber dann habe ich irgendwie Arbeitsausfall, weil ich keinen Urlaub dafür nehmen kann, dann gibt es dafür Projekte für jede Aktion 500 Euro.

Genau, und die verteilen wir jetzt. Das ist so ein bisschen nämlich das Thema, wir haben über den Verband halt die Möglichkeit, über Sponsoren und über alles andere eben Geldmittel einzusammeln und haben gesagt, naja, wir wollen jetzt eigentlich, dass die Leute, die in der Community aktiv sind und gerade das Thema Sustainability ist ja auch so ein großes Ding, da wollen wir jetzt nicht, dass die Leute, die Zeit mitbringen, auch noch das Geld mitbringen, sondern dass man das ein bisschen einfach nur als, man nimmt den Leuten ein bisschen Druck weg und lässt sie halt experimentieren.

mehr Dinge ausprobieren, mehr schauen,

was funktioniert, was funktioniert nicht

und ganz ohne den Druck sich irgendwie

rechtfertigen zu müssen, ob das jetzt wirtschaftlich war oder nicht.

Klingt super, klingt echt

toll. Das macht ja echt viel

Lust, das klingt echt interessant. Also bestimmt

noch ein paar Interessenten, die das

zu schätzen wüssten. Genau, definitiv. Also gerade bei

den Entwicklungs

Sponsorings ist die

Soap-Plone-Welt irgendwie sehr

stark, weil die halt in der ganzen

Vereins-Community sehr stark vertreten ist.

Die machen halt viel so Sprints, wo sie

sich treffen, wo sie halt an

den Open-Source-Projekten entwickeln

und die fordern

das immer mal ein, die muss man eher mal

bremsen. Dummerweise haben wir niemanden anders,

auf den wir zeigen können mit, hier, die rufen auch Geld

ab, aber komm, nicht dran.

Momentan ist es echt so, dass wir uns eigentlich wünschen würden, dass

mehr Leute auf uns zukommen, dass wir da mehr Gutes tun können.

Umgekehrt kann ich natürlich auch

sagen, jetzt wo ihr wisst, was der

Verband mit dem Geld macht,

werdet Mitglied.

Euer Geld ist gut angelegt.

Genau, das ist so was,

so ein bisschen was wie eine organisierte

Patron-Variante sozusagen dann.

Aber es ist auch für Unternehmen halt ganz schön.

Das andere wäre natürlich,

wenn man sonst sagen kann,

dann mache ich den Kreis

mit diesen ganzen Organisationen zu,

die PSF, die Python Software Foundation,

das ist die amerikanische,

wo auch, ich glaube,

der gehören inzwischen die Copyrights für Python.

Ich glaube, da sind die hingewandert.

Die sind natürlich ziemlich groß,

die haben halt die ganzen Großsponsoren auch,

die koordinieren halt eher so Sachen mit Google

und Microsoft etc.

Die veranstalten ja hauptsächlich auch die große

PyCon US, haben aber eben auch, die haben auch so ein Förderprogramm

und da sind wir aber auch dabei

zuzusehen, dass wir

die Sachen halt mit koordinieren, dass wir

dann, wenn jemand sagt, okay, das Förderprogramm,

was wir haben, das ist eigentlich zu klein,

ich würde gerne von der PSF noch was holen, dann

haben wir da halt auch die Kontakte,

um dann zu sagen, man kennt sich schon und man

muss es nicht groß ausverhandeln, wer da welchen Papierkrieg

über den großen Teich schiebt.

Genau, ja.

Cool, kurze Leitung, also falls ihr den habt,

meldet euch da direkt, könnt natürlich auch das alles kommentieren.

Genau, immer her damit.

Ja, ich habe es letztens nur gehört,

dass es bei Django gibt es da auch sowas,

es gibt halt die Django Software Foundation

und die bezahlen ja jetzt auch, glaube ich,

ein oder zwei Vollzeitstellen.

Aber im Grunde ist das immer so ein Problem,

dass halt Software die wichtige Infrastruktur

für ganz viele Projekte ist.

Dann halt irgendwie so, wo dann, naja, vielleicht so,

Also bei Django ist es so, dass er, glaube ich,

ein halbes Dutzend Leute irgendwie so wirklich aktiv

dran entwickelt und das ist halt eines der

größten Projekte, aber

eigentlich ist das ziemlich wenig, wenn man sich überlegt,

wo das überall eingesetzt wird und

wie viele Webseiten ja

darauf angewiesen sind, dass das irgendwie

weiterentwickelt wird,

Sicherheitsgeschichten irgendwie

gehändelt werden und so.

Das ist,

das berührt ein total interessantes Thema,

was jetzt nicht heute mit unserem Tagesthema zu tun hat,

aber ich habe in der letzten Zeit halt viel

Gedanken mir gemacht,

gerade um die sind,

wie ich an dem Begriff Digitalisierung

irgendwie

einen Griff, also wie ich da irgendwie einen Griff dran

kriege ohne

bla bla.

Keiner kann das Wort eigentlich mehr hören

und wahrscheinlich ist es vom Hype-Cycle her so langsam

durch und ich habe mich immer gewehrt, es überhaupt einzusetzen.

Und aber

dieses, da sind

so wenig Leute teilweise an so kritischen Sachen dran.

Aus einer Open-Source-Perspektive

oder freien Software-Perspektive finde ich das

überhaupt nicht schlimm. Das eigentliche

Thema ist nur, es müssen alle, die

so ein Zeug einsetzen, im Prinzip wissen, sie

zahlen weniger Geld, als man

früher in Lizenzkosten in sowas reingesteckt

hat oder Pflege- und Wartungsverträge.

Das heißt aber im Prinzip,

wenn man dann die Sicherheit haben möchte,

dass einem das nicht unter dem Hintern wegschimmelt,

muss man halt, muss man eigene

Kompetenz aufbauen und das

greift aber genau an dieses Thema ran, was bedeutet

es eigentlich, wenn immer mehr Dinge

digitalisiert werden, dann heißt das halt eigentlich,

ich muss dort mehr Kompetenzen

selber entwickeln, anstatt das Zeug

einfach nur blind einzusetzen, blind zu kaufen,

also fast egal, ob ich es kaufe oder

als Open Source

oder freie Softwarelösung habe.

Ich bin eigentlich darauf angewiesen, wenn das mein Kerngeschäft

so dermaßen berührt, dass ich genügend

Kompetenz habe, um wenigstens zu wissen,

wo meine Risiken sind,

wenn ich es schon nicht selber

lösen kann.

Das ist aber schon wieder so technisches Detailwissen,

das hat der meiste normale Vorstand

wahrscheinlich gar nicht mehr auf dem Schirm.

Der denkt sich dann so, ja, erst Geld ausgeben

für Software, die wir gar nicht brauchen, also

wir kaufen ja nicht, warum?

Ist ja umsonst.

Ich hab da momentan

eine Metapher für,

das ist, Digitalisierung

wird an der Stelle, also die ist ja total relevant,

weil

im Prinzip die alten

Sprüche, die wir jetzt wahrscheinlich schon seit 20 Jahren

kennen, sowas wie Marc Andreessen mit

Software eats the world,

das heißt, alles wird irgendwie Software sein.

In einer positiven

Variante bedeutet

dass Software ist als so Augmentierungshilfsmittel ständig dabei.

Nicht im Sinne von verdrängt den Menschen oder ersetzt ihn,

sondern es wird immer mehr Stellen geben, wo so ein organisches Zusammenwachsen bei Prozessen ist,

wo ich auf unterschiedliche Teile von Software angewiesen bin,

mit der ich interagiere und die sich miteinander verbindet.

Das wird aber so integral sein, dass es tatsächlich im Prinzip wie eine Sprache zu behandeln ist.

Und ich habe momentan immer den Eindruck, wenn jemand in einem Unternehmen,

Wenn du jetzt Vorstand sagst, wir machen jetzt irgendwas mit Digitalisierung, dann klingt es in meinen Ohren so, wie der Vorstand kommt daher und sagt, wir stellen jetzt die Unternehmenssprache von Deutsch auf Englisch um und um das richtig hinzukriegen, haben wir jetzt einen Übersetzer und zwei Wörterbücher angeschafft.

So ungefähr ist es auch. Wir wollen digitalisieren, deswegen kaufen wir jetzt mehr Software ein oder so. Das ist aber ja ein Unternehmen, das im Prinzip wirklich atmen muss. Ich trage da momentan viel mit mir rum und das ist jetzt extrem Python-unspezifisch.

Ja, echt interessant. Das ist auch überhaupt nicht so richtig, es gibt da auch keine gute Kultur für. Also ich habe da auch schon in diversen Unternehmen, die ja dann oft diese ganzen Sachen einsetzen, also am Anfang war es immer noch schwer, das irgendwie durchzusetzen, dass überhaupt irgendwie Open Source verwendet wird und wieso, wenn das nichts kostet, ist ja doof und so, war diese Haltung noch sehr weit verbreitet.

Und dann teilweise wurden so Dinge gemacht, wie Weihnachten, als alle im Urlaub waren,

hat man halt dann die Netscape-Webserver ersetzt durch Linux-Webserver und so.

Und als dann sichtbar wurde, dass das sehr gut funktioniert und auch besser halt oft als die kommerziellen Varianten,

dann hat sich das durchaus etabliert, dass man das so macht.

Aber irgendwie, dass es eine gute Idee wäre, da halt auch selber mit an der Infrastruktur zu arbeiten und dass das natürlich auch Geld kostet oder dass man zumindest Selbstkompetenz aufbauen muss, das ist auch immer noch schwer.

Die ganzen Unternehmen haben das nicht verstanden, was das bedeutet, was Digitalisierung ist. Das bedeutet für jeden irgendwas anderes und die meisten sind so fern von jeder Digitalisierung, schleppen dann die E-Mails ausgedruckt im Koffer mit sich rum, das funktioniert halt dann noch nicht.

Und wenn das die Entscheider noch manchmal sind, leider, dann braucht das länger.

Ja, ich würde mal behaupten, wie war das jetzt mit der PDF-CDU?

Ich würde jetzt halt behaupten, die E-Mails werden nicht mehr ausgedruckt, sondern es werden PDFs draus gemacht, die kann man sich dann aufs iPad legen.

Ja, und dann da drinnen irgendwie rummalen.

Ja, genau.

Ja, alles andere wird dann einfach verboten.

Ich meine, genau das, was du beschrieben hast mit den Netscape-Servern, das ist halt auch der Punkt, wo ich es spannend finde. Meine Erfahrung, würde ich halt sagen, ist jetzt auch 20 Jahre Digitalisierung. Das ist mein ganzes Berufsleben im Prinzip seit 99 und der eigentliche Effekt, den wir gesehen haben, das, was man jetzt Digitalisierung nennt, passiert ja seitdem. Das passiert schon seit Ewigkeiten.

Ich würde sagen, die Jahrtausendwende war tatsächlich so ein Knackpunkt mit Internet, ist explodiert und wir haben damals immer schon Projekte gemacht, wo wir gemerkt haben, du musst Digitalisierung im ganz, ganz, ganz Kleinen umsetzen.

Und die eigentlich großen Effekte, wenn es halt immer heißt, es ist Time to Market oder alles billiger oder schneller oder effizienter oder individueller, die eigentlichen großen Effekte sind nie aus der Planung heraus entstanden, sondern die sind dann entstanden, wenn wir bei den Projekten beim Kunden vor Ort waren und dann zufällig eine Dame, die da Sachbearbeiterin ist, überhören, wie sie gerade unser Projekt benutzt und sie irgendwie über Excel flucht.

Und man dann feststellt, okay, was machst du gerade mit Excel? Ja, da hat sie halt so eine Tabelle gehabt, wo sie so eine Statistik mitführen musste, einmal pro Monat. Und da das ja niemand auf die Idee kam, dass das irgendwas mit unserer Software zu tun haben könnte, mündete es darin, dass diese Dame als halbe Stelle, die hat eine halbe Stelle damit verbracht, 20 Stunden pro Woche, eine Zählliste zusammen zu klicken, indem sie sich durch unsere Software durchgeklickt hat.

Um dann in dieser Excel-Tabelle zu erfassen, wie viele Personen dieses Kriterium, wie viele Personen dieses und wie viele Personen dieses Kriterium hat.

Und nur weil wir neben ihr saßen, immer über die Schulter geschaut hatten, konnten wir mal mit ihr reden und sagen, du, das kann ich dir da rauslassen.

Das merkt man dann so, das ist ja alles relativ komplex.

Und so in Excel kannst du, wenn die Stadt dir so eine Statistik gibt mit tausend Makros drin, dann generierst du das nicht.

Aber wenn du mit den Leuten ein bisschen Ping-Pong spielst mit, zeig mir mal, was du machst.

Und siehst, ah, guck mal, die füllt die Daten immer nur in so einem Rechteck aus.

dann generiere ich dir jetzt eine HTML-Tabelle, die kannst du per Copy & Paste in diese andere Tabelle von der Stadt reinpacken

und plötzlich ist dein 20-Stunden-Job, also 80 Stunden pro Monat auf 5 Minuten eingedampft.

Ich hoffe, die Arme hat dann noch da arbeiten dürfen für irgendwas anderes.

Natürlich, also ihre Vorgesetzte waren halt super glücklich, weil die so viele Themen auf der Pfanne hatten, zu denen sie nie gekommen sind,

aber Bürokratie drückt dir halt immer die Prioritäten weg.

Also Bürokratie

kann ja immer sagen, ich muss gemacht werden,

zum Termin. Und dann hast du die Leute

beschäftigt. Und eigentlich wollen die noch tausend andere

Sachen machen, kommen aber nicht dazu, weil die Bürokratie

das wegfrisst.

Das ist halt dann dringend, aber nicht wichtig eigentlich.

Und die wichtigen Sachen werden dann nicht mehr gemacht.

Genau.

Ich habe viel Komplexitätstheorie

gemacht in den letzten Jahren. Dave Snowden,

Kenevan und so. Und es gibt

ein wichtiges

Ding

aus der Komplexitätstheorie, was da

reinspielt, ist, das sind

die unarticulated needs.

Das ist, die Welt ist so komplex,

dass Anwender

schrägstrich Betroffene

schrägstrich Bürger, schrägstrich

Patienten, egal welche

Teilgesellschaft wir nehmen,

die haben gar keine Vorstellung mehr

davon, was überhaupt möglich ist

oder geschweige denn,

in welcher Sprache müssten sie ihren Bedarf,

den sie haben, überhaupt formulieren, dass jemand

anders angreifen kann, sagen kann,

hier, da kann ich dir helfen. Die Dame hat das

halt in völliger Zufriedenheit

gemacht, sich da monatelang durchzuklicken,

weil ihr nicht bewusst war,

dass es da überhaupt

eine Möglichkeit gibt, das zu lösen.

Die wusste gar nicht, dass es ein Problem war

und deswegen ist das nie in der Planung aufgetaucht.

In Digitalisierungsprojekten musst du im Prinzip

im ganz Kleinen alle Leute im Unternehmen

zu befähigen,

diesen Übersprung zu haben von, hey, Moment,

das hier ist ein Problem,

das müsste sich doch in Software erschlagen lassen.

Und zwar nicht im Sinne eines, oh, wir machen mal

den großen Aufschlag und dieses ganze

Unternehmen wird durch KI ersetzt, sondern tatsächlich

über so ganz völlig blöde

kleine Teilchen

und der Herr Wolfram

von Wolfram Alpha, der hat jetzt

ein paar Artikel geschrieben, wo er meinte halt

Computational Thinking,

wenn wir sagen, in der Schule wird ja Mathematik

gelehrt, aber da lernst du halt nur rechnen.

Und Computational Thinking

wäre tatsächlich total spannend

aus einer Perspektive zu wissen, wann

sind so Zahlen

oder Datenmengen eigentlich für

Computer zugänglich?

Also ich habe jetzt so ein Bauprojekt an der Backe,

weil ich ein privates Haus baue und da fliegen natürlich

tausend Excel-Tabellen rum und wenn ich,

dann habe ich es mehrfach gehabt, dass dann Excel-Tabellen

rausfallen, wo in einer Spalte

irgendwelche Zahlen drinstehen, aber dann gleichzeitig

auch noch irgendwelche Worte mit

entweder einem Kommentar dran oder

irgendwie unterschiedliche Maßeinheiten,

wo ich dann auch drauf gucke und sage so, ja gut,

die kann ich jetzt halt nicht mehr benutzen, um da Formeln drüber zu jagen.

Das geht so nicht.

Aber dieses Gefühl halt, wann

sind Sachen für Rechner zugänglich, das musst du im Prinzip

kulturell in so ein Unternehmen reinkriegen,

wenn du Digitalisierung machen möchtest. Und damit

schlagen wir uns halt seit 20 Jahren rum. Das ist das

ganze 90er Jahre Schulen ans Netz

und das ist Neuland und das ist

Ja, ja, klar. Das ist

ein großer kultureller Wandel, der

da nötig ist und die Leute

müssen, ja, ich meine, es gibt halt so ein paar

Verrückte irgendwie, die das

vielleicht dann vorher schon oder

machen oder sich selber damit so lange beschäftigt

haben, bis sie es irgendwie können. Aber

für viele wird es halt so sein, das ist nur dann natürlich,

wenn man da reingeboren wird.

Ich glaube, das ist auch gar nicht so, weil ich glaube,

gerade durch diese Vereinfachung, die man hat,

man hat jetzt nur noch so ein Pad in der Hand, wo man links und rechts

wischt, ist das nicht unbedingt zugänglich.

Also dadurch, dass du diese tollen User-Interfaces hast

und so, das ist ja... Ja, aber ich glaube, du

kannst nicht ohne die

Sicht der Benutzer oder der

Leute, die sich mit dem

Bereich, mit der Domäne irgendwie auskennen,

ohne die kommst du nicht aus.

Die müssen halt auch sozusagen verstehen,

wie das, was sie tun... Ja, aber die wachsen ja nicht automatisch

mit nach, sondern du musst sie ausbilden. Ich glaube

nicht, dass nur, weil du Digital Native irgendwie bist,

reingebunden wirst, dass das

funktioniert, sondern ich glaube, du musst tatsächlich

mit dieser Brille draufgehen, du wirst jetzt da

Tech-Experte sein.

Ich glaube vor allem auch, es gab einen massiven Bruch durch

die Systeme Android

und iOS, weil

bisher, wir können es natürlich sozusagen

Opa erzählt vom Krieg

spielen.

Ein Chapter Mark, Opa erzählt vom Krieg.

Okay, warte mal, ich mache.

Das ist mir vorgeworfen

worden, nein, das ist mir nicht vorgeworfen worden, aber es ist

irgendwie mit einem zwinkernden Auge auf ein PyCamp

in Köln konfrontiert

wurden, wo ich halt auch meinte, guck mal, die Historie,

ging es um irgendein Stück Technik, wo ich

nochmal irgendwie nachgezeichnet habe, wie das die letzten 15

Jahre halt entstanden ist. Und ich meine, ich bin jetzt

Mitte 30 und werde dann halt von Leuten,

die gerade im Studium stecken, angeguckt mit, Opa erzählt vom

Krieg.

Und es ist aber witzig, weil

klar, wir haben uns, oder also ich mich,

ich glaube, wir sind so eine Liga, glaube ich, vom Alter.

Ich habe

mich so über die 90er Jahre halt durch Sachen durchgequält,

wo ich da sagen muss,

es gab halt nie dort eine Trennung

zwischen Konsument und Produzent.

Ich bin, egal ob auf DOS oder Windows,

dann Mitte der 90er irgendwann Richtung Linux,

da war halt immer ein, du interagierst mit dem Ding

und du versuchst irgendwie rauszukriegen selber,

dass das irgendwie tut, was du willst.

Und jetzt aber in dem ganzen Umfeld iOS, Android

hast du fast reine Konsumentengeräte.

Zumindest auf einer Ebene, wo diese Rekursivität von Rechnern,

Also von Neumann-Maschine, Daten und Programme sind ja im gleichen Speicher und es ist sozusagen eine Wandelgestalt, ob etwas als Datum oder als Programm interpretiert wird, weswegen wir halt auch solche Dinge wie Viren haben.

Und das ist ja was, was damals halt dazu geführt hat, dass man ständig, das war wahnsinnig aufwendig, das willst du nicht für jeden. Wir können ja sagen, okay, wir haben uns da durchgekämpft und was einen nicht umbringt, macht einen stärker.

Aber das ist natürlich nicht die Zugänglichkeit.

Ich sehe aber tatsächlich, dass Tablets und ganz einfache Systeme,

eben auch, dass zum Beispiel das Dateisystem sich ja als Metapher aufgelöst hat im Prinzip,

das macht, dass die Leute diese Universalität der Rechner nicht mehr wahrnehmen,

sondern es ist nur noch eine Sammlung von Apps,

die irgendwie, entweder sind sie miteinander integriert oder sie sind es nicht.

Ja, aber sind wir da nicht vielleicht noch einfach ein bisschen früh dran?

also wenn man sich jetzt sowas anguckt wie Shortcuts

oder so auf iOS,

das geht ja schon so ein bisschen in die

Richtung, dass man damit dann halt auch Dinge tun kann,

wie, ja, ich meine, ich übertreibe jetzt ein bisschen,

aber mit Pipes auf der

Kommandozeile oder so,

nur halt in grafisch und mit einem schönen Interface.

Halt nicht, weil

das ist halt nicht mehr universal. Es geht halt nur das,

was dir zugelassen wird, was geht.

Gut,

okay, ja, man kann natürlich noch einige

Sachen selber schreiben, aber das

ist natürlich dann auch wieder,

da ist man dann sofort in so einem Profibereich,

wo man dann irgendwie

sich registrieren muss bei Apple und so.

Ja genau und das Modell ist halt nicht

sehr stark an der Stelle, sondern das ist halt sehr

darauf angelegt, dass es halt, ich meine,

Sachen einfach zu machen ist ein schwieriges Problem

und Computing

ist ein schwieriges Problem.

Das wird so nicht halt für jeden zugänglich sein,

aber es ist halt, wenn ich die Sprachmetapher

nochmal bemühe, wenn du halt das Unternehmen umstellst

von Deutsch auf Englisch, dann erwartest

du ja auch nicht, dass jeder danach

ein englischer Schriftsteller ist.

Sondern der Wort ist, dass die Leute halt so ein gewisses

robustes Set an Sprache halt

können, mit dem sie halt

wissen, ah, der Empfang kann zumindest mal sagen,

wo die Toilette ist und wo es in die Chefetage geht

und kann dir ein Taxi rufen.

Kantine. Ja, Kantine,

auch noch wichtig, genau.

Aber es ist halt was anderes,

als wenn du dann sagst, wir bringen jetzt das Unternehmen

auf Englisch, indem wir halt überall Wörterbücher auslegen.

Ja.

Das ist halt. Das funktioniert

halt einfach nicht, ja.

Okay, spannend, spannend.

Ja, aber ich glaube, von diesem generellen Problem der Digitalisierung würde ich uns jetzt mal so ein bisschen wieder wegführen, weil wir können das, glaube ich, heute auch nicht mehr reden oder wir können zumindest noch mindestens zwei Stunden darüber reden, was das alles für Fragen ist.

Okay, dann mache ich jetzt hier direkt mal eine Kapitelmarke, aber ich würde auch noch gerne eine Sache ansprechen, wo es, ich glaube, da ging es kurz eben drum, aber ich habe es nicht geschafft, da reinzugrätschen.

Aber nur ganz kurz, weil wir wollen dann auch erklären tatsächlich, wie man das mit Python so machen kann.

Ja, und zwar ging es da um die Bereiche, in denen Python eingesetzt wird. Ich weiß nicht, habt ihr das mitbekommen, die PyCon US war jetzt erst vor kurzem und die Keynote hat da, glaube ich, Russell Keyes McGee oder so gehalten.

Ich weiß nicht, ob ihr den Vortrag gehört habt.

Ich war im Urlaub.

Achso.

Nee.

Nee. Ich hab Kinder.

Ganz gute Entschuldigung.

Immer.

Was ich ja jetzt mittlerweile häufig mache,

ist, ich,

die laden ja meistens auf YouTube

und es gibt in meinem Podcast-Player irgendwie

so ein, der hat so ein Zeit-Loading

Share-Sheet-Extension-Dings

für iOS und dann sage ich auf dem

YouTube, auf der YouTube-Seite so

irgendwie, share das mal mit meinem

Podcast-Player und dann kriege ich das Audio halt dann als

normale Podcast-Folge sozusagen rein.

Und das ist ganz, ganz angenehm, wobei man dann halt auch merkt, dass die Audioqualität bei so Vorträgen oft auch nicht so toll ist.

Und naja, wenn man das Bild halt nicht sieht und die Folien, ist auch schon ein bisschen Information weg.

Also ganz toll ist es nicht.

Aber seitdem höre ich mehr Talks, weil ansonsten die Zeit irgendwie vorm Rechner zu sitzen und ein Video zu gucken, das ist einfach nicht.

Ich kriege das immer nur dann hin, wenn ich noch nebenbei was anderes mache.

Ansonsten funktioniert das irgendwie nicht.

Aber zum

Thema, das war ganz

interessant und zwar hatte der etwas angesprochen,

was man halt auch so als,

der kommt irgendwie aus Australien,

nach dem Taleb hat man ein Buch geschrieben,

The Black Swan, und

genau, das mit den schwarzen

Schwänen ist auch so ein Ding, was in Australien halt da mal

aufgefallen ist, man dachte halt bis irgendwie

vor ein paar hundert Jahren, also bis halt Australien

irgendwie so richtig entdeckt war, dass es nur

weiße Schwäne gäbe, weil man hatte noch nie einen schwarzen

gesehen, aber in Australien

gibt es tatsächlich wohl schwarze

schwarze Schwäne und

ja, dann, als die

zum ersten Mal jemand gesehen hat, dann

war sozusagen diese Theorie, dass das

dass alle Schwäne weiß sind

halt auf einen Schlag erledigt und

das sind solche Sachen, die passieren halt

ab und zu und die kann man sehr schlecht

vorhersagen und das, ja,

solche Ereignisse gibt es ja halt nicht nur in der Natur,

wenn man Natur beobachtet, sondern halt auch

in diversen anderen Bereichen, es gibt halt irgendwelche

Finanzkrisen oder so, die auftreten können,

wo man halt vorher gedacht hat, das geht jetzt immer

so weiter und

naja,

der sprach halt über

diese Ereignisse, die halt passieren können

und was das für Ereignisse

sein könnten, die

Python, ja, sozusagen

vielleicht obsolet machen oder schwer

sozusagen, ja,

beeinflussen könnten und die man momentan

nicht so richtig kommen sieht, weil

auch im IT-Sektor ist das natürlich

schon ganz oft passiert, irgendwie so der

PC, der irgendwie aufgetaucht ist, war wahrscheinlich

für viele Unternehmen, die vorher ganz gut mit

Ningen gelebt haben,

so ein schwarzer Spahn, der

aufgetreten ist und dann plötzlich die ganze Märkte kaputt gemacht hat

oder irgendwie, ja,

Smartphones sind halt auch sowas,

die den ganzen

PDA-Markt irgendwie aufgerollt

haben und Nokia irgendwie

sozusagen in die, naja,

in den, ja, wie soll man,

Microsoft-Vorruhestand geschickt haben und

dass der sagte, also man

kann inzwischen sehen, was das sein könnte

und für ihn ist halt interessant rauszukriegen,

was man dagegen tun kann und

er meint, dass wäre halt zum Beispiel

eine ganz schlechte Geschichte

ist, dass halt eben auf solchen Geräten wie Tablets,

irgendwie Telefonen oder so, halt

Python nicht wirklich läuft

und dass wenn jetzt aber der

Markt so umkippt, dass halt irgendwie

Desktop-Computer und auch Laptops nur noch was für

Profis sind und

ja, die ganze

Konsumenten, der ganze Konsumentenmarkt halt

auf irgendwelchen

Tablet- oder Smartphone-mäßigen Endgeräten

ist, dann kann es sein, dass das

ein sehr großes Problem wird, dass da

Python halt überhaupt, dass man mit Python überhaupt

nichts machen kann.

Und dass es halt auch ein Riesenproblem ist, dass das halt auch nicht

sich überbrücken lässt durch irgendwie solche Sachen wie

Web oder so, weil JavaScript wird das

wahrscheinlich überleben. JavaScript läuft

halt in Browser, Browser sind auch von den Geräten

nicht wegzudenken, aber

Python läuft weder im Browser noch.

Ja, wobei, was

mir da mehr durch den Kopf geht, ist, dass

ich glaube, wir werden dann eher sehen,

dass es noch

tatsächlich diese agnostischen Runtimes

geben wird. Also bei Web

fällt mir gerade eben WebAssembly ein.

Das

finde ich blöd aus einer anderen

Perspektive, weil dann ist halt ViewSource

endgültig kaputt.

Das ist was, womit

ich halt

auch wieder aufgewachsen bin. Allein das

hat es mir ermöglicht, irgendwie vernünftig

das Zeug überhaupt zu lernen, dass man in Sachen

reingucken kann. Aber

sei es mal gespenkt.

Man kann in jede Webseite reingucken

und sich angucken, wie das geschrieben ist.

Ja, genau.

Das war halt, wobei das auch heute eigentlich,

es ist praktisch

tot durch

Minifizierung etc. Ich meine,

mit dem Inspector kriegst du dann halt, wenn Mappings da sind,

beziehungsweise auch noch die Minifier

und so ein Zeug, aber es ist praktisch

eh tot, weil die Komplexität zu groß ist. Früher war es

so, da hast du halt mal deine 10K, 20K

HTML-Code, bloß ein bisschen JavaScript

angeguckt und, ah, guck mal, der benutzt das so und so.

Die Doku war früher auch

schlechter, heute ist die Doku besser, dadurch

dämpft das halt vieles wieder.

Ich glaube aber, dass solche agnostischen Runtimes, also

zum einen, naja, Profi

ist halt jetzt wieder, machen wieder die Schleife.

Wenn nur

die Profis Software entwickeln sollen

und Python kommt eigentlich eben aus der Ecke,

dass nicht nur die Profis das können sollen,

weil ansonsten haben wir

ja als Gegenentwurf eben

in der Android-Ecke haben wir Java und Java

kommt halt aus diesem extrem ingenieursartigen

Ansatz für, da ziehst du dir

bitte einen Laborkittel an, bevor du anfängst zu programmieren

oder sonst hältst du das nicht aus.

Du hast doch keinen Kittel angefangen, bevor du angefangen hast.

Ja.

Also das ist ja so

Business-Programmieren, ja. Da stellt man sich

die Leute vor, die im Laborkittel programmieren und jetzt

halt mal ordentlich hier, das ist der deutsche Ingenieur,

jetzt kriegst du gleich Qualitätssoftware, wenn du nicht aufpasst.

Die, ähm, und Python

kommt ja von einem anderen Ende und Python kommt eigentlich von

einem sehr charmanten Ende, nämlich, dass es halt so zugänglich

ist für Leute, die halt Quereinsteiger sind, die

noch selber Schüler sind und

auch da wieder in einer komplexen Welt ist,

lernen durch Experimentieren, durch

Experimentieren halt eigentlich genau das

Richtige, Grenzen austesten. Und dafür

musst du dir aber sozusagen eine Umgebung,

einen Weg bereiten und sagen, hier ist

irgendwie erstmal so grüne Wiese,

lauf mal los, guck mal. Systeme

wie Java sind halt wenig ein, hier ist grüne

Wiese, sondern es sein, so hier kommt jetzt erstmal

das große Konstruktionstemplate und

ohne das kannst du nichts tun.

Mir fällt gerade auf, dass der Christian gerade zum ersten Mal

den Java Bash gemacht hat, auf den ich die ganze Zeit gewartet

habe, den wir in Zeitfolge 1 vorgenommen haben.

Ah, bitteschön. Danke.

Es ist die zehnte Episode.

Und ich meine, Java

leidet an der Stelle, also die leiden ja

selber unter ihrem Erfolg an der Stelle,

weil es war ja

gemacht von

Sun mit ein bisschen IBM-Unterstützung

damals, mit

der Idee, dass Entwickler

zu teuer waren.

Ja, also es gibt die eine Story, das ist eine, also es gibt ja mehr Perspektiven da drauf. Das eine ist, es sollte mal dieses Set-Top-Boxen-System sein, Mitte der 90er. Dann wurde es irgendwann zu so einem Server-System, dann wurde es irgendwann zu der Universalen.

Ja genau, das was heute ein Apple TV ist, wo man halt sich in den 90er Jahren das erste Mal die Finger dran verbrannt hat. Das sind ja häufig so Embedded-Geräte, wo jeder den kompletten Software-Stack mit Betriebssystem selber gebaut hatte und Sun hatte damals mit Java versucht eine Sprache zu bauen, wo ich die gleiche Programmiersprache halt über unterschiedliche Geräteklassen hinweg eben von Mobiltelefonen zu Servern zu Desktop-Rechnern zu Set-Top-Boxen anwenden kann, um die zu programmieren.

Und ja gut, also jeder, die mal gesehen hat, irgendwie auch dieses Ding von der Telekom hier, diese komische Fernsehgeschichte, die die haben, da kriege ich immer das Gruseln, wenn ich sehe, wie das UI aussieht dazu, weil es halt, ja, weil dort das ganze Ökosystem ist durchdrungen von diesem Ingenieursansatz, ja, von diesem, du musst alles ausdefinieren und aber die wirklich interessanten Sachen, sowas wie, dass das UI geschmeidig ist, das kommt als letztes.

Und dann stellst du fest, oh, unser UI-Toolkit kann gar keine schönen Übergänge, sondern das geht bloß so hackelig.

Warte mal, wir kamen von, was hat Python für eine Zukunftsperspektive?

Python ist ja als Sprache eh darauf angelegt,

eine Sprachspezifikation zu sein und

sich unterschiedlichen Runtimes

gut halt anzudienen und ich würde

vermuten, dass irgendwann

der Zeitpunkt, also wir haben halt eben zum

einen, Web könnte für Python

halt mit WebAssembly durchaus interessanter werden

und auf der anderen Seite

werden wir

eine Lösung brauchen, wie

solche Endgeräte,

die sich ja zum Programmieren auch gar nicht

eignen,

Und das ist sozusagen auch eine ganz eigene Schleife zum Thema Digitalisierung und Selbstständigkeit von Anwendern. Da ist ja auch die freie Softwarebewegung als Ganzes im Prinzip dran, dass du sagst, hey, ich will eigentlich, dass die User emanzipiert sind und dass ich nicht um Erlaubnis fragen muss, um Software zu modifizieren oder Software zu verstehen, sondern dass ich halt eben genau Emanzipation mit Kompetenz auch gleichsetze an der Stelle.

Ja, interessanter Gedanke.

Ja, das wäre auf jeden Fall sehr schön.

Momentan geht es leider so ein bisschen in eine andere Richtung.

Ja, aber ich glaube,

dass Python da definitiv halt massive

Chancen hat, aufgrund der Größe,

aufgrund der Erfahrung auch und aufgrund

dem Fokus halt als eine freie Sprache,

die sich so flexibel

halt in unterschiedlichen Kontexten halt

einsetzen lässt.

So, aber jetzt endgültig,

und jetzt fangen wir an zu erklären,

wie man das mit Python alles so

insgesamt machen möchte, wenn man sowas

DevOps'en

möchte.

Was macht man denn da? Was ist das überhaupt?

Vielleicht fangen wir damit nochmal ganz kurz an, aber diesmal

jetzt so vielleicht ein bisschen kompakt.

Wer möchte zuerst?

Ja, ich kann ja einfach mal

genau,

ich habe eben schon mal so kurz überlegt,

wie man das irgendwie

anfangen

könnte und ich dachte, naja, also

vielleicht einfach

in der Differenz

zu anderen Geschichten, die es halt schon lange gab, die Leute

vielleicht auch kennen, ich weiß nicht so genau.

Aber so früher war das ja

so, dass wenn man jetzt, also

ich nehme jetzt mal den Bereich,

man möchte jetzt eine Webseite irgendwie haben,

die irgendwo online

zu sehen ist, die man nicht nur lokal irgendwie

anguckt, da kann man auch einfach ein HTML-File

von einem Editor hinschreiben und dann

guckt man sich das mal um. Webseite mit Service, also jetzt nicht nur

meine Visitenkarte. Das kann auch

einfach nur ein HTML-Datei sein, aber die

kann ja jemand anders noch nicht sehen, nur wenn

ich sie auf meinem Rechner mit dem Editor

abgesorgt habe, dann sollten

andere Leute die ja hoffentlich erstmal so nicht sehen können.

Die Frage ist halt, wie kriege ich das hin, dass das Ding

zum Beispiel weltweit dann halt

sichtbar ist. Und

wenn man jetzt

die ersten Geschichten, die es da gab,

auch Ende der 90er

irgendwie PHP und

irgendwie FTP-Server oder so, da haben

Leute irgendwie

quasi so eine Web-Route in einem

Apache gehabt und dann haben sie da irgendwie

PHP-Sachen per FTP hochgeladen und dann war das

irgendwie dann deployed,

sozusagen. Vielleicht kennt man das.

Ich war sehr überrascht, als ich letztens gesehen habe, dass Leute

das heutzutage immer noch so machen.

Ja, sie machen es.

Es ist immer wieder...

Also, ja.

Sie sterben nicht aus.

Ja, auf der anderen Seite muss man halt sagen,

dass es halt so, auch wenn es

aus diversen

unterschiedlichen Gründen halt eine sehr problematische

Geschichte ist, das so zu machen, es ist

halt irgendwie so ein definierter Weg. Die Leute haben sich

irgendwie reingewöhnt. Es gibt viele, die kennen überhaupt nichts anderes.

Und es ist halt so ein Standardweg,

wie deployed man jetzt irgendwie

Software mit PHP

irgendwie, wenn man das jetzt... Funktioniert.

Ja, naja, für

bestimmte Werte von

Funktionieren.

Und diese

Geschichte so, wie macht man das jetzt eigentlich,

wenn man das tun will, gab es für Python

sozusagen nie. Und das ist

jetzt halt für Python dann irgendwie, gibt es

halt sehr viele unterschiedliche Arten,

das zu tun. Und

ja, den Leuten ist nicht so richtig bewusst, wie das

dann überhaupt gehen soll und was irgendwie

dann so ein bisschen dazu führt, dass sie oft gar keine

Vorstellungen davon haben, wie man das dann

macht und

das dann halt auch nicht so richtig tun.

Das Schmeinende daran ist, man kann

jetzt sozusagen mal den Bogen, du hast jetzt wirklich

das abschreckende

90er-Jahre-Beispiel ins eine Ende gestellt.

Ich meine, der Extremwert von dem, was du

beschrieben hast, ist ja noch, ich kenne auch die Leute,

die haben das FTP gemountet und editieren

halt dann mit ihrem Editor direkt

auf dem, ja genau.

auch die existieren noch und

ich durfte auch schon, ich glaube, wir durften

letztes Jahr auch schon mal aufstehen und

irgendwie kaputtgegangene Seiten reparieren, weil

irgendwie sein Editor nicht ordentlich zugemacht hat.

Das andere Ende davon ist ja jetzt sozusagen,

wenn man sich heutzutage fragt,

wenn man das Thema abhaken will,

dann sage ich jetzt Docker und dann ist irgendwie

alles vorbei.

Also das würdest du sagen, also eben das Best Practice,

dass wir jetzt die Antwort hätten.

Nee, überhaupt nicht. Nein, gar nicht.

Weil das halt,

weil Docker jetzt erstmal ja nur

ein, auf der einen Seite

hast du eine Lösung, die ist sozusagen so

grottig auf so vielen Enden, dass

die Leute, die sie einsetzen, noch nicht mal verstehen,

warum es schlecht ist.

Und am anderen Ende hast

du ein Ding, das als Totschlag

Variante macht, dass man auch

nicht mehr versteht, warum es jetzt gut ist.

Also Docker hat halt

löst wahnsinnig viele Probleme, die es da

so gibt und hat, bringt halt

eigene große Komplexität mit

und

was ich halt spannend finde, wenn wir das Wort

DevOps eigentlich nehmen, dann kommen wir

halt in so einen

auch mit agil, ich muss jetzt meine Buzzword-Matrix

irgendwo aufmachen,

dann kommst du halt aber in

dieses Thema von, wie arbeitet man eigentlich

in Teams gut zusammen, weil

wenn ich meine Software alleine baue und ich habe

meine drei, vier Privatprojekte,

dann kann ich halt irgendeine technische

Lösung nehmen, die mir für mich

alleine löst, dass ich mir

nicht auf die Füße trete. Die kann so klein oder so

groß sein, wie ich es halt gerade vertrage.

Wenn ich aber das Thema habe,

dass ich eben nicht mehr alleine bin, sondern

dass ich halt mehrere Leute habe, die

entwickle oder halt unterschiedliche Zuständigkeiten,

dass ich mir vielleicht auch mal für

bestimmte Themen, gerade

ich mache die kurze Schleife zur Digitalisierung,

wenn ich halt eben auch Software für mich

entwickeln lasse, das heißt, ich habe halt irgendwem,

dem gehört die Software vielleicht nachher, aber

irgendwer anders, irgendeine Agentur oder irgendein Freelancer

oder ein Team entwickelt das für mich und dann

habe ich noch irgendwen, der soll das

irgendwo betreiben und

Das wird halt alles relativ schnell komplex und dann ist halt die eigentlich interessante Frage von, was sind denn für solche Szenarien interessante Arten, wie man da zusammenarbeiten kann.

Weil, wenn man jetzt mal das FTB-Beispiel weglegt und sagt, wie war es sonst im großen Umfeld vielleicht, im professionellen und nicht so in diesem semi-professionellen Umfeld, dann gab es da früher immer diese Metapher des Software-über-den-Zaun-Werfens.

Das sah dann ungefähr so aus, du programmierst dein Kram runter, packst das alles in eine kleine Kiste, also zum Beispiel ein Tarball oder CVS und danach schreibst du ein Readme und das Ding zusammen, also der Lieferschein und diese kleine Kiste, wirfst du über den Zaun, am anderen Ende steht schon irgendein Admin, der sammelt das dann ein, packt das wieder auseinander, geht dieses Readme durch, stellt fest, dass das vorne und hinten nicht funktioniert.

Und der Prozess war aber definiert, siehe Wasserfall-Methodik und so, von, wenn ihr fertig mit dem Entwickeln seid, dann gibt es halt den Admins. Und in einer komplexen Welt hast du halt eben nicht mehr solche ganz klaren, harten Interfaces zwischen Leuten.

Hat der gerade Agile gesagt oder was?

Oder warst du ja gerade beim Buzzword-Bingo?

Ja, ja.

Agile ist schon eine Weile her.

In einer komplexen Welt hast du halt das Problem,

dass du die Schnittstellen zwischen unterschiedlichen Leuten,

unterschiedlichen Teams, unterschiedlichen Prozessen

halt nicht mehr so glatt definieren kannst à la

ihr arbeitet bis hierhin und das Werkstück, was da rausfällt,

gebt ihr dann dem Nächsten.

Also das kannst du machen, wenn du Auto baust.

Und Autobauen ist halt tatsächlich ein Ding,

das können wir heutzutage ingenieursmäßig machen

eben, dann weißt du, es gibt die

Station, der dreht die Schrauben rein, dann wandert das

Auto selbstständig zur nächsten Station,

der dreht die anderen Schrauben rein, der nächste macht den

Spiegel dran und so, alle,

da muss keiner mehr miteinander reden.

Ja, wobei, wenn ich

dann noch mal so kurz abschweifen darf, ich

Bitte, bitte.

Also das, was wir sozusagen

dann als Agile

Methoden ja dann in der Softwareentwicklung

irgendwie gesehen haben, das kommt ja ursprünglich

daher. Ich fand das

letztens beim Abendessen

haben wir dann mit

bekannten

Freunden gesprochen und einer von denen kam

halt aus der

Automobilindustrie und beschwerte sich bitterlich,

was denn dieser komische neue Trend

sei, der da irgendwie jetzt über sie

hereinbräche. Irgendwie dieses

ganze komische Agile-Zeugs

und dass es da irgendwie, dass

jetzt plötzlich irgendwie eine tausendmal

Entwicklungsabteilung irgendwie Agile-Dinge

machen sollte und dann machen halt alle,

wird die in Teams aufgeteilt und die machen dann halt alle

irgendwie Dinge in unterschiedliche Richtungen

und es passt nichts mehr zusammen, alles ganz furchtbar.

Und das fand ich irgendwie

witzig, weil eigentlich kommt das ja

aus der Automobilindustrie.

Ja, Toyota.

Ja, nee, nee, Moment.

Nein, da muss ich reingrätschen.

Nein.

Du hast zwei Sachen. Du hast Agile auf der einen Seite

und du hast Kanban auf der anderen.

Und Kanban, das sind

ähnliche Konzepte. Kanban ist das, was

Toyota stark gemacht hat.

Das ist tatsächlich, es kam aus

so einem produktionsorientierten Thema

und Produktion hieß

an der Stelle tatsächlich eine Flussoptimierung,

dass du machst,

dass das, also

wenn du so eine Werkshalle hast mit

Autos und dieser

Straße, dieser Fertigungsstrecke,

dann wandern die Autos

halt schön durch und ein Thema ist immer,

dass wenn da irgendwas blockiert,

dann bleibt halt dieses ganze Band stehen.

Dann hast du ein sogenanntes

Stop-the-Line, Head-of-Line-Blocking auch,

es geht hier hinten nicht weiter, bevor es da vorne nicht

weitergeht. Und

Toyota hat ja tatsächlich

sich Methodiken zurechtgelegt,

um

die Planung

von diesen Abläufen

möglichst gut zu machen.

Da gehört Can-Band unter anderem mit dazu.

Can-Band ist eine Abstraktion von so einem

Fertigungsstraßending,

wo du halt sowas hast wie, du hast bestimmte Schritte,

die werden nacheinander durchlaufen und in jedem

Schritt dürfen nur maximal so und so viel gleichzeitig

sein, weil ansonsten verlieren die Leute sich

halt im Threshing, weil sie ständig Kontextwechsel machen müssen

und so. Das ist halt mehr das

Thema, wie kann ich Durchfluss optimieren und das

geht aber nur, wenn ich möglichst

einheitliche, möglichst gleichförmige Arbeitsschritte

habe.

Wenn ich zu viel unterschiedliche

Arbeitsschritte habe und deswegen ist Softwareentwicklung

Agile im Prinzip anders, weil du hast

völlig unterschiedliche Sachen, die du zwischendurch machst.

Auf der einen Seite von UIs

zu Features, zu Bugs, zu einem

großen Architekturthema, zu einem kleinen

Usability-Thema. Das geht so alles quer durcheinander

und bei Canban willst du aber eigentlich, dass

jedes Teilchen möglichst

eine einheitliche Größe hat,

damit du darauf, auch über diese,

ansonsten würde nämlich die Regulierung

der Work-in-Progress-Anzahl von Kärtchen

gar nicht helfen,

wenn du gar nicht weißt, wie groß das Kärtchen ist.

Klar, okay, ja.

Deswegen sind das so zwei, die sind nicht unabhängig,

also die kann man unabhängig

und zusammen komplementär einsetzen, aber die haben

unterschiedliche Eigenschaften. Agile

war ja eher dafür gedacht,

um

die User und die Entwickler

näher aneinander zu bringen,

also das ist eher ein Thema von Disintermediation,

dass du nicht möchtest,

dass die so weit auseinander sind,

dass sie keine gemeinsame Sprache sprechen.

Und das Interessante bei Agile ist,

weil ich habe das in letzter Zeit auch mal wieder da gehabt,

dass du, wenn man das Manifest nochmal rausholt

und diese ur-ur-ur-alte Seite

und die haben ihr HTTPS nicht im Griff,

dann ist es halt sehr knapp.

Es ist halt People over, jetzt muss ich es selber halt raussuchen,

das war People over Processes, Working Software over Comprehensive Documentation,

Collaboration over Contract and Negotiation, Responding to Change over Following a Plan.

Und das Dumme ist, das sind Techniken, die waren entwickelt worden,

ich glaube, das war ein Chrysler-Projekt und das ist eigentlich gar nicht so gut,

aber die Techniken an sich haben sich halt durchaus als hilfreich bewiesen,

dass diese vier Grundsätze ja die Entwickler und die User enger aneinander bringen sollten,

um die Realität schneller sichtbar zu machen.

Ansonsten kannst du halt über Dokumentationen, Prozesse und Vertragsverhandlungen und Plangestaltung

kannst du die Realität dermaßen verzerren, weil du hast halt so viele Ebenen von mittlerem Management

und halt eben Mediation dazwischen, dass du hast halt stille Post vom Anwender bis zum Entwickler.

Und damals wurde ja auch immer gesagt, die Anwender sollen nicht

mit den Entwicklern reden. Und ein

großes Problem, was die Agile-Community

hat, meiner Meinung nach, ist, es war eine

Team-Methode, die war nie dafür

gedacht, auf ganze Unternehmen angewendet

zu werden. Also die war

gedacht für so 10 bis 15 Leute.

Ja, genau.

So man sagt auch oft,

bei neun Leuten ist bei einem Team dann irgendwie Schluss.

Und irgendwie so eine überzeugende Antwort darauf,

was man denn jetzt macht, wenn man Projekte hat,

die sich mit neun Leuten halt nicht

stemmen lassen,

habe ich auch nie so wirklich gehört.

Ja, aber ich meine...

Mach es kleiner.

Genau, du musst es halt...

Mach es kleiner.

Du teilst dann die einzelnen Teams auch, ne?

Du machst dann ein Team,

was für das spezielle Projekt ist.

Du machst dann ein eigenes Team,

einen eigenen Raum.

Die haben ihre eigene Peergroup,

ihre eigenen Stakeholder.

Du musst dann gucken,

wie sich damit klarkommt irgendwie, ne?

Aber das Interessante an der Stelle ist,

jetzt hat man halt versucht,

dann irgendwie da drumherum

ein Gesamtframework,

das heißt dann entweder Scaling Agile

oder Scrum oder was auch immer,

ein Gesamtframework zu bauen,

was Unternehmen halt kaufen können.

Und es ist aber ein massiver Unterschied, ob ich ein Team habe, was aufgrund so einer Methodik, Methodology mit kleinem M, arbeitet und verstanden hat,

dass diese Aussage zum Beispiel ist, wenn man das Manifest noch eins runterkochen will und sagt, diese vier Sätze sind mir zu viel,

dann ist die eigentliche Ansage, liebes Team, du hast nicht nur eine Verantwortung, Software abzuliefern,

sondern du hast auch eine Verantwortung dafür,

den Prozess zu guter Software zu kommen,

selbst zu gestalten.

Und wenn ich dann aber im Gegensatz dazu

heutzutage immer mal in irgendwelchen Runden bin,

wo irgendwelche Entwickler sich selbst als,

ja, ich bin ja nur ein Entwickler,

bezeichnen, denke ich mir so,

ey, mein Kindheitsherz bricht gerade,

weil die Softwareentwicklung selber war das,

was, als ich groß geworden bin, war mit,

hey, da ist doch die ganze Power,

das ist doch was, was attraktiv ist,

da ist die Gestaltung

und nicht in irgendwelche Leute

lassen dich nur noch Tickets abarbeiten.

Ja, ich

finde das auch immer total seltsam, wenn Leute da so

sich so zurückziehen

auf so eine

ganz, ganz enge Funktion.

Ich kann

das auch nicht so richtig, aber es gibt das natürlich durchaus

und es gibt auch Leute, die sich total unsicher fühlen,

wenn sie dann halt da irgendwie

mit Fragen konfrontiert werden,

die sie jetzt nicht kompetent

fühlen.

Und dann probieren wir mal die Schleife zum DevOps zu machen. Jetzt hast du also mit agilen Methoden eigentlich eine Ansage von, hey Jungs, ihr müsst euch halt Gedanken machen, wie man vernünftig zusammenarbeitet.

Ich komme immer mal wieder jetzt mit diesem komplexe Welt Thema und ich mache einen kurzen Aufschlag zu, was heißt komplexe Welt. Komplexe Welt heißt, wir haben Beziehungen zwischen Dingen, die wir nicht vorhersagen können.

Du kannst die Welt einteilen, kannst Systeme einteilen.

Das ist halt wieder das Kinevin von Dave Snowden.

Ja, der macht irgendwie Unterschiede zwischen kompliziert, komplex und chaotisch.

Genau, genau.

Das ist deine Theorie, an der er seit 30 Jahren arbeitet.

Und die nimmt jetzt gerade auch ganz gute Formen an, dass er sie finalisiert.

Der unterscheidet Systeme in Unterschied.

Du kannst es als Typologie benutzen, du kannst es als Klassifikationssystem benutzen,

Du kannst es aber auch als exploratives Werkzeug benutzen.

Und er sagt halt, es gibt zum einen geordnete und ungeordnete Systeme.

Und geordnete Systeme sind die, wo Ursache-Wirkungs-Prinzipien halt vorhersagbar sind für uns Menschen.

Die kannst du nochmal unterteilen in offensichtliche Systeme.

Das heißt, du brauchst kein Fachwissen, um eine Vorhersage zu treffen.

Beispiel, ich lasse mein Glas runterfallen und dann ist da eine Pfütze auf dem Boden.

Da weiß ich halt auch ohne Fachwissen, ich hebe das jetzt auf, wische das weg.

wenn es gesplittert hat, hole ich noch einen Staubsauger.

Da brauche ich nicht groß irgendwie

Analyse betreiben.

In solchen Umgebungen

kannst du halt auch zum Beispiel... Es gibt Unternehmen, die machen

genau sowas. Die kaufen sich da ein neues Glas und

auf dem Boden stammeln sich immer mehr Scherben an.

Ja, genau. Kann man machen.

Denn dann

kompliziert ist, wenn du

für Vorhersagen

in einem System

Analyse betreiben musst. Wenn du sozusagen

einen Fachmenschen brauchst,

Der sich ein Problem nimmt und sagt, okay, was sind denn hier jetzt die Parameter, da gehören zum Beispiel sowas wie, jetzt beim Hausbau ein Statiker, ein deutscher Ingenieur, die sind genau für sowas gut.

Den gibt es ein Problem, was man nicht auf den ersten Blick erkennt, aber wo du weißt, der setzt sich jetzt hin, das dauert dann 10 Stunden, dann rechnet er das durch und dann kommt dein Ergebnis raus.

Der kann dir das Ergebnis nicht vorab sagen, aber er weiß, wenn er das jetzt macht, dann kommt er halt am Ende raus.

Und er weiß, wie wird die Tragfähigkeit von dem System sein, bevor ich es baue.

Kompliziert wiederum ist der Fall, wenn ich Ursache-Wirkungs-Prinzipien eben nicht vorhersagen kann, aber zumindest die Chance hätte, es im Nachhinein zu erklären. Wenn ich nicht mal die Ursache-Wirkungs-Prinzipien im Nachhinein erklären kann, dann sind wir in den sogenannten chaotischen Systemen. Dann habe ich gar keine für Menschen entdeckbaren Zusammenhänge mehr.

Und es gibt unterschiedliche Handlungsstrategien für diese unterschiedlichen Systeme. Und im komplexen, jetzt muss ich versuchen die Schleife wieder hinzukriegen, wo ich gerade abgeschwiffen bin, in der komplexen Welt ist es eben so, dass ich diese Ursache-Wirkungs-Prinzipien eben nicht vorhersehen kann.

Und deswegen ist das der Grund, warum starre Methodiken, starre Formen der Zusammenarbeit, starre Formen der Planentwicklung dort niemals funktionieren werden. Und die Leute wundern sich immer, die wenden Techniken an aus einer analytischen Perspektive und sagen, das musst du ja einmal runter definieren, hab aber ein komplexes System und wundern sich dann, warum es nicht funktioniert.

Und die typische Antwort ist dann ja, wir müssen das nächste Mal einen besseren Plan machen, wir müssen das nächste Mal noch genauer hingucken. Und dabei ist die Aussage, nein, die Welt ändert sich um dich drumherum, während du mit ihr interagierst und sie zeigt sich dir nicht in ihrer Fülle.

Und das ist so ein massiver Unterschied, weswegen dann nämlich agile Methoden oder DevOps immer mitbringen, du musst die für deinen Kontext, also Kontext ist ein angemessene Kombination herstellen und dafür brauchst du aber eine Auswahl an unterschiedlichen Methodiken, eine Auswahl an unterschiedlichen Fertigkeiten, unterschiedlichen Werkzeugen.

Und deswegen ist sozusagen beide Extreme, wenn wir drüber reden, FTP-Deployments oder Docker oder Kubernetes eats the world, beide Extreme sind nicht gesund. Beides sind halt Werkzeuge, die kontextabhängig sind. Docker und Kubernetes ist, also gerade Kubernetes ist halt ein riesengroßes Tier. Das ist halt vielleicht nicht angemessen, wenn ich Embedded-Systeme mache, weil ich halt nicht 20 Gigabyte in meinen armen kleinen Raspberry Pi reinkriege.

Und dafür aber dann halt zu wissen, was sind denn auch die Grundlagentechniken, damit alle, die beteiligt sind, halt Entwickler, User, Businessleute, Opsleute, dass die halt sich in einem Projekt auch zusammenfinden und sagen, so, was ist denn hier jetzt die richtige Kombination für jetzt?

Weil auch die Zeit ist ja wieder ein Faktor

da dran. Man fängt ja mit Projekten an und will

erstmal was basteln und

das ist eben wieder dieses Thema im Komplexen.

Du willst so schnell wie möglich experimentieren,

Ende, Ende, sehen, was tut meine Software

eigentlich? Kann mein User damit

irgendwas anfangen? Und da sind wir wieder beim Agilen.

Warum machen wir eigentlich kleine Zyklen?

Naja, weil ich so schnell wie möglich vom User

rausfinden möchte, ob ich überhaupt in die richtige

Richtung entwickle. Ja, Learn, Process, Learn, Process.

Genau. Ja, genau. So ein bisschen

Trial and Error halt.

Ja, ja, auch Sachen wegwerfen.

Und ein ganz interessantes Thema halt aus der Komplexität dabei ist wieder, wenn du nicht an die Grenzen kommst, wenn du keine Fehler machst, und das erklärt sich für mich, was bedeutet Fehlerkultur eigentlich, das ist nämlich völlig fehlverstanden, das heißt nicht, ah, man macht was falsch und dann geht was kaputt und deswegen sind wir jetzt alle nicht sauer auf dich, sondern wir müssen eigentlich vorher einen Plan machen, in einer Umgebung, die wir noch nicht vollständig erfasst haben, die Grenzen zu finden.

Und wie finde ich eine Grenze? Indem man was kaputt gehen lässt. Indem ich was kaputt gehen lasse, weil dann weiß ich nämlich, ah, bis hierher und nicht weiter. Wenn ich die nur nie austeste, dann haben Menschen auch einen, die Menschen, ich bin kein Roboter, dann haben Menschen das Problem, dass sie gerne linear denken und dass sie denken, ah, guck mal, das ging jetzt mit 5, das ging jetzt mit 10, ja, dann geht es halt auch mit 20, 40 und 100.

dass dann aber vielleicht bei

elf

eine abrupte Grenze kommt, wo es halt gar nicht mehr geht,

das können wir eben nicht vorhersagen. Das ist wieder der Black Swan

auch, den du halt hattest.

Und auch

Taleb im

Black Swan argumentiert ja für

den Longtail. Die Menschen

unterschätzen den Effekt der Risiken

eines Longtails. Die Fläche

in dem Rattenschwanz,

der nur sehr selten kommt,

ist in Summe aber sehr groß.

Und deswegen sind die Wahrscheinlichkeiten, dass

eins dieser unwahrscheinlichen Ereignisse

eintreten wird, auch extrem hoch.

Kann ja trotzdem einfach mal irgendwas twittern.

Ja, ja, ich finde dann auch die

Arten, damit umzugehen, interessant.

Also gerade bei Infrastruktur gibt es

da zum Beispiel bei Netflix gibt es da

den

Chaos Monkey. Genau.

Der halt dann einfach mal irgendwie

einen Dienst, der halt

irgendwie den Stecker bei Maschinen zieht

oder die einfach vom Netz trennt und dann

guckt man halt, ob die Infrastruktur

weiterhin lebt. Und wenn sie das nicht tut, dann hat man da irgendwas nicht

ordentlich gebaut, sozusagen.

Ja, und das Interessante bei, das unterstützt

ja diesen psychologischen Effekt. Das unterstützt

ja dieses, ja, wann kommt denn das schon mal

vor, dass so eine VM ausgeht? Und wann kommt denn das schon mal

vor, dass da eine Netzwerkverbindung hakelig ist?

Und wenn du das umdrehst und sagst,

das ist nächsten Dienstag,

dann

haben die Leute halt ein anderes Händel da dran.

Dann hast du nicht mehr dieses psychologische, ah, da kann ich

mich drum rum wickeln. Das ist DevOps.

Also dann solche Situationen herzustellen und

die ganze Zeit die Leute zu nerven mit

Szenarien, die in der Realität irgendwie

im Wahnsinn auftreten könnten und die man dann realisiert?

Nee, es ist eher, dass man

diese Dinge nicht so klar

voneinander trennen kann. Also auf der einen

Seite Softwareentwicklung, auf der anderen Seite

Betrieb

des Systems. Also früher,

klassisch war das halt so, Entwicklungsabteilung hat halt

die Software nach Spezifikationen

entwickelt, wie auch immer die aussah.

Und dann

eine IT-Abteilung war dann halt dafür zuständig,

also für Sicherheit, Skalierbarkeit

und dafür, dass das letztendlich irgendwo

dann läuft, zuständig.

Ja, die sogenannten nicht-funktionalen Anforderungen.

Ja, genau. Und

das ist aber schwer voneinander zu trennen.

Das ist halt...

Vor allem, wenn der Manager dann irgendwie kein

ITler ist wahrscheinlich.

Bei nicht-funktionalen Anforderungen denke ich mir halt

auch immer, zum Beispiel Performance,

da hieß es dann halt, wie groß

muss die CPU sein, wo das läuft.

Der Trick ist, wenn ich halt Blödsinn baue am anderen Ende

und eine Endlosschleife baue, dann kann die CPU

halt so schnell sein, wie sie will.

Das wird nicht funktionieren, genau.

Ja, genau, aber wenn man jetzt Systeme bauen will, die damit umgehen können, dass jetzt so irgendwie so ein Chaos Monkey ab und zu mal da irgendwie nicht deterministische Dinge ausfallen lässt, dann muss man sich halt auch nicht nur, dann reicht es nicht, sich sozusagen auf der IT-Ebene sozusagen damit zu beschäftigen, sondern dann muss man vielleicht auch die Software schon so bauen, dass sie damit irgendwie klarkommt.

Es ist vor allem extrem teuer, wenn du Sachen, also wie es halt immer auch ist mit dem Thema, wie teuer sind Bugs, je später du sie findest, desto teurer werden sie halt. Und so ähnlich ist es halt auch, wenn ich bestimmte Probleme wie Verfügbarkeit, Performance, Ressourcennutzung, wenn ich die versuche dann erst spät im Prozess, also irgendwo im Betrieb zu lösen, dann bin ich eigentlich nur noch dabei, Duct Tape rauszuholen.

Also das halt alles wieder zusammenzubinden, was vorne schon mal verrissen wurde. Das sehe ich relativ häufig. Also wir sehen halt immer wieder Anwendungen, die verbraten Unmengen an CPUs und RAM. Und wenn man dann halt feststellt, das hat irgendein Java-Entwickler gemacht, Java-Bashing, der tatsächlich nur irgendwie als Quereinsteiger mal so ein bisschen reingeguckt hat und von algorithmischer Komplexität keine Ahnung hat und sich da ein ON hoch 5 gebaut hat,

Dann kannst du schon sagen, ja, logisch, dass das explodiert, da brauche ich auch nicht noch mehr Hardware draufwerfen. Und beim DevOps dreht es sich jetzt eher darum, dass du zwischen Leuten, die halt operative Erfahrung haben und Leute, die Entwickler sind und diese beiden als Tagesgeschäft, also diese beiden als unterschiedliche Disziplinen wahrzunehmen, hat jetzt erstmal Wert. Häufig wird DevOps auch so aufgegriffen, dass man sagt, oh, jetzt machen die Devs irgendwie alles. Auch bekannt als NoOps.

Und die, ich fände es ja, diese Begriffe fallen ja gerne so aus einem von diesen Open-Source-Treffen raus.

Das Dumme ist, das nimmt irgendein Manager dann halt noch ernst.

Das sind eigentlich bloß immer irgendwelche Biersprüche.

Weshalb es so macht, die zu trennen ist, die haben völlig unterschiedliche Tagesabläufe, die Leute.

Also als Entwickler ist es schon so, ich brauche extrem hohe Konzentration

und will mich halt auf bestimmte Sachen, die ich entwickeln möchte, konzentrieren.

Und aus einer Ops-Perspektive hast du aber eher das Thema,

dass du eben reaktiv, auch Echtzeit-reaktiv,

auf das Verhalten der Anwendung reagieren können möchtest.

Und das sind zwei Sachen, die funktionieren nicht gut

an einem Tag in der gleichen Person, sagen wir es mal so.

Also du kannst es schon so machen, wenn ich einen Tag mache,

wo ich sage, ich entwickle jetzt wieder Software bei uns,

dann versuche ich es möglichst zu vermeiden,

dass ich irgendwie so OBS-Sachen mache, weil

OBS-Sachen sind Dinge, die können gerne

mehrere Stunden dauern, wo du immer mal nochmal hingucken

musst. Und irgendwie...

Und dann die grüne und dann bringt die blaue die ganze Zeit

und dann oh oh. Genau, genau.

Ja, ja.

Genau, genau. Und allein deswegen

macht es Sinn, das als unterschiedliche Rollen halt

auch aufzufassen.

Das muss ja noch nicht mal dann sein, dass eine Person

immer OBS ist, aber dass du halt zum Beispiel weißt,

das sind unterschiedliche Zuständigkeiten und ich muss mir das halt auch

unterschiedlich zurechtlegen. Insofern ist eine

mentale Separierung dieser zwei Rollen und die

auch so ein bisschen zu klären,

was haben die eigentlich zu tun? Erstmal

ganz sinnvoll. Und wenn du es jetzt über

DevOps als Portmanteau wieder zusammenklatscht,

bedeutet es halt nur, die beiden müssen

trotzdem in einem ständigen Austausch miteinander stehen,

im konstruktiven Austausch miteinander stehen. Auf der einen

Seite möchtest du, dass operatives Wissen

in Projekte reinfließt, während die anfangen.

Und auf der anderen Seite möchtest

du auch, dass Entwicklung,

es sind vier Sachen, also auf der einen Seite

willst du operatives Wissen in Richtung Entwickler

bei Projektbeginn haben, à la

okay, was wollten ihr machen, was wollten ihr für Tools

nehmen, ah, könnt ihr vielleicht statt der MySQL

über eine Postgres nehmen, könnt ihr vielleicht, was, wofür

nehmt ihr den Memcache, komm, nehmt ihr den Redis.

Da wundere ich mich auch schon manchmal, dass

das eine Ops-Aufgabe

ist, sowas zu unterstützen, weil eigentlich denke ich

mir so, hallo, liebe Entwickler, ihr müsst eure

Tools halt auch kennen, ja.

Aber anyway, die

war zumindest mein Entwickleranspruch

immer. Umgekehrt möchte ich, dass

Entwickler wissen, von wie tickt diese

Anwendung intern eigentlich, und da finde

ich auch so Sprachen wie Python zum Beispiel angenehm, wo

du den Source-Code eigentlich immer gleich zur Hand hast,

dass die Ops halt mehr Einsicht kriegen in

was macht die Anwendung hier eigentlich? Ist das hier

gerade ein Bug? Ist das Absicht? Was tut denn das?

Also wir holen da halt gerne dann auch mal gleich den

Code raus, um zu sehen, warum rechnet

der hier? Ah, guck mal da drüben.

Und dass diese Form von Austausch halt

dann auch macht, dass Ops zum Beispiel mehr lernen,

okay, was brauchen Entwickler eigentlich aus der

operativen Perspektive? Und wenn die Entwickler

das dann halt mitgekriegt haben,

wie ist denn das mit dem Ops, dass die dann halt besser wissen,

ah, guck mal, wenn wir folgende Dinge tun, dann bauen

wir uns halt schon unser eigenes Grab und ich

vermeide jetzt halt wieder bestimmte...

Ja, ein beliebtes Beispiel ist halt

irgendwie, du renderst irgendeine Page raus,

wenn man halt serverseitiges HTML-Rendering

macht, du willst irgendeinen Twitter-Feed einbinden

und redest halt mit der Twitter-API.

Programmierfehler für

10 Euro,

du gehst halt mit einem synchronen

Socket per HTTP an diese Schnittstelle ran

und wenn Twitter in dem Moment meint, ich hab keinen Bock, dann bleibt

halt deine Frontpage stehen. Dann läuft dir dein

Threadpool für den Anwendungs-Server voll und dann bist du

halt komplett down. Und das dauert

halt so ungefähr 30 Sekunden, bis das der Fall ist.

Es passiert halt

immer wieder und das

kriegst du auch nicht raus, weil die Welt halt so komplex

ist, dass auch Entwickler, die zwar entwickeln gelernt

haben und selbst die halt

schon 10, 20 Jahre dabei sind, auch die machen da

immer mal Fehler dabei und müssen sich ein bisschen mit

obs reiben, mit was sind denn die

Fehler, die jetzt halt momentan typischerweise auftreten.

Es gibt halt bestimmte Fehler, das ist auch

wieder so ein Thema aus der komplexen Welt,

die gleichen Fehler treten die zweimal auf

und bestimmte Probleme,

die wir dann über sowas wie Root-Course-Analysis

oder so erschlagen wollen.

Da kommt immer ein Root-Course-Analysis.

Das musst du einmal noch mal kurz erklären.

Das sind einige Hörer, die sind genauso doof wie ich

und die wissen nicht, was das ist.

Die Wurzel-Grundanalyse.

Jetzt weiß ich mehr.

Was war, du hast halt bei Fehlern,

wenn Probleme auftreten, hast du ja irgendwann mal ...

Also welche Zeile, wo das steht.

Sozusagen.

Oder halt auch, welche Komponente ist kaputt gegangen,

Welche Festplatte ist kaputt gegangen? Hat die Putzfrau gerade irgendwie den Server ausgesteckt?

Okay, also wo ist die Lampe an und warum ist die an vor allen Dingen?

Ja, genau. Es kann ja so eine Kausalitätskette geben, so eine Kette von mehreren Gründen, die aufeinander aufgelaufen sind, warum dann am Ende irgendwie vorne was umgefallen ist.

Und diese Kette nachzuverfolgen, das nennt sich halt Root Cause Analysis.

Und die ist halt aus einer auch wieder sehr analytischen Perspektive von, finde bitte raus, wer schuld ist, erschieß ihn und schaff was Besseres an. Und das Dumme ist aber, wenn du halt eben in sowas wie die Black Swan Theorie reingehst oder in die Komplexität, dann wirst du feststellen, im Prinzip ist im Komplexen der Normalzustand, dass ständig irgendwelche Sachen außerhalb des Optimums laufen.

Das ist halt der Normalzustand und dein System so zu designen und auch dieses Feedback auf Team-Ebene zu haben von, was ist eigentlich normal und wann darf ich mich nicht zu weit aus dem Fenster lehnen, dafür ein Bauchgefühl zu entwickeln und die Praktiken, die halt heute relevant sind, ich kann nicht alle Praktiken, die es jemals gab, aufaddieren.

Und so wird aber dieser analytische Ansatz gemacht mit, wir machen jedes Mal, wenn was schief geht, eine Root Cause Analysis und wenn wir alle davon dann fixen, dann kann nie wieder was schief gehen.

Und die Leute wundern sich dann, warum trotzdem halt regelmäßig was schief geht. Und das ist dann halt eine Technik, ja, aus dem Ops-Bereich gibt es noch die, erkläre ich dann auch gerne, Meantime Between Failure und die Meantime to Recovery.

Dominik, sagst du bitte, dass ich es erklären soll?

Ja, ja, müsstest du bitte erklären, wann genau, wie lange man, wie viel Zeit braucht.

Ja, genau, genau, genau. Also das eine ist, ich kann halt mein System darauf auslegen, möglichst selten kaputt zu gehen. Und das andere ist, ich kann es halt darauf auslegen, möglichst schnell wieder reparierbar zu sein.

Und Extremwerte sind halt ungünstig.

Also, wenn man sich die Extremwerte anguckt,

sage ich, ich will, dass es nie kaputt geht.

Da wissen wir alle,

dann musst du so viel Energie vorab reinstecken,

dass du die Kosten nie wieder reinkriegst.

Und der Black Swan sagt uns,

es wird trotzdem auf eine Art kaputt gehen,

die du nicht vorhergesehen hast.

Das wäre dann sowas wie Full-Test-Coverage.

Ja, genau, Full-Test-Coverage mit allen Loops,

mit allen Grenzbedingungen, mit allen...

Also formale Verifikationen irgendwie.

Ja, genau, genau, genau, genau.

Und das ist halt, das ist halt, jeder Praktiker guckt dich dann halt an und sagt, das geht halt nicht.

Und das Dumme ist sozusagen, es wird halt sogar irgendwann kontraproduktiv.

Du steckst dann irgendwann so viel Energie und Zeit rein, Sachen starr zu machen, damit sie nicht kaputt gehen,

während aber Starrheit gegenüber einer flexiblen Umwelt eine schlechte Idee ist.

Also das hält halt relativ lange, so lange, bis es dann so richtig gar nicht mehr hält.

Du willst halt Methodiken haben, die so flexibel sind, dass du frühe Warnsignale kriegst von,

das ist hier eigentlich nicht mehr okay, aber ich

explodiere noch nicht,

damit du dann nämlich die Möglichkeit hast, aus diesen

kleinen, schwachen Signalen

schon mal was zu lernen und dein System dann schon mal

in die richtige Richtung zu bewegen. Das andere

Ende ist, statt sozusagen die Häufigkeit

der Fehler zu

reduzieren, ist zu sagen, naja,

ich mache mir den Fehlerfall ganz,

ganz einfach. Das sind dann solche

Sachen wie Clean Crash Restart,

also im Sinne von,

ich mache, dass meine Anwendung extrem schnell starten

kann. Ich weiß jetzt nicht, wie lange

Django zum Hochfahren braucht. Soap hat immer

urlange gebraucht, bis es mal

einen Port aufgemacht hat.

Während dann halt neuere Tools,

also ich habe halt immer viel mit Pyramid zu tun,

die machen halt nach

500 Millisekunden oder so den Port auf

und fangen an, wieder zu arbeiten.

Was bedeutet, im Ernstfall kann ich so eine

Anwendung auch einfach abstürzen lassen,

wenn es in einen unbekannten Zustand kommt,

weil ich weiß, die ist in 500 Millisekunden

eh wieder am Start.

Und wenn ich dann einen Pool von 10 oder so

davon habe, dann

mit einem vernünftigen Loadbalancer, dann denke

ich mir so, klar, die kann jede Nacht einmal abstürzen,

ist mir völlig egal, weil merkt keiner.

Merkt keiner.

Und dann kriege ich aber solche Infos mit,

oh du, übrigens gestern Nacht sind zwei Sachen

kaputt gegangen, hier ist der Stacktrace.

Geh mal gucken.

Versus, hm, wir haben jetzt ganz

lange alle Fehler unterdrückt und jetzt ist das ganze

System stehen geblieben. Viel Spaß.

Jetzt aber nochmal so eine ganz doofe Frage wieder.

Was ist denn jetzt eigentlich der Unterschied zu einem

Administrator dann?

Ich habe keine Ahnung, Namen sind schon alle drauf.

Das weiß ich nicht, naja, genau, ich glaube,

ob es ist nochmal ein bisschen älter,

irgendwie wurden teilweise auch Opis

genannt, was ist Opis, oder weiß nicht,

ja, oder Leute, die dann tatsächlich

im Rechenzentrum rumlaufen.

oder so. Und Admin ist schon so ein bisschen

so, der sitzt dann schon im

Bürostuhl.

Naja, ein Admin war

ja. Auf was sitzt du da gerade, Christian?

Ich sitze auf einem

schönen Bürostuhl.

Ja, also auch da

wieder, ich rede schon erstmal

wieder zur Komplexität drüber. Menschen

haben halt unterschiedliche Facetten.

Also Leute in

so eine eindimensionale Perspektive

zu schieben, macht den Menschen halt

eher weniger Spaß, also auch

weniger als Mensch.

Ich bin gerne mal im Rechenzentrum

in Arbeitshose unterwegs, weil ich halt

irgendwie wissen will, wie ist denn das mit diesen blöden Kabeln

und ach guck mal, da sind immer diese komischen

Nasen, die da abbrechen, ja genau und wenn du das nicht

ordentlich machst, dann hast du nach einem halben Jahr plötzlich ein Kabel,

das rausrutscht und umgekehrt

weil daraus

entwickelst du ja auch ein Gefühl zum Beispiel

von, wie stabil ist

so ein Kram eigentlich, anstatt ständig nur

über Abstraktionen zu reden und deswegen ist

Multidimensionalität und mehr Facetten

den Menschen

in ihrem Alltag

zu erlauben, ja, total wichtig.

Operator

ist der ältere Begriff, der

stammt dann wirklich schon aus

dem

Zweiten Weltkrieg.

Nee, Industrialisierung

tatsächlich schon. Also du hast halt,

das war dann eher so Engineering versus Operator.

Du hast halt Leute, die

entwerfen eine Maschine und Leute,

die die Maschine im Tagesbetrieb am Laufen

halten. Aber auch

das sind halt immer so ineinandergreifende

Tätigkeiten gewesen. Also die hatten

halt ihr begrenztes Feld von, ja, ich weiß,

hier, die und die Sachen kann ich machen, da hört irgendwo

meine Kompetenz auf, dann hole ich halt den Ingenieur

dazu und dann ist der Ingenieur halt auch vom Reißbrett weg

und muss dann halt mit der Ölkanne an das Ding ran.

Der kann aber in dem Moment

überlegen, was gerade die Konstruktionsprinzipien sind.

Der andere weiß halt, ja, komm,

das knarzt jeden Dienstag, da rufe ich jetzt nicht an.

Ja, da würde

der Ingenieur, dem würde irgendwie der Hut platzen,

das darf da nicht knarzen und der andere so,

Das knarzt seit 20 Jahren, das war wurscht.

Und das ist halt genau dieses Thema, so Alltags-Know-how, wie die Systeme, die designt wurden, sich dann real verhalten.

Das ist so das, was ich einem Op angeben würde.

Und ein Admin war immer auch eher einer, der halt aus so einer Systemmanagement, Systemkonfigurationssicht als ein Ingenieur tätig war.

Als überleg mir das hier einmal und dann tut das irgendwie.

Ich neige heute mehr zu dem Ops-Begriff, weil es halt so ein bisschen umfassender den gesamten Lebenszyklus auf der Server-Seite dann widerspiegelt.

Ja, ich meine,

in der FOPs hat man das ja sowieso dann schon im Namen

irgendwie mit drin.

Was ich an der Stelle noch ganz interessant finde, ist, dass halt auch

wenn man

jetzt sozusagen das komplett

voneinander getrennt hat, auch dieses Problem bekommt, dass

die unterschiedlichen

ja, sozusagen

Facetten da

halt unterschiedliche, also

der Erfolg wird halt unterschiedlich gemessen.

Das war halt also, sozusagen, ich war auch

eine Zeit lang Admin

und im Rechenzentrum unterwegs und so

und das Interessante

ist halt, dass

sich das halt gegenseitig blockiert, deswegen

ist es vielleicht auch nicht so eine gute Idee, das voneinander

zu trennen, weil

sozusagen der ganze Betriebsbereich,

also eben

Administration, die ganzen Infrastruktur-Kram,

Rechenzentrumsbetrieb, das wird halt

daran gemessen, dass es halt nicht kaputt geht,

sozusagen, also

ja, also ich meine

über, dass der Strom

da ist, das feiert niemand, aber wenn er

ausfällt, ist halt blöd.

Das heißt, wenn der ganze Kram funktioniert,

dann wird man nicht wahrgenommen.

Wenn es kaputt geht, dann ist es blöd.

Haha.

Genau.

Und bei den Entwicklern ist es halt so,

bei denen schlägt das ja gar nicht so sehr auf,

wenn das System irgendwie insgesamt nicht mehr funktioniert.

Und die werden halt daran gemessen,

wie viele Features sie halt rauskriegen irgendwie.

Und ob das jetzt irgendwie irgendwas verbessert oder so.

Das heißt, wenn man dann eine klare Trennung

zwischen den beiden Geschichten hat,

sind halt sozusagen

die optimalen Strategien möglicherweise für Entwickler

halt möglichst kaputtes Zeug

einfach raus damit, egal.

Die werden das schon irgendwie am Laufen

halten. Vielleicht steht ja nicht mein Name dran oder keiner.

Genau, weil ich meine, ich werde halt

nicht dafür bestraft sozusagen, wenn es kaputt geht

und aber belohnt, wenn

ich genug Features rausdrücke

und auf der anderen Seite optimiert

man halt darauf, möglichst keine Änderungen zuzulassen,

weil ein System, das

sich überhaupt nicht ändert, das ist auch relativ stabil

und dann blockiert man

einfach alle Anforderungen sozusagen oder

alle neuen Geschichten so lange,

ja, bis halt der Strom dann

nicht ausgefallen ist und man seinen Job erledigt hat

und, ja,

hat aber das Problem, dass es insgesamt auch für die

Firma nicht funktioniert und das war halt...

Solche neuen modischen Scheiße machen wir nicht.

Ja.

Ich meine, die,

das ist halt auch da wieder,

zum einen, spannend,

man, DevOps ist im Prinzip

in der Lage, dort diese Anreize einmal umzukehren

Im Prinzip kannst du

dann halt nämlich sagen,

erst mal messen

ist zwar eine gute Sache, aber auch da

Menschen haben halt so den Vorteil, die können so Systeme

gut austricksen.

Und wenn du,

das Schlimmste, was du eben machen kannst, ist, wenn du halt so

harte Metriken einführst, weil, was werden die

Leute machen? Die optimieren da drauf hin

gnadenlos.

Gnadenlos. Das ist das Problem,

warum halt Systeme sich dann immer

ad absurd führen, weil sie

versuchen, eine komplexe Welt reduktionistisch

zu betrachten im Sinne von

Uptime. Das ist

unsere Welt, danke.

Und was man

tatsächlich, manchmal kann man damit spielen, in so einem System kannst du

zum Beispiel dann sagen, naja, liebe Admins,

wir messen euch dran, wie viele Features rausgehen

und liebe Devs, wir messen euch dran, wie stabil

das Rechenzentrum ist.

Sondern wie stabil halt

die Anwendung draußen ist.

Und dann kriegst du nämlich plötzlich

eine ganz andere Bewegung da rein.

Ja, das wird dann auf jeden Fall dynamisch.

Dann jagen nämlich die Devs den Admin durchs Haus,

wenn der Server abgerottet ist.

Das willst du. Du willst Reibung.

Du willst Reibung, du willst Dynamik,

du willst nicht Complacency haben.

Du willst nicht, dass die Leute zufrieden in ihrer Ecke sitzen

mit, ah, der Strom ist an.

Sondern du willst sagen,

ist ja schön, dass hier der Strom an ist, wo bleiben

die Features?

Und das ist halt,

das ist tatsächlich was, wo DevOps

eigentlich sich ganz gut positioniert

an der Stelle. Da sind auch viele Tools

jetzt eigentlich gut darauf ausgerichtet,

das eben so zu überlagern, dass man

dann eben nicht mehr klar trennen kann.