Transkript: Kubernetes
Vollständiges Transkript der Episode. Zeitstempel beziehen sich auf die Audiowiedergabe.
Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode 52.
Heute reden wir über Kubernetes.
Hallo Johannes.
Hallo zusammen.
Hallo Johannes.
Hallo Dominik.
Hallo Johannes.
Ja, schön, dass du wieder da bist, Johannes.
Ja, schön, dass wir wieder da sein.
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üssen wir.
Manche von uns müssen.
Ich musste auch schon.
Genau.
Und deswegen wollen wir vielleicht so 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 den kleineren, da verlasse mich dann, dass andere das wissen.
Okay, aber ich mache jetzt einfach hier mal den News Wade Chapter mal.
Ich mache doch einfach mit dem normalen Python 3.12 News an, weil wir haben Oktober und ich glaube, da ist immer neueste Python.
Ja, ist jetzt immer einmal im Jahr, irgendwie neue Release.
Seit drei Tagen, oder?
Ich weiß gar nicht genau, wann das release wurde, weil wir haben das irgendwie noch nicht so lange.
Je nachdem, wann dieser Podcast gehört wird.
Ja.
Also für uns ist es noch frisch, für euch dann vielleicht so, was?
Das war doch ein bisschen Jahre her.
Genau.
Und ja, also ich habe verwendet ihr das schon?
Nein.
Nein?
Nicht runtergeladen.
Hab nur die News gesehen.
Also ich
habe gesehen, dass du Probleme hattest, das auf deinem Mac zu installieren.
Aber das ist schon.
Nein, bei mir ist ja neues, aber ich habe mir angewöhnt, bei 1 erstmal alle Projekte umzuziehen.
Aber es ist jetzt nicht das Feature dabei, wie ich dachte, 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, ja, das will ich jetzt sofort benutzen.
Weil es ist ja nicht so richtig so was dabei, was man so richtig benutzen kann, oder?
Ja, kein neues Wallrust oder kein Metal
Case oder.
Habt ihr ein Match schon mal verwendet?
Ja.
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 Patenti-Modell validiert oder halt nicht.
Und kannst das dann halt direkt welche nutzen, das ist nett.
Ja, wie gesagt, ich finde das total super, aber ich habe einfach irgendwie noch nicht genug Probleme.
Wo wir bei Patenti reden, ich glaube, Patentic 2 hatten wir auch noch nicht in den News und weil wir eben doch was
gemacht hatten.
Doch, doch hatten wir das jetzt mal genau.
Okay.
Aber auch noch, also nur, dass ich damit Probleme hatte, das abzudenken.
Ich habe in der Zwischenzeit ein weiteres meiner Projekte irgendwie updaten müssen, weil jemand auf GitApen-Ischue aufgemacht hat und gesagt hat, ich habe das jetzt gerade mal probiert, es gibt mir diese komische Pedantic-Fehlermeldung, weiß gar nicht, was das ist.
Ja.
Und genau, so habe ich das dann auch gemerkt, dass es nicht mehr funktioniert.
Und das habe ich jetzt auch umgezogen.
Und es war auch deutlich mehr Arbeit, als ich gedacht hätte.
Und also ich habe jetzt zwei Projekte umgezogen auf die neue Pydentic-Version und das war beide Male ätzend.
Also, ja, 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.
Ganz wahrscheinlich, höchstwahrscheinlich.
Ja, aber gut, jetzt inzwischen habe ich ein bisschen Übung, dann kann ich ganz in anderen Sachen auch noch umstellen, dass dann kein Problem mehr hoffentlich ist.
Wenn du das
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 Piedentic-Fehlermeldung nicht so richtig hilfreich.
Also zum Beispiel die 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 sie hier, ich zeige sie 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 mal, ich kann das lesen vom Sofa aus, was du da dann rechts machen kannst.
Ich mach mal nichts größer.
Ja, ich wollte gerade sagen.
So, und dann, wenn man diesen Tracker kriegt, der eigentlich relativ lang ist, sodass man Schwierigkeiten hat, den relevanten Teil zu erfassen.
Ich habe jetzt das hier extra so rausgekuttet, 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 A, Database ORL, und dann komme ich halt, ah, Database URL ist missing.
Das stimmt aber nicht.
Nein.
Die ist ja da.
Sondern die ist da, aber das, was.
Aber die B-Engine ist halt Missing, was da drüber steht, wo man denkt, das gehört hier noch zu einem anderen Teil.
Und was hier gar nicht drin steht, 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 es leicht.
Aber so
wie das bei dir aussieht, könnte auch in der Formatierung, wahrscheinlich hast du es absichtlich so formatiert, dass sie dann einträgt so aus.
Nein, nein,
das sieht wirklich so aus.
Das sieht tatsächlich etwas schräg aus.
Also die Fehlermeldung ist ja ein bisschen zwar geschückelt.
Hast du das mal mit 3.12 probiert?
Nein.
Ist das noch so?
War das nicht die 3.122.
Okay, du hast vorher schon das Problem umziehen.
Ja, ja, ja.
Also die Piedentic ist ja schon in einer neuen Version seit einigen Monaten.
Vielleicht, aber das kann das dann 3.12 dabei geholfen hätte noch.
Ist das anders in 3.12, weil das ist doch eine Fehlermeldung von Pydentic oder so?
Ja, ja, genau, genau.
Nee, wahrscheinlich hat das.
Aber durch diese, ich weiß nicht, ob die verbesserten Fehlermeldungen in 3.12 auch was damit zu tun haben, wie dieser ganze.
Wie dieser Traceback-String gerendert wird.
Genau, weil da sind ja auch verschiedene andere Sachen passiert, die dieses Rendern beeinflussen, weil die F-Strings ja beispielsweise sind auch neu.
Ja, ja, da kommen wir gleich noch zu.
Also auf jeden Fall dieses Padentic-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.
Da fliegt es raus.
Ja, das kann auch sein.
Genau, was ist die Konstante an diesem Experiment?
Ja, genau.
Ja, also genau.
Jetzt waren wir schon bei den 3-12-Änderungen.
Genau, bessere Fehlermeldungen.
Also 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 PiePy-Episode erinnert hat, war, dass jetzt, wenn man irgendwie eine Variable verwendet und die nicht definiert ist sozusagen in einer Methode, dann sagt einem jetzt der Traceback so, sag mal, kann es sein, dass du Self-Dot irgendwie vorher vergessen hast?
Und PyPi konnte das halt schon einige Zeit.
Und ich glaube, das ist halt, das haben sie sich dann von PyPie 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 unterkringelt und sowas.
Ja, genau, solche Sachen.
Also da ist noch ein bisschen was passiert.
Ich weiß es nicht, weil ich sehe nie Fehlermeldungen.
Ach so.
Du machst einfach, kennt ihr das Modul, als wollte er eigentlich mal so ein Pick, ne?
Fuck it.
Du machst einfach Pippin-Style Fuck it und dann schreibst einfach Add Fuck it um drüber oder Whistfuck it und dann gibt es keine Fehlermelde mehr.
Ja, dann eine andere Geschichte, etwas, also F-Strings haben an irgendwie ordentliche Überarbeitung erfahren.
Ja, genau, davon musste man ziemlich viel umbauen, hast du gesagt.
Ja, der, 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 dieselben Quotes wie der String eigentlich.
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 vernästen kannst, also ineinander schachteln kannst, halt auf die Anzahl unterschiedlicher Arten zu Quoten.
Wie tief würdet ihr denn empfehlen, so F-Strings in den Ländern?
Aber was zum Beispiel echt nervig war, dass du zum Beispiel in Multiline F-Strings keine Kommentare hinter so einen F-String machen mehr konntest.
Ja, und Multiline-F-Strings gingen auch, also 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 New Lines 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 in C implementiert und ist halt auch ein gutes Stück schneller, ist irgendwie 60% schneller als vorher.
Und ja, das hat jetzt zur Folge, dass man F-Strings halt auch beliebig nesten kann und all diese anderen Details jetzt auch gehen.
Zeit, dass zum Beispiel Logging oder sowas mal umsteigt 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 nach macht das Logg nicht, weil das nicht evaluiert werden soll, bevor es, wenn es nicht gelockt wird, auf einem falschen Level.
Ja, das 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 eine 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 dann eine Aggregation anhand des Template-Strings und kriegst dann innerhalb dieser aggregierten Sache gesagt, hier sind mit folgenden Attributen aufgetreten, XY und Z.
Ja, okay, aber man könnte ja auch jetzt irgendwie Sentry erklären, dass sie das bitte anders aggregieren sollen und das da wieder rauspopeln sollten.
Ah, gut, aber da muss man doch jetzt schon wieder so mit dem Loggingmodul anpassen.
Ja, dann bist du schon wieder bei so Sprachsachen, dass du sagst, dann musst du doch rausfinden, wo die F-F-Attribute drin waren.
Ja, bei Loggingmodul ist eh einigermaßen furchtbar mit Chemic-Case und so warst, das ist alles eh bah.
Ah, das mag ja schon sein, aber gerade diese F-Strings, die zerstören halt, dass du siehst, wo da die
Templates startet.
Also das einzige Argument, was ich gehört habe, halt, ist, dass halt je nach Lockdown, 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 evaluieren.
Jedes Mal.
Ja, keine Ahnung.
Ja, gut, okay.
Also Geschmacksfragen.
Ich weiß es nicht.
Ja, genau.
Achso, was auch, wofür das vielleicht auch ganz, obwohl, ich glaube, das ist jetzt auch eine doofe Idee.
Es gibt ja für das hatte auch der, na, wie heißt er noch, Thomas Küttler, der hier war wegen HTMX immer gesagt.
Also es gibt ja in Python gibt es halt nicht sowas wie Template Literal Strings in JavaScript oder so, womit 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.
Das Sinn macht, weiß ich auch nicht.
Du hast irgendwas von Parchals gerade gesagt?
Django Template-Parchals, damit geht das halt auch ganz gut eigentlich.
Genau, das sind aber jetzt so ein paar Module, die waren in einer der letzten Folgen von, weiß nicht mehr was, Django Cast?
Django Chat, meinst du mit den Podcast?
Ja, das war da auch drin, ja.
Ja, genau, genau, da war irgendwie eine nette Folge, wo die Leute genau diese Templating-Sachen, Parchels mitgewusst hat, die waren schön, weil kann man schöne Sachen mit einzelnen Templates machen, die sonst so nicht einfach so modular sind.
Ja, ich habe es jetzt auch schon ein paar Mal verwendet und das ist echt tatsächlich ziemlich gut.
Kommen wahrscheinlich auch in Django 5.1 mit rein.
Ah, ja, schön.
Genau, dann, es gab so ein paar Performance-Geschichten, genau, bei F-Stings, die sind ein bisschen schneller geworden.
Es gibt jetzt irgendwie Comprehension Inlining.
Uh, ehrlich gesagt, was es genau macht, weiß ich nicht, aber List Set-Dick-Comprehensions werden jetzt ungefähr zweimal schneller.
Das nehmen wir doch mit, oder?
Das ist gut, ja.
Und dann natürlich die Gill-Aufteilung.
Das habe ich mit Interesse gelesen.
Ja, das ist ein sehr interessanter.
Erklär doch mal ja auch noch, was ist denn die Gill-Aufteilung?
Ja, es gibt ja das globale Interpreter-Lock.
Das ist ein großes Lock und das sorgt dafür, dass Python sehr schlecht ist bei Multithreaded-Anwendungen, weil immer nur ein Thread Python-Code ausführen kann.
Und das ist natürlich so ein bisschen bescheuert, weil dann bringt es ja nichts mehr, ja.
Doch, doch, das bringt ja durchaus schon was.
Ja, es kommt daran, wie deine Threads sind, aber wenn du lauter Python-Threads laufen hast, also du kannst nicht mehr als eine CPU verwenden.
Nee, die geht auch 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 IO bringt es was, aber nicht für Compute.
Also nicht für CPU.
Ist aber das Argument, warum Python so ein Gill hat, ist halt, dass das für den Single-Threaded Case einfach die beste Lösung ist.
Weil du keine komplizierten Loks einbauen musst, weil es schnell ist, weil du gar nichts hast.
Weil du halt nicht
gucken musst, ist halt irgendwie lock, muss das frei werden und dies und das.
Genau, es ist einfach ein Interpreter, ein und fertig.
Und es gibt ja schon lange Bestrebungen und viele Bestrebungen, diesen Gill loszuwerden, zum Beispiel PyPy oder auch Unladen Swallow, falls ihr euch da noch dran erinnert, die haben versucht, das loszuwerden.
Bitte was, bitte mehr?
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, ja, weil es einfach ein großes Ärgernis ist, dass du Multithreaded-Programme schreibst, trotzdem nicht mehr CPU kriegst.
Genau, Anlehnswaller, weil halt die schneller fliegen kann.
Und jetzt wandert es auch so langsam oder beziehungsweise ist ja schon lange unterwegs, dass man das schneller macht und den Gill so ein bisschen wegbekommt.
Und da gab es jetzt eben diese eine Bewegung, dass es keinen globalen, kein globales Global Interpreter-Lo mehr gibt, sondern eben eins für Subinterpreter.
Das heißt, die Python Runtime, der C Python, die CPython VM kann jetzt Subinterpreter starten, die dann ihr eigenes Global Interpreter-Lock haben.
Aber ich weiß nicht, wie 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 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 einfach sagt, hallo, mach mir mal einen neuen Interpreter und dem gibt man dann einen String und dieser String wird dann als Pythoncode da drin ausgewertet.
Da kann man sich natürlich auch wie irgendwie hübschere Abstraktionen noch drumherum bauen, keine Ahnung.
Ja, also ich meine, ich finde das auch so ein bisschen so ein Spezial, 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 da muss man halt schon.
Du kannst ja halt an diese Prozessgrenze.
Du musst 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 besten?
Ja, also es kommt halt hängen halt von den Daten.
Ja, aber du bist, also oft übergibst du halt einfach nur eine URL zu irgendeinem Bucket oder sowas.
Ja, das kommt natürlich auf den Anwendungsfall an nach Handy.
Also ich meine, da gibt es auch Anwendungsfälle, wo du bist.
Wenn man viel Daten übergeben muss, dann ist es schlecht.
Dann musst du immer serialisieren oder musst du ihn irgendwie Speicher irgendwo reinschreiben oder
irgendwie ein.
Genau, du kannst natürlich per Pickel einfach serialisieren und dann irgendwie übergeben oder über eine Pulpe schicken oder sowas.
Also auch ein Standardweg, wie man das macht, ist dann halt einfach Shared Memory verwenden, sodass halt alle Prozesse, die man erzeugt, halt auf den gleichen Speicher zugreifen.
Das geht auch.
Wie geht denn das mit Reisenschaften?
Das kannst du ja das Locking-Problem.
Als Elevator.
Naja, solange du nur liest, ist es kein Problem.
Ja, solange du nur liest, ist das nie ein Problem.
Aber nur lesen hilft ja.
Du kannst ja immer so, vielleicht kannst du neue Keys schreiben, vielleicht geht das gleichzeitig oder geht das nicht auf einen Dick gleichzeitig neue Keys reinschreiben?
Nee, das ist nicht das Problem.
Das geht halt.
Das geht alles nicht.
Aber oft lässt sich das schon darauf abbilden, dass man sagt, man liest das halt und dann macht man irgendeine Berechnung und dann hast du ein Ergebnis von der Berechnung und das führt man halt wieder zusammen.
So quasi so ein Map-Reduce-Schritt, wo du das halt worker rausmappst und.
Das kannst du schon machen, oder?
Das kannst du auch jetzt schon machen, gar kein Problem.
Genau.
Für viele Anwendungsfälle, denke ich, ist wahrscheinlich genau das Richtige, was man 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.
Okay, das muss man dann halt verwendet.
Also du machst irgendwie so ein Map-Reduce-Ding, um die Computation auseinanderzudrüsen 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.
Also und dann, je nachdem, wie groß das ist, was du zurückbekommst von der von der Berechnung, kannst du es halt einfach auch wieder irgendwie serialisieren und in deinem Master-Prozess sozusagen wieder deserialisieren.
Oder wenn das zu groß wird, dann schreibst du das halt in den Prozess.
Von wo?
Also von dem Shared Memory oder was machst du mit der Pipe?
Was meinst du damit?
Wo kommt das her?
Nee, darum geht es nicht.
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.
Genau.
Wenn du jetzt aber so ein System hast, wo du zwölf Threads hast, die alle zehn Millisekunden miteinander kommunizieren, die irgendeine Nachricht schicken, über die Ques schicken, sowas wie das Act-Modell.
Wenn du in Erlang sagst, jede Funktion ist ein Thread und du schickst jedes Mal bei jedem Funktionsaufruf schickst da 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 gewöhnt ist, ja, ob es Pipesinn oder Shared Memory oder ist was egal, geht gar
nicht 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, also du hast üblicherweise einen von beiden Fällen, was 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 irgendwie 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 Load balanced, 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, Mann-Back-Crunching meinst du, du lässt dann doch auf jedem Kern irgendwie einen Python-Prozess laufen und.
Du willst halt ein Array von einem Patabyte irgendwie Zahlen sortieren oder sowas.
Klassische Anwendung.
Das ist aber 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, also es ist aus meiner Perspektive schon ein ziemlicher Nischenanwendungsfall.
Ich meine, es wäre natürlich schöner so
gehen würde.
Vielleicht, weil es nicht geht, Jochen.
Ja, vielleicht auch, weil es nicht geht, mag ich sagen.
Wenn es einfacher gehen würde, würden wir das alle machen.
Ja, vielleicht.
Ich weiß es nicht.
Ja, gut, aber die Beschreibung in die Richtungen und das ist doch schön.
Genau.
Jetzt hast du jetzt nochmal bei 3, 12 was gesagt.
Teil Gil.
Subinterpreter.
Genau, und der Subinterpreter macht immer seinen eigenen Gil.
Okay.
Subinterpreter.
Dann, was haben wir denn noch?
Ja, es gibt jetzt so ein paar Typing-Verbesserungen.
Also die, ich finde das, ich finde das ehrlich gesagt, da sagen mal alle so, ah, das ist so toll, weil jetzt geht das noch einfacher als vorher.
Ich denke mir, wie bitte, das war vorher einfach.
Also mit den Type-War, Type-Aliases und.
Ja, das ist noch einfacher.
Jetzt geht es halt, ja, es ist halt, also wenn man sich da anguckt, wie die Signaturen von Funktionen aussehen, das sieht schon, also du definierst hier zuerst so einen Type War irgendwie den Namen für einen generischen Type und dann musst du, dann setzt er den noch irgendwie da ein und dann, also es ist schon.
Also du hast auf jeden Fall ganz viele Klammern und ganz viele Doppelpunkte und komische Dinge.
Ja, 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 ist es so ein bisschen nervig.
Ja, sozusagen verwendest du dann MyPy D oder MyPy D immer von der Schwert.
Genau, die MyPy.
Der dort fällt dann so ein MyPai-Server und dann kann er mal fragen und mit den ganzen anderen Linting-Sachen halt auch.
Und ja, es ist mehr gekringelt, als ich dachte.
Weil vorher war das immer schön sauber und aufgeräumt.
Und ich finde es tatsächlich auch ein bisschen.
Also wenn man halt Module benutzt, die zum Beispiel falsch Type hinten oder sowas, ja.
Also in Anführungszeichen, dann meckert MyPa halt direkt und du musst halt einfach nebenschreiben, dass er es ignorieren soll, weil das komplett aus dem Modul und es ist ja falsch, das kann ich jetzt ja nicht ändern.
Oder ich kann halt den Typehind davon dann neu machen oder sowas.
Oder eine Juli draus machen, was er aber dann eigentlich auch falsch ist, weil.
Hä, was soll das?
Ja, da müssen wir, glaube ich, mal eine Episode drüber machen.
Ja, nicht nur eine, glaube ich.
Da sind so ein paar.
Das ist eine sehr
lange Episoden.
Ja, also ich gerade so bei generischen Types und so, die finde, das ist alles Willen.
Also und da muss man halt echt
Jung-Stubs oder sowas.
Ja, jetzt ist es auf jeden Fall besser geworden.
Aber man kann es nicht.
Man kann ja zum Beispiel sowas sagen wie, also wenn man jetzt irgendwie irgendwo sagen will, Sternstern, KW-Args oder so.
Was man ja mal manchmal machen möchte, dann ist das ja irgendwie nicht gut zu typen.
Any.
Ja, kann man natürlich auch sagen, String Any, äh, Dikt, String Any, ja, 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, sagt, man sagt, KW-Args, Doppelpunkt, Unpack und dann zum Beispiel klicke ich mal auf und dann gibt man den Namen von einem Type-Dikt an.
Und dann in dem Type-Dikt definiert man dann sozusagen für jedes Keyword-Argument quasi den genauen Type.
Oh, da könnte man auch eine Data-Class reingeben oder sowas.
Aber warum.
Ja, sieht ziemlich genauso aus wie in einem Data-Class.
Warum definiert man die denn nicht direkt?
Was ist dann noch der Sinn von Quark?
Wie willst du denn hinschreiben?
Kannst du nicht.
Du kannst dann halt keinen Standardschang sehen.
Ja, gut, das kannst du natürlich auch machen.
Du kannst halt einfach die ganzen Keyword-Argente hin, wenn es halt ganz gut ist.
Am Ende sind viele Argumente dann irgendwo,
hast du sie halt getypt.
Ja, und du kannst halt auch nicht wiederverwenden.
Aber ja, ist ja nicht so.
Und Validierung kannst du nicht machen.
Ja, ist schon ein Nischenfall.
Ja.
Und genau, bei den Generic-Type-Geschichten muss man jetzt auch nicht mehr irgendwie Type-War und Type-Alias davor schreiben, sondern man kann halt irgendwie einfach Type nehmen als Keyword, 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, der Type ist schon so ein bisschen Bloatware, oder?
So Typing manchmal.
Ja, ich glaube, da müssen wir mal eine Episode nehmen.
Wir müssen nochmal länger, aber das können wir jetzt nicht leisten.
Das können wir
beliebig vertiefen.
Ja, es ist halt wirklich nützlich.
Ich würde sagen, kollaboratives Arbeiten, gerade mit Leuten, die das noch nicht so wissen, was da passiert, ist das echt hilfreich, um so zu zeigen, welches das gehen sollte.
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 nicht.
Zum Typing dazu ist, es gibt jetzt einen Override-Dekor-Dekorator.
Override?
Ja, wo man halt über eine Methode schreiben kann, at override, und dann damit dem einen Type-Checker 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 Type-Checker, und jetzt nennt jemand irgendwie die Methode in der Oberklasse, aber refactort die und benennt die um.
Dann merkt der statische Type-Checker davon überhaupt gar nichts und alles stimmt.
Das Verhalten ändert sich aber.
Weil er jetzt plötzlich irgendwie das nicht mehr überschrieben wird.
Und ja, dann ist natürlich schlecht.
Und das heißt, du sagst explizit, hey, ich überschreib hier eine Methode von einem.
Genau.
Und sobald jemand in der Oberklasse das Ding umbenennt, dann sagt dir der Typechecker, äh, sagt dir der statische Type-Checker, das ist überhaupt keine, das überschreibt überhaupt keine Methode mehr, hier ist irgendwas kaputt.
Was vielleicht schon hilfreich ist.
Ja, und das tatsächlich findet man ein Tabugs, ja.
Genau, das, ich glaube, das ist immer mit dem Typ Typing-Zeugs dann durch.
Genau.
Zu Dekoratoren.
Ah, habt ihr das schon mal verwendet?
Cached Property?
Ja.
Ich habe das mal in den Jungle.
Ich habe das auch schon häufiger verwendet, genau.
Ja, das weg.
Warum?
Es war kaputt.
Das Problem ist, irgendwie, das hat so, es hat irgendwie massiv viele Loks gemacht und hat irgendwie nicht auf Instance-Ebene gelockt und ist alles ganz schrecklich und die Leute haben es gemessen und festgestellt, oh, es ist viel langsamer damit als vorher.
Ich habe es nie überprüft, ich dachte mir so, oh, Cash Tag Real Cash-Property voll gut.
Nee, war scheiße.
Und ja,
das ist ja Cash schon ein Methodenauf, oder?
Ja, also ich habe es ja eben für solche Dinge benutzt, wo halt dann irgendeine Berechnung stattfindet und dann, also wenn die Berechnung sehr lang ist, gut, vielleicht ist es dann auch noch irgendwie tatsächlich effizienter, aber so im Generell war es oft eher langsamer mit dem Cache-Dekorator drüber als ohne und
man kann jetzt die Kalkulation cachen und dann eine andere Sache machen, wo eine Property drin ist.
Ja, also auf jeden Fall irgendwie hat sich wohl, hat sich jemand das genauer angeguckt, dabei hat sich herausgestellt, dass so wie das gedacht ist, das geht das alles gar nicht.
Und daher haben sie es jetzt entfernt.
Das heißt, du musst das jetzt selber bauen.
Also Kleinstmaster zwei Methoden.
Die eine Methode ist eine Property, die eine Methode ist eine.
Es ist nicht so schlimm, also man kann das relativ leicht, sowas sich sowas bauen.
Wenn du keine Loks brauchst.
Ja.
Ja, aber wenn man Loks braucht, dann ist man eh schon in so einem Drachenterritorium.
Das ist halt, ja, muss man eh gucken.
Ja.
Genau.
Dann Drachenterritorium, wo die wilden Tiere wohnen.
Genau.
Große Drachenkultur.
Parslip, etwas, was mich immer.
Also das ist so ein Nervpunkt.
Also 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 ist halt einfach, es gibt halt Parslip, so als das aktuellste.
Und OS.
Es gibt OS, ja, es gibt irgendwie 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 Parslip hat natürlich auch schon diverse, also Parslip, 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.
Also, und jetzt gibt es halt einen Walk in Parslip.
Das musst du machen.
Itad-Dir musst du machen und dann immer rekursiv deine Funktion selber aufrufen.
Ja, aber das willst du vielleicht nicht selber schreiben.
Gleichzeitig Ether-Files und das ist und keine schöne Arbeit und leicht verändert.
Also nur für was anderes und dann willst du jetzt mal kurz irgendwie über alle Files in deinem Dateisystem raum gehen und dann fängst du da an, mit Rekursionen zu machen, Dinge zu tun und so, wo viel schief gehen kann.
Ah, ich weiß nicht.
Also da will man doch eigentlich eine Funktion einfach nehmen und die dann verändern.
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.
Weil 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.
Wenn du ja hier Permissions haben und dann.
Bitte was?
Ja, du kannst ja Cycles in deinem Verzeichnis haben.
Du kannst ja links zum darüberliegenden Verzeichnis und dann hast du eine Kurve drin und dann hast du schon einmal
der Ding zu da, der Ding zu da, dann
kommt der Beachball.
Wenn du dich in dieses Rabbit-Hole eingreibst, dann wird das, was du eigentlich machen wolltest, nicht mehr fertig, sondern dann bist du irgendwie verschwunden.
Erstmal für den Zeichen.
Aber das mit dem Cycle klingt, das könnte man damit lustige Sachen machen.
Ja, schon.
Oder andere Devices und dann von den anderen Devices wieder das andere Device eingebunden und Cycle über Devices.
Und so schnell
kommt man durch.
Da habe ich letztens irgendwo sehr schön, hat das jemand beschrieben, ich weiß nicht, ob das auf Masteron war oder keine Ahnung.
Ja, also die coole Innovation von Unix ist ja, dass irgendwie in Unix einfach alles ein Pfeil ist.
Es gibt ein kleines Problem mit dieser Philosophie, nämlich irgendwie, dass eigentlich so gut wie gar nichts ein Pfeil tatsächlich ist.
Ansonsten war es eine super Idee, aber ist was dran.
Den Witz musst du jetzt nochmal genauer erklären.
Das war jetzt so ein Insider.
Also die Philosophie von Unix ist ja, alles ist ein File.
Du kennst ja.
Da gibt es Files, wo du die CPU-Rauslastung auslesen kannst.
Aber das ist ein Netzwerk-Sock.
Ja, er muss ja den richtigen Dateinamen.
Alles ist ein Pfeil.
Tatsächlich, fast alles.
Aber was bedeutet das denn?
Vielleicht müsst ihr ja kennen.
Also du Zeiger drauf hin und dann kannst du darfst losrennen.
Nee, du hast nicht.
Nee, das ist ein Pfadnamen.
Das ist ein Pfadnamen und dann öffnest du die Datei und anstatt, dass du da Dateien, dass du Daten von der Festplatte liest, kriegst du halt Daten von irgendwo her anders geliefert.
Zum Beispiel CPU-Auslastung oder zum Beispiel Netzwerk-Sockets oder zum Beispiel sonst irgendwas.
Das ist zumindest die Idee, ja.
Dass wenn du halt den richtigen Pfad auf eine bestimmte, auf eine bestimmte Datei hast, ja, ist gar keine Datei, sondern ein Socket an irgendeinem Punkt.
Also Netzwerkverbindungen sind auch nur Files, irgendwie Geräte sind auch nur Files.
Du kannst halt zum Beispiel irgendwie eins 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.
Ja, und dann kann man irgendwie dem Programm beim aus dem Lautsprecher tröpfeln zuhören.
Und solche Dinge.
Weil das ist auch nur eine Datei.
Ja, also unter Windows oder MS-Dos war das halt, das ist halt irgendwie, weil das war zu aufwendig.
Also 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.
So reservierte Namen, du darfst keine Datei haben, die Com1 heißt.
Auch in der 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 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, eine bestimmte Stelle spulen.
Man kann aber wahnsinnig viel damit machen.
Die ist halt total tief.
Also die ist halt schmal und tief.
Das ist mal gut für eine API.
Also schlechte Apis, äh, worüber reden wir gleich?
Breit und flach.
Breit und flach.
Breit und flach.
Was könnte ein Beispiel von einer sehr breite, sehr flach sein?
So, die so, weiß ich nicht, zum Beispiel Java-APIs irgendwie für Pfeil lesen, ne?
Die sind halt scheiße.
Die sind halt irgendwie, du musst halt tausend Klassen kennen und die konfigurieren und die ineinander stöpseln.
Und willst eigentlich nur ein Pfeil lesen, ja?
Und das ist halt irgendwie, ach, und ja.
Genau.
So sozusagen, also das ist halt, also Leute sagen mal, das ist wirklich schön, ne?
Das ist eine schöne Abstraktion, das hat super funktioniert.
Genau, man kann halt sagen, aber ein kleines Problem, es gibt ein 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 nichts?
Du musst da irgendwie Daten reinstopfen oder so eine Spule bauen.
Nee, das ist halt so ein bisschen, ja, das ist.
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.
Ich glaube, ich verlinke, dass man den schon.
Ja, bitte, bitte.
Den kenne ich auch noch nicht.
Ja, der ist schon relativ alt inzwischen, der ist von 2014 oder so.
Aber ja, ist immer noch genauso wahr wie damals.
Er wird sich wahrscheinlich auch nie ändern.
Ja.
Das mit dem Audio muss ich auch mal ausprobieren.
Kann ich auch nicht.
Direct von Bash auf der Audio.
Genau, was auch, äh, C-Python benutzt jetzt auch Pre-Commit.
Ah, auch nett.
Pre-Commits sind die Hooks, die den Code automatisch.
Genau, also so blinden oder.
Ja, also du kannst halt mit Pre-Commit irgendwie diverse Regeln aufstellen, die halt erfüllt sein sollen, damit jetzt.
Also zum Beispiel Black-kompatibel oder ich weiß nicht, weil bei CPython ist jetzt ein RNC, also irgendwie.
Jammel-Syntax gecheckt wird oder das andere.
Weiß ich nicht, das kann zu falls zu groß sind.
Weniger Bugs, für das du weniger Bugs.
Vielleicht.
Naja, du kannst damit auch zumindest irgendwie relativ hart sicherstellen, dass bestimmte Regeln eingehalten werden.
Machst du Pre-Commit bei deinen Projekten?
Ja.
Auch mit MyPy?
Ja.
Aber ja.
Mach ich auch.
Also ich mache Ruff und MyPy und Icehort und Black und PiUpgrade und sowas.
Ja, mache ich auch.
Also bis auf Ruff, das benutze ich nicht, weil ehrlich gesagt, wenn man MyPi verwendet, ist es so langsam, dass alles alles egal ist.
Aber cache MyPi nicht nach dem ersten Durchlauf?
Ja, mag sein.
Ich weiß, ich habe immer die Erfahrung, dass immer, wenn ich dir denke, so, ich hab doch jetzt auf diesen Knopf gedrückt.
Doofes PyCharm.
Warum reagiert dieser, dieser Knopf ist ausgegraut und irgendwas tut es?
Und dann gucke ich hier hoch so und sage ich, ah, CPU-Auslastung ist hoch.
Dannke ich mir so, PyCharm.
Und dann denke ich mir, nein, MyPi.
Und es dauert einfach lange.
Also MyPi muss man ja irgendwie die ganzen Dependencies da irgendwie mit angeben.
Dann fürchter
dich alles.
Ja, weil das halt in einem eigenen Virtual Env alles stattfindet.
Ja, aber warum und warum.
Kann das das nicht selber raffen aus der Pi-Project Hummel oder sowas, wo man deine Dependencies hat oder wo auch immer die liegen oder also ich finde
es auch schon.
Ja, 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 damals mit.
Ja, vielleicht, ich weiß es nicht.
Aber es ist auf jeden Fall nicht so.
Aber C-Python benutzt es jetzt, also es erhöht die Wahrscheinlichkeit, dass es nicht weggeht.
Das ist gut.
Ja, also dass sich jemand findet, der das dann halt weiter maintained.
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, äh, also, ähm, 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, das mir eine, wenn so ein langes, so eine lange Liste oder irgendwie ein langes Iterable kommt, was mir das halt so in Badges zerlegt, mit denen, wo ich dann mit den Badges irgendwas mache.
Brauch ich immer.
Also dass das halt da, wo du am Ende wieder zusammenfügst oder so.
Nee, einfach in Stücke hacken.
In vierer Blöcke, in achter Blöcke, in zwölfer Blöcke.
Genau, weil du willst halt zum Beispiel irgendwie alle C willst immer 100 Dinger gleichzeitig in die Datenbank oder immer in 100er Blöcke in die Datenbank schreiben.
Oder ausgeben.
Oder ausgeben oder sonst irgendwie was machen, aber du willst es halt nicht jedes Mal machen, sondern halt immer so, genau, also ich brauche das irgendwie immer und hab dann irgendwie so, bei mir heißt diese Funktion meistens so chunked oder sowas.
Und jetzt gibt es eine in Intertools, die heißt Batched und die macht genau das.
Ist die neue?
Die ist neu, ja.
Okay, ich dachte, da gäbe es also was ähnliches.
Ich hab's
mal gehört.
Also man kann auch mit Zip oder mit Iceleis,
wenn man das bauen hat.
Aber ich meine, Batched ist neu.
Ich habe irgendwie
letztes Jahr bei mir auch immer eine geschrieben.
Advent of Code-Varianten irgendwie sowas.
Würde ich mal nachgucken.
Jeder hat sowas schon mal geschrieben.
Ja, also da ich das irgendwie immer brauche, ist es gut, wenn das jetzt in der Standardbibliothek ist.
Hast du das reingebracht, Johann?
Nein.
Aber irgendwie, ja, ganz in meinem Sinne.
Ja, ja.
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.
Aber es ist halt sowas 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 En funktioniert nicht, weil es sagt halt so, ich kann dieses Wheel nicht bauen.
Von irgendeinem von irgendeiner Abhängigkeit.
Und dann habe ich also reingeguckt, ja, warum kann es das nicht bauen?
Ja, weil irgendwie Dist-Utils vielleicht fehlen manchmal, weil Dist-Utils sind Disintegrecated.
Aber wenn man Setup-Tools installierst, dann kommen die alten Dist-Utils quasi mit und dann geht's wieder.
Und genau, ach so, und früher wurde das automatisch in VNV, wenn man per Venf irgendwie einen Virtual-Entw erzeugt hatte, wurden Setup-Tools direkt mitinstalliert.
Und das passiert nicht mehr.
Also das ist auch nicht mehr drin.
Also auf jeden Fall, 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 Pi-Project-Thommel mitbringen, aus der dann sozusagen steuert, wie den Wheel erzeugt wird.
Das geht nur noch, wenn Pi-ZMQ installiert ist.
Keine Ahnung warum.
Was ist denn Pi ZMQ?
Irgendwas mit einer Messaging-Queue.
Okay.
Hätte ich jetzt
nicht mit Wheels in Verbindung gebracht.
Ja, ich auch nicht.
Deswegen hat es mich gewundert.
Und zwar auch 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 es noch.
Also keine Ahnung, was da genau das Problem ist, aber naja.
Vielleicht installiert das irgendwie eine Subdependenzieh auf die irgendwie hidden.
Ja, kann ich auf jeden Fall nicht.
Genau weiß ich jetzt nicht von, aber das ist halt etwas, worüber das 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 ja zu alt.
Wahrscheinlich ist das irgendein Fehler im Configure-Skript oder so.
Und wenn man dann OpenSSL 1.1 entfernt und dann geht's.
Das möchte man ja eigentlich.
Ja.
Habe ich jetzt auch.
Ich dachte dann, wenn man sagt, entfernt es mal, dann hat es mir gesagt, irgendwie ganz viele Pakete, die drauf basieren.
Unter anderem sowas wie T-Max und so und diverse andere Geschichten, Image-Magik, Libhive, so Sachen, wo man sagt, das kann ich nicht deinstallieren.
Das ist da wiederum dependet zu viele andere Zeugs drauf.
Wenn man das alles deinstalliert, dann OpenSSL 1.1 entfernt und dann das nochmal installiert, dann linkt es halt gegen die richtige OpenSSL.
Ja, gut.
Also wahrscheinlich ist er auch wieder ein Fehler in irgendwelchen Config-Skripten von.
Das ist doch ein Mac-Problem, oder?
Kauft euch meinen richtigen Fehler dafür.
Ja, kann schon sein.
Genau.
Jetzt haben wir aber tatsächlich so ein bisschen News, also nur von 13.12 gemacht und ich glaube, wir müssen mal zum Thema eine neue Folge sonst irgendwie auch machen mit News-Python 3.12.
Wir machen mehr News.
Ja, also eigentlich wollten wir ja über Kybernetes reden und ich glaube, wir hatten jetzt so eine neue Markierung und haben die ganzen News jetzt, wenn ihr noch dran seid und Kriminiten wollt.
Oder über Sprung habt ihr Kubernetes 12 ist schon auch relevant, muss ich sagen.
Ja, das stimmt natürlich.
Ja, also die anderen News dann später.
Wir haben immer noch.
Haben wir noch welche?
Nee.
Nee, gut.
Ich nicht.
Gut, dann spreche jetzt über Kubernetes.
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 es ist so ein bisschen das, also ich glaube, wenn man sich das so vorstellt, dann laufen halt so bestimmte Boote, also Pots, so Container halt auf dem.
Containerschiff sozusagen.
Genau, aus dem, ja, oder ich weiß nicht, ob das ein Schiff ist.
Vielleicht sind 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 anstellen kann.
Also das ist ein Bild, was ich nicht in den Kopf kriege, aber.
Okay.
Man kann es sicherlich so betrachten.
Was ich auch schon mal, ja, du sagst, verteilte Runtime für, man könnte auch sagen, vielleicht ein Betriebssystem für eine Gruppe von Rechnern irgendwie?
Ja.
Dass man halt quasi einen, die kann man dann wie ein Ding ansprechen, obwohl es halt viele Rechner sind.
Das finde ich tatsächlich gar nicht so wichtig da drin, sondern das Wichtige daran finde ich eigentlich, dass das weggeht von dem imperativen Modell, was man ja so bei den, also wenn man Ansible macht, ja, 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, ja.
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 vielleicht auch noch so einer der Zwecke, die Kubernetes am meisten irgendwie verwendet wird, dass du halt irgendwie so ein Loadbalancing machen kannst und halt Container Orchestration.
Genau, dass du so skalieren kannst in horizontale Richtung, wenn du mehr Last kriegst oder sowas.
Und dass du vielleicht so wie dieses machen kannst.
Das eine 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 so ein bisschen wie bei einer Datenbank, ja.
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.
Sorg 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 nimm 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 zwei meine Datenbank, fünf meine Anwendungen.
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.
Du schreibst eine Bauanleitung von Lego mal.
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.
Und das beschreibt auch so ein bisschen das System, ja.
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, dann musst du irgendwelche Node-Gruppen machen und musst irgendwelche Verteilungsdinge machen und Affinitäten und Netzwerk, was weiß ich.
Und mit Kubernetes sagst du halt einfach, ja, 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, so, 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 einstellen kann.
Aber im Endeffekt ist es, wenn man das, also aus Anwendersicht, ja, aus Workload-Betreibersicht, ist es schon was relativ Simples.
Du sagst halt, du beschreibst halt, wie deine Workloads auswählen sollen, was du gerne am Laufen haben möchtest.
Und auch wie viele, ja.
Also wenn du so ein System hast, wo du 100 Nodes hast oder 1000 Nodes, ja, dann ist es leicht zu sagen, ich brauche jetzt 100 von diesen Frames oder 200 von diesen oder da ist jetzt gerade Last drauf, also mach die bitte hoch oder wieder runter.
Naja, das klingt manchmal sehr, sehr charmant, wenn man das einfach so, wenn man sagen kann, okay, ich abstrahiere von den konkreten Maschinen irgendwie.
Da können unten können halt irgendwie Leute immer neue Maschinen in irgendwie Racks stecken und mein Cluster wird halt größer.
Wenn ich das drauf installieren und den als Node deklarieren.
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.
Weil auch, wenn du, also das Lustige ist ja ja, das Argument gibt es ganz oft, Google macht das, also machen wir das auch.
Oh je.
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 braucht man einen Kubernetes-Cluster.
Ja, genau.
Also wir haben hier zwei Server, dann mach doch mal einen 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-VM starten oder andere VMs, ja.
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 sagst du einfach, hier ist euer Quota und hier ist euer Quota und hier ist euer Quota.
Und ihr dürft darauf starten, was ihr wollt, solange ihr in eurem Quota bleibt.
Was ist ein Quota?
Also ein Anteil von Rechenkapazität von euch.
Genau, also du kannst Accounts, also es ist natürlich alles viel komplizierter, als es sich anhört.
Weil genau wie bei Datenbanken, ja, 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.
Oder abschießen können.
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 Gefühl, zu 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 die, die.
Also ich hatte immer noch die Schmerzen, als ob mir jemand auf die Füße getrieben hätte.
Aber ich kann die nicht mehr sehen, die das waren.
Ja, genau.
Keine Operation gibt es wohl.
Eine Administrationsgruppe, die dann trotzdem alles da.
Und die Geisterkondine hatte das putzen und sauberbar.
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 eine Quota, das heißt, die dürfen eine bestimmte Menge CPU anfordern und eine bestimmte Menge RAM 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, ja, dass du halt sagst, okay, wir brauchen aber mehr und es geht nicht mehr.
Nur das Problem hattest du vorher auch, ja, wenn du hier die drei Server hattest und die sind halt voll.
Ja, kannst du nicht.
Bis dir höchstens noch selber dran schon.
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.
Ich meine, wie alle Abstraktionen so ein bisschen.
Also zum Beispiel etwas, was halt irgendwie, ich meine, keine Ahnung, vielleicht gibt es auch irgendwie eine tolle Lösung für, aber was ist halt, 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 Klasse dir so, äh, ja, du hast jetzt hier schon keine Bricke, das Kind nicht.
Das heißt, du überlegst dir dann so, okay, naja, also eigentlich braucht der dieser Kante braucht ja gar nicht so viel.
Das ist auch nicht.
Dann setzt man die Ressourcen da runter.
Ja, da hast du zu wenig Ressourcen gemacht.
Und dann kann man deine Quota zu nötig machen.
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.
Und das ist halt
nicht so nett irgendwie.
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 und aber auf keinen Fall mehr als so viel.
Manchmal brauchst du es halt aber doch.
Und diese Worte bedeuten auch nicht das, was sie bedeuten, sondern dieses Requests, wenn du zwischen dem Requests und dem Limit bist, dann heißt es, dass Kubernetes diese VM abschalten darf.
Weil du ja über dem Requests drüber bist.
Du bist über das, was du angefordert hast.
Diese Worte bedeuten halt nur, wenn du übers Request gehst, darf Kubernetes deinen VM abschalten?
Bei Limit muss es die VM abschalten.
Und das heißt, es darf halt dann, wenn andere anfragen, ob sie neue Ressourcen haben können und es keiner Freien mehr findet.
Ja, beziehungsweise, wenn du über dein, also es gibt zwei wichtige Kenngrößen, ja, CPU und Memory.
Und 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 Requests.
Das heißt, wenn du sagst, meine Anwendung verbraucht 500 MB Hauptspeicher und maximal 1000, dann kannst du auf einen Rechner gesetzt werden, auf den Knoten gesetzt werden, wo 500 Megabyte frei sind.
Weil dann ist deine Anforderung erfüllt.
Du hast gesagt, ich brauche 500 Megabyte 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 Megabyte angefordert hat und du halt aber mehr als deine 500 Megabyte verbraucht hast, weil du zwischen Requests 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 hast, darfst du dann halt nicht haben.
Beziehungsweise Spitzen hast du ja dadurch abgedeckt, dass du sie.
Das kenne ich auch, aber das Problem ist halt, dass du nicht so gut.
Das kann man aber auch nicht irgendwie schlafen.
Und ist auch nicht schlau, ja.
Eigentlich willst du ja, dass dich diese Wellen so ergänzen kannst du halt.
Und wenn ich jetzt einfach auf einen normalen Rechner sozusagen deploye und ich habe jetzt halt irgendwie, sagen wir mal, zehn Projekte, die alle unterschiedliche Last haben und so.
Und ab und zu brauchen die halt mal so einen Gigabyte-Hauptspeicher oder zwei für irgendwas, weil sie halt irgendwie, zum Beispiel, einen Fall, an den ich gut erinnere, wo das halt echt Kopfschmerzen breitet hat, manchmal stattdessen.
Und du kannst es auch nicht, hast du nicht unter Kontrolle, weil 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 ist einfach alles aus.
Naja, also es kann auf jeden Fall passieren.
Du hast halt, also normalerweise passiert nichts und dann, aber du hast halt FFMPG mit irgendwie so, weiß ich nicht, 200 Zeichen irgendwie komischen Optionen hinten dran und meistens passiert gar nichts.
Und in komischen Fällen manchmal braucht das dann halt zwei Gigabyte Hauptsprecher.
Ist halt so.
Ja, aber solltest du das dann nicht abschießen in dem Fall?
Nein, das ist nicht.
Willst du das nicht bieten in diesem Fall?
Ja, und es ist halt dummerweise sinnvoll und das braucht es halt wirklich.
Und jetzt kann man natürlich dann irgendwie, keine Ahnung, FFM-PEG irgendwie sich angucken und schauen, wo ist denn das Problem?
Aber ja, aber wie geht man denn mit so einem Fall um?
Also wenn ich einfach auf eine normale Maschine deploie, 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, ja, das dauert auch nicht so lange, dann ist es wieder gut.
Weil Kubernetes hat mir das echt, das macht dann echt Kopfschwung.
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, ja, genau, aber dann immer so, also irgendwie kann das doch nicht die Lösung sein, oder?
Ja.
Weil man braucht es ja tatsächlich eigentlich nicht.
Also es ist halt nicht so, dass man.
Also, ja.
Ja, man muss ja eigene Pots starten mit FFM-Pack drin.
Ja, ja, genau, das kann man natürlich dann auch.
Du kannst dann halt irgendwie so dir spezielle, oder das Problem hast du natürlich auch, wenn du Spezialehardware hast, sowas wie GPUs oder sowas.
Ja, gut, klar, die musst du natürlich auch verhindern.
Aber dann geht auch so ein bisschen der ganze Vorteil irgendwie so ein bisschen wieder verloren, weil dann muss sich ja doch wieder um die ganze Konkurrenz.
Die Annahme ist halt, dass du, dass du viele, sag ich mal, gleichbrehige Arbeitslasten hast, wo es nur darum geht, die irgendwie so mehr oder weniger gleichmäßig zu verteilen.
Und dann ist das großartig.
Ja, ist das wirklich.
Aber das Interessante, was ich, als ich Kubernetes gelernt habe, war, dass sich da so die Denke so ein bisschen verändert.
Genauso wie wenn man SQL lernt, ja.
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.
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, nee, macht Kubernetes.
Du löscht dir einfach.
Du sagst, 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.
Und deklarativ ist halt, diese Maschine soll jetzt bitte entfernt werden.
Ja.
Das war auch so ein paar Probleme, ne?
Also, was das halt auch kann, ist irgendwie so Rolling-Release dann halt irgendwie, du hast halt mehrere Versionen von einer Software, die dann live ist, weil die halt einfach.
Das ist ja eine wundervolle Sache, oder?
Ja, genau.
Also du hast keinerlei Verzug mehr zwischen neuer Versionen, also gefühlt und 10% laufen noch auf der alten Version oder schon auf der neuen.
Und dann schalten die ab, wenn die Prozesse irgendwie fertig sind, alte Maschinen ab und neu halt irgendwie rein.
Aber das ist ja auch irgendwie ein bisschen blöd an
verschiedenen Stunden.
Also ich.
Ja, aber es ist doch eine großartige Sache.
Es gibt einen großen super Artikel zu Blue Green Deployments mit Django.
Da hast du.
Wird in den Shownotes erscheinen.
Wo du halt ganz arg darauf achten musst, dass du deine Datenbankmigration so machst, dass du quasi bei jedem Übergang beide Versionen betreiben kannst.
Das ist ja genau das Problem.
Was machst du eine Migration in Django?
Und dann ist er irgendwie eine Stadt.
Ja, fällt in der Tabelle auf einmal ein neues
steht dir ja frei, das anzuhalten und dann die Migration zu machen und dann neu zu starten.
Das darfst du ja machen.
Ja, aber bevor
ja so neu ist, aber ich kann keine Frage.
Das ist ja kein Problem.
Also Problem ist halt eher, wenn ein Zweckfällt oder so, ne?
Aber wie gesagt, dieser Mechanismus kannst du ja immer noch machen.
Du kannst ja alle anhalten und Skabulation machen und alle nachstarten.
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, ja.
Ich wusste diese Worte auch nicht.
Rolling Release heißt, dass wenn du zum Beispiel fünf 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 und nach und nach die neuen Zuschauer.
Dass halt immer eine gleichen Lasse erstanden ist, genau.
Dann eine neue hochfahren.
Und erst wenn die neue hochgefahren ist, wird die nächste Geschichte.
Das heißt, du hast keine Situation, wo du keine Available
erreicht hast.
Ja, genau, aber da ist ja so ein Problem.
Wenn die Postgres da ein Getkauf kriegt mit einem neuen Feld,
das muss halt deine Software dann können.
Und das ist nicht immer so einfach.
Ja, also aber das kannst du auch mit Ansible machen, oder dieses Problem hast du natürlich sowieso auch.
Mit Ansible ist es natürlich schwierig, weil es ist schon eine komplizierte Operation.
Ja, aber na 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 neuen halt 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, genau, 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 die migrierst immer länger, bis dann irgendwann abschalten kannst, dann kannst du auch hier nur noch die neuen und 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, ja, 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 ja auch nicht so gut.
Du fragst auch.
Wenn du den
Load-Balan einfach von an auch wieder.
Also wenn ich bei mir irgendwie ein neues Deployment mache, habe ich Zero Downtime.
Du machst halt den Downtime in der Mitte.
Du machst einen alten System läuft.
Dann fährst du das neue System hoch.
Ja, gut, das ist ja Blue-Green.
Und dann zeigst du aber dem Load-Balancer einfach aufs Ordnungsystem.
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 Load Balancer bitte allen Traffic auf Blue.
Und dann startest du den System, ein komplettes, was Green hat als Status.
Und wenn das fertig da ist, sagst du dem Load Balancer jetzt umschalten auf Green.
Diese Technik, die ihr beschreibt, heißt Blue-Green-Deployment.
Also ich weiß, es gibt nicht.
Das 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 auch
ungeheuer viel Arbeit und die machen ungeheuer viele Probleme.
Also dieser Django-Artikel über Blue-Green-Deployments, der 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 Migration und dann starten wir es einfach wieder noch.
Es gibt da noch ganz viel schönere Ansachen.
Weil 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 er halt klar ist, dass das Update geht und der nicht direkt neue Sachen baut, dann kann er sein, dass neue Versionen bauen, anders ist als auf ein altes System Update setzen und dann muss er halt erst alte bauen und dann das neue abbauen.
Und wenn man dann sowas macht, wie weiß ich, neue Environments oder Sequels dazu und die es beim Anfang noch nicht gibt, aber am Ende dann schon, dann muss halt quasi, oder halt welche entfernt halt, ne, größeres Problem, dann sind die halt auf einmal weg beim 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.
Wieso?
Also die allermeisten Projekte und Teams und Unternehmen können doch auf, können doch eine Minute Downtime hinnehmen.
Ist doch egal.
Ja, aber du hast
Service-Level Agreements hast, wo five Level Hinz alle so,9 Prozent.
Das war ein Service-Level Agreement.
Ich garantiere mindestens 55,55% Abteil.
Hauptsache viele Hauptsache.
Hauptsache viele Digits.
Nee, das ist eben die Sache, ja, das ist diese Krankheit.
Man kann das machen, aber muss man das machen?
Und bloß weil das.
Und klar, das ist so vom Engineering her ist das schon cool, ja.
Hast du eine Woche Arbeit reingesteckt, um ein Update zu machen?
Und dafür hast du, hast du 100% Availability.
Großartig.
Ja, muss sich dann halt lohnen, sich das.
Ja, genau.
Es gibt Fälle, wo das so ist.
Ja, klar, es gibt Fälle, in denen das so ist.
Und aber, also ich meine, wie viele Engineering-Stunden sind eine Minute Downtime-Wert?
Oder zwei Minuten oder fünf Minuten oder zehn Minuten.
Ja, 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 hätte 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 also 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 wegabstrahieren kann.
Aber Jochen
Google scheint das ja auch.
Du kannst ja einfach ein Managed Manitis-Cluster kaufen, dann kannst du einfach zwei Pots hochschreiben und da kannst du so einen Schieberegler in deinem Webinterface einstellen, der sagt dann sieben Pots von 8 bis 10 Uhr und Load
Balanced, also wenn die CPU-Auslastung über 50% steigt, dann skalierst
du hoch.
Okay, es kann sein, dass man das heutzutage alles nicht mehr braucht, aber was wir zum Beispiel damals hatten, so auch bei diesen Load Balancing-Geschichten, ist halt sowas, was ist denn jetzt, wenn dann dein Netzwerkkonnektivität asymmetrisch ist?
Und du kannst halt so viel Traffic.
Ja, genau.
Du musst ja alle gleich behandeln können.
Ich wollte erstmal bitte wieder kurz erklären, was das denn bitte nicht ist.
Du hast halt so eine natürliche Asymmetrie in dem Verhältnis von, wie viele Daten kommen rein, viel gehen raus bei Web.
Weil es kommt halt einfach viel weniger rein, als rausgeht.
Ja.
Also ein Request ist viel kleiner als die Antwort auf einen Request.
Antwort auf einen Request ist viel größer.
Üblicherweise, ja.
Üblicherweise ja.
So, das heißt, genau, dieses, deswegen haben wir das bei DSL, also wenn man halt sich überlegt, okay, wie kann ich denn jetzt das halt noch okay aussehen lassen, obwohl es eigentlich nur Klingeldraht ist, dann macht man das halt so asymmetrisch.
Und auf der anderen Seite hat man diese Asymmetrie aber auch.
Und das kann man dann jetzt dann halt zum Beispiel so nutzen, dass man dass man halt irgendwie das rausgehende Interface ist halt einfach viel dicker als das reinkommende.
Weil reinkommen tut ja nicht so viel.
Und dann kannst du zum Beispiel auch so, also wenn du jetzt so viel Traffic hast, dass du den eigentlich gar nicht mehr load balancen könntest, weil das ist zu viel für, damals war das halt ein Gigabit oder so, mehr war halt kriegte man halt nicht hin.
Und ja, so, heute geht wahrscheinlich ein bisschen mehr, aber so, das geht halt nicht.
Dann ist es aber kein Problem, weil ich muss ja nur den reinkommenden Traffic load balancen können.
Und der rausgehende Traffic, der geht halt dann über so ein Fake-Interface raus und das landet dann halt alles irgendwie.
Und das kann halt deutlich dicker sein, das ist dann kein Problem.
Und also sowas geht dann ja alles schon nicht mehr.
Das kannst du gar nicht mehr machen.
Weil also du musst ja dann alle gleich behandeln können.
Und der Load Balancen geht ja auch nur so, dass, also es kann ja nicht so sein, dass beim Load Balancing, oder ich denke mal, so in Kubernetes kann es ja nicht sein, dass die Pakete über den einen Weg rein und auf den anderen Weg rausgehen oder sowas, was man ja an der Stelle gerne halt.
Ingressen 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.
Das ist kein Problem.
Ja, Netzwerk hast du immer genug.
Ja, genau.
Das glaube ich nicht.
Also, dass das keinen Unterschied macht.
Ja, also okay, ich weiß es nicht.
Aber ich hab so den Verdacht, dass das dann doch vielleicht irgendwann liegt.
Ja, aber erölt und.
Eine sehr schöne Sache ist halt, dass du wirklich diese Trennung hast zwischen als Softwareentwickler bin ich ein Anwender von dem System.
Und ich kann einfach den Betrieb des Systems wegdelegieren.
Und ich kann sagen, hier, ich gehe zu Amazon und Kaufmann und Managed Kubernetes Cluster.
Oder ich gehe zu Azure und Kaufmann und Managed Kubernetes Cluster.
Und dann ist es sehr einfach.
Ich kann dann einfach sagen, hier sind meine Workloads und sorgt bitte dafür, dass das läuft.
Und brauche mich darum einfach nicht mehr kümmern.
Und 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.
Das 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, ob ich das nicht mehr so gut habe.
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 Compute-Größen sehen und wie viele Milli-CPUs du da brauchst.
Das ist schon für, aber wieder ja, wieder für ein Unternehmen einer gewissen Größe.
Ja, ja, klar.
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 paar VMs starten möchte.
Das mache ich halt händisch, ja.
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 sich es einfach nicht lohnt, weil die Last nicht groß genug ist, weil die in Homogenitä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.
Ja, es gibt ja ganz viele Workloads, die sehr compute-havy sind.
Wir hatten mal so ein, 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.
Und eine Möglichkeit, die du hast, ist halt, das zu verteilen.
Dass 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 Host-Adresse zu hinterlegen, sondern 100.
Und dann auf diesen 100 Hosts oder 1000 IP-Adressen zu hinterlegen, ja.
Und zu sagen, starte bitte auf allen diesen Rechnern in diesem Inventory diese Workload.
Da brauche ich keinen Kubernetes dafür.
Ja, aber die müssen ja trotzdem irgendwie das IO, Adobe kommen, das halt alles her.
Ja, gut, klar, das musst du dann immer noch managen, aber das ist dann bei allen gleich.
Und das ist das, worauf ich raus möchte.
Wenn du 1000 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.
Und das muss man nochmal genau erklären.
Also vielleicht so ein reales Beispiel mit.
Und am besten, 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 Alterungsverrottungsverwirrungsstufen auf verschiedenen Teams, weil dann, sodass du halt nicht sagen kannst, ah, ich deploy das jetzt auf eine homogene Geschichte, sondern dass du sagen musst, das geht nur mit Docker, das geht nicht anders, weil das halt einfach zu unterschiedlich ist.
Ja, und du musst kontrollierisieren.
Ja, das alle nach Docker, nur du willst es machen.
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, aktuelles NixOS und da habe ich hier ein Debian und das muss ich aber alles gleich auf dem gleichen Cluster.
Java 17 und 18 und 21 und 8 und 2.
Ja, und für alte Sachen, weil ich da sind alle Programmierer schon gestorben, da muss ich das muss ich aber weiter betreiben.
Deine Cookie-DockerVM.
Ja, ja, okay, okay.
Dann ja.
Eine AS400 DockerVM.
Ja.
Ja, also das ist.
Also nochmal an den Fall bitte noch einmal, du wolltest kurz das nochmal erläutern.
Also was denn da.
Also wir haben jetzt verschiedene Sachen, die ganz heterogen sind.
Okay, aber
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 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 da VM starten dürfen.
Und zwar egal, welche sie wollen.
Und klar, wenn du 5000 verschiedene 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.
Genau, 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 und du willst, dass sie möglichst nah aneinander dran sind.
Aber wo die dann laufen.
Ich hätte gern mehr, diesen Schalter, den muss doch, der muss doch, ich hätte gern mehr Netzwerklatenz, das ist doch immer gut.
Größere Zahlen, besser, mehr Netzwerklatenz hinter meinen Microservices.
Das muss einfach, das muss doch, das muss
Spaß machen.
Ganz ehrlich, für mich als Anwendungsentwickler ist es auch völlig egal, wo das läuft.
Solange das halt läuft.
Ja, ja.
Na, also ich weiß nicht.
Ich habe halt doch so, also von der Erfahrung her würde ich, also ich gibt halt Infrastruktur, die gut funktioniert und 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.
Hätte ich gesagt, zum Beispiel.
Oh Gott, das hört sich so an wie.
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üh.
Oh, ihr könnt wissen, wo deine Programme laufen.
Nee, ja.
Also früher hätte ich gedacht, also Prozesse, so beim Softentwickelprozesse ganz wichtig und das total, wenn man jetzt richtig macht, dann ist das voll gut.
Und wenn man es falsch macht, dann ist halt alles eine Katastrophe.
Und irgendwie Engineering total super, wenn man da 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 aus der Zeit von der Zeit her geschuldet, weil man hatte nichts Besseres, ja.
Also ich, wie gesagt, wir hatten ja nichts.
Also ich habe mich daran erinnern, ich dachte, vielleicht besser nicht bei wem, 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.
Das hat richtig, auch mit richtig vielen Nachstaaten.
Da habe ich selber ein Proto-Kybernetes gebaut.
Das war kein Kubernetes, das war irgendwie, und die Shell-Skripte waren auch teilweise so ein bisschen.
Aber es war, das hat richtig gut funktioniert.
Und ich habe auch schon Kubernetes gesehen, auch große Infrastruktur, 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 darum kümmern muss, sondern ein Großteil des Teils, also ein größerer Anteil der Zeit, als ich mir oft hätte, musste 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.
Da musst du bestimmt ranchern oder so.
Ja, genau, weil du es nicht darfst.
Weil du es nicht sollst und deshalb darfst du es auch sagen.
Ja, und dann versucht man mit den anderen zu reden, die verantwortlich sind und dann denkt man sich so.
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 das ja ein Feature.
Du willst die Leute nicht zu nah an die gefährlichen Dinge ranlassen.
Also lieber schlecht betrieben als gar nicht betrieben.
Operation Schlüssel noch.
Also einfach so, also 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 in den Raum warm kriegen, ja.
Während halt irgendwie, also keine Ahnung, dann irgendwie, weil 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 dann besser sein, wenn man ein besseres Tool hat, wenn man halt für die falschen Leute zu steuern.
Ja, das ist aber so ein bisschen Tautologie, oder Jochen?
Also die guten Leute kriegen Dinge gut hin und die schlechten Leute kriegen Dinge schlecht.
Ja, aber ich glaube, das ist halt aus so einer 10.000 Fuß-Übersichtsperspektive, sieht das halt zu einfach aus.
Das sieht halt so aus, wie wir machen das, was die alle, was alle machen und das funktioniert halt schon.
Wir haben auch viel Geld ausgegeben jetzt.
Muss das auch gut sein.
Ja, aber vielleicht funktioniert es auch nicht.
Und zwar aus anderen Gründen, als man jetzt sagte.
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 das läuft.
Ja.
Und dann.
Der Rest ist ja egal.
Der Rest ist mir egal, ne?
Du hast ein Pastierschatten, dass es dafür verantwortlich ist.
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, ABS.
Ja, aber okay.
Okay, ja, die können das wahrscheinlich sogar.
Azure, ja, das ist genauso.
Da habe ich halt schon häufiger gehört, dass das vielleicht dann.
Kriegt man bei Google Compute oder bei Google Cloud, kriegt man da auch Kubernetes Cluster?
Okay.
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, dass da waren Leute auch nicht so etwas unter Underware.
Dann setzt du halt bei dem großen Azahl auch den Premium-Preis.
Der ist schon alles nicht günstig, aber es ist halt die Frage, wenn man das eh bezahlen kann, egal.
Ja, möchte vielleicht noch einen Manager haben, der vielleicht nicht so technisch affin ist, der Loadbuddings 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 Centern und hin in die Cloud, ja, das ist ja das Versprechen der Cloud, dass das 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 es immer billiger ist, in die Cloud zu gehen.
Ganz im Gegenteil.
Aber es ist der Trend gerade.
Es ist der Trend weg vom eigenen Data Center.
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 da quasi.
Ja, natürlich für Geld.
Und danach kannst du vielleicht wieder hingehen und kannst wieder lokal machen.
Aber diese Fortentwicklung quasi, dass halt diese ganzen heterogenen Teams alle abgelöst werden müssen durch was Neues, da verlierst du natürlich nur how du kannst halt so Prozesse, Skaleneffekte erzeugen irgendwie und dann vielleicht doch merken, wo du halt was nicht mehr so brauchst.
Ich weiß nicht.
Also dieses Skaleneffekte erzeugen klingt ganz falsch.
Ja, das hört sich immer gut an, das hört sich unsere Businesspräsentationen.
Warum funktioniert das wirklich?
Also da habe ich so manchmal.
Ich glaube tatsächlich, dass so eine Costcenter-Frage ist.
Naja, aber ich glaube schon, also du kriegst halt die Leute dazu, dass die dann das alles gleiche machen müssen.
Da fährt halt dann vier Hunden runter, was du halt vorher gemacht hast, selbst wenn es gut war, möglicherweise, ja.
Aber du hast alle auf dem gleichen Stand.
Also du würdest sagen, der kleinste gemeinsame Nenner ist immer noch besser, als wenn du.
Nein, das würde ich nicht sagen.
Das kann notwendig sein für bestimmte Dinge halt.
Also auch überhaupt für eine Bewegung, weil das Problem ist ja, dass du gerade in so Konsensus tun oft so Silos hast, die sich halt bilden, die politisch sind und die sich nicht mehr aufbrechen lassen, außer mit Gewalt.
Und das ist halt eine der Methoden.
Wenn du Benetis dagegen ankommst.
Ja, soziale Probleme mit Technik lösen.
Bewerbungsherdensilen.
Das Prinzip funktioniert immer super.
Ganz genau.
Du hast diese Silos halt tatsächlich aufgebrochen und du brauchst halt dann tatsächlich, musst du halt wieder von vorne anfangen.
Du kannst das wieder neu bauen.
Ja, es kommt wahrscheinlich drauf an.
Aber also 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 wegen gibt, dass es dann besser ist als das, was vorher da war und dass man diese Recht.
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 du da mehr machen kannst, als du vorher machen kannst.
Weil du halt 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 nach Stack Overflow 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 Netzwerkkram auskennt.
Und das kannst du nie, dieses System kannst du in keine Cloud deployen, weil die hat halt die Hardware nicht.
Und auch nicht, die haben auch nicht die Kenntnisse über die über das, was man da.
Ich kenn das nicht, willst du damit sagen,
bei bestimmten Sachen, die man da dann sieht, wenn die irgendwie so ein Redis irgendwie in den Nisch dahin hängen, dann müssen manuell hingehen, dann musst du eine halbe Stunde warten, weil irgendjemand da runter rennt und das Wack reinschiebt oder so, ja.
Ja, das ist dann vielleicht noch viel schlechter als.
Ich glaube auch Stack Overflow ist inzwischen tatsächlich irgendwie irgendwohin in irgendeine Cloud umgezogen.
Insofern kann ich das auch vielleicht nicht mehr als Beispiel als
nicht mehr das beste Beispiel haben.
Aber sagen wir, so für viele, die halt unterhalb der irgendwie Google-Große sind oder weiß ich nicht, konzernpolitische Probleme haben.
Gibt es so kleine
sein, dass manchmal vielleicht der ein oder andere manchmal sowas gesehen hat.
Was mich ja auch noch interessiert, ist, ich meine, hey, da haben wir jetzt so ein Managed Kriminalist-Cluster irgendwie gemäß, aber wie kriege ich denn vom Entwickler den Pott 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 deployt oder auf einem Brand.
Da gibt es verschiedene Möglichkeiten.
Also ich meine, du kannst es natürlich prinzipiell manuell machen.
Yay.
Großartig.
Ist auch genau der Verwendungszweck.
Ja.
Völlig automatisch.
Wenn man bitte hier diesen Pott bitte neu.
Oder du hast ein CI-System, ja, was das dann heute
pusht, du hast ein CI
System Jenkins-System oder du hast ein was weiß ich-System.
Wo kriegt man das CI-System her?
Das auch kannst du auch mieten.
Ja, ach so.
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
irgendeinen CI.
Da gibt es halt tausend.
Egal, genau, gibt es ganz viele.
CI ist noch ein anderer Server, auf dem eigentlich nichts anderes passiert, als irgendwie so ein Diplom-Skript ablaufen.
Ja, es kommt darauf 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
Chatting und dann musst du eigentlich noch irgendwie
also die Integration heißt ja nur, dass du immer eine getestete Version hast.
Und der nächste Schritt ist dann Continuous Deployment.
Delivery, oder?
Delivery oder Deployment?
Ich meine, irgendwas mit D halt.
CD, CICD, 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.
Und sind das nur die automatischen Tests, die durchlaufen müssen oder muss noch irgendwie mal das abnehmen auf dem Button oder so.
Kommt drauf an.
Aber muss noch jemand auf den grünen Knopf drücken oder muss jemand.
Okay, aber das ist ja genau der Baum, da muss halt so verschiedene Systeme dann gebaut werden.
Das muss ja dann irgendwer dann wieder übernehmen und das muss halt dann eigentlich gestartet, also ich würde sagen, ideal wäre es, du hast eine Production Branch irgendwie und du pusht dann irgendwie, dann gibt es eine Action auf deinem GitHub oder auf deinem GitLab, die dann das Ding anstößt
und das ist ja schon sehr viel zu spezifisch.
Das ist viel zu spezifisch für das
viele, kann ich mir viele verschiedene Umgebungen vorstellen.
Wo es sowas nicht geht.
Oder wo du es auch nicht machen darfst oder wo du auch nicht machen kannst.
Oh, wie machen wir es denn dann?
Ja, mit anderen Prozessen.
Jochman hat doch vorhin darüber, dass du Prozesse haben musst und dass das dann, wenn die genügend Prozesse haben.
Ja, aber das ist ja genau der Punkt, da muss er sich irgendwie um kümmern, dann muss er ja das machen, da brauchst du wieder ein Team für, 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 das ja nicht.
Ja, aber
du hast halt Team, genau, und du hast halt jemand, der sich damit auskennt.
Auf jeden Fall muss das ein Entwicklungsteam machen.
Wenn das aber jemand sich damit nicht auskennt, dieser ganze Quatsch irgendwie gar nicht da ist, wie, ja, dann hast du ja selber Probleme.
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 es doch bequem, weil da gibt es ja die Leute schon, die das machen.
Ach, da gibt es die schon.
Ja klar.
Oh ja, wirklich?
Also du bist in der Abteilung, die das macht.
Dann ist sie noch nicht.
Aber dann ist das besser auch irgendwas.
DevOps oder so.
Nee, das ist ja tatsächlich mehr Obs.
Das ist ja nicht DevOps.
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 auch.
Ja gut, aber
das ist die ICD DevOps, oder?
Ja, genau, aber das ist ja in den Anwendungsteams, weil die entscheiden müssen, was zu ihnen haben.
Aber wenn du jetzt nur Devs hast, die kein Ops können, dann.
Ja gut,
aber das musste auf der auf der Scale, wo du so ein 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 ein Managed Gebiness-Cluster und dann haben wir entwickler.
Genau, und dann die Arbeit, das passt schon irgendwie.
Und die vergessen diesen Programm.
Ja gut, das kann auch gut und schlecht sein, ja.
Also 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 sein Quota und dann muss jedes Team die Kosten tragen und ist selber verantwortlich.
Und die Kosten sind aber immer noch da an diesen höher.
Und du hast 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 willst.
Ja, aber dann hast du deinem Controlling die Aggregationsspalte vergessen.
Ja, genau.
Beziehungsweise die ist halt jetzt woanders.
Das ist nicht mehr im Datacenter Kosten, sondern im Development.
Und das ist halt dann möglicherweise eine ganz andere Seite der Bilanz halt.
Ja, aber das ist ja eigentlich vom Controlling her eher so Fail, weil eigentlich müssen ja auch das ja irgendwie erlöst werden.
Aber ich glaube, dass viele auch, solche Fails haben reale Konsequenzen.
Also ob du das jetzt, also genau, es kann sein, dass auf der einen, du zahlst halt, du zahlst halt irgendwie einen guten Teil deines Umsatzes an Amazon oder an Microsoft oder so und das wird verbucht als Investition, die halt, wo irgendwie Geld zurückkommt.
Was auch so.
Also vielleicht.
Beziehungsweise, du könntest viel weniger investieren und könntest trotzdem genauso viel Umsatz.
Und auf der anderen Seite sieht das so aus wie, oh, da das ist halt, das sind halt bloß Kosten, die da rausgehen und
da brauchst du Leute, die da hingehen und ein Gebäude, das sind ja sowieso tote Kosten und dann brauchst du Hardware und was machst du mit dir nach zwei Jahren, wenn du die nicht mehr verkaufen kannst, aber das kannst?
Aber Strom und Kühlung und diese ganzen Kosten, die dir da.
Du musst halt irgendwie ein Team.
Du bist doch der klassische Kauf versus Mieten.
Ja, aber
genau, aber wo findest du genau das interne?
Also wenn du bist jetzt mal ein Konzern, ne?
Du hast jetzt nicht mehr so.
Verkaufen ihr Zeugs und Mietens zurück zu einem teuren Preis.
Also du hast halt keine Ahnung.
Du musst halt irgendwas machst da irgendwas anderes.
Und dann musst du eigentlich so ein, brauchst du irgendwas mit Cloud.
Hast du überlegt, okay, du musst jetzt irgendwie Anwendung.
Wir sind jetzt irgendwie so ein Super-Konzern.
Ja, ja, genau, so irgendwas mit Cloud.
Das ist ja Passwort, ne?
Bei Cloud-KI und so, dies, das.
Und dann sagst du, ja, okay, das müsste jetzt aber schon alle so modern sein und machen wir ein bisschen Cloud machen.
Und wenn wir jetzt aber unser eigenes Datacenter irgendwie betreiben, das müssen wir ja dann irgendwie offshore und das funktioniert aber auch nicht so richtig, weil da die guten Leute irgendwie dann doch irgendwie so, ja und dann baust du dann irgendwie so ein Dacenter, merkst du dann irgendwie so, ja, selbst wenn wir jetzt irgendwie in Deutschland irgendwie sowas bauen, was ja irgendwie total gut ist, das ist auch schon teuer und das wird, das festigt sich dann da alles und könnt ihr jetzt Globalas betreiben und die kennen ja die ganzen Sachen nicht.
Und wie bieten das denn jetzt für Services in Brasilien an und so und dann könnt ihr ja gar nicht mit denen reden und gar nicht kommunizieren und warum machen wir jetzt dann nicht alles in der Cloud?
Das ist ja total einfach, einfaches Interface für alle gleich und benutzt das dann einfach und dann haben wir dieses Controlling-Problem, dann ja, brauchst du halt diese ganzen Sachen nicht mehr.
Aber das ist ja tatsächlich, du musst das nicht selber vorhalten die ganze Zeit.
Du brauchst nicht das ganze Team vor Ort an der gleichen Stelle, dass die ganzen Sachen managt und irgendwelche Schnittstellen ausbietet, oder?
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, es gibt ja auch so Meet-Racks und so weiter.
Aber ab einer gewissen Größe lohnt sich das halt.
Und ich 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 dies hochskalieren, so viel willst du.
Ja, gut, okay.
Aber ich habe zwölf Visitor im Monat und ich muss niemals etwas hochskalieren.
Ich würde es gerne sagen.
Dann machst du Serverless.
Noch weiter.
Ja, genau, mache ich Serverless.
Da kann ich für die gleiche Latenz wie vorher, nur für einen höheren Preis.
Voll gut.
Ja, aber da muss er jetzt nicht die ganze Zeit an sein, du bezahlst ja nur für die genutzte Minute.
Ja, gut, aber dafür muss ich ja auch das Ein- und Ausschalten mitbezahlen.
Und wenn dann mal 100.000 kommen, dann muss ich auf einmal alles bezahlen.
Nee, das will ich gar nicht.
Also das ist so eine.
Ja, da wird ja viel Buzzword-Bingo gespielt.
Und ich verstehe
zum Beispiel auch gar nicht, warum Amazon, Entschuldigung, dass ich gerade noch reingehe, aber 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 an Idees klasse viele Requests auf die ganzen Server, dass die per Lambda angebunden sind oder so und hauen einfach da mal so die Quotas so massiv hoch, weil wir benutzen das alles einfach mal.
Aber bisher brauchen sie das noch gar nicht.
Voll einfach.
Du kannst einfach dann dadurch so deinen Umsatz voll hoch.
Sie können auch einfach die Preise erhöhen oder so, aber es ist robot.
Woher viele Leute nutzen unsere Sachen und dann merken sie, oh, der kommt da gar keinen Umsatz mit raus, oder?
Es gab von einer Weile so einen Artikel, ich kann den auch für die Shownotes wieder raussuchen.
Das ist ja nett.
Das 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 dieses Serverless-Verteilte total cool ist, weil jede einzelne Komponente des Systems kann einzeln skalieren.
Aber brauchst du 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.
Aber auch da wieder abstraktionslässt, dieser tolle, du brauchst gar nicht mehr.
Also die haben irgendwie ihr Budget um 90% gesenkt und die Latenzen auch.
Und das finde ich so ein bisschen gruselig, ja, wenn so die Amazon-internen Teams sagen, also wir wollen es 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, ja.
Das ist auch cool und neu und damit kannst du alles das machen, was Google auch macht.
Aber brauchst du es wirklich?
Ja, also dieses, wie du sagtest, 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 frei.
Da muss man auch dazu sagen, ehrlicherweise ist es Jammern, was man schreiben muss an Konfigurationsdateien.
Naja, ist das schlimm.
Ich muss ja mal an dieses Meme-Bild denken von dem Typen, der halt irgendwie, der da irgendwie vor dem Haufen Soldaten steht und die dann sagen, ja, erschießt ihn oder so.
Und er ist so, hey, aber ich kann irgendwie Kubernetes oder ich kann, ich kann aber mit Computendicke machen.
Und dann sagen die, ja, kannst du auch Jammel für Kubernetes schreiben und dann so, erschieß 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-Engenieer bei uns werden?
Dann sagt die Maus, bitte friss mich.
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.
Ja, alles nicht so schön.
Tommel.
Tommel ist auch nicht schön, aber es ist der beste Kandidat vielleicht.
Jetzt vielleicht nochmal erklären, bitte kurz den Unterschied zwischen Yammel und Tommel.
Yammel ist yet another Markup Language.
Tommel ist Toms Markup Language.
Also die Probleme bei Yammel sind halt, dass wenn man da nicht vorsichtig ist, dann bedeutet halt eine YAML-Dateipasen halt Code ausführen, was vielleicht viele Leute nicht
so klar ist.
Oh, das tolle Norwegen-Problem.
Jetzt muss man noch runtertechnen, was das Norwegen-Programm ist.
Tabs versus Spaces?
No.
No.
Das Norway-Problem.
Das No.
Wenn man eine Liste von Ländern speichern möchte und dann dazu die ISO-Lendercodes verwendet, dann sind das ja zwei buchstabige Ländercodes und das 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 gepasst, 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.
Nein.
Und das kann einem auch echt das Deployment kaputt machen, wenn man das halt da drin hat.
Ja, oder auch Tabs versus Spaces, ja, und generell so Significant Whitespace ist ja generell abzulehnen, gerade in der Python-Welt.
Ja, das halt jammern ist halt so eine, ja, das krankt halt an den gleichen Problemen, die viele solche Datenbeschreibungssprachen haben.
Dass wenn man genügend Daten da durchschickt oder wenn die genügend Leute damit arbeiten, dann siehst du alle Ecken und Kanten.
Und wenn die nur so ein kleines Loch haben, ja, 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.
Jetzt haben wir so vier Datentypen, ne?
Das ist vielleicht manche, also es ist elegant oder halt auch irgendwie.
Ja, und auch die Wiederholung, ja.
Du kannst nicht, wenn du irgendwie eine Million gleiche Objekte hast, dann die alle zehn Byte benutzen, aber die Keys, die du da halt reinschmeißt, die sind alle gigabyteweise Keys reingeschrieben.
Das Komma und auch keine Geschwindigkeiten.
Ja, obwohl, weil der
Jason-Kills-Trailing-Koma und
Jason-Parson geht inzwischen quasi schneller, als du von der Platte lesen kannst.
Also da, ähm, ich lese ja mal das Blog von Daniel Lemeyer, Lemia, ich weiß nicht genau, wie man ausspricht.
Kanadischer Computer Science.
Ich hab das auch in meinem RSS-Reboard drin, diesen Blog, aber der schreibt so viele gute Sachen.
Ja, muss man auch irgendwie überlesen.
Der war letztens in irgendeinem, war was, in einer, von dem von dem IEEE Podcast, Software Engineering Radio oder so, wo er auch drüber geschrieben hat, äh, geredet hat.
Der hat SimD-Jason, glaube ich, geschrieben.
Und wie man das halt machen kann und was man aufpassen muss.
Und man kann JSON-Parsen quasi beliebig schnell hinbekommen.
Also sie waren aber mehrere Gigabyte pro Sekunde.
Ja, gut, aber mehrere Gigabyte pro Sekunde impliziert ja immer noch, dass du mehrere Gigabyte hast.
Und wenn du dann stattdessen Protobuff hast und nur 100 Megabyte hast, dann ist es natürlich weniger.
Gut.
Aber sei es drum, ja.
Die eigentliche Aussage ist ja, jede von diesen Beschreibungssprachen hat Vor- und Nachteile und jede hat ihre Krankheiten.
Und Tommel ist da nichts anderes.
Ja, Tommel ist halt eine relativ simple Sprache, so ein bisschen an INI angelehnt, damit man auch das schön im Texteditor haben kann und 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 ist.
Die wird manuell geschrieben und maschinell ausgelesen.
Ich weiß nicht, ob ich auf die Idee käme, Tommel maschinell zu schreiben.
Nee, wahrscheinlich nicht.
Message-Spec 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 nicht so toll.
Ja.
Wenn es für Menschen nicht so toll ist, dann kannst du auch.
XML nehmen.
Auch Dominik.
Das würde ich gerne noch, aber wir sind jetzt auch schon ein bisschen dran, aber das würde ich gerne noch, das habe ich versucht zu sagen und hab's irgendwie 20 Minuten lang nicht hingekriegt.
Und das hat mich irgendwie dann noch verfolgt.
Also XML, ja, 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 hier ja auch schon ein paar Mal, warum Abstraktionen 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 habe dann irgendwie gesagt, so, ja, CSV gefällt mir viel besser als XML, weil ich, ich war ja lange in diesem Datenexport-Import-Geschäft tätig und nach vielen 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.
Kannst du uns auch XML geben, das geht.
Mach es nicht.
Nimm CSV.
Und dann, ich dachte auch nur so, ja, ich würde über CSV vorziehen und gegenüber XML.
Ich so, ja, wieso das denn?
Das ist auch CSV, ist ja noch viel schrecklicher, da ist ja gar nichts definiert und so.
Denn auf Python Readability Counts?
Nee, das ist gar nicht so der Punkt.
Sondern der Punkt ist eher dieses Abstraktionsding aus meiner Perspektive jetzt sozusagen, also 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.
Joachim, du holst gerade alle Zuhörer, das ist ganz schlimm, um dazu zu hören.
Haben wir jetzt noch welche jetzt gerade?
CSV ist besser, XML ist besser.
Nein, nein, nein, aber ich fand es schon interessant, wo dann so Probleme passieren.
Weil oft hast du halt kaputte Prozesse innerhalb von Unternehmern, aber das haben wir auch schon.
Und die, wenn du jetzt XML erzeugst und das irgendwo hinschiebst, dann bist du ja gezwungen.
Zum Beispiel, wenn du das auch gegen eine DTD validierst oder so.
Oder 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 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, nee, das nehme ich nicht.
Das geht nicht, das ist irgendwie kaputt.
Ja, kann man machen.
Aber es ist halt auch Geld, das dann verloren geht unter Umständen.
Und ehrlich gesagt, wenn ich jetzt sage, so, ich passe 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 Latin One, okay, geht.
Ja, oder so.
Das ist nicht so schlimm.
Das geht, das kann man programmieren, das geht.
Ich kann jetzt immer noch parsen.
Selbst wenn solche Dinge passieren wie, ja, das ist halt jetzt nicht mehr Semikolon, der Spaltentrenner, sondern Komma.
Oder das, äh, oder Tab oder da gibt es auch, gab es da nicht so ein Size-Gefühl?
ASCII-Sparated 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 Parser.
Da kannst du, 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 es halt irgendwie wollen, aber ja, es geht auf jeden Fall.
Man kann da raus 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 da halt vorher da waren.
Was halt ein katastrophaler Fehler sein kann.
Wo dann ein Rechtsstreit draus wird.
Update oder delete.
Ja, so die Frage ist, was machst du denn an der Stelle?
Du siehst halt, okay, jetzt kommt hier dieses Ding und dann denkst du dir so, okay, was willst du denn jetzt als Programmlogik machen?
Willst du sagen, nö, ich, das führe ich jetzt nicht aus, weil das kommt mir irgendwie komisch vor, landest du im Rechtsstreit.
Du führst es aus, viel Geld geht verloren, du landest in einem Rechtsstreit.
Du hast nur schlechte Option.
Du hast nicht die Option so, okay, wir machen das Encoding 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üsstest du dann irgendwie alarmieren und dann müsste jemand irgendwie einen anrufen oder so.
Aber das ist halt auch dann einfach Kacke, ja.
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, wenn man sagt halt, wir haben so viele Probleme mit diesen Syntaxen und so, wir machen jetzt ein Format, wo das validiert ist, dass es nicht mehr passieren kann.
Ja, und dann hast du halt sozusagen mit dieser Art Whack-'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.
Es ist, also wenn da, wenn da Abteilungen sind und die eben verwenden alle Excel und dann in unterschiedlichen Formaten, dann ziehst du das irgendwie zusammen und versuchst es rauszuschreiben, dann ja.
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.
Robusness-Principle.
Ja, versus Programming by Contract und wenn du das nicht 100% erfüllst, dann ist es halt weg.
Ja, also.
Ja, schmeiße ich alles weg, wenn ich halt irgendwie Mist bekomme auf meiner API.
Sage ich hart, weil der Datentyp,
das ist halt jemand, die gar nicht benutzen kann, die API.
Ja, aber das Problem ist halt, vielleicht weiß ich ja noch gar nicht, was da alles kommen soll.
Vielleicht möchte ich das ja einfach irgendwie als Zeichenkette konvertieren, da trotzdem irgendwie reinschreiben und wieder rausgeben, wenn da jemanden fragt.
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-Prinzipe.
Für eine Weile lang war das total, ja, wir akzeptieren alles und dann hast du so lustige Modi Bake in deinem Notebook drin.
Shit-in-Shit out, sagt man ja.
Ja, ja,
glaube ich.
Internet Explorer zeigt auf einmal alles auf Koreanisch an und dann schwingt es wieder, 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 wieder rum zu HTML5, wo das ist so, oh ja, gut, wenn da ein HTML5-Tag drin ist, dann kannst du schon irgendwas draus machen.
Und ja.
Ja, so, 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 auf.
Der Kunde ist schuld, der Benutzer ist schuld, ist immer die richtige Antwort.
Ja.
Naja.
Ja, schwierig.
Schwierig da auch, ja.
Wieder wie vorhin, ja, es gibt Situationen, in denen es so ist und es gibt Situationen, in denen sowas und sogar.
Nee, aber klar, vor allem, also ich meine, viele von diesen Datenschnittstellen sind ja zwischen, sag ich mal, 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 hundertprozentigen können.
Und wie geht man damit um?
Und?
Ja.
Ja, okay.
Das hat jetzt aber nichts mehr mit Kubernetes zu tun, oder?
Ich habe gerade sagen, Q-Controller.
Nein.
In gewisser Weise, in gewisser Weise schon, weil bei Kubernetes hast du halt auch so eine Abstraktionsschicht, die dann halt irgendwie sagst, okay, ich zwinge dich dazu, dass du sagen kannst, wie viel Hauptspeicher du denn brauchst.
Ja, okay, gut, das schon.
Und dann kann es sein, dass du halt ein anderes Problem kriegst, weil.
Das ist quasi das, was du vorhin sagen wolltest, ja.
Genau.
Dass es Situationen gibt, in denen kannst du gar nicht sagen, wie viele Hauptspeicher du brauchst.
Also zumindest nicht dauerhaft oder zumindest nicht so richtig
im Vorfeld.
Oder das sicher halt ein gutes Argument ist halt so viel aufwendiger als du hast.
Ja, 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 muss leider musst du jetzt einplanen.
Ja, und das musst du dann halt auch bezahlen.
Ja, genau, und das musst du dann auch bezahlen, weil so viel hast du ja requestet.
Hattest du zum Beispiel für so ein Konzertticket anbieter, wäre das vielleicht ein relevantes Problem.
Ja, oder überall, wo du Spitzen hast, ja.
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, ja, das ist ja das Versprechen von Cloud, dass du diese Spitzen abfangen kannst.
Für die realen Kosten, sag ich mal.
Weil in dem Moment mietest du dann halt mehr Rechenleistungen als in anderen Momenten.
Ich mietest ja auf einmal halt 250.000 Rechner, die normalerweise brauchst du noch fünf.
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.
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 Shellskripten, 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 kaufgerecht.
Was meinst du, warum ich mir hierher komme, Dominik?
Achso, natürlich.
Für die ganzen großen Aufträge.
Ja, die ich alle schon über den Podcast an Land gezogen habe.
Funktioniert jedes Mal.
Immer.
Also liebe Zuhörer, wenn auch Sie Interesse haben an einem Pick.
Ach ja, hast du
ein Pick.
Dominik, hast du einen Pick?
Environment.
Kennt ihr das?
Was ist Environ?
Ihr kennt ihr Django Environ oder kennt ihr eine Python.env oder sowas.
Genau, ähm.
Python ist was anderes.
Egal.
Also Environ, doch, ja, nicht ganz.
Environment ist so ein anderes Paket, wo man halt Environment-Dateien leasen kann oder halt aus der Environment-Variablen dann irgendwann seine Sachen ins Projekt vorkommt.
Das ist so ein bisschen.
Also 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 Dankware Environ habe ich sonst mal nutzen, ich versuche gerade alles umzuziehen und ist irgendwie schön.
Ich weiß noch nicht, es ist einfach intuitiv, funktioniert.
Du machst ein Env auf und machst dann Read Env von den Dot-Files, die du haben willst, finde ich.
Apropos Dot-Files, wie benutzt ihr das?
Schreibt ihr einfach tatsächlich Stumpf-Secrets irgendwo rein oder habt ihr da irgendwelche Secret-Walls oder es gibt ja noch ganz andere Sachen.
Also muss ja irgendwie dem Vertrauen.
Weiß ich nicht, ob ich das jetzt hier sagen würde.
Doch ein Secrets liegen auf einem offenen S3-Pucket, der ohne eher die ID kennt.
Ja.
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.
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 ja auch irgendwie kriegen.
Ich benutze ja gerade einen proprietären Service für, den ich ganz gut finde.
Aha.
Doppler.
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 dann 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-Apps rein oder so.
Aber Moment, aber da liegen dann deine Secrets getrennt von einem anderen, also auch von deinen Repositories und deine Produktionsmaschine geht halt auch zu Doppler und zieht da die Secrets und schreibst sie nochmal irgendwo lokal hin oder holt sich die Karte.
Zumindest in den Hauptfalls.
Du musst auch irgendwie auf Doppler zugreifen.
Genau, du musst halt so ein bisschen.
Du musst dieses Secret noch mit einem Token.
Das Token muss aber die Applikation irgendwie krassen.
Das ist dann ein Master Key.
Ja, wenn ich den kenne, dann kann ich die Secrets abgreifen.
Du musst vorher einen Hits-Ignore und das dann ins Deployment Script.
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 denn nicht einfach alle anderen Sachen damit?
Weil wo ist jetzt der Vorteil?
Also du musst ja, also du kannst das ja irgendwie mit.
Also ich muss gerade kurz überlegen, also das Problem.
Ja, also wie willst du die anderen Sachen da reinbekommen dann?
Also wenn ich jetzt ein Deploy-Token habe, das halt dann einfach so zugreift auf die ganzen Anarchies, die da irgendwo rumliegen und die vielleicht rotated sind oder was?
Das ist ein Token, okay, dann habe ich lesene Zugriffe auf die ganzen Geheimnisse.
Aber wenn du die sonst eh hinschreibst, ich verstehe den Unterschied nicht.
Ja, ich auch nicht.
Also ich meine, 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.
Ja, genau.
Warum kannst du diesen Weg nicht benutzen, um alle anderen Geheimnisse, die du halt auch hast, der Applikation auch mitzuteilen, weil ja.
Es ist dieser Weg oder machst du es einmal beim Setup?
Manuelle Eingabe einmal irgendwie mit Hist.
Ja, man kann sich ja auch ändern.
Also du hast eigentlich nur die Menge der Secrets, die du mitgeben möchtest, verringert.
Ja.
Ja, aber ich verlege gerade.
Du hast die Secrets komprimiert.
Also du kannst halt zum Beispiel jetzt GitHub irgendwie sagen, bei den Secrets steht drin, da könntest du aber auch dann sagen, du sagst dann halt, okay, dann machst du alle bei Secrets, bei GitHub Secrets.
Ja.
Okay, ich wollte ja gar nicht, es ist halt einfach nur so, es ist ein blödes Problem, ne?
Aber was ich tatsächlich mache, ist, ich, oh doof, das ist echt doof, das zu sagen, ne?
Aber.
Don't do it.
Erzählst du mir gleich ein geheimes Volksspäter.
Ich habe Sachen oft in Valls drin liegen und dann schreibe ich das halt tatsächlich in so ein End-File und dann hat die Applikation das.
Der Nachteil, also 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.
Zack.
Genau, aber die Nachteile sind, ja, wenn ein Angreifer irgendwie in meine Applikation reinkommt,
der muss auch den Entschlüsseln halt einfach dann.
Nein, nein, der muss nichts entschlüsseln.
Das ist halt das, was in Angriff.
Ja, aber er ist halt besonders einfach, weil er muss einfach nur, er nimmt einmal das komplette Environment, macht da JSON raus und schickt es an irgendein, ich hier alle Secrets in alle Environments von allen irgendwie stormen.
Und dann hinterher guckt er, ob da vielleicht ein AVS-Key drin war oder sowas.
Be jeder Edge of M oder bei irgendwas, das muss ja irgendwann 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.
Also NV-Runs macht ja auch nichts anderes, als dass irgendeiner Pfeil oder irgendwie anders die Sachen hat.
Man könnte es ja auch anders machen.
Man könnte ja auch sowas machen wie man packt es in ein Modul mit komischem Namen irgendwie und schreibt das halt als Python-Code irgendwo hin.
Security by Obscurity.
Und ihr importiert den Kram, ja.
Also sag mal so, wirklich helfen tut es nicht, weil du kommst immer noch an den Kram ran.
Aber die automatischen Dinge, die halt über irgendwie eine.
Es wird 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.
Also genauso wie wenn ich den Standard-SSH-Port ab 2224 ändere, damit das nicht.
Ja, okay, es ist Security by Obscurity so ein
bisschen ab.
Was du dann eigentlich machen müsstest, ist, dass du irgendwelche Capabilities hast.
Also dass dir die Datenverbindung nicht mehr direkt über Django machst, wo das Datenbank-Passwort 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 dass der dann auch schon wieder so viel Aufwand ist.
Ja, genau.
Ja, ich überlege andererseits, vielleicht fehlt da eine Standardlösung.
Vielleicht fehlt da eine Security Onion um Django außenrum.
Ja, ich weiß es nicht.
Aber ich überlege immer noch was für diesen proprietären Server, sprich, weil das sind da 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 Secrets, da komme ich dann trotzdem an, die Secrets nicht dran.
Also irgendwie, ja, ist halt die Frage, wo liegt denn dieser Key zum Produktionsdeployment?
Da kann man ja noch per Netzwerk irgendwo 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.
Und insbesondere, also es gibt halt diesen Level von, ich habe jetzt Dev-Secrets für den einen Entwickler als die anderen Dev-Secrets, ich habe noch Station-Secrets, die steigen alle drin.
Die kannst du einfach mit einem Kommando aufsetzen, es funktioniert, es wird eingetragen und es ist nutzbar, ist das übertragbar.
Du kannst einfach, wenn irgendwie 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 Walls nicht mit drin.
Da musst du alles selber anfassen.
Ja.
Okay.
Ja, ja.
Okay, was ist denn dein Pick?
Mein Pick ist ein Artikel mit dem Titel An Interactive Intro to CRDTs.
Und ich bin ja ein großer Fan von CRDTs, also Concurrent Replicated Data Types.
Wie sagt ihr dieses Wort?
CRDT.
Keine Ahnung.
Credites.
Credities, ja.
Also Conflict-Free Resolution Dependent Data Types irgendwie sowas.
Wo du Datenstrukturen hast, die sich selbst wieder in einen synchronen Zustand bringen.
Also sowas wie Etherpad oder Hedgehog oder Google Documents.
Wo zwei Leute gleichzeitig bearbeiten können und am Ende ist ein Dokument da, was bei beiden.
Oh ja, 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 es aber auch nicht, hat mir das sehr weitergeholfen und ich finde das sehr großartig.
Und es ist auch schön so mit eben interaktiv.
Also du kannst dann, du hast dann zwei Malfenster und kannst dem einen malen, kannst du dem anderen malen und 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 einer Episode davor schon mal gepickt habe.
Du musst jetzt eigentlich zwei machen.
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, was absichtlich besonders unappetitlich und unverdorlich nachher kommt.
Und das ist, ich weiß nicht, ob ihr das kennt.
Man sollte es aber trotzdem mal konsumieren.
Nämlich das V-Bock.
Oh, das Software Engineering Body of Knowledge.
Genau.
Haben wir doch alle schon mal konsumiert, sonst wären wir doch gar keine Software-Engineer.
Also, ja, ich habe es mir jetzt auch irgendwie mal.
Es sind ja auch nicht viele Seiten.
Ich bin in der Ticketschubsecode, da gibt es ja andere noch hier.
Es ist, es ist ein bisschen kompliziert reinzukommen, man muss halt irgendwie so ein Formular ausfüllen und dann kann man, kann ich mal einen Download-Link geschickt, aber genau, und dann kann man, da steht halt, da sind halt all solche, was 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 oder so, da wird das alles definiert.
Genau, aber sozusagen, um diese Diskussion zu beenden, kann man immer sagen, ja, ich verwende jetzt die Definition hier aus den Dings und dann.
Oder auch die ganzen Prozesse und so ist alles definiert und was sind 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 große Glossary ist das?
Nummer Version 3.0.
Das ist jetzt die aktuelle Grad.
Das ist das große Glossar für alle Dinge, die Software entwickelt.
Ja, die Festlegung der Wahrheit.
Die einzig wahre Wahrheit TM.
Die ist hier festgelegt.
Na dann?
Dann müssen wir keine Kinder.
Ja, sehr appetitlich auch und sehr schön.
Ja, das war auch schon der Pick, oder?
Cool bekommst.
Na gut.
Ja, dann eine nicht so Kubernetis-Kybernetes-Folge.
Aha.
Also doch auch schon auch schon durchaus Kubernetes.
Ja, okay.
Wir haben nicht so viel erklärt, wie man das benutzt, aber das müsst ihr selber rausfinden.
Wenn ihr wirkliche Dinge wissen wollt, dann dürft ihr nicht hierher zukommen zum Zuge.
Ja, es gibt auch so ein paar einfache Sachen.
Golo hatte irgendwie noch, vielleicht kann man es auch noch verlinken, so einen schönen YouTube-Einsteiger.
Guck mal doch mal, wie du dein Minikube aufgesetzt hast und was man damit macht.
Ja, genau, also ich habe eigentlich Golos Tutorial so ein bisschen gemacht.
Ist das der zweite Pick?
Ist das der Pick, der
Sundial-Kanal, der irgendwie die Woche irgendwie so Sachen macht?
Es ist relativ einfach, auf Deutsch ein bisschen langsamer als wir reden.
Und das ist ganz nett so ein bisschen.
Vielleicht sollte man das am Anfang sagen, ja.
Alles klar?
Okay.
Dann bleibt uns gewogen.
Schalt uns ein, wann auch immer ihr hört.
Mittags, morgens, abends, nachts.
Ein guten Tag und gute Zeit.
Bis zum nächsten Mal.
Bis zum nächsten Mal.
Tschüss, Johannes.
Bis bald.
Ciao.
Tschö.