#56 Applikations-Skalierung: Wann, wieso, was kostet es? Stateless und Stateful, Horizontal vs. Vertikal

Die App muss skalieren. Das kann doch nicht so schwer sein, oder?

Sekundenschnelles und automatisches Hochskalieren bei einem erhöhten Traffic-Aufkommen. So oder so ähnlich versprechen es die Cloud-Hyperscaler in ihren Marketing-Texten. Das erweckt oft den Anschein, dass das Ganze gar nicht so schwer sein kann. Doch ist dies auch in der Realität so? Eine Applikation skalierbar zu gestalten, ist bei weitem nicht einfach. Stichworte wie Ausfallsicherheit, vertikale- oder horizontale Skalierung, Stateless- oder Stateful-Applications, Loadbalancer und Auto-Discovery, Kubernetes und zusätzliche Code-Komplexität, finanzieller Impact, Load-Tests, Request-Deadlines, Chaos Monkey und Down-Scaling. Alles Begriffe, die damit in Verbindung stehen und einen wichtigen Bestandteil ausmachen.

In dieser Episode geben wir einen Überblick über das Thema Application-Skalierung: Was ist das? Wer braucht es? Was sind die Grundbegriffe und welche Grundlagen müssen erfüllt werden, damit das ganze erfolgreich wird?

Bonus: Warum Andy eine Märchenstimme hat und warum wir Milchmädchenrechnung nicht mehr sagen sollten.

Sprungmarken

(00:00:00) Intro

(00:00:35) Das Märchen der Skalierung und meine Datenbank skaliert nicht

(00:02:55) Was ist Skalierung?

(00:06:45) Braucht man Skalierung überhaupt? Wer muss skalieren?

(00:12:41) Es ist cool auf Scale zu arbeiten

(00:16:23) Wenn wir skalieren können, sparen wir Geld

(00:20:50) Stateless vs. Stateful-Systeme

(00:31:43) Horizontaler vs. Vertikaler skalierung

(00:35:38) Ab wann skaliere ich die Hardware oder optimiere die Applikation?

(00:39:24) Gesteigerte Komplexität durch Skalierung

(00:42:42) Was braucht ihr, um skalieren zu können bzw. damit anzufangen?

(00:48:49) Outro

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:04 - 00:00:41)

Willkommen zu einer neuen Mächenstunde im Engineering Kiosk. Dieses Mal mit unseren Mächenfiguren, der nicht skalierenden Datenbank, Kubernetes, der die nicht skalierende App rettet, mutige Webshop-Server, die sich mit Rammstein und den toten Hosen anlegen, Lügengeschichten der Ausfallsicherheit und was natürlich nie fehlen darf, das Mächen von der Marie. Denn billig ist Skalierung nie. Heute sprechen wir ja über das Märchen der Eskalierung und Andi, du hast dir schon eine Märchenstimme zugelegt, dessen nenne ich mal ein Satz.

Andy Grunwald (00:00:41 - 00:00:47)

Das wäre dann eher die Stimme vom bösen Wolf, oder? Anstatt vom Held des Märchens.

Wolfi Gassler (00:00:47 - 00:00:48)

Der da Kreide frisst.

Andy Grunwald (00:00:49 - 00:00:53)

Kreide, Schafe, Geißlein, alles was gerade da in den Märchen so rumschwirrt.

Wolfi Gassler (00:00:54 - 00:00:57)

Ja, deine Stimme klingt, als hättest du gerade ein Schaf gefressen.

Andy Grunwald (00:00:57 - 00:01:08)

Es tut mir leid, alle Hörerinnen und Hörer. Auch mich hat diesmal diese Wintererkältung eingefangen. Der Wolfgang hat mich trotzdem dazu gezwungen, eine Podcast-Folge aufzunehmen.

Wolfi Gassler (00:01:08 - 00:01:10)

Ein Märchen bitte, wir haben heute ein Märchen.

Andy Grunwald (00:01:10 - 00:01:18)

Deswegen arbeite ich eigentlich krank, wenn man so möchte. Nein, mir geht's super, nur meine Stimme zieht sich noch ein paar Tage.

Wolfi Gassler (00:01:18 - 00:01:21)

Das heißt, ich muss heute mehr reden ausnahmsweise mal.

Andy Grunwald (00:01:21 - 00:01:34)

Aber wie lautet denn das Märchen? Es war einmal eine App, die skalieren musste? Und wenn sie nicht skaliert wurde, skaliert sie noch heute? Und wenn sie nicht skaliert wurde, will sie immer noch skalieren? Oder wie läuft das?

Wolfi Gassler (00:01:34 - 00:01:56)

Ich glaube, die Märchen, die wir heute besprechen wollen, sind eigentlich ziemlich kurz. Das sind so diese Mini-Pixie-Bücher, die man so diesen Babys gibt, so mit drei Seiten. Da steht auf der ersten Seite oben Kubernetes, auf der zweiten da Microservices und auf der dritten Cloud. Und damit ist doch alles skaliert. Was ist denn dein Lieblingsmärchen oder die Lieblingsseite von unseren Märchen?

Andy Grunwald (00:01:56 - 00:02:10)

Das, was mich aus meiner beruflichen Erfahrung immer am meisten auf die Palme bringt, ist, wenn irgendjemand um die Ecke kommt, ohne irgendwelche Beweise oder harten Kriterien und sagt, wir müssen die Datenbank wechseln. Die Datenbank skaliert nicht. Wie oft hast du das schon gehört?

Wolfi Gassler (00:02:10 - 00:02:19)

Sehr oft, und vor allem, weil die neue Datenbank dann immer wesentlich besser skaliert oder automatisch skaliert und out of the box alles funktioniert. Es ist immer superperfekt.

Andy Grunwald (00:02:20 - 00:02:55)

Und das Lustige ist, es gibt ja ja immer, wenn ich so eine Aussage kriege, da gibt es gar nicht so das Pattern, dass irgendwie immer MySQL nicht skaliert oder immer Redis nicht skaliert, sondern es ist immer die Datenbank, die wir jetzt gerade haben. Und dann muss eine andere Datenbank eingesetzt werden, die es letzte Woche auf Hacker News wieder irgendein Feature gebracht hat. Es ist völlig egal, ob die Datenstruktur dazu passt oder ähnliches, sondern man kommt einfach um die Ecke. Die Datenbank skaliert nicht. Deswegen habe ich mal davor am Wochenende ein Proof of Concept gehackt. Und schau mal da, die App läuft jetzt auf DynamoDB, MongoDB, von mir aus auch Memcache.

Wolfi Gassler (00:02:55 - 00:03:11)

Aber bevor wir da in die Details einsteigen, was ist denn für dich überhaupt Skalierung, Andi? Weil Skalierung kann ja sehr viel sein. Ich kann ja auch mein Businessmodell skalieren und einfach viel Geld machen. Hört man ja in der Startup-Welt auch immer öfter. Aktuell weniger oft, aber früher immer öfter.

Andy Grunwald (00:03:11 - 00:04:10)

Bei den aktuellen Layoffs hört man es, glaube ich, gerade umso mehr, weil die ganzen Startups natürlich diese Rule of Forty wieder haben wollen und deswegen skalieren müssen und deswegen ganz viele Leute entlassen. Aber wir sprechen natürlich, wenn wir über Skalierung sprechen, sprechen wir nicht über das Businessmodell, sondern wirklich über die IT und über die Infrastruktur, dass die Applikation ausfallsicher sein muss und im Groben und Ganzen Lastspitzen abfangen können muss. Jetzt kann man natürlich sagen, Ausfallsicherheit ist nicht gleich Skalierung, aber statistisch gesehen, umso mehr Maschinen man hat, umso eher fallen davon Maschinen natürlich auch aus. Es bringt nichts, wenn ich einfach nur mehr Kisten dahinstelle und dann Ausfälle nicht abfangen kann. Deswegen ist für mich die Skalierung genau beides. Und wenn ich von Lastspitzenabfangen spreche, dann meine ich eigentlich, dass man unter der Last nicht zusammenbericht oder in kurzer Zeit eine deutlich erhöhte Anzahl an Anfragen abgearbeitet bekommt. Also wie zum Beispiel bei TV-Werbung oder saisonalem Traffic oder ähnliches.

Wolfi Gassler (00:04:10 - 00:04:49)

Jetzt hast du schon gesagt, Skalierung ist auch Ausfallsicherheit für dich, aber ich glaube, genau da ist auch ganz oft das Problem, dass die Leute das eben nicht genau im Auge haben, ob jetzt nur irgendwas skaliert oder auch ausfallsicher ist. Weil nur weil ich viele Nodes habe und dann Kubernetes stehen habe, heißt es noch lang nicht, dass der auch ausfallsicher ist. Und das sind, glaube ich, schon zwei Paar Schuhe. Und da muss man schon viel mehr Sachen beachten, wenn es um Ausfallsicherheit geht. Und die Frage ist dann, wie ausfallsicher ist irgendwas? Wie viele Dinge dürfen denn ausfallen? Darf ein Node ausfallen? Dürfen fünf Nodes ausfallen? Darf das Netzwerk ausfallen? Also da spielt dann schon viel mehr mit rein.

Andy Grunwald (00:04:49 - 00:05:17)

Was Ausfallsicherheit bedeutet, ist ja auch ganz spezifisch. Nehmen wir mal ein Shopsystem und nehmen wir mal die Zahlungsschnittstellefeld aus. Stecken wir jetzt Arbeit da rein, dass das Shop-System weiter besuchbar ist, obwohl man keine Sachen bestellen kann? Also ist ja mal die Frage, weil wenn ich nicht bezahlen kann, ist der Sinn eines Shop-Systems auch irgendwie dahingestellt. Also was ausfallen kann und wie die Applikation degraded sein kann, also nicht 100% verfügbar, kommt ja auch ganz auf deine Applikation an.

Wolfi Gassler (00:05:17 - 00:05:54)

Und da ist dann, glaube ich, ganz wichtig, auch sich zu überlegen, okay, wie teuer ist denn diese Skalierung oder Ausfallsicherheit? Und was bringt mir das Ganze? Also kann ich damit leben, dass man in dem Shop kurzzeitig mal nichts bestellen kann? Oder kann ich das dann vielleicht auch wieder zurückholen, weil die Leute haben das schon in Warenkorb gelegt und ich kann sie später dann erinnern, dass sie jetzt bestellen können im Notfall. Also kann ich mit dem Problem dann umgehen oder ist mir das so wichtig, dass ich eben auch die ganze Bezahlung, die Bestellung auch komplett ausfallsicher halten will? Solche Überlegungen haben natürlich extreme Auswirkungen auf den finanziellen Aufwand, aber auch auf die Komplexität von dem ganzen System.

Andy Grunwald (00:05:54 - 00:06:18)

Genau, hier ist glaube ich wichtig zu erwähnen, dass das Wort teuer nicht immer finanziell teuer sein muss, obwohl natürlich Skalierung auch finanziell teuer sein muss, entweder wenn etwas ausgefallen ist, der Zahlungsdienstleister, Aber oft spricht man halt vom zusätzlichen Aufwand, den man in die Entwicklung stecken muss, um skalieren zu können, um Ausfälle abfangen zu können. Also teuer im Sinne von Aufwand ist glaube ich der höhere Kostenfaktor.

Wolfi Gassler (00:06:18 - 00:07:07)

Was aber am Ende auch Geld entspricht wieder. Also es geht schon um den finanziellen Aufwand. Aber der ist natürlich oft unterschätzt, weil du auch mit der Komplexität dann später viel mehr Aufwand hast. Also den du jetzt vielleicht noch gar nicht siehst, aber wenn deine Debugging-Sessions dreimal so lange dauern wie davor, dann hast du da natürlich auch wesentlich mehr Komplexität drinnen, weil du in deinen Microservices suchen musst, wo denn jetzt wirklich was kaputt gegangen ist zum Beispiel. Aber wir sind jetzt eigentlich schon komplett in der Skalierung drin. Für mich stellt sich ja oft die Frage, braucht man denn Skalierung überhaupt? Und wer braucht die Skalierung? Weil man hört ja ganz oft, ich verwende Kubernetes. Und dann fragst du ja, warum eigentlich? Ja, damit das Ganze skaliert. Und dann fragst du genauer nach, was da betrieben wird. Und dann ist es irgendwie eine kleine Webseite mit ein paar tausend Zugriffen pro Tag. Aber man muss ja Kubernetes heutzutage verwenden.

Andy Grunwald (00:07:08 - 00:07:35)

Ist natürlich eine sehr schwierige Aussage, die du betroffen hast, wenn man sagt, okay, Kubernetes nimmt man nur zur Skalierung. Aber ja, sowas hört man wirklich oft. Und ein paar tausend Zugriffe. Jeder aktuelle Raspberry Pi kann, glaube ich, mehr Zugriffe abfangen. Auch mit Java-Software. Und da lache ich jetzt ein kleines bisschen. Aber ich glaube, Java-Software ist nicht mehr so memory-hungrig, wie es früher mal war. Dennoch, auch eine ältere Applikation müsste, glaube ich, so ein aktueller Raspberry Pi für ein paar tausend Zugriffe pro Tag locker abfangen können.

Wolfi Gassler (00:07:35 - 00:07:55)

Es kommt auch darauf an, wie das Ganze programmiert ist. Ich glaube, die Programmiersprache ist das kleinste Problem. Du kannst auch mit sehr optimierten Programmiersprachen wahrscheinlich sehr dreckig irgendwas machen, was dann super speicherintensiv ist. Also es kommt immer darauf an, was du machen willst. Aber was sind denn so typische Anwendungen, wo man wirklich Skalierung braucht, deiner Meinung nach?

Andy Grunwald (00:07:55 - 00:08:46)

Der klassische Fall sind irgendwelche Sonderevents. Nennen wir mal ein Finalspiel bei einer Weltmeisterschaft, der NFL, Superbowl, vielleicht auch TV-Werbung, Primetime auf ProSieben, aber auch so wirkliche High-Traffic-Events wie Black Friday im E-Commerce. wenn Rammstein neue Konzertkarten verkauft, Twitch-Stream mit tausenden Live-Usern oder vielleicht einfach Geschäftsmodelle, die ganz stark saisonalen Traffic haben. Urlaube werden zum Beispiel immer zu bestimmten Zeiten gebucht, immer so sehr stark um Weihnachten und um den Sommer herum. Da hat man so sieht man sehr saisonale Peaks oder bis vor kurzem wurden Autoversicherungen immer Ende November abgeschlossen beziehungsweise verglichen. Ich gehe stark davon aus, dass Check24 und die Ideale und wie sie alle heißen um diesen Zeitraum herum schon sehr viele Zugriffe auf ihren Autoversicherungsvergleich sehen.

Wolfi Gassler (00:08:47 - 00:09:19)

Also du sprichst ja jetzt vor allem diesen Autoscaling-Use-Case an, wo man automatisch irgendwie skaliert um Weihnachten herum, um Black Friday, was auch immer, dass man mehr Power hinter dem Ganzen hat, damit man das abfangen kann. Aber Skalierung kann natürlich auch verwendet werden, um zum Beispiel bestehende Hardware möglichst gut auszulasten, damit man da flexibel ist und die ganze Power, die man hat, wenn man jetzt tausende Server hat, dass man die einfach möglichst gut auslastet zum Beispiel. Aber im Endeffekt hat es die selbe Auswirkung auf die Software, dass sie flexibel ist und skalierbar.

Andy Grunwald (00:09:19 - 00:10:21)

Es muss ja nun als Autoskalierung sein, wenn du den Zeitpunkt ganz genau abschätzen kannst, nehmen wir das Rammstein Ticketverkauf Event, dann kannst du halt auch vorher einfach hoch skalieren und hast halt für diesen Zeitraum einfach sehr viel Hardware da stehen. Weil, wenn Rammstein eine neue Europa-Tour ankündigt, dann geh ich mal davon aus, innerhalb von, weiß ich nicht, so, angenommen, die verkaufen um 20 Uhr die Tickets, vier Stunden vorher loggen sich die ersten Leute ein, um wirklich sehr früh in die Warteschlange zu kommen. Und dann ist das ganze Ding um 21 Uhr durch. Spätestens. Also, dann weißt du ja, okay, da hast du für fünf Stunden, weiß ich nicht, 20, 30, 40 Server da stehen, find ich sogar mehr. Und dann kann sich ja wirklich jemand hinsetzen und manuell downscalen, ja? magie und automatisch gehen tut sowieso nicht warum kann man gleich noch zu aber es kommt halt immer ganz darauf an was hast du für ein event und man sollte sich auch fragen brauche ich das denn wirklich denn wie gerade erwähnt die ganze sache ist sehr sehr teuer beziehungsweise kann sehr teuer sein je nach.

Wolfi Gassler (00:10:21 - 00:11:08)

Architektur und Und es gibt ja dann auch so Use Cases, wo du eigentlich dann abhängig bist von dem externen Service, wie dem Bezahlungsdienstleister, den du jetzt genannt hast. Jetzt kannst du alles skalierbar bauen, aber wenn dein Bezahldienstleister für das Rammstein-Konzert nichts skaliert, dann hilft dir das Ganze wieder nichts. Ich kann mich erinnern, der Andi und ich sind mal am Abend im Büro gesessen, nebeneinander, Computer an Computer. Ich glaube, es war 6 Uhr am Abend und wir haben probiert, Tote-Hosen-Konzertkarten zu bekommen und sind am F5-Button geklebt, um den Browser zu reloaden. Und es ist am Ende immer gescheitert bei der Bezahlung. Und bis wir dann mal verstanden haben, wenn wir einfach auf Bezahlung bei Rechnung klicken, dann kommt diese Transaktion gar nicht zum Bezahlserver, geht super schnell durch und es hat perfekt funktioniert.

Andy Grunwald (00:11:09 - 00:11:45)

Unser Vorgehen war wie folgt. Wir wollten immer per Kreditkarte oder per Paypal zahlen. Das bedeutet wir klicken unsere Tickets zusammen. Wie funktioniert ein Shop? Der redirectet dich zum Zahlungsdienstleister, du gibst deine Kreditkartendaten ein oder dein PayPal und dann kommst du wieder zurück, dann wirst du vom PayPal oder vom Kreditkandidat wieder zurück auf die Toten-Hosen-Webseite gelenkt. Und auch der Server muss in der Lage sein, diesen Backcall wieder abfeiern zu können. Und da habe ich gelernt, kleiner Tipp, Konzertkarten immer auf Rechnung kaufen, dann habt ihr diesen Roundtrip zum Zahlungsdienstleister einfach nicht und eure Chance steigt, ich würde fast sagen um 90 Prozent, dass ihr ohne Probleme Karten bekommt.

Wolfi Gassler (00:11:46 - 00:12:24)

Wenn es zumindest angeboten wird, ist die Frage, ob das heutzutage noch oft angeboten wird, bei den Toten Hosen war es zumindest immer so der Fall. Auf jeden Fall war das dann wesentlich einfacher und da ist es wieder einfach sinnlos investierte Zeit und Geld, wenn man das extrem skalierbar macht, wenn dann am Ende ein Stück wie der Bezahldienstleister nicht skaliert und nicht mitmacht bei der ganzen Aktion und das muss man sich natürlich auch überlegen. Und solche Sachen sind jetzt nicht unmöglich mitzudenken, aber man muss sie mitdenken. Und das macht auch Skalierung komplex, weil man wirklich alle Elemente, alle Dienste innerhalb mitdenken muss. Und darum ist es gar nicht so leicht, die ganze Applikation skalierbar zu machen.

Andy Grunwald (00:12:24 - 00:12:31)

Du hast ein gutes Stichwort genannt. Leicht. Das ist auch so einer der Mythen. Alle denken, das ist leicht. Und du hast auch schon Kubernetes angesprochen.

Wolfi Gassler (00:12:32 - 00:12:41)

Genau, ich kaufe mir einen Kubernetes, ich nehme mir einen Kubernetes und drei Hetzner Nodes und die Sache hat sich out of the box skaliert. Fertig.

Andy Grunwald (00:12:41 - 00:12:54)

Und ein dritter Punkt, den ich auch schon oft gehört habe, dass es cool ist auf Scale zu arbeiten. Auch bei Bewerbungsgesprächen haben wir oft gehört auf die Frage, warum man hier arbeiten möchte. Es ist cool auf Scale zu arbeiten. Ich möchte mal auf Scale zu arbeiten.

Wolfi Gassler (00:12:54 - 00:13:55)

Was ja grundsätzlich stimmt. Also es ist ja cool auf Scale zu arbeiten. Die Frage ist, muss ich auf Scale arbeiten, wenn ich gar nicht auf Scale arbeiten muss? Und das ist ja das eigentliche Problem. Brauche ich wirklich Scale oder denke ich mir nur, es ist cool und ich mache irgendwas nur, weil es halt cool ist und weil ich gern diese Technologie lernen will. Was ja auch fair ist, wenn man die Technologie mal ausprobieren will, lernen will, ist ja alles in Ordnung. Aber dass das halt so die Default-Antwort ist, wir brauchen Kubernetes und das ist einfach das Einfachste und wir skalieren dann und Wir brauchen nicht drüber nachdenken und vielleicht, das ist ja auch so immer die Sache, vielleicht brauchen wir ja in Zukunft dann die Skalierung, weil wir hoffen ja, dass unser Business-Modell super funktioniert, braucht man nur auf die Statistiken schauen, dass wahrscheinlich 99 oder 95 Prozent aller Business-Modelle nicht funktionieren und nicht skalieren müssen, aber man denkt sich halt immer, man ist Teil von diesen 5 Prozent oder 10 Prozent und braucht diese Skalierung, darum baue ich sie jetzt schon mal. macht mein Leben schwerer, aber in Zukunft, in fünf Jahren, kann der Land skalieren. Dann, wenn die Technologie veraltet ist. Ironie, Ende.

Andy Grunwald (00:13:55 - 00:15:01)

Mit dem Argument, es ist cool, aufs Geld zu arbeiten, ja und nein. Ich verbinde das immer so mit, du möchtest etwas haben und dann hast du es und dann merkst du, du willst es eigentlich nicht haben, weil du vorher nicht wusstest, wovon du sprichst. Und ich lehne mich gerade ein bisschen weit aus dem Fenster, denn wenn man mit großen Infrastrukturen, einer High-Traffic-Webseite arbeitet oder Ähnliches, man lernt sehr viel. Ja, das stimmt. Man hat aber auch sehr viele Probleme, die man oft eigentlich gar nicht haben möchte, weil auf der einen Seite sind diese sehr schwer nachzustellen, denn nämlich oft nur unter Last. Also die Probleme kommen immer nur, wenn da ziemlich viel Traffic drauf ist. Wenn du Probleme hast, die unter sehr viel Traffic entstehen, müssen diese in der Regel sehr schnell gelöst werden. Du hast einen starken Zeitdruck. Wenn du diesen Zeitdruck hast, hast du in der Regel eine nicht oder nur halb funktionierende App. Das bedeutet, dein Stresslevel ist unglaublich hoch. Und all das führt dazu, dass dies auch in der Regel nicht zu klassischen Arbeitszeiten passiert, sondern außerhalb. Abends, wenn du vielleicht auf dem Geburtstag bist, am Wochenende, wenn du auch das Finalspiel der Weltmeisterschaft gucken möchtest oder oder oder. Und wenn man Ja, aber ich glaube.

Wolfi Gassler (00:15:01 - 00:15:32)

Dass das sehr viele Leute, die sagen, sie finden das cool, auf Scale zu arbeiten, wenn du das jetzt erwähnst, die würden wahrscheinlich alle sagen, ja, das ist genau das, was ich eigentlich will, bis sie es mal dann selbst erleben und vielleicht am Wochenende dann durcharbeiten müssen oder so. Aber grundsätzlich, ich glaube, das ist schon auch eine spannende Herausforderung. Aber man muss sich im Klaren sein, dass das, glaube ich, auch teilweise sehr anstrengend sein kann. Das stimmt natürlich, ja. Aber ich glaube viele finden das auch cool und wenn man mal sowas durchgemacht hat, hat man auch Geschichte zum erzählen, muss man ja zugeben.

Andy Grunwald (00:15:32 - 00:15:53)

Das faszinierende daran ist, ja technisch eine tolle Herausforderung, aber auch kulturell oder menschlich zwei Riesenprobleme. Erstens, wie findet das denn dein Lebensabschnittgefährte oder deine Lebensabschnittgefährtin, deine Frau findet das bestimmt nicht knorke. wenn du freitag abends vor dem rechner hängst und versuchst die webseite wieder hochzukriegen und die zweite geschichte ist kulturell wieso.

Wolfi Gassler (00:15:53 - 00:15:55)

Du bist doch ein held dann genau.

Andy Grunwald (00:15:55 - 00:16:22)

Das ist genau dieses zweite problem ist eine hero culture du kommst da rein bist der held weil das ein high visibility event ist nämlich ein inzident was auch nicht das ziel ist deiner techkultur also und der clue ist nein es ist nicht nur die operativ abteilung also nicht nur die systemadmins und co Bei diesen Events brauchst du nämlich sehr tiefes Wissen der Applikationen und da werden dann auch oft die Software-Engineers mit reingeholt. Also es ist nicht nur die DevOps-Leute und so weiter und so fort.

Wolfi Gassler (00:16:23 - 00:17:58)

Ein anderes klassisches Argument für Skalierung ist, wir können Kosten sparen, weil wir ja in der Nacht vielleicht die Server in der Cloud nicht mehr bezahlen müssen, weil in der Nacht ist wenig los oder im Winter ist wenig los und im Sommer ist viel los und wir fahren im Sommer unsere Kapazitäten nach oben und im Winter nicht und dafür brauchen wir diese Autoskalierung, die alles automatisch macht und darum investieren wir jetzt Zeit und Geld in diese Skalierung. Und da muss man sich schon wirklich überlegen, bringt mir das wirklich so viel? Ist meine Applikation und sind meine Ausgaben so hoch, dass mir da eine Autoskalierung zum Beispiel hilft? Oder ist es vielleicht einfacher, wenn ich einfach im Sommer ein paar Maschinen dazuschalte und irgendwas dumm kopiere als einen riesen Kubernetes Cluster aufsetze, der super fluide skalierbar ist und sich an jede nur erdenkliche Situation in der Theorie zumindest anpasst. Weil, wenn man sich das mal durchrechnet, mit einer Milchmädchenrechnung muss ich zugeben, aber wenn man sich das mal überlegt, eine Programmiererin kostet mal geschätzt 70 bis 100 Euro pro Stunde, super brutto Kosten mit allem drum und dran, teilweise wahrscheinlich sogar mehr. Und man baut jetzt zum Beispiel irgendwas skalierbarer, flexibler, rechnen wir mal ganz easy, zwei Wochen ist super schnell, dass man in zwei Wochen was umsetzen kann, würde ich sagen. Wir machen jetzt was skalierbar. Innerhalb von zwei Wochen können wir vielleicht auf drei Jahre verrechnen, also auf drei Jahre abschreiben. Wenn man jetzt noch ein bisschen Wartung dazu rechnet, 20% Wartung pro Jahr und wir sparen uns jetzt insgesamt 30% ein von unseren gesamten Cloud Kosten. Ab wann rentiert sich das, Andi? Was glaubst du?

Andy Grunwald (00:17:59 - 00:18:01)

Aus dem Woche heraus würde ich Jahre sagen.

Wolfi Gassler (00:18:01 - 00:20:36)

Ja, es kommt natürlich auf deine Rechnung drauf an, was du Cloud Rechnung hast oder für deine Infrastruktur bezahlst. Aber jetzt bei deinem simplen Beispiel, bei zwei Wochen Aufwand für eine Skalierung, was ja wirklich nicht lang ist, brauchst du Cloud Kosten oder Infrastruktur Kosten von über 10.000 Euro pro Jahr. Erst ab dann würde sich so eine Investition von zwei Wochen rentieren. Und das ist jetzt wahrscheinlich eher niedrig schon gerechnet. Also da kann man wirklich viele Server oder viel Infrastruktur mieten, vor allem wenn es dann nur im Sommer ist, manuell oder so, anstatt da wirklich zwei Wochen zu investieren, um irgendwas hochzufahren. Und ich bezweifle mal, wenn du eine Applikation komplett skalierbar machst, dass da irgendwie zwei Wochen ausreichen, eine Person. Kann ich mir also gar nicht wirklich vorstellen. Und wenn man sich das dann so durchrechnet, dann kommt man eigentlich sehr schnell an den Punkt, wo man sagt, okay, rendiert sich diese Skalierung oder diese Flexibilisierung von unserer App wirklich? Kann natürlich auch andere Einsparungen haben, natürlich, wenn man Debugging dadurch erleichtert, aber ganz oft ist es ja eher, dass man die Komplexität erhöht und alles viel, viel schwieriger wird in Zukunft. Du hast einen Bug und du musst da 20 verschiedene Stellen suchen, die Log-Dateien sind irgendwie komplizierter überhaupt zu finden, sind teilweise verteilt, du musst eigene Monitoring-Systeme wieder drüber bauen. Also es macht alles komplexer und da brauchst du wirklich ein hohes Budget, was du in deine Infrastruktur investierst, damit sich das wirklich am Ende überhaupt rentiert. Und ich glaube, das Gleiche ist auch bei einem Totalausfall. Wenn du sagst, okay, du willst ausfallsicher sein, was kostet dich ein Totalausfall, was ist verkraftbar und wie schlimm ist ein Totalausfall von drei Stunden jetzt in irgendeinem Bereich? Und das kann natürlich wichtig sein, wenn das jetzt ein System ist, was deine Produktionslinie, deine Roboter steuert und wo du wirklich Revenue, Umsatz verlierst. Oder ist das nur ein System zur Verwaltung von irgendwelchen Schlüsseln, wo man halt vielleicht gerade keine neue Berechtigung auf einen Schlüssel buchen kann. Diese Systeme sind sicher weniger wichtig. Also irgendwas, wo Live Traffic drauf ist. Oder vielleicht kann ich auch einfach damit umgehen, wenn die Seite mal eine Stunde offline ist. Steht vielleicht in Relation zu meinen Ausgaben immer noch nicht, das so ausfallsicher zu machen. Also das kann man sich, glaube ich, sehr hart durchrechnen. Und das machen aber sehr wenige, dass man das wirklich hart kalkuliert. Weil man kann alles bis ins Unendliche skalieren, ausfallsicher machen und ich kann jede Netzwerkleitung fünffach zur Verfügung stellen, damit die viermal ausfallen kann. Aber es wird auch niemand machen, weil es einfach in keiner Relation steht. Und ich glaube, diese Relation fehlt oft, dass man die wirklich sauber durchrechnet.

Andy Grunwald (00:20:37 - 00:21:05)

Es ist natürlich eine Bierdeckelrechnung und es kommt immer auf deinen Use Case an und es gibt vielleicht auch Use Cases auf der Welt, wo dies Sinn macht, aber im Allgemeinen ist der Engineering Aufwand deutlich höher als die Erspartenkosten. Jetzt reden wir hier schon die ganze Zeit von Skalierung und ob man es braucht und für wen es ist und allem drum und dran, aber eine Sache wurde noch nicht erwähnt und zwar, was skaliere ich denn da eigentlich? Klar, Applikationen, aber Applikationen sind ja nicht gleich Applikationen.

Wolfi Gassler (00:21:05 - 00:21:18)

Und an der Applikation hängt auch hinten viel dran. Also wir sprechen ja da nicht nur immer vom BHB-Code, sondern da hängt hinten ein Cash-Schnitt, Datenbank, andere Schnittstellen, der Payment-Provider, hängt ja alles hinten auch dran.

Andy Grunwald (00:21:18 - 00:22:06)

Im Allgemeinen spricht man von zwei Arten von Systemen. Auf der einen Seite hast du stateless-Systeme und auf der anderen Seite hast du stateful-Systeme. Stateless-Systeme sind, wie der Name schon sagt, Systeme, die keinen Zustand halten. Also eigentlich, ich nehme eine Anfrage entgegen und leite diese weiter oder ohne irgendeine Connection zu einem externen Service. Zwei Charakteristika sind eigentlich, dass man solche Systeme ohne Probleme einfach neu starten kann. Und, dass man diese horizontal skalieren kann. Horizontal heißt also in die Breite. Das bedeutet, du hast eine Instanz und du kannst einfach eine zweite, dritte, vierte daneben stellen. Die klassischen Beispiele sind halt so ein Webhook-Server, der die Nachrichten in eine Message-Queue schreibt, eine statische Webseite oder halt auch eigentlich das ganz klassische PHP-Frontend oder eine REST-API.

Wolfi Gassler (00:22:06 - 00:23:22)

Aber auch sowas wie ein Cache ist meiner Meinung nach stateless. Der hat zwar einen State, aber der kann jederzeit wieder neu starten. Den kann man einfach mal durchdrehten und der fängt dann einfach wieder an seinen Cache neu aufzubauen. Das heißt auch da kann man eigentlich jederzeit die Applikation den Cache neu starten oder verteilen. Dass man einfach einen zweiten irgendwo hochfährt ist auch kein Problem. Also das ist, glaube ich, die Charakteristik, dass man eben wirklich jederzeit das Ding durchdrehten kann, neu starten kann, drei Instanzen davon hochfahren kann, ohne dass es ein Problem gibt. Die sind wirklich unabhängig voneinander und können sich auch immer wieder von Null aufbauen. Wenn du eine Datenbank durchdrehtest und den Speicher wegreißt und alles bei Null startet, wirst du ein Problem haben. Und das ist eigentlich der große Unterschied. Und diese Dinge sind natürlich viel leichter zu skalieren, wenn du stateless bist. weil du da einfach von Grund auf schon keine Abhängigkeiten hast, außer jetzt auf externe Systeme, aber die sind ja immer da. Und wenn du dann ein Spike im Sommer hast, das ist kein Problem, du stellst einfach drei zusätzliche Maschinen hin, fährst dieses Service dreimal noch hoch parallel, brauchst natürlich einen Load Balancer, das macht es natürlich schon auch wieder komplizierter, aber fährst diese Dinger dreimal hoch und hast sonst überhaupt keine Schwierigkeiten, musst nichts daran ändern, wenn du das ganze stateless hältst.

Andy Grunwald (00:23:23 - 00:23:31)

Das Gegenstück dazu sind Stateful-Systeme, also Systeme, die einen dauerhaften beziehungsweise persistenten Zustand halten.

Wolfi Gassler (00:23:31 - 00:23:32)

Also die Datenbank.

Andy Grunwald (00:23:32 - 00:24:12)

Datenbanken sind ein Beispiel. Session Storages kann man auch als Datenbank bezeichnen. Sachen, Applikationen, die eigentlich Daten speichern. Und das Hauptcharakteristika ist eigentlich, dass man einen persistenten Speicher hat, eine Synchronisation mit anderen Services. Und oft sind solche Systeme deutlich komplizierter zu skalieren. Und zu skalieren meine ich eigentlich, horizontal zu skalieren. Das bedeutet, mehrere Instanzen davon zu haben. Bei persistenten Daten kommt noch dazu, wie zum Beispiel Datenbanken oder Object Storage und wenn wir von Object Storage reden, reden wir sowas wie Dateisysteme, Amazon S3.

Wolfi Gassler (00:24:13 - 00:24:37)

Gibt es eigentlich Stateful Services, die keine Datenbanken sind? Also wo ich irgendwas abspeichere und wieder rausholen will? Oder sind es eigentlich immer Datenbanken? Oder Dateiablagesysteme, wie du es auch immer nennen willst, aber halt wo du Daten reinsteckst und wieder rausholst. Mir fällt gerade nichts ein. Ist aber wahrscheinlich auch die Definition von persistentem Speicher eigentlich. Weil ich will ja immer irgendwas rausbekommen, sonst würde ich es nicht persistent abspeichern.

Andy Grunwald (00:24:37 - 00:24:49)

Ich habe das Gefühl, das ist so eine klassische Frage, wir sitzen in der Kneipe, der Wirt bringt kontinuierlich neues Bier und wir hängen uns den ganzen Abend auf dieser Frage auf. Ich glaube, das ist so die Frage, weil es ist schon Definitionssache.

Wolfi Gassler (00:24:49 - 00:25:05)

Also ich weiß nicht, was ihr bei euren Stammtischrunden da besprecht, aber ich bin ja überrascht, was es da in Duisburg alles noch so gibt. Okay, aber wie kann man das jetzt persistent abspeichern? Ist ja auch nicht so einfach, gerade in so verteilten Systemen. Weil sobald man was horizontal skaliert, hast du ja ein verteiltes System.

Andy Grunwald (00:25:06 - 00:25:55)

Naja, also eigentlich gibt es da zwei Ahnen. Zumindest fallen mir gerade zwei Ahnen ein. Auf der einen Seite kannst du den Storage, auf dem gespeichert wird, teilen. Ganz klassisches Beispiel und gegebenenfalls oft nicht klug zu machen, aber du hast irgendwelche Network Attached Disks, also Festplatten, und die werden einfach in mehrere Cloud-Server gehangen. Das ist natürlich dann eine Frage, wie sieht dein Write-versus-Read-Pattern aus. Das bedeutet, dass du eigentlich deine Storage teilst Oder du legst obendrauf eine Logik, um die entsprechenden Daten halt zu schaden. Also das bedeutet, du stückelst die eigentlich in mehrere Teile und hast verschiedene Kopien auf verschiedenen Servern. Cluster-Filesysteme wie zum Beispiel Ceph oder ähnliches machen sowas sehr viel. Oder auch Front-Applikationen wie Vitesse, die kümmern sich halt um das Schaden von MySQL-Datenbanken.

Wolfi Gassler (00:25:56 - 00:27:46)

Und die Dinger sind natürlich wirklich kompliziert. Wenn man sich sowas mal reinholt, auch das ist wirklich sehr gefährlich meiner Meinung nach, weil das ist mittlerweile sehr einfach sich reinzuholen, so ein Cluster-File-System. Das geht mittlerweile wirklich gut. Aber wenn du da mal ein Problem hast, dann hast du glaube ich wirklich ein Problem, weil die sind super schwierig zu beheben, diese Cluster-File-System-Probleme. weil die natürlich auch hochkomplex sind und wenn man da wenig Ahnung hat, ist es wirklich schwierig. Ich kann mich an einen Fall erinnern, ein Hoster, den ich damals verwendet habe, Philoo war das, die hatten alle ihre virtuellen Maschinen auf einem Clusterfile-System und denen ist damals vor einigen Jahren, vielleicht sogar vor zehn Jahren, da war das wahrscheinlich sehr neu, ist wegen dem Stromausfall, wo dann auch noch irgendwie die Batterien versagt haben, wirklich der Strom parallel auf sehr vielen Nodes ausgefallen oder auf allen Nodes sogar. Und das, damals SEV war es glaube ich auch, bin mir nicht ganz sicher, hat aufgegeben, weil einfach mehrere Nodes parallel ausgefallen sind und die haben für zweieinhalbtausend virtuelle Maschinen ihr Cluster-File-System verloren. Und die haben, glaube ich, am Ende zwei Wochen gebraucht. Sie haben alles wieder herstellen können, sie haben sogar irgendwie die Entwickler von Amerika eingeflogen, aber die haben zwei Wochen gebraucht, um diese zweieinhalbtausend virtuellen Maschinen wieder ans Laufen zu bekommen, manuell, händisch. Ich war sehr froh, dass ich damals meinen Mail-Server verteilt hatte auf zwei Rechenzentren. Aber da sieht man schon, wie komplex so Cluster-Filesysteme sein können. Und da holt man sich wirklich Komplexität ins Haus. Und das vergisst man eben oft, wenn man so schnell einfach sagt, ja, es ist eh alles bekannt, hol mir da einen Ceph rein, die zwei, drei Befehle und dann läuft das schon alles. Das läuft, solange es kein Problem gibt. Und wenn es ein Problem gibt, dann kann es auch sein, dass der Ausfall dann wesentlich länger dauert. Also auch da ist immer wieder abzuwägen, Was hole ich mir an Komplexität wieder an Bord?

Andy Grunwald (00:27:46 - 00:28:12)

Du hast das Wort gefährlich genutzt. Soweit würde ich nicht gehen. Aber ich stimme dir schon zu. Du musst wissen, was du tust. Du musst wissen, wie viele Replika du von deinen Daten hast. Du musst wissen, wie deine Infrastruktur sich verhält. Auch wenn Festplatten deutlich stabiler geworden sind und Netzteile und allem Drum und Dran, Hardwarefailures gibt es immer und immer und immer wieder. Und wenn du eine falsche Konfiguration hast, dann sind auch deine Daten in einem replizierten und verteilten Dateisystem einfach futsch.

Wolfi Gassler (00:28:13 - 00:30:32)

Und vor allem bei so einem Cluster-File-System, das ist ja in sich nicht ausfallsicher. Also wenn ich ein Problem auf der Software-Ebene habe im Cluster-File-System, dann betrifft es womöglich alle meine Nodes automatisch, weil die alle voneinander abhängig sind auf dieses Cluster-File-System. Also ihr habt da auch wieder eine Art Single Point of Failure auf der Software-Seite im Cluster-File-System. Natürlich sind das gute Systeme mittlerweile und sehr stabil. Aber trotzdem, wenn es da ein Problem gibt, dann betrifft es plötzlich alle meine Nodes quer durch die Bank und auch das muss ich mal überlegen und da kann ich natürlich auch wieder dagegen arbeiten, dass ich zum Beispiel mehrere Cluster-File-Systeme verwende und nicht nur eines über alle meine Nodes hinweg und solche Dinge. Also auch da wieder intelligent einsetzen und nicht vergessen, dass man sich da eben Komplexität und vielleicht einen neuen Single Point of Failure an Bord holt. Und weil es so komplex ist, lagern das Leute auch gerne an den Hoster aus, dass ich also dieses Ceph-Filesystem einfach verwende, was mir der Hoster zur Verfügung stellt. Zum Beispiel jetzt bei Hetzner zum Beispiel kann man Volumes mounten in mein System und es läuft im Hintergrund transparent mit irgendeinem Cluster-Filesystem, ist scheinbar sicher auf irgendeinem Rate, weiß man nicht und man bindet dann direkt diese Volume ein. Der Nachteil an so einem System ist zum Beispiel wieder, dass man das nur auf einem Node einbinden kann. Also wenn jetzt der Node down ist und flöten geht, dann kann ich auf einem neuen Node der Hochfahrt natürlich wieder dieses externe System einbinden. Das ist aber dann weniger dynamisch. Also es können nicht mehrere Nodes auf ein Volume direkt zugreifen. Das heißt, ich muss dann wieder zum Beispiel meine Datenbanken auf einen Node pinnen, dass die wirklich nur auf diesem Node hochgefahren wird, wo ich dieses externe Volume eingebunden habe. Wenn der stirbt und woanders die Datenbank dann hochfährt, muss ich irgendwie sicherstellen, dass dieses Volume wieder eingebunden ist. Also auch da steigt dann wieder die Komplexität und die hat mit automatisch nur, weil die Kubernetes habe oder ein Docker Swarm und da ein externes Volume gemountet habe, was sicher ist, dass das dann automatisch wieder skaliert und ausfallsicher ist, automatisch umschaltet. Auch das ist wieder ein Trugschluss und holt mir viel Komplexität mit rein, die vielleicht sogar noch selber programmieren muss, dass die richtigen Volumes gemountet werden, eingebunden werden. Und es kann ja jeder mal probieren einfach einen Node abzuschalten, wie gut das System dann am Ende skaliert.

Andy Grunwald (00:30:32 - 00:30:50)

Stichwort Ausschalten ist ganz gut. Da ist natürlich die Königsklasse nicht manuell ausschalten, sondern die berühmt-berüchtigten Affen im Datacenter loszulassen. So wie Netflix es damals gemacht hat, beziehungsweise macht. Da hab ich auch nur Wissen, was man so liest. Was Netflix macht, nennt sich Chaos Monkey.

Wolfi Gassler (00:30:50 - 00:30:56)

Moment, seid ihr in eurem DevOps-Team nicht so sicher drauf, dass ihr einen Affen loslassen könnt?

Andy Grunwald (00:30:56 - 00:31:15)

Ich sag ja, das ist schon Königsklasse. Chaos Monkey ist ein Tool, Was zwar auch kontrolliert losgelassen wird, aber deine Infrastruktur wird mehr oder weniger einem Affen überlassen. Eine Applikation, die Chaos Magie heißt. Und diese Applikation schaltet zufallsmäßig den einen oder anderen Teil deiner Applikation ab.

Wolfi Gassler (00:31:15 - 00:31:21)

Der Infrastruktur, oder? Also zieht irgendwo das Netzwerk weg oder eine Platte oder einen ganzen Node?

Andy Grunwald (00:31:21 - 00:31:43)

Ja, nicht nur Infrastruktur. Kann auch einfach sein, dass die Netzwerk-Connection degraded oder ähnliches. Ja, gibt es verschiedene Failure-Modus. Es wird auf jeden Fall eine Störung im System eingeführt und dann soll geguckt werden, verhält sich das System wie erwartet. Das ist natürlich Königslasse, wenn man das automatisiert macht. Meine Erfahrung ist eigentlich, dass sehr, sehr viele Infrastrukturen bereits an simplen Sachen scheitern, wie zum Beispiel einfach mal eine Applikation neu starten.

Wolfi Gassler (00:31:43 - 00:31:54)

Jetzt haben wir schon die ganze Zeit von horizontaler Skalierung gesprochen, Andi. Das heißt, ich stelle den zweiten Rechner nebendran, der das gleiche macht. Aber es gibt ja auch die vertikale Skalierung.

Andy Grunwald (00:31:54 - 00:32:15)

Ja, wenn Leute von Skalierung sprechen, meinen sie eigentlich horizontale Skalierung. Und der Grund ist recht simpel. Die Hyperscaler, Google, Microsoft, Amazon, das ist das, was sie in ihrem Marketing verkaufen. Wenn du nicht klarkommst, stell einfach einen Server daneben. Horizontale Skalierung bedeutet also wirklich in die Breite skalieren, neue und zusätzliche Server daneben stellen.

Wolfi Gassler (00:32:15 - 00:32:54)

Das war ja damals auch die Idee von Google, wie Google gestartet hat, dass sie gesagt haben, okay, wir verteilen eine Suchanfrage von dir auf ganz, ganz viele Rechner und weil wir zu wenig Geld haben, stellen wir da ganz viele billige Rechner hin, die können alle ausfallen, fallen ständig aus, aber die kosten wenig Geld und dadurch können wir überhaupt diese Masse an Webseiten überhaupt verarbeiten in unserer Infrastruktur mit tausenden Rechnern, aber super billigen Rechnern. Das ist so die ganz klassische horizontale Skalierung. Ganz viel billige Rechner, die aber ständig ausfallen können und mir ist komplett egal, wenn es ausfällt. Eigentlich der Start der Cloud, würde ich fast sagen. Heutzutage muss man immer mit einem Ausfall rechnen in der Cloud.

Andy Grunwald (00:32:54 - 00:33:01)

Von Hetzner gibt es ein schönes Video auf YouTube. Da macht jemand eine Datacenter-Tour in einem dieser Hetzner-Datacenter.

Wolfi Gassler (00:33:01 - 00:33:03)

Mal linken wir in den Show Notes natürlich.

Andy Grunwald (00:33:03 - 00:33:17)

Und da gibt es ein schönes Bild, wie du ganz viele klassische Desktop-Tower in einem Regal siehst. Und das ist eigentlich genau das, was der Wolfgang gerade erzählt hat. Ganz viele günstige Commodity-Hardware hinstellen, weil du ja halt in die Breite skalierst.

Wolfi Gassler (00:33:17 - 00:33:28)

Wobei man natürlich das auch mit teurer Hardware machen kann. Also man kann auch mit teurer Hardware in die Breite skalieren, aber ganz oft wird es mit billiger gemacht, weil man ja dann ausfallsicher ist durch die Masse. Und bei der vertikalen Skalierung?

Andy Grunwald (00:33:28 - 00:33:39)

Ja, das ist ein Punkt. Die Vertikalisierung wird oft hinten angestellt oder vergessen. Umgangssprachlich heißt es, du stellst einfach einen dickeren Server dahin. Du hast also einen existierenden Server und packst da mehr RAM rein, mehr CPU, mehr Disk.

Wolfi Gassler (00:33:40 - 00:33:56)

Wobei das heutzutage in der Cloud meistens eine Checkbox ist oder irgendeinen Slider, den du nach oben ziehst. Das ist ja heutzutage nicht mehr so, dass man wirklich Hardware austauschen muss, sondern wenn man Infrastructure-as-a-Service verwendet, dann ziehe ich da meinen Slider nach oben und hab plötzlich statt 100 GB RAM 200 GB RAM.

Andy Grunwald (00:33:56 - 00:34:06)

Und diese Art von Skalierung wird meist vergessen. Warum, weiß ich leider nicht. Die ist natürlich nicht so cool wie, als wenn ich meiner Applikation über 10 Server schade, sondern dass ich einfach nur...

Wolfi Gassler (00:34:06 - 00:34:08)

Und sie ist so einfach, das ist ja auch langweilig.

Andy Grunwald (00:34:08 - 00:34:35)

Sondern... Du stellst einfach einen dickeren Server dahin. Und das Beste ist, du musst kein Data Sharding betreiben. Dieser ganze Aufwand, wie teuer doch Skalierung ist, fällt halt auch weg, weil in der Regel packst du mehr Hardware rein, startest die Kiste neu und abfahrt. Und du kannst immer noch für die nächsten zwei, drei Monate ohne Probleme agieren. Also das ist so ein klassisches Beispiel, wo du einfach Hardware aufs Problem schmeißt, anstatt Engineering Power.

Wolfi Gassler (00:34:35 - 00:35:37)

Und wie wir alle wissen, heutzutage ist Hardware einfach viel viel billiger. Der Klassiker früher bei den Datenbanken, also wirklich vor Jahrzehnten, da war die Hardware so teuer, dass man einfach zehn Administratoren drauf geworfen hat. Die waren billiger als die Hardware und wenn die irgendwo eine Millisekunde rausholen haben können, war das schon von Vorteil. Heutzutage hat sich das einfach alles umgedreht. Die Menschen sind so teuer geworden, zu Recht, dass man einfach über die Hardware viel einfacher skalieren kann, anstatt die Spezialisten zu haben und auch die Software ist einfacher geworden, muss man auch dazu sagen. Und wir haben ja auch schon öfters erwähnt, wie viel ein Server eigentlich abfackeln kann. Man unterschätzt es ja wirklich. und wirst du mit einem simplen, gar nicht riesen Server, an Traffic zum Beispiel von einer Web-App abdecken kannst, wo es Millionen von Requests sind an einem Tag und das Ding fängt nicht mal schwitzen an. Also da muss man sich schon überlegen, ob es wirklich Sinn macht, in die Breite zu skalieren und die Komplexität wieder auf sich zu nehmen. Also wie du richtig sagst, Andi, wird oft vergessen und ist ganz oft einfach die schnellere und einfachere Lösung.

Andy Grunwald (00:35:37 - 00:35:58)

Ab wann weiß ich denn, wann ich entweder Hardware daneben stelle, Hardware vertikal skaliere, also dickeren Server dahin stelle, oder ab wann ich eigentlich mein Software Engineering Team da dran setzen soll und sage, optimiert mir bitte die Applikation, denn ich denke auch, jede Applikation hat noch unten drunter sehr viel Potenzial, um ein bisschen mehr Performance aus der existierenden Hardware rauszuholen.

Wolfi Gassler (00:35:59 - 00:37:24)

Könnte man ja auch unter dem Punkt Skalierung eigentlich sehen, weil wenn ich meine Applikation schneller mache, skaliert sie ja auch besser. Und da gibt es ja ganz oft so low-hanging fruits, wenn ich jetzt an irgendeine Webseite oder Webapplikation denke, dass man zum Beispiel eine CDN verwendet für die Bilder, dass man eben nicht alle Bilder von dem klassischen Webserver ausliefert, sondern das auf einen anderen Server auslagert, um Traffic zu sparen, die SSL-Terminierung zum Beispiel auslagert an den Loadbalancer. So kleine Maßnahmen, die oft eine große Wirkung haben können und da brauche ich dann noch gar nicht die Applikation auf 3, 5, 10, 20 Servern verteilen, sondern kann auch so das Ganze schneller machen. Das Schwierige ist natürlich diese Low Hanging Fruits zu finden, weil die teilweise nicht so offensichtlich sind. Aber auch da kann man wirklich sich überlegen, investiert man die Zeit in solche Low Hanging Fruits, um die Applikation schneller zu machen? Oder baue ich schon wirklich irgendwas Großes, wo ich dann skalieren kann mit Kubernetes oder sonst irgendwas. Da muss man halt einfach die Zeit investieren, um überhaupt diese Low-Hanging-Fruits zu finden. Und da kann man sich ja irgendein Kontingent zurechtlegen, dass man sagt, okay, wir schauen mal, ob wir da irgendwelche einfachen Dinge finden, die wir optimieren können. Wir investieren ein paar Tage und dann sollte man das eigentlich schon wissen, ob da überhaupt Möglichkeiten sind. Also das ist, glaube ich, immer gut, egal in welche Richtung man geht. Aber man muss das natürlich irgendwie begrenzen, weil sonst macht man da irgendwelche Micro-Optimizations, die einfach keinen Sinn machen.

Andy Grunwald (00:37:24 - 00:37:32)

Ja, dann hast du, glaube ich, noch die klassische Frage für alle BWLer. Was ist denn eigentlich günstiger unterm Strich? Weil die Leute hast du ja so oder so angestellt. Also die Software-Engineer sitzen ja da.

Wolfi Gassler (00:37:33 - 00:38:05)

Ja, aber die können meistens dann auch irgendwas anderes machen, Produkt weiterentwickeln. Also es wäre nicht so, dass wir jetzt immer zu viele SoftwareentwicklerInnen haben im Team und die kurz davor sind aus Langeweile zu sterben. Also keine Ahnung, was du für Teams hast, aber ich kenne diese Teams noch nicht. Insofern können die derweil andere Sachen machen und das ist ja auch immer so ein Argument, dass man nur mit so Stundensätzen rechnet, so wie in meiner Milchmädchenrechnung sollte man eigentlich auch nicht mehr sagen, weil Mädchen können nicht schlechter rechnen.

Andy Grunwald (00:38:05 - 00:38:06)

Bierdeckelrechnung.

Wolfi Gassler (00:38:06 - 00:39:23)

Bierdeckelrechnung ist besser, ja genau. Die Männer mit Bier können am schlechtesten rechnen, darauf können wir uns einigen. Also die Bierdeckelrechnung, back of an envelope, wie man so schön sagt im Englischen, also auch die ist halt oft ein bisschen verzerrt, weil es sind ja nicht nur die eigentlichen Personenstunden, die mir fehlen an finanziellen Mitteln, sondern auch die Personen sind dann belegt mit diesen Optimierungen, das heißt, die kosten mir Geld und ich habe keine Möglichkeit, diese Personen mit anderen Dingen zu beschäftigen, die vielleicht wichtiger sind, irgendwie das Produkt weiterzuentwickeln, irgendwelche Bugs zu fixen, Andere Dinge, die mich vielleicht sogar schneller weiterbringen würden, als jetzt irgendeine Skalierung. Das heißt, ich habe den Verlust auf zwei Seiten. Aber diese Opportunitätskosten sind halt immer schwer abzuschätzen, aber die darf man auch nicht vergessen, vor allem jetzt, wo es so schwierig ist, Leute zu bekommen und alle Teams sowieso komplett überfordert sind schon. Da muss man dann wirklich klar priorisieren, was macht mehr Sinn? Die Skalierung, die Optimierung, Beziehungsweise ist das überhaupt nötig und bringt mir das am Ende so viel oder kann ich vielleicht einfach simpel das ganze duplizieren, 10 Server hinstellen, manuell, keine Abhängigkeiten, kein Kubernetes, total simpel, reicht das vielleicht auch als Skalierung. Also da gibt es ja viele, viele verschiedene Möglichkeiten, die man einfach durchrechnen muss und sich durchüberlegen muss.

Andy Grunwald (00:39:24 - 00:39:48)

Ja und dann hat man natürlich noch eine Herausforderung und zwar ist das die gesteigerte Komplexität von Skalierung, besonders bei Stateful-Systemen wie Datenbanken. Da geht es dann nicht nur auf die Optimierung deines eigenen Sourcecodes, sondern halt auch oft an die Infrastruktur. Man hängt einen Cache vor die Datenbank, man hängt irgendeine andere Applikation wie zum Beispiel eine Proxy für deine SQL-Datenbank oder vielleicht sowas wie Vites, was einfach deine Daten schadet.

Wolfi Gassler (00:39:49 - 00:40:49)

Wobei man ja dazusagen muss, dass Dinge wie Cache oder Proxy SQL, was ja auch ein Cache ist für MySQL oder aus Cache verwendet werden kann, das sind ja noch die einfachen Dinge. Also die würde ich ja noch besser sehen, weil der Cache ist relativ einfach installiert, ein Proxy SQL, den kann ich einfach davor hängen. Aber wenn du im Vergleich eine geschadete Datenbank verwendest, wie Tess oder ähnliches, und wenn du jetzt nicht gerade PlanetScale als Hosted wie Tess verwendest, sondern das wirklich selbst machst, dann hast du da viel, viel mehr Komplexität, als wie wenn du da jetzt ein, zwei, drei Caches davor hängst. Und ganz oft kann ein Cache aber extrem viel abfangen, weil wenn man sich überlegt, in der Datenbank hast du halt ganz oft nur irgendwelche Read-Patterns und schreibst sehr wenig und die Datenbank ist komplett überfordert, aber oft nur beim Lesen und dann ist es relativ einfach, Cache davor zu hängen, eine Read Replica dazu zu hängen, weil das steigert noch nicht die Komplexität in so einer Weise, wie wenn jetzt wirklich eine echte verteilte Datenbank einsetzen muss, administrieren muss und die ganzen Probleme einer verteilten Welt habe.

Andy Grunwald (00:40:49 - 00:41:07)

Du hast nicht unrecht, aber eine Proxy-SQL allein als Cache zu bezeichnen, ist auch irgendwie unter Proxy-SQLs Würde, meines Erachtens nach. Natürlich. Besonders, wenn du nämlich mit solchen Sachen anfängst, wie du blockst einfach SQL-Querys, du schreibst die on the fly neu, was nämlich auch Proxy-SQL kann.

Wolfi Gassler (00:41:07 - 00:41:10)

Oder du leitest sie an verschiedene Server um, ist ja dann auch eine Eskalierung.

Andy Grunwald (00:41:11 - 00:41:38)

All sowas kann die Wurzel jeden übelt sein, denn die Infrastrukturabteilung konfiguriert irgendwas am ProxySQL um, wo die Application Engineers keine Ahnung von haben und buff, 20% der SQL Queries liefern keine ordnungsgemäßen Resultate mehr zurück, werden geblockt oder oder oder. Was meinst du eigentlich, wieviel Stunden, Tage und vielleicht sogar Wochen da drauf gehen, um nur einen kleinen Config Change zu finden?

Wolfi Gassler (00:41:39 - 00:42:40)

Aber das zeigt einfach, wie komplex die ganze Sache ist, sobald du neue Dienste einführst. Und wenn du Skalierung willst und wenn du Kubernetes willst und Microservices oder sonst irgendwelche Dinge, die machen dein Leben einfach viel komplexer. Du brauchst dann auch das richtige Monitoring dazu. Also alles wird komplizierter und auch das Debugging und Bugfinden überhaupt wird komplizierter, weil du halt an hundert Stellen deine Log-Dateien verteilt hast, deine Monitoring-Daten, die verschiedenen Services, die zusammenspielen, Netzwerk wird viel wichtiger. Also es gibt schon viele Dinge, die da komplexer werden, egal ob das jetzt ein Proxy, SQL ist, ein Cache oder eine verteilte Datenbank. Mit jedem System, das du dazu nimmst, wird deine Infrastruktur komplexer. Und darum bin ich zum Beispiel auch jemand, der immer schaut, wenn man ein neues System einführt, braucht man das wirklich oder kann man es vielleicht einfacher lösen. Und darum bin ich auch ein großer Fan, dass man manche Dinge einfach in einer Datei abspeichert, anstatt eine Datenbank einzuführen, weil es einfach zu handeln ist und die Komplexität nach unten geht.

Andy Grunwald (00:42:41 - 00:43:14)

Und jetzt haben wir immer komplett gegen Skalierung gewittert. Das ist alles schlecht, das ist alles böse, das ist alles teuer, das ist alles komplett unnötig. Und man sollte sich wirklich fragen, macht man das? Und am besten ist halt, wenn man keinen Code schreibt, jada, jada, jada. Aber kommen wir mal zu den Punkten, was man eigentlich haben sollte, um sich diesem ganzen Thema Skalierung den eigentlich mal ordnungsgemäß widmen zu können. Also was ist denn nicht die Grundlage, die man braucht, um an die Frage, soll ich skalieren, muss ich skalieren und was muss ich anfassen, den ordnungsgemäß und strukturiert angehen zu können.

Wolfi Gassler (00:43:15 - 00:44:39)

Und genau da sind wir eigentlich wieder beim Monitoring, weil die Metriken und die Daten, die wir zuerst sammeln müssen, um überhaupt die Frage zu klären, müssen wir skalieren. Die steht eigentlich im Vordergrund, beziehungsweise das müssen wir als erstes machen, dieses Metriken und Daten sammeln von unserer Applikation, damit wir genau wissen, wo ist unser Bottleneck, Ist es Network? Ist es unsere Power, die Compute-Power, die wir haben? Ist es der RAM? Ist es der Storage? Ist es das Netzwerk zwischen Storage und meiner Applikation? Also da können ja überall Bottlenecks sein. Und diese Daten muss ich mal zuerst erfassen und ich muss genau alles monitoren und Metriken erstellen, damit ich dann überhaupt das für meine Entscheidung verwenden kann und eine Entscheidungsgrundlage habe. Und erst dann kann ich genau sagen, okay, was muss ich skalieren in meiner Infrastruktur? Weil ich kann ja die Applikation zehnmal kopieren, wenn mein Storage zu langsam ist im Hintergrund, dann wird mir das alles nichts helfen. Oder wenn ich die Applikation skaliere, zehn Instanzen von meiner Applikation habe, hinten aber die Datenbank hängt, die auf einem Node läuft, die ist dann auch nicht ausfallsicher automatisch. Und skalieren tut die meistens auch nicht auf einem Node. Also auch da wieder immer genau herausfinden, wo ist mein Bottleneck? Und dann kann ich mir überlegen, wie kann ich dieses Bottleneck beheben? Horizontal skalieren, vertikal skalieren. Vielleicht reicht es einfach, eine zusätzliche Netzwerkschnittstelle anzubinden und ich brauche gar nicht meine Applikation in der Form skalieren.

Andy Grunwald (00:44:39 - 00:44:49)

Vorteilhaft ist natürlich, dass ihr Daten über mehrere Tage, vielleicht sogar Wochen habt. Also das bedeutet Time Series Data über einen Monat oder zwei, wenn nicht sogar vielleicht über Jahre.

Wolfi Gassler (00:44:49 - 00:44:56)

Ich glaube, sogar wenn es saisonale Geschichten sind, dann musst du das über ein Jahr machen, weil wie wirst du sonst deinen Sommertraffic abschätzen?

Andy Grunwald (00:44:56 - 00:45:13)

Das ist natürlich dann auch herausfordernd, wie speichert man das ab, wie macht man das schnell abfragbar und so weiter und so fort. Aber nur so könnt ihr diese klassischen Sägezähne, Traffic geht hoch, Traffic geht runter, nur so könnt ihr diese Sägezähne erkennen und dann wirklich anfangen darüber nachzudenken, wo was optimiert wird.

Wolfi Gassler (00:45:14 - 00:46:01)

Und wenn man es ganz schön macht, dann hat man nicht nur die Daten, sondern sammelt nochmal künstlich auch noch Daten, indem man zum Beispiel Load-Tests macht. Wenn man jetzt weiß, okay, ich habe irgendwo eine Problemstelle in meinem Netzwerk oder in meiner Compute-Power bei der Application, dann mache ich nochmal gezielt Load-Tests, um herauszufinden, okay, ist es wirklich dieser Bereich und wie kann ich den skalieren? Dann kann ich das mal künstlich testen in meinem geschützten Bereich. Hilft mir das überhaupt was, wenn ich das jetzt auf zwei Rechner hochfahre und denselben Loadtest fahre? Habe ich dann überhaupt Vorteile oder bricht mir dann das Netzwerk zusammen? Was es auch immer ist, also ich kann das nochmal künstlich in einer geschützten Umgebung testen und erst dann kann ich wirklich meinen Produktivbetrieb in die Richtung treiben oder in die Richtung gehen, dann die Skalierung auch im Produktivbereich umzusetzen.

Andy Grunwald (00:46:02 - 00:46:09)

Loadtests an sich klingen einfach, sind sie aber bei weitem nicht. Der Software-Engineer, der zum Over-Engineering tendiert.

Wolfi Gassler (00:46:09 - 00:46:11)

Du kannst auch Andy dazu sagen.

Andy Grunwald (00:46:11 - 00:46:30)

Da denkt man immer, ja lass uns doch den Live-Traffic kopieren, shadowen. Das ist alles nicht so einfach, besonders wenn ihr eine Applikation habt hinter einem Login. Wie transportierst du Session-Daten und so weiter und so fort. Richtige Loadtests, und zwar nicht nur immer nur auf einen Endpoint, sondern mit verschiedenen Daten. All sowas ist eine Kunst für sich.

Wolfi Gassler (00:46:30 - 00:46:41)

Da hilft dir übrigens in der Datenbankwelt auch der Proxy SQL, weil wir ihn schon so hoch gelobt haben. Der kann dir natürlich auch alle Queries, die so laufen, einfach mal weglocken und dann hast du einen super Loadtest für später.

Andy Grunwald (00:46:42 - 00:47:11)

Und diese ganze Thematik, von der wir hier sprechen, bedarf natürlich genauer Kenntnis über deine App und die involvierten Komponenten. Jetzt sagt jeder, ach, meine Verantwortlichkeit ist ein Microservice, da kenne ich mich in- und auswendig. Ja, das mag richtig sein, aber wie gut kennst du denn die Library, die zu deiner Datenbank connectet? Wie gut kennst du denn deinen Kafka-Producer oder Consumer? Wie gut kennst du denn die Library und wie die sich unter dem Fehlerfall verhält, die zum anderen Microservice connectet, gRPC oder ähnliches?

Wolfi Gassler (00:47:12 - 00:47:21)

Oder die externe Payment-Schnittstelle, weil die kann man noch schlechter testen. Wie kannst du einen Load-Test auf deine Payment-Schnittstelle fahren, dass 30.000 Leute gleichzeitig zahlen wollen?

Andy Grunwald (00:47:21 - 00:48:12)

Und genau diese Libraries, auf die ihr euch dann immer so verlasst, auf die kommt es nämlich im Fehlerfall nämlich an, weil die machen nämlich das Heavy Lifting, die machen das Verhalten der Connection, gegebenenfalls ein Reconnect und so weiter und so fort. Und da kommt zum Beispiel eine Technik ins Spiel Request Deadlines, Reconnects und Exponential Backoffs. Das bedeutet, wie lang darf eigentlich ein Request durch eure Infrastruktur dauern und ab wann tötet ihr den, also brecht den Request ab und was sind die Maximal-Deadlines? Wenn man keine Request-Deadline definiert hat, dann rennt man in eigentlich in die Summe aller Standard-Timeouts und die sind sehr oft auf 30 Sekunden eingestellt, was natürlich für ein HTTP-Request Welten sind. Also ich glaube 30 Sekunden im Internet ist, glaube ich, wer wartet 30 Sekunden bis eine Webseite lädt.

Wolfi Gassler (00:48:13 - 00:48:26)

Und du hast dann ganz viele Applikationen und Teile in deiner Infrastruktur, die alle auf Requests warten plötzlich und alle Speicher belegen und noch aktiv sind, Ressourcen belegen. Die können alleine in einem Domino-Effekt dann womöglich irgendwas lahmlegen.

Andy Grunwald (00:48:26 - 00:48:49)

Das ist so der Klassiker, wie man sich selbst halt abschießt, weil man halt durch die wartenden Requests alle Ressourcen belegt. Deswegen Request-Deadlines ist eine tolle Sache, dass du sagst, okay, ein Request darf maximal drei Sekunden durch meine Infrastruktur dauern und alles, was länger als drei Sekunden dauert, brichst du automatisch ab. Ja, dann kriegt der User einen Fehler. Ist schon richtig. Ist aber besser, wenn ein User einen Fehler kriegt, anstatt dass alle Leute einen Fehler kriegen.

Wolfi Gassler (00:48:49 - 00:49:22)

Wir haben jetzt sehr oft zu Dinge erwähnt, die wir auch in unserem Bilderbuch schon am Anfang erwähnt haben, wie Microservices oder Kubernetes, Autoscaling, die ganze Datenbankskalierung. Da sind wir jetzt überall nicht ins Detail gegangen. Das machen wir dann gerne mal in einem der nächsten Episoden und schauen uns die Dinge mal im Detail an, wie man das skalieren kann und was es da für Probleme gibt. Aber für heute schließen wir mal das Märchenbuch. Gott sei Dank hält uns ja die ganze Industrie mit Märchen auf Trab, da haben wir ja dann in zukünftigen Märchenstunden noch viel abzuhandeln.

Andy Grunwald (00:49:22 - 00:49:59)

Und wenn man uns so zuhört, denkt man wir sind Gegner der Skalierung, aber so ist das alles nicht. Was wir eigentlich nur machen wollen ist, ein realistisches Bild vermitteln, dass nicht alles Friede, Freude, Eierkuchen ist und dass wir nicht immer auf dieser tollen kleinen grünen Wiese mit Sonnenblümchen rumstolzieren, sondern dass der Satz, Skalierung ist einfach, ein sehr großer Mythos ist und dass da bei weitem mehr zugehört, als einfach nur ein Server daneben steht. Deswegen, wir sind ja keine Feinde, wir wollen euch nur sagen, überlegt euch zweimal, welche Route ihr geht, denn ihr macht da einfach ein riesen Fass auf.

Wolfi Gassler (00:49:59 - 00:50:13)

Und es gibt ganz viele Bereiche, wo man Skalierung braucht, aber ich glaube in ganz vielen Fällen wird da auf Spatzen mit Kanonen geschossen und ich glaube diese Fälle sollte man einfach probieren zu vermeiden bzw. zu verringern.

Andy Grunwald (00:50:13 - 00:50:15)

Ansonsten wünschen wir euch viel Spaß beim.

Wolfi Gassler (00:50:15 - 00:50:17)

Skalieren, sogar mit Kubernetes.

Andy Grunwald (00:50:17 - 00:50:19)

Bis nächste Woche. Tschüss. Ciao.