SPAs in Azure: Fünf Fragen, die sich ein:e Frontend-Entwickler:in stellen sollte

In Unternehmen spielen auf Kundenbedürfnisse angepasste Frontends eine immer wichtigere Rolle. Denn vor allem im Frontend können sich Unternehmen in den Augen ihrer Kunden am deutlichsten von ihrer Konkurrenz abheben, indem sie eine einzigartige Benutzererfahrung anbieten.

Um benutzerfreundliche Frontends schnell und günstig zu entwickeln, werden häufig Single Page Application (SPA) Frameworks wie Angular oder React verwendet. SPAs haben viele Vorteile, wie z.B.: kurze Ladezeiten, viele vorhandene Libraries und kontinuierliche Weiterentwicklung durch grosse Open-Source-Communities.

SPAs werden heute häufig in der Public Cloud betrieben. Cloud-Anbieter wie Azure bieten dazu viele verschiedene Optionen. Oft ist es jedoch schwierig, die richtige Lösung auszuwählen. Nachfolgend möchte ich einen Leitfaden aus der Praxis vorstellen, wie man das passende Azure-Produkt für verschiedene Anwendungsfälle findet.

Wie funktionieren SPAs nochmal?

Beim Aufruf einer SPA wird eine HTML-Seite und zugehörige Dateien (CSS, JavaScript, Bilder usw.) vom Webserver auf den Browser des Benutzers heruntergeladen (Siehe Abb. 1 A). Im Gegensatz zu anderen Technologien wird bei der Nutzung einer SPA nicht jedes Mal eine neue Seite auf dem Webserver gerendert und heruntergeladen, sondern die neue Seite wird direkt im Browser des Benutzers mit Hilfe der anfangs heruntergeladenen Dateien erstellt.

Dies hat den Vorteil, dass in einer SPA die Ladezeiten sehr kurz sind, da keine zusätzlichen Daten vom Webserver nach dem initialen Download heruntergeladen werden müssen - die Benutzung fühlt sich flüssig und natürlich an. Eine gut entwickelte SPA kann somit eine ähnlich gute Benutzererfahrung wie eine native Mobile App bieten.

SPA-Frontends arbeiten immer mit Backend-Services zusammen. Dabei rufen die SPAs Programmierschnittstellen (sogenannte APIs) in den Backend-Services online auf, um z.B. Daten zu verarbeiten oder Prozesse auszulösen (siehe Abb. 1 B). In diesem Leitfaden habe ich  somit auch den Betrieb der Backend-Services berücksichtigt, da diese eine wichtige Rolle spielen.

Zusammengefasst benötigt eine SPA folgende zwei Komponenten (siehe Abb. 1) :

1. Ein Webserver, der die Dateien der SPA online hostet
2. Eine Infrastruktur, welche die Backend-Services zur verfügung stellt

3 Lösungen für unterschiedliche Anwendungsfälle

Folgende drei Lösungen möchte ich genauer vorstellen:

Azure Storage Account

Storage Accounts sind dazu da, um grosse Mengen unstrukturierter Daten (z.B.  Dokumente, Bilder, Backups oder Logs) kostengünstig und hochskalierbar online zur Verfügung zu stellen.
Zum Betrieb von SPAs wird das Static Website Hosting Feature in Storage Accounts verwendet. Diese Funktion ermöglicht es, die Dateien einer SPA auf einem vollständig von Microsoft verwalteten Webserver zu hosten.
Backend-Services können nicht in Storage Accounts betrieben werden und man muss daher eine eigene Lösung dafür bereitstellen.

Azure App Service

App Services dienen dazu, Webanwendungen jeglicher Art in einem vollständig von Microsoft verwalteten Service zu hosten. App Services werden jeweils einem App Service Plan zugewiesen. App Service Plans stellen die physische Infrastruktur dar (vergleichbar mit einer Serverfarm), auf welcher die App Services betrieben werden.
Um eine SPA zu betreiben, wird ein Webserver mit den SPA-Dateien in einem App Service gehostet. Sofern die Hardware-Ressourcen im App Service Plan ausreichen, können im selben Plan mehrere App Services gleichzeitig betrieben werden (z.B. neben dem Webserver auch die Backend-Services).

Azure Static Web App

Static Web Apps (SWAs) sind ein relativ neues Produkt in Azure, um die Entwicklung von SPAs so weit wie möglich zu vereinfachen. Dies wird durch zwei Punkte erreicht:

• Minimaler Betriebsaufwand: bei SWAs werden sowohl der Webserver als auch die Backend-Services (in Form von Azure Functions) vollständig durch Microsoft verwaltet.
• Optimierter Entwickler-Workflow: SWAs können mit dem Tool namens Static Web App CLI sehr einfach lokal getestet und anschliessend in Azure deployed werden. Zusätzlich können mit SWAs Staging-Environments in Azure erstellt werden, welche automatisch bei Erstellung eines Pull Requests provisioniert und nach dem Mergen gelöscht werde

Die richtige Lösung wählen: ein Leitfaden

Die drei genannten Lösungen unterscheiden sich stark in ihren Eigenschaften und ihrem Funktionsumfang (siehe Abb. 2). Je nach Einsatzzweck und Gewichtung der Kriterien kann jede von ihnen die bestgeeignete Lösung für eine bestimmte Anwendung sein. Eine einfache Tabelle oder Checkliste reicht daher nicht aus, um die richtige Entscheidung zu treffen.

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.

Fazit

Der Betrieb von SPAs in der Public Cloud gewinnt immer mehr an Bedeutung. Azure bietet dafür mit Storage Account, App Service und Static Web App drei verschiedene Lösungen, deren Eigenschaften sich stark unterscheiden. Mit einem Leitfaden aus fünf Fragen habe ich eine praxisnahe Methode beschrieben, wie man die Azure-Produkte sinnvoll miteinander vergleicht und die bestgeeignete Lösung für verschiedene Anwendungsfälle findet. Meine Empfehlung ist, vor einer Entscheidung diese Analyse durchzuführen, denn darum geht es bei der Entwicklung in der Cloud immer: das passende “Werkzeug” für ein Problem aus dem riesigen “Werkzeugkasten” der Cloud-Anbieter auszusuchen.