# Strategic Hyperscaler Exit: Cost & Sovereignty

**Podcast:** Software Architektur im Stream
**Published:** 2026-02-20

## Transcript

Hallo, ich bin Iberhard Wolf.
Freitags mache ich oder Lisa Moritz ein Livestream zum Thema Softwarearchitektur, oft zusammen mit Gästen.
Dieser Podcast ist das Audio des Streams.
Weitere Folgen, Sketchnotes und vieles mehr findet ihr unter software-architektur.tv.
Softwarechitektur im Stream.
Dann herzlich willkommen zu einer weiteren Episode von Software Technologia Stream, dieses Mal mit Lukas zum Thema Hyperscaler Exit.
Lukas, möchtest du kurz zwei Worte über dich sagen?
Ja, gerne.
Hallo Eberhard.
Ja, wir sind Kollegen bei Swag Lab.
Ich bin Principal Consultant bei Smack Lab und beschäftige mich eigentlich schon sehr, sehr lange mit Webanwendungen als Architekt, als Entwickler, aber auch im Operations-Teil.
Das ist ja heute so ein bisschen das Thema.
Und genau, davon möchte ich so ein bisschen berichten, auch aus so dem letzten Projekt, also dem aktuellen Projekt von mir.
Genau.
Genau.
Und du warst ja auch mehrfach schon im Stream.
Also zum einen eben mit dem Performance-Thema, auch mit zum Frontend-Architektur-Thema mehrfach.
Und dann eben auch zu diesem Thema mit einer kritischen Betrachtung zum Thema LMs.
Ich war jetzt versucht zu fragen, warum eigentlich Hyperscaler Exit.
Ich glaube, wir sollten erstmal den Begriff clearen, weil du sagst ja Hyperscaler Exit und wir hatten ja darüber diskutiert, deswegen weiß ich, dass du halt Wert darauf legst, dass es eben nicht ein CloudExit ist.
Magst du kurz was dazu sagen?
Ja, also ich gehe mal einen Schritt auf die auf das konkrete Beispiel, über das wir heute reden, auch ein.
Also das Projekt, an dem wir an dem ich arbeite aktuell, ist Fayo DK.
Das ist eine Plattform, bei der man Ferienhäuser in Dänemark buchen kann, einen führenden Anbieter in dem Bereich.
Und die hatten jahrelang haben die auf AWS gehostet, also zehn Jahre oder so.
Und da war eben die Entscheidung der Geschäftsführung, dass sie gerne aus politischen Gründen nicht mehr einen US-Anbieter haben möchten für solche zentralen Dinge.
Also Fayo ist noch weit davon entfernt, jetzt gar keine US-Dienste mehr im Hintergrund oder sowas zu benutzen.
Das kennt, glaube ich, jeder von uns.
Da gibt es halt eigentlich einiges, wenn man so ein in so einem Business-Kontext ist.
Aber das ist eben einfach ein sehr, sehr großer und wichtiger Faktor und darum war es der Geschäftsführung wichtig, da zu wechseln.
Und das war auch die Haupt- und einzige Motivation der Geschäftsführung in dem Bereich.
Ich glaube, dieses Bedürfnis kennen jetzt mittlerweile viele.
Also Sorgen um Datenschutz halten diese ganzen Versprechen in dem aktuellen politischen Kontext weiter, dass der Datenschutz gewährleistet ist.
Legal ist die eine Frage und dann halt real ist nochmal die andere Frage.
Aber auch möchte ich halt ein Unternehmen unterstützen, was vielleicht direkt die Trump-Regierung unterstützt in monetärer oder anderer Form.
Das ist bei FAIU einfach die Hauptmotivation gewesen.
Die andere Motivation, die auch bei manchen da ist, ist einfach, wenn man so, also hauptsächlich jetzt AWS, Azure und Google Cloud-Plattform benutzt, die sind sehr, sehr teuer.
Und manche Preise gehen auch erst so, wenn man seine Benutzung hochfährt, langsam hoch am Anfang wirkt es noch gar nicht so, aber mit der Zeit wird es echt teuer.
Und das war auch bei Fario dann, obwohl es denn nicht der Grund war, nachher halt auch ein großer Vorteil bei der Einsparung.
Warum habe ich jetzt gesagt, Hyperscaler und nicht Cloud?
Es gibt viele, also es gibt viel Diskussionen darum.
Also dass man halt irgendwie, ja, wir gehen jetzt wieder zurück zu Bare Metal, also dass man halt wirklich Server kauft, die in einem Rechenzentrum stehen und die gehören, also der ganze Server gehört einem und da kann man machen, was man möchte.
Das ist eine Option, aber es ist definitiv nicht die einzige Option, sondern man kann eben auch ein Weg dazwischen wählen, wo man eben das, was man vielleicht früher Virtual Private Server genannt hat, was teilweise auch immer noch so genannt wird, also quasi Slices von so einem Rechner zu haben, um eine gewisse Flexibilität zu haben.
Hier geht es jetzt nicht darum, irgendwie, ich weiß nicht, im Stundentakt hoch und runter zu gehen, aber dass man eben vielleicht erstmal klein startet, dann merkt man, okay, es bekommt mehr Traffic oder im Sommer ist mehr los als im Winter, also Saisongeschäfte, dass man da eben mehr Flexibilität hat.
Aber es gibt eben auch andere Gründe, weil Anbieter wie Hetzner Cloud, den Anbieter, zu dem wir bei Fayo gewechselt sind, bieten eben auch noch weitere Services an.
Dazu gehört dann halt so etwas wie ein Load Balancer oder ein Object Storage und so weiter.
Was aus meiner Sicht Gründe sind, eben nicht zu Bare Metal zu gehen.
Und ich glaube, das große Missverständnis, was in vielen Diskussionen aufkommt, ist, dass die Leute denken, dieser Preisunterschied existiert erst bei Bare Metal, aber der Preisunterschied von allem, was ich weiß und beobachtet habe und was wir auch ausgerechnet haben für den Fall von Fayo, besteht zwischen AWS und also AWS Azure, Google Cloud Cloud Professor und allen anderen quasi.
Weil da ist dieser große Gap.
Und der Gap zwischen einem kleinen Cloud-Anbieter, Simple Cloud-Anbieter und Bare Metal ist dann eben vernachlässigbar, meiner Meinung nach und wird ein bisschen vergessen, glaube ich.
Und wir werden auf jeden Fall heute auch nochmal drauf eingehen, wo ich eben die Vorteile bei dem Cloud-Teil gegenüber von Bare Metal sehe.
Genau.
Vielleicht ein paar Ergänzungen.
Also die Grünland-Geschichte ist hier, glaube ich, irgendwie allen bekannt.
Also es gibt eben tatsächlich eine Drohung der Vereinigten Staaten gegenüber Dänemark, die ja für Grönland sozusagen gerade stehen.
Und wir wissen jetzt bereits schon, es gibt ja diesen Fall, dass der internationalen Strafgerichtshof, die eben von Microsoft letztendlich das IT-Zeug abgedreht bekommen hat, sodass es halt irgendwie, also nachvollziehbar ist, dass man halt als dänisches Unternehmen, glaube ich, sagt.
Es ist irgendwie ungünstig, auf eine amerikanische Infrastruktur zu setzen.
Und achso, genau, das weiter hattest du gesagt, es sind halt die Kosten.
Kannst du das beziffern, wie viel weniger das ist?
Genau, also in dem konkreten Fall von Fayo ist es so, dass wir durch den Umstieg 80% der Infrastrukturkosten eingespart haben.
Genau, Zahlen darf ich aber nicht nennen, aber diese Zahl darf ich nennen.
Genau, und also ich fand das halt deswegen spannend, wir hatten halt eben darüber vorab gesprochen, weil ich eigentlich immer der Meinung bin, dass wir optimieren sollten als auf SoftwareentwicklerInnen.
Ich weiß Softwareentwickler im wahnsinnig teuer sind.
Ich muss gestehen, dass das ein Hinweis darauf ist, dass das eben tatsächlich ein valides Optimierungsziel ist.
Einfach aus dem monetären Kontext und ich glaube, von daher ist das halt irgendwie passend und hilfreich.
Und die andere Sache, wie soll ich sagen, auch so eine Sache, die ich im Vorgespräch auch nochmal gelernt habe oder für mich nochmal klar geworden ist, wenn man sich ja beispielsweise Amazon anguckt, das meiste Geld verdienen die eben tatsächlich mit der Cloud und eben nicht mit dem E-Commerce-Business.
Und dazu passt ja das, was du gerade sagst, dass eben die Leistungen, die sie halt bringen, teuer sind, was eben bedeutet, dass sie halt eine hohe Marge haben und dass eben der Vorteil, den sie halt haben, weil sie halt wahnsinnig effizient das natürlich betreiben können, eben letztendlich nicht an Kundinnen weitergeben, sondern eben dort dann entsprechend auf Marscharbeiten.
Gut, das ist jetzt so ein bisschen der Grund, glaube ich, das haben wir dann, glaube ich, abgehakt.
Wie mache ich es denn jetzt?
Also, bevor wir darauf gehen, wäre mein Vorschlag, dass wir nochmal kurz über diese Abgrenzung zwischen diesem Hyperscaler und Simple Cloud eingehen.
Also es gibt viele Cloud-Anbieter, also wirklich viele, und die Angebotsbreite, die die anbieten, ist sehr unterschiedlich.
Also es gibt manche, die haben, also AWS hat konkret über 200 Services, die man kaufen kann.
Ich glaube, es gibt keinen vergleichbaren, also Azure und Google Cloud-Plattform haben auf jeden Fall weniger.
Und ich wüsste nicht, wer sonst irgendwie vergleichbar viel haben sollte.
Und so einen Simple Cloud-Anbieter, der hat halt eher unter 10 Services, die sie anbieten.
Und das heißt also, hier sehen wir schon mal einen Unterschied.
Also natürlich gibt es mehr Sachen, wo ich mit einem Klick quasi was bekomme.
Aber es ist auch natürlich unübersichtlicher.
Ich muss mich mehr einarbeiten, um zu verstehen, welches dieser Offerings jetzt zu dem passt, was ich haben möchte.
Ich muss mehr erklären gegenüber den anderen Leuten im Team.
Was haben, warum haben wir jetzt, weiß ich nicht, diesen Datenbankteil benutzt, weil du kannst ja bei AWS nicht nur eine Art von Postgres betreiben, sondern mindestens drei verschiedene.
Da musst du dich auch schon wieder entscheiden, musst erklären, warum das so ist.
Das haben wir halt alles wesentlich reduziert bei solchen Simple Cloud-Anbietern.
Und wenn man jetzt mal dieses USA-Thema zur Seite schiebt, einfach nur mal auf Simple Cloud guckt, wäre jetzt so für mich der Anbieter, der das so ursprünglich gepusht hat, Digital Ocean, der auch ein US-Unternehmen ist, die halt auch wirklich ein sehr reduziertes Set haben, das ähnlich ist zu dem, über das ich jetzt spreche.
Also das ist nichts Spezifisches bei Hetzner Cloud, da gibt es einfach mehrere Anbieter.
Warum ist das interessant?
Weil wenn wir drüber reden, wir wollen, wir wollen beweglich bleiben.
Also wir wollen jetzt nichts von AWS wechseln zu einem anderen Anbieter und dann wieder im selben Login landen, bei dem wir bei AWS waren.
Und diese geringere, diese geringere Angebot von Services bedeutet, wir haben weniger Login-Effekt, weil wir einen vergleichbaren Anbieter viel einfacher finden können.
Wir können halt sagen, ah, okay, Hetzner Cloud vervierfacht die Preise, das ist blöd.
Jetzt gehen wir zu einem anderen Anbieter, der dasselbe Portfolio hat.
Das heißt, hier sehe ich den ersten Vorteil, weil auch wenn auf den ersten Blick natürlich die 200 Services praktisch sind, und auch gerade halt für einen Startup, was noch gar nicht so genau weiß, was das Businessmodell ist, vielleicht, dann möchte man das mal kurz ausprobieren und dann merkt man, drei Monate später brauchen wir doch nicht, da kann man es halt wegklicken.
Dafür ist das praktisch, aber als etabliertes Business hast du so einen Hin- und Her wechseln, üblicherweise nicht mehr.
Und dann ist es halt eben attraktiver, unabhängiger zu sein von seinem Anbieter, weil man eben flexibler ist.
Da würde ich jetzt, also im Kern sagen, virtuelle Server ist halt Kernangebot von so einem Anbieter.
Load Balancer ist üblicherweise Kernangebot.
Dann Software-Defined Networking, also welcher Server darf auf welchen Server zugreifen.
Das gehört bei allen, die ich kenne dazu.
Und dann eben Block Storage, also die Möglichkeit, eine Network-Attached Storage an einen an meine virtuelle Maschine dran zu hängen.
Auch vor allem sehr wichtig, damit ich virtuelle Server austauschen kann, ohne die Daten zu verlieren und umziehen zu müssen.
Object Storage, das, was man jetzt quasi wie beim Tempo-Taschentuch S3 kennt, also wo man halt einfach quasi so ein Key Value-Store hat, wo man große Daten ablegen kann, wird oft benutzt, um Bilder hochzuladen oder weiß ich nicht, Docker-Images oder was auch immer.
Also sehr vielseitig einsetzbar.
Das sind das, was alle Anbieter, die ich kenne, im Angebot haben.
Und manche Anbieter haben dann zusätzlich noch die üblichen Datenbanken in ihrem Portfolio.
Also ich denke an sowas wie Postgres, Maria.db, wahrscheinlich noch Redis und dann wahrscheinlich Ende.
Manche noch Kafka vielleicht.
Genau.
Das wäre für mich das, was für mich eine Simple Cloud ausmacht.
Das ist eben ein beschränkte Anzahl von Services ist, aber das, was man halt in 99 Prozent der Fälle braucht.
Der zweite wichtige Punkt ist eben Infrastructure as Code.
Also Infrastructure as Code bedeutet, du definierst, welche Server du hast und wie die miteinander reden können und wie die gesized sind und so weiter in Code.
Da gibt es so als den Marktführer-Terra-Form als Tool oder den Fork davon Open Tofu.
Das sind so die zwei üblichen Tools.
Und die das erlaubt uns eben, ein Environment aufzusetzen, sagen wir jetzt mal das Produktionsenvironment und dann ohne Mühe ein Staging-Environment daneben zu setzen, was genauso funktioniert, aber vielleicht ein bisschen kleineres Sizing hat.
Also bei Fayo konkret haben wir genau zwei Environments und das hat natürlich einen kleineren Application-Server und eine kleinere Datenbank, weil das wäre übertrieben für so ein Staging-Environment.
Aber sonst ist es eben gleich.
Und das ermöglicht halt Testing, das ermöglicht, Sachen auszuprobieren.
Also wir haben über die Zeit jetzt auch wieder Services eingeführt, wie ein Image Reverse-Proxy, den erstmal auf Staging aufzusetzen.
Und wenn er da funktioniert, können wir halt, ohne dass wir dann nochmal schauen müssen, was haben wir jetzt alles gemacht, den auf Produktion ausrollen.
Und das ist für mich auch wirklich ein wichtiger Vorteil gegenüber Bare Metal, wo wir sowas natürlich nicht machen können.
Da müssen wir quasi unsere Infrastruktur dokumentieren und dann, wenn wir es nochmal reproduzieren wollen, das quasi in Klick-Ops, wie man das manchmal nennt, durchklicken und hinzufügen.
Genau, also verschiedene Sachen dazu.
Die eine Sache, das war auch etwas, was wir vorher besprochen haben, was ich sozusagen nochmal unterstreichen möchte.
Diese Flexibilität, schnell halt was auf die Reihe zu bekommen, ist vielleicht wirklich etwas, was halt für Startups gerade relevant ist.
Und da muss man sich die Frage stellen, ob es halt später tatsächlich immer noch relevant ist und ist ja auch ein bisschen deine Story, nicht.
Also, Frage ist hier mein Unternehmen, was halt schon länger am Markt ist, und das ist jetzt irgendwie, wäre jetzt überraschend, wenn die irgendwie spontan sagen, wir brauchen eine ganz andere technische Infrastruktur.
Genau.
Dann sozusagen für mich zum Verständnis ist tatsächlich, also ich habe ja früher bei einem Unternehmen gearbeitet, so ein bisschen zufällig, dass er tatsächlich mit Virtualisierung seinen Geld verdient hat.
Sagen die Bare Metal-Leute ernsthaft, dass man halt auf Bare Metal ohne Virtualisierung arbeiten will.
Also nicht, dass Infrastructure as Service oder Infrastructure as Code wird sich für mich so logisch und sinnvoll an, dass ich irgendwie mir nicht vorstellen kann, dass halt jemand sagt, nee, das wollen wir halt irgendwie nicht.
Genau, also da würde mich halt interessieren, warum die es nicht wollen.
Genau, also ein meinungsstarker dänischer Entwickler vertritt die These, dass man Bare Metal machen sollte, weil man dann eben die volle Power von der Maschine bekommt und eben günstiger geht es nicht mehr und wofür braucht man den ganzen Cloud-Kram.
Aber aus meiner Sicht übersieht diese ganze Argumentation, also ich habe mir das auch durchgelesen und mir auch ein Talk nicht gezwungen, den Talk zu schauen, dass der, dass es überhaupt vollständig übersieht, dass es eben Cloud gibt ohne Hyperscaler.
Also ich glaube, diese Option ist irgendwie gar nicht so präsent und Cloud wird irgendwie als quasi als, das sind nur diese drei.
Und ich meine, Cloud hat als Wort ja sowieso schon das Problem, weil es gibt ja sowas wie Own Cloud oder Nextcloud.
Und das ist ja eine ganz andere Art von Cloud.
Das heißt, da kommt ja noch dazu bei der Verwirrung.
Aber ich sehe keine ernsthaften Argumente, warum man Bare Metal machen sollte.
Okay, aber es ist ja tatsächlich Bare Metal gemeint, ohne Virtualisierung und ohne alles.
Okay.
Also, weil, also ich kann das nochmal wiederholen, mir war nicht klar, dass das das ist, was man halt, was er ernsthaft tatsächlich arbeitet hat.
Aber wichtiger Punkt dazu noch eben, ist die, also selbst wenn man jetzt sagen würde, man nimmt ein Virtual Private Server, was üblicherweise eben eine Virtualisierung auf Basis von einem Server ist, hat man als Kunde von den Anbietern, die ich kenne, selten die Möglichkeit, dann das zu automatisieren in der Form.
Also das ist eben ein Resource Sharing, der Teil ist erfüllt, aber der Infrastructure als Code-Teil ist für den Customer nicht erfüllt von allem, was ich kenne.
Okay, alles klar.
Und eine Sache noch, weil, also ist vielleicht sogar gar eine Rückgriff auf die Diskussion, das war auch etwas, was wir, glaube ich, gestern diskutiert hatten.
Diese Login-Geschichten beging dann uns ja auch bei Mainframes nicht.
Und bei Mainframes ist es eben tatsächlich so, dass wir jetzt, also ich mache das mal eine ganze Karriere schon, Mainframe-Migration, ich gehe ja auch davon aus, dass ich mit dem Thema in Rente gehen werde.
Und ein wichtiger Motivator ist dafür halt Login.
Und das ist halt etwas, wo hier eine Analogie ist, wo man halt im Prinzip auf einer modernen Infrastruktur ein ähnliches Thema hat.
Und der Grund, warum irgendwie die Leute gerne von Mainframe weggeben wollen, ist eben, weil sie halt durch den Login dann anschließend Probleme haben, weil es halt einfach teuer wird.
Mainframe-Technologie ist an sich leistungsfähig und gut, aber nicht, dass halt ein Problem.
Ja, definitiv.
Gut.
Jetzt wäre halt die nächste Frage, du hast es gerade eben angesprochen.
Ich glaube, das ist ja auch so ein bisschen so eine so eine Software-Architekturfrage.
Also würde jetzt bedeuten, dass ich eben nicht mein Postgres in fünf Variationen von meinem Hyperscaler bekommen, sondern ich muss das halt selber machen.
Und gerade Datenbanken sind ja aufgrund dessen, dass sie halt Daten speichern, halt ein Problem, weil sie die Daten halt idealerweise nicht verloren machen sollen.
Genau, sodass also im Betrieb nicht nur das Problem ist, dass das Ding verfügbar sein soll, sondern wir müssen auch die Daten gesichert werden.
Und um es jetzt sozusagen brutal zu fragen, das will ich mir ja nicht ernsthaft ans Bein binden, oder?
Also es ist ja eine echte Aufgabe und das, und nicht, wenn es schief geht, habe ich halt ein echtes Problem.
Da ist doch eigentlich die Hyperscaler-Lösung, dass ich es einfach kaufe oder halt einen gehosteten Service irgendwo habe, gibt ja auch andere Möglichkeiten, die bessere Lösung.
Genau, also da muss man jetzt klar unterscheiden zwischen verschiedenen Simple Cloud-Anbietern.
Also, wenn jetzt DigitalOcean betrachten, die haben eben genau dieses Kernangebot, was ich eben beschrieben habe, und Hosted-Datenbanken.
Das ist für mich eigentlich so die perfekte Lösung.
Weil genau den Teil, den möchte ich eigentlich Geld für bezahlen, dass das jemand anderes macht, damit ich mich da nicht drum kümmern muss.
Datenbankadministratoren, die sich damit halt einfach sehr lange schon beschäftigt haben.
Das ist das Optimum.
Aber es gibt eben Anbieter, und dazu zählt Hetzner Cloud, die das eben nicht anbieten, und dann müssen wir es selber machen.
Also, wir haben diesen Wunsch gegenüber Cloud auch schon geäußert, dass sie das vielleicht in ihr Portfolio aufnehmen.
Mal schauen, ob das irgendwann passiert.
Aber grundsätzlich bedeutet das eben, dass wir das selber machen müssen.
Und das empfinde ich als den größten Nachteil gegenüber dem vorigen Setup.
Weil vor allem dem Rest, weil du ja auch eben nochmal auf diesen Punkt, wir wollen ja eigentlich optimieren, dass wir quasi möglichst wenig Entwickler, Entwicklerinnen-Zeit investieren.
Wir investieren nicht mehr Zeit als bei AWS, mit der einzigen Ausnahme der Datenbank.
Sonst haben wir keinen höheren Effort im Vergleich zu AWS.
Aber es ist, wenn ich fragen darf, ja nicht Entwickler in Zeit, sondern Obs-Zeit, nehme ich an, oder?
Genau.
Genau, also das ist auch noch ein wichtiger Punkt.
Also das Fayo, das Team, in dem ich arbeite, wir sind zur fünft.
Das heißt auch, dass quasi alle Leute an allen Stellen mitarbeiten.
Das heißt, wir haben keine klare Trennung zwischen Operations und Development, sondern, also ich schreibe an manchen Tagen Ruby-on-Rails-Code und an anderen Tagen mache ich Operations mit Terraform.
Also das sind keine getrennten Rollen in diesem, auf dieser Unternehmensgröße, sage ich jetzt mal.
Aber ja, genau, ich meine Operations-Zeit und die ist nicht größer geworden als bei AWS, wenn wir den einen Aspekt von der Datenbank ausklammern.
Und deswegen ist das für mich ein wichtiger Faktor, über den wir reden sollten, ja.
Also kann ich daraus ableiten, dass man sozusagen mit einem Team von fünf Personen sich das halt auf die Fahnen schreiben kann oder anders gefragt und also welche zusätzlichen Rahmenbedingungen sollte ich halt einhalten, damit ich da nicht irgendwie gegen die Wand fahre.
Genau.
Also auf jeden Fall, also das funktioniert.
Und ich glaube, der eine der Gründe dafür ist, dass es eben ein kleines Set von Technologien ist, über das Gerät.
Wir reden eben nicht darüber, dass es irgendwie zehn verschiedene Technologien geht, in allen muss ich mich einarbeiten.
Was üblicherweise so ist, wenn wir auf ein Unternehmen gucken, was ein Frontend hat in Angular oder React und dann halt irgendwie einen Spring Boot, Backend und dann vielleicht ein Kubernetes-Cluster und was weiß ich, dann brauchen wir Experten und Expertinnen in jedem der Bereiche, weil es sehr schwer ist, in jedem dieser Bereiche Experte oder Expertin zu sein.
Und deswegen ist der Ansatz bei Fayo, sich auf wenige Technologien zu beschränken.
Also in dem Fall ist es die Anwendung, ist eine Ruby-on-Rails-Anwendung.
Es ist Server-seitiges Rendering ohne Angular, React und so weiter, sondern mit Progressive Enhancement, also wenig JavaScript, sodass einfach der Technologie-Stack beherrschbarer ist.
Und deswegen haben wir uns auch in dem Fall gegen ein Kubernetes entschieden, beispielsweise, weil das eben auch nochmal eine weitere Technologie ist, die das Team lernen müsste.
Ich glaube, diese Abschätzung, also gerade die letzte Abschätzung, ist nochmal anders, wenn wir über ein Team von 20 Leuten sprechen oder wenn wir über ein Team von 100 Leuten sprechen.
Definitiv, da muss man das auch einfach auf den Use Case anpassen.
Aber wenn wir halt unter 10 Personen sind und wir wollen halt auch ein bisschen dafür sorgen, dass nicht eine Person on Call ist, 24.7 quasi, weil alle anderen gar nicht verstehen, wie diese Infrastruktur versteht, äh funktioniert, dann müssen wir dafür sorgen, dass das verstehbar, also einfach zu verstehen ist, einfach man sich einarbeiten kann.
Was im Umkehrstoß bedeutet, wenn ich halt sozusagen ein größeres Unternehmen bin, dann könnte ich halt, also würde ich wahrscheinlich tatsächlich eine Infrastruktur schaffen im Sinne von sowas wie Team Topologies und ein Plattform-Team haben, der das dann irgendwie dafür sorgt, dass das ja irgendwie ein Postgres irgendwie betrieben werden kann.
Richtig, also und das ist eben auch das, weswegen ich denke, dass dieser Simple Cloud-Ansatz eben auch auf verschiedenen Ebenen funktioniert.
Er sieht dann halt in der Praxis nicht exakt gleich aus.
Aber trotzdem ist es eben so, dass ich eben vorschlagen würde, dass ein großes Team, eher auch ein Plattform-Team aufsetzt, was dann eben auch eine Datenbank betreiben kann, damit das eben nicht das Team selber tun muss.
Weil wir dann eben die Ressourcen haben und das Geld haben, um zu sagen, hey, wir haben Spezialisten und die wissen exakt, wie man eine Postgres betreibt.
Und dann ist der Nachteil, dass halt ein Anbieter vielleicht gar keine Datenbank as a Service anbietet, sowieso schon nicht mehr da.
Aber dann ist es auf jeden Fall auch eine Überlegung wert, passt jetzt Kubernetes vielleicht besser zu diesem zu diesem Unternehmen als den Docker-Swarm-Mode, den wir gewählt haben.
Genau.
Der Robert Wiesner schrieb gerade Ruby on Reads mit einem mit diesem Smiley mit dem Herzen in den Augen.
Okay.
Ja, genau, also es ist eine Ruby on Rails-Arbettung, genau.
Bevor wir da hinkommen, ich weiß nicht, wollen wir kurz über diese Geschichte mit der JobQ sprechen.
Können wir ja gerne machen.
Also wollen wir erstmal noch kurz das Datenbankthema einmal anschauen.
Das sei noch das Datenbank-Thema, aber fair, fair, ja ist es.
Ich will einfach nur nochmal darauf hinweisen, weil ich glaube, viele Leute haben diesen das quasi vergessen, weil es so selbstverständlich geworden ist, dass das eine Datenbank was ist, wo man draufklickt und dann ist die halt da.
Aber wir müssen halt, wenn wir das selber machen, bedeutet, dass wir uns um eine Backup-Strategie kümmern und die auch regelmäßig testen, damit wir sicherstellen, dass keine Daten verloren gehen.
Das ist allein schon eine Herausforderung.
Also das ist nichts, was man in fünf Minuten aufgesetzt hat.
Da muss man sich einfach mit beschäftigen.
Wir haben da auch dann recherchiert, was passt am besten zu uns, wie können wir auch sicherstellen, dass wir eine Point-in-Time-Recovery machen.
Also nicht nur jede Nacht wiederherstellen können, sondern halt auch auf Stundenbasis sagen können, hey, um die Uhrzeit ist irgendwas Schlimmes passiert, wir wollen davor hin zurück.
Solche Sachen waren halt wichtig, wichtige Teil der Strategie.
Und genauso die Konfiguration, also ich rede jetzt speziell über Postgres, bei Maria.db ist es ein bisschen anders, aber es ist ein anderes Thema.
Die Default-Konfiguration von Postgres ist nicht geeignet für große Server, weil die Postgres-Leute haben eine sehr konservative Einstellung und sagen halt, wir wollen quasi, die Default-Konfiguration soll auf jedem beliebigen Computer laufen können.
Wenn man dann halt da eine Maschine mit 192 Gigabyte RAM mit betreibt, dann kriegt man nichts von dem Wumms von dieser Maschine mit, wenn man einfach die Default-Konfiguration benutzt.
Das heißt also, wir mussten halt auch uns nochmal beschäftigen damit, was ist die Konfiguration der Datenbank, an welchen Stellschrauben müssen wir drehen.
Das auch einfach nur mal als Beispiel für einen Aspekt, den man übersieht, wenn man das einfach als Service einkauft.
Also und das auch eben diese Komplexität, die da, die da dran hängt.
Und dann kann es nochmal einen Schritt noch komplizierter werden, wenn man eben nochmal ein Hot Stand-Bein, in Anführungsstrichen haben möchte, also die Möglichkeit mit möglichst wenig Downtime auf einen Ersatzserver zu wechseln.
Das ist Gott sei Dank mittlerweile in so einer Datenbank wie Postgres problemlos möglich, aber auch das kostet wieder Zeit und man muss sich einarbeiten und verstehen, wie es funktioniert und dann vielleicht auch nochmal ein Testlauf machen und gucken, dass es auch wirklich funktioniert.
Und das ist eben das, was da sich aufaddiert als Komplexität.
Kann man das irgendwie quantifizieren?
Also ist es eine schwierige Zeitaufwand?
Ja.
Also es ist eine schwierige Frage.
Ich dachte nur, ich frage es sozusagen mal, also reden wir über einen Tag, reden wir über eine Woche oder.
Also die Postgres-Konfiguration, also die Postgres-Konfiguration inklusive Backup vollständig zu machen, hat uns waren ungefähr drei Wochen Arbeit, das vollständig fertig zu machen.
Also inklusive Tests von dem ganzen Zug, genau.
Der Anatolic hat bei LinkedIn gefragt, ist die Autoskalierung in dem Projekt ein Thema?
Nehme ich mal nicht an.
Also da gibt es ja ein AWS, wie wahrscheinlich bekannt, diesen Elastic Load Balancer, und dann gibt es halt die Möglichkeit, mehr virtuelle Maschinenlos hochzufahren.
Und das Kostenmodell von AWS ist ja auch so, dass man dann eben Maschinen, ich glaube, pro Stunde bezahlt.
Also zumindest war das halt so, als ich das noch kannte, so dass man halt dynamische Loadpeaks halt abfangen kann durch Autoskalierung und dabei eben auch tatsächlich nicht die Infrastruktur die ganze Zeit vorhalten muss.
Genau, also grundsätzlich, also auch eine der wichtigen Zutaten da ist ja, dass der Loadbalancer eben die Load feststellt und dann eben merkt, okay, ich muss ein Signal geben, dass wir mehr Server hochfahren.
Also wir arbeiten durchaus mit Skalierung, aber nicht mit Autoskalierung.
Also bei Fayo ist es eben so, dass es ein Saisongeschäft ist.
Es gibt Monate, in denen ist der Traffic ein Vielfaches höher als in anderen Monaten, weil da einfach häufiger gebucht wird.
Das heißt also, wir haben keine Hot, in fünf Minuten müssen wir jetzt die Skalierung hochfahren, aber es ist durchaus so, dass wir halt in bestimmten Monaten einfach hochfahren und dann merken wir, okay, Peak Season der Buchung ist jetzt so langsam vorbei, wir fahren die Kapazität wieder langsam runter.
Das ist problemlos möglich.
Und wir könnten auch innerhalb von vertretbarem Zeitraum auch selbst hochskalieren, weil wir eben alles als Infrastructure as Code haben, können wir einfach mit zwei Befehlen doppelt so viel Compute da zur Verfügung stellen.
Das, was wir nicht haben, ist, dass das das System von sich aus macht.
Und da hatten wir einfach die Anforderung nicht.
Und deswegen haben wir da auch keine weitere Zeit investiert.
Und meiner Erfahrung nach ist es auch so, dass das in vielen Bereichen auch wirklich eigentlich nur eine theoretische Anforderung ist, die irgendwie gemacht wird.
Aber braucht man es wirklich?
Und es gibt natürlich Bereiche, wo man es braucht, das möchte ich gar nicht in Abrede stellen.
Ich würde einfach nur mal in Frage stellen, ob es wirklich auf dieses super schnelle reagieren, dass ohne dass jemand was tut, das automatisch passiert.
Ob das wirklich eine Anforderung ist, war jetzt in dem Fall keine Anforderung.
Ja, also tatsächlich ist es ja so, ich habe irgendwann jemanden gesehen, der tatsächlich auf einem Kurzblocking-Dienst hatte ich das damals geschrieben.
Und das hätte auf eine frühige Band von wegen die Skalierung ist die Nummer 1 Anforderung, die man eigentlich nicht hat.
Nur Interessehalber und die Granularität, in der ich jetzt abrechne, ist die auch stundenweise oder tragebar.
Das wollte ich auch noch gerade sagen.
Gut, gut, danke für die Frage.
Genau, also bei Hetzner ist es stundengenaue Abrechnung.
Und das ist, glaube ich, bei allen Anbietern, die ich mir angeguckt habe, gibt es diese Option.
Meistens kriegt man halt quasi ein Monat günstiger, als wenn man jetzt quasi ein Monat in Stunden bezahlen würde.
Aber genau, grundsätzlich geht das.
Das heißt, wenn man jetzt wirklich einen Peak hat, sagen wir jetzt mal, wir haben, wir machen eine große Aktion, also keine Ahnung, 20% Rabatte auf alles.
Dann könnte man im Vorhinein kurzfristig die Kapazitäten hochfahren und danach wieder runterfahren, ohne dass wir dafür einen ganzen Monat bezahlen müssen.
Auch Interesse habe, also das ist ja gesagt, das ist keine Anforderung, aber wenn das eine Anforderung wäre, was hält mich denn eigentlich davon ab zu sagen, okay, wenn da das Monitoring gerade feststellt, dass alle Webserver ausgelastet sind, dann fahre ich halt einfach noch einen hoch.
Das höchst du sein, als könnte man es einfach bauen.
Das könnte man bauen, aber das ist halt der Unterschied ist, dass du das eben bei AWS über diese Scaling-Groups quasi mit ohne Aufwand bekommst.
Und wenn du das eben in einem anderen System machst, dann musst du selber dafür sorgen, dass das passiert.
Also bei uns ist es jetzt zum Beispiel so, auch wieder aus diesem Pragmatismusgrund, diese Terraform-Sachen, die werden von den Entwicklermaschinen aus ausgeführt.
Weil es ist halt nicht notwendig, das im CI zu machen.
Wenn wir das machen wollen würden, könnte man das tun.
Und dann hätte man auch die Möglichkeit, auf bestimmte Events zu reagieren und dann eben hochzuskalieren.
Aber Ziel ist ja eben so einfach wie möglich.
Wenn das eine Anforderung ist, kann man das erfüllen, aber ist halt einfach wieder Aufwand, den man reinstecken muss und der ist höher, als er bei AWS wäre.
Oder auch bei Heroku, also als jetzt so ein Platform as a Service-Anbieter.
Halt Architekturanscheidung, nicht?
Also ich mache halt nichts.
Ich mache halt nichts, wenn ich halt nicht die Anforderung habe, dass halt ist das halt irgendwie automatisch skaliert.
Gut, wollten wir jetzt über JobQs sprechen?
Ja, gerne.
Ja, also eine der Dinge, die wir diskutiert hatten, war eben, also bevor wir den Umzug gemacht haben, hat Fayo es so gemacht, dass wie das in Ruby on Rails sehr üblich ist, Redis als das Backend für die JobQ zu benutzen.
Genauso wie als Backend für den Cache.
Also hier nochmal kurz, also Cache in dem Fall bedeutet, Inhalte, die die Anwendung da hinlegt und schnell abrufen kann und nicht sowas wie ein Warnisch der vor der Anwendung steht.
Also es gibt ja zwei verschiedene Arten von Cache.
Und da hatten wir halt diskutiert, brauchen wir, brauchen wir dann eine Redis?
Also sollten wir auch ein Redis aufsetzen oder ein Walkey, wie auch immer.
Also eine von den Redis-artigen Datenbanken.
Und haben dann entschieden, wir probieren jetzt mal aus, dass was mit Rails 8 gekommen ist, quasi diesen neuen Default, den neuen Default-Que-Backend, der eben die Datenbank als Queue benutzt.
Und das haben wir gemacht, haben das umgestellt und es funktioniert wunderbar.
Dazu muss man wissen, dass Fayo ein wirklich hohes Maß an Background-Job hat.
Weil Fayo eben als Vermittlungsplattform Informationen von Partnersystemen einsammeln muss, über die Häuser, über die Verfügbarkeiten und so weiter.
Das heißt, es laufen ständig sehr, sehr viele Background-Jobs.
Und trotzdem funktioniert das eben auch mit einer Datenbank als Backend problemlos.
Also wir haben da gar keine Nachteile feststellen können.
Die spezielle Software hat noch an ein, zwei Stellen, so im Admin-Interface sind Sachen nicht mehr so cool wie die Lösung, die wir davor hatten, aber das hat wirklich gar nichts mit der Simple-Cloud zu tun, dass es wirklich jetzt Rails-spezifisch.
Aber sonst funktioniert das wirklich super.
Und der Grund, warum das so ist, ist, dass also es gab früher auch in der Rails-Community viele Diskussionen darüber, benutzen wir unsere Datenbank als Queue.
Und da wurde viel mit sozusagen Brute Force quasi immer wieder abgefragt, gepollt quasi nach Jobs.
Und das hat die Datenbank-Performance halt wirklich signifikant kaputt gemacht.
Und mittlerweile können, also Postgres war die erste Datenbank, die das eingeführt hat mit Advisory-Logs und so weiter, so ein paar Tricks, kann ich gerne auch nochmal ein Link für die Shownotes dazugeben.
Um extrem effizient mit PubSub in Postgres zu arbeiten, um das, um das Job-Processing zu machen.
Und dann hat man keinen Nachteil gegenüber einer Redis.
Und beim Caching ist es eben so, wenn wir eine Tabelle, man kann Tabellen anlegen, die nicht auf die Platte geschrieben werden, in Postgres.
Und dann ist es eben auch nur ein In-Memory-Zugriff.
Und auch das funktioniert für uns gut.
Wir benutzen aktuell noch relativ viel Caching.
Wir haben da auch noch Pläne, das zu verändern, aber auch in dem aktuellen Szenario funktioniert das wirklich sehr gut.
Und dadurch haben wir quasi nur zwei Systeme, die Daten halten.
S3, was wir halt einkaufen, also es heißt nicht S3, Job Object Storage von Hetzner und die Datenbank, die wir halt selbst betreiben.
Das sind die zwei Orte, an denen Daten liegen und mehr Orte haben wir nicht.
Und das macht es natürlich auch einfacher zu managen.
Was aber wiederum bedeutet, und das ist, glaube ich, ein Mieterpunkt und nicht, also es ist hier so fällt sich drumstream, dass man im Prinzip jetzt halt eine Architekturanschreitung, die hat dazu geführt hat, dass man sagt, wenn man da JobQs mit Redis, die ist eben durch dieses Thema revidiert und umgebaut worden, was halt wiederum bedeutet, dass man das eben nicht einfach so migriert, sondern eben dann tatsächlich umbaut und dann erst migriert, logischerweise, weil nicht, also Redis auf der neuen Infrastruktur zu betreiben, will man ja nicht.
Das ist gerade der Grandpunkt.
Ja.
Genau, und das ist halt auch wirklich eine unserer Leitprinzipien jetzt bei diesem Umzug gewesen.
Wir haben quasi die gesamte ABS-Um-Infrastruktur umgebaut auf AWS und so, dass wir sie so haben, wie wir sie auf Hetzner haben wollen.
Und erst dann haben wir den Umzug gemacht, um zu vermeiden, dass beim Umzug was passiert und man nicht mehr weiß, welche, aus welchem Grund es kaputt gegangen ist.
Also haben wir zum Beispiel erst diese JobQ umgestellt.
Wir hatten am Anfang auch ein, zwei Probleme, die wir dann untersucht haben und fixen konnten, aber wir wussten, es liegt an dieser Umstellung und es ist nicht irgendwas, was kaputt gegangen ist.
Und das würde ich auch wirklich jedem vorschlagen, dass man eben versucht, dass den Diff zwischen den beiden Environments möglichst gering zu halten.
Ich würde an der Stelle auch noch gern auf das Thema Kosten an der Stelle eingehen, weil das ist nämlich auch ein wichtiger Faktor.
Eine der ganz gemeinen Tricks von Amazon, also vor allem Amazon, ich glaube aber bei den anderen zwei ist es jetzt auch nicht besser, ist, dass sie einen Login-Effekt über die sogenannten Egress-Kosten verursachen.
Das bedeutet, dass wir, wir müssen die Daten, die rausgehen aus AWS, müssen wir bezahlen.
Und diese und diese sind übermäßig teuer.
Also wirklich übermäßig teuer.
Das heißt, also, nehmen wir es mal als Beispiel, wir benutzen Cloud Front, also das CDN, was AWS anbietet, im Vergleich zu Cloud Flare, also jetzt auch einem, ich würde ihn auch als Hyperscaler bezeichnen.
Dann sind die Kosten zwischen Cloud Front und meinem und meiner Anwendung kostenlos und die Kosten zwischen Cloud Flare und meiner Anwendung nicht kostenlos.
Das heißt also, man bezahlt zusätzlich dafür, dass man eben einen externen Anbieter wählt.
Und das müssen wir uns bewusst machen.
Und also ich glaube, vielen ist gar nicht bewusst, weil sie bisher quasi einfach alles in AWS haben, wie hoch dieser Faktor ist, das vorher mal ernsthaft durchzurechnen, weil das auch die Strategie, mit dem wir den Exit machen, extrem beeinflusst.
Weil man könnte ja denken, irgendwie, man zieht erstmal zwei, drei Services raus, macht die erstmal auf der neuen Plattform, aber wenn dann zwischen diesen Services und meiner meinen Service, die noch auf AWS sind, sehr viel Traffic sind, kann das sehr, sehr teuer werden, weil eben die Egress-Kosten so hoch sind.
Und das war eine der Gründe, warum wir eben diesen Weg gewählt haben, also auf einen Schlag möglichst umzustellen und dann eben so die Änderung erstmal in AWS zu machen.
Also bedeutet halt tatsächlich, dass an dem einen Tag das Ding noch auf AWS lief und am nächsten Tag dann auf Heads, habe ich das richtig verstanden?
Auch vollständig.
Ja, genau.
Das ist ja eigentlich ein hohes Risiko, oder?
Also das kann ja leicht, oder?
Also das Risiko bestand darin, dass man quasi eine längere Downtime haben hätte können.
Also konkret geht es eigentlich nur um den Datenbankbestand, der ein Problem war.
Weil wenn wir jetzt hätten, gemerkt hätten, okay, bei Hetzner funktioniert nicht, wir müssen es zurück, dann hätten wir quasi erstmal den Datenbestand von Hetzner wieder zu AWS zurückziehen müssen.
Aber grundsätzlich haben wir die AWS-Infrastruktur auch noch eine gewisse Zeit laufen lassen und hätten auf die wieder umstellen können.
Also die haben wir nicht abgerissen.
Aber ja, das wäre ein Faktor gewesen.
Wir haben auch auf, also wir haben eine Downtime gehabt.
Wir haben also eine Statusseite aufgeschaltet.
Aktuell haben wir Umbauarbeiten und in der Zeit haben wir dann sichergestellt, dass das Backup up to date ist, haben das Backup eingespielt und dann haben wir umgelenkt.
Aber das war, ich müsste es jetzt mal nachschauen, aber es war ungefähr eine halbe Stunde und wir haben das eben so getimt, dass es zu der niedrigsten Zeit ist, wo am wenigsten Traffic auf dem System ist.
Das ist natürlich auch wieder unterschiedlich.
Wenn man jetzt einen Geschäft hat, wo quasi ununterbrochen Traffic ist, muss man sich eine andere Strategie überlegen.
Aber wir konnten eben uns einfach eine Stunde aus.
Also wir haben, glaube ich, gesagt, eine Stunde als Maximum setzen wir uns.
Und wenn es länger dauert, dann müssen wir es doch irgendwie anders machen oder abbrechen.
Und das hatten wir halt einfach mit der Geschäftsführung abgesprochen.
Und ich glaube, dass es in vielen Unternehmen möglich ist.
Also manche Unternehmen haben quasi am Wochenende kein Traffic, manche haben nachts kein Traffic.
Da muss man halt einfach gucken, was ist der richtige Zeitpunkt.
Aber damit spart man sich halt auch unfassbar viel Kopfschmerzen, wenn man versuchen möchte, quasi Zero Downtime diesen Umzug zu machen.
Ja, also ich muss hier gestehen, auf meiner Abstraktionsebene ist das halt wieder eine Architekturentscheidung.
Und im Prinzip sagst du halt, die Kosten sind wichtig, also die Kosten rechtfertigen nicht, diese halbe Stunde Downtime einzusparen und deswegen und das Risiko ist irgendwie sozusagen beherrschbar und da machen wir es halt irgendwie so.
Und wenn man halt eine andere Umgebung hat, macht man halt was anderes, weil man vielleicht das Geld übrig hat und eben andere Optimierungsmöglichkeiten hat.
Von daher.
Genau, also und das ist auch nichts Unlösbares.
Also man müsste sich halt dann eine Replikation überlegen, die über die Grenze hinweg geht.
Aber auch an der Stelle einfach nochmal als Reminder, weil ich das zu oft merke, dass die Leute quasi diesen, weil das irgendwie das ist, was man gelesen hat, macht man das, weil das so, man muss Zero Downtime erzeugen.
Aber ich würde einfach vorschlagen, einfach mal ernsthaft zu fragen, können wir uns eine halbe Stunde Downtime leisten?
Weil die kostet ja auch, die kostet etwas vielleicht, weil wir entgangenen Umsatz haben, aber vielleicht kostet sie weniger als der zusätzliche Engineering-Aufwand, diese Migration Zero Downtime zu machen.
Und ich glaube, diese Abwägung, die fehlt mir ein bisschen zu auch.
Ich muss halt gestehen, ich muss die ganze Zeit in dieses LinkedIn-Posting, glaube ich, von Gernot sehen, was sie denken, was ich halt im Vorbeigehen gesehen habe, wo sich halt darüber aufgeregt hat, dass irgendeine Bank seine Bank halt irgendwie übers Wochenende gesagt hat, hier geht halt gar nichts.
Und von daher, also nicht eine halbe Stunde hört sich jetzt irgendwie nicht wie ein Drama an für mich.
Genau, genau.
Und genau.
Deswegen schaut euch das an und erklärt das erstmal mit den Stakeholdern ab, weil ich glaube, da wird sehr viel Engineering-Arbeit geleistet, die vielleicht gar nicht zielbringend ist an der Stelle.
Dann haben wir.
Achso, da können wir halt, glaube ich, kurz, ich verlinke das auch nochmal, es gab halt im Vorhinein diese Frage.
Aber, also ich paraphräisiere, da gibt es halt einen längeren Mastodon-Thread, den kann man irgendwie auch nachlesen.
Und die Kurzzusammenfassung ist halt, aber das bedeutet ja, dass irgendwie Hetzner ein Risiko wird und eben alles auf Hetzner läuft und dass man da irgendwie das nächste Risiko hat.
Also wenn Hetzner ausfällt, dann fällt eben dabei halt die Aussage des halbe Feediverse halt irgendwie in sich zusammen.
Und dann habe ich halt ein massives Problem.
Was sagst du?
Genau, also da würde ich zu sagen, dass ich glaube, gerade, also das ist irgendwie so ein Fediverse-Ding, glaube ich, das hat sich so ein bisschen zu einem Meme entwickelt.
Ich glaube auch, dass das Feediverse wirklich sehr stark irgendwie auf Hetzner läuft, aber das ist eben keine Betrachtung, die sich deckt mit dem Rest der Welt.
Also Hetzner ist, spielt nicht mal irgendwie im selben Stadion wie ein AWS.
Also, das ist halt so viel größer, das kann man nicht mal ernsthaft vergleichen.
Und es ist auch noch nicht mehr einer der größten Anbieter.
Also, wenn wir jetzt an so Firmen wie Ionos denken, die sind viel, viel größer als ein Hetzner.
Ich glaube, das ist ein bisschen eine Fehlwahrnehmung.
Ich stimme aber zu, dass man natürlich darauf achten muss, dass man nicht jetzt irgendwie quasi den deutschen Hyperscaler erzeugt und dann dieselben Probleme hier hat.
Also da stimme ich zu.
Aber ich glaube, man muss schon uns auch nochmal jetzt klar machen, wenn wir Unternehmen haben, die einen gewissen Scale haben, dann brauchen wir auch einen Hoster, der einen gewissen Scale hat.
Wir können nicht alle quasi bei unserem Server jetzt da in den Schrank reinschrauben und einfach selber machen.
Wir wollen halt eine gewisse Agilität, gewisse Bewegungsfreiheit haben.
Und dann müssen wir auch damit einverstanden sein, dass das bedeutet, bis zu einem gewissen Grade werden die größer.
Aber ja, wir sollten schon darauf achten, dass wir jetzt keinen neuen Monopolisten erzeugen, würde ich jetzt mal behaupten.
Wobei der ja vor allem Austausch weiß nicht, das ist ja, glaube ich, der Punkt.
Das heißt, das Zeug, was ihr jetzt habt, könntet ihr, oder korrigiert mich, aber könntet ihr halt morgen irgendwo anders betreiben.
Genau, das war ja das, was ich am Anfang sagte und das ist mir schon wichtig.
Und nur nochmal, weil das glaube ich auch viel nicht bewusst ist.
Die Amazon, Microsoft und Google, diese drei Firmen alleine haben einen Marktanteil von 63 Prozent im Cloud-Markt.
Also diese drei Firmen.
Und da spielt halt auch Ionos keine Rolle, obwohl das ein Riesenunternehmen ist.
Genau, du hast halt die Umsatzzahlen veröffentlicht und das stand halt, dass Ionos halt eineinhalb Milliarden Umsatz.
Hetzner hat 360 Millionen, Digital Ocean 700 Millionen und nicht.
Also Telekom Cloud ist ja wahrscheinlich auch irgendwie groß.
Das ist, glaube ich, der Punkt dazu.
Da ist eine Frage von der Marcel Krämer in LinkedIn.
Der hat geschrieben, wie habt ihr das Thema Sicherheit gelöst?
Headsner bietet ja, soweit ich weiß, keine Waffe, also Web Application Firewall, Intrusion Detection und so weiter und die meisten Mittelstände haben kein Sorg, dass er am Mittelwochenende etc.
bereitsteht.
Genau, also Hetzner Cloud bietet D-DoS-Protection, aber keine Waff, das ist korrekt.
Wir, also schon vorher war es eben so, dass die Anwendung hinter Cloudflare läuft und Cloudflare ist quasi die Web Application Firewall und auch unsere DDoS-Protection.
Also wir benutzen gar nicht die DDoS-Protection von Hetzner Cloud.
Mittelfristig wollen wir natürlich auch von Cloudflare weg, weil das eben ein ähnliches Problem ist.
Aber wir lösen halt ein Problem nach dem anderen.
Und da gäbe es dann eben als Option auch beispielsweise einen europäischen CDN-Anbieter zu wählen, der ein ähnliches Angebot hat.
Ich glaube nicht, dass das unbedingt derselbe Anbieter sein muss, der das macht.
Und WAF gibt es eben auch einfach als Open Source-Software, die man bei sich dann selbst betreiben kann.
Und ich glaube, da überschätzen auch viele die Komplexität.
Also das, was Cloudflare bietet, was schwer nach, also schwer zu bieten ist, ist eben diese weltweite Entdeckung von Botangriffen, weil die einfach durch ihren Scale wissen, die kennen den globalen Traffic im Prinzip.
Das kriegst du halt nicht repliziert, aber die WAF-Protection von denen ist jetzt auch nicht so super sophisticated.
Intrusion Detection hast du jetzt ausgeklammert, also hast du nichts dazu gesagt?
Genau, also, also grundsätzlich wehre mich immer ein bisschen dagegen, dass man halt irgendwie denkt, weil man da was geklickt hat, ist man jetzt sicher.
Ich glaube, dass es ein Problem ist, was man immer lösen muss und immer im Blick halten muss und wo halt auch viel in der Anwendung gelöst werden muss.
Aber wie gesagt, es gibt existierende Systeme, die man dazu deployen kann.
Man müsste sich in dem Fall von Hetzner eben selbst darum kümmern.
Aber ehrlicherweise sehe ich da nicht so einen großen Blocker.
Aber wir haben eben als quasi unsere Firewall, in Anführungsstrichen, haben wir eben Cloudflare.
Und dann war die andere Frage von Zockbusch heißt der Mensch.
Oder ich vermute, er heißt nicht so, aber das ist das Hände, was er oder sie sich gegeben hat.
Und da war die Frage, ich würde gerne eure Einschätzung hören, wie kleine Rooster wohl in Sachen weltweite Pops, also Points of Presence für regionales Hosting, zum Beispiel für Latenzobdingung darstellen.
Anscheinend hat zumindest Hetzler wohl schon vier Zonen im Angebot, EU Central, US East, US West und AP, also Asia Pacific South Southeast.
Und da geht es halt darum, dass man eine globale Verteilung haben möchte.
Die halt dazu führt, dass eben der Rechner irgendwie mindestens mal auf dem selben Kontinent steht, mit dem man halt irgendwie zu tun hat, damit irgendwie die Latenz nicht explodieren.
Genau, also da würde ich erstmal nochmal einen Schritt nochmal zurückgehen und fragen, was genau möchte man eigentlich mit dem Pols of Presence erreichen, weil, also ich habe ja bis letzten Sommer das Webteam von Komoot geleitet, was ja ein weltweit operierende Anwendung ist mit sehr vielen Usern.
Und da haben wir auch die Entscheidung getroffen, dass der, dass die das Backend läuft in einer Region von AWS.
Und der C und der Rest ist über ein CDN abgebildet, dass wir eben weltweit verfügbar sind und schnell verfügbar sind, weil du sonst eben große Schwierigkeiten hast, die Datenkonsistenz weltweit sicherzustellen.
Da gibt es Möglichkeiten, aber die sind alle nicht for free.
Ich glaube, es gibt Anwendungen, bei denen das so ist.
Ich glaube, es gibt auch Anwendungen, bei denen man beispielsweise sagen kann, okay, wir haben die Kundendaten der US-Kunden in einem US-Data Center, die europäischen Europa und die australischen Australien.
Aber das ist oft auch schon schwierig, weil man eben doch irgendwie eine Kommunikation zwischen allen erreichen möchte.
Also da gibt es einfach keine einfachen Lösungen.
In dem Fall von Komoot wäre das also aber auch kein Blocker gewesen, obwohl das eben eine wirklich große Anwendung war oder ist, Entschuldigung.
Und ja, deswegen weiß ich nicht, ob man von seinem Hester in Anführungsstrichen das erwarten muss oder sollte, sondern ob das nicht einfach eher nochmal eine Aufgabe ist für dieses Layer des Content Delivery Networks.
Genau, das wäre meine Antwort darauf.
Ja, also ich muss ja gestehen, es ist ja auch wieder so eine Geschichte mit Architekturentscheidung nicht.
Also im Prinzip ist ja die Anforderung, eine bestimmte Latenzzeit, und was du halt eher im Prinzip sagst, ist, die Latenzzeit kann man wahrscheinlich möglicherweise erreichen mit einem CDN und einem Backend, was er dann an einer Stelle ist.
Und ich muss gerade an einem Projekt denken, wo das eigentlich für mich auch der Hinweis gewesen wäre, wo er also sehr schnell viel Caching eingeführt worden ist, ohne dass mir halt zumindest klar war, ob man das wirklich muss und ob nicht einfach stumpfe Sachen irgendwie ausreichen und irgendwie die globale Verteilung auch ein Thema war, wo mir auch nicht klar war, warum man nicht den Ansatz, den du gerade skizziert hast, benutzt hat, mir viel da empirische Hinweise.
Der Dominik.
Eva darf ich dich kurz unterbrechen, ich glaube, wir sollten einmal noch kurz auf die Frage von Jens Eck Eckmeier eingehen, weil der die eben vorhineingestellt hat, oder?
Ja, sehr gerne.
Genau, also ich habe jetzt die Formulierung nicht mehr vor mir, aber er hat halt gefragt, ob wir auch Kamal evaluiert haben als Alternative, als alternativen Ansatz oder ob das, ob wir das benutzt, benutzen.
Und die Antwort darauf ist, wir haben es uns angeschaut und wir haben uns dagegen entschieden.
Ich hatte ja eben schon gesagt, dass wir das ist ein Ding überhaupt.
Genau.
Danke, gute Frage.
Also Kamal ist ein Deployment-Tool, würde ich jetzt mal sagen.
Also ein Tool, was einem dabei hilft, Docker Container auf dem Server zu deployen und sich halt um bestimmte Aspekte des laufenden Betriebs kümmert, wie zum Beispiel eine neue Version des Docker-Containers auf dem Server zu deployen.
Und das Problem, also aus meiner Sicht hat Kamal ein Problem gelöst, was vorher schon gelöst war und benutzt dabei Tools, die sie selbst benutzen.
Also ist es etwas absurd aus meiner Sicht.
Was wir stattdessen benutzen, ist Docker Swarm-Mode.
Und das führt zu viel, ich glaube, dass das Hauptproblem von Docker Swarm Mode ist der Name.
Es gab nämlich mal einen Produkt, das hieß Docker Swarm, das heißt heute Docker Classic Swarm.
Und das ist eingestellt.
Das gibt es nicht.
Also das wird nicht mehr aktiv weiterentwickelt.
Das ist aber einfach ein vollständig anderes Produkt.
Und weil die den Namen so cool fanden, haben sie ihn für ein neues Produkt wiederverwendet.
Das war aus meiner Sicht ein Fehler, weil jetzt die Leute, wenn sie Docker-Swarm hören, denken, ach, das ist doch das, was es nicht mehr gibt.
Aber Docker-Swarm-Mode ist einfach eine Funktionalität, die ist in Docker eingebaut.
Dafür müsst ihr gar nichts zusätzlich installieren, es ist einfach dabei.
Und die wird auch weiter maintained und weiterentwickelt.
Da gibt es gar keine Aussage, dass das überhaupt deprecated ist oder sonst irgendwas.
Also das einfach mal festgehalten.
Und das, was uns Docker-Swarm-Mode bietet, über Docker einfach auf dem Server hinweg, ist das Zero-Downtime-Deployment von Containern.
Weil in Docker-Swar-Mode kann ich sagen, hier nimm bitte diesen Container und fahre den hoch.
Wenn der Health-Check von diesem Container grün ist, dann lenkt den Traffic auf den neuen Container um und schalte den alten ab.
Das ist das Einzige, was in Docker fehlt, um ein gutes Deployment zu machen, weil das möchte man nicht selber bauen.
Das ist super nervig.
Und das übernimmt Docker Swarm Mode.
Das ist auch die einzige Funktionalität, die wir für Docker Swarm-Mode benutzen.
Man kann auch mit Docker-Swarm Mode daher auch der Name mehrere Server zusammenschalten, die dann quasi nach außen hin wie ein Docker-Host aussehen.
Das benutzen wir aber gar nicht, weil wir eben auch das Networking in Terraform modellieren wollen und eben nicht in Docker.
Und deswegen, ich glaube, das haben viele überhaupt nicht auf dem Radar.
Und das kann alles, was Kamal kann, nur eingebaut in Docker, ohne diese zusätzliche zusätzlichen Probleme, die ein weiteres Tool, was man Updaten, warten und so weiter muss, löst, weil mehr bietet Kamal am Ende nicht an.
Es gebietet keine Unterstützung bei allen weiteren Tätigkeiten, die man da machen möchte.
Und es ignoriert halt auch, weil es eben von Leuten kommt, die auf Bare Metal setzen, das gesamte Thema Infrastructure as Code.
Also, also wie setze ich die Server überhaupt auf, wie dürfen die miteinander kommunizieren?
Das ist null abgedeckt.
Das decken wir eben mit Terraform ab und Docker mit Swarm-Mode benutzen wir auf den Servern, um das Zero-Downtime-Deployment der Docker-Container sicherzustellen.
Was ja auch ein Kubernetes-Feature wäre, nicht?
Also Kubernetes kann natürlich nicht mehr so gut.
Genau.
Und also meine Behauptung wäre auch, dass wenn man eine Microservice-Architektur hat, mit signifikant vielen Microservices, dann sollte man vielleicht sich doch Kubernetes angucken, weil es eben einfach nochmal zusätzliche Features bietet.
Wir haben hier ein Monolithen.
Dasselbe würde aus meiner Sicht aber auch für eine Self-Contained Systems Architektur gelten.
Da würde auch Docker Swarm sehr gut funktionieren.
Wenn wir halt eben komplexe Interaktionen zwischen verschiedenen Sets von Containern haben oder Pots, wie sie halt bei Kubernetes heißen, dann lohnt sich vielleicht das Investment in Kubernetes.
Aber auch da wieder, das ist nicht die einzige Option.
Wir können eben auf einfachere Tools zurückgreifen, wenn wir eben nicht diese Ansprüche haben, die das Recht fertigen.
Und ich behaupte, dass Kubernetes oversized ist für eine Safe-Contained Systems oder eine monolithische Anwendung in den meisten Fällen.
Genau.
Also vielleicht Self-Contained Systems kurz, das ist halt die Idee, dass man halt das System aufteilte, mehrere eigenständige Webanwendungen mit jeweils einer UI und eher grob granular nicht, also die dann eine komplette Funktionalität, also im Sinne von Border-Kontext oder sowas umfassen.
Genau dazu direkt hat der Dominik Lemke gerade bei LinkedIn in Frage gestellt und die Frage, die gestattet ist, verwendet ihr Docker Swarm oder Docker Stack?
Also Docker Stack ist ein Kommando für den Docker Swarm.
Deswegen verstehe ich die Frage nicht zu 100 Prozent.
Also Docker-Stack macht quasi das Kommando, um die Container auf dem Server hochzufahren und dafür zu sorgen, dass die quasi eine Identität ist, bei der man updaten kann.
Wenn die Frage darauf sich bezieht, ob wir das Multi-Rechner-Ding von Docker-Swarm benutzen, dann ist die Antwort Nein.
Aber es ist trotzdem Docker Swarm.
Also wir schalten, also ich habe das Kommando vergessen, aber es ist irgendwie Docker Swarm Activate oder so ähnlich.
Damit aktiviert man den Swarm-Mode auf dem Host und dann hat man eben die Möglichkeit, das Docker-Stack-Kommando zu benutzen.
Vorher geht es nicht.
Sonst hätte man nur Docker Compose.
Und das bietet eben nicht die Möglichkeit, Zero-Downtime-Deployments von Containern zu machen.
Genau, selbige Person, also der Dominik hat auch geschrieben, habt ihr euch auch andere Oster außer Hetzler angeguckt, zum Beispiel Scaleway Stack It und QYEP.
Also Koyab habe ich jetzt noch nie von gehört, kann ich jetzt nicht so sagen, aber ja, wir haben uns auch andere Anbieter wie Scaleway und Stack It angeguckt.
Was also zum einen haben wir eben auch aus unserem Netzwerk nochmal nachgefragt, wer hat Erfahrung mit der Zuverlässigkeit verschiedener Anbieter, weil wir eben schon dafür sorgen wollen, dass es eben uns nicht mehr Stress und so weiter macht als notwendig.
Und Hetzner Cloud, alle Leute, mit denen wir gesprochen haben, haben halt gesagt, das ist sehr zuverlässig im Betrieb und man hat nicht irgendwelche Downtimes oder irgendwelche Services fallen aus.
Und das hat sich bisher auch zum größten Teil bestätigt.
Also wir hatten ein Problem mit dem Object Storage, wo der sehr langsam wurde.
Er ist nicht ausgefallen, aber er wurde sehr langsam.
Das Problem wurde adressiert und auch gelöst, aber das war der einzige Punkt, wo wir bisher Probleme hatten, weil wir eben bei anderen Anbietern durchaus negatives Feedback bekommen haben, wo das eben nicht so zuverlässig funktioniert.
Das war für uns ausschlaggebend, also ausschlaggebend uns für so ein Anbieter zu entscheiden.
Der andere Punkt war, dass wir denken, dass die, dass ein Anbieter, ein kleiner Anbieter, der jetzt schon irgendwie sehr, sehr viele Services anbietet, sich vielleicht übernimmt.
Also der jetzt irgendwie versucht, doch irgendwie 50 verschiedene Services zu betreiben.
Deswegen wollten wir lieber einen Anbieter, der das, was wir braucht, anbietet und das eben verlässlich macht, anstatt einem, der einfach quasi versucht, wild alles anzubieten und dann funktioniert das nur so halb und das nur so halb.
Das war für uns der wichtigere Auswahlfaktor.
Kosten sind tatsächlich von allem, also ich habe jetzt, also die Recherche ist jetzt ein paar Monate her, ich weiß die Zahlen nicht mehr, aber die waren alle sehr, sehr nah aneinander.
Also das sind gar nicht so die ausschlaggebenden Punkte bei diesen Anbietern.
Das ist halt eher mehr auch ein Vertrauens- und bisschen auch, was bietet ihr und was brauchen wir Frage, würde ich behaupten.
Genau.
Dann hatte der Josef Rossa auch bei LinkedIn die Frage gestellt.
Gibt es in diesem Simple Cloud-Umgebung Serverless-Möglichkeiten vergleichbar mit AWS Lambda oder ECS?
Also AWS Lambda ist ja Function as a Service, wo ich also dann eine Python-Funktion irgendwie hochladen kann oder Java oder irgendwas und ich zahle halt pro Ausführung.
Es gibt ein ziemlich großes freies Paket und ECS ist dieser, ist dasselbe für Docker-Container.
Genau, also ECS ist halt eher schon quasi ein fertig laufender Docker-Host.
Ja, ich, also korrigiere mich, aber ich meine, dass das halt Serverless abgerechnet wird in dem Sinne, dass ihr.
Ja, das stimmt.
Genau, und das ist ja die Definition von Serverless, dass ich eben sage, ich bezahle nicht den Server, sondern irgendwie pro Aufruf und da gibt es eben Functions as a Service.
Das wäre dann eben Container as a Service.
Und es gibt halt auch diese Dynamo DB im AWS-Universum, wo ich ja dann die Datenbank habe, die eben auch tatsächlich sozusagen pro Query irgendwie abgerechnet wird.
Genau, also Hetzner bietet das nicht.
Digital Ocean zum Beispiel bietet Functions as a Service an.
Das heißt also, das kann man wieder nicht allgemein beantworten.
Da müsst ihr schauen, die verschiedenen Anbieter haben verschiedene Angebote.
ECS haben wir beispielsweise bei Komoot verwendet für unsere Container, aber auch gar nicht so sehr, um jetzt irgendwie dieses super schnelle Hoch- und Runter skalieren zu machen, sondern eben um nicht selber einen Docker-Host zu betreiben.
Da muss ich aber sagen, das ist ein, das ist wirklich überhaupt kein Schmerzpunkt.
Irgendwie Docker auf einem Server zu installieren und das zu laufen zu lassen, ist wirklich nicht der Punkt, der einen irgendwie Nerven oder Zeit oder sonst was kostet.
Ich sehe da nicht den großen Vorteil.
Bei Functions as a Service, also diesem wirklich, ich schreibe eine Funktion, ich kümmere mich um gar nichts, außer dass ich diese Funktion geschrieben habe.
Das hat natürlich an manchen Stellen sein Wert, ist aber auch wieder ein großer Kostenfaktor.
Also die sind nachher teurer als man denkt.
Und deswegen habe ich auch viele Unternehmen gesehen, die davon weggewechselt sind, weil es ihnen zu teuer geworden ist.
Das einfach nur als Warnung.
Aber ja, wenn ihr diese Anforderungen habt, dann könnt ihr halt schauen, ob ihr beispielsweise auch wieder, also ein Grund für Functions as a Service ist ja auch, man möchte die Funktion auf der Edge ausführen, also auf den Endknoten, die näher am Kunden sind.
Dann ist das wieder eher eine Aufgabe für einen CDN-Anbieter als für euren Hosting-Anbieter.
Aber das ist auch wieder eine Frage, wofür wollt ihr Functions as a Service benutzen.
Genau.
Wir haben eine Episode gemacht vor längerer Zeit zum Thema Serverless-Architektur mit Sascha Möllering.
Und ich habe ehrlich gesagt nur im Hinterkopf, dass diese, also du hebst ja jetzt irgendwie auf Kosten ab und Scale to Zero und solche Sachen.
Und ich bin mir nicht sicher, ob das sozusagen der Punkt ist.
Also ich glaube, das war halt komplizierter, könnte man sich da angucken.
Genau.
Wie unterstützt du da, also bist du da, stehst du da zur Verfügung für Fragen oder genau, also wenn euch das Thema interessiert, also wie gesagt, ich habe jetzt ja auch viel beschrieben aus dem Kontext, in dem ich das jetzt zunächst gemacht habe.
Jedes Unternehmen hat andere Anforderungen.
Das heißt, man muss das halt einfach sich darüber unterhalten, was genau, wo genau isst man, wo genau möchte man hin.
Dann sprecht mich gern an.
Ich glaube, Eberhard kann gleich nochmal einen Link posten, wo man mit mir Kontakt aufnehmen kann, um einfach erstmal so einen Kaffee trinken, wie das Eberhard immer nennt, einfach mal Online-Chat einmal mal drüber sprechen, was wollt ihr genau tun?
Was, wie kann ich euch dabei helfen?
Welche Fragen kann ich euch vielleicht vorher schon beantworten?
Dann nehmt gerne Kontakt auf.
Genau, ich habe das halt gerade reingepackt in den Chat bei YouTube und bei Twitch.
Das ist halt Swaglab.rog slash Schreiberskiller Binde-xet.
Da war noch der Hinweis, dass du zu leise bist.
Sorry, sozusagen dazu, aber wir sind jetzt irgendwie ziemlich weit am Ende.
Und hier ist noch eine Frage.
Falls man Ressourcen übrig hat, gibt es auch sowas wie Fission oder Key da beides Open Source, um Sachen innerhalb des Clusters zu betreiben.
Genau, das ist, also stimme ich zu, Marcel.
Man könnte, wenn man das braucht, dann kann man sich das auch anschauen.
Also dass man quasi selbst den Host für die Functions as a Service aufsetzt.
Ja.
Okay, das sind die Möglichkeiten da.
Okay.
Genau, das gibt ja auch irgendwie auf Kubernetes, gibt es halt kein Native, dann ist das, gehört das sozusagen in den Universum.
Alles klar.
Ich finde das halt ehrlich gesagt immer ein bisschen, wie soll ich sagen, schwierig, weil dieser Scale to Zero und eben tatsächlich Abrechnung pro Einheit kann ich ja nur dann in reinkultur machen, wenn ich sozusagen diesen Hyperscaler habe und nur da habe ich irgendwie null, nicht?
Also null Euro, wenn halt gar nichts passiert.
Wenn ich das halt selber huste, ist es ja inhärent so, dass ich eben die Hosting-Kosten im Entsprint habe.
Haben wir noch irgendwas vergessen, irgendwelche weiteren Themen?
Ich glaube, wir haben alle wichtigen Dinge, die ich auf jeden Fall erwähnen wollte, besprochen.
Super.
Dann wir sind auch sozusagen am Ende der Timebox.
Dann würde ich sagen, vielen Dank für die Aufmerksamkeit.
Vielen Dank, dass du da warst, Lukas.
Und wie gesagt, Lukas steht halt sehr gerne zur Verfügung, wenn es halt irgendwie Themen gibt und wenn ihr euch da selber halt drum kümmern wollt.
Und ich glaube, der Bezug zur Software-Architektur ist ja auch sehr schön deutlich geworden.
Nächste Woche wird es eine Episode geben.
Es ist noch nicht ganz klar, zu welchem Thema, aber es wird halt Freitag irgendwas passieren.
Und nicht auf den üblichen Kanälen, in diesem Internet werden wir das, glaube ich, eher rechtzeitig dann bekannt geben.
Dann würde ich sagen, vielen Dank, schönes Wochenende.
Und vielleicht bis nächste Woche oder an einem anderen.
Bis dahin.
Tschüss.