006 VIBE-CODING-APPS VOM EIGENEN RECHNER INS INTERNET BRINGEN

[00:00:00] Moin Kai! Moin Trutz, wie geht’s dir? Mir geht’s gut. Kai, nutzt du schon das neue

[00:00:05] Claude Opus 5.0 in deiner Vibe-Coding-App?

[00:00:08] Nein, tatsächlich noch nicht. Ich habe heute Morgen noch mit Sonnet gearbeitet und habe

[00:00:15] aber da mein Limit auch ausgereizt. Das heißt, mein Claude Code hat heute Morgen direkt mal

[00:00:23] das Usage-basierte Abrechnungsmodell genutzt. Das heißt, mein inkludiertes Volumen war

[00:00:30] aufgebraucht. Das heißt, heute Morgen für ein kleines Feature in meiner Tennis-App sind

[00:00:35] sieben Euro darunter gebucht. Da sieht man, dass es teuer wird, wenn man das wirklich

[00:00:43] Usage-basiert macht. Ich bin mal gespannt. Ich probiere das ein bisschen aus jetzt mal.

[00:00:46] Da bin ich auch gespannt, ob es mal irgendwann auch dahin geht. Momentan profitieren wir

[00:00:51] von diesen subventionierten Plänen. Du hast den 100-Dollar-Plan, ich habe diesen 200-Dollar-Plan.

[00:00:55] Das ist ja Wahnsinn, was man da in Leistung oder in Gegenleistung für bekommt im Vergleich

[00:00:59] zu den US-Dollar, die man da bezahlt. Da frage ich mich, ob das mal irgendwann anders wird. Ich

[00:01:03] hoffe nicht, weil da wird es, wie du gesehen hast, ja echt schnell sehr teuer. Eine zweite

[00:01:07] Frage habe ich aber noch an dich. Und zwar nutzt du in deinem Projekt eigentlich GIT,

[00:01:11] diese Versionskontrolle? Ja, auf jeden Fall. Nicht immer von Anfang an. Manchmal erst,

[00:01:17] wenn so die erste Version steht, aber spätestens dann baue ich ein GIT-Repo auch da rein. Und

[00:01:22] typischerweise pushe ich das dann auch auf GitHub, lege das da als privates Repository ab.

[00:01:28] Aber vielleicht ganz kurz zum, was ist denn GIT überhaupt? Es ist ein Tool zur Versionskontrolle,

[00:01:35] das heißt eine Idee, die es schon sehr, sehr lange in der Softwareentwicklung gibt,

[00:01:40] mit früher Subversion und davor noch ganz, ganz andere Tools, wo es darum ging, wie schafft man

[00:01:47] es denn in solchen großen Repositories, irgendwie Nachvollziehbarkeit zu schaffen? Das heißt,

[00:01:52] was ist denn überhaupt wann entstanden? Welche Codeänderungen wurden gemacht? Für welche Feature

[00:01:57] in der Software? Und auch im Zweifel, um zurückrollen zu können. Das heißt, ich möchte auf

[00:02:03] einen Stand zurück, wo ein Fehler noch nicht existierte, möchte das mal ausprobieren, gehe

[00:02:07] dann wieder auf einen Stand nach vorne, wo der Fehler dann aufgetaucht ist und kann das analysieren.

[00:02:11] Das heißt eigentlich so dieses GIT, die Versionsverwaltung, damit kannst du Änderungen in

[00:02:17] deinem Code tracken und das ist total hilfreich bei der Entwicklung, vor allem bei Coding-Agenten

[00:02:25] ganz früh, in den frühen Tagen des Vibe-Codings war es für mich extrem wichtig, weil mir das da

[00:02:31] ständig passiert ist, dass ich mit dem Agenten irgendwie ein Feature tatsächlich genauso gebaut

[00:02:35] habe, wie ich es brauchte, weil das bestimmte Anforderungen erfüllen musste. Und dann habe

[00:02:42] ich irgendwie einen Tag später, eine Woche später ein ganz anderes Feature gebaut und dann hat er

[00:02:47] mir das da wieder zerschossen und im Zweifel musste ich dann halt wieder zurück. Das heißt,

[00:02:51] irgendwie so zwei Stunden Vibe-Coding-Arbeit musste ich wieder zurückrollen. Das geht aber mit GIT,

[00:02:56] das heißt, man checkt dann einfach eine alte Version aus und kann die dann nutzen. Das heißt,

[00:03:01] eigentlich ist das so eine Schritt-für-Schritt-Dokumentation. Welche

[00:03:04] Änderungen hat man denn im Source-Code tatsächlich gemacht?

[00:03:07] Genau, da sind wir schon mittendrin. Genau darum sollte es mich heute gehen,

[00:03:10] euch doch die nächsten Konzepte so ein bisschen zu erläutern, die wir in der letzten Folge

[00:03:13] ausgespart haben. Sprich, was muss ich als ambitionierter Vibe-Coder eigentlich wissen,

[00:03:18] um gefährlich zu sein? Und GIT gehört auf jeden Fall dazu. Und du hast es schon gesagt,

[00:03:22] ich glaube, GIT in einem Satz ist so ein bisschen Änderungen nachvollziehbar machen,

[00:03:27] dass man im Zweifel immer sehen kann, wann wurde welcher Text von wem wie geändert. Es

[00:03:31] unterstützt auch sehr stark bei der Zusammenarbeit. Also sprich, wenn man im Team arbeitet, das hatten

[00:03:36] wir ja auch zum Beispiel bei unserer Podcast-App, die wir zusammen gebaut haben, da haben wir ja

[00:03:39] beide daran entwickelt. Spätestens dann muss man ja irgendein System haben, damit man sich nicht

[00:03:44] gegenseitig auf die Füße tritt und plötzlich zwei Leute in der gleichen Datei Änderungen vornehmen

[00:03:48] und dann überschreibt der eine die Änderung vom anderen. Das darf natürlich nicht passieren. Und

[00:03:53] da bietet GIT auch eine ganze Menge an Möglichkeiten. GIT ist so ein bisschen,

[00:03:57] glaube ich, für den Außenstehenden erst mal ein bisschen komisch, weil es läuft erst mal

[00:04:01] wieder im Terminal. Es hat eine ganz eigene Sprache. Man redet da von Commits, von Branches,

[00:04:07] von Push, von Repos, Repositories und vielen mehr. Wir wollen auch heute oder haben auch gar nicht

[00:04:13] den Anspruch, heute jetzt da einen Deep Dive zu machen in GIT, weil GIT ist auch eine relativ,

[00:04:16] kann man, glaube ich, beliebig komplex machen auch. Aber die Grundkonzepte sind einfach. Wir

[00:04:22] wollen euch einfach nur erklären, wofür ist das da? Was könnt ihr damit machen? Denn die Umsetzung,

[00:04:27] da kann euch nachher auch der Coding Agent helfen, denn der Coding Agent kennt sich auch

[00:04:31] mit GIT sehr gut aus und kann euch da auf jeden Fall auch begleiten. Aber ihr müsst, glaube ich,

[00:04:34] nur verstehen, welches Problem löst das eigentlich? Und du hast es schon gesagt,

[00:04:37] Änderungen bleiben nachvollziehbar und auch zurückdrehbar. Wenn ich mich irgendwo vertan

[00:04:44] habe, kann ich auch jederzeit wieder auf den Stand gehen vor drei Jahren im Zweifel,

[00:04:48] wenn ich das möchte, sofern GIT da schon mitgelaufen ist und alles mit protokolliert hat.

[00:04:52] Genau darum geht es, glaube ich. Und was sind doch so Konzepte, die man bei GIT kennen sollte? Du

[00:04:59] hast es eben, glaube ich, schon gesagt, wenn man jetzt mal ein neues Feature entwickeln möchte,

[00:05:02] dann arbeitet man da häufig in sogenannten Branches, also in einem Zweig. Man kann sich

[00:05:09] das so vorstellen, man macht einfach eine Kopie von dem bestehenden Projekt, separiert diese Kopie

[00:05:13] und arbeitet darin weiter, ohne jetzt den Hauptbranch, der meistens Main oder Master

[00:05:17] genannt wird, anzufassen, sodass auch mehrere Leute an verschiedenen Features arbeiten können,

[00:05:23] ohne sich in die Quere zu kommen. Und später kann man dann diese Änderungen wieder in die

[00:05:28] Hauptkopie oder in die Hauptversion wieder zurückführen und dann wieder reinbringen.

[00:05:31] Das ist auch, glaube ich, ein sehr praktisches Feature. Das nutzen wir auch bei AMALYTIX ganz

[00:05:35] viel, denn da arbeiten wir meistens an ganz verschiedenen Themen parallel. Und wenn alle

[00:05:40] in den gleichen Dateien arbeiten würden, würde man sich da auch schnell auf die Füße treten.

[00:05:43] Also dieses Branching-Konzept ist, glaube ich, da auch ganz praktisch. Was muss man noch wissen,

[00:05:49] Kai, um GIT irgendwie so im Überblick zu verstehen? Was sind noch so Konzepte?

[00:05:53] Genau, eigentlich der Basic ist einfach, wenn du eine Änderung hast, dann kommittest du die. Das

[00:05:58] ist so der hauptsächliche Befehl. Das heißt, du hast jetzt irgendwie was gebaut und sagst so,

[00:06:03] das ist jetzt mal fertig, dass es irgendwie zusammenhängt, dann macht man ein Commit. Im

[00:06:07] Zweifel sagt man dem Agenten, er soll den Commit machen, dann macht er einen vernünftigen Kommentar

[00:06:12] da rein. Das heißt, man kann so ein Kommentar auch dranhängen. Habe ich jetzt für Feature XY,

[00:06:17] sind diese Änderungen und dann ist das die nächste Version quasi. Und das ist es fast auch schon,

[00:06:25] wenn man GIT nutzt. Wichtig ist, glaube ich, auch zu verstehen, dass GIT und GitHub nochmal

[00:06:29] ein Unterschied ist. Das heißt, GIT kann man ganz normal auf dem eigenen Rechner benutzen,

[00:06:33] ohne dass da irgendwer was, mache ich einfach lokal auf meinem Rechner, um einfach nachvollziehen zu

[00:06:37] können, was habe ich wann geändert, warum. Und wenn ich dann, wie du eben gesagt hast,

[00:06:42] mit mehreren arbeiten will, dann ist so was GitHub der typische Weg. So gibt es auch andere

[00:06:46] Plattformen, aber GitHub ist eigentlich der Weg zu gehen. Und dann kann man einfach da einen

[00:06:52] Repository anlegen, das dann freigeben, entweder ganz public für alle, die da unterwegs sind,

[00:06:57] macht man es ganz frei verfügbar oder man kann es auch privat machen und dann nur für

[00:07:00] einzelne Personen freigeben, so wie wir es auch mit dem Podcast-Thema gemacht haben.

[00:07:04] So hast du das erzeugt, mir freigegeben, da können wir da zusammen arbeiten. Und du hast

[00:07:11] eben gesagt, lebt im Terminal. Es gibt auch Desktop-Apps dafür, das heißt, die das so ein

[00:07:17] bisschen visueller machen. Das macht es nicht besser, um ehrlich zu sein, das macht es nur

[00:07:21] anders. Man hat dann irgendwie ein grafisches User-Interface, aber trotzdem das zu durchdringen,

[00:07:27] was da alles so passiert, ist im Zweifel auch nicht ganz einfach. Und ich glaube auch,

[00:07:31] fast nicht alle Entwicklerinnen und Entwickler, die es tatsächlich auch beruflich nutzen,

[00:07:35] haben es voll durchdrungen, was da wann passiert, unter welchen Umständen. Aber die Basics sind

[00:07:40] einfach. Wenn man alleine arbeitet, geht es eigentlich nur darum, das zu committen. Im

[00:07:44] Zweifel ist dann der Push, das ist das, das dann hochzuladen auf die GitHub-Plattform. Das ist

[00:07:52] dann ein Push. Und wenn es dann darum geht, mit mehreren zusammenzuarbeiten, dann brancht man,

[00:07:58] das heißt, ich arbeite in einem eigenen Zweig und merge das nachher wieder zurück. Das heißt,

[00:08:02] verknüpfe das wieder mit dem Hauptzweig. Das sind so die Hauptdinge, die man wissen muss,

[00:08:07] die Details drumherum. Wenn man in Situationen kommt, wo Fehlermeldungen auftauchen, die man

[00:08:12] nicht versteht, da hilft auch die KI des Vertrauens. Das heißt, die Fehlermeldung

[00:08:16] in Chatbots schmeißen und mal fragen, was man denn tun soll. Und dann kommt man da auch weiter.

[00:08:20] Das war vor einigen Jahren noch anders und man hat dann sehr lange irgendwie versucht,

[00:08:26] herauszufinden, was denn jetzt gerade kaputt ist am Git-Repo. Insofern, ein gutes Tool,

[00:08:32] probiert es mal aus. Das, was man so tagtäglich braucht, ist relativ einfach. Wenn Fehler

[00:08:37] auftauchen, fragt die KI eures Vertrauens und damit kommt man ganz gut weiter eigentlich.

[00:08:42] Super. Ich glaube, GitHub ist auch kostenlos, zumindest in der Basisvariante. Man kann natürlich

[00:08:48] ein paar kostenpflichtige Features dazu buchen. Die braucht man am Anfang meines Erachtens aber

[00:08:51] nicht. Auch private Repositories, die keiner sehen kann, sind bei manchen Diensten kostenpflichtig.

[00:08:57] Hier sind sie aber auch bei GitHub mit inkludiert. Es gibt noch andere Anbieter wie Bitbucket oder

[00:09:01] GitLab. Denn Git als solches ist eine Open-Source-Software oder das Konzept dahinter. Das

[00:09:06] ist kein kostenpflichtiger Dienst. Aber wenn man das praktisch in der Cloud abspeichern möchte,

[00:09:11] kann man sich vielleicht vorstellen, ganz vereinfacht wie eine Art Dropbox. Mehrere

[00:09:15] Leute haben dann Zugriff auf diese Dropbox und können da den Code teilen. Dann braucht man eine

[00:09:20] zentrale Cloud-Plattform. GitHub ist eine davon, gehört mittlerweile zu Microsoft und ist der

[00:09:26] de facto Standard, würde ich fast sagen. Ich würde vermuten, wir nutzen wahrscheinlich 95

[00:09:32] Prozent GitHub und der Rest irgendwie Bitbucket und GitLab. Aber das ist jetzt eine ganz gute

[00:09:37] Schätzung. Ich glaube, GitLab gibt es auch noch viel On-Prem, also im eigenen Unternehmen gehostet.

[00:09:43] Da machst du deine eigene GitLab-Instanz, wo du unternehmensintern was hosten kannst. Das ist

[00:09:49] ganz gut. Und wenn es dann in Richtung Professionalisierung geht, dann bieten die

[00:09:53] Dienste dann auch so etwas wie GitLab Runners. Das heißt nochmal Services, wenn du eine Änderung

[00:09:59] hochpushst in den Hauptzweig, dann führen die Tests aus, versuchen das Ganze zu bauen als Windows-App,

[00:10:05] als Mobile-App für iOS oder ähnliches und all diese Dinge. Das heißt, wenn es dann professioneller

[00:10:11] wird, bieten diese Plattformen noch deutlich mehr. Das ist aber, glaube ich, jetzt nicht Thema für

[00:10:15] uns heute. Genau, das soll auch, glaube ich, reichen zum Thema Git. Vielleicht noch ein letzter

[00:10:20] Tipp, was Best Practice ist, was man nicht tun sollte, ist, irgendwelche Passworte, Wörter oder

[00:10:25] API-Keys im Git-Repository mit abzuspeichern. Die lässt man meistens außen vor. Es gibt so eine

[00:10:31] kleine Datei, die heißt gitignore. Da kann man reinschreiben, welche Dateien bitte nicht gespeichert

[00:10:35] werden sollen oder versionskontrolliert werden sollen. Das vielleicht noch so als letzter Tipp.

[00:10:41] Aber ansonsten soll das mal heute reichen, glaube ich, um Überblick zu kriegen, welches Problem

[00:10:46] löst Git, was ist das, was kann ich damit machen, sollte ich das nutzen? Unsere Empfehlung ja. Und

[00:10:51] das ist es eigentlich, was wir euch noch nachschieben wollten zur letzten Folge.

[00:10:54] Vielleicht da ganz kurz zur Ergänzung noch, heißt dann natürlich auch, dass man so die API-Keys für

[00:10:59] OpenAI oder so nicht einfach in Source Code kopiert. Das heißt, das taucht dann nicht

[00:11:04] irgendwo da auf, machen die Agenten. Aber wenn du die Agenten das bauen lässt, machen die das auch

[00:11:07] vernünftig in einer Environment-Datei, wo das dann liegt, die man ignorieren kann. Ist aber ein

[00:11:12] wichtiger Punkt, glaube ich, in Source-Dateien. In den Python-Dateien haben solche Keys nichts

[00:11:18] zu suchen. Die müssen woanders hin. Exakt. Perfekte Überleitung. Und dann hatten wir letztes Mal ja

[00:11:23] auch aus oder haben ja aufgehört an dem Punkt, wo die App auf dem eigenen Rechner läuft und da

[00:11:30] auch schon Dinge tut. Und das reicht vielleicht auch für 90 Prozent der Dinge, die ihr wollt,

[00:11:34] braucht nur ein Tool, was euch irgendwie lokal unterstützt. Manchmal hat man aber vielleicht,

[00:11:38] jetzt bei dir in deinem Fall ist es ja auch so, Kai, du arbeitest gerade an dieser kleinen App für

[00:11:42] euren Tennisverein. Da sollen vielleicht auch mal andere Mitglieder darauf zugreifen können.

[00:11:46] Und spätestens dann muss man sich ja Gedanken machen, wie kriege ich das denn jetzt hin,

[00:11:50] dass auch andere darauf zugreifen können. Die sollen jetzt ja nicht zu dir an deinen Rechner

[00:11:54] gehen und da irgendwas machen, sondern du willst ja die App dann irgendwo im Internet haben,

[00:11:58] sag ich mal. Und da wollen wir heute auch mal so ein bisschen darauf eingehen,

[00:12:02] welche Möglichkeiten es da gibt. Denn die sind relativ vielfältig und auch jede dieser

[00:12:09] Möglichkeiten ist wahrscheinlich auch wieder ein eigener Podcast für sich. Aber auch da geht es

[00:12:13] uns darum, erstmal nur einen Überblick zu geben, damit ihr mal so ein bisschen das Spektrum kennt

[00:12:17] und vielleicht hier die eine oder andere Idee mitnehmen könnt, wo ihr dann eure App vielleicht

[00:12:21] mal hosten könnt. Ja, typischerweise ist der Weg dann, du musst irgendwie den Code,

[00:12:31] den du auf deinem Rechner jetzt erfolgreich laufen hast, irgendwie auf einen Server bringen oder

[00:12:35] irgendwie auf einen Rechner, der übers Internet verfügbar ist. Und früher sind dann genau da die

[00:12:41] Probleme aufgetaucht. Das heißt, bei mir auf dem Entwicklungsrechner lief alles. Ich habe das schön

[00:12:45] rüber kopiert übers Repository, dann auf einem Server, habe es da ausgeführt und es funktionierte

[00:12:50] erst mal nicht, weil irgendwelche Umgebungen waren anders. Ich habe Dinge auf meinem Rechner

[00:12:55] installiert, ohne es oder ich hatte es installiert, ohne es zu wissen. Und die Software hat Gebrauch

[00:13:01] davon gemacht. Das heißt, ich komme irgendwie in eine andere Umgebung auf dem Server und es läuft

[00:13:05] wieder nicht und muss erst mal gucken, was denn da jetzt fehlt, was ich nicht konfiguriert oder

[00:13:09] installiert habe. Und wenn ich zum nächsten Server umziehe, das gleiche Problem, irgendwie

[00:13:15] wieder ein anderes Setup und ich habe wieder die Probleme. Deshalb eine Möglichkeit, dem zu entgehen

[00:13:20] oder besser damit umzugehen, ist Containerisierung. Docker bestimmt auch schon mal dem einen oder

[00:13:26] anderen begegnet, ist eine Möglichkeit, eigentlich auf deinem Rechner nochmal einen kleinen anderen

[00:13:33] Rechner, einen virtuellen Rechner zu instanziieren. Das heißt, wenn du es nachher deployen willst,

[00:13:40] also wenn du es nachher ausführen willst, deine Anwendungen, dann machst du das in einem

[00:13:45] Docker-Container. Das heißt, du definierst im Entwicklungsprozess sehr genau, in welcher

[00:13:49] Umgebung die Software nachher laufen soll, was die Voraussetzungen sind. Das heißt, welche Pakete

[00:13:55] und Abhängigkeiten installiert werden sollen, welche Versionen von diesen Abhängigkeiten etc.

[00:13:59] Das heißt, das definierst du alles mit und sagst dann, baue mir einen Docker-Container, also baue

[00:14:06] mir einen virtuellen Rechner, der diese Anforderungen erfüllt, kopiere meinen Source-Code

[00:14:11] da rein und dann läuft die App in einem Docker-Container in einer virtuellen Umgebung.

[00:14:15] Typischerweise sind solche Docker-Container einfach Linux-Maschinen. Das heißt, da ist ein

[00:14:19] Linux-Betriebssystem drin, wo du alle Abhängigkeiten installiert hast und deine Anwendung dann da laufen

[00:14:26] kann. Das heißt, das nutzt du typischerweise nicht für die Entwicklung bei dir auf dem lokalen

[00:14:31] Rechner, sondern wenn du es nachher betreiben willst. Das heißt, wenn ich eine App habe,

[00:14:34] die ich wie auf meinem Rechner betreiben will, würde ich auch bei mir einen lokalen

[00:14:38] Docker-Container installieren. Ich starte den Docker-Container und dann ist die App da einfach.

[00:14:43] Das ist ein Weg, wie man sehr klar strukturiert eine gesicherte Umgebung mitnehmen kann. Das heißt,

[00:14:53] auf meinem Rechner läuft genau die gleiche Umgebung wie auf dem Server, wo ich das nachher in der Welt

[00:14:57] verfügbar machen möchte. Ich glaube, das Geheimnis dabei ist, dass man die Abhängigkeiten halt sauber

[00:15:04] definiert, schon auf dem Entwicklungsrechner. Ich muss ja sagen, welche Abhängigkeiten brauche

[00:15:08] ich etc. Das heißt, das kann man natürlich auch ohne Containerisierung machen. Wenn ich mir ganz

[00:15:13] sauber definiere, welche Abhängigkeiten muss denn das Betriebssystem haben, dann kann ich das

[00:15:17] natürlich auch auf einem anderen Server neu aufsetzen. Aber Docker hilft total dabei,

[00:15:21] das zu machen. Typischerweise nutzt man auch mehrere Docker-Container. Das heißt, man trennt

[00:15:29] das auch ein bisschen, dass ich eine normale Web-App habe. Ein typisches Setup sind, glaube ich,

[00:15:34] drei Docker-Container. Ich habe einen Docker-Container für das Frontend, also alles,

[00:15:37] was Web-Anwendung ist, was der Nutzer sieht. Dann habe ich einen eigenen Docker-Container für das

[00:15:43] Backend. Alles, was die Logik der App ist, was wann, wie, wo passieren soll, die Schnittstellen,

[00:15:48] wo letztendlich diese Webseite darauf zugreift. Sehr häufig hat man dann noch einen dritten

[00:15:55] Docker-Container, wo die Datenbank drin läuft. Das heißt, das, wo man Daten speichert, eine Postgres-Datenbank

[00:15:59] oder was auch immer man da braucht, läuft im dritten Docker-Container. Das ist ein Setup,

[00:16:04] was einem relativ häufig begegnet. Die Docker-Umgebung hilft dir dabei, auf deinem Rechner

[00:16:13] eigentlich die gleichen Bedingungen zu schaffen wie auf einem Server und dann relativ leicht

[00:16:18] sowas auch auf anderen Rechnern, auf anderen Servern deployen zu können.

[00:16:22] Super, also habe ich nichts mehr hinzuzufügen. Ich glaube, ich habe es sehr gut erklärt und

[00:16:26] ich glaube, es reicht auch für den Überblick. Aber was ich in einem Satz sagen will,

[00:16:31] es ist praktisch wie so eine Art virtueller Computer oder so eine virtuelle Maschine oder

[00:16:35] so ein eigener Computer im Computer. Den kann man freigestalten, genauso aufbauen,

[00:16:38] wie man das gerne hätte, sodass er überall, wo dieser Container läuft, gleich läuft. Das haben

[00:16:43] wir auch gemacht. Bei unserer Podcast-App hast du ja auch so ein Docker-Setup gemacht. Das konnte

[00:16:47] ich dann einfach runterladen. Ist auch Teil des Repositories. Liegt ja also auch im Git-Hub mit

[00:16:53] dritten. Wird ja beschrieben über Textdateien letztlich auch und kann deswegen auch über

[00:16:59] entsprechenden Git dann weitergegeben werden, sodass ich das dann entsprechend auch aufrufen kann. Und

[00:17:03] auch wenn wir auf komplett unterschiedlichen Maschinen arbeiten, du vielleicht auf Windows,

[00:17:06] ich auf Mac, auf Linux wird es nachher gehostet, stellt man dann trotzdem sicher, dass die Umgebung,

[00:17:12] in dem der Code läuft, immer der gleiche ist. Und das war, glaube ich, wirklich ein

[00:17:16] Game-Changer auch nochmal in der Software-Entwicklung. Hilft vor allem bei etwas

[00:17:20] komplexeren Apps, würde ich sagen. Wenn man jetzt nur so ein kleines Mikro-Tool baut,

[00:17:25] was jetzt irgendwas in Python macht, braucht man es vielleicht nicht zwingend. Aber sobald man,

[00:17:29] sage ich mal, so ein bisschen mehrere Moving-Parts da einbaut, du hast es schon gesagt,

[00:17:33] eine Datenbank oder ein Backend oder ein Frontend etc., dann macht es vielleicht schon Sinn,

[00:17:38] das mitzudenken. Gerade wenn man später auch schon weiß, diese App wird auch mal irgendwann

[00:17:43] das Licht der Welt erblicken und soll mal irgendwie auch mal größer werden oder auch

[00:17:47] mal gehostet werden irgendwo, dann kann man das auch dem Coding-Agenten direkt mitsagen und dann

[00:17:51] legt er das an. Hat natürlich einen gewissen Overhead. Man muss dann diese Container bauen,

[00:17:55] neu starten, vielleicht auch mal aktualisieren etc. Aber lohnt sich, glaube ich, wenn das Ganze

[00:18:03] eine gewisse Komplexität bekommt. Genau, ganz kurze Ergänzung noch. Gibt, glaube ich,

[00:18:08] aktuell so zwei Varianten. Das heißt ganz einfach, ich habe einen Docker-Container,

[00:18:13] den konfiguriere ich typischerweise über so einen Docker-File einfach,

[00:18:17] womit ich den starten kann. Und wenn man so eine Konstellation hat, wie ich eben gesagt habe,

[00:18:23] man hat drei Docker-Container, die eigentlich eine App bereitstellen, dann macht man das

[00:18:27] typischerweise über Docker-Compose. Das heißt, da hat man dann drei Container, die alle irgendwie

[00:18:33] zusammengehören und auch miteinander sprechen müssen. Das heißt, irgendwie Docker über einen

[00:18:37] Docker-File oder Docker-Compose, wenn man mehrere Docker-Container zusammen in einer App

[00:18:42] managen will oder für eine App managen will. Aber auch da hilft euch euer Coding-Agent,

[00:18:48] das sauber aufzusetzen. Wenn ihr sagt, ich habe das jetzt soweit fertig programmiert und das sieht

[00:18:53] irgendwie ganz gut aus, dann kann man ihm auch einfach sagen, mach mir daraus irgendwie ein

[00:18:57] Docker-Compose-Setup und dann baut er das auch relativ gut. Das ist einfach gut durchdrungen,

[00:19:03] das können die Coding-Agenten einfach total gut. Solche Dinge machen das relativ einfach. Da muss

[00:19:08] man selbst gar nicht so tief reingehen. Ja, guter Hinweis. Kann man also auch

[00:19:12] nachträglich machen. Muss man jetzt nicht von Tag eins machen irgendwie, aber sobald es vielleicht

[00:19:15] darum geht, das Ganze mal irgendwo anders laufen zu lassen, macht es glaube ich Sinn. Was man glaube

[00:19:19] ich auch braucht, zumindest ist es bei mir auf dem Mac, man muss sich dann diese Docker-Umgebung

[00:19:22] auch selber einmal runterladen. Also bei docker.com, glaube ich, kann man sich dann entsprechend was

[00:19:27] installieren, sodass dann diese Docker-Umgebung auf dem eigenen Rechner läuft und die stellt dann

[00:19:32] praktisch diese Umgebung bereit, dass man da halt Docker-Container starten, laufen lassen

[00:19:37] und erstellen kann. Genau, super. Ja, dann können wir auch eigentlich schon zum dritten Schritt

[00:19:44] jetzt gehen. Jetzt haben wir praktisch unsere Software in Git. Wir haben sie vielleicht nicht

[00:19:49] zwingend mit Docker-Containerisiert. Kann man machen, muss man nicht machen. Und jetzt ist

[00:19:53] ja die nächste Frage, wo lässt du denn deine Tennis-App dann irgendwann laufen, Kai? Also hast

[00:20:00] da schon Gedanken gemacht. Genau, ich habe eine Idee. Gehen wir glaube ich auch gleich mal noch

[00:20:06] ein bisschen tiefer darauf ein. Ich glaube aber so, der erste Schritt wäre ja, ich habe hier

[00:20:10] einen Rechner, das läuft auf meinem Rechner. Wie mache ich das? Stelle ich jetzt das der Welt zur

[00:20:14] Verfügung? Das wäre natürlich der eine Weg. Ich habe das hier bei mir lokal laufen und ich schaffe

[00:20:20] es irgendwie, dass jemand anderes Zugriff auf meinen Rechner hat, auf die Webseite, die ich

[00:20:25] hier bereit stelle. Das ist ein Weg, den man gehen kann. Der hat viele Nachteile. Zum einen

[00:20:32] muss mein Rechner immer laufen und zum anderen muss der irgendwie aus dem Internet erreichbar

[00:20:38] sein, was ja auch nicht so typischerweise der Fall ist. Ich kann mit meinem Rechner irgendwie

[00:20:43] das Internet erreichen, aber wenn du jetzt Zugriff auf meinen Rechner haben wollen würdest,

[00:20:48] braucht man einen Weg dafür. Das geht auch, aber das wäre so der erste Weg. Ich habe einen Rechner

[00:20:53] bei mir zu Hause, der ist irgendwie in die Welt verfügbar und dann kann man das einfach abrufen.

[00:20:59] Sollen wir erstmal einmal so den Überblick machen? Was gibt es für Möglichkeiten und dann gehen wir

[00:21:06] da ein bisschen näher darauf ein. Das eine ist das, ich habe bei mir einen Rechner laufen,

[00:21:13] mache den irgendwie nach außen verfügbar. Das nächste ist dann, es gibt Anbieter,

[00:21:18] die Server im Internet betreiben, die ich mir einfach buchen kann. Es gibt auch zwei Varianten,

[00:21:24] entweder einen virtuellen Server, das heißt ein Teil auf einem Server, auch wieder so eine

[00:21:30] kontainerisierte. Ich kriege halt so einen virtuellen Computer auf einem großen Server

[00:21:34] oder ich kriege einen eigenen Server. Das heißt, jemand hat da tatsächlich einen Rechner einfach

[00:21:39] in einem Rechenzentrum stehen und ich bekomme Zugriff darauf und der gehört dann mir. Das

[00:21:43] heißt, das ist der dritte Schritt. Danach gibt es dann die großen Hyperscaler, die dann nicht

[00:21:52] eigene Server anbieten, sondern tatsächlich Dienste auf ihren eigenen Server, so wie Amazon

[00:21:59] Web Services oder ähnliches. Und dann gibt es noch die Ebene dahinter oder die Ebene da drüber. Da

[00:22:06] habe ich aber tatsächlich gar nicht so einen richtig guten Blick darauf. Das sind dann Plattformen,

[00:22:11] die dir noch speziellere Dienste bieten, Möglichkeiten, bestimmten Code zu hosten,

[00:22:15] etc. Aber vielleicht, keine Ahnung, war das ein guter Überblick? Ich glaube fast nicht so richtig,

[00:22:21] oder?

[00:22:22] Ja, doch, ich finde das gut. Man kann eigentlich ganz platt beschreiben, es wird immer mehr abstrahiert

[00:22:33] eigentlich. Du hast es eben schon gesagt, wenn man sich so einen eigenen Server mietet, sei es

[00:22:40] virtuell oder bare metal, wie man es auch schon so schön sagt, dann bin ich natürlich auch für alles

[00:22:47] verantwortlich. Dann bin ich da wirklich der Hausmeister und muss mich um alles kümmern.

[00:22:50] Betriebssystem-Updates, ist die Festplatte noch, hat die noch genug Platz, habe ich genug RAM da,

[00:22:54] läuft der noch, muss ich den mal neu starten, etc. Das bringt natürlich auch eine gewisse

[00:23:00] Komplexität mit sich, dafür aber auch ganz viele Freiheitsgrade und ist meistens auch ein sehr

[00:23:04] günstiger Einstieg, weil ich kümmere mich ja eh um alles. Wenn ich aber mehr so die volle

[00:23:09] Managed-Service-Plattform haben will, die sich um all das kümmert und ich eigentlich nur meinen

[00:23:14] Quota hochschieben will und den Rest kümmert sich dann jemand anders, dann gibt es auch dafür

[00:23:19] entsprechende Lösungen, die sind dann vielleicht etwas spezialisiert haben, weniger Freiheitsgrade

[00:23:23] sind vielleicht auch etwas teurer. Dafür habe ich aber auch den ganzen Stress nicht und muss

[00:23:26] nicht nachts um drei aufstehen, weil mein Server plötzlich abgestürzt ist, aus welchen Gründen auch

[00:23:30] immer oder von irgendeiner DD- oder US-Attacke attackiert wird. Dieses Spektrum wollen wir

[00:23:36] vielleicht mal so ein bisschen aufzeigen, also vom eigenen Server, was kann ich da machen,

[00:23:40] bis hin zu diesen gemanagten Plattformen. Ich kenne auch nicht alle, ich kann aber ein paar

[00:23:45] zu ein paar auf jeden Fall mal was sagen. Den ersten Schritt, den du gerade beschrieben hast,

[00:23:50] es läuft auf meinem Rechner und ich gebe das irgendwie an die Außenwelt, das ist ja wahrscheinlich

[00:23:54] eher der Ausnahmefall aus den genannten Gründen, der Rechner muss dauernd laufen, ich muss irgendwie

[00:23:59] ein Loch nach außen bohren, sodass Leute von draußen auf meinen Rechner kommen. Das hat natürlich

[00:24:03] auch ein paar Sicherheitsaspekte oder Risiken. Das sieht man vielleicht nicht, aber ist durchaus

[00:24:08] eine gängige Möglichkeit und hat bestimmt auch Anwendungsfälle, gerade wenn man es erstmal testen

[00:24:13] will vielleicht auch, die dann auch günstig sind. Und ich glaube Kai, du hast dich auch damit ein

[00:24:18] bisschen beschäftigt für die Tennis-App, so den ersten Prototypen vielleicht mal nach draußen zu

[00:24:21] bringen. Da wolltest du irgendwas basteln mit so einem Cloudflare-Tunnel, glaube ich. Was ist das

[00:24:27] denn? Müssen wir vielleicht gar nicht in Detail darauf eingehen, weil es schon sehr speziell ist,

[00:24:29] aber durchaus möglich. Genau, warum finde ich das gut? Ich habe natürlich auch, wenn man jetzt über

[00:24:36] eigene Server spricht, dann ist irgendwie Hetzner, DigitalOcean, Yonnos, das sind so die typischen

[00:24:42] Anbieter. Ich habe auch einen kleinen Yonnos-Server, den ich gebucht habe. Das ist auch ein absoluter

[00:24:47] Einstieg, relativ kleiner, nicht sehr leistungsstarker, virtueller Server. Kostet dann aber

[00:24:53] auch 5-10 Dollar im Monat und damit kannst du noch nicht viel machen. Die sind nicht super

[00:24:57] leistungsfähig und vor allem, wenn du viel herumprobieren willst. Ich habe viele App-Ideen

[00:25:02] im Kopf, wo ich Dinge mal ausprobieren will. Deshalb finde ich das ganz charmant. Ich habe

[00:25:07] hier einen alten Mac-Mini rumstehen, wirklich schon zehn Jahre plus auf dem Buckel, wirklich

[00:25:12] schon etwas älter. Da läuft jetzt ein Linux-Betriebssystem drauf und da kann ich einfach

[00:25:17] Dinge ausprobieren. Das ist nicht mein Notebook, der läuft sowieso. Da ist auch ein Setup,

[00:25:24] wie ich meinen Home-Automation mache, meinen Home-Assistant laufen lasse und ähnliches. Das

[00:25:29] heißt, so einen alten Mac-Mini, der verbraucht auch nicht viel Strom, ist leise, der hat keine

[00:25:33] Lüfter, den kann man auch einfach so stehen lassen. Ich finde das total spannend, um einfach

[00:25:38] mal Dinge auszuprobieren. Ich muss keinen neuen Server bei Yonnos buchen und viel drumherum machen,

[00:25:44] sondern das ist ein Rechner, der hier läuft und da kann ich einfach Dinge drauf deployen.

[00:25:48] Jetzt ist die Frage, wie findet man das? Wenn ich google.com oder analytics.com eingebe,

[00:25:55] dann hat man eine Idee oder gibt es einen Weg, wie diese Namen wirklich aufgelöst werden zu

[00:26:01] einem Server, der dahinter steht. Das ist das DNS. Das heißt, wenn ich das in meinen Browser

[00:26:06] eingebe, dann kann der Browser nachgucken, welche IP-Adresse ist das denn? Wo ist denn

[00:26:12] der Server, der mir das ausliefert? In der Realität noch viel komplexer, weil das im

[00:26:17] Zweifel hinter irgendwelchen Anbietern ist, die dann Load-Balancing machen und wo Cloudflare,

[00:26:21] Sicherheitsfeature noch vorhat und all diese Dinge. Aber das ist mal der wichtige Punkt. Ich

[00:26:26] habe hier einen Server und wie erreicht man den denn jetzt? Früher wäre das so dünn DNS gewesen,

[00:26:32] dynamisches DNS. Das heißt, irgendwie hätte ich in meinem Router wilde Sachen konfigurieren müssen,

[00:26:36] damit der Router immer, wenn er eine neue IP-Adresse bekommt, einem Dienst Bescheid sagt,

[00:26:40] ich bin unter einer neuen IP-Adresse erreichbar. Das heißt, wenn du jetzt eine Anfrage an

[00:26:45] kais-homeserver.net hast, dann landet das jetzt auf dieser IP-Adresse und nicht auf einer anderen.

[00:26:51] Völlig kompliziert. Das hat nie Spaß gemacht. Das hat funktioniert, aber ist kein Weg,

[00:26:58] den ich gerne gemacht habe. Deshalb habe ich mal geguckt, wie kriege ich das denn einfacher hin und

[00:27:05] habe die Cloudflare Tunnels entdeckt. Das ist tatsächlich relativ einfach. Cloudflare ist ein

[00:27:12] großer Anbieter, sieht viel Traffic des Internets, weil die auch Sicherheitsfeature machen,

[00:27:19] so ein Content Delivery Network. Die sind ein wichtiger Player in diesem Umfeld und die bieten

[00:27:24] auf einem kostenlosen Level Cloudflare Tunnel an. Das heißt, ich habe eine eigene Domain. Die

[00:27:30] kaufe ich mir. Die kostet 5 Dollar im Jahr oder so. Das ist relativ günstig, eine eigene Domain zu

[00:27:36] machen. Das heißt, ich bin dann erreichbar im Netz unter meiner Domain. Die kaufe ich mir. Da hast

[00:27:47] du aber erstmal nur diesen Namen. Da steckt noch kein Server dahinter oder keine Erreichbarkeit.

[00:27:52] Dann kannst du bei Cloudflare so einen Tunnel beantragen und dann installierst du einen Dienst,

[00:27:57] den Cloudflare-D, also einen Dienst bei dir auf dem Rechner, auf dem Linux-Betriebssystem und

[00:28:07] der baut quasi einen Tunnel zu Cloudflare auf. Das heißt, das eine ist der Server bei mir zu Hause.

