Hallo zusammen und herzlich willkommen bei unserem Webinar Sicher, schnell, schnell, skalierbar wie First Spirit mit einer Cloud -Native Plattform Enterprise Ansprüche erfüllt. Wir wollen euch heute zeigen, wie man den Einsatz moderner, agiler Frontend-Technologien, Enterprise-Anforderungen an Sicherheit, SEO und Performance mit der redaktionellen Power von First Spirit und Cloud-Native Entwicklung unter einen Hut bringen lässt. Dafür werde ich heute unterstützt von René und Fabio, die sich jetzt auch selber vorstellen können und damit will ich auch gar nicht mehr Zeit verbrauchen als notwendig. Insofern, René, weiter mit dir. Ja, super, vielen Dank. Auch von mir nochmal ein herzliches Willkommen zu unserem Webinar First Spirit und Cloud-Native Plattform. Mein Name ist René Zoller. Ich bin Teamleiter des First Spirit-Trump-Teams beim Monday Consulting und ich werde heute durchs Programm führen. Ihr kennt das sicherlich. Ihr startet ein neues Projekt und ihr plant und investiert in einen modernen Tech-Stack und ihr möchtet agil sein und schneller werden in eurem Projekt. Doch dann kommt unweigerlich der Enterprise-Alltag mit seinen komplexen Anforderungen an Sicherheit, SEO und Performance. Was aber, wenn man dieses entweder, ich bin total state of the art, modern unterwegs oder ich muss komplexe Enterprise-Anforderungen an Sicherheit, SEO und Performance erfüllen, wenn man das auch lösen könnte. So wie Jens das eben schon gesagt hat, die redaktionelle Power von First Spirit und gleichzeitig wirklich Cloud-Native Entwicklung anzubieten oder verwenden zu können. Und genau das wollen wir euch heute zeigen. Money Consulting ist mehr als zehn Jahre First Spirit-Partner und wir haben genau dafür eine Referenz-Architektur entwickelt, die diese Versprechen einhält. Und da wir heute viel über Frontend-Technologien sprechen werden, habe ich mir heute auch noch jemanden mitgebracht, nämlich meinen Kollegen Fabio, unseren Teamleiter des Frontend-Teams beim Money Consulting. Da kann ich gar nicht mehr so viel zu beisteuern. Moin erstmal. Ich habe aber noch kurz was beizustellen, das habe ich nämlich eben vergessen zu erwähnen. Sollten im Laufe des Webinars Fragen aufkommen, könnt ihr die direkt über Zoom unten, seht den Punkt Q&A. Da könnt ihr die entsprechend direkt stellen. Triviale Fragen, triviale Fragen klingt doof. Fragen, die nicht für die Masse interessant sind, beantworten wir direkt. Alles andere versuchen wir am Ende zu beantworten, wo vielleicht auch ein bisschen Interesse bei anderen Teilnehmern sein sollte. Schaut euch nicht, haut die Fragen einfach raus und wir gehen dann gerne drauf ein und betrachten zusammen, wie man diese Probleme dann entsprechend lösen kann. Ja, super. Vielen Dank für die Erinnerung. Das hatten wir ganz vergessen. Gut, bevor ich loslege, möchte ich euch nochmal zeigen, wie ich mich mit euch dem Thema, das wir heute haben, nähern möchte. Zunächst werde ich über Herausforderungen jenseits des TMS sprechen und wie sie klassischerweise gelöst werden. Und dabei auch aufzeigen, wo deren Grenzen liegen. Dabei werden wir auch sehen, dass Verspill eine sehr gute Basis für Enterprise-Projekte ist. Aber in der Cloud stößt man unweigerlich auf eine Lücke, auf ein Delta, wenn es komplexer oder dynamischer wird. Anschließend stellen wir unsere Vision vor, wie man dieses Delta, diese Lücke elegant und vor allem State of the Art schließen kann, um das volle Potenzial von Headless-Lösen, und Headless-Lösungen freizulegen und die Versprechen einer echten Cloud-Native-Entwicklung einzulösen. Das soll natürlich nicht nur Theorie bleiben. Mein Kollege Fabio zeigt unseren Ansatz dann auch in Aktion. Das soll auch ein Großteil des Webinars sein. Und zum Abschluss, um das abzurunden, würde ich dann noch einmal die entscheidenden Vorteile einmal zusammenfassen. Gut, legen wir los. Aus unserer Erfahrung heraus ist es so, dass das Verspill sich hervorragend eignet für Enterprise-Projekte. Das liegt vor allem daran, dass an dieser originären, entkoppelten Architektur, in der Content-Erstellung und Content-Auslieferung getrennt sind. Das führt nämlich dazu, dass man potenziellen Angreifern eine minimale Angriffsfläche bietet, vor allem in statischen Projekten. Durch diesen vorgenerierenden Ansatz skaliert Verspill nicht nur hervorragend bei der Content-Delivery. Verspill skaliert auch in anderen Aspekten ganz ausgezeichnet. Ich muss mich ganz kurz unterbrechen. Wir haben hier Feedback, dass zumindest bei einem Teilnehmer oder einer Teilnehmerin keine Präsentation sichtbar ist. Könnten wir vielleicht kurz mal über die Q&A informiert werden, ob das bei anderen Teilnehmern auch der Fall ist oder ob das eine lokale Problematik ist? Okay. Willst du vielleicht nochmal neu teilen, René? Ja, Moment. Da gab es jetzt so ein neues Podcast. Danke für das Feedback. Das wäre jetzt blöd gewesen, wenn wir durch die komplette Präsentation gelaufen haben. Super. Moment. Ihr müsstet das jetzt... Neue Freigabe. So. Freigeben. Jetzt ist die Leiste wieder im Weg. Das haben wir übrigens alles schon vorher einmal ausprobiert. Die Leiste sehe ich jetzt gerade aber auch nicht. Jetzt sehe ich die Leiste. Jetzt sehe ich die Leiste. Ctrl-Alt-Shift-H. Ctrl-Alt-Shift-H. Genau. Okay. Ja, vielen Dank für das Feedback. Das wäre jetzt... Mal kurz nochmal den Gegencheck. Ich sehe es jetzt. Geht es allen anderen Teilnehmerinnen und Teilnehmern auch so? Ich sehe hochgehobene Hände. Ich sehe alles klar. Okay, René, weitermachen. Perfekt. Gut. Woran wir stehen geblieben? Also ich hatte gerade darüber gesprochen, dass dieser vorgenerierende Ansatz von FirstPirit, dass das ein Riesenvorteil gegenüber anderen CMS-Systemen, die da draußen in der Welt rumfliegen ist. Und dass dieses vorgenerierende sich hervorragend für die Content-Delivery eignet, weil man im Zweifelsfall einfach nur ein S3-Bucket, wie man es vielleicht schon kennt, braucht oder einen einfachen Web-Server. Es gibt aber auch andere... Es gibt aber aus meiner Sicht auch noch andere Aspekte, wo FirstPirit ausgezeichnet skaliert. Nämlich, wir haben schon Kunden gelernt, die eine unzählige Anzahl an Projekten in einem FirstPirit-Server am Laufen haben, samt der dazugehörigen Assets. Und auch bei Sprachkanälen haben wir schon so einige Überraschungen gesehen. Das heißt, die Skalierbarkeit von FirstPirit ist auch ein großer Baustein für eine gute Grundlage, um im Enterprise-Umfeld Content zu bearbeiten. Dazu kommt noch die Flexibilität für die Redakteure, die man mit dem Content-Creator hat. Der Content-Creator ist aus meiner Erfahrung eines der schlagenden Argumente, auch im Vergleich zu anderen CMS-Systemen, weil man hier wirklich als Redakteur intuitiv arbeiten kann. Und gleichzeitig hat man aber auch eine Freiheit für die Entwickler, einschließlich auch mittlerweile Headless, was alles gute Argumente im Enterprise-Umfeld sind, um FirstPirit einzusetzen. Dazu kommt dann noch die herausragende Integrierbarkeit über eine äußerst stabile API. Das kennen wir von anderen Herstellern auch komplett anders. Da ist das nicht so stabil mit den ganzen Problemen, die man hat. Und aus meiner Sicht, aus all diesen Punkten macht das FirstPirit zur ersten Wahl für große und komplexe Projekte. Doch ein Problem haben wir, was passiert denn, wenn die Ambitionen steigen und wir nicht mehr zum Beispiel über rein statische Seiten sprechen, wenn wir damit nicht mehr auskommen? Und die erste Antwort auf neue Anforderungen in Bezug auf mehr Dynamik auf der Webseite kann man tatsächlich auch wirklich noch ziemlich weit treiben mit diesem statischen Ansatz. Oder man begegnet dem Ganzen mit einem Hybrid-Headless-Ansatz. Das heißt, man generiert relativ viel vor und nur einzelne Elemente der Webseite werden dann über Headless-Technologien, also über API und JavaScript aktualisiert. Aber was passiert denn, wenn das alles noch viel, viel weiter geht? Also wir sprechen hier über globale Verteilung. Überall auf der Welt soll die Webseite ausgerollt werden. Das Ganze, und das sehen wir vor allem jetzt auch viel in Ausschreibungen mit höchstmöglicher Sicherheit. Also viele Kunden haben zu Recht starke Bedenken im Hinblick auf Sicherheit oder ganz aktuell das Thema Optimierung nicht nur für Menschen und Suchmaschinen, sondern auch für KI-Agenten. Und das alles soll natürlich umgesetzt werden bei einer exzellenten Performance, auch wenn die Seite hochgradig dynamisch ist. Und hier kommen wir dann zu der eigentlichen Frage von heute. Wie macht man denn das zusammen mit First Spirit? Und diejenigen von euch, die schon länger mit First Spirit zu tun haben, die kennen diesen klassischen Ansatz. Man sagt, okay, dann hosten wir die dynamischen Sachen gegebenenfalls selbst. Aber warum ist denn das nötig? Wenn man solche Enterprise-Anforderungen wie zuvor gesehen erfüllen möchte, dann wird statisches Hosting in der Regel nicht ausreichen. Bei sicherheitskritischen Dingen wie zum Beispiel im Login -Bereich oder Anwendung von Drittsystemen reden wir mit unseren Kunden sehr häufig über serverseitige Technologien, über komplexe API-Logik und Middleware. Und da kommen wir nämlich zu dem Delta. Crown Peak bietet derzeit nur statisches Hosting an. Und wo laufen dann diese dynamischen Komponenten? Und das ist genau die Lücke, über die wir heute sprechen und die wir in Projekten sehen. Und wie ich es eben schon angeteasert habe, wie wird das Ganze traditionell gelöst? Man hostet es selbst. Aber das kommt nicht ohne eine große Kehrseite. In der Realität ist das nämlich bei unseren Kunden so, die haben einen Betriebsdienstleister oder setzen irgendwie eine generische Cloud-Plattform wie Azure oder AWS ein. Und in diesem Modell hängt der Erfolg von wenigen Schlüsselpersonen ab. Und da wir hier von Menschen sprechen, ist es sicherlich sehr einsichtig, dass deren Wissen nicht so gut skaliert. Hinzu kommt, dass sich häufig das Wissen auf den Betrieb der Infrastruktur bezieht oder auf Funktionen der Cloud-Plattform. Es gibt also eigentlich keine richtige Applikationsexpertise. Auch wenn man solche Ansätze fährt wie DevOps oder ähnliches, erleben wir das halt immer wieder, dass das halt gerade nicht so funktioniert. Es arbeiten sich einige einzelne Kolleginnen und Kollegen ein in die Applikation und können die dann auch betreuen. Und da haben wir dann trotzdem immer noch das Problem, es gibt konstant neue Anforderungen und die Bedrohungslagen ändern sich auch laufend. Und hier up to date zu bleiben, das ist dann im Tagesgeschäft kaum möglich. Und eine zweite Sache ist, wir reden jetzt hier gerade nur von Betrieb, aber was ist mit modernen Bild-Pipelines? Die Einrichtung von Bild-Pipelines und die Wartung dieser Bild-Pipelines mit Quality Gates und den ganzen Kram, den man da gerne mit einsetzen möchte. Das wird in der Regel dann schnell zu einem Projekt im Projekt. Und was dann unterm Strich bleibt, es wurde in eine Cloud-Lösung investiert, aber de facto liegt die Betriebsverantwortung wieder bei mir und meine eigenen Ressourcen werden wieder damit gebunden. Und das ist genau das Gegenteil von Cloud-Native-Agilität, so wie wir das verstehen und wie wir auch gerne arbeiten möchten. Und aus unserer Sicht brauchen wir deshalb einen fundamentalen anderen Ansatz. Und um genau diesen neuen fundamentalen Ansatz soll es heute gehen, den wollen wir heute vorstellen und zeigen, nämlich die Verwendung einer spezialisierten Cloud-Delivery-Plattform. Und wie der Untertitel das schon so ein bisschen beschreibt, es geht hier um einen echten Paradigmenwechsel. Das Ziel, was wir damit verfolgen, ist, das volle Potenzial von so einer Headless-Architektur auch wirklich auszuschöpfen und die Versprechen, die wir unseren Entwicklerinnen und Entwicklern gegeben haben, nämlich wirklich Cloud-Native entwickeln zu können, dieses Versprechen echter Agilität ohne Kompromisse bei Qualität und Sicherheit einzugehen, das Versprechen wollen wir damit halten. Wir wollen nämlich, dass unsere Teams sich auf die Entwicklung von Features konzentrieren, anstatt auf die Komplexität der Infrastruktur. Schauen wir uns jetzt, bevor ich gleich an Fabio übergebe, das nochmal an, was das für euer Business aus meiner Sicht bedeutet. Nämlich der Wechsel zu einer Cloud-Delivery-Plattform ist aus meiner Sicht ein fundamentaler Wandel in der Art, wie wir digitale Projekte denken. Wie gesagt, es geht nämlich darum, sich von der permanenten Sorge um die Infrastruktur zu befreien und den Fokus vollständig auf den Geschäftswert zu legen. Stellt euch vor, die Themen Sicherheit und globale Verfügbarkeit sind einfach gelöst, gemanagt von Spezialisten, die den lieben Landtag nichts anderes machen als genau das. Und das ist die sichere Basis, auf der alles aufbaut. Was bedeutet das gegebenenfalls für eure Teams oder auch für unsere Teams? Es bedeutet Freiheit und Geschwindigkeit. Die Freiheit, sich auf das Wesentliche zu konzentrieren, Features zu entwickeln und live zu bringen und der automatisierte Workflow, den wir euch gleich zeigen, der ist der Motivation für einen Time-to-Market und für eine Qualität, mit der man mit diesen alten Modellen niemals erreichen kann. Und das auch wiederum, muss nochmal zu betonen, wieder mit höchster Sicherheit. Und diese Agilität kombiniert mit dem Wegfall des operativen Aufwands und des operativen Risikos führt direkt zu spielbar niedrigen Betriebsposten. Was daraus resultiert ist, ihr investiert also nicht mehr in die Verwaltung von Problemen und Risiken, sondern direkt in den Produkterfolg, was auch das Ziel meist unterkunden ist. So schöpft ihr also das Potenzial eurer First Build Investition aus und maximiert damit auch den Wert eurer Investitionen. Und das sind jetzt natürlich alles ganz große, stark Versprechen. Und damit das nicht nur Behauptungen auf Folien bleiben, wollen wir euch live zeigen, wie das Ganze in der Praxis aussieht. Und das ist jetzt der Punkt, wo ich gern an meinen Kollegen Fabio übergebe, der euch in einer Live-Demo vorstellen wird, wie unsere Referenzarchitektur diese Vorteile wirklich zur Realität werden lassen. Ja, Fabio, ich würde sagen... Ja, vielleicht bevor du das... Ich hiefte es hier mal wieder, es geht... Nee, nee, bevor du die Freigabe wegmachst, mach doch noch einmal die nächste Folie auf. Ah, ja. Dann muss ich das nicht selber nochmal... Genau. So, genau. Nur bevor wir... Es wurden ja schon so viele Versprechen gemacht und die Messlatte wurde auf jeden Fall hochgehängt. Bevor wir in Netify mal reingucken und uns ansehen, wie das denn jetzt eigentlich nun wirklich alles funktioniert, möchte ich ganz kurz noch ein paar Worte sagen. Oh, jetzt fragt er mich gerade, welche Sprache ich hier spreche. Also Zoom. Okay, gut. Und zwar, hier sieht man eine grobe Architekturskizze, wie denn jetzt eigentlich First Spirit oder die First Spirit Welt und die Netify Welt und dann auf der rechten Seite der User dann überhaupt zusammen funktionieren und zusammen im Bild stehen. Ich will da gar nicht zu wahnsinnig tief ins Detail gehen, aber wir haben auf der linken Seite den First Spirit Server, der über unser Netify Connect Modul mit der Netify Plattform direkt sprechen kann und wir haben den CAS, der die Daten für uns über die GraphQL-Schnittstelle so aufbereitet, dass wir die Daten aus dem CAS direkt in Netify Connect bringen können und dort haben wir dann auch die Netify-Seite, die wir uns jetzt ein bisschen fokussiert angucken wollen, die wiederum die Möglichkeit haben, auf die Netify-Daten, also auf die Netify Connect-Daten direkt zuzugreifen, als auch auf die Functions. Genau, das ist jetzt nochmal ein bisschen rangezoomt, das gleiche wie eben, bloß, dass wir nochmal ein bisschen mehr sehen, der User ist jetzt in der Mitte. Ich glaube, das ist dieses User-Centric-Design, von dem alle immer sprechen, einfach in die Mitte packen. Und auf der rechten Seite haben wir die gesamte Netify -Welt und auf der linken Seite oben die Crown-Pick-Welt. Da hat sich jetzt auch oben gar nichts dran geändert. An der Netify-Plattform sieht man da jetzt nochmal so ein bisschen mehr und zwar auf der rechten Seite sehen wir oben die Functions, das ist jetzt gerade das Health Funnel, Jobs und was auch immer noch und unten haben wir die Netify-Sites. Und das ist eigentlich auch schon ein wichtiger Punkt von dieser ganzen Netify-Architektur, weil wenn wir uns jetzt gleich mal eine Next.js-App zum Beispiel angucken, aber das kann was auch immer sein, ob es jetzt Angular, React, JavaScript oder nur HTML statisch oder whatever ist, da spielt dafür gar keine Rolle, haben wir die Möglichkeit, das über Netify zu deployen und die Backend-Routen, die viele von diesen Frontend-Frameworks, damit ja eigentlich nicht mehr nur Frontend-Frameworks, aber zum Beispiel Next.js, werden diese, die API-Routen dann als Netify-Funktionen, als Serverless-Functions deployed, das ist dann zum Beispiel Sales Funnel und Jobs und die können dann nicht nur auf die Daten in Netify Connect, was ja die Daten sind, die wir aus dem Cast gezogen haben und synchron halten, sondern jede Webseite, die wir auf Netify hosten, hat die Möglichkeit, auf diese Daten dann zuzugreifen. Und das bietet uns auch die Möglichkeit, sehr einfach Drittanbieter-Archites anzusprechen. Ich meine, den Cast, den haben wir angebunden und das ist ja auch alles wunderbar, aber in der Regel ist es ja dann so, dass im Projekt gibt es dann doch immer einen ganzen Sack voll APIs, die auch noch angesprochen werden müssen, die vielleicht nicht besonders gut erreichbar sind oder die einfach regelmäßig down sind oder lange Response -Zeiten haben oder wahnsinnig schlechte Strukturen, was auch immer, da können wir die Daten in Netify Connect ziehen, in den meisten Fällen oder zumindest auf der Netify-Site gecashed direkt ansprechen und haben damit dann auch deutlich weniger Probleme mit Integration von Dritt-APIs. So, jetzt aber nun wirklich genug geschnackt. Jetzt werde ich, René könnte mal einfach die Freigabe stoppen, falls ich ihm die nicht sowieso klaue und ich werde hier mal direkt, gehen wir mal direkt hier rein. So, ihr seht meine webene Leiste zwar nicht, aber ich werde die für mich mal von das hinfügen. Ihr könnt, müsstet jetzt die Netify-Projektansicht sein. Ich brauche nur einmal einen Daumen hoch oder nicken. Okay, das reicht mir jetzt schon mal erstmal. Gut, und zwar, das ist jetzt die erste Ansicht, die man sieht, wenn man sich anmeldet. Wir sind in Netify drin. Wir haben uns angemeldet, in diesem Fall mit unserem Monday-Consulting-Projekt. Sandbox-Account und kommen dann immer auf diese Projektansicht. Und nur ganz kurz hier drüber geflogen. Wir sehen hier die Bandbreite, die wir diesen Monat schon benutzt haben. In unserem Fall 356 MB von 600 GB. Also da ist noch etwas Luft nach oben. Wie viele Bildminuten von unserem aktuellen Plan, wie viele parallel laufende Bilds und wie viele Team -Members sind insgesamt da drauf schon geonboardet worden. Aber ansonsten haben wir hier unsere Netify. Es sind Projects, es sind alles einzelne Seiten. Das könnte jetzt eine Next.js-Seite sein. Hier haben wir eine Astro-Seite. Hier haben wir eine Extension, die hier gebaut ist. Hier haben wir irgendwas Undefiniertes, was über Bitbucket deployed wurde. Alles haben wir hier an einem Spot. Und das Schöne an Netify ist, oder nein, das erste Schöne an Netify ist, wie einfach es ist, ein neues Projekt tatsächlich zu deployen. Und das möchte ich euch nicht nur erzählen, sondern auch einmal zeigen. Man sieht hier schon die Teste oder die Übungen, aber wir machen das einmal zusammen. In Netify gibt es grundsätzlich zwei Möglichkeiten, Projekte zu deployen. Und zwar an ein Git-Repository geknüpft und die Möglichkeit, es komplett manuell zu machen. Manuell bedeutet, das können wir uns einmal hier angucken, deploy manually. Dann kommen wir hier auf diese Netify-Drop-Seite. Hier kann ich jetzt einfach einen Ordner mit statischen Dateien laden. Und das ist dann einfach nur ein ganz rudimentärer Web-Server. Bloß mit der gesamten Magic, die Netify-Drop-Seite. So bietet mit Caching, Image, CDN und, und, und, wo wir alles noch ein bisschen später zukommen. Gut. Aber wir wollen, das ist dann nicht wirklich das Coole, sondern viel interessanter ist es, wenn wir das an ein existierendes Projekt hängen und ob es jetzt Bitbucket, GitHub, whatever ist, was wir jetzt mal tun werden, ist Start from a Template, was nichts anderes tut, als dieses Template-Projekt in meinen Git-Provider of Choice zu klonen und das dann direkt zu deployen. Wir werden uns jetzt mal hier, hier gibt es eine ganze Menge für verschiedene Architekturen. Ich werde mir jetzt mal hier die Next.js -Plattform-Starter-Kit aussuchen und ich sage hier, ich möchte es gerne in GitHub haben. Da braucht einmal der Oort-Redirect. Das gebe ich jetzt mal hier. Crownpeak Webinar. Dafür wird es jetzt mal egal. Das nenne ich Webinar. Irgendwie, dass ich es wiederfinde. So. Deploy Crownpeak Webinar. Ich habe auch nichts falsch geschrieben. Und was er jetzt gerade tut, ist, erstmal klont er das in meinen Git-Repository und jetzt ist dieses Projekt schon angelegt. Das, was wir jetzt sehen, ist tatsächlich die Ansicht von unserem Netlify-Projekt. Und wir sehen hier oben den Namen, den ich da ausgewählt habe. Hier steht, Prontalcast has not yet been deployed. Es wird von GitHub direkt deployed und wir sehen auch, dass es die Next.js Runtime benutzt. Und während er hier unten, sieht man das, während er hier baut, kann ich dazu noch ein bisschen was sagen. Und zwar, Netlify hat angefangen einfach mit der Möglichkeit, okay, du kannst ein statisches Projekt, irgendeine Single-Page-Application in irgendwas hochladen und deployen oder erst bauen und dann deployen und dann wird es über das globale CDN als wirklich Cloud-Native-Plattform für alle Frontend-Projekte, die man sich vorstellen kann, deployed. Es sind, glaube ich, über 106 Point of Presence weltweit. Das Image-CDN hat da noch eine ganze Menge mehr Points of Presence. inklusive eines Punktes in China. Da sind noch ein paar extra Schritte zu machen, aber Konfigurationsschritte und keine großen aufwendigen. Und ein wirklich großer, großer Punkt zu sagen, ja, natürlich kann man das hier alles selber machen. Ich meine, grundsätzlich ist es nur eine Next.js App, die, klar, kann ich die bauen und dann schmeiße ich die da in meine AWS-Instanz. Aber das CDN, das Image-CDN, das Asset-CDN, das selber zu bauen, ist wirklich, wirklich, wirklich rickelig und will man auch einfach nicht. Und natürlich, was auch einher damit kommt, ist die Ausfallrate, nee, die Availability von 99,95, glaube ich, schreiben wir jetzt immer dran. Ich hatte das gestern mal kurz ausgerechnet. Das ist, wenn man das auf ein Jahr betrachtet, ein Jahr hat es, glaube ich, 8400 Stunden, dann fällt die Seite davon vier Stunden aus. Genau. Und wir sind jetzt sogar schon dabei mit dem Enterprise-Plan, sind jetzt, glaube ich, schon bei 99,99 und dann reden wir, glaube ich, nur noch über 45 Minuten. Also das ist wirklich, wirklich krass mittlerweile. Gut. Dazu auch noch alles noch ein bisschen mehr später. Ich möchte jetzt hier erstmal, bevor wir jetzt hier nochmal in unseren Deploy direkt reingucken, hier haben wir noch dieses Template-Information, wo man sieht, okay, get started locally, npx-Netlify-Clone. Da können wir jetzt so fragen, okay, wieso soll ich das, warum ist das kein Git-Clone? Was soll ich jetzt hier, was hat Netlify da mit einer Z-Link zu tun? Und Netlify macht ja eine ganze Menge Magic und das heißt, von dieser Next-Sage-Runtime habe ich ja schon kurz erzählt, das heißt, alle API-Routen, alle Backend-Routen werden zu Serverless Functions. Die Serverless Functions kann man ja noch mit eigenen Netlify-Functions dann nochmal erweitern, indem man sagt, so, ey, hier habe ich eine Route, die, eine Serverless-Funktion, die soll mir irgendwelche Tarife zusammenrechnen oder whatever. Ich kann aber auch Custom-Rerouting, die Firewall konfigurieren, whatever. Relativ viel, was für eine Cloud-Native-Plattform in dieser Größenordnung essentiell ist und offensichtlich. Aber wenn man dann lokal damit arbeiten will, dann hat man das ja alles gar nicht, wenn man einfach nur die Next.js-App startet. Man hat das mit bekommen, aber alle diese Features auch lokal, wenn man hier an dieser Stelle einfach über Netlify-Clone, das Repository-Clone, was das tut, ist auch dann das direkt zu starten und die Serverless-Functions dann lokal bei sich auszuführen, sodass man die gesamte Netlify-Site mit allem drum und dran lokal wirklich testen kann. Das ist wirklich für Entwickler wirklich wahnsinnig geil, muss ich sagen. So, jetzt gucken wir hier aber einmal in unser Production-Deploy rein. Wir sehen schon Production. Wir haben den Head von Main deployed. Das wurde auch gepublished, weil jedes Deployment, was auch erfolgreich durchgelaufen ist, wird dann gepublished, standardmäßig. Das kann man auch ausschalten. und es wurden keine Exposed-Secrets gefunden. So, da gehen wir mal rein. Wir sehen dann, ich habe Published Deploy for Crown Week Webinar, bla bla bla. Crown Week Webinar ist ein Next.js-Project. Das hat er eigenständig erkannt, auto-detektet. Das erkennt er hauptsächlich an der Package-JSON, an den Config-Dateien und, und, und. Kann man aber auch überschreiben oder manuell setzen. Das geht alles auch. Dann sehen wir nochmal hier die Deploy-Summary. Was ist denn eigentlich alles passiert? Das ist alles sehr transparent. Es wurde eine Function deployed, weil es eine API-Route gibt. Es wurde eine Edge-Function deployed. Edge-Functions unterscheiden sich von normalen Functions nur da drin, dass sie halt wirklich on the edge, also ganz dicht beim User tatsächlich ausgeführt werden und nicht stateless sind und dadurch auch Zugriff haben auf Geolocation und alle möglichen sonstigen Features, die es dann nur bei den Edge-Functions gibt. Genau. Build using the Next.js-Runtime. Es hat insgesamt eine Minute vier gedauert und insgesamte Deploy-Time eine Minute vier Sekunden. Das könnte länger sein, wenn wir noch mehr Build-Steps haben oder Post-Processing-Steps, die wir zum Beispiel durch Extensions hier reinbekommen. Nativa hat einen relativ großen Marketplace, wo es alles möglich gibt, von Accessibility-Scans zu Lighthouse-Reports, Performance-Reports, whatever. Da geht eine ganze Menge und hat dann auch die Möglichkeit, das gebaute Artefakt dann nochmal weiter zu verwenden. All diese Deployments können aber auch failen, ganz besonders je mehr Plug-Ins und mehr Extensions man benutzt, desto wahrscheinlicher ist, dass da einfach mal einer sagt, so ey, nee, das entspricht hier nicht meinem Threshold, das läuft hier nicht und dass ein Deployment fehlt. Netlify baut sowieso, er published nur natürlich die Deployments, die auch erfolgreich durchgelaufen sind, aber natürlich kann es trotzdem mal sein, dass ein Deployment erfolgreich durchgelaufen ist. Es gab keinen Fehler beim Bauen, aber nichtsdestotrotz ist etwas deployed worden, was nicht deployed werden sollte. Und anstatt über Git alles wieder zurückzurollen, neues Deployment, Hotfix-Branch, all so ein Hickhack, haben wir die Möglichkeit in Netlify auch einfach zu sagen, ey, bitte publish mal das und das Deployment und das zeige ich euch jetzt mal hier in einem Projekt, was schon etwas länger existiert, wo wir dann nämlich auch gleich mal genauer reingucken werden und zwar nämlich hier mal Smart Living, Next.js, das sollte ja dem einen oder anderen, sollte Smart Living ja ein Begriff sein. Hier sehen wir jetzt, wir haben vier Production Deploys, eins am 24. September, noch eins am 24. September, eins am 8. Also ich hoffe, es ist nur noch eins. Und jetzt habe ich hier, das letzte hier ist tatsächlich gepublished. Wenn ich jetzt hier in das hier mal reingehe, habe ich hier die Möglichkeit auf Publish Deploy zu drücken. Da fragt er mich dann nochmal, will ich das wirklich tun? Ich mache das jetzt nicht, aber dauert dann wirklich nur wenige Sekunden und der Stand ist zurückgerollt und das standardmäßig auf dem, auf dem Free Tier, mindestens 90 Tage könnt ihr jedes Deployment zurückrollen. Auf Enterprise Plänen ist das dann nochmal ein ganz anderer Schnack. Tatsächlich haben wir einen Kunden, der muss für eine, hat die Auflage für zehn Jahre rückwirkend die, den aktuellen Stand der Website inklusive der Tarife, die wir angeboten haben, auf der Tasche zu haben. Und für diesen Kunden haben wir auch mit Netlify ein Konzept ausgearbeitet, wo er, wo alle Daten in Netlify Connect raus sind, indem sie durch First Spirit gezogen werden und auch die Tarifdaten werden in Netlify Connect gepumpt. Und mit dem Stand von dem Frontend, was auch dann hier in Netlify lebt, haben wir die Möglichkeit, mit nur einem Klick innerhalb weniger Sekunden jeden Stand für die letzten zehn Jahre auf einen neuen, schnell auf den Feature Branch zu deployen, um dann zu gucken, ah, okay, wie sah denn die Seite zu 100% zu diesem Zeitpunkt aus. Wie eine Wayback Machine bloß für diesen einen Kunden. Genau, ich gucke mal kurz hier. Fragenmäßig, nee, da kam keine Frage zwischendurch. Gut, falls es Fragen gibt, unterbrecht mich ruhig zwischendurch. Aber ich glaube gerade sieht das gut aus, ne? Gut, dann gehen wir jetzt einfach mal in unseren, wir sind jetzt hier ja schon in diesem Smart Living Projekt drin. Das ist ja auch alles wunderbar. Wir können uns jetzt, es gibt eine URL, unter der jedes Projekt dann immer eine Netlify.app Domain, unter der jedes Projekt automatisch deployt wird. Da können wir natürlich auch unsere eigenen Domains und DNS-Einträge setzen. Aber diese Netlify.app URLs sind insofern ganz praktisch, weil wenn wir jetzt hier zum Beispiel mal in ein altes Deployment gehen, dann sehen wir hier, haben wir hier diesen schönen Permalink-Button und das ist tatsächlich ein Permalink auf den Stand von diesem Deployment, was wir uns jetzt nach wie vor immer noch angucken können. Das ist besonders cool bei, das hängt so ein bisschen darauf an, davon ab, wie man es konfiguriert hat, aber das ist wahnsinnig schön, besonders für Pull-Requests, weil wenn, Netlify connected ist zu GitHub oder zu Bitbucket dann und ein Pull-Request erstellt wird, baut Netlify automatisch einmal den Pull-Request durch, schreibt das als Kommentar oder hängt das je nach Git -Provider dann da direkt ran und dann siehst du so, ah, okay, hier ist mein Pull-Request, Netlify hat das gebaut und jeder, der das reviewt, der kann dann direkt auf den Link klicken, kann sich das dann live ansehen, wenn er dann da was findet, dann direkt den Pull-Request anpassen. Sehr, sehr, sehr, sehr schön. Funktioniert auch einfach wahnsinnig gut. Gut, wir wollen jetzt aber nicht eine alte Version angucken, sondern wir gucken uns jetzt mal hier, smartlivingnext.netlify.app, da könnt ihr übrigens auch alle drauf gehen. Jetzt muss ich mal gucken, ob hier mein Internet reicht, sieht aber gut aus und dann sehen wir schon eine Seite, die hier für niemanden oder für die wenigsten neu sein sollte, die wunderschöne Smart Living-Seite. bloß jetzt komplett Next.js, also alles, was ihr hier seht, ist Next.js, was die Daten von Netlify Connect bekommt und in Netlify Connect haben wir die synchronisierten Daten aus dem Cast und genau, sieht alles aus, wie man es auch an dieser Stelle erwarten würde. Hier ist jetzt gar nicht so viel mehr zu zeigen, weil es einfach so aussieht, wie es aussehen sollte. Deswegen werden wir einmal zurückbringen und zwar in unser vorher deployedes Template, Crownpick-Webinar, weil da will ich nämlich noch ein, zwei Sachen zeigen. Dann gehen wir hier wieder in ein Crownpick-Webinar und dann haben wir hier unser deployeden Next.js Netlify-Starter. Da will ich auch gar nicht zu tief ins Detail gehen. Das Image-CDN habe ich schon ein bisschen erwähnt. Jedes Image, was in Next.js benutzt wird, wird automatisch von Netlify über die Runtime erkannt, gecached, hochverfügbar, überall auf der Welt angeboten. Genauso geht es aber auch bei Revalidation. Das finde ich ist noch ein Punkt, den ich gerne nochmal ansprechen möchte, ist dieses das Caching von HTTP-Request. Und das ist jetzt auch nicht nur Next.js, das ist jede, gilt für jede App und für jede Technologie, die ihr deployed. Wenn ihr einen Request macht, habt ihr die Möglichkeit, über die Header zu sagen, okay, Netlify soll das bitte global cachen. In diesem Fall, was jetzt hier gerade passiert ist, für das mit einer Time-to-Live von 60 Sekunden und dem Tag Random Wiki, wird hier dieser Patch-Request gecached und wird dann alle 60 Sekunden als Dale markiert. Wirklich schön, besonders wenn man auch mit APIs arbeitet, die man nicht direkt in der Tiefheit Connect integrieren konnte, sondern die wirklich live angefragt werden müssen, aber die trotzdem einfach nicht zuverlässig genug sind, haben wir hier die Möglichkeit, da die Schlinge darum etwas enger zu ziehen. Gut. Mehr möchte ich auf der Template-Seite, wenn euch das interessiert, guckt euch das gerne selber an. crownpeak-webinar.netlify-app ist jetzt ja auch deployed, könnt ihr euch alle angucken, ist öffentlich zugänglich, genauso wie Smart Living Next.js. Ich werde einmal hier die, das einmal in den Chat packen. und hier werden wir auch noch mal den Chat reintun. crownpeak-webinar.netlify.app, alles in einem, crownpeak-webinar, alles in einem Wort und smartliving -next.js.netlify.app sagt das deswegen, weil ich glaube, dass der Chat nicht Teil des, der Aufnahme ist. Oder früher wurde bei Zoom jedenfalls der Chat nicht mit aufgenommen. Gut. So, wenn ich das hinkriege, dann bevor wir, komme ich auch relativ zum Ende. Und Deployment von A bis Z, das haben wir uns jetzt angeguckt. Ich möchte noch einmal grob über ein paar weitere Sachen gehen, Features von Netlify, die für jede Seite angeboten sind. Wir haben natürlich die Möglichkeit, in die Logs zu gucken, über die Next-Year-Stand-Time, die ich jetzt mehrfach angesprochen habe, können wir in die Logs von der Backend-Seite, aber auch von den Edge-Functions gucken. Wir können unsere Log-Drains aktivieren, wenn wir sagen wollen, okay, ihr wollt eure Logs in Hibana, in Sentry, in einem Grafana-Dashboard, wo ihr wollt, hinterlegen. Dann könnt ihr das über die Log-Drains machen. Jetzt hat sich hier aber gerade Roland gemeldet. Jo, ich weiß nicht, ob ich dich irgendwie entmuten muss oder so. Lasst uns die Fragen über die Q&A-Funktion sammeln und dass wir alle zusammen durchgehen, dann haben wir es ein bisschen strukturiert. Also Roland, einmal bitte Q&A-Frage da reinhauen und dann gehen wir gleich drauf ein, wenn die Story durch ist. Top. Und heißt auf Deutsch F&A, falls ihr den Knopf hättet. Ja, F&A, guter Punkt. Gut, genau. Audit Log natürlich auch. Wer hat was getan? Metrics ist aber noch mal wirklich spannend an dieser Stelle. Ihr habt Out-of-the-Box, Project Analytics, was passiert? Also wirklich, was ist innerhalb von Netlify passiert? Wir haben User Metrics, wo wirklich alles Mögliche getrackt wird. Besonders interessant finde ich immer Large Contents for Paint als Frontendler, aber auch First Input Delay oder Interaction to Next Paint. All solche Sachen findet ihr über die Real User Metrics und zwar auch in jeder Edition inkludiert. Function Metrics, also wie gesagt, Next.js, haben wir hier den Server-Händler, wie schnell war der? Hier sehen wir auch noch die Percentiles, 50th, 95th und das 99th Percentile inklusive Average Duration. Alles, was das Herz begehrt. Und vielleicht auch nochmal spannend, wir haben hier Web Security, um nochmal zu gucken, okay, wie sieht das denn hier eigentlich aus mit welcher Traffic wurde automatisch geblockt. Wir haben auch da natürlich die Möglichkeit über Firewall, über Traffic Rules Regionen oder andere Segmente auszublenden oder komplett zu blocken. Genauso haben wir aber auch die Möglichkeit, bestimmte Geolocations zu rate limiten oder das über User -Segmente zu definieren und wir haben die Möglichkeit, die Web Application Firewall jetzt hier gerade Disabled ist, die wird standardmäßig auch enabled in dem Moment, wenn man seine eigene Domain dran hängt, dann enabled er die automatisch. Nur jetzt quasi mit dieser internen URL ist das noch nicht passiert. Und die Domains, ich will hier gar nicht viel zu sagen, SSL-Zertifikat erstellt nicht die Fall für dich, wenn du das möchtest. Und Domains hinterlegen ist auch komplett Walk in the Park, sagt man ja schon. Und auch hier kann man Custom Domains für Branch Deployments hinterlegen, was wirklich sehr praktisch ist und was wir auch bei unserem Produktteam von Centric viel benutzt, sind diese, da haben sie eine richtig eigene Domain für Branch Deployments, um die Staging und Dev-Systeme und das Pod-Systeme alles ein bisschen noch weiter voneinander zu trennen und auch, weil es unterschiedliche O-Ort-Instanzen sind, die dann alle auf einer anderen Domain laufen und das dann mit Netlify DNS wirklich sehr, sehr einfach ist. Gut, ich glaube, eine letzte Sache möchte ich noch zeigen und dann haben wir da ja noch einen Moment Zeit für und zwar, es gibt natürlich noch eine ganze Menge mehr zu entdecken, aber ich möchte euch ja nur den wirklich wichtigen Teil jetzt hier zeigen und das ist das, was ich ja schon mehrfach angesprochen habe, Netlify Connect. Netlify Connect ist einfach ein großer Data Hub. Netlify spricht hier von Layern, ein großes Data Repository, wo wir über Konnektoren Daten reinpushen können und die dann in unserer Deployed Netlify Seite dann auch wieder rausziehen können. Und jetzt sehen wir hier, wir haben jetzt hier gerade vier Layer, zwei für jede Phase, also von DQP haben wir jetzt gerade, fehlt uns das Q, aber D und P haben wir hier und da haben wir immer einen Release und einen Review Layer und hier kann man auch einmal ganz kurz reingucken, jetzt wenn ich mal hier in unseren Pod Release Layer reingehe, sehen wir schon Things from Crown Peak for Spirit Connector, das ist das, was wir vorhin in der Architektur Skizze, das waren diese blauen Boxen, die ihr gesehen habt und jetzt sehen wir hier alle Syncs, die in der vergangenen Zeit gelaufen sind, also immer wenn es Content-Änderungen gibt, haben wir hier Teil-Deployments, die dann über den Cars in Netlify Connect reinkommen und dann hier ankommen und dann seht ihr hier auch 30 Sekunden, 30 Sekunden, 31 Sekunden. Hier hat er mal, da glaube ich war das einer der ersten, wo wirklich alles gepopulated wurde, 2 Minuten 14, aber geht wirklich wahnsinnig schnell und wir haben auch die Möglichkeit über die GraphQL Sandbox direkt mit der Daten, mit Netlify Connect zu interagieren und haben hier in dem Explore, hier erkennt man vielleicht von A, First Build Page, First Build Project Properties, First Build Scheduled Action, erkennt der einen oder anderen vielleicht schon. Genau und ein Satz noch zu dieser zu dem Connector, ich hatte ja ganz am Anfang gezeigt, okay, wir haben es von einem Git Repository gesynkt, wir haben aber auch die Möglichkeit, wenn wir jetzt sagen, okay, wir haben eine komplett statische Seite, die wir aus First Build heraus deployen wollen, dann könnt ihr das auch machen und zwar mit dem Connector von uns, wo dann der gesamte Satz an statischen Daten aus First Build automatisch über dieses Netlify Drop, weil es dafür auch über Extension Points die Möglichkeit gibt, das automatisch zu machen, direkt zu deployen, sodass da überhaupt von Netlify wird da an dieser Stelle nichts mehr gebaut, sondern wirklich für Spirit generiert die statischen Daten, über das Modul werden sie deployed und dann haben wir sie hier in Netlify. Falls wir keinen Headless oder Hybrid-Ansatz mit Next .js oder was anderem fahren wollen. So, René, habe ich was vergessen? Hast du noch was auf den Lippen dazu? Ne, also man sieht jetzt hier ganz klar die Vorteile von so einer Cloud-Native-Plattform. Wir nehmen jetzt, das hattest du, glaube ich, am Anfang sozusagen den Rahmen noch vergessen. Wir zeigen das Cloud-Native-Plattform, am Beispiel von Netlify. Wir haben diese ganzen Sicherheitsfeatures gesehen von Netlify. Das Interessante ist, es gibt nicht nur diese Konfiguration, die man da selber vornehmen kann, sondern es gibt auch ein dediziertes Sicherheitsteam von Netlify, das auch, so wie ich es vorhin gesagt habe, den ganzen Tag nichts anderes zu tun hat, als den Traffic zu scannen, um zu gucken, ob es neue Bedrohungslagen gibt und ob man darauf reagieren muss. Fabio hatte jetzt schon von den Plugins in den Build-Pipelines gesprochen. Das ermöglicht mir einen sehr hohen Grad an Qualität, den ich da auch testbar machen kann. und alles im Allem. Habt ihr gesehen, Fabio ist kein IT-Nerd, kein Server-Administrator, sondern er konnte das alles selbst in wenigen Minuten machen und auch selbst die Anbindung an den Cars ist so gestaltet, dass ihr mit den Daten, die man aus diesem Cloud-Handover von Brownpeak, mit den Daten kann man das auch komplett selber einrichten. Und das alles wird dann am Edge gecached. Das ist das Interessante. Also diese Performance, die man damit bekommt weltweit, die gibt es sonst nirgendwo. Gut. Aber wir wollen noch einmal kurz, so wie ich es angekündigt hatte, noch einmal kurz zusammenfassen, was wir da jetzt sozusagen auch der Bitnob Perspektive auch nochmal drauf schauen, was wir da, Steuerung, Alt-H, Umschalt-H, was wir da gesehen haben. Das Wichtigste für mich, was ihr mitnehmen sollt, ist, dass diese strategische Idee, mit der wir euch heute konfrontiert haben, dass wir damit einen zentralen Spannungsfeld in jedem Enterprise-Projekt auflösen wollen, nämlich den Konflikt zwischen den Bedürfnissen der Redaktion und denen der Entwickler. Die Redakteure benötigen ein stabiles, intuitives System und eine sichere Umgebung, um kreativ und effizient irgendwie zu arbeiten. Und sie brauchen sowas wie ein verlässliches und vielfaches bewährtes System, wie zum Beispiel Verspirit. Und wir können euch das auch wärmstens empfehlen. Die Entwickler auf der anderen Seite brauchen genau diese Freiheitsgrade, die ihr gerade von meinen Kollegen gesehen habt und die Geschwindigkeit. Und Fabio und sein Team wollen gerne mit modernen Tools arbeiten, in einem agilen Prozess deployen. Und diese Prozesse sollen natürlich auch performant sein und skalierbar. Und sie wollen möglichst nichts mit der Infrastruktur zu tun haben. Und auch nicht irgendwelche Tickets schreiben, dass irgendjemand sich in der Infrastruktur darum kümmert, irgendwelche Probleme zu lösen. Sondern genauso, wie es Fabio gerade gezeigt hat, es sind wenige Klicks, es ist qualitätsgesichert vom Hersteller und der übernimmt mit seinen SLA auch die Betriebsverantwortung dafür. Und dieses Spannungsfeld aufzulösen, das ist genau der Kern unserer Lösung. Wir schaffen keine Kompromisse, sondern unser Ziel ist es, eine echte Synergie zu schaffen. Wir wollen beiden Seiten, beiden Welten genau das geben, was sie brauchen und dass sie irgendwie großartig Abstriche machen müssen. Und das Ergebnis, was wir in unseren Projekten sehen, ist nicht nur, dass wir produktiver werden, dass die Produkte besser werden und qualitativ hochwertiger sind, sondern dass wir auch eine höhere Zufriedenheit haben im gesamten Team. Und dadurch, dass wir nicht mehr noch fünf andere Leute, die das als Nebenaufgabe haben, die Pipeline zu betreuen, die Infrastruktur zu betreuen, dass wir die nicht mehr haben, haben wir am Ende sogar niedrigere Gesamtkosten. Und das ist die Vision, die wir mit diesem Ansatz verfolgen. So, ganz viel Input. Damit sind wir auch am Ende unseres Vortrags angelangt, Fabio und ich. Wir hoffen, wir konnten euch wertvolle Einblicke geben, wie sowas funktionieren könnte. Und vielleicht habt ihr auch Interesse, Impulse mitzunehmen für eure eigenen Projekte. Und ja, Fabio, wir freuen uns jetzt auf Rückfragen. Ich bin jetzt auf Roland gespannt. Macht mich jetzt schon ganz neugierig. Ja, genau. Einmal Roland, die Frage ist bis jetzt noch nicht in der Q&A angekommen. Wenn möglich, schreibt die doch bitte da rein. Wir kümmern uns kurz mal um zwei, drei andere Fragen, die an der Stelle eingegangen sind. Erstmal danke René, danke Fabio. Eine Frage, die sich mir als Verantwortlicher für Budget und Team stellt. Welche konkreten Skills benötigt mein bestehendes Entwicklungsteam, um mit diesem Ansatz erfolgreich zu sein? Ist ja ein großes Umdenken oder eine komplett neue Teamstruktur notwendig? Da fange ich mal an. Ne, große Umstellung und ganz komplett neue Teamstruktur brauchst du nicht. Also deswegen habe ich das ja auch gezeigt. Ich als, nur als Frontendler kann dann da wirklich schon wahnsinnig viel tun. Und es ist alles sehr rudimentär gehalten. Nein, nicht rudimentär, ist das falsche Wort. Es ist alles sehr einfach gehalten. Und der Fokus liegt wirklich auf der Developer Experience. Und da hast du wirklich die Möglichkeit, in alle Bereiche einfach einzutauchen, um, ob es jetzt Security oder Metrics oder whatever sind, was wir jetzt ja schon gesehen haben, hast aber auch die Möglichkeit, über Konfigurationsmöglichkeiten dann viel tiefer gehend darauf Einfluss zu nehmen. Sodass da kein komplett neues Team überhaupt benötigt ist, sondern das kann direkt losgehen. Super, vielen Dank. Das genau. Ich möchte vielleicht noch ergänzen. Ja, klar. Das kam so nur nebenbei heraus. Ich würde sogar so weit gehen, wenn man das Potenzial von Netlify Connect zum Beispiel Wenn man das wirklich heben will, dann kommt man sogar mit dem bestehenden Team weiter als bisher. Ja, ähm, Netlify Connect, äh, diese Anbindung, die wir da vorhin gesehen haben, die ist komplett mit Frontend Technologien geschrieben. Also nicht schwergewichtige First-World-Modul, Schrägstrich Java-Entwicklung, Schrägstrich Microservice-Entwicklung, sondern das Anzapfen von APIs, was ja auch in, in großen Enterprise-Projekten, eins der wichtigsten Dinge ist, da kann man tatsächlich, äh, das kann man dann plötzlich, ähm, mit seinen Frontend Entwicklern machen, statt auf schwergewichtige Java-Entwicklung zurückgreifen zu müssen. Ja, und das ist eher ein Punkt, wo ich sage, okay, ähm, ich kann sogar mit meinem Team, äh, noch weitergehend, äh, einsetzen. Und ich meine, letztes Jahr haben wir beim, beim, äh, GitHub, äh, Developer-Server gesehen, dass, äh, über zwei Drittel aller Entwickler, ähm, schon mal mit TypeScript, äh, mit TypeScript gearbeitet haben und sich damit auch ganz wohlfühlen, ähm, und ein Drittel mit Next.js und, ähm, das heißt, da kommt man mit, mit den wirklich verbreiteten Technologien mit Netlify schon einfach wirklich wahnsinnig weit, weil halt diese Serverless Functions genauso aufgebaut sind. Okay, super. Dann machen wir mit der nächsten Frage weiter. Äh, wie würdet ihr diesen Ansatz im Vergleich zu einer eigenen Entwicklung auf einer Hyperscaler-Plattform wie AWS oder Azure bewerten? Wo liegt aus eurer Sicht der entscheidende Vorteil, wenn man doch auf den ersten Blick bei AWS, etc. mehr Kontrolle hat? Ähm, mehr Kontrolle hast du bestimmt, ähm, und jenem tut das natürlich, ähm, und gemacht wird es ja auch. Ähm, aber du musst an dieser Stelle dann wirklich wieder Experte an, äh, einer Million, äh, sich bewegenden Teilen sein, ähm, was wir, ähm, hier mit Netlify alles out of the box bekommen, musst du alles selber machen. Und besonders bei den Themen, ähm, hochverfügbares, ähm, CDN, ähm, Caching, Image Caching, Metrics, ähm, Ausfallsicherheit auch in anderen Ländern, den, den, den Tunnel nach China rein, ähm, das sind alles so viele Punkte, die, um sie anständig zu machen, brauchst du dafür, entweder muss das Know-how in dir gebündelt sein, oder du brauchst echt, äh, ein ganzes Dorf, äh, um das anständig auf die Beine zu ziehen, ähm, Beine zu stellen, so rum heißt das. Ähm, und besonders, wenn es, wenn wir dann von Kunden sprechen, die auch Anforderungen haben an die, an die Ausfallsicherheit und, äh, das auch vertraglich festgelegt ist, dann ist glaube ich auch die, äh, das Selbstvertrauen, äh, schnell dahin, das alles wirklich selber zu machen und dann halt eine Ausfallsicherheit von 99,99 Prozent zu gewährleisten. Ja, also ich kann auch noch ein, äh, äh, noch eine, noch eine Sache aus dem Projekt, äh, äh, äh, ähm, ähm, ähm, ähm, ähm, da, äh, da haben wir ohne Netlify angefangen, da ging es um das Einrichten der Build-Pipelines, ähm, ähm, und das Zusammenspiel zwischen First-Bild -Templates und Frontend-Entwicklung und, äh, äh, äh, die Erfahrung, die ich da, äh, die ich da gemacht habe in diesem Projekt, das hat mich dazu gebracht vorhin, äh, äh, was dazu zu sagen von Projekt in Projekt, ne? Also das kann schnell beliebig komplex werden, weil dann muss, äh, soll noch Snook mit integriert werden, dann soll noch dieses oder jenes Tool mit integriert werden, da gibt es natürlich One-Quick-Solutions, aber das, ähm, das muss halt irgendjemand machen und, äh, das ging dann so weit, dass Wifront und Entwickler in diesem Projekt, die eigentlich für das Umsetzen von Feature, äh, äh, äh, geplant und gedacht waren, sich nur damit beschäftigt haben, diese Build-Pipeline, A, aufzubauen und B, am Leben zu erhalten, weil es dann natürlich auch immer wieder zwischendrin Änderungen und Kleinigkeiten gab, die verbessert werden sollen und, ähm, ähm, da, äh, aus der, aus der Business-Sicht würde ich sagen, die sollen doch lieber das machen, ähm, was sie am besten können, ja? Und, äh, und Werte schaffen und, äh, deswegen, ja, man kann das machen, man hat mehr, man hat mehr Kontrolle drüber, ähm, äh, aber, äh, äh, das, äh, im Umkehrschluss, wenn man es richtig machen will, bedeutet das auch, äh, so wie es Fabio gesagt hat, man braucht dann auch das entsprechende How, Know-how und das muss man aufbauen und das skaliert dann, wenn man das in einem Kopf drin hat, skaliert das halt nicht einfach billig. Ja, ich glaube, im Endeffekt läuft es auf das hinaus, was du vorhin schon gesagt hast, im Endeffekt ist das Attraktive einer SaaS-Lösung ja, dass man gerade mit diesen ganzen organisatorischen Dingen nichts mehr zu tun hat, natürlich kann man all diese Anforderungen auch selber umsetzen, aber halt gibt genau diesen Vorzug, den man sich eigentlich ins Haus holen möchte, wieder auf, um diese Kontrolle zu behalten, die man wahrscheinlich gar nicht braucht an der Stelle. Okay, danke, ähm, so, die Hand von Roland ist immer noch behoben, äh, im Chat ist noch keine Frage eingekommen, ich gebe dir jetzt mal die Möglichkeit zu sprechen, wenn du möchtest und die Frage mehr ist als eine vergessen, die Hand wieder runterzunehmen, dann gerne jetzt einmal entmuten und, ähm, ich haue die Frage in den Chat. Okay, gehen wir mal davon aus, dass es vielleicht eine versehentlich gehobene Hand war. Ich glaube auch. Ja, genau, okay, dann, in dem Fall, ihr habt die Kontaktdaten von René und von Fabio, ihr wisst, wie ihr uns kontaktiert, wenn Fragen sein sollten zu den heute besprochenen Themen, meldet euch gerne bei einem von uns, ähm, die Verbindung entsprechend lässt sich auch herstellen, wenn andere Parteien als Informationsgeber benötigt werden. Ansonsten danke ich euch für die Aufmerksamkeit, danke euch fürs Zuhören und wir freuen uns auf, äh, die nächste Session. Macht's gut zusammen und habt noch eine gute restliche Woche.