Ashley: Willkommen zur nächsten Ausgabe der Taktsoft Campus Podcast. Mein Name ist Ashley Steele und heute habe ich Sebastian Müller und Boris Altman bei mir. Ja. Hallo, Boris. Hallo, Sebastian. Schön, dass ihr Zeit gefunden habt für uns heute Abend. Wie geht es euch? Boris: Ganz gut. 
Sebastian: Hallo. Gut geht's. Ashley: Ja, schön. Bevor wir einsteigen. So ein spannendes Thema heute. Function as a Service. Bevor wir da einsteigen, möchte ich mal bis kurz ein bisschen zu Euer Werdegang und ich sage mal so Euch Spezialgebiet was erzählen. Sebastian, wenn du damit anfängst. 
Sebastian: Mein Spezialgebiet. Das ist die interessante Frage. Ich glaube, es ist eher so mein wo mein Herz schlägt. Und das ist halt in der Softwareentwicklung und in der Art und Weise, wie Teams bestmöglich zusammenarbeiten können. Und das ist halt ein Themenbereich, der ist unerschöpflich. Und früher oder später kommt man dann halt auch auf diesen Bereich. Function as a Service und Services. Aktuell arbeite ich als Cloud Consultant bei der Super Domina GmbH mit Boris zusammen und mein Background ist halt eine langjährige Erfahrung in der Produktentwicklung, Teamleitung und agile Prozesse. Ashley: Ja, sehr schön. Und Boris? Zu deiner Person. Boris: Ja, ähm, ich glaube, ich mache Softwareentwicklung, seit ich denken kann. Ist vielleicht ein bisschen übertrieben, aber seit ich 16 17 bin und nach dem Studium in diversen Rollen und Positionen war ich dann irgendwann eine längere Zeit bei dem Unternehmen, das ja auch ein Software as a Service unternehmen Jimdo. Ähm, habe da auch in verschiedenen Rollen und Positionen zuletzt als CTO ähm. Ja. Viele interessante Dinge erleben dürfen. Und da ist es halt in 2009 irgendwann dazu gekommen, dass wir uns mit dem Thema Cloud auch beschäftigt haben. Und nach meinem Weggang bei Jimdo habe ich dann irgendwann mit ein paar Kollegen die Firma Super Lumina gegründet, wo wir heute halt auch Cloud Consulting im Wesentlichen betreiben. Ashley: Super, vielen Dank. Ja, gut, in der Einführung haben wir Software as a Service gehört. Wir haben auch Function as a Service gehört und ich glaube, ich muss einfach die erste Frage stellen Was ist dann eigentlich Funktion als Service? Wer kann was mir was dazu erzählen? 
Sebastian: Möchtest du, boris? oder soll ich? Oder sollen wir beide probieren, jeweils eine eigene Definition dafür zu finden. 
Ashley: Und dann gucken, ob die Definitionen zusammenpassen oder nicht? Das wird interessant. Aber genau aus. 
Boris: Ja, genau! Starte doch einfach mal. 
Sebastian: Perspektive korrigiere ich mich natürlich immer, wenn ich falsch liege. Function as a Service ist für mich der Logische nächste Schritt, der in der Softwareentwicklung passiert. Vor Jahren oder Jahrzehnten hat man angefangen hardware-Server irgendwo hinzustellen. Dann war eine lange Pause, dann kommt irgendwann ein Container und dann geht es immer weiter. Und der der Schritt oder der Gedanke ist ja, ich will mich nicht um Dinge kümmern, mit denen ich nichts zu tun habe. Ich will irgendwo meine Software betreiben, ich will irgendwo meine Logik haben und jemand soll die hosten, soll die ausführen. Und da es funktion as a Service halt der nächste logische Schritt, weil es die kleinstmögliche Einheit an Software ist. Ich habe eine Funktion, die gebe ich meinem Dienstanbieter und die kann ich ausführen, wenn sie da liegt. Und ich muss mich nicht darum kümmern, wie viel CPU ich Provision ihre, ob ich auch noch für den Server bezahle, wo die drauf ist und wo die ausgeführt wird. Und im Idealfall zahle ich auch nichts dafür, wenn sie nicht ausgeführt wird. 
Boris: Genau. Also so auf technischer Ebene kann man halt sagen function as a service. Ist letzten Endes nur eine Ausführungsumgebung für Code. Und was Sebastian schon gesagt hat der Konsument einer solchen Umgebung muss sich da halt überhaupt nicht um Management Aufgaben auf der Umgebung, Betriebssystem oder Hardware Ebene kümmern. Also insofern ist das halt eine Form von Virtualisierung oder Container isierung. Wobei die Betonung darauf liegt, dass es eine Ausführungsumgebung ist, denn in der Regel hat man auch keine lokale Persistenzschicht, das heißt Anwendungen, die oder oder Funktionen, die in einer function as a Service Umgebungen laufen, sind in der Regel Zustand. Bloß das muss nicht immer so sein, aber das ist schon irgendwie nach der reinen Lehre der Fall. Und man sagt daher, dass eben nur die Geschäftslogik in so einer Funktion implementiert wird. Und wenn ich dann irgendwie Daten präsentieren will, dann muss ich halt irgendwie noch einen externen Datenbank Server oder im besten Fall einen Service mit einbeziehen. Oder ein Netzwerk Dateisystem. Ähm, ja. Was Sebastian auch schon gesagt hat, dass man sozusagen. Letzten Endes dann eben nur die Ausführungszeit berechnet bekommt, anstelle dass man früher sich einen ganzen Server hinstellt, den man kaufen muss oder wo sozusagen die gesamte Betriebszeit, ja wenn man so will, berechnet wird. Wenn man das in der Cloud macht, bekommt man ja eine virtuelle Maschine, dass man halt die ganze Zeit dafür bezahlen, dass sie an ist. Und bei Funktion als Service hat man sozusagen so eine Granularität, dass man eben sagt ja, es wird eben nur die Ausführung des Codes so lange berechnet, wie wie eben diese Ausführung auch stattfindet und. Ja, dadurch, dass man das eben in der Form hat, kann man, kann man eben auch beliebige Skalierung Modelle sich ausdenken. Also man, wenn man wenn man sozusagen den die gleiche Funktion mehrfach zur selben Zeit ausführen will, dann ist das eben möglich, weil man häufiger also häufig ist das halt function as a Service bekommt man irgendwie bei einem Cloud Anbieter. Also wenn man das nicht selbst betreibt. Und dort kann man dann quasi die gesamten Ressourcen dieses Anbieters zur Verfügung bekommen. Und kann kann dann eben auch zum einen gut horizontal skalieren, was daran liegt, dass das ganze Zeug halt Zustands los ist. Und auf der anderen Seite eben auch da nur die ausgeführte Zeit berechnet bekommen. Üblicherweise ist bei function as a Service auch noch ein Charakteristikum, dass das eben event gesteuert ist. Also im Gegensatz zu man hat irgendwo einen Prozess laufen auf einem Server oder in einem Container und der läuft die ganze Zeit und tut Dinge oder tut sie eben auch nicht und wartet darauf, dass das angestoßen wird oder dass eine Anfrage hereinkommen. Das ist bei Function Service eben so, die Funktionen werden gestartet, weil irgendwo anders was passiert ist. Also es gibt sozusagen ein eine Auslöse Moment dafür. 
Sebastian: Es ist halt erst auch nur eine Funktion, die einfach nur irgendwo liegt. Also sie weiß ja im Idealfall gar nicht, wieso sie aufgerufen wird, woher jetzt der Impuls kommt, dass die die Berechnung ausgeführt werden soll. 
Ashley: Das ist auch für mich so ein bisschen zum Verständnisfrage, wenn ich dann meine Funktionen irgendwo in der Cloud habe. Ich kenn das so, ich sag mal so, ich baue meine Anwendung und ich habe alle meine Komponenten zu meiner Anwendung, ich sage mal so zusammen und wenn ich dann ein bisschen platt ausgedrückt los im Cloud diese Funktionen habe, du hast dann das Thema Ereignis gesteuert, event gesteuert, mal kurz angesprochen Boris, aber wie baue ich dann aus dieser einzelne Funktionen meine Anwendung? Wie wie passt das dann zusammen? Sebastian: Na ja, da die die Funktion im Idealfall halt so klein wie möglich ist und einen Single Purpose hat, ist halt die Frage wie orchestrieren ich meine Business Logik oder meine meine Domainen Logik dahinter? Also ich habe ja meistens, wenn ich Software entwickelt, einen gewissen Ablauf von Dingen, die passieren. Ich habe, conditions und Bedingungen, wenn a, dann B, wenn C, dann D. Und so gibt es halt bestimmte Bindeglieder, die man zwischen den Funktionen haben kann, Dinge, die Funktionen miteinander verknüpfen, Methoden, wie man Informationen von A nach B weitergeben kann. Das deckt sich alles eigentlich auch mit den mit den Mustern von lose verzahnten Applikationen. Also ich möchte ja, wenn möglich nicht einen großen Monolithen bauen, sondern ich möchte viele kleine Komponenten haben, die in sich eigenständig sind. Und im Idealfall reißt ein Fehlverhalten in Funktion A auch nicht die Funktion B oder die Funktion C mit nach unten und deswegen gibt es da diese Bindeglieder. Ich kann Dinge in Event Bus reinwerfen, ich kann ein Queing haben, ich kann auf bestimmte Events warten, bis sie passieren. Also es ist eher die die Orchestrierung, dass ich mir Gedanken mache, was ist eigentlich passiert in meiner Anwendung, dass diese bestimmte Logik block ausgeführt werden muss? Ja. Boris: Also da gibt es, da gibt es tatsächlich, wie Sebastian schon gesagt hat, einfach eine ganze Reihe von, von Möglichkeiten oder Mechanismen, die das halt unterstützen. Also in diesem Ökosystem sind einfach bestimmte Frameworks oder oder Tools, sage ich mal gewachsen, die eigentlich ihren Ursprung schon ähm ja, in der in der Ära der der der Microservices haben, weil also letzten Endes ist das was mit Function as also Service passiert ähm ja im Regelfall irgendwie eine ein Zusammenspiel von Microservices. Also das ist nicht zwingend oder nicht nicht nicht zwangsläufig eine eine technische Implikation von Funktion as a Service, aber ähm, die Dienstanbieter und Betreiber von von function as a Service, ähm Diensten, die die wollen in der Regel ja, dass dieser Service irgendwie zuverlässig zur Verfügung gestellt wird. Das heißt, man hat irgendwie bestimmte Limits. Das heißt, die sagen Hey, du bekommst so und so viel Speicher und soundso viel CPU muss das auch vorher ansagen und innerhalb dieses Rahmens kannst du dich auch nur bewegen. So, das heißt so eine klassische alte monolithische Anwendung kann man aus Praktikabilität Gründen normalerweise nicht wirklich in so einem so einer Umgebung von function Service betreiben. Das heißt, es gibt sozusagen so einen natürlichen Impuls oder Reflex zu sagen, ja, okay, dann muss ich. Mein meine alte Anwendung zerlegen. Oder wenn ich eine neue Anwendung schreibe, dann schreibe ich sie direkt im Stil von Micro-services. Aber Micro Services, das das Pattern, das gab's im Prinzip auch schon for function as a service. Das heißt auch, dass es sozusagen die Tools um Microservices zu orchestrieren oder gegebenenfalls auch zu choreografieren. Die gibt es halt auch schon viel länger und das ist eigentlich nicht wirklich eine Cloud Erfindung. Aber was, was Sebastian gesagt hat, da gibt es einfach eine ganze Reihe von Tools oder Frameworks, die das unterstützen. Das ich halt meine ja, dass ich meine Anwendungen auch so Client Diensten komponieren kann. Also was schon gesagt wurde, so was wie Event Busse oder Event Broker. 
Ashley: Hier kannst du dann ein paar Beispiele von diesem Frameworks geben, dann so, also konkret oder Anfang, ein paar Tipps, wo, wo, wo man schauen kann, sozusagen, welche Frameworks es gibt, gibt es die? 
Boris: Etwas, was häufig gemacht wird, ist, dass man zum Beispiel Event Broker einsetzt und da gibt es irgendwie populäre, die man sowohl on Promises hosten kann. Also es kommt da so ein bisschen ist das dann in der klassischen Welt, oder die man eben auch in der Cloud einsetzen kann, wie zum Beispiel Kafka. Ob das eine gute Idee ist, das zu machen, das können wir später vielleicht nochmal diskutieren. Oder eben andere Dienste, die dann eben bei den jeweiligen Cloud Anbieter zur Verfügung gestellt werden. Also wenn man im Beispiel AWS nehmen, da könnte man sowas nehmen wie ein Event Bridge, das ist ein Event Bus oder Chinese. Das ist halt mehr so ein Streaming Service, dass man eben sicherstellt, dass irgendwo an einer Stelle Daten reingekippt werden können und irgendwo an einer anderen Stelle können die dann konsumiert werden. Das klingt erst mal komisch. Ähm, aber das dient dazu, die Dienste voneinander zu entkoppeln. Und trotzdem kann man dann halt seine Software gegen konstante APIs bauen. Das macht dann halt total Sinn. Das heißt, ich kann meine Blöcke unabhängig von den anderen Blöcken, die ich entwickle, trotzdem mit relativ konstanten APIs entwickeln und so sicherstellen, dass die Anwendung nicht auseinanderfliegt. Wenn ich mal irgendwie einen Service verändern will. Ähm, dass das das wären halt so Beispiele. Auf der Ebene der Orchestrierung gibt es verschiedene Pattern, sag ich mal, also man kann halt mit so was arbeiten wie Wiener Service Discovery. Häufig reicht es aber auch schon aus, wenn man in einem Mal in einem Kunst, in einem über den Services liegenden Konstrukt die. Die Dienste gemeinsam, sage ich mal, orchestriert oder komponiert. Da gibt es beispielsweise Tools wie das Serverless Framework, also Serverless ist halt eine Firma. Also das ist halt ein Begriff im Cloud Computing, was sehr nahe an diesem Service dran ist. Aber es ist halt auch irgendwie eine Firma, die so ein Framework bereitstellt, wo ich halt mehrere von diesen kleinen Diensten, diesen Micro Services zu einem Ganzen komponieren kann und miteinander verdrahten kann, wenn man so will, so dass die eine Funktion weiß, dass sie mit der anderen spricht oder mit welchen Datenbanken sie sprechen muss oder eben mit welchem Event Broker oder welchem Bus. 
Ashley: So, ich habe verstanden. Dann, wie gesagt, es gibt diese Möglichkeit, die Functions im Cloud zu haben und es gibt dann Frameworks in Tools, die man benutzen kann, um das das Ganze dann zu orchestrieren, wie du sagtest. Und um das mal zusammenbringen, dass aus den Anwendungen eine Frage, dann, dann, dann baue ich meine Anwendung oder ich schreibe meine Funktionen. Gibt es besondere Herausforderung zum Thema Test? Ja, in der Vergangenheit ist aber so, wie ich das kenne, in Anführungsstrichen, man hat eine lokale Umgebung, ich habe alles auf meine lokale Rechner, ich habe da getestet und dann wird es irgendwann mal irgendwann mal deployed. Gibt es dann dann besondere Herausforderung im Systeme testen in für so ein Funktion as a service? 
Sebastian: Service theoretisch zum Testen nicht. Also wie der Begriff schon sagt, ich habe eine kleine Unit, eine Funktion. Dafür kennen wir Werkzeuge und Methoden, um die zu testen, seit Jahren oder Jahrzehnten. Das nennt sich Unit Tests. Das funktioniert für Function as a Service genauso, wie wenn ich mal eine große Java Library habe, weil ich habe ein kleines Paket. Ich habe einen in sich geschlossenen Block Code, der bekommt Argumente übergeben, der macht eine gewisse Kalkulation und bekommt dann einen Rückgabewert. Das ist das perfekte Setup, um mit Unit Tests die komplette Business Logik zu testen. Was aber nicht mehr so einfach geht wie vorher, dass ich das lokale Setup genauso identisch habe wie mein Produktiv System oder meine Staging Umgebung. Das heißt, ich muss mich daran gewöhnen, dass ich nicht eins zu eins meine Infrastruktur auf meinem lokalen Rechner nachstellen kann. Weil das ist ja mit dem Function Services Ansatz etwas, was ich von einem Dienstleister einkaufe, etwas, was ich vielleicht von Apps kaufe, von Google oder von Microsoft. Und dann muss ich mir halt überlegen, wie teste ich etwas, was wichtig ist oder was der elementare Baustein zu meiner Architektur ist, was ich aber nicht im Lokal habe. Das heißt, ich brauche ein Framework oder ein Konstrukt, mit dem ich Integrations Test schreiben kann und kontinuierlich ausführen kann, wenn ich meine Funktion deployed habe. 
Boris: Also Cloud Anbieter stellen häufig ja so lokale Pendants für Teile ihrer Services zur Verfügung, dass man dann in der Lage ist, das eben auch lokal zu testen. Ja, in der Regel kann man gerade bei function as a Service aber eben auch ein Setup sich aufbauen, das man den Code lokal ausführt und der dann aber mit den Services in der Cloud kommuniziert. Ob das immer praktikabel ist, hängt von Fall zu Fall ab. Aber was eben auch ein gängiges Pattern ist, ist, dass man sagt okay, im Kontext von function as a Service und Serverless, was wir vielleicht gleich mal definieren sollten, kann ich eben auch eine Struktur identische Umgebung relativ kostengünstig noch einmal zur Verfügung stellen. Das heißt ich habe in der Cloud ja mein produktiv System und ich kann aber in der Cloud auch ein Testsystem haben, das sich einigermaßen kostengünstig betreiben lässt und wo ich dann eben auch testen kann, weil ich da halt alle Szenarien genau eins zu eins nachgebildet habe. Ähm, das ist so so ein bisschen. Ich versuche mal so auf diesen Begriff Serverless zu kommen, weil das so ein bisschen eben der Main Shift ist. Function as a Service reiht sich halt in Serverless ein. Und was will Serverless mir eigentlich sagen? Dass ich halt auch die anderen Dienste, die so eine kleine Funktion konsumiert, möglichst eben nicht in einem Kontext betrachte oder betreibe, wo ich alles selber machen muss. Sprich ich habe einen Haufen virtuelle Maschinen mit Datenbanken drauf und dann muss ich das alles selber maintain und skalieren und Software Patches nachlegen. Und so weiter und so weiter. Sondern dass ich halt dann eher sage okay, welche Dienste die eben wartungsfrei sind, stellt mir mein Cloud Anbieter noch zur Verfügung und dann verwende ich stattdessen diese und die haben halt in der Regel oder häufig eben auch genau dieses, dieses Muster von ich bezahl halt nur das, was ich konsumiere. Das heißt, wenn ich eine Testumgebung habe mit relativ wenig Workload, wo ich das alles in kleiner noch mal nachgebildet habe, bezahle ich halt auch entsprechend weniger, weil da nicht die ganze Zeit Loot drauf ist, so dass man das sich eben in der Regel schon leisten kann zu sagen okay, ich habe hier eine Testumgebung, die im Prinzip genauso aufgebaut ist wie meine produktive Umgebung und daran kann ich dann halt auch alle Tests fahren. Also das was, also dass das Toolset, was man so viel Integrations Tests zur Verfügung hat, kann ich dann dort anwenden. 
Sebastian: Das klingt auf den ersten Blick auch irgendwie ich immer komplizierter oder komplexer als es eigentlich ist. Was ich dann immer interessant finde von vom Aspekt her ist zu bedenken wenn ich früher oder wenn ich eine Software Anwendung schreibe, die vielleicht ein HTTP Interface bereitstellt, dann habe ich ja meistens ein HTTP Framework und eine Library, die jetzt auf den Requests hört, die ein HTTP Routing macht. Dann habe ich irgendeinen definierten Händler, der wird ausgeführt und da passiert dann eigentlich erst mal eine Logik drin. Und wenn ich Integration Tests lokal laufen lasse, dann teste ich ja auch immer ein Framework, was ich gar nicht müsste. Also in diesen ganzen Setups mit, dass ich lokal einen Webserver starte, dass ich einen request hin schicke, auch mit welcher Library immer. Ähm, teste ich halt erstmal sehr, sehr viel Code mit, der gar nicht mir gehört. Und ich finde, durch diesen Function as a Service Ansatz kann ich mich wirklich darauf konzentrieren, dass ich nur das teste, was ich auch kontrolliere, nämlich meine Funktion und meine Business Logik. Und ob da jetzt ein HTTP Framework drumherum ist, das entscheidet dann mein Dienstleister oder meine Konfiguration, wie ich das deploye. Aber ich will diesen Layer http, um bei dem Beispiel zu bleiben, eigentlich gar nicht mit in meiner Testsuite drin haben. Boris: Wahrscheinlich ja. 
Ashley: Und ist das dann nicht ein bisschen so, dass man als Entwickler anders denken muss? Ich sage mal so, jetzt nicht von der Technologie her, aber von dem, von dem Mindset ist es so ein Paradigma Shift. Ich ich habe nicht alles bei mir, ich beherrsche nicht alles in Anführungsstrichen. Muss man dann als Entwickler ein bisschen Free your mind und anders denken, wenn man in so einem Function as a Service Umfeld entwickeln will oder in der Entwicklung. 
Sebastian: Dass es stellt alles auf den Kopf. Wahrscheinlich eher. 
Boris: Na ja, das. 
Ashley: Aha. Und wie geht man damit um? 
Sebastian: Es entwickelt eigentlich eine positive Sache. Denn, sage ich mal so Historisch gesehen war es ja mal so, dass man alles lokal auf seinem eigenen Rechner gebaut und getestet hat. Also eben auch die Integrations Tests und dann hat man das nach Produktion deployed.. Und dann kam halt die große Überraschung, weil das Produktionssystem halt irgendwie anders ist. Da kommt es ja irgendwie dieser Spruch her Runs on my machine, aber was nützt es mir, was nützt es. 
Ashley: Mir, wenn es das kenne, ich. 
Sebastian: Nicht mal auf meinem Rechner irgendwie läuft oder funktioniert und sich dann nachher in der produktiven Umgebung ganz anders verhält. Deswegen ist das eigentlich schon seit längerer Zeit ein gutes Pattern zu sagen Nee, nee, ich stell hier sozusagen dieses, diese Umgebung noch ein zweites Mal hin. Und wenn ich eine Aussage haben will, ob alles fehlerfrei ist, bevor ich es wirklich in Produktion bringe, dann muss es halt sich in dieser Umgebung erst einmal beweisen. Und ich würde sagen, dass das eigentlich mittlerweile schon zum guten Ton gehört, das so zu machen. Natürlich kann man irgendwie seine Unit-Tests oder Teile von Integrations Tests auch immer noch lokal machen. Ähm, aber der eigentliche Beweis, dass das auch in Produktion laufen könnte, sollte immer in so einer Umgebung stattfinden. Und von daher ist das eigentlich ein vernünftiger Zwischenschritt. Und wenn man das, wenn man das sowieso gedanklich mit eingebaut hat, dann ist. Dann ist das eben auch gar nicht mehr so ein großer Schritt. Also ich glaube, es ist eher sozusagen diese Der Schritt passiert gedanklich, bevor man vielleicht sogar in die Cloud gegangen ist. Also ich würde das gar nicht so so stark auf ein Cloud Pattern beziehen, sondern eigentlich sollte man auch vorher schon seine Software so entwickelt haben. 
Ashley: Okay. Und dann auch vieles dann verbunden mit dem Cloud. Da braucht man gewisse APIs von von AWS oder Google oder Microsoft, wie du vorhin gesagt hast, Sebastian. Wie sieht es dann mit der Stabilität von dieser API´s aus? Weil ich ich muss natürlich so Vertrauen haben, dass auch diese, diese Dienste oder dieses Umfeld, was zur Verfügung gestellt wird, dann wirklich immer so einwandfrei funktioniert und dann nicht auf einmal so einer API sich verändert. Wie sieht es dann? Oder wie ist eure Erfahrung da zum Thema Stabilität der APIs? Sebastian: Also in der Regel ganz gut. Also die unterschiedlichen Anbieter verhalten sich da unterschiedlich. Wir haben bei AWS beispielsweise die Erfahrung gemacht, dass APIs sich selten. Er gar nicht in ihrer Basis Funktionalität verändert. Sie werden halt manchmal erweitert. Also, dass ich halt neue Funktionen oder Methoden bekomme, die aber an und für sich die Funktionalität der alten API Calls nicht berühren. Wenn es dann einmal was, also wenn, dann sozusagen, indem man das Gefühl hat, dass es irgendwie einen Breaking Change geben sollte, dann bauen die halt eher eine Version zwei der API und die Version eins ist in der Regel auch dann quasi nach nach Release der Version zwei irgendwie mehrere Jahre noch verfügbar. Da hat AWS so ein ganz, ganz guten, eine ganz gute Historie vorzuweisen, die, wie ich finde, da einigermaßen Vertrauen stiftend ist. Es gibt andere Anbieter, bei denen das ein bisschen mehr Wild West zugeht. Ich habe gerade vorgestern da einen Blogartikel gelesen, was Leute teilweise machen, um sich davor zu schützen. Ich will da jetzt keine Namen nennen, einfach weil das von mir sozusagen persönlich nicht verifiziert ist. Aber das muss man sich natürlich dann vorher angucken. Ähm, ich denke, da da gibt es aber eben auch im Netz einfach genügend Referenzen, um um mal zu gucken, welche Anbieter halten es denn mit der API-Stabilität also oder welche Anbieter nehmen es halt da einfach ernst? 
Boris: Und man darf ja dabei nicht vergessen kein Anbieter sollte von heute auf morgen einfach eine API elementar ändern, weil jeder Anbieter Grund Hypothese möchte ja natürlich die Kunden nicht vergraulen. Und wenn sich jetzt schlagartig von heute auf morgen eine API ändert, ist das halt nicht so elegant und deswegen ist auch glaube ich die Gefahr dafür nicht so groß. Ashley: Und vielleicht dann, dann so ganz zum Schluss so eine Frage zusammengefasst Wann ist es dann sinnvoll? Wirklich das Thema Functional Service oder zwei Fragen zum Schluss das wäre die erste. Wann ist es dann sinnvoll, fuction as a Service dann in Betracht zu nehmen und sagen Okay, ich werde mich jetzt damit beschäftigen und wer diese Funktion, dieses Service so nutzen, um meine Anwendung zu bauen, zu orchestrieren. Was ist dann aber so der, der, der der ausschlaggebende Punkt zu sagen okay, ich gehe jetzt diesen Weg, könntet ihr das, ich sage mal so in einer zwei Sätze mal zusammenfassen als das Zusammenfassen Was würdest du dazu sagen? 
Sebastian: Ja, ich würde sagen, das ist halt sinnvoll. Also in Funktion, also Funktionen, Service zu denken ist halt sinnvoll, wenn man, ähm, möglicherweise, wenn man eher in so einer Greenfield Situation ist, das heißt, wenn man ein neues Projekt hat und man die Möglichkeit hat, eben auch Micro Services zu bauen, im Gegensatz zu AH, ich habe so einen alten Monolithen und ich muss den da irgendwie rein dengeln. Das macht wahrscheinlich eher weniger Sinn. Und sinnvoll ist es halt eben dann, wenn man in so einem Kontext in der Lage ist, eben auch komplett in Richtung Serverless zu denken. Das heißt, wenn die anderen Komponenten eben auch eher service full konsumierbar sind, also im Sinne von das sind wirklich Services, die von dem Anbieter konsumieren kann und ich brauche mich dann um die Maintenance nicht mehr zu kümmern, weil das ist so das eigentliche Versprechen, das ich ja habe, ist, ich kümmere mich um die Business Logik, die ich bauen will und um um den Code, der diese Logik modelliert. Und ich muss mich halt nicht mehr um diese diesen ganzen operativen Teil kümmern. So, und wenn ich möglichst viele Dienste in diesem Zusammenspiel komponieren kann, die, die ich einfach nur on demand benutze und bezahle und wo ich eben keinen Maintenance Anteil mehr habe, dann dann ist es halt besonders sinnvoll, eben auch in dem Zusammenspiel Funktion as a Service zu benutzen. 
Boris: Und dazu würde ich auch noch sagen, wenn man seine Business Domäne kennt. Also ich muss wissen was passiert. Ich muss meine Logik runtergebrochen haben. Ich muss wissen, wie Informationen von A nach B übergeben werden. Und ich muss halt auch den Anspruch haben, nachhaltig Software entwickeln zu wollen und zu betreiben. Also ich glaube, wenn ich jetzt nur für ein privates Projekt irgendwie diesen diesen Mehraufwand auch betreiben würde, wäre das sicherlich eine Verschwendung an Ressourcen. Aber ich glaube, wann immer man etwas wirklich kontrollieren oder oder ownen und verantworten möchte und damit nachhaltig umgehen möchte, ist das auf jeden Fall der richtige Weg. 
Ashley: Die Kleinen und vielleicht dann die, die, die, die. Die letzte Frage. Wenn ich ein Entwickler bin und möchte jetzt, ich sage mal so in diese Richtung gehen, wo soll ich dann anfangen? Gibt es irgendwelche Tipps von dem Sebastian, wo du sagst okay, beschäftige dich mit einem bestimmten Framework oder wie steigt man ein in diesem Thema? Sebastian: Das war jetzt der Punkt, wo ich nicht sagen durfte Bei uns anrufen und einen Workshop mieten? 
Ashley: Ja, richtig. Genau. Das muss einen zweiten, es muss eine zweite Antwort dazu geben. Sebastian: Aber das ist halt immer so ein bisschen davon abhängig, wie lernt jede Person für sich selber? Also ich bin ein ganz großer Fan davon, mir Dinge anzugucken, mir Beispiele anzugucken. Ich war früher sehr, sehr großer Fan von diesen Kochbüchern, die es in der Softwareentwicklung gab, wo es ein Use Capes gab, ein Tutorial. Und dann guckt man sich an, wie andere Menschen etwas bauen und probiert es zu verstehen oder adaptiert das. Ja. Boris: Ja. Also wenn, wenn jemand sozusagen noch gar keine Berührung damit hatte und der befindet sich jetzt irgendwie vor der Wahl. Ja, welchen Cloud Anbieter soll ich nehmen? Und diese ganzen Fragen? Sie hat ja auch davon ab. Ich habe vielleicht schon einen Cloud Anbieter, dann kann ich einfach mal gucken, ob ich das Angebot dann nutzen kann. Wenn er das jetzt noch nicht hat, würde ich vielleicht sagen, man könnte es mal mit AWS ausprobieren. Nicht weil ich jetzt irgendwie Werbung dafür machen will, sondern da. Das ist der Marktführer und man findet einfach im Netz unwahrscheinlich viele Ressourcen für den Einstieg. Und dann kann man sich immer noch überlegen, ob man die Art und Weise, wie es bei Apps gemacht wird, ob man das MAG oder nicht. Aber es gibt halt das, was ich vorhin genannt hatte, zum Inhalt dieses sogenannte Serverless Framework, was einem den Einstieg stark erleichtern kann und wo es auch unglaublich viele Beispiele gibt für von Hello World bis komplexere Setups. Ähm, oder man guckt sich in dem Kontext vielleicht einfach mal das CDF an, das das Cloud Development Framework, mit dem das auch sehr einfach ist, irgendwie function as a Service mal auszuprobieren. Ähm, das wären so Einstiegspunkt. Weil. Weil es einfach für diese Frameworks und Tools und einfach aufgrund der großen Verbreitung von AWS unheimlich viele Ressourcen im Netz gibt, wo man sehr schnell einen Einstieg findet. Da man wie gesagt schon in einer anderen Situation ist und sein Cloud Anbieter schon ausgewählt hat, dann macht es natürlich Sinn sich einfach das Angebot dort anzuschauen. Also alle großen Cloud Anbieter haben da was im Programm. Ashley: Super. Ich glaube, das war eine sehr, sehr gute Erklärung. Funktion as a Service, um was geht es da überhaupt? Und auch um so ein bisschen diesen Angst zu nehmen. Ja, soll ich in diese? Oder ist es einfach in diese Richtung zu gehen, dass sie wirklich gezeigt habe, da gibt es genug Möglichkeiten da einzusteigen und auch dann die die Vorteile, die man da daraus resultieren. Ich würde mich jetzt mal bei euch beiden für das Gespräch bedanken. Es war sehr schön. Wünsche euch mal einen schönen Abend und ich sage mal so, bis zum nächsten Mal vielen, vielen Dank für vorher sehr, sehr interessante Inputs in diesem sehr gerne! Sebastian: Vielen Dank, dass wir da sein durften. 
Boris: Ebenfalls vielen Dank. 
Ashley: Alles klar. Tschüss. Taktsoft Campus Podcast. Der Podcast für Software und IT Professionals Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxisfragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Taktsoft Campus Podcast Team.