Serverless ist nach wie vor ein Hype-Thema. Das Versprechen “Zahle nur noch, wenn Deine Software auch wirklich etwas macht” klingt verständlicherweise erst mal sehr verlockend. Ein Aspekt, der bei der Beschäftigung mit Serverless aus meiner Sicht häufig nicht genug Beachtung findet ist das Thema Vendor-Lock-In.

Aktuell gibt es noch keinen Standard für FaaS. AWS Lambda, Google Cloud Functions und Azure Functions sind in der Softwareentwicklung alle unterschiedlich. Deutlich wird das z.B. bei den zur Entwicklung benötigten Paketen. Enthält ein Paket den Namen des Cloud-Anbieters, wird man bei der Konkurrenz nicht weit damit kommen. Dazu kommt, dass eventuell ein anderer Cloud-Anbieter die gewählte Programmiersprache gar nicht unterstützt. Eine Portierung von einem Cloud-Anbieter zum Anderen bedeutet aktuell im schlimmsten Fall ein komplettes Neuschreiben der Software.

Container hingegen laufen überall da wo es ein Kubernetes-Cluster gibt – und managed Kubernetes-Cluster bekommt man mittlerweile bei jedem Cloud-Anbieter. Natürlich besteht auch bei Containern bei einem Anbieterwechsel Migrationsaufwand. Verwendet man z.B. Datenbanken als managed Service so müssen diese auf ein anderes Produkt beim neuen Anbieter migriert werden. Die Container im Kubernetes-Cluster hingegen
lassen sich in weiten Teilen wiederverwenden.

Der Vendor-Lock-In ist bei FaaS also z.Zt. noch signifikant höher als bei Containern. Das muss kein Totschlagargument sein. Es gibt andere Argumente, wie z.B. den Abrechnungsmodus, die je nach Anwendungsfall trotzdem stark für Serverless sprechen können. Das Thema Migrierbarkeit und Vendor-Lock-In sollte bei einer Entscheidung aber auf jeden Fall Beachtung finden.

Martin Pelzer, Softwarearchitekt und Softwareentwickler

Hier gehts zum Fortbildungsangebot der tarent Academy: Microservices entwickeln und betreiben