#43 Cloud vs. On-Premise: Die Entscheidungshilfe

Wann ist die Cloud das richtige für dich und deine Applikation? Oder doch lieber alles selbst hosten?

Die Cloud wird oft als "die Lösung" für all deine Probleme beschrieben. Sie ist günstig, man benötigt weniger Personen für den operativen Betrieb, alle Services sind gemanagt und serverless und alle anderen Probleme hat man sowieso nur On-Premise. Sind damit On-Premise Datacenter und Selfhosting ausgestorben und sollten gemieden werden? Oder gibt es sogar Szenarien, wo On-Premise sogar große Vorteile hat? In dieser Episode geht es um diese Frage: Wann ist die Cloud und wann On-Premise / die eigenen Server für dich die bessere Wahl? Wir diskutieren über diese Frage anhand eines Blogposts über eine Migration aus der Cloud von 37Signal's Produkt "Hey.com".

Bonus: Was der Produktlebenszyklus vom VW Golf mit der Cloud zu tun hat und warum ein Raid 1 kein Backup ist.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Sprungmarken

(00:00:00) Intro

(00:00:54) Return to Monkey Island für Linux

(00:02:59) Der letzte Service, der von Google wieder eingestellt wurde: Google Stadia (Cloud Gaming)

(00:04:08) Das heutige Thema: Migration aus der Cloud hin zu On-Premise

(00:06:20) Warum 37Signal sich mit ihrem Service HEY aus der Cloud zurück zieht

(00:13:13) Warum ist eine Migration aus der Cloud ein Thema für den Podcast und die Ansichten von Basecamp/37Signals

(00:17:06) Was ist eigentlich die Cloud bzw. was heißt "die Cloud"? Und wo ist die Abgrenzung zu "Cloud Native"?

(00:26:19) Verlernen wir, wie Server geracked und Datacenter betrieben werden, wenn wir immer nur die Cloud nutzen?

(00:31:44) Was kostet die Cloud vs. On-Premise und wann rentiert sich welches Modell? Total Costs of Ownership, Hardware und die Größe des Operations-Team

(00:51:01) War die Migration von On-Premise in die Cloud bei trivago eine gute und sinnvolle Entscheidung?

(00:58:00) In welchem Setup würden wir die Cloud und wann On-Premise wählen?

(01:06:59) Angst um den eigenen Job bei einer Cloud-Migration

(01:09:33) Zusammenfassung und Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

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

Transkript

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

Andy Grunwald (00:00:04 - 00:01:16)

Willkommen zu einer neuen Episode vom Engineering-Kiosk. Heute geht es wieder um das Thema Cloud. Im Speziellen um die Frage, wann ist die Cloud und wann On-Premise, also der Betrieb von eigenen Servern, für dich und deine Applikation die bessere Wahl? Wir diskutieren diese Frage anhand eines Blogposts von dem Ruby & Whales Gründer David Heinemeier-Hansen, worin erklärt, warum er mit seinen Produkten Basecamp und Hey! einem E-Mail-Service die Cloud verlässt und wieder zum Selbsthosting via On-Premise-Data-Centern wechselt. Bevor es losgeht, noch eine kleine Bitte. Falls ihr uns supporten wollt, lasst uns doch bitte eine Bewertung auf eurem Podcast-Service eurer Wahl da und empfiehlt diesen Podcast euren Kollegen und Kolleginnen sowie Freunden. Vielen Dank dafür und nun viel Spaß! In der letzten Episode haben wir über Lexapasa und Counter-Strike gesprochen. Da ging es natürlich auch ein bisschen um Computerspiel und ich habe mich gefragt, wie war eigentlich deine Historie zu Computerspielen und inzwischen habe ich gelesen, es gibt Monkey Island, das neue Monkey Island, nun für Linux. Meine Frage, müssen wir den Podcast jetzt stoppen, weil du mit Rätsellösen beschäftigt bist?

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

Ja, wir haben einfach die besten Hörer, die uns auf sowas hinweisen. Und ein Hörer hat mir geschrieben, es gibt es jetzt auf Linux. Ist glaube ich wirklich ein paar Tage alt. Wir haben ja schon Steam installiert auf Linux, aber wir haben es noch nicht geschafft, das Spiel zu installieren. Aber höchstwahrscheinlich nach dieser Episode schauen wir mal, ob noch irgendwelche anderen Episoden folgen werden.

Andy Grunwald (00:01:34 - 00:02:04)

Was mich natürlich jetzt auch wirklich dringend interessiert, du hast ja jetzt auch nicht mehr den modernsten Computer. Und wir haben uns ja auch in der letzten Episode ein bisschen über meinen Windows Computer unterhalten, dass der 10 oder 12 Jahre alt ist und die Grafikkarte auch nicht mehr mitmachen. Und da sagst du, ja Monkey Island läuft bestimmt. Das würde mich mal interessieren. Wenn du es mal installierst, lass uns doch mal bitte wissen, auch wenn du die Grafikeinstellungen ganz nach oben drehst, da frage ich mich gerade, wie sieht das eigentlich bei Monkey Island aus, aber ob das dann ruckelt. Und da meine nächste Frage, kann Monkey Island überhaupt ruckeln, weil es ist ja glaube ich nur so 2D und solche Geschichten.

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

Ich werde auf jeden Fall berichten in der nächsten Episode. Aber ich hab schon ein Testspiel gespielt, das war so ein Jump and Run. Aber der Hauptcharakter hat ungefähr vier Pixel und die ganze Welt hat 100 Pixel. Das ist aber flüssig gelaufen.

Andy Grunwald (00:02:17 - 00:02:23)

Hat das neue Monkey Island auch in irgendeiner Art und Weise so einen Multiplayer-Modus, dass wir dann mit anderen Leuten zusammenspielen, oder ist das wirklich nur Singleplayer?

Wolfi Gassler (00:02:24 - 00:02:29)

Ist glaube ich nur Singleplayer. Ist aber der schnell verkaufenste Monkey Island bisher, habe ich gelesen.

Andy Grunwald (00:02:29 - 00:02:39)

Denkst du die meisten Neukäufer kaufen das Spiel, auch wenn sie es früher nie gespielt haben, weil jeder ältere Person davon redet?

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

Ey, sag nicht alt zu mir.

Andy Grunwald (00:02:41 - 00:02:49)

Also wenn du heute irgendjemand aus der 10. Klasse auf Monkey Island ansprichst, bin ich mir nicht sicher, ob die Person wirklich weiß, was wir meinen.

Wolfi Gassler (00:02:49 - 00:02:54)

Ja, wer hat denn schon den originalen Top Gun Film gesehen? Trotzdem schlagt der irgendwie einen der Neue.

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

Ist aber auch grandios, also falls du ihn noch nicht gesehen hast.

Wolfi Gassler (00:02:57 - 00:02:58)

Nein, natürlich nicht.

Andy Grunwald (00:02:58 - 00:03:04)

Interessiert mich auch wenig. Naja, okay, Spiele und Multiplayer-Modus.

Wolfi Gassler (00:03:04 - 00:03:08)

Jetzt bin ich gespannt, was deine Überleitung ist auf das heutige Thema.

Andy Grunwald (00:03:08 - 00:03:19)

Was war der letzte Service, der von Google wieder eingestellt wurde? Von der Google Cloud. Weil Google Cloud ist ja bekannt dafür, dass sie Services launchen und nach ein, zwei, drei N-Jahren wieder mit einer 30-Tage-Notice wieder einstellen.

Wolfi Gassler (00:03:19 - 00:03:29)

Keine Ahnung, ich kann mich nur erinnern, dass sie Google Inbox irgendwann eingestellt haben. Das war ein großer Aufschrei. Das war das Letzte, was ich im Kopf hab. Ist aber kein GCP-Service. Aber du wirst es mir sicher gleich sagen.

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

Google Inbox wurde 2019 eingestellt, Wolfgang.

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

Der war ja eh gerade kürzlich dran.

Andy Grunwald (00:03:35 - 00:03:40)

Machen wir ganz einfach die Verbindung. Wir haben gerade über Computerspiele gesprochen. Heute sprechen wir über das Thema Cloud.

Wolfi Gassler (00:03:40 - 00:03:42)

Moment, was ist jetzt dieses Service, was da eingestellt worden ist?

Andy Grunwald (00:03:42 - 00:03:58)

Sag ich dir jetzt. Google Stadia. Das Cloud Gaming. Was? Google Stadia. Google Stadia war Cloud-Gaming, wo das eigentliche Spiel gar nicht bei dir lokal läuft, sondern in der Cloud. Und die Bilder und so weiter werden nur zu dir runtergestreamt.

Wolfi Gassler (00:03:59 - 00:04:09)

Ah, GeForce hat auch so ein Service. Das hab ich mir sogar angeschaut, weil ich gedacht hab, vielleicht kann ich darüber Monkey Island spielen. Hat aber nicht so funktioniert, wie ich das gelesen hab.

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

Ist jetzt eh vorbei, wurde eingestellt.

Wolfi Gassler (00:04:12 - 00:04:19)

Das thema cloud heute und zwar aus einem ganz speziellen anlass und zwar andy du hast mir auch ganz nervös schon.

Andy Grunwald (00:04:19 - 00:04:33)

Geschickt den artikel wir haben mal wieder eine firma die sehr laut bekannt gegeben hat dass sie der cloud den rücken kehren wird und sie ist natürlich in der industrie mal wieder dieser artikel ist wieder eingeschlagen wie als hätten wir eine.

Wolfi Gassler (00:04:33 - 00:05:49)

Zweite erde entdeckt Und zwar ist das 37signals. Die Firma kennen jetzt vielleicht nicht alle, aber wahrscheinlich kennen viele die Produkte von denen. Und die bekanntesten Produkte sind einerseits Basecamp, diese Projektmanagement-Suite. Und das zweite jüngere Service, das extrem bekannt ist, ist Hey, das E-Mail-Service. Also die haben, wie sie es nennen, E-Mails neu erfunden, neu gedacht. Und man muss ihnen das lassen, also sie haben da schon einiges geändert und es ist zwar im Hintergrund E-Mail, aber die Oberfläche als Frontend ist schon was ganz was Neues, wie man mit E-Mails umgeht, wie man sie strukturiert, wie man damit arbeitet. Also da sind sie eigentlich auch sehr bekannt in der Szene und die zwei Herren, die zwei Gründer Jason Fried und David Heine Meyer Hansen besser bekannt als THH, die haben auch einige Bücher geschrieben und sind daher eigentlich sehr bekannt, die haben auch ein Buch remote zum Beispiel geschrieben vor Jahren schon über remote work, das sehr eingeschlagen hat, auch wie sie Projekte planen, das rework Buch, ist eigentlich sehr bekannt. Also die sind in der Szene sehr bekannt und haben das Marketing eigentlich sehr gut drauf, wenn es darum geht zu zeigen, dass sie einen sehr, sehr neuen Weg gehen. Und jetzt haben sie gezeigt, zumindest behaupten sie das, dass sie einen sehr, sehr neuen Weg gehen und wieder rausgehen aus der Cloud.

Andy Grunwald (00:05:49 - 00:06:10)

Naja, also ich würde jetzt mal nicht sagen, dass Jason Freed und DHH David Heinemeier-Hansen bekannt sind durch ihre Firma und durch ihre Bücher, weil DHH ist ja eigentlich bekannt als Creator von Ruby on Rails, dem Rails-Framework. Also ich glaube schon, dass Basecamp ohne.

Wolfi Gassler (00:06:10 - 00:06:10)

DHH.

Andy Grunwald (00:06:12 - 00:06:23)

Nicht so bekannt wäre. Weil soviel ich weiß wurde Ruby on Rails als Seitenprodukt von Basecamp selbst. Von dem Produkt ist das da so ein bisschen rausgepurzelt und darüber haben die halt ihre Bekanntheit.

Wolfi Gassler (00:06:24 - 00:06:25)

Okay, fair point.

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

Kommen wir zur News der Woche. Gib uns doch mal einen Abriss. Was ist da passiert? Was haben die announced? Warum haben sie überhaupt announced? Und um was geht es da eigentlich?

Wolfi Gassler (00:06:35 - 00:07:56)

