Microsoft Azure App Services - eine Plattform für viele Anwendungsfälle

Das Betreiben moderner Webanwendungen kommt einem wohl nicht als Erstes in den Sinn, wenn man von App Services hört. Die Azure App Services haben tatsächlich nur sehr wenig mit dem zu tun, was im Allgemeinen als „App“ bezeichnet wird. Microsoft Azure App Services sind ein so genannter „Platform as a Service (PaaS)“-Cloud-Dienst, der eigentlich aus vier Teilen besteht: Web Apps, API Apps, Mobile Apps und Logic Apps.Während die ersten drei Services sehr eng miteinander verwandt sind und sich im Wesentlichen nur in Nuancen voneinander unterscheiden, stellen Logic Apps einen neuen Weg dar, Workflows auf deklarativer Ebene und ohne großen Entwickler-Hintergrund zu erstellen und zu warten.

Web Apps

„It’s all about Apps“: Dieses Motto war ganz sicher nicht der Grund, weshalb Microsoft die schon bekannten Azure Web Sites auf Azure Web Apps umgetauft hat. Vielmehr war ausschlaggebend, dass es sich bei Web Sites nicht nur um simples Webhosting handelt. Nein, Microsoft wollte mit Nachdruck darauf hinweisen, dass es sich bei diesem Angebot um mehr als nur Webseiten handelt, weshalb der Slogan „more than just websites“ auf der einen oder anderen Marketingfolie auch immer wieder zum Vorschein kommt. Neben dem klassischen Webhosting, sind es vor allem die zusätzlichen Dienste und Möglichkeiten, die in Azure Web Apps enthalten sind, die die Plattform so attraktiv gestalten. Dabei wird nicht einmal auf die zu verwendete Technologie beschränkt: Azure Web Apps lassen sich neben .NET auch mit Java, PHP, Python und Node.js betreiben.

Always On & High Throughput

Je nach App Service Plan entscheidet man, welche Art von Hostingmodell gewünscht ist. Dabei steht von einer gratis Testinstanz, bis hin zum leistungsstarken, automatisch skalierenden Cluster, welcher (geo-)redundant ausgeführt ist, alles zur Verfügung, was zum reibungslosen Betrieb einer Anwendung von Nöten ist. Mit Hilfe der so genannten „Deployment Slots“, wird ein Modell eingeführt, welches neben herkömmlichen Staging-Szenarien Features wie „Auto-Swapping“ und „Testing in Production“ (TiP) ermöglicht. Neue Versionen werden zunächst auf einem eigenen Deployment Slot getestet und gehen erst dann online, wenn alle Tests erfolgreich durchgeführt wurden.
Falls Ihnen dieses Schwarz/Weiß-Denken des Swappings für Test- und Produktionsumgebungen zu kritisch erscheint, können Sie per „Traffic Routing“ steuern, wie der eingehende Traffic Ihrer Webanwendung prozentuell auf verschiedene Deployment Slots aufgeteilt wird. Sie können somit neue Features schleichend einführen bzw. das Risiko bei großen Änderungen an der Anwendung weiter minimieren.

(Auto-)Scaling

Um in Zeiten erhöhter Last entsprechend gerüstet zu sein, bieten Azure App Services umfangreiche Scaling-Optionen. Grundsätzlich werden die beiden Scaling-Strategien „Scale-Up“ und „Scale-Out“ unterstützt. Während Scale-Up die Erhöhung der Rechenleistung einer einzelnen Instanz darstellt, wird die Last beim Scale-Out auf mehrere Instanzen aufgeteilt. Für fortgeschrittene Scale-Out-Strategien gibt es neben der simplen Angabe einer festen Instanzzahl ebenso hoch konfigurierbare Autoscaling-Einstellungsmöglichkeiten, die neben der Angabe zeitlicher Rahmenbedingungen (z. B. Mo-Fr von 07:00 bis 18:00 Uhr) auch Metriken, wie beispielsweise die durchschnittliche CPU-Last, für die Skalierung auf mehrere Instanzen miteinbeziehen.

Monitoring

Neben integrierter Monitoring-Dashboards direkt im Azure Portal stehen mit „Application Insights“ eine Vielzahl an Informationen für die Detailanalyse Ihrer Anwendung bereit. Application Insights ist nebenbei bemerkt nicht nur für Cloud-Anwendungen verwendbar – auch herkömmliche Windows-Desktopanwendungen sowie iOS- oder Android-Apps können bis ins letzte Detail (live) instrumentiert werden.

API Apps

