foto: fotolia / maxim kzmin · 42 serverless computing cloud & infrastruktur 4/2017 com!...

42

Serverless Computing

Cloud & Infrastruktur

4/2017 com! professional

Serverless Computing – das klingt wie Atmen ohne Luft,

Singen ohne Ton oder Braten ohne Fett. „Serverless im-

pliziert das gänzliche Fehlen von Maschinen“, sagt Manuela

Rink, Technical Evangelist – Mobile Platform bei der Mi-

crosoft Deutschland GmbH, „aber ganz so einfach ist es

nicht.“ Natürlich kommt auch Serverless Computing nicht

wirklich ohne Rechenressourcen aus – der Anwender küm-

mert 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.

Warum Serverless Computing das Zeug zum nächsten großen Cloud-Trend hat.

Serverless Computing treibt die Cloud voran

Function as a Service

Function as a ServiceMit Serverless Computing – auch als Function as a Service

(FaaS) – bezeichnet, erreicht Cloud-Computing nach Infra-

structure as a Service (IaaS) und Platform as a Service (PaaS)

die nächste Abstraktionsebene. „Die Einheit, die bereitge-

stellt wird, ist eine Funktion, keine Applikation wie bei PaaS

oder ein Server wie bei IaaS“, sagt Jens Kuehlers, Cloud Plat-

form 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-

Fo

to: F

oto

lia

/ M

axi

m K

zmin

sammen. „Beim Betreiben einer Serverless-

Computing-Architektur wird eine Anwendung

in einzelne Funktionen wie Benutzer-Registrie-

rung, Login oder Passwort-Erinnerung auf-

geteilt,“ 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 Infra-

strukturkomponenten wie Datenbanken oder

Speicher verknüpft.“

Business-Logik im FokusLaut Sascha Möllering von AWS kommt der

Anwender auf diese Weise schneller zu funkti-

onsfähigen Applikationen und kann sich bes-

ser auf die eigentliche Business-Logik dahinter

konzentrieren: „Es besteht nicht mehr die Not-

wendigkeit, sich über das Sizing, die Hochver-

fü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 Ar-

chitektur ist damit deutlich kosteneffizienter“, erklärt Mölle-

ring. Der AWS-Solutions-Architekt weist allerdings darauf

hin, dass sich „Serverless“ nicht mit „NoOps“ gleichsetzen

lässt: „Operations bedeutet deutlich mehr als nur die Admi-

nistration von Servern. Monitoring, Deployment und Networ-

king bleiben als Aufgaben im Software-Betrieb erhalten.“

Durch die extreme Modularisierung einer Serverless-Ap-

plikation können Software-Teams zudem sehr viel unabhän-

giger 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 ver-

wendete für eine bestimmte Aufgabe besser geeignet, kann

das verantwortliche Team sie einfach nutzen, ohne das vor-

her mit der gesamten Entwicklermannschaft absprechen zu

müssen“, so Müns.

Stärkerer Vendor-Lock-inBei Serverless Computing setzt sich ein Trend fort, den man

aus den anderen Bereitstellungsmodellen bereits kennt: Je

mehr man sich von der eigentlichen Infrastruk-

tur entfernt, desto abhängiger wird man vom

jeweiligen Cloud-Provider.

Lassen sich beispielsweise virtuelle Maschi-

nen noch recht einfach von einem IaaS-Ange-

bot auf ein anderes verschieben, so wird der

Umzug einer Applikation bei PaaS bereits

schwieriger und ist bei FaaS mit ganz erheb-

lichem Aufwand verbunden. „Baut man eine

Anwendung innerhalb einer Plattform, lässt

sich nicht ohne Weiteres der Anbieter wechseln

oder die Applikation beliebig woanders hos-

ten“, sagt Manuela Rink von Microsoft.

René Büst, Director Market Research & Tech-

nology Evangelism beim KI-Spezialisten Ara-

go, sieht im Vendor-Lock-in allerdings nicht

notwen digerweise ein Problem: „Wer sich oh-

nehin für eine Cloud-Umgebung wie AWS oder

Microsoft Azure entschieden hat, um dort eine

Microservice-Architektur aufzubauen, der wird

auch nicht vor Serverless Computing zurück-

schrecken.“ Statt sich um Abhängigkeiten Sor-

gen 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 entwi-

ckeln müsste.“