Ja, sie haben das auch marketingtechnisch sehr gut gemacht. Sie haben da einen kleinen Blogpost released, ganz klein, also war das nur so eine kleine Entscheidung. Und dann haben sie so Podcast Episode noch rausgebracht. Wir verlinken das natürlich alles in den Shownotes. Und dann ist so das Ganze größer geworden, ist diskutiert worden auf Hacker News und es ist dann so ziemlich explodiert und sie haben das auch immer so geframed, als war das nur so eine kleine Entscheidung und jetzt ist aber die Industrie aufgesprungen auf diese Entscheidung. Und diese Entscheidung, die sie getroffen haben, war eigentlich, dass sie wieder raus aus der Cloud gehen und zurück auf On-Prem, also in ein Datacenter. Und sie haben das auch gut argumentiert und sehr viele Argumente gebracht. Und das Hauptargument war eigentlich, dass sie mit ihrer Größe, also sie haben so ungefähr 80 Leute aktuell und 10 Leute in einem Ops-Team mit ungefähr 100.000 Kunden und sie haben einen sehr konstanten Load. dadurch mit ihren Produkten, mit dem Hey-Email-Service und dem Basecamp, also sie wissen ziemlich genau, was sie brauchen. Sie haben da jetzt keine Spikes auf irgendeinem Black Friday wie Amazon oder so, wo dann extrem viele User drauf zugreifen, weil sie halt ein System haben, was eigentlich tagtäglich verwendet wird, sowohl E-Mail wie auch dieses Projektmanagement-Tool Basecamp. Daher können sie das alles sehr gut abschätzen, sehr gut kalkulieren und haben argumentiert, dass das für sie wesentlich besser ist, on-prem zu sein in einem Datacenter.

Andy Grunwald (00:07:56 - 00:08:05)

Mit konstantem load meinst du stabilem load oder dass die ihre traffic patterns kennen oder was meinst du mit konstantem load.

Wolfi Gassler (00:08:05 - 00:08:39)

Also so wie es dhh erklärt hat haben die einfach eigentlichen ziemlich konstanten load gar keine patterns in dem sinne weil die weltweit unterwegs sind und bei email natürlich jeder greift regelmäßig auf sein email postfach zu es gibt nicht irgendwie ein spike oder so dass plötzlich, die User irgendwie dreimal so oft auf ihr E-Mail-Postfach zugreifen. Also das ist ja alles sehr konstant. Dasselbe mit Basecamp Projektmanagement. Das hast du immer. Das wird immer verwendet. Da gibt es auch nicht extreme Spikes. Und auch mit der Useranzahl. Es kommt nicht vor, dass jetzt plötzlich 50 Prozent mehr User oder so sind von einem Tag auf den anderen.

Andy Grunwald (00:08:39 - 00:08:46)

Und wenn du von Cloud sprichst, weißt du, bei welchem Anbieter die waren und welche Services die auch genutzt haben?

Wolfi Gassler (00:08:46 - 00:09:16)

Also Services weiß ich jetzt nicht genau. So wie das geklungen hat, haben sie eher die Basis-Services verwendet. Also sowas wie Compute Engines oder einfach virtuelle Maschinen, vielleicht mal eine Datenbank. Und die haben sie in AWS und GCP verwendet. Sie haben auch manche Produkte immer noch im Data Center gehabt, die alten Basecamp-Versionen zum Beispiel. Also sie waren immer parallel unterwegs in mehreren Clouds on-prem und haben so natürlich auch eine gute Übersicht gehabt, wo sie welche Kosten haben, was wie funktioniert.

Andy Grunwald (00:09:16 - 00:09:28)

Und waren die monatlichen oder jährlichen Kosten der Haupttreiber? Also, was war jetzt der ausschlaggebende Punkt? Oder war das eine Kombination aus allem? Also, ging's da rein ums Geld? Oder weswegen?

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

Also, die Kosten waren natürlich ein großer Punkt. Sie haben drei Millionen Cloud-Kosten pro Jahr. Und alleine die Datenbank beziehungsweise die Suche in der Datenbank frisst ungefähr 600.000 Dollar pro Jahr. Und sie haben eben gemeint, dass sie ungefähr auf 40 bis 50 Prozent runterkommen, wenn sie wieder on-prem in ihrem Datacenter das Ganze hosten. Also der Kostenfaktor war natürlich ein großer Punkt, aber sie haben auch noch andere Argumente erwähnt, zum Beispiel die ganze moralische Seite. Ich nenne sie mal moralische Seite. Zum Beispiel, wenn man den Umweltaspekt beachtet, dadurch natürlich auch vielleicht Einsparungen hat, wenn man die Hardware länger verwendet, dass man weniger Hardware produzieren muss, wenn man die länger ausnützt. Sie haben da gesprochen von teilweise bis zu acht Jahren oder so, wie sie kalkulieren mit der Hardware. Aber natürlich auch, dass man zum Beispiel das lokale Datacenter unterstützt, lokale, kleinere Firmen, Firmen, die ungefähr die Größe haben von ihnen selbst, dass man da einfach mit guten Partnern zusammenarbeitet und nicht auf die Großen setzt, dass man halt die Großen unterstützt, die noch größer werden, sondern dass man da auf selbem Level arbeitet. Und ein Argument, das ich natürlich schon gut verstehen kann, ist, wo sie gesagt haben, der Service ist auf der Ebene viel, viel besser. Weil wenn du so ein kleines Datacenter hast, wo du vielleicht sogar der größte Kunde bist oder ein großer Kunde, dann hast du natürlich ganz einen anderen Support. Du rufst dort an, hast du sofort jemand an der Leitung, als wenn du jetzt als Basecamp Firma bei Google anrufst und da mal nach irgendwas fragst oder EWS. Und die Erfahrung habe ich schon selber auch gemacht, dass das durchaus sehr hart sein kann und viele Tage dauert, wenn du dann kein extrem großer Player bist.

Andy Grunwald (00:11:11 - 00:11:27)

Haben wir irgendwie ein paar Eckdaten über diese Applikation? Hey, also wie viel Kunden die hat, wie viel Storage, wie viel Server, also irgendwie mal ein paar Eckdaten, wie viel Cloud-Ressourcen eigentlich diese Hey-Applikation verbraucht.

Wolfi Gassler (00:11:27 - 00:12:11)

Also ich habe natürlich keine Details dazu, aber was sie zum Beispiel veröffentlicht haben ist, dass sie am Anfang in recht kurzer Zeit zum Beispiel für das Hey-E-Mail 300.000 User bekommen haben. Das ist ja erst kürzlich gelauncht worden und sie haben in den ersten sechs Monaten glaube ich war das 300.000 User bekommen. Basecamp hat natürlich sicher weniger User, weil es ja ein klassisches B2B-Produkt ist. Aber sie müssen natürlich schon ihren Service weltweit anbieten. Sie haben das natürlich in mehreren Zonen, damit es irgendwie stabil läuft und ausfallsicher ist. Aber es ist natürlich jetzt kein Amazon oder ein richtig großes Produkt. Aber es sind schon einige hunderttausend User auf diesen Produkten drauf und die wirklich regelmäßig zugreifen.

Andy Grunwald (00:12:11 - 00:12:22)

Okay, nur um das klarzustellen, weil am Anfang wir über konstanten Load gesprochen haben, Als der Service gelauncht wurde, hatten die anscheinend einen sehr großen Peak, ist das richtig?

Wolfi Gassler (00:12:22 - 00:13:02)

Genau, also das wurde auch von ihnen erwähnt, dass zum Beispiel ihr Start mit Hey sehr schwierig gewesen wäre im Datacenter, weil sie mit 30.000 Usern gerechnet. im ersten halben Jahr und sie haben dann 300.000 User. Ich glaube sogar, es waren sogar nur drei Monate, in den ersten drei Monaten sogar 300.000 User gehabt. Also das war schon ein ordentlicher Spike und da haben sie zugegeben, auch dass natürlich die Cloud dann sehr angenehm war für so einen Start und dass sie da hochskalieren können, weil das im Data Center natürlich schwieriger ist, weil du kannst nicht innerhalb von ein paar Wochen irgendwie deine geplanten Ressourcen verdoppeln, verdreifachen, verzehnfachen in dem Fall vielleicht sogar. Also das ist natürlich schon dann eine Herausforderung.

Andy Grunwald (00:13:02 - 00:13:17)

Okay, wir haben da jetzt eine Internetfirma, die hat announced, wir haben alle Vorteile der Cloud genutzt, als wir das gelauncht haben und jetzt ziehen wir uns wieder zurück aus der Cloud. Und warum ist das jetzt hier ein Thema im Podcast, Wolfgang? Warum möchtest du da mit mir darüber sprechen? Was ist daran so besonders?

Wolfi Gassler (00:13:17 - 00:14:00)

Ja, hauptsächlich war das ja in der letzten Folge, Also nicht in der letzten Folge, sondern in der Folge 34. Wie Cloudy bist du? Da haben wir über Cloud gesprochen und ihr habt da ja auch einen Artikel zitiert, der irgendwie gemeint hat, dass man mit einem Server eigentlich sehr viel machen kann und vielleicht gar nicht diese ganzen Cloud-Services braucht. Du hast mir da ja sehr stark dagegen gesprochen. Und jetzt habe ich endlich eine Firma gefunden, die du schätzt und die dir jetzt auch erklärt, dass wir alle aus der Cloud raus müssen. Jetzt hab ich gleich noch viel mehr Feinde. Ich hab damals schon sehr viele Rückmeldungen bekommen, ich bin zu cloudfeindlich. Ich hab auch Rückmeldungen bekommen, ich bin zu cloudfreundlich. Ich versteh's eh nicht ganz, aber jetzt hast du wenigstens mal eine große Firma, die dir erklärt, Andi, du als Cloud-Supporter, dass Cloud gar nicht so toll ist.

Andy Grunwald (00:14:00 - 00:14:07)

Du sagtest grade, dass ich diese Firma sehr schätze. Das ist ein bisschen weit gefasst, glaub ich. Was ich an ... Komm, Andi, du.

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

Bist ja ein Fanboy von Basecamp und von DHH.

Andy Grunwald (00:14:11 - 00:15:32)

Also ich muss zugeben, ich habe mal ganz kurz Basecamp verwendet und bin not amused über die Software, weil ich finde sie einfach, sie ist glaube ich nicht für mich. Ich habe mich noch nie bei Hey! diesem E-Mail-Service registriert. Ich finde die Ansichten von den beiden sehr interessant und ich finde die Firmenkultur, von Basecamp bis auf ein paar Dinge sehr sehr löblich, primär aus dem Grund, dass die beiden Gründer nicht auf jeden Hype aufspringen und ziemlich vieles sehr gut durchdenken und die Firma explizit nicht so aufgebaut ist auf Gewachstum, Skalierung und was weiß ich nicht, sondern Ich habe das Gefühl, dass man Basecamp oder 37signals in Deutschland als gesunden Mittelstand bezeichnen würde. Die haben einfach ein gutes solides Business, wo alle Leute sehr gut von bezahlt werden können, haben keine Ambitionen 10.000 Mitarbeiter zu haben. Und einfach eine tolle Zeit zu haben, Remote First, da waren die am Anfang sehr, sehr bekannt für, dass sie sehr, sehr früh auf weltweites Arbeiten gesetzt haben. Und ich denke schon, man kann die beiden Gründe, aber auch die Experimentierplattformen, beziehungsweise den Spielplatz, und zwar ihre Firma, schon zusprechen, dass sie vielleicht sogar kleine Sword Leader sind.

Wolfi Gassler (00:15:32 - 00:16:02)

Auf jeden Fall ist es sogar, wie du richtig sagst, eine Firma, die sich gegen das Wachstum wehrt. Die haben Produkte wieder eingestampft, weil sie einfach gesagt haben, wir wollen in der Größe bleiben, wir wollen nicht zu stark wachsen und wir wollen das, was wir machen, aber dafür sehr, sehr gut machen. Also es ist eigentlich eine sehr interessante Herangehensweise. Sie sind immer wieder in den Medien, spielen das aber auch sehr gut, auch teilweise negativ. Sie haben einen ziemlichen Einbruch mal kürzlich gehabt, wo sie dann Politikdiskussionen innerhalb ihrer Firma verboten haben.

Andy Grunwald (00:16:02 - 00:16:40)