[00:28:12] Dann setze ich einen Dienst auf, der einen aktiven Tunnel zu Cloudflare aufbaut. Das heißt, ich muss

[00:28:19] auch in meinem Router nichts offen machen. Ich muss keine Ports aufmachen oder ähnliches. Ich

[00:28:24] werde nicht von außen. Der Server wird nicht von außen erreichbar, sondern dieser Cloudflare-Dienst

[00:28:28] auf meinem lokalen Rechner baut eine Verbindung mit Cloudflare auf und sagt, hier bin ich. Wenn

[00:28:32] du was für die Domain hast, die ich da registriert habe, dann schick das mal zu mir über diesen

[00:28:37] Tunnel, den ich mit dir aufgebaut habe. Dann muss ich bei Cloudflare noch meine Domain registrieren.

[00:28:43] Das ist auch relativ einfach. Das ist jetzt auch kein super Hexenwerk, sondern das ist meine

[00:28:46] Domain, kaishomeserver.net. Die gibt es nicht. Vielleicht muss ich die mal registrieren. Aber

[00:28:52] ich sage dann Cloudflare. Meine Domain ist kaishomeserver.net und ich baue von mir den

[00:28:57] Tunnel auf und dann kann ich so viele Projekte, wie ich möchte, darüber im Internet verfügbar

[00:29:04] machen. Das ist das Spannende, wenn man viel ausprobieren will und viel hin und her testen

[00:29:08] will und hier mal was ausprobieren will und da mal was ausprobieren will. Wenn man jetzt eine

[00:29:12] feste App hat, die immer genutzt werden soll, ist das, glaube ich, nicht der Weg. Aber wenn

[00:29:15] ich heute mal meine Tennis-App, morgen mal die Podcast-App und dann meine Schuhsortier-App

[00:29:21] oder was auch immer mir einfällt, irgendwie mal für andere im Internet verfügbar machen will oder

[00:29:27] meine Essensplanungs-App oder was auch immer in so einer Testphase, dann ist das immer eine

[00:29:31] Subdomain. Das heißt, ich kann dann 20, 30, 40 Subdomains anlegen und das heißt dann, keine

[00:29:37] Ahnung, essensapp.kaishomeserver.net und dann ist das Projekt erreichbar. Eigener Docker-Container

[00:29:43] auf meinem lokalen Server und dann ist das erreichbar. Und wenn ich tennisapp.kaishomeserver.net

[00:29:50] habe, dann ist das andere Projekt darüber erreichbar. Und das alles nur, indem ich von

[00:29:55] diesem Server einen Tunnel aufbaue. Das heißt, wenn ich jetzt morgen früh eine neue Idee habe,

[00:29:59] kann ich den Agenten das bauen lassen, auf meinem Server starten, eine neue Domain anlegen quasi,

[00:30:05] einmal in den Cloudflare einloggen und sagen, meine neue App.kaishomeserver.net und dann ist

[00:30:10] die erreichbar. Das heißt, das ist ein Weg, wenn man viel ausprobieren will und das einfach mal

[00:30:15] nach außen verfügbar machen will, um anderen zu zeigen, um die das mal ausprobieren zu lassen,

[00:30:19] ist das ein Weg, den ich total gut finde. Heißt aber auch, wenn mein Internet weg ist,

[00:30:24] wenn bei mir Stromausfall ist, wenn ich den Rechner aus Versehen aus dem Strom ziehe oder

[00:30:29] aus dem Netz verbanne oder was auch immer, dann ist das einfach nicht mehr erreichbar. Das heißt,

[00:30:34] das geht für Testprojekte, für Dinge, die man einfach mal ausprobieren will, für kleinere

[00:30:38] Sachen. Aber das ist ein total valider Weg. Ich habe den Rechner bei mir lokal im Netz,

[00:30:42] der ist auch nicht sehr exponiert nach außen, weil er halt selber einen Tunnel aufbaut und

[00:30:46] ich in der FRITZ!Box gesagt habe, hier den Rechner bitte voll ins Internet stellen. Deshalb

[00:30:51] ist die Angriffsfläche auch kleiner. Die ist nicht null, aber die ist kleiner und damit habe ich dann

[00:30:56] meine eigenen Projekte im Internet so und kann das mal Leuten zeigen, die es einfach mal ausprobieren

[00:31:01] können und kann morgen wieder was ganz anderes machen, ohne dass ich einen neuen Jonas Server

[00:31:05] brauche, ohne dass ich da bei Jonas neue Domain verknüpfen muss oder was auch immer. Das heißt,

[00:31:11] ein sehr einfacher Weg. Genau für das viele Dinge immer mal ausprobieren, dann auch wieder

[00:31:15] wegschmeißen und wenn das alles funktioniert, dann umziehen auf einen eigenen Server oder zu

[00:31:19] einem Hyperscaler oder was auch immer. Aber das ist so der allererste Schritt. Ich probiere viel

[00:31:24] aus, kann das mit meinem eigenen Rechner machen und da ist Cloudflare Tunnels ein richtig guter

[00:31:31] Weg. Mir gefällt es total gut, hat echt schnell funktioniert, das aufzusetzen.

[00:31:35] Ja, habe ich witzigerweise auch noch nie probiert, aber ich glaube,

[00:31:38] ich echt ein valider Weg, denn genau wie du sagst, man spart sich dann dieses gesamte Setup von einem

[00:31:44] neuen Server. Da gehen wir gleich nochmal drauf ein, brauche aber halt auch einen eigenen Rechner,

[00:31:49] der noch so bei einem rumsteht, der halt dauerhaft dann auch läuft. Das hat auch nicht jeder,

[00:31:52] aber wenn man es hat, praktische Geschichte. Du hast es eben schon gesagt.

[00:31:57] Im Zweifel kurz noch, du könntest es auch einfach, wenn du jetzt mal sagst, jemand anders soll das

[00:32:03] mal ausprobieren, dann kann ich jetzt auch einfach mal für zwei Stunden von meinem Notebook so einen

[00:32:06] Tunnel aufbauen und den dann auch wieder zumachen. Das ist auch ein Weg, wenn ich einfach mal sage,

[00:32:09] jemand soll das testen, kann ich den auch einfach mal für zwei, drei Stunden aufmachen,

[00:32:13] dann testet das jemand und dann baust du es auch wieder ab. Also damit geht schon relativ viel,

[00:32:17] selbst wenn ich keinen eigenen Rechner hierhin stelle. Deshalb finde ich es ganz spannend.

[00:32:21] Ja, und es ist auf jeden Fall auch die bessere Lösung, glaube ich, als ein dickes Loch durch die

[00:32:25] Fritzbox zu bohren und dann ganze Ports freizugeben und dann irgendwann mal zu vergessen, dass man die

[00:32:30] freigegeben hat und das ganze Internet freut sich dann, dass sie jetzt auf deine Webcams im

[00:32:33] Garten zugreifen können. Genau, ja, spannend. So, und der nächste Schritt, du hast es eben schon

[00:32:40] gesagt, wäre dann halt, wenn man sagt, das will ich jetzt auf die nächste Ebene bringen, sich einen

[00:32:45] eigenen kleinen Server zu mieten, entweder virtuell oder halt tatsächlich fest. Ich glaube,

[00:32:50] virtuell ist fast heute schon, würde ich sagen, der Standard. Aber für kleinere Projekte reicht

[00:32:55] virtuell, glaube ich, komplett aus. Selbst die können ja auch viele Ressourcen bereitstellen.

[00:32:58] Wenn man immer wirklich viel Leistung braucht, dann macht es sicherlich Sinn, sich so einen

[00:33:03] dedizierten Server zu nehmen, mit dem man sich nicht mit anderen teilt. Aber virtuell kriegt

[00:33:07] man die schon sehr günstig. Du hast es gesagt, Hetzner ist ja ein deutscher Anbieter, witzigerweise

[00:33:10] auch wirklich weltweit bekannt. Also ich glaube, viele auch in den USA nutzen die, sind bekannt

[00:33:15] dafür, dass sie es sehr günstig bereitstellen, eine gute Qualität bereitstellen, also auch hohe

[00:33:19] Verfügbarkeit, guter Kundensupport. Und das wäre jetzt auch meine Empfehlung, glaube ich,

[00:33:22] für ernstgemeintere Anwendungen und auch gerade in diesem virtuellen Bereich sehr günstig. Dann

[00:33:30] meldet man sich bei Hetzner an, hinterlegt eine Kreditkarte, sagt, ich hätte jetzt gerne einen

[00:33:34] Web-Server mit dem und dem Betriebssystem, so und so viel Rahmen, so viel Festplatte brauche ich.

[00:33:39] Und dann wird er innerhalb von Minuten bereitgestellt und man kann sich in diesem

[00:33:42] Web-Server dann anmelden. Üblicherweise über das Terminal dann auch. Stellt man dann praktisch eine

[00:33:51] Verbindung her, landet dann im Terminal von dem Server und muss dann da rummachen. Und spätestens

[00:33:56] da ist man dann auf die Kommandozeile angewiesen. Das heißt, so eine Servereinrichtung, Verwaltung

[00:34:00] bringt dann auch eine gewisse Komplexität mit sich. Auch da kann einem sicherlich ein Coding-Agent

[00:34:05] helfen, entweder indem man einem vorschlägt, was soll ich da jetzt eingeben? Oder man installiert

[00:34:10] sogar den Coding-Agenten auf dem entfernten Rechner und lässt ihn dann da machen. Das hat

[00:34:14] natürlich auch ein bisschen die Gefahr, dass der Coding-Agent vielleicht Dinge tut, die man

[00:34:17] vielleicht nicht möchte. Aber kann sicherlich auch helfen, was die Ersteinrichtung angeht und

[00:34:23] wo es vielleicht noch nicht so sicherheitsrelevant ist. Und spätestens da kommt dann ja wieder Git

[00:34:27] ins Spiel. Oder auch GitHub. Irgendwie muss ich ja jetzt meinen Code, der auf meinem Rechner liegt,

[00:34:32] irgendwie da hinbringen, damit er da auf dem entfernten Server läuft. Und spätestens da

[00:34:37] macht es Sinn, mit Git zu arbeiten, sich ein Repository auf GitHub anzulegen, wo man dann den

[00:34:44] Code entfernt hat. Denn dort kann man sich den Code dann wieder abholen, um ihn dann auf dem

[00:34:48] entfernten Server dann wieder auszuspielen. Man spricht dann auch mal Git-Clone oder Git-Pull,

