Warum sollten IT-Projekte auf Serverless setzen? F\u00fcr Teams, die bereits auf eine Cloud-Infrastruktur (AWS, Azure, IBM etc.) setzen, ist die Argumentation im Grunde ein No-Brainer: Wer bereits den Cloudgedanken akzeptiert hat, also dass der Cloudanbieter die Virtualisierung, die Serverfarmen, die Skalierung und anderes \u00fcbernimmt, so gilt die gleiche Argumentation f\u00fcr Serverless. Serverless folgt daher dem Servicegedanken und wir nennen es auch (FaaS = Function as a Service).<\/p>\n
Ganz einfach: F\u00fcr gew\u00f6hnlich k\u00fcmmert sich ein weiterer Infrastrukturdienstleister oder spezielle Leute im Team darum, auf dem Cloudservice z.B. Container zu betreiben, die letztlich die Anwendungen ausf\u00fchren, also bereitstellen. Das Gleiche gilt f\u00fcr die Ver\u00f6ffentlichung der Software: Jemand k\u00fcmmert sich darum.<\/p>\n
Doch durch den Servicegedanken IaaS und PaaS (Infrastructure as a Service und Platform as a Service) ist uns bereits das Konzept klar, solche Low-Level-Aufgaben als Standardpaket zu nutzen.<\/p>\n
Wir setzen also Cloudservices ein, weil dies zu mehr Standardisierung, zu mehr Skalierbarkeit, zu effizienteren Abrechnungsmodellen f\u00fchrt. Damit erh\u00f6hen wir die Zuverl\u00e4ssigkeit unserer Softwareprodukte, die Planungssicherheit und erzielen daraus letztlich finanzielle Vorteile.<\/p>\n
Function as a Service (FaaS = Serverless) minimiert die Time-to-Market weiter. Container m\u00fcssen nicht explizit auf Funktion getestet werden. Die Containerisierung schl\u00e4gt nicht fehl. Wir haben weniger Risiken. Eine Softwarelieferung (ein Release) wird daher einfacher bzw. zuverl\u00e4ssiger. Weniger manuelle Aufw\u00e4nde und Zwischenf\u00e4lle bei Inbetriebnahmen f\u00fchren zu k\u00fcrzerer Iteration bzw. Features k\u00f6nnen schneller ausgeliefert werden.<\/p>\n
Schon bei Evolutionsschritten in die Cloud haben wir verstanden, dass wir die Ressourcen an unseren tats\u00e4chlichen Bedarf anpassen k\u00f6nnen. Diese Effekte und Vorteile der Cloud sind bekannt. Konkret gesprochen: Unsere IT muss nicht erst neue Server bestellen, anliefern, montieren lassen und so weiter, damit mehr Last, mehr User, h\u00f6herer Bedarf unserer Kunden gedeckt werden kann. Mit wenigen Klicks in den Konsolen des Cloudanbieters kann die IT nun Ressourcen loswerden, wenn diese nicht mehr ben\u00f6tigt werden, bzw. neue Ressourcen dazunehmen, sobald sich der Bedarf erh\u00f6ht. Durch das sogenannte Auto-Scaling ist dies sogar automatisch m\u00f6glich. Beispielsweise an verschiedenen Werktagen oder bei gewissen Ereignissen, wie Produktvorstellungen oder saisonalen Ereignissen.<\/p>\n
Dieses Konzept l\u00e4sst sich mit Serverless noch effizienter gestalten. Kosten fallen nun nur noch an, wenn gewisse Funktionen auch tats\u00e4chlich verwendet werden.<\/p>\n
Angenommen Ihr Team betreibt einen Blog. In diesem Blog k\u00f6nnen Artikel auf Social Media Plattformen geteilt werden, Artikel gesucht, gelesen und kommentiert werden. Nach dem urspr\u00fcnglichen Konzept fallen Kosten f\u00fcr einen bestimmten Server an, auf dem eine Software vorliegt (die Blog-Anwendung), die all diese Funktionen erm\u00f6glicht.<\/p>\n
Egal ob 10.000 User oder 100 Ihren Blog pro Monat aufrufen und egal welche Funktionalit\u00e4t sie davon verwenden. Die Skalierbarkeit der Cloud erm\u00f6glicht es nun, dynamisch in einem Monat die Ressourcen f\u00fcr 10.000 Nutzer zur Verf\u00fcgung zu stellen, w\u00e4hrend die Ressourcen im n\u00e4chsten Monat so reduziert werden k\u00f6nnen, dass sie die 100 Nutzer bestm\u00f6glich versorgt, allerdings die Kosten der nicht ben\u00f6tigten Ressourcen einspart. F\u00fcr Teams, die bereits auf die Cloud setzen, ist dies nichts Neues.<\/p>\n
Was aber, wenn die in einem Monat, in dem 10.000 User ihren Blog verwenden, nur knapp 1.000 davon, ihre Artikel kommentieren, 9.000 von ihnen aber nicht? Sie bezahlen das Feature „Artikel kommentieren“ f\u00fcr 9.000 Nutzer, die es nicht nutzen.<\/p>\n
Mit Serverless ist es nun m\u00f6glich, ausschlie\u00dflich f\u00fcr die Ausf\u00fchrung der reinen Funktionalit\u00e4t zu zahlen. Die 9.000 Nutzer im Beispiel oben w\u00fcrden demnach f\u00fcr das Kommentieren keine Kosten erzeugen, lediglich f\u00fcr andere Aktionen, wie Lesen und Teilen.<\/p>\n
Der ROI (Return on Investment) ist an der Stelle nat\u00fcrlich erst mit konkreten Zahlen zu erreichen, die den Betrieb der Instanzen (also der Ressourcen, die eine Anwendung wie den Blog in unserem Beispiel) f\u00fcr 10.000 Nutzer in dem Monat pauschal verf\u00fcgbar machen, den Kosten f\u00fcr die Nutzung der jeweiligen Features gegen\u00fcberstellen. Das ist vielleicht Stoff f\u00fcr einen weiteren Artikel. Kommentiert doch bitte, falls dies interessant w\u00e4re.<\/p>\n
Wie im Beispiel oben, fallen nat\u00fcrlich nicht nur Kosten in ungenutzten Zeiten (Idle-Times) an, Server laufen, sind in Standby und verbrauchen w\u00e4hrenddessen Ressourcen. Nicht bei Serverless. Die Technologie verteilt die Ausf\u00fchrung der Funktionalit\u00e4t optimal auf die entsprechende Infrastruktur, sodass die entsprechenden Funktionalit\u00e4ten stets zur Verf\u00fcgung stehen – bei jeder Bedarfssteigerung und Minderung.<\/p>\n
In Teams, die Container verwenden, braucht es Mitglieder im Team, die sich darum k\u00fcmmern, dass die Anwendungen korrekt in Container verpackt werden, dass die Anwendungen der QS unterzogen werden, dass die Releases automatisiert funktionieren etc. Diese Aufgabe geht nicht auf Null, denn weiterhin m\u00fcssen die allgemeinen Zyklen wie Planung, Entwicklung, Test, Release etc. automatisiert durchgef\u00fchrt werden. Doch diese Themen werden schlanken. Es muss weiterhin entwickelt und getestet werden, soweit ist klar. Doch Container m\u00fcssen nicht hergestellt, versioniert und verwahrt werden. Dadurch werden Routineaufgaben bzw. Wartungsaufgaben vermindert, weniger Fehler treten auf und es fallen weniger Lizenzgeb\u00fchren an.<\/p>\n
Die Vorteile f\u00fcr IT-Projekte und Teams durch Serverless sind somit recht deutlich. Die feinere Skalierbarkeit auf der Ebene der Funktionalit\u00e4ten und nicht auf Anwendungsebene erm\u00f6glicht eine weitere Steigerung von Verf\u00fcgbarkeiten und geringere Kosten durch weniger Aufwand. Es gibt aus meiner Sicht keinen Grund, nicht auf Serverless setzen.<\/p>","protected":false},"excerpt":{"rendered":"
Warum sollten IT-Projekte auf Serverless setzen? F\u00fcr Teams, die bereits auf eine Cloud-Infrastruktur (AWS, Azure, IBM etc.) setzen, ist die Argumentation im Grunde ein No-Brainer: Wer bereits den Cloudgedanken akzeptiert hat, also dass der Cloudanbieter die Virtualisierung, die Serverfarmen, die Skalierung und anderes \u00fcbernimmt, so gilt die gleiche Argumentation f\u00fcr Serverless. Serverless folgt daher dem […]<\/p>","protected":false},"author":1,"featured_media":485,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[42],"tags":[87,45,127,125,126,32,128,129],"class_list":["post-481","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologien","tag-cloud","tag-devops","tag-infrastruktur","tag-serverless","tag-skalierbarkeit","tag-team","tag-uptime","tag-vorteile"],"yoast_head":"\n