Und genau das ist dieser Bereich, wo ich sage, gehen sie vielleicht nicht ein bisschen zu weit. Auf jeden Fall, sie haben ein sehr lautes Sprachrohr auf jeden Fall und ziemlich viele Leute hören denen auch zu und das tue ich auch. Manchmal springen sie ein bisschen über die Stränge, und ich denke auch, dass ihre kontroversen, harten Meinungen, und die ist halt primär gegen den Strom zu schwimmen, dass dieses auch effizient als Marketing genutzt wird. Ja, da muss man dann ein bisschen mal mit beiden Augen draufgucken und ein bisschen evaluieren und vielleicht nicht immer, yo, das, was D. H. H. und Jason Fried sagen, ist immer richtig.

Wolfi Gassler (00:16:41 - 00:16:47)

Deswegen gibt es ja uns. Und darum wollen wir das ja jetzt mal auseinander sezieren, würde ich fast sagen.

Andy Grunwald (00:16:47 - 00:16:49)

Im Pott sagen wir auseinander klamüsern.

Wolfi Gassler (00:16:49 - 00:16:51)

Sezieren, Andi, sezieren.

Andy Grunwald (00:16:51 - 00:16:53)

Kennst du das Wort klamüsern?

Wolfi Gassler (00:16:53 - 00:16:58)

Ja, natürlich. Ist irgendwas, es kommt von Klamydien oder so, oder?

Andy Grunwald (00:16:58 - 00:17:06)

Glaub ich jetzt nicht, aber ... Okay, dann fangen wir an mit deinem Seziermesser. Welcher Punkt ... Möchtest du als erstes...

Wolfi Gassler (00:17:07 - 00:17:26)

Ja, vielleicht fangen wir mal an. Was mich persönlich immer so stört bei diesen Artikeln, ist, dass man über die Cloud spricht. Und es gibt eigentlich nicht die Cloud, weil was ist die Cloud überhaupt? Es gibt so viele Services in der Cloud und meiner Meinung nach muss man das ein bisschen genauer definieren, was man denn wirklich selber unter Cloud versteht.

Andy Grunwald (00:17:26 - 00:19:38)

Also viele Leute sagen, es gibt keine Cloud, es gibt nur von jemand anders die Computer. Was ja auch stimmt. Eigentlich fasst es das zusammen. Das bedeutet eigentlich nur, ich habe keine eigenen Server, ich habe keine eigenen Computer, wo ich meine Infrastruktur auflaufen lasse, sondern ich miete mir sie eigentlich von jemand anders. Und jemand anders ist dann eben In der Umgangssprache oftige die großen drei, Google Cloud Platform, in Kürze GCP, Amazon Web Services, in Kürze AWS oder Microsoft Azure oder Azure. Es gibt natürlich auch noch ganz andere Cloud Provider. Hier in Deutschland ist sehr groß die Hetzener Cloud, in Frankreich und sehr datenschutzgetrieben OVH. Dann gibt es aber noch den amerikanischen Billig-Cloud-Anbieter DigitalOcean. Mit Billig meine ich nicht Billig gleich schlecht, sondern Billig gleich günstig. Dann gibt es aber noch sowas etwas Unbekannteres wie UpCloud oder Vultr oder seit gar nicht so langer Zeit gibt es auch Stackit, das ist die umgangssprachliche Lidl Cloud, wird nur Lidl Cloud genannt, weil der Schwarzkonzern, die Schwarzgruppe dahinter steckt und dass Lidl eine der Firmen von der Schwarzgruppe ist, die dann auf ihre eigene Cloud Service, was von der Subfirma Stackit angeboten wird, migriert haben, beziehungsweise gerade dabei sind. Kurzum, man mietet also fremde Server und auf diesen Servern wird dann oft nochmal Zusatzangebot betrieben. Zusatzangebot könnte jetzt sein sowas wie Function as a Service, das ist jetzt ganz groß bei Amazon, nennt sich das Lambdas, bei Google heißt das Cloud Functions oder man betreibt eine Datenbank. Also das ist so eigentlich für mich die Cloud. Und jetzt gibt es natürlich, was man da mietet, verschiedene Möglichkeiten. Auf der einen Seite kann man ganz klassisch Hardware mieten. Es gibt auch wirklich, dass du Bare Metal mietest. Also wirklich einen Server, der irgendwo in einem Rack sitzt. Die Masse ist jedoch Virtualisierung. Das bedeutet, du mietest dir eine virtuelle Maschine und teilst dann einen physischen Host, einen physischen Server mit N Leuten und sagst, okay, du kriegst nur eine CPU zugewiesen und so und so viel Gebiobeit RAM und so und so viel Storage.

Wolfi Gassler (00:19:38 - 00:20:22)

Aber eben, da fängt es schon mal an, wenn du sagst, okay, man mietet nur die Hardware von anderen, die Computer von anderen. Das ist zum Beispiel das, was Basecamp ja eigentlich dann schlussendlich auch macht. Die kaufen natürlich Server über die Datacenters. Das wird für sie gerackt, das wird für sie angeschlossen. Und sie fahren da natürlich nie persönlich hin und racken da selber die Server oder sowas. Also man könnte sogar argumentieren, wo ist jetzt der Unterschied, ob jetzt bei Hetzner irgendwie online einen physikalischen Serverbuch oder das in meinem kleineren Datacenter mache, das in der Nähe ist und mit dem ich einen guten Draht habe. Also auch da ist die Frage, geht das dann schon in Richtung Cloud oder ist das On-Prem? Also auch da sind die Grenzen schon verschwimmend, meiner Meinung nach.

Andy Grunwald (00:20:23 - 00:20:30)

Denke ich überhaupt nicht, weil der große Innovationstreiber der Cloud ist ja unter anderem Minuten- oder sekundenbasierte Abrechnung.

Wolfi Gassler (00:20:30 - 00:20:38)

Okay, das ist ein fairer Punkt. Also das wäre dann deine Definition von Cloud, dass du diese sekundengenaue Abrechnung hast.

Andy Grunwald (00:20:38 - 00:21:51)

Ja, vielleicht würde ich es nicht auf Sekunden pinnen, aber ich würde sagen, dass die Vertragslaufzeiten deutlich flexibler sind und im klassischen Software-as-a-Service-Modell sehr nahe kommen. sagt, okay, wenn ich mir jetzt nur einen Server nehme, kann ich das auf Minuten basiert runterrechnen? Vielleicht macht man, vielleicht sind die Vertragslaufzeiten sogar monatlich, ja? Wo man natürlich ein bisschen aufpassen muss, ist bei, wenn wir jetzt sagen, okay, das ist der Riesenvorteil von irgendeiner Cloud, wenn du natürlich über einen Jahresumsatz von siebenstellig oder schon hohe sechsstellig, das bedeutet 900.000, eine Million oder mehr redest, dann sprichst du natürlich in der Regel auch, mit den Cloud-Anbietern über sogenannte jährliche Commitments. Das bedeutet, jährliches Commitment besagt, okay, über die nächsten drei Jahre gebe ich mindestens fünf Millionen Euro bei euch aus. Ja, dann macht man halt schon größere Rahmenverträge, wo dann natürlich auch andere Nachlässe, Rabatte eine Rolle spielen. Da zahlt man dann nicht mehr die Listenpreise und dann ist man natürlich schon wieder in einem längeren vertraglichen Konstrukt und wo du dann gegebenenfalls vertragliche Regelungen hast, wie zum Beispiel Wenn du innerhalb der nächsten drei Jahre diese fünf Millionen Euro nicht zahlst, zahlst heißt verbrauchst an Cloud-Ressourcen, dann kommt eine Strafzahlung in Höhe von x Prozent ist dann fällig oder ähnliches. Ja also sowas gibt es natürlich auch.

Wolfi Gassler (00:21:52 - 00:22:12)

Übrigens auch die drei Millionen von Basecamp, die die ausgeben, das ist natürlich schon committed, das ist schon perfektioniert, sagen Sie, die sind schon extrem runtergekommen mit den Kosten. Also Ihrer Meinung nach kann man das nicht mehr weiter optimieren, das ist schon mit Langzeitverträgen und so weiter und trotzdem schaffen Sie es eben auf 40 Prozent, behaupten Sie zumindest in Ihrer Schätzung einmal.

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

Also ich meine Cloud-Kostenoptimierung ist natürlich eine ganz andere Liga. Da können wir irgendwann auch mal eine eigene Episode machen. Da geht es natürlich neben diesen jährlichen Commitments über 1, 3, 5, 7, 10, was weiß ich nicht wie viele Jahre, kriegt man natürlich höhere Rabatte, wie zum Beispiel 30% auf jeden Egress-Traffic oder ähnliches. Man zahlt dann nicht mehr die Listenpreise, die man Online auf der Webseite sieht, dann kann man natürlich auch noch Cloudkosten reservieren und so weiter und so fort. Aber das ist nicht das Thema dieser Episode. Aber wenn wir über was ist Cloud sprechen, dann sprechen wir wie gesagt über Hardware, die einem nicht gehört. Hardware, die deutlich flexibler zugänglich ist und auch kündbar ist. Aber wenn wir von Hardware reden, reden wir natürlich von Virtualisierung und auch von Netzwerk. Wir reden von Storage, namentlich, bekanntlich Amazon S3. Das ist, glaube ich, einer der ersten oder der zweiten Service, die Amazon gelauncht hat. Aber wir reden auch über sowas wie Platform as a Service, Database as a Service, Software as a Service, sowas wie Planet Scale, was die zum Beispiel einen Managed MySQL Server komplett geschadet und was weiß ich nicht noch alles hinten dran stellt. Oder sowas wie Heroku oder eine Google Container Registry oder AWS Code Commit, was dann circa das Git von Amazon ist oder Dataflow oder Looker, was dann BI-Dashboards darstellt.

Wolfi Gassler (00:23:32 - 00:24:36)

Aber eben, da sind wir eigentlich schon in der Software-Ecke. Und das finde ich eben auch sehr schwammig, weil man spricht ja von der Cloud. Und von der Cloud, das kann sein, ich verwende irgendwie virtualisierte Server. Ich verwende eine VM, that's it. Oder ich verwende eine full-fledged recommendation engine von Google, die mir da aus meinen Daten irgendwie einen Recommender automatisch baut mit AI und sonstigem, schießt mich tot. Und da sind natürlich Welten dazwischen. Und wenn jetzt zum Beispiel Basecamp von der Cloud spricht, dann sprechen sie normalerweise von recht rudimentären Services wie Virtualisierung, vielleicht noch eine Datenbank, aber that's it. Und ich glaube, da muss man natürlich auch unterscheiden, was ist die Cloud? Und wenn man von Cloud spricht, was verwendet man wirklich für Services? Weil es ist natürlich ein Unterschied, ob ich jetzt eine Virtualisierung selber baue oder ob ich eine komplette Recommender-Engine mit meinen eigenen Modellen und solche Dinge baue. Also das sind schon Unterschiede. Und trotzdem wird in der Umgangssprache immer nur von Cloud gesprochen und die verwenden Cloud-Dienst.

Andy Grunwald (00:24:37 - 00:25:20)

Ja, ich denke, da kommt dann die Differenzierung von Cloud und Cloud Native. Obwohl die beiden Begriffe gar nicht so wirklich so hart definiert sind in der Industrie. Also ich schlage jetzt nicht einen Duden auf und da steht dann Cloud Native. Aber ich denke, das ist so für mich das Verständnis, wo ist der Unterschied. Cloud ist die schnell zugängliche, schnell kündbare Hardware und Compute-Ressourcen und Storage-Ressourcen und all das. Cloud-Native ist dann ... Ich nutze relativ viele Seitenangebote von diesen Cloud-Providern oder beziehungsweise nutze Software, die auf diese flexible, nutzbare Hardware drauf angepasst ist und mit dynamischem Sizing deutlich besser zurechtkommt. Ich glaub, da ist dann vielleicht ...

Wolfi Gassler (00:25:20 - 00:25:33)

Aber das heißt nicht unbedingt Cloud, oder? Weil Prometheus zum Beispiel ist Cloud Native, würde ich mal sagen, kann ich aber natürlich selber hosten genauso. Also das heißt ja nur, wie die Herangehensweise der Software ist, nicht unbedingt, wie ich sie verwende dann.

Andy Grunwald (00:25:34 - 00:26:25)

