Serverless Computing: Darauf müssen Sie achten

Die Anwendung kann/wird nicht geändert werden

Wenn Sie eine Fremdherstellersoftware oder Bestandsanwendung bereitzustellen planen, die Sie nicht ändern können oder werden, so werden Sie mit dem Serverless-Ansatz erhebliche Probleme kriegen. Serverless-Angebote der führenden Cloud-Anbieter wie Amazon Web Services Lambda, Azure Functions und Google Cloud Functions sind noch vergleichsweise neu. Als die ältere Software entwickelt wurde, waren solche Einsatzmöglichkeiten also noch nicht abzusehen, geschweige denn implementiert.

Viele sehen den Ursprung von Serverless Computing in den Social Media Apps (allen voran Twitter), die einem ereignisgesteuerten Modell folgen. Die meisten Geschäftsanwendungen unserer Zeit haben mit Ereignissteuerung nichts am Hut. Das bedeutet keineswegs, dass sie so nicht funktionieren könnten. Allerdings müssen Sie dafür die Anwendung in ihre Einzelkomponenten zerlegen und neu kombinieren, einschließlich der Logik einiger solcher Komponenten.

Einige Anwender kommen zu dem Schluss, dass sie ganze zwei Drittel der Anwendungen, die sie für Serverless Computing vorgesehen hatten, nicht verändern können. Sei es, weil diese von einem Drittanbieter stammt, oder weil eine Änderung sehr viel Zeit und Geld verschlingen würde. Wenn Sie Software von Fremdherstellern einsetzen, sollten Sie sich vom Anbieter vertraglich zusichern lassen, dass die entsprechende Anwendung auch auf einer Serverless-Architektur ablauffähig ist.

Die Anwendung läuft ständig

Serverless Computing verursacht nur dann Kosten, wenn die Funktionalität der Anwendung benötigt wird. Das kann durchaus sehr kosteneffektiv sein. Für Anwendungen, die sehr häufig genutzt werden, kann es aber andererseits die Kosten massiv in die Höhe treiben. Die ideale Serverless-Anwendung ist innerhalb weniger Millisekunden startbereit, wird aber nur selten aufgerufen. Eine Anwendung, die ununterbrochen genutzt wird, verursacht durchgängig Kosten, die weit über denen des Betriebs einer VM oder eines Containers in der Cloud liegen können.

Es ist nicht immer ganz so einfach zu wissen, ob eine Anwendung tatsächlich laufen oder nur zum Abruf bereitstehen muss. Ein gutes Beispiel für den ersten Fall ist eine Anwendung, die ein Kreditkarten-Terminal in einem Einzelhandelsgeschäft versorgt. Diese Anwendung wird bei jedem Einkauf aufgerufen, was sie zu einem guten Kandidaten für eine eher konventionelle IaaS-Plattform (Infrastructure as a Service) macht. Ein Beispiel für den zweiten Fall ist eine Anwendung, die einen Umgebungssensor in einem Warenlager überwacht, der durch Temperaturschwankungen aktiviert wird. Diese Anwendungsart muss zwar jederzeit zum Abruf bereitstehen, wird aber nur selten tatsächlich abgerufen. Eine solche Anwendung ist ein hervorragender Kandidat für Serverless Computing.

Die Anwendung arbeitet zustandsbehaftet

Da eine Serverless-Anwendung auf Abruf geladen und gestartet wird, können Sie innerhalb der Anwendung nichts speichern, das Sie bei einem nachfolgenden Abruf wieder auslesen könnten. Eine dafür notwendige Speicherfunktionalität nennt man zustandsbehaftet oder kontextuell. Ist Ihre Anwendung inhärent zustandsbehaftet (so wie jede Geschäftsanwendung, die Inhaltsaktualisierungen bietet, oder Dialoge über mehrere Schritte hinweg anbietet), so machen Sie einen Bogen um Serverless Computing.

Amazon und Microsoft beschreiben Serverless Computing als funktionales Lambda-Processing. Damit wird auf eine spezifische Programmiertechnik abgezielt, die jedwedes Speichern innerhalb einer Anwendung oder deren Komponenten zwischen zwei Aktivierungen vermeidet. Funktionale oder Lambda-Logik ist stets zustandsfrei, was zum Vorteil hat, dass ein bestimmtes Ereignis von jeder beliebigen Instanz einer Anwendungskomponente bearbeiten werden kann.

Google bezeichnet Serverless Computing als Microservice Computing. Ein Microservice sollte immer zustandsfrei sein, was auch daran liegen kann, dass mehrere Anwendungen dieselbe Logik nutzen. In einem solchen Szenario wäre das Speichern kontextueller Informationen gefährlich, denn diese könnte unerkannt an eine andere Anwendung oder an einen anderen Benutzer weitergereicht werden.

Möglicherweise müssen Sie Teile Ihrer Anwendung oder sogar die gesamte Anwendung neu schreiben, um sie zustandsfrei arbeiten zu lassen. Selbst wenn Ihre Anwendung nicht komplett neu geschrieben werden muss, sondern nur einzelne Teile der Anwendung neu entworfen werden müssen, sollten Sie Entwickler mit an Bord haben oder nehmen, die mit Zuständen, Kontext, Lambda-Programmierung und Microservices umzugehen wissen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!