Deep Dive 190 –

Cloud-Exit mit Andreas Lehr

02.09.2025

// Podcast
// Deep Dive 190

Shownotes

Cloud-Exit ist aktuell in aller Munde – spätestens seit Firmen wie Basecamp den Wechsel von der Cloud zurück zur eigenen Infrastruktur angekündigt haben.

Dennis und Jan sprechen in dieser Folge mit Andreas Lehr und erkunden, was sich hinter dem Hype verbirgt. Andreas berät Firmen zu Cloud und DevOps-Themen und hostet den Podcast „Happy Bootstrapping“ sowie den Newsletter „Alles nur gecloud“.

Gemeinsam diskutieren sie, welche Argumente es neben den häufig angeführten hohen Kosten für einen Cloud-Exit gibt – darunter Vendor-Lock-ins, Souveränität, Datenschutz, Performance und Kostenstrukturen. Andreas berichtet dabei von konkreten Fällen, die er selbst begleitet oder dokumentiert hat.

Auch wenn alle drei überzeugt sind, dass Cloud-Exits nicht pauschal die Lösung sind und Hyperscaler nach wie vor ihre Daseinsberechtigung haben, stellen sie sich die Frage: Wo beginnt ein Cloud-Exit und wie nah muss man den eigenen Servern kommen, damit sich der Aufwand lohnt und Abhängigkeiten reduziert werden?

Download

/transkript/programmierbar/deep-dive-190-cloud-exit-mit-andreas-lehr

Jan: Hallo und herzlich willkommen zu 1 neuen DeepDive Folge hier in der programmier.bar. Heute endlich mal wieder mit 'nem Thema, wo ich von Anfang an sagen kann, wie der Titel heißt, weil das ein sehr konkretes Thema ist, über das wir sprechen. Wir sprechen heute über Cloud Exit und dazu ist nicht nur der Jan hier alleine im Studio, sondern ich hab natürlich wie immer den Dennis mit am Start. Hallo, Du.
Dennis: Moin moin. Hallo.
Jan: Diesmal nicht in der mittleren Ecke. Ich weiß nicht, was Du in Riverside gemacht hast, diesmal ist es ganz oben bei mir. Alles ist anders Weil
Dennis: diesmal vielleicht nicht direkt ein Ich war nicht der Erste, der in dem Riverside Call war. Vielleicht ist das das
Jan: Geheimnis. Ist die magic, ja. Und wir haben hier heute noch den Andreas Lehrzugast. Hallo Andreas.
Andreas: Einen wunderschönen guten Morgen.
Jan: Der Andreas macht neben unserem Podcast auch einen eigenen Podcast. Er kümmert sich außerdem son bisschen Cloud und Obst Beratung und er betreibt die Webseite Alles nur geklaut, die ich allein für den Namen Hart Fire, so, ja? Ich hab gestern hier in in Vorbereitung meine meine Shownotes son bisschen zusammen geschrieben und hatte dann, ja, mir die Webseite son bisschen angeguckt und hatte dann erst mal sone halbe Stunde lang die Prinzen auf Dauerschleife laufen in den Kopfhörern, mich son bisschen einzustimmen auf alles neu geklaut.
Andreas: Ja, das ist der Gag an dem Namen, der ist so vielschichtig, ne. Ich klau die News, es geht Cloud, es geht ja, kann man interpretieren, wie man will. Wunderbar. Wir wollen heute im Prinzip über den Ausstieg aus der aus der Cloud sprechen.
Jan: Das ist ja son Thema, was grade son bisschen in Mode gekommen ist vielleicht, ja. Und ich muss sagen, mir ist das das erste Mal über den Weg gelaufen, als das gehört hab in dem Kontext von Basecamp steigt irgendwie bei ABS aus. Das war, glaub ich, vor 2 Jahren oder so gab's da eine erste eine erste Ankündigung. Vorher muss ich sagen, hat man das zwar vielleicht immer mal so im Rahmen von einzelnen Projekten gehört, aber so als richtiges Movement oder so hab ich das nicht wahrgenommen. Andreas, was ist da deine Einschätzung? Hat das damit angefangen oder gibt's das eigentlich schon länger und ich hab's nur ignoriert?
Andreas: Das gibt's eigentlich schon immer. Also würd ich jetzt sagen, vor allem so, wie Spacecamp gemacht hat, aber den Begriff haben Sie sicherlich schon mit geprägt, wollt ich sagen. Also Cloud Exit, das deutlich populärer noch mal geworden seit der David Heinemeyer Hansen das auf Twitter LinkedIn auf seinem Hey Blog rauf und runter gespielt hat, ne. Es geht ja mittlerweile so weit, es gibt eine Landingpage BaseCamp dot com Slash Cloud minus Exit, wo die alle News und Pressemeldungen dazu verlinkt haben. Aber das Thema an sich ist ja schon schon älter, ne. Du hast ja immer Man darf nicht den Fehler machen, einfach On Premise und Cloud gegeneinanderzustellen. Da gibt's noch ganz viele Dinge dazwischen. Ich muss auch gestehen, ich mag auch den Begriff Cloud Exit nicht so wirklich, weil im Prinzip ging's ja bei denen auch einen Hyperscaler Exit, ne. Die sind halt zu 'nem anderen Provider umgezogen, bei dem sie gewisse Layer in Zukunft selber machen und andere immer noch als Service einkaufen. Können wir dann bestimmt auch noch länger drüber sprechen. Und da gibt's eben verschiedene Stufen dazwischen noch, ne. Also Cloud Exit ist bei den Leuten immer im Kopf, na ja, dann machen die Leute wieder selber Festplattentausch und Server reinschieben. Aber genau das ist es halt nicht, sondern es gibt halt ganz viel Ebene dazwischen.
Jan: Das ist, glaub ich, 'n 'n superwichtiger Punkt, das einmal anzusprechen, dass es halt kein Schwarz und Weiß ist, sondern 'n fifty shades of Cloud irgendwie dazwischen sind. Und der andere Punkt, den's, glaub ich, heute auch nicht unbedingt gehen soll, ist ja, dass auch Cloud oder Hyperscaler, wie Du richtig sagst, ne, ja trotzdem eine Daseinsberechtigung haben, ne. Also es geht ja nicht darum, hier das irgendwie alles zu verteufeln und zu argumentieren, dass man das bitte nie machen sollte, sondern vielleicht eher darum zu diskutieren, was ist halt der Punkt, ab dem oder vor dem oder wie auch immer sich das vielleicht nicht mehr lohnt oder ne? Wie wie kann sich eine Firma 'n Projekt weiterentwickeln, das dann vielleicht neu evaluieren zu müssen zu 'nem gewissen Zeitpunkt?
Andreas: Ist richtig, ja. Also kannst Du kannst Du auf beliebigen Ebenen spielen und ich bin jetzt auch weit davon entfernt, Cloud zu verteufeln. Also grade bei alles nur geklaut versuch ich immer, beide Seiten zu beleuchten. Die Cloud Exit Thema, die funktionieren natürlich echt ganz gut. Aber jetzt, was so jetzt die letzten Wochen ja auch war, waren so diese, weiß nicht, habt ihr bestimmt mitverfolgt, die Cloud Kosten von Figma wurden ja durch deren IPO Feeling, also sie wollen ja an die Börse gehen, die wurden son bisschen geleakt und dann gab's erst mal son bisschen einen Aufschrei auf Hacker News und dann gab's auch eine diverse Einordnungen von den Kosten. Und dann hast Du son Geschäftsmodell, wie Figma es hat und sone Marge, dann ist dir vielleicht völlig wurst, dass Du 300000 Dollar am Tag an ABS bezahlst und 'n Fünfjahresvertrag abschließt, ne. Es hängt auch immer komplett am Geschäftsmodell, was man eben hat und an dem und dann macht Cloud Sinn oder halt nicht. Ist dann mittlerweile so ja, meine Aussage dazu. Muss man immer abwägen. Gibt kein Schwarz und Weiß, wie Du sagst.
Jan: Und vielleicht zur zur Einordnung, wo wir herkommen. Dennis, was würdest Du sagen, wenn ich jetzt pitchen würde, dass Lotum morgen die Cloud verlässt?
Dennis: Also ich Begeisterung sieht anders aus. Ja. Ja, ich glaube, also bei uns ist das große Ding, dass unser Markt ja schon sehr dynamisch ist. Und vielleicht würd Andreas gleich sagen, das ist auch in anderen Kontexten dann kein Thema und das ist dann vielleicht was, was wir lernen können. Aber zum einen, was die Zukunft Also eigentlich in beide Richtungen. Also ne, wir haben immer Risiken durch die Plattformen, auf denen wir unterwegs sind, dass sie sich auch unabhängig unserer Einflussnahme verändern in in den Userzahlen. Und das kann relativ extrem sein. Das kann nach oben relativ extrem gehen, das kann aber auch nach unten relativ extrem gehen. Das heißt, sowohl ein Commitment auf, ne, also auf auf auf große Volumen in die Zukunft ist schwierig, als auch irgendwie auf gesicherte, weiß ich nicht, Hardware oder ein gesichertes Level oder so was wir brauchen auf längere Zeit so, ne. Das alles, so gefühlt würd ich sagen, immer in 'nem, weiß ich nicht, 2, 3 Jahreshorizont oder so, wenn man sich den anguckt, dann ist es dann schon schwer. Wir hätten jetzt kein Problem für die nächsten 6 Monate, uns auf irgendwas zu committen oder so. Genau, aber halt diese Flexibilität fühlt sich im Moment halt einfach für uns noch wie 'n wie 'n guter Luxus an, dass man ihn, dass man ihn hat. Und wenn man das was Neues aufsetzt, sich jetzt keine Riesengedanken darum machen muss, sondern praktisch alle Tools und auch die Weiterentwicklung, die es auf diesen Plattformen irgendwie gibt, mitzunehmen. Aber ich muss auch gestehen, dass ich dass wir uns und ich mich auch noch nie irgendwie intensiv mit dem Thema auseinandergesetzt haben, von daher, dass inhaltlich sehr spannend wird die Folge, mal son bisschen zu gucken, okay, was bedeutet das denn überhaupt, ne? Also was was was verliert man, wenn man vielleicht bei meinem Hyperscaler weggeht? Was sind die Dinge, die man gewinnt und was sind die Use Cases, wo das irgendwo spannend ist?
Andreas: Ja, also für 6 Monate kriegst Du noch keinen, für 6 Monate Commitment kriegst Du noch keinen Rabatt. Wo sich's lohnt, das zu machen. Ja, dann musst Du halt 12 Monate machen, 24, 36 und da wird's dann schon schwierig, ne. Und dann musst Du immer schauen, dann musst Du die gleiche CPU Typen haben für die 3 Jahre, sodass Du auch wirklich den Discount bekommst. Also je nachdem, bei welchem Hyperscaler Du bist. Das nicht so einfach, das vernünftig zu machen, ne. Das Also es hat ja Basecamp auch, gab's ja auch ganz viel Gegenfeuer und die haben mir das alles komplett offengelegt und die Hosen runtergelassen. Und die hatten ja schon diese 3 Jahre Discounts und alles einberechnet, ne. Und trotzdem sind die Zahlen einfach so krass jetzt, wenn die das selber machen. Was natürlich aber auch beim Geschäftsmodell bei denen passt ne. Weil die haben eine SARS Applikation oder mehrere ne. Die haben halt neben Basecamp noch ihr E-Mail-Produkt und noch 'n paar andere Sachen. Und die wachsen, die sind Bootstab, die wachsen langsam, aber gesund, denk ich mal, zumindest sieht's von außen so aus. Und es reicht, 'n Rennstall oder das Le Man rennen vom DHH zu bezahlen, zumindest zu sponsern. Und das find ich schon interessant und bei denen macht's total Sinn, das so zu machen. Also das war mir auch klar, dass es funktioniert ehrlicherweise. Haben sie jetzt ja auch vor ihrem Plan geschafft. Aber ja, Du hast ja Spiele angesprochen oder generell euer Umfeld. Da fällt mir natürlich Roblox gleich ein, das ist ja auch son Player in dem Markt und die sind auch nicht in der Cloud zum Beispiel, ne. Die haben eigene Datacenter und und betreiben dort selbst ihre ja also ich hab nur ältere Zahlen damals, hatten die die 20000 Server, wo sie's selber betrieben haben mit dem, also. Und ich glaub, die hatten damals auch eine sechsstellige Anzahl an Container, die über die Flotte verteilt läuft. Und wenn Du in der Größenordnung bist, macht's dann schon wieder Sinn, das zu tun.
Dennis: Ja, nein. Ja, das das kann sein. Könnt ihr, weil ich hab den den Fall noch nicht so irgendwie groß mitbekommen, was war denn, also von welchen Kostenreduktionen haben Sie denn gesprochen oder in welchem Zeitraum wollte, sollte sich das irgendwie amortisieren und was sind son bisschen die Größenordnung in Prozenten oder anteilig oder so?
Jan: Also Bei Basewebsite, ja, ja, ja.
Dennis: Bei Basecampbörsen. Ja, Sie
Jan: reden so von zwischen 5 und 10000000 Dollar über die nächsten 10 Jahre, die Sie sparen. Das ist natürlich auch sone relativ abstrakte Zahl, weil man müsste das ja eigentlich son bisschen gegen den Revenue- und die Operating Kosten setzen, ne, weil es kommt ja immer son bisschen auch auf die Firmen drauf an, Aber
Dennis: ja. Aber Sie haben keinen, Sie haben keinen Vergleich in den tatsächlichen Kosten, also irgendwie, dass es jetzt 30 Prozent günstiger ist oder x Prozent günstiger ist?
Jan: Also also in dem Jahr, wo Sie angefangen haben, hatten Sie wohl 'n Cloud Budget von ungefähr 3000000. Im Jahr. Im Jahr, genau. Und jetzt realisieren Sie offensichtlich ein bis 2000000 Dollar Savings pro Jahr mit diesem Plan in den ersten paar Jahren. Also klingt das so nach, Sie halbieren halt Ihre Operating Kosten vielleicht. Mhm. Ja.
Andreas: 50 Prozent wären die Marge vom Hyperscaler. Also ich glaub, die Reduktion ist noch deutlich mehr gewesen jetzt am Ende.
Jan: Und also man muss halt natürlich auch sagen, Sie reden hier so von den 5 Jahren, ne, aber da sind ja auch Hardwareanschaffungen und bla bla bla alles drin. Also der da ist dein dein Profit, dein dein Gewinn, deine Einsparung kann ja hintenraus noch größer werden. Aber das ist halt auch, ja, da kommt wieder diese Ungewissheitsaspekt rein, den Dennis ja auch gesagt hat, das ist natürlich auch fürn Basecamp irgendwie schwierig, den Bedarf in 5 Jahren zu antizipieren oder so. Und deshalb ist wahrscheinlich das jetzt mal so der der Zeithorizont, auf den sie sich eingelassen haben. Aber bevor wir uns vielleicht bei diesen Kosten noch 'n bisschen im im Kreis drehen, würd ich vielleicht noch mal kurz das 'n bisschen größer machen und frag, ist es ist es der einzige Punkt, ja? Also Dennis hat eben schon so ganz kurz angerissen, ja, es gibt bestimmt auch son gewissen Wenderlog in, den man eingehen kann, will, der einen stört oder nicht, ja. Aber gibt es noch noch andere Gründe außer Geld und Wender, die einen vielleicht so aus der Wolke verjagen könnten?
Andreas: Da gibt's noch ganz viele Punkte bestimmt. Also Performance kannst Du bessere bekommen mittlerweile. Wenn Du jetzt anschaust, wie wie Hardware sich entwickelt hat, also wenn Du jetzt heut, Du mietest mal, schau dir bei Hetzner on dedicated Server an, also 'n Hardware Server, was Du da heute bekommst für 100 Euro im Monat, ist schon total abgefahren, ne. Da da das kannst Du nicht mit Computer und der Cloud vergleichen, ne. Also natürlich hat's auch ganz andere Implikationen, Ausfallsicherheit, Du hast viel längere Reboot Seiten, Hardware kann kaputtgehen und so weiter. Aber es sind einfach durch die, ja, Skalierung, die wir bei Hardware mittlerweile haben, hast Du eine brutale Performance, ne. Dann hast Du den Souveränitätsgedanken. Du hast die ganzen AI- und GPU Themen, wo Du dann sowieso vielleicht eigene Hardware brauchst, je nachdem, was Du fürn Use Case machst, weil's mieten einfach dort noch mal. Also die die da spielt die Marge halt noch viel mehr rein, weil's halt noch deutlich teurer ist. Also auf der anderen Seite willst Du dir jetzt für dreißig-, 40000 Euro einen NVIDIA GPU kaufen und irgendwo bei dir im Datacenter betreiben, ne. Also muss man sich auch immer abwägen, aber so, das sind so die Themen, die mir jetzt spontan noch einfallen. Da gibt's bestimmt noch ganz viele mehr. Also ja. Also für Cloud spricht ja auch einiges, musst Du ja auch sagen, ne. Die Leute wissen ja teilweise nicht mehr, wie's geht. Wenn Du jetzt heute jemand hast, der der neu anfängt bei dir, dann ist das ja auch gewohnt, mit AWS, Google Azure und so weiter zu arbeiten, mit Terraform, Polumi und anderen Dingen. Aber so von der Basis lernen, das passiert ja heute auch selten. Und dann hast Du da dieses Knowledge Gap und deswegen ist es auch schwierig ja zu sagen, das wie kann ich das machen? Ich denk immer von den Geschäftsmodellseiten her und ich find Basecamp ist natürlich der brutale Fall, weil die das echt also mit der Marketingflöte total gespielt haben und wenn Du dir die Landingpage anschaust, haben sie auch einiges zu produziert. Aber ich mag auch gern so andere Fälle, die das machen und Du hast jetzt so, wolltest übers Geld nicht treten, aber für mich ist immer entscheidend und wichtig und was schau ich mir an und frag ich auch, wisst ihr denn eigentlich, wie viel Cloud Infrastrukturkosten ihr habt und wie viel Prozent vom Umsatz machen die denn aus? So das ist immer das Und dann kommt's aufs Geschäftsmodell an und danach kannst Du entscheiden, was Du tust.
Jan: Also ich will gar nicht nicht über Geld reden, ne. Ich wollt nur sagen, es gibt ja noch da noch andere Dimensionen und Du machst da 'n guten Punkt, weil am Ende zahlt das ja auch wieder son bisschen auf das Geld ein, ne. Wenn Du jetzt sagst, es fehlt vielleicht die die Expertise, dann ist ja der der eine Punkt zu sagen, na ja, wir gehen jetzt von unserem Hyperscaler weg. Wir machen keinen kein Google, kein Amazon, kein Azure, kein whatever mehr. Aber dann muss es ja irgendjemand anderes machen bei uns so. Und den muss ich ja im Zweifelsfall auch bezahlen. So also im Regelfall sogar, ja, ja. Und der lässt sich das ja bestimmt auch gut bezahlen zurecht, weil das ja auch sone verantwortungsvolle Rolle, ja, sich diese ganzen Sis Admin und ob's Themen irgendwie zu kümmern. Und da kann einen natürlich schon vielleicht auch so der Kostenpunkt wieder 'n bisschen einholen, oder?
Andreas: Meiner Erfahrung nach nicht, ne, weil Du hast ja die Leute trotzdem da. Also uns wär fahrlässig, wenn Du jetzt niemand hast, deine Cloud zu betreiben. Also große Firmen haben halt und nennen's Plattformteams oder SRI Teams oder DevOps Teams, die sich drum kümmern. Und die machen halt das Gleiche nur eben auf 'ner anderen Plattform, ne. Bei Basecamp ist es auf jeden Fall so, die haben niemanden neu eingestellt. Die machen das einfach mit ihrem vorhandenen Personal und dann ist es für die finanziell nicht teurer, ne. Und Du musst mal schauen, es gibt auch 'n paar Artikel da, die Performance ist halt auch deutlich besser geworden, weil Du hast eben bessere Computerressourcen, der Weg zur Datenbank ist ist kürzer. Du hast viel mehr Performance in der Datenbank, ne, was weil Du weil Du eben keine keine Network Volumes mehr hast, die an der Cloud SQL hängen, sondern hast halt lokale SSDs, ne? Das ist halt ist halt kann man heute gar nicht mehr vergleichen, ne? Es gibt ja jetzt so mit Planet Scale auch Anbieter, die dann hergehen und Meta Base Service dann wieder auf auf Metall anbieten, also auf Hardware. Und ich glaub, das kann dir auch ganz viel Kosten sparen, also an der Stelle, an operativen Kosten, ne. Also das darf man nicht vergessen. Aber Du hast natürlich recht, Du brauchst Personal, wo sich mit auskennt. Brauchst Du aber in beiden Fällen.
Dennis: Da würde mich dann noch interessieren, wie viel und offenbar auch, wie wenig Ahnung ich davon habe, aber wie sieht das denn
Jan: so Das sind wir ja Podcast.
Dennis: Genau, dafür sind wir ja hier. Wo für wie sieht es denn so softwaremäßig aus? Also weil, ne, grundsätzlich, keine Ahnung, für mich ist jetzt das, was in Google Cloud passiert, mehr als irgendwie die die Hardware, die da bereitgestellt wird, ne. Da ist ja alles Mögliche, was irgendwie drauf läuft. Du hast immer irgendwie neue Funktionen, die es Developern einfacher machen, ne. Dinge irgendwie da am Laufen zu halten mit verschiedensten Funktionen, mit Monitoring, mit keine Ahnung was. Wie sieht denn da so die Softwarelandschaft aus, die man dann braucht, das vernünftig zu machen, wenn man's komplett selbst macht?
Andreas: Da gibt's ja ganz viel verschiedene Dinge, ne. Du musst dir immer schauen, also ein gutes Beispiel, das ich mir immer zu Augen halte, oder das kannst kannst Du eine Shownotes verlinken. Es gibt von Andresen Horowitz hier, dem Wagniskapitalfinanzierer, gibt's einen Artikel, der heißt Cloud, der trillian Cloud Paradox oder so. Da geht's zum Beispiel Firmenumsatzanteil von 60 Prozent für Cloud Revenue und da ist Datadoc dabei. Häufig hast Du oder treff ich Kunden, die haben irgendwas bei Azure, Google, ABS laufen und dann nutzen die noch Datadoc. Und dann hast Du Oder Du nutzt Cloudwatch oder Du nutzt bei Google die internen Monitoringtools, ne. Und das macht ja aus Cloud Provider Sicht auch Sinn und auch aus Sicht des Anwenders in deinem Fall oder deiner Developer, weil die möchten natürlich nicht mit 10 verschiedenen Interfaces arbeiten, ja. Also aber die Gefahr ist natürlich, dass Du gar nicht mehr rauskommt. Du bist irgendwann sind die Dinger so miteinander verzahnt, dass Du nicht mehr rauskommst. Ich hatte neulich 'n Kunden, der hat dann auch DNS und alles eben in AWS gemacht. Also wirklich und der weiß dann erst mal gar nicht, wo fang ich denn an, so. Und dann kannst Du fängst Du entweder ganz vorne an, also sagst Du, okay, wir machen die Dinge, die CDN und DNS sind. Fängt wir die mal an, rauszuziehen, sodass man eben erstens mal eine Mehrventor Strategie hat. Am Ende wird's dann auch billiger, je nachdem, was man eben macht. Und man ist flexibler und dann kann man eben aber auch hinten anfangen und sein CICD Tooling woanders hin umziehen oder sein Observability Stack. Und da gibt's ja mittlerweile ganz, ganz viele richtig geile Lösungen, auch Open Source. Und da kannst Du ja, kommt drauf an, wo Du den Painpoint hast. Die häufig auch schon Applikationen gesehen, da war 50 Prozent der Cloud Kosten waren für Logs von der Applikation, ne. Also deswegen kannst Du das pauschal nicht sagen. Wenn ich jetzt so was sehe, würd ich natürlich sofort anfangen, den Logging Stack auf eine andere Lösung zu ziehen. Und da kannst Du gibt's Lösungen wie Victoria Metrics und Logs, was in meinen Augen sehr gut funktioniert. Du hast jetzt aber auch von von von Klickhaus, gibt's diesen Klick Stack und Klickhaus weiß nicht, ob Du das kennst, das ist eben das, was Du bei Google mit bequery machen würdest und mit anderen Tools, hast Du eben eine wahnsinnig schnelle, eigentlich ist es als BI Datenbank mal gestartet im Yantex Umfeld. Und heute nutzt das Cloudflare, so eine Logs reinzuhauen, ne. Und dann machen die dort echt weiß nicht die Zahl auswendig, die schreiben mehrere 100000000 Logs pro Sekunde da rein, ne. Und wenn's für die funktioniert, wird's für dich auch funktionieren und dann kannst Du mit so was anfangen, ne. Ob Du das dann bei Clicahos in der Cloud nimmst oder selber hostest, musst Du dir dann überlegen, wie wichtig dir das ist und ob Du's kannst. Und dann kannst Du mit sonem Stack halt anfangen oder Du, weiß nicht welche, was ihr noch alles von Google nutzt. Bei Basecam war's auf jeden Fall so, die Kostentreiber waren Easy Two Maschinen, RDS und s 3. Und das ist eigentlich so auch das Typische. Auch wenn Du da jetzt mittlerweile über 200 Services hast, so hast Du den Grundumsatz und den Grundpfeiler von dem Hyperscaler Umsatz sind immer diese 3 Dinge.
Dennis: Mhm. Grade in der Auflistung hattest Du unter anderem CDNs auch. Ja. Was ist denn, das stell ich mir jetzt zum Beispiel schwer vor, oder? Also wenn Du weltweit Kunden hast oder in unserem Fall Spieler*innen, die weltweit sind und wo's schon gut ist, da nah immer dran zu sein. Wie kann man, wie würde man so einen Fall ohne Hyperscaler machen?
Andreas: Im Prinzip sind es ja, also gibt's ganz viele Anbieter, die dir da helfen können. Das gibt ja mittlerweile, die meisten beschäftigen sich einfach nur nicht damit. Das kommt jetzt drauf an, was Du bei den Spielen für Dinge auslieferst, ne. Ich mag zum Beispiel, ich hab Kunden, wo's viel Bilder geht, da machen wir mittlerweile viel mit Bunny CDN, was dann aus der ein europäisches CDN, das trotzdem weltweit Notes hat, ne. Das viele nehmen das nicht ernst, weil sie auf die Webseite gehen und dann hoppelt der Hase durchs Bild. Aber der die Performance ist mega, Du hast Support über Discord, Hast Du das bei Cloudflare? Hast Du das bei Google? Wahrscheinlich nicht, ne. Also und die Kleinen, die geben sich schon sehr viel Mühe und das macht immer immer Sinn, sich das anzuschauen. Ich was ich zum Beispiel auch mag, ist, weiß nicht, ob Du jetzt das in der Vorbereitung brauchst, es gibt hier Sofa Score aus Kroatien, die sind son Football Scoring Service. Und da war ich mal auf 'nem Talk auf der OSMC von 'nem CTO und da ging's natürlich auch viel Cloud Kosten. Die sind, glaub ich, bei 0.5 Prozent vom Umsatz, nur damit ihr mal sone eine Hausnummer habt. Er hat gesagt, also da geht's Ergebnisdienst für Fußball. Das heißt, das hoch volatiler Traffic, die deren deren Statistiken und Daten werden auf anderen Traffic starken Webseiten eingebunden und dann hast Du, was weiß ich, bei 'nem Champions League Finale halt 'n hundertfachen Traffic. Und die haben am Anfang CDM selber gebaut mit Warnish, so wie ne Fastly basiert auf auf Warnish hier dem Web Ad Generator, den's auch schon eine Weile gibt. Und das kannst Du auch selber machen. Heute nutzen die das glaub nicht mehr. Bin ich mir jetzt gar nicht mehr ganz sicher, müsst ihr den Talk noch mal anschauen, aber die sind jetzt auch nicht klein, ne. Die hatten war, glaub ich, letztes Jahr, als ich da war, 25000000 Benutzer, ne. Und ganz viel Traffic starke Seiten eben und dann kannst Du das selber machen. Also das ist jetzt kein Hexenwerk mehr. Du kannst auch, gibt, glaub ich, auch EngineX Repositories auf GitHub, wo Du dir mal anschauen kannst, wenn's ums Thema Es kommt immer drauf an, was Du machst, ne. Bilder und statische Files ausliefern ist ja jetzt der einfache Fall. Dann buchst Du dir halt 20 Notes irgendwo und schaust, dass deine Sachen hinpushen tust. Und eben eine Invalidierung machst Du, aber CDN ist heute auch viel viel mehr wie das. Mir ging's eben in dem Punkt nur dadrum, dass es häufig keinen Sinn macht, eben alles von Google oder alles von AWS zu nehmen. Du kannst ja auch Immer Cloudflare macht 'n Supportshop an ganz vielen Ecken. Du kannst dann eben sagen, okay, im ersten Schritt zieh ich mal mein CDN zu Cloudflare und dann bin ich da mal flexibel vorn und kann eben hinten an verschiedene Origins Routen und kann eben auch 10 Prozent mal woanders hinschicken wie zu meinem Google Cloud RZ, wenn meine Applikation das erlaubt.
Jan: Also bei Cloud wär wär ich vorsichtig, aber ich glaube trotzdem hast Du 'n validen Punkt, ne, weil wieder zurückzukommen zu sehen, was wir am Anfang sagen, es geht ja nicht darum, dass Du irgendwie bär Metal jeden Server selber auf der Welt verteilst, denn das, wenn Du deinen CTN aufbaust, sondern Du kannst ja schon Dienstleister nehmen. Die Frage ist halt nur, gibt es da Dienstleister abseits der großen 5 sozusagen und müssen es immer diese großen, hoch integrierten 5 sein? Oder tut das nicht halt auch was was Kleineres, Schlichteres, aber trotzdem Performanteres? So. Das glaub ich dann dann so der Punkt. Und warum ich gesagt hab, bei Cloudflair wär ich vorsichtig, ne. Cloudflair ist jetzt nicht eine, wo man so, wenn man über Hyperscanner spricht, dran denkt. Aber ich hab gestern erst wieder 'n Report gelesen, so, dass Cloudflair mittlerweile 20 Prozent Internettraffics irgendwie managt. Und das ist halt auch so, da sind wir wieder bei Vendarlog in, da sind wir bei gefährlichen Situationen so. Deswegen, also die machen coole Produkte. Der der der Bericht hat so damit geschlossen, man kann denen grade glauben, aber wir sind halt nur einen schlechten CEO davon entfernt, dass das irgendwie alles den Bach runtergeht so, ja? Und das das ist, glaub ich, sone gute, wenn man irgendwie an Cloud verengt so. Die sind grade nett, aber es muss halt nur ein schlechter CEO mal rankommen.
Andreas: Ich glaub, die Zahl der großen Seiten, die ist noch viel krasser. Da müsst ihr mal gucken, da gibt's vielleicht bei netcraft out und sone Survey, also der Die 20 Prozent sind glaub ich bezogen auf alle Internetseiten. Und wenn Du dir, was weiß ich, die 100000 stärksten Traffic Seiten anschaust, ist der Cloud Lernanteil noch höher. Also deswegen hab ich auch an die CDN erwähnt, ehrlicherweise es gibt ja auch viele andere noch. Und ist immer 'n Blick wert, sich das anzuschauen, weil die machen alle auch 'n guten Job ehrlicherweise.
Jan: Ja. Also ich kann sagen, ich bin auch auf Cloudflyer, so mit meinem Zeug, aber wenn wenn man jetzt sagt, man will son bisschen weg von den Großen und sich unabhängiger machen, ist vielleicht Cloudflyer nicht die erste Anlaufstelle, an die man denken soll. Ja.
Andreas: Vor allem bist Du wahrscheinlich aufm Freeplan und dann hast Du wieder andere Probleme mit Telekom Kunden, die dann über die USA geroutet werden. Das ist dann halt kein Spaß, muss man sich dann anschauen, ja.
Jan: Das ist richtig. Dennis, Du wolltest gerade was fragen, fürchte ich's unterbrochen, ne? Nee,
Dennis: also für mich ist noch nicht so, also
Andreas: Bist nicht überzeugt.
Dennis: Nee, ich bin Nee, da da darum
Jan: geht's nicht.
Dennis: Daran entscheidet's nicht, sondern grundsätzlich vermute ich, aber das hat Andreas auch gesagt, dass es da diese unterschiedlichen Schichten gibt, ne. Aber wenn ich jetzt Cloud Exit höre, dann ist es für mich in meinem Kopf nicht verknüpft mit, ich geh zu 'nem Anbieter, der kleiner ist und ne oder such mir für 3 der Tools, die ich auf Google hab, jetzt 3 unabhängige Anbieter, die aber letztendlich auch ein Managed Service irgendwie in der in der Cloud sind, sondern damit verknüpf ich dann schon eher, aber das liegt jetzt nur an dem Wording, von daher ist ja schon interessant, über die verschiedenen Stufen zu sprechen, dass man halt 'n bisschen mehr selbst managt, wirklich einen Vorteil zu haben so. Also klar, sicher sind die die die Hyperscaler, vermute ich, nicht die nicht die günstigsten für das, was man da bekommt. Aber vermutlich ist auch gleichzeitig der der Zugang am einfachsten, am et cetera. Und klar, also ich ich ich seh das auch mit dem Endor Login. Ich mein, das ist bei uns, würd ich sagen, sehr extrem im Sinne von, ne, dass wir, wir waren mal auf AWS, sind dann irgendwann, weil's eine Zeit war, das ist auch schon viele Jahre her, aber wo Google Cloud dadurch, dass sie später waren, irgendwie die Möglichkeit hatten, einige Produkte einfach noch developerfreundlicher zu bauen und irgendwie cooler zu bauen, sind wir aus aus User Experience Gründen vor allen Dingen in die Google Cloud gegangen. Ich glaub, Firebase war damals so 'n sehr geschickter Einkauf und so. Anker oder den sie so hatten, den sie ausgeworfen haben, weil das halt, ne, auch grade für Mobile Development so super zugänglich war und letztendlich ja nur son kleiner abstrakter Layer noch mal über der Google Cloud ist, wo man dann so reingezogen wird, wo's am Anfang schön und einfach und günstig ist und man dann in die in die echten Google Cloud Produkte gehen muss, wenn's wenn's 'n bisschen größer wird. Und klar, ne, jetzt alles so letztendlich von von Google Workspace, den wir nutzen für ja, unser Marketing, viel auf der Seite ist, die Werbemonitorisierungsplattform, die wir nutzen von Google ist und so. Ja, wo einiges natürlich auch Vorteile hat, wenn das dann so integriert ist, weil manches manches auch so möglich dann nur ist, wenn wenn alles dann aus 1 Hand kommt. Aber klar, wir irgendwo natürlich eine krasse Abhängigkeit haben von dem einen großen Anbieter.
Jan: Also ich würd doch mal die These aufstellen, das, was Du eingangs gesagt hast so, na ja, das ist schon recht einfach, auf diesen Hyperscalern irgendwie was zum Laufen zu bringen. Da würd ich mal 'n Fragezeichen hinten dran machen. Weil jeder, der schon mal, also irgend eine Anwendung auf sonem v-Server installiert hat und da seine Firewall zusammenkonfiguriert hat, der würd dir vielleicht auch sagen, das ist im Zweifelsfall sogar einfacher und schneller als dir bei AWS oder Google Cloud so, ne, deine Ressourcen zusammenzuklicken, deine Geo Group irgendwie richtig zu konfigurieren, deine Network Group zu machen. Also man muss da ja mittlerweile auch schon einiges zusammenklicken, bis es überhaupt so fertig öffentlich erreichbare Service irgendwie zustande kommt, ne?
Andreas: Völlig klar. Also ist ja jetzt auch dadurch, dass die und da muss ich euch schon zustimmen, die Google Cloud ist da viel freundlicher, weil Du hast eben nicht diesen diese 100 Möglichkeiten, irgendwas zu machen, wie sie bei ABS eben ist, ne. Wenn Du jetzt einen Container deployst. Ich glaub, der Cory Quinn hat hier im Last Week in AWS gibt's den coolen Newsletter übrigens. Also ich les ich les konsumiere auch andere Sachen, lass mich da also über da überzeugen. Der der hatte mal sone Serie gemacht, 12 wways to deploying Container in AWS und eine Woche später kam, Containen AWS, so. Und in Google hast Du Du hast halt eine relationale Datenbank. Du hast eine nicht relationale Datenbank. Dann hast Du b Query, dann hast Du dann hast Du die die so. Und der Einstieg ist da schon einfacher, wie wenn Du jetzt heute in AWS anfängst so. Wenn Du dich noch gar nicht mit beschäftigt hast, ich mein, es gibt ja jetzt auch schon eine Weile und Du hast eben wahnsinnig viele Möglichkeiten. Also klar, wenn Du dich bei Hetzner einloggst und eine VM deployest, ist die nach 50 Sekunden, 30 Sekunden da und kannst sofort loslegen. Das ist 'n bisschen einfacher, an manchen Stellen auch gefährlicher wahrscheinlich. Und man muss eben wissen, was man tut, das muss man aber überall, ne. Und wie können wir dich jetzt überzeugen, Dennis? Das ist jetzt die Frage. Muss ich ja aber eigentlich auch gar nicht. Also ich glaub, wichtig ist, dass man eben weiß, was was man sich eben was man sich antut und diesen Cloud Infrastrukturkosten pro Umsatz oder bei euch dann pro Spiel irgendwie zu quantifizieren und im Auge zu behalten bei neuen Features, das ist wahnsinnig wichtig. Also was ich halt häufig merke, ist diese Naivität im Umgang mit Cloud Providern, ne. In der Cloud wäre das nicht passiert, ist son Zitat, was ich im Newsletter hab von 1 ehemaligen Führungskraft, die ich kenne, wo wir mal Probleme hatten mit 'ner Applikation. Und das die Cloud löst eben keine Applikationsprobleme, ne. Da sind wir 'n bisschen aneinandergeraten. Häufig komm ich in Projekte rein und frage so, na ja, wie sieht 'n euer Observability Stack aus? Habt ihr sowas wie Century am Start? Kennt ihr denn den Userflow? Wisst ihr denn, an welcher Stelle was wie langsam werden kann? Versteht ihr denn die Timeouts? Versteht ihr ja eure Abhängigkeiten in den Services? Wenn's Microservices sind, wird's dann komplexer. Dann hast Du noch Abhängigkeiten zu externen APIs und das sind alles Dinge, die musst Du ja irgendwie sehen, so. Und dann hast Du die Kunden, die gehen halt her und buchen sich die nächstgrößere Datenbank. Das ist natürlich schön für den Cloud Provider. Hättest Du halt 'n Index angelegt, dann könntest Du eine Stufe runterstellen sogar. Und das ist immer so die Naivität so, ich brauch kein DBA, ich brauch kein Cis Admin. Das das ist ja alles son bisschen 'n Trugschluss, ne. Du wolltest, glaub ich, aber auf die Ebene noch mal eingehen und ich glaub da jetzt noch mal, also ich weiß nicht, mit der Hand wolltest Du eine Frage stellen, sonst ich kann dir kurz sagen, wie bei Basecamp das läuft, die haben einen einen Housing Anbieter, ne. Und das ist eigentlich was, was wir in der Vergangenheit auch häufig gemacht haben. Das heißt, die haben jemand, bei dem mieten die sich Rex, die kriegen quasi Stromnetzwerk, ganze Brandmeldegeschichte, Notstrom. Die kriegen im Datacenter. Das heißt, da buchst Du dir dann jemand, der an den Server geht und eine Festplatte tauscht, zahlst Du dann 15 Minutenweise. In dem Falle von Basecamp haben die dann auch so Dinge wie Firewall und Load Balancer dazu gemietet. Und was sie gekauft haben, ist dann Comput Hardware, wo sie eben ihre Container drauf deploylen. Da haben sie halt auch mit Kamal was eigenes, eine eigene für gebaut, die ihr, ich glaub, sie hat's Decobernetis genannt oder d k aids, also auch der Exit von von der Container. Und dann haben sie mit Pure Storage Hardware für s 3 gekauft. So. Und das steht dann im RZ und das betreiben die Leute selber und die Hardware da, also die Software, die da drauf läuft. Aber sobald die Hardware kaputtgeht, rufst Du jemand im RZ an oder machst 'n Ticket auf und jemand tauscht das für dich aus. Also ist dann schon 'n professioneller Dienstleister, der das für ganz viele Firmen macht. Und witzigerweise machen die das auch für Hyperscaler, weil das ist ja immer der Trugschluss, den die Leute haben. Ne, AWS in Frankfurt ist kein eigenes RWSRZ meines Wissens nach und Google auch nicht. Und deshalb sind die Preise dort auch anders wie jetzt in Berlin oder in Belgien zum Beispiel bei Google, wo's dann eigene Datacenter sind. Und das heißt, das ist auch dort eingemietet einfach. Nur halt eine andere Größenordnung wie jetzt Basecamp.
Dennis: Ja. Okay, aber das heißt, zumindest die Schicht, also wenn es 'n Mann so macht, kommt ja zumindest die Schicht des Monitorings der Hardware noch dazu, ne, die Du sonst nicht hast. Das heißt, da musst Du irgendwie Dinge etablieren, Bescheid sagen zu können, dass eine Festplatte ausfällt und hoffentlich irgendeine Art von Strategie haben, dass diese wieder eingebunden werden kann oder dass damit nichts Kritisches verloren gegangen ist. Ja.
Jan: Und im Prinzip musst Du halt auch die Fakeover Regelung selber treffen, ne. Also wenn Du jetzt son Managed Cybernetes Cluster kaufst und da fällt unten drunter irgendwie eine Hardware Kiste aus, dann kümmert sich halt irgendwie Google oder Amazon darum, dass das umverteilt wird. Das musst Du dann halt auch selber machen, wenn Du das Metall sozusagen selber kaufst, selber anbindest, selber betreibst. Aber das ist auch eine relativ dünne Schicht so.
Andreas: Ja, und das Metall ist mittlerweile ganz schön relibl, wenn man vernünftiges Zeug kauft. Also wir haben ja auch Kunden, da kaufen wir gebrauchte HP Server, Generation älter oder davor sogar. Teilweise laufen die dann noch 10 Jahre. Ist echt nicht so. Ich bin mal gespannt, wenn wir in 3, 4 Jahren auf den Basecamp Fall zurückschauen und das haben sie vor 2 Jahren die Hardware gekauft und noch 5 Jahre ausgelegt. Ich denke, Du kannst die deutlich länger nutzen, ne. Ist ja auch was, ich glaub Google schreibt die mittlerweile auch deutlich länger ab, die Hardware, die sie selber kauft. Und das ist ja auch nicht so, dass das regelmäßig kaputt kaputtgeht, mehr.
Jan: Als wir in der Folge über Green IT mit Arne gesprochen haben, hat er auch gemeint, das ist so eigentlich auch 1 der größten Hebel, so den c-o-zwei-Fußabdruck von deinen Operations so zu senken, weil natürlich in der Produktion von der Infrastruktur, die Du so verwendest, viel Fußabdruck anfällt und mittlerweile einfach die Hardware viel länger durchhält als der Zeitraum, für den sie eigentlich provisioniert ist. Und wenn man das einfach random 2, 3, 4, 5 Jahre verlängert, was sie locker mithalten könnte, dann ist das auch schon aus anderen Gründen gut. Ja. Ein ein Punkt, den ich noch machen wollte oder oder 2 Punkte, vielleicht in einem, wie man sich vielleicht diesem Thema son bisschen noch nähern kann oder wie man sich vielleicht zu diesem diesem Exit mit mehr Vertrauen nähern kann. Das es gibt ja dieses dieses geflügelte Wort in der IT so, IBM. Das ist also das ist, glaub ich, schon älter als ich so, würd ich mal sagen. Und das ist ja so, ne, also immer dann, wenn wenn Manager irgendwie Risikoentscheidungen treffen müssen und so irgendwie Angst haben müssen, dass sie am Ende persönlich irgendwie angreifbar gemacht werden für irgendwas in der IT, dann dann tendieren sie halt so zu diesen großen De facto Standardlösung, damals halt IBMs, würde man heute wahrscheinlich auch anders sagen. Und in dem Fall ist es vielleicht nobody get fireed vorbeiing aWS, so, ja? Also wenn Du halt irgendwie in deiner Bude verantwortlich für Infrastruktur bist und Du Du setzt von Anfang an auf AWS und selbst wenn da dann irgendwas schiefgeht, dann kreidet das dir halt irgendwie niemand an. So, weil AWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW So wie viele Sicherheitslücken sind da draußen schon entstanden durch falsch konfigurierte s 3 Buckets so, ja? Ist glaub ich mit son son Standardfall mittlerweile. Und von daher, vielleicht kann man da son bisschen mehr mehr Mut zur Lücke vielleicht auch finden. Und ich glaube, noch mal zurückkommt auf das, was wir ganz, ganz am Anfang gesagt haben, dass es ja doch auch irgendwie eine Daseinsberechtigung hat, ne, ist, wenn man sich anguckt, wie sich sone Firma entwickelt, dann setzen ja viele mit Cloud und Hyperscanner am Anfang schon auf das richtige Pferd. Du hast ja zurecht den Punkt so gemacht, na ja, guck dir halt irgendwie deinen Umsatz an und was fürn Anteil das von deinem Umsatz ist. Und das ist ja eigentlich der allerwichtigste Punkt. Und wenn Du jetzt zum Beispiel grade am Anfang bist, Du hast noch fluktuierende Kunden, Du kannst das noch nicht so wirklich vorcasten, dann ist ja grade diese Flexibilität halt irgendwie superwichtig für dich. Und wenn man sich dann so Sachen anguckt wie Serverless Computing, wo Du vielleicht kaum Grundkosten hast und im Prinzip Kosten nur dann entstehen, wenn auch wirklich Arbeit und hoffentlich Umsatz für dich anfällt so, ja, dann ist das ja schon irgendwie genau das richtige Modell an der Stelle. Also es macht ja für niemanden Sinn, 10000 Euro in Infrastruktur zu stecken, bevor der erste Kunde überhaupt zur Tür reingekommen ist. Boah, völlig klar. Und dann aber halt zu schauen, okay, wann sind wir an 'nem Zeitpunkt, wo unser unser unser son hohes Grundrauschen irgendwie erreicht hat, so son hohen Standardbedarf, dass wir halt diese Flexibilität, die wir uns teuer erkaufen bei 'nem Hyperscaler, vielleicht gar nicht mehr brauchen oder gar nicht mehr für alles brauchen, ja? Weil wir wenn wir sehen, 80 Prozent von unserem Traffic ist irgendwie konstant, dann können wir das und dann kommen wir zu diesen gemischten Lösungen, ne? Ja, irgendwo hinschieben, wo wir uns fixed irgendwie kaufen können, dann lassen wir das darüber laufen. Und dann kann man ja immer noch, wenn man irgendwas am Produkt hat, was sich so burst mäßig fällt, kann man das ja immer noch dadurch ergänzen durch son Produkt.
Andreas: Exakt. Du, bei den Serverlast Lösungen musst Du halt aufpassen. Da hatte ich, wann war 'n das? Gab's ja jetzt mit diesen AI Tools ganz viele, die schnell was bauen. Da hab ich neulich wieder auf Twitter eingesehen, der hatte über Nacht dann irgendwie 25000 Dollar kosten. So. Weil Du baust es natürlich nicht, dass es optimiert ist, dass es eben 100000 User kann. Und wenn's dann viral geht, während Du im Bett bist, dann ja, hast Du 'n Problem. Aber Du hast sonst komplett recht. Also würd ich auch immer immer so empfehlen, macht gar keinen Sinn, sich damit rumzusaren, bevor man überhaupt Kunden hat oder Umsätze, würde ich mich mit dem Thema gar nicht beschäftigen. Und man muss auch sagen, das ist jetzt auch in den letzten 2, 3 Jahren hat es an Popularität gewonnen, weil sowohl bei Start ups als auch bei etablierten Firmen es eher drum geht, ist die Firma denn eigentlich profitabel oder wie werden wir denn profitabel? Und nicht mehr diese Hockey Stick Wachstumskurven, ne? Und dann hinterfragst Du ja oder wenn Du jetzt sowieso Probleme hast, was so dein Kapital oder dein Liquidität betrifft, dann hinterfragst Du deine Kosten und dann kann so was halt mal bei rauskommen. Und wie Du sagst, Du kannst auch die Dinge modular irgendwie austauschen. Also und da kommt's voll drauf an, was sind denn meine Kostentreiber und was ist vielleicht unverhältnismäßig? Und das sind halt individuelle Fälle und das muss man sich anschauen, so.
Jan: Aber da ist es ja eigentlich essenziell für die eigenen Kosten zu verstehen und so, ja? Und da gibt's, glaub ich, 2 Probleme. Das eine Problem ist, jeder, der schon mal sone AWS oder Google Rechnung gesehen hat, der wird bezeugen können, dass das nicht grade Also ist auf der einen Seite sehr transparent und auf der anderen Seite sehr intransparent, weil Du natürlich so überhaupt nicht verstehst, so wo das wo das herkommt, ne. Du siehst dann so, ja, für s 3 fallen halt irgendwie diese Kosten an. Und dann musst Du dich halt irgendwie erst mal durchfuchsen, welcher, welche Art von Traffic, welche Region bla bla bla, ne, das son bisschen genauer zu verstehen. Und dann verstehst Du ja immer noch erst mal nur die Kosten, aber nicht den Zusammenhang mit dem Produkt. Und jetzt kommt, glaub ich, der Teil, der für viele da draußen super-, superschwierig ist. Und vielleicht kannst Du da so so die irgendwie für geben. Aber wenn ich jetzt 'n Produkt hab und ich hab meine Infrastrukturkosten auf der anderen Seite, dann muss ich ja eigentlich das irgendwie dem Produkt oder 'nem Feature auch zuordnen können, ne. Ich muss ja verstehen, was an meinem Produkt verursacht eigentlich welche Kosten? Also wenn wir jetzt, weiß nicht, Dennis, ne, wenn wir das bei uns irgendwie versuchen, so zu sehen, dann müsste man im Idealfall gucken, na ja, was kostet mich eine gespielte Partie oder eine Multiplayerrunde oder Push nach Rechten oder keine Ahnung. Und das halt so wirklich dann zu schauen, welcher Teil davon ist eigentlich fix und welcher ist der schwankende Teil und was würde sich vielleicht lohnen, irgendwie auszulagern? Aber wie wie nähert man sich dem überhaupt?
Andreas: Du müsstest in der Rechnung Wie wie schön wäre das, wenn die Rechnung son sone Art OML Diagramm wär, wo Du eben den den Traffic Flow sehen würdest und dann könntest Du sehen, was hat wie viel Kosten verursacht in der in der Kette, ne? Das Ich
Dennis: ich ich
Jan: kann dir sagen, ich hab ja schon mal für größere Firmen AWS Set ups verantwortet und es gibt ja mittlerweile Dienstleister, die also genau das machen, ja, die Tools für Tausende Euro im Monat anbieten, deine AWS Rechnung für Zehntausende Euro im Monat irgendwie besser verstehen zu können. Und allein da sieht man ja schon, wie wie paradox und problematisch dieses Setup irgendwie ist.
Andreas: Ja. Ja, ja. Also wie gesagt, der Cory Quinn hier von Last Week in AWS, dem seine Firma, die heißt die, glaub ich, die machen auch nichts anderes wie Kosten analysieren. Und der hat ja, glaub ich, auch eine Zweistege Anzahl an Angestellten, ne. Und er spielt das Thema auch immer rauf und runter. Ich versteh's komplett. Also wo fängst Du an? Also das ist halt immer eine individuelle Sache. Ich würd immer anschauen, wo haben wir denn Kosten, ne? Du hast zum Beispiel, Du hast s 3 erwähnt. S 3 an sich ist 'n total geiler Dienst, egal wo Du den nutzt, ne. Und und was Du damit machen kannst an Flexibilität und rein die Speicherung in AWS, die ist gar nicht mal teuer. So, spannend wird's bei Dingen wie und Traffic. Traffic, der in der Region ist, kostet nix. Traffic, der nach der Region rausgeht, der kostet mehr. So, jetzt hatt ich neulich 'n Kunden. Bei dem seiner Applikation ist jedes Dokument hat halt zweimal Traffic gemacht, ne, weil Du bist quasi, das war also sone Art B2B SARS Applikation für, wir nennen's mal Makler, dann ist nicht ganz klar, die Makler laden was für ihre Endkunden an Dokument hoch, also macht schon Traffic beim Upload von draußen nach drinnen. Und der Kunde draußen, der lädt sich das runter, macht also noch mal Traffic. Vielleicht lädt dann der Kunde draußen wieder was hoch, der Makler lädt's runter, im Gegenzug irgendwas Unterschriebenes oder so was. Und dann hast Du, oder es hat bei dem dazu geführt, dass die reinen s-drei-Speicherkosten 10 Prozent sind. Und der s-drei-Traffic und Zugriffe sind 90 Prozent der s-drei-Kosten. So. Und das ist zum Beispiel was, das kannst Du in diesem tollen Kostcalkulator vorher gar nicht wissen, weil Du weißt ja gar nicht, wie viele Requests wird meine Anwendung am Ende machen? Was für wie wie sehen die Patterns aus, wie die Nutzer dies nutzen? Und das musst Du dir halt musst Du dir anschauen. Und da, was macht den Sinn? Also ich würd mir immer erst mal die Top 3 Verbraucher oder so was anschauen, ja. Und dann würd ich mir angucken, was passiert denn da eigentlich und wie agieren die Nutzer an der Stelle mit dem Dienst und was kann ich denn da besser machen? Häufig reicht's ja auch schon, Du kannst ja auch s 3 zu 'nem anderen Anbieter stellen, wo vielleicht die Speicherung teurer ist, aber der Traffic deutlich billiger und der Anbieter jetzt eine aus der zweiten oder dritten Reihe, der hat gar kein Abrechnungsmodell für oder für für Putcat und so was. Und dann sparst Du diese, sparst Du von den 90 Prozent eben 80 Prozent wieder ein. So, dann hast Du schon mal einen Baustein raus und s 3 kannst Du in der Regel ganz gut irgendwo anders hin verschieben, weil sich's einfach als Standard etabliert hat.
Dennis: Ja. Du hast am Anfang oder nee, immer mal wieder von dem dem Verhältnis gesprochen so der Cloud Kosten zu dem Umsätzen, die man macht. Gibt's da irgend eine Hausnummer, wo Du sagst so, ab da sollte man es auf jeden Fall mal kritisch hinterfragen und gucken?
Andreas: Also es kommt drauf an, in welchem Geschäftsfeld Du unterwegs bist, ne. Wenn Du jetzt so Discount E-Commerce machst, ja, dann sollte das irgendwie unter 5 Prozent sein. Wir waren mal unter 2 zum Beispiel. Wenn Du eine SaaS Applikation machst für für ja, so im mittleren Segment, dann wahrscheinlich irgendwo zwischen 5 und 10 Prozent, wenn Du dann so Enterprise Segment bist, ne. Ich hatte Datadoc erwähnt und der Artikel heißt übrigens, Paradox, da ist dann auch so was drauf wie wie, ach, wie heißen die, Snowflake und so. Die haben halt schon 40, 50, 60 Prozent von ihren Umsätzen geben die an den Hyperscaler ab, so.
Jan: Mhm.
Andreas: Und klar ist es denen wurscht, weil die eben weiter wachsen. Die wachsen mit ihren Bestandskunden, die legen mehr Daten ab oder bei Datadoc hast Du größere Infrastruktur, dann wird die Consumption immer höher, von daher ist es für die kein Problem, das zu bezahlen. Für dich wird's vielleicht irgendwann zum Problem, wenn deine Monitoring Rechnung dann größer ist wie deine eigentliche App Rechnung und dann musst Du's dir anschauen. Also das die Antwort ist leider, es kommt darauf an, Mhm.
Jan: Aber da
Andreas: gibt's so son bisschen Richtwerte, ne? So SARS Applikationen 5 bis 10 Prozent vielleicht. Wenn's drüber ist, würd ich's mir wirklich dringend empfehlen, das anzuschauen. Bei bei bei euch weiß ich's jetzt gar nicht genau, was so, ne, Roblox hat da auch keine Zahlen veröffentlicht, wie's bei denen läuft. Zumindest erinner ich mich nicht dran. Moment klar, wenn Du jetzt hier 18, 20000 Server betreibst, ist es auch nicht billig. H-Refs hat es mal hier, dieser SEO Dienst, die hatten das mal die hatten den Weg mal andersrum gemacht, ne. Die sind die sind auf eigener Hardware und die hatten mal ausgerechnet, was würde sie das in der Cloud kosten, ne. Und dann wären sie nach 2 Monaten insolvent oder so. Aber halt auch, weil die wahnsinnig viel Compute und CPU brauchen, so. Deswegen kommt's echt immer auf den Use Case an.
Dennis: Mhm. Okay.
Jan: Weil Du grad die Case ansprichst?
Andreas: Ja, Figma, Entschuldigung, das wär son aktueller Case, da waren's, glaub ich, 15 Prozent oder 10, 15 Prozent. Also von deren Umsatz sind die Cloud Kosten und in der Headline stand halt, ja, unterschreiben 550000000 AWS Vertrag. Aber es sind halt über 5 Jahre und dann kommst Du auf die 300000 Dollar am Tag irgendwie. Ich find's trotzdem noch erschreckend viel, aber wenn Du in sonem Wachstumspfad bist wie die, ist das vielleicht Wurst einfach.
Jan: Es gab Anfang des Monats, weil Du's grade den den anderen Case angesprochen hast, auch 'n interessanten Blogpost von Stack Overflow, der betitelt war, the create unracking. So, also wie die machen im Prinzip grade genau dasselbe, so vom Rack in die Wolke und haben auch son bisschen dokumentiert, ne, warum sie sich vielleicht andersrum entschieden haben und wie das für sie so alles funktioniert. Die waren ja sonst immer sehr gut dabei, so ihre eigene Hardware zu dokumentieren und so ihre Rechencenter irgendwie sehr transparent zu machen. Und die ziehen jetzt grade peu à peu andersrum Also es kann auch berechtigte Wege in beide Richtungen vielleicht geben.
Andreas: Bei denen liegt's vielleicht da dran, dass der Traffic Ich wollt grad sagen, ich eingebrochen ist, wo sie jetzt ihre Hardware nicht mehr ausgelastet haben.
Dennis: Wenn Du halt 'n Produkt hast, was nicht mehr funktioniert, dann ist wahrscheinlich besser, wenn Du deine Rex abbaust und
Jan: Aber da da sind wir ja wieder bei genau dem, was wir eben gesagt haben so, ne? So eigene Hardware lohnt sich halt, solang Du 'n konstant vorhersehbaren Traffic Account halt irgendwie hast und wenn Du den halt nicht mehr hast, dann wird's halt schwieriger. Ja. Aber Dennis, ich hab dich ja vorhin schon so gefragt, was Du so sagen würdest, wenn ich jetzt pitchen würde, wir gehen hier von von Google weg. Wie würdest Du denn glauben, würde das bei uns in den Devteams ankommen, wenn ich mich nächsten Donnerstag bei uns ins Dev Weekly stelle und sag, so, ab sofort machen wir Schrägstrich macht ihr das alles selbst? Weil das ist ja auch sone Dimension, die auch dazugehört, ne. Also es bringt ja son gewissen Komfort, hast Du auch schon gesagt, mit, wenn man einfach jetzt so seinen Service bauen kann. Man packt den in son Docker Container und schiebt den irgendwohin und nach mir die Sintflut. Das ist ja dann im Prinzip vielleicht auch vorbei, wenn man sich mehr dieser Infrastruktur selber kümmern müsste oder kann, darf, will, wie auch immer.
Dennis: Ja, also ich mein, ich hab Andreas so verstanden, dass der Aufwand vielleicht gar nicht so viel größer ist, also ne, dass, sagen wir mal, Du es ja jetzt auch irgendwie in 'ner gewissen Art und Weise managen musst, was Du dort in der Cloud hast und dass dann eben bisschen anders gelagerte Tätigkeiten sind. Bei uns konkret, ja, ich würde jetzt nicht sagen, dass auf große Liebe Gegenliebe stößt so, weil es einfach Ja, am Ende würd ich sagen, können wir uns auch den Luxus leisten, so, ne. Also ich glaube, das ist in 'nem Bereich, wo wir sagen können, okay, ohne jetzt halt harte Commitment zu machen, ohne genau zu sagen, zu projizieren, was ist die Hardware, die wir brauchen, ne. Das ist ja dann auch alles irgendwie dann gewisse Risikofaktoren, die damit auch einhergehen, die man dann auch zusätzlich hat. Da ist uns, glaub ich, einfach die die die Weiterentwicklung, die dort passiert und die Flexibilität im Moment, glaub ich, höher. Und das wäre wahrscheinlich auch was, aber wir haben auch keinen, muss man auch dazu sagen, wir haben jetzt auch kein explizites DevOps Team oder so was, sondern bei uns sind das Full Stack Entwickler*innen. Das heißt, ne, die ja, ist nicht deren Hauptaufgabe, sich diese Dinge zu kümmern. Und ich ich würde denken, Sie würden's lieber gerne so laufen lassen.
Andreas: Aber machen die, wie viele sind das und machen die on Call selber? Gibt's das gar nicht, weil es läuft ja in Google und wie man wissen, läuft's ja die ganze Zeit?
Dennis: Ja, genau. Nee, gibt es tatsächlich nicht. Und ich mein, auch das jetzt wieder irgendwo, also für diese Situation als als luxuriös betrachtet, weil am Ende sind es Spiele, die wir betreiben und es ist nicht irgendeine kritische Infrastruktur, kritische Hardware, es sind keine Finanzen et cetera. Das heißt, wir sind okay damit, wenn irgendwie bei den Großen was ausfällt und das nachts ist, dass wir darauf nicht reagieren in dem Moment, sondern im Zweifel auch mal ein Produkt für ein paar Stunden nur et cetera nicht nicht verfügbar ist. Das ist, ja, das ist, können auch hier, ja genau, können wir irgendwie abfedern. Ja. Passt. Deshalb,
Andreas: Independense, ne. Also es kommt echt immer aufs Geschäftsmodell an. Wenn Du jetzt eine SaaS Applikation hast oder wir haben zum Beispiel Kunden, die machen im Fußballumfeld viel Content, ne. Sind recht große Contentpages im Fußballumfeld. Und wann sind die Traffic stark? Na, wenn die Fußballspiele sind, ist halt am Wochenende und abends, ne? Und da musst Du halt einen Prozess haben, wie Du denen helfen kannst, wenn was passiert. Und das ist halt völlig anders, wie jetzt, wenn Du ja wenn halt 'n Spiel nicht geht. Also es deswegen kommt's echt immer voll drauf an Ja. Was Du machst und und ja, was das für ja, Auswirkungen potenziell halt hat, wenn's nicht funktioniert.
Dennis: Ja. Nee. Absolut. Genau. Aber ich glaube, das ist auch tatsächlich dann so 1 der der Dinge, die die ich gedanklich auch so ein der Hauptpunkte auch mit rausnehme aus der aus der Podcastfolge. Also natürlich kommt es darauf an, ne, was was der Use Case ist. Aber auch vor allen Dingen, ich glaube, son bisschen Beständigkeit ist, glaub ich, eine Sache, die man auch irgendwie nennen kann, ne. Also wenn Du einfach viele Fragezeichen hast und einige Faktoren, die Du nicht so hundertprozentig bestimmen kannst, dann ist es vermutlich einfacher, ne, sei es in in Anfangsphasen, in, ja, in in in starker, starken Variablen, die irgendwie dauerhaft drin sind, dass man dann eben, und das ist ja dann auch die Realität, dafür zahlt,
Jan: ne.
Dennis: Also das ist ja letztendlich, was man sich zusätzlich einkauft, ist ist das dann zu haben für Mehrkosten, die man hat.
Andreas: Und Du musst es halt vernünftig planen, wenn Du's tust, ne. Wir haben jetzt tatsächlich auch jetzt aktuell jemanden, den wir aus der Google Cloud rausziehen. Es wird am Ende so 85 Prozent Ersparnis rauslaufen, hängt aber auch wieder komplett am Use Case, ne. Und das Spannende ist, dass Du in diesen Zwischenschritten, Du fängst an, Teile von der Applikation rauszuziehen. Dann läuft die Datenbank zum Beispiel noch bei Google. Dann passiert auf einmal Folgendes, Du greifst von extern auf die Datenbank zu für die Zeitpunkt der Migration. Dann zahlst Du für den Traffic, den Du zur Datenbank machst. Und das sind Kosten, die hattest Du vorher nicht, ne. Weil Du warst ja eben intern Netzwerk, so. Das heißt, Du hast 'n gewissen Invest für Demigration und das ist auch hochindividuell. Mich fragen auch immer die Leute dann, na ja, was was müssen wir denn da rechnen und so was. Das kommt kommt auch wieder voll drauf an, wie die Applikation gestrickt ist und was die tut und in dem Fall macht die halt viel Requests an in die Richtung Und dann musst Du halt schnell schauen, dass die Datenbank dann auch rauskommt, dass Du auch wirklich dann sparst und nicht die Kosten jetzt dann, die Du oder die die Kosten, die Du sparst, in Traffic investierst sozusagen.
Jan: Aber also ich versteh, dass man über die Kosten nur so sehr abstrakt irgendwie reden kann im Vorfeld, aber kannst Du vielleicht über die die Dauer son bisschen was sagen, ne? Also wenn jetzt so der durchschnittliche Mittelständler irgendwie zu dir kommt und sagt, okay, lass uns mal überlegen, wie können wir da eine andere Lösung finden? Wie kann sone Migration aussehen? Über was fürn Zeithorizont reden wir von so dieser Idee bis zu 'nem fertig durchgezogenen fertig durchgezogener Migration?
Andreas: Wir machen das hauptsächlich ja nur für Webapplikationen und das ist jetzt typischerweise kein Mittelständler, der sich da meldet, ne. Sind halt so E-Commerce-S-Content Themen, aber Du hast dann je nachdem, also es kann auch schon 'n halbes Jahr bis Jahr dauern, je nachdem wie die Applikation halt gebaut ist, ne. Wenn alles auf auf Kubernetist läuft, dann geht's natürlich deutlich einfacher. Dann gehst Du halt auf einen anderen Provider. In der Regel ist es aber nicht der Fall, Du gar nicht im Mittelstand. Und dann musst Du dir das anschauen, ne, wir haben jetzt andere Kunden, jetzt den, den ich grade angesprochen hab, da geht es sehr viel schneller, als wenn man halt in 2 Monaten mit dem Größten durch. Das kommt auf die Priorität an, die der Kunde draufsetzt und man merkt schon, wenn die wenn die sehen, was sie sparen, sind sie ja auch angefixt, den Rest herauszuholen. Und ja, jetzt in dem Fall, wie wir das tun, ne, wir machen ja dann sozusagen dann auch die DevOps Themen und arbeiten wie einen Mitarbeiter mit und dann bist Du in Slack für die ansprechbar und das fühlt sich für die halt auch gut an. Das ist halt jetzt nicht so, wie Du machst 'n Google Support Ticket auf und dann kriegst Du morgen Feedback, sondern das läuft. Aber ja.
Jan: Okay.
Andreas: Mittelständler hat sich, melden sich weniger aktuell. Bei denen ist mehr so, ich will in die souveräne Cloud, glaub ich, grad das Thema, dass das, was bei denen ankommt.
Jan: Mhm.
Andreas: Mhm. Ich würd, einen Punkt, was Du vorher noch gemacht hast, den hab ich völlig vergessen und ich hatt's hier drauf stehen. Du hast dir dieses no Body was feiert, vorbying IBM noch angesprochen. Und das war ja zwischendurch, bevor das AWS war, aber das ist zumindest, wie ich's immer erzähle, war das SAP dann zwischendurch, ne? Und das ist heute wahrscheinlich auch noch so. Und heute ist es tatsächlich AWS und das das ist, ich finde es tatsächlich auch sehr schade, weil Du hast halt, wenn Du jetzt so wie jetzt im Juni, als wir einen Google Cloud Ausfall hatten von zweieinhalb Stunden und Cloudflare war auch so lang betroffen, da geht's halt das halbe Internet nicht und dann haben wir eine Akzeptanz dafür, ne. Wenn aber bei 'nem kleinen Provider was ausfällt, dann gibt's diese Akzeptanz nicht und da wollt ich jetzt einfach mal eine Lanze für brechen, weil's kochen eben einfach alle nur mit Wasser. Das ist dann auch immer das, was ich eben meinem Newsletter schreib, was mich einfach auch 'n Stück weit beruhigt, weil es gibt halt einfach keine 100 Prozent Uptime. Das gibt's nirgends, egal wie die Firma noch so groß ist und was die für Heidi Skill Engineers am Start haben. Die Menschen machen Fehler, die Maschinen machen Fehler und am Ende hängt's dran, wie Du vertraust, ne. Da hab ich mal einen Talk drüber gehalten tatsächlich, wie wir Menschen und Maschinen vertrauen. Und da kommt es auch so mit rein und was Du so angesprochen hast, man hat einfach viel mehr Vertrauen zu a aWS und Co, weil das sind halt die anderen alle auch, ne. Und das ist schon eine schwierige Thematik, die ich auch immer wieder treffe in so Gesprächen.
Jan: Na ja, also das das Ironische, das Paradoxe daran ist ja, dass sobald Du mal groß genug bist, dein Ausfall halt auch akzeptabler wird, weil nichts mehr funktioniert. Weißt Du? Wenn wenn dein dein E-Commerce auf AWS und Cloudflare läuft und beide sind irgendwie weg, dann ist es voll egal, weil selbst wenn Du woanders laufen würdest, könntest Du keine Zahlungen entgegennehmen, weil wahrscheinlich PayPal oder Brain Tree oder Apple Pay halt durch Cloudflare geht und so. Also wenn Du dich an den in Anführungszeichen, ne, den richtigen Teil des Internets hängst, ist auch nicht mehr schlimm, wenn Du weg bist, weil der ganze Rest ist dann auch mit weg. So. Und hast Du irgendwie größere Probleme bis dahin noch. Das macht natürlich die Situation nicht besser, aber das ist, glaube ich, so die der Gedankengang bei vielen so. Also wenn wir uns schon an irgendjemanden ketten, dann an den, der irgendwie alles mitnimmt, wenn er wenn er den Bach runtergeht.
Andreas: Und am Ende hängt's da wieder auch an deinem Geschäftsmodell, ne, egal wo Du jetzt bist und was Du machst, selbst wenn da nur deine Payment API nicht geht. Das ist dem für den Kunden draußen ist das Ergebnis das Gleiche, wie wenn da eine ganze Seite nicht geht. Der kann halt nicht kaufen, dass es so der Kundenprozess ist. Ich will 'n Artikel verkaufen, ja? Ich will 'n suchen, ich will 'n finden, ich will 'n Checkout gehen und fertig. So. Und da sind ja so viel, ist mittlerweile so komplex alles eingebaut mit, was weiß ich, Recommedation Engine APIs zu Newsletter, zu Payment, zu Risikomanagementsystems. Es reicht ja immer schon ein Ding in der Kette, wie Du's angesprochen hast, je nachdem, wie das System gebaut ist eben, dass der Kundenprozess nicht funktioniert. Und den dürfen wir, glaub ich, an keiner Stelle ausm Auge verlieren, so.
Jan: Das ist doch ein gutes Schlusswort. Aber immer noch meine letzten 2 Fragen. Dennis, hast Du noch eine Frage? Nein. Wunderbar. Bist Du überzeugt?
Dennis: Also ich ich find's wichtig, darüber nachzudenken und sich das einfach mal vor Augen zu führen, was es bedeuten würde und auch darüber nachzudenken, dass es eine Alternative gibt zu den Hyperscaldern da draußen. Ich bin relativ sicher, dass es für uns weiterhin ganz, ganz sinnvoll scheint, den Weg weiterzugehen, wie wir aktuell tun. Sternchen, ob jetzt ein Anbieter für alles so, kann man wahrscheinlich infrage stellen, aber hat natürlich dann auch irgendwo Vorteile. Aber nee, fand's fand's superspannend, da 'n bisschen Einblicke drin zu haben.
Jan: Also vollkommen richtig. Ich glaub auch nicht, dass das Ziel dieser Folge war, irgendjemanden da draußen zu überzeugen, morgen irgendwie seinen AWS Account zu kündigen und irgendwie alles wieder im Keller selber zu hausten oder wie Du schon sagst, ne, einfach son bisschen die Perspektive dafür zu öffnen, wo kann das sinnvoll sein? Wann sollte man mal darüber nachdenken? Wann sollte man vielleicht auch regelmäßig an welchen Stellen darüber nachdenken? Was könnte das alles bedeuten? Und der ganze Rest ergibt sich dann, glaub ich, zugegebenermaßen organisch daraus. Andreas, hast Du noch irgend eine Frage, bei der Du dir denkst, wieso haben die Jungs mich das nicht gefragt? Ich wollte unbedingt über XYZ reden und keiner hat mich danach gefragt.
Andreas: Nee, der Dennis hat es so nicht beantwortet, ob sie denn ob ihr einen Dashboard habt mit euren Cloud Kosten. Also das würd mich mal noch interessieren, oder wie ist ihr das denn runtergebrochen auf eure auf eure Games? Also könnt ihr das beziffern oder ist das was, was aktuell nicht im Fokus ist, weil's eben funktioniert?
Dennis: Es ist wirklich, ist ganz lustig, weil es war diese Woche Thema oder ich hab's auf diese Woche auf meine Studdulliste geschrieben und es hatte nichts für diese Podcastfolge zu tun. Aber da da steht Serverkosten, Format finden für die Dev Talks, das noch mal Also Johannes das letzte Mal, ich weiß nicht. Also wir haben tatsächlich auch einen Commitment bei Google über 3 Jahre und ich glaub, vor ungefähr anderthalb Jahren das letzte Mal gestartet oder so. Zu dem Zeitpunkt haben wir uns das dann noch mal, ne, detaillierter angeguckt, aber es ist tatsächlich nicht so, dass es jetzt mega im Fokus ist und deswegen so was wie einen Dashboard oder so was existiert. Ich glaube 'n grundsätzliches Gefühl, was wohin geht, ist ist bei uns schon vorhanden, aber dadurch, dass auch nicht der Fokus ist und auch nicht unbedingt sein muss, ist es trotzdem, glaub ich, sinnvoll, ab und zu mal die Perspektive noch mal da drauf zu lenken und zu gucken, okay, haben wir irgendwelche, ne, wo wir einfach Kosten sparen können, wo wir das nicht so machen müssen, wie wir's aktuell tun. Und ja, aber auch grade aus eigenem Interesse parallel hatt ich die Cloud Konsole Nummer aufgemacht und bisschen mich durch den Billing Bereich geklickt so. 'N greller definitiv großer Part bei uns ist tatsächlich der der ganze Teil, ne. Also weil einfach da sehr, sehr viel an Daten passiert und das ein sehr essenzieller und wichtiger Part ist für uns. Also das heißt, ja, 'n relativ großer Batzen, genau, kommt aus dem ganzen Analytics Bereich.
Andreas: Ja. Dann oder Ja. Generell. Okay. Genau. Da gibt's auch wunderbare Alternativen. Ja. Ja. Aber ich ich versteh's voll, dir das geht sehr vielen Firmen wie euch, denk ich. Die sind da. Du machst 3 Klicks und dann landen deine Daten von Google Analytics auch in Big Query, dann hast Du die da für die Marketingeeute. Du kannst die Kampagnen besser schalten. Man muss halt irgendwann mal sagen, na, warum ist das eigentlich so, ne? Und wer hat denn Interesse dran? Ich glaub, bei den Kostenthema ist es eben wichtig, dass man irgendwie 'n Blick drauf hat und dass man Veränderungen sieht, weil häufig drehst Du eine Kleinigkeit in deiner Anwendung und dann passiert irgendwas Krasses an den Kosten. Und das musst Du irgendwie merken, bevor's zu spät ist so. Also oder im im Nutzerverhalten, das reicht ja vielleicht auch schon. Und das ist so, wenn man ein ein Ding jetzt vom Hören der Episode im Kopf behält, dann wär das, denk ich mal, wichtig, sich das anzuschauen, glaub ich.
Jan: Ja. Wunderbar. Wenn wir schon über sinnvolle Alternativen und andere Tools reden, dann ist das vielleicht der richtige Übergang zu unseren. So, liebe Kinder, wer hat denn was mitgebracht?
Dennis: Vorbereitet wie immer hab ich natürlich was. Mhm.
Jan: Dennis Nase wird grad so lang, dass er die Webcam durchquert hat. Okay, dann Dennis fang ich an.
Dennis: Gerne, ich fang an. Genau, wir haben grade bei bei Lotrum oder haben grade, kommt nächste Woche eine AI Week, wo wir uns noch mal als ganzes Unternehmen die Zeit nehmen, einfach dort zu recherchieren und zu gucken. Wenn der Podcast veröffentlicht wird, liegt die dann vermutlich schon hinter uns und ich bin sowieso leider nicht da, wo ich im Urlaub bin, aber in in Vorbereitung dessen. Und im Moment ist ja das ganz große Buzzword, also auch Agenten bauen und ne, auf Konferenzen haben irgendwie alle schon Agenten gebaut und alles Mögliche und wir setzen viel KI ein, auch in der, im vor allen Dingen natürlich im im Dev Bereich, aber irgendwie dacht ich so, okay, son son son Workflow und irgendwas zu haben, Agenten besser, ja, zu kreieren zu können oder so Workflows besser abbilden zu können, muss wahrscheinlich irgendwie was geben. Und Google hat da ja auch, Open Source, relativ groß das Google Agent Development Tool Kit oder nee, ich glaub nur Kit ohne Tool Kit rausgebracht, was eben ermöglicht, mit Code solche Agents zu erstellen und die ganzen Tools anzubinden, die man dann da benutzen möchte. Fand ich grundsätzlich ganz cool. Ist auch, glaub ich, relativ einfach zu bedienen und hat 'n hat 'n gutes Getting gestartet. Ist aber nicht mein.
Jan: Sondern geschrieben.
Dennis: Sondern wenn man's noch haben möchte, gibt es was. Es ist vorher schon häufiger mal irgendwie über meine Bildfläche gekommen. Ich hab's mir aber nie angeguckt. Und zwar NAN ist ein automatisierungs, eine Automatisierungsplattform. Und genau, die Software kann man entweder einfach gehostet von denen nutzen und man kann sie aber auch selbst hosten. Und das Coole daran ist, dass sie halt natürlich jetzt auch, glaub ich, schon länger auf dem AI Hype sind und es dort auch eine gibt. Und das kann man sich halt einfach visuell zusammenklicken, hat dann auch son kleines Chatfenster, das jeden kann halt supereasy, also an dieser an dieser Chat, an dem an der ist zum Beispiel einfach ein son kleiner Pynökel dran, wo man das Modell auswählt. Und man kann halt supereinfach wechseln von 'nem Gemini Modell zu 'nem Open Air Modell, was auch immer man irgendwie dort hat. Man kann unterschiedliche Tools zur Verfügung stehen stellen. Ich hab schon den Eindruck, grade wenn man so was dann 'n bisschen evaluiert und versucht, so simple Dinge erst mal umzusetzen, ist es eben auch was, was relativ zugänglich dann für ist, weil man, ne, dann relativ gutes Interface irgendwie hört. Und so erst mal alles, was ich damit so angetestet hab, jetzt kein kein ewiges Ding, fühlte sich irgendwie recht, recht und modern und cool an. Und also würd ich es deswegen, wenn man sich grade mit irgendwelchen Workflows Prozessen und 'n bisschen AI mit drin beschäftigt, durchaus mal empfehlen und in die Schale, nee, wie nennt man das? Cool, wie auch immer, in die Datenbank werfen.
Jan: Wunderbar. Die, unsere Datenbank, die übrigens nicht bei 'nem Hyperscale läuft, nur das mal gesagt zu haben.
Dennis: Weil, weil?
Jan: Wie weil? Warum das so ist? Ja. Also ehrlicherweise war das ja vor meiner Zeit her, aber also die Programmierer ist ja bei Digital Ocean gehostet. Und ich muss sagen, ich find Digital Ocean auch so den für mich schon seit Jahren eigentlich guten Mittelpunkt zwischen, das skaliert halt ordentlich für dich, aber das ist halt trotzdem noch so simpel, weil Du halt ehrlicherweise auch nicht so viel machen kannst wie bei ABS oder bei Google. Aber wenn Du den einfach nur im Container hinschmeißen willst und Du wirfst 5 Dollar hinterher, dann wird der für dich halt auch deployed. Du kannst ja deine Datenbank einfach zusammenklicken und irgendwie sagen, wie viel RAM und CPU die haben soll. Also Du hast schon genug Freiheit, son bisschen für dich mitzuskalieren, aber Du musst dich, wenn Du's nicht möchtest, halt nicht mit irgendwelchen Security Policies und ne, Konfigurationen und Georegionen und bla bla bla halt allem beschäftigen. Das ist für mich immer noch son bisschen der der Sweet Spot so. Aber persönliche Meinung.
Andreas: Gibt's ganz viele, also in diesem Sweet Spot. Aber Digital Ocean machen wir auch einiges und kann kann ich nachvollziehen. Für N8N kurze Sightnote hatt ich auch im Newsletter paar Mal drin. Es gibt Workflow Automation Templates. Da kannst Du mal reinschauen. Das sind so ganz, ganz viele Beispiele, wo Leute ihre Templates hochladen. Gibt's mittlerweile über 3800, seh ich grade. Also wie mach ich, verknüpfe ich, keine Ahnung. LinkedIn mit Google Drive oder so weit, ist 'n blödes Beispiel, aber da kannst Du wirklich echt so Bin
Jan: mir ziemlich sicher, es gibt Leute, die machen das da draußen LinkedIn angeguckt. Ja.
Andreas: Was weiß ich, da gibt's jetzt, wenn ich mal hier trending sind, was weiß ich, Generate AI Viral Videos zum Beispiel oder Automate Sales Cold Calling. Gut, das find ich jetzt nicht so gut, aber das braucht man nicht noch mehr. Aber das ist wirklich wahnsinnig cool, zu sehen, was da alles geht.
Dennis: Ja. Und das stimmt, das ist auch son Aspekt, den ich den ich mega fand. Die haben irgendwie supercool, dass man das so extern als i-Frame irgendwie einbinden kann, diese Workflows. Und das heißt, in irgendwelchen Supportforen und auf irgendwelchen anderen Webseiten kannst Du halt einfach auch diese Flows finden und die sind halt einfach per Json, denk ich oder was es ist, zu zu exportieren und auch reinzukopieren. Das heißt, auch wenn Du in 'nem völlig anderen Kontext bist, siehst Du sonen Workflow, der interaktiv ist und wo man rumklicken kann. Das haben sie so irgendwie aus, also aus aus Dev Sicht sehr schön gelöst.
Jan: Guerilla Marketing, wo andere Plattformen nutzen, dich son bisschen durchzuschieben. Cool. Andreas, was hast Du für uns dabei?
Andreas: Als Newsletterschreiber empfehl ich euch natürlich einen Newsletter und das wär der Pragmatic Engineer Newsletter von Gerigali Oros. Ich weiß nicht, ob ihr den kennt. Mhm. Der hatte letzte Woche eine Developer Survey drin für da hat er über 3000 Entwickler gefragt. Und es sind ganz, ganz, ganz, ganz viele Themen drin von Cloud über CID Tools oder auch AI Usage zum Beispiel. Fand ich wahnsinnig spannend Und über ein Thema musste ich schmunzeln und das Thema heißt Jenkins. Ich hatte neulich einen Call mit 'nem Kunden potenziell und die nutzen noch Jenkins. Und dann hab ich, ja, musste ich so schmunzeln wie Du jetzt gerade auch. Hab dann gesagt so, na ja, macht das denn Sinn? Findet man dazu noch Sachen, das ist doch alles veraltet im Internet, dann sind auch die ganzen Das ist ja, muss man auch immer dran denken, wenn man heut AI Tools nutzt, macht es Sinn, noch Jenkins zu nutzen, weil die AI wird wahrscheinlich da auch keine vernünftigen Infos dazu haben. Jetzt ratet mal, auf welchem Platz der CICD Tools, ohne die Seite aufzumachen, Jenkins ist. Ich würde sagen, auf 2 oder 3. Dennis?
Dennis: Also wenn Du's wenn Du's so ankündigst, vermute ich auch, leitet sehr hoch.
Andreas: Hab ich falsch angekündigt, Mist. Ja, also GitHub Actions ist vorne, haben wir die 100 Leute abgestimmt. Dann kommt Jenkins auf Platz 2 mit knapp 400 und dann kommt echt sehr weit abgeschlagen, aber auch alles auf gleicher Höhe. Dann GitLabsy, Aircle, Algo und Travis so mit bisschen so 100, 150 Nennungen.
Jan: Travis auch so. Bei Pipelines.
Andreas: Ja, krass, okay. Ja, ja. Und und da hab ich dann wieder gemerkt und das ist son bisschen auch der Grund, warum ich selber Newsletterschreiber bin, man lernt nie aus, egal, was man schon gesehen hat. Und deswegen ist der Break of the date der Pragmatic engineer Newsletter, weil ich jedes Mal überrascht bin, wie krass und tief der in Themen reingeht und diese Umfrage ist auch wirklich super. Und ich pick auch immer Dinge von dem raus und teaser das an bei mir im Newsletter und find das einfach wahnsinnig interessant, was man da alles lernen kann. Das hat auch ganz viel zu AI Themen oder zu Remote Work oder zu der AI Bubble, wie er's ja manchmal nennt. Und deswegen wäre das mein Pick of the day. Cool.
Jan: Wunderbar. Notted. Landet übrigens auch immer in meiner Inbox. Aber ich muss ehrlich sagen, dass ich mittlerweile so viele Newsletter abonniert hab, dass die alle in so eine Newsletterbox weggefiltert werden und ich dann immer nur so, wenn ich mal eine Stunde oder eine halbe Stunde irgendwie Lücke hab, ne, so wie man halt sone Zeitung durchblättert, so geh ich dann durch meine Newsletter Inbox irgendwie durch. Das ist son bisschen das Problem an der Sache. Okay. Ich hab noch 'n Pick, der wo ich dachte, der hat eigentlich gar nichts so mit der Folge zu tun, aber vielleicht hat er auf der Metafolge Metaebene was mit der Folge zu tun. Und zwar hab ich hier, dieses Notebook ist mein Pick, so, ein ein Framework, 12 Notebook. So, und wer Framework vielleicht kennt, der weiß, dass so der der Pitch von Framework ist, dass sie im Prinzip weg von diesen diesen Senderlog in Geräten sozusagen wollen und wieder Notebooks und Desktops machen, wo Du halt deinen RAM austauschen kannst, dein Display reparieren kannst. Die liefern dir Ersatzteile für alles. Also hast wieder son bisschen mehr Kontrolle über dein Metall, son son bisschen das analog zu der Folge, die wir die wir heute hatten. Wer sich zurückerinnert, ich hatte, glaub ich, in der Weihnachtsfolge vor 'nem Jahr oder vor anderthalb Jahren mittlerweile so gesagt so, hey, ich freu mich auf mein neues Framework Laptop, auf
Dennis: mein hast Du grad sagen, hast Du das nicht schon, war das nicht schon 'n Pick oder war das
Jan: Nein, das war das 16 Zoll Laptop, was hier mein mein Desktop ersetzt hat. Das steht hier neben mir. Das seht ihr jetzt leider nicht mit der mit der Webcam. Und dieses Kleine hab ich so als so für Familie und aufm Sofa und und weißte, wenn Du halt mal irgendwie was was brauchst, was Du jemanden so in die Hand drücken kannst, auch son 2 in 1 Gerät, kann man auch als Tablet irgendwie jemandem geben. Und das ist jetzt gekommen nach langer Pre order Phase und ich hab's vorgestern zusammengeschraubt und das war für mich das das coole Erlebnis an diesen Frameworkgeräten einfach, Du bekommst es so in Einzelteilen geliefert und schreibst es dann zusammen. Und allein, dass Du wieder so dein dein Laptop mal so selber zusammengeschraubt hast und deinen deinen SSD da reinhast und deinen Akku rein, dein Keyboard drauf und deinen RAM da rein und so alles zusammengeschraubt ist. Das ist son sehr befriedigendes Gefühl irgendwie und gibt einem noch mal son anderes Gefühl von Ownership über son Gerät. Und ehrlicherweise auch son besseres Gefühl im Umgang, weil man sich denkt, na egal, was kaputtgeht, ich kann's halt im Zweifelsfall auch wieder reparieren. Passt man ehrlicherweise dann son bisschen weniger gut drauf auf wie hier auf mein MacBook, wo ich im Prinzip, nicht, immer in 'ner dicken Hülle und in 'nem dick gepolsterten Rucksack und am besten im Auto auch immer angeschnallt bei mir mein MacBook und so, ja. Ihr lacht, ist wirklich so. Mein MacBook ist immer angeschnallt im Auto, so. Und deswegen ist das mein, mal son bisschen was anderes zu machen im Hardwarebereich.
Dennis: Sehr gut. Ja.
Jan: Und dann empfehl ich allen da draußen, Macbooks gehören angeschnallt, wenn sie im Auto mitfahren. Die sind wichtig und teuer und wir haben sie alle sehr lieb und deshalb sollten wir sie gut behandeln.
Andreas: Was kostet das? Hast Du jetzt nicht erzählt, oder?
Jan: Das das Framework, oh Gott, das gibt's in verschiedenen Konfigurationen. Das fängt so bei, ich glaub, 5 oder 600 Dollar an. Also es ist auch fairer Preis, so.
Andreas: Auf jeden Fall, ja.
Jan: Cool, cool. Dann sind wir damit durch. Danke Andreas, dass Du dir die Zeit genommen hast. Es war 'n cooles Gespräch, fand's superinteressant, da auch mal son bisschen mehr gechallenged zu werden und son bisschen da darüber nachzudenken, den Status quo für viele vielleicht auch mal zu hinterfragen. Ich bin gespannt, bei wem das vielleicht den einen oder anderen Stein ins Rollen bringt da draußen, so. Wenn das für euch der Fall war, wenn es euch überzeugt hat oder vielleicht überhaupt gar nicht überzeugt hat, dann könnt ihr uns wie immer gerne schreiben an Podcast at Programmier Punkt bar oder ihr hinterlasst uns einen Kommentar auf Social Media, auf Youtube, auf Spotify, wo auch immer. Wir lesen alles mit und freuen uns immer, wenn wir noch was von euch hören.
Dennis: Auf Discord, das musst Du natürlich noch ergänzen.
Jan: Auf der Discord, ja. Oh mein Gott, ja. Wenn ihr diese Diskussion weiterführen wollt, dann unbedingt unseren Discord Server jo und ich hab's in der letzten Folge auch nicht gesagt. Nicht nur, dass wir nicht den Aufnahmeknopf gedrückt haben, wir haben auch nicht auf Discord hingewiesen. Das war
Andreas: Siehst Du?
Jan: Richtig schwierig.
Dennis: Heute war alles richtig gemacht.
Jan: Heute war alles richtig gemacht. Wunderbar. Dann 1000 Dank euch und wir hören uns spätestens in 2 Wochen zum nächsten Deep Dive. Bis dann. Vielen Dank, Andreas.
Andreas: Danke euch auch.
Dennis: Tschau. Tschau.

Cloud-Exit mit Andreas Lehr

Shownotes

Picks of the Day

Framework Laptop 12

The Pragmatic Engineer

n8n

Speaker Info

Andreas Lehr