Ja, ja, das ist korrekt, das ist korrekt, aber es ist halt natürlich schon ein Mindset-Shift, wo wir früher, und früher meine ich jetzt vor dieser ganzen Cloud-Revolution, bevor Amazon, Google große Marktanteile hatten, da hatten wir natürlich alle Server und da war die Infrastruktur eher statisch. Das bedeutet, bis ich einen neuen Server deployed habe, hat man einen Tag oder zwei gedauert oder vielleicht sogar länger. Und die ganze Software, die ganze Monitoring-Software, die ist halt auf statische Software. Man hat halt IP-Adressen irgendwo eingetragen, und die haben sich dann connectet. Wohingegen in der Cloud natürlich ein deutlich dynamischeres Umfeld herrscht. Server fahren runter, Server fahren hoch, vielleicht sogar Minutentakt. Themen wie Autodiscovery, neue Server müssen automatisch in irgendwelche Systeme eingebunden werden, ohne dass die Systeme neu gestartet werden, et cetera, et cetera, ja. Ich glaub schon, dass da dann so ein bisschen der größte Unterschied ist.

Wolfi Gassler (00:26:25 - 00:27:27)

Jetzt eines der großen Argumente, wenn es um so Cloud geht, und die habe ich auch auf Hacker News zum Beispiel einige Male gelesen, ist ja, dass uns die ganzen Spezialisten von der Cloud weggenommen werden und auch das ganze Wissen abfließt. Also es hat eine Message gegeben auf Hacker News, die ich ganz interessant gefunden habe als Vergleich, dass die Medienbranche zum Beispiel in den letzten Jahrzehnten immer mehr ausgelagert hat, also irgendwelche TV, Radiosender und so weiter, dass das alles extern gemacht wird, die gesamte Produktion, der Schnitt und so weiter. Und mittlerweile gibt es keine Leute mehr, die sinnvoll überhaupt schneiden können oder irgendwelche Arbeiten in der Industrie, in der Medienindustrie machen können. Ich kenne es auch zum Beispiel bei der Feuerwehr. Vielmehr wurde ausgelagert an externe Werkstätten. Und früher hattest du interne Leute, die dir bei irgendeinem Feuerwehrauto was umbauen konnten. Gibt es heutzutage intern einfach nicht mehr. Du musst das alles extern machen. Das Gleiche kommt immer auch bei der Cloud als Argument. Jetzt du als großer Cloud-Evangelist, was würdest du zu dem Argument sagen, Andi?

Andy Grunwald (00:27:27 - 00:28:44)

Ist auf jeden Fall ein wahrer Gedanke, den man mal durchspielen müsste. Umso mehr Leute die Cloud verwenden, desto weniger Server müssen in der eigenen Firma beziehungsweise im eigenen Homelab oder ähnliches geragt werden. Das ist natürlich schon richtig. Verlernt man das? Ja, vielleicht. Also ich hab in meiner klassischen Ausbildung als Fachinformatiker Anwendungsentwicklung, haben wir natürlich auch Bereiche der Fachinformatiker Systemintegration gelernt und da habe ich auch gelernt, wie ich einen Server racke, wie ich dann Netzwerkkabel verlege, wie ich Netzwerkkabel krimpe und so weiter und so fort. Habe ich das jemals gebraucht? Ja, ich habe das in der kleinen Webagentur damals auch wirklich mal gebraucht. habe ich es verlernt ich bin da jetzt glaube ich nicht mehr so flüssig aber meine frage ist halt ist das ein skill den die meisten informatiker können müssten oder ist das auch okay dass wir das verlernen weil wenn man sich den produkt lebenszyklus von aktuellen trends, Produkten, Applikationen ansieht, dann wird alles immer schnelllebiger. Damals in der Uni haben wir auch den Produktnebenzyklus des VW Golfs durchgenommen und dann merkst du, dass die Zeitspannen zwischen dem Release einem neuen VW Golf deutlich kleiner werden. Somit gibt der Volkswagen-Konzern natürlich da einen kleineren Produktnebenzyklus vor.

Wolfi Gassler (00:28:44 - 00:28:50)

VW Golf ist übrigens auch ein super Beispiel. Kann man da noch irgendwie eine Lampe selber tauschen? Wahrscheinlich nicht mehr, oder? Muss man in die Werkstatt.

Andy Grunwald (00:28:50 - 00:29:32)

Ich hab doch einen VW Golf 6. Ich fahr einen VW Golf 6. So einen Scheinwerfer müsste ich noch ... So eine Birne müsste ich noch getauscht kriegen. Aber ich hab auch keine Mittelkonsolencomputer und so Quatsch, ne? Also, das hab ich dann auch nicht. Aber wie dem auch sei. Meine Frage ist halt eher, ja, ich stimme dir zu, ich glaube, weniger Leute können ordentliche Netzwerke aufbauen, Hardware-Netzwerke. die frage ist muss das jeder können und bewegen wir uns in eine in ein gefährliches spektrum wo nur noch die großen cloud player dann diese leute haben die server raken können und so weiter ja vielleicht ist das schlecht weiß ich gar nicht weil das die welt sich schneller dreht ja also und deswegen man sich auf das wichtige fokussiert also ist.

Wolfi Gassler (00:29:32 - 00:31:18)

Eine Also ich glaube sowieso nicht, dass das so schnell geht und die Cloud ist eine gute Anwendung für viele Bereiche, aber es ist auch nicht geeignet für ganz viele andere Bereiche und lokales Netzwerk wird es immer geben. Das heißt, du brauchst Leute, die die Netzwerkkabel crimpen können in Gebäuden zum Beispiel. Die Frage ist, müssen das Informatiker machen oder ist es vielleicht in Zukunft einfach auch, oder ist es ja eigentlich schon der ganze Job von Elektrikern? Wie weit, vielleicht wird es auch ein bisschen schwammiger in Zukunft und wahrscheinlich der Beruf eines Elektrikers wird wahrscheinlich auch vielseitiger und die werden ihn in Zukunft vielleicht auch wesentlich mehr machen, vielleicht geht es sogar ins Serverracking irgendwann. Also ich glaube nicht, dass das Ganze verlernt wird und ich sehe das halt auch so ein bisschen wie die Diskussion von C++ und Java oder so. C++-Leute sind halt nicht sehr happy mit den anderen Sprachen, die sehr viel abstrahieren, wo du dann keinen Zugriff mehr auf den Speicher hast. Aber man könnte natürlich auch noch weiter zurückgehen und sagen, jeder sollte Assembler programmieren, weil da hat man dann wirklich richtigen Zugriff und am wenigsten abstrahiert. Das macht halt auch niemand. Also ich glaube, gewisse Abstraktionsebenen sind gut und auch wenn das abstrahiert wird am ende gibt es auch spezialisten die schon den jeweiligen bereich noch kennen du wirst auch leute finden die in irgendeiner form assembler programmieren können oder zumindest auf der ebene unterwegs sind und nachdem er das weltweit diese ganzen server so so braucht glaube ich auch nicht dass google die ganzen abzieht weil du hast immer lokale anbieter du hast kleinere data center Anbieter, eben diese kleinen lokaleren Anbieter oder auch Digital Ocean ist im Vergleich auch sehr klein oder Hetzner. Du hast diese Firmen und die werden natürlich auch lokal dieses Wissen weiter pflegen. Also ich glaube nicht, dass das verloren geht und dass man da überhaupt, dass dieses Wissen absolut weg ist.

Andy Grunwald (00:31:18 - 00:31:47)

Ist ja nicht nur Data Center Provider, sind ja auch Telekommunikationsunternehmen, Oder vielleicht sogar kritische Infrastruktur wie Atomkraftwerke oder irgendwelche großen Krankenhäuser oder ähnliches, ja? Also da ist ja lokale Infrastruktur auch vonnöten. Da müssen auch Glasfaserkabel gezogen werden, Hochverfügbarkeits-Switches et cetera, et cetera. Also ich meine, diese Infrastruktur wird ja nicht ganz verschwimmen. Vielleicht wird es weniger Leute geben, die sich damit auskennen. Ja, das ist richtig.

Wolfi Gassler (00:31:47 - 00:32:04)

Aber kommen wir mal zurück zum Hauptpunkt, den Kosten. Das ist ja auch immer dein Lieblingsthema mit den Opportunitätskosten. Was kostet die Cloud, was kostet On-Prem? Jetzt behauptet DHH, er kann 60 Prozent einsparen. Glaubst du ihm das? Siehst du das anders?

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

Die Aussage, ohne irgendwelche Details zu kennen, ist erst mal schwierig und auch sehr schwierig zu beantworten. Generell denke ich, Co-Locations in Datacentern kann man sehr kostengünstig betreiben. Ich denke, das ist möglich und ich denke auch, dass man dann eine Kostenreduktion von 40, 50, 60 Prozent hinbekommt.

Wolfi Gassler (00:32:25 - 00:33:29)

Machen wir mal ein konkretes Beispiel. Ich habe da ein bisschen recherchiert, natürlich nur ganz grob, weil ich mich auch in dem Bereich nicht perfekt auskenne. Da gibt es andere, die wesentlich tiefer natürlich in dem ganzen Datacenter-Details drin sind. By the way, da können wir gleich einen befreundeten Podcast empfehlen, das Wartungsfenster. Also wer sich für mehr in Richtung Ops und Datacenter interessiert, können wir definitiv das Wartungsfenster empfehlen. Ist ein super, super Podcast und die zwei sprechen mehr über die datacenter-nahe Thematik, würde ich mal sagen. Aber ich mit meinen vor allem Webkenntnissen habe mir mal probiert, da was auszurechnen, weil natürlich auch die Argumentation war vom DHH, er kann heutzutage 12 Terabyte für 3.000 Dollar bekommen und früher war das wesentlich höher und früher wurde halt auch die Entscheidung getroffen, geht man in die Cloud oder nicht. Also seine Meinung war auch, das basiert auf alten Daten und alten Zahlen. Und die haben mir mal dann so angeschaut, was heutzutage so ein Storage-System kostet. Was schätzt du, Andi, was man heutzutage für 180 Terabyte Server so zahlt?

Andy Grunwald (00:33:29 - 00:33:37)

Ich glaube, Flashplatten ist halt wirklich das Segment, was extrem günstig geworden ist in letzter Zeit. Keine Ahnung, wirklich nicht.

Wolfi Gassler (00:33:37 - 00:33:45)

Also es sind 50.000 Euro, ist jetzt gar nicht so wenig würde ich mal sagen, wenn man das auf fünf Jahre rechnet sind es 800 Euro pro Monat.

Andy Grunwald (00:33:45 - 00:33:54)

Halten Festplatten inzwischen fünf Jahre, also besonders wenn die konstant geschrieben und gelesen werden, also ich meine da gibt es doch immer so Hardware Tests oder, also ich meine sind fünf Jahre realistisch?

Wolfi Gassler (00:33:55 - 00:34:02)

Das ist eine gute Frage. Das sind SSDs mittlerweile. Ich glaube mal schon, dass die im Großen und Ganzen fünf Jahre halten.

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

Und die 12 Terabyte, reden wir da um 12 Terabyte Speicher oder reden wir da über 6 Terabyte Speicher und das wird alles gespiegelt oder?

Wolfi Gassler (00:34:09 - 00:34:28)

Also diese 50.000 Euro Server, da sind 180 Terabyte Plattenplatz drinnen und du musst natürlich dann mit RAID oder mit sonstigen Techniken das dementsprechend. Verlierst du wahrscheinlich ein Drittel oder sowas in der Größenordnung, schätze ich mal. Aber nur so als Größenordnung. Dann hast du 800 Euro pro Monat.

Andy Grunwald (00:34:28 - 00:34:41)

Ich möchte nochmal ganz kurz einwerfen. Rate ist kein Backup. Das nur als Grundgedanke. Hat jetzt gerade nicht wirklich viel mit dem Thema, aber viele Leute denken, okay, ich habe ein gespiegeltes Rate. Ah, da habe ich ja ein Backup. Rate ist kein Backup.

Wolfi Gassler (00:34:42 - 00:36:11)