SOAP war gestern – REST ist heute! Azure API Apps helfen Ihnen dabei, leichtgewichtige APIs für die Cloud zu erstellen und zu betreiben. Nicht nur aufgrund der vielfach zitierten „separation of concerns“ bietet es sich an, eine Serviceschicht in Ihre Anwendung zu integrieren. Auch der klare Trend zu „Single Page Applications“ (SPA) und die einfache Konsumierbarkeit von beinahe jeder denkbaren Plattform bzw. Technologie weist ganz klar in Richtung leichtgewichtiger Web Services.
Oftmals werden REST-Services von hartgesottenen SOAP-Verfechtern aber als Modeerscheinung abgetan. Grund dafür ist zumeist das Fehlen von Metadaten bzw. eines so genannten Interface-Kontraktes. Zugegebenermaßen sind Metadaten beim REST-Ansatz nicht so stark mit der Technologie verwoben, wie das beispielsweise bei SOAP der Fall ist.
Dank „Swagger“ und dem NuGet-Package „Swashbuckle“ (.NET-Implementierung für Swagger) können für REST-APIs entsprechende Metadaten im JSON-Format erzeugt werden. Neben der API-Version und den zur Verfügung stehenden Endpunkten, werden auch noch zusätzliche Informationen über die API bekanntgegeben. Basierend auf einer solchen Swagger-Definition, können nun Proxyobjekte für verschiedenste Plattformen und Technologien erzeugt werden.
Das Azure-Portal bietet außerdem die Möglichkeit zur Konfiguration eines „API definition“-Endpunktes, was mehrere Vorteile speziell im Zusammenhang mit Logic Apps (siehe unten) bringt und eine zentrale Stelle für andere Services zur Verfügung stellt.

Mobile Apps

Mit Azure Mobile Apps bietet Microsoft eine Möglichkeit, auf sehr einfache Art und Weise Backends für mobile Anwendungen zu erstellen. Neben den bei Web- und API Apps angemerkten Features zum Betrieb der Anwendung steht bei Mobile Apps vor allem die Lösung gängiger Probleme bei der Entwicklung mobiler Backends im Fokus. Zu diesen zählen unter anderem Single Sign-On (SSO), Offline Synchronisierung und plattformübergreifende Push-Notifications.

Logic Apps

Neben den drei bisher vorgestellten App Services stellen Logic Apps die Außenseiter dar. Grund dafür ist, dass diese nicht zwingend nur von Entwicklerinnen und Entwickler erstellt und betrieben werden können – vielmehr zielen Logic Apps darauf ab, Workflows auf einfache Art und Weise zu erzeugen und zu warten. Dies passiert direkt im Azure Portal, was bedeutet, dass das einzige benötigte Werkzeug ein Webbrowser ist. Damit ist es möglich, beispielsweise auch Ihren Kunden eine Möglichkeit zu bieten, verschiedene Tasks selbst anzustoßen und steuern zu können. Die dabei zur Verfügung stehenden Bausteine die sind Aktionselemente (Actions) und logische Überprüfungen bzw. Verzweigungen (Conditions).
Diese Abbildung zeigt einen sehr einfachen Workflow.

Am Beginn von Workflows stehen so genannte „Trigger“. Diese können in der einfachsten Form direkt über das Portal bzw. per HTTP-Request, im fortgeschrittenem Fall aber auch durch ein angebundenes Web-Service oder sogar OnPremise-Ressourcen wie beispielsweise eine unternehmensinterne Datenbank (z. B. mit Hilfe eines Hybrid-Connectors) ausgelöst werden. Nachdem der Workflow gestartet wurde, wird im nächsten Schritt auf die zuvor erstellte API zugegriffen, um Zufallszahlen zu liefern. Diese ist aufgrund der zur Verfügung gestellten Swagger-Definitionen direkt als Logic App-Action verwendbar. Das Ergebnis dieses Calls wird schließlich an eine „Twilio Send Message“-Action weitergeleitet, welche abschließend eine SMS versendet. Besonders spannend ist, dass in allen Schritten des Workflows auf bereits existierende Resultate zugegriffen werden kann, wie beispielsweise in folgender Abbildung das Resultat des API-Calls als Parameter in den SMS-Text mitaufgenommen wird.

Zusammenfassung

Azure ist ein großer Baukasten. In den App Services finden sich zahlreiche Werkzeuge, die uns die Entwicklung hochprofessioneller, skalierbarer und offener Lösungen ermöglichen. Der Betrieb moderner Web-Anwendungen ist mehr als das Hosting auf einem Webserver im Keller und die App Services setzen auf vielen Gebieten neue Standards. Wir setzen seit dem ersten Tag darauf.