Serverless ist ein weiterer Hype-Begriff im DevOps Umfeld. Zu Gast habe ich Niko Köbler und diskutiere mit ihm die Unterschiede zu Cloud, Vorteile und Risiken von Serverless sowie dem möglichen Problem „Vendor Lock-In“.
In dieser Podcast-Episode diskutieren Dierk Söllner und Nico Köbler intensiv über das Thema Serverless Computing. Sie beleuchten, wie Serverless Computing ein wichtiger Evolutionsschritt in der IT ist, insbesondere in Bezug auf Cloud-Technologien und deren Einfluss auf Entwicklungsprozesse. Nico erklärt die technischen Aspekte, Herausforderungen und Vorteile von Serverless und wie es sich von herkömmlichen Cloud- und Container-basierten Ansätzen unterscheidet. Zudem wird auf die kulturellen und prozessualen Veränderungen eingegangen, die Serverless in Unternehmen, insbesondere im DevOps-Bereich, mit sich bringt.
Inhalt
- Einführung und Vorstellung von Nico Köbler
- Definition und Diskussion von DevOps
- Bedeutung und Einfluss von Serverless Computing
- Unterschied zwischen Cloud und Serverless
- Vorteile von Serverless für Entwickler und Startups
- Kosten- und Skalierungsaspekte von Serverless
- Zukunftsperspektiven und -entwicklungen im Bereich Serverless
- Die Rolle von Serverless im Kontext von Microservices
- Diskussion über Vendor Lock-in und Cloud-Abhängigkeiten
Shownotes
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dirk Söllner.
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen als Trainer, Berater und vor allem als Coach
auf dem Weg zu einer DevOps-Organisation. DevOps umfasst für mich kulturelle, organisatorische,
prozessuale und technische Aspekte. Das diskutiere ich mit Experten aus der Praxis.
Ich freue mich heute auf das eher technische Thema. Serverless ist ein Evolutionsschritt.
Zu Gast habe ich Nico Köbler. Der ist freiberuflicher Softwareentwickler.
Mein letzter Podcast zum Thema Spotify hat viel Beachtung gefunden und der war ja eher informativ.
Heute hat mir Nico einen polarisierenden Podcast versprochen. Nico ist seit ca. 20 Jahren in der IT
und bezeichnet sich selbst als Problem Solver. Er programmiert Java und JavaScript,
sowohl Frontend als auch Backend. Hauptsache Code schreibt er. Mittlerweile ist er auch viel
im Deployment und in der Automation unterwegs. Er bewegt sich zwischen On-Premise und Cloud.
Am liebsten Serverless. Über Serverless hat er 2017 auch ein Buch geschrieben.
Serverless Computing in der AWS Cloud.
Das ist im Entwickler-Pressverlag erschienen. Er betreibt natürlich auch eine Webseite
n-k.de, die ich dann auch in den Shownotes natürlich verlinken werde.
Das Stichwort Serverless ist nun schon viermal gefallen. Unser Thema basiert auf einem Interview
zur JAX 2019 mit der Überschrift, Serverless ist nicht nur eine nette Randerscheinung.
Serverless ist ein Evolutionsschritt.
Hallo Nico, ich habe dich ja nun schon kurz vorgestellt. Habe ich irgendwas vergessen?
Möchtest du noch was ergänzen?
Hallo Dirk. So weit war das eigentlich alles vollständig. Um die Überleitung gut hinzubekommen,
wie ich zu dem Thema Serverless gekommen bin, ist vielleicht noch ganz interessant,
dass ich einer der Co-Leads bin der Java User Group in Darmstadt. Und in dieser Aufgabe bin
ich auch dann letztendlich zu dem ganzen Serverless-Thema gekommen.
Okay, ja.
Ja. Nun haben wir ja, bevor wir auf das Thema eingehen, haben wir hier ja den DevOps-Podcast.
Ja.
Und einen DevOps-Podcast beginne ich immer mit der Frage an meine Gäste, wie definierst
du Podcasts? Wie definierst du DevOps?
Am liebsten gar nicht.
Okay. Würdest du es trotzdem für uns machen?
Ich versuche es mal. Also mir ist der Begriff DevOps und der ganze Hype darum irgendwie
so ein bisschen ein Dorn im Auge, weil es ist letztendlich das, was ich,
was ich tue oder was ich schon immer tun möchte und versuche überall zu tun, um gute
Software zu schreiben, bessere Software zu schreiben, den Entwicklungsprozess in den Teams
bei meinen Kunden einfach zu verbessern. Und ich finde es schade, dass wir dafür einen
Begriff brauchen und es nicht einfach tun. Weil für mich ist DevOps erstmal nur was
komplett Kulturelles. Ob da jetzt ein Prozess dahinter steckt, weiß ich nicht. Aber ich
weiß nicht, Prozess ist für mich immer so negativ besetzt. Das mag an meiner Historie
aus Enterprise-Projekten liegen. Ja, es geht für mich bei DevOps wirklich nur darum, es
müssen alle Beteiligten zusammenarbeiten und dann das bestmögliche Konstrukt oder
das bestmögliche Ergebnis liefern und das am besten kontinuierlich und kontinuierlich
immer besser. Es hat nichts damit zu tun für mich, dass ein Developer, der sich in der
Software befindet, jetzt auch Ops machen muss und einen Ops-Mensch auch entwickeln
können muss. Für mich ist nach wie vor wichtig, dass jeder seine Kernkompetenzen hat und
das auch dann durchführt und sich in seinem Bereich weiterbildet. Aber der Austausch muss
einfach da sein und die Zusammenarbeit. Also ein Austausch von wegen, wir als Entwickler
schreiben den Ops-Menschen ein Ticket und sagen denen, was sie zu tun haben. Es ist
auch der falsche Weg. Das ist auch keine Zusammenarbeit. Das ist wirklich Zusammenarbeit.
Am liebsten Face-to-Face, also wirklich zusammensitzen. Das ist auch heutzutage nicht so häufig, weil
wir machen das alles über unser DevOps-Tool Slack.
Das habe ich noch nie gehört, dass das ein DevOps-Tool ist, aber okay.
Heutzutage ist jedes Tool irgendwie ein DevOps-Tool, sobald sich Dev- und Ops-Menschen zusammen unterhalten.
Ich finde es auch schrecklich.
Es gibt auch ganze DevOps-Ingenieure, es gibt auch ganze DevOps-Abteilungen und sonst was.
Ich glaube, sobald es eine DevOps-Abteilung gibt, hat der Prozess DevOps versagt.
Ja, okay. Das finde ich interessant. Dann wäre ja Telefon auch ein DevOps-Tool.
Ein Telefon ist ja oldschool.
Ja, aber…
Das ist ja nicht…
Okay. Wobei in meinen DevOps-Trainings habe ich dann manchmal auch ältere ITler,
die mir dann auch was sagen.
Und wenn die dann so verstehen oder mitbekommen, was ich ihnen so erkläre,
sagen sie, ah, okay, das haben wir vor 15 Jahren auch schon gemacht.
Ja.
Also das ist dann auch oldschool. Einfach auf einem Raum, in einem Raum oder am Flur zusammensitzen
und dann geht man eben mal kurz rüber zum Admin und klärt mit dem irgendetwas.
Vielleicht nicht klären, aber den Admin auch einbeziehen in das Projekt von Anfang an.
Und nicht irgendwie sagen, ja, das ist der Admin und dann, wenn wir zum Deployment kommen,
dann gehen wir da mal rüber.
Dann ist es auch zu spät.
Von Anfang an wirklich sagen, hier, wir haben jetzt ein neues Projekt, neues Software-Tool,
was wir entwickeln und wem brauchen wir da alles dabei, um es letztendlich zu deployen.
Von Anfang an mit in das Team holen.
Das muss ja nicht unbedingt Fulltime sein.
Das kann ja auch immer zeitweise sein.
Auf den Menschen zugehen und sagen, hier, das sind unsere Anforderungen, die wir haben.
Passt das mit deinen Anforderungen?
Was müssen wir dir geben?
Was kannst du uns geben?
Das ist für mich das Wichtige.
Ja, okay.
Also es ist interessant.
Interessant, dass viele Gäste in meinem Podcast DevOps natürlich unterschiedlich beschreiben oder erklären, definieren.
Aber wenn man den Kern rauszieht, meinen alle das Gleiche, das, was du auch gesagt hast.
Die einen packen das vielleicht in einen Satz, die anderen schwafeln elendig lange drüber.
Aber es kommen immer wieder Dinge vor, die bei allen gleich sind.
Zusammenarbeit, zum Wohle des Kunden und, und, und, und so weiter.
Besonderer Menschenverstand kann man auch mal drüber schreiben.
Also insofern.
Würde ich jetzt mal zu dem Begriff oder zu dem Thema unseres Podcasts überleiten.
Und ich habe ja gesagt, das gab ein Interview von dir.
Und in dem ersten Absatz des Interviews hast du gesagt zum Thema Serverless, dass es ein unglücklicher Begriff ist.
Und jetzt haue ich als BWLer mal in die gleiche Kerbe.
Irgendwo muss doch doch irgendwo noch blech rumstehen.
Also ich brauche ja trotzdem noch Server, auch wenn du das eben unglücklich findest.
Ja, natürlich.
Also ganz ohne Server können wir das Ganze natürlich nicht ausführen.
Es ist immer wieder dieser Einstieg.
Natürlich brauchen wir noch Server.
Jetzt ein bisschen provokant gesagt, es langweilt mich mittlerweile, diesen Satz zu hören und darauf eingehen zu müssen.
Der Begriff ist halt nun mal irgendwo aufgekommen.
Irgendjemand hat ihn geprägt.
Wahrscheinlich war es AWS, die ihn wirklich geprägt haben.
Auch die, wenn sie tolle Produkte herstellen oder anbieten, sind jetzt nicht unbedingt die Besten in der Namensfindung.
Wir wissen alle.
Naming ist hart in IT.
Und es ist nur einfach mal ein Begriff und wir sollten damit leben.
Es hat seinen Ursprung darin, dass es einfach darum geht, dass wir keinerlei Instanzen, wie auch immer die aussehen,
diese Instanzen von Servern, mehr managen müssen.
Dass das komplett uns abgenommen wird.
Also Instanz von Server heißt wirklich das Blech.
Das heißt die virtuelle Maschine.
Das heißt ein Container, wie auch immer.
Also damit kommen wir.
Überhaupt gar nicht in Berührung beim Thema Serverless.
Oder wir kümmern uns nicht um die Verwaltung von Servern, von Containern, von virtuellen Maschinen.
Das wird uns abgenommen von dem jeweiligen Serviceanbieter, Cloud-Anbieter.
Und das ganze System skaliert dabei automatisch und völlig transparent für den Entwickler.
Und ist so ausgelegt.
Dass eben jeder anfallende Workload auch bearbeitet werden kann.
Auch da gibt es Grenzen.
Die muss man nicht unbedingt kennen, je nachdem was man macht.
Die Grenzen sind mal enger, mal weiter gesteckt.
Aber ich als Entwickler muss jetzt nicht gucken, ist der Server, der Container oder sowas ausreichend für die Anzahl an Threads, die ich bearbeiten können muss.
Das passiert automatisch.
Und ich muss mich auch…
Ich muss mich auch nicht mehr drum kümmern, ob die ganzen Maschinen aktuell sind, ob die Container irgendwie das neueste Image haben, dass irgendwelche CVEs oder sonstigen Sicherheitslöscher geflickt sind.
Das wird mir alles vom Cloud-Provider abgenommen.
Okay.
Du hast jetzt eben den Begriff Cloud ja auch eingeführt.
Gibt es einen Unterschied zwischen Cloud und Serverless?
Ja, natürlich.
Gehe ich gleich drauf ein.
Ich habe mal in einem Vortrag von mir auf einer Konferenz das ein bisschen so beschrieben.
Cloud, als Cloud aufkam, so vor 10, 15 Jahren, wurde uns gesagt, die Cloud nimmt uns alles ab an Management, an Verwaltung.
Und wir können uns wirklich auf die Business-Logik konzentrieren.
Und müssen nur noch mit einem Knopfdruck…
Können das Ganze deployen und in der Cloud läuft das alles automatisch.
Die Praxis hat uns gezeigt, dass es nicht so war.
Und jetzt kam Serverless vor vier Jahren und hat quasi den gleichen Satz gebracht.
Mit Serverless könnt ihr euch wieder auf eure Business-Logik konzentrieren.
Müsst euch nicht um Technik kümmern, was damals der Cloud-Begriff gebracht hat.
Cloud ist ja heute auch einfach mehrfach besetzt.
Was ist denn Cloud?
Also frag mal Michael.
Wenn Microsoft was Cloud ist, dann könnte das die Azure Cloud sein mit den ganzen Services.
Dann kann das aber auch Office 365 sein.
Bei Google kann es irgendwie Hosted Kubernetes sein.
Das kann irgendwie die Google Compute Engine sein.
Das kann aber auch Google Drive sein, wo meine ganzen Daten liegen oder sonst was.
Also was genau Cloud heißt, ist für, glaube ich, jeden Mensch in unterschiedlichen Kontexten auch, hat eine unterschiedliche Bedeutung.
Kann man heutzutage leider gar nicht.
Kann man gar nicht mehr so sagen.
Und Serverless ist bei den Cloud-Providern erstmal populär geworden, weil die eben auch die Manpower haben, das aufzusetzen, diese ganze Infrastruktur darunter zu verwalten, um die ich mich ja nicht mehr kümmern muss.
Aber der Cloud-Provider kann das halt und macht das halt, weil dort arbeiten genug Leute, die sich genau mit dem Thema auskennen, eben dem Management von Server-Einheiten.
Und die können das richtig gut, besser als jeder Entwickler das kann.
Würde ich mir jetzt mal so sagen.
Und da stehen halt in der Cloud auch genügend Ressourcen rum, die dafür verwendet werden können.
Das heißt, dort ist das Ganze populär geworden.
Und dann kommen natürlich immer Leute, die sagen, ja, wir wollen das aber auch zu Hause bei uns im Rechenzentrum betreiben.
Was uns dann zum anderen Thema Serverless On-Premise führen würde, gehen wir wahrscheinlich auch später nochmal drauf ein.
Wo ich dann wieder in Frage stelle, ob das immer noch Serverless ist.
Weil da ein bestimmter Kontext mit ins Spiel kommt.
Aber Serverless selbst ist erstmal für mich ein Cloud-Thema und ein Hosted-Cloud-Thema, wo die Cloud nicht irgendwie in meinem Unternehmen steht, sondern Public Cloud ist.
Okay, gut.
Jetzt hast du eben schon so ein bisschen darauf abgezielt, warum wir das überhaupt machen.
Weil bei allen Schwierigkeiten, Naming in IT ist hart, muss es ja Vorteile geben.
Es muss ja irgendwie Nutzen geben, ein Business-Case geben.
Wer hat denn Vorteile von Serverless?
Das sind unterschiedliche Zielgruppen oder können unterschiedliche Zielgruppen sein.
Zuerst mal der Entwickler, der eine kleine Lösung aufbauen will, ohne sich jetzt um Server-Management, Server-Aufsetzen, Betriebssysteme oder so irgendwas kümmern zu wollen.
Das war so mein Use-Case, wie ich dazu gekommen bin, mich eingangs erwähnt hat.
Ich bin Organisator von der Java User Group in Darmstadt und wir sind bei uns in der TUC ein Organisatoren-Team von vier bis acht Leuten und jeder verlässt sich gerne auf den anderen, dass er was tut.
So war das auch bei unseren Einladungs-Mails Ende 2015, dass jeder meinte, der andere schickt die monatliche Einladungs-Mails an die Mailing-Liste.
Und dann dachte ich, das muss auch irgendwie automatisiert gehen, weil das ist so ein manueller Task, den muss man ja nicht fortführen manuell mit den ganzen Fehlern.
Also war mein Ansatz zu sagen, ich brauche irgendwie eine VM in der Cloud, die ich einmal am Tag für eine Minute starte, ein Programm ausführe und die Mail verschicke und die VM wieder runterfahre.
Weil ich wollte ja nicht für 24-7 bezahlen. Ich brauche ja nur einmal eine Minute am Tag einfach die VM, um zu gucken, haben wir irgendwie in der nächsten Woche eine Veranstaltung.
Wenn ja, verschicke eine Mail, wenn nicht, lege ich einfach wieder schlafen.
Da ich zu dem Zeitpunkt noch nicht wusste, wie macht man das am besten, so eine VM hochfahren, Programm ausführen, wieder runterfahren, bin ich zum damaligen Kollegen gegangen, haben das geschildert und der sagte, ja, Moment, das geht nicht, was du vorhast, aber es gibt da was Neues bei AWS, nennt sich Lambda.
Damit kannst du eventgetrieben Code ausführen. Ich so, okay, klingt interessant, aber ich habe ja jetzt kein Event, ich will das zeitgesteuert machen.
Er sagte, ja, auch.
Ein Cron-Event ist ein Event. Also du kannst auch zeitgesteuert da irgendwie ein kleines Programm ausführen.
Fand ich klasse, habe mir das angeguckt und AWS Lambda war der erste, der erste weitbekannte Serverless-Service.
Und dann habe ich mich hingesetzt, habe dann ein kleines Programm geschrieben, in JavaScript, Node.js, Runtime, habe das hochgeladen, also wirklich nur den JavaScript-Code hochgeladen und
da, es wurde Magic so ausgeführt, wie ich das wollte. Das heißt, Lambda stellt dann die Laufzeitumgebung zur Verfügung, in dem Falle Node.js, führt mein JavaScript aus und die Mail wurde versendet.
Ich war begeistert und war irgendwie von dem Thema Serverless dann, ja, gefesselt. Und das ist so ein Anwendungsfall für eine mögliche Zielgruppe, die Serverless betreiben wollen, also ohne viel Aufwand.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
weil ich habe weniger Management-Operationskosten, dafür etwas höheren Satz zu bezahlen als vielleicht eine normale virtuelle Maschine, ist letztendlich ein Rechenexempel, ob sich das lohnt oder nicht lohnt, ist der rein finanzielle Gedanke.
Wenn ich weniger Management-Aufwand habe und dadurch auch sicherer bin, weil die Plattform selber ja gemanagt wird für mich, bin ich vielleicht auch bereit, das mehr an Geld zu bezahlen, weil ich weniger tun muss, mich mit weniger Dingen beschäftigen muss.
Andere mögliche Zielgruppe könnte sein ein Start-up, das noch gar nicht weiß, wie wird denn unsere neue Applikation am Markt angenommen. Wir haben eine tolle Business-Idee, die wir umsetzen können, wir haben auch Entwickler hier,
aber wir wollen gar nicht so viel jetzt in den personellen Aufwand stecken, um jetzt einen Ops-Menschen noch einzustellen, der die ganzen Server da aufsetzt und verwaltet und dafür zu bezahlen, dass irgendwie, wenn die App gut ankommt im Markt, dass das alles automatisch skaliert und so weiter.
Die können wunderbar mit Serverless starten.
Und dadurch, dass ein Serverless-Plattform automatisch transparent skaliert mit der anfallenden Last, können die den gesamten Traffic damit auch abbilden, egal, ob das jetzt durch die Decke geht oder halt doch nicht so gut ankommt.
Wenn es nicht so gut ankommt, zahlen sie weniger. Wenn es durch die Decke geht und ein Riesenerfolg wird, zahlen sie mehr, aber dann werden die hoffentlich einen richtigen Use-Case haben, dass sie auch entsprechend mehr einnehmen.
Und dann rentiert sich das auch wieder für die.
Okay. Wenn ich das richtig verstanden habe, geht es eigentlich bei Servers also um Skalierung, Skalierungsmöglichkeiten und eben die Kosten dabei, also die verbundenen Kosten damit.
Würde sich denn überhaupt aus deiner Sicht überhaupt noch lohnen, eigene Server zu haben?
Aus meiner Sicht nicht.
Okay, so klare Antwort.
Wir wollen ja auch einen provozierenden Podcast machen.
Letzten Endes ist das eine klare Ansage. Du sagst also, ein Unternehmen braucht heute keine eigenen Server mehr.
Genau, das ist richtig. Ich kenne auch durchaus ein paar Unternehmen, die keine eigenen Server mehr haben, die komplett alles in der Cloud gehostet haben, die da natürlich auch noch ein paar virtuelle Server in der Cloud haben, die nicht alles Serverless machen, weil es gibt spezielle Use-Cases, da macht Serverless einfach keinen Sinn.
Heutzutage noch nicht. Das wird in Zukunft anders werden.
Aber teilweise…
Aber teilweise ist es heute so, wenn wirklich eine Anwendung da ist, die 24-7 eine konstante Last bewältigen muss, dann kann es durchaus sinnvoller sein, das auch auf einer virtuellen Maschine zu betreiben als Serverless.
Da gibt es auch im Bereich Serverless noch Dinge, die noch behoben werden müssen, sowas wie Schlagworte Startup Latency und sowas.
Das wird aber alles gelöst werden in der Zukunft.
Okay.
Da rede ich aber dann über die Zukunft von, ich sag mal, irgendwo zwischen zwei und sechs Jahren.
Das ist jetzt nichts, was in den nächsten Monaten kommt.
Okay. Wir haben ja eben, wenn du da quasi jetzt ein bisschen abgedriftet, weil wir bei der Frage waren, wer hat Vorteile von Serverless?
Und du hast auf die Entwickler abgehoben, du hast von Startups erzählt.
Und wenn man über DevOps redet, auch wenn du den Begriff nicht magst, da ist ja Ops drin.
Also wie sieht das denn für Operating aus, für die Admins?
Welche Admins?
Also es gibt in der Serverless-Welt…
In der Serverless-Welt, manche nennen es auch den Serverless-Tribe, also den Stamm der Serverless-Jünger,
gibt es so ein bisschen den Ansatz, wir brauchen den Begriff DevOps nicht.
Wir leben das automatisch.
Also das Deployen von Code, von meiner Anwendung, von meiner Serverless-Anwendung,
bedingt automatisch auch die Überwachung und die Verbesserung meines Codes.
Und es ist eine Selbstverständlichkeit in Serverless-Teams,
dass das Team…
Das Team das macht.
Das heißt, ich deploye meinen Code, überwache mit entsprechenden Metriken,
wie wird mein Code ausgeführt, wo gibt es Fehler, wo gibt es Schwachstellen,
Performance-Einbußen, was auch immer, und optimiere das Ganze dann.
Das heißt, es ist einfach der Entwickler, der diese Aufgaben mit übernimmt.
Und es gibt jetzt gar nicht den Menschen, den eigentlichen Operations-Menschen mehr,
weil das macht der Cloud-Anbieter von diesem Serverless-Service oder Serverless-Umgebung.
Und…
Deswegen sagen auch die Serverless-Leute, wir machen DevOps implizit, ohne dass wir es so nennen.
Ja, okay.
Wenn wir von den Vorteilen sprechen, du hast ja in deinem Interview das auch ein bisschen beleuchtet.
Wenn ich es für mich mal zusammenfasse, Vorteile haben die Entwickler, also die Menschen, die entwickeln.
Ich würde es als Nachteil sehen, dass ein Operator dann keinen Job mehr hat.
Also zumindestens vielleicht nicht mehr in Deutschland oder in der Form, wie auch immer.
Das ist für den Menschen…
Also für den Operator oder für den Admin auch ein Nachteil.
Aber für das Unternehmen, für den Entwickler, für die Aufgabe Operating und Administration ist es dann auch wieder ein Vorteil,
weil er sich quasi nur um das kümmern muss, was so highfly ist.
Aber der Rest wird ja eben irgendwo anders gemacht.
Genau, es ist nicht weg, es ist nur woanders.
Unser vieles Geld ist ja auch nicht weg, das ist ja nur bei anderen Menschen.
Ja, das ist richtig, ja.
Du hast gerade so schön gesagt, zumindest in Deutschland…
Nein, in Deutschland wird der Opsmann…
Immer noch weiter seinen Job haben.
Gerade in Deutschland ist das Thema Serverless, glaube ich, noch in einer weiten Zukunft für eine breite Übernahme.
Ich glaube, die klassischen großen Enterprises, also die großen Unternehmen, Konzerne oder sowas,
die nicht in die Cloud gehen wollen, was ja eigentlich am meisten mit Wollen zu tun hat.
Die sagen ja, sie können nicht in die Cloud wegen irgendwelchen Regulatorien.
Ja, mag sein.
Aber technische Gründe gibt es.
Es gibt nämlich keine, nicht in die Cloud zu gehen.
Die wollen alles in ihrem eigenen Rechenzentrum machen.
Und letztendlich könnten die ja auch eine eigene Umgebung schaffen, dass deren Entwickler Serverless betreiben oder Serverless arbeiten können.
Also für den Entwickler könnte es dann völlig transparent sein.
Und dann würde Operations sich rein um das Management im Betrieb der Serverless-Plattform im Unternehmen kümmern.
Jetzt muss man natürlich dann das hinterfragen.
Ist das noch Serverless, weil es On-Premise ist?
Weil da sind ja dann doch die eigenen Server, die das Unternehmen managen muss, verwalten muss und bezahlen muss.
Also im Gesamtkontext, also Total Cost of Ownership für das Unternehmen, ist es nicht Serverless, weil da immer noch das Blech rumsteht.
Und die eigenen Mitarbeiter das verwalten müssen.
Also das Unternehmen zahlt auch die Mitarbeiter, die das machen müssen.
Im Gegensatz zu, ich nutze eine Serverless-Plattform in einer Public Cloud, wo das komplett…
Natürlich zahle ich das auch.
Es ist ja nicht kostenlos für mich.
Ich zahle mit jeder Sekunde Rechenzeit, die ich nutze, zahle ich natürlich auch das Personal bei dem Cloud-Provider.
Das ist ganz klar.
Aber wenn man so von der Aufteilung sagt, wenn ich es in der Public Cloud gar nicht nutze, zahle ich es auch nicht, obwohl die Plattform zur Verfügung steht.
Wenn ich es im eigenen Unternehmen aufbaue, die Plattform, und ich würde sie nicht nutzen, muss ich sie trotzdem bezahlen und auch die Menschen, weil sie läuft, die Umgebung.
Der Entwickler nutzt es nicht.
Für den Entwickler ist es transparent.
Der meint, es fallen keine Kosten an.
Aber die Serverfarm im Keller läuft ja trotzdem durch, wo diese Serverless-Plattform läuft.
Und die muss bezahlt werden.
Ja, okay.
Das heißt, wir haben jetzt über Vorteile und über das Risiko, über den Nachteil von Kosten gesprochen.
Oder überhaupt das Thema Kosten und Preise.
Jetzt komme ich als BWLer wieder und sage, was ist denn mit dem Thema Sicherheit und Verfügbarkeit?
Wenn ich das Ding in meinem Keller…
Wenn ich das Ding in meinem Keller stehen habe, ist es doch viel sicherer und viel verfügbarer.
Wirklich?
Ja, ich bin BWLer. Ich kann mich doof stellen. Wir wollen ja polarisieren hier.
Also, ich bringe da immer so ein Beispiel von einem Unternehmen, bei dem ich mal gearbeitet hatte, bevor ich Freelancer wurde.
Die hatten auch die eigene IT, Neubau.
Also, das Gebäude, der Lebensgebäude wurde neu gebaut, neu geplant.
Die IT wurde auch in den Keller geplant.
Da hat man gemerkt, oh, das ist eine schlechte Idee. Es ist ein Sumpfgebiet.
Da könnte Wasser, irgendwie Hochwasser auftreten, wenn das ein Keller ist.
Die ganze IT, dann könnte die unter Wasser sitzen.
Dann mussten nochmal irgendwie statische Veränderungen eingebaut werden, bis dann die IT plötzlich im ersten Stock war.
Nicht mehr im Keller.
Soviel zum Thema, der Keller ist sicher.
Ich glaube, es gibt auch eine große deutsche Bank, die das mal hatte, die ihren…
Tatsache…
…teich, ihren schönen großen Teich vom Gebäude über das Rechenzentrum gebaut hat.
Ist unbestätigt, aber ich glaube, es soll so etwas gegeben haben.
Ja, es gibt auch in Frankfurt einen großen silbernen Turm, in dem ein deutsches Eisenbahnunternehmen drin sitzt.
Da ist ganz oben in dem Hochhaus ein Swimmingpool, auch eher Löschteich genannt, dass also da Löschwasser zur Verfügung steht.
Und wenn der mal ausläuft, läuft der über die gesamte…
IT ist ja, glaube ich, jetzt nicht drin in dem Turm, aber die gesamten anderen Rechner und sonstige Infrastruktur wird unter Wasser gesetzt.
Also diese Vielplanung gibt es heute noch.
Zum Thema Verfügbarkeit.
Ja, wenn ich das neue Gebäude jetzt am Ende einer Straße, einer Sackgasse plane, wo nur ein Kabel hinführt und kann dann zwar von irgendwie zwei Telekommunikationsunternehmen…
…einen Vertrag haben, die laufen trotzdem letztendlich über die gleiche Leitung oder kommen über das gleiche Leerrohr in mein Haus rein.
Und wenn der Bagger dann dieses Leerrohr durchhaut, haut er beide Leitungen durch und dann habe ich auch keine redundanten Leitungen und auch keine Verfügbarkeit.
Zudem wissen wir, die meisten Angriffsszenarien kommen aus der eigenen IT heraus oder aus einem eigenen Unternehmen heraus.
Das heißt, wenn die Systeme in meinem eigenen…
…Unternehmen stehen oder im eigenen Gebäude stehen, ist es einfacher, wenn das mit eigenem Personal betrieben wird, gemanagt wird, ist es einfacher, da einen Datenklau zu provozieren, als wenn das irgendwo anders steht.
Weil es doch ganz andere Überwachungsmechanismen gibt, die nur die wenigsten Unternehmen auch bei sich im eigenen Rechenzentrum aktiviert haben.
Dass man wirklich nachvollziehen kann, wer was gemacht hat.
Was aber heute…
…mit DSGVO und so weiter ja Standard sein sollte, dass man genau weiß, welcher Mitarbeiter hat was an den Systemen gemacht und was geändert, gerade wenn es um personenbezogene Daten geht.
Ich glaube nicht, dass das eigene Rechenzentrum im Keller sicherer und verfügbarer ist, als das, was große Anbieter anbieten, die sich genau darauf fokussiert und spezialisiert haben.
Ja, okay. Also, das muss ich jetzt wahrscheinlich mal akzeptieren als BWLer.
Ja, dass es eben so nicht ist, dass ich mir vielleicht ein bisschen meine Vorstellungskraft erweitern muss oder in die Praxis gucken muss.
Aber wenn ich von BWL gesprochen habe, von Wirtschaftssicht, ich finde das ganze Thema Microservices auch sehr interessant, wenn ich jetzt mal so wiederum auf die praktische Nutzung schaue.
Ich versuche immer, selbstorganisierte, autonome Teams hinzubekommen.
Das ist natürlich auch ein klares Thema von DevOps aus meiner Sicht.
Hängt das Thema Microservices mit Serverless irgendwie zusammen?
Ja und nein. Microservices ist jetzt erstmal ein Architekturansatz, wie du deine Applikation schneidest und du teilst es in viele kleine logische Einheiten auf.
Und bei Serverless wird es noch dazu kommen, dass du deinen Service vielleicht sogar in noch mehr kleine Deployment-Einheiten, kleinere Deployment-Einheiten,
Deployment-Einheiten aufteilst.
Also ein Service, ein Microservice kann ja durchaus irgendwie zum Beispiel vier Endpunkte beinhalten, die fachlich zusammenhängen.
In der Serverless-Welt könnte es aber dann so weit gehen, dass du aus diesen vier Endpunkten also vier Funktionen machst und diese dann unabhängig voneinander auch deployst.
Also der Ansatz von Microservice ist ja, ich will eine Unabhängigkeit, eine fachliche Unabhängigkeit haben, dass ein fachlicher Service unabhängig von anderen,
Fachlichkeiten ausgetauscht, aktualisiert, abgeschaltet dazukommen kann oder was tun kann und technologisch in der Serverless-Welt ist es dann so,
dass ich sage, ich will meine einzelnen Funktionen unabhängig voneinander deployen können.
Also das, was ich mit Microservice fachlich habe, habe ich dann in der Serverless-Welt technisch auf Basis von Funktionen und mehrere Funktionen könnten dann wieder einen Microservice geben.
Also gibt auch die Ansätze, sagen, eine Funktion ist ein Microservice, das ist ja nie so ganz genau abgetrennt, wie groß oder was umfasst jetzt ein Microservice.
Und den Code, den ich halt deploye bei Serverless-Einheiten, das nennt sich eigentlich die Funktion, also man spricht auch häufig von Function as a Service,
weil ich die Funktion, den Code deploye und das Ganze dann als Service ausgeführt wird, deswegen Function as a Service.
Neben irgendwie Software as a Service, Backend as a Service, Infrastructure.
As a Service, alles as a Service.
Alles as a Service.
Genau, haben wir jetzt auch Function as a Service.
Okay, du hast, also habe ich verstanden, du hast ja in dem Artikel, in dem Interview auch eine These von Simon Wardley erwähnt, der hat ja mehrere rausgebracht, sag ich mal.
Die fand ich aber ganz interessant, aus meiner Sicht eben wieder, kannst du zu der These ein bisschen was sagen?
Ja, also er hat gesagt, Container in Kubernetes, alles was da momentan so hip,
und gehypt wird bis zum Gehtnichtmehr und jeder seine Anwendungen auf Container in Kubernetes umstellt, ist alles ganz nett,
aber wenn man die Evolution der IT oder der Computertechnik so ein bisschen zugrunde legt, ist das alles nur eine Randerscheinung.
Das ist ein Evolutionsschritt hin zu Serverless, weil Serverless baut im Grunde genau auf dieser Technologie auf,
Container und Container-Management.
Systemen, sowas wie Kubernetes, aber das ganze Management darum, werden wir uns in Zukunft nicht mehr darum kümmern, aus der Entwicklersicht.
Und das ist genau, was Serverless eben ist.
Und alle Unternehmen, die momentan auf Docker bauen, Kubernetes bauen und das ganze umstellen dahingehend und sagen, das ist die Zukunft und Serverless ist ja nur nebenbei,
nette Spielerei.
Die werden sich auch…
Die werden sich auch nochmal umgucken und werden auch in Zukunft ihre gesamten Anwendungen nochmal umbauen in Richtung einer Serverless-Welt.
Wie gesagt, Container und Kubernetes ist jetzt nichts, was per se schlecht ist, aber das Ding, dass jetzt ein Entwickler sich so detailliert mit Kubernetes auskennen muss,
wie es momentan irgendwie gehypt wird und wie jeder das fordert, das ist mir auch so ein bisschen ein Dorn im Auge.
Okay.
Weil Kubernetes ist eine…
Scheduling-Plattform für Container.
Ja, ich finde Container toll.
Ich mag auch gerne meine Applikationen in Container bauen und die deployen, wenn ich sie nicht Serverless entwickeln darf.
Und ich muss, um eine Applikation in Container zu betreiben, auch bestimmte Dinge wissen und berücksichtigen.
Ja, als Entwickler auch noch, d’accord.
Aber sobald ich als Entwickler auf meinem lokalen Rechner plötzlich mehr als irgendwie Docker oder Docker Compose fahren muss,
weil ich einen eigenen Kubernetes-Cluster…
… brauche, Single-Node-Cluster mit irgendwie Minikube oder sowas, um da noch 50 andere Microservices in Containern hochzufahren,
nur dass ich meinen eigenen neuen Service testen kann und dann noch irgendwie genau wissen muss, wie viel YAML-Files ich wie editieren muss,
nur irgendwie ein Hello-World rauszubekommen, dann läuft irgendwas schief.
Weil dann mache ich als Entwickler nicht mehr das, was ich gut kann, sondern ich versuche, mich durch die Kubernetes-Welt durchzubringen.
Also, einfachstes Beispiel.
Wenn du mit Kubernetes anfängst und du willst wirklich nur dieses Hello-World-Beispiel machen, musst du, glaube ich, drei verschiedene YAML-Files erstellen
und dort irgendwas mit Hello-World eintragen, dass du auch dann im Browser letztendlich ein Hello-World ausgegeben bekommst.
Das ist irgendwie, in meinen Augen, kann es das nicht sein.
Und wenn ich dann eben die Server des Welt nebendran stelle und da schreibe ich halt meinen Hello-World-Code, deploye ihn und bekomme Hello-World.
Mhm.
Ob da jetzt im Untergrund darunter Kubernetes läuft oder irgendwie was anderes,
weil bei Amazon ist es eine Micro-VM-Umgebung, so nennen die das, nennt sich Firecracker,
die ist mittlerweile auch Open Source, die kann ich sogar auch selber betreiben, wenn ich das möchte.
Das ist mir eigentlich egal.
Ich will nur, dass die Funktion irgendwie deployed werden kann
und ob die jetzt unter der Haube in Workern ausgeführt wird,
so dass es bei Cloudflare oder in einen Container verpackt wird
und in dieser Firecracker-Micro-VM gestartet wird, ist mir alles völlig egal.
Okay.
Ich möchte irgendwie sagen, das ist mein Code, den möchte ich so und so skalierbar ausführen,
also in gewissen Grenzen und wie das im Untergrund passiert, ist mir egal.
Das, was ich jetzt daraus verstanden habe, würde mich jetzt zu der Frage bringen,
ist das aus deiner Sicht dann eine Sackgasse mit Kubernetes
oder ist das einfach nur kurz falsch abgebogen und man kann wieder auf eine Spur kommen?
Weil wenn ich jetzt mir die Business-Leute vorstelle,
die werden jetzt die Hände über den Kopf zusammenschlagen.
Super, die IT hat wieder die tolle Lösung erfunden
und wissen, in zwei Jahren ist es schon wieder falsch.
Also Kubernetes, Sackgasse oder falsch abgebogen?
Einen unnötigen Umweg genommen, würde ich sagen.
Also ich habe ja vorhin schon mal gesagt,
Serverless hat insgesamt noch ein paar Schwachstellen.
Es ist noch nicht für jeden Use Case wirklich so super toll.
Muss ich auch erläutern.
Das will ich zugeben.
Lambda gibt es jetzt seit Ende 2014.
Also im November 2014 auf der Reinvent von AWS der Hausmesse
wurde das der Öffentlichkeit präsentiert.
AWS selber hat das intern schon ein bisschen länger benutzt,
aber so richtig public ist jetzt seit viereinhalb, fünf Jahren.
Das Konzept, Serverless ohne den Begriff zu nutzen,
mit Funktionen zu hantieren,
gibt es schon seit Ende der 60er Jahre, glaube ich.
So wie es auch Container ja schon deutlich länger gibt
in der Linux-Welt oder Unix-Welt.
Das ist ja auch keine Erfindung von Docker.
Nur jetzt wird es halt gehypt.
Wir brauchen die Container und sowas wie Kubernetes,
um Serverless betreiben zu können.
Und Serverless ist einfach noch sehr, sehr jung
in den gesamten Ausprägungen.
Hat noch ein paar Schwachstellen, die noch gelöst werden müssen.
Und natürlich brauchen wir in der Zwischenzeit
irgendeine andere Technologie,
um unsere Applikationen betreiben zu können.
Ob Kubernetes das richtet,
wie es momentan überall verwendet wird,
weiß ich nicht, möchte ich auch bezweifeln,
weil Kubernetes selbst war von den Entwicklern
nie dafür gedacht, direkt eingesetzt zu werden.
Es war immer nur als Basisplattform für eine andere Plattform,
also für sowas wie eine PaaS-Plattform,
also Service, dann heißt es wieder As-a-Service,
zu nutzen.
Also so wie jetzt heutzutage OpenShift auf Kubernetes basiert,
so war Kubernetes eigentlich gedacht,
dass ich das,
das als Basis nutze für eine andere Plattform,
um dort Applikationen zu betreiben.
Und jeder will aber heutzutage Kubernetes direkt einsetzen,
weil er denkt, das ist eine tolle Idee.
Ja, das ist ein Thema Hype wahrscheinlich.
Ja, genau.
Gute Marketing- und Manager-Leute dabei.
Okay, das ist ja eben deine Ansicht,
also problematisch,
vielleicht einen kleinen Umweg genommen,
vielleicht muss er den auch nehmen,
keine Ahnung, das wird die Zeit zeigen.
Jetzt habt ihr in dem Interview noch ein anderes Thema gehabt,
nämlich das Thema Vendor-Login.
Also das Problem von einem Anbieter vielleicht abhängig zu werden,
was ja häufig kritisch gesehen wird in Richtung Cloud
oder in Richtung Serverless.
Wie stehst du dazu?
Schwieriges, kontroverses Thema.
Wir wollen polarisieren.
Du hast immer irgendwo ein Login,
egal was du tust.
Und ich will das Thema gar nicht wegdiskutieren,
dass du keinen Vendor-Login hast,
beim Thema Serverless.
Gerade wenn du es irgendwie stark auf Lambda setzt zum Beispiel
oder die AWS-Welt.
Es ist ja nicht nur Lambda,
es ist ja deutlich mehr als nur Lambda.
Du bist natürlich irgendwie an einen Anbieter erstmal gebunden,
bekommst dafür aber,
und das ist jetzt nicht auf Serverless,
das ist auf Cloud allgemein spezifisch auch gemünzt,
bekommst dadurch, dass du die Services in der Cloud nutzt,
auch gewisse Vorteile.
Du musst halt die Services nicht mehr selber entwickeln,
du musst die Infrastruktur nicht selber holen,
du musst dich nicht um irgendwelche Patches teilweise kümmern,
es wird alles für dich gemacht,
Speicherplatz steht dir quasi unbegrenzt zur Verfügung,
das musst du nicht selber dazukaufen,
also eine Platte kann nicht volllaufen oder so irgendwas.
Du kriegst ja Vorteile, wenn du in die Cloud gehst.
Du kriegst auch Vorteile, wenn du Serverless machst.
Damit bindest du dich aber natürlich irgendwann an einen Anbieter.
Wenn du jetzt irgendwie sagst,
ich möchte jetzt meinen Storage,
um erstmal nicht,
Serverless zu sein,
meinen Storage möchte ich jetzt unabhängig,
Cloud-Anbieter unabhängig betreiben,
dann wird das schwer,
weil AWS hat zum Beispiel S3 als Object Storage,
da kann ich wunderbar meine Objekte ablegen,
viele Daten ablegen,
kann die dort auch irgendwie mittlerweile durchsuchen,
also wenn ich eine riesen JSON-Datei habe,
kann ich die online durchsuchen
und auch Queries machen,
SQL-ähnlich auf diese strukturierte Datei,
alles wunderbar.
Das Gleiche,
kann ich aber nicht bei Azure machen mit dem gleichen Protokoll,
weil die ein anderes Protokoll haben.
Die haben halt kein S3-Protokoll
und haben diesen Service nicht,
dass ich die S3-Dateien durchsuchen kann.
Letztendlich haben die das auch bei Azure,
nennt sich bloß anders
und die haben ein anderes Protokoll,
andere API, um das zu machen.
Das heißt,
wenn ich wirklich eine Multi-Cloud-Strategie fahren möchte
und meine Daten redundant in verschiedenen Clouds,
ablegen möchte,
das ist mir die These,
was ist, wenn morgen AWS pleite geht?
Dann müssen, glaube ich, andere Dinge passieren.
Was ist, wenn morgen Cloud-Provider A die Preise erhöht?
Ich kenne bislang nur einen Cloud-Provider,
der mal die Preise erhöht hat.
Das war, glaube ich, Google.
Ansonsten haben die Cloud-Provider in den letzten zehn Jahren
ihre Preise immer nur reduziert.
Es ist einfach ein Wettbewerb da
und der wird auch die nächsten Jahre noch anhalten,
der Wettbewerb,
sodass es sehr, sehr, sehr, sehr unwahrscheinlich ist,
dass die Preise angehoben werden.
Dass, ja, dass wenn Cloud-Provider A die Preise erhöht,
dass wir dann zu Cloud-Provider B nahtlos switchen können
und dort unsere Services weiter betreiben können.
Dann müsste ich quasi redundant meine Daten
bei Cloud-Provider A und B halten
und muss dafür Sorge tragen,
dass ich irgendwie so einen Protokoll-Übersetzer habe,
der beide Protokolle,
die im Hintergrund spricht,
was aber wiederum heißt,
ich muss ja auch doppelt bezahlen.
Ich nutze ja zwei Clouds
und ich weiß nicht, ob sich das rechnet.
Naja, und vor allen Dingen,
wenn ich mir jetzt überlege,
was du gerade sagst
und das mal auf die anderen Themen übertrage,
das, was du sagst,
ist ja eigentlich nicht erst mit Cloud und Server das gekommen.
Also ich kann ja auch fragen,
okay, womit mache ich meine Buchhaltung?
Ich mache sie mit SAP.
Wenn ich wechseln will,
weil SAP die Preise erhöht,
ich kann natürlich wechseln,
aber ich kann auch vielleicht Buchungen exportieren,
aber ich muss natürlich auch mich
mit einem anderen Anbieter auseinandersetzen
und eine Migration der Daten auch vornehmen.
Und jeder weiß,
eine Migration entweder hin zu SAP
oder weg von SAP ist auch kein Ponyhof,
muss man so ausdrücken.
Ja, klar.
Ich habe eine Oracle-Datenbank
oder ich habe eine IBM-Datenbank
oder eine MSSQL-Datenbank.
Ich werde immer irgendwann anfangen,
herstellerspezifische Erweiterungen
meiner Daten zu vermitteln.
Und ab dem Zeitpunkt ist es mir nicht mehr möglich,
einfach die Datenbank zu wechseln.
Also diesen Anspruch,
den irgendwie JPA und JDB-SIMA hatte,
ich habe hier Abstraktionen auf mein Objektmodell
und dann kann ich das in jeder beliebigen Datenbank ablegen,
das funktioniert ja auch nicht wirklich.
Irgendwann fange ich immer an,
was Spezifisches zu verwenden
und dann kann ich nicht von heute auf morgen
den Datenbankanbieter wechseln.
Klar, ich kann sie,
hosten, wo ich möchte.
Entweder bei mir im Keller,
im Hochwassergebiet oder in Cloud A oder Cloud B.
Aber ich habe irgendwie ein Login auch auf die Datenbank.
Ja, klar.
Also insofern,
ich habe im Leben immer ein Login.
Richtig.
So, Nico, jetzt gucke ich mal auf die Uhr
und auf unser Thema.
Unser Thema heißt ja,
Serverless ist ein Evolutionsschritt.
Kannst du deine Glaskugel mal auspacken
und da mal reingucken,
wie es mit Serverless weitergeht?
Sorry,
da muss ich dich enttäuschen.
Die Glaskugel ist gerade in der Werkstatt.
Das Ende hier.
Oder hast du doch noch eine Chance?
Ja, also ich versuche mal so einen Ausblick,
auch ohne Glaskugel.
Ich glaube,
in fünf bis zehn Jahren,
so einen Zeitraum müssen wir einfach fassen,
werden wir das,
was wir heute mit der Container,
Container Scheduling Belt
an Workload umsetzen,
ungefähr mit Serverless umsetzen
und deutlich weniger uns um Container kümmern.
Weil,
weil eben noch viele Dinge auch in Serverless-Plattformen
optimiert werden müssen.
Die sind halt noch nicht so super toll, teilweise.
Nichtsdestotrotz gibt es heute Unternehmen,
die bereits einen Serverless-First-Ansatz fahren
und die sagen,
alle neuen Features, die wir entwickeln in unserer Software,
versuchen wir mit Serverless-Komponenten umzusetzen
und erst wenn das nicht möglich ist,
warum auch immer,
oder zu viele Nachteile bringt,
dann werden wir das mit einem Container umsetzen.
Aber wir werden definitiv,
keine EC2-Instanz,
also virtuelle Maschinen mehr,
ja, für,
konkret für Dinge benutzen
und sehen das einfach als Legacy an.
Wollen wir nicht mehr.
Serverless-First.
Dazu muss man sagen,
diese Unternehmen sind natürlich von der Mitarbeiterstruktur her
sehr, sehr jung im Verhältnis
zu mir zum Beispiel.
Okay.
Ich war natürlich auch in frühen Jahren
irgendwie kurz nach dem Studium und so weiter,
sage ich,
hier neue Technologie,
machen wir alles damit,
wir haben es auch richtig gemacht,
die machen das auch richtig,
das ist ja nicht, dass die sagen,
oder dass ich sage,
die stoßen sich jetzt ihre Hörner ab
und dann machen sie das dann doch besser auf der Mainframe,
nein,
die wissen, was sie machen,
die machen das gut
und ältere Entwickler,
das soll jetzt gar nicht negativ sein,
gar nicht negativ bewertend sein,
sind halt so,
die tun sich schwer mit neuen Dingen.
Das merke ich auch teilweise,
ich brauche länger,
um mich in neue Technologien einzuarbeiten,
teilweise, um es richtig zu verstehen,
never change the running system,
was einmal läuft, läuft immer weiter.
Das ist okay,
das bringt der Lauf der Zeit einfach so mit sich.
Damit muss man leben,
müssen wir alle leben,
werden älter und in Teilweisen werden wir auch langsamer.
Aber dieser Serverless-First-Ansatz
wird sich mehr und mehr durchsetzen
und mit der Zeit auch weiter publik werden.
Wir hatten vorhin Simon Wortley angesprochen,
ich habe mal einen Tweet von ihm gesehen mit einer Übersicht,
und er hat gesagt,
wann so Begriffe wie Cloud, virtuelle Server,
Container und auch Serverless
das erste Mal erwähnt wurden
und wie lange sie brauchen,
bis sie Commodity werden, wie er immer sagt.
Und das ist immer so,
je nach Technologie unterschiedlich
zwischen 30 und 60 Jahre dauert sowas,
bis das Konzept das erste Mal erwähnt wurde
und bis es dann wirklich Commodity ist.
Container sind heutzutage noch immer nicht Commodity,
das ist immer noch so,
wenn man den Gartner-Hype-Cycle nimmt,
so ein bisschen immer noch oben auf der Spitze.
Und für Serverless wird das einfach noch ein bisschen dauern.
Ich schicke dir gerne mal den Link dann auf den Tweet,
den kannst du dann auch im Podcast verlinken.
Super.
Wenn die Zuhörer sich das mal anschauen,
wie Simon Wortley das sieht.
Okay, gut.
Das heißt also, das ist ja interessant,
haben wir ein schönes Schlusswort.
Und wenn ich das mal so zusammenfasse,
das ist ein interessantes Thema.
Wenn ich das richtig verstanden habe,
wird es grundsätzlich noch ein bisschen dauern
und in Deutschland auch vielleicht noch ein bisschen länger.
Genau, was der Bauer nicht kennt, frisst er nicht.
Und in Deutschland haben wir das schon immer so gemacht
und dann machen wir auch weiterhin so
und dieses neue Zeug.
Und gerade wenn das von amerikanischen Unternehmen kommt,
die mit der NSA zusammenarbeiten,
das kann ja nur schlecht sein.
Okay, dann haben wir doch noch ein bisschen Zirkulation zum Ende.
Alles klar.
Gut.
Nico, hast du noch was?
Das ist nicht meine Meinung, das höre ich nur sehr oft.
Okay, Zitat Ende.
Ja, okay, ist in Ordnung.
Alles klar.
Hast du noch irgendwas, was du zu sagen wolltest zum Schluss,
was wir fachlich noch nicht besprochen haben?
Ich glaube auch,
wir könnten uns noch zwei Stunden weiter unterhalten, glaube ich.
Also mein guter Rat ist,
für die Leute, die irgendwie Interesse haben,
aber nicht so genau wissen, was das ist,
fangt einfach mal an.
Es gibt zahlreiche Webseiten,
die irgendwelche Tutorials bieten.
Es gibt spezielle Serverless-Podcasts.
Es gibt Newsletter dazu,
die behandeln Entwicklungsthemen,
Deployment-Themen,
teilweise auch rechtliche Themen und so weiter.
Also super spannend, interessant, gibt ganz viel.
Da kann ich dir, glaube ich,
auch ein paar Links nochmal zur Verfügung stellen.
Das ist ja die Aufforderung,
dass du mir noch was zusagst.
Ja, genau.
Das macht…
Das mache ich auch.
Das kann ich auch reinpacken, jawohl.
Und ja, einfach mal anfangen, ausprobieren,
sich damit beschäftigen, erste Erfahrungen sammeln.
Eigentlich das, was DevOps dann auch meint.
Anfangen, machen, ausprobieren,
wegschmeißen, neu machen, besser machen.
Machen ist wie wollen, nur krasser, ne?
Genau.
Ja, okay.
Gut, dann danke ich dir für diesen Podcast.
Der ist jetzt…
Ich muss nachher nochmal zusammenrechnen, mal schauen.
Aber ich glaube, der ist ein bisschen länger als die anderen.
Aber ich fand es sehr interessant,
gerade für mich als BWLer, eben als Nicht-Techniker,
so ein paar Dinge mal gehört zu haben zu dem ganzen Umfeld.
Und insofern vielen Dank an meiner Stelle,
hier von mir an dich, Nico.
Sehr, sehr gerne.
Hat mir Spaß gemacht, Dirk.