© Excellent backgrounds/Shutterstock.com
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


Nach IaaS, PaaS und BaaS ist FaaS das neueste Mitglied der stetig wachsenden „As a Service“-Familie in der Cloud. Eine verteilte Anwendung ganz ohne Server, so das Wunschbild. Aber kann das wirklich funktionieren? Und wenn ja, für welche Art von Anwendungen?

„Kein Server ist einfacher zu verwalten als kein Server“, so die Aussage von Werner Vogels, seines Zeichens CTO bei Amazon. Und der muss es ja schließlich wissen, ist Amazon doch aktuell mit AWS einer der führenden Cloud-Service-Anbieter weltweit. „Run Code, not Servers“. Oder etwas plakativer formuliert: „Kein Server, kein Stress“. Genau hier setzt die Grundidee des neuen Hypethemas Serverless an. Aber wie soll das funktionieren? Irgendwo muss der Code doch laufen!

Natürlich kommt auch die Wunderwelt der Function as a Service (FaaS) nicht wirklich ohne einen Server aus. Allerdings ist er für den Anwendungsentwickler mehr oder minder transparent. Der Entwickler programmiert einen Teil der Anwendungslogik in Form einer Funktion, lädt sie in die Cloud hoch und fertig ist die FaaS. Ok, ganz so einfach geht es am Ende dann leider doch nicht. Auch wenn der Begriff Serverless suggeriert, dass es keinen Server gibt, existiert natürlich dennoch eine Laufzeitumgebung für die hochgeladene Funktion. Und die möchte konfiguriert werden – von wem auch immer. Adrian Cockcroft, ehemals Cloud Architect bei Netflix und heute VP Cloud Architectures bei Amazon, beschreibt das in einem seiner Tweets passend mit: „If your PaaS can efficiently start instances in 20ms that run half a second, then call it serverless“.

DevOps vs. NoOps

Es stellt sich also die Frage, was weiterhin in der Verantwortung des Entwicklers bzw. des Operators ist – und was nicht. Es gilt, die Funktion zu konfigurieren. Dazu gehört je nach Anbieter, dass man den zu allokierenden Speicher angibt, einen Time-out setzt, Zugriffsberechtigungen auf und für die Funktion vergibt, Dead Letter Queues für den Fehlerfall definiert und vieles mehr. Darüber hinaus kann und sollte der Entwickler verschiedene Versionen und Aliasse für die Funktion verwalten, die er zum Beispiel für ein selbstdefiniertes Staging-Konzept verwenden kann. Schließlich wollen wir ja nicht am offenen Herzen operieren und jede Änderung gleich in Produktion bringen. Von NoOps zu sprechen, wäre also ein wenig zu viel des Guten. Einigen wir uns besser auf LessOps.

Orchestration vs. Composition

Neben der eben erwähnten Konfiguration muss ebenfalls festgelegt werden, wie die Funktion überhaupt a...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang