Die Cloud Native Infrastruktur vs. ein dicker Server - Ein Dauerstreit-Thema
AWS, GCP, Azure und Co bieten viele Cloud Native Services, die dir dein Leben vereinfachen sollen. Serverless, weniger Admins und alles super günstig. Das sind die Versprechen. Doch ist das wirklich so? Wäre ein leistungsstarker Server nicht besser, günstiger, einfacher und ausreichend? Und wie steht das nicht im Konflikt mit einer modernen Microservice-Architektur?
All diese Fragen stellen Wolfgang und Andy in dieser Episode, wo sie einen Artikel "Use One Big Server" besprechen.
Bonus: Was eine Klatsche auf Reddit, Vendor-Lock-in und CV-Driven-Development mit Servern zu tun hat.
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Links
- Reddit-Post: https://www.reddit.com/r/de_EDV/comments/wp9arv/was_habt_ihr_so_mit_github_actions_automatisiert/
- Artikel "Use One Big Server": https://specbranch.com/posts/one-big-server/
- Hackernews: https://news.ycombinator.com/
- 9gag: https://9gag.com/
- F-Online - Vorbereitung für die theoretische Fahrschulprüfung: https://www.f-online.app/
- Proxmox: https://www.proxmox.com/
- Kelsey Hightower: https://en.wikipedia.org/wiki/Kelsey_Hightower
Sprungmarken
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
Wolfi Gassler (00:00:02 - 00:00:59) 
Nerdy gilt in unseren Kreisen ja schon als Kompliment. Aber wie cloudy bist du eigentlich? Und damit willkommen zu einer neuen Episode des Engineering Kiosks und gleichzeitig zu einem kleinen Streitgespräch zwischen Andi und mir. Denn ist Cloud Native nun besser oder schlechter? Und wie sieht es denn mit der guten alten Ein-Server-Strategie eigentlich aus? Über Lambdas Cloud Functions, Skalierung out-of-the-box, Vendor-Logins und der Cloudy-Preisfalle versuchen wir uns an eine Antwort heranzutasten. Aber bevor wir loslegen, erklären wir noch, wie man auf Reddit, auf ganz österreichisch, sich ordentliche Watschen abholen kann. Also eigentlich wollten wir ja heute über ein sinnvolles Thema sprechen, aber Andi ist gerade so gepisst, weil er auf Reddit eine kassiert hat und das muss jetzt unbedingt loswerden. Also jetzt einmal alle auch mal Andi, aber erklär mal, was passiert ist.
Andy Grunwald (00:00:59 - 00:01:08)
Hier und da posten wir mal eine Diskussion auf Reddit und verlinken ganz unten dann immer auf die Podcast-Episode.
Wolfi Gassler (00:01:08 - 00:01:11)
Ah, ich hab ja da schon oben auf die Podcast-Episode verlinkt.
Andy Grunwald (00:01:12 - 00:01:44)
Das ist aber gar nicht so wirklich als Werbung gemeint, sondern eher wirklich für Leute, die Audio-Content haben wollen, zu der Frage. Und wir stellen halt auch schon wirklich die Frage, okay, was automatisieren Leute mit GitHub Actions oder haben die Leute One-on-ones mit ihrem Vorgesetzten oder ähnliches. Naja gut, und dann kam halt ein motivierter Moderator vorbei und ist dann meine ganze Post-Historie auf Reddit durchgegangen und hat irgendwelche Posts aus, weiß ich nicht, vor zwei, drei Jahren ausgegraben und hat mich deswegen da gesperrt.
Wolfi Gassler (00:01:44 - 00:01:52)
Also die eigentliche Sperre war, weil du in 42% deiner Posts Trivago gementioned hast und damit Werbung für Trivago machst.
Andy Grunwald (00:01:52 - 00:02:04)
Und der letzte Post war irgendwie vor drei Jahren oder so. Also, und in ganz anderen Communities, also gar nicht in dem Subreddit, wo der Moderator ist, von daher. Naja, holt man sich mal ne Klatsche ab in diesem Internet.
Wolfi Gassler (00:02:04 - 00:02:28)
Wir möchten übrigens dazu sagen, dass wir im Vorhinein zum Beispiel mit den Moderatoren auch abgeklärt haben von diesem Subreddit, ob wir Episoden posten können. Und der Moderator hat damals gesagt, ja klar, viel Glück, aber halt nicht jede Episode bitte. Und an das halten wir uns natürlich auch, dass wir hier und da einfach mit interessanten Themen auch eine Diskussion einfach starten und in dem Zuge natürlich auch unsere Episoden verlinken.
Andy Grunwald (00:02:28 - 00:02:45)
Ich glaub das war, ich glaub wir sind jetzt bei Folge 31, 32, 33 irgendwie sowas und ich glaub wir haben 5 Posts gemacht oder so, also bei weitem nicht über jeden. Naja, Reddit ist halt ein Platz für sich, genauso wie Hacker News, genauso wie 4chan, genauso wie 9gag, genauso wie dieses Internet.
Wolfi Gassler (00:02:46 - 00:02:59)
Wir haben aber von Reddit auch viele Hörer und Hörerinnen bekommen, weil uns das einige geschrieben haben per E-Mail. Wir fragen da auch immer nach. Also scheinbar interessiert es auch die Leute. Insofern haben wir uns natürlich überlegt, da auch hin und wieder mal was zu posten.
Andy Grunwald (00:02:59 - 00:03:01)
Aber anscheinend nicht den Moderator.
Wolfi Gassler (00:03:01 - 00:03:12)
Nun gut. Ich glaube einfach, das war deine Ruhr-Bot-Formulierung. Oder du hast vielleicht ein persönliches Problem mit diesem Moderator. Bei meinen Posts bisher war immer alles in Ordnung.
Andy Grunwald (00:03:12 - 00:03:13)
Ich kenne ihn ja gar nicht.
Wolfi Gassler (00:03:13 - 00:03:15)
Ja, das weißt du ja nicht.
Andy Grunwald (00:03:15 - 00:03:16)
Ja, dann kennt er mich ja.
Wolfi Gassler (00:03:16 - 00:03:17)
Vielleicht, ja.
Andy Grunwald (00:03:18 - 00:03:25)
Nicht so schlimm. Wenn ihr diese Folge hört, hört ihr uns ja zu. Somit würden wir euch ja dann mit diesem Post nicht erreichen.
Wolfi Gassler (00:03:25 - 00:03:33)
Wir verlinken auf jeden Fall noch gern mal die Reddit-Diskussion, die jetzt ohne Startpost im Internet zumindest verfügbar ist.
Andy Grunwald (00:03:33 - 00:03:42)
Der Post hat sogar Upvotes und ich bin nicht im negativen Vote-Sektor, also ich weiß auch nicht. Naja, lassen wir das.
Wolfi Gassler (00:03:42 - 00:03:48)
Also zu deiner Genugtuung, ich habe diese Argumentation vom Moderator nach unten gevotet. Nur für dich, Andi.
Andy Grunwald (00:03:48 - 00:03:49)
Vielen Dank für den Support.
Wolfi Gassler (00:03:50 - 00:04:21)
Wenn wir übrigens gerade bei Support sind, wir würden uns natürlich freuen, wenn ihr uns in eurer Podcast-App nach oben votet. Zumindest, wenn es irgendwie möglich ist. Oder Sterne vergeben oder irgendwo auf Like klicken. Was es auch immer gibt. Vor allem an alle iPhone-User oder Apple-User. Dort sind unsere Anzahl an Votes immer noch sehr niedrig. Obwohl eigentlich sehr viele auf Apple hören. Also springt mal über euren Privacy-Schatten und klickt mal auf möglichst viele Sterne. Falls es Sterne sind. Keine Ahnung. Bin kein Apple-User. Bin Linux-User.
Andy Grunwald (00:04:21 - 00:04:24)
Ich bin zwar Apple-User, aber ich habe uns, glaube ich, auch nicht bewertet.
Wolfi Gassler (00:04:24 - 00:04:34)
Wie soll man da erfolgreich einen Podcast machen mit solchen Co-Hosts? Aber kommen wir mal zum eigentlichen Thema. Du wolltest mir eine Frage stellen.
Andy Grunwald (00:04:34 - 00:04:39)
Wolfgang, dein Zeitprojekt, wie heißt das nochmal? F-Online, Fahrschule online, irgendwie sowas.
Wolfi Gassler (00:04:40 - 00:04:43)
F-Online, ja genau. Vorbereitung für die theoretische Fahrscheinprüfung.
Andy Grunwald (00:04:44 - 00:04:50)
Und ich erinnere mich, dass du dafür irgendeine virtuelle Maschine irgendwo bei Hetzner gemietet hast.
Wolfi Gassler (00:04:50 - 00:04:51)
Ja, genau.
Andy Grunwald (00:04:51 - 00:04:59)
Und auf dieser virtuellen Maschine läuft ja noch eine alte PHP-Version, eine MySQL und so weiter und so fort. Also du hast alles irgendwie auf einer Maschine laufen, richtig?
Wolfi Gassler (00:04:59 - 00:05:05)
Ja, ist korrekt. Ist eigentlich sogar ein physikalischer Server, aber virtualisiert, ja. Von mir selbst.
Andy Grunwald (00:05:05 - 00:05:11)
Das bedeutet, wenn da jetzt ein Festplatten-Failure hat oder das Netzteil hops geht, dann ist das Ding aus.
Wolfi Gassler (00:05:11 - 00:05:23)
Ja, Festplatte nicht, weil ein RAID drinnen steckt, aber wenn das Netzteil aus... keine Ahnung, ob es ein redundantes Netzteil ist, hab ich schon wieder vergessen. Aber theoretisch ja, wenn irgendwas Gröberes ausfällt, ja, ist alles weg.
Andy Grunwald (00:05:23 - 00:05:24)
Hattest du sowas schon mal?
Wolfi Gassler (00:05:24 - 00:05:30)
Festplattenausfälle sehr oft, ja. Aber die waren dann eigentlich relativ leicht zu beheben, ja.
Andy Grunwald (00:05:30 - 00:05:40)
Hattest du dann schon mal einen Fehlerfall bei deinem Server, bei Hetzner, was dazu geführt hat, dass F-Online offline ist? F-Online offline ist es auch schön.
Wolfi Gassler (00:05:40 - 00:05:50)
Nein, war immer online. Darum heißt es ja F-Online. Keine Ahnung, ob das jetzt ist, weil Hetzner so gut arbeitet oder weil die Server einfach so stabil sind heutzutage. Aber hatte nie ein Problem damit.
Andy Grunwald (00:05:50 - 00:05:54)
Unten runter wird der Server wahrscheinlich auch zwei Netzteile haben oder so oder?
Wolfi Gassler (00:05:54 - 00:06:03)
Ja da bin ich mir eben gar nicht mehr sicher, was das für ein Server ist, das hat man auswählen können, bin mir jetzt nicht genau, glaube eher nicht, aber müsste nochmal nachschauen.
Andy Grunwald (00:06:03 - 00:06:04)
Was kostet der Server dich im Monat?
Wolfi Gassler (00:06:05 - 00:06:11)
Auch das müsste ich jetzt nochmal genau nachschauen, aber irgendwo so bei den 40 Euro, schätze ich mal.
Andy Grunwald (00:06:11 - 00:06:12)
Wann hast du das Projekt gestartet?
Wolfi Gassler (00:06:12 - 00:06:21)
Vor 10 Jahren. Also der Server existiert noch nicht 10 Jahre, da sind wir schon ein, zweimal umgestiegen von Architekturen.
Andy Grunwald (00:06:21 - 00:06:23)
Und wann bist du auf diesen aktuellen Server umgestiegen?
Wolfi Gassler (00:06:23 - 00:06:33)
Also ich habe mal gerade gecheckt, kostet 55 Euro und die Rechnung war von 2017, da war ich mal schon auf diesem Server. Also ich schätze mal vor mindestens fünf Jahren.
Andy Grunwald (00:06:33 - 00:07:02)
Ok, da gab es ja schon Amazon, ich glaube Google Cloud auch, Azure, also ich sage mal diese ganzen populären Cloud Anbieter, die gab es ja schon. Was hat dich damals dazu bewegt, die ganze Sache selbst in die Hand zu nehmen und nicht auf einen der berühmten Cloud-Provider zu gehen und alles serverless zu machen, managed zu gehen. Also warum updatest du da selbst jetzt noch das Betriebssystem und kümmerst dich selbst darum, wenn dein MySQL mal wieder out of memory läuft oder ähnliches?
Wolfi Gassler (00:07:02 - 00:07:45)
Also mein MySQL ist natürlich perfekt gewertet. Es läuft nie out of memory. Ist übrigens wirklich so. Ist wirklich sehr stabil, muss man sagen. Gibt wirklich wenig Probleme. Ich bin mir gar nicht sicher, ob das damals schon so populär war, zu diesen Zeiten, wirklich auf so Cloud-Provider wie GCP oder Amazon zu gehen. Und es war ganz einfach der Preis. Wenn du das vergleichst, was bekommst du um 50 Euro bei AWS oder 55 Euro. Das wird dann schon sehr schwierig. Du musst dann natürlich Im Gegenzug, wie gesagt, da ist eine Virtualisierung drauf, ein Proxmox, den musst du natürlich dann selbst warten, ist schon klar. Also du musst natürlich mehr Zeit investieren, aber um 50 Euro bekommst du, wenn es rein um die Rechenleistung geht, eigentlich sehr wenig bei AWS.
Andy Grunwald (00:07:47 - 00:08:11)
Wenn ich jetzt sage, eine Stunde von dir kostet 100 Euro, würdest du, wenn du deine Arbeitszeit zur Wartung dieses Proxmox und was du da nicht noch alles hast, wenn du das mal grob überschlägst, denkst du, es ist immer noch günstiger, wenn du das selbst wartest versus, dass du F-Online bei Amazon betreibst zum Beispiel oder bei Google in einem Managed-Environment, in einem Serverless-Environment?
Wolfi Gassler (00:08:12 - 00:09:17)
Ich glaube, es kommt dann wirklich darauf an, was du für Angebot von denen auch nutzt, weil auch wenn du jetzt deren Service verwendest und da eine VM hochfährst auf AWS, dann habe ich im Endeffekt dieselbe Umgebung, wie wenn ich eine VM bei mir hochfahre. Das heißt, alles was jetzt nach Proxmox kommt und Proxmox in einem einfachen Setup ist eigentlich relativ stabil und funktioniert ganz gut. Also wenn man da jetzt keine High Available Cluster Lösung oder sonstige Dinge baut, sondern auf einem Rechner virtualisiert, ist das wirklich eigentlich recht easy, wenn man da eine gute Lösung hat. Ein bisschen Firewalls und Routing muss man sich einmal zurechtlegen, aber das funktioniert dann ganz gut. Und danach habe ich eigentlich dann dieselbe Arbeit, egal ob ich jetzt auf meiner Hardware bin oder auf der AWS-Hardware. Also wenn ich jetzt kein serverless verwende, in dem Sinne, dann habe ich den selben Aufwand, meine MySQL zu warten, zu klären, wo kann ich meine persistenten Daten abspeichern von MySQL, was sind meine Parameter von MySQL und so weiter. Also da habe ich den selben Aufwand. Das heißt, es geht wirklich nur um diesen Proxmox-Aufwand im Vorfeld.
Andy Grunwald (00:09:18 - 00:09:57)
Da redest du ja von der klassischen Migration mehr oder weniger, von diesem sogenannten Lift-and-Shift. Wovon ich aber rede, ist eigentlich der zweite Schritt nach deinem Lift-and-Shift, nämlich wirklich Nutzung von der Cloud zu machen. Das bedeutet, du würdest dann jetzt deine MySQL bei Amazon auf dem RDS ziehen oder bei einem Google auf eine Cloud SQL, dein Storage vielleicht irgendwie auf S3, deine Bilder vielleicht da in deren CDN, was ist das? Ich glaub, Amazon CloudFront. Und so weiter und so fort und vielleicht sogar noch die die ec2 oder computeinstanz wegschmeißen und dann vielleicht einen container für f-online vielleicht nach elastic beanstalk zupacken oder app engine oder ähnliches.
Wolfi Gassler (00:09:57 - 00:10:47)
Genau und dann würde ich wesentlich mehr geld natürlich ausgeben ist klar so alleine mysql in der cloud gemanagt, ist eigentlich fast der teuerste Aspekt. Also ich habe mir das auch mal durchgerechnet mit GCP, mit Cloud Run zum Beispiel, also das sind dann schon extrem hohe Kosten und bei so einem kleinen Side-Project ist halt immer die Frage, investierst du da lieber deine eigene Zeit, was dir vielleicht auch Spaß macht, wo du viel lernen kannst oder verwendest du eben so eine Cloud-Solution, die dann ordentlich ins Geld geht und bisher war halt die Entscheidung immer, einen gewissen Teil selbst zu machen. Natürlich Cloud-Angebote zu nutzen, aber durchaus zum Beispiel die MySQL dann einfach selbst zu konfigurieren und zu betreiben, weil das auch für mich zum Beispiel relativ einfach ist, da habe ich viel Erfahrung und dann ist es auch für mich weniger Aufwand, das einfach selbst zu warten und da direkten Zugriff drauf zu haben.
Andy Grunwald (00:10:48 - 00:10:54)
Hast du irgendeine Art saisonalen Traffic oder so Lastspitzen oder ähnliches?
Wolfi Gassler (00:10:54 - 00:11:17)
Ja, natürlich, extrem. Also Führerscheinneulinge lernen primär unter der Woche, nie am Wochenende. Weißt du das selber? Da bist du bei diesen, deinen komischen Holzbausteinen, die du da herumwirfst, um irgendwie Bier zu trinken, wie wir in der letzten Folge besprochen haben. Das heißt, es wird nur unter der Woche gelernt. Da ist wirklich doppelt so viel Traffic unter der Woche und eher am Anfang der Woche als jetzt Ende der Woche.
Andy Grunwald (00:11:18 - 00:11:23)
Das bedeutet auch, du zahlst sozusagen kontinuierlich für die Peak-Usage aktuell.
Wolfi Gassler (00:11:23 - 00:13:09)
Natürlich zahle ich für Peak ganz klar. Aber wenn man sich überlegt, wie viel man sonst in der Cloud zahlen würde für die Nicht-Peak-Zeiten, dann würde sich das überhaupt nicht rentieren. Also ich würde mir da jetzt vielleicht irgendwo ein paar Euro sparen. Aber die Gesamtkosten sind dann einfach viel höher, als wenn ich einfach einen physikalen Server habe und den immer verwende. Und man muss ja auch dazu sagen, es wäre ja schön, dass es wenn man überhaupt keine Peak-Zeiten zahlen müsste, aber in der Cloud ist das ja auch irgendwo eingepreist. Es wäre ja nicht so, dass die Cloud immer zu 100% ausgenützt ist. Natürlich können die Großen wie Google oder AWS möglichst gut ihre Hardware auslasten, aber im Endeffekt zahlst du natürlich trotzdem für irgendeinen Buffer für die 20, 30, 40% die gerade nicht verwendet werden. Also es ist ja nicht umsonst, dass es so Angebote von AWS oder GCP gibt, wo du so Spot Instances zum Beispiel ganz billig haben kannst, weil die gerade nicht gebraucht werden. Also die Cloud Provider haben das Problem schon auch und müssen das auch irgendwo einkalkulieren. und das zahlst du halt im normalen Preis mit. Und wenn man das vergleicht mal die Preise und ich habe da gerade kürzlich einen interessanten Artikel gelesen, der heißt Use One Big Server, der genau in die Richtung geht, der eben eher dafür plädiert einen großen Server zu verwenden und weniger dieses Serverless oder irgendwelche Cloud Functions zu verwenden. Und der hat mal ausgerechnet, wie viel es kostet, wenn man solche Lambdas zum Beispiel, also Functions, in der Cloud verwendet versus einem VM-Server in der Cloud, beide bei Amazon zum Beispiel. Also ich kaufe einmal den ganzen Server auf ein Jahr, bekomme einen besseren Preis, weil ich den ganzen Server für ein Jahr nehme, verglichen mit Functions. Was glaubst du, was der Faktor ist preislich?
Andy Grunwald (00:13:10 - 00:13:36)
Die frage ist meines erachtens nach komplett falsch formuliert weil du eigentlich nicht äpfel mit bieren vergleich sondern äpfel deine compute virtuelle maschinen mit elefanten oder ähnliches du du du willst grad mit einem dreirad zwar mit den lambdas auf nürburgring fahren dass das die die sind ja nicht lambda sind ja oder oder cloud function sind ja nicht dafür ausgelegt im klassischen web traffic zu serven klar kann man das so bauen aber, Es geht ja.
Wolfi Gassler (00:13:36 - 00:13:54)
Jetzt gar nicht um Webtraffic, sondern ganz normaler Load, einfach um irgendwas zu berechnen. Und da kannst du natürlich eins zu eins das umrechnen, was bekommst du mit einer Cloud Function, auf was für einer Hardware, wie viel RAM und so weiter läuft die Cloud Functions versus einem eigenen Rechner. Wenn du nur mal die Monatspreise vergleichst.
Andy Grunwald (00:13:55 - 00:14:01)
Moment, du hast dann jetzt die Erwartung, dass du 24 Stunden durchrechnest, richtig?
Wolfi Gassler (00:14:02 - 00:14:06)
Ja, sag mal, mach mal eine Schätzung, was dieser Faktor ist.
Andy Grunwald (00:14:07 - 00:14:10)
Also ich sage jetzt einfach was, obwohl ich das immer noch für Blödsinn halte.
Wolfi Gassler (00:14:10 - 00:14:11)
Ja?
Andy Grunwald (00:14:11 - 00:14:13)
Weiß ich nicht, mal 20 oder so.
Wolfi Gassler (00:14:13 - 00:14:38)
Genau, also es ist der Faktor 5 bis 30, je nachdem, was man für Angebote vergleicht. Und dadurch kommt eigentlich der Fakt zustande, dass wenn du nur 20% der Zeit nutzt, bist du schon billiger. Das heißt, wenn du nur 20% diesen Server auslastest, eben gar keine 24 Stunden, nur 20% auslastest, bist du schon billiger als wenn du Cloud Functions verwendest.
Andy Grunwald (00:14:38 - 00:14:44)
Unter der Voraussetzung, dass die Cloud Function genauso viel RAM benötigt wie der Server und der Server kontinuierlich unter 90-95% Auslastung steht.
Wolfi Gassler (00:14:46 - 00:15:07)
Nein, der Server muss nur 20% ausgelastet sein. Wenn du den Server mit deiner Applikation 20% auslasten kannst, ist es billiger, als wenn du dieselbe Applikation oder den Prozess, der so und so viel RAM benötigt, in den Functions ausführst, sagt dieser Artikel. Der vergleicht das im Detail, wir verlinken den natürlich noch.
Andy Grunwald (00:15:08 - 00:15:26)
Du kannst aber auch, und deswegen sage ich, der Vergleich ist eigentlich totaler Blödsinn, weil du nimmst sehr viele Annahmen von dem gleichen Verbrauch von Memory wie der Server. Eine Lambda ist ja nicht ein Standardding, du kriegst ja auch Lambdas in verschiedenen Memorygrößen.
Wolfi Gassler (00:15:27 - 00:17:03)
Ja, natürlich, aber du kannst es ja alles vergleichen. Du kannst dir das ja ausrechnen, wie viel RAM brauchst du, in der Lambda Functions, wie viele Cores hast du und dann kannst du die ausrechnen. Wenn du natürlich weniger als den 20 Prozent des Servers auslastest, dann ist es besser mit Lambda Functions. Du hast natürlich auch was weg abstrahiert, ganz klar. Aber es geht eben darum, wenn du mit Lambda Functions beginnst, Und das dann sehr stark nach oben skaliert, wird es halt sehr schnell teuer. Und da ist halt dann die Frage, wechselst du auf einen Server, wo du dich ein Jahr committest zum Beispiel, dann viel bessere Preise bekommst oder gehst du überhaupt vielleicht in eine andere Cloud wie von Hetzner, wo du wirklich nur die Hardware kaufst oder nur einen VM-Server und den Rest dann selber machst, dein Docker-Image raufspielst und dann wird das einfach gesurft von dort. Oder machst du das eben mit Cloud Functions? Und dieser Artikel geht natürlich in die Richtung, dass er sagt, okay, es ist nicht alles Gold, was glänzt und nur weil das dann so einfach ist, ich würde auch mal bezweifeln, dass es so einfach ist, ich habe auch ein paar Functions laufen, es ist schon wartungsfrei, aber es gibt halt auch andere Probleme natürlich. dass man sich auch überlegen muss, okay, vielleicht macht es auch Sinn, eben auf meinen Server zu gehen, wo ich vielleicht auch dann weniger Komplexität habe, weil ich eben vielleicht mehr in Richtung Monolith gehe oder zumindest alle meine Docker-Container auf einem Server habe. Ich habe kein komplexes Setup mit Netzwerk, wie die Docker-Container miteinander kommunizieren. Ich brauche keine Kubernetes oder ähnliche Dinge, die ja auch extrem aufwendig sind. Ich brauche dann Leute wieder, die die Kubernetes warten. Es ist ja nicht so, dass das alles Gratis aus der Cloud rausputzelt und die überhaupt keine Arbeit habe.
Andy Grunwald (00:17:03 - 00:17:09)
Der Artikel von dem du sprichst, der nimmt aber dann wirklich nur die monetären Kosten, das am Ende was auf der Rechnung steht von diesem Cloud Provider oder?
Wolfi Gassler (00:17:10 - 00:17:39)
Natürlich, aber er argumentiert eben auch, dass du brauchst zwar dann keine Sysadmins, wenn du mehr, also er nennt es Cloudy, dass man, mehr von diesen Cloud-Services wie Functions oder Serverless nutzt. Wenn man Cloudy ist, braucht man dann zwar weniger Sysadmins, aber man braucht dafür Cloud-Ops-Leute. Und meine Erfahrung ist schon auch, dass du sehr viele Leute brauchst, um Cloud-Applikationen zu betreiben. Also es macht gewisse Dinge einfacher, aber es nimmt dir nicht automatisch alles ab.
Andy Grunwald (00:17:39 - 00:18:29)
Naja, auch allein die technische Implementierung von einer Lambda, wo du einfach nur ein vordefiniertes Interface implementierst und du sofort mit deiner Businesslogik startest, Versus eine Applikation, die kontinuierlich auf einem Server läuft, mit graceful Shutdown, mit einem Event entgegennehmen, wie zum Beispiel eine HTTP-Request oder irgendwas aus einer Q-Least. Also dieser ganze Rahmen, den du bei einer Lambda-Funktion ja nicht brauchst, weil dieser gegeben ist durch dieses Framework von diesem Lambda- oder Cloud-Functions. All das sind ja auch Kosten zur Implementierung, zur Wartung und allem drum und dran. Deswegen habe ich ja nachgefragt, ob das nur die monetären Kosten in dem Artikel berücksichtigt werden oder halt auch die Implementierungskosten und allem drum und dran. Weil das ist ja eine ganz andere Welt zur Implementierung.
Wolfi Gassler (00:18:30 - 00:19:33)
Klar, es kommt immer darauf an, was du implementierst, aber ich muss schon auch sagen, dass Cloud Functions teilweise kompliziert sind, auch wenn es um Debugging geht und jeder, der mal probiert hat, mit Cloud Functions, vor allem bei GCB, die sind meiner Meinung nach noch weit hinten im Vergleich zu AWS, ordentliches Debugging zu betreiben. da wird dann die Entwicklung schon auch sehr aufwendig und auch der Betrieb sehr aufwendig. Wenn man das vergleicht, ich habe meinen eigenen Docker-Container, da läuft Node.js drauf zum Beispiel, wenn du schon JavaScript erwähnst, wo du nur ein Interface implementierst oder so, vielleicht mit einem Nginx, wenn überhaupt, dann ist das ein kleiner Docker-Container. Ich habe auch sowas, ich habe Sowas seit Jahren laufen, wirklich ganz klein, wird ganz selten aufgerufen. Aber das war in der Cloud nicht möglich. Aber ein Teil sogar läuft in der Cloud mit Cloud Functions. Also ich habe einen Teil auf meinem eigenen Server und einen Teil mit Cloud Functions. Und mein Docker-Container hat bisher noch nie Probleme gemacht. Wie gesagt, ist keine große Anwendung, aber läuft stabil, läuft seit Jahren, nimmt Requests an, wird, glaube ich, nur ein paar Mal pro Woche aufgerufen. Funktioniert perfekt.
Andy Grunwald (00:19:34 - 00:22:00)
Genau das meine ich ja. Natürlich hat die Benutzung von Cloud-Native-Services wie eine Lambda-Function oder eine Cloud-Function, wie es in Google heißt, auch andere Nachteile, wie zum Beispiel das lokale Testing. Es gibt auf GitHub Frameworks, und manchmal bieten die Cloud-Provider auch sogenannte Frameworks an, um so was Ähnliches wie Cloud-Functions lokal laufen zu lassen. Aber das ist immer noch eine Hürde. Und umso neuer ein Cloud-Service ist, umso schwieriger wird auch das lokale Testing. Aber deswegen sage ich ja auch, dass dieser Artikel, von dem du da sprichst, vielleicht ein bisschen zu kurz denkt oder der Vergleich vielleicht ein bisschen hinkt, weil in der Regel sind das einfach zwei unterschiedliche Architekturen, wo du eine Applikation hast, die wirklich Request entgegennimmt und 24-7 läuft, und wo du ein reaktives System hast, wie zum Beispiel Lambdas, was dann nur bei Bedarf hochfährt. Wenn du jetzt Facebook bist und so viele Anfragen kriegst oder Booking, oder ähnliches, diese HTTP-Anfragen dann mit einer Lambda zu beantworten, da stimme ich dir zu. Da macht es finanziell, architekturell mit hoher Wahrscheinlichkeit nicht Sinn, weil die Lambda dann unter Umständen, je nachdem, was sie denn tut, doch schon teurer wird. habe ich aber jedoch mal irgendwann einen kleinen Cronjob, der einmal die Woche läuft oder von mir aus auch einmal am Tag und eine Minute läuft, weil eine Minute Berechnungszeit, auch bei einer Lambda, da kann man sehr viel berechnen, da wird die Lambda-Methode wahrscheinlich ganz weit vorne sein, wenn wir über eine kostengünstige Lösung sprechen. Deswegen, der Vergleich hinkt so ein bisschen und ist auch meines Erachtens sehr limitiert. Wenn ich den Artikel aber richtig verstehe, argumentiert er generell dafür, dass sehr viele Applikationen oder sehr viele Arten von Applikationen gar nicht cloud native sein müssen, sondern dass sehr viele Applikationen, sei es ein Monolith oder sei es ein verteiltes System mit Microservices, auf einem Server Platz finden und dass ein Server generell sehr leistungsstark sein kann und deswegen nicht schlechter ist. Ich bin mir gar nicht sicher, ob er da nur... Also wenn du nur auf die Kosten guckst... Mit allem drum und dran, muss ich zugeben, weiß ich nicht, was günstiger ist, ob On-Premise, ein dicker Server oder ein Server bei Hetzner oder Cloud. Mit allem drum und dran meine ich Entwicklungskosten, Leute und so weiter. Ich glaube, das ist wirklich eine Fallentscheidung und du musst deine Spezifika da mal durchrechnen.
Wolfi Gassler (00:22:00 - 00:22:49)
Es kommt glaube ich ganz stark darauf an, was du für eine Applikation hast und auch wie stark du skalieren musst. Das große Versprechen von Cloud Native oder von Cloud Services im Allgemeinen ist ja, dass das einfach skaliert, out of the box, du brauchst nichts machen. dass es in der Realität anders ausschaut, wissen wir alle, aber du bist halt dann auch sehr tief in diesem Abhängigkeitsverhältnis und es ist ja nicht umsonst, dass wirklich große Firmen und ich möchte jetzt keine Namen nennen, weiß nicht, ob irgendwelche interne Ausblau oder aber wirklich sehr, sehr große Kunden von den Cloud-Anbietern dass die intern auch an Projekten arbeiten und große Teams dran sitzen haben, um wieder wegzukommen aus diesem Abhängigkeitsverhältnis, weil das einfach so extrem teuer wird, wenn du irgendein PubSub verwendest oder andere Dinge.
Andy Grunwald (00:22:49 - 00:23:41)
Der Artikel hat ja nicht Unrecht. Ich hab mir den gerade mal aufgemacht. Der Artikel sagt ja unter anderem, okay, ein moderner Server ist recht leistungsstark, 64 Cores, hält aktuell ein Terabyte am RAM, kann maximal acht Terabyte am RAM halten, Dann werden hier ein paar Beispiele ausgeführt, wozu ein solcher Server denn heutzutage fähig wäre. Man wird hier geschrieben, dass man Videodateien mit einer Geschwindigkeit von 400 Gigabit pro Sekunde liefern kann. Wenn man den Link klickt, dann kommt man zu einem Netflix-Lightdeck. Da muss man natürlich auch einmal kurz sagen, die Netzwerk- und Operating System Engineers bei Netflix, das sind auch hochkarätige Leute, die sich auf jeden Fall mit jedem kleinen Netzwerk-Setting auseinandergesetzt haben, um eine solche Performance natürlich aus einem Server rauszudrücken.
Wolfi Gassler (00:23:42 - 00:24:01)
Aber da geht es ja auch um einfach mal eine Richtung zu zeigen, in welche Richtung das geht mit einem einzigen Server. Da sind ja auch noch ein paar andere Beispiele, eine Million Operations auf einer NoSQL-Datenbank, 70.000 Operations in Postgres, finde ich übrigens fast ein bisschen niedrig, scheint mir jetzt niedrig.
Andy Grunwald (00:24:01 - 00:24:13)
Da kommt da kommt für mich dann immer an was ist das denn für ein query was ist das denn mit wie viel mit wie viel datensätze sprechen wir denn da was ist das ist das ein selector ist das eine insight query ist das ein ride ist das ein was ist das denn.
Wolfi Gassler (00:24:13 - 00:26:08)
In dem fall ist es ja nur um zu zeigen dass ein server sehr leistungsstark ist. Und man sollte sich halt auch meiner Meinung nach überlegen, ob es nicht Möglichkeiten gibt, einen Server zu nutzen. Ich kann da zum Beispiel über Docker sehr gut das Ganze parallelisieren und auch abgrenzen, dass ich meine ganzen Applikationen oder unterschiedlichen Services, sogar wenn ich Microservices habe, auf einem Server betreibe. Klar ist er nicht ausfallsicher, ich brauche immer ein sinnvolles Backup, aber wenn man sich das durchrechnet, wie stark die Architektur vereinfacht wird, wenn du zwei fette Server dort stehen hast, vielleicht in zwei unterschiedlichen Rechenzentren und die in irgendeiner Form ausfallsicher machst, dass einer übernehmen kann. Das ist dann gar nicht so kompliziert im Vergleich zu einer wirklichen Microservice-Umgebung, die auf irgendeinem Kubernetes oder ähnliches läuft und wenn der Kubernetes ausfällt oder eine ganze Region ausfällt, ist es auch schon wieder komplizierter, da musst du Multi-Region-Setups fahren und das wird schon alles sehr, sehr kompliziert und da stellt sich für mich schon oft die Frage, kann ich nicht, wenn ich da zwei, drei, vier fette Maschinen hinstelle, kann ich da nicht unter Umständen das gleiche erreichen und mir extrem viel Komplexität wegnehmen von der ganzen Verteilung, weil wie wir alle wissen, Verteilung ist schwierig, Debugging ist extrem schwierig, wenn es um verteilte Systeme geht, wo sind die Fehler, auf welchen Node und Jeder, der mal in so einem Setup gearbeitet hat, weiß, dass es nicht ganz so einfach ist. Da gibt es natürlich auch Möglichkeiten, das zu verbessern. Aber es ist schwierig. Da brauchen wir uns, glaube ich, alle nichts vormachen. Und das ist die klassische Diskussion, die wir eigentlich nie führen wollten. Monolith versus Microservices. Aber jetzt sind wir schon fast irgendwo in dieser Diskussion drinnen. Aber die Verteilung ist einfach schwierig und es werden die Challenges in eine andere Richtung verlagert. Ich bin immer noch der Meinung, dass es nicht so ist, dass die Microservice-Welt oder die extrem verteilte Welt alles einfacher macht. Ganz im Gegenteil. Sie macht es sicherer, meiner Meinung nach, in Bezug auf Ausfallsicherheit. Aber sie macht definitiv die Entwicklung und den Betrieb nicht einfacher.
Andy Grunwald (00:26:09 - 00:26:28)
Meines Erachtens nach hat nicht der ganze Artikel recht. Der ganze Artikel, meines Erachtens nach, da fehlen Perspektiven. Und zwar wird einzig und allein, es werden technische Fähigkeiten ohne Berücksichtigung des Anwendungsfalls auf reine Hardware und monetäre Kosten heruntergebrochen. Was einfach fern der Realität ist.
Wolfi Gassler (00:26:29 - 00:27:42)
Naja, der Artikel erwähnt schon am Ende nochmal die üblichen Gegenargumente, was gegen so einen Server spricht. Und da ist zum Beispiel auch eben, dass man Sys-Devs zum Beispiel einspart, wo der halt einfach sagt, okay, dafür wie halt Cloud-Ops und andere Leute, die ich brauche, also spart man wirklich so viele Leute ein. Noch dazu sind Cloud-Ops-Leute extrem schwer zu bekommen. Vielleicht sind Setups, die einfacher sind, auch zu handeln von anderen Leuten oder vielleicht sogar von Developern. Also, da gibt es schon Argumente auch in diese Richtung, die man sich, glaube ich, überlegen sollte. Und natürlich, ich kann nicht für alle Use Cases sprechen, aber man kann natürlich das mal vergleichen, was man vergleichen kann, und das ist halt Kosten und Leistung von einem Server zum Beispiel. Aber natürlich im Hintergrund, klar, die Developer, wie aufwendig ist es überhaupt, so ein System zu entwickeln? Das kommt dann natürlich immer auf den Anwendungsfall drauf an, und das kann man auch so nicht direkt sagen. Und die Opportunitätskosten haben wir ja auch schon öfters darüber gesprochen. Die haben wir jetzt noch gar nicht erwähnt, die kann man natürlich auch schwer mit einkalkulieren und bei gewissen Cloud-Lösungen ist es natürlich so, dass wenn man gewisse Services aus der Cloud verwendet, hat man natürlich Opportunitätskosten, die nicht anfallen, beziehungsweise man hätte sie, wenn man nicht die Cloud nutzt und sowas kann man natürlich kaum voraussagen.
Andy Grunwald (00:27:43 - 00:29:01)
Und genau bei den Opportunitätskosten, die generell sehr schwierig zu berechnen sind, da kommt aber die Realität ins Spiel. Nicht die meisten, Entschuldigung, da muss ich mich korrigieren. Viele Firmen nutzen ja unter anderem auch die Cloud, um innovationsfreudig zu sein. Um zu sagen, okay, ich teste jetzt mal diesen Service. Oder ich mache jetzt mal mein Machine Learning-Modell. Oder ich versuche das jetzt mal zu trainieren. Oder was ist denn, wenn ich einfach mal wirklich alle Sensoren, alle Daten von allen Sensoren in eine BigQuery schreibe und ähnliches. Das ist ja innerhalb von wenigen Minuten oder vielleicht wenigen Stunden getestet, um dann eine weitere Entscheidung treffen zu können. All sowas wurde ja hier gar nicht berücksichtigt. Deswegen sage ich ja, prinzipiell hat der Artikel so nicht Unrecht, dass in sehr vielen Fällen ein einziger Server mit den gleichen Hardware-Ressourcen gegenüber einem Cloud-Server oder Cloud Run oder Elastic Beanstalk oder Lambda Functions mit der gleichen Hardware günstiger ist. Das ist korrekt. Der unterschied ist jedoch dass dies realitätsfern ist weil in der regel lambdas und allem drum und dran nicht so benutzt werden also nicht so benutzt werden sollten, hier und da gibt es das bestimmt dass leute sowas was benutzen und sich dann wundern warum die lambda auf einmal 30000 euro im monat kostet aber, Aber.
Wolfi Gassler (00:29:01 - 00:30:55)
Ich glaube, da ist halt einfach der interessante Aspekt, dass man bei 20 Prozent Auslastung unter Umständen schon billiger fahren kann. Natürlich, wie gesagt, man muss sich das immer im Detail anschauen, aber ich habe das sehr interessant gefunden, dass das schon so ein großer Unterschied ist zwischen den unterschiedlichen Architekturen. Und Opportunitätskosten sind nicht mit eingerechnet, klar, das ist alles nicht mit eingerechnet, aber ich glaube, es ist wert, da auch genauer drauf zu schauen. Und ich habe das eigentlich sehr interessant gefunden, Cloudy, was dieser Artikel definiert, wie cloudy sollte man denn sein, weil der Artikel sagt ja auch, man sollte in die Cloud gehen, VMs aus der Cloud verwenden, nicht selber das Ganze administrieren, weil das ist dann wirklich wahrscheinlich wesentlich mehr Aufwand und da einfach mithalten zu können mit den Leuten, die die Hardware selber bauen und die alles optimiert haben, das Netzwerk und so weiter, sicherheitstechnisch auch. Das ist natürlich schwierig selbst, aber die Frage ist immer, wie Cloudy möchte ich sein? In welchem Bereich auch? Wie du richtig sagst, wenn es darum geht, ich will irgendwo ein Modell berechnen im Data Science Bereich, warum nicht irgendeinen Service verwenden? Da ist ja auch die Abhängigkeit dann relativ klein. Aber wenn es halt um Applikationen geht, die dann auch mehr Ressourcen in Anspruch nehmen, dann würde ich mir schon einmal überlegen, okay, macht es wirklich Sinn, das zu verwenden und auch wann natürlich, kommt darauf an, um jetzt schnell irgendwas auszuprobieren für ein Startup, was sowieso keine Leute hat, kann man das ja mal schnell probieren. Aber wie gesagt, es haben auch viele Startups erlebt, die jetzt mittlerweile sehr groß sind, die jetzt genau in diese, ich würde es nicht Preisfalle nennen, aber es ist schon sowas in die Richtung reinlaufen, weil sie jetzt einfach merken, es ist doch etwas teuer das Ganze und wie gesagt, dann wieder an eigenen Lösungen arbeiten. Das ist trotzdem ein valider Ansatz und ich glaube, wenn man am Anfang Zeit sparen kann, ist das gut. Aber man muss sich halt auch überlegen, spart man Zeit? Wie viel Zeit spart man wirklich? Macht Sinn? Und in welche Richtung möchte ich gehen? In welchem Bereich natürlich? Data Science ist sicher ein anderer Bereich als jetzt irgendein Webserver.
Andy Grunwald (00:30:55 - 00:33:29)
Ich meine, du hast gerade ein bisschen auf die Cloud-Kostenoptimierung angesprochen. Das ist sowieso ein ganz anderes Feld. Viele Firmen kommen gar nicht zu dem Punkt, wo die Cloud-Kosten optimiert werden können, weil das Daily Business doch so viel Feature-Druck oder ähnliches hat. Es macht bestimmt nicht immer Sinn, dass eine Firma immer in die Cloud geht. Und wenn wir sagen Cloud, dann reden wir von Amazon, GCP und allem drum und dran. Und umso mehr Cloud-Native-Services von diesem Provider nutzt, umso mehr hat man Vendor-Login. Ich meine, das ist noch mal ein anderes Thema. Meines Erachtens nach, wenn man Amazon, Google oder Azure nutzt, dann sollte man auch voll in den Vendor-Login gehen. Denn nur dann kriegt man das volle Potenzial dieser Cloud. Wenn man jetzt jedoch immer nur die Cloud nutzt und sagt, ich nutze alles immer nur auf Compute oder EC2 Instanzen und immer nur Block Storage und immer nur die Standard-Netzwerk-Fähigkeiten, kann man machen. Aber ich bin mir nicht sicher, ob man dann wirklich den vollen Gewinn einer solchen Plattform wirklich nutzt. Denn der kommt einfach nur, wenn du dich der ganzen Vendor-Login-Geschichte hingibst. Wenn du jetzt aber eine Multi-Cloud-Strategie hast und dich unabhängig von einem Provider machen möchtest, dann reicht es halt leider nicht, nur auf Kubernetes zu gehen, weil eine Kubernetes-Engine auf Amazon mag nicht 100% die gleiche sein wie die auf Google oder wie die auf Azure, sondern wenn man dann wirklich seine Applikation über mehrere Clouds spannt, Das sind wir dann in einem ganz anderen Bereich, da wird es dann schon deutlich komplizierter. Und da muss man dann gucken, okay, was betreibt man hier und warum ist denn überhaupt eine Multicloud-Strategie notwendig? Ich würde halt auch sagen, dass ziemlich viele Firmen oder ziemlich viele Use Cases mit ein paar dicken Servern in irgendeinem Hetzner- oder OVH-Rechenzentrum, glaube ich, besser bedient wären. Ich glaube, dass sie dann weniger Zeit für irgendwelche Operations verbringen würden. Aber das kommt immer ganz drauf an. Besonders hier, wenn du von Monolith versus Microservices sprichst, Das ist für mich, natürlich ist das auch ein Cloud Thema, ja, Microservices wird immer mit Cloud zusammengepackt, aber meines Erachtens ist Monolith versus Microservice gar nicht so wirklich an die Infrastruktur, an die Hardware gebunden, sondern Microservice löst für mich teils ein technisches Problem, teils ein organisatorisches, technisch in der Hinsicht, dass du einzelne Teile deiner Applikation anders skalieren musst und ein organisatorisches, dass du einfach unabhängige Teams haben möchtest. Dann kriegst du aber natürlich andere Probleme mit dem Kommunikationsaufwand, dass die Teams sich abstimmen, API-Versionierung und so weiter und so fort. Das sind dann ganz andere Probleme. Also Microservice versus Monolith, das ist jetzt keine Frage, ob ich jetzt einen Server habe oder komplett Cloud-Native gehe.
Wolfi Gassler (00:33:30 - 00:33:44)
Wird aber gern in einen Topf geworfen, fälschlicherweise natürlich. Aber das eine hat mit dem anderen nichts zu tun. Ich kann auf einem Server Microservice-Architektur fahren, weil ich kann meine 100 Docker-Container auch auf einem Server betreiben.
Andy Grunwald (00:33:44 - 00:34:12)
Da musst du dann ein bisschen mehr Augenmerk auf deine Netzwerkisolation legen, das ist richtig, aber kannst du tun, ja. Aber wenn ich jetzt ein Zwei-Mann- oder ein Drei-Mann-Team bin und ich habe nur einen Server und habe von jedem Docker-Container zwei Instanzen, dann weiß ich nicht, warum das alles ein Microservice sein muss. Ist dann auch mal eine Frage, ob das dann nicht ein Monolith sein kann, weil dann skalierst du ja die unterschiedlichen Teile nicht anders. Du hast aber bei allen drei die Basisarbeit von den Basis-Dependencies, die du immer updaten musst und so weiter und so fort.
Wolfi Gassler (00:34:13 - 00:34:32)
Wäre jetzt für dich, rein zum Abgrenzen, wenn du jetzt ein Docker-Compose-File hast, wo du eine Datenbank hast, du hast einen Nginx, du hast PHP mit deinem Code, ist das dann für dich schon ein Microservice, weil du ja alles wirklich einen Prozess pro Docker hast und die in irgendeiner Form zusammenspielen?
Andy Grunwald (00:34:33 - 00:36:23)
Nö, das klingt mir nach dem klassischen LAMP-Stack, nur mit einem Nginx anstatt einem Apache. Ich meine, so hat man früher, so wird aktuell ja auch noch ein WordPress betrieben. Wenn du deine PHP-Applikation jetzt in mehrere Services splitten möchtest, dann ja, aber so hast du ja gerade nur von dem Web-Server gesprochen, der PHP rendert, dann hast du eine Datenstorage, eine Datenbank, und dann hast du die PHP-Applikation. Und wenn man von Monolith versus Microservice spricht, dann spricht man ja eh in der Regel über die Aufsplittung deines PHP-Containers in dieser Hinsicht und nicht der Datenbank. Also du kannst ja auch 35 PHP-Applikationen haben, die alle auf dieselbe Datenbank gehen. Daran ist ja nichts verkehrtes. Kannst du so machen. Jeder sagt immer, alle Microservices brauchen ihren eigenen Data Storage. Ja, kann man machen. Man kann aber auch einfach sagen, die gehen alle auf denselben Datenbankserver oder auf dieselbe Datenbank sogar. Ist dann gegebenenfalls ... Hat andere Nachteile. Je nachdem, wie groß diese Applikation skaliert werden muss, je nachdem, wie viel Traffic da drauf ist, Daten gespeichert werden, je nachdem was für Compliance-Ansprüche man hat an die Daten. Aber prinzipiell ist das ja erstmal nichts Falsches. Und viele Leute werden mich jetzt steinigen, doch sind wir mal ehrlich, so sieht halt oft die Realität aus. Die Realität ist halt leider nicht immer, dass jeder Microservices, jeder Microservice irgendwie seinen eigenen Data Storage hat, sondern die Realität ist, dass sehr viele Firmen mit einem großen Monolithen gestartet sind, über die letzten Jahre in Richtung Digitalisierung gehen, vielleicht das Engineering Team ein bisschen aufstocken und auf einmal merken, hey, wir kriegen hier ein Bottleneck mit der Datenbank, weil wir das entweder nicht skaliert kriegen oder weil mehr und mehr Leute Schemaänderungen machen wollen und dann fangen sie an zu migrieren. und dann wollen die Teams unabhängig werden und dann splittet man die Datenbank-Storages aus pro Applikation und so weiter und so fort. Das ist so ein klassischer Werdegang von einer Firma, die entweder größer wird oder digitaler wird oder mit Software-Engineers hirnt oder vielleicht gerade irgendwie durchstartet, aber die Realität ist halt oft dreckig.
Wolfi Gassler (00:36:23 - 00:37:28)
Ich glaube, Microservices sind auch nicht per se automatisch schöner oder cleaner. Also es kommt immer darauf an, wie die Teams zusammenarbeiten, ob es überhaupt mehrere Teams sind und wie man das Ganze strukturiert. Und ich glaube, der Hype ist eigentlich vorbei, würde ich sagen. Also diese Microservice-Geschichte, dass irgendwie jeder Microservices baut, ist irgendwo vorbei. Ich glaube, man hat in der Zwischenzeit einen guten Mittelweg gefunden mit Docker, dass man einfach gewisse Sachen abstrahieren kann. und leichter wieder in einem modularen Prinzip zusammenbauen kann, zusammenstecken kann, zwei unterschiedliche Applikationen zum Beispiel. Aber so, dass man irgendwie aus einer Applikation 50 Microservices macht und wirklich möglichst kleine Units und die sind dann alle connected über HTTP-Interfaces und man hat dann bei jedem Request hinten raus irgendwie 100 Requests zu irgendwelchen Microservices und hat dann keine Ahnung, wenn irgendwo ein Problem auftaucht. Ich glaube, diese Architektur ist wieder ein bisschen weniger geworden, dass das so die Standard- oder die präferierte Architektur ist. Oder was meinst du?
Andy Grunwald (00:37:28 - 00:39:40)
Also es gab ja auch mal zwischenzeitlich den Begriff von Nanoservice oder ähnliches, was dann Nano ist, dann schon wieder kleiner als Microservice. Und was ein Microservice ist, welche Größe ein Service haben darf, weiß ich jetzt auch nicht. Gab es ja 10.000 Diskussionen darüber. Und man muss ja auch mal ganz ehrlich sagen, ein Microservice heißt ja nicht unbedingt eine eigene Applikation. Du kannst ja auch einen großen Monolithen haben und dann verschiedene Komponenten und jede einzelne Komponente ist ein Microservice. Ein Microservice ist meines Erachtens nach nur eine klar abstrahierte Komponente, die über eine einheitliche Schnittstelle oder über eine definierte Schnittstelle angesprochen werden kann. Das kann auch ein gutes Class-Interface sein oder das kann ein Proto-File sein oder was weiß der Geier nicht. Die Schnittstelle zu dieser Komponente ist halt nur knallhart definiert. wo ich dir aber zustimme ist dass man beobachtet dass viele firmen inzwischen die schmerzen die eine microservice architektur bringen kann festgestellt haben und deswegen gesagt haben hey so viel overhead wollen wir gar nicht betreiben deswegen gehen wir schon wieder zurück zu einer art monolithischen applikation beziehungsweise zu einer Applikation, die man vereinheitlicht deployen kann oder zusammen deployen kann, denn gut über Deployment-Probleme bei einzelnen Microservices haben wir noch gar nicht gesprochen, Abhängigkeiten von Microservices, alles schwierig. Auch einer der größten Developer Advocates im Cloud-Bereich, Kelsey Hightower, fängt auch schon wieder an, über Monolithen zu sprechen und wie man diese managt und allem drum und dran. Also ist das ein Hype? Es war mal auf jeden Fall ein Hype. Bricht dieser Hype ab? Er ist auf jeden Fall nicht mehr so stark da. Microservices sind aber immer noch sinnvoll. Doch ich würde fast sagen, ich lehne mich mal weit aus dem Fenster, 80 Prozent der Firmen brauchen keine Microservices. Würde ich mal so sagen. Wenn es das jetzt keine Compliance-Regelungen sind oder Ähnliches. Bei sowas ist das natürlich ein super Mittel, wenn man irgendwie bestimmte Daten in einem anderen Segment hat, ich gehe da jetzt mal so Kreditkartendaten oder Userdaten oder Gesundheitsdaten oder ähnliches, da macht es natürlich Sinn, so diese Daten in Microsoft auszulagern und diesen Service dann unter anderen Regulatorien zu setzen, dass dann zum Beispiel das ganze Team nicht damit zu tun hat.
Wolfi Gassler (00:39:41 - 00:40:56)
Aber wie du schon richtig sagst, das ist dann eigentlich ein Service, das ausgelagert wird. Und da reden wir dann nicht mehr von Microservices, sondern von Services. Und ich glaube, Services ist ein guter Gedanke, wenn du einfach unterschiedliche Komponenten hast, die du vielleicht an zwei Händen abzählen kannst, ist das ja völlig in Ordnung. Aber Microservices geht ja nun mal noch einen Schritt weiter, dass die wirklich kleiner sind und noch kleinere Einheiten. Und ich glaube, da hat die Industrie eigentlich einen ganz guten Mittelweg mittlerweile gefunden, weil wenn man jetzt drei, vier Services hat, die kann man auch noch ganz gut debuggen. Aber sobald es mal zweistellig wird oder noch höher, dann wird es schon mit Debugging und allem wesentlich komplexer. gibt es natürlich auch Möglichkeiten. Und wenn man dann IDs vergibt für jedes Request, um dann das durchtracken zu können und zu tracen, da gibt es natürlich Möglichkeiten, aber die sind schon sehr kompliziert. Und ich würde auch ganz klar sagen, ich würde sogar sagen, es sind mehr als 80 Prozent der Firmen kommen mit einem einfachen Setup ganz gut durch. Und das macht auch Sinn, dass man das einfach haltet, weil man braucht wieder andere Spezialisten. Man braucht Leute, die das Ganze verstehen. Es macht das Ganze komplexer. Und da kommt wieder dein Lieblings-Gredo an die Use Borrowing Software. Hilft sicher auch aktuell, wenn man auf dem Arbeitsmarkt schaut, wie schwer es ist, Leute zu bekommen.
Andy Grunwald (00:40:56 - 00:41:57)
Ich denke, auch ein großer Server ist eine gute Lösung. Starte mit einem kleinen Server, guck, wie weit du kommst. Wenn du an die Memory-Grenzen kommst, upgrade deinen Server mal eben. Du bist halt unglaublich schnell, bis du wirklich das Problem hast zu skalieren. Das ist ein schönes Problem zu haben. Wenn du ein Problem hast, wo du wirklich skalieren musst und wo du komplett in die Breite gehen musst, das ist ein schönes Problem, Firmen ja haben wollen, sofern denn auch die Einkommensströme von Geld dann natürlich im Business stimmen und nicht durch irgendwelche Forkbombs oder Programmierfehler. Aber mit einem Server kommt man schon sehr sehr weit und da bin ich auch ein Freund von, weil es einfach super einfach zu maintainen ist. Die Architektur ist relativ einfach, weil man malt nur eine Box auf dem Blatt Papier und nicht zehn Trillionen Pfeile Onboarding an den Leuten ist relativ einfach. Ich verstehe, dass das gegebenenfalls nicht hip ist und ja, vielleicht sieht das auch total langweilig auf einem Lebenslauf aus, aber man muss halt nicht immer CV-Driven Development machen.
Wolfi Gassler (00:41:57 - 00:43:10)
Ich glaube auch gar nicht, dass es unbedingt nur ein Server sein muss. Auch zwei, drei, vier Server funktionieren noch ganz gut. Und es ist immer die Frage, wenn ich jetzt MySQL skalieren will, zum Beispiel als Datenbank, dann habe ich da ganz andere Challenges. Und das ist dann egal, ob das auf Kubernetes oder sonst wo läuft, sondern die Verteilung ist das Schwierigere. Da würde ich vielleicht dann auch auf ein sinnvolles Datenbank-Service zurückgreifen oder halt einfach einen Server und einen Backup-Server noch dazu stellen. Und das Ganze kann man dann ja auch automatisieren, man kann es ja auch mit Infrastructure as Code, haben wir in Folge 24 behandelt, kann man das ja auch automatisieren, dass wenn ein Server zum Beispiel zusammenbricht oder irgendwie ein Problem hat, fährt man in der Cloud einen anderen VM hoch, installiert wieder alles oder man kann da sogar mit mit Lastspitzen umgehen, wenn man jetzt saisonale Spitzen hat, dann fährt man halt mal ein, zwei Server hoch, dazu brauche ich aber nicht ein komplettes automatisches, verteiltes System, was sich selber skaliert und automatisch selber hochspinnt. Für ganz viele Anwendungsfelder braucht es diesen Automatismus gar nicht in dem Sinne, sondern da kommt man mit so einem Zwischenweg mit Infrastructure as Code, den man vielleicht selber anstoßt, aber halt automatisiert hat wenigstens, kommt man da eigentlich auch sehr weit.
Andy Grunwald (00:43:10 - 00:43:17)
Ja, Wolfgang, dann kannst du ja wohl jetzt daran arbeiten, wie du mit einem Server Videofiles mit 400 Gigabit pro Sekunde surfst.
Wolfi Gassler (00:43:17 - 00:43:24)
Und FreeBSD übrigens, ganz wichtig. Ist scheinbar mit FreeBSD gemacht worden von Netflix.
Andy Grunwald (00:43:24 - 00:44:33)
Wir werden auf jeden Fall diesen Artikel in den Shownotes verlinken. Ist auf jeden Fall mal ein ganz guter Zeitvertreib, das zu lesen. Meine Meinung ist, rein objektiv, nur eine sehr limitierte Perspektive mag der Autor recht haben. Über die Key-Message, die er sagen möchte, da bin ich auch d'accord. Dennoch sag ich auch, die Realität sieht oft anders aus. Ich sag aber auch, dass ziemlich viele Firmen einfach nur in die Cloud migrieren, weil's cool ist, beziehungsweise weil sie dann als Digital Native oder ähnliches gelten, oder weil das C-Level-Management diese Entscheidung vielleicht trifft, weil beim letzten Golf man das so gemacht hat, beim letzten Golfspielen. Gibt's auch, ist ja wahrscheinlich auch nicht die Masse, ob es dann immer günstiger ist, monetär günstiger, steht auf einem anderen Blatt, aber auch nicht jede Entscheidung ist komplett monetär getrieben, sondern gegebenenfalls auch mit einem Langzeitplan oder mit dem Innovationsgrad, von daher. Meines Erachtens ist das alles eine Fall-bei-Fall-Entscheidung, ob man jetzt einen großen Server nutzt, ob man jetzt Lambdas nutzt, ob man jetzt einen Monolithen oder eine Microservice-Architektur baut oder, oder, oder. Relativ schwer, da generell ein Für oder Wider zu finden.
Wolfi Gassler (00:44:33 - 00:45:52)
Was für mich einfach interessant war, zu sehen, dass halt nicht automatisch alle Cloud-Lösungen immer die perfekte Lösung sind, also Cloud-Native oder die ganzen Services von der Cloud, sondern dass man sich da durchaus auch Probleme mit reinholt und das sollte man halt auch bedenken. Wie es halt überall so ist, man sollte halt alles bedenken. Oft wird halt einfach gerne sowas erschlagen mit einem Cloud-Service, ohne dass man sich überlegt, okay, was ist die beste Lösung, wo habe ich Vor- und Nachteile und wo kann ich denn persönlich einen Nutzen draus ziehen? Sei es jetzt monetär oder sei es von der Einfachheit oder dass ich einfach weniger auf meiner To-Do-Liste habe, weil wenn ich Services selber maintainen muss, wird es halt einfach aufwendiger mit der Zeit. Also, dass man da einfach sinnvoll die Situation betrachtet und dann eine sinnvolle Entscheidung trifft. Wen das übrigens auch noch interessiert, wir haben in der Folge 12, Make oder Buy, auch über so Dinge gesprochen, soll man eben eher externe Services verwenden oder selbst etwas bauen. Passt auch sehr gut zu dieser Folge. Da geht es mir ja dann um Software auch. Und lasst uns vielleicht auch wissen, einfach was ihr so betreibt an Services in der Cloud oder nicht in der Cloud. Wäre auch schön mal so paar Beispiele zu hören, einfach aus der realen Welt, vielleicht was ihr betreibt mit einem Server oder mehr Server, damit die Hörerinnen und Hörer auch mal sehen, was so in anderen Firmen da draußen los ist.
Andy Grunwald (00:45:53 - 00:46:06)
E-Mail oder was. Wie immer gibt's das Feedback an stetisch at engineeringkiosk.dev oder via Twitter an at engkiosk. Wir freuen uns über jede Meldung und ansonsten wünschen wir euch noch einen schönen Tag. Bis bald. Ciao.