Aber auch wenn man sich ganz auf einen Anbieter verlas-

sen will, gibt es auf dem Weg zu einer Serverless-Infrastruk-

tur 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 Ser-

verless 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).

Ideal für neue ProjekteFür erste Gehversuche mit Serverless Computing eignen sich

deshalb vor allem neue Projekte. Sie sollten überschaubar

und relevant, aber nicht geschäftskritisch für ein Unterneh-

men sein. Ein gutes Beispiel für ein solches Projekt ist die in

mehreren Ländern durchgeführte „Face of Kinder“-Kampa-

gne des Süßwarenherstellers Ferrero, bei der Eltern Porträt-

fotos ihrer Sprösslinge auf eine Internetplattform hochladen

können. Dort wird dann per Voting über das Gesicht ent-

schieden, 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 Entschei-

dung ließ sich nicht nur die Dauer des Rollouts auf weni-

43

Cloud & InfrastrukturServerless Computing

com! professional 4/2017

▶

„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

Fo

to: A

WS

„Beim Betreiben einer Server-

less-Computing-Architektur wird

eine Anwendung in einzelne

Funktionen (…) aufgeteilt.“

Philipp Müns

Senior So'ware Engineer

Serverless Inc.

https://serverless.com

Fo

to: S

erv

erl

ess

Inc.

ge Wochen reduzieren, auch die Gesamtkosten

für den Betrieb sanken um 75 Prozent, da kei-

ne 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 Ser-

verless Computing geeignet: Es ist zeitlich be-

grenzt, weshalb es wenig sinnvoll ist, eine kom-

plexe Infrastruktur dafür aufzubauen und zu

unterhalten. Außerdem lässt sich die Nachfra-

ge kaum abschätzen, vor allem aber schwankt

sie extrem: „Immer wenn ein Radio- oder Fern-

sehspot die Aktion bewirbt, steigen die Up-

load-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 Ama-

zon-Plattform AWS spezialisiert hat und unter

anderem die Internetauftritte der meisten Fer-

rero-Marken betreut.

Diese Verkehrsspitzen ließen sich mit AWS Lambda sehr

gut abfangen, so Berz-Vöge weiter. „Unsere Erfahrungen zei-

gen, 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 Ser-

verless Computing zumindest derzeit noch nicht eignet: Kom-

plexe, 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-Pro-

jekt auswählen. Bestimmte Aufgaben lassen sich aber auch

in solchen Umgebungen gut als Function as a

Service auslagern, so zum Beispiel ETL-Prozes-

se (Extract, Transform, Load) oder andere For-

men von Data-Pipelines.

Wenig sinnvoll ist eine Migration auch bei re-

lativ statischen Plattformen, bei denen das Traf-

fic-Aufkommen vorhersehbar ist. „Hierbei ist es

meist einfacher, die Applikation wie bisher zu

entwickeln und auf einen üblichen Server hoch-

zuladen“, sagt Philipp Müns von Serverless.

Die Serverless-AngeboteAuch wenn Serverless Computing vor allem in

Entwicklerkreisen auf großes Interesse stößt,

ist das Angebot noch überschaubar.

Eine relativ große Zahl an Anwendern, die

Serverless Computing tatsächlich produktiv

einsetzen, kann der Amazon-Service AWS

Lambda vorweisen. Der Dienst, 2014 auf der

AWS-Konferenz re:invent vorgestellt, wird be-

reits 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-Ser-

vices wie Amazon S3, DynamoDB, Kinesis oder Cognito auf-

gerufen werden. Lädt ein Nutzer beispielsweise ein Bild in ei-

nen 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. Ei-

gene Aufrufe lassen sich über das Amazon API Gateway per

HTTPS definieren. Es ist auch möglich, eine Lambda-Funkti-

on direkt aus einer Applikation anzustoßen, ohne dass eine

Event-Quelle definiert werden muss.

44




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 o' aufgerufen

werden, ohne dass bei der Entwicklung oder im Betrieb

Skalierungsmechanismen definiert werden müssen.

☑ Kostenflexibilität. Der Kunde bezahlt nur, wenn eine Funk-

tion 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 von-

einander lau+ä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 er-

hö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.

Serverless-Applikationen: Vor- und Nachteile

Fo

to: G

oo

gle

„Die Einheit, die bereit-

gestellt 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

Abrechnungsbasis für AWS Lambda ist die Zahl der Funk-

tionsaufrufe und die Verarbeitungszeit. Diese berechnet sich

aus der Dauer des Funktionsaufrufs, gerundet auf 100 Milli-

sekunden, und der zugewiesenen Arbeitsspeichergröße. Ge-

messen 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 Funktions-

aufruf beteiligte Komponenten, etwa das API-Gateway, kön-

nen zusätzliche Kosten verursachen.

Die Berechnung der Aufwände ist nicht ganz einfach, denn

wie viele Aufrufe tatsächlich im kostenlosen Kontingent lau-

fen 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 Arbeits-

speicher pro 100 Millisekunden kostet und wie viele Sekun-

den sie im kostenlosen Kontingent laufen kann.

Eine Open-Source-Alternative zu AWS bietet OpenWhisk

von IBM. Die Plattform ist als Service in der IBM-Cloud Blue-

mix verfügbar, lässt sich aber auch als Apache OpenWhisk

(http://openwhisk.org) herunterladen und lokal installie-

45



▶

Projekt: Der Süßwarenkonzern Ferrero setzte für seine Kam-

pagne „Face of Kinder“ auf den Serverless-Dienst AWS Lambda.

Anbieter von Serverless Computing (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 Programmier-sprachen: 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-Topic- oder Cloud-Storage- Bucket-Änderungen

Webhooks, Timing Triggers, REST-Calls

iOS SDK

Services: Monitoring / auto-matische Skalierung / Load Balancing / Datensicherung

● / ● / ● / ○ ● / ● / ● / ○ ○ / ● / ● / ● ● / ● / ● / ○

Sonstige Services – – Integration mit bestehen-den Cloud-Diensten

–

Abrechnungsmodell Anzahl der Anforderun-gen / Ausführungszeit (GB/s)

noch keine Angaben GB/s * Transaktions-anzahl

GBs

Abrechnungsintervall 100 ms noch keine Angaben 1 s 100 ms

Kosten (Dollar) 0,20 USD pro 1 Mio. An-forderungen; 0,00001667 USD pro GB/s

während der Alpha-Phase gratis

0,20 USD pro 1 Mio. An-forderungen; 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

ren. Ebenso wie AWS Lambda definiert der

Entwickler Ereignisse, die bestimmte Funktio-

nen auslösen. Er kann dies aus anderen Blue-

mix-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, aller-

dings weist IBM die Funktionsaufrufe nicht ex-

tra aus und nennt seine Abrechnungseinheit

nicht „GB/s“, sondern „GBs“ (Gigabyte*

Sekunde). Der Verbrauch wird auf 100 Millise-

kunden genau gerundet, 400.000 GBs Rechen-

zeit 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 Tech-

nik losgelöst von der Plattform Azure im eige-

nen, vielleicht selbst gehosteten Ökosystem

nutzen“, sagt Manuela Rink.

Azure Functions zeichnet sich unter anderem

dadurch aus, dass es eine ganze Reihe von Pro-

grammiersprachen unterstützt, in denen die Funktionen um-

gesetzt werden können, darunter F#, C#, Node.js, PHP und

Python. Aufrufe lassen sich unter anderem zeitbasiert defi-

nieren, durch die Aktivität eines anderen

Azure-Dienstes auslösen oder auch über eine

SaaS-Lösung wie OneDrive triggern. Abrech-

nungsmodell, Freikontingente sowie Preise

entsprechen weitgehend denen von AWS be-

ziehungsweise 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 befin-

det sich Google Cloud Functions. „Google hat

im Vergleich zu AWS, Microsoft oder IBM deut-

lichen Nachholbedarf, was Serverless Compu-

ting betrifft“, sagt René Büst. Cloud Functions

erlaubt es, Funktionen in Node.js zu entwi-

ckeln, 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 Gegen-

satz zu anderen Anbietern bieten wir eine Out-

of-the-Box-Integration von HTTP(S) an, die oh-

ne weitere Komponenten auskommt“, sagt

Google-Solutions-Engineer Jens Kuehlers. Entwickler kön-

nen zudem einen lokalen Emulator nutzen sowie Abhängig-

keiten automatisch auflösen lassen.

46




Platformen im Vergleich

Bei Serverless Computing muss sich der Anwender – anders als bei IaaS und PaaS – nicht um Aufgaben wie Kapazitäts-

planung, Skalierbarkeit und Flexibiltät kümmern.

com! professional 4/17 Quelle: Crisp Research

Infrastructure

as a Service

Platform

as a ServiceServerless Computing

„Wer sich ohnehin für

eine Cloud-Umgebung

wie AWS oder Microsoft

Azure entschieden hat

(…), der wird auch nicht

vor Serverless Computing

zurückschrecken.“

René Büst

Director Market Research &

Technology Evangelism

www.arago.co

Fo

to: A

rag

o G

mb

H

Virtuelle Umgebung Virtuelle Umgebung










Verwaltung durch AnbieterVerwaltung durch Kunden

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung


Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

Virtuelle Umgebung

ting, auch Function as a Service (FaaS) genannt, noch ganz

am Anfang. Immer mehr Unternehmen erkennen jedoch das

Potenzial.

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 ei-

ne 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ög-

lich in sehr kurzen Zeiträumen auftreten, ist das Serverless-

Modell deshalb vom Preis-Leistungs-Verhältnis her ge-

sehen unschlagbar. Neue Produkte lassen sich auf

Basis einer Serverless-Infrastruktur darüber hi-

naus deutlich schneller auf den Mark bringen,

da sich die Entwickler ganz auf die funktiona-

len Aspekte einer Applikation konzentrieren

können.

Allerdings sollte man vor der Entscheidung

für Serverlesss Computing einige Punkte beach-

ten. 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 Anbie-

ter ist – wenn überhaupt – nur mit hohem Aufwand und lan-

gen 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 Frame-

work, Chalice oder Zappa hier wesentliche Verbesserungen.

Ebenfalls berücksichtigen sollte man, dass Serverless-Platt-

formen den Funktionen Grenzen setzen, was Ausführungs-

zeit und Speicher betrifft. Bei selten aufgerufenen Funktio-

nen kann es außerdem zu einer deutlichen Verzögerung bei

deren Ausführung kommen. Schließlich funktioniert Server-

less Computing nur, wenn Applikationen direkt dafür aus-

gelegt 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 Ant-

wortzeiten angewiesen ist, kann mit Serverless Computing

nicht nur bis zu 75 Pro-

zent der Betriebs- und

Verwaltungskosten spa-

ren, sondern auch viel

kürzere Entwicklungs-

zeiten verbuchen.

Eher einen Nischenmarkt bedienen Auth0 mit seinem Pro-

dukt Webtask, das derzeit lediglich Node.js unterstützt, so-

wie Iron.io, das auf Basis von Docker-Containern eine Ser-

verless-App-Plattform anbietet, deren Backend in Go ge-

schrieben ist.

Frameworks helfen beim EinstiegProjekte wie das „Serverless Framework“, „Zappa“ oder

auch das als „Chalice“ bekannte „Python Serverless Mi-

croframework für AWS“ sollen den Entwicklern die Arbeit an

FaaS-Projekten erleichtern und deren Umsetzung beschleu-

nigen. 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 auf-

gerufen werden kann. „Dieser Prozess ist langwierig, fehler-

anfällig, nur aufwendig reproduzierbar und nicht skalier-

bar“, sagt Philipp Müns von Serverless.

Im Serverless Framework beispielsweise lassen sich diese

Aufgaben automatisieren. Eine Konfigurationsdatei be-

schreibt die notwendigen Komponenten und Abhängig-

keiten. Ein Befehl auf der Kommandozeile erledigt

dann sämtliche Schritte, die zuvor manuell aus-

gefü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“, ver-

spricht 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 weite-

re 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.

FazitEinzelne Serverless-Dienste gibt es zwar schon lange, doch

als Cloud-Bereitstellungsmodell steht Serverless Compu-

47



[email protected]

Thomas Hafen/js

„Unsere Erfahrungen zeigen,

dass Serverless-Services linear

skalieren.“

Dieter Berz-Vöge

Geschä'sführer Storm Reply GmbH

www.reply.com

„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.microso*.de

Fo

to: M

icro

soft

Fo

to: S

torm

Re

ply

Gm

bH

◾

Bis zu

75 % Betriebs- und Verwaltungs-

kosten spart Serverless Computing

foto: fotolia / maxim kzmin · 42 serverless computing cloud & infrastruktur 4/2017 com!...

Documents