Neuer Cloud-Trend auf dem Prüfstand: Ist Serverless-Computing ein Vendor Lock-In?

Die Entwicklung, dass sich immer mehr Verwaltungsaufgaben zum Cloud Anbieter verlagern, ist bereits seit einiger Zeit zu beobachten. Die aktuellste Weiterentwicklung in diesem Bereich wird als „Serverless“ bezeichnet und ist derzeit in aller Munde. Der bekannteste Serverless-Computing-Dienst ist dabei wohl „Lambda“ von Amazon Webservices (AWS). Das Pendant dazu von Microsoft heißt „Azure Functions“. Serverless-Computing bietet dabei einige Vorteile gegenüber dem „klassischen“ Entwicklungsmodell. Hier wird die komplette Umgebung (Physikalische Maschinen, Betriebssystem, Laufzeitumgebung, …) durch den Cloud Anbieter verwaltet. Dies erlaubt es dem Entwickler, sich voll auf die Implementierung seiner Anwendung zu konzentrieren. Bei der Entwicklung von Anwendungen in diesem Umfeld stellt sich jedoch auch die Frage, wie stark man sich bei der Entwicklung einer Anwendung in diesem Umfeld, vom jeweiligen Cloud Anbieter abhängig macht und ob eine Migration zu einem anderen Anbieter (mit vertretbarem Aufwand) möglich ist. Gründe für einen Anbieterwechsel könnten zum Beispiel Kostenvorteile oder sich ändernde rechtliche Rahmenbedingungen sein. Dieser Frage nach der Anbieter(un)abhängigkeit bin ich im Rahmen meiner Bachelorarbeit bei OPITZ CONSULTING nachgegangen, indem ich ein kleines Beispielprojekt von AWS zu Azure migriert habe. Ein Teil der Ergebnisse soll im Folgenden kurz vorgestellt werden.

Kompatible Programmiersprache

Zunächst einmal fällt bei einem Vergleich auf, dass Azure Functions und AWS Lambda nicht die gleichen Programmiersprachen unterstützen. Derzeit werden nur diese Programmiersprachen von beiden Anbietern unterstützt: JavaScript bzw. NodeJS, Python und C#. Verwendet man eine andere Programmiersprache bleibt einem im Falle einer Migration nichts anderes übrig, als den kompletten Code neu zu schreiben. Daher empfiehlt es sich eine dieser Sprachen zu verwenden. Das Angebot wird jedoch stetig ausgebaut.

Der Functionhandler

Des Weiteren unterscheiden sich die Functionhandler, also die zu implementierende Schnittstelle, der beiden Anbieter leicht voneinander. Dies sind jedoch hauptsächlich Unterschiede in der Namensgebung der Attribute bei  Objekten, welche beim Aufruf übergeben werden. Hier müssen im Falle einer Migration die Namen entsprechend abgebildet werden. Eine von Beginn an saubere Trennung der Implementierung der Schnittstelle von der eigentlichen Geschäftslogik erleichtert diesen Schritt enorm. Vereinzelt unterscheidet sich auch die Formatierung der Werte, zum Beispiel der Pfad der aufgerufenen HTTP-Schnittstelle, falls man die Funktion über eine solche aufruft. Diese müssen dann ebenfalls angepasst werden.

Integration weiterer Dienste

Anders sieht es hingegen aus, wenn man spezielle Dienste von AWS wie DynamoDB oder S3 verwendet. Abgesehen von der Migration des jeweiligen Dienstes müssen dann nämlich sämtliche API-Calls in Lambda angepasst werden (also jeder Zugriff auf einen angebundenen Dienst!), wenn man das gesamte Projekt migrieren möchte. Auch hier kann eine saubere Kapselung dieser API-Calls im Falle einer Migration viel Aufwand vermeiden und die eigentliche Geschäftslogik unberührt lassen. Abhilfe kann hier das Verwenden von anbieterunabhängigen Services wie MongoDB zur Datenspeicherung anstelle von DynamoDB schaffen, da man dann die jeweiligen API-Calls nicht weiter anpassen muss. Dies bringt aber wiederrum den Nachteil mit sich, dass man auf die Vorteile des vollständig verwalteten Datenbankservices DynamoDB verzichtet. Hier gilt es im Einzelfall abzuwägen ob man dies in Kauf nehmen möchte. Um eine Migrationsfähigkeit des Gesamtprojektes sicherzustellen, muss natürlich jeder verwendete Dienst mitbetrachtet werden.  Im Falle des Beispielprojektes stellte der Dienst „Cognito“ ein Vendor Lock-In dar, da es (zu diesem Zeitpunkt) nicht möglich ist, das Nutzerverzeichnis zu exportieren oder auf andere Art zu migrieren.

Fazit

Die Serverless-Computing-Dienste AWS Lambda und Azure Functions stellen grundsätzlich kein Vendor Lock-In dar und  die entsprechenden Funktionen lassen sich aus Entwicklersicht relativ leicht migrieren. Das Problem bilden vielmehr herstellerspezifische Dienste, auf die man aus der Funktion heraus, über die API, zugreift.

 

Dieser Beitrag wurde unter Cloud & Infrastructure, Software Engineering abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s