[00:34:53] je nachdem. Und dann kann ich den Code auch dann da wieder zum Laufen zu bringen. Aber dann habe

[00:34:58] ich ja wieder das Problem, du hast es eben schon beim Thema Docker erwähnt, da muss ich erst mal

[00:35:01] die ganze Software installieren, die ich brauche. Vielleicht brauche ich eine Datenbank, vielleicht

[00:35:04] brauche ich einen Web-Server, vielleicht brauche ich ein SSL-Sicherheitszertifikat. Ich muss

[00:35:09] irgendwie vielleicht Python oder eine andere Laufzeitumgebung nachinstallieren. Ich muss mich

[00:35:13] um die ganzen Abhängigkeiten kümmern. Ich muss die richtigen Versionen installieren. Und das ist

[00:35:17] genau das, wo einem Docker dann halt viel abnimmt. Weil dann würde ich halt nur noch Docker installieren,

[00:35:21] nehme den Docker-Container rein, da sind die Abhängigkeiten schon beschrieben. Und dann hätte

[00:35:25] ich halt da das Problem dann über Docker gelöst. Das soll nicht heißen, dass das nicht auch geht,

[00:35:30] aber bringt natürlich so ein eigener Server eine ganze Menge Arbeit und Verantwortung mit sich. Und

[00:35:34] genau aus dem Grund hat man dann überlegt, wie können wir das einfacher machen. Und daraus sind

[00:35:39] ja dann auch die ganzen Hyperscaler entstanden, wie AWS, Google Cloud etc. Da kommen wir gleich noch

[00:35:45] zu. Aber so ein eigener Server ist durchaus eine Alternative, weil sehr günstig und sehr mächtig

[00:35:51] und sehr viele Freiheitsgeräte. Man kann praktisch alles darauf machen, was man möchte und hat

[00:35:54] eigentlich ein dauerhaftes Gerät im Internet. Ja, total praktisch, wenn man kontinuierlich was

[00:36:02] damit macht. Das tut es halt nicht so. Ich deploye da einmal was und ignoriere das dann die nächsten

[00:36:07] zwölf Monate, weil dann ist das, hast du keine Sicherheitsupdate, kriegt man vielleicht noch mit

[00:36:14] rein und so. Aber das ist typischerweise so das Problem. Das veraltet dann, weil man selber dafür

[00:36:19] verantwortlich ist, das zu managen. Und ein Schritt weiter abstrakter, hast du gerade eben schon

[00:36:26] gesagt, sind dann die Hyperscaler, Amazon Web Services, die Azure Cloud, Google Cloud. Das sind

[00:36:32] so die Dienste, die dann da noch ein bisschen drüber sind. Ich benutze das selber tatsächlich

[00:36:39] relativ wenig, um ehrlich zu sein. Ich bin da auch immer noch old school unterwegs. Ich mag es,

[00:36:44] wenn ich einen eigenen Server habe, wo ich dann auch vergesse, den zu administrieren oder besser

[00:36:50] auch nicht. Letztes Mal, na nicht letztes Mal, aber wo ich AWS mal intensiver genutzt habe,

[00:36:58] war tatsächlich jetzt auch schon lange her, in der Corona-Zeit für die Grundschule meines Sohnes. Da

[00:37:04] habe ich ein Jitsi eingerichtet, damit die sich überhaupt mal irgendwie sehen können in der

[00:37:09] Corona-Zeit, die vierte Klasse von der Grundschule. Das ist aber auch tatsächlich schon ein bisschen

[00:37:14] her. Aber solche Hyperscaler bieten dir halt die Möglichkeit, tatsächlich komplexere Dienste einfach

[00:37:23] als Dienst in Anspruch zu nehmen. Das heißt, du kannst dann beispielsweise eine Datenbank einfach

[00:37:28] als Datenbankdienst da dir dazuklicken und hast dann halt einen Datenbankdienst. Das heißt,

[00:37:35] eine Datenbank, die ist öffentlich oder die ist dann im Internet erreichbar. Und das geht für ganz

[00:37:43] unterschiedliche Dienste. Hast du da mehr Erfahrung? Kannst du ein bisschen was dazu

[00:37:46] erzählen, was die so bieten an Featuren? Ja, man kann sich das, glaube ich, vorstellen wie

[00:37:51] so einen riesen Lego-Kasten. Alles, was ich mir sonst selbst installieren müsste auf so einem

[00:37:55] eigenen Server, stellen die praktisch als fertige Anwendungen bereit. Und man kann sich das praktisch

[00:38:00] zusammenbauen oder zusammenklicken und sagen, ich brauche hier einen kleinen Rechner, dann brauche

[00:38:04] ich eine Datenbank, dann brauche ich noch irgendwie einen Ablageort für ein paar Dateien. Und Amazon

[00:38:08] kümmert sich dann aber im Hintergrund, dass das Ganze läuft, dass das Ganze sicher ist,

[00:38:12] dass das nicht abstürzt etc. Die stellen praktisch nur die Anwendung bereit, auf die man

[00:38:15] dann einfach zugreift. Und das ist ja, glaube ich, auch warum das auch wirklich viele größere

[00:38:20] Unternehmen nutzen, weil du hast dann dieses ganze Infrastrukturmanagement nicht mehr. Du kannst

[00:38:24] dich dann auf deine App konzentrieren und weißt, die Datenbank im Hintergrund läuft. Die stürzt

[00:38:28] auch nicht ab. Die muss natürlich groß genug konfiguriert sein etc. Ich selber habe jetzt keine

[00:38:33] eigene. Wir nutzen immer nur Bausteine davon, aber ich habe jetzt selber keine komplett eigene App bei

[00:38:38] AWS oder Google Cloud oder Azure laufen. Aber wir nutzen ausgewählte Dienste. Zum Teil, weil wir es

[00:38:46] müssen, weil wir haben eine Anwendung, die mit der Amazon API im Bereich E-Commerce arbeitet und da

[00:38:51] laufen halt manche Sachen auch nur über die AWS Bausteine, zum Beispiel eine Message Queue oder

[00:38:57] so ein Event Stream Services etc. Und wir nutzen natürlich auch dieses Bedrock-Modul von AWS. Da

[00:39:05] stellen die halt KI-Anwendungen bereit oder Sprachmodelle bereit. So nutzen wir halt auch,

[00:39:09] weil wir wissen, dann bleibt das Ganze im Amazon-Ökosystem. Es ist sicher. Die Daten

[00:39:13] werden nicht für irgendwelche anderen Trainingszwecke missbraucht. Punktuell nutzen wir

[00:39:19] dann halt ausgewählte Services. Aber das lässt sich halt Amazon auch sehr gut bezahlen. Das muss

[00:39:23] man auch dazu sagen. Das ist nicht billig. Also wenn man seine eigene große App auf Amazon hostet,

[00:39:28] zahlt man sicherlich ein Vielfaches von dem, was man hätte, würde man das Ganze auf dem eigenen,

[00:39:33] selbst gehosteten Server betreiben. Also die ganzen Vorteile, die man da bekommt,

[00:39:38] die muss man dann meistens auch irgendwann bezahlen. Spätestens dann, wenn man viele

[00:39:42] Ressourcen von Amazon in Anspruch nimmt. Große Datenmengen, viel Traffic, große Datenbanken etc.

[00:39:48] Dann wird es sehr schnell teuer. Auf der anderen Seite bietet AWS oder auch eigentlich alle

[00:39:52] Cloud-Anbieter auch ein sehr großzügiges Freikontingent an. Also die haben eigentlich

[00:39:56] bei fast allen Diensten, würde ich glauben, irgendwie so ein

[00:40:00] einen kleinen Bereich, den man kostenlos nutzen kann, bis zum gewissen Grad. Und da kann man dann

[00:40:04] schon kleinere Apps durchaus für einen schmalen Taler oder vielleicht sogar umsonst laufen lassen,

[00:40:10] auch bei Cloudflare. Auch Cloudflare entwickelt sich immer mehr eigentlich zu so einem

[00:40:14] vollständigen Cloud-Anbieter. Und da laufen ja auch Teile unserer Cast-Hubber, also unserer

[00:40:20] Podcast-App. Und bis ich da den ersten Euro bezahlt hatte, hat es lange gedauert. Also

[00:40:25] da konnte ich wirklich schon viel machen und viel tun, bis ich da überhaupt was bezahlt habe. Also

[00:40:30] es ist auch super praktisch für den kleinen, einfachen Einstieg, wenn die Projekte noch

[00:40:35] keine bestimmte Größe haben. Insofern kann man sich das durchaus angucken. Und jemand,

[00:40:39] der keine Lust hat, sich um das ganze Server-Management zu kümmern, der ist da sicherlich

[00:40:43] auch besser aufgehoben, würde ich sagen. Ja, wie du eben gesagt hast, die lassen sich das

[00:40:51] gut bezahlen, weil im Hintergrund halt auch sich jemand um den Update der Server kümmert,

[00:40:56] dass die Dienste alle aktuell sind, dass die laufen, dass die Backups laufen und das sind

[00:41:00] halt Dinge, die man sonst mit eigener Zeit oder eigenem Personal dann in größerem Kontext

[00:41:05] investieren müsste. Und so zahlt man es halt mit den Diensten. Das ist immer eine Abwägung. Wo ist

[00:41:10] der Sweet-Spot? Genau für mich will ich ein eigenes DevOps-Team haben, was sich dann wirklich

[00:41:15] um meine Server kümmert und all diese Dinge. Oder letztendlich auch Administratoren oder

[00:41:20] betreibe ich es auch in der eigenen Infrastruktur und all diese Dinge. Aber ich glaube, worüber wir

[00:41:27] gerade so sprechen und wo wir auch glauben, dass unsere Hörer unterwegs sind, die ersten

[00:41:32] Vibe-Coding-Projekte mal in die Welt bringen, da geht schon richtig viel kostenlos. Weil das

[00:41:38] einfach kleine Dinge sind, die die mit anbieten, wo die Anbieter natürlich die Hoffnung haben,

[00:41:42] ihr startet klein und wenn es dann mal größer wird, dann zahlt ihr auch bei uns. Deshalb ist

[00:41:47] diese ganzen kleinen Themen, die kann man sehr gut am Anfang kostenlos machen.

[00:41:54] Erstaunlich wie viel Cloudflare. Im Tunnel zahle ich jetzt auch nichts. Das kostet einfach nichts.

[00:42:01] Genau. Und neben diesen ganzen Hyperscalern haben sich ja noch ein paar Spezialanbieter

[00:42:07] herausgearbeitet, die dann vielleicht noch ein Stück weitergehen, noch mehr abstrahieren. Zum

[00:42:12] Beispiel nutze ich jetzt relativ häufig für reine Frontend-Geschichten, wo es nur darum geht,

[00:42:17] eine Webseite zu hosten. Dienste wie Netlify oder Vercel, zum Beispiel die AMALYTIX-Homepage,

[00:42:24] die läuft komplett bei Netlify. Da geht es einfach nur darum, die Webseite ohne irgendwelche

[00:42:29] Backend-Systeme ins Netz zu stellen und das Praktische da ist, da verknüpfe ich einfach

[00:42:32] nur Netlify mit meinem GitHub-Account, gebe den entsprechend frei und immer dann, wenn ich was zu

[00:42:38] GitHub pushe, wird die Webseite neu gebaut. Ich verknüpfe einmal meine Domain und das war es.

[00:42:42] Netlify kümmert sich um den gesamten Rest. Die haben dann das SSL-Zertifikat bereitgestellt,

[00:42:47] die haben vielleicht so ein kleines Content-Delivery-Network, die sorgen also dafür,

[00:42:51] dass die Seite weltweit gut ausgespielt wird und schnell erreichbar ist. Ich muss mich da um keinen

[00:42:56] Server kümmern, um kein Hosting. Es ist auch da vieles im kostenlosen Bereich möglich. Erst wenn

[00:43:01] man im Team mit mehreren Leuten ist, dann fangen die an, Geld zu nehmen. Also auch sehr praktisch

[00:43:06] im Bereich Frontend da ist Netlify und Vercel sicherlich stark. Andere Anbieter haben sich

[00:43:12] darauf spezialisiert, eine Datenbank zur Führung zu stellen und vielleicht auch diese ganzen Themen

[00:43:17] wie User-Authentifizierung zu lösen. Da sei mal vielleicht Superbase genannt. Andere gehen dann

[00:43:23] irgendwie noch einen Schritt weiter und integrieren dann das ganze AI auch drin,

[00:43:27] dass ich meine ganze App dann in einem geschlossenen System bauen kann. Da gibt es zum

[00:43:30] Beispiel Repl.it und dann gibt es noch so Sachen wie Fly.io, Railway, Render, die alle jetzt auch

[00:43:37] gerade auf diesen KI-Zug aufspringen und versuchen, da so viel wie möglich den Leuten abzunehmen,

[00:43:41] dass sie sich eigentlich nur noch auf Swipe-Coding konzentrieren müssen. Und alles,

[00:43:45] was im Hintergrund passiert, damit überhaupt so eine App läuft und erreichbar ist, darum kümmern

[00:43:49] die sich auch drum. Aber mit den Letztgedanken habe ich jetzt auch noch nicht so viel Erfahrung.

[00:43:52] Aber ich kenne jemanden, der sehr weit gekommen ist mit Superbase zum Beispiel und da eine ganz

[00:44:00] spannende App gebaut hat. Und die Coding-Agenten kennen sich meistens auch sehr gut aus mit den

[00:44:04] jeweiligen Diensten. Oder selbst diese Dienste bieten dann schon für die Coding-Agenten häufig

[00:44:09] auch dedizierte Dokumentationen. Das sieht man meistens daran, dass man darauf klicken kann,

[00:44:14] hier als Markdown kopieren oder hier an meinen Coding-Agenten senden oder sowas. Dann wissen

[00:44:18] die schon, was zu tun ist, um irgendwas da zum Laufen zu bringen. Genau, das vielleicht mal so

[00:44:23] um den Überblick, den wir heute mal geben wollen. Mehr kann es glaube ich auch nicht sein, mal

[00:44:30] abzuschließen. Was sind denn sonst noch so typische Sachen, die man braucht, wenn man so eine App mal

[00:44:37] wirklich ans Laufen bringen will? Ich denke da gerade an das Thema E-Mail-Versand. E-Mail ist ja

[00:44:44] meistens auch ein Thema, was man irgendwie lösen muss. So eine App muss meistens E-Mails verschicken

[00:44:48] können. Und wenn es nur darum geht, hier ist dein Passwort zum Zurücksetzen oder irgendwelche

[00:44:53] Informationen aus der App herausstellen. Denn das ist witzigerweise ein komplexeres Thema,

[00:44:59] als man denken würde. Man würde ja denken, warum lasse ich das nicht über den eigenen Server laufen?

[00:45:04] Da kann ich mir auch einen Mail-Server installieren. Aber dadurch, dass wahrscheinlich 90 Prozent aller

[00:45:08] E-Mails Spam sind, reagieren andere Mail-Server sehr empfindlich auf irgendwelche Mail-Server,

[00:45:14] die mal eben frisch aufgesetzt wurden. Und deswegen haben sich auch da Anbieter herauskristallisiert,

[00:45:19] die das Problem wiederum lösen. Wir nutzen da zum Beispiel Mailgun. Aber ich glaube,

[00:45:24] du, Kai, hast da schon mal mit Render rumprobiert. Also auch da gibt es viele Anbieter, die das Thema

[00:45:29] E-Mail-Versand speziell lösen, damit die E-Mails am Ende auch im Posteingang des jeweiligen Empfängers

[00:45:36] auch ankommen und nicht im Spam-Feld heran. Ich glaube, das ist so ein bisschen das Problem,

[00:45:40] was die lösen. Ja, ist ja eigentlich ganz einfache Technologie, auch schon uralt. In

[00:45:46] der Theorie setzen wir unseren eigenen Mail-Server auf und verschicken E-Mails. Technisch geht das,

[00:45:51] aber durch die Realität des Internets ist das unmöglich. Also das ist kein Weg,

[00:45:55] den man gehen kann. Um so einen allerersten Test zu machen, kann man mit Sicherheit auch

[00:46:02] einen Gmail-Account nutzen. Gmail-Account, die haben auch so App-Keys. Das heißt,

[00:46:07] da gibt es die Möglichkeit, über Apps zu senden. Aber das ist auch nur so ein allererster Test,

[00:46:13] um mal schnell eine Mail rauszubekommen. Ich glaube, da schmeißen die einen auch relativ

[00:46:17] schnell raus, wenn die sehen, da steckt irgendwie ein Dienst hinter. Das geht schon zu testen. Ich

[00:46:22] habe jetzt Resend genutzt. Das ist einer dieser Anbieter. Das sieht ganz gut aus. Das war relativ

[00:46:28] unkritisch, das irgendwie an den Start zu kriegen. Aber das ist eine Anforderung, die du auf jeden

[00:46:34] Fall sofort hast, wenn du über Nutzeranmeldungen sprichst. Wenn sich Menschen bei dir anmelden

[00:46:39] sollen, vergessen die ihr Passwort und müssen sich irgendwie wieder zurücksetzen können.

[00:46:43] Auf jeden Fall. Was ich noch spannend fände, ich glaube, eine WhatsApp-Integration ist fast

[00:46:49] nicht möglich. Ich weiß gar nicht, ob du dich damit mal beschäftigt hast. Als OpenClaw aufgekommen

[00:46:59] ist, der erste Agent für jedermann und jede Frau, dann war glaube ich der erste Channel,

[00:47:08] um nach außen zu kommen, Telegram-Kanal. Irgendwie eine Telegram-App. Das ging ganz gut.

[00:47:13] Das ging, weil die darauf vorbereitet sind oder weil sie es erlauben, dass Apps darauf schicken.

[00:47:26] WhatsApp wäre natürlich auch ein total interessanter Kommunikationskanal. Ich habe

[00:47:31] mich noch nicht damit beschäftigt, was wirklich geht. Ich glaube, das ist sehr restriktiv. Hast

[00:47:35] du dir das mal angeschaut? Nein, auch nicht so richtig. Bei manchen Apps sehe ich es.

[00:47:40] Jetzt ist man mit Wir kaufen dein Auto beschäftigt und die haben tatsächlich viel über WhatsApp

[00:47:44] kommuniziert. Also irgendwie so ein Business-B2B-Bereich muss es schon irgendwie gehen.

[00:47:48] Aber ich bin mir jetzt auch nicht bekannt, dass man sich einfach ein Paket installiert und zack

[00:47:52] hat man da einen WhatsApp-Bot, der da irgendwie rummacht. Also ganz genau verstanden habe ich

[00:47:55] es auch nicht. Vielleicht eher nur für B2B-Kunden. Das heißt, wenn man nach außen mit Nutzern,

[00:48:00] Nutzerinnen kommunizieren will, dann ist E-Mail halt der Weg. Dafür gibt es aber Dienste. Das

[00:48:05] funktioniert. Irgendwie ist auch kein riesen Hexenwerk. Da sind die freien Pläne. Für so

[00:48:11] kleine Projekte tust du auch die freien Pläne. Da kommst du nicht irgendwie an Limits, wo es

[00:48:15] relevant wird. Und wenn, dann zahlt man halt dafür. Aber auch lösbar. Was sonst noch so

[00:48:22] wichtig ist? Das ist, glaube ich, der Weg. Wir haben eine App auf dem eigenen Rechner gebaut,

[00:48:26] fanden die gut und wollen die irgendwie nach außen bringen. Wenn man mehr arbeiten möchte

[00:48:31] und mehr selber in der Hand haben möchte, ein eigener Server zu Hause oder ein eigener Server

[00:48:35] bei einem Anbieter. Wenn man weniger Arbeit mit den Basics haben will, dann geht man zu einem

[00:48:41] Hyperscaler oder tatsächlich zu expliziten Diensten, die dein Frontend hosten, die dein

[00:48:47] Backend zusammen klicken lassen. Da gibt es, glaube ich, auch echt spannende Geschichten,

[00:48:52] wie solche Dinge, wie auch wirklich komplexe Anwendungen mit solchen Diensten gebaut wurden.

[00:48:57] Ich finde das auch immer sehr beeindruckend. Da muss man sich, glaube ich, aber auch dann gut

[00:49:00] einarbeiten und überlegen, welcher Dienst liefert mir denn was. Aber das sind, glaube ich, so die

[00:49:05] Ebenen, auf denen man unterwegs sein kann, um seine Vibe-gecodete App dann tatsächlich auch

[00:49:10] irgendwie der Welt zur Verfügung zu stellen. Absolut, ja. Wir können ja mal ein paar Beispiele

[00:49:16] nochmal, um das Ganze ein bisschen plastischer zu machen, mal erklären, wie wir es bei manchen

[00:49:19] unserer Projekte jetzt gemacht haben. Wir haben es eben schon mal so ein bisschen angedeutet. Du

[00:49:22] hast eine Tennis-App jetzt vielleicht noch auf deinem Mac Mini, Cloudflare-Tunnel nach draußen,

[00:49:27] schon ist die erreichbar. Wir hatten ja in einer unserer ersten Folgen viel über Mikro-Tools,

[00:49:33] die im Browser laufen, gesprochen. So was kann man gut bei Vercel oder Netlify hosten, wenn man sich

[00:49:39] da um gar nichts kümmern will. Zum Beispiel unsere AMALYTIX-Homepage läuft da, wie gesagt, drauf.

[00:49:43] Und auch da haben wir so ein paar Mikro-Tools in die Homepage eingebaut. Da brauche ich kein

[00:49:46] Backend für. Das läuft alles komplett im Browser. Dafür ist das halt super geeignet.

[00:49:50] Wir können mal so ein bisschen auf eingehen, wie wir das jetzt zum Beispiel bei AMALYTIX machen.

[00:49:55] Da gehen wir wirklich den kompletten anderen Weg. Da läuft alles auf dedizierten Servern,

[00:50:01] also wirklich bare Metal, riesige Maschinen, wahnsinnig viel Rahmen, weil wir da eine große

[00:50:06] Datenbank haben. Die braucht sehr viel Rahmen, die braucht sehr viel Speicherplatz. Wir haben

[00:50:10] eigene Server, die für bestimmte Themen zuständig sind. Der Datenbank-Server gibt es zwei verschiedene.

[00:50:17] Dann haben wir noch einen Backup-Server. Da brauchen wir viel Platz, viel Leistung. Da

[00:50:21] arbeiten wir auch nicht mit Docker, weil wir eigentlich doch diesen Overhead nicht haben

[00:50:24] wollen. Da wird wirklich auf dem Server gearbeitet. Das ist so das Extreme. Da geht es darum,

[00:50:28] viel Leistung bereitzustellen, möglichst kostengünstig. Würden wir das Gleiche auf Amazon

[00:50:33] AWS hosten, würden wir ein Vielfaches zahlen. Das ist Wahnsinn. Aber dafür müssen wir uns auch

[00:50:39] darum kümmern. Wenn der Server nachts um drei abschmiert, dann geht bei uns eine Lampe an,

[00:50:42] dann muss sich einer in den Rechner setzen und gucken, was los ist. Das ist halt der Nachteil.

[00:50:45] Dafür aber sehr performant etc. Und vielleicht bei CastHaber, unserer App, die wir ja nutzen,

[00:50:53] um diesen Podcast zu hosten. Da gehen wir so einen Mittelweg. Da haben wir das Frontend bei

[00:51:00] Cloudflare. Das Backend wiederum liegt auf einem virtuellen Server, der bei Hetzner steht. Da

[00:51:07] wiederum nutzen wir Docker. Und über diesen Docker-Container laufen dann die entsprechenden

[00:51:12] Anwendungen auf diesem Hetzner-Server. Wir haben aber ein paar Dienste ausgelagert. Zum Beispiel,

[00:51:18] dadurch, dass wir sicher gehen wollen, dass alle Podcasts immer erreichbar sind,

[00:51:22] liegen die Dateien dazu. Sprich die Audiodateien. Die liegen nicht auf dem Server von Hetzner. Die

[00:51:27] legen wir wiederum in einen gemanagten Service ab, nämlich von Cloudflare. Die sogenannten R2-Buckets,

[00:51:33] das ist so etwas wie eine Art Dateispeicherplatz. Aber um den müssen wir uns dann nicht kümmern.

[00:51:37] Der ist dann einfach sicher. Wir sorgen auch dafür für Backups. Das wird dann aber von

[00:51:42] Cloudflare gehostet und gemanagt. Wir legen einfach die Dateien da rein und fertig. Oder

[00:51:47] ein paar andere Analytics-Anwendungen laufen dann auch in Cloudflare, sodass eigentlich unserer

[00:51:51] Server, der jetzt bei Hetzner liegt, komplett abschmieren kann. Aber alle Podcasts, die jederzeit

[00:51:56] erreichbar sein sollen, die MP3-Dateien sind immer in der Regel bis Cloudflare immer abschmiert,

[00:52:01] muss schon einiges passieren. Das heißt nicht, dass das nicht auch passieren kann. Es passiert

[00:52:04] ja auch regelmäßig, dass irgendwie auch AWS nicht erreichbar ist. Dann sind wir nicht die Ersten,

[00:52:09] die das Problem kriegen. Genau. Dann ist das ganze Internet down und dann ist man dann auch

[00:52:14] der Andere in der Zeitung. Genau, das stimmt. Dann nutzen wir so einen gemischten Ansatz,

[00:52:20] der, glaube ich, auch sehr gut aktuell zumindest noch irgendwie funktioniert.

[00:52:24] Das ist auch ein wichtiger Hinweis, zu überlegen, welche Teile von meiner App sind denn wie wichtig.

[00:52:32] Die Dateien auszulagern nochmal und anders verfügbar zu machen als die Webseite ist,

[00:52:38] glaube ich, auch einfach ein wichtiger Punkt. Die Dateien werden irgendwie von

[00:52:41] jede Menge Clients runtergeladen und müssen verfügbar sein. Ob die Webseite jetzt mal

[00:52:45] nicht erreichbar ist oder wir mal irgendwie gerade keine neue Folge editieren können oder

[00:52:51] sowas, weil unsere App gerade nicht funktioniert, das ist nochmal was anderes. Das heißt,

[00:52:55] muss man sich auch immer Gedanken machen, wer sind die Nutzer? Was passiert, wenn der Dienst mal

[00:52:59] nicht verfügbar ist? Muss ich da nachts aufstehen oder nicht? Oder ist es eigentlich auch egal und

[00:53:02] ich kümmere mich dann darum, wenn ich sehe? Das ist, glaube ich, ein wichtiger Punkt auch.

[00:53:07] Exakt, genau. Deswegen Dateien und auch der RSS-Feed liegt auch als Datei bei Cloudflare,

[00:53:12] weil das ist ja das Wichtigste, auf den die ganzen Podcast-Apps zugreifen. Da haben wir gesagt,

[00:53:16] da wollen wir eine Hochverfügbarkeit haben. Deswegen nutzen wir da halt auch Cloudflare,

[00:53:19] aber auch das ist billig. Das heißt, da zahlen wir auch nichts für, weil diese Cloudflare-R2-Buckets

[00:53:24] bis zu einem gewissen Grad sind auch die kostenlos. Cloudflare hat dann auch ein

[00:53:28] Content-Delivery-Network. Das heißt, Cloudflare sorgt dafür, dass die Dateien schnell erreichbar

[00:53:32] und verfügbar sind. Auch große Datenmengen. Stell dir vor, wir hätten jetzt hier den

[00:53:36] Gemischtes Hack-Podcast, der millionenfach abgerufen wird. Das kriegst du ja mit so einem

[00:53:40] kleinen eigenen Server gar nicht hin. Da brauchst du halt einen Anbieter, der auch in der Lage ist,

[00:53:44] die Bandbreite zur Verfügung zu stellen. Das merkt man ja auch dann, wenn Tim Pritlove auf seinen neuen

[00:53:50] Podcast online stellt. In den ersten Stunden ist der Server ganz gut. Das merkt man richtig

[00:53:54] ganz gut am Machen. Da dauert der Download relativ lang. Und das geht, wenn man das selber hostet,

[00:54:00] aber wenn man es für andere anbieten will, dann natürlich nicht. Insofern, wie du sagst,

[00:54:04] man muss sich immer überlegen, welche Ansprüche habe ich denn? Sicherheit, Verfügbarkeit, etc.

[00:54:10] Gibt es noch Beispiele? Haben wir einen guten Überblick gegeben? Ich glaube fast ja. Wer

[00:54:20] interessiert ist, hat jetzt eine Idee, womit man anfangen kann und wo man mal anfängt,

[00:54:25] sich einzuarbeiten. Oder fehlt dir noch irgendwas? Ich glaube, das ist es. Jetzt haben wir fast schon

[00:54:31] die Stunde voll. Insofern wollen wir die Leute auch nicht überfordern. Es waren viele sehr

[00:54:35] technische Konzepte, aber an die stößt man halt irgendwann, wenn man wirklich mal irgendwas der

[00:54:41] Öffentlichkeit zur Verfügung stellen möchte. Und ja, alles hat auch da wieder eine steile Lernkurve,

[00:54:47] muss man glaube ich fairerweise auch dazu sagen. Aber wenn man sich einmal damit beschäftigt,

[00:54:51] dann werden viele Dinge einfacher. Und euer Coding Agent ist auch da euer Freund. Er kennt sich in

[00:54:55] all diesen Technologien, die wir besprochen haben, sehr gut aus und kann euch da Stück

[00:54:59] für Stück helfen, entsprechende Dinge einzulegen, einzurichten. Also auch mein Coding Agent hat

[00:55:05] sehr viel mit dem Cloudflare Wrangler Tool gearbeitet, was von eurem Rechner aus alle

[00:55:11] Ressourcen einrichten kann, die man bei Cloudflare braucht. Auch da kann man sich überall helfen

[00:55:16] lassen. Gut, haben wir es glaube ich. Dann würde ich sagen, danke Trotz. Danke Kai. Und dann bis zum

[00:55:29] nächsten Mal. Gerne mal Podcast kommentieren, abonnieren sowieso, Bewertungen dalassen,

[00:55:34] hilft uns auch immer. Und wir freuen uns auch total auf Feedback. Passt das so für euch? Was

[00:55:39] fandet ihr am spannendsten? Wo sollen wir mal tiefer drauf eingehen? Meldet euch gern bei uns.

[00:55:44] Schreibt uns an podcast@kontext.fm. Wir lesen jede E-Mail, freuen uns. Und dann würde ich sagen, Kai, bis zur nächsten Folge. Alles klar. Ciao Trotz. Ciao ciao.