Cloud & Infrastruktur Foto: Fotolia / Maxim Kzmin Function as a Service treibt die Cloud voran Warum das Zeug zum nächsten großen Cloud-Trend hat. das klingt wie Atmen ohne Luft, Singen ohne Ton oder Braten ohne Fett. Serverless impliziert das gänzliche Fehlen von Maschinen, sagt Manuela Rink, Technical Evangelist Mobile Platform bei der Microsoft Deutschland GmbH, aber ganz so einfach ist es nicht. Natürlich kommt auch nicht wirklich ohne Rechenressourcen aus der Anwender kümmert sich nur nicht mehr darum. Im Gegensatz zu anderen Cloud-Bereitstellungsmodellen besteht bei Serverless nicht die Notwendigkeit, selbst Infrastruktur aufzusetzen, das übernimmt vollständig der verwaltete Service, erklärt Sascha Möllering, Solutions Architect bei der Amazon Web Services Germany GmbH (AWS), das Prinzip. Function as a Service Mit auch als Function as a Service (FaaS) bezeichnet, erreicht Cloud-Computing nach Infrastructure as a Service (IaaS) und Platform as a Service (PaaS) die nächste Abstraktionsebene. Die Einheit, die bereitgestellt wird, ist eine Funktion, keine Applikation wie bei PaaS oder ein Server wie bei IaaS, sagt Jens Kuehlers, Cloud Platform Solutions Engineer bei Google. Anders als bei Software as a Service (SaaS) ist der Kunde bei FaaS aber nicht auf vorgefertigte Pakete angewiesen, sondern stellt sich mit selbst geschriebenen oder auch vom Provider beziehungsweise aus der Open-Source-Community stammenden Komponenten seinen eigenen Workflow zu- 42 4/2017 com! professional
Cloud & Infrastruktur sammen. Beim Betreiben einer Serverless- Computing-Architektur wird eine Anwendung in einzelne Funktionen wie Benutzer-Registrierung, Login oder Passwort-Erinnerung aufgeteilt, sagt Philipp Müns, Senior Software Engineer bei Serverless, Inc., dem Entwickler des ersten Serverless Application Frameworks. Diese Funktionen werden anschließend beim Cloud-Provider hochgeladen und mit Infrastrukturkomponenten wie Datenbanken oder Speicher verknüpft. Business-Logik im Fokus Laut Sascha Möllering von AWS kommt der Anwender auf diese Weise schneller zu funktionsfähigen Applikationen und kann sich besser auf die eigentliche Business-Logik dahinter konzentrieren: Es besteht nicht mehr die Notwendigkeit, sich über das Sizing, die Hochverfügbarkeit und das Monitoring von Servern Gedanken zu machen. Außerdem werden Prognosen darüber, ob, wann und wie viele Nutzer auf eine Applika tion zugreifen, überflüssig, sagt Philipp Müns von Serverless: Es ist kein Problem, von jetzt auf gleich eine Million mehr Anfragen zu beantworten. Bezahlen muss der Kunde nur, wenn eine Funktion auch wirklich ausgeführt wird. Diese Art der Architektur ist damit deutlich kosteneffizienter, erklärt Möllering. Der AWS-Solutions-Architekt weist allerdings darauf hin, dass sich Serverless nicht mit NoOps gleichsetzen lässt: Operations bedeutet deutlich mehr als nur die Administration von Servern. Monitoring, Deployment und Networking bleiben als Aufgaben im Software-Betrieb erhalten. Durch die extreme Modularisierung einer Serverless-Applikation können Software-Teams zudem sehr viel unabhängiger voneinander arbeiten. Das geht sogar so weit, dass die Code-Basis auf Funktionsebene verschieden sein kann. Ist eine andere Programmiersprache als die sonst im Projekt verwendete für eine bestimmte Aufgabe besser geeignet, kann das verantwortliche Team sie einfach nutzen, ohne das vorher mit der gesamten Entwicklermannschaft absprechen zu müssen, so Müns. Stärkerer Vendor-Lock-in Bei setzt sich ein Trend fort, den man aus den anderen Bereitstellungsmodellen bereits kennt: Je Foto: Serverless Inc. Beim Betreiben einer Serverless-Computing-Architektur wird eine Anwendung in einzelne Funktionen ( ) aufgeteilt. Philipp Müns Senior Software Engineer Serverless Inc. https://serverless.com mehr man sich von der eigentlichen Infrastruktur entfernt, desto abhängiger wird man vom jeweiligen Cloud-Provider. Lassen sich beispielsweise virtuelle Maschinen noch recht einfach von einem IaaS-Angebot auf ein anderes verschieben, so wird der Umzug einer Applikation bei PaaS bereits schwieriger und ist bei FaaS mit ganz erheblichem Aufwand verbunden. Baut man eine Anwendung innerhalb einer Plattform, lässt sich nicht ohne Weiteres der Anbieter wechseln oder die Applikation beliebig woanders hosten, sagt Manuela Rink von Microsoft. René Büst, Director Market Research & Technology Evangelism beim KI-Spezialisten Arago, sieht im Vendor-Lock-in allerdings nicht notwen digerweise ein Problem: Wer sich ohnehin für eine Cloud-Umgebung wie AWS oder Microsoft Azure entschieden hat, um dort eine Microservice-Architektur aufzubauen, der wird auch nicht vor zurückschrecken. Statt sich um Abhängigkeiten Sorgen zu machen, sollte man lieber die vielen vorgefertigten Services optimal nutzen, die solche Plattformen zur Verfügung stellen, rät Büst. So bekommt man seine Applikation sehr viel schneller lauffähig, als wenn man alles selbst entwickeln müsste. Aber auch wenn man sich ganz auf einen Anbieter verlassen will, gibt es auf dem Weg zu einer Serverless-Infrastruktur einige Hürden. Noch ist die Technologie neu, vielfach fehlt das Know-how. Entwickler, die ausreichend Erfahrung in diesem Bereich sammeln konnten, sind aktuell nicht leicht zu finden, sagt Philipp Müns. Experimentierfreude und eine gewisse Frustrationstoleranz sollte man deshalb schon mitbringen, wenn man sich auf Serverless einlässt. Erfolge stellen sich aber relativ schnell ein, weiß Michael Muckel, Vice President of Engineering bei der ProSiebenSat1-Tochter glomex, aus eigener Erfahrung: Die Lernkurve ist sehr steil. (siehe dazu auch das Interview auf Seite 48). Foto: AWS Im Gegensatz zu anderen Cloud-Modellen besteht bei Serverless nicht die Notwendigkeit, selbst Infrastruktur aufzusetzen. Sascha Möllering Solutions Architect Amazon Web Services https://aws.amazon. com/de Ideal für neue Projekte Für erste Gehversuche mit eignen sich deshalb vor allem neue Projekte. Sie sollten überschaubar und relevant, aber nicht geschäftskritisch für ein Unternehmen sein. Ein gutes Beispiel für ein solches Projekt ist die in mehreren Ländern durchgeführte Face of Kinder -Kampagne des Süßwarenherstellers Ferrero, bei der Eltern Porträtfotos ihrer Sprösslinge auf eine Internetplattform hochladen können. Dort wird dann per Voting über das Gesicht entschieden, das künftig als Face of Kinder in der jeweiligen Region auf der Schokoladenpackung zu sehen ist. Basierte die erste, in Brasilien durchgeführte Aktion noch auf einer eher klassischen Cloud-Infrastruktur, so setzte der Hersteller für Folgeprojekte in Ungarn, Mexiko und Israel den Serverless-Dienst AWS Lambda ein. Mit dieser Entscheidung ließ sich nicht nur die Dauer des Rollouts auf weni- com! professional 4/2017 43
Cloud & Infrastruktur ge Wochen reduzieren, auch die Gesamtkosten für den Betrieb sanken um 75 Prozent, da keine Infrastruktur vorgehalten werden musste, sondern nur Kosten anfielen, wenn Anwender die Funktionen auch tatsächlich nutzten. Das Ferrero-Projekt ist noch aus weiteren Gründen sehr gut für die Umsetzung mit Serverless Computing geeignet: Es ist zeitlich begrenzt, weshalb es wenig sinnvoll ist, eine komplexe Infrastruktur dafür aufzubauen und zu unterhalten. Außerdem lässt sich die Nachfrage kaum abschätzen, vor allem aber schwankt sie extrem: Immer wenn ein Radio- oder Fernsehspot die Aktion bewirbt, steigen die Upload-Zahlen innerhalb von Sekunden enorm an, sagt Dieter Berz-Vöge, Geschäftsführer beim Dienstleister Storm Reply, der sich auf die Umsetzung von Kundenprojekten auf der Amazon-Plattform AWS spezialisiert hat und unter anderem die Internetauftritte der meisten Ferrero-Marken betreut. Diese Verkehrsspitzen ließen sich mit AWS Lambda sehr gut abfangen, so Berz-Vöge weiter. Unsere Erfahrungen zeigen, dass Serverless-Services linear skalieren. Beim Einsatz von Autoskalierungsmechanismen oder Docker-Systemen könne es dagegen in der Aufwärmphase zu Verzögerungen und Leistungseinbußen kommen. Im Umkehrschluss wird klar, für welche Szenarien sich Serverless Computing zumindest derzeit noch nicht eignet: Komplexe, geschäftskritische Applikationen, die womöglich noch auf einer herkömmlichen Software-Architektur basieren und viele Abhängigkeiten von proprietären Systemen aufweisen, sollte man sicher nicht als erstes Serverless-Computing-Projekt auswählen. Bestimmte Aufgaben lassen sich aber auch Foto: Google Die Einheit, die bereitgestellt wird, ist eine Funktion, keine Applikation wie bei PaaS oder ein Server wie bei IaaS. Jens Kuehlers Cloud Platform Solutions Engineer bei Google https://cloud.google.com in solchen Umgebungen gut als Function as a Service auslagern, so zum Beispiel ETL-Prozesse (Extract, Transform, Load) oder andere Formen von Data-Pipelines. Wenig sinnvoll ist eine Migration auch bei relativ statischen Plattformen, bei denen das Traffic-Aufkommen vorhersehbar ist. Hierbei ist es meist einfacher, die Applikation wie bisher zu entwickeln und auf einen üblichen Server hochzuladen, sagt Philipp Müns von Serverless. Die Serverless-Angebote Auch wenn vor allem in Entwicklerkreisen auf großes Interesse stößt, ist das Angebot noch überschaubar. Eine relativ große Zahl an Anwendern, die tatsächlich produktiv einsetzen, kann der Amazon-Service AWS Lambda vorweisen. Der Dienst, 2014 auf der AWS-Konferenz re:invent vorgestellt, wird bereits von Unternehmen wie Coca Cola, Ferrero, Thomson Reuters, Periscope und Associated Press oder auch der Pro- SiebenSat1-Tochter glomex produktiv eingesetzt. AWS Lambda kann aus verschiedenen anderen AWS-Services wie Amazon S3, DynamoDB, Kinesis oder Cognito aufgerufen werden. Lädt ein Nutzer beispielsweise ein Bild in einen definierten S3-Bucket, so lässt sich aus diesem Ereignis automatisch eine Lambda-Funktion anstoßen, die das Bild bearbeitet. Über Amazon Echo beziehungsweise Lex kann der Entwickler seine Funktion sprachgesteuert triggern. Eigene Aufrufe lassen sich über das Amazon API Gateway per HTTPS definieren. Es ist auch möglich, eine Lambda-Funktion direkt aus einer Applikation anzustoßen, ohne dass eine Event-Quelle definiert werden muss. Serverless-Applikationen: Vor- und Nachteile Diese Argumente sprechen für oder gegen den Einsatz von Function as a Service: Kein Verwaltungsaufwand. Der Provider stellt die für die Ausführung der Funktionen notwendige Cloud-Umgebung zur Verfügung. Skalierbarkeit. Funktionen können beliebig oft aufgerufen werden, ohne dass bei der Entwicklung oder im Betrieb Skalierungsmechanismen definiert werden müssen. Kostenflexibilität. Der Kunde bezahlt nur, wenn eine Funktion auch tatsächlich genutzt wird. Schnelligkeit. Da sich Entwickler ganz auf die funktionalen Aspekte eines Projekts konzentrieren können, lassen sich Lösungen schneller auf den Markt bringen. Unabhängigkeit. Einzelne Funktion sind unabhängig voneinander lauffähig und können sogar in unterschiedlichen Programmiersprachen codiert sein. Latenzgefahr. Selten aufgerufene Funktionen benötigen relativ viel Zeit bis zum Start. Nicht funktionale Einschränkungen. Arbeitsspeicher und die für die Ausführung einer Funktion zur Verfügung stehende Zeit sind begrenzt. Höhere Komplexität. Die sehr kleinteilige Architektur erhöht den Aufwand für Orchestrierung, Monitoring, Logging und Fehlersuche. Abhängigkeit vom Anbieter. Severless-Applikationen lassen sich nicht ohne Weiteres auf eine andere Cloud- Plattform migrieren. 44 4/2017 com! professional
Cloud & Infrastruktur Abrechnungsbasis für AWS Lambda ist die Zahl der Funktionsaufrufe und die Verarbeitungszeit. Diese berechnet sich aus der Dauer des Funktionsaufrufs, gerundet auf 100 Millisekunden, und der zugewiesenen Arbeitsspeichergröße. Gemessen wird sie in GByte/s. Die erste Million Anforderungen pro Monat sowie 400.000 GByte/s Datenverarbeitungszeit sind kostenlos. Für jede zusätzliche Million Aufrufe fallen 20 US-Cent an, 100.000 GByte/s weitere Verarbeitungszeit schlagen mit 1,667 Dollar zu Buche. Andere am Funktionsaufruf beteiligte Komponenten, etwa das API-Gateway, können zusätzliche Kosten verursachen. Die Berechnung der Aufwände ist nicht ganz einfach, denn wie viele Aufrufe tatsächlich im kostenlosen Kontingent laufen können, hängt von der Arbeitsspeichergröße ab, die einer Funktion zugewiesen wird. Eine Tabelle auf der Preisdetail- Seite von AWS Lambda (https://aws.amazon.com/de/lamb da/pricing/) hilft bei der Abschätzung. Sie listet auf, wie viel eine Funktion in Abhängigkeit vom zugewiesenen Arbeitsspeicher pro 100 Millisekunden kostet und wie viele Sekunden sie im kostenlosen Kontingent laufen kann. Projekt: Der Süßwarenkonzern Ferrero setzte für seine Kampagne Face of Kinder auf den Serverless-Dienst AWS Lambda. Eine Open-Source-Alternative zu AWS bietet OpenWhisk von IBM. Die Plattform ist als Service in der IBM-Cloud Bluemix verfügbar, lässt sich aber auch als Apache OpenWhisk (http://openwhisk.org) herunterladen und lokal installie- Anbieter von (Auswahl) Hersteller / Produkt Amazon Web Services / AWS Lambda Google / Google Cloud Functions Microsoft / Azure Functions IBM / IBM Bluemix OpenWhisk Internet https://aws.amazon.com/ de/lambda https://cloud.google.com/ functions https://azure.microsoft. com/de-de/services/ functions https://www.ibm.com/ cloud-computing/ bluemix/openwhisk Release-Stand: Produktiv / Beta / Alpha Bereitstellung: Cloud / On Premise Unterstützte Programmiersprachen: Node.js / Python / Java / Swift / / / / / / / / / / / / / / / / / / / / / / / / Sonstige unterstützte Programmiersprachen C# PowerShell, PHP, JS, C#, F#, Bash Docker-Unterstützung Aufruf per CLI / HTTP(S)- Request / CRON-Job / / / / / / / / Sonstige Aufrufmöglichkeiten AWS-Services im Hintergrund bei Cloud-Pub/Sub-Topicoder Cloud-Storage- Bucket-Änderungen Webhooks, Timing Triggers, REST-Calls ios SDK Services: Monitoring / automatische Skalierung / Load Balancing / Datensicherung / / / / / / / / / / / / Sonstige Services Integration mit bestehenden Cloud-Diensten Abrechnungsmodell Anzahl der Anforderungen / Ausführungszeit (GB/s) noch keine Angaben GB/s * Transaktionsanzahl GBs Abrechnungsintervall 100 ms noch keine Angaben 1 s 100 ms Kosten (Dollar) 0,20 USD pro 1 Mio. Anforderungen; 0,00001667 USD pro GB/s während der Alpha-Phase gratis 0,20 USD pro 1 Mio. Anforderungen; ca. 0,000016 USD pro GB/s 0.000017 USD pro GBs Kostenloses Kontingent 1 Mio. Anforderungen / 400.000 GB/s pro Monat noch keine Angaben 1 Mio. Aufrufe / 400.000 GB/s pro Monat 400.000 GBs pro Monat com! professional 4/2017 45
Cloud & Infrastruktur ren. Ebenso wie AWS Lambda definiert der Entwickler Ereignisse, die bestimmte Funktionen auslösen. Er kann dies aus anderen Bluemix-Diensten wie Cloudant oder Watson, über das Command Line Interface (CLI) oder auch mit Hilfe des ios SDKs tun. Die Abrechnung entspricht ebenfalls dem AWS-Schema, allerdings weist IBM die Funktionsaufrufe nicht extra aus und nennt seine Abrechnungseinheit nicht GB/s, sondern GBs (Gigabyte* Sekunde). Der Verbrauch wird auf 100 Millisekunden genau gerundet, 400.000 GBs Rechenzeit sind pro Monat frei. Jede weiteren 100.000 GBs kosten 1,7 Dollar. Microsoft bietet seine Function-as-a-Service- Lösung Azure Functions auf GitHub ebenfalls als Open Source an. So kann man diese Technik losgelöst von der Plattform Azure im eigenen, vielleicht selbst gehosteten Ökosystem nutzen, sagt Manuela Rink. Azure Functions zeichnet sich unter anderem dadurch aus, dass es eine ganze Reihe von Programmiersprachen unterstützt, in denen die Funktionen umgesetzt werden können, darunter F#, C#, Node.js, PHP und Foto: Arago GmbH Wer sich ohnehin für eine Cloud-Umgebung wie AWS oder Microsoft Azure entschieden hat ( ), der wird auch nicht vor zurückschrecken. René Büst Director Market Research & Technology Evangelism www.arago.co Python. Aufrufe lassen sich unter anderem zeitbasiert definieren, durch die Aktivität eines anderen Azure-Dienstes auslösen oder auch über eine SaaS-Lösung wie OneDrive triggern. Abrechnungsmodell, Freikontingente sowie Preise entsprechen weitgehend denen von AWS beziehungsweise IBM. Microsoft bietet einen Preisrechner zur Abschätzung der Kosten an: https://azure.microsoft.com/de-de/pricing/cal culator. Noch in einem frühen Alpha-Stadium befindet sich Google Cloud Functions. Google hat im Vergleich zu AWS, Microsoft oder IBM deutlichen Nachholbedarf, was betrifft, sagt René Büst. Cloud Functions erlaubt es, Funktionen in Node.js zu entwickeln, die auf Ereignisse wie HTTP-Anfragen, auf Änderungen in den Google Cloud Storage Buckets oder auch auf Nachrichten aus Goo gle Cloud Pub/Sub Topics reagieren. Im Gegensatz zu anderen Anbietern bieten wir eine Outof-the-Box-Integration von HTTP(S) an, die ohne weitere Komponenten auskommt, sagt Google-Solutions-Engineer Jens Kuehlers. Entwickler können zudem einen lokalen Emulator nutzen sowie Abhängigkeiten automatisch auflösen lassen. Platformen im Vergleich Bei muss sich der Anwender anders als bei IaaS und PaaS nicht um Aufgaben wie Kapazitätsplanung, Skalierbarkeit und Flexibiltät kümmern. Infrastructure as a Service Platform as a Service com! professional 4/17 Verwaltung durch Kunden Verwaltung durch Anbieter Quelle: Crisp Research 46 4/2017 com! professional
Cloud & Infrastruktur Eher einen Nischenmarkt bedienen Auth0 mit seinem Produkt Webtask, das derzeit lediglich Node.js unterstützt, sowie Iron.io, das auf Basis von Docker-Containern eine Serverless-App-Plattform anbietet, deren Backend in Go geschrieben ist. Frameworks helfen beim Einstieg Projekte wie das Serverless Framework, Zappa oder auch das als Chalice bekannte Python Serverless Microframework für AWS sollen den Entwicklern die Arbeit an FaaS-Projekten erleichtern und deren Umsetzung beschleunigen. Bei einer manuellen Inbetriebnahme einer Funktion muss der Entwickler den Code selbst packen, beim Cloud- Anbieter hochladen und alle notwendigen Abhängigkeiten erzeugen, damit die jeweilige Funktion ereignisbasiert aufgerufen werden kann. Dieser Prozess ist langwierig, fehleranfällig, nur aufwendig reproduzierbar und nicht skalierbar, sagt Philipp Müns von Serverless. Im Serverless Framework beispielsweise lassen sich diese Aufgaben automatisieren. Eine Konfigurationsdatei beschreibt die notwendigen Komponenten und Abhängigkeiten. Ein Befehl auf der Kommandozeile erledigt dann sämtliche Schritte, die zuvor manuell ausgeführt werden mussten. So lassen sich nicht nur sim ple Aufgaben schnell und einfach als Serverless-Applikation in der Cloud erstellen, sondern auch umfangreiche Anwendungen, die eine komplexe Infrastruktur mit Hunderten von Funktionen und Services benötigen, verspricht Müns. Das Framework abstrahiert die Konfiguration der Infrastruktur außerdem so weit, dass sich die Anwendung von einer Cloud-Plattform auf eine andere übertragen ließe. Das komplette Framework ist Plug-in-basiert, aus diesem Grund lassen sich eigene Funktionen leicht hinzufügen, um zum Beispiel unternehmensspezifische Abläufe abbilden zu können. Serverless, Inc. bietet neben dem Framework auch weitere Tools an, die die Arbeit der Serverless-Entwicklerteams einfacher machen sollen. Derzeit arbeiten wir an Projekten, die Lösungen für äußerst komplexe Serverless-Architekturen bieten sollen, sagt Müns. Fazit Einzelne Serverless-Dienste gibt es zwar schon lange, doch als Cloud-Bereitstellungsmodell steht Serverless Compu- Foto: Microsoft Baut man eine Anwendung innerhalb einer Plattform, lässt sich nicht ohne Weiteres der Anbieter wechseln oder die Applikation beliebig woanders hosten. Manuela Rink Technical Evangelist Mobile Platform www.microsoft.de ting, auch Function as a Service (FaaS) genannt, noch ganz am Anfang. Immer mehr Unternehmen erkennen jedoch das Potenzial. Bis zu 75 % Betriebs- und Verwaltungskosten spart Serverless Computing Für das FaaS-Modell sprechen in erster Linie drei Gründe: Es entlastet Entwickler und Betreiber einer Applikation von Verwaltungsaufgaben, verursacht keine Kosten, solange eine Funktion nicht genutzt wird, und skaliert linear, ohne dass dafür Ressourcen vorgehalten werden müssten. Vor allem wenn es um sehr große Lastschwankungen geht, die womöglich in sehr kurzen Zeiträumen auftreten, ist das Serverless- Modell deshalb vom Preis-Leistungs-Verhältnis her gesehen unschlagbar. Neue Produkte lassen sich auf Basis einer Serverless-Infrastruktur darüber hinaus deutlich schneller auf den Mark bringen, da sich die Entwickler ganz auf die funktionalen Aspekte einer Applikation konzentrieren können. Allerdings sollte man vor der Entscheidung für Serverlesss Computing einige Punkte beachten. Zum einem ist die Abhängigkeit vom Cloud- Provider bei diesem Modell wesentlich höher als bei PaaS oder gar IaaS. Eine Migration zu einem anderen Anbieter ist wenn überhaupt nur mit hohem Aufwand und langen Transferphasen möglich. Die geringe Reife der Serverless-Plattformen bringt es außerdem mit sich, dass Überraschungen und Verzögerungen im Projektablauf nicht ausbleiben. Das sollte man einplanen. Immerhin versprechen Initiativen wie das Serverless Framework, Chalice oder Zappa hier wesentliche Verbesserungen. Ebenfalls berücksichtigen sollte man, dass Serverless-Plattformen den Funktionen Grenzen setzen, was Ausführungszeit und Speicher betrifft. Bei selten aufgerufenen Funktionen kann es außerdem zu einer deutlichen Verzögerung bei deren Ausführung kommen. Schließlich funktioniert Serverless Computing nur, wenn Applikationen direkt dafür ausgelegt sind. Für bestehende Anwendungen sind andere Cloud-Konzepte, etwa die Containerisierung über Docker, sinnvoller. Wer also seine Applikationen in viele kleine und abhängige Funktionen zerlegt und nicht auf sehr kurze, garantierte Antwortzeiten angewiesen ist, kann mit nicht nur bis zu 75 Prozent der Betriebs- und Verwaltungskosten sparen, sondern auch viel kürzere Entwicklungszeiten verbuchen. Foto: Storm Reply GmbH Unsere Erfahrungen zeigen, dass Serverless-Services linear skalieren. Dieter Berz-Vöge Geschäftsführer Storm Reply GmbH www.reply.com Thomas Hafen/js js@com-professional.de com! professional 4/2017 47