Transkript: Devops

Ja, hallihallo, herzlich willkommen zum Python Podcast.

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

Oh hervorragend, cool, ne?

Zehn Stück schon geschaffen.

Ja, und es ist noch eine kleine andere Premiere.

Und zwar haben wir heute das erste Mal eine Remote-Sitzung, einen Studiogast quasi, der nicht bei uns im Garten sitzt.

Wo sitzt du denn, Christian?

Hi.

Hi.

Ihr sitzt im Garten.

Das sind Tag nicht so angehört.

Ah, okay.

Ich gucke in meinen Garten.

Ich sitze in meinem Homeoffice.

Ich sitze in der Nähe von Stuttgart.

Das ist eine ganz schöne Remote-Verbindung hier von Düsseldorf nach Stuttgart, durch die halbe Republik.

Wundervoll.

Was machen wir heute?

Wir machen heute DevOps ein bisschen und wie man Python so

wenn man irgendwie Python-E-Applikationen entwickelt hat, dann möchte man ja auch irgendwie die sozusagen dann produktiv benutzen können, dass andere Leute sehen und so und dann muss man da auch noch Dinge tun, damit das geht und ja.

So ein Zirkus.

Danke.

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

Das ist dann auch mein Twitter-Handle.

Und ich müsste mich jetzt eigentlich fast als Urgestein in der Python-Szene sozusagen bezeichnen.

Und deswegen bist du auch in unserer Jubiläumsausgabe dabei.

Mein Herz wird warm.

Ich mache Python jetzt seit 99, glaube ich, irgendwie in der Größenordnung.

Ich weiß sogar, dass ich irgendwann 95, 96 als erste 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ühster 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 bei der 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, so im Sinne von Anwendungsentwicklung.

Und ich mache aber seit Ewigkeiten halt auch schon Serverbetrieb nebenbei und die Firma, wo ich jetzt bin, die verdiene ich dann jetzt auch meine Brötchen.

Aber die lassen wir jetzt hier einfach mal fröhlich aus dem 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 nochmal kurz so ins Spiel bringen und vorstellen.

Achso, 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, dass man unter Best Practice, sehr ich dieses Wort hasse, abhaken kann und dann ist das irgendwie erledigt, das Chef-approved.

Die in den letzten Auswertungen über den Jahreswechsel, was die Beliebtheit von Programmiersprachen angeht, ist Python halt weltweit im Prinzip immer unter den Top 5, wenn nicht sogar auch auf Platz 1.

Und deswegen haben wir vom Python Softwareverband irgendwann gesagt, Python einfach nur an sich zu pushen, das braucht es gerade gar nicht mehr, das läuft.

Was ich auch 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 die 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 beim 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.

So tatsächlich für Kinderkurse mit dem Respi und dann in Python mit Minecraft oder so Coden.

Macht viel Spaß.

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 sie 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 ab wenn du zehn 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 heißt, 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 man einen kleinen Sponsoring-Vertrag macht, dann braucht man nicht über irgendwie Kleingruß-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 sind dann typischerweise so etwas wie die Django-Con-Sponsor.

Da gibt es dann irgendwie 1000 Euro einmal glatt, um anderen Leuten halt den Zugang zu Python-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 ein Sprint machen und dafür brauchen wir Reisekosten oder wir wollen es mal ein 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.

Die verteilen wir jetzt.

Das ist 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 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 das.

Da macht er echt viel, das dafür machen.

Das klingt echt interessant.

Also bestimmt noch ein paar Interessenten, die das zu 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 so Sprints, wo sie sich treffen, wo sie halt an den Open-Source-Projekten entwickeln.

Und die fordern das immer mal ein, die müssen wir immer bremsen.

Dummerweise haben wir niemand anders, auf dem 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.

Ja, gut, okay, stimmt.

Euer Geld ist gut angelegt.

Genau, das ist sowas 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, 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, 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 einen großen Teich schiebt.

Genau.

Cool, kurze Leitung.

Also, falls ihr Ideen habt, meldet euch da direkt.

Ihr könnt natürlich auch das alles machen.

Genau, 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 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 es irgendwie weiterentwickelt wird, Sicherheitsgeschichten irgendwie gehandelt werden und so.

Also ja.

Ich meine, 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 viele Gedanken mir gemacht, gerade um diese, wie ich an dem Begriff Digitalisierung irgendwie einen Griff, also wie ich da irgendwie einen Griff dran kriege ohne bla.

Keiner kann das Wort eigentlich mehr hören und wahrscheinlich ist es vom Hypecycle her so langsam durch und ich habe mich immer gewehrt, es überhaupt einzusetzen.

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 unterm Hintern weg schimmelt, 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, als 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, wenn ich es schon nicht selber lösen kann.

Ja, 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, ach, jetzt Geld ausgeben für Software, die wir gar nicht brauchen.

Also wir kaufen ja nicht, warum?

Also ist ja umsonst.

Ja, ja,

irgendwo raus.

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, sowas wie Mark Andresen mit Software Eats the World, das heißt, alles wird irgendwie Software sein.

In einer positiven Variante bedeutet das, 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.

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

Faxgerät ab.

Nee, wir stellen die Unternehmenssprache als Metapher, wir stellen die Unternehmenssprache von Deutsch auf Englisch um und um das richtig hinzukriegen, haben wir jetzt einen Übersetzer und zwei Wörterbücher angeschafft.

Ja.

So ungefähr ist es auch, wir wollen digitalisieren, deswegen kaufen wir jetzt mehr Software ein oder so.

Und das ist 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-un-spezifisch Server.

Echt interessant.

Das ist auch überhaupt nicht so richtig verbreitet.

Es gibt 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 das ü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 Urlaub waren, hat man halt dann die Netscape-Web-Server ersetzt durch Linux-Web-Server und so.

Und als dann sichtbar wurde, dass das sehr gut funktioniert und auch besser halt oft als die kommerziellen Varianten, dann hat sich das durchaus etabliert, dass man das so macht.

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

Die ganzen Unternehmen haben das nicht verstanden, was das bedeutet, was Digitalisierung ist.

Das bedeutet für jeden irgendwas anderes und die meisten sind so fern von jeder Digitalisierung, schleppen dann die E-Mails ausgedruckt im Kopf mit sich rum, das funktioniert halt dann noch nicht.

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

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, aber genau das, was du geschrieben 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 1999.

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 wartet sich so einen 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 ja 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, überhaupt, wie sie gerade unser Projekt benutzt, und sie irgendwie über Excel fluch.

Und man feststellt, okay, was machst du halt mit Excel?

Ja, da hat sie halt so eine Tabelle gehabt, wo sie so eine Statistik mitführen musste, einmal pro Monat.

And da 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 Zail-Liste zusammenzuklicken, indem sie sich durch unsere Software durchgeklickt hat, um dann in dieser Excel-Tabelle zu erfassen, wie viele Personen dieses Kriterium, wie viele Personen dieses, 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, ah, das ist ja alles relativ komplex und so ein Excel kannst du, wenn die Stadt dir so eine Statistik gibt mit 1000 Makros drin, dann generierst du das nicht.

Aber wenn du mit den Leuten ein bisschen Pingpong 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 and Paste in diese andere Tabelle von der Stadt reinpacken und auch plötzlich ist dein 20-Stunden-Job, also 80 Stunden pro Monat auf fünf Minuten eingedampft.

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

Natürlich, also ihre Vorgesetze war 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, genau.

Und es gibt, ich habe viel Komplexitätstheorie gemacht in den letzten Jahren, Dave Snowden, Kinevin 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ägstrichbü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 so ein Bauprojekt an der Backe, weil ich ein privates Haus baue und da fliegen natürlich tausend Excel-Tabellen rum.

Und wenn ich ein, dann habe ich es mehrfach gehabt, dass dann Excel-Tabellen rausfallen, wo in einer Spalte irgendwelchen 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 da Formeln drüber zu jagen.

Das geht so nicht.

Und 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, 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 vom Links und rechts wisch, 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.

Die müssen halt auch sozusagen verstehen, wie das, was sie tun.

Ja, aber die wachsen ja nicht automatisch mit nach, sondern du musst die ausbilden.

Ich glaube nicht, dass nur weil du Digital Native irgendwie bist, aber du da reingebunden wirst, dass das funktioniert.

Sondern ich glaube, du musst tatsächlich da auf der Perspektive mit dieser Brille draufgehen, du wirst jetzt da Tech-Experte sein.

Ich glaube vor allem auch, es gab einen massiven Bruch durch dieses Thema Android iOS, weil bisher, wir können es natürlich sozusagen Opa erzählt vom Krieg spielen.

Chattermarken Opa erzählt vom Krieg.

Okay, warte Moment, ich mache mal.

Ja, genau.

Das ist aber was, das ist mir vorgeworfen worden.

Nein, das ist mir nicht vorgeworfen worden, aber es ist irgendwie mit einem zwinkernden Auge auf dem Pike Camp 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 meine, ich bin 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, im Alter, ich habe mich so über den 90er Jahren halt durch Sachen durchgequält, wo ich halt sagen muss, es gab halt nieder eine Trennung zwischen Konsument und Produzent.

Ja, ich bin, egal ob auf DOS oder Windows, dann Mitte der 90er irgendwann in 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 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 da, das war, 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.

Na, 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, da man dann irgendwie sich 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 erwartest, dass die Leute halt so ein gewisses robustes Set an Sprache halt können, mit dem sie halt wissen, ah, der Empfang kannst du mindestens mal sagen, wo die Toilette ist und wo es in die Chefetage geht und kann dir ein Taxi rufen.

Kantine.

Ja, Kantine, ist auch noch wichtig, genau.

Aber es ist halt, 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.

Okay, spannend, spannend.

Ja, aber ich glaube, also 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 drüber reden, was das da alles für offen Fragen hat.

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

Aber nur ganz kurz, weil wir wollen dann auch mal erkennen, tatsächlich, wie man das mit Python so 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 Keith Magee oder so gehalten.

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

Ich beim Urlaub.

Achso.

Nee, nee.

Nee.

Der hat da was.

Ah, ganz gute Entschuldigung.

Was ich da jetzt mittlerweile häufig mache, ist, die landen ja meistens auf YouTube und es gibt in meinem Podcast-Player irgendwie so einen, der hat so ein Zeitloading-Share-Sheet-Extension-Dings für iOS.

Und dann sage ich auf dem YouTube, äh 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 so ein bisschen Information weg, also ganz toll ist es nicht.

Aber seitdem höre ich mehr Talks, weil das 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 der, das war ganz interessant.

Und zwar hatte da etwas angesprochen, was man halt auch so als.

Der kommt irgendwie aus Australien.

Nassim Taleb hat mal 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 nicht, also bis halt Australien irgendwie so richtig entdeckt war, dass es nur weiße Schwände gäbe, weil man hatte noch nie einen Schwarzen gesehen.

Aber in Australien gibt es tatsächlich wohl schwarze Schwäne.