Ist ein guter Punkt, ist aber auch in der Cloud so. Wenn du jetzt Speicher in einer Availability Zone einfach nimmst, dann ist das natürlich auch keine Sicherheit, dass die Daten dort sicher sind, dass sie immer verfügbar sind. Also wahrscheinlich musst du auch in eine andere Region gehen. Also man muss das eh fast immer mal zwei rechnen. Auch die DHH sagt, sie verwenden zwei Datacenter, haben also alles doppelt. Du musst es sowieso immer mal zweier nehmen, aber auch in der Cloud, das vergisst man eben oft, dass nicht alles in der Cloud automatisch irgendwie gespiegelt ist oder sowas. Man muss sich auch darum sinnvoll kümmern natürlich, auch wenn es, wenn es einfach ist. Aber bleiben wir mal bei dem Beispiel. 180 Terabyte, 800 Euro im Monat, rein Hardwarekosten. Dann kommt die Co-Location dazu. Die kann man mal vernachlässigen, weil die sind ein paar hundert Euro im Monat. Was schon ein großer Punkt ist, ist natürlich Strom. sehr teuer geworden. Ich habe da nur mal schnell gecheckt. Das sind schon bei den 50 Cent in Deutschland pro Kilowattstunde. Vielleicht bekommt man das noch billiger irgendwo oder wenn man es im großen Stile einkauft. In den nordischen Ländern ist es dann die Hälfte. Aber man zahlt da doch noch ganz gut Strom und bei so einem Server ist es wahrscheinlich doch irgendwie um die paar hundert Euro pro Monat reine Stromkosten, die man dazu zahlt. Also ich würde mal sagen, man ist dann irgendwo bei 1.500 Euro pro Monat. Wenn man das selber jetzt bei Google kauft, was schätzt du, was es bei Google kostet? 180 Terabyte? Was natürlich jetzt ein unfairer Vergleich ist, weil die haben das wahrscheinlich doppelt vorliegen und so schon in der Region zumindest.

Andy Grunwald (00:36:12 - 00:36:13)

Alleine Storage?

Wolfi Gassler (00:36:13 - 00:36:13)

Ja.

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

Also nicht 10.000?

Wolfi Gassler (00:36:15 - 00:37:44)

Ist gar nicht so hoch. 3.700 Dollar im Monat. Euro im Monat gegen die 1.500 im eigenen Datacenter. und dann ist es ungefähr eben das Doppelte. Das kommt auch ganz gut hin, da sind jetzt natürlich keine Mitarbeiterinnen und so weiter eingerechnet, aber das kommt auch ganz gut hin, wenn man sich so überlegt, was Amazon verdient mit der Cloud und da gibt es ja so Schätzungen, weil genau weiß man es natürlich nicht, aber die Schätzungen gehen in Richtung 60% Cross-Margin, das heißt 60% haben die Gewinn mit den Cloud-Services. Das heißt, Man zahlt natürlich auch deren Gewinn und man finanziert damit auch seine kostenlose Lieferung bei Amazon mit, über die man dann vielleicht glücklich ist. Aber man muss natürlich auch rechnen, die machen Gewinn damit, 60 Prozent. Natürlich haben die eine andere Skalierung und können das besser optimieren, aber nur mal um so ein Gefühl zu bekommen, wo man da liegt. Und dann muss man sich natürlich ausrechnen, was kostet mich das noch, um das Ganze zu administrieren, zu warten. Wie viel Zeit muss ich da noch mit einkalkulieren? Aber natürlich, das ist schon eine Hausnummer, wenn ich bei einem so einen Server 1.500 Euro sparen kann. Da muss ich natürlich noch die Mitarbeiter dazu haben. Aber trotzdem, wenn ich einige Server habe oder viele Server habe, dann kann sich das natürlich schon rentieren. Und da gehen wir jetzt schon in die Richtung von DHH. Wenn ich dieses Personal habe, das sich darum kümmern kann, dann kann ich mir da natürlich vielleicht in Richtung diesen 60 Prozent annähern, die der Amazon verdient.

Andy Grunwald (00:37:45 - 00:37:50)

Naja, also ich bin mir jetzt nicht sicher, ob ich die Rechnung wirklich so professionell annehmen würde, weil...

Wolfi Gassler (00:37:50 - 00:37:59)

Vielleicht kann uns da das Wartungsfenster nochmal helfen. Wir werden denen die Rechnung nochmal schicken. Vielleicht können die das professionalisieren. Aber sag mal deine Meinung dazu.

Andy Grunwald (00:37:59 - 00:38:13)

Also wir haben jetzt hier einen Unterschied von 1.500 Euro im Monat versus, also on Prem, versus 3.700 Euro bei Google. Du sagtest, Co-Location sind ein paar hundert Euro. Das bedeutet, bei so kleinen Beträgen spielen natürlich ein paar hundert Euro schon eine große Rolle.

Wolfi Gassler (00:38:13 - 00:38:17)

Das ist die erste Frage. Die ist aber schon eingerechnet, die Co-Location in die 1.500. Ah, okay.

Andy Grunwald (00:38:17 - 00:38:20)

Dann die zweite Geschichte ist Netzwerktraffic, ja?

Wolfi Gassler (00:38:20 - 00:38:32)

Der ist da auch schon eingerechnet. Aber natürlich nur ... Ich hab da diese Standard-Hetzner-Traffic mitgerechnet. Aber auch bei Google ist der schon eingerechnet. Das waren, glaub ich, 20 Terabyte, was da dabei sind.

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

Dann müsste man halt mal gucken, okay, Co-Location, was die? Weil da hast du natürlich auch Traffic-Verträge. In deinem Co-Location-Vertrag stehen ... In der Regel hast du keine Bandwidth-Free.

Wolfi Gassler (00:38:42 - 00:38:46)

Jaja, 20 Terabyte eben, also ihr habt das so umgerechnet, auch mit Google 20 Terabyte.

Andy Grunwald (00:38:46 - 00:39:40)

Dann hast du natürlich auch von den MitarbeiterInnen gesprochen oder da, also ich meine für alle Leute, die den Fachbegriff nicht kennen, wenn man solche Vergleiche macht, Ist die Cloud wirklich günstiger? Ist On-Premise wirklich günstiger? Was weiß ich nicht. Dann redet man immer hier von Total Cost of Ownership. Das bedeutet, was kostet uns das Summa Summarum, wenn ich wirklich alles mit einberechne. Und da sind solche Hardware 1 oder Option 1 für Hardware versus Option 2 für Hardware halt echt ein bisschen kurz gegriffen. weil du natürlich auch dir die Frage stellen musst, okay, wenn ich das jetzt On-Premise betreibe, brauche ich mehr oder weniger Mitarbeiter oder mache ich das mit der gleichen Mannstärke genauso oder Fraustärke, genau dasselbe mit, wenn ich das in der Cloud betreibe, brauche ich dann so viele Leute wie jetzt. Ja, und das ist die Frage, die kann man gar nicht so einfach beantworten, denn ...

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

Vielleicht darf ich da mal kurz reingrätschen noch, was da auch DHH gemeint hat. Wir sprechen schon fast von irgendwie so einem Gott oder so, das ist unglaublich. Also, ... Also wir ... Wir betrachten das ja eigentlich ganz objektiv. Aber seine Meinung dazu ist und seine Erfahrung von dieser Firma ist auch, dass wie sie in die Cloud gewechselt sind, die haben ja diesen Move schon mal gemacht von On-Prem in Cloud, dass sie sich auf der Operations-Seite nichts eingespart haben. Er sagt, sie haben diese zehn Leute, sie haben die früher gebraucht, sie brauchen die jetzt. Und ich kann das auch in gewisser Weise natürlich schon verstehen, weil wenn du nur diese Hardware-Services oder die Infrastruktur verwendest, dann musst du da natürlich danach noch sehr viel machen. Deine Software aufsetzen und so weiter. Da ist der Hardware-Teil natürlich sehr, sehr klein. Das heißt, wenn du dir jetzt, keine Ahnung, bei dem Rechenbeispiel 1.500 Euro einsparst bei einem Server, da kannst du natürlich schon einiges an Personalkosten auch zahlen, wenn du viele Server hast. Weil wenn du dir bei jedem Server 1.500 Euro einsparst, da kannst du dir dann schon relativ relativ viel leisten. Und ob die Leute dann überhaupt andere Sachen machen können, weil du musst in der Cloud natürlich genauso deine Infrastructure as Code Sachen schreiben, du musst deine Software administrieren, du musst mit Fehlern umgehen, du musst dich um Sicherheit kümmern, weil Sicherheit wird dir auch nicht abgenommen. Das ist auch ein Argument von ihm, auch wenn es immer gesagt wird, in der Cloud ist Sicherheit for free sozusagen. Das stimmt natürlich auch nicht. Auf deiner Software-Ebene musst du natürlich das alles machen. Und ich kann mir schon vorstellen, wenn du das alles zusammenrechnest, deine Operations, dann ist der Teil von der Hardware, von dem untersten Layer, eigentlich relativ klein. Und den kannst du halt wegoptimieren durch die Cloud. Aber der ist im Vergleich relativ klein.

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

Da spreche ich gar nicht gegen, aber ich denke, du hast einen Punkt vergessen. Und zwar die Größe des Operations-Teams. Hast du, wenn du mehrere Datacenter selbst betreibst, oder mehrere Co-Location-Räume, dann, und hast du ein größeres Operations-Team wie, sag mal so 50, 60, 70 Leute, die sich nur um die Server kümmern, warum auch immer, ja, dann fallen diverse Aufgaben, die dieses Operations-Team übernimmt, in der Cloud natürlich weg, ja. hast du aber nur 10 Leute in deinem Operations-Team, dann bin ich voll bei dir, dass du, wenn du in die Cloud gehst, mit hoher Wahrscheinlichkeit bei einer Mannstärke eines 10-Mann-Teams oder 10-Frau-Teams nicht so viel mit einsparen kannst, weil jemand ist immer krank, jemand ist immer irgendwie im Urlaub, dann hast du vielleicht noch Rufbereitschaft und du brauchst verschiedene Skills. Der eine ist der Netzwerk-Profi, der andere der Security-Profi und so weiter. Da kann man dann bei dem Cloud-Move sehr wahrscheinlich nicht an Personal einsparen, wo man hingegen bei einem Operations-Team von 50, 60, 70 Leuten gegebenenfalls durch eine intelligente Konzeptionierung, welches Service nutze ich, wie, wo, was, was automatisiere ich, gegebenenfalls schon das Team, ich sag mal, runterschränken kann, ja? Und wenn wir das jetzt auf den.

Wolfi Gassler (00:42:31 - 00:42:36)

... Heißt das dann, Cloud rendiert sich aus, wenn du ein Ops-Team von 100 Leuten hast?

Andy Grunwald (00:42:36 - 00:43:22)

Nein, denke ich nicht, weil ich denke auch, dass Cloud Und jetzt kommen wir wieder zu Total Cost of Ownership und jetzt kommen wir zu diesem von meinem Lieblingsbegriff Opportunitätskosten, der eigentlich sehr schlecht zu berechnen ist. Weil Opportunitätskosten sind eigentlich Kosten aller Was-Wäre-Wenn. Was wäre, wenn wir eine zweite Realität hätten, in der wir in der Cloud geblieben sind? Wie hätten sich die Kosten mittel- bis langfristig denn entwickelt? Das sind Opportunitätskosten. Und die kann man natürlich nur schätzen. Weil wir haben natürlich keine zweite Realität. Also, beziehungsweise glaube ich, dass wir keine zweite Realität haben. Und da muss man natürlich auch überlegen, an was könnten diese Leute denn stattdessen arbeiten, wenn sie nicht die On-Premise-Hardware betreiben würden? Schwierig, weil da muss man natürlich auch den Markt mit einbeziehen und so weiter.

Wolfi Gassler (00:43:22 - 00:43:42)

Ich glaube, das ist eigentlich der größte Punkt, den man aktuell eigentlich mit einrechnen muss, dass der Markt eigentlich so schwierig ist, dass man überhaupt Leute bekommt. Also du kannst gern sagen, ich kann da Geld einsparen, aber wenn du die Leute nicht dafür hast, um dieses Geld einzusparen, dann kannst du natürlich das gerne rechnen, aber du findest die Leute nicht für deine On-Prime-Lösung.

Andy Grunwald (00:43:43 - 00:44:35)

Deswegen sind Opportunitätskosten auch immer mit Vorsicht zu genießen, aber ich denke, sie sollte man nicht komplett ausblenden. Dann, der nächste Punkt ist... Die Hardware. Du sagst jetzt, okay, du kannst sie fünf bis sieben Jahre nutzen, glaube ich. Ja, das ist richtig, wenn sie denn die 180 Terabyte oder wie viel das auch immer war, in fünf Jahren noch ausreicht. Ja, das bedeutet, du musst dann auch wieder nachkaufen. Dann hast du auf einmal wieder 50.000 Euro. Natürlich kannst du sagen, okay, dann wirtschafte ich klug und mache Rücklagen. Solltest du dann gegebenenfalls tun, wie in einem Mietshaus, da werden ja auch Rücklagen fürs Dach, was dann alle betrifft, irgendwie. zurückgelegt, aber Punkt ist, dass ab einem gewissen Punkt in der Zeit, in der Zukunft wieder Renew von deiner Hardware fällig ist und du dann deutlich höhere Kosten auf einmal hast. Natürlich kannst du es auch leasen und Second-Hand-Hardware kaufen und refurbish und was, was.

