Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream, dieses Mal mit Lucas zum Thema Hyperscaler-Exit.
Lucas, möchtest du kurz zwei Worte über dich sagen?
Ja, gerne.
Hallo Eberhard.
Wir sind Kollegen bei SWAGLab.
Ich bin Principal Consultant bei SWAGLab und beschäftige mich eigentlich schon sehr, sehr lange mit Web-Anwendungen 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, dem aktuellen Projekt von mir.
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 daneben auch zu diesem Thema mit einer kritischen Betrachtung zum Thema LLMs.
Ich war jetzt versucht zu fragen, warum eigentlich Hyperscaler-Exit?
Ich glaube, wir sollten erst mal den Begriff klären, weil du sagst ja Hyperscaler-Exit und wir hatten ja darüber diskutiert.
Deswegen weiß ich, dass du Wert darauf legst, dass es eben nicht ein Cloud-Exit ist.
Magst du kurz was dazu sagen?
Ja, also ich gehe mal einen Schritt auf das konkrete Beispiel, über das wir heute reden auch ein.
Also das Projekt, an dem ich arbeite aktuell, ist Fejo.
Das ist eine Plattform, man Ferienhäuser in Dänemark buchen kann, einer führenden Anbieter in dem Bereich.
Und die hatten jahrelang 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 FIOD 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 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 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 FIOD einfach die Hauptmotivation gewesen.
Die andere Motivation, die auch bei manchen da ist, ist einfach, wenn man hauptsächlich jetzt AWS, Azure und Google Cloud-Plattformen 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 FIOD dann, obwohl es 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 Diskussionen darum, 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 einen 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 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 Faryo gewechselt sind, bieten eben auch noch weitere Services an.
Dazu gehört dann halt sowas wie ein Load Balancer oder einen 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 Faryo, besteht zwischen AWS, also AWS, Azure, Google Cloud Platform 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 noch mal darauf 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 ja, glaube ich, irgendwie allen bekannt.
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 internationale Strafgerichtshof 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, hier auf amerikanische Infrastruktur zu sitzen.
Und, ach so, genau, desweiter, hattest du gesagt, sind halt die Kosten.
Kannst du das beziffern, wie viel weniger das ist?
Genau, also in dem konkreten Fall von FAIO ist es so, dass wir durch den Umstieg 80 Prozent der Infrastruktur Kosten 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 eben darüber vorher abgesprochen, weil ich eigentlich immer der Meinung bin, dass wir optimieren sollten, auf SoftwareentwicklerInnen.
Ich weiß, SoftwareentwicklerInnen wahnsinnig teuer sind.
Ich muss gestehen, dass das ein Hinweis darauf ist, dass das eben tatsächlich ein valides Optimierungsziel ist, einfach aus 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 noch mal gelernt habe oder für mich noch mal klar geworden ist, wenn man sich 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 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 den Kundinnen weitergeben, sondern eben dort dann entsprechend auf Marge haben.
Gut, das ist jetzt 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 noch mal 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 Platform 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, 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 darüber reden, 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.
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, 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 für ein Startup, was noch gar nicht so genau weiß, was das Business-Modell ist.
Dann möchte man das mal kurz ausprobieren und dann merkt man, drei Monate später brauchen wir doch nicht mehr.
Da kann man es halt wegklicken.
Dafür ist das praktisch, aber als etabliertes Business hast du so ein 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, virtuelles 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 eine 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, MariaDB, 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, dass es eben eine 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, welches Server du hast und wie die miteinander reden können und wie die gesized sind und so weiter in Code.
Da gibt es so den Marktführer Terraform als Tool oder den Forkter von OpenTofu.
Das sind so die zwei üblichen Tools.
Und das erlaubt uns eben, ein Environment aufzusetzen.
Sagen wir jetzt mal das Produktions-Environment und dann ohne Mühe ein Staging-Environment daneben zu setzen, was genauso funktioniert, aber vielleicht ein bisschen kleineres Sizing hat.
Also bei Falio 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 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 Click-Ops, wie man das manchmal nennt, durchklicken und hinzufügen.
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, die Schnellheit, was auf die Reihe zu bekommen ist, vielleicht wirklich etwas, was für Startups gerade relevant ist.
Da muss man sich die Frage stellen, ob es später tatsächlich immer noch relevant ist.
Das ist ja auch ein bisschen deine Story, nicht?
Also ich frage mich, was ist mein Unternehmen, was schon länger am Markt ist?
Und das wäre jetzt überraschend, wenn die 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 Virtualisierungsangebot verdient hat.
Seien die Bare-Metal-Leute ernsthaft, dass man halt auf Bare-Metal ohne Virtualisierung arbeiten will?
Also Infrastructure as Service oder Infrastructure as Code hört sich für mich so logisch und sinnvoll an, dass ich mir nicht vorstellen kann, dass halt jemand sagt, nee, das wollen wir halt irgendwie nicht.
Und dann 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 einen Talk, mich gezwungen, den Talk zu schauen, dass der, dass es 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 Next-Cloud und das ist ja eine ganz andere Art von Cloud.
Das heißt, das kommt ja noch dazu bei der Verwirrung.
Aber ich sehe keine ernsthaften Argumente, warum man Bare-Metal machen sollte.
Okay, aber es ist dann tatsächlich Bare-Metal gemeint ohne Virtualisierung und alles.
Okay, also ich kann das nochmal wiederholen.
Mir war nicht klar, dass das das ist, was man hat, was ernsthaft hat.
Aber wichtiger Punkt dazu noch, Eberhard, ist die, also selbst wenn man jetzt sagen würde, man nimmt einen 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-as-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 ein Rückgriff auf die Diskussion, das war auch etwas, was wir, glaube ich, gestern diskutiert hatten.
Diese Login-Geschichten beginnen uns ja auch bei Mainframes, nicht?
Und bei Mainframes ist es eben tatsächlich so, dass wir jetzt, also ich meine ganze Karriere schon, Mainframe-Migration.
Ich gehe auch davon aus, dass ich mit dem Thema in Rente gehen werde.
Und ein wichtiger Motivator ist dafür Login, nicht?
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 wir die Leute gerne vom Mainframe weggehen 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 also leistungsfähig und gut, aber nicht das Problem.
Ja, definitiv.
Gut, jetzt wäre die nächste Frage, du hast es gerade eben angesprochen, ich glaube, das ist ja auch so ein bisschen so eine Software-Architektur-Frage.
Also würde jetzt bedeuten, dass ich eben nicht meinen 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 geben sollten.
So, dass also im Betrieb nicht nur das Problem ist, dass das Ding verfügbar sein soll, sondern dann 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 das ist ja eine echte Aufgabe 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 Digital Ocean 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.
Datenbank-Administratoren, 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 Hetzner 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, Entwicklerinnenzeit 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 Entwicklerinzeit, sondern Ops-Zeit nehme ich an, oder?
Genau, genau.
Also das ist auch noch ein wichtiger Punkt.
Also das FAIO, das Team, in dem ich arbeite, wir sind zu 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 Developments, 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 auf dieser Unternehmensgröße, sage ich jetzt mal.
Aber ja, genau.
Ich meine Operationszeit 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.
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, 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, einer der Gründe dafür ist, dass es eben ein kleines Set von Technologien ist, über das wir reden.
Wir reden eben nicht darüber, dass es irgendwie zehn verschiedene Technologien gibt.
In allem 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 ein 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 Bereich Experte oder Expertin zu sein.
Und deswegen ist der Ansatz bei Fajo, sich auf wenige Technologien zu beschränken.
Also in dem Fall ist es die Anwendung, ist eine Ruby on Rails Anwendung, es ist serverseitiges 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 einen 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 zehn Personen sind und wir wollen halt auch ein bisschen dafür sorgen, dass nicht eine Person on Call ist, 24 sieben quasi, weil alle anderen gar nicht verstehen, wie diese Infrastruktur funktioniert, dann müssen wir dafür sorgen, dass das verstehbar, also einfach zu verstehen ist, einfach man sich einarbeiten kann.
Was im Umkehrschluss 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 so etwas wie Team Topology, sondern ein Plattform-Team haben, der das dann irgendwie dafür sorgt, dass das ja im Postgress irgendwie betrieben werden kann.
Richtig, also 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-Anbieter sowieso schon nicht mehr da.
Aber dann ist es auf jeden Fall auch eine Überlegung wert, passt jetzt Kubernetes vielleicht besser zu diesem Unternehmen als den Docker-Spawn-Mode, den wir gewählt haben.
Genau, der Robert Wiesner schrieb gerade Ruby on Rails mit diesem Smiley mit dem Herzen in den Augen.
Bevor wir dahin kommen, ich weiß nicht, wollen wir kurz über diese Geschichte mit der Job-Queue sprechen?
Können wir gerne.
Also wollen wir erstmal noch kurz das Datenbank-Thema einmal.
Ich dachte, das sei noch das Datenbank-Thema, aber ja.
Okay, aber fair ist es.
Ich will einfach nur noch mal darauf hinweisen, weil ich glaube, viele Leute haben das quasi vergessen, weil es so selbstverständlich geworden ist, dass eine Datenbank was ist, wo man drauf klickt und dann ist die halt da.
Aber wir müssen halt, wenn wir das selber machen, bedeutet das, wir müssen 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 einen 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 ein wichtiger Teil der Strategie.
Und genauso die Konfiguration, also ich rede jetzt speziell über Postgres, bei MariaDB 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 als Beispiel für einen Aspekt, den man übersieht, wenn man das einfach als Service einkauft.
Und das auch eben diese Komplexität, die da dran hängt.
Und dann kann es noch mal ein Schritt noch komplizierter werden, wenn man eben nochmal ein Hot-Standby in Anführungsstrichen haben möchte, also die Möglichkeit mit möglichst wenig Downtime auf einen Ersatz-Server 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 einen 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, 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 inklusive Backup vollständig zu machen, waren ungefähr drei Wochen Arbeit, das vollständig fertig zu machen.
Also inklusive Tests und dem ganzen Zeug, genau.
Der Anatoli Litschi hat bei LinkedIn gefragt, ist die Autoskalierung in dem Projekt ein Thema?
Nehme ich mal nicht an.
Also da gibt es ja in AWS, wie wahrscheinlich bekannt, diesen Elastic Load Balancer und dann gibt es halt die Möglichkeit, mehr virtuelle Maschinen hochzufahren und das Kostenmodell von AWS ist ja auch so, dass man dann eben Maschinen 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 Load Balancer 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 FAIO 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 System von sich aus macht und da haben wir einfach die Anforderungen 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 superschnelle Reagieren, dass ohne dass jemand was tut, das automatisch passiert, ob das wirklich eine Anforderung ist.
War jetzt in dem Fall keine Anforderung.
Tatsächlich ist es sehr so.
Ich habe irgendwann jemanden gesehen, der tatsächlich auf einem Kurzblocking-Dienst, hatte ich das damals geschrieben und das hat auf eine frühe gebannt von wegen nicht Skalierung ist die Nummer eins Anforderung, die man eigentlich nicht hat.
Nur Interesse halber und die Granularität, in der ich jetzt abrechne, ist die auch stundenweise oder trageweise?
Das wollte ich auch gerade sagen.
Danke für die Frage.
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 einen Monat ist günstiger, als wenn man jetzt quasi einen Monat in Stunden bezahlen würde.
Aber grundsätzlich geht das.
Das heißt, wenn man jetzt wirklich einen Peak hat, sagen wir jetzt mal, wir machen eine große Aktion.
Also keine Ahnung, 20 Prozent 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 du hast 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 das Monitoring feststeht, dass alle Webserver ausgelastet sind, dann fahre ich halt einfach noch einen hoch.
Das könnte man einfach bauen.
Das könnte man bauen.
Aber der Unterschied ist, dass du das eben bei AWS über diese Scaling Groups quasi 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 hoch zu skalieren.
Aber Ziel ist ja eben so einfach wie möglich.
Wenn das eine Anforderung ist, kann man das erfüllen.
Aber es 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.
Also Architekturentscheidung nicht?
Also ich mache halt nichts, wenn ich halt nicht die Anforderung habe, dass das halt irgendwie automatisch skaliert.
Gut.
Wollen wir jetzt über Job Queues sprechen?
Ja, gerne.
Ja, also eine der Dinge, die wir diskutiert hatten, war eben, also bevor wir den Umzug gemacht haben, hat FIOS so gemacht, dass, wie das in Ruby on Rails sehr üblich ist, Redis als das Backend für die Job Queues zu benutzen.
Genauso wie als Backend für den Cache.
Also hier nochmal kurz, also Cache in dem Fall bedeutet Inhalte, die die Anwendung dahinlegt und schnell abrufen kann.
Und nicht so was wie ein Varnish, der vor der Anwendung steht.
Also es gibt ja zwei verschiedene Arten von Cache.
Und da hatten wir halt diskutiert, brauchen wir dann ein Redis?
Also sollten wir auch ein Redis aufsetzen oder ein Valky?
Wie auch immer.
Also eine von den Redis Datenbanken.
Und haben dann entschieden, wir probieren jetzt mal aus, dass was mit mit Rails 8 gekommen ist.
Quasi diesen neuen Default, den neuen Default Queue 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 FIOS ein wirklich hohes Maß an Background Job hat.
Weil FIOS 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 und Sachen nicht so cool wie die Lösung, die wir davor hatten.
Aber das hat wirklich gar nichts mit der Simple Cloud zu tun.
Das ist wirklich jetzt Rails spezifisch.
Aber sonst funktioniert das wirklich super.
Und der Grund, warum das so ist, ist, dass es gab früher auch in der Rails Community viele Diskussionen darüber, nutzen 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.
Da gibt es so ein paar Tricks, kann ich gerne auch noch mal einen Link für die Shownotes dazu geben, um extrem effizient mit PubSub in Postgres zu arbeiten, 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 das heißt nicht S3, 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 Wiederpunkt und nicht, so fällt es hier im Stream, dass man im Prinzip jetzt sagt, es ist eine Architekturentschreibung, die dazu geführt hat, dass man sagt, wir machen Job Queues 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 er dann erst migriert, logischerweise, weil nicht, also Redis auf der neuen Infrastruktur zu betreiben will man ja nicht.
Das ist gerade der Punkt.
Ja, genau.
Und das ist halt auch wirklich eine unserer Leitprinzipien jetzt bei diesem Umzug gewesen.
Wir haben quasi die gesamte AWS-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 Job Queue 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 gerne auf die, auf das Thema Kosten an der Stelle eingehen, weil das ist nämlich auch ein wichtiger Faktor.
Einer 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 sind übermäßig teuer.
Also wirklich übermäßig teuer.
Das heißt also, nehmen wir es mal als Beispiel, wir benutzen Cloudfront, also das das CDN, was AWS anbietet.
Im Vergleich zu Cloudflare, also jetzt auch einem, ich würde ihn auch als Hyperscaler bezeichnen, dann sind die Kosten zwischen Cloudfront und meinem und meiner Anwendung kostenlos.
Und die Kosten zwischen Cloudflare 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 erst mal zwei, drei Services raus, macht die erst mal auf der neuen Plattform.
Aber wenn dann zwischen diesen Services und meinen Services, die noch auf AWS sind, sehr viel Traffic sind, kann das sehr, sehr teuer werden, weil eben die Egresskosten so hoch sind.
Und das war einer der Gründe, warum wir eben diesen Weg gewählt haben.
Also auf einen Schlag möglichst umzustellen und dann eben so die Änderung erst mal in AWS zu machen.
Also bedeutet da tatsächlich, dass an dem einen Tag das Ding noch auf AWS lief und am nächsten Tag dann auf Hetzner, habe ich das richtig verstanden?
Und auch vollständig?
Ja, genau.
Das ist ja eigentlich nur das Risiko, 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 gemerkt hätten, okay bei Hetzner funktioniert nicht, wir müssen zurück, dann hätten wir quasi erst mal 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 eine Downtime gehabt.
Wir haben also eine Statusseite aufgeschaltet.
Aktuell haben wir ja 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 getimed, 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 ein 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 keinen Traffic, manche haben nachts keinen Traffic.
Da muss man 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 dir gestehen, auf meiner Abstraktionsebene ist das halt wieder eine Architekturentscheidung.
Im Prinzip sagst du halt, die Kosten sind wichtig, also die Kosten rechtfertigen nicht, diese halbe Stunde Downtime einzusparen.
Und das Risiko ist irgendwie sozusagen beherrschbar und da machen wir es halt irgendwie so.
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.
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 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.
Ich muss halt gestehen, ich muss die ganze Zeit in dieses LinkedIn-Post von Gernot sehen, was die denken, was ich halt im Vorbeigehen gesehen habe, wo er sich darüber aufgeregt hat, dass irgendeine Bank, seine Bank hat irgendwie übers Wochenende gesagt hat, hier geht da gar nichts.
Und von daher, also eine halbe Stunde hört sich jetzt nicht wie ein Drama an für mich.
Genau.
Und deswegen schaut euch das an und klä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 glaube ich kurz, ich verlinke das auch nochmal, ich glaube im Vorhinein diese Frage, aber also ich paraphrasiere, da gibt es 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, da war halt die Aussage des Heilbefehlers halt irgendwie in sich zusammen.
Dann habe ich halt ein massives Problem.
Was sagst du dazu?
Da würde ich zu sagen, dass ich glaube, das ist irgendwie so ein Fediverse-Ding, glaube ich.
Das hat sich so ein bisschen zu einem Meme entwickelt.
Ich glaube auch, dass das Fediverse wirklich sehr stark irgendwie auf Hetzner läuft, aber das ist eben keine Betrachtung, die sich deckt mit dem Rest der Welt.
Also Hetzner 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 mal 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.
Ich stimme nicht zu, aber ich glaube, man muss schon uns auch noch mal 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 in einen Schrank reinschrauben und einfach selber machen.
Wir wollen halt eine gewisse Agilität, eine 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 Austauschpreis nicht, das ist ja, glaube ich, der Punkt.
Das heißt, das Zeug, was ihr jetzt habt, könntet ihr, oder korrigiere mich, aber könntet ihr morgen irgendwo anders betreiben?
Genau, das war ja das, was ich am Anfang sagte.
Und das ist mir schon wichtig.
Und nur noch mal, weil das, glaube ich, auch vielen 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 die Umsatzzahlen veröffentlicht, und da stand, IONOS hat eineinhalb Milliarden Umsatz, Hetzner hat 360 Millionen, DigitalOcean 700 Millionen.
Also Telekom Cloud ist ja wahrscheinlich auch irgendwie groß.
Das ist, glaube ich, der Punkt dazu.
Da ist eine Frage von der Masse Crema in LinkedIn.
Die hat geschrieben, wie habt ihr das Thema Sicherheit gelöst?
Hetzner bietet, soweit ich weiß, keine Waffe, also Application Firewall, Intuition Detection und so weiter.
Und die meisten Mittelständler haben keinen Sock, das am Wochenende etc. bereitsteht.
Genau, also Hetzner Cloud bietet DDoS Protection, aber keine Waffe.
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 belö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 zu bieten ist, ist eben diese weltweite Entdeckung von Bot-Angriffen, weil die einfach durch ihren Scale-Wissen den globalen Traffic im Prinzip kennen.
Das kriegst du halt nicht repliziert.
Aber die WAF-Protection von denen ist jetzt auch nicht so super sophisticated.
Intuition-Detection hast du jetzt ausgeklammert, also hast du nichts dazu gesagt?
Genau, also grundsätzlich, ich 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, heißt nicht so, aber das ist das Handy, was er oder sie sich gegeben hat.
Und da war die Frage, ich würde gerne eure Einschätzung hören, wie kleine Roster wohl in Sachen weltweite POPs, also Points of Presence, für regionales Hosting, zum Beispiel für Latenzbedingungen darstellen.
Anscheinend hat zumindest Hetzner wohl schon viel zu einem Angebot EU Central, US East, US West und AAP, also Asia Pacific, South East.
Und da geht es halt darum, dass man eine globale Verteilung haben möchte.
Die hat dazu geführt, dass eben der Rechner zumindest mal auf dem selben Kontinent steht, mit dem man zu tun hat, damit die Latenzen nicht explodieren.
Genau, also da würde ich erstmal noch mal einen Schritt zurückgehen und fragen, was genau möchte man eigentlich mit den Points of Presence erreichen?
Weil ich habe ja bis letzten Sommer das Webteam von Komoot geleitet, das ja eine weltweit operierende Anwendung ist mit sehr vielen Usern.
Und da haben wir auch die Entscheidung getroffen, dass das Backend läuft in einer Region von AWS und der Rest ist über einen 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-Datacenter, die europäischen in Europa und die australischen in 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.
Deswegen weiß ich nicht, ob man von seinem Hoster 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.
Also ich muss hier gestehen, es ist auch wieder so eine Geschichte mit der Architekturentscheidung.
Im Prinzip ist ja die Anforderung eine bestimmte Lizenzzeit.
Und was du ja im Prinzip sagst, ist, die Lizenzzeit kann man möglicherweise erreichen mit einem CDN und einem Backend, was an einer Stelle ist.
Und ich muss gerade an ein Projekt denken, wo das eigentlich für mich auch der Hinweis gewesen wäre, wo 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 ausreichen und 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 fehlten da empirische Hinweise.
Der Dominik.
Eben, da darf ich dich kurz unterbrechen.
Ich glaube, wir sollten einmal noch kurz auf die Frage von Jens Eickmeyer eingehen, der die eben vorhin eingestellt 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 alternativen Ansatz oder ob wir das 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…
Was ist denn das ü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 es ist 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 ein 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.
Das ist einfach dabei.
Und die wird auch weiter maintainen 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 Swarm-Mode kann ich sagen, hier nimm bitte diesen Container und fahr den hoch.
Wenn der Health-Check von diesem Container grün ist, dann lenkt der Traffic auf den neuen Container um und schaltet 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 von 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 Karmal kann, nur eingebaut in Docker, ohne diese zusätzlichen Probleme, die ein weiteres Tool, was man updaten, warten und so weiter muss, löst.
Weil mehr bietet Karmal am Ende nicht an.
Es bietet 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 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 ja das selber.
Genau.
Und also meine Behauptung wäre auch, dass wenn man eine Microservices-Architektur hat, also signifikant viele Microservices, dann sollte man vielleicht sich doch Kubernetes angucken, weil es eben einfach nochmal zusätzliche Features bietet.
Wir haben hier einen Monolithen.
Dasselbe würde aus meiner Sicht aber auch für eine Self-Contained-Systems-Architektur gelten.
Da würde auch Dockers Swarm sehr gut funktionieren.
Wenn wir halt eben komplexe Interaktionen zwischen verschiedenen Sets von Containern haben oder Pods, 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 rechtfertigen.
Und ich behaupte, dass Kubernetes oversized ist für eine Self-Contained-Systems- oder eine monolithische Anwendung in den meisten Fällen.
Genau.
Also vielleicht Self-Contained-Systems, das ist halt die Idee, dass man das System oft in mehrere eigenständige Web-Anwendungen mit jeweils einer UI und eher grob-granular, also die dann eine komplette Funktionalität im Sinne von Border-Context oder sowas umfassen.
Genau dazu direkt hat der Dominik Lemke gerade bei LinkedIn eine Frage gestellt.
Und die Frage, die er gestellt hat, ist, verwendet ihr Dockers Swarm oder Dockers Stack?
Also Dockers Stack ist ein Kommando für den Dockers Swarm.
Deswegen verstehe ich die Frage nicht zu 100 Prozent.
Also Dockers Stack ist 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 Dockers Swarm benutzen, dann ist die Antwort nein.
Aber es ist trotzdem Dockers Swarm.
Ich habe das Kommando vergessen, aber es ist irgendwie Dockers Swarm activate oder so ähnlich.
Damit aktiviert man den Swarm-Mode auf dem Host und dann hat man eben die Möglichkeit, das Dockers 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 Roster aus der Hetzner angeguckt?
Zum Beispiel Scaleway, Stack-It und QJEP?
Also QJEP habe ich jetzt noch nie von gehört.
Da kann ich jetzt nichts zu sagen.
Aber ja, wir haben uns auch andere Anbieter wie Scaleway und Stack-It angeguckt.
Zum einen haben wir eben auch aus unserem Netzwerk nochmal nachgefragt, wer hat Erfahrungen mit der Zuverlässigkeit verschiedener Anbieter, weil wir eben schon dafür sorgen wollen, dass es eben uns nicht mehr Stress und so weitermacht als notwendig.
Und Hetzner Cloud, alle Leute, mit denen wir gesprochen haben, haben halt gesagt, es 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, uns für so einen Anbieter zu entscheiden.
Der andere Punkt war, dass wir denken, dass 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, 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 ein 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 im Vergleich mit AWS Lambda oder ECS?
Also AWS Lambda ist ja Function as a Service, wo ich also dann eine Preisenfunktion irgendwie hochladen kann oder Java oder irgendwas und ich zahle halt pro Ausführung und es gibt ein ziemlich großes Freispaket und ECS ist dasselbe für Docker Container.
Genau.
Also ECS ist halt eher schon quasi ein fertig laufender Docker Host.
Also korrigiere mich, aber ich meine, dass das halt Serverless abgerechnet wird in dem Sinne, dass das stimmt.
Genau und das ist ja die Definition von Serverless, dass ich eben sage, ich bezahle nicht den Server, sondern eben pro Aufruf und da gibt es eben Function as a Service.
Das wäre dann eben Container as a Service und es gibt halt auch diese DynamoDB im AWS-Universum, wo ich dann die Datenbank habe, die eben auch tatsächlich sozusagen pro Query irgendwie abgerechnet wird.
Genau, also Hetzner bietet das nicht.
DigitalOcean 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 superschnelle Hoch- und Runterskalieren zu machen, sondern eben, um nicht selber einen Docker-Host zu betreiben.
Da muss ich aber sagen, 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 seinen Wert, ist aber auch wieder ein großer Kostenfaktor.
Also die sind nachher teurer, als man denkt.
Deswegen habe ich auch viele Unternehmen gesehen, die davon weggewechselt sind, weil es ihnen zu teuer geworden ist.
Das einfach nur als Warnung, aber 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 den 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 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 halt angucken.
Genau.
Wie unterstützt du da, also bist du da, stehst du da zur Verfügung für Fragen?
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 zuletzt gemacht habe.
Jedes Unternehmen hat andere Anforderungen.
Das heißt, man muss sich darüber unterhalten, wo genau ist man, wo genau möchte man hin.
Dann spreche mich gerne 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 darüber sprechen, was wollt ihr genau tun, 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 SwagDev.Rox der Schreiber aus Gela-Binde-Strich-Exit.
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 KEDA bei Open Source, um Sachen innerhalb des Clusters zu betreiben?
Genau, das stimme ich zu, Marcel.
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.
Okay, das sind die Möglichkeiten da.
Genau, das gibt es ja auch auf Kubernetes.
Es gibt halt Knative, dann gehört das sozusagen in diese Kategorie.
Alles klar.
Ich finde das halt ehrlich gesagt immer ein bisschen, sozusagen schwierig, weil diese Scale-to-Zero und eben tatsächlich Abrechnung pro Einheit kann ich ja nur dann in Reihenkultur machen, wenn ich sozusagen diesen Hyperscale habe.
Und nur da habe ich irgendwie null, also null Euro, wenn halt gar nichts passiert.
Wenn ich das halt selber hoste, ist es ja inherent so, dass ich eben die hosten Kosten dementsprechend 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, Lucas.
Und wie gesagt, Lucas steht halt sehr gerne zur Verfügung, wenn es halt irgendwie Themen gibt und wenn ihr euch da selber halt darum kümmern wollt.
Und ich glaube, der Bezug zu das hoffentliche Direktor 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 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.