Und ja, dann, 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 ist 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 darauf 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 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 Hingelbt 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 so ein Microsoft-Forestand geschickt haben.

Und was der sagte, also man kann inzwischen sehen, was das sein könnte und für ihn ist halt interessant rauszukriegen, was man dagegen tun kann.

Und er meint, das 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 ganzen 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 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 irgendein Browser.

Browser sind auch von den Geräten nicht wegzudenken.

Aber Python läuft jeder im Browser.

Ja, 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 WebAssembl ein.

Das finde ich blöd aus einer anderen Perspektive, weil dann ist halt View Source endgültig kaputt.

Das ist was, womit ich halt auch wieder aufgewachsen bin, mit, allein das hat es mir ermöglicht, irgendwie vernünftig das Zeug überhaupt zu lernen, dass man in Sachen reingucken kann.

Aber sei es meistens.

Man kann in jede Webseite reingucken und sich angucken, wie das geschrieben wird.

Ja, genau.

Genau, genau.

Das war halt, wobei das auch heute eigentlich ist, es ist praktisch tot.

Durch Minifizierung etc.

Ich meine, mit dem Inspektor kriegst du dann halt, wenn Mappings da sind, beziehungsweise auch noch Deminifier und so ein Zeug, aber es ist praktisch eh tot, weil die Komplexität zu groß ist.

Früher warst du, da hast du dir halt mal deine 10K, 20K HTML-Code plus ein bisschen JavaScript angeguckt und dann, 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 Laborkettel an, bevor du anfängst zu programmieren oder sonst hältst du dich nicht aus.

Also das ist ja so Business programmieren, ja.

Da stellt man sich die Leute vor, die im Laborkettel programmieren und jetzt halt mal ordentlich hier, da ist der deutsche Ingenieur, jetzt kriegst du gleich Qualitätssoftware, wenn ihr nicht aufpasst.

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 Querinsteiger 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 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 so, hier kommt jetzt erstmal das große Konstruktions-Template und ohne das kannst du nichts tun.

Java-Bash gemacht hat, auf den ich die ganze Zeit gewartet habe, die seit Folge 1 vorgenommen hat.

Bitte schön.

Danke.

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

Also es gibt die eine Story, das ist eine, also es gibt ja mehr Perspektiven darauf.

Das eine ist, es sollte mal dieses Set-Top-Boxen-System sein.

Mitte der 90er.

Dann wurde es irgendwann zu so einem Serversystem, dann wird es irgendwann zu der Universal.

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, dann kriege ich immer das Gruseln, wenn ich sehe, wie das UI aussieht dazu.

Das ganze Ökosystem ist durchdrungen von diesem Ingenieursansatz.

Von diesem, du musst alles ausdefinieren.

Und aber die wirklich interessanten Sachen, sowas wie, dass das UI geschmeidig ist und das kommt als letztes.

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

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

Ich glaube halt, 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.

Das ist sozusagen auch eine ganz eigene Schleife zum Thema Digitalisierung und Selbstständigkeit von Anwendern.

Da ist halt auch die freie Softwarebewegung als Ganzes im Prinzip dran, dass du sagst, hey, ich will eigentlich, dass die User emanzipiert sind und dass ich keine, dass ich nicht um Erlaubnis fragen muss, um Software zu modifizieren oder Software zu verstehen oder sondern dass ich halt eben genau Emanzipation mit Kompetenz auch gleichsetze an der Stelle, ja.

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.

Ja, ja.

So, aber jetzt Endkultamarken.

Jetzt fangen wir an zu erklären, wie man das mit Python alles so insgesamt machen möchte, wenn man sowas DevOps 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, 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, ja, die man nicht nur lokal irgendwie anguckt, da kann man auch einfach einen HTML-File von Hand mit einem Editor hinschreiben und dann guckt man sich dann an.

Das kann ja auch, das kann auch einfach nur eine HTML-Datei sein, aber die kann ja jemand anderes noch nicht sehen.

Nur wenn sie jetzt auf meinem, also wenn ich sie auf meinem Rechner mit dem Editor erzeugt 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, ja, so auch Ende der 90er irgendwie PHP und irgendwie FTP-Server oder so, da haben da Leute irgendwie quasi so eine Webroute in einem Apache gehabt und dann haben sie da irgendwie Sachen per FTP hochgeladen und dann war das irgendwie dann deployed, sozusagen.

Vielleicht kennt man das.

Ich war sehr überrascht, dass ich letztens gesehen habe, dass Leute das heutzutage immer noch so machen.

Ja, sie machen es.

Es ist immer wieder, also sie sterben nicht aus.

Ja, auf der anderen Seite muss man halt sagen, dass das ist halt so ein, 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 dran gewöhnt.

Es gibt viele, die kennen überhaupt nichts anderes.

Und es ist halt so ein Standardweg, wie deployt man jetzt irgendwie Software mit PHP irgendwie, wenn man das jetzt.

Funktioniert.

Ja, naja, für bestimmte Werte 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 denn ü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 Spannende daran ist, man könnte jetzt sozusagen mal den Bogen, du hast jetzt wirklich des abschreckenden 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 FCP 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 kaputt gegangene 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 das 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 Totschlagvariante 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 sich.

Und was ich halt spannend finde, wenn wir das Wort DevOps eigentlich nehmen, dann kommen wir halt in so einen, auch mit Ag, ich muss jetzt meine Buzzword-Matrix für irgendwo aufmachen, dann kommt es halt aber in dieses Thema von, wie arbeitet man eigentlich in Teams gut zusammen.

Weil weißt du, wenn ich meine Software alleine baue und ich habe irgendwie 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 da 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 anderes, irgendeine Agentur oder irgendein Freelancer oder ein Team entwickelt es 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 FDP-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 Zaunwerfens.

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 ein README und gib 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 es vorne und hinten nicht funktioniert.

Und der Prozess war aber definiert, siehe Wasserfallmethodik und so, von, naja, wenn ihr fertig mit Entwickeln seid, dann geht das halt den Admins.

Und in einer komplexen Welt hast du halt eben nicht mehr solche ganz klaren, harten Interfaces zwischen Leuten gesagt.

Hast du das Agile gesagt oder was?

Was wir gerade beim Buzzwort bringen?

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.

Ihr arbeitet bis hierhin und das Werkstück, was da rausfällt, gibt 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.

Wobei, wenn ich da nochmal so kurz abschweifen, darf ich, 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 da 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 tausend Mann-Entwicklungsabteilung irgendwie Agile-Dinge machen sollte und dann machen alle, wird die in Teams aufgeteilt, die machen dann halt alle irgendwie Dinge in unterschiedliche Richtungen und es passt nichts mehr zusammen, alles ganz furchtbar.

Und das fand ich, das fand ich irgendwie witzig, weil eigentlich kommt das ja aus der Automobilindustrie.

Toyota?

Ja, das, das, genau.

Ja, nee, nee, nee, Moment.

Nein, da muss ich reingegrätschen.

Okay.

Nein.

Du hast zwei Sachen.

Du hast Agile auf der einen Seite und du hast Canban auf der anderen.

Und Canban, das sind ähnliche Konzepte.

Can ist das, was Toyota stark gemacht hat.

Das 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 so, es geht hier hinten geht es 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.

Und da gehört Canban unter anderem dazu.

Can 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 Thrashing, 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 viele 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 da oft 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 es ist halt sehr knapp.

Es ist halt People over jetzt muss ich selber halt raussuchen.

Das war People over Processes, Working Software over comprehensive documentation, Collaboration over Contract Negotiation, responding to change over following a plan.

Und wenn du jetzt aber, und das Dumme ist, das sind Techniken, die waren entwickelt worden, das war auch, ich glaube das war ein Chrysler-Projekt und das liegt 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 Dokumentation und Prozesse und Vertragsverhandlung 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 Entwicklern reden.

Und ein großes Problem, was die Agile-Community hat, meiner Meinung nach, ist, es war eine Teammethode, die war nie dafür gedacht, auf ganze Unternehmen angewendet zu werden.

Also die war gedacht für so 10 bis 15 Leute.

Ja, nicht, ja, wahrscheinlich, genau.

Man sagt auch oft so, 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, genau, man muss halt alles kleiner.

Du teilst dann die einzelnen Teams auch, ne?

Dann machst du da ein Team, was für das speziell Projekt tut, dann machst du einen eigenen Team, einen eigenen Raum, die haben ihre eigene Peel Group, ihre eigenen Stakeholder, du musst dann gucken, wie sich damit klarkommt irgendwie.

Und 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, also 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, sel

bst 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, ja.

Das kann das auch nicht so richtig, aber es gibt das 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, für die sie sich nicht kompetent fühlen.

Ja, ja.

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 Weltthema 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, sozusagen, du kannst Systeme einteilen in das ist halt wieder das Knevin von Dave Snowden.

Ja, ja, das ist irgendwie, der macht irgendwie zwischen kompliziert, komplex und komplexer.

Das ist sozusagen, das ist sein, das ist seine Theorie, an der er seit irgendwie 30 Jahren arbeitet und die nimmt jetzt gerade auch ganz gute Form an, dass er sie finalisiert.

Der unterscheidet sozusagen 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 Wirkungsprinzipien 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, wisch das weg und wenn es gesplittert hat, habe ich noch einen Staubsauger.

Da brauche ich jetzt nicht groß irgendwie Analyse betreiben.

Dieses, so, das, ähm, in solchen Umgebungen kannst du halt auch zum Beispiel mit.

Das Unternehmen, die machen genau sowas, die kaufen sich da ein neues Glas und auf dem Boden schlammeln sich immer mehr Scherben an.

Ja, genau.

Kann man machen.

Denn dann kompliziert ist, wenn du für das auf, 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 zehn Stunden, dann drechet der 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 Ursachewirkungsprinzipien eben nicht vorhersagen kann, aber zumindest die Chance hätte, es im Nachhinein zu erklären.

Wenn ich nicht mal die Ursachewirkungsprinzipien 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 abgeschliffen bin, in der komplexen Welt ist es eben so, dass ich diese Ursache Wirkungsprinzipien eben nicht vorhersehen kann.

Und deswegen ist das der Grund, warum starre Methodiken, starre Formen der Zusammenarbeit, starre Form 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 runterdefinieren, haben 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, 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, FDP-Deployments oder Docker oder Kubernetes eats the world.

Beide Extreme sind nicht gesund.

Beide 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, Business-Leute, Ops-Leute, dass die halt sich in einem Projekt auch zusammenfinden und sagen, was ist denn hier jetzt die richtige Kombination für jetzt?

Weil auch die Zeit ist ja wieder ein Faktor daran.

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, 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?

Ja, 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, wenn ich die nur nie austeste, dann haben die 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.

Der halt dann einfach mal irgendwie ein Dienst, der halt irgendwie den Stecker bei Maschinen zieht und die einfach vor dem 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 Handel da dran.

Dann hast du nicht mehr dieses psychologische, ah, da kann ich mich drum rumwickeln.

Das ist das, also dann solche Situationen herzustellen und die ganze Zeit die Leute zu nerven mit Szenarien, die in der Realität irgendwie im Wang auftreten könnten und die man dann realisiert?

Nee, 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 diese Software nach Spezifikationen entwickelt, wie auch immer die aussah.

Und dann eine IT-Abteilung war dann halt dafür zuständig, dass 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.

Also vor allem, wenn der Manager dann irgendwie kein IT-Ler ist, wahrscheinlich.

Bei nicht-funktionalen Anforderungen denke ich mir halt auch immer, zum Beispiel Performance, ja, da hieß es dann halt, wie groß muss der 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.

Ach, mach mal Kerne.

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 deterministisch 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 teurer 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 ja eigentlich nur noch dabei, Ducktape rauszuholen.

Also dass 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, ach, 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 einen ON hoch 5 gebaut hat, dann kannst du schon sagen, ja, logisch, dass es explodiert, da brauche ich auch nicht noch mehr Hardware drauf werfen.

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

Und die, ich fände es ja, also 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.

Eigentlich sind das bloß immer irgendwie Biersprüche.

Weshalb es 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 Konzentrationen und will mich halt auf bestimmte Sachen, die ich entwickeln möchte, halt konzentrieren.

Und aus einer Obst-Perspektive 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, also 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 Obsachen mache, weil Obsachen 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, dann

OO, genau, oh, dann kompetent.

Genau, genau.

Und deswegen, 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, dass 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 zusammenklatschst, 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, also vier Sachen, also auf der einen Seite willst du operatives Wissen in Richtung Entwickler bei Projektbeginn haben.

Ah, okay, was wollt ihr machen?

Was wollt ihr für Tools nehmen?

Ah, könnt ihr vielleicht auf dem MySQL eine Postgres nehmen, könnt ihr vielleicht, was wofür nehmt ihr den Memcache?

Komm, Lindy oder den Reddis.

Da wundere ich mich auch schon manchmal, dass das eine Obs-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 von wie tickt diese Anwendung intern eigentlich.

Und da finde ich auch so Sprachen wie Python angenehm, wo du den Source-Code eigentlich immer gleich zur Hand hast, dass die Obs 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 denn der hier?

Ah, guck mal da drüben.

Und dass diese Form von Austausch halt dann auch macht, dass Obs 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 Obs, dass die dann halt besser wissen, ach, 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 ich, ja, ein beliebtes Beispiel ist halt irgendwie, du renderst irgendeine Page raus, wenn man halt serverseitiges HTML-Rendering macht, du willst irgendein 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 habe keinen Bock, dann bleibt halt deine Frontpage stehen.

Dann läuft dir dein Threadpool für den Anwendungsserver 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 nie zweimal auf und bestimmte Probleme, die wir dann über sowas wie Root Cause Analysis oder so erschlagen wollen, da kommt immer ein Root Cause Analysis.

Das muss ich einfach nochmal kurz erklären, das sind einige Hörer genauso doof wie ich und die wissen nicht, was das ist.

Die Wurzelgrundanalyse.

Also die sozusagen.

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?

Ja, genau.

Und 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, ja.

Und diese Kette nachzuverfolgen, das nennt sich halt Root Cause Analysis und die ist halt aus so 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, ist 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 Teame-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.

So wird aber dieser analytische Ansatz gemacht mit, wir machen jedes Mal, wenn was schief geht, eine Root Cause Analyse.

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 Obs-Bereich gibt es noch die, erkläre ich dann auch gleich gerne, Mean Time between Failure und die Mean Time 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 im irgendwelchen Teil.

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

Das sind formale Verifikationen, irgendwie

an die Stadt.

Ja, ja, genau, 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.

SOP hat er immer urlange gebraucht, bis es mal einen Port aufgemacht hat.

Während dann halt neuere Tools dann, also ich habe halt immer dann 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 ein Pool von 10 oder so davon habe, dann, 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 aber nochmal so eine ganz dumme Frage wieder.

Was ist denn jetzt da eigentlich der Unterschied zu einem Administrator dann?

Keine Ahnung, Namen sind schade so.

Das weiß ich nicht.

Naja, genau.

Ich glaube, Ops ist nochmal ein bisschen älter, irgendwie wurden teilweise auch Opis genannt.

Also es ist Opis oder weiß ich.

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

Das ist

ein Admin war, ja.

Auch was bist du da gerade, Christian?

Ich sitze auf einem schönen Büroschul.

Ja, also auch da wieder, ich gehe 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ß.

Also auch mich 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 aus rausrutscht und umgekehrt will, 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 Mehrfacetten den Menschen in ihrem Alltag zu erlauben, ja total wichtig.

Ein Operator stammt tatsächlich, ist der ältere Begriff, der stammt dann wirklich schon aus dem Zweiten Weltkrieg und früher halt eigentlich Nähe 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.

Und der andere weiß halt, ja komm, das knarzt jeden Dienstag, da rufe ich jetzt nicht an.

Da würde der Ingenieur, dem würde irgendwie der Hut platzen fand, das darf da nicht knarzen und der andere so, das knarzt seit 20 Jahren, ist er 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 Ob angeben würde.

Und ein Admin war immer auch eher einer, der halt auf 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 Obs-Begriff, weil es halt so ein bisschen umfassender den gesamten Lebenszyklus auf der Serverseite dann widerspiegelt.

Ja, ich meine, bis 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 Facetten da halt unterschiedliche, also der Erfolg wird halt unterschiedlich gemessen.

Das war halt also, sozusagen, ich habe auch, 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 ganze Infrastrukturkram, Rechenzentrieb, das wird halt daran gemessen, dass es halt nicht kaputt geht, sozusagen.

Also, also ich meine, über dass der Strom da ist, das feiert niemand, aber wenn er ausfällt, ist es 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.

Und bei den Entwicklern ist es halt so, dass, naja, 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, ne?

Und ob das jetzt irgendwie irgendwas verbessert oder so.

Das heißt, jetzt, wenn man da eine klare Trennung zwischen den beiden Geschichten hat, dann 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 kommt.

Also genau, weil ich meine, ich werde halt nicht dafür bestraft, wenn es kaputt geht, aber belohnt, wenn ich genug Features rausdrücke.

Und auf der anderen Seite optimiert man halt darauf, möglichst keine Änderungen zuzulassen.

Weil ein System, das sich überhaupt nicht ändert, das ist auch relativ stabil.

Und dann blockiert man einfach alle Anforderungen sozusagen oder alle neuen Geschichten so lange, ja, bis halt der Strom dann nicht ausgefallen ist und man seinen Job erledigt hat und ja, hat aber das Problem, dass es insgesamt auch für die Firma nicht funktioniert.

Solche neunmodischen Scheiße machen wir nicht.

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, Devs, also erstmal 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 darauf 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.

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.

Ja, das wird dann auf jeden Fall dann dynamisch.

Dann jagen nämlich die Devs den Admin durchs Haus, wenn der Server abgestellt wird.

Boah, das willst du, du willst Reibung.

Du willst Reibung, du willst Dynamik, du willst nicht, dass die, du willst nicht Complacency haben, du willst nicht, dass die Leute zufrieden in ihrer Ecke sitzen mit, ah, der Strom ist an.

Ja, 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, was wo DevOps eigentlich ganz gut positioniert an der Stelle.

Da sind auch viele Tools jetzt eigentlich gut darauf ausgerichtet, das eben so zu überlagern, dass man dann eben nicht mehr klar trennen kann.

Okay.

Ich würde jetzt sagen, wieder 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?

Python?

Okay.

Tja.

Wie macht man das denn?

Ja, achso, ich meine, wenn man jetzt über komplette Systeme redet, da ist es ja so, dass da gibt es halt halt so diverse Stacks, die man verwenden kann, um halt so komplette Infrastrukturen aufzuziehen.

Ich weiß aber nicht, ob wir das, also sowas wie Ensible oder halt SaltStack oder OpenStack oder was auch immer.

Ja.

Und einiges davon ist ja auch in Python tatsächlich geschrieben.

Möglicherweise ist das halt auch so ein Feld, wo Python relativ stark ist.

Ich glaube, viele der, es gibt irgendwie noch Chef Puppet, das ist.

Chef Puppet.

Ja, es sind zwei unterschiedliche Geschichten.

Das ist irgendwie Ruby oder sowas, ich weiß es nicht mehr so genau.

Ja, Chef und Puppet sind Ruby und ich glaube, Salt ist Python und Ensibel ist definitiv auch Python.

Das ist auch Python und OpenStack ist auch Python.

Also, aber ja, OpenStack ist wahrscheinlich alles mögliche.

Aber was ist denn sowas drin?

Also für jemanden, der das jetzt noch nie gehört hat, was wäre jetzt in so einem Ensible denn jetzt drin?

Ich würde es vielleicht tatsächlich nochmal von dem anderen Ende herholen, weil Ensible ist sozusagen schon ziemlich weit drin.

Auf der einen Seite ist Python in diesem ganzen Umfeld erstmal an sich, wir haben jetzt ja zwei Enden.

Auf der einen Seite können wir darüber reden, dass wir Anwendungen haben, die in Python geschrieben sind, von denen ich irgendwie möchte, dass die raus in die Welt kommen.

Und das andere wiederum ist, dass Python ja selber so eine gute Sprache ist, um Tools zu schreiben, die Dinge automatisieren.

Und damit habe ich sozusagen so eine kleine Janusköpfigkeit von dem Ökosystem.

Ja, es ist halt die Frage, von welchem Ende man anfangen möchte.

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

Weil ansonsten glauben, ansonsten glauben unsere Hörer, glauben die Menschen da draußen halt, um Jobs zu machen, muss ich irgendwie Kubernetes rausholen.

Das stimmt halt nicht.

Das ist halt, das ist halt kontextabhängig.

Und ich meine, die eine, die ein, man kann vielleicht mal so ein bisschen skizzieren.

Auf der einen Seite gibt es halt das Problem der Runtime-Umgebung.

Ich habe halt mein Python-Skript und brauche dann irgendwie einen Interpreter, der die richtigen Dependencies alle so hat.

Das ist so ein Spielfeld.

Und das andere ist dann halt tatsächlich auch so diese Mechanik von, wie verteile ich das dann halt von meinem Entwicklung, wie mache ich das auf meinem Entwicklungssystem, wie mache ich das auf dem Staging-System, wie mache ich das dann draußen in der Produktion.

Da kann man so die unterschiedlichen, das wären also mindestens so zwei Perspektiven, aus denen man das mal andiskutieren kann.

Ja, ne, finde ich im Grunde auch genauso richtig, weil ja, also das ist ja auch vielleicht dann tatsächlich das, was Leute praktisch als Problem haben.

Irgendwie würden, wenn sie jetzt sich überlegen, okay, ich würde gerne, weiß ich nicht, das als Pyramid oder Django oder Flask oder was auch immer anwenden, würde ich gerne eine Website oder so bauen und wie kriege ich die jetzt sozusagen live im Video.

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 auch hier nicht gerne machen, ja.

Ein Python 2.7 Gedächtnis-Podcast zum Jahresausklang.

Aber auch innerhalb von Python 3 sind die Sprachfeatures nochmal so weiter, dass man halt auch da zumindest erstmal wissen muss, ah, okay, ich habe eine Anforderung von welcher 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 die neuesten Sachen, wo ich sagte, so, ja oh ja, die will ich unbedingt haben.

Das ist cool, das ist sogar schneller als String auf, ne?

Das kann sein.

Und das ist sozusagen schon mal so das erste Thema von, okay, ich brauche also irgendwie ein Zielsystem, wo die richtige Version von diesem Interpreter vorliegt.

Das ist dann häufig damit gekoppelt, dass ich eine bestimmte Version von einem Betriebssystem irgendwo habe.

Genau.

Wenn ich Docker nehme, dann ist da typischerweise die Auswahl, nimm dir irgendwie so ein Basis-Image, wo jemand draufgeschrieben hat, das hier ist das mit Python-Version so und so oder wo alle Python-Versionen drin sind oder was auch immer.

Aber im Prinzip läuft es halt darauf hinaus, naja, ich habe erstmal die Frage, welchen Python-Interpreter will ich gerne haben.

Ich mache es in letzter Zeit so, wenn ich kleinere Projekte mache und tatsächlich im Sinne von mal so Command-Line-Skripte, das ist bei mir relativ viel dran, dann gebe ich mir Mühe, dass ich am Anfang, wenn ich noch rumexperimentiere und das teilweise auch verteilte Systeme sind, dann habe ich meinen Editor, bei mir ist es dann zufällig der Sublime, mit einem R-Sync-Plugin, mache ein einziges Python-File, und das kann gerne mal für den Anfang bei der Entwicklung 1000, 2000, 4000 Zeilen lang werden und

habe ein R-Sync-Plugin, was mir bei jedem Speichern das auf sieben, acht, neun Kisten verteilt und gebe mir Mühe, dass ich nichts anderes außer der Standard Library benutze.

Dann brauche ich mir nämlich keine Gedanken machen.

Und ich meine, die Standard Library hat einen Haufen Kram drin.

Da ist halt, damit machst du dann keine Webentwicklung mit Django in dem Moment, aber

Interferenz, Interferenz, sorry.

Oh ja, Entschuldigung, ich glaube, das war diesmal ich.

Ah, Weg da, halb mit da weggeworfen.

Lag zu nahm Kabel.

Die Standard Library bietet ja schon so viele Sachen von JSON zu, hast du nicht gesehen?

Typische Dinge, die dann bei mir relativ schnell dazukommen als Dependencies sind dann halt irgendwie Requests oder irgendwas in der Art.

Aber ich baue selbst bei mir die Projekte dann immer erstmal von so einem ganz kleinen minimalen Punkt auf und ich mache nicht so dieses, oh, ich habe hier mein Projekt-Template und jetzt schütte ich erstmal ein Megabyte-Template ins Repository.

Sondern fange halt gegebenenfalls wirklich mit einer einzelnen Datei an.

Quasi.

Blank, völlig blank.

Und kann auf dem Zielsystem auch einfach sagen, hier Python 3.6, da die Datei, puff, mach mal.

Und kann halt, weil ich bin immer der Freund von diesem, ich nerv meine Kollegen, mit denen ich arbeite, auch an der Stelle, ich will eigentlich so schnell wie möglich, eigentlich innerhalb von einer Stunde oder zwei, irgendeine Ahnung haben, wie das, was ich gerade mache, von Ende zu Ende funktioniert, ja.

Also dich interessieren die Knoten dann dazwischen, oder?

Nee, mich interessiert halt, okay, ich will irgendwie X erreichen und dann kann man halt entweder sagen, ah, für X muss ich erstmal A, B, C und D machen.

Und dann fängt jemand an und macht A total hübsch und definiert das durch und macht B total hübsch und definiert das durch.

Am dritten Tag macht er C und am vierten Tag macht er D.

Dann läuft das Skript zum ersten Mal und er stellt fest, nee, das brauche ich eigentlich auch nicht.

Und was ich er haben will, ist, ich rotze A, B, C und D einmal so gerade mal so hin in den so wenig Zeilen wie nur möglich, mit auch wenig Fehlerbehandlungen, wenig, also nur der Happy Path im Prinzip.

So der Idealfall.

Der Happy Path.

Der Happy Path, ja, genau.

Um tatsächlich zu sehen, ist das, was ich hier baue, gerade überhaupt das, was ich will?

Oder fange ich schon mal an, Zeug zu polieren, was ich gleich in zwei Tagen ewig wegwerfe?

Happy, happy, happy.

Happy, ja genau.

Und das erleichtert, und dadurch kann ich halt auch mit wenig Dependencies anfangen, dadurch kann ich halt, also, 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, hast du jetzt nur die Standard-Library, irgendwelche Sachen, aber was macht das?

Also ich habe zum Beispiel ein Skript, mit dem wir bei uns Ceph-Server managen.

Ceph ist so ein verteiltes Storage-System und da hat jede Festplatte, die du in deinem Cluster hast, einen Demon, der da läuft und die Config zu generieren und die Teile aufzusetzen, ist halt nicht so ganz trivial.

Und die Tools, die es dafür schon vordefiniert gibt, die haben alle so ihre Meinung darüber, wie die Umgebung aussehen soll, wo wir leider eine andere Meinung haben.

Und deswegen habe ich dann halt irgendwann ein Tool geschrieben.

Wir schreiben gerne Tools, die andere Tools integrieren.

Wir machen Glue-Code gern selber, so Policy-Code und versuchen eigentlich Werkzeuge einzusetzen, die standalone für sich irgendeinen konkreten Job haben und wir integrieren uns die dann halt.

Und dann habe ich halt so ein Tool, der kann dann halt irgendwie die Festplattencontroller angucken und kann sagen, machen wir mal eine neue Partition, mach mal dies, machen wir mal jenes, baue das mal wieder ab.

Aber eben mit so Policy-Entscheidungen wie, ja, da musst du vorher mal gucken, ob da drüben in den Loks komische Dinge auflaufen, weil das ist ein Indikator dafür, dass gerade der Cluster überlastet ist und darfst du das so nicht machen und solcherlei Dinge.

Und dann ist das halt, was da ist dann der Arc-Parts mit drin und da wird dann mit irgendwie so Prozessen geredet, da ist JSON-Decoding drin, dass so Glucode, um fünf, sechs 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-Libel im Hinterkopf von, wie abstrahiere ich mir eine bestimmte API, um Subprozesse aufzurufen, wie abstrahiere ich mir eine bestimmte API, um HTTP-APIs anzusprechen.

Aber selbst denen gebe ich eigentlich immer wieder die Chance, sich nochmal neu zu beweisen, weil Python nun mal eigentlich so einfach ist, um den Happy Path mal schnell runterzuschreiben, um dann später nochmal mit der Zahnbürste hinterher zu gehen und das irgendwie blank zu machen und hübsch zu machen.

Genau.

Und das heißt also, im ersten Fall bei mir habe ich sogar ein Deployment, da passiert nichts, außer aus meinem Editor raus ein R-Sync irgendwo in die Umgebung rein.

Und ich nehme den Standardinterpreter, der vom System halt mir entgegengeworfen wird.

Das hört sich so ein bisschen an, also du hast gar nicht so viele Klassen, die haben los, also mehr funktional alles oder?

Nö, das geht quer durcheinander.

Das geht quer durcheinander.

Also, Klassen ziehe ich mir halt dann rein, wenn es halt nötig ist, wenn ich merke, da kristallisieren sich Strukturen raus, die sich halt in Klassen gut abbilden lassen.

Machst du noch ein extra Modul dafür oder packst das dann trotzdem alles in die?

So, und das wird halt, 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 mein gescheites Package in Richtung halt, dass da ein Eck rausfallen könnte könnte.

Beziehungsweise Eggs macht man ja nicht mehr.

Also eine Source-Dist oder ein Real 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 PiPy laden kann, etc.

Und das zweite ist, dann fängt es halt meistens auch an, dass da die ersten Dependencies dazukommen.

Weil das kommt meistens sogar früher, als dass ich ein Package draus mache, wenn ich so kleine Sachen habe.

Was aber mit den Dependencies halt auf jeden Fall kommt, ist, Jochen kann es bestimmt auch aussprechen, was ich jetzt denke.

Ja, natürlich Virtual Environments oder irgendeine Art zu isolieren halt die Umgebung, die man auch schafft.

Genau, also verlockende Falle ist halt, aber das ist eigentlich auch schon eine so 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 Yam 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 Pakettierung halt an sich, also auch bei Debian.

Wenn Debian halt sagt, ich pakettiere Version 7 und deine Anwendung braucht Version 8, dann hast du halt verloren.

Deswegen macht man sowas nicht, dass man Sachen in den Systeminterpreter rein installiert, sondern dafür gibt es halt die sogenannten Virtual Ents, die sind seit Python 3 auch kein extra zu installierendes Tool mehr, sondern du kannst ja über, kurz überlegen, Python 3-mvenv und dann Verzeichnisname oder wenn du es in deinem Repo direkt machen willst mit Punkt, erzeugst du dir eine virtuelle neue Python-Installation, in der du dann beliebig Dependencies installieren kannst.

Und dann installierst du die da halt rein.

Das kannst du mitmeißeln, also das kannst du imperativ machen, indem du dann aufrufst Binpip Install Requests.

Oder du kannst auch einen Requirements-File schreiben, was sowas dann deklarativ erfasst, wo du sagst, hier, ich hätte gerne Requirements, ich hätte gern in folgender Version oder ich hätte es gern 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 pakettierst und sagst, ich habe ein Package, wo auch Dependencies in der Setup Pi deklariert sind, dann kannst du die über binpi-Punkt zum Beispiel installieren.

Dann zieht er die Dependencies auf, wobei da gibt es halt dann auch so eine Unterscheidung von wie drücke ich Versionen in einem Paket aus.

Da gibt es eigentlich die Heuristik, dass man sagt, dass man nur dort Mindestversionen angibt.

Dass man sagt, ich brauche mindestens Version XY von 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-Textfile, 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 Exaktversion 2.3.4 oder was auch immer.

Genau.

Das ist so ein bisschen hakelig im Sinne von, das gibt dir kein garantiert pures Environment, weil du kannst es halt vermixen, dass du sagst, du installierst Sachen, Dependencies per Requirements Text und kannst dann gleichzeitig trotzdem noch mit BinPip Install dazwischen rumfuhrwerken.

Ist da nicht jetzt so sogar so eine Neuerung geplant, irgendwie in 3.8, dass man das irgendwie mit in die Verzeichnisse irgendwie direkt reinkriegen kann oder sowas?

Also da war irgendwie.

Ja, das fand ich mal interessant, das habe ich jetzt noch nicht auf dem Schirm.

Ja, das hatten wir irgendwie, ich habe es jetzt aber auch nicht mehr so wirklich genau.

Also da ist es auf jeden Fall so, dass man Pip irgendwie sagen kann.

War das Pip oder ist das.

Man kann ja irgendwie die Versionen aussuchen, ob der irgendwie Versionen nimmt, die irgendwie im System hängt oder halt die.

Nein, das ist halt lokal, also das macht halt automatisch ein Environment, das halt lokal in dem Verzeichnis.

Das ist quasi genauso wie bei NPM auch.

Ja, ja, okay.

Das mit dem System-Byte ist noch ein, es gab die, es gab früher eine, also die Option gibt es immer noch als Abwärtskompatibilität, 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, sie wollen es, 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, was ich habe, ist eher, dass diese Virtual Ents, wenn du dann, keine Ahnung, dann entwickelst du im Team und die Requirements-Text entwickelt sich weiter und du sagst dann Binpip Install-R Requirements-Text, dann kriegst du halt nur die Änderungen.

Und wenn du aber schon irgendwelche Sachen, keine Ahnung, dann gibt es irgendwas, was ist keine Dependency mehr, dann ist die aber trotzdem noch drin, weil etwas, was in der Requirements-Text nicht drin steht, wird halt nicht rausgeworfen in dem Moment.

Du hast halt also keinen, du hast keine abgeschlossene Hülle von dem, was da drinnen definiert ist und kannst dich nicht drauf verlassen, dass nicht noch zufällig mehr Zeug da ist.

Und das kann aber tricky sein, weil es gibt halt Mechanismen zum Beispiel in Setup-Tools, die haben halt Auto-Discovery für irgendwelche Entry Points und dann werden da Entry Points aktiviert, von denen du nicht wusstest, dass sie da sind und dann geht dir irgendwie alles den Bach runter.

Das will man halt einfach nicht.

Und auch das ist so ein Black Swan-Ding im Sinne von, ja, in vielen Fällen funktioniert das sehr gut.

Aber nächsten Dienstag geht deswegen halt irgendein Serverbaden.

Weil wir haben halt so viel Code, der so viel Autodetection für bestimmte Dinge macht.

Dann kann es halt sein, das nächsten Dienstag tritt halt irgendein Exception auf und dann gibt es halt irgendein Tool, das hat so Exception Handling, der geht dann wieder auf die Suche, ob es für das Exception Handling noch irgendeinen Entry Point gibt, der da irgendwie deklariert ist und deswegen kommt da plötzlich irgendwie Code zum Tragen, wo du dachtest, das haben wir doch nie definiert.

Ja, der war halt noch von vor zwei Wochen da.

Auch das ist ein Problem, was Docker ja löst.

Ja, löst Docker das Problem.

Ja, weil 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 Enim sozusagen zweit verwendest, 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 im selber baust du ja.

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

Das ist halt, genau, ich meine, das ist dieses ganze Thema Dependency Management, Vendering.

Wo kommen meine Sachen her, die ich jetzt irgendwie als Route irgendwo in ein 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.

Build-out, habe ich schon mal irgendwie gehört, aber habe ich, glaube ich, selber noch nicht verwendet.

Das ist ein Tool, das stammt halt auch so aus der Zeit, wo die VirtualEnfs sich gerade etabliert haben.

Der kann, zum einen kann er das, was VirtualEnv macht, auch machen, nämlich dir vom System Python entkoppelte Pfade zu liefern, wo die Dependencies klar ausgesteuert sind.

Und was ich am Build-Out spannend finde, ist, der hat eben diese Option, dass du über die Build-Out-Config explizit sagst, auf der einen Seite, du darfst nur Pakete mit folgenden Versionsnummern anziehen.

Und wenn die wiederum rekursiv Dependencies anziehen, die ich nicht dokumentiert habe, hier explizit in meinem Version-Pinning, dann fall bitte aufs Maul.

Und das ist total spannend, weil der putzt auf der einen Seite sozusagen nach hinten hinweg Sachen, die du nicht mehr verwendest.

Das heißt, das ist immer automatisch garantiert clean.

Und auf der anderen Seite kannst du halt dich darauf verlassen, dass wirklich nur exakt das Versionsset da ist, was du halt brauchst.

Und das 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 ein Virtual Env, um die Systemtrennung zu erreichen, das ist doch Bequemlichkeit halber.

Oder installiere da drin CC Build-Out und mache dann eine kleine Build-Out-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 man 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 Open Source-Herz von vor zehn Jahren halt dran.

Das hat eigentlich das bessere Engineering.

Es hat sich halt nur nicht durchgesetzt.

Das ist so ein bisschen Krokodilträne.

Genau.

So, ja, jetzt haben wir so Virtual Ents und.

Ja, dann machen wir doch dein Wrap nochmal drum und machen doch mal weiter.

Also habt ihr, was habt ihr denn noch?

Wie macht man denn dann, wenn jetzt so das Umgebungssetting so gebaut ist?

Jetzt haben wir erstmal die Möglichkeit, dass wir in Projekten überhaupt Umgebungen mehrfach bauen können.

Also du checkst ja jetzt die Requirements-Texte oder das Build-Out checkst du halt mit ein.

Und da kommt eine interessante Frage, nämlich, checkst du zusammen mit deinem Code ein oder machst du ein neues Repo?

Ja, also ich check das immer zusammen mit allem anderen ein, aber ja.

Man könnte natürlich das so machen, dass man den Code in andere Repository packt und dann den ganzen Infrastruktur, wie deployed man das Projekt halt in eine andere Geschichte reinpackt, ja.

Das machen wir eigentlich so, das machen wir sehr gerne.

Also zieht sich dann die Maschine selber immer den Code von Remote und andersherum musst du den immer pushen oder was war jetzt der Unterschied?

Ah, das ist noch ein interessanter Vorschlag.

Interessant.

Also klar, was du halt machen kannst, ist, du kannst jetzt solche Dinge spielen wie auf deinen Zielmaschinen machst du dir einen Conjob, 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 Bildskript aus.

Das kannst du machen.

Das machen wir auch an ein paar Stellen.

Da kommt es ja immer drauf an, wofür man es braucht.

Ja, genau.

Und selbst da kann man eben diese Auftrennung machen, wenn du davon ausgehst, dass deine Anwendung zum Beispiel von unterschiedlichen Leuten mal deployed werden soll, dann macht es halt Sinn, das in unterschiedliche Repos zu legen.

Oder wenn du es über Teams trennst.

Also wir haben es halt häufig, weil wir ja als Dienstleister in Projekten drin hängen, wo wir über jemand anders die Software entwickelt, dann haben die halt ihre Repo für die eigentliche Software.

Und wir haben das Repo für das Deployment.

Wir haben meistens gegenseitig auch Schreibzugriffe drauf, aber es ist so mehr ein, man tritt sich halt nicht unnötig auf den Füßen rum.

Ja, ja, das ist, ich meine, ich weiß nicht, also das, was man da vielleicht, also mache ich jetzt für meine, also so privaten, kleineren Geschichten auch nicht, aber wenn man jetzt irgendwie eine größere Sache hat, was man ja vielleicht dann haben will, ist halt Continuous Integration oder Delivery sogar, dass man dann, wenn halt man ja, sozusagen Code, den man irgendwie geändert hat, dann in einen Master Branch oder so reinpusht, dass das dann halt automatisch irgendwie ein neues Bild lustritt und das auch ausrollt automatisch alles, wenn man halt

irgendwie so einen CE-Server da irgendwo stehen hat, der das dann macht.

Du musst ja einmal vielleicht nochmal für die Leute, die es 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 eine Release fertig ist, und dann baut man die halt einmal und dann presst man die auf eine CD oder speichert die auf Disketten und verschickt die mit der Post oder irgendwie sowas.

Aber was man ja jetzt eigentlich tun kann, wenn das Ganze sowieso alles 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, 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

hinten dran und dann liefern wir das aus.

Und dann fällt an Tag 3 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 Ducktape auspacken, was diverse Nachteile hat, oder man kann halt irgendwie sagen, okay, wir können auch nicht releasen, was dann halt auch wieder Nachteile hat.

Also man ist in einer Situation, wo man keine guten Optionen mehr hat eigentlich.

Und das ist natürlich ein bisschen dumm.

Oder man hat halt das Problem, dass man die Arbeit von anderen Leuten, die dann vielleicht auf anderen Branches irgendwie gearbeitet haben, irgendwie integrieren muss und das dann auch nicht richtig funktioniert und dann 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 so, diese Geschichten sind halt der Versuch, dass sozusagen dadurch, dass man das Release jetzt nicht einmal so ein großes Riesenbrocken-Ding macht, sondern man zerteilt das halt in viele kleine Geschichten, das dann halt so undramatischer zu machen.

Und damit dann dahin zu kommen, dass das dadurch, dass das halt häufig passiert und alles durchautomatisiert ist, ist ja auch so etwas, was man früher hat man dann viele dieser Prozesse, die nötig sind, um irgendwas zu releasen, dann hat man dann manuell gemacht, dann hat man dann mit Chatlisten gearbeitet, weil man sich das nicht alles merken kann.

Und trotzdem passieren dann immer wieder Fehler und alles nicht so toll.

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 den Knopf drücken muss.

Also das jetzt, was man jetzt hat, wenn man jetzt so ein GitFlo sich eingerichtet hat und das dann irgendwie in so ein Framework reinlädt, dann wird das automatisch getestet, dass man bei Git, weiß nicht, Travis oder was habe ich dann mal getan.

Travis CI ist halt so eine Continuous Integration-Geschichte, die war.

Ja, also man hätte 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, die Travis ist eigentlich durch.

Was gibt's jetzt?

Naja, du hast halt GitHub kannst du es ja inzwischen selber machen, Bitbucket kann Pipelines, du hast GitLab.

Da gibt es schon noch einiges.

Okay, die Pipelines werden dann eigentlich integriert.

Ich mache es bei Azure Magazine irgendwie, dann wird dann einfach direkt dann getestet.

Dann kann man sich da was schreiben und dann testet ihr das direkt durch, also ob es läuft.

Einfach auf dem Server integriert insgesamt.

Ja, ob die Tests durchlaufen, kann man natürlich machen und das kann man halt dann auch nicht nur so machen, dass es halt irgendwie für eine spezielle, sondern man kann halt 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 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 dem kann man sagen, welchen Dingern das halt funktionieren sollte und dann werden Interpreter in unterschiedlichen Versionen installiert und Software in unterschiedlichen Versionen und dann wird das halt, wenn die Tests laufen gelassen und wenn die halt durchlaufen, dann ist halt gut.

Aber man kann halt nicht nur das machen, sondern man kann halt beliebige Dinge tun, wie auch irgendwie dann halt ein Deployment lostreten, wenn das dann halt alles funktioniert hat.

Und so, dass das halt im Grunde dann komplett durchautomatisiert ist von irgendwie Entwickler, sagt jetzt, okay, ich bin mit dem Feature fertig, macht eine Release oder macht einfach nur Push auf Master und ja, irgendwie, weiß ich nicht, ein paar Minuten später ist es dann halt im Produktionssystem live.

Aber zwischen irgendwie, man macht halt irgendwie alle paar Wochen eine Release und ebenso etwas, man checkt Code ein und es geht dann sofort live, gibt es halt alle möglichen Zwischenstufen und die dann, ich weiß gar nicht genau, wie die genauen Definitionen jetzt für die unterschiedlichen Sachen da sind.

Hätte ich jetzt auch keine, die irgendwie formal wären.

Ich finde es eher spannend, dass auch da wieder diese beiden Extreme nur zu betrachten, eben genau nicht hilfreich ist.

Wir haben so viele Projekte, wo wir ganz unterschiedlich eben diese Zwischentöne eher sehen, wo auch Entwickler dann teilweise sagen, ich finde es eigentlich ganz gut, wenn ihr bestimmte Sachen auch nochmal mit anschaut.

Und das ist halt genau dieses Thema von, warum will man denn enger zusammenarbeiten, weil man ja möchte, dass Menschen miteinander Wissen austauschen.

Und dann ist sozusagen dieser, so, das jetzt ist 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 du guckst, dann bitte ich dich mal irgendwie noch bestimmte Sachen mit mir gemeinsam anzuschauen.

Oder einige sagen, hier kommen du, kümmere du dich drum, mach einfach wie du willst, drück selber auf den Knopf, wenn du soweit bist.

Da gibt es halt tatsächlich diese ganzen, wenn du es durchautomatisiert, also es ist halt, wenn du es durchautomatisiert hast, kannst du die ganzen kleineren Varianten davon halt automatisch auch spielen.

Zu sagen, okay, das läuft jetzt halt nicht vollautomatisch, sondern es läuft jetzt halt nur bis hier hin und dann musst du nochmal drauf drücken oder dann schicke ich hier nur eine Nachricht ab in irgendein Channel.

Das lässt sich halt besser erreichen und du musst dich im Prinzip halt auf diese, äh, auf diese, da auch annähern und ich meine, jeden Kommit sofort rauszublasen, das kommt dann halt auch drauf an, wie, was für einen Impact so ein Deployment halt hat.

Wenn du, wenn wir sind bei, okay, das dauert halt nur 500 Millisekunden, um mal neu zu starten.

Ja, das kannst du fast immer überall machen.

Wenn du halt Rolling Releases kannst.

Wenn du also sozusagen in der Lage bist, alte und neue Versionen deiner Software parallel zu betreiben, dann versteckst du das hinter einem Load Balancer, hast irgendwie 10 Instanzen und dann updatest du die erste stattest du neu, updatest du die zweite statt ist hier neu, jadada yada.

Dann müssen aber halt die Softwareversionen mit den unterschiedlichen Datenbankständen habt, 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.

Ja, genau.

Der Trick ist, das kannst du ja machen, wenn du dir im Prinzip sicher bist, weil das alles so eingespielt ist, dass das halt nicht kaputt geht.

Wie du vorhin so meintest, wenn es halt weh tut, weil du es halt ständig machst, dann optimieren die Leute halt darauf hin, dass man es ständig macht.

Die alte Laie 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 es halt irgendwie wegkriegen von dem, es ist irgendwas Außergewöhnliches, Schreckliches, wo wir alle Angst haben und dann so zu etwas, was halt vielleicht ein bisschen weh tut, aber dass man das man regelmäßig machen muss, wie sie Zähne putzen, keine Ahnung, dann geht das.

Ja.

Genau, also das ist halt so die Idee dahinter und dann, wie das dann auf die Maschinen kommt, ja, 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.

So für so private, kleine Geschichten.

Also was ich momentan tatsächlich irgendwie selbst am liebsten mache, ist, ich benutze tatsächlich Docker.

Ja.

Also aus Entwicklersicht hat das einige echt 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 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 eine Maschine halt innerhalb von, ja, sagen wir mal, wenigen Sekunden da oder noch weniger.

Und man kann sofort damit was machen.

Klar, wenn man was ändern muss, dauert es auch ein bisschen länger, aber das ist alles nicht so schlimm wie das, was man da vorher hatte.

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, also gerade beim Vagrant, da sind wir auch noch ein bisschen dran.

Wir haben für uns ja, wir haben ja nicht so S 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 rumpken.

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 bin und aber tatsächlich und NixOS kann halt auch solche, installiert es mal bitte XYZ, das haben die in dieser Sprache drin schon verwusstet, das ist eigentlich eine schöne Alternative zu dem, wie Docker das macht.

Aber auch das ist tatsächlich immer wieder so relativ fragil, weil es dann doch noch drauf ankommt, wie das Werkland genau aussieht und nervt gerade auch noch ein bisschen.

An der Stelle ist das Docker-Konzept halt zumindest so, dass man halt relativ gut produktiv sein kann.

Ja, und vor allen Dingen, also es hat halt, sowas ich, ich kann ja einfach vielleicht, also ich mache das so, also ist auch interessant, weil es vielleicht so ein bisschen der umgekehrte Ansatz ist, zu dem, man macht halt ein Skript, das man irgendwie remote direkt vielleicht schon sogar entwickelt, um sofort sehen zu können, ob das irgendwie funktioniert oder nicht.

Wenn man jetzt irgendwie so eine Webseite zusammenbaut, dann hat man da enorm viele komische Abhängigkeiten auch noch zu anderen Systemen hin, blöderweise.

Das ist auch so etwas, was ich irgendwie so ein bisschen schrecklich finde, aber wo ich nicht genau weiß, wie man das irgendwie besser hinkriegt.

Und ich fange tatsächlich oft so an, selbst für kleine Geschichten, dass ich halt so ein Cookie-Cutter-Django-Template oder so halt ausführe und dann erstmal so ein riesen Ding da ausrolle.

Ein selbstgeschriebenes Template oder nimmst du.

Nein, nein, ich nehme das, äh, das, das, äh, irgendwie, kriegt man immer nach Django Cookie-Cutter, googelt, ist von den Leuten, die halt auch das Toolscoops auf Django Buch geschrieben haben.

Und ja, das macht dann halt schon eine ganze Menge Sachen.

Unter anderem halt legt es halt auch schon so Docker-Config-Files, also Docker-Compose, YAML-Files an.

Und ein großer Vorteil jetzt, wenn man damit arbeitet, ist, man kann es sofort hochfahren, kann Dinge damit tun und vor allen Dingen kann man halt auch lokal das Produktionssystem halt mal hochfahren und dann gucken.

Weil oft, also es wäre natürlich schön, wenn das identisch wäre, aber lässt sich oft nicht so wirklich komplett durchziehen und dann hat man schon Unterschiede zwischen lokalem Entwicklungssystem.

Also wenn ich jetzt irgendwas.

High-Tech-Mac gegen 486er schmeißen?

Also genau, und dann Open Server sieht es dann doch anders aus.

Also die Unterschiede sind halt vor allen Dingen sowas wie, naja, wenn ich halt lokal entwickle, dann ist das halt eher das lokale Fallsystem.

Einfach weil ich auch lokal nicht so toll ans Netz angebunden bin.

Und produktiv ist es dann halt irgendwie Google Computer Engine oder AWS oder S3 Buckets oder sowas.

Und das verhält sich dann manchmal dann doch subtil anders oder auch ganz, ganz krass anders.

Dann treten halt Dinge auf, die man halt lokal einfach nicht sieht.

Da funktioniert das problemlos und dann, naja, dann, wenn man das aber trotzdem mal lokal reproduzieren möchte, weil man halt, weil das halt auch blöd ist, man kann ja auch irgendwie das Debug-Flag sozusagen auf Produktionsmaschinen nicht einschalten, weil ansonsten reicht man halt diverse Sachen, die eigentlich vertraulich bleiben sollten nach außen.

Daher, 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 Bagrant wäre das dann schon so, uh, geht wahrscheinlich auch noch irgendwie, aber dann wird es halt schon sehr, sehr schwergewichtig.

Und ja, natürlich funktioniert das auch nur, solange die Systeme halbwegs klein sind.

Wenn das dann irgendwie sehr, sehr viele unterschiedliche Services werden.

Also bei mir ist es halt meistens nur in Postgres-Datenbank, es ist irgendwie ein Riddis, es ist irgendwie vielleicht ein bisschen Salary oder so.

Du hast sowas von Keddy erzählt als Belinst.

Das ist sozusagen der Applikationsserver vorne dran meistens, den ich meistens benutze.

Also der, der, der, der, ähm, der Webserver einfach vorne dran, der halt so ein Reverse-Proxy auch ist für die Applikationsserver.

Applikationsserver ist Junicorn meistens.

Und ja, das sind halt vier, fünf unterschiedliche Container-Typen, das war's.

Und das kann man auch lokal problemlos noch handeln.

Eigentlich.

Genau, und ja, meistens mache ich das dann einfach so, dass ich habe halt so Skripte, die, also ich habe zum Beispiel ein Deploy-Skript, mit dem ich das alten, also ich mache das dann halt per SSH und benutze aber auch Python dafür, damit ich einfach nur Python-Skripte ausführen muss.

Das lockt sich halt dann irgendwie auf einer Produktionsmaschine ein oder so, checkt halt den Code aus, baut irgendwelche Container neu und startet dann alles neu oder so.

Das ist halt so das, was es, was es an der Stelle macht und dann halt auch noch irgendwelche Skripte, die halt lokal und produktiv Systeme komplett abgleichen.

Also Datenbank, Backups ziehen, das Kopieren, irgendwie die vielleicht Daten, die aus irgendwelchen Buckets benötigt werden, ziehen und synchronisieren.

Ja.

Und das funktioniert für mich eigentlich ganz gut.

Hatte halt so ein bisschen das Problem, dass ich jetzt auf dem Server sozusagen auch Docker laufen lassen muss, was natürlich so ein bisschen ätzend ist.

Aber da komme ich natürlich nicht so wirklich drum rum, weil wenn ich das lokal genauso nachstellen können möchte, wie es halt produktiv läuft, dann muss ich das halt so machen, weil ich kann ja den Produktionsserver nicht.

Also wenn das jetzt halt irgendwie, keine Ahnung, ist halt wahrscheinlich irgendein Debian Stable oder sonst irgendwas, das kriege ich ja lokal irgendwie nur schwer reproduziert, irgendwie in alter, also ja, außer wiederum mit Vagrant und Ensibel oder so, aber ja.

Ich meine, das ist halt ein ungelöstes Problem, so ein bisschen da dran.

Was mir immer negativ auffällt, ist, dass die Tech-Sacks immer größer werden, ohne dass wir die eigentlich Probleme gelöst haben.

Also dieses, wenn du jetzt halt einen Docker hast, dann hast du jetzt sozusagen das ganze Thema, ja, die Security-Updates für dein Zeug musst du halt selber machen.

Du musst halt das Basis-Image nachziehen, musst halt hoffen.