Wolfi Gassler (00:44:35 - 00:45:42)

Gibt'S alles irgendwie, Da ist natürlich die Argumentation so ähnlich wie, wenn du irgendwo dir überlegst, okay, du willst jetzt lange irgendwo leben in einer Wohnung, in einem Haus, ist es besser, du mietest das Ganze oder kaufst es? Weil beim Mieten, Argumentation wieder von DHH, beim Mieten zahlst du ja immer irgendwem anderen diesen Gewinn, der da mitmachen will. Und langfristig, wenn du das langfristig planen kannst und wenn du Produkte hast, die sehr konstant sind und wo du auch langfristig planen kannst, im 5-Jahres-Zyklus zum Beispiel, was sie eben machen und was immer ihre Herangehensweise ist, dann kannst du eben mit dem ganz gut rechnen, ganz gut kalkulieren, weil so schnell dreht sich dann natürlich die Technik auch nicht. Und dann kannst du das dementsprechend kalkulieren und dann kannst du diesen Weg der Investition und des selber Bezahlens natürlich machen. Das wird dir natürlich auch jeder Ökonom erklären können, wenn du was besitzt, ist es üblicherweise die günstigere Variante, als wenn du irgendwas mietest, liest, was es auch immer ist. Also wenn du dir das irgendwie leisten kannst, ist es natürlich üblicherweise die bessere Lösung, wenn du es dann auch effektiv nutzen kannst und auch den Bedarf natürlich dafür hast.

Andy Grunwald (00:45:43 - 00:45:56)

Ja, ich glaub, das kommt immer ganz auf die Lebenssituation an. Wie zum Beispiel, wenn ich gerne Billiardspielen geh, dann denkt man immer drüber nach, okay, kauf ich mir einen eigenen Billiardtisch, dann stell ich den hin, dann hab ich den hier, dann benutze ich den aber kaum, weil Billiardspielen dann nix mehr Besonderes ist, ja? Dann hast du dir hier einen Billiardtisch.

Wolfi Gassler (00:45:56 - 00:47:24)

... Ja, aber das ist jetzt ein soziales Event, das kannst du jetzt nicht wirklich vergleichen mit Hardware. Da geht es nicht um eine soziale Komponente. Das ist ein unfairer Vergleich. Aber was ich auch noch bringen wollte, verlinken wir natürlich gern. Es gibt auch ein Artikel zum Beispiel, weil du gesagt hast, wenn du viele Leute hast, dann kann sich das besser rentieren, wenn man dann in die Cloud geht, dass man was einspart. Es gibt einen Artikel von 2019, wo die Bank of America zurückgegangen ist in ihre eigene Cloud oder die hat ihre eigene Cloud entwickelt und sie hat zwei Milliarden damit eingespart. Also in diesem Scale, wenn du dann so groß bist, kann sich das erst recht natürlich rentieren, weil wenn du dieses Potenzial ausnützen kannst und so viele Leute hast und die finanziellen Mittel hast, dass du deine eigene Cloud machst, dann kannst du natürlich auch wieder argumentieren, das was Amazon schafft mit ihren 60% Cross-Margin, das holst du dir zurück, indem du deine eigene Cloud baust. Aber das ist halt dann schon wieder die nächste Stufe, wenn du so groß bist. Also ich glaube, es kommt immer auf die Größe drauf an von deinem Team und von der Firma und was kannst du überhaupt machen, weil wenn du ganz klein bist als Einzelperson, dann kannst du natürlich nicht sagen, ich kann on Prem irgendwie Zeit einsparen oder mir da irgendwie Geld, du kannst Geld sparen, aber du hast dann natürlich auch kein Ops-Team, das dann irgendwas betreuen kann. Also auch da ist unter Umständen die Cloud vielleicht wieder die bessere Lösung, wenn du ein Einzelperson bist. Oder ich bin mir ziemlich sicher, dass da die Cloud die bessere Variante ist. Aber in so Zwischenbereichen, glaube ich, kann On-Prem durchaus eine gute Lösung sein.

Andy Grunwald (00:47:24 - 00:49:20)

Anderer Punkt ist, dass die Cloud natürlich oft als Innovationstreiber verkauft wird. Das bedeutet, es ist sehr einfach, neue Services zu nutzen. schneller Time-to-Market von neuen Produkten zu haben und so weiter und so fort. Das ist die positive Seite. Die negative Seite ist aber auch, es ist sehr einfach, einfache Ressourcen hochzufahren und einfach Lambdas zu feuern und SQS und Kafka und was weiß ich nicht alles. Und dann laufen die Ressourcen und werden nicht mehr genutzt, ja, für Hackathons oder ähnliches. Das sind natürlich dann auch Ressourcen, die kontinuierlich laufen, Kosten erzeugen. Und wenn wir jetzt sagen, okay, ich kenn jetzt die Details von dieser Bank of America Cloud zu On-Premise-Move jetzt nicht, Aber ich kann mir schon vorstellen, umso größer die Firma ist, desto mehr wird von den Entwicklern, von den Produktmanagern und von all den Leuten, die an Infrastruktur arbeiten, geschrien, dass natürlich das Operations-Team ein Gatekeeper ist, beziehungsweise ein Blocker oder ähnliches. Und dass man dann doch in die Cloud gehen sollte, weil da kann ja jeder alles machen. Was natürlich dann im Endeffekt eine Lüge ist, weil Operations ist halt nicht Development und ist halt nicht einfach. Deswegen gibt es Operations-Teams und Systemadministratoren und allem drum und dran. Aber es ist halt sehr einfach, ich sag mal clicky-bunty über die Web-UI irgendwelche Services hochzufahren und die dann zu vergessen. Monatlich stehen die aber kontinuierlich auf der Rechnung. Und wenn man jetzt sagt, okay, ich fahre mir einfach einen Server mit 24 oder 60 CPUs hoch und zwei Terabyte RAM und so weiter, kann man da machen, ist genauso einfach wie, als wenn ich mir eine 5-Dollar-Büchse da hochfahre. Dann kann das natürlich ratzfatz sein, dass man etliche Ressourcen am Laufen hat, die man gar nicht mehr nutzt, die aber trotzdem monatlich bezahlt werden müssen, ja? Das bedeutet, das Operations-Team oder die Person oder Security-Team muss dann schon gewisse, man nennt das Guardrails, Rahmen setzen, was Leute hochfahren können, wie Ressourcen aufgeräumt werden und so weiter und so fort. Und mit dem Argument zu kommen, man kann ja Autoscaling nutzen, das ist jetzt auch ein bisschen zu kurz gedacht, weil Autoscaling ordentlich einzurichten, ist halt auch nicht ganz so einfach.

Wolfi Gassler (00:49:21 - 00:51:07)

Aber eben, ich glaube, das ist halt auch dieser Punkt, dass dieses Operations-Team am Ende viel Arbeit hat, egal ob das in der Cloud ist oder on-prem, weil es eben ganz viele Bereiche gibt, die du in beiden Welten abdecken musst. Und daher kann man das, glaube ich, nicht so einfach sagen, du brauchst bei der Cloud wesentlich weniger Operations. Ein Teil fällt natürlich sicher weg, aber umso größer du bist, umso besser kannst du das dann vielleicht auch selber skalieren und da die Vorteile von einer Skalierung nutzen, dass du die Leute in mehreren Bereichen einsetzt und das möglichst automatisierst und so weiter, also deine eigene Cloud baust. Das funktioniert schon auch. Was du aber auch erwähnt hast, ist, dass man zum Beispiel einfach Software ausprobieren kann. Das ist natürlich schon auch ein guter Punkt und da sind wir wieder bei dem Bereich, was ist denn Cloud eigentlich? Ist es wirklich nur eine Instanz hochfahren oder bedeutet das, ihr könnt so wie mit PlanetScale eine Vitesse-Datenbank verwenden, die auch noch ein Git-Source-Control-artiges Management drüber hat, um eine Schema da in der Datenbank zu verwalten, wo es viel, viel weiter geht. Es ist zwar MySQL-Interface am Ende, aber da ist extrem viel dahinter. Da kann ich noch viel, viel, viel mehr machen. Also das ist eigentlich keine MySQL. Datenbank, Database as a Service. Das ist viel, viel mehr. Und wenn ihr natürlich diese Sachen dann nutzen kann, dann macht es natürlich schon Sinn. Aber da sind wir eben bei dem Bereich von Software as a Service, meiner Meinung nach. Und das fällt natürlich auch ganz oft mittlerweile in das Wort Cloud. Und da muss man halt auch ganz fein unterscheiden. Okay, von was sprechen wir eigentlich? Aber Andi, du warst ja vor ein paar Jahren eigentlich sehr stark involviert bei Trivago in den Cloud-Move oder in den Move in die Cloud weg von On-Prem. Das ist jetzt auch schon ein paar Jahre her. Würdest du sagen, das hat Sinn gemacht? Würdest du es heute anders machen? Wie stehst du zu dem ganzen Move?

Andy Grunwald (00:51:08 - 00:51:49)

Ja, unglaublich schwierige Frage. Da muss man mal ein bisschen ausholen. Also warum ist man erstmal in die Cloud gegangen? In die Cloud ist man gegangen, weil man mit der existierenden On-Premise-Hardware ein paar Herausforderungen hatte. Initial ging es da um Builder-Storage. Der Storage hat nicht so skaliert und da wären dann genau wieder diese Investitionskosten vorhanden gewesen. Man hätte einen größeren Storage kaufen müssen. Und da ist halt die Frage, okay, nutzt man da vielleicht nicht Amazon S3? Und die ganze Thematik hat sich dann über die Zeit so entwickelt. Trivago war sehr, sehr lange on-premise und dann haben ein paar Teams sich nach Innovationsmöglichkeiten gesehen und dann haben wir die Cloud mal ausprobiert und so ist das dann, ich nenne es mal, naturell gewachsen.

Wolfi Gassler (00:51:49 - 00:52:11)

Aber gerade zum Verständnis, das heißt, die Anforderungen haben sich auch stark verändert. Also das war kein Use Case wie jetzt bei Basecamp, wo du konstanten Traffic hast und sehr gut planen kannst, sondern es ist plötzlich, keine Ahnung, der Storage, man hat wesentlich schnelleren Storage benötigt und es hat sich von heute auf morgen eigentlich was in den Anforderungen geändert, oder?

Andy Grunwald (00:52:11 - 00:53:33)

Ja genau, die Anforderung war damals eigentlich, dass ziemlich viele neue Bilder von Hotelzimmern und so weiter in sehr kurzer Zeit dazukamen und verarbeitet werden mussten. Man redet hier von 10, 20, 30 Millionen zusätzlichen Bilder, die in relativ kurzer Zeit halt verarbeitet werden müssen. Verarbeitet heißt Resizing, Metadaten sammeln und so weiter. Alles das, was man halt aus so Bildern rauskriegt. Also die Anforderungen haben sich dann schon sehr kurzfristig geändert, und dass man dann schneller auf diese Anforderungen reagieren kann. Da wurde dann gesagt, okay, lass uns doch mal Amazon EC2 und Amazon S3 ausprobieren. Das war echt schon, weiß ich nicht, so sechs, sieben, acht Jahre her. Auf jeden Fall hat sich das dann so naturell entwickelt, dass dann mehr und mehr Cloud-Services genutzt wurden und so weiter und so fort. Und so ist das dann in die Cloud gegangen. Und später hatte man einen Status, der nicht sehr schön war, dass man verschiedene Cloud-Provider genutzt hatte. Man hatte manche Workloads bei Azure, primär um das Active Directory rum und den E-Mail-Server. Man hatte ein paar Workloads bei Amazon. Man hatte ein paar Workloads auch bei Google, unter anderem natürlich auch Kubernetes, weil Google Cloud da ja der Vorreiter war. Und dann hat man sich die Frage gestellt, okay, können wir das alles irgendwie konsolidieren? Und dann kam auch die Frage, okay, schließen wir unsere On-Premise-Data-Center und so weiter und so fort. Und dann geht man halt so ein Riesenprojekt rein und versucht das alles zu klassifizieren. Man versucht wirklich herauszufinden, was kostet uns das denn über die nächsten ein, zwei, drei, fünf Jahre, wenn wir ...

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

Was war das On-Prem-Setup? Also, größenordnungsmäßig, wie viele Data-Centers oder in welcher Größenordnung sprechen wir da?

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

Mehrere colocations zwei colocations oder drei colocations in amerika eins in europa oder zwei in europa eins in asien.

Wolfi Gassler (00:53:49 - 00:53:53)

Eine in china kurzzeitig sogar oder zeitweise.

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

Genau eine vor der chinesischen mauer eine in china das ist richtig.

Wolfi Gassler (00:53:57 - 00:53:59)

China heißt es.

Andy Grunwald (00:53:59 - 00:54:07)

China china. Also diese, diese chinesische Mauer, die große Firewall, die gibt es, sie ist real und Business in China zu machen ist nicht ganz so einfach, das ist eine andere Story.

Wolfi Gassler (00:54:07 - 00:54:14)

Du sprichst jetzt nicht von der chinesischen, wirklich von der physikalischen chinesischen Mauer, sondern von der Firewall chinesischen Mauer, nur um das klarzustellen.

Andy Grunwald (00:54:14 - 00:55:16)

Ganz genau, Latenz ist eine schwierige Sache da hinten, wenn man nach, in China rein und in China raus. Auf jeden Fall haben wir dann versucht, die Kosten zu klassifizieren, und da holt man natürlich auch Google mit ins Boot. Wir haben uns die Frage gestellt, was würde uns das kosten, wenn wir alles nach Google schieben würden, wenn wir alle Cloud-Provider canceln würden, unsere Co-Locations canceln würden und dann nach Google gehen würden. Und das war wirklich ein Projekt. Da haben wir mehrere Wochen zusammengesessen, unsere Architekturen durchgegangen, versucht, CPUs zu klassifizieren und so weiter. Und das ist superschwierig, Man redet hier in der Regel nicht von einem lift and shift, man kann nicht einfach sagen, okay wir haben jetzt on premise 20.000 CPUs und wir brauchen jetzt 20.000 CPUs in der Cloud, weil wenn man halt Cloud Service betreibt, baut man sie halt anders, hat man gerade schon erwähnt, dynamische Infrastruktur, vielleicht sogar Container und On-Premise laufen die vielleicht wirklich auf Bare-Metal ohne Container und so weiter und so fort. Also da ist halt deutlich mehr Zusatzaufwand notwendig. Natürlich kann man, wenn man das native gebaut hat, dann auch wieder On-Premise betreiben, aber das ist dann ein Shift in einer Architektur und in einer Konzeption.

Wolfi Gassler (00:55:16 - 00:56:21)

Ich glaube, das war ja auch damals ein großer Punkt, dass das wirklich optimiert war auf Bare-Metal. Diese ganzen Prozesse, alles war super optimiert auf genau diese Hardware. Und ich vermute, wenn man das jetzt vergleicht mit Basecamp, wenn die natürlich jetzt zurückkommen aus der Cloud, wo hoffentlich alles irgendwie dockerized ist oder virtualisiert, dann kann man da natürlich auch viel einfacher wieder auf On-Prem wechseln. Und wenn du da eine saubere Virtualisierung hast, die du ja hoffentlich heutzutage sowieso hast, dann ist es ja auch wesentlich einfacher heutzutage zwischen Cloud, On-Prem zu wechseln. Du bist allgemein flexibler. Also die ganze Struktur hat sich ja auch geändert. Die Architektur, wie du Sachen baust heutzutage, ist ja viel flexibler gebaut und da gibt es nicht mehr so den harten Unterschied zwischen Bare-Metal-Optimierung, wo es wirklich um irgendwelche Einstellungen im Compiler geht, dass du das wirklich optimierst auf die Hardware und dann wirklich in der Cloud das ganz anders machen musst. Also ich glaube, dieser Dieser Gap, der damals war, vor fünf, sechs, sieben Jahren, zum Beispiel in der Architektur, den gibt's heutzutage viel, viel weniger, würde ich mal sagen.

Andy Grunwald (00:56:22 - 00:57:24)

Ja, man redet halt nicht über Greenfield-Software, wo alles Cloud-Native und Container gebaut wurde, sondern man redet halt schon von Software, die halt zehn, zwölf, 15 Jahre auf dem Buckel hat. Kommen wir zurück zu deiner ursprünglichen Frage. War das damals richtig oder falsch? Würde ich das jetzt noch so machen? Unglaublich schwierige Frage. Ich kenne die aktuellen Herausforderungen von Trivago jetzt nicht. War das zu dem Zeitpunkt richtig, sich darüber mal Gedanken zu machen? Ich denke, man sollte immer eine gute Diskussion führen und die ganzen Optionen mal auf den Tisch legen und wirklich mal ausrechnen. Das denke ich schon, damit man wirklich Fakten hat und weiß, wo man sich jetzt hier entscheidet. Ich bin aber, wie initial auch schon gesagt, auch der Meinung, dass On-Premise Co-Locations relativ kostengünstig betrieben werden können. Ich bin jetzt kein Fan davon, On-Premise-Kubernetes-Cluster zu betreiben, weil das ist einfach Pain. Ich denke, das kann so ein Google oder so ein Amazon deutlich besser, aber man braucht ja auch nicht immer nur Kubernetes. Und man muss ja auch dazu sagen, nur weil man On-Premise-Colocation unterwegs ist, das eigene Server hat, heißt das ja nicht, dass man die Cloud nicht dazu nutzen kann. Ja? Also Cloud-Hybrid und so weiter ist ja auch ein Ding.

Wolfi Gassler (00:57:24 - 00:57:42)

Vor allem, wenn du das in der Architektur schon mit betrachtest und mit überlegst, dass du das eben so flexibel baust, containerized, nicht auf irgendwelche Spezialservices das Ganze aufsetzt, dann hast du natürlich diese Möglichkeit, parallel zu fahren. Und ich glaube, das ist auch eine gute Möglichkeit, um dann irgendeinen Black Friday oder so abzufangen.

Andy Grunwald (00:57:42 - 00:57:52)

Man sollte sich halt nur bewusst werden, wofür nutzt man die Cloud? Wofür benutzt man On-Premise? Wann lädt man Workloads in die Cloud? Nutzt man das nur für Storage oder vielleicht nur als externe Backup-Location?

Wolfi Gassler (00:57:52 - 00:58:18)

Okay, dann werden wir jetzt gleich mal konkreter, um das abzuschließen, um vielleicht auch ein bisschen Guidance zu geben, vielleicht ganz schnell gefragt bei Beispielszenarien, wie du die machen würdest, gerade mit Cloud oder nicht. Also wenn du jetzt ein Side-Project von dir startest, würdest du es in der Cloud machen oder On-Prem? Wobei On-Prem jetzt schwierig ist, aber ich sage mal jetzt irgendwo, keine Ahnung, physikalischen Hoster, physikalischen Server bei Hetzner.

Andy Grunwald (00:58:19 - 00:58:43)

Zeitprojekt starte ich alle in der Cloud. Ich starte sie aber nicht bei GCP oder bei Amazon, weil ich denke, GCP und Amazon haben, wie man so schön sagt, Apothekenpreise. Wo ich dann eher der Fan davon bin, ist, ich starte das bei DigitalOcean, was recht kostengünstig ist, ich meine, das ist deren Markt, und nutze da halt natürlich auch ein limitiertes Setup-Service. Das bedeutet ein bisschen Compute, vielleicht so ein Shared Kubernetes Cluster Storage. Ich baue jetzt nicht alles auf Lambdas oder Ähnliches.

Wolfi Gassler (00:58:43 - 00:58:52)

Wenn wir jetzt einen Schritt weiter gehen, ein kleines Startup, also aus dem Side-Project wird wirklich ein Startup, wo du Full-Time dran arbeitest oder vielleicht mit ein, zwei Leuten.

Andy Grunwald (00:58:52 - 00:59:07)

Dann würde ich erstmal noch mit DigitalOcean weitermachen, weil bis ich die Grenzen der Server da erreiche, braucht das eine Zeit. Also ich muss erstmal so erfolgreich werden und da kann ich relativ kostengünstig neue Kisten oder meine existierenden Kisten aufstocken.

Wolfi Gassler (00:59:07 - 00:59:19)

Okay, jetzt wird es ein bisschen schwieriger, weil das natürlich wirklich jeweils abhängt vom Anwendungsfall. Wenn wir jetzt in diesen Mittelstand gehen, wann würdest du keine Cloud verwenden?

Andy Grunwald (00:59:19 - 01:00:21)

Wenn man genau weiß, wie sich die Applikation verhält, wenn man genau weiß, welche Verfügbarkeitsrichtlinien oder sogar Compliance-Richtlinien diese Applikation hat und wenn man wirklich ein Modell hat, wovon man wirklich weiß, wovon man redet. Wenn man jetzt vielleicht keine Burst-Workloads hat oder ähnliches, wenn man kontinuierliche Workloads hat, wo man weiß, okay, ich muss jetzt nicht hochskalieren, ich habe jetzt hier nur eine interne CAD-Anwendung und da tingeln nur 20 Ingenieure drauf, die dann jeden Tag so ein Rendering-Workload haben oder ähnliches, den man gut einschätzen kann. Wo Planungssicherheit da ist, aber wo auch nicht schnell reagiert werden muss. Ja, also wenn ich von heute auf morgen zehn neue Server brauche, dann ist das jetzt vielleicht ... Wenn das einmal im Jahr stattfindet, und man das planen kann, okay. Wenn man genau weiß, wovon man redet, dann könnte man das ... Und wenn man natürlich auch schon die Leute da hat. Das bedeutet, wenn man mindestens zwei bis drei Personen hat, die das frequentieren können, oder man holt sich ein externes Dienstleister, ein sogenanntes IT-Systemhaus, kann ich mir auch vorstellen, dass das dann im Endeffekt immer noch günstiger ist.

Wolfi Gassler (01:00:22 - 01:00:44)

Wenn wir jetzt noch einen Schritt größer gehen, so in Richtung Trivago zum Beispiel, jetzt rechnen wir mal, du hast ja ein paar hundert Entwickler drauf und hast auch dementsprechend Ops-Leute, würdest du heutzutage in der Größenordnung, würdest du dir da wieder überlegen, On-Prem auch was zu machen oder würdest du in die Cloud gehen? Können wir dann direkt im CTO von Trivago verrechnen, deine Expertisenmeinung da.

Andy Grunwald (01:00:44 - 01:02:14)

Wenn du ein Operations-Team hast, beziehungsweise ein SAE, beziehungsweise DevOps-Team, beziehungsweise Team von System Engineers, wie man die auch immer bezeichnet, die wirklich eine allgemeingültige und einfach zu benutzende Plattform für die ganzen Engineering Teams bauen und auch in der Lage sind, wirklich eine Developer Experience zu liefern, die Spaß macht zu verwenden, dann kann ich mir schon vorstellen, dass On-Premise Sinn machen könnte. Obwohl man natürlich sagen muss, da muss die Architektur auch ein bisschen umgestellt werden, weil Trivago auch Variable Traffic Patterns hat und man dann ebenfalls überlegen könnte, ob man diese höheren Traffic Patterns dann nicht in die Cloud auslagert. Aber da ist natürlich auch ein sehr hohes In-House Investment notwendig, um diese Art von einfach zu nutzender Plattform für die Engineering Teams zu bauen. Wenn dies nicht der Fall ist, wenn das noch nicht da ist, dann kann man sich überlegen, mache ich dieses Investment oder gehe ich direkt in die Cloud, weil umso mehr Engineers du hast, umso mehr Produktmanager hast du, umso mehr Teams hast du, desto Eher willst du auch mal schnell was prototypen, schnell was ausprobieren und brauchst halt diese Innovationskraft und diese Innovationsgeschwindigkeit von wirklich unabhängigen Teams, was natürlich sehr schwer zu erreichen ist, ist aber der heilige Gral, wenn man so möchte, wenn das Team wirklich voll und ganz in der Lage wäre, die Applikation zu launchen, zu testen. und zu evaluieren, dann würde ich gegebenenfalls jetzt in die Cloud gehen, weil das bieten dir ein Plattform-Themen eher selten.

