Aus diesem Grund habe ich einen Leitfaden entwickelt, welcher meinen Gedankengang bei der Wahl der passenden Lösung zum Betrieb von SPAs auf Azure beschreibt. Folgende fünf Leitfragen empfehle ich zu beantworten:

1 Wie sollen die Backend-Services betrieben werden?

Es ist wichtig zu wissen, welche Eigenschaften die von der SPA aufgerufenen Backend-Services haben und welche Produkte am besten zum Betrieb der Services geeignet sind. Denn sowohl die Lösung für den Betrieb der SPA als auch diejenige für die Backend-Services müssen zueinander passen.

Bei Storage Accounts muss für die Backend-Services eine eigene Lösung bereitgestellt werden. Man kann daher frei das Azure-Produkt wählen, welches am besten zu den Eigenschaften der Backend-Services passt (z.B. Azure Kubernetes Service oder Azure Container Apps für komplexe Applikationen mit vielen Backend-Services).
App Services sind ideal für einfache Applikationen, welche nur aus wenigen Backend-Services bestehen und geringe Hardware-Ressourcen verbrauchen. Der Grund ist, dass App Service Plans mit hoher Rechenkapazität sehr teuer sind und nicht so feingranular skaliert werden können wie andere Azure-Produkte.
Bei SWAs werden Azure Functions für die Backend-Services eingesetzt. Diese passen vor allem zu event-basierten Applikationen mit ungleichmässiger Auslastung, deren Logik sich in Form von “Nano-Services” ausdrücken lässt. Azure Functions können sehr feingranular skaliert werden und sind extrem kosteneffizient.

2 Welche Anpassungen sind nötig?

Gibt es Anforderungen, welche individuelle Anpassungen an die Infrastruktur der SPA benötigen, wie z.B. eine spezielle Konfiguration am Webserver oder an der Infrastruktur für die Backend-Services? Vor allem fully-managed Produkte sind nur begrenzt anpassbar, weshalb man prüfen muss, ob diese Lösungen den Anforderungen genügen.

In Storage Accounts kann der Webserver nicht angepasst werden, da es von Microsoft verwaltet wird. Für den Betrieb der Backend-Services kann man frei das Azure-Produkt wählen, welches die Anforderungen am besten erfüllt.
In App Services kann der Webserver selbst ausgewählt und konfiguriert werden. Die App Services und App Service Plans sind jedoch nur begrenzt anpassbar, da sie vollständig von Microsoft verwaltet werden.
In SWAs ist die Anpassbarkeit am geringsten, da sowohl der Webserver als auch die Azure Functions fully-managed sind. Statt Azure Functions kann man zwar eine eigene Lösung verwenden, jedoch verliert man dadurch viele Vorteile von SWAs.

3 Wie hoch ist der Betriebsaufwand?

Eine selbstverwaltete Infrastruktur ermöglicht eine hohe Anpassbarkeit. Man braucht jedoch viel Know-how und Aufwand, um sie zuverlässig und sicher zu betreiben. Ich empfehle, PaaS- oder serverless Produkte einzusetzen, um möglichst wenig Betriebsaufwand zu haben. Die gewählte Lösung muss zum Know-how und zur Kapazität im Team passen.

Bei Storage Accounts hängt der Aufwand stark von der gewählten Lösung zum Betrieb der Backend-Services ab. Bei z.B. Azure Kubernetes Services ist die Komplexität und der Aufwand viel höher als bei Azure Container Apps.
Bei App Services ist der Betriebsaufwand gering, da sie von Microsoft verwaltet werden. Bei Verwendung von App Services mit Containern muss zusätzlich ein Container Registry betrieben werden.
Bei SWAs ist der Aufwand ebenfalls gering, da sie fully-managed sind. Mit SWAs können zudem temporäre Staging-Environments erstellt werden, wodurch man sich Aufwand zum Betrieb von zusätzlichen Umgebungen sparen kann.

4 Wie wichtig ist die Reife der Lösung?

Als “reif” (engl. mature) bezeichnet man in der IT ein Produkt, das bereits seit längerer Zeit auf dem Markt ist und schon von vielen Kunden eingesetzt wurde. Reife Produkte werden gegenüber "jungen" Produkten bevorzugt, weil sie meistens weniger Bugs und Änderungen sowie bessere Dokumentation und Tooling haben. Man sollte daher abwägen, ob man lieber ein reifes Produkt oder ein junges Produkt mit mehr Features verwenden möchte.

Storage Accounts und App Services werden bereits seit vielen Jahren bei Kunden in Produktion eingesetzt und zählen zu den reifsten Produkten auf Azure.
SWAs hingegen sind erst seit Mai 2022 aus dem Public View. Es ist zu erwarten, dass sie in den nächsten Jahren noch viele Änderungen erfahren werden.

5 Wie kritisch ist Vendor Lock-in?

Einen Lock-in zu haben bedeutet, dass man seine Applikation zu sehr auf die Produkte eines bestimmten Cloud-Anbieter angepasst hat. Diese Abhängigkeit führt dazu, dass viel Änderungsaufwand benötigt wird, um den Anbieter zu wechseln. Daher sollte man Produkte mit geringem Lock-in verwenden, falls es nicht sicher ist, ob man in Zukunft beim selben Cloud-Anbieter bleiben wird.

Storage Accounts können einfach ohne Code-Änderungen durch eine andere Lösung, welche die SPA-Dateien hosten kann, ersetzt werden. Beispiele sind S3 Buckets auf AWS oder Google Storage auf GCP.
App Services mit Containern können ebenfalls einfach durch Container-Lösungen bei anderen Cloud-Anbieter ersetzt werden, da hohe Portierbarkeit eines der Hauptvorteile von Containern ist.
Bei SWAs ist der Lock-in am grössten, da die verwendeten Azure Functions oftmals sehr eng mit den restlichen Produkten in Azure integriert sind. Dadurch werden oft grössere Code-Änderungen benötigt, um SWAs zu ersetzen.

Hast du auch einen spannenden Use Case? Let's talk!

Weili Gao