Microsoft Azure App Services: Eine Plattform für viele Anwendungsfälle
"Always On", "High Throughput" und "Short Release Cycles": Oftmals stellen diese Anforderungen für alle "Nicht-Big-Players" dieser Welt, wie etwa Google, Facebook und Co. es sind, eine enorme Hürde dar. Dieser Artikel zeigt, wie der Betrieb moderner (Web-)Anwendungen für "Jedermann" auf einem Professionalitätsniveau realisiert werden kann, das lange als unerreichbar erschien.
"App" Services?
Zugegebenermaßen ist wohl das Betreiben moderner Webanwendungen nicht der erste Gedanke, der jemandem in den Sinn kommt, wenn man zum ersten Mal von "App Services" hört. Dennoch haben Azure App Services nur sehr wenig mit dem zu tun, was im Allgemeinen als "App" bezeichnet wird. Vielmehr stellt Microsoft eine Plattform zur Verfügung, die für Entwicklerinnen und Entwickler beinahe keine Wünsche offen lässt.
So wird unter "Microsoft Azure App Services" ein so genannter Platform as a Service (PaaS) Cloud-Dienst verstanden, der aus vier Services 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. Im Folgenden wird nun näher auf die jeweiligen Details eingegangen und gezeigt, welche Möglichkeiten geboten werden.
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 der Grund, dass es sich bei Websites nicht nur um simples Webhosting handelt, was man auf den ersten Blick vielleicht vermuten könnte. 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 machen. Dabei wird nicht einmal auf die verwendete Technologie eingeschränkt: Azure Web Apps lassen sich neben .NET auch mit Java, PHP, Python und Node.js betreiben.
Wenn Sie nun nochmal an die drei Anforderungen zu Beginn des Artikels zurückdenken, werden Web Apps all diesen gerecht und darüber hinaus sogar noch weiteren:
Always On & High Throughput: Je nach App Service Plan [1] entscheiden Sie, welche Art von "Hostingmodell" Sie wählen. Dabei können Sie von einer Gratis-Testinstanz bis hin zum leistungsstarken, automatisch skalierenden Cluster welcher (geo-)redundant ausgeführt ist, alles konfigurieren, was zum reibungslosen Betrieb Ihrer Anwendung von Nöten ist.
Mit Hilfe der so genannten "Deployment Slots" [2], wird ein Modell eingeführt, welches neben herkömmlichen Staging-Szenarien, Features wie "Auto-Swapping" und "Testing in Production" (TiP) ermöglicht. Testen Sie also Ihr neues Deployment zunächst auf einem eigenen Deployment Slot (welcher im Grunde wieder als eigene Web App gesehen werden kann) und setzen Sie das Deployment erst dann in den Livebetrieb, wenn alle (Akzeptanz-)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 prozentual auf verschiedene Deployment-Slots aufgeteilt wird (s. Abb.1). Sie können somit beispielsweise neue Features "schleichend" einführen bzw. das Risiko bei großen Änderungen an der Anwendung weiter minimieren.
Short Release Cycles: Neben dem klassischen Deployment mittels FTP oder WebDeploy ist es möglich, Continuous Delivery [3] samt Build-Automatisierung und automatisierter Tests für Ihre Anwendung zu betreiben. Dabei stehen neben Visual Studio Team Services [4], OneDrive, GitHub und privaten Repositories auch noch andere Quellen bzw. Repository-Typen zur Verfügung (s. Abb.2).
(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 eine 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 mit einbeziehen.
Remote Debugging: Neben Features wie etwa Testing in Production, auf welches bereits näher eingegangen wurde, sind Sie mit Visual Studio nur einen Klick davon entfernt, per "Remote Debugging" Breakpoints direkt in der Cloud zu setzen (s. Abb.3). Als kleiner Hinweis sei an dieser Stelle gesagt, dass dieses Feature nicht unbedingt zur Analyse des Produktivsystems geeignet ist, da sie tatsächlich alle Requests auf Ihre Anwendung in einem Breakpoint "gefangen halten" können.
Monitoring: Neben integrierter Monitoring-Dashboards (s. Abb.4) direkt im Azure Portal [5] stehen mit "Application Insights" [6] 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.
(CRON-)Jobs: Bei einem Großteil moderner Webanwendungen spielen wiederkehrende bzw. vom Frontend entkoppelte Aufgaben eine wesentliche Rolle. Denken Sie beispielsweise an Worker-Prozesse, welche rechenintensive Operationen ausführen oder schlicht an die asynchrone Entkopplung von Mailversand-Jobs. Mit Hilfe von so genannten "WebJobs" können Entwicklerinnen und Entwickler beginnend bei einfachen Batch- oder PHP-Scripts bis hin zu kompletten Anwendungen als WebJob alles im Kontext der Webanwendung betreiben. Neben der manuellen bzw. zeitgesteuerten Ausführung dieser WebJobs ist eine Kopplung an Message-Queues fest im Azure SDK [7] integriert, was die Verwendung von WebJobs äußerst einfach gestaltet. Die deployten WebJobs werden pro Deployment Slot gehostet, was im Umkehrschluss bedeutet, dass auch automatisierte Jobs in Staging-Environments vorher getestet werden können, bevor der "Swap" auf das Produktivsystem erfolgt.
Neben den zahlreichen Platform-Services, die von Azure Web Apps geboten werden, stehen auch bereits fertig vorkonfigurierte "Software as a Service" (SaaS)-Angebote im Azure Marketplace zur Verfügung. Sie brauchen also nicht das Rad neu zu erfinden, falls Sie ein simples Hosting eines Blogs, Shops oder ähnliches in Erwägung ziehen – werfen Sie einen Blick auf die bestehenden Templates und provisionieren Sie beispielsweise Ihren Wordpress-Blog in nur 5 Minuten. Der aufmerksamen Leserschaft kommt beim Thema Wordpress womöglich MySQL als Datenbanktechnologie in den Sinn. Richtig! Durch so genannte Container Apps [8] können auch andere (nicht auf den ersten Blick vermutete) Technologien direkt in Azure betrieben 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 so genannten "Single Page Applications" (SPA) und die einfache "Konsumierbarkeit" von beinahe jeder denkbaren Plattform bzw. Technologie weist ganz klar in Richtung leichtgewichtiger Web Services. Doch damit nicht genug – der "letzte Schrei" geht sogar in Richtung noch stärkerer Entkoppelung: Stichwort Microservices, worauf jedoch in diesem Artikel nicht näher eingegangen wird [9].
Ähnlich wie auch bei den Azure Web Apps ist es möglich, sich für andere Technologien als für C# und .NET zu entscheiden, um die jeweilige API App zu entwickeln – so kann beispielsweise auch auf Java oder Node.js zu Entwicklung der Serviceschicht zurückgegriffen werden.
In der Einführung wurde bereits darauf hingewiesen, dass eine sehr enge Verwandtschaft zwischen Web Apps und Mobile Apps besteht – diese äußert sich dadurch, dass auch die Konfigurationseinstellungen im Azure Portal nahezu identisch sind und Funktionen wie Autoscaling, Remote Debugging, Deployment Slots, Continuous Delivery, Monitoring, etc. ebenfalls für API Apps zur Verfügung stehen.
Neben Features wie der einfachen Absicherung von Schnittstellen über integrierte Zugriffssteuerungen wie beispielsweise Azure Active Directory oder anderen Identitätsanbietern wie Facebook und Twitter, stehen ebenso fertige Out-of-the-box-Lösungen für "Cross Origin Resource Sharing" (CORS)-Management zur Verfügung, welche direkt über das Azure Portal eingerichtet werden können.
Nun aber zum Thema Metadaten: Oftmals werden REST-Services von hartgesottenen SOAP-Verfechtern 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, dennoch gehört diese Argumentation der Vergangenheit an und zwar aus folgendem Grund: Ausgehend von einer mittels ASP.NET Web API [10] realisierten REST-Schnittstelle zum Abrufen von Zufallszahlen zwischen 0 und 100 (s. Listing 1), werden unter Verwendung der Interface-Spezifikation "Swagger" [11] und dem NuGet-Package "Swashbuckle" [12] (.NET-Implementierung für Swagger), die entsprechenden Metadaten in JSON-Repräsentation für unsere Mini-API erzeugt (s. Listing 2). 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 (ähnlich SOAP) erzeugt werden.
Listing 1:
using System;
using System.Web.Http;
namespace RandomNumbers.API.Controllers
{
public class RandomNumberController : ApiController
{
private Random rand = new Random();
public int Get()
{
return rand.Next(0, 101);
}
}
}Listing 2:
{
"swagger": "2.0",
"info": {
"version": "v1",
"title": "RandomNumbers.API"
},
"host": "localhost:1499",
"schemes": [ "http" ],
"paths": {
"/api/RandomNumber": {
"get": {
"tags": [ "RandomNumber" ],
"operationId": "RandomNumber_Get",
"consumes": [ ],
"produces": [ "application/json", "text/json", "application/xml", "text/xml" ],
"responses": {
"200": {
"description": "OK",
"schema": {
"format": "int32",
"type": "integer"
}
}
},
"deprecated": false
}
}
},
"definitions": { }
}Das Azure-Portal bietet außerdem die Möglichkeit zur Konfiguration eines "API definition"-Endpunktes, was mehrere Vorteile speziell im Zusammenhang mit Logic Apps (s. u.) bringt und eine zentrale Stelle für andere Services zur Verfügung stellt, auf die Metadaten zuzugreifen.
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.
Azure Mobile Apps bieten somit einen großen Werkzeugkasten an fertigen Features und APIs, die direkt von Entwicklerinnen und Entwicklern verwendet werden können. Mit Hilfe der sogenannten "Easy Tables" bzw. "Easy APIs" können einfache Web-Services (mit und ohne Datenbankanbindung bzw. dynamischem Schema) per "Project Monaco" [13] sogar direkt im Browser (mittels Node.js) erstellt werden. Für Fans "herkömmlicher" .NET-Backends ist es aber trotzdem möglich, dieses auch über ein im Azure SDK enthaltenes Mobile Service App-Template direkt per Visual Studio zu erzeugen und später beispielsweise per Web-Deploy zu veröffentlichen.
Zum raschen Anbinden mobiler Clients, werden so genannte Quickstart-Projekte für verschiedene Plattformen direkt über das Azure-Portal zum Download angeboten (s. Abb.5).
Logic Apps
Neben den drei bisher vorgestellten App Services, stellen Logic Apps die "Außenseiter" dar. Grund dafür ist, dass Logic Apps nicht zwingend nur von Entwicklerinnen und Entwicklern erstellt und betrieben werden können – vielmehr zielen Logic Apps darauf ab, Workflows auf einfache Art und Weise zu erstellen und zu warten. Dies passiert direkt per Azure Portal, was ebenso bedeutet, dass das einzige benötigte Werkzeug ein Webbrowser ist. Damit ist es möglich, beispielsweise auch Ihren Kunden eine Möglichkeit zu bieten, um verschiedene Tasks selbst anzustoßen und steuern zu können. Die Bausteine die dabei zur Verfügung stehen sind Aktionselemente (Actions) und logische Überprüfungen bzw. Verzweigungen (Conditions).
Abb.6 zeigt einen sehr einfachen Workflow. Am Beginn des Workflows stehen so genannte "Trigger". Diese können in der einfachsten Form direkt über das Portal bzw. per HTTP-Request, im fortgeschrittenen Fall aber auch durch einen angebundenen 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 erstelle API um Zufallszahlen zu liefern zugegriffen. 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 Abb.7 das Resultat des API-Calls als Parameter in den SMS-Text mit aufgenommen wird.
Da Logic Apps nicht mit Hilfe von Visual Studio entwickelt werden, stehen Ihnen direkt im Azure-Portal umfangreiche Möglichkeiten für Debugging und Monitor zur Verfügung, um so stets alle Details Ihres Workflows im Auge zu behalten.
Zusammenfassung
In diesem Artikel wurde gezeigt, dass Microsoft Azure mit der App Service-Plattform eine Vielzahl an Werkzeugen zur Verfügung stellt, um solide Anwendungen, beginnend bei der einfachen Website bis hin zur umfangreichen Enterprise-Webanwendung zu realisieren. Dabei stehen Ihnen Services wie Web Apps, um Webanwendungen bzw. API Apps um Web-Serviceanwendungen zu erstellen, zur Verfügung. Für mobile Endgeräte eignen sich die so genannten Mobile Apps speziell auch deswegen, weil diese fertige Out-of-the-box-Lösungen zur Umsetzung von Cloud-Backends samt Datenbankanbindung zur Verfügung stellen. Die vorgestellten Logic Apps bieten eine Möglichkeit, sehr einfach und elegant Workflow-Anwendungen zu realisieren, was Zeit und auch Entwicklungsaufwand sparen kann und zugleich für gute Wartbarkeit sorgt.
- Microsoft Azure: App Service Plan
- Microsoft Azure: Deployment Slots
- Wikipedia: Continuous Delivery
- Visual Studio: Team Services
- Azure Portal
- Microsoft Azure: Application Insights
- Microsoft Azure: Azure SDK
- Microsoft Azure: Container Apps
- Informatik Aktuell: Von Monolithen und Microservices
- ASP.NET: Web API
- Swagger
- Swashbuckle
- Microsoft Azure: Project Monaco