Wolfi Gassler (01:02:14 - 01:02:20)

Kann das CTO eigentlich Deutsch von Trivago, der Neue? Können wir die Episode ihm schicken und dann Geld verlangen?

Andy Grunwald (01:02:20 - 01:02:22)

Jaja, der kann Deutsch.

Wolfi Gassler (01:02:22 - 01:02:54)

Perfekt, ideal. By the way, wir bekommen kein Geld von keiner Firma, die wir heute irgendwie erwähnt haben. Also das sind alles nur irgendwie Berichte oder persönliche Präferenzen. Jetzt wenn wir einen Schritt weiter gehen zum letzten Schritt große Firmen. Du musst jetzt irgendwie Shopify, Spotify neu bauen sowas in der Größenordnung Cloud oder nicht Cloud, Herr Consultant. Man sieht jetzt gerade Andi schnaufen. Also das ist schade, dass ihr das Video nicht habt. Wir müssen endlich mal mit Video machen. Andi ist gerade sehr hart am Denken.

Andy Grunwald (01:02:54 - 01:03:20)

Shopify und Spotify sind natürlich auch zwei harte Firmen mit, kann ich mir gut vorstellen, Burst-Workloads. Shopify ganz besonders, Black Friday und Co. Spotify, Rihanna bringt ein neues Album raus, kann ich mir schon vorstellen, dass da dann die Luzi abgeht. Aber wenn du so supergroß bist, ich glaub, das kommt dann auf den Use-Case drauf an. Zum Beispiel im Analytics-Space, denke ich, macht die Cloud schon sehr, sehr viel Sinn, weil eine sehr große Datenbank ...

Wolfi Gassler (01:03:20 - 01:03:21)

Was meinst du jetzt mit Analytics-Space?

Andy Grunwald (01:03:22 - 01:03:27)

Ja sowas wie, sowas wie Data Analyst, Data Scientist, sowas wie Big Query.

Wolfi Gassler (01:03:27 - 01:03:30)

Also für interne Analysen und Data Science.

Andy Grunwald (01:03:30 - 01:05:01)

Ganz genau, für sowas denke ich schon macht es Sinn in die Cloud zu gehen, weil du da einfach Innovationspotenzial hast und da kommt es ja öfter mal vor, du hast alles in der Big Query, du musst alles mal in der CSV oder XML dumpen und von da aus dann irgendwie weiter. Natürlich kannst du das auch alles mit einem guten Hadoop Cluster machen, verstehe mich bitte nicht falsch, doch gegebenenfalls ist nicht jeder in der Lage gut performante SQL Queries zu schreiben, die dann vielleicht mal nicht so performant auf dem eigenen Hadoop Cluster laufen und dann gegebenenfalls den ganzen Cluster runterziehen, wo du solche Optimierungen vielleicht ab und zu gar nicht in der Cloud machen musst, sondern bist eher in der Lage ein paar Euro mehr für das Query zu zahlen. Ich denke schon für Internet Analytics macht Cloud so Sinn bei so Megascalern wie Shopify, Spotify. Compute ist eine sehr gute Frage. Microservice Architekturen, Kubernetes sind ja auch keine kleinen Kubernetes Cluster. Wenn es an die Region-Failovers geht und so weiter und so fort, kann ich mir schon vorstellen, dass das Sinn macht, auch besonders sehr viel AB-Testing und wirklich, also ich glaube, du brauchst schon ein hartes Netzwerk-Team, um alles On-Premise sehr gut aufzubauen und da brauchst du aber auch die Remote-Hands in den Co-Locations und so. Schwierig, aber ich meine, wenn du so groß bist, dann lässt du auch nicht nur 5 Millionen bei den Cloud-Providern, sondern dann kannst du natürlich ganz andere Deals mit denen machen, wo du ganz andere Preise kriegst, weil du sehr viel Geld da lässt, weil du vielleicht sogar sagst, okay, lass mal eine große Case Study zusammen machen, was dann wiederum Werbung für Google ist. Ich glaube Spotify ist einer der Hauptkunden bei Google.

Wolfi Gassler (01:05:01 - 01:05:04)

Ich glaube der Größte, so wie Netflix der Größte bei Amazon ist.

Andy Grunwald (01:05:05 - 01:05:18)

Genau, und da reden wir natürlich dann von ganz anderen Preisen. Da wird vielleicht sogar darüber überlegt, wie viel Profitabilität wird bei dem Cloud-Provider, bei Amazon oder Google, weggenommen, um dann den Marketing-Uplift zu haben.

Wolfi Gassler (01:05:18 - 01:06:10)

Aber es ist schon auch klar, dass diese Firmen, also ich weiß es konkret, dass diese Firmen auch intern immer daran arbeiten, können wir irgendwie auf eigene Open-Source-Produkte aufbauen, können wir unsere eigene Software bauen, gerade bei Software-as-a-Service, ob es jetzt um irgendwelche keine Ahnung, PubSub oder solche Dinge geht, also über so Dienste, die man vielleicht auch selber in irgendeiner Form abbilden kann, kann ich da jetzt einen eigenen Kafka verwenden statt PubSub zum Beispiel bei Google, dass über solche Dinge schon ständig nachgedacht wird und die das schon auch intern prüfen, weil gerade die Software ist ziemlich teuer, Software as a Service bei diesen Cloud Providern und da kann man natürlich dann als Großer auch sehr viel rausholen, aber man muss sich dann natürlich auch im Clan sein, dass man dann da irgendwie ein Team mit 20 Leuten abstellt, die nur an dieser Software arbeiten, aber das kann sich natürlich im Endeffekt dann trotzdem rendieren, wenn man die Leute hat. Auch da wieder großes Fragezeichen, wie sich das Ganze entwickelt.

Andy Grunwald (01:06:11 - 01:06:22)

Genau, also ich glaube es gibt für und wieder für die Cloud, ab und zu spielt ja auch Geld einfach gar keine Rolle. Es kommt halt ganz drauf an, was hat man schon da, was hat man nicht da. Recruiting spielt natürlich auch eine Riesenrolle.

Wolfi Gassler (01:06:22 - 01:06:57)

Und was ist auch das Hauptbusiness? Muss man auch ganz klar sagen. Also ist diese IT, ist die Cloud, ist das wirklich ein wichtiges Standbein von der Firma? Ist das wirklich das Hauptprodukt? Oder ist das jetzt nur eine IT-Abteilung und das ist die offizielle Webseite, die man da irgendwie hostet? Also das muss man schon auch noch unterscheiden. Mit was macht man sein Geld und wo investiert man mehr? Macht das selber? Will das auch selber ownen? Will weniger Abhängigkeiten? Oder wo habe ich weniger Abhängigkeiten und was kann ich auslagern? Also auch die Frage, glaube ich, muss man sich immer stellen, damit man überhaupt weiß, wie viel will man denn überhaupt investieren in irgendein Projekt oder im Bereich.

Andy Grunwald (01:06:58 - 01:07:46)

Was ich immer schwierig finde, wenn man sagt, Cloud ist immer die Lösung oder On-Premise ist immer die Lösung, finde ich immer schwierig solche Aussagen, weil ich denke schon, man sollte so professionell sein, da mal eine ordentliche Diskussion zu führen. Und meines Erachtens nach, Leute, die gerade sehr viel On-Premise Co-Locations maintainen, es gibt ja auch die Angst um deinen Job, wenn man in die Cloud geht, dass man denkt, ich habe da nichts mehr zu tun. Meines Erachtens nach ist das purer Quatsch. Weil Leute mit Betriebserfahrung und Operationserfahrung braucht man in der Cloud genau wie on-premise, ja? Also mal die Problematiken wie Subnetze, Netzwerke, Routing, Security, Identity- und Access-Management und all so was, die sind auch alle noch da, die Herausforderungen. Also es gibt für Leute mit solchen Fähigkeiten genug Arbeit an allen Ecken und Enden.

Wolfi Gassler (01:07:46 - 01:08:24)

Das würde wieder das Argument unterstreichen, dass du eigentlich das Ops-Team trotzdem brauchst, dass du dir gar nicht so viel einsparen kannst. Also ich glaube, die Herausforderungen werden sowieso auch immer größer, jetzt gerade wenn man an Security denkt oder an andere Komplexitäten. bei Software. Es wird alles viel, viel schwieriger, viel komplexer und es wird einfach schwieriger, den Überblick zu behalten. Also auch wenn es früher vielleicht möglich war, mit einer Person zu managen, ist es heutzutage garantiert nicht mehr möglich mit einer Person. Also allein durch die Komplexität, die ständig ansteigt, wird es immer schwieriger. Also dass das Leute irgendwann langweilig wird, kann ich mir auch schwer vorstellen.

Andy Grunwald (01:08:24 - 01:08:49)

Also ich meine, die Arbeit an sich ändert sich halt schon ein bisschen, wo du, wenn du ein Kubernetes-Cluster on-premise maintains und updaten musst, dann ist das natürlich schon eine andere Arbeit, als wenn du ein Managed Kubernetes Cluster hast. Das heißt aber nicht, dass die klassische Arbeit von Container-Isolation und Rechte-Management und was da eigentlich noch alles zugehört, wegfällt. Es ist nur eine andere Art von Arbeit und die shiftet sich ein Layer höher oder niedriger.

Wolfi Gassler (01:08:50 - 01:09:32)

Höher, glaube ich. Und auch wenn es gemanaged ist, du musst dir ja trotzdem überlegen, was für Netze machst du? Wie verbindest du die einzelnen Teile im Cluster? Und auf Software-Ebene, wie verbindest du die miteinander? Wie isolierst du die? Also das bleibt ja auch alles bestehen. Nur weil der unterste Teil wegfällt, der unterste Layer, hast du ja alle anderen Layer, die immer komplexer werden. Auch bei Kubernetes zum Beispiel wesentlich komplexer sind das früher, wo du nur eine Maschine hingestellt hast. Also die Komplexität bleibt, wird höher. Das wäre vielleicht höchstens ein Grund, okay, wir gehen wieder auf On-Prem, um die Komplexität zu verringern. Das kann natürlich auch ein guter Punkt sein, aber im Allgemeinen wird es komplexer und ich glaube, du brauchst eher mehr Leute, insofern, wenn du da irgendwo was vereinfachen kannst durch die Cloud, hilft dir das natürlich auf jeden Fall.

Andy Grunwald (01:09:33 - 01:10:02)

Summa summarum kann ich die Entscheidung von 37signals schon nachvollziehen. Und ich denke, für deren Use Case macht das auch Sinn. Und ich denke auch, dass der initiale Start in der Cloud auch richtig für die war. Ich denke aber auch, dass sie diesen Move natürlich jetzt als unglaublichen Marketing-Gag sehen, um vielleicht nochmal auf ihren Service Hey aufmerksam zu machen. Weil die haben natürlich ein sehr lautes Sprachrohr und schwimmen jetzt schon wieder, ich nenne es mal ein bisschen, gegen den Strom.

Wolfi Gassler (01:10:03 - 01:10:43)

Was aber gut ist, weil einfach darüber diskutiert wird und vielleicht jetzt eben auch, wie du sagst, diese Meinung, die dann halt alle CTOs so gefahren haben in letzter Zeit, wir müssen alle in die Cloud, dass man sich das halt auch vielleicht wieder mal überlegt und auch sieht, dass nicht alles, was Cloud ist, automatisch gut ist. Es ist viel gut, aber man muss es sich natürlich im Detail anschauen und im Idealfall so wie 37signals auch die beide Welten sehr gut kennen und schon diesen Move in die Cloud mitgemacht haben, das halt auch sehr gut abschätzen können und da viel gelernt haben und das halt jetzt auch dementsprechend einfach kalkulieren können und das halt die strategische Entscheidung für die ist. Und weil wir jetzt schon so lange gesprochen haben, Andi, schnelles Ende, du kannst jetzt alles perfekt in das übliche Ende in dreieinhalb Sekunden abhandeln.

Andy Grunwald (01:10:43 - 01:10:57)

Clouded On Premise, ein Herzensthema. Ich bin immer dabei, wenn's um meinen gesunden Streit geht. Danke, Wolfgang, dafür. Und ich freu mich auf nächste Woche wieder mit dir über ein Thema hitzig zu diskutieren. Danke dir. Bis bald, tschüss. Ciao.