Also du kannst es unterschiedlich machen, du kannst es, es gibt welche, es gibt Leute, die machen das irgendwie so, dass sie sagen, okay, da wo ich das Docker-Image betreibe, rebuilde ich den Container jeden Tag nochmal, indem ich halt noch einen Layer drüber jagage, der sagt, Upget, Upgrade, Upget Upgrade.

Ja, genau, genau, so mache ich das jetzt auch.

Das habe ich ja auch da drin sozusagen in meinem Docker-File und ich habe halt irgendwie, ich mache das am Bildno-Cache und dann muss das halt nochmal neu gebaut werden, alles klar.

Ja, genau.

Aber das ist halt, ich finde das halt so von der von dem konzeptionellen Layering eher, ich sag mal, Holzklasse.

Ja, ja.

Die, ähm, die, die das andere, was du meintest, wegen Produktivser und dem Debug, das ist halt spannend, weil du kannst dir ja natürlich schon das über einen Loadbalancer zum Beispiel aussteuern.

Also ich mache sowas gerne mal, wenn es wirklich völlig abstruse Sachen sind, die halt auch zum Beispiel eben temporal davon abhängen, dass momentan im Internet irgendwas komisch ist.

Wir hatten zum Beispiel mal ein Problem, dass.

Der Satz war super.

Ja, wir hatten zum Beispiel mal das Problem, dass Leute bei uns nicht deployen konnten und die kamen an und meinten, bei uns im Netzwerk wäre irgendwas kaputt, weil GitHub geht nicht mehr.

So, und dann gehst du halt irgendwie auf die Suche und dann stellst du irgendwann fest.

Oh, GitHub offline.

Nee, GitHub ist online.

Geht bei uns im RZ aber nur jedes zweite Mal.

So, also damit bist du schon mal in so einer Art von Problem, die du halt nicht lokal nachstellen kannst.

Und das muss halt nicht GitHub sein, das kann halt auch irgendwas anderes sein.

Und da haben wir damals festgestellt, dass GitHub halt über Fastly ausliefert.

Und unser RZ sitzt netztepologisch so genau in der Mitte zwischen Amsterdam und Frankfurt.

Das sind so zwei der großen Netzknoten in Europa.

Und ich kann nicht entscheiden, wenn er will.

Ja, genau.

Es ist manchmal nach Frankfurt und manchmal nach Amsterdam gegangen zu einem Fastly-Knoten.

Und das Problem war, der Fastly-Knoten in Frankfurt war anders konfiguriert als der in Amsterdam und hat auf ein ganz bestimmtes TCP-Flag, was bei uns gesetzt war, allergisch reagiert.

Out.

Habt ihr das Fibel mitgesetzt?

Nee, ich weiß ja gar nicht mehr, welches das war.

Und der mündete halt darin, dass es halt auch die Frage von der Internetarchitektur mit diesen Grey Boxes ist.

Das mündete halt am Ende daran, dass wir halt irgendwo im Fasty-Support aufgeschlagen sind, um ihnen klarzumachen, dass sie dort ein Netzkonfigurationsproblem haben.

Das ist das Obs-Ende von diesem Thema von was gibt es da an Zeug zu debuggen, ja.

Oder eben wenn halt die Webseite steht still, warum?

Und dann gehst du halt her und S-Trace den Python-Prozess, um festzustellen, guck mal, der macht dauernd Socket zu Twitter auf, aber die gehen die wieder zu, die, ich glaube, die bleiben hängen.

Du stellst fest, ah, Twitter ist die Api gerade kaputt.

Und das ist halt, da sind, da ist Docker an der Stelle für uns manchmal so ein, ja, wir nur.

Da 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 Subbrozesse typischerweise im Host.

Beziehungsweise bei uns wird das, also das Docker-Sperchst ja halt erstmal in eine VM und dann läuft die VM halt irgendwo auf so einer Infrastruktur.

Und du kannst ja die Subbrozesse 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.

Und ja, was bei uns häufiger passiert vom Workflow, ist, dass Entwickler tatsächlich das Zeug erstmal einen Docker bauen, das macht sie produktiv.

Und wir gehen dann aber wieder her und sagen, super, das Docker ist jetzt erstmal die Grundlage, auf der wir das auseinanderreißen.

Dann nehmen wir das alles wieder auseinander und sagen, okay, was habt ihr hier da?

Okay, da habt ihr irgendwie die russische Postgres, das ist aber nett, das nehmen wir mal nicht.

Oder was ja halt auch manchmal vorkommt, ist, dass Entwickler sich dann sehr große Basis-Images bauen, wo sie dir nachher nicht mehr erklären können, was davon eigentlich in Benutzung ist.

Ja, das heißt, da hast du dann halt so, ich kenne das selber, wir hatten früher so 2004, 2005 rum auch immer mal für irgendwelche Webprojekte dann uns 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 die alle von diesem Ding abhängen, wo alles drin ist.

Das war so ein bisschen, sowas, so ein Nexus an Dependencies ist immer schwierig.

Und vor allem, wenn du halt implizite Dependencies hast, die einfach nur von, ja, ich benutze halt das Basis-Image.

Und wenn das aber deine Dependency war, die nie gewollt war und die schaltet jemand ab, dann fliegt sie plötzlich um die Ohrne, du weißt noch nicht mal warum.

Da kommen dann teilweise ganz obskure Fehlermeldungen.

Wir hatten das, glaube ich, beim Thema, da hatte jemand eine Postgres mit 17.000 Extensions und unser, also übertriebenermaßen, das ist schon das dritte alkoholfreie Bier hier.

Die hat dann auch nur das noch quittiert beim Einspielen von einem Dump mit einer völlig obskuren Fehlermeldung, die auch kein Postgres-Expert mehr so richtig lesen konnte, bis irgendwann meintest, ah, wir benutzen ja noch die Extension.

So, ah, okay, alles klar, gut.

Und da merke ich, da ist halt genau diese Klärung dann auch für Ops-Leute, was ist hier eigentlich im Einsatz?

Brauche ich das eigentlich?

Wenn du halt immer nur die Weihnachtsbaum-Variante hast mit All Features On, dann läuft dir irgendwann weg, dass du keine Handlungsfähigkeit mehr hast, weil du davon ausgehen musst, okay, hier ist alles installiert, kann alles, was hier installiert ist, kann auch noch in Benutzung sein.

Ich habe keine Ahnung, was ich jetzt tun soll.

Läuft das noch oder kann das weg?

Ja, genau.

Und das ist so ein bisschen dieses, wir hatten, ich habe eine Zeit lang für Soapkorp consultet und Benji York, der war auch ein guter Ingenieur da, der hatte so einen Spruch, der hieß Test what you fly, fly what you test.

Und das war nämlich die Frage von, was ist denn die richtige Anzahl von Paketen, die ich, also egal ob auf Python-Ebene oder Betriebssystemebene oder was auch immer, in Produktion haben sollte.

Und das ist ein bisschen abseits dessen, was viele für besser halten.

Der sagt halt, naja, natürlich ist die ganze Test-Suite und die Test-Tools auch in der Produktion installiert.

Weil du hast es ja mit der Test-Suite getestet.

Du kannst es ja nicht testen, wie es läuft, wenn die Test-Suite nicht dabei ist.

Du kannst natürlich ein Abstraktionsargument sagen und machen, diese Test-Suite ist nicht das Problem.

Also ich mache hier gerade diesen Podcast-Move von, das sind nicht die Roboter, die ihr sucht.

Aber nichtsdestotrotz hast du eigentlich eine ungetestete Konfiguration in Produktion.

Ja, klar, natürlich.

Das Gegenargument dazu ist immer, oh, du hast den Testcode installiert, wenn jetzt zufällig jemand den Testcode anträgert und er dann mit deiner Live-Datenbank redet, dann ist alles platt.

Aber da muss ich ganz ehrlich sagen, da ist der Pragmatiker bei mir.

Ich habe mehr Sachen kaputt gehen sehen, weil zum Beispiel ich eine Dependency hatte, auf die ich mich verlassen habe, die nur um die Ecke über die Testsuite kam.

Und dann ging es draußen nicht mehr, weil die Test-Suite und ihre Dependency nicht mehr da waren.

Also das ist mir schon öfter mal vorgekommen, das Umgekehrte, dass der Ausversehen der Testcode aktiviert wird, das habe ich noch nie habt.

Noch nie.

Und deswegen ist so meine persönliche Historie, dass ich sage, ich will halt immer die komplette Umgebung, die der Entwickler hatte, nicht mehr und nicht weniger so gut geht.

Und deswegen sind so fette Basis-Images für uns dann immer so ein bisschen so ein rotes Tuch.

Weil sich dann rauszusuchen, was ist da jetzt eigentlich das, was hier benutzt wird, woraufhin müssen wir es.

Aber dann kommt ja das nächste, dann will man das ja für die Produktivum auch getuned haben, dass du sagst, okay, ich hole hier aus den Ressourcen, die ich habe, das Beste raus.

Wenn da aber irgendwie tausend unbenutzte Dinge rumgeistern, weißt du gar nicht, was du anfassen sollst.

Ja, das ist, ich meine, das hat natürlich halt auch einen Vorteil, wenn man das halt alles schön sauber durchspezifiziert hat.

Ja, dann weiß man auch, warum man das.

Also das macht man dann auch nicht, wenn man es gar nicht braucht.

Während wenn man einfach ein Image von irgendwo zieht, dann ist halt da per Unfall schon ganz viel Zeug drin und man weiß halt gar nichts.

Ja, genau.

Ich meine, wie gesagt, wir nehmen das ja, wir reißen es auseinander und wir versuchen ja so ein Modell zu machen, wo wir die ständig wiedergebrauchten Sachen wie so ein Postgres oder ein Webserver, die managen wir auf eine Art, wo man dann trotzdem natürlich lokale Config von einem Projekt reinschießen kann und Entwickler sehen das im Prinzip auch alles und können sich auf diesen Maschinen anmelden und an die Teile ranpieksen.

Aber wir bringen da halt diesen ganzen Ballast an Obs-Kram dann rein und sagen, okay, wie muss ich das denn eigentlich ins Monitoring integrieren, wie muss ich das dann ins Backup integrieren, wie muss ich das in Upgrade-Pfade integrieren, wie muss ich dieser ganze Kram, dass das halt auch ausdefiniert ist und eben nicht nur, ja, ich habe dieses Image genommen, weil da ist halt das Postgres mit dem Plugin drin.

Sondern halt, wie monitore ich jetzt, dass das Ding ab ist, wie mache ich das Backup, etc.

Das muss man ja miteinander verheiraten.

Und deswegen finde ich, ist Docker häufig für mich so ein Tool, das hat die Neigung, wenn man das halt einfach nur blind Ende-End einsetzt, dann wird es wieder zum Software über den Zaun werfen.

Ich habe hier was zusammengebaut, du bist bloß dafür zuständig, dass der Strom läuft.

Und damit machen wir jetzt gerade so ein bisschen so einen Kreis zum Anfang.

Dann haben wir wieder das Problem, die obs 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, wobei aus meiner Perspektive der Trans, der da momentan so ein bisschen nicht da sehe, ist halt, dass das 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 funktioniert das halt in der weniger.

Da hat man halt schon eine harte Trennung.

Aber die sozusagen die Trennung ist halt an der, man bekommt halt Maschine und kann da per ROOT und SH dra drauf.

Aber das ist jetzt auch nicht viel besser als das mit dem FDP und dem PHP.

Ja, das genau, ist das natürlich so, ja, das stimmt natürlich auch, ja.

Und dann auf der anderen Seite gibt es dann halt so Dienstleister wie Heroku oder so, die dann halt schon sehr viel selber betreiben.

Da hat man dann das Problem sozusagen nicht, dass man sich auch um die Datenbank und so selber kümmern muss, sondern man im Wesentlichen schiebt man da so den Code hin und der läuft dann in der Heroku-Infrastruktur irgendwie.

Auch bei ABS dann.

Wahrscheinlich auch bei ABS.

Es ist ABS.

Heroku ist ja nur ABS.

Naja, gut, das sind ja auch diese unterschiedlichen Konzepte dann, auf was für Infrastruktur möchte ich aufsetzen, von Infrastructure as a Service, Plattform as a Service zu Whatever as a Service.

Da ist halt auch spannend, diese Frage danach, habe ich halt diese Magic Services im Sinne von die Postgres, ist da irgendwie Magic irgendwo gemanagt?

Das heißt, ich weiß auch gar nicht so richtig, was ist da noch an Sachen drin.

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 Addons, dann sind die zwar eine gut integrierte API, die lebt aber irgendwie in einem Rechenzettum am anderen Ende des Erdballs.

Und wenn man dann halt den Datenschutz irgendwie reinholt, ist so ein bisschen die Frage, weißt du wirklich, wo deine Daten gerade sind?

Die sind bei Heroku.

Okay, die sind bei Amazon.

Das heißt, 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 macht Dinge selber und macht die Fehlerdomänen

auch kleiner.

Also Amazon wird ja am Ende zu einer einzigen großen Fehlerdomäne, ja.

Ja, 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 Jahre her oder so, aber das daran ich mich noch gut, aber 80% des Webs war plötzlich irgendwie tot, weil da ein Rechenzentrum wegen einem Blitz Blitzschlag nicht mehr funktioniert hat.

Lustigerweise auch die eigene Amazon-Statseite war, also die AWS-Statusseite, sie sagen sollte, ob das noch alles funktioniert oder nicht, war die war auch kaputt.

Nee, nee, nee, das war subtiler, das war viel subtiler.

Achso, okay.

Die Amazon-Statusseite ging und hat grün angezeigt.

Weil das grüne Icon war in der Statusseiten Software hart kodiert.

Und das rote Icon haben sie aber aus dem S3 gezogen und das S3 war kaputt und dann blieb das grüne Icon da stehen.

Achso, ja, okay.

Das ist schön.

Also da hatte ich ja niemand andere Intenders gehabt, dann nur grüne Lämmchen 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 in DevOps eingestiegen, wie macht man aber, dass die Leute halt besser zusammenarbeiten können und dass man diesen Hotransfer halt hinkriegt.

Wie macht man sich?

Happy, happy.

Wie macht man die Happy, happy, happy, ja genau.

Weil, und das war unsere Schleife zur Digitalisierung, diese Erkenntnisse finden ja an vielen Stellen im Kleinen statt.

Und das wird jetzt momentan so, das hat so Entwicklungen, das wird mit so Pinselstrichen werden, ganze Systemarchitekturen ganz breit mal auf irgendein Papier geschrieben.

Und dass aber die eigentlichen Schwierigkeiten, und das wissen die Obsleute von den großen Anbietern wie von ABS und von Google, die, wenn man sich die Google System Reliability Engineering Dokumente anguckt und so, die wissen, der Teufel liegt im Detail.

Du kannst es halt nicht sagen mit, naja, ich habe es jetzt halt in der Cloud und dann ist das halt alles super.

Im Gegenteil, du hast jetzt halt noch eine Abstraktionsebene mehr und wir wissen ja alle, also jedes Problem kann dadurch gelöst werden, dass ich halt noch einen Layer oben drüber ziehe.

Und ja, also ich merke so, für mich sind die Lösungen immer an so Stellen, wo ich gucke, wo ich suche sie ja eher immer im Kleinen und an den etwas nicht so ausgetretenen Pfaden, um zu gucken, wie kann man das denn so zurechtschneiden, dass man mit Entwicklern eigentlich so einen konstruktiven Alltag hinkriegt, auch an der Stelle.

Weil eben, jetzt haben wir ja gesagt, diese zwei Rollen, die etwas diskret sind, ob es halt halt eben auch einen anderen Rhythmus, dass man sagt, okay, wir würden gerne ein paar Updates ausrollen, wir würden ein paar alte Versionen sanieren, wir will gerne ein bisschen diesen 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 Meistung auf die neue Major oder auf die oder das, sondern ich will da halt eher so ein vernünftiges Verständnis haben von, warum sind zum Beispiel welche Komponenten für einen Entwickler eher so mit Feingefühl zu updaten, während andere irgendwie völlig egal sind, die updatest du halt durch und da geht nie irgendwas kaputt.

Um da dann halt auch mal die Augen offen halten zu können, was sind denn möglicherweise bessere andere Tools für bestimmte Probleme oder wo muss man irgendwie eine Integrationsleistung noch erbringen oder wo lohnt es sich aus alten 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 selten um.

Naja, ein ganz herzlicher Blick auf die ganze Mikroarchitektur.

Ja, ja.

Richtig.

Ja, im Grunde brauchst du halt, um halt ein Projekt wirklich komplett machen zu können, brauchst du halt in dem Team, das das Produkt baut, halt all diese Kompetenzen irgendwie drin.

Ja.

Das Problem ist da ja.

NIH war da ja irgendwie das Problem, ne?

Ja, ja, ja.

Das ist dann halt auch das etwas, was dann passieren kann, was man dann irgendwie alles selber macht.

Das ist natürlich auch eine Satz, so man kann.

Ja, genau, AnyH.

Aber NIH ist halt der Trick, ist, 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 Make-up-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, benutz mich einfach, dann ist alles gut.

Die kochen und drürt halt auch nur mit Wasser.

Also in einem Amazon irgendwie, hast du nicht gesehen, MySQL ist halt immer noch MySQL, vermutlich noch mit irgendwelchen obskuren Patches drin.

Aber das läuft dann auch bloß in einer EC2-Instanz irgendwo.

Da ist jetzt nicht irgendwie was groß anders.

Der einzige Unterschied ist, du siehst es halt nicht.

Anekdota am Rand, MongoDB hat irgendwie Lizenz geändert.

Weil ihnen das ein Dorn im Auge war, dass die ganzen Plattformen jetzt da irgendwie Geld mit verdienen, dass sie.

Redis, Redis, nicht Mongo, Redis

war es.

Ja, aber MongoDB hat das auch irgendwie gemacht.

Auch?

Oh, okay.

Und hat sozusagen dann quasi Lizenz Amazon verboten, irgendwie MongoDB anzubieten.

Woraufhin Amazon irgendwie ein quasi komplett kompatibles, eigen, selbstgeschriebenes Ding an die Stelle gesetzt hat.

Krass.

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.

Das ist ja die und dafür dafür finde ich halt teilweise dann eben der klar, bei allem, was die Flexibilität in Richtung Investkosten, also CapEx vs.

OPEX und so angeht, ist das alles super und du kannst, musst halt nicht um Erlaubnis fragen, wobei das halt auch.

CapEx, OPEX, ich bin gerade wieder rausgeflogen.

Ja, unternehmerisch, wenn du halt deine Kosten betrachtest, dann ist die CapEx-OPEX-Trennung ganz spannend, CapEx bedeutet, du gibst Geld einmal aus, um ein Gerät zu kaufen, sogenannte Capital Expenditure, also Investitionsgüter.

Da wird der Wert des Gutes, also wenn du zum Beispiel ein Auto kaufst, dann hast du deine da 30.000 Euro, 40.000 Euro, die du ausgegeben hast, die gehen auf einmal von deinem Konto runter.

Die ist, glaube ich, dran lassen.

Also du baust es dann so ein bisschen dann und guckst, wie

du es.

Genau, du brauchst das, der Wert des Autos wird wieder in deinen Büchern geschrieben.

Da ist sozusagen das Geld nicht einfach nur weg, sondern du hast ja einen Gegenwert dafür bekommen.

Dafür musst du es halt abschreiben, es 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 eine RZ stecken musstest, was du dann runter wohnen musst, was dann entsorgt werden muss, etc., kannst du halt ein reines OPEX draus machen, hast halt auch kurze Kündigungsfristen und so.

Das ist halt, das macht es wirtschaftlich extrem attraktiv an den Stellen.

Weil du erstmal bestimmt Scale irgendwie dann auf die Idee kommst, irgendwie die Kosten selber zu investieren in.

Ja, genau.

Ich glaube, Netflix hatte das dann irgendwann auch mal gemacht.

Netflix hat jetzt auch wieder eigene AZs 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 rein.

Ja, da haben wir jetzt quasi ja die Kurven alle wieder zum Ende gekriegt.

Alle losen Enden wieder zum Ende.

Das ist ja die Aufgabe, die der Admin dann ja hat, ne?

Alles was der Operator.

Fix it twice.

Ja, ich war auch irgendwann mal, hatte ich mal so ein Obzeichen in so einem Ihr C-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 zu unserem Gast.

Ich nehme das jetzt nicht als Ehre, weil das ist immer mein Fluch.

Ja, großartig.

Das ist ja auch beim Zuhören sehr interessant alles.

Ja, genau.

Das hat mega Spaß gemacht und wieder ganz viel gelernt.

Ich hoffe, euch hat es genauso viel Spaß gemacht.

Vielleicht, ich weiß nicht, ob wir uns entschuldigen müssen für die Voice-Qualität diesmal.

Oder ob das genauso gut geworden ist wie sonst.

Schreibt uns das unsere Kommentare, falls ihr nicht wusstest.

Wir können jetzt Kommentare bei uns gemacht.

Ja, ich habe die letzte Folge heute mal angehört.

Oh ja.

Da ging es um die Kommentare, genau.

Ich habe auch gesehen, es gab einen sehr guten Kommentar.

Ja.

Ja, das war irgendwas war's, ne?

Feedback.

Hallo at pythonpodcast.de Tja.

Ich glaube, für heute sind wir sonst weit durch, oder?

Wir sind auch schon relativ lange dran, ja.

Ja, so war es ja, dass du da warst wolltest.

Das war echt toll.

Sehr gern jederzeit wieder.

Alles klar, ja, dann okay.

Bis zum nächsten Mal.

Ja, bis zum nächsten Mal.

Tschüss.