Unsere Microservices sind die größten...
Es ist soweit. Ich reihe mich ein, bei denen, die schon die ganze Zeit auf Microservices, Docker, Kubernetes und Konsorten herum hacken.
Ich war ja bislang immer der Meinung, dass die Idee dahinter doch eigentlich völlig nachvollziehbar ist. Und dass es durchaus vorteilhaft und fortschrittlich ist.
Aber da kannte ich die konkrete Umsetzung und "best practises" ja auch noch nicht näher.
Das fängt schon bei den Docker-Images an.
Eigentlich ist die Idee ja, dass eine Applikation schön abgekapselt in ihrem Container läuft und sich nicht darum sorgen muss, in welcher Umgebung usw. sie läuft.
Nun braucht so eine Applikation nur zumeist eine Laufzeitumgebung und diese wiederum ein Betriebssystem.
Und was kommt dann dabei heraus? Naja, ein Docker-Image, wo das komplette OS + Runtime schon mit drin ist.
Wir haben also eine vielleicht 2MB große Applikation ...plus eine 100MB Runtime und ein 700MB OS. Daraus bauen wir ein ca. 800MB fettes Docker-Image und nennen das ganze dann "Microservice" oO
Das erinnert mich ein wenig an die alten Witze über Robotron in der DDR.
Das ganze packen wir dann mit Hilfe von Kubernetes in "die Cloud" - z.B. MS Azure.
Denn wir wollen ja mehrere von diesen "schlanken" Applikationen laufen lassen um die Last bewältigen zu können.
Über Kubernetes schreibe ich hier jetzt nicht mehr viel, denn folgender Beitrag von Fefe sagt eigentlich alles dazu:
https://blog.fefe.de/?ts=a3b25963
Nun stellen wir uns vor, wir wollen eine Konfiguration für die App ändern. Zum Beispiel einen String von "Wert-1" auf "Wert-2".
Früher hätte man vermutlich die Konfiguration irgendwo abgelegt (Shared Storage oder Datenbank) und die Applikation hätte sich die Config von dort gezogen.
Aber in Zeiten von Docker und Co. ist es natürlich total "old school", dass sich die Applikation darum kümmern soll. Wir wollen ja die armen Entwickler entlasten!!!!111elf
Also packen wir die Konfiguration als Dateien oder Umgebungsvariablen in das Docker-Image! Und wenn wir die ändern wollen? Ganz genau!
Wir bauen in Azure eine Pipeline, der wir den neuen Wert übergeben und die baut dann ein komplett neues, 800MB großes Docker-Image, dass komplett identisch zum alten Image ist, mit Ausnahme dieser Umgebungsvariablen. Und dann wird das ganze via Kubernetes ausgerollt. Also ein neuer POD mit dem neuen Image gestartet und dann die alten sukzessive "durchgetauscht" - was schon mal seine Zeit dauern kann.
Und die Leute finden das nicht etwa verschwenderisch oder ineffizient, sondern normal. Kommentar eines Kollegen dazu: "So macht man das heute! In Zukunft werden wir ganze Rechenzentren weg schmeißen und neu bauen!"
Und wenn man sich die "Möglichkeiten" von Kubernetes so anschaut, stellt man fest: das ist so gewollt! Es gibt kein Feature, mit dem man so Kleinigkeiten mal eben auf alle Instanzen propagieren und ggfs. ein Reload/Restart der Applikation triggern kann! Ein Reload ist immer gleichzusetzen mit einem kompletten Deployment der Applikation. Also wieder: ein neuer POD mit dem neuen Image gestartet und dann die alten sukzessive "durchtauschen".
Da passt es ja dazu, dass man - zumindest in Azure - die Volumes, die man in die Container mounten kann, nicht kleiner als 1GB machen kann.
Du brauchst ein shared Volume für 720KB Config? Pech. Weniger als 1GB geht nicht.
Und so dauert eine Konfigurationsänderung von eigentlich wenigen Sekunden schon mal eine viertel Stunde oder mehr. Aber dafür verbrauchen wir dabei auch um Größenordnungen mehr Speicher und Rechenzeit!
Das muss dieser Fortschritt sein, von dem alle reden!
"Nehmt Docker, Kubernetes und die Cloud!", haben sie gesagt. "Damit wird alles besser, größer und schneller!", haben sie gesagt!
Nun zumindest größer wird der ganze Scheiß auf jeden Fall.
Passend dazu, zum Schluss noch einen Robotron-Witz:
Robotron hat einmal einen Draht entwickelt, der so dünn war, dass kein Messinstrument in der DDR genau genug war, um seine exakte Dicke zu bestimmen.
Also schickte man den Draht per Post nach Japan. Dummerweise hatte man vergessen den Brief beizulegen, was die Japaner mit dem Draht eigentlich machen sollten.
Ein paar Wochen später kam der Draht per Post aus Japan zurück. Anbei lag ein Schreiben der Japaner:
"Leider wussten wir nicht, was wir mit dem Draht machen sollten. Also haben wir ein Innen- und Außen-Gewinde rein geschnitten!"
Ich war ja bislang immer der Meinung, dass die Idee dahinter doch eigentlich völlig nachvollziehbar ist. Und dass es durchaus vorteilhaft und fortschrittlich ist.
Aber da kannte ich die konkrete Umsetzung und "best practises" ja auch noch nicht näher.
Das fängt schon bei den Docker-Images an.
Eigentlich ist die Idee ja, dass eine Applikation schön abgekapselt in ihrem Container läuft und sich nicht darum sorgen muss, in welcher Umgebung usw. sie läuft.
Nun braucht so eine Applikation nur zumeist eine Laufzeitumgebung und diese wiederum ein Betriebssystem.
Und was kommt dann dabei heraus? Naja, ein Docker-Image, wo das komplette OS + Runtime schon mit drin ist.
Wir haben also eine vielleicht 2MB große Applikation ...plus eine 100MB Runtime und ein 700MB OS. Daraus bauen wir ein ca. 800MB fettes Docker-Image und nennen das ganze dann "Microservice" oO
Das erinnert mich ein wenig an die alten Witze über Robotron in der DDR.
"Robotron - unsere Mikroelektronik ist die größte!"
"Robotron - unsere Mikroelektronik ist einfach nicht klein zu kriegen!"
Das ganze packen wir dann mit Hilfe von Kubernetes in "die Cloud" - z.B. MS Azure.
Denn wir wollen ja mehrere von diesen "schlanken" Applikationen laufen lassen um die Last bewältigen zu können.
Über Kubernetes schreibe ich hier jetzt nicht mehr viel, denn folgender Beitrag von Fefe sagt eigentlich alles dazu:
https://blog.fefe.de/?ts=a3b25963
Nun stellen wir uns vor, wir wollen eine Konfiguration für die App ändern. Zum Beispiel einen String von "Wert-1" auf "Wert-2".
Früher hätte man vermutlich die Konfiguration irgendwo abgelegt (Shared Storage oder Datenbank) und die Applikation hätte sich die Config von dort gezogen.
Aber in Zeiten von Docker und Co. ist es natürlich total "old school", dass sich die Applikation darum kümmern soll. Wir wollen ja die armen Entwickler entlasten!!!!111elf
Also packen wir die Konfiguration als Dateien oder Umgebungsvariablen in das Docker-Image! Und wenn wir die ändern wollen? Ganz genau!
Wir bauen in Azure eine Pipeline, der wir den neuen Wert übergeben und die baut dann ein komplett neues, 800MB großes Docker-Image, dass komplett identisch zum alten Image ist, mit Ausnahme dieser Umgebungsvariablen. Und dann wird das ganze via Kubernetes ausgerollt. Also ein neuer POD mit dem neuen Image gestartet und dann die alten sukzessive "durchgetauscht" - was schon mal seine Zeit dauern kann.
Und die Leute finden das nicht etwa verschwenderisch oder ineffizient, sondern normal. Kommentar eines Kollegen dazu: "So macht man das heute! In Zukunft werden wir ganze Rechenzentren weg schmeißen und neu bauen!"
Und wenn man sich die "Möglichkeiten" von Kubernetes so anschaut, stellt man fest: das ist so gewollt! Es gibt kein Feature, mit dem man so Kleinigkeiten mal eben auf alle Instanzen propagieren und ggfs. ein Reload/Restart der Applikation triggern kann! Ein Reload ist immer gleichzusetzen mit einem kompletten Deployment der Applikation. Also wieder: ein neuer POD mit dem neuen Image gestartet und dann die alten sukzessive "durchtauschen".
Da passt es ja dazu, dass man - zumindest in Azure - die Volumes, die man in die Container mounten kann, nicht kleiner als 1GB machen kann.
Du brauchst ein shared Volume für 720KB Config? Pech. Weniger als 1GB geht nicht.
Und so dauert eine Konfigurationsänderung von eigentlich wenigen Sekunden schon mal eine viertel Stunde oder mehr. Aber dafür verbrauchen wir dabei auch um Größenordnungen mehr Speicher und Rechenzeit!
Das muss dieser Fortschritt sein, von dem alle reden!
"Nehmt Docker, Kubernetes und die Cloud!", haben sie gesagt. "Damit wird alles besser, größer und schneller!", haben sie gesagt!
Nun zumindest größer wird der ganze Scheiß auf jeden Fall.
Passend dazu, zum Schluss noch einen Robotron-Witz:
Robotron hat einmal einen Draht entwickelt, der so dünn war, dass kein Messinstrument in der DDR genau genug war, um seine exakte Dicke zu bestimmen.
Also schickte man den Draht per Post nach Japan. Dummerweise hatte man vergessen den Brief beizulegen, was die Japaner mit dem Draht eigentlich machen sollten.
Ein paar Wochen später kam der Draht per Post aus Japan zurück. Anbei lag ein Schreiben der Japaner:
"Leider wussten wir nicht, was wir mit dem Draht machen sollten. Also haben wir ein Innen- und Außen-Gewinde rein geschnitten!"
Trackbacks
Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt