Ein Software-Architektur im Stream Podcast

1: Simple Cloud in der Praxis

Wie betreibt man eine Webanwendung in der Simple Cloud – also auf transparenter Basis-Infrastruktur (VPS, Networking, Firewalls) ohne Cloud-Managed-Services? Mit Dirk Breuer bespreche ich, wie unser Setup bei fejo.dk, einem der führenden Portale, um Ferienhäuser in Dänemark zu buchen, funktioniert und wie wir dabei auf Einfachheit gesetzt haben. Wir gehen das Setup durch: von Terraform über Ansible zu Docker und Capistrano.

Transkript

Lucas Dohmen: Willkommen im Maschinenraum. Wir sind heute zu Gast bei Softwarearchitektur im Stream und reden über Simple Cloud in der Praxis. Mein Name ist Lucas Domen und ich bin Principal Consultant bei SWAGLab. Und zu Gast habe ich heute Dirk Breuer. Hallo Dirk, magst du dich mal kurz vorstellen?

Dirk Breuer: Sehr gerne. Ich bin Dirk, ich bin freier Softwareentwickler seit sehr langer Zeit mittlerweile, und bin vor allen Dingen im Bereich Webentwicklung unterwegs, mache da so Betriebssachen auch mit und vor allen Dingen mit der Programmiersprache Ruby on Rails, was ich noch viel länger mache, als dass ich als freiberuflicher Softwareentwickler unterwegs bin.

Lucas Dohmen: Super. Bevor wir ins eigentliche Thema starten, habe ich dir noch eine Frage mitgebracht. Wann hast du eigentlich das letzte Mal Production kaputt gemacht?

Dirk Breuer: Also das genaue Datum kann ich dir jetzt gar nicht genau sagen, aber allzu lange ist es nicht her und so ganz hart kaputt war es auch nicht, aber es war auf jeden Fall offline, ungeplant, es gab keine Wartungsseite und die Leute haben auf jeden Fall einen 503 gesehen, also zählt das glaube ich. Und zwar habe ich ja gesagt, ich mache hauptsächlich Rails und jeder, der das vielleicht schon mal benutzt hat, da gibt es sowas wie Datenbankmigration, die legt man an, super praktisch, die werden dann einfach immer ausgeführt beim Deployment, was auch in der Regel super ist, aber manchmal, wenn man Dinge tut, die vielleicht etwas länger gehen, so wie größer angelegte Indizes ändern oder eine, Stored Functions ändern, die auch die andere dann brauchen und man dann nicht daran gedacht hat, ah, das wird gleich deployed, da müssten wir vielleicht eine Wartungsseite online schalten, damit er das sauber durchführen kann, ja, dann geht dann schon mal die Produktion down. In der Regel ist es dann auch wieder in Ordnung, aber das war auf jeden Fall das letzte Mal.

Lucas Dohmen: Ja, ich meine, das ist ja auch so ein Kritikpunkt an der Art und Weise, wie Ruby on Rails das macht. Ich meine, Ruby on Rails ist ja nicht die Einzigen, die das so machen, aber dass diese Migrations so ein bisschen Teil der Anwendung sind und so mitlaufen, das führt ja manchmal doch zu Problemen.

Dirk Breuer: Ja, das ist an vielen Stellen super praktisch, macht andere Probleme weniger. Aber in solchen Fällen muss man halt explizit daran denken, okay, du machst da eine Migration, die Einfluss darauf hat, die potenziell deine Produktion dann in dem Moment lahm legt. Merkst du halt nicht lokal und das merkst du in der Regel auch nicht, wenn du es auf Staging deployst, weil du da nicht die ganze Zeit drauf guckst während des Deployments. Da ist nicht die ganze Zeit Last drauf und ja.

Lucas Dohmen: Ja, und ich finde auch, das ist auch so ein bisschen ein Zeichen dafür, wie sicher wir uns damit fühlen, in Produktion zu gehen, weil man halt gar nicht mehr so das krass babysittet, sondern irgendwie man shipped halt und dann funktioniert es halt, weil es halt in, 99,9 Prozent der Fälle einfach völlig problemlos funktioniert. Und das ist aus meiner Sicht eigentlich ein gutes Zeichen. Und wenn es dann halt irgendwie ein bis zwei Minuten sind, dann geht ja auch nichts wirklich kaputt. Also wenn man jetzt nicht irgendwie eine medizinische Anwendung baut oder so.

Dirk Breuer: Das stimmt, das ist korrekt. Schöne Frage auf jeden Fall, Lucas.

Lucas Dohmen: Danke dir. Dann würde ich sagen, wir starten jetzt mal rein in das Thema. Worüber wollen wir eigentlich heute sprechen? Also ich habe den Dirk eingeladen, weil Dirk und ich arbeiten zusammen an fejo.dk und dort machen wir beide Operations. Wir haben letztes Jahr diesen Umstieg gemacht von AWS auf Hetzner Cloud und, darüber wollen wir gar nicht so sehr jetzt sprechen, wie diese Migrationen gelaufen sind. Dazu haben wir auch schon mal einen Vortrag gehalten, wer sich dafür interessiert. Wir wollen heute mal darüber sprechen, wie sich das so anfühlt oder wie das genau aussieht, in einer Simple Cloud eine Rails-Anwendung laufen zu haben. Das ist das Thema heute. Und darum haben Dirk und ich überlegt, wir wollen euch da so ein bisschen durchführen. Wie wäre es, also quasi, wir haben alle Server gelöscht und jetzt deployen wir das Ganze nochmal neu. Was würde da passieren? Welche Tools sind da am Werk? Warum haben wir diese Tools ausgewählt? Welche Alternativen gäbe es? Und warum haben wir für diesen Fall diese Alternativen gewählt? Und dabei ist es uns ganz wichtig, das heißt nicht, dass das die beste Wahl für jedes System ist. Also das ist klar. Aber wir denken, dass es für viele eine Option ist, die unterschätzt wird, weil viele zu komplexeren Tools greifen, als sie das vielleicht bräuchten für den Use Case. Das ist so ein bisschen das, was wir euch erzählen wollen. Aber bevor wir das können, müssen wir so ein bisschen was zu Fejo erzählen, damit man einschätzen kann, wie das so ist. Magst du damit einmal kurz anfangen, Dirk? Wie sieht Fejo denn so aus?

Dirk Breuer: Also Fejo ist eine Ferienhausvermittlungsplattform für Ferienhäuser in Dänemark, suggeriert die Endung DK vielleicht schon und auch ausschließlich in Dänemark. Also man kann keine in Norwegen oder Schweden oder sowas oder in Norddeutschland, nur Dänemark. Und das ist ein relativ spezieller Ferienhausmarkt, der dänische. Gut, es gibt Ferienhäuser überall und Ferienwohnungen, aber der dänische Ferienhausmarkt ist insofern speziell, dass es eben, die sind im Grunde fast alle in privater Hand, die Ferienhäuser. Die Dänen haben einfach Ferienhäuser, sehr, sehr viele. Und Teile davon werden vermietet an Touristen. Auch für sich selber, aber vor allen Dingen an Touristen ist es auch vorgeschrieben. Und weil die da so viele von haben, gibt es entsprechend Infrastruktur. Das heißt, nicht jeder ist da Privatvermieter, sondern es gibt, so Agenturen und Büros, die sammeln dann diese Ferienhäuser und kümmern sich um die Vermietung, kümmern sich darum, dass die Verträge geschlossen werden, Schlüsselübergabe, Reinigung, dieser ganze Kram und auch Ansprechpartner vor Ort. Weil der Däne, dem das Haus gehört, der Dänin, die sitzt vielleicht in Kopenhagen und trinkt nen Kaffee, hat keine Lust darauf, dann kontaktiert zu werden, wenn der deutsche Urlauber da ein Problem hat. Und das sind die Ansprechpartner, mit denen wir kommunizieren. Von denen bekommen wir die Daten über diese Häuser. Mit denen rechnen wir sozusagen die Provision auch ab, die wir dann für eine Buchung bekommen. So verdient Fejo Geld für diese Vermittlung. Und da ist dann auch relativ, wird schon deutlich, wo ein Großteil der Arbeit liegt, nämlich die Aufarbeitung dieser Daten, die müssen irgendwie von den Partnern zu uns kommen, die sind in ganz vielen unterschiedlichen Formaten, die müssen irgendwie verarbeitet werden, das heißt, es gibt bei Fejo einen relativ großen Anteil an, Hintergrund Datenverarbeitung, wo wir in die Datenbank schreiben und dann gibt es eben den ganzen Teil, wo man als Kundin ein Ferienhaus suchen kann, buchen kann und das vermitteln wir dann. Ein wichtiger Aspekt ist, es gibt keine Bezahlfunktion auf Fejo, also das Bezahlen läuft völlig out of band. Das ist insofern relevant, weil das natürlich so ein paar Dinge sehr viel einfacher im Betrieb macht. Wir müssen keine Webhooks für Zahlungsanbieter haben, auch so Sicherheitssachen, sind einfach nicht so relevant für die Plattform, wie wenn du eine Kreditkartenanbindung hättest oder was ähnliches. Also bestimmte Zertifizierungen fallen weg und dergleichen. Das ist, finde ich, immer ein relativ wichtiger Punkt, wenn man sich auch so Architektur anguckt und Entscheidungen, weil das einfach deutlich Sachen einfacher macht. Ja, genau. Und dann der andere wesentliche Aspekt, das hat auch gar nichts mit Ruby und Rails zu tun. Wir haben uns entschieden, dass es so eine ganz klassische Server-Site gerenderte Seite ist mit JavaScript, was Dinge anreichert. Im Grunde funktioniert die Anwendung mehr oder weniger auch ohne JavaScript. Das ist natürlich Quatsch, aber das ist so der Grundgedanke dahinter. Und ich glaube, diese Aspekte sollten einigermaßen gut aufspannen, mit was wir hier hantieren und da könnt ihr dann ja schauen, ob das dann für euch auch passt, Teile daraus. Weil das hat auf jeden Fall Auswirkungen auf die Architektur, die wir in der Infrastruktur gewählt haben.

Lucas Dohmen: Genau. Aber ich finde, einen wichtigen Aspekt hast du noch nicht erwähnt und das ist die Größe des Teams. Also wir reden darüber, dass wir im Team sechs Leute sind, also im Entwicklungsteam sechs Leute sind. Das heißt, es ist kein riesiges Team, wo man jetzt irgendwie einen Operations-Teil hat und einen Dev-Teil oder sonst irgendwas, sondern wir sind insgesamt sechs.

Dirk Breuer: Das sind nicht sechs Vollzeitäquivalente. Vollzeitäquivalente sind weniger. Ja, das ist ein wesentlicher Aspekt. Wir sind ein relativ kleines Team und dazu muss man auch sagen, auch das Team, was im Backoffice Kundenanfragen und Verwaltungssachen, macht, ist auch nicht viel größer. Personenzahlen sind das mehr, aber das ist das Vollzeitäquivalent noch weniger im Grunde. Instagram ist Fejo ein sehr überschaubares Team und das ist ein wesentlicher Aspekt, dass wir versuchen sowohl in der Entwicklung als auch im Backoffice sehr effizient zu arbeiten.

Lucas Dohmen: Ja, definitiv. Und ich finde auch, das muss man auch noch mal betonen, weil Konkurrenten ja durchaus wesentlich größer sind. Also das scheint ja gut zu funktionieren, dieses Setup, dass das mit so einem relativ kleinen Team sehr gut läuft. Und ich finde auch noch mal zu ergänzen ist, dass der Großteil des Entwicklungsteams tatsächlich entweder Freelancer wie du oder Externe wie ich sind. Das heißt, wir müssen auch damit rechnen, dass mal jemand eine Zeit lang nicht verfügbar ist. Das heißt, auch das ist Teil von den Entscheidungen, die wir treffen.

Dirk Breuer: Und vollständig remote.

Lucas Dohmen: Stimmt.

Dirk Breuer: Gleich, wenn wir über organisatorische Aspekte sprechen, auch noch ein wichtiger Aspekt. Das ist vollständig remote und es arbeiten, nicht alle zur gleichen Zeit. Also wir müssen sowieso auch asynchron kommunizieren. Daher, das sind die Aspekte, die da mit reinspielen in die Dinge, über die wir heute wahrscheinlich reden werden.

Lucas Dohmen: Genau, das denke ich auch. Gut, dann würde ich sagen, starten wir mal rein in die Infrastruktur. Also, wir haben schon erwähnt, wir sind irgendwie aus AWS weggegangen. Wir sind auf einen, was wir Simple Cloud Anbieter gewechselt. Das ist bei uns Hetzner Cloud, aber es ist ganz bewusst so, dass wir gar nichts haben, was uns nur Hetzner Cloud bieten würde. Weil das ist genau das, was wir vermeiden wollen, was jetzt bei AWS eben sehr üblich ist, dass das Wegwechseln sehr teuer ist. Das, was wir bei Hetzner Cloud bekommen, kriegen wir bei mehreren anderen Anbietern auch. Das heißt, wir wollen uns da auch nicht so fest dran binden. Deswegen ist es für unsere Erklärung heute gar nicht so relevant, dass wir auf Hetzner Cloud sind. Wir können nur sagen, es funktioniert gut. Das ist der Teil, den wir dazu erzählen können, aber im Prinzip spielt es für den Rest keine Rolle. Das heißt, was benutzen wir von Hetzner Cloud? Wir benutzen da ganz intensiv natürlich die VMs, die uns zur Verfügung gestellt werden. Wir benutzen Load Balancer, wir benutzen die Storage, also das S3-Äquivalent von denen und natürlich dieses ganze Firewalling und Networking, was so ein System anbietet. Und das ist im Prinzip schon alles, oder habe ich was vergessen, Dirk?

Dirk Breuer: Nee, so technisch hast du die wesentlichen Sachen genannt. Ein wichtiger Aspekt, der natürlich da vorhanden sein muss, wenn man jetzt was anderes nimmt und den ja auch viele andere dann anbieten, ist natürlich eine API, über die man diese Infrastruktur fernsteuern kann. Wir wollen das auf jeden Fall nicht irgendwie mit Clicky-Bunty in so einem Web-Interface machen. Nicht, weil wir uns dem zu fein sind, sondern weil wir einfach das im Team verteilen müssen und keine Anleitung schreiben wollen und müssen bitte hier klicken und dann da klicken und dann ändert sich das Interface, was durchaus vorkommt. Auch bei AWS kommt das regelmäßig vor, dass sich das Interface ändert, sondern wir möchten das gerne im Code haben, dieses sogenannte Infrastructure as Code, damit man es eben versionskontrolliert haben kann. Wir können Codereviews durchführen und man hat ausführbare Dokumentation. Das finde ich ist immer ein ganz gutes Bild an der Stelle.

Lucas Dohmen: Genau, genau. Und es bringt uns natürlich auch den Vorteil, also wir haben ein Staging Environment, in dem wir Changes halt vorab nochmal in produktionsnahe Umgebung testen können, und das wollen wir natürlich so nah an Produktion haben wie möglich. Das heißt also, klar, das ist runterskaliert, das sind weniger Server, das sind kleinere Server, das wäre ja einfach Geldverschwendung, aber es ist an sich das gleiche und deswegen ist für uns dieses Infrastructure as Code auch eine der wesentlichen Aspekte, die wir auch nicht missen wollten im Vergleich zu einem Hyperscaler wie AWS. Also das wollen wir haben. Wir wollen eben nicht alles auf Oldschool, einfach so einem Root-Server, wo man alles so von Hand einrichtet und dann muss man irgendwie Staging genauso einrichten und wenn man was ändert, muss man daran denken, es auf allen Environments zu machen. All so was wollen wir natürlich vermeiden und das bringt uns dann glaube ich auch direkt schon zum ersten Tool in der Toolbox und das ist dann Terraform. Ja. Und als wir den Vortrag gehalten haben, wurden wir auch direkt gefragt, warum Terraform und nicht Open Tofu. Können wir gerne gleich nochmal darauf eingehen. Aber grundsätzlich, was bietet ein Tool wie Terraform? Das bietet genau das, was Dirk sagt. Es nimmt eben diese API, die der Provider zur Verfügung stellt und erlaubt uns halt so eine Deklaration zu schreiben. Da steht dann halt drin, wir haben hier so einen Server, davon haben wir fünf Stück und da ist eine Netzwerkregel dran und da hängt übrigens eine feste IP dran und so weiter und so fort. All das können wir dort textuell beschreiben, sodass es zum einen für alle sichtbar ist, also alle im Team können da einfach reingucken und sehen, so sieht Produktion aus. Das ist halt keine Dokumentation in dem Sinne, also es ist schon Dokumentation, aber es ist halt wahre Dokumentation, weil wenn wir daran was ändern, dann ändert sich auch Produktion mit quasi. Also natürlich müssen wir das ausführen, aber grundsätzlich ist es eben die Beschreibung der Realität und das Tool ist halt aus meiner Sicht mittlerweile auch schon gut abgehangen. Ich weiß gar nicht, wie lange es Terraform schon gibt, aber eine ganze Weile, und funktioniert einfach sehr, sehr gut. Und was muss eine Cloud dafür bieten, damit das funktioniert? Die muss eben diese APIs bieten, der Dirk gesagt hat. Es muss eine API geben, mit der man sagen kann, hey, leg mal eine VM an, hey, löscht mal eine VM. All diese Sachen müssen über eine API zur Verfügung stehen und nicht nur über, Klicken in einem Web-Interface. Und dann muss sich halt jemand hinsetzen und einen sogenannten Provider schreiben. Das ist Code, der eben dieser Terraform-Sprache die ganzen Objekte zur Verfügung stellt, wie eine VM oder einen Load-Balancer oder was auch immer. Und man kann sich vorstellen, bei AWS ist das sehr, sehr umfangreich, weil es da eben sehr, sehr viele Services gibt, die man da einfügen kann. Und das ist bei Hetzner übersichtlicher. Da gibt es halt einfach nicht so viele Services. Da müssen sie auch nicht so viele Sachen schreiben. Und genau, wir benutzen eben diesen Provider und der hat bisher uns auch keine Probleme gemacht. Ich glaube, wir haben nur eine Sache gefunden, die gefehlt hat. Das waren die Storage, das S3 in Anführungsstrichen, was nicht da war. Aber sonst ist alles da und hat für uns sehr gut funktioniert, oder?

Dirk Breuer: Ja, auf jeden Fall. Also genau, das S3 war das Einzige, was so im Großen und Ganzen gefehlt hat. Und ja, das wird halt kontinuierlich auch weiterentwickelt, aber das meiste funktioniert ganz gut. Was auf jeden Fall so eine Besonderheit ist, wo man vielleicht drüber stolpert, das ist bei AWS auch so gewesen, die verlangen ja, dass so eine Instanz einen Namen bekommt. Und eigentlich wollen wir ja gar keinen Namen vergeben, es ist ja wurscht, wie das Ding heißt. Und die kann man dann zufällig generieren. Und das war auf jeden Fall bei Hetzer ein bisschen komplexer, oder ist immer noch etwas umständlicher, den so zufällig zu generieren, weil wenn man eine neue Instanz hochfährt, dann möchte man vielleicht, oder das machen wir zumindest, erst die neue Instanz vor oben haben, bevor man die alte abschaltet. Einfach um sicher zu gehen, dass alles da ist, bevor man das alte Ding runterfährt, was dann auch im laufenden Betrieb nämlich ein Update der Server erlaubt. Und die Namen dürfen sich natürlich nicht duplizieren, also kann ich nicht zweimal irgendwie eine Worker-Instanz irgendwo haben, sondern muss da immer so etwas zufälliges hinten dran hängen. Das ist aber jetzt nicht super spezifisch, das ist nur eine Sache, über die man vielleicht das erste Mal so stolpert, wenn man das macht.

Lucas Dohmen: Stimmt. Ja, guter Punkt. Genau. Und um das jetzt mal konkreter zu machen, was beschreiben wir jetzt da? Also wir haben in unserem Terraform-Ding beschreiben wir unsere Web-Knoten. Also auf den Web-Knoten kommen wir gleich zu, da läuft diese Rails-Anwendung drauf, da läuft auch noch ein bisschen mehr drauf, können wir auch gern gleich noch was zu sagen. Dann haben wir einen sogenannten Image Server. Das ist einfach ein Server, der liefert die Hausbilder aus. Da benutzen wir eine Software, die heißt Image Proxy, also imgproxy, die wir jetzt auch schon lange benutzen und mit der wir sehr zufrieden sind. Die funktionieren einfach so völlig langweilig. Also wir müssen uns darum nie kümmern. Ich glaube, ich weiß gar nicht, ob wir die überhaupt anfassen mussten seit einer halben Ewigkeit. Und die bietet uns so Funktionalität wie Resize mal das Bild auf 800 mal 600 oder sowas. Weil wir wollen responsive images haben. Wir haben viele Leute, die mobil auf die Seite zugreifen. Also sollen die natürlich auch kleinere Bilder bekommen. Das ist quasi gerade mal so das Service von dem, was das bietet. Aber das ist so die für uns wichtigste Funktionalität, dass es eben schnell Bilder ausliefern kann und eben solche Transformationen wie Resizing oder in andere Bildformate umwandeln.

Dirk Breuer: Genau, vor allem die anderen Bildformate. Das ist der spannende Punkt, warum wir das dann am Ende genutzt haben. Weil es nämlich erkennt, okay, kann der Client, der das anfragt, webP oder will er lieber AVIF? Und der prüft auch, ist das AVIF kleiner, ist das webP kleiner oder nehme ich einfach das JPEG oder was auch immer davor liegt. Genau, weil das eben Dinge sind, die, wenn man sie einkauft, sehr schnell sehr teuer werden. Also wenn man das bei Cloudflare macht oder Cloudinary oder es gibt ja genügend Dienste, die das anbieten, dann wird das relativ schnell teuer. Und selbst wenn man nur das Resizing selber macht und dann das Erkennen, okay, will ich WebP oder AVIF ausliefern, dann zum Beispiel von Cloudflare oder seinem CDN machen lässt, ja, dann hat man erst noch einen extra Schritt. Das ist aus unserer Erfahrung einfach nicht auch sehr robust gewesen. Dann wurde doch das Falsche ausgewählt. Dann hat sich der Lighthouse-Report beschwert. Und deswegen haben wir ja vor einiger Zeit gesagt, okay, wir nehmen einfach diese imgproxy. Das funktioniert einwandfrei. Das ist ein Docker... das ist in Go geschrieben, aber es läuft als Docker-Container irgendwo und macht einfach, was es soll, ohne zu murren.

Lucas Dohmen: Genau, genau. Das ist eine gute Zusammenfassung. Genau. Und daneben haben wir dann noch Worker-Nodes. Dirk hat ja eben schon ausgeführt. Die sind tatsächlich bei uns, brauchen die mehr CPU als die Web-Worker, weil wir halt so viel importieren und verwalten müssen im Hintergrund. Und auf der technischen Ebene ist das auch einfach die Rails-Anwendung, die wir so geschrieben haben. In Rails ist es so, das ist ja auch in anderen Programmsprachen oder in anderen Frameworks anders, dass man eben solche Worker im Code mit definiert. Und dann kann man halt einfach eine weitere Instanz davon hochfahren und sagen, hey, du lauschst übrigens auch auf Jobs hier und arbeitet die halt im Hintergrund ab. Das ist das, was die Worker für uns tun. Jetzt habe ich Web Worker gesagt, das wäre ja völlig verwirrend. Genau, die Worker für uns tun. Auch nochmal auf der technischen Ebene ist es eben so, dass wir dabei Postgres als den, in Anführungsstrichen, Message Bus benutzen, also der die Nachrichten weiterleitet von der Anwendung an die Worker, was auch für uns sehr solide funktioniert. Wir hatten früher da Redis für im Einsatz und jetzt machen wir das mit Postgres und das funktioniert sehr, sehr gut. Können wir auch gerne noch ein paar Sachen zu den Shownotes werfen, wer sich dafür interessiert, weil früher, also kurzer Seitennotiz. Hatte sich das so zum Anti-Pattern entwickelt. Also viele haben gesagt, mach das lieber nicht, das ist zu langsam, das skaliert nicht. Aber es gibt halt mittlerweile doch viele Sachen in Postgres, die das wesentlich verbessert haben, dass das jetzt wunderbar funktioniert. Also wo das halt früher relativ brute force war, klappt das jetzt halt einfach total unaufgeregt, würde ich jetzt mal sagen. Weil ich glaube, auch damit hatten wir, seitdem wir live gegangen sind, eigentlich keine Probleme. Nicht nur eigentlich.

Dirk Breuer: Das hat keinerlei Probleme gemacht. Wobei man, also wir verarbeiten sehr viel im Hintergrund, aber nicht an Menge. Also für unsere Verhältnisse sind das schon ein paar 10.000 Jobs, die da jeden Tag laufen. Aber das sind jetzt nicht Millionen Jobs pro Stunde, die da durchgeschoben werden. Also da muss man dann vielleicht noch als Hinweis schon nochmal gucken, passt das dann immer noch? Wenn ich wirklich so sehr hohe Anforderungen an niedrige Latenz habe, ob das dann mit Postgres immer noch so hinhaut, das muss man einfach einmal durchmessen am besten. Das muss man auch mit Redis durchmessen, ob das alles passt. Da ist man dann einfach in einem anderen Scope. Aber das funktioniert super für uns. Wir haben zum Beispiel aber ja auch den Cache in die Postgres verlagert. Das geht auch mittlerweile recht gut. Das war auch vorher bei Redis. Das war einfach bei AWS sehr einfach. Man klickt sich einfach eine Redis-Instanz oder diese Elastic Cache-Instanzen, wie sie dann da heißen, und kriegt das einfach fertig hingestellt. Und der Grund war ja, wir wollten möglichst wenig Abhängigkeiten haben. Wir hätten dann Redis selber betreiben müssen. Das wollten wir nicht. Da haben wir allerdings Probleme gehabt mit dem Cache. Das ist nicht so problemlos gelaufen, weil die Implementierung für den Cache in Postgres bei Rails ist der Meinung, man muss die Tabellen trotzdem loggen, was für ein Cache herzlich irrelevant ist, ob der geloggt ist oder nicht. Und das hat den Durchsatz deutlich verbessert.

Lucas Dohmen: Ja, genau. Aber auch da, also es war wirklich, es war sehr langsam geworden, Aber es ist nicht völlig kaputt gegangen. Aber es war halt wirklich, ja, also wir waren überrascht darüber, dass wir uns das darum selber kümmern mussten, ehrlich gesagt, weil wir gedacht haben, das wird ja wohl standardmäßig in dieser Implementierung so sein. Wir haben da gar nicht drüber nachgedacht. Aber so ist das halt manchmal mit diesen Details, dass man dann merkt, okay, vielleicht hätten wir das doch ganz genau anschauen müssen. Genau, aber so klappt das auch wieder unaufgeregt, würde ich es einfach nennen. Also jetzt cachen wir halt in der Datenbank, die halt einfach nicht persistiert im Prinzip. Das funktioniert sehr, sehr gut. Genau, das heißt also, was haben wir jetzt bisher beschrieben an VMs? Wir haben Webnodes, wir haben Worker-Nodes, wir haben diese Image-Nodes. Dann haben wir Datenbank-Knoten. Da haben wir eine sehr bewusste Entscheidung getroffen, wirklich nur eine zu haben. Aber da die Datenbank so ein spezielles Thema ist, haben wir überlegt, da reden wir am Ende nochmal drüber. Wir schieben jetzt die Datenbank mal zur Seite. Wir sagen einfach, da ist ein Node, da läuft eine Datenbank drauf. Der Rest kommt später. Genau. Und dann haben wir noch einen ganz kleinen Server, den Proxy. Den brauchen wir für manche der Partner. Wenn wir von denen Daten importieren, dann erwarten die eine feste IP aus Gründen. Und um dem entgegenzukommen, ist das halt ein einfacher Proxy. Alle Requests, die an diese Partner gehen, gehen einmal durch diesen Proxy durch. Ist nicht so schlimm, funktioniert. Auch wieder sowas, was uns lange nicht mehr überhaupt beschäftigt hat. Also wir gucken da, glaube ich, gar nicht mehr so richtig drauf. Der läuft halt einfach so.

Dirk Breuer: Ja, der läuft einfach vor sich hin.

Lucas Dohmen: Genau. Und das ist auch der Knoten, dem wir eine feste IP zugewiesen haben. Und der Rest hat keine festen IPs. Also der, genau. Ja, dann würde ich sagen, lass uns noch mal kurz über den Loadbalancer sprechen. Das ist ja so ein Leidenschaftsthema von dir, Dirk, das überlasse ich mal dir.

Dirk Breuer: Also den Loadbalancer, den nutzen wir von Hetzner und das hat den, also wir hätten den natürlich auch selber als Node zur Verfügung stellen können. Das ist kein Problem. Was ich sehr sympathisch daran finde, das auszulagern auf den Dienstleister, das war bei AWS auch so, das geht auch bei vielen anderen so, dass der nämlich dann TLS-Terminierung macht. Ich muss also keine Secrets auf meine VMs spielen, sondern lade die quasi in die Cloud da hoch, konfiguriere das da drüber. Manchmal erlauben die dir dann ja auch, dass die da automatisch gemanagt werden und verlängert werden und all so ein Kram. Das benutzen wir also da. Das ist sehr angenehm. Und die regeln dann, okay, da sind jetzt nur von den drei Nodes, die eigentlich antworten sollten, sind nur zwei gesund, also wird der andere rausgenommen. Ja, wir haben am Ende auch total unaufgeregt. Und der Hauptgrund ist im Grunde die TLS-Terminierung und dass der Endpunkt eben auf deren Hardware läuft und nicht bei uns, wenn wir eine VM dann da durchläuft. Und wir uns dann noch darum kümmern müssten. Das spielt auch in das Firewall-Thema dann rein, das wir auch von Hetzner benutzen. Also die Kisten sind alle nicht von außen erreichbar, außer über SSH dann entsprechend, um irgendwie drauf deployen zu können und alles anderes eben gesperrt. Nur der Load Balancer kann eben auf den HTTP-Endpunkt zugreifen in den einzelnen Kisten. Und der Worker zum Beispiel, der hat überhaupt gar keinen, der exposed gar keinen HTTP-Point an der Stelle.

Lucas Dohmen: Ja, genau. Ja, das ist auch ein wichtiger Punkt. Also die Netzwerkregeln sind auch extrem übersichtlich. Also es ist jetzt kein Dschungel von tausend von Regeln, weil es ist sehr, sehr klar. Also ich glaube, das kann sich auch jeder und jede, die zuhört, denken, wie diese Regeln ungefähr aussehen, wer welcher Knoten auf welchen anderen Knoten zugreifen kann. Also ja, auch wieder einfach gehalten. Aber wie machen wir das denn mit dem Autoscaling, Dirk?

Dirk Breuer: Gar nicht. Also dazu musst du vielleicht kurz einmal umreißen, was Autoscaling bei so einem Hyperscaler bedeutet. Das ist ja der Name Scaler im Hyperscaler mit drin. In meiner Wahrnehmung war das damals so eines der coolen Features von AWS. Du hast einen Autoscaler und der skaliert automatisch, wenn du ganz viel Zeug brauchst. Und dann denkt man so, boah, wie cool, dann kann ich dann nachts, da habe ich nur einen Server und dann tagsüber, wenn es so richtig brummt, dann habe ich irgendwie zehn Server und dann stellt man fest, man braucht überhaupt immer nur einen. Also vor allen Dingen mit zunehmender Leistungsfähigkeit der einzelnen Maschinen. Und dazu, ich hole jetzt einmal ein bisschen länger aus. Irgendwann sind ja dann, also man kann ja nicht beliebig kleine Maschinen nehmen, weil an einer beliebig kleinen Maschine, die hat zwar wenig CPU, die hat aber auch wenig I/O, die hat wenig RAM, die hat wenig alles, also die ist sowieso nicht nutzbar für irgendwas, nicht Triviales oder Naives. Daher, man muss sowieso eine Grundgröße nehmen, damit man irgendwie einen garantierten I/O-Durchsatz bekommt bei AWS, damit man irgendwie garantiert RAM bekommt und auch garantiert nicht nur I/O-Netzwerk, sondern I/O auch an die Platte, die da angeschlossen ist. Also all diese Dinge muss man sowieso ein Mindestmaß an Instanz nehmen. Und die sind in der Regel sowieso groß genug, um so eine Standard-Webanwendung zu machen. Wie gesagt, diese Worker, die laufen dann eben mehr. Und wenn man jetzt sich vorstellt, okay, ich habe eine Anwendung, keine Ahnung, da weiß ich ganz genau, wann ich diese Jobs mache, dann kann ich das vielleicht hoch und runter skalieren. Aber bei Fejo ist. Rund um die Uhr werden da Dinge ausgeführt. So ein bisschen im Tagesverlauf so geshifted, was wichtiger ist oder was weniger wichtig ist. Aber im Grunde läuft ja die ganze Zeit, was auch damals wenig Sinn ist, das zu machen. Aber, angenommen, wir wollen das gerne haben mit dem Autoscaler, ist das halt cool, weil der Autoscaler sagt halt, pass mal auf, hier ist so eine Launch-Configuration, heißt das bei AWS, und die beschreibt quasi, was da laufen soll. Und dann sagt man dem Autoscaler, pass mal auf, ich hätte davon gerne fünf Stück. Sorge einfach dafür, dass immer fünf Kisten laufen. Und wenn es irgendwie, dann kann man dann so Metriken einstellen, wenn dann die Last hochgeht, dann fährst du bitte noch weitere hoch. Der hat ja dann diese Konfiguration da liegen. Und dann kann er einfach neue hochfahren. Und das sorgt zum einen dafür, dass so Lastspitzen automatisch abgefangen werden, theoretisch. Das ist immer so in der Theorie total einfach, aber das bedeutet, ihr müsst euch ja auch dann im Klaren sein, wenn ich jetzt 10 mehr Webnodes habe, also ich habe 5 und ich verdoppel das auf 10 und meine Datenbank ist aber gar nicht für die Menge an Connections ausgelegt, dann bringt das ja nichts. Also dann muss ich vielleicht auch das auch mit also ganz so einfach ist das nicht, wie man sich das vielleicht vorstellt. Aber was der Autoscaler halt macht, ist, wenn eine von diesen Nodes stirbt, warum auch immer, und in der Cloud können Dinge auch einfach mal sterben, weil die Hardware unten drunter ist kaputt gegangen oder. Beliebige Gründe sorgen dafür, dass diese Kisten einfach auch ausgehen. Und das muss man schon mit rechnen in der Cloud. Und noch stärker als wenn man irgendwie so einen dedizierten Server irgendwo laufen hat. Dann geht die aus und der Autoscaler sagt, ah, ich soll aber doch fünf laufen haben. Jetzt sind nur noch drei da, weil zwei gestorben sind. Und dann fährt er halt zwei neue hoch. Und das war auch der Grund, warum wir das bei AWS hatten, damit einfach konstant was läuft, weil bei AWS sind die tatsächlich oft ausgegangen. Oft jetzt relativ, jetzt nicht jeden Tag irgendwie, aber im Monat sind da mehrfach die Kisten einfach weggebrochen und dann wird da eine neue gestartet. Gleichzeitig erlaubt dieser Autoscaler unabhängig, wir hatten ja eben gesagt, in Terraform will man erst die neue hochfahren, um die andere runterzufahren. Und der Autoscaler erledigt das quasi auf dieser Ebene auch. Ich kann halt komplett die Server austauschen, irgendwie neu provisionieren, neue Updates, neue Instanzen nutzen, was auch immer. Und der Autoscaler sorgt dafür, dass erst die neue Launch-Konfiguration vollständig, heile da ist, bevor er den Load-Balance automatisch umbiegt. Das war da auch sehr praktisch. Und Autoscaler gibt es bei Hetzner nicht. Das heißt, wenn uns eine Instanzen wegbricht, dann ist die weg. Und wir müssen die selber wieder hochfahren. Also da gibt es niemanden, der das für uns tut. Bisher sind uns keine nennenswert weggebrochen. Die sind trotzdem redundant natürlich, die Webnodes. Damit, wenn jetzt eine wegbricht, dann geht das Alerting an, wir können eine hochfahren, die Anwendung läuft weiter und durch die geringeren Kosten, die man bei so einer Simple Cloud hat, sind die Kisten alle auch überprovisioniert. Sowieso genügend Headroom für irgendwelche Lastspitzen. Daher ist das verkraftbar, sage ich mal, dass wir keinen Autoscaler haben und wir haben das auch dann nicht irgendwie mit dem Kubernetes oder was ähnlichem selber implementiert so ein Mechanismus, der das so autoheilend da durchgeht.

Lucas Dohmen: Genau und ich glaube, man muss sich auch einfach nochmal klar machen, wie viel mittlerweile so eine einzelne Kiste an Kram machen kann. Also die sind einfach sehr, sehr schnell. So eine große Maschine von Hetzner, die kann echt viel. Da braucht man jetzt auch nicht hunderte von Instanzen für eine normale Web-Anwendung. Also ich glaube, da haben viele auch irgendwie so ein bisschen die Verbindung zu verloren, wie viel so eine Maschine kann. Gerade wenn man halt auch noch ein CDN davor schraubt, das viel von dem ganzen Kleinkram einem ja schon abnimmt, dann kommt man damit echt gut zurecht.

Dirk Breuer: Ja, also an der Stelle nochmal der Hinweis, also der einzige Grund ist, warum man eine dickere Maschine nehmen möchte, als man so rein CPU-technisch baut, ist Netzwerk. Weil das sind ja virtualisierte Kisten und die müssen gucken, dass sie irgendwie das aufteilen. Und das war schon bei AWS nicht so ganz, also kriegst du das ohne weiteres gut gestaffelt. Also du kannst nicht für die gleiche CPU quasi viel mehr Netzwerk einkaufen. Weil das total unpraktisch ist natürlich für die zu schneiden, für die Anbieter. Deswegen, wenn du mehr Netzwerk willst, dann brauchst du mehr CPU. Und für die Webnodes ist das jetzt meistens nicht so ein Riesenproblem. Aber wenn die Datenbank irgendwo drauf läuft, die möchte vielleicht möglichst viel Netzwerk haben, weil die mit mehreren Nodes reden möchte. Und das ist auf jeden Fall bei uns sowas gewesen. Deswegen haben wir quasi die größte Maschine für die Datenbank genommen, einfach um die größte Netzwerkkapazität zu bekommen.

Lucas Dohmen: Ja, sehr guter Punkt. Und jetzt, um das mal so ein bisschen einzuschätzen, über was reden wir da? Das, was jetzt da in Terraform geschrieben haben, das sind 650 Zeilen Code. Und interessant dabei, das habe ich extra vorher noch mal kurz nachgeschaut. Der letzte Edit von diesen Files ist vor fünf Monaten gewesen. Das heißt also, das ist sehr stabil, das hat einen sehr geringen Churn. Wir sind nicht da die ganze Zeit am rumoperieren und ändern da irgendwelche Dinge dran. Diese grundlegenden Sachen sind seit fünf Monaten gleich. Und ich erwarte auch nicht, dass da in nächster Zeit irgendeine größere Änderung dran passiert. Das ist halt einfach quasi in Anführungsstrichen fertig. Was ist schon fertig, aber kann man so ein bisschen als fertig betrachten. Genau, vielleicht noch kurz zum Secret Management, weil das auch manchmal gefragt wird. Wir benutzen dabei hauptsächlich ein Feature von Rails, das heißt Rails Credentials. Da kannst du verschlüsselt Dinge in der Anwendung ablegen und dann brauchst du halt einen Key, mit dem du das aufmachen kannst. Und das heißt auch, man kann quasi eine neue Version der App deployen, weil, sagen wir jetzt mal, wir haben einen neuen Mail-Provider oder sowas. Da muss man natürlich auch anderen Code anpassen. Dann kann man diese Secrets quasi gemeinsam mit dem Code-Change ausspielen, was sehr, sehr praktisch ist. Man muss nicht irgendwie so ein Phasing machen, wo man erst die neuen Credentials hinzufügt, die Alten dann aber drin lässt und so weiter. Das brauchen wir gar nicht zu tun, weil die Anwendung halt immer in Sync ist mit den Credentials, und da ist der Großteil der Credentials steht da halt drin. Ausnahmen sind halt so ein paar kleine Sachen, die eben erst so zum Terraform ausführen bekannt sind. Und die machen wir über Environment-Variablen, die dann, also die Terraform auf die Platte schreibt, damit sie im Environment stehen. Das heißt, das ist schon unser gesamtes Secret-Management. Ja, habe ich was vergessen?

Dirk Breuer: Das trifft es ziemlich genau. Der wichtige Punkt ist, dass alle Secrets, die für die Anwendung relevant sind, in der Anwendung liegen, um eben dieses Phasing nicht zu haben. Bevor das zuverlässig funktioniert hat in Rails, hatten wir halt, ja, lag halt irgendwo eine verschlüsselte Secret-Datei irgendwo rum. Die ist dann beim Deployment geladen worden, aber da hatte man halt immer dieses Problem, okay, ich muss die beiden eintragen, bla bla, hin und her. Und auf den Maschinen selber liegen nur Secrets, die die Maschinen brauchen. Weil beispielsweise der Key, um das Monitoring zu befüttern oder der Key, um von der Docker-Registry zu laden, solche Sachen.

Lucas Dohmen: Genau, ja, exakt. Genau. Und damit haben wir im Prinzip fast alles, was Terraform bei uns macht, schon beschrieben. Das Einzige, was Terraform jetzt am Ende noch macht, ist, also nicht am Ende, aber auf den jeweiligen Maschinen spielt es das Docker-Image ein, was Hetzner zur Verfügung stellt. Das ist ein Ubuntu, wo halt Docker einfach schon vorinstalliert ist. Das kommt auf alle von diesen Maschinen, über die wir eben gesprochen haben, drauf. Und danach führen wir Ansible aus. Und dann kommen wir schon zum nächsten Tool. Was machen wir denn eigentlich mit Ansible, Dirk?

Dirk Breuer: Ja, Ansible ist ja im Grunde Bash-Skript als YAML. Ja, das soll gar nicht abwertend klingen, aber ich finde, das trifft es eigentlich ganz gut. Man hat irgendwie sehr strukturiert in YAML-Form stehen, was man durchführen möchte und unten drunter werden dann halt Dinge ausgeführt. Man kann das schön modular sich zusammenstecken, auch die ganzen Dateien, die irgendwie da dran hängen, also hat man da, ja, so Rollen nennt sich das dann in Ansible, die man zusammensteckt und wo man so einzelne Tasks ausführt. Die dann abarbeiten, was so auf diesem Server passieren muss. Und unter anderem ist es eben, machen wir damit, Kernel Update am Anfang erstmal, richten irgendwie unattended Upgrades ein, solche Sachen, installieren so ein paar Basistools, weil vieles auf den Kisten nicht zusätzlich installiert, dadurch, dass das Image selber schon Docker mitbringt, brauchen wir das nicht noch nachinstallieren. Da ist halt irgendwie ein vi noch drauf installiert, sichergestellt, tmux installiert, solche Sachen. So ein paar Monitoring-Tools, so Housekeeping-Tools, um mal irgendwas auf den Maschinen selber sich anzuschauen, was wirklich selten genutzt wird. Aber ja, wenn man dann doch mal was machen muss, dann ist es angenehm, dass es da ist. Und dann kopieren wir eben damit auch einige Konfigurationsdateien dahin, unter anderem eben die ganzen Docker-Konfigurationen. Und dafür setzen wir das ganze Ding dann auch in den Docker-Swarm-Mode. Da kommen wir vielleicht auch gleich noch separat drauf.

Lucas Dohmen: Definitiv.

Dirk Breuer: Gibt Redebedarf bei dem Swarm Mode. Genau, und das ist im Grunde der Teil, der dann dafür sorgt, dass die Maschine alleine starten kann, ohne dass man manuell was drauf deployen muss. Damit man eben einfach eine neue Kiste hochfahren kann, ohne danach noch was deployen zu müssen, sondern die Maschine kann sich selber booten. Konzeptionell haben wir das aus AWS-Zeiten mit übernommen, weil der Autoscaler fordert einfach, dass sich die Instanzen hochfahren können und dann fertig sind, ohne dass was manuell gemacht werden müsste, sonst wäre das Ganze relativ witzlos. Und das ist hier auch dann der Fall. Der Nachteil dabei ist natürlich, kann man sich recht leicht überlegen wahrscheinlich, die Docker-Konfiguration ist ja anwendungsspezifisch am Ende des Tages. Und eigentlich viel näher an der Anwendung als an der Infrastruktur. Und das heißt, wenn ich was an dem Docker ändern möchte, dann muss ich das im Infrastrukturteil machen. Das ist so ein bisschen komisch vielleicht. Nicht nur vielleicht, sondern das ist schon etwas unhandlich. Kommt aber super selten vor. Und viele Sachen kann man auch rausextrahieren und dann über, wenn man einmal weiß, was man alles machen muss und das so für seine Anwendung eingespielt hat, dann über Umgebungsverfahren steuern. Aber ja, das ist auf jeden Fall so ein wichtiger Hinweis an der Stelle, glaube ich.

Lucas Dohmen: Genau. Ja, und also wir kommen gleich nochmal auf den Docker Swarm zurück. Also das ist ein eigenes Thema, aber grundsätzlich sind diese Maschinen, glaube ich, sogar gleich. Also fast gleich. Ich glaube, so ein, zwei kleine Unterschiede gibt es zwischen den Maschinen, zwischen den Datenbankknoten, Webworkern und den anderen Workern. Aber das ist hauptsächlich die unterschiedliche Docker Swarm-Konfigurations-File. Also welche Docker-Container drauflaufen.

Dirk Breuer: Ansonsten müssten sie im Grunde alle identisch sein. Also insofern, also doch, in der grundsätzlichen Konfiguration sind sie alle identisch. Was Terraform halt macht, der sagt, wir brauchen bestimmte Volumes, also sonst wäre quasi die Festplatte einfach in der VM dabei. Und wenn die VM ausgeht, dann ist auch diese Festplatte weg. Und das ist manchmal nicht so praktisch, wie ihr euch vorstellen könnt, vielleicht bei der Datenbank. Oder auch bei dem Bilderserver ist es auch relevant. Wir wollen nicht jedes Mal alle Bilder, die wir ausliefern, irgendwo nur noch runterladen, sondern die sollen bitte dauerhaft da sein. Also nutzen wir diese Volumes. Das ist so ein Network Attached Storage. Den stellt Terraform grundsätzlich bereit, dass sie da sind, aber das Mounten auf den Maschinen, das passiert in Ansible. Das passiert natürlich nur auf den Servern, die das auch brauchen. Also der Web Node und der Worker Node, die haben kein Volume attached. Warum denn? Aber ansonsten sind die im Grunde alle gleich. Es gibt dann aber trotzdem im Code bei uns, werdet ihr eben unterschiedliche Konfigurationen für diese unterschiedlichen Nodes finden. Genau.

Lucas Dohmen: Genau, und deswegen sind es auch insgesamt 1000 Zeilen Code, weil es halt zum einen halt einfach YAML verbos ist und zum anderen, weil wir halt da auch eine gewisse Menge von Duplikationen haben zwischen diesen verschiedenen Knoten. Und auch dazu noch einfach mal einfach als so ein Bauchgefühl. Wir hatten jeweils ein Commit im Mai, im August und im September. Das heißt also, auch hier passiert nicht viel. Das ist auch sehr stabil und wir haben es quasi einmal durchkonfiguriert und jetzt funktioniert es halt einfach.

Dirk Breuer: Außer wir hätten in diesem Committee jeweils irgendwie tausend Zeilen geändert.

Lucas Dohmen: Das stimmt. Das stimmt, haben wir aber nicht. Spoiler Alert. Genau. Und das ist im Prinzip das, was wir mit Ansible machen. Es ist nicht viel. Also es ist wirklich eine Handvoll Tasks, die da ausgeführt werden, die aber einfach dazu führen, dass wir genau wissen, was darauf passiert und wir machen halt nichts noch händisch nach auf diesen Maschinen. Also das ist halt das, was wir da machen und fertig. Genau. Und deswegen Ansible auch wieder so ein Tool, was man, ich habe das auch irgendwann einem Kollegen beigebracht, es ist relativ einfach, wenn man einfach irgendwie verstanden hat, okay, eigentlich ist das ein Shell-Skript und man hat ein paar Abstraktionen, die sehr, sehr praktisch sind, die da so drüber hängen, aber eigentlich führt es einfach nur diesen Shell-Skript in Ruhe aus. Und wir führen jetzt auch gar nicht oft jetzt irgendwie die Ansible-Skripts auf den Maschinen nochmal aus oder so. Also das ist ja eigentlich so ein Flagship-Feature eigentlich von Ansible, dass man das kann, aber das ist gar nicht so wirklich notwendig. Im Prinzip laufen die einmal da drüber und dann ist es schon wieder gut.

Dirk Breuer: Das ist nur nicht notwendig, das ist quasi unmöglich, weil der einzige, also was heißt unmöglich, aber man könnte das machen, aber das aktuelle Setup sieht vor, dass es ausschließlich durchgeführt wird, wenn Terraform die Maschine gebootet hat. Also wenn man was ändert, muss man eine neue Maschine booten. Das könnt ihr euch schon mal im Hinterkopf behalten, wenn wir nämlich gleich über die Datenbank reden, dann ist der Punkt wieder relevant.

Lucas Dohmen: Genau, das ist ein guter Punkt. Aber bevor wir dahin gehen, wechseln wir erst nochmal zu Docker. Also Docker, ich glaube, das braucht man, glaube ich, jetzt nicht mehr groß auszuholen, warum das irgendwie praktisch ist und warum wir das benutzen. Aber eine Sache, die tatsächlich ein bisschen ungewöhnlicher ist, ist zum einen, dass wir alle tatsächlich Docker Compose als lokale Entwicklungsumgebung nutzen und zum anderen, dass wir in Produktion Docker Swarm benutzen. Also erstmal kurz zu Docker Compose. Meine Beobachtung aus anderen Teams ist, dass viele Leute das nur lokal benutzen, wenn sie irgendwas debuggen wollen. Aber bei uns ist das wirklich so, alle von uns, alle sechs, wenn sie anfangen zu arbeiten, schreiben sie docker compose up und dann startet es und dann läuft es und dann editiert man vor sich hin, arbeitet und kriegt halt Refreshs und fertig. Das heißt also, das ist wirklich unsere Entwicklungsumgebung und nicht irgendwie sowas, was daneben liegt. Damit wollen wir eben so nah dran sein an der Produktion wie möglich. Natürlich haben wir lokal keinen CDN und so weiter, brauchen wir jetzt nicht darüber zu sprechen. Aber die Maschinen, also in Anführungsstrichen, sind eben wirklich die gleichen. Das heißt, wir haben da einfach keine Überraschungen, dass da Sachen ganz anders funktionieren, als sie in Produktion passieren. Überraschender ist, glaube ich, dass wir Docker Swarm benutzen. Docker Swarm ist halt, also wirklich auch, glaube ich, aus meiner Sicht einer der größten Marketing-Fails der letzten zehn Jahre im Naming-Bereich. Also es gab mal ein Ding, das hieß Docker Swarm und das gibt es nicht mehr. Und das wurde eingestellt, dieses Produkt. Deswegen alle Leute, die hören, dass wir Docker Swarm benutzen, denken, wir benutzen eine Software, die es nicht mehr gibt oder die, also so eine Legacy Software, die quasi einfach nicht mehr verwendbar ist. Es wurde aber irgendwann ein Docker Swarm Mode eingeführt. Also eigentlich benutzen wir nicht Docker Swarm, sondern Docker Swarm Mode. So ist der volle Name. Und das ist überhaupt nicht eingestellt. Das ist einfach in Docker eingebaut. Ihr müsst dazu nichts zusätzlich installieren. Ihr müsst den nur aktivieren. Das haben wir ja auch eben beschrieben, dass wir das in Ansible anklicken. Bitte starte dich hier den Swarm-Mode. Und auch bescheuert ist eben, dass Docker Swarm und Docker Swarm-Mode so gut wie nichts gemeinsam haben. Also das sind einfach zwei völlig unterschiedliche Produkte. Und genau, deswegen legt die Angst vor Docker Swarm-Mode ab. Das ist gar nicht tot, das ist lebendig und funktioniert für uns sehr, sehr gut. Was bietet uns Docker Swarm-Mode? Also im Prinzip könnten, was wir ja machen könnten, wäre, wir könnten auf jedem der Server einfach docker compose up machen und dann würde da der Server laufen und fertig. Also das würde auch funktionieren. Also so funktioniert es ja auch lokal bei uns. Das ginge. Der Nachteil daran ist, wie macht man dann ein Deployment? Weil Docker Compose kein Konzept davon hat, von fahr jetzt mal diesen Container hoch und ersetzt ihn durch einen anderen Container. Und wenn der hochgefahren ist, dann route bitte mal den Traffic dahin und bla. Das kann der Compose nicht, weil er es ja auch nicht braucht im lokalen Fall. Also ist ja irgendwie nachvollziehbar. Aber für uns das einzige Feature, was wir vom Swarm-Mode benutzen, ist genau das. Dass wir sagen, hey, jetzt bügel bitte mal das neue Image auf den Server, fahr das hoch. auch wenn es sagt, ich bin healthy, dann route den Traffic auf diese neue Instanz und fahr die alte runter. Das ist im Prinzip das, was wir damit machen und das ist schon alles. Docker Swarm Mode kann auch mehrere Server verbinden, sodass sie von außen so aussehen, als wären sie ein Docker Host. Das benutzen wir aber gar nicht, sondern jede von den Instanzen Ist quasi ein eigenständiges Ding. Also wir connecten sie nicht miteinander, sondern die laufen eigenständig, wir benutzen nur dieses eine Feature. Und das funktioniert für uns halt wirklich super gut. Also auch wieder so eine von den Technologien, die total langweilig sind. Also wir hatten noch exakt null mal Probleme damit, nachdem wir es initial einmal aufgesetzt hatten. Am Anfang, da hatten wir ein, zwei Probleme. Ich glaube, das wäre so für mich das eine Learning, das haben wir tatsächlich vergessen. Ich mache eine kurze Seitennotiz. Auf den Servern läuft jeweils ein Traefik, das ist ja so ein Reverse-Proxy, ein Cloud-Native-Reverse-Proxy, der irgendwie so Sachen machen kann wie, route mal den Traffic auf den und den Container. Und der macht ganz komische Dinge mit dem Netzwerk von Docker. Also wirklich so super komische Dinge, sowohl den eingehenden als auch den ausgehenden Traffic. Und das hat uns total verwirrt. Also ich glaube, da haben wir, als wir das initial aufgesetzt haben, haben wir uns mehrfach irgendwie an den Kopf gefasst und gesagt, Dirk, verstehst du das? Lucas, verstehst du das? Nee. Also so wirklich völlige Verwirrung. Aber als es einmal dann lief, seitdem ist es wieder völlig unaufgeregt. Ich glaube, das wäre so das Einzige, wenn ich es jetzt nochmal ganz neu machen würde, was ich anders machen würde. Ich glaube, ich würde einmal ausprobieren, ob es Alternativen zu Traefik gibt, wie zum Beispiel Caddy. Da habe ich von ein paar Leuten gehört, dass das ein bisschen weniger komische Dinge macht als Traefik. Das ist aber mit allen anderen Komponenten bin ich total zufrieden. Nur Traefik, das war wirklich einfach frustrierend, weil an sich hat es coole Features, dass du bestimmte Sachen mit Labels einfach regeln kannst und sagen kannst, hey, ich nehme übrigens den Traffic auf dem Port entgegen. Aber ja, der Teil...

Dirk Breuer: Der war ein bisschen komisch, ja. Aber danach hat das super funktioniert mit dem Swarm-Mode. Also nicht nur das Deployment, dieses Zero-Downtime-Deployment in Anführungszeichen. Machen wir damit, was halt super praktisch ist, was auch nur ein Befehl ist, was Lucas eben beschrieben hat. Diese ganzen Schritte ist halt ein, das heißt dann Stack, der Swarm-Mode, es gibt auch den Swarm-Befehl, aber das hat Leute, ne, den gibt es gar nicht. Man sagt nur swarm mode activate, und dann gibt es einen Stack und Services innerhalb des Stacks. Wir machen so ein Stack-Update und der regelt das dann halt alles. Was gleichzeitig auch den Vorteil hat, wenn man sich irgendwie Logs anschauen möchte von Services innerhalb dieses Stacks und so eine Stack-Definition ist im Grunde ein Docker-Compose mit so einem anderen Ding noch drin. Man kann das nicht eins zu eins überführen, so ein Docker-Compose. Das Stack unterstützt nicht alles einfach so, was im Docker-Compose verfügbar ist. Im Grunde sieht das genauso aus. So müsst ihr euch das vorstellen. Und der Traefik läuft auch innerhalb dieses Stack-Files. Das ist einfach ein Service innerhalb des Stacks, wird halt der Traefik gestartet. Dann kann man sich eben einfach sagen, ich möchte gerne von dem Webnode die Logs sehen und nicht den konkreten Containernamen angeben müssen. Was halt einfach super praktisch ist. Auch das braucht man super selten, aber gerade, weil man es so selten braucht und dann sich immer daran erinnern, wie komme ich nochmal an die Logs? Ah ja, ich kann einfach service logs und dann für den Webservice mir die Sachen anschauen. Also ja, das war auf jeden Fall, da haben wir viel geguckt ja, was wir da nehmen können, um das hinzukriegen und hatten schon irgendwie die Kubernetes-Dokumentation auf oder dieses Micro-Kubernetes. Und dann gibt es ja dieses Kamal aus der Rails-Welt und so. Wir haben uns verschiedene Sachen angeschaut und irgendwann dann sind wir dann nochmal über diesen Docker-Swarm gestolpert und haben festgestellt, dass genau das, was wir brauchen, ist einfach da und nichts anderes und tut exakt, was wir brauchen.

Lucas Dohmen: Ja, exakt. Und ich glaube, dass das einfach nicht auf dem Radar ist von ganz vielen Leuten, weil es halt einfach diese im Kopf, Ich hatte auch abgespeichert, Swarm ist irgendwie so ein vergangenes Projekt, was es nicht mehr gibt. Und man guckt es sich gar nicht erst an, obwohl es für viele Sachen total ausreichend ist und viel einfacher zu handeln. Ich habe ja auch die Theorie, dass das Kamal-Team sich diese Doku auch mal durchlesen sollte, anstatt einen eigenen Reverse-Proxy zu bauen. Aber das ist ein anderes Thema. Genau, also das ist unser Docker-Setup, auch wieder relativ unaufgeregt. Also wieder einfach zu handeln. Ich habe, Bin ich noch da? Irgendwie hängt mein Bild, glaube ich.

Dirk Breuer: Jetzt bist du schon da, dass ich wieder bewegt. Also auch hier zu reden, dann bin ich sehr verwirrt.

Lucas Dohmen: Es tut mir sehr leid. Dann gab es da einen kurzen Knacks. Genau, also das war Docker Swarm. Wie funktioniert jetzt so ein Deployment bei uns? Wir benutzen dafür auch wieder ein altes Tool, was quasi auch wieder so aus der Vorzeit kommt. Das heißt Capistrano. Das ist aus der Rails-Welt, aber eigentlich macht es nichts Rails-Spezifisches. Also man kann damit alles deployen. Und eigentlich benutzen wir auch davon, wir schalten im Prinzip alle Features aus, weil das kann halt so ganz viele Sachen, die man früher gebraucht hat, wie mit Apache dann irgendwie so diese Datei dahin schieben und dann so ein Switchover machen und all so ein Kram. Eines brauchen wir ja gar nicht. Im Prinzip macht Capistrano exakt zwei Dinge. Es macht einmal Docker Pull und einmal Docker-Image-Prune, damit unser Server nicht vollläuft. Sorry, docker stack deploy und docker image prune. Das ist alles, was es tut. Und dann ist es schon fertig. Damit das funktioniert, sieht unser Deployment so aus. Wir taggen die Images, auf unserem Docker wie heißt es? Nicht Hub...

Dirk Breuer: Registry.

Lucas Dohmen: Danke dir. Auf der Docker Registry taggen wir die Images. Und es gibt einen Tag, den wir für Staging benutzen und einen Tag, den wir für Production benutzen. Und wenn man einen Docker Stack Deploy macht, dann holt es sich einfach von dem entsprechenden Image, also von dem entsprechenden Label, das aktuelle Image und fertig ist die Laube. Und deswegen ist das unser Prozess. Also dafür sorgen, dass das Tag richtig steht. Das passiert bei unserem Staging automatisch. Also alles, was auf dem Main branch ist, wird getaggt für Staging. Und für Produktion haben wir so ein Mini-Skript, was einmal einfach den Tag draufhängt und fertig. Und damit haben wir wirklich einen super einfachen Prozess. Warum benutzen wir jetzt überhaupt Capistrano? Wir können ja auch einfach... Die zwei Befehle selber ausführen. Der Grund ist eigentlich nur, dass wir uns ja auf alle von den Knoten einloggen müssen und auf jedem davon das ausführen müssen. Und da gibt uns einfach Capistrano so ein paar Komfortfeature, die wir nicht selber bauen wollen und die klappen halt einfach gut. Also im Prinzip ist ein bisschen Kanonen auf Spatzen geschossen, würde ich jetzt mal sagen. Also Capistrano kann so viel und wir machen exakt zwei Dinge.

Dirk Breuer: Ja, es ist eine kleine Kanone.

Lucas Dohmen: Genau, es ist eine kleine Kanone, genau. So würde ich es auch sagen, eine Spatzenkanone im Prinzip.

Dirk Breuer: Ach, und selbst ehrlich gesagt, selbst wenn, trotzdem, also bevor ich das selber schreibe, also würdest du lieber irgendwie eine Sammlung von irgendwie Shell-Skripten da liegen haben, die irgendwelche SSH-Kommandos da machen?

Lucas Dohmen: Ja...

Dirk Breuer: Du hast so den Vorteil, okay, es gibt so definierte Punkte, die Capistrano ausarbeitet und in die kannst du dich quasi reinhängen und sagen, was er zu diesem Zeitpunkt machen soll. Wie Lucas sagte, die meisten davon tun quasi nichts, aber dadurch, finde ich, wird das Ganze sehr lesbar und nachvollziehbar und man kann bestimmte Sachen nur auf bestimmten Knoten ausführen. Ja, daher finde ich das einfach sehr komfortabel, auch wenn es quasi overengineered ist, aber bevor man einfach auch jetzt mal was Eigenes zusammenzimmert.

Lucas Dohmen: Ja, ich sehe das auch so. Es ist für mich halt das Einzige, wo ich halt das Gefühl habe, wir benutzen so einen kleinen Teil davon, es fühlt sich komisch an, aber ich gebe dir absolut recht, den kleinen Teil, den wollen wir halt einfach haben. Also warum sollen wir ihn ja nicht nutzen. Und auch das Tool, das ist auch einfach fertig. Also da brauchst du halt auch nicht dir Sorgen zu machen, dass da jetzt ein großer Breaking Change kommt und wir müssen alles nochmal neu bauen. Das ist einfach fertig. Da wird halt zwischendurch dafür gesorgt, dass halt irgendwie alles mit SSH up to date ist und dann passt das halt. Also easy. Genau. Und damit habt ihr eigentlich schon bis auf die Datenbank eine gute Übersicht über das, was wir da so gebaut haben. Und ich finde. Für wen passt dieses Setup? Ich glaube, das Setup passt wirklich für kleine Teams. Also ich sage jetzt mal bis zehn Leute, vielleicht sogar noch ein bisschen mehr, wo man eben nicht dediziert irgendwelche Leute haben möchte, die sich die ganze Zeit nur um Operations kümmern. Und dann irgendwie, also so typische "you build it, you run it" Teams, die das einfach selber machen wollen, die nicht in einen größeren Kontext eingebunden sind, wo sie sich mit anderen Teams noch irgendwelche Komponenten teilen. Dann würde unser Setup, glaube ich, an eine Grenze stoßen. Ich glaube, da würde ich da eher von abraten und wirklich dazu raten, mal zu überlegen, ob so ein Kubernetes dazu gut passt. Aber für viele von diesen Mittelständlern ist das, glaube ich, eine super, super Lösung, weil es einfach zu verstehen ist, Also wir haben euch im Prinzip jetzt durchgeführt durch unsere Dokumentation, die wir dazu geschrieben haben, die interne. Und man kann das halt sich hinsetzen mit einem Kaffee in Ruhe, einmal das Terraform durchlesen, das Ansible durchlesen und weiß man, was da passiert. Da ist nichts Aufregendes dran. Und es funktioniert halt einfach unfassbar zuverlässig. Und darum mag ich dieses Setup, weil es ist in Anführungsstrichen langweilig. Also wir haben ja auch dieses Boring-Tech in unserem Talk auch mal zitiert. Es ist halt langweilig in der besten Art und Weise, weil wir müssen es gar nicht oft anfassen. Also wir passen es, wie ich ja ausgeführt habe, super selten an. Und im Prinzip ist es einfach nur eine Docker-Runtime, wo halt eine Datenbank hinterhängt. Und die Datenbank, das ist das eine Teil, was ein bisschen schwieriger ist, da kommen wir jetzt gleich nochmal zu, aber alles andere ist halt total unaufgeregt. Oder wie siehst du das?

Dirk Breuer: Ja, ich würde, glaube ich, noch einen wichtigen Hinweis hier an der Stelle geben wollen. Es ist so, wie du sagst, für diese Teamgröße passt das gut. Es passt aber, glaube ich, nur deswegen auch so gut, wenn du eine monolithische Anwendung hast. Das haben wir bisher nicht so richtig explizit genannt. Also wenn du dich auch als kleines Team dazu entschieden hast, ob das eine gute oder schlechte Entscheidung ist, das ist ein anderes Blatt. Wir haben uns explizit dafür entschieden, einen Monolithen zu bauen. Die Anwendung ist ein paar Mal zwischendurch neu geschrieben worden. Wir hatten auch mal verschiedene Service-Iterationen, so eine Service-Phase, Sturm- und Drang-Phase, wo wir alles mit Services gemacht haben oder versucht haben, das zu machen und viele kleinere Anwendungen zu machen. Dann ist das anstrengend und wir sind irgendwann explizit dazu übergegangen, okay, wir bauen nur noch einen Monolithen. Die Worker laufen alle in derselben Codebase, Und ja, der Image-Service, der läuft irgendwie einzeln, aber selbst auf dieser Kiste läuft die gesamte Rails-Anwendung nur, um die Worker laufen zu haben, die die Bilder runterlädt. Die machen sonst nichts, die Dinger. Die schreiben auch nicht in die Datenbank. Die laden einfach nur Bilder runter. Die lesen aus der Datenbank. Aber das war es dann auch. Und das ist schon noch eine wichtige Einschränkung, würde ich sagen. Ich bin weiterhin der Meinung, dass in so kleinen Teamgrößen das hilfreich ist, weil es eben einfach langweilig gut funktioniert und du nicht irgendwie zehn Services hast bei fünf Leuten und jeder weiß nicht mehr, welcher ein Service links und rechts und, du fängst dann an, doch irgendwie Abhängigkeiten einzubauen und implizite Sachen zu machen und dann musst du auf einmal drei Services gleichzeitig deployen und sowas, weil es einfach einfacher ist in so einem kleinen Team. Aber das ist ein relevanter Aspekt. Wenn du in einem kleinen Team gesagt hast, okay, wir wollen warum auch immer Services haben, dann wird das auch an die Grenzen stoßen, würde ich behaupten.

Lucas Dohmen: Ja, definitiv.

Dirk Breuer: Man kann dann sagen, okay, vielleicht macht es trotzdem Sinn, mit Docker Swarm erstmal zu starten und sich das mal anzuschauen, was da noch mit geht, bevor man Kubernetes macht. Einfach weil Kubernetes sehr viel Komplexität in das Team noch zusätzlich trägt und vielleicht reicht dann Docker Swarm, aber da können wir keine verlässliche Aussage an der Stelle treffen.

Lucas Dohmen: Ja, das stimmt. Genau. Hier nochmal ein kurzer Hinweis für die Leute, die live zuhören. Es hören ja ein paar live zu. Wenn ihr Fragen habt, könnt ihr die auch gerne in den Chat schreiben. Wir können da gleich auch noch mal kurz darauf eingehen, wenn ihr was habt. Sonst würde ich jetzt sagen, lass uns noch mal über den Elefanten im Raum sprechen, Postgres. Danke dir, da habe ich lange dran gearbeitet. Das ist so der eine Teil, wo wir am Anfang auch überlegt haben, ist das ein Grund, nicht Hetzner Cloud auszuwählen für uns. Also wir haben uns ja damals für Hetzner Cloud entschieden und Hetzner Cloud bietet eben keine Database-as-a-Service an. Es gibt auch andere kleinere Cloud-Anbieter, die das anbieten, aber bei Hetzner ist es aktuell nicht im Portfolio. Wenn es da wäre, würden wir es kaufen dann würden wir dann sagen okay, hier nehmt dieses Geld und macht das für uns aber wir haben uns trotzdem dafür entschieden, dort hinzugehen und das ist so das eine, wo wir überhaupt Maintenance Aufwand haben, würde ich sagen eben im Operations Bereich der Rest läuft einfach. Bei der Datenbank haben wir uns also wir müssen erstmal einmal damit starten: Wofür haben wir uns entschieden? Wir haben uns für ein Single-Node-Setup entschieden. Also wir haben keine Follower auf der Datenbank für High Availability oder so etwas, weil das Management sagt, das ist das zusätzliche Geld nicht wert, einen zweiten Server zu haben und vor allem den zusätzlichen Aufwand, all dieses Setup dazu zu machen. Wenn das Ding mal eine Stunde oder zwei offline ist, dann ist das halt so. Dann schaltet eine Maintenance-Page, macht die Datenbank wieder heile und alles ist in Ordnung. Das ist eine Entscheidung, die, glaube ich, zu wenige Unternehmen treffen.

Dirk Breuer: Das ist ein wichtiger Punkt, Lucas. Das ist ja keine Entscheidung, die man leichtfertig trifft, wo viele sagen, wenn man liest von High Availability und diesem ganzen Kram und die Five Nines und so ein Spökes, die mit Verbindung mit Kosten und Aufwände, was ja dann auch Kosten sind, sind gerade für kleine Teams sehr, sehr hoch und kann man sich nicht so richtig gut vorstellen. Und dass das Management dann hingeht und sagt, okay, jetzt lassen wir mal ganz Tacheles reden. Was bedeutet das, wenn wir zwei Stunden offline sind? Und wie oft kommt das denn überhaupt vor? Maschinen sind stabiler geworden, Software insgesamt ist einfach sehr viel stabiler geworden, ist das Risiko da so gering, dass sich dieser Aufwand eben für uns dann am Ende des Tages nicht gelohnt hat. Wenn man das so erzählt, dann kommen immer so, boah, was nur eine Node, was ist da los? Aber ja, am Ende des Tages hatten wir deswegen auf jeden Fall noch nie Probleme. Doch, einmal. Ja, aber es hätte uns auch nichts gebracht, wenn wir einen Follower gehabt hätten.

Lucas Dohmen: Das stimmt.

Dirk Breuer: Dann wäre der auch gestorben in dem Zusammenhang. Und es ist nicht so, dass wir das jetzt seit dem Umzug auf die Simple Cloud haben. Auch in der AWS-Welt, also seit knapp zwölf Jahren, fahren wir auf einem Single-Node-Datenbank-Setup ohne Follower und hatten kein einziges Mal ernsthafte Probleme dadurch. Wo wir gesagt haben, boah, jetzt sind wir irgendwie tagelang offline, hätten wir doch mal so einen Follower gehabt und einen Hot Standby und dann wäre alles gut gewesen, haben wir aber leider nicht.

Lucas Dohmen: Genau.

Dirk Breuer: Und selbst als wir, gut, jetzt in der Simple-Cloud-Welt haben wir noch keine, Major-Datenbank-Upgrades gemacht, ein paar kleinere Upgrades, aber in der AWS-Welt haben wir eine Reihe von Major-Upgrades gemacht, also alle, die halt angefallen sind, was irgendwie, glaube ich, vier oder fünf waren, nee, noch mehr, müssten sechs gewesen sein oder so, aber auf jeden Fall viele. Und das ist mit Downtime verbunden. Das ist mittlerweile auch nicht mehr ganz so schlimm. Das ist auch besser geworden. Ja, aber daher haben wir da nie große Probleme mit gehabt. Was man noch als Hinweis, glaube ich, einsortieren, wir haben uns auch entschieden, so einen Cloud-Server herzunehmen, Lucas. Wir haben keine Dedicated-Kisten genommen. Die sind kostentechnisch ja im Grunde etwas attraktiver und du kriegst nochmal irgendwie dedizierter diese Ressourcen zur Verfügung gestellt. Das hat im Grunde ausschließlich so verwaltungstechnische Gründe bei uns jetzt gehabt, weil das quasi zwei Produkte sind bei Hetzner und auch zwei Firmen irgendwie, und der Dedicated Server sich nicht über die API, wie er so einen Cloud-Server steuern lässt. Das ist quasi der einzige Grund, warum wir das nicht gemacht haben. Es hätte einfach zusätzlichen Aufwand bedeutet, sowohl den Server zu regeln, also die Netzwerke zu mischen und so ein Kram. Deswegen haben wir das nicht gemacht und deswegen ist es auch ein Cloud-Server.

Lucas Dohmen: Genau. Und ein wichtiger Aspekt ist, weil das glaube ich auch bei vielen im Kopf irgendwie ist, ist, was ist denn mit Datenverlusten und so weiter. Und das ist aus unserer Sicht eben einfach ein separates Thema. Also der Server, auf dem läuft Postgres und pgBackrest. pgBackRest ist eine, Backup-Software für Postgres. An der Stelle packe ich auch nochmal in die Shownotes eine sehr gute Podcast-Episode, von Postgres.fm, die wir uns dazu angehört hatten, wo diese Empfehlung auch herkam. Das haben wir natürlich dann auch nochmal an weiteren Stellen uns auch nochmal, schlau zugelesen. Aber ja, eine von den wichtigen Sätzen ist halt, pgdump ist kein Backup-Tool. Also das ist eine der ganz wichtigen Sachen. Das steht auch tatsächlich in der Dokumentation von pgdump. Trotzdem ist es, glaube ich, das am meisten verwendete Backup-Tool für Postgres. Was macht pgBackRest? pgBackRest bietet uns eine sogenannte Point-in-Time-Recovery. Das heißt, wir können tatsächlich zu jedem Zeitpunkt in der zurückspringen. Wir können sagen, hier, stell das Backup von 13:02 Uhr wieder her. Ja, und das macht es eben, indem es inkrementell Daten wegschreibt. Also alles, was in den Write-Ahead-Log von der Datenbank geschrieben wird, wird halt quasi weggeschrieben. Und zwar auf ein S3, also das von Hetzner, das ist wie Tempo. Ich sage einfach S3, ich habe mich daran mittlerweile so gewohnt.

Dirk Breuer: Ist okay.

Lucas Dohmen: Also wir schreiben auf diesen S3-Bucket, schreiben wir all diese Informationen, legen die dort ab. Und wenn jetzt dieser ganze Server und sein Volume sich einfach explodiert, dann haben wir alles auf dem S3-Bucket auch drauf. Das heißt, wir können das aus diesem Backup wiederherstellen. Und das ist kein Grund, rauszugehen aus dem Single-Node-Setup. Und darum, überlegt einfach nochmal, ob ihr das wirklich braucht. Also wir haben die Eigenschaft, und das ist auch keine unübliche Eigenschaft, dass es klare Maintenance-Windows geben kann. Also zwischen 1 Uhr und 3 Uhr nachts passiert auf unseren Servern so gut wie nichts. Wenn man da eine Maintenance-Seite schaltet, merkt das nicht mal jemand. Also weil halt alle Leute aus Europa auf diese Seite zugreifen, wir sind halt nicht weltweit verteilt. Aber das sind die meisten ja nicht. Das heißt, wenn wir jetzt so ein Postgres-Backup machen, dann machen wir das natürlich nicht um 13 Uhr. Sondern machen wir, also ein Update, sorry, ein Postgres-Update machen, dann machen wir das natürlich nicht in der Prime-Time. Dann machen wir das halt zu dem Zeitpunkt, wo halt so gut wie nichts los ist. Und das wäre aus meiner Sicht ja einfach was, was man sich überlegen kann. Ist es jetzt total schmerzfrei? Nein. Also wir mussten mehrfach nochmal an der Konfiguration am Anfang rumtunen. Wir haben ab und zu einen Restart vom Server, den wir aktuell untersuchen. Es sind halt so ärgerliche Kleinigkeiten, mit denen man sich eigentlich nicht beschäftigen will, wo man am liebsten einfach jemanden für bezahlt, dass er das für einen macht. Aber an sich funktioniert auch das sehr gut und wir haben auf jeden Fall nicht bereut so ein einfaches Setup zu haben von einem Single Node mit ordentlichem Point in Time Recovery.

Dirk Breuer: Und diese, also da sind Probleme, die man auch noch nicht wegdiskutieren kann. Diese Random Restarts der Datenbank sind einfach nervig und ja, die Konfigurationssachen waren auch nervig, aber das sind so Dinge, die so ein bisschen Haus gemacht sind, weil ich glaube, wir haben so in den letzten 10, 15 Jahren, gerade so als Webentwickler, uns ganz schön wohlig damit gefühlt, die Datenbank, das ist so ein Dienst, den habe ich einfach. Mir wurscht, wie der genau funktioniert. Ich mache mir da wenig Gedanken mit, was da genau dranhängt und auch gucke da wenig rein. Wie kann ich das irgendwie weiter optimieren? Und das hört da ja nicht mit auf. Man macht sich überhaupt wenig Gedanken. Wie kann ich meine Queries optimieren? Also das haben wir auch immer wieder festgestellt. Das ist, glaube ich, so auf der Seite ganz gut, dass man sich mal gezwungen fühlt, jetzt da genauer reinzuschauen. Aber nichtsdestotrotz gibt es einfach konkrete Dinge, die nicht ganz so sauber funktionieren. Die ein Stück weit vielleicht auch damit zu tun haben, dass es immer so eine Simple Cloud ist und alles nicht ganz so hochverfügbare Hardware ist und alles Top-Performance. Genau, also wir hatten solche Ausfälle halt nie bei AWS. Das muss man halt einfach auch dazu sagen und wahrscheinlich auch bei einem anderen großen Anbieter, wo man dann signifikant Geld da drauf wirft, nicht. Ja, aber bereut habe ich es auf jeden Fall nicht definitiv. Und dieses simple Setup mit kein Failover und Hot Standby und was man alles da noch machen könnte, hilft dabei auf jeden Fall.

Lucas Dohmen: Ja, definitiv. Wir haben jetzt noch eine Frage aus dem Publikum und zwar von Ultrakatel. Würdet ihr heute noch Hetzner wählen, trotz der Preiserhöhung? Magst du kurz ein bisschen was nochmal zu dem Pricing-Thema sagen?

Dirk Breuer: Genau, also Hetzner ist sicherlich dafür berühmt, dass es sehr, sehr günstige Preise hat, sehr kompetitive Preise. Das liegt nicht daran, dass sie Ramschware verkaufen, sondern da gab es letztes, das kann man vielleicht mal verlinken, das fand ich sehr spannend, das Video, wie es bei Hetzner in den Rechenzentren aussieht. Das ist schon hoch effizient gestaltet und deswegen können die einfach auch sehr günstige Preise anbieten. Das liegt auch daran, dass sie quasi Consumer-Hardware verwenden und nicht sehr, sehr teure spezielle Server-Hardware. Ob das als Sternchen, ob das AWS tut, für die meisten Instanzen würde ich bezweifeln. Die werden das Gleiche tun, dass es einfach Common Hardware ist, weil nochmal gerade im Cloud-Umfeld, das ist darauf ausgelegt, dass das Zeug wegbricht. Und wenn dann einer abkachelt, dann ist er halt abgekachelt. Diese Preise konnte Hetzner nicht halten seit Anbeginn des Jahres. Das liegt nicht daran, dass Hetzner gierig geworden ist, sondern es liegt daran, dass andere gierig geworden sind. Wir bedanken uns an dieser Stelle bei KI. Das hat einfach die Preise für alle, extrem in die Höhe getrieben und nicht nur die Preise in die Höhe getrieben, sondern auch die Verfügbarkeit von Hardware einfach zum absoluten Mangel gemacht. Und die großen Anbieter, die ihre Hardware stellenweise selber bauen, wie AWS mit den Graviton-Prozessoren, können das so ein bisschen tanken, wie man so heute in Neudeutsch sagt, und das irgendwie wegstecken. Aber auch da sind Preiserhöhungen ja nicht, also die machen ja nicht die Preise, weniger hoch, nur weil sie schon hohe Preise haben. Die sagen ja nicht, hallo, ich wollte bei der gleichen Marge bleiben. So, und Hetzner musste die jetzt halt anheben. So, das ist, woher die kommen. Die haben die zweimal angehoben. Wir haben einmal die Einrichtungsgebühr irgendwie um Faktor 3 hochgedreht, Vor allem für die Dedicated-Kisten. Das war ja, weil das quasi den Server sozusagen großteils finanziert. Selbst wenn du nur einen Monat behältst, dann ist der über die Einrichtungsgebühr quasi dann schon nicht komplett abgeschrieben. Aber ja, das stellt sicher, dass du nicht sehr günstig einfach jeden Monat einen neuen Server machst und die da auf den Kosten hängen bleiben. Aber auch die Mieten für die Cloud-Server sind deutlich nach oben gegangen. Wir würden das genauso wieder machen, weil, was ist die Alternative? Also, diese Preiserhöhung ist einfach da im Markt. Und wir haben uns dafür entschieden, aus politischen Gründen ja auch weg von AWS zu gehen, zu einem lokalen Anbieter. Und ja, das ist dann einfach so da mitzutragen. Und zur Einsortierung muss man vielleicht noch sagen, trotz der Preiserhöhung haben wir immer noch 70 Prozent der Kosten gespart, so 70 bis 75 Prozent.

Lucas Dohmen: Genau. Ich glaube, das ist ein ganz wichtiger Punkt, weil irgendwie man hört, es ist so und so vielfach gestiegen. Oh mein Gott, lohnt es sich jetzt noch? Es ist immer noch deutlich günstiger, wie du ja ausgeführt hast. Also das ist, glaube ich, schon wichtig zu betonen. Vielen Dank für die Frage.

Dirk Breuer: Ja, ein sehr wichtiger Punkt. Also es ist durchaus insgesamt einfach ein wichtiges Thema, was man sich klar machen muss und wo man dann auch noch sagen muss, in was für einer Situation wir gerade hängen mit Hardwarepreisen.

Lucas Dohmen: Genau, absolut. Und kein Anbieter außerhalb von den Hyperscalern wird euch davor direkt schützen und die werden euch auch irgendwann nicht mehr schützen. Also das sollte euch bewusst sein. Das ist jetzt nicht eine spezifische Hetzner-Sache. Ich glaube, die hätten sich einen Gefallen getan, wenn sie das ein bisschen anders verkauft hätten, diese ganze Sache. Aber an sich ist das keine Besonderheit von Hetzner. Es ist halt einfach nur, glaube ich, noch mehr besprochen worden, weil Hetzner ja gerade für seine günstigen Preise bekannt ist. Ich glaube, das ist so der Effekt.

Dirk Breuer: Also die Details oder die Interna sind uns natürlich nicht bekannt. Ich weiß ja nicht, ob die die rausgeben würden oder so. Aber ich kann mir schon vorstellen, dass denen das so ein bisschen um die Ohren geflogen ist und sie relativ schnell handeln mussten und irgendwie gucken mussten, dass sie das in den Griff bekommen. Ja, und dann ist es manchmal nicht optimal kommuniziert, aber die Kosten sind einfach nach oben gestiegen. Das hat nichts mit Hetzners Gier an der Stelle zu tun.

Lucas Dohmen: Ja, sehe ich auch so. Haben wir noch irgendwas? Wir sind schon ein bisschen über der Zeit drüber. Haben wir noch irgendwas vergessen oder sind wir soweit mit allem durch?

Dirk Breuer: Also wie gesagt, die Datenbank ist sicherlich der spannende Teil, weil immer da, wo State liegt, ist spannend. Achso, eine Sache zur Datenbank haben wir noch nicht erwähnt. Die Datenbank ist zwar ein Cloud-Server, aber die lässt sich natürlich nicht einfach so mit Terraform einfach so steuern. Also das erfordert extra Aufwand, die Cloud-Instanz auszutauschen. Deswegen ist die auch immer noch die gleiche wie eh und je. Da machen wir quasi die, also alle anderen lassen sich quasi, wenn wir ein Update des Kernels machen wollen, oder der Kiste selber, das ist kein Problem, aber die Datenbank, die müssen wir so ein bisschen separat behandeln. Einfach, weil sie diesen State hat und das nicht ganz so komfortabel, wie man das vielleicht sich wünschen würde oder von so einem Hyperscaler kennt, dann läuft. Also das kommt ja nicht dauernd vor. Aber wenn da intensivere Sachen dran gemacht werden müssen, dann gibt es einen Downtime und dann muss man auch händisch irgendwie ran an die Kiste. Das vielleicht noch so abschließend.

Lucas Dohmen: Okay, wir haben jetzt noch, Ultrakatel hat uns noch eine Frage gestellt, wir beantworten die noch ganz kurz, aber dann müssen wir tatsächlich mal Feierabend machen. Wie aufwendig ist dein Umzug auch ohne Vendor-Lockin? Also ich verstehe die Frage jetzt so, wie teuer wäre er jetzt noch, wenn wir jetzt nochmal umziehen würden von Hetzner woanders hin, weil wir jetzt kein Vendor-Lockin mehr haben. Verstehst du die Frage auch so, Dirk?

Dirk Breuer: Ja, ja. Ja, würde ich sagen.

Lucas Dohmen: Also im Prinzip müssten wir dafür das Terraform leicht anpassen, weil das ist ja providerabhängig an ein paar Stellen. Das Ansible könnten wir beibehalten, so wie es ist, weil das geht ja einfach nur von einem normalen Docker auf einem Ubuntu aus. Also das ist ja auch ein totaler Standard, würde wahrscheinlich auch auf dem Debian funktionieren, würde ich jetzt mal davon ausgehen. Das das Capistrano-Zeug, das kann alles gleich bleiben. Im Prinzip ist der Hauptaufwand, den wir hätten, den State halt umzuziehen. Das ist immer das Ding, man muss halt einmal das, Backup auf den Stand bringen, Pause drücken, damit man eben woanders hingehen kann, das dort einspielen und dann im CDN umbiegen. Das ist im Prinzip das, was da anstehen würde. Das heißt, ich würde sagen, der Aufwand wäre überschaubar.

Dirk Breuer: Ja, würde ich auch sagen. Und das lässt sich auch dadurch belegen, dass auch der Aufwand am Ende von AWS weg überschaubar war. Das Projekt hat insgesamt relativ lange Zeit gekostet, aber nicht, weil so viel umzuziehen war, sondern weil wir, viele der Vereinfachungen, die wir auf der neuen Zielstruktur haben wollten oder Zielinfrastruktur haben wollten, schon bei AWS gemacht haben, um den Diff so klein wie möglich zu halten. Und das wäre auf jeden Fall ein Tipp, das immer so zu tun und nicht irgendwie tausend Sachen, die man gerne ändern möchte, dann während des Umzugs zu machen und sich danach zu fragen, okay, es funktioniert nichts, was genau ist schiefgelaufen, und nachdem wir das getan haben, war im Grunde die Hauptarbeit das Terraform umstellen, weil das einfach neu, also das haben wir einfach neu geschrieben, das Terraform das meiste von dem Ansiblezeug haben wir wiederverwendet, wir haben auch dieses ganze Docker-Deployment haben wir alles schon auf AWS gemacht und die eigentliche Umzugsarbeit war dann echt überschaubar viel und es würde ich sagen, es ist hauptsächlich ein anderer Terraform-Provider anbinden. Und ja, das State umziehen, das ist nicht zu unterschätzen.

Lucas Dohmen: Ja, genau. Vielen, vielen Dank für die beiden Fragen. Ich hoffe, wir haben das gut beantwortet. Sonst nochmal der Hinweis darauf, wir haben auch einen Talk dazu gegeben, speziell zu dem Thema, wie haben wir diesen Umzug geplant. Kommt auch in die Shownotes und genau, dir auch ein schönes Wochenende, Ultrakatel. Genau, dann kommen wir jetzt zum Abschluss. Ja, also wie am Anfang gesagt, ist das die erste Folge von Maschinenraum. Vielleicht hört ihr die Folge aber auch bei Softwarearchitektur im Stream, wenn ihr das tut. Und ihr wollt mehr von solchen Hands-on-Themen aus Operations, Entwicklung und auch Design hören, dann abonniert am besten diesen Podcast, weil nicht alle Folgen werden in Zukunft immer hier im Stream erscheinen. Aber so ein paar Livestreams sind auf jeden Fall noch geplant. Und genau, dann danke ich dir, Dirk, für deine Zeit. Vielen Dank für die Einblicke.

Dirk Breuer: Danke dir für die Einladung, Lucas. Vielen Dank.

Lucas Dohmen: Und dann wünsche ich allen ein schönes Wochenende.

Dirk Breuer: Bis dann.

Lucas Dohmen: Tschüss.

Dirk Breuer: Wünsche ich euch auch. Bis dann. Tschüss.