Serverless aus Europa: Meine Erfarhrung mit Scaleway als Alternative zu AWS und Co.

Neben den dominierenden US-Anbietern wie AWS, Azure und GCP bietet das französische Unternehmen Scaleway jetzt auch ein umfangreiches Serverless-Computing-Angebot. Dieses umfasst unter anderem Services für Function as a Service, einen leichtgewichtigen Key/Value Store und einen einfachen Messaging-Dienst und bietet somit die Basisfunktionen für Cloud-natives Serverless-Computing. Um dieses Angebot auf den Prüfstand zu stellen, habe ich eine Beispielanwendung zu Scaleway migriert und möchte meine Erfahrungen in diesem Beitrag mit euch teilen.

Anwendungsfall und Testumgebung

Die Anwendung besteht aus einer Single Page Application, einem Backend mit mehreren Serverless-Functions für API-Aufrufe und Authentifizierung per OAuth und einer Key/Value-Datenbank zur Nutzerverwaltung. Ursprünglich habe ich die Implementierung auf AWS aufgebaut, wo mir zahlreiche Managed Services zur Verfügung standen. Dafür habe ich mir ein Äquivalent bei Scaleway angesehen. Auch bei Scaleway konnte ich die Anwendung mit wenigen Einschränkungen implementieren. Die Repositories für beide Implementierungen finden sich auf GitHub. GitHub Repository der AWS-Implementierung GitHub Repository der Scaleway-Implementierung

Feature	AWS Service	Scaleway Service
Hosten der Single Page Application	AWS S3	Scaleway Object Storage
Verwalten der Subdomains	AWS Route53	Scaleway Domains and DNS
Ausliefern der Website mit SSL/TLS	AWS CloudFront	Teilweise vom Object Storage abgedeckt
Erstellen von SSL Zertifikaten	AWS CertificateManager	-
Serverless Functions Backend	AWS Lambda	Scaleway Serverless Functions
Konsolidierung von Functions	AWS ApiGateway	-
Verwaltung externer Secrets	AWS ParameterStore	Scaleway Secret Manager
Session-Verwaltung für Anwender	AWS DynamoDB	Managed Database for Redis

Positive Erfahrungen

Grundsätzlich hat mir der Umgang mit Scaleway sehr gut gefallen. Das UI ist sehr aufgeräumt und intuitiv, besonders wenn man die überladene Oberfläche der AWS-Konsole gewöhnt ist. Dadurch konnte ich mir schon bei der Bedienung der Website einen guten Überblick über den Funktionsumfang der Services verschaffen. Meine Anwendung habe ich mit Infrastructure as Code und dem Scaleway Terraform-Provider erstellt. Dieser hat für mich gut funktioniert und meiner Erfahrung nach auch verständliche Fehlermeldungen ausgegeben, wenn mal etwas schiefgelaufen ist.

Meiner Meinung nach setzt Scaleway an vielen Stellen sinnvollerweise auf Open Source Software und spart sich somit viel Arbeit zur Implementierung einer eigenen Lösung. Beispielsweise werden Logs und Metriken in einer Grafana-Instanz dargestellt, die komplett transparent in das System integriert ist, wodurch Logs automatisch erfasst werden und dann durch einen Klick direkt in der Konsole abgerufen werden können. Dadurch fühlt sich zwar nicht alles wie aus einem Guss an wie bei den anderen Anbietern, es erlaubt Scaleway aber, sich um andere spannende Features zu kümmern.

Eines dieser Features ist die Möglichkeit, Serverless-Funktionen zu deployen, was ich auch für meinen Anwendungsfall ausgiebig getestet habe. Außerdem gibt es noch die Möglichkeit, Serverless-Container zu deployen und die Kommunikation zwischen Services durch Queues und Topics zu gestalten. Die Verwaltung von Berechtigungen zwischen diesen Services wird über ein simples IAM-System möglich. Für mich sind das genau die Features, die ich von einem konkurrenzfähigen Cloud-Anbieter erwarte, um Cloud-native Anwendungen bauen zu können.

Herausforderungen und Hindernisse

Bei der Implementierung meiner Beispielanwendung bin ich an einigen Stellen auf Herausforderungen gestoßen. Dies lag hauptsächlich daran, dass meine ursprüngliche Implementierung auf AWS zugeschnitten war und Scaleway nicht alle Features anbot, die ich dafür verwendet habe. Ich möchte hier ein paar Beispiele für Features geben, auf die man aktuell verzichten müsste, wenn man sich für Scaleway entscheidet.

