Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast Episode 52.
Heute reden wir über Kubernetes. Hallo Johannes.
Hallo zusammen.
Hallo Jochen.
Hallo Dominik.
Hallo Jonas.
Ja, schön, dass du wieder da bist, Johannes.
Ja, schön, dass ich wieder da sein darf.
Super vor Ort.
Und wir haben uns heute Kubernetes ausgedacht, obwohl das gar nicht so viel mit Python zu tun hat,
weil wir das, glaube ich, alle so ein bisschen öfter nutzen müssen, wollen.
Müssen wir.
Müsst du ja.
Manche von uns müssen.
Ich musste auch schon
Genau, und deswegen wollen wir vielleicht
ein bisschen erklären, was das ist, was das so macht und was das so tut
Vielleicht fangen wir wie immer ein bisschen
an mit den News, da haben wir ja noch so ein paar
offen, glaube ich
Ja, aber ich habe mich jetzt auch nur so ein bisschen
Also es gibt eine große News und
die kleineren, da verlasse ich mich dann um das andere, das Wissen
Okay, aber ich mache jetzt einfach mal hier den
News-Chapter
Fangen wir doch einfach mit dem normalen Python
3.12 News an, weil wir haben Oktober
und ich glaube, da ist immer Neues in Python
Ja, es ist jetzt immer einmal im Jahr
irgendwie neue Release. Seit
drei Tagen, oder?
Ich weiß gar nicht genau, wann das
Release wurde, aber ja, noch nicht so lange.
Je nachdem, wann dieser Podcast gehört wird.
Ja, genau. Also für uns ist es
noch frisch, für euch dann vielleicht so,
das war doch vor ein paar Jahren.
Ja.
Genau, und ja,
also,
verwendet ihr es schon? Nein.
Nein? Nicht runtergeladen.
Habt nur die News gesehen. Also ich
hab gesehen, dass du Probleme hattest, was auf deinem Mac
zu installieren.
Bei mir läuft es,
aber ich
habe mich angewöhnt, bei 1 erstmal
alle Projekte umzuziehen.
Es ist jetzt nicht das Feature dabei, wo ich sage,
das baue ich jetzt unbedingt sofort.
Ja, das war auch so ein bisschen mein Eindruck. Das liest sich alles
sehr gut, aber es ist nicht so, dass ich sagen würde,
das will ich jetzt sofort benutzen.
Es ist ja nicht so richtig dabei, was man so richtig
benutzen kann, oder?
Ja, kein neues
Walrus
oder kein Matchcase.
Habt ihr den Match schon mal verwendet?
Ja, häufig.
Ich finde es cool, aber ich habe noch nichts damit gemacht.
So Pattern-Matching, habe ich gehört, geht damit ganz gut.
So Typing oder Type-Matching.
Also dann kannst du so Guards bauen und dann kann man halt gucken,
ob irgendwie so ein Objekt, das reingegangen ist,
auf irgendein Pydantic-Model validiert oder halt nicht.
Und dann kannst du das dann halt direkt weiter nutzen.
Das ist nett.
Ja, wie gesagt, ich finde das total super,
aber ich habe einfach irgendwie noch nicht genug damit gemacht.
Wo wir bei Pydantic reden, ich glaube, Pydantic 2 hatten wir auch noch nicht in den Newsroom,
weil wir ewig lange nichts gemacht hatten.
Doch, doch, hatten wir jetzt das letzte Mal
Genau, aber
nur, dass ich damit Probleme hatte, das abzudaten
Ich habe in der Zwischenzeit
ein weiteres meiner Projekte irgendwie updaten müssen
weil jemand auf GitHub
ein Issue aufgemacht hat und gesagt hat
Ich habe das jetzt gerade mal probiert, es gibt mir diese komische
Palentik-Fehlermeldung, weiß gar nicht, was das ist
Ja, und
genau, so habe ich das dann auch gemerkt, dass das nicht mehr
funktioniert und
das habe ich jetzt auch umgezogen und das war auch
deutlich mehr Arbeit, als ich gedacht hätte
und also ich habe jetzt zwei Projekte
umgezogen auf die neue Python Tech Version
und das war beide Male ätzend.
Also man braucht da schon so ein bisschen
Muße, wenn man das
irgendwie machen will. Oder bei mir, ich habe
vielleicht das auch einfach falsch gemacht am Anfang
und deswegen habe ich da besonders viel Arbeit,
aber ganz wahrscheinlich, höchstwahrscheinlich.
Ja, aber gut, jetzt inzwischen
habe ich ein bisschen Übung, dann kann ich ganz andere
Sachen auch noch umstellen, das ist dann kein Problem mehr.
Wenn du 312 benutzt hättest,
hättest du vielleicht schon viel bessere Fehlermeldungen
bekommen, direkt gesehen, woran es liegt. Könnte sein, aber
ich finde zum Beispiel auch die PyTentic-Fehlermeldung
nicht so richtig hilfreich. Also zum Beispiel
diese
Field Missing-Fehlermeldung, die finde
ich ist echt, ich weiß nicht, ob die
schon immer so war oder ob die jetzt erst so geworden ist,
aber die
ist halt, genau,
das ist hier, ich zeige es dir jetzt mal auf dem
Monitor, kann sonst keiner sehen außer uns, aber
da steht halt irgendwie so,
also da steht noch mehr, da ist eine ganze
Liste von irgendwie Field Required
Type Missing Input Value.
noch nicht, weil ich kann das lesen vom Sofa aus, was du da dann rechnen kannst.
Ich mache das jetzt größer.
Ja, ich wollte gerade sagen.
So, und dann, wenn man diesen Traceback kriegt, der eigentlich relativ lang ist, sodass man
Schwierigkeiten hat, den relevanten Teil zu erfassen, ich habe jetzt das hier extra so
rausgekattet, dass man es sehen kann, aber dann ist das, was ich halt lese, vor allen
Dingen das hier.
Da steht dann halt irgendwie type missing, input value, database URL und dann komme ich
halt, ah, database URL ist missing.
Das stimmt aber nicht.
Nein, die ist ja da.
Sondern die ist da.
Aber die Value ist falsch.
und die B-Engine ist halt missing, was da drüber steht.
Und man denkt, das gehört hier noch zu einem anderen Teil und was hier gar nicht drinsteht.
Das heißt, dieser Kram, der danach kommt, ist eigentlich völlig irrelevant.
Aber das ist halt, also ich meine, klar, also wenn man jetzt weiß, okay, ach, das Ding hier ist missing.
Okay, dann ist klar, aber man überliest das leicht.
Also so wie das bei dir aussieht, könnte auch in der Formatierung, wahrscheinlich hast du es absichtlich so formatiert,
dass es in deinem Eintrag so aussieht.
Nein, nein, das sieht wirklich so aus.
Dass es tatsächlich etwas schräg ist.
Also die Fehlermeldung ist ein bisschen zu verhackstückelt.
Hast du das mal mit 3.12 probiert?
Nein.
Du hast vorher schon das Problem umgezogen.
Ja, ja, ja. Also die
Pydantic ist ja schon eine neue Version
seit einigen Monaten.
Aber wäre es anders, wenn 3.12
dabei geholfen hätte?
Ist das anders in 3.12? Das ist doch eine Fehlermeldung von Pydantic.
Ja, ja, genau.
Aber ich weiß nicht,
ob die verbesserten Fehlermeldungen in 3.12
auch was damit zu tun haben, wie dieser ganze
Traceback-String gerendert wird.
Genau, weil
weil da sind ja auch verschiedene andere Sachen passiert, die dieses Rendern beeinflussen,
weil die App-Strings ja beispielsweise sind auch neu.
Ja, kommen wir gleich noch zu.
Also auf jeden Fall dieses Pydentik-Ding, das hat mich jetzt schon zum zweiten Mal,
wenn ich das nächste Mal sage, beim dritten Mal, hat es auch wieder Schwierigkeiten gemacht.
Das liegt raus, das liegt bei mir.
Ja, das kann auch sein.
Genau, was ist die Konstante an diesem Experiment?
Ja, genau.
Jetzt sind wir schon bei den 3.12-Änderungen.
Genau, bessere Fehlermeldung. Das ist das Einzige, was ich mir davon gemerkt habe. Also es gibt ein paar Dinge, die da geändert wurden, aber die einzige, die ich mir gemerkt habe, weil sie mich an die PyPy-Episode erinnert hat, war, dass jetzt, wenn man irgendwie eine Variable verwendet und die nicht definiert ist sozusagen in der Methode, dann sagt einem jetzt der Traceback so, sag mal, kann es sein, dass du self.vorher vergessen hast?
und PyPy konnte das halt schon einige Zeit
und ich glaube, das ist halt, das haben sie sich
dann von PyPy abgeguckt.
Diese
Geschichte und es gibt halt noch so ein paar andere Dinge.
Ich weiß gar nicht genau.
Wisst ihr das?
An der richtigen Stelle unterkringeln und sowas?
Ja, genau, solche Sachen. Also da ist noch ein bisschen
was passiert.
Ich weiß es nicht, weil ich sehe nie Fehlermeldungen.
Ja, so.
Johannes, du machst einfach,
erkennt ihr das Modul, als wollt ihr eigentlich mal so ein Pick, ne?
Fuckit, du machst einfach pip install fuckit und dann schreibst du einfach add fuckit
oder with fuckit und dann gibt es keine Fehlermeldung mehr,
sind weg.
Ja, dann eine
andere Geschichte,
F-Strings haben eine ordentliche
Überarbeitung erfahren.
Ja genau, davon musste man natürlich umbauen, hast du gesagt.
Ja, also
das mutet so ein wenig nach Detail an,
dass man jetzt sagt, okay, du kannst jetzt auch Quotes
innerhalb von F-Strings haben.
Genau, zwar die selben Quotes wie der String.
Das hat mir tatsächlich aufgefallen,
schon, dass man da nicht die gleichen Quotes
verwendet. Genau, und das beschränkt natürlich die
Tiefe, in der du F-Strings
vernesten kannst, also ineinander schachteln
kannst, auf die
Anzahl unterschiedlicher
Arten zu quoten. Wie tief
würdet ihr denn empfehlen, so F-Strings
in der Quote? Aber was zum Beispiel echt
nervig war, dass du zum Beispiel in Multiline
F-Strings keine Kommentare hinter so
einem F-String machen mehr konntest. Ja, und Multiline
F-Strings gehen
natürlich schon,
wenn du das halt so machst, wie man das mit Multiline
Strings halt so macht, aber was jetzt
auch zusätzlich geht, ist, dass du
quasi Newlines in
F-Strings haben kannst.
Das geht nämlich jetzt auch, das ging vorher auch nicht.
Genau, Backslash war vorher auch gebannt.
Genau, geht jetzt auch. Also das wirkt
so ein bisschen wie Details, aber nein, das ist
dafür haben sie den
Tokenizer komplett neu geschrieben.
Der ist jetzt rein NC
implementiert und ist halt auch ein gutes Stück
schneller, ist irgendwie 60% schneller als vorher und
ja, das hat jetzt zur Folge,
und wie man F-Strings beliebig nesten kann.
Und all diese anderen Details jetzt auch gehen.
Zeit, dass zum Beispiel Logging oder sowas mal aufsteigt und auch mal F-Strings verwendet.
Ja, da habe ich schon unterschiedliche Meinungen darüber gehört.
Ja, also genau. Also ich auch, aber ich verstehe es noch nicht so genau.
Also meine Meinung macht das Logging nicht, weil das nicht evaluiert werden soll,
bevor es, wenn es nicht geloggt wird, auf dem falschen Level.
Ja, also der Haupteinwand, den ich da gehört habe, der kommt von Sentry.
und Sentry macht ja
Log Aggregation oder Error Log Aggregation
und
wenn du jetzt quasi deine
Fehlermeldung loggst und da deine
Fehlerobjekte mit reinschreibst,
dann ist das ja ein
anderer String bei jeder
dieser Fehlermeldungen. Das heißt, du kriegst
keine Aggregation. Wenn du aber
normale Template Strings
benutzt, dann
schickst du ja den Template String und die Argumente, die
da reinkommen. Das heißt, du kriegst deine Aggregation
anhand des Template Strings
und kriegst dann innerhalb dieser
aggregierten Sache gesagt, hier sind
mit folgenden Attributen aufgetreten,
x, y und z.
Ja, okay, aber man könnte ja auch erst irgendwie
Sentry erklären, dass sie das bitte anders aggregieren sollen
und das da wieder rauspopeln sollten.
Ja, gut, aber dann bist du jetzt schon wieder bei
so Sprachsachen, dass du sagst,
da musst du doch rausfinden,
wo die F-Attribute drin sind.
Ja, aber das Login-Modul ist eh einigermaßen furchtbar,
mit CamelCase und sowas, das ist alles eh bäh.
Ah, das mag ja schon sein,
aber gerade diese F-Strings, die zerstören halt,
dass du siehst, wo da die Templates
stehen. Also das einzige
Argument, was ich gehört habe, ist, dass halt je nach
Log-Devel die gar nicht evaluiert werden sollen
und dass wenn du das halt als F-String da reinschreiben würdest, dann
würdest du halt jedes Mal immer...
Ja, keine Ahnung.
Ich weiß es nicht.
Ja,
genau. Achso,
wofür das vielleicht auch ganz... obwohl ich glaube, das ist jetzt
auch eine
doof Idee. Es gibt ja für
das hatte auch der, na, wie heißt er noch, Thomas Güttler
der hier war, wegen HTMLX
immer gesagt, also es gibt ja in
Python gibt es also nicht sowas wie
Template Literal Strings
in JavaScript oder so
wo man halt Partials da relativ gut
handeln kann und
das geht halt mit F-Strings nicht so richtig und
das geht jetzt vielleicht schon, also das könnte man eventuell
naja, auch nur bei einfachen
Template-Ersatzungen wahrscheinlich, ob das Sinn macht
weiß ich auch nicht. Hast du irgendwas von Partials
gerade gesagt? Django Template Partials, damit geht
Das ist halt auch ganz gut eigentlich.
Genau, das sind aber jetzt so ein paar Module, die waren in einer der letzten
Folgen von, weiß ich mehr was,
DjangoCast?
DjangoChat meinst du,
den Podcast, ja, das war da auch drin, ja.
Ja genau, da war irgendwie
eine nette Folge, wo die Leute genau diese
Templating-Sachen-Partials
mitgebruchst, die waren schön,
weil man kann man schöne Sachen mit
einzelnen Templates machen, die sonst so
nicht einfach so modular
Ich habe das auch schon ein paar Mal verwendet
und das ist echt tatsächlich ziemlich gut.
Kommt wahrscheinlich auch in Genro 5.1 mit rein.
Ah, ja.
Genau.
Es gab so ein paar
Performance-Geschichten bei AppStreams, die sind ein bisschen
schneller geworden. Es gibt jetzt
irgendwie Comprehension Inlining.
Was ist das?
Ehrlich gesagt,
was es genau macht, weiß ich nicht, aber
List-Set Comprehensions
werden jetzt ungefähr zweimal schneller.
Das nehmen wir doch mit, oder?
Das ist gut, ja.
Und dann natürlich
die GIL-Aufteilung.
Das habe ich mit Interesse gelesen.
Ja, das ist ein sehr interessanter...
Erklär doch mal, was ist denn die GIL-Aufteilung?
Ja, es gibt ja das globale
Interpreter-Log. Das ist
ein großes Log und das
sorgt dafür, dass Python sehr schlecht ist bei
Multithread-Anwendungen, weil
immer nur ein Thread Python-Code
ausfüllen kann. Und das ist natürlich so ein bisschen bescheuert,
weil dann bringt es ja nichts mehr.
Doch, doch, das bringt ja durchaus schon was.
Ja, es kommt darauf an, wie deine Threads sind.
Aber wenn du lauter Python-Threads laufen hast, also du kannst
nicht mehr als eine CPU verwenden.
Genau, nicht mehr als eine CPU, aber du kannst schon,
wenn du mehrere Threads machst, machst du halt viel mehr
I.O. möglicherweise. Genau,
für I.O. bringt es was, aber nicht für Compute.
Also nicht für CPU.
Das Argument, warum Python so ein
Gill-Hunt ist, dass das für den Single-Threaded-Case
einfach die beste Lösung
ist, weil du keine komplizierten
Logs einbauen musst, weil es
schnell ist, weil du gar nichts hast.
Weil du halt nicht gucken musst, muss das frei werden?
Genau, es ist einfach ein
Interpreter ein und fertig.
Und es gibt ja schon lange
Bestrebungen und viele Bestrebungen,
diesen GIL loszuwerden, zum Beispiel PyPy
oder auch Unladen Swallow, falls ihr euch da noch
dran erinnert. Wir haben versucht, das loszuwerden.
Bitte was? Bitte wer? Das war so eine
Initiative, ich glaube, von Google,
von Google-Angestellten,
die versucht haben, eben den Python Interpreter
neu zu schreiben, ohne das Global Interpreter
Log. Und es kommt alle paar
Jahre wieder, weil es einfach ein großes Ärgernis ist,
dass du Multithreaded-Programme schreibst,
an Leanswallow, aber trotzdem nicht
mehr CPU kriegst.
Genau, an Leanswallow, weil halt die
schneller fliegen kann.
Und jetzt
wandert es auch so langsam, oder beziehungsweise
es ist ja schon lange unterwegs, dass man
das schneller macht und den
GIL so ein bisschen wegbekommt.
Und da gab es jetzt eben diese
eine Bewegung, dass es keinen
globalen, kein globales
Global Interpreter Log mehr gibt, sondern
eben eins für Subinterpreter.
Das heißt,
die Python Runtime, der
CPython
die CPython VM
kann jetzt Subinterpreter starten, die dann
ihr eigenes Global Interpreter lockern
aber ich weiß nicht, wie man da drankommt
Jochen, weißt du, wie man das macht?
Ja, über die, also momentan nur
in C-Code kann man das halt
kann man halt sich halt einen neuen Interpreter erzeugen und da
irgendwelche Dinge mitmachen, in 3.13
soll es dann eine API geben, die halt auch
innerhalb von Python Code verfügbar ist, wo man dann einfach sagt
Hallo, machen wir mal einen neuen Interpreter
und dem gibt man dann einen String
und dieser String wird dann als Python-Code
darin ausgewertet.
Da kann man sich natürlich auch irgendwie hübschere Abstraktionen
noch drumherum bauen, keine Ahnung.
Ja, also ich meine, ich finde das auch so ein bisschen
so ein spezielles, also das mag schon
Anwendungsfälle geben, wo das sinnvoll ist,
aber ich meine, das wird schon
sehr speziell, weil ich meine, für viele Sachen, wo man
sowas, wo man denken würde, oh, das kann
ich gut brauchen, warum macht man da nicht einfach einen zweiten
Prozess auf? Also kann man ja auch machen.
Einen zweiten Interpreter und
und da muss man halt schon...
Da hast du halt dann diese Prozessgrenze.
Da musst du halt irgendwie
die Daten von einem Prozess zum anderen übergeben
und in vielen Fällen, denke ich,
ist das wahrscheinlich kein so großes Problem, weil...
Wie macht man das dann am Messen?
Ja, also es hängt halt von den Daten ab.
Ja, aber oft übergibst du halt einfach nur
eine URL zu irgendeinem Bucket
oder sowas.
Ja, das kommt natürlich auf den Anwendungsfall an.
Da gibt es auch Anwendungsfälle,
wo man viel Daten übergeben muss.
Viel Kommunikation und viel Compute.
Dann ist schlecht. Dann musst du ihn mal serialisieren
oder musst du ihn in den Speicher irgendwo reinschreiben
oder irgendwie... Genau, du kannst
natürlich per Pickel einfach serialisieren
oder irgendwie übergeben
oder über den Pipe
schicken oder sowas. Also auch ein Standardweg, wie man
das macht, ist dann halt einfach
Chat-Memory verwenden, sodass halt alle Prozesse,
die man erzeugt, halt auf den gleichen Speicher
zugreifen. Das geht auch.
Wie geht denn das? Aber dann hast du ja wieder das Locking-Problem.
Als Elevator?
Naja, solange du nur liest, ist es kein Problem.
Ja, solange du nur liest, ist das nie ein Problem.
über Python.
machen sollte. Und dann gibt es vielleicht so ein paar,
bei denen geht das aus irgendwelchen
Gründen nicht so gut und dann macht das mit den Subinterpretern
halt irgendwie Sinn.
Also du machst irgendwie so ein
Map-Use-Ding, um die Computation
auseinanderzudröseln und dann zusammenzuführen und wo
schreibst du dann wieder was rein und wenn du sagst, du
Ja, du kriegst es halt wieder zurück.
Und dann je nachdem, wie groß das ist, was du zurückbekommst
von der Berechnung, kannst du es halt
einfach auch wieder irgendwie
serialisieren und in deinem Masterprozess
sozusagen wieder deserialisieren.
Und wenn das zu groß wird, dann schreibst du das halt
und von wo realisiert
du das denn? Also von dem Chat memory
oder was sagst du mit der Pipe, was meinst du damit?
Es geht ja nur darum,
dass du in diesem Modell, was der Jochen vorstellt,
nur zwei Synchronisationspunkte hast, nämlich ganz am Anfang,
wenn du es verteilst und ganz am Ende, wenn du es zusammenbringst.
Und das bedeutet,
dass es nicht so wichtig ist, wie schnell
die Kommunikation ist, weil du die nicht die ganze Zeit
verwendest, sondern du verwendest die nur einmal
en bloc. Wenn du jetzt aber so
ein System hast, wo du zwölf Threads
hast, die alle 10 Millisekunden
miteinander kommunizieren, die irgendeine Nachricht
über die Queues schicken, sowas wie das Actor-Modell.
Wenn du in Erlang sagst, jede Funktion
ist ein Thread und du schickst jedes Mal
bei jedem Funktionsaufruf eine Message rüber.
Dann geht das nicht mehr, weil
du dann eben über diese Prozessgrenze
irgendwas haben musst, was
innerhalb des Betriebssystems über die Prozessgrenze
drüber geht und das ist üblicherweise langsam.
Egal, welche Technik du hören willst.
Ob es Pipes sind oder Shared Memory oder
was weiß ich.
Es ist ganz anders, weil du hast ja automatisch irgendwie Kontext-Switches dabei,
wo es halt langsam wird.
Aber die Frage ist halt, passiert das in der Praxis häufig?
Weil ich würde sagen, du hast üblicherweise einen von beiden Fällen.
Du hast halt entweder den Fall, du musst halt viel I.O. machen,
aber du brauchst eigentlich keine CPU.
Also wenn du jetzt sowas hast wie eben so eine Web-Anwendung
oder irgendwie eine Anwendung, die irgendwie so, weiß ich nicht,
selbst sowas wie ein massiv paralleler Chat-Server oder sowas,
der rechnet ja nichts aus.
Also der schiebt ja nur irgendwie Bits und Bytes hin und her.
Da brauchst du die mehreren CPUs eigentlich nicht.
Oder du kannst halt dann mehrere Prozesse starten,
die dann halt alle, auf die du dann loadbalancest,
die dann halt alle auf einer CPU hocken,
aber die sich nicht miteinander unterhalten
müssen. Oder du hast halt den Fall, wo du
Number Crunching machen willst, aber da brauchst
du dann eigentlich diese
Kommunikation nicht mehr.
Das heißt, Number Crunching meinst du, du lässt dann doch auf jedem
Kern irgendwie einen Python-Prozess laufen und
Du willst halt ein Array von
einem Petabyte irgendwie Zahlen sortieren
oder sowas.
Klassische Anwendung.
Ja, das ist immer das,
womit man dann demonstriert,
irgendwie, dass man irgendwas parallelisieren
kann oder so.
Ja, aber dafür brauchst du normalerweise keine
Kommunikation zwischen den Dingern.
Und ja, also dass man den Fall
hat, dass man gleichzeitig Kommunikation
viel hat und gleichzeitig
irgendwie ganz viel
Prozessor braucht,
also
der ist aus meiner
Perspektive schon ein ziemlicher Nischenanwendungsfall.
Ich meine, das wäre natürlich schön,
wenn das so gehen würde, aber...
Vielleicht, weil es nicht geht, Jochen.
Ja, vielleicht auch, weil es nicht geht.
Wenn es einfacher gehen würde, würden wir das alle machen.
Ja, vielleicht.
Weiß ich nicht.
Auf jeden Fall gibt es Begräbungen in die Richtungen
und das ist doch schön.
Genau.
Jetzt hast du nochmal bei 3.12 was gesagt.
Teigel?
Subinterpreter.
Ja, und der Subinterpreter macht immer seinen eigenen
Subinterpreter.
Was haben wir denn noch?
Ja, es gibt jetzt so ein paar
Typing-
Verbesserungen.
und
also ich finde das
ehrlich gesagt, da sagen alle so
das ist so toll, weil jetzt geht das noch einfacher als
vorher. Wie bitte, das war vorher einfach?
Also mit dem Type-Var-Type-Aliases
Jetzt geht es noch einfacher.
Also wenn man
sich da anguckt, wie die Signaturen von Funktionen aussehen,
das sieht schon, also
definierst du ja zuerst so ein
mit Type-Var irgendwie den Namen
für einen generischen Type und dann
setzt du den noch irgendwie da ein
und dann, also es ist schon
Also du hast auf jeden Fall ganz viele Klammern
und ganz viele Doppelfunkte und komische Dinge
Ich muss auch sagen, ich habe den Fehler gemacht
Ich habe jetzt meinen Editor umgestellt auf die
neue Linting-Variante mit komplett
MyPy auch drin und so
Also normalerweise habe ich das immer nur beim
Committen drüber laufen lassen, aber jetzt
Es ist so ein bisschen
nervig
Ja, sozusagen
Verwendest du dann MyPyD oder
Genau
Genau, die MyPy
Da läuft halt dann so ein MyPy-Server und dann
kann ja mal fragen und mit den ganzen anderen
Sachen halt auch und
ja, es ist mehr gekringelt, als ich dachte.
Weil vorher war das immer schön sauber und aufgeräumt
und schönster lässt sich auch
ein bisschen
also, wenn man halt Module benutzt, die zum Beispiel
falsch typen oder sowas,
also in Anführungszeichen, dann meckert
MyPy direkt und du musst halt einfach nebenschreiben,
dass er es ignorieren soll, weil es kommt halt aus dem Modul und es ist ja
falsch, das kann ich jetzt ja nicht ändern. Oder ich kann
halt den TypePint davon dann neu machen oder
sowas. Also, oder eine Julien draus
machen, was ja aber dann eigentlich auch falsch ist, weil
Was soll das?
Ja, da müssen wir glaube ich mal eine Episode drüber machen
Ja, eine Typing-Episode müssen wir machen
Nicht nur eine, glaube ich
Das sind so ein paar lange Episoden
Ja, also
gerade so bei generischen Types und so
die finden das ist alles wild
und da muss man halt echt
Jango-Stubs oder sowas
Ja, jetzt ist es auf jeden Fall
besser geworden
Genau besser geworden
Man kann ja zum Beispiel sowas sagen
wenn man jetzt irgendwo sagen will
Sternstern KW-Args oder so.
Was man ja manchmal
machen möchte, dann ist das ja irgendwie nicht gut
zu typen. Any.
Ja, kann man natürlich auch sagen,
String Any, Dict String Any,
aber machen ja auch viele,
aber das natürlich dann geht halt auch irgendwie so ein bisschen der Nutzen
verloren. Also was man jetzt tun kann, ist,
man sagt KW-Args
Unpack und dann zum Beispiel
Ecke Klammer auf und dann gibt man den Namen
von einem TypeDict an und dann
definiert man dann sozusagen für jede,
für jedes Keyword-Argument
quasi den genauen Teil. Oh, da könnte man auch
eine Dataclass reingeben oder sowas. Aber warum?
Ja, sieht ziemlich genauso aus wie eine Dataclass, ja.
Warum definiert man die denn nicht direkt?
Was ist dann noch der Sinn von Quark? Wie willst du
den hinschreiben? Kannst du nicht.
Du kannst dann halt
jedes einzelne KW hin.
Ja gut, das kannst du natürlich auch machen, ja. Du kannst dann einfach
die ganzen Keyword-Argumente hin.
Wenn es halt ganz viele sind, dann hast du sie halt getypt.
Ja, und du kannst es halt auch nicht wiederverwenden.
Das hast du schon hingeschrieben.
Und Validierung kannst du nicht machen.
Ja, ist schon ein Nischenfall.
Und genau, bei den
Generic
Type-Geschichten
muss man jetzt auch nicht mehr
irgendwie type-wahr und type-alias davor schreiben,
sondern man kann halt irgendwie einfach type nehmen
als Keyword, also als Statement
und dann irgendwie den Kram dahinter schreiben
und muss auch nicht mehr den ganzen Kram importieren.
Das funktioniert einfach so.
Ja, also wenn man
drauf steht, dann ist das wahrscheinlich eine deutliche
Verbesserung.
aber ich weiß nicht. Ja, Typing ist schon so ein bisschen
Bloatware, oder? So Typing? Manchmal?
Ja, ich glaube,
da müssen wir mal eine Episode machen.
Aber das können wir jetzt
nicht leisten.
Ja, es ist halt wirklich
nützlich. Ich würde sagen, kollegatives Arbeiten, gerade
mit Leuten, die das noch nicht so wissen, was da
passiert, ist das echt hilfreich.
Um denen so zu zeigen, welche Dinge es gehen sollte.
Ich habe da auch Meinungen dazu, ja. Also, nein.
Ja.
Was haben wir noch? Ah, coole
kleine Verbesserungen, die aber, achso,
genau, auch noch zum Typing, weil das gehört
auch noch zum Typing dazu, es gibt
jetzt einen Override-Dekorator.
Override? Ja.
Wo man halt über eine Methode schreiben
kann, addOverride
und dann damit dem
einen TypeChecker sagen kann,
also
das hier überschreibt übrigens eine Methode
in der Superklasse, weil
das Problem, das man bisher hat, ist halt,
wenn man jetzt Methoden überschreibt
in der Unterklasse,
Dann kann die ja komplett korrekt getypt sein und so
und der statische Typechecker
und jetzt nennt jemand irgendwie die Methode
in der Oberklasse, aber refactored die
und benennt die um.
Dann merkt der statische Typechecker
davon überhaupt gar nichts und alles stimmt.
Das Verhalten ändert sich aber.
Weil ja jetzt plötzlich
irgendwie das nicht mehr überschrieben wird.
Und ja, dann ist natürlich schlecht.
Das heißt, du sagst explizit, hey, ich überschreibe hier eine Methode.
Genau, und sobald jemand in der Oberklasse
das Ding umbenennt,
dann sagt dir der
statische Type-Checker,
das überschreibt überhaupt keine Methode mehr,
hier ist irgendwas kaputt, was vielleicht schon
hilfreich ist. Ja, und das tatsächlich
findet man ein Tramax, ja.
Genau, das
ist mit dem Typ-Typing-Zeugs
dann durch.
Zu Dekoratoren, ah, habt ihr das
schon mal verwendet, Cached-Property?
Ich hab das auch schon häufiger verwendet,
genau. Ja, das weg.
Warum?
Es war kaputt.
Das Problem ist, es hat
massiv viele Logs gemacht und
hat irgendwie nicht auf Instance-Ebene
geloggt und
das ist ganz schrecklich und die Leute haben es gemessen und festgestellt,
es ist viel langsamer damit als vorher.
Ich habe es nie überprüft.
Ich dachte mal so, Cash Property,
voll gut. Nee, war scheiße.
Das heißt, man hat einfach
Cash und Methodenaufruf, oder?
Ja, also ich habe es eben für solche Dinge benutzt,
wo halt dann irgendeine Berechnung stattfindet und dann
Genau, also wenn die Berechnung sehr lang ist, gut, vielleicht ist es dann auch noch irgendwie tatsächlich effizienter, aber so generell war es oft eher langsamer mit dem Cache-Dekorator drüber als ohne.
Naja, man kann ja dann die Kalkulation cachen und dann eine andere Sache machen, wo der Property drin ist.
Ja, also auf jeden Fall, irgendwie hat sich jemand das genauer angeguckt, dabei hat sich herausgestellt, so wie das gedacht ist, geht das alles gar nicht.
Und daher haben sie es jetzt entfernt.
Das heißt, man muss das jetzt selber bauen.
also du kannst Master 2 Methoden, die eine Methode ist
eine Property, die andere Methode ist
Es ist nicht so schlimm, also man kann sich relativ leicht
sowas bauen. Wenn du keine Logs brauchst.
Ja, wenn man Logs braucht, dann
ist man eh schon in so einem
Drachen
Territorium, das ist halt
ja, muss man eh gucken.
Ja, genau, dann
Drachen
Territorium, ja
wo die wilden Tiere wohnen. Genau.
Große Drachen.
Das ist so ein Nervpunkt,
dass es in Python halt mehrere Module gibt,
die sich irgendwie mit sowas wie Files
und so Zeugs beschäftigen, ist halt
einfach nervtötend. Hat historische Gründe,
aber es gibt halt ParseLib,
so als das aktuellste.
Es gibt OS,
es gibt dann noch SH-Util
und es gibt noch irgendwie so ein paar andere.
Und je nachdem, was man machen möchte, muss man halt eins von denen
verwenden und es gibt keins, wo man alle verwenden kann.
Auch ParseLib hat natürlich auch schon
diverse, also ParseLib, da wird immer
rumkritisiert, ein bisschen zu Recht,
dass es ultra langsam ist.
Vielleicht hat sich das jetzt auch gebessert, das weiß ich nicht genau.
Auf jeden Fall, wofür man früher immer noch
mit OS häufig verwenden
musste, war halt OS-Walk, also wenn man
halt so ein Dateisystem im Baum einfach mal so
rekursiv durchgehen möchte.
Und in Parslip gab es nichts dafür.
Und jetzt gibt es halt ein Walk
in Parslip.
Das musst du machen, etalieren musst du das so machen
und dann immer rekursiv deine Funktion selber aufrufen.
Ja, aber das willst du vielleicht nicht selber schreiben.
Und gleichzeitig Etalfiles
und das ist
Arbeit und keine schöne Arbeit
und leicht falsch zu machen Arbeit.
Du machst irgendwas anderes und dann willst du jetzt mal
kurz über alle Falschen in dein Dateisystem
umgehen und dann fängst du da an mit Rekursionen
zu machen, Dinge zu tun und so,
wo viel schief gehen kann.
Ich weiß nicht. Also da will man doch
eigentlich eine Funktion einfach nehmen und die
dann einfach...
Generell alles, was mit Dateien zu tun hat, ist so,
dass man eigentlich da lieber Funktionen dazu hat,
die sich schon mal jemand
ausgedacht hat, der was davon versteht.
Ja
Die sind deceptively simple, wie man so sagt
Die sind ganz einfach zu schreiben und gehen dann auf
überraschend beeindruckende Art und Weise kaputt
An vielen verschiedenen Stellen
An allen Stellen
Oder Cycles
Du kannst ja Cycles in deinem Verzeichnis haben
Und links
zu einem gut darüberliegenden Verzeichnis
und dann hast du eine Kurve drin
und dann hast du schon einmal
Tüdüdüdü
Der Ding zu da, der Ding zu da
Und dann kommt der Beachball
Wenn du dich in dieses Rabbit Hole
eingreifst, dann wird das, was du eigentlich machen wolltest,
nicht mehr fertig, sondern dann
bist du irgendwie verschwunden.
Oder mit dem Cycle-Klink, das könnte man ja mit lustiger
Sachen machen.
Ja, schon. Oder andere
Devices und dann von den anderen Devices wieder das
andere Device eingebunden und
ein Cycle über Devices.
Habe ich letztens irgendwo
sehr schön, hat das jemand beschrieben,
ich weiß nicht, ob es auf Mastodon war oder
keine Ahnung. Ja, also die
coole Innovation von Unix ist ja,
und wie man das in Unix einfach alles ein File ist.
Es gibt ein kleines Problem mit dieser Philosophie,
nämlich dass eigentlich so gut wie gar nichts ein File tatsächlich ist.
Ansonsten war es eine super Idee.
Ja, ist was dran.
Den Bits musst du jetzt nochmal genau erklären.
Das war jetzt so ein Insider.
Also die Philosophie von Unix ist ja, alles ist ein File.
Da gibt es Files, wo du die CPU-Auslastung auslesen kannst.
Aber das heißt, du machst einen Händler auf, der zeigt an irgendeiner Stelle und dann
Ja, du musst halt den richtigen Dateinamen wissen
Alles ein Pfeil, tatsächlich fast alles ein Pfeil
Aber was bedeutet das denn?
Vielleicht willst du ja erklären
Also du hast ein Pfeil da drauf hin und kannst von da aus losrennen
Nee, du hast
Nee, das ist ein Pfadnamen
Du hast ein Pfadnamen und dann öffnest du die Datei
Und anstatt dass du Daten von der Festplatte liest, kriegst du halt Daten von irgendwoher anders geliefert
Zum Beispiel CPU-Auslastung oder zum Beispiel Netzwerksockets oder zum Beispiel sonst irgendwas
Das ist zumindest die Idee, ja
dass wenn du halt den richtigen Part
auf eine bestimmte Datei hast ja das ist gar keine Datei sondern ein Socket an irgendeinem Also Netzwerkverbindungen sind auch nur Files Ger sind auch nur Files
Piles sind auch nur Piles.
Eines der ersten Unix-Dinge, die man
so macht, wenn Leute das nicht kennen, ist,
man nimmt halt irgendwie die Shell, zum Beispiel Bash,
sagt halt Cat, bin Bash oder
nach
größerzeichen DevAudio.
Und dann kann man irgendwie in dem Programm
aus dem Lautsprecher-Tropfen zuhören.
Und solche Dinge.
Weil das ist auch nur eine Datei.
Also unter Windows oder MS-Boss
war das halt, das ist halt irgendwie,
weil das war zu aufwendig.
Das ist ja auch von Unix inspiriert, aber das haben sie
halt nicht so richtig implementiert, sondern da haben sie
da so komische Dinge gemacht wie
Laufwerksbuchstaben oder Device-Buchstaben.
Ja, so reservierte Namen.
Du darfst keine Datei haben, die COM1 heißt.
Auch unter Windows 11 noch nicht.
Und das ist natürlich eigentlich
total schrecklich.
Aber ja gut,
wenn man das nicht anders kennt, dann
Fällt einem das vielleicht gar nicht so auf, aber
genau, nur
genau, also diese Philosophie, dass halt alles
ein Pfeil ist und man alles gleich behandeln kann, ist eigentlich schon sehr cool
und ist eigentlich auch immer
so ein Beispiel für eine sehr gelungene API
weil man halt fast, also ganz ganz
viel kann man damit erschlagen
und die API ist gleichzeitig einerseits
sehr schmal oben, also sozusagen
es gibt nur wenige Dinge, die man drauf machen kann
lesen, schreiben, bestimmte
Stelle spulen
man kann aber wahnsinnig viel damit
machen, die ist halt total tief
und PyTest.
Genau, also sozusagen, also das ist halt, also Leute sagen mal, das ist wirklich schön, das ist eine schöne Abstraktion, das hat super funktioniert. Genau, man kann halt sagen, aber ein kleines Problem, es gibt ein kleines, kleines Detail, das nicht so richtig gut funktioniert, nämlich die meisten Sachen sind kein Pfeil und verhalten sich auch nicht so und daher...
Wie kriegt man das Problem? Muss man da irgendwie reinstopfen oder so eine Spule bauen oder...
Nee, das ist halt so ein bisschen, ja,
das stimmt auch irgendwo.
Also es ist halt einfach, ja, es gibt halt,
alles ist halt furchtbar.
Was habe ich letztens, ich habe letztens ein Essay gelesen
auf einer sehr schönen Domain. Die Domain heißt
irgendwie stilldrinking.com
und da steht irgendwie
Programming Sucks oder so
und da ist sehr schön aufgelistet,
was alles so schief geht und warum
eigentlich nie irgendwas funktioniert, warum wir alle keine schönen Dinge
haben können.
Kann man ja mal lesen. Ja, ich glaube, ich verlege das mal in den Schuhen.
Ja, bitte, bitte.
Den kenne ich auch noch nicht
Ja, der ist schon relativ alt inzwischen
Der ist von 2014 oder so
Aber er ist immer noch genauso wahr wie damals
Er wird sich wahrscheinlich auch nie ändern
Ja
Das mit dem Audio muss ich auch mal ausprobieren
Das kann ich auch nicht
Direct von Bash auf
Def Audio
Genau, was auch
C-Python benutzt jetzt auch Precumit
Auch nett
Precumit sind die Hooks, die den Code automatisch
blinden?
Ja, also du kannst halt mit
Precommit irgendwie diverse
Regeln aufstellen, die halt erfüllt
sein sollen.
Also zum Beispiel Black-kompatibel oder
bei C-Python ist das jetzt in R&C, also irgendwie
Jammer-Syntax gecheckt wird oder
weiß ich nicht, falls sie zu groß sind.
Weniger Bugs? Fühlst du weniger Bugs?
Vielleicht?
Naja, du kannst damit
zumindest irgendwie relativ hart
sicherstellen, dass bestimmte Regeln
eingehalten werden. Machst du Precommit bei deinem Projekt?
auch mit MyPy?
Ja.
Aber, ja.
Mach ich auch, also ich mach
Ruff und MyPy und Icehorde und Black
und PyUpgrade und
sowas. Ja, mach ich auch.
Also bis auf Ruff, das benutze
ich nicht, weil ehrlich gesagt,
wenn man MyPy verwendet, ist es so langsam,
dass alles an den Regalen ist.
Aber catcht MyPy
nicht nach dem ersten Durchlauf?
Ja, mag sein. Ich weiß nicht, ich hab immer
die Erfahrung, dass wenn ich mir denke,
so, ich hab doch jetzt auf diesen Knopf gedrückt,
doofes PyCharm, warum reagiert
dieser Knopf, ist ausgegraut und irgendwas
tut es und dann gucke ich hoch, so und sehe ich, ah,
CPU-Auslastung ist hoch, dann denke ich mir so,
PyCharm. Und dann denke ich mir,
nein, MyPy.
Und es dauert einfach lange
und ja. Also MyPy muss man ja
irgendwie, wenn man das konfiguriert, die ganzen Dependencies
irgendwie mit angeben, das ist ja nicht fürchterlich alles.
Ja, weil das halt
in einem eigenen Virtual Env alles stattfindet.
Ja, aber warum kann das das nicht selber
raffen aus der PyProject-Hummel oder sowas
wo man seine Dependencies hat oder wo auch immer die liegen.
Tja, wo auch immer
die liegen. Ja, da kann man doch sagen,
deine Dependencies liegen hier. Guck mal nach,
das Format kennst du bestimmt. Nimm sie
und bau da was mit.
Ja, vielleicht. Ich weiß es nicht.
Aber es ist auf jeden Fall
nicht so einfach. Aber C-Python benutzt es jetzt.
Es erhöht die Wahrscheinlichkeit, dass es nicht
weggeht. Das ist gut.
Ja, also dass sich jemand findet, der das
dann halt weiter maintaint. Was auch noch schön ist,
ist, oh, das ist total super.
Ich weiß nicht, das habe ich in jedem Projekt
gehabt und jetzt ist es
also, jetzt ist es halt quasi
hoffentlich gelöst.
Ich habe in jedem Projekt irgendwie eine
kleine Funktion, die ich dann auch immer von Projekt zu Projekt
kopiere, weil es ist einfach zu wenig,
um daraus irgendwie ein eigenes
Paket zu machen oder so, aber ich brauche es halt irgendwie
tatsächlich, in jedem Projekt brauche ich halt irgendwie so ein Ding,
dass mir, wenn
so eine lange Liste oder
irgendwie ein langes Iterable
kommt, was mir das halt so in Batches
zerlegt, wo ich dann mit den Batches irgendwas mache.
Brauche ich immer.
und das ist auch ein Schild.
Nee, einfach
in Stücke hacken, in Viererblöcke, in Achterblöcke,
in Zwölferblöcke. Genau, weil du willst
halt zum Beispiel irgendwie alle,
du willst immer 100 Dinger gleichzeitig in die Datenbank
oder immer in hunderter Blöcke in die Datenbank schreiben
oder ausgeben
oder sonst irgendwie was machen,
aber du willst das halt nicht jedes Mal machen, sondern halt
so. Genau, also ich brauche das irgendwie
immer und
bei mir heißt diese Funktion
meist so chunked oder sowas
und jetzt gibt es eine in
in Intertools. Die heißt Batched und die macht genau das.
Ist die neu? Die ist neu.
Ich dachte, da gäbe es sowas ähnliches.
Also man kann auch mit Zip
oder mit Icelice bauen.
Aber meine Batched ist neu.
Ich habe irgendwie letztes Jahr beim Advent of Code
Varianten irgendwie sowas.
Jeder hat sowas schon mal geschrieben.
Ja, also da ich das irgendwie immer brauche
ist es gut, wenn das jetzt in der Standardbibliothek
Das hast du jetzt reingebracht, Jochen
Nein
Aber
irgendwie, ja, ganz in meinem Sinne
Ja, das glaube ich
Dann genau, ich habe es wie gesagt schon installiert
und ich hatte auch so ein bisschen Probleme
Also ich weiß nicht so ganz genau
woran diese Probleme liegen, ist ja auch noch alles sehr frisch
Ich habe sie bloß, ich stehe noch unter dem Eindruck
sie erfahren zu haben
So was wie zum Beispiel
also bei Projekten, die ich dann auf 3.12 umgestellt habe
das ging halt irgendwie nicht
also irgendwie das Installieren von dem ganzen Virtual-Event funktioniert nicht, weil
es sagt halt so, ich kann dieses Wheel nicht bauen
von irgendeiner Abhängigkeit
und dann habe ich was reingeguckt, warum kann ich das nicht bauen, ja weil irgendwie
Dist-Utils vielleicht fehlen
manchmal, weil Dist-Utils sind
Disintegrated, aber wenn man Setup-Tools installiert
dann kommen die alten Dist-Utils quasi mit und dann geht's wieder
und
genau, achso, und früher wurde das automatisch
in VNF, wenn man per VNF
irgendwie in Visual Nv erzeugt hatte, wurden die Setup-Tools direkt mit installiert
und das passiert nicht mehr, also das ist auch nicht mehr drin
also auf jeden Fall, da an der Stelle ist es halt bei mir irgendwie zuverlässig gebrochen
und wo es auch gebrochen ist, das fand ich etwas
überraschend und ich habe keine Ahnung, ob das irgendwie so beabsichtigt war
ist es bei vielen Abhängigkeiten
die halt nur noch eine PyProject
Hummel mitbringen, aus der dann
sozusagen steuert, wie den
Wheel erzeugt wird
das geht nur noch, wenn PyZMQ
installiert ist, keine Ahnung warum
Was ist denn PyZMQ?
Irgendwas mit einer
diese, irgendein
Messaging Queue
Hätte ich jetzt nicht mit Wheels
in Verbindung gebracht. Ja, ich auch nicht, deswegen hat es mich
gewundert und zwar auch in einer relativ neuen Version
und wenn man das halt nicht installiert hat, also ich muss jetzt
eine Reihe von Projekten das Ding als
Core-Abhängigkeit mit hinzufügen,
weil ansonsten konnte man
irgendwie die ganzen Abhängigkeiten nicht mehr installieren.
In 3.12, in 3.11 geht's noch.
Also keine Ahnung, was da genau das Problem ist,
aber naja.
Vielleicht installiert das irgendwie eine Subdependency
auf die irgendwie hin.
Ja, genau
weiß ich jetzt nicht, aber das ist halt etwas,
wo ich gestolpert bin und wo ich auch gestolpert bin,
aber das kann sein, dass das jetzt ein sehr spezifisches
Mac-Problem ist, ist halt,
auf dem M1 findet, wenn man
Python kompiliert mit Homebrew
das
statt der aktuellen OpenSSL-Version
die OpenSSL-Version 1.1
wenn sie installiert ist
und das geht dann schief, weil
zu alt, wahrscheinlich ist das irgendein Fehler im
Configure-Skript oder so
und wenn man
dann OpenSSL 1.1 entfernt
und dann geht's
ja
das möchte man ja eigentlich
ich dachte dann, wenn man sagt
im Fernsmal, dann hat es mir gesagt, ganz viele Pakete,
die darauf basieren, unter anderem sowas wie
TMAX und so und
diverse andere Geschichten,
ImageMagick, LibHive,
so Sachen, wo man sagt, das kann ich nicht deinstallieren.
Da wiederum
dependet zu viel anderes Zeugs drauf.
Wenn man das alles deinstalliert, dann
OpenSSL 1.1 entfernt und dann
das nochmal installiert, dann
linkt das halt gegen die richtige OpenSSL.
Ja, gut. Also wahrscheinlich ist da auch
wieder ein Fehler in irgendwelchen Configure-Struppen.
Das ist doch ein Mac-Problem, oder?
Kauft euch mal einen richtigen.
Ja, kann schon sein.
Genau, ja.
Jetzt haben wir aber tatsächlich so ein bisschen News, also nur von
Python 3.12 gemacht und ich glaube,
wir müssen
eine neue Folge
aufmachen mit Python 3.12.
Wir machen chaptermark.
Also eigentlich wollten wir ja über
Kubernetes reden und ich glaube, wir hatten jetzt so
eine neue Markierung
und haben die ganzen News jetzt, wenn ihr noch
dran seid und Kubernetes benutzen wollt.
oder übersprungen habt.
Python 12 ist schon auch relevant.
Ja, das stimmt natürlich.
Die anderen News dann später.
Haben wir noch welche?
Nee, ich nicht.
Sprechen wir jetzt über Kubernetes.
Spannend.
So ganz am Einstieg, was ist denn das?
Das ist schwer zu sagen.
Es ist schwer zu beschreiben, was Kubernetes eigentlich ist.
In wenigen Worten zusammengefasst
würde ich sagen, das ist eine verteilte
Runtime für Docker-VMs.
Also sowas, das irgendwie so ein paar Boote auf einem See beaufsichtigt.
Nee.
Doch.
Also ich glaube, wenn man sich das so vorstellt, dann laufen halt so bestimmte Boote, also Pots, so Container halt.
So Containerschiff sozusagen.
Genau.
Ja, oder ich weiß nicht, ob das ein Schiff ist.
Vielleicht sind das einfach so kleine Nussschalen oder sowas auf so einem See rum.
Und irgendwer guckt halt, dass die in der richtigen Reihenfolge da laufen.
und dass man damit Dinge anstehen kann.
Also das ist ein Bild, was ich nicht
in den Kopf kriege, aber
man kann es sicherlich so
betrachten.
Du hast ja auch schon mal gesagt, verteilte Runtime
für, man könnte auch sagen, vielleicht ein Betriebssystem
für eine Gruppe von Rechnern irgendwie.
Ja.
Die kann man dann wie ein Ding ansprechen,
obwohl es halt viele Rechner sind.
Ja, also das finde ich tatsächlich gar nicht so wichtig
da dran, sondern das Wichtige da dran finde ich eigentlich,
dass das weggeht von dem imperativen
Modell, was man ja so bei den, also wenn man
Ansible macht, dann sagst du, auf diesem
Server soll jetzt das hier ausgeführt
werden und auf diesem Server soll das hier ausgeführt werden.
Das ist sehr imperativ,
du gibst an, was passieren soll.
Und Kubernetes geht
hin zu so einem
deklarativen Modell.
Du sagst gar nicht mehr, auf dem Computer soll
das passieren, sondern du sagst, es soll drei
Instanzen von dieser VM
geben. Also das ist wahrscheinlich auch noch so
einer der Tracker, die Kubernetes am meisten irgendwie
verwendet wird, dass du halt irgendwie so ein
Load-Balancing machen kannst und halt
Skalieren kannst,
in horizontale Richtung, wenn du mehr
Last kriegst oder sowas.
Oder dass du vielleicht so Releases machen kannst.
Das ist ein Aspekt davon,
dass du so Skalierungsthemen
hast, finde ich jetzt aber gar nicht tatsächlich so wichtig,
sondern für mich ist eher wichtig, dass du so
eine Abstraktion hast zwischen
was ist das
Substrat, also die
Computer, die du hast und was ist
die Workload, also die Sachen, die du ausführen
möchtest. Und
und so ein bisschen wie bei einer Datenbank.
Bei einer Datenbank ist das Substrat die Festplatte
und die Workloads sind die Daten, die du drin hast.
Und ich will eigentlich gar nicht selber entscheiden müssen,
welche Daten wo liegen und wie die aufgebaut sind.
Und deshalb nehme ich eine SQL-Datenbank,
weil da sage ich einfach nur, hier sind die Daten
und die haben folgende Eigenschaften,
sorgt dafür, dass die gut sind.
Und bei Kubernetes ist es genauso.
Da sage ich, ich habe hier meine Nodes,
das sind die Computer, die ich habe,
und nehme die mal.
und dann komme ich von der anderen Seite und sage, hier ist meine Workload.
Ich brauche jetzt zwei VMs von der Sorte und fünf von der Sorte und sieben von der Sorte
und die müssen so und so miteinander kommunizieren können. Sorg mal dafür.
Also zweimal eine Datenbank, fünfmal eine Anwendung. Genau, und die müssen folgende Ports offen haben
und die müssen folgenden Speicherplatz haben und die müssen miteinander kommunizieren können und die müssen so
und so exposed sein und sorg mal dafür, dass das passiert.
Ja, da steckt man halt quasi so ein bisschen Lego zusammen.
Jein
Du steckst es nicht selber zusammen
sondern du sagst hier
so soll das Lego Modell am Ende aussehen
Schreibst die Bauanleitung für Lego
Und das ist das, was mich da eigentlich
dran reizt
dass du eben nicht mehr sagst, es soll etwas passieren
sondern du sagst, es soll ein Zustand erreicht werden
Ja
Und das beschreibt auch so ein bisschen das System
Das beschreibt so ein bisschen
was Kubernetes überhaupt ist
Das ist eine Engine, die dafür sorgt, dass
ein Zustand von VMs
erreicht wird
mit den gegebenen Ressourcen.
Und das ist was Sinnvolles, das ist was Nützliches.
Das ist nicht dann nützlich, wenn du eine VM
ausführst oder wenn du einen Rechner hast.
Das ist dann nützlich, wenn du 100 Rechner hast
und 1000 VMs ausführen musst.
Weil dann, wenn du das manuell machen möchtest,
das fängt alles an.
Dann musst du
irgendwelche Node-Gruppen machen und musst
irgendwelche Verteilungsdinge
machen und Affinitäten und Netzwerk
was weiß ich.
Mit Kubernetes sagst du halt einfach,
das ist jetzt in Anführungsstrichen
gesetzt, sagst du einfach, hier sind
deine Nodes und dann kommst
du von der anderen Seite an die AP ran und sagst,
ich habe jetzt hier Workloads und zwar diese hier
und diese hier und diese hier und diese hier und jetzt mach mal.
Und idealerweise
sorgt dann das System dafür, dass die
Workloads, also die Images, die du laufen
möchtest, auf diesen Knoten, die du hast,
verteilt werden, sodass die
alle ihre Anforderungen erfüllen und dass die
Knoten trotzdem alle gut ausgelastet
sind und gut verteilt sind und
was weiß ich nicht, was man da alles noch einteilen
kann.
Aber im Endeffekt ist es,
wenn man das, also aus
Anwendersicht, aus Workload
Betreiber Sicht,
ist es schon was relativ simples.
Du sagst halt, du beschreibst halt,
wie deine
Workloads ausschauen sollen,
was du gerne am Laufen haben möchtest.
Und auch wie viele.
Also wenn du so ein System hast, wo du
100 Nodes hast oder 1000 Nodes,
dann ist es leicht zu sagen, ich brauche jetzt 100 von
diesen Files oder 200 von diesen oder
da ist jetzt gerade Last drauf, also mach die bitte
hoch oder wieder runter.
Das klingt
erstmal sehr charmant,
wenn man das einfach so, wenn man sagen kann, okay,
ich abstrahiere von den konkreten
Maschinen irgendwie, da können unten
Leute immer neue
Maschinen und Racks
stecken und mein Cluster
wird halt größer.
Genau, und
Ich muss das alles gar nicht wissen.
Und auch von den Operationen.
Du gehst weg von den Operationen.
Also eine Node braucht tatsächlich nichts anderes als
ein installiertes System mit einem
Kubernetes. Das weiß ich nicht genau, wie
das eingerichtet wird, weil
diese Operations-Seite
habe ich noch nicht selber erlebt. Wir
benutzen überall nur Managed
Kubernetes.
Das Lustige ist ja,
das Argument gibt es ganz oft,
Google macht das, also machen wir das auch.
und das
stimmt aber so nicht, weil Google hat halt
bestimmte Anforderungen und andere
Firmen oder Projekte oder Teams haben halt andere
Anforderungen. Wir haben ja bestimmt zwei Applikationen,
dafür brauchen wir ein Kubernetes-Cluster. Ja, genau.
Wir haben hier zwei Server, dann mach doch mal
ein Kubernetes-Cluster auf. Wir wollen da
vier VMs laufen lassen, mach doch mal ein Kubernetes-Cluster auf.
Nee, das brauchst du nicht.
Dafür brauchst du einen Server
und da kann jeder Docker-VMs starten
oder andere VMs.
Das brauchst du dann, wenn du
1000 Rechner hast und 30 Teams
die 5000 VMs
da drauf betreiben wollen, weil dann willst du da nicht mehr
händisch reingehen und sagen, ihr kriegt
jetzt diese Server und ihr kriegt diese Server
und ihr kriegt diese Server, sondern dann sagst du einfach
hier ist euer Quota und hier ist euer
Quota und hier ist euer Quota
und ihr dürft da drauf starten,
was ihr wollt, solange ihr in eurem Quota bleibt.
Kurz, was ist ein Quota, also ein Anteil
von Rechenkapazität? Genau, also du kannst
Accounts,
also es ist natürlich alles viel komplizierter, als es
sich anhört, weil genau wie bei Datenbanken,
eine Datei auf die Festplatte speichern ist easy,
eine Datenbank betreiben, ist nicht so easy.
Und das kommt auch mit der
Scale dazu. Wenn du so eine gewisse
Größe erreicht hast, wenn du halt mehr
als fünf Teams hast oder mehr als zehn Teams hast,
dann musst du da irgendwie Autorisierung drin haben.
Und dann musst du auch dafür sorgen, dass
sich die Teams nicht gegenseitig zu sehr auf die Füße
treten können. Oder abschießen können.
Genau. Das heißt, du musst verhindern,
dass ein Team sagt, so, wir brauchen jetzt 100.000
VMs mit jeweils einem Gigabyte Speicher und
dann ist dein ganzer Knoten nur noch von
diesen kaputten Sachen. Ich hatte
so ein bisschen, so meiner Erfahrung nach,
Ich hatte nicht so das Gefühl, dass mir das wirklich
dafür sorgt, dass mir niemand auf die Füße tritt,
sondern eher so, dass ich die auf mir
also ich hätte mir immer noch die Schmerzen, als ob mir jemand auf die Füße
getreten hätte,
aber ich kann die nicht mehr sehen, die das waren.
Ja genau, weil du eine andere Absatzgruppe
Es gibt eine Administrationsgruppe,
die dann trotzdem alles da hat, die Geisterkundin
hat, die das Putzen und Zaubern hat.
Aber normalerweise, also um zu dem Normalzustand
zurückzukehren, ja normalerweise hast du halt dann da
deine Teams drauf, die irgendwelche Accounts auf diesem
Kubernetes-System haben und diese Accounts haben ein Quota,
das heißt, die dürfen eine bestimmte Menge
CPU anfordern und eine bestimmte Menge Rahmen
anfordern und
mehr
starten, mehr VMs starten kannst du halt
nicht, du kannst dem System sagen, starte bitte
mehr VMs und dann sagt das System, nee, ich kann
nicht mehr VMs starten, weil dein Quota
aufgebraucht ist
und ja, auch das kann zu Schmerzen
führen, dass du halt sagst, okay, wir brauchen
aber mehr und das geht nicht mehr, nur
das Problem hattest du vorher auch,
wenn du hier die drei Server hattest und
die sind halt voll, dann kannst du
Ich sehe höchstens noch selber dran.
Es gibt schon Probleme, die man kriegt,
die ich so sonst nicht
kenne, also die ich halt ohne
Kubernetes nicht habe,
weil diese Abstraktion
halt doch irgendwie leaky ist.
Ja, natürlich.
Also zum Beispiel etwas, was halt irgendwie
keine Ahnung, vielleicht gibt es auch
eine tolle Lösung für, aber was ich
halt schon irgendwie ätzend fand, ist halt,
dass du eben, wenn du jetzt
viel Zeug betreibst, dann kannst
du ja nicht irgendwie allen
Sachen irgendwie ganz viel Ressourcen geben, weil
sonst sagt der Cluster dir so,
du hast ja viel Schuttland, das geht nicht.
Das heißt, du überlegst dir dann so, okay,
naja, also eigentlich
braucht der, das braucht ja gar nicht so viel.
Dann setzt man
die Ressourcen darunter.
Zu wenig Ressourcen, dann war dein Quota zu niedrig.
Ja, und
dann passieren aber im Betrieb so Dinge,
wo man dann halt mal kurzfristig ein bisschen mehr
braucht. Und dann, zum Beispiel
Hauptspeicher, und dann killt es das einfach weg.
Das ist halt,
und das ist dann tatsächlich
das Interessante, was da passiert,
weil das System
kompliziert genug ist, findest du
auf einmal die Ecken und Kanten. Also zum Beispiel,
dass du zwei
Limits hast. Du hast ein Requests-Limit
und ein Limit-Limit.
Du forderst, du brauchst mindestens
so viel RAM,
aber auf keinen Fall mehr als so viel.
Und manchmal brauchst du es halt aber doch.
Und diese Worte bedeuten auch nicht,
dass was sie bedeuten, sondern
dieses Requests, wenn du zwischen dem
Requests und dem Limit bist, dann heißt
es, dass Kubernetes
diese vor allem abschalten darf.
Weil du ja
über dem Request drüber bist. Du bist über
das, was du angefordert hast.
Diese Worte bedeuten halt
nur, wenn du übers Request gehst,
darf Kubernetes
deine VfA abschalten.
Beim Limit muss es die VfA abschalten.
Das heißt, es darf halt dann, wenn andere
anfragen, ob sie neue Ressourcen haben können
und es keine freien mehr findet.
Ja, beziehungsweise, wenn du über
Es gibt zwei wichtige
Kenngrößen, CPU und
Memory.
Für jede der beiden kannst du angeben,
wie viel du requestest, also wie viel
du anforderst
und wie viel du maximal benutzen
wirst, also wie viel du am Limit hast.
Und
das Scheduling, also die Zuweisung,
welche
Arbeitslasten auf welchem System,
auf welchem Knoten laufen,
die gehen über das Request.
PyTest. Das heißt,
wenn du sagst, meine Anwendung verbraucht
500 MB Hauptspeicher
und maximal
1000, dann kannst du auf einen Rechner gesetzt
werden, auf einen Knoten gesetzt werden, wo 500
MB frei sind.
Weil dann ist deine Anforderung erfüllt. Du hast gesagt,
ich brauche 500 MB Hauptspeicher.
Wenn du drüber gehst, dann
kann es halt sein, dass es nicht geht.
Du kannst nicht mehr Speicher reservieren oder es
kann sein, dass du abgeschossen wirst,
weil jemand anderes auch gerade
500 MB angefordert
hat und du halt aber mehr als deine
500 MB verbraucht hast, weil du zwischen Request
und Limit bist.
Die pragmatische Lösung, die sich bei uns
in diesem Projekt ergeben hat, ist, dass du
Request gleich Limit setzt. Das heißt,
du forderst einfach so viel an, wie du denkst,
dass du maximal brauchst und
Spitzen darfst du dann halt nicht haben.
Beziehungsweise Spitzen hast du dadurch abgedeckt, dass
das... Das kenne ich auch, aber das Problem
ist halt...
Und ist auch
nicht schlau. Eigentlich willst du ja, dass sich diese
Wellen so ergänzen.
Und wenn ich jetzt einfach auf dem normalen Rechner
sozusagen deploye und ich habe jetzt halt irgendwie
sagen wir mal 10 Projekte, die alle unterschiedliche
Last haben und so und ansonsten brauchen die halt
mal so einen Gigabyte Hauptspeicher oder
zwei für irgendwas
weil sie halt irgendwie zum Beispiel
ein Fall, an den ich mich gut erinnere, wo das halt
echt Kopfschmerzen breitet hat
manchmal startest du
und du kannst es auch nicht, hast es nicht unter Kontrolle
Bei Python hast du es halt oft unter Kontrolle
da kann man schon irgendwas machen
aber zum Beispiel für manche Sachen
wenn man dann so ein externes Binary startet
wie zum Beispiel FFmpeg
FFmpeg, du kannst nicht
Der isst einfach alles aus
Naja, also es kann auf jeden Fall passieren
Du hast halt, also normalerweise passiert
nichts, aber du hast halt FFmpeg mit
irgendwie so, weiß ich nicht
200 Zeichen irgendwie komischen Optionen
hintendran und meistens passiert gar nichts
In komischen Fällen manchmal braucht das dann halt
2 GB Hauptsprecher
Ja, aber solltest du das dann nicht abschießen in dem Fall?
Nein
Und es ist halt dummerweise sinnvoll
und das braucht es halt wirklich.
Und jetzt kann man natürlich dann irgendwie, keine Ahnung,
MPEG irgendwie sich angucken und schauen, wo ist denn
das Problem. Aber
wie geht man denn mit so einem Fall um?
Wenn ich einfach auf eine normale Maschine
deploye, dann das
gleicht sich alles aus, das ist kein Problem.
Wenn dann mal ein Prozess mit ein bisschen mehr Hauptspeicher
läuft, ist nicht schlimm.
Das dauert auch nicht so lange, dann ist es wieder gut.
Weil Kubernetes hat mir das echt
das macht dann echt Kopfschmerzen.
Es geht so weit, dass dann Leute dann hingehen und neue Maschinen kaufen,
weil man das irgendwie nicht in den Griff kriegt sonst.
und das ist halt schon irgendwie so, wenn ich denke so,
ja, genau, aber dann denke ich mir so, also irgendwie
kann das doch nicht die Lösung sein, oder? Also,
ja, weil man braucht
es ja tatsächlich eigentlich nicht, also
es ist ja nicht so, dass man, also,
ja. Ja, man muss ja eigene
Pods starten mit
FFmpeg drin. Ja, ja, genau, das kann man
natürlich dann auch machen. Du kannst dann halt
irgendwie so dir spezielle,
oder das Problem hast du dann natürlich auch, wenn du
Spezialhardware hast, sowas wie GPUs oder sowas.
Ja, gut, klar, die musst du natürlich. Aber dann
geht auch so ein bisschen der ganze Vorteil irgendwie so ein bisschen
wieder verloren, weil dann musste ich ja doch
wieder um die ganze...
Die Annahme ist halt, dass du
viele
gleichpräige
Arbeitlasten hast,
wo es nur darum geht, die irgendwie
so mehr oder weniger gleichmäßig zu verteilen.
Und dann ist das großartig.
Ja, gut.
Aber das Interessante,
was ich als ich Kubernetes gelernt habe,
war, dass sich da
die Denke so ein bisschen verändert. Genauso wie
wenn man SQL lernt. Beim SQL lernen, wenn du
anfängst SQL zu lernen, dann ist die
Frage oft so, wie sorge ich
denn dafür, dass er das aus der Tabelle holt?
Ja. Und die Antwort ist
gar nicht. Du sorgst da gar nicht dafür, sondern
du sagst nur, ich brauche was aus der Tabelle
und dann sorgt er schon selber dafür,
dass es aus der Tabelle kommt. Ja.
Und so Situationen
gibt es bei Kubernetes
auch ganz viele, weil du eben zu diesem deklarativen
Modell hingehst. Zum Beispiel
eine der schönsten ersten Lernerfahrungen war,
wie sorge ich denn dafür, dass diese
Maschine neu gestartet wird?
und die Antwort ist gar nicht.
Du löscht die einfach.
Du machst einfach die, die jetzt gerade existiert,
weg und Kubernetes bemerkt,
oh Moment, da fehlt ja eine und startet eine neue.
Und
das ist am Anfang
manchmal etwas unintuitiv,
auf diese Operationen zu kommen,
wenn du irgendwas erreichen möchtest,
wie du das deklarativ machst.
Diese Maschine soll jetzt bitte entfernt werden.
Ja.
Das sind auch so ein paar Probleme.
also
was das halt auch kann, ist irgendwie so Rolling Release
dann halt irgendwie, das hat mehrere Versionen
von einer Software, die dann live ist, weil die halt
eine wundervolle Sache oder Blue-Green-Apple
ja genau, also das ist keinerlei
Verzug mehr zwischen neuer Version
also gefühlt und 10%
laufen noch auf der alten Version oder schon auf der neuen
und dann falten die, wenn die Prozesse
irgendwie fertig sind, alte Maschinen ab und
neue halt irgendwie rein
aber das ist auch ein bisschen
Ja, aber ist doch eine großartige
Sache. Es gab einen super
Artikel zu Blue-Green-Deployments mit Django.
Da hast du halt...
Genau.
Wird in den
Shownotes erscheinen.
Wo du halt ganz arg darauf achten musst, dass du
deine Datenbank-Migration so machst,
dass du quasi bei jedem Übergang
beide Versionen betreiben kannst.
Das ist ja genau das Problem. Was machst du in Migration?
In Django?
Und dann fällt die Tabelle auf einmal neu?
Es steht dir ja frei, das anzuhalten
und dann die Migration zu machen und dann
neu zu starten. Das darfst du ja machen.
Neu ist ja kein Problem
Problem ist halt eher, wenn
eins wegfällt oder so
Aber wie gesagt, dieser Mechanismus kannst du ja immer noch machen
Du kannst ja alle anhalten und
Mutation machen und alle neu starten
Das ist ja kein Ding
Nur, was du jetzt auch noch machen kannst
ist eben diese, ja zum Beispiel ein Rolling Release
oder ein Blue-Green Deployment
Rolling Release
Ich glaube, wir müssen das erklären, ich wusste diese Worte auch nicht
Rolling Release heißt
dass wenn du zum Beispiel
5 VMs in einer bestimmten Version
laufen hast, dass du das Kubernetes-System
anweisen kannst, ich möchte jetzt auf
eine andere Version, auf eine höhere Version
und zwar Rolling.
Das heißt, er wird die
VMs nach und nach abschalten,
nach und nach die neuen zu verändern.
Das heißt, eine stoppen, dann eine neue
hochfahren. Und erst wenn die neue hochgefahren ist,
wird die nächste alte gestoppt.
Das heißt, du hast keine Situation,
wo du keine
Erreichbarkeit hast.
Ja genau, aber das ist so ein Problem.
wenn die PostgreSQL da ein Gipf draufkriegt mit einem neuen Feld.
Das muss halt deine Software dann können.
Und das ist nicht immer so einfach.
Ja, also
das kannst du auch mit Ensemble machen.
Dieses Problem hast du natürlich sowieso.
Mit Ensemble ist es natürlich schwierig,
weil es ist schon eine komplizierte Operation.
Ja, aber gut,
ich weiß nicht, ob man das halt so einfach automatisieren kann,
weil es gibt halt sehr unterschiedliche
Arten von, also es gibt halt die Dinge, wo man halt
ein Rolling Update machen kann, wo das halt
gar kein Problem ist, wo man sozusagen
nur irgendwie die alten rausnimmt
und die neuen im Loadbalancer mit hinzufügt.
Aber dann gibt es halt auch Dinge, wo das halt nicht geht,
sondern wo du alle auf einmal umschalten musst.
Weil das sonst
deine Datenbank kaputt macht zum Beispiel.
Ja, oder du musst halt
zu deiner alten Datenbank eine neue Datenbank
gleichzeitig hochfahren und dann erst
die neuen Daten halt einmal spiegeln,
dann rüberfahren und dann irgendwie aufsammeln,
das, was in der Zwischenzeit noch in die alten Datenbank geschrieben wird
und dann auch so eine Liste machen,
die du dann in die neuen Datenbank migrierst
und dann das aber dann rollen.
Das heißt, während du migrierst immer länger,
bis du dann irgendwann abschalten kannst, dann kannst du nur noch die Neuen
das danach fliegen und dann hast du vielleicht nicht mehr ganz
klar Daten, weil welche kamen jetzt zuerst.
Also es eignet sich sicherlich nicht
für jede Situation, sagen wir es mal so.
Aber wenn du zum Beispiel irgendwo nur
Konfigurationsänderungen machst oder nur
keine Ahnung, irgendwelche harmlosen
Features live schaltest, dann ist das schon irgendwie
schön, weil du dann halt Zero Downtime hast.
Ja, aber das hast du doch sonst auch.
Wenn ich bei mir
irgendwie ein neues Deployment
und PyTest zu Downtiming Ich habe eine Sekunde Downtime in der Mitte Du machst den einen alten System dann f du das neue System hoch und dann zeigst du aber den Loadbalancer einfach
aufs neue System. Das ist Blue-Green-Deployment, was ihr da
beschreibt. Das heißt, du hast ein System
im Background laufen, was Blue ist,
also was den Status Blue hat
und sagst dem Loadbalancer, bitte allen
Traffic auf Blue und dann startest du ein System,
ein komplettes, was Green hat als Status
und wenn das fertig da ist, sagst du dem
Loadbalancer, jetzt umschalten auf Green.
Diese Technik, die ihr beschreibt, heißt Blue-Green-Deployment
Also ich weiß es gar nicht ganz
Die ist relativ leicht mit Kubernetes umzusetzen
Die eigentliche
Frage, die sich für mich stellt, ist
Braucht man überhaupt Zero-Downtime-Deployments?
Ja, das ist auch so eine Frage
Die machen ja ungeheuer viel Arbeit und die machen
ungeheuer viele Probleme, also dieser
Django-Artikel über Blue-Green-Deployments
ist wunderbar zu lesen und ist auch
sehr schön, aber es sind halt einfach
acht Arbeitsschritte mehr, als wenn du sagst
Okay, wir halten kurz an, dann sind wir für eine Minute
down, dann machen wir die Migrationen
und dann starten wir es einfach wieder.
Das gibt da noch ganz viele schöne Reihen.
Wenn du sowas nämlich in so einer CICD-Chain drin hast,
wo man, um zu testen, ob das überhaupt funktioniert,
noch einen Staging-Prozess zwischendurch hat,
der dann aber sowas macht, wie erstmal
die alte Version auschecken und dann darauf
ein Update fahren, damit halt klar ist,
dass das Update geht und er nicht direkt neue Sachen
baut, dann kann ja sein, dass
neue Versionen bauen anders ist, als auf ein altes
System Update setzen. Und dann musst du halt erst alte
bauen und dann das neue. Und wenn man dann sowas macht,
wie neue Environments oder Sequels dazu
und die es beim Anfang noch nicht gibt,
beim Ende dann schon, dann muss halt quasi,
oder halt welche Entfernteil, größeres Problem,
dann sind die halt auf einmal weg beim
das sind ein paar Sachen, die so problematisch sind, weil
dann musst du zwei Releases machen, um so
Sachen rauszukriegen zum Beispiel.
Ja, das ist diese Krankheit. Google macht das,
also machen wir das auch.
Also die allermeisten
Projekte und Teams und Unternehmen
können doch eine Minute
Downtime hinnehmen. Das ist doch egal.
Ja, aber wenn du Service-Level-
Agreements hast, wo
5.9, das hat so 99,999%
Das sind ja alle haben.
Das sind ja nur 9.5.
Das ist mein Service Level Agreement.
Ich karatiere mindestens 55,555% Abteil.
Hauptsache viele fahren.
Hauptsache viele sind auf dem T-Shirt.
Ne, das ist eben die Sache.
Das ist diese Krankheit.
Man kann das machen,
aber muss man das machen.
Und klar, vom Engineering her
ist das schon cool.
hast du eine Woche Arbeit reingesteckt
um ein Update zu machen
und dafür hast du 100%
Availability, großartig
ja, es gibt Fälle
wo das so ist
ja klar, es gibt Fälle in denen das so ist
aber ich meine, wie viele
Engineering Stunden
sind eine Minute Downtime wert
oder zwei Minuten oder fünf Minuten oder zehn Minuten
ja
das ist eine Frage
die man sich stellen muss und bloß weil man das kann
und weil die Techniker das machen wollen,
ich zähle mich da ja auch dazu,
ich möchte auch gerne so ein cooles Deployment-System bauen,
wo du Zero-Downtime hast und 100%
Uptime und dann geht es aber leider doch nicht,
weil du irgendwo Websocket verbindest.
Ich hatte ja auch mit dem operativen Teil von
so größeren Systemen schon irgendwie intensiveren
Kontakt irgendwie vor langer
Zeit. Damals.
Damals. Als wir noch jung waren.
Aber sozusagen
mein Bauchgefühl aus der Zeit würde
sagen, es gibt so viele
unterschiedliche Arten von Dingen, die man tun muss,
Das kann man unmöglich irgendwie abstrahieren.
Und das ist halt von der Hardware auch abhängig, die da drunter liegt.
Das ist halt, dass man das weg abstrahieren kann.
Aber Jochen, Google macht das doch auch.
Wenn du ein Managed Kubernetes Cluster kaufst, dann kannst du einfach zwei Pods hochschreiben
und da kannst du so einen Schieberegler in deinem Webinterface einstellen.
Der sagt dann sieben Pods von 8 bis 10 Uhr.
Oder Load Balance auch, wenn die CPU-Auslastung über 50% steigt.
Dann skalierst du hoch.
Okay, es kann sein, dass man das heutzutage alles nicht mehr braucht.
und PyTest.
und das ist ein Testframework für Python
über so ein Fake-Interface
raus und das landet dann halt alles irgendwie,
das kann halt dann deutlich dicker sein, das ist dann kein Problem.
Und sowas geht dann ja also schon nicht mehr.
Das kannst du gar nicht mehr machen, weil du musst ja dann alle gleich behandeln können.
Und der Loadbalancing geht ja auch nur so,
es kann ja nicht so sein, dass beim Loadbalancing, oder ich denke mal,
so in Kubernetes kann es ja nicht sein, dass die Pakete über den einen Weg rein
und auch über den anderen Weg rausgehen oder sowas, was man ja an der Stelle gerne halt...
in Westen. Das wirst du ja vielleicht über
Netzwerk-Policies schon irgendwie hinkriegen.
Ich weiß es nicht, aber mir scheint das so, als ob
das irgendwie da implizit
mit drin wäre, dass das irgendwie alles schon egal
ist, wenn das über das Netzwerk geht und das ist kein Problem.
Ja, Netzwerk hast du ja immer genug.
Ja, genau. Das glaube ich nicht.
Also, dass das keinen
Unterschied macht.
Ja, also, okay. Ich weiß es nicht.
Aber ich habe so den Verdacht, dass das dann doch
vielleicht irgendwann liegt.
Ja, aber...
Eine sehr schöne Sache ist halt,
und PyTest.
Klar, bezahle ich da zu viel.
Das ist bei Amazon immer so, ja.
Ja, ja, aber gut, okay, verstehe ich auch, dass das Sinn machen kann.
Aber es macht mir einfach eine Sache weg.
Wenn mein Business halt viel Geld umsetzt und ich dafür gar nicht so viel IT brauche
und ich damit keine Schmerzen haben möchte und sage, okay.
Ja, oder auch eine Trennung.
Du hast eine Trennung.
Du kannst eine Trennung machen zwischen den Leuten, die die Computer betreiben,
die sich um so unangenehme Sachen wie Strom und Wärme kümmern müssen
und wer da dran darf.
und du hast die Entwickler,
die eigentlich das als abstrakte
Computergrößen sehen und wie viele
Milli-CPUs du da brauchst.
Das ist schon
für, aber wieder
für ein Unternehmen einer
gewissen Größe.
Und ich möchte nicht zu Hause auf meinem
Raspberry Pi oder auf meinen Raspberry
Pis einen Kubernetes-Cluster betreiben müssen,
bloß weil ich da ein Power-VM starten möchte.
Das mache ich halt händisch.
Oder mit irgendwelchen Tools, die dann
dafür geeignet sind.
und das ist eigentlich so, das
finde ich so das Problem an
diesen ganzen Enterprise
Sachen. Lohnt sich
das überhaupt für
diese Situation?
Und es gibt viele Situationen, in denen
Kubernetes eingesetzt wird, in denen es sich einfach nicht lohnt,
weil die Last
nicht groß genug ist, weil die
Inhomogenität nicht groß genug ist.
Wenn du tausend identische Maschinen starten
möchtest, gibt es einfache Wege.
Wenn du
50 Maschinen starten möchtest,
gibt es einfachere Wege.
Du musst kurz so einen kleinen Elevator machen.
Warum? Was?
Es gibt ja ganz viele Workloads, die sehr
computer-heavy sind. Ich war mal in so einem
Projekt in Norwegen, wo wir einfach eine
Berechnung durchführen mussten
und wir hatten nicht viel Zeit und wir
hatten aber terabyteweise Daten.
Eine Möglichkeit, die du hast, ist halt
das zu verteilen.
Du sagst, okay, wir nehmen halt mehr Computer,
weil du mehr CPUs brauchst.
und diese Arbeitslast oder diese Dinge, die wir berechnet haben, die waren auf jedem Computer gleich.
Das heißt, das ist dann sehr einfach in Ansible zu gehen oder in Salt oder in Terraform oder in sonst was
und halt nicht nur eine Hostadresse zu hinterlegen, sondern 100.
Und dann auf diesen 100 Hosts oder 1000 IP-Adressen zu hinterlegen und zu sagen,
starte bitte auf allen diesen Rechnern, diesem Inventory diese Workload.
und da brauche ich keinen Kubernetes dafür.
Ja, aber du musst ja trotzdem irgendwie das
I-O-Commando, wo kommt das alles her?
Ja, gut, klar, das musst du dann immer noch merken, aber
das ist dann bei allen gleich.
Und das ist das, worauf ich raus möchte.
Wenn du tausend identische Dinge hast,
dann reicht ein Ansible.
Und das ist auch nicht mal
kompliziert, weil die alle gleich konfiguriert sind.
Kubernetes hat
einen bestimmten Anwendungsfall und der ist,
du hast viele verschiedene
Workloads, die aber alle
Compute ähnlich sind
auf vielen verschiedenen
Maschinen, die aber
Compute ähnlich sind. Das muss man nochmal genau
erklären. Also vielleicht so ein reales
Beispiel. Und am besten,
also auch das würde ich denken, geht eigentlich
noch sehr gut, es sei denn, du hast jetzt noch
die Software
läuft auf sehr unterschiedlichen
Betriebssystemen, in sehr unterschiedlichen
Alterungsverordnung
Verwesungsstufen
auf verschiedenen Teams, weil dann
so, dass du halt nicht sagen kannst,
und ich deploye das jetzt auf eine homogene
Geschichte, wo man sagen muss, das geht nur mit
Docker, das geht nicht anders, weil das halt einfach zu
unterschiedlich ist.
Das machen Entwickler sowieso, Jochen.
Das machen ja nach Docker, nur du willst das.
Na gut. Ja, aber dann verstehe ich das.
Also wenn man sagt, okay, ich mache hier auf der einen Seite
irgendwie, keine Ahnung, ein Headless
Qt in einer sehr alten Version,
weil ich das für irgendwas sehr Spezielles brauche
und hier habe ich jetzt irgendwie, keine Ahnung,
ein aktuelles
NixOS und da habe ich hier ein Debian und das muss ich aber
alles gleich auf dem gleichen Klasse.
Java 17 und 18 und 21 und 8 und 2
Ja und für alte Sachen
sind alle Programmierer schon gestorben,
das muss ich aber weiter betreiben.
Deine Kobo Docker VM
Ja, okay, okay, dann
eine AS400 Docker VM
Ja, also das
Also nochmal, anwenden Sie bitte noch einmal,
du wolltest das nochmal erläutern, also was denn da
Also wir haben jetzt verschiedene Sachen, die
ganz heterogen sind
Okay, aber
Also zum Beispiel Google, ja? Google betreibt
35.000 verschiedene Services
auf ihren 8 Millionen Computern
oder was weiß ich.
Und dann ist das großartig, weil dann kannst du einfach sagen,
okay, es gibt jetzt eine Mannschaft,
eine große Mannschaft, die sorgt dafür, dass diese
Computer laufen und ans Netzwerk angeschlossen
sind und dass die in den
Kubernetes-Cluster eingeordnet sind
und das ist deren Spezialität
und auf der anderen Seite hast du eine Mannschaft von Softwareentwicklern,
die halt auf diesem
einen großen Kubernetes-Computer
Workloads starten dürfen, also die
VRM starten dürfen. Und zwar egal, welche
sie wollen. Und klar, wenn
du 5000 verschiedenen Teams
hast, die eben diese 5000
verschiedenen Sachen starten, dann
ist das großartig. Dann willst du nicht mehr jedem einzelnen
Entwickler sagen müssen, okay, du kriegst jetzt
die VM und du kriegst die VM und du kriegst die VM.
Sondern du willst aber sagen,
wir machen einfach einen großen
Computer-Mischmasch
und einen großen Kubernetes-Cluster und
hier ist dein Quota und innerhalb des Quotas darfst du
machen, was du willst. Bist du verantwortlich.
Das heißt, du hast einfach diese Trennung zwischen
den Computern, die das betreiben und der
Software, die da laufen soll.
Und wo die dann läuft, das kannst du meistens
gar nicht sagen. Du kannst meistens gar nicht sagen,
ich habe jetzt
hier einen Pod, also eine
Docker-VM, die hier laufen
soll. Du kannst vielleicht sagen, die soll in einer bestimmten Zone
laufen oder in einem bestimmten Cluster oder in einem
bestimmten Datacenter, aber manchmal nicht
mehr das. Wenn du einen Kubernetes-
Cluster hast, der über viele Datacenter verteilt
ist,
Dann kannst du höchstens noch sagen, du willst, dass die möglichst weit voneinander entfernt sind, dann willst du, dass sie möglichst nah aneinander dran sind, aber wo die dann laufen
Ich hätte gern mehr Netzwerk-Latenz, das ist doch immer gut
Größere Zahlen, mehr Netzwerk-Latenz hinter meinen Microservices, das muss doch Spaß machen
Ganz ehrlich, für mich als Anwendungsentwickler ist es auch völlig egal, wo das läuft
solange das halt läuft
Jaja, na
also ich weiß nicht
ich hab halt doch so
von Erfahrung her würde ich
also ich, es gibt halt
es gibt halt Infrastruktur, die gut
funktioniert, aber es gibt halt Infrastruktur
die nicht gut funktioniert und das hat
meine Erfahrung hat weniger
damit zu tun, ob man jetzt Kubernetes verwendet
oder keine Ahnung, irgendwas anderes
sondern eher damit
welche Leute die betreiben
ich sag zum Beispiel
Oh Gott, das hört sich so an wie, ne, so
Ihr seid alle blöd und ihr könnt es nicht
Ja, aber also mit dem Alter, also das ist halt auch sowas, vielleicht werde ich auch einfach alt, das kann auch sein, aber früher
Oh, du willst wissen, wo deine Programme laufen
Ja, na, nee, ja, ja
Also früher hätte ich gedacht, also Prozesse, ne, beim Softwareentwickeln Prozesse ganz wichtig und das total, wenn man das richtig macht, dann ist das voll gut
Und wenn man es falsch macht, dann ist alles eine Katastrophe
und irgendwie Engineering
total super, wenn
man halt nur die richtigen Tools verwendet und
dann geht
alles super und wenn man halt das Falsche macht
und heute denke ich mir eher so,
ja gut, die Sachen, die ich gesehen habe, die
wirklich gut funktioniert haben, teilweise war das
Engineering sehr grottig.
Möglicherweise auch deswegen, also einfach
von der Zeit her geschuldet, weil man hatte nichts
Besseres.
Wir hatten ja damals nichts anderes.
Ich kann mich da nicht mehr erinnern,
vielleicht besser nicht bei mir, aber
Da lief die ganze Operations-Geschichte
halt über Shell-Skripte, die von einem
gemeinsam gemounteten NFS-Ding
halt liefen und so. Wo man sich sagt,
oh mein Gott, das ist ja alles total schrecklich.
Aber das war es nicht. Es war ziemlich cool.
Das hat richtig gut funktioniert alles.
Auch mit richtig vielen...
Du hast eigentlich selber ein Proto-Kubernetes gebaut.
Nein, das war kein Kubernetes.
Die Shell-Skripte waren auch teilweise ein bisschen...
Aber das hat richtig gut funktioniert.
Und ich habe auch schon Kubernetes gesehen.
Auch ein großes Unternehmen
mit groß viel... und das war
scheußlich, weil
ja, man hatte... also
dieses Versprechen wurde nicht eingelöst,
dass halt man sich nicht mehr drum kümmern muss, sondern
ein Großteil des...
ein größerer Anteil
der Zeit, als ich mir oft hätte,
muss ich mich damit
verbringen, warum der Kram denn jetzt nicht so
funktioniert, wie ich mir das denke und was denn da jetzt das
Problem ist und warum ich das nicht sehen kann,
was da das Problem ist, weil ich nicht darf.
Da musst du schon ranchern oder so. Ja, genau, weil du es nicht darfst.
weil du es nicht sollst und deshalb darfst du es auch nicht.
Ja, und dann versuchen wir mit den Leuten zu reden, die verantwortlich sind
und dann denkt man sich so...
Und Performance und Latenz sind auch so Sachen, wo du halt
einfach plötzlich viel weniger
Einblick rein hast.
Genau, man sieht einfach viel weniger, was ja
kann ja ein Feature sein, aber...
Ja, klar, in vielen großen Organisationen
ist es ja ein Feature. Du willst die Leute nicht zu nah
an die gefährlichen Dinge
ranlassen. Also lieber schlecht betrieben als
gar nicht betrieben.
Ja, aber...
Also, es wäre einfach so,
es ist halt, wenn das Leute sind,
die das betreiben, die das halt irgendwie,
denen das Spaß macht, die da Interesse dran haben,
die das irgendwie auch versuchen zu optimieren,
die sich da reinfuchsen oder so,
dann kann es sein, dass man auch, dass die halt auch,
keine Ahnung, mit einem Stock und einem
Feuerstein irgendwie
den Raum warm kriegen, ja,
während halt irgendwie,
keine Ahnung,
es gibt halt Leute, die nehmen halt
den Schaufelradbagger und baggern
halt das falsche Dorf weg, ja,
Das ist halt irgendwie so, das muss nicht unbedingt
besser sein, wenn man ein besseres Tool hat, wenn man halt
die falschen Leute steuern.
Ja, das ist aber so ein bisschen
eine Tautologie, oder Jochen?
Die guten Leute kriegen Dinge gut hin
und die schlechten Leute kriegen
Dinge schlecht hin.
Aus so einer 10.000 Fuß
Übersichtsperspektive
sieht das halt zu einfach aus. Das sieht halt so aus,
wie wir machen das, was alle machen
und das funktioniert dann schon.
Wir haben auch viel Geld ausgegeben jetzt.
Dann muss das auch gut sein.
Ja, aber vielleicht funktioniert es auch nicht
und zwar aus anderen Gründen, als man jetzt sagte
Also
Also ich muss sagen, aus Anwendungsentwicklersicht
ich finde es sehr angenehm, weil ich einfach nur noch sagen muss
hier ist ein Docker-Image, sorgt dafür, dass es läuft
Ja
Der Rest ist mir egal
Der Rest ist mir egal, ja
Für Performance ist
Irgendjemand anders ist dafür verantwortlich
Ja, aber was passiert denn, wenn das nicht, also funktioniert das dann tatsächlich auch
Also ich meine, dann wäre das ja wahrscheinlich ein Fall für
das betreiben dann halt auch Leute, die sich da irgendwie
Ja, Amazon, AWS
Ja, aber
okay, die können das wahrscheinlich sogar
Azure, ja, ist genauso
Ja, da habe ich das schon häufiger gehört
Kriegt man bei Google Compute oder bei Google Cloud
kriegt man da auch Kubernetes Plastomin
Ja, ja
Wäre ich mir jetzt aber nicht so sicher, ob die gut sind
Weiß ich auch nicht, also bei Azure
habe ich auch schon gehört, da waren Leute auch nicht so
etwas unter
Ja gut, dann wäre es halt bei dem großen
A-Zeit halt auch den Premiumpreis
Ja, das ist schon alles
nicht günstig, aber es ist halt die Frage,
wenn man das eh bezahlen kann,
egal.
Möchtest du vielleicht noch einen Manager haben, der vielleicht nicht so technisch
affin ist, der dann so ein Load-Binding-Screen
mal kurz in einem Webinterface hochschieben kann,
weil der gerade eine Spitze am Wochenende erwartet oder so?
Ja, das ist aber so ein bisschen der Trend, oder?
Dass du weggehst von den eigenen Data Centers
und hin in die Cloud. Ja, das ist ja das Versprechen der Cloud,
dass jemand anders für dich besser managt.
Ich unterschreibe das nicht
immer so und ich glaube auch nicht, dass das
immer eine gute Idee ist, in die Cloud zu gehen.
Und ich glaube auch nicht, dass das immer billiger ist,
in die Cloud zu gehen. Ganz im Gegenteil.
Ja. Aber
es ist der Trend gerade. Es ist der Trend
weg vom eigenen Datacenter hin zu... Das Hauptproblem ist halt,
wenn du eine Konzernstruktur
hast mit einer sehr heterogenen
Infrastrukturwelt, dann
ermöglicht dir halt dieser Weg in die Cloud
eine Homogenisierung deines ganzen
Geschäfts.
Ja, natürlich für Geld. Und danach kannst du
vielleicht wieder lokal machen.
Aber diese Fortentwicklung
quasi, dass halt diese ganzen heterogenen Teams
alle abgelöst werden müssen, durch
was Neues.
Da verliert man natürlich Know-how, aber du kannst
halt so Prozesse, Skaleffekte erzeugen
irgendwie und dann vielleicht doch merken,
wo du halt was nicht mehr so brauchst.
Ich weiß nicht, also dieses Skaleffekt
der Erfolg klingt ganz falsch.
Ja, das hört sich immer gut an,
das hört sich in so Business-Präsentationen immer gut an.
Wann funktioniert das wirklich?
Da habe ich so meine...
Naja, aber ich will auch schon, also du
kriegst halt die Leute dazu,
dass sie dann das alles Gleiche machen müssen.
Du fährst halt dann vier Hunden runter,
und PyTest.
ganz... Ja, aber du hast
diese Syshalter tatsächlich aufgebrochen und du brauchst
dann tatsächlich, musst du halt
wieder von vorne anfangen.
Du kannst das wieder neu bauen.
Ja, es kommt wahrscheinlich darauf an, aber
ich würde auch, ich würde immer dazu sagen,
also klar, okay, das mag sein, dass das alles super ist
und es kann sein, dass das, wenn man das an AWS
oder sonst wen gibt, dass es dann besser ist als das, was
vorher da war und dass man diese...
Kann alles sein.
Vielleicht ist das dann auch super
viel besser als vorher. Und wenn du so Spitzen
hast, kann es ja auch sein, dass das, dass du da
mehr machen kannst, als du vorher machen kannst.
Weil der hat einfach ungeheuer viel
Kapazität jetzt kurz.
Aber ich würde immer mit dazu
sagen wollen, dass es halt auch so Dinge gibt,
wie eben
zum Beispiel, die das halt in einem halben Rack
machen. Und
einer der Gründe, warum sie das können, ist halt,
dass da jemand irgendwie ein
totaler Switch-Nerd ist und sich halt mit dem
Netzwerk-Kram auskennt.
Und dieses System
kannst du in keine Cloud deployen.
Weil die hat halt die Hardware nicht.
und die haben auch nicht die Kenntnisse über das, was man da...
Die können das nicht, willst du damit sagen, die können das nicht?
Ja, bei bestimmten Sachen, die man da so den Spann mitnimmt,
wenn die irgendwie so ein Redis irgendwie im Minister hängen,
dann müssen die manuell hingehen, dann musst du eine halbe Stunde warten,
weil irgendjemand da runterrennt und das Rack reinschiebt oder so, ja.
Ja, das ist dann vielleicht noch viel schlechter.
Ja, man muss da planen vorher.
Ich glaube auch, Stack Overflow ist inzwischen tatsächlich
irgendwie irgendwo hin in irgendeine Cloud umgezogen.
Insofern kann ich das auch vielleicht nicht mehr als Beispiel...
Nicht mehr das beste Beispiel.
Aber sagen wir so, für viele, die halt
unterhalb der Google-Größe
sind oder, weiß ich nicht, konzernpolitische
Probleme haben, könnte
sein, dass manchmal vielleicht der eine oder andere
schon mal sowas gesehen hat.
Was mich ja auch noch interessiert, ich meine, hey, dann haben wir jetzt so ein
Managed-Criminalist-Cluster irgendwie gemäß, aber wie kriege ich denn
vom Entwickler den Pod da hin?
Ja, da gibt es
verschiedene Möglichkeiten. Ah ja, Moment,
aber jetzt sind wir ja irgendwie wieder bei so einem anderen Thema,
das müssen wir irgendwie so eine Kette haben, so eine CI,
die das dann baut oder das dahin deployed
oder auf dem Branch.
oder? Ja, es gibt ja verschiedene Möglichkeiten. Also ich meine, du kannst es natürlich
prinzipiell manuell machen. Yay!
Großartig.
Auch genau der Verwendungszweck.
Ja, genau.
Einmal bitte hier diesen Pott bitte neu.
Oder du hast ein CI-System,
was das dann halt irgendwie pusht.
Du hast ein Jenkins-System oder du hast ein was weiß ich System.
Wo kriegt man dieses CI-System her?
Das kannst du auch mieten.
Achso.
Automatisch? Du betreibst es auf deinem
Kubernetes-Cluster. Aha.
Also so ein Drone. Habe ich tatsächlich gesehen.
Also ich meine,
dass du Jenkins auf einem
Kubernetes-Cluster startest.
Oder Drone-CI oder sowas?
Ja, oder irgendein CI.
Ja, da gibt es ja 2000.
Also das ist dann,
nochmal, ein CI ist noch wie
so ein anderer Server, auf dem eigentlich nichts anderes passiert,
also irgendwie sind so Diplom-Skript-Ablaufen, oder?
Ja, das kommt drauf an. Also ich meine, kann man
auf verschiedene Arten und Weisen verwenden.
Das Erste, was du machst, ist ja Continuous Integration.
Das heißt, da hast du auf jeden Fall
deine Tests laufen und deine
Dein Testing und dann
musst du eigentlich noch...
Also die Integration heißt ja nur, dass du
immer eine getestete
Version hast.
Der nächste Schritt ist dann Continuous Deployment.
Delivery, oder?
Delivery oder Deployment? Irgendwas mit D halt.
CD,
die ICD.
Dass du eben diese Continuous Delivery oder Deployment
machst, wo du halt
sagst, gut, jedes Mal, wenn eine fertig gebaut ist
und korrekt getestet, dann kannst du ja auch gleich ausrollen.
Aber der sagt dann genau, korrekt getestet
sind das nur die automatischen Tests, die durchlaufen müssen
oder muss noch irgendwie mal das abnehmen
oder so
Aber muss noch jemand auf den grünen Knopf drücken
oder nicht, oder muss jemand abnehmen
Da muss halt so verschiedene Systeme dann gebaut werden
Das musst du dann irgendwie wieder übernehmen
und das muss halt dann eigentlich
wie das halt gestartet wird, also ich würde sagen, ideal wäre es
du hast einen Production Branch irgendwie und du pushst dann irgendwie
und dann gibt es eine Action auf deinem GitHub
die dann das Ding anspricht
Das ist viel zu spezifisch
für deine Umgebung.
Da kann ich mir
viele verschiedene Umgebungen vorstellen,
wo das sowas nicht geht.
Oder wo du es auch nicht machen darfst.
Oder wo du es auch nicht machen kannst.
Und wie machen wir das denn dann?
Mit anderen Prozessen.
Jochen hat doch vorhin geschrieben,
dass du Prozesse haben musst.
Ja, aber das ist ja genau der Punkt.
Da musst du dich irgendwie darum kümmern.
Da musst du ja das machen.
Dann ist er aber doch wieder jemand,
der sich damit auskennen muss,
wie das ganze Zeug funktioniert.
Also, sag mal so,
das kann auch ein Entwicklungsteam machen.
So ist es ja nicht.
Ja, aber du brauchst halt jemanden, der sich damit auskennt.
Auf jeden Fall muss das ein Entwicklungsthema sein.
Wenn das aber jemand sich damit nicht auskennt,
dieser ganze Quatsch irgendwie gar nicht da ist,
dann hast du das Problem.
Ja, also wie gesagt,
alleine möchte ich das nicht betreiben müssen
und alleine möchte ich es mir auch nicht ausdenken müssen.
Aber als Entwickler in einem großen Konzern
ist das doch bequem,
weil da gibt es ja die Leute schon, die das machen.
Ach, da gibt es die schon?
Ja, klar.
Oh ja, wirklich?
Außer du bist in der Abteilung, die das macht.
und dann ist es besser auch
Irgendwer kann bestimmt DevOps oder so
Nee, das ist ja tatsächlich mehr Ops
Das ist ja nicht DevOps
Das ist ja nur Ops, genau
Du sorgst ja nur dafür, dass der Cluster da ist
und auch funktioniert
Die DevOps-Schicht ist ja
Ja, aber das ist ja
DevOps, oder?
Ja, genau, aber das ist ja in den Anwendungsteams
Aber wenn du jetzt nur noch
Devs hast, die kein Ops können
Ja gut, aber das
muss ja auf der Scale
wo du so einen Cluster einsetzt, musst du davon
ausgehen, dass du dann halt auch das machen musst.
Ja genau, aber das ist genau der Punkt. Ich glaube, dass das
bei vielen so, die denken halt, ey, ich kaufe mir jetzt so
einen Managed-Kibinist-Cluster und dann habe ich mich hier.
Genau, und dann die Arbeit, das passt schon
irgendwie. Und die vergessen diesen
Ja gut, das kann auch
gut und schlecht sein.
Das, was
ich vorhin meinte mit dieser Cost-Center-Mentalität,
dass du halt sagst, okay, früher haben wir
ein Data-Center betrieben und es war so teuer
und heute betreiben wir Cloud
und dann ist das verteilt auf die Teams und
jedes hat seinen Quota und dann muss jedes Team die Kosten
tragen und ist selber verantwortlich.
Und die Kosten sind aber immer noch da, die sind höher.
Nur hast du sie jetzt anders verteilt, sodass du sie
nicht mehr in einer Spalte siehst, sondern halt
im Team auf die Teams oder auf die
Anwendungen oder wie auch immer du es spielst.
Ja, aber dann hast du im Controlling die Aggregationsspalte vergessen.
Ja, genau. Beziehungsweise die ist halt jetzt woanders.
Nicht mehr im Data Center
sondern im Development.
Das ist halt möglicherweise
eine ganz andere
ganz anderer Seite der
Bilanz halt. Ja, aber das ist ja eigentlich
vom Controlling her eher so fail, weil eigentlich müssen ja auch
Projekte, die irgendwie erlöst konnten,
aber ich glaube, dass
solche Fails haben
reale Konsequenzen. Also ob du das jetzt,
also genau, es kann sein, dass auf der
einen Seite, du zahlst
halt irgendwie
einen guten Teil deines Umsatzes
an Amazon oder an Microsoft oder so
und das wird verbucht
als Investition, wo irgendwie
Geld zurückkommt.
Was heißt das?
Sieht ja auch so.
Also vielleicht, ja.
Du könntest dir weniger investieren
und könntest trotzdem genauso viel umsetzen.
Und auf der anderen Seite sieht das so aus wie,
das sind halt bloß Kosten,
die da rausgehen.
Da brauchst du Leute, die da hingehen und ein Gebäude,
das sind sowieso tote Kosten
und dann brauchst du Hardware und was machst du mit der
nach zwei Jahren, wenn du die nicht mehr verkaufen kannst?
Ja, aber das steckt genau so ein Problem.
Du musst halt irgendwie ein Team finden.
Das ist doch der klassische Kauf versus Mieten.
Genau, aber wo findest du genau das interne?
Du bist jetzt mal ein Konzern, du hast jetzt
keine Ahnung.
Wir verkaufen ihr Zeugs und mieten es zurück zu einem teuren Preis.
Du hast jetzt keine Ahnung.
Du machst halt irgendwas anderes.
Und dann brauchst du irgendwas mit Cloud.
Dann hast du überlegt,
wir sind jetzt ein so geballer Konzern.
Das ist ja Buzzword, Cloud,
KI und so.
Und dann dachtest du, ja, okay, dann müssen jetzt aber schon
alle so modern sein und ein bisschen Cloud machen.
Und wenn wir jetzt aber unser eigenes Data Center
irgendwie betreiben, das müssen wir dann irgendwie
Offshore und das funktioniert
aber auch nicht so richtig, weil die guten Leute
irgendwie dann doch irgendwie so, ja,
und dann baust du dann irgendwie so ein Letter Center,
merkst dann irgendwie so, ja, selbst wenn wir jetzt irgendwie in Deutschland
sowas bauen, was ja irgendwie total
gut ist, ist aber schon teuer und
das festigt sich dann da alles
und können jetzt Globalas betreiben und die kennen ja die ganzen
Sachen nicht und wie bieten die das jetzt für Services
in Brasilien an und so und
dann können die ja gar nicht mit denen reden und gar nicht kommunizieren
und warum machen wir jetzt nicht alles in der Cloud?
Das ist ja total einfach, einfaches Interface für alle gleich
und benutzen das dann einfach und
und dann haben wir dieses Controlling-Problem,
dann brauchst du halt diese ganzen Sachen nicht mehr.
Aber tatsächlich, du musst das nicht selber vorhalten die ganze Zeit.
Du brauchst nicht das ganze Team vor Ort an der gleichen Stelle,
das diese ganzen Sachen managt und irgendwelche Schnittstellen nach außen anbietet.
Das ist operativ sicherlich wesentlich einfacher,
von Amazon Services zu mieten, anstatt ein eigenes Datacenter zu betreiben.
Nur ab einer gewissen Größe.
Ich meine, es gibt ja auch Schritte dazwischen.
Es gibt ja auch Co-Location und es gibt ja auch so Mietracks und so weiter.
Aber ab einer gewissen Größe lohnt es sich halt.
und ganz ehrlich, ich sehe
die Vorteile von vielen von diesen Cloud-Diensten
nicht. Die sind sehr teuer und die haben
viele so fiktive Vorteile. Ja, aber du kannst
die hochskalieren so viel wie du willst. Ja, gut.
Okay. Aber ich habe
zwölf Visitor im Monat und ich muss nie
mal etwas hochskalieren. Ich würde es gerne...
Dann machst du Serverless. Noch weiter. Ja, genau.
Dann mache ich Serverless.
Die gleiche
Latenz wie vorher, nur für einen
höheren Preis. Voll gut.
Ja, aber da muss jetzt nicht die ganze Anleitung bezahlt werden.
Nur für die genutzte Minute.
Ja, gut, aber dafür muss ich
auch das Ein- und Ausschalten mitbezahlen und
wenn dann mal 100.000 kommen, dann muss ich auf einmal alles
bezahlen
Ne, das will ich gar nicht
Also, das ist so eine
Ja, da wird ja viel
Buzzword-Bingo gespielt
Ich verstehe zum Beispiel gar nicht, warum Amazon
nicht einfach so eine tolle Strategie fährt
wie zu sagen, hey, wir könnten unseren Umsatz
hochbekommen, wir gucken einfach mal bei allen unseren Kunden
dann stellen wir irgendwelche Server in Russland auf
und machen einfach ganz knapp viele Requests
auf die ganzen Server
per Lambda angeboten sind oder so
und hauen einfach da mal so die Quotas so massiv
hoch, weil wir benutzen das alles einfach mal
und die mal Geld brauchen.
Ja, aber bisher brauchen sie das noch gar nicht.
Voll einfach.
Du kannst einfach dann dadurch so
deinen Umsatz voll hoch.
Das ist ja auch eine gute Idee.
Die Preise erh oder so Voll viele Leute nutzen unsere Sachen und dann merken sie oh da kommt eigentlich ein Umsatz raus oder Es gab von der Weile so einen Artikel ich kann den auch f die Show noch wieder raussuchen dass
Amazon Prime, dieses
Video-Hosting, die sind umgestiegen von
Serverless
auf quasi
reservierte Instanzen.
Weil die halt auch so FFM-Pack-Lasten
haben, ja, und weil die da auch so
Transcoding machen und
das über diese Serverless verteilte
Total cool ist, weil jede
einzelne Komponente des Systems kann
einzeln skalieren, aber brauchst
gar nicht, weil du hast nur eine in der Mitte, die halt
dick Rechenkraft verbraucht und dann
außen so ein bisschen Gewürz außenrum.
Auch da mit den Abstraktionsledern,
die da tolle, du brauchst da gar nicht mehr.
Also die haben irgendwie ihr Budget um 90%
gesenkt und
die Latenzen auch.
Und das finde ich so ein bisschen
gruselig, wenn so die Amazon-internen
Teams sagen, also wir wollen das
nicht benutzen.
dann ist da doch schon was im Argen
aber klar, also ich meine
das ist ja das Problem bei diesen ganzen Technologien
die sind cool und neu und man will die mal ausprobieren
und auch im Unternehmensumfeld ist es ja so
die sind cool und neu und man will die mal ausprobieren
genau wie bei Kubernetes auch
das ist auch cool und neu
und damit kannst du alles das machen, was
Google auch macht
aber brauchst du es wirklich?
Ja, also meistens
wie du sagst, dieses deklarative
hat halt was für sich, man schreibt zwei, drei
Konfigurationsdateien und wenn man sich jetzt ein Minikube
auf dem Server deployt, dann ist auch das relativ einfach.
Da muss man auch dazu sagen, ehrlicherweise
ist es Jammer, was man schreiben muss an Konfigurationsdateien.
Naja, ist das schlimm?
Ich weiß nicht, ich muss halt mal an dieses
Memem-Bild denken,
von dem Typen, der halt irgendwie
vor einem Haufen Soldaten
steht und
die dann sagen,
ja, schieß ihn oder so
und dann so, hey, aber ich kann irgendwie
Kubernetes, oder ich kann
mal mit Computer ein Ding machen
und dann sagen die, ja, kannst du auch
Jammer für Kubernetes schreiben? Und dann so, erschießt mich bitte.
Da gibt es auch dieses Bild mit der
Schlange und der Maus,
wo die Maus sagt, bitte friss mich nicht
und die Schlange sagt, nee, ich will dich gar nicht fressen.
Dann sagt die Maus, okay, was willst du denn stattdessen?
Dann sagt die Schlange, kannst du nicht
Kubernetes-Ingenieur bei uns werden? Dann sagt die Maus, bitte friss mich.
Ja
Ich glaube mit Schlange und Maus, ich glaube, dass das mal ein Python
eine Python-Metapher war
Jason, genau das, wie man es eigentlich jetzt machen sollte?
Nee, auch nicht
Ach, alles
Ist alles nicht so schön
Tommel
Ist auch nicht schön, aber der beste Kandidat
Ihr könnt es vielleicht nochmal erkennen, bitte kurz den Unterschied
zwischen Jamel und Tommel
Jamel ist yet another Marker-Language
und Tommel ist Toms Marker-Language
Also die Probleme bei Jamel
sind halt das, wenn man da nicht vorsichtig ist,
dann bedeutet halt, ja, will Dateiparsen
halt Code ausführen, was
vielleicht für die Leute nicht so gut ist.
Ja, oder auch so Ambiguitäten, ja, das Norwegen-Problem.
Oh, das ist halt ein Norwegen-Problem.
Jetzt musst du noch untertechnen, was das Norwegen-Problem ist.
Tabs versus Spaces.
Das Norway-Problem.
Das No.
Wenn man eine Liste
von Ländern speichern möchte
und dann dazu die ISO-Länder-Codes
verwendet, dann sind das ja zwei
buchstabige Länder-Codes und es geht
bei den allermeisten Ländern sehr gut, außer
bei Norwegen, weil der norwegische
Ländercode ist NO und das
wird von Jammel als FALSE geparst,
weil NO ist ja ein Synonym für FALSE.
Das heißt, du hast dann so eine Liste von Ländern,
Deutschland,
Dänemark, Schweden,
Nein.
Das kann einem auch echt das Deployment kaputt machen,
wenn man das
halt da drin hat.
Ja, oder Tabs vs. Spaces, ja, und generell
so Significant Whitespace, das ist ja
generell abzulehnen,
gerade in der Python-Welt.
Ja, das
ist halt so eine,
das krankt halt an den
gleichen Problemen, die
viele solche Datenbeschreibungssprachen
haben, dass
wenn man genügend Daten da durchschickt oder
wenn genügend Leute damit arbeiten, dann siehst du
alle Ecken und Kanten.
Und wenn die nur so ein
kleines Loch haben, wo sie nicht genügend
spezifiziert sind, dann fallen dir da
gigabyteweise die Daten raus.
und das ist bei allen
Sprachen so, das ist bei Jason so
Jason hat seine Probleme
und auch seine
Ungereimtheiten, es gibt nur Floats
Wir haben nur so vier Dattypen
das ist vielleicht manchmal
einfach, elegant
oder halt auch irgendwie
Ja und auch die Wiederholung, du kannst nicht
wenn du irgendwie eine Million
gleiche Objekte hast, dann die alle
10 Byte benutzen, aber die Keys
die du da halt reinschmeißt, die sind alle
diesen Gigabyte-weise Keys reingeschrieben.
Das Komma,
keine Kommentare,
Trailing-Komma
und
Jason Parsons geht inzwischen
quasi schneller, als du von der Platte
lesen kannst.
Ich lese mal das Blog von
Daniel
Lemire,
ich weiß nicht genau, wie man das ausspricht,
kanadischer
Computer Science.
Ich habe das auch in meinem RSS-Reader drin,
in diesem Blog, aber der schreibt so viel
gute Sachen.
Ja, das muss man auch irgendwie mal lesen.
Der war letztens in irgendeinem
von dem IEEE
Podcast, Software Engineering Radio
oder so, wo er auch drüber geschrieben hat,
äh, geredet hat.
Der hat
Sam D. Jason, glaube ich,
geschrieben.
Und wie man das halt machen kann und was, wo man
aufpassen muss und man kann
Jason parsen quasi beliebig schnell
hinbekommen. Also sie waren
über mehrere Gigabyte pro Sekunde und
Ja gut, aber mehrere Gigabyte pro Sekunde
impliziert ja immer noch, dass du mehrere Gigabyte
hast, die du pausen musst.
Und wenn du dann stattdessen
Protobuff hast und nur 100 Megabyte hast, dann ist
das natürlich weniger. Gut, aber
sei es drum.
Die eigentliche Aussage ist ja, jede von diesen
Beschreibungssprachen hat Vor- und Nachteile
und jede hat ihre Krankheiten. Und Tommel
ist da nichts anderes. Tommel ist halt eine
relativ simple
Sprache, so ein bisschen an
INI angelehnt, damit man auch das schön
im Texteditor haben können, damit du auch
schön so auf quasi Dateiebene
das machen kannst. Aber Jochen, würdest du
tatsächlich irgendwo eine Schnittstelle machen, die Tommel verwendet?
Also würdest du Tommel
irgendwo schreiben?
Ich habe
das Gefühl, dass Tommel sowas ist, so eine
Konfigurationssprache. Die wird manuell geschrieben
und maschinell ausgelesen.
Ich weiß nicht, ob ich auf die Idee käme,
Tommel maschinell zu schreiben.
Nee, wahrscheinlich nicht.
Messagespeck oder sowas mit Python und dann
eine genaue...
Für automatische Sachen würde ich eher tatsächlich
sowas wie JSON nehmen.
Aber für Menschen ist JSON
halt nicht so toll.
Weil es die Default-Wahl ist.
Und wenn es für Menschen nicht so toll ist, dann kannst du auch
XML nehmen.
Auf Dominik.
Nein, Photobuff oder Messageback.
Das würde ich gerne noch,
wir sind jetzt auch schon ein bisschen dran, aber
das würde ich gerne noch, das habe ich
versucht zu sagen und habe es so irgendwie 20 Minuten
lang nicht hingekriegt.
und das hat mich irgendwie dann noch verfolgt.
Also XML,
warum das halt,
also alle jammern immer drüber,
aber warum das halt unter Umständen
eine schlechte Idee ist oder was überhaupt,
das ist auch wieder ein schönes Beispiel für, das hatten wir ja auch schon
ein paar Mal, warum Abstraktion
ist immer so Fluch und Segen, das ist immer so schwierig
und XML hat halt auch so fiese
Probleme, warum jammern da Leute immer so
und ich hab dann irgendwie gesagt
so, ja, CSV
gefällt mir viel besser als XML,
weil ich war ja lange in diesem Datenexport-Import-Geschäft tätig und nach viel Schmerzen wurde jedem, der halt irgendwie an diesem Datenaustauschpunkt teilnehmen wollte, geraten von den Kundenberatern halt immer so, nimm CSV, nimm nicht XML.
Wir können XML, klar.
Du kannst uns auch XML geben, das geht.
Mach es nicht. Nimm CSV.
Und
ich dachte auch nur so, ich würde immer CSV
vorziehen und
gegenüber XML.
Wieso das denn?
CSV ist ja noch viel schrecklicher, da ist ja gar nichts
definiert und so.
Wenn auf Python Readability Counts?
Nee, das ist gar nicht so der Punkt.
Sondern der Punkt ist eher dieses
Abstraktionsding aus meiner Perspektive.
Es gibt möglicherweise auch Anwendungen,
Es gibt auch Anwendungen, nicht möglicherweise ganz sicher,
wo XML viel besser ist und wo
CSV schrecklich ist, aber
Jochen, du verkaufst gerade alle Zuhörer.
Das ist ganz schlimm, dir zuzuhören.
Haben wir jetzt noch welche jetzt gerade?
CSV ist besser, XML ist besser.
Aber
es ist schon interessant, wo dann so
Probleme passieren, weil oft
hast du halt kaputte Prozesse innerhalb von
Unternehmer, das hatten wir auch schon,
und wenn du jetzt XML
erzeugst und das irgendwo hinschiebst,
dann
bist du ja gezwungen. Zum Beispiel, wenn du das auch
gegen die DTD validierst oder so.
Das musst du überhaupt irgendwie. Die meisten
XML-Schreibbibliotheken weigern
sich halt einfach, irgendwie was rauszuschreiben,
was halt nicht okay ist als XML.
Das heißt, wenn du irgendwie Mist machst
und dann aber was rausschreiben willst,
dann funktioniert das halt nicht.
Und dann kann es sein,
dass die Probleme, dass es halt aus einem
kleinen Fehler ein großer Fehler wird.
Und das ist halt das eigentlich üble Problem.
Also sozusagen das praktische Beispiel, was
immer und immer wieder passiert ist halt oft,
sowas wie, wir kriegen CSV
und dann passieren da so Dinge
drin wie, naja, also ein Teil
der Zeilen ist halt UTF-8
irgendwie Encoding verwendet, ein Teil
der Zeilen irgendwie Windows, ein Teil der Zeilen
Latin One. Großartig.
Großartig kann man sagen, ja so,
das nehme ich nicht, das geht nicht,
das ist irgendwie kaputt, kann man machen,
aber ist halt auch
Geld, das dann verloren geht unter Umständen
und ehrlich gesagt, wenn ich jetzt sage,
ich paste jetzt diese Zeile
und dann kriege ich halt irgendwie eine Exception
oder ich weiß nicht, ich merke halt so, oh, das ist hier was ganz anderes, das ist kein UTF-8,
dann zu sagen, na gut, dann probiere ich halt mal Latin1, okay, geht.
Ja, oder so, das ist nicht so schlimm, das geht, das kann man programmieren, das geht.
Ich kann jetzt immer noch parsen, ja, selbst wenn solche Dinge passieren wie,
ja, das ist halt jetzt nicht mehr Semikolon der Spalten-Trenner, sondern Komma oder Tab
oder da gab es doch nicht so ein Zeichen für.
Ja, have the separated values, das ist mein eigener kleiner Kreuzzug.
Genau, das kann ich auch irgendwie erkennen und dann kann ich damit irgendwie umgehen
und wenn man das halt ein paar Jahre macht, dann hat man halt
irgendwie ein paar Sachen. Da kannst du gegenschmeißen,
was du willst, der passt, ist alles egal. Geht.
So. Okay, ist Aufwand und ist
hässlich und macht keinen Spaß, aber es geht
irgendwie. Und die
meisten Probleme bei CSV sind so, dass man die
schon irgendwie in den Griff kriegt. Man muss
halt irgendwie wollen, aber
ja, es geht auf jeden Fall.
Man kann sich aus diesem Problem wieder rausrecovern.
Bei XML ist es oft so, dass
du Probleme halt dann siehst, aus denen
du dich überhaupt nicht mehr rausrecovern kannst,
wie zum Beispiel, es kommt halt ein syntaktisch korrektes XML,
aber
das ist halt leer
und jetzt bedeutet halt leer halt zum Beispiel sowas wie
naja, lösche alle
Dinge, die halt vorher da waren
was halt
ein katastrophaler Fehler sein kann
wo dann Rechtsstreit
draus wird
die Frage ist, was machst du denn
an der Stelle, du siehst halt, okay, jetzt kommt hier dieses Ding
und dann denkst du so, okay
was willst du denn jetzt
als Programmlogik machen
willst du sagen
Nö, das
führe ich jetzt nicht aus, weil das kommt mir
irgendwie komisch vor, landest du im Rechtsstreit
Du führst das aus
viel Geld geht verloren, du landest
in einem Rechtsstreit, du hast nur schlechte Optionen
du hast nicht die Option so, okay, wir machen das
in Coding nochmal ein bisschen anders und dann versuchen wir das irgendwie anders
zu parsen, dann geht's, sondern du bist eigentlich nur
bei, eigentlich wahrscheinlich müsst du dann irgendwie
alarmieren und dann müsste jemand irgendwie einen anrufen
oder so, aber das ist halt auch dann
einfach Kacke, ja
das ist einfach, und solche Sachen
hast du halt bei, wenn die
Fehler nicht mehr, also die Idee bei XML ist so ein bisschen
wenn du auf der syntaktischen, also
wenn man sagt halt, ah, wir haben so viele Probleme mit diesen
Syntax und so, wir machen jetzt
ein Format, wo das validiert ist, dass das nicht mehr passieren
kann, ja, und dann hast du halt
sozusagen mit dieser
Art Wacky Mole zu spielen, ja, dann kommt
das Ding halt an einer anderen Stelle wieder hoch und zwar auf einer
semantischen Ebene, wo du gar nichts mehr machen kannst
oder wo es viel schwerer ist, damit umzugehen mit dem Fehler
und ja, das ist halt
so ein bisschen mein Problem mit XML
und dass man das halt, man kriegt die Probleme
nicht so einfach weg.
Also wenn da Abteilungen sind und die
verwenden alle Excel und dann in unterschiedlichen Formaten,
dann ziehst du das irgendwie zusammen und versuchst es rauszuschreiben.
Dann besser, du schreibst es irgendwie raus
und es ist halt falsch und du kannst es hinterher noch irgendwie wieder fixen,
als da fehlen dann halt bei zwei Abteilungen,
die fehlen die Daten einfach und du weißt
halt nicht, was passiert ist.
Das ist so ein bisschen die Debatte zwischen
be lenient with what you accept
and strict with what you create.
Robustensprinciple.
Ja, das ist
Programming by Contract und wenn du
das nicht 100% erfüllst, dann ist es halt weg.
Ja, also
schmeiße ich alles weg, wenn ich halt irgendwie
Mist bekomme auf meiner API.
Sage ich harte Begegnungen.
Das ist halt jemand, die
gar nicht benutzen kann, die API.
Vielleicht weiß ich ja noch gar nicht, was
da alles kommen soll. Vielleicht möchte
ich das ja einfach irgendwie als Zeichenkette
konvertieren und da trotzdem reinschreiben und wieder rausgeben,
wenn da jemand nachfragt.
selbst wenn das irgendwie gar nicht dem entspricht, was ich eigentlich
dachte, was ich haben brauche.
Das kommt auch so ein bisschen in Wellen, oder?
Dieses Robustness-Principle. Für eine Weile
lang war das total
ja, wir akzeptieren alles und
dann hast du so lustige Modi-Bake
in deinem Notepad drin.
Shit in, shit out, sagt man ja.
Internet Explorer zeigt
auf einmal alles auf Koreanisch an und dann
schwingt das Pendel wieder in die
andere Richtung, wo alles XML, XHTML sein
muss und nur wenn das validiert, kannst du die Webseite
auch überhaupt anzeigen.
und dann schwingt es wiederum zu HTML5, wo das so, ja gut, wenn da ein HTML5-Teig drin ist, dann kannst du schon irgendwas draus machen.
Ja, so persönlich ist mir aber das irgendwie, wir versuchen es irgendwie hinzukriegen, ist mir sympathischer als, wir machen jetzt eine Bürokratie und dann fällt uns auch das...
Nein, der Kunde ist schuld, der Benutzer ist schuld, das ist immer die richtige Antwort.
Ja, naja.
Ja, schwierig, schwierig da auch, ja.
wieder wie vorhin, es gibt Situationen,
in denen es so ist und es gibt Situationen,
in denen es so ist.
Aber klar, vor allem, also ich meine,
viele von diesen Datenschnittstellen
sind ja zwischen
Entitäten, die
mehr oder minder professionell sind und
dann ist es halt
einfach pragmatisch zu sagen, okay,
das kann halt sein, dass die das nicht
100% richtig generieren können.
Und wie geht man damit um?
Und
ja,
Ja, okay
Das hat jetzt aber nichts mehr mit Kubernetes zu tun
Ich wollte gerade sagen, kube-control-apply
In gewisser Weise schon, weil
bei Kubernetes hast du halt auch so eine
Abstraktionsschicht, die dann halt irgendwie
du sagst, okay, ich zwinge dich dazu, dass du
sagen kannst, wie viel Hauptspeicher du denn brauchst
Ja, okay, gut
Und dann kann es sein, dass du halt ein anderes Problem kriegst
Das ist quasi das, was du vorhin sagen wolltest
Genau
Dass es Situationen gibt, in denen kannst du gar nicht sagen, wie viel Hauptspeicher du brauchst
Also zumindest nicht dauerhaft oder zumindest nicht
so richtig im Vordergrund.
Das ist ein gutes Argument.
Das ist halt so viel aufwendiger.
Beziehungsweise du überprovisionierst.
Du musst halt einfach quasi vom Worst Case ausgehen
und der Worst Case
ist halt,
alle Menschen auf der Welt
rufen gleichzeitig dieses Video ab und
das
musst du jetzt einplanen.
Ja, und das musst du dann halt auch bezahlen.
Ja genau, das musst du dann auch bezahlen, weil so viel hast du ja requestet.
Also zum Beispiel für so einen Konzertticketanbieter wäre das vielleicht
ein relevantes Problem.
Ja, oder überall, wo du Spitzen hast.
Es gibt ja überall Saisonalität, es gibt ja überall
Zeitpunkte, wo mehr Traffic ist und wo weniger Traffic ist
und Spannungsspitzen, aber das ist ja auch das Versprechen, das ist ja das Versprechen
von Cloud, dass du diese Spitzen abfangen kannst, für die realen Kosten
sag ich mal. In dem Moment mietest du dann halt mehr Rechenleistung
als in anderen Momenten. Du mietest ja auf einmal halt 250.000 Rechner, die normalerweise
aber auch nur 5, aber für das Wochenende, wo halt dann die Konzertkarten
Ja, wo Taylor Swift eine Milliarde Dollar umsetzt
mit ihren Konzertkarten, dann
bricht dein System halt trotzdem zusammen.
So war es ja.
Ja gut, aber das
ist so ein bisschen das eigentlich Frustrierende,
finde ich, dass man aus technischer Sicht so
viele Sachen sieht, die man machen könnte
und dann macht aber trotzdem
jemand so viel Geld mit
Shell-Skripten, die jede Nacht
alles neu starten und
diese Personen, die sitzen
an der richtigen Stelle. So ärgerlich.
Wir könnten es alles viel besser.
Das war ein Kauf-mich-Vortrag.
Ja, jede
Unterhaltung ist, jedes Gespräch ist
ein Kauf-mich-Vortrag.
Was meinst du, warum ich immer herkomme, Dominik?
Ach so, natürlich. Für die ganzen großen Aufträge.
Ja, dann habe ich alle schon über den Podcast
an Landtag gezogen.
Funktioniert jedes Mal. Immer.
Also, liebe Zuhörer, wenn auch Sie
Interesse haben an einem...
An einem Pick.
Ein Pick?
Dominik, hast du einen Pick?
Environs. Kennt ihr das?
Was ist Environs?
Kennt ihr Django Environ oder kennt ihr
Python.env oder sowas?
Genau.
Environ, doch, ja, nicht ganz.
Environ ist so ein anderes Paket,
wo man halt Environment-Dateien
lesen kann oder halt aus der Environment-Variablen
dann irgendwann seine Sachen
ins Projekt bekommt.
Das ist so ein bisschen anders als Django Environ.
irgendwie. Und das macht halt auch sowas, dass man
halt irgendwie
quasi auf das
Environment irgendwie
geordneter Form zugreifen kann. Genau, also
mit Konvertierung direkt in die richtigen
Datentypen und sowas. Ah, okay.
Und ja.
Finde ich ganz nett, also weil
Dango Envyron habe ich sonst immer benutzt, ich versuche gerade alles umzuziehen
und
ist irgendwie schön. Ich weiß noch nicht, ist das einfach,
intuitiv, funktioniert das? Du machst ein Env auf
und machst dann Read Env von den Podfiles, die du haben willst
und für dich. Apropos,
wie nutzt ihr es? Schreibt ihr einfach tatsächlich
Stumpf-Secrets irgendwo rein oder
habt ihr da irgendwelche Secret-Vaults
oder es gibt ja noch ganz andere
Sachen, also man muss ja irgendwem vertrauen.
Ich weiß nicht, ob ich das jetzt hier sagen will.
Jochen's Secrets
liegen auf einem offenen
S3-Bucket, wo nur er
die ID kennt.
Nee, verschlüsselt im Git.
Gut, das sind zwei unterschiedliche Probleme.
Einmal, wie hält man die Secrets
vor,
bevor man deployed hat?
sozusagen.
Und wie hält man die Secrets eigentlich,
wenn deployed ist, weil
die Applikation ja irgendwie sie kennen
muss. Und dafür können sie ja nicht mehr verschlüsselt
sein. Ja, aber das ist doch das DRM-Problem, oder? Du kannst
eine Nachricht nicht vor dem Empfänger verschlüsseln.
Genau, genau, genau. Aber der
Empfänger muss sie auch irgendwie kriegen.
Ich benutze ja gerade einen proprietären Service
für, den ich ganz gut finde.
Doppler. Und also
natürlich kennen die dann halt auch die ganzen Sachen, aber die
machen sowas wie Automatic Rotation oder sowas.
Da musst du nicht mehr anfassen und du kannst halt
für jeden Entwickler irgendwie so eigene Sachen
haben, der muss ja einfach nur noch sagen,
Doppler-Login, Doppler-Setup, fertig.
Für so ein Projekt. Oder halt Doppler-Use
und der schreibt dann, wenn du willst, seine Dot-Ams rein oder so.
Aber Moment,
da liegen dann deine
Secrets getrennt von allem anderen, also auch von
deinen Repositories
und deine Produktionsmaschine geht halt auch zu Doppler
und zieht da die Secrets und
schreibt sie nochmal irgendwo lokal hin?
Oder holt sich die einfach?
Oder du musst auch irgendwie auf Doppler zugreifen.
Genau, du musst halt mit Token
mit Token.
Das Token musst du aber die Applikation irgendwie kennen.
Das ist dann Masterkey.
Wenn ich den kenne, dann kann ich alle Secrets abgreifen.
Wie weißt du dieses Token?
Du musst das vorhin nur
und schreibst das dann ins Deployment-Skript.
Du hast ein sekundäres
System, wo dieses Token drin ist.
Genau, eben. Weil wenn du das schon ein System hast,
um dieses Secret, was sehr wichtig ist,
zu deployen, warum deployst du dann nicht einfach
auch alle anderen Sachen damit?
Wo ist jetzt der Vorteil?
Also du musst ja, also du kannst das ja irgendwie mit
Ich muss gerade kurz überlegen
Ja, also
wie willst du die anderen Sachen da reinbekommen
dann
Also wenn ich jetzt so ein Deploy-Token
hab, das halt dann einfach so zugreift auf die ganzen
anderen Keys, die da irgendwo rumliegen und die vielleicht
rotated sind oder was
Das ist ein Token, okay, dann hab ich
lesende Zugriff auf die ganzen Geheimnisse
Aber
wenn du die sonst eh nicht hinschreibst
und ich verstehe den Unterschied nicht.
Also mein Punkt wäre halt gerade,
wenn du eine, dieses Ding muss ja auch geheim
bleiben. Und wenn du einen
Weg haben musst, wie du dieses Geheimnis
deiner Applikation mitteilst,
warum kannst du diesen Weg nicht benutzen,
um alle anderen
Geheimnisse, die du halt auch hast, der Applikation
auch mitzuteilen, weil
ja,
musst du ihn ja eh haben.
Oder machst du das einmal beim Setup?
Manuelle Eingabe einmal, irgendwie
mit PyTest. Ja, aber das kann sich ja auch ändern.
Also du hast
eigentlich nur die Menge der Secrets, die du
mitgehen möchtest,
verringert. Ja.
Hast die Secrets komprimiert.
Also du kannst halt zum Beispiel jetzt GitHub
irgendwie sagen, bei den Secrets steht es drin,
da könntest du aber auch sagen, du sagst dann halt, okay, dann machst du alle
bei Secrets, bei GitHub Secrets.
Ja.
Okay,
ich wollte ja gar nicht,
es ist ein blödes Problem, aber
was ich tatsächlich mache, ist ich,
Oh doof, das ist echt doof, das zu sagen,
aber
Ich habe Sachen oft in
Voice drin liegen und dann
schreibe ich das halt tatsächlich in so einen Endfile
und dann hat die Applikation das.
Der Vorteil dabei ist, es ist eigentlich
total einfach, ich muss mir keine Gedanken machen über
irgendwelche externen Services oder so, ich habe auch kein System
neben dem Repository, es ist alles im Repository
drin, aber halt verschlüsselt.
So, zack. Genau, aber
die Nachteile sind
und, äh, tja, wenn ein Angreifer irgendwie in meine Applikation reinkommt, dann...
Ja, der muss auch entschlüsseln halt einfach.
Nein, nein, der muss nichts entschlüsseln. Das ist halt das, was ein Angreifer...
In der Applikation ist es ja...
In der Applikation...
Aber das ist ja immer so.
Ja, aber er hat es halt besonders einfach, weil er muss einfach nur, er nimmt einmal das komplette Environment,
ne, macht da JSON raus und schickt es an irgendeinen, ich hier alle Secrets in, alle Environments von allen irgendwie stormen.
Und dann hinterher guckt er, ob da vielleicht ein ABS-Key drin war oder sowas.
So, also das ist halt blöd.
bei jeder HFM oder bei irgendwas,
das muss ja irgendwie, muss die Sache liegen.
Ja, aber genau,
also das würde ich sagen, der Nachteil ist,
es ist halt besonders, also ich,
wenn jemand meine Applikation schafft aufzumachen, dann
habe ich ein Problem.
Ja gut, aber genau, also
Envy Runs macht ja auch nichts anderes, als dass du irgendeine
Pfeile oder irgendwie anders die Sachen reinzuschreiben.
Ja, man könnte es ja auch anders machen, man könnte ja auch
sowas machen wie,
man packt es in ein
Modul mit komischen Namen
irgendwie und schreibt es halt als Python-Code
irgendwo hin. Security by Obscurity.
Und importiert den Kram,
ja. Also, sag mal so, wirklich
helfen tut es nicht, weil du kommst immer noch in den Kram ran,
aber die automatischen
Dinge, die halt über irgendwie eine
Sicherheitslücke in Django gefunden und
es läuft über alle Dinge, wo man
erkennen kann, oh, das ist ein Django, läuft das halt
drüber und holt alle Environments
und damit alle Secrets. Das wird
da nicht funktionieren. Das ist genauso, wenn ich den
Standard-SSH-Port auf 2224
ändere, damit das nicht... Ja, okay,
es ist Security by Obscurity so ein bisschen.
Was du dann eigentlich machen müsstest, ist, dass
du irgendwelche Capabilities hast.
Also, dass du die Datenverbindung nicht mehr
direkt über Django machst,
wo das Datenbankpasswort drinsteht, sondern
dass es da einen getrennten Service gibt, der
ein anderer Benutzer ist, der eine andere Technologie hat,
den du nicht automatisch mit aufgemacht hast,
der nur von dem Django-System
erreichbar ist, wo du quasi sagen kannst, ich möchte jetzt
eine Datenbankverbindung haben.
Aber das ist ja dann auch schon wieder so viel
Aufwand.
Aber vielleicht fehlt
deine Standardlösung.
Vielleicht fehlt da eine
Security-Onion um
Django außenrum.
Ja, ich weiß es nicht.
Ich überlege immer noch, was für diesen profiteren Service spricht, weil das sind
verschiedene Sachen, die halt dann davon getrennt sind, die vielleicht
gar nicht so schlecht sind, weil wenn ich halt aufs Repo
zugreifen kann oder auf die Secure-Sager komme, ist dann
trotzdem an die Secures nicht dran.
Es ist halt die Frage, wo liegt denn dieser Key
zum Produktionsdeployment?
Da kann man ja noch Benet-Safe und so davon
und so.
Ich muss mir nochmal genau überlegen, was davon der coole Vorteil ist.
Also weil alternativ,
Die anderen Lösungen finde ich alle nicht so
convenient.
Es gibt halt diesen Level von
ich habe jetzt DevSecrets für den einen Entwickler
als die anderen DevSecrets. Ich habe noch
StagingSecrets, die stehen alle drin.
Du kannst einfach mit einem Kommando aufsetzen, das funktioniert,
das wird eingetragen, das ist nutzbar, das ist übertragbar.
Du kannst einfach, wenn irgendwie ein Entwickler aussteigt,
kannst du einfach den Account da rausnehmen oder so.
Das sind alles Sachen, die ziemlich easy sind.
Und du kannst automatisch dann halt so Sachen migrieren und so.
Das ist schon nice. Und das hast du zum Beispiel
alles bei diesen anderen Vaults nicht mit drin.
Du musst alles selber anfassen.
Ja, okay.
Ja, na.
Okay, was ist denn dein Pick?
Mein Pick ist ein Artikel
mit dem Titel
An Interactive Intro to CRDTs.
Ich bin ja ein großer Fan
von CRDTs, also
Concurrent Replicated Data Types.
Wie sagt ihr dieses Wort?
CRDT.
WTF?
Everpet?
Also ich sag, keine Ahnung,
Crudities?
also
Conflict-Free-Resolution-Dependent-Data-Times
wo du
Datenstrukturen hast, die sich selbst wieder in einen
synchronen Zustand bringen. Also sowas wie Etherpad oder
HedgeDoc oder Google Documents, wo zwei Leute gleichzeitig
bearbeiten können und am Ende ist ein Dokument da, was bei beiden
Google Wave.
Google Wave war großartig.
Live Share.
Ja, und da gibt es viele Anwendungsfälle
dafür und dieser Artikel ist eben eine
interaktive
Erklärung, wie diese Datentypen
funktionieren und wie man die
umsetzen kann. Und weil ich
CRDTs großartig finde und jeder sollte die verwenden
und überall und ich kann sie aber auch nicht,
hat mir
das sehr weitergeholfen und ich finde das
sehr großartig. Und es ist auch schön so mit
interaktiv. Also du kannst dann
Hast dann zwei Malfenster und kannst
im einen malen, kannst im anderen malen, kannst auch
zwischendurch die Verbindung abschalten und dann sehen, wie die sich
synchronisieren. Und das ist sehr, sehr
schön gemacht und sehr anschaulich.
Das muss ich unbedingt mal spielen. Das ist sehr gut.
Das empfehle ich jedem. Deshalb ist das mein Pick
in dieser Episode.
Ja,
ich hatte ja letztes Mal
etwas gepickt, was ich in der Episode
davor schon mal gepickt habe.
Das war auch
ein sehr leckerer Pick.
Daher dachte ich mir heute, okay, mache ich mal etwas, was ich noch nicht
gepickt habe und etwas, das
absichtlich besonders unappetitlich und
unverdrohlich daherkommt.
Und das ist,
ich weiß nicht, ob ihr das kennt, man sollte
es aber trotzdem mal konsumieren,
nämlich
das
VBOG.
Das Software Engineering Body of Knowledge.
Haben wir doch alle schon mal konsumiert,
sonst wären wir doch gar keine Software Engineering.
Also,
ja, ich habe es mir jetzt auch irgendwie mal...
Es sind auch nicht viele Seiten.
Ich bin eh in der Ticketschubse
Code Monkey, da ist ja ein anderer noch hier
Es ist ein bisschen kompliziert
reinzukommen, man muss halt irgendwie so ein Formular ausfüllen
und dann kann man sich mal einen Downloadlink geschickt, aber
genau, und dann kann man, da steht halt
da sind halt alle solche, das ist eigentlich
wenn man sich diese Fragen, die wir ja auch schon öfter
diskutiert haben, was sind eigentlich die unterschiedlichen Arten von
Tests, irgendwie Unit Integration
oder sonst irgendwas, da wird das
alles definiert
Da wird einfach die Wahrheit
festgelegt
Genau, aber sozusagen, um diese Diskussion
zu beenden, kann man immer sagen, ja, ich verwende jetzt die
Definition hier aus dem Ding, sondern auch
die ganzen Prozesse und so, das ist alles definiert und
was sind die Requirements und wie funktioniert das und
was gibt es alles für, weiß ich nicht, Dinge,
die man so tun kann in der Softwareentwicklung.
Welche Version ist das?
Das ist das große Glossary für alle
Dinge, die Softwareentwicklung.
Ja, die Festlegung der Wahrheit.
Die einzig wahre Wahrheit, TM.
Die ist hier festgelegt.
Na dann?
Ja, sehr appetitlich Jochen, sehr schön
Ja, das war auch schon der Picker
Wohlbekommens
Na gut
Ja, dann
eine nicht so Kubernetes-Kubernetes-Folge
Aha
Ja, doch, war auch schlau
Ja, wir haben nicht so viel
erklärt, wie man das benutzt, aber das müsst ihr selber
rausfinden
Aber wenn ihr wirkliche Dinge wissen wollt,
dann dürft ihr nicht hierher zukommen
Ja, es gibt auch so ein paar einfache Sachen, die der Golo hatte
irgendwie. Vielleicht können wir das auch noch verlinken.
So einen schönen YouTube-Einsteiger-Ding.
Finde mal, wie du dein Minikube aufgesetzt hast
und was man damit machen kann. Ja, genau. Also ich habe eigentlich
Golos-Tutorials ein bisschen gemacht.
Ist das dein zweiter Pick?
Ist das der Pick, der
Jochen's letztes Mal? Ja, das ist so ein YouTube-Kanal, der
die Woche irgendwie so Sachen macht.
Es ist relativ einfach auf Deutsch, ein bisschen langsamer als wir reden.
Und es ist ganz nett.
Vielleicht sollte man das am Anfang sagen.
Alles klar?
Okay. Dann
bleibt uns gewogen.
Schaltet uns ein, wann auch immer ihr hört
Mittags, morgens, abends, nachts
Einen guten Tag und gute Zeit
Bis zum nächsten Mal
Tschüss Johannes, bis bald