In meiner AWS-Implementierung konnte ich mein Serverless-Backend in mehrere Funktionen aufteilen, die ich mit einem ApiGateway konsolidiert und mit Pfad-basiertem Routing unter einer URL verfügbar gemacht habe. Mit Scaleway ist das nicht möglich, da es kein Äquivalent zum ApiGateway gibt und jede Funktion eine eigene URL bekommt. Da mein Backend sehr überschaubar ist, habe ich den gesamten Code in einer Funktion zusammengefasst und dann innerhalb der Funktion die Zugriffspfade ausgewertet. Für größere Anwendungen ist dies aber nicht mehr praktikabel, weshalb man beispielsweise selbst einen Service hosten muss, der das Routing übernimmt. Scaleway empfiehlt dazu eine Lösung, die auf dem Kong Gateway basiert.

Auch das Berechtigungssystem für die Kommunikation zwischen Services ist an einigen Stellen noch nicht ganz ausgereift. So musste ich für den Zugriff auf den Secrets Manager zuerst im IAM Service einen API-Key anlegen, der über eine Policy die Berechtigung für den Secrets Manager erhält. Diesen API-Key habe ich dann per Umgebungsvariable an meine Serverless-Funktion übergeben, die diesen Wert auslesen und für den direkten Zugriff auf das Secret verwenden muss. Bei AWS dagegen kann ich einfach der Execution Role einer Lambda-Funktion über eine Policy den Zugriff auf ein bestimmtes Secret zuweisen. Dadurch entfällt das manuelle Key-Management, wodurch auch kein Key verloren oder in falsche Hände geraten kann.

Als Alternative zu AWS CloudFront bietet Scaleway ein Feature namens Edge Services, mit dem öffentliche Endpunkte für Buckets und Load Balancers mit Caching und SSL/TLS versehen werden können. Die Bedienung des Services über die Oberfläche funktioniert zwar gut, allerdings hat das Erstellen von Ressourcen via Terraform bei mir für einen Absturz gesorgt. Dabei war das komplette Feature in der Web-Konsole nicht mehr nutzbar, bis ich die entsprechenden Ressourcen mit Terraform wieder entfernt habe. Die Scaleway Edge Services werden aktuell noch als neues Feature beworben, weshalb diese Fehler vermutlich bald behoben sein werden.

Generell hatte ich das Gefühl, dass aktuell sehr viel an neuen Funktionen und Services gearbeitet wird und sich vieles im Umbau befindet. Auch bei dem relativ neuen Angebot für Serverless Functions bin ich auf ein Hindernis gestoßen, als ich die Dokumentation durchsucht habe. In der Referenz-Dokumentation zum Code der Handler-Funktionen steht leider aktuell beispielsweise nicht, wie die an die Funktion übergebenen event und context Objekte genau aussehen und welche Attribute diese besitzen. Diese Informationen muss man sich also aus Beispielen im Internet zusammensuchen.

Fazit

Insgesamt hat mir das Arbeiten mit Scaleway sehr gut gefallen und besonders durch die intuitiv gestaltete Oberfläche der Web-Konsole Spaß gemacht. Vor allem für Entwickler, die noch nicht viel Erfahrung mit Cloud-Technologien haben, bietet der etwas reduzierte Funktionsumfang und die aufgeräumte Bedienung einen einfachen Einstieg. Einige Anwendungsfälle erfordern zwar etwas mehr Aufwand, als dies bei den großen Hyperscalern der Fall wäre, es gibt aber für die meisten Probleme auch eine Lösung. Die Basis-Services, die für eine Serverless-Architektur benötigt werden, sind vorhanden und es gibt sogar einige spezialisierte Angebote für IoT- oder Machine-Learning-Anwendungen. Mich persönlich hat am meisten das Berechtigungskonzept gestört, da ich durch die Benutzung von AWS sehr daran gewöhnt bin, sämtliche Berechtigungen durch Roles und Policies zu verwalten und mich nicht um Secrets kümmern zu müssen. Für Kunden, die auf europäische Lösungen setzen wollen und keine spezifischen Features benötigen, stellt Scaleway dennoch meiner Meinung nach eine sinnvolle Alternative zu den etablierten US-Unternehmen dar.