Das Azure App-Service-Angebot für Entwickler
Dieser Artikel stellt das App-Service-Angebot der Microsoft Azure Cloud für Entwickler vor. Im ersten Teil werden die verschiedenen Wege in die Cloud erläutert und wie diese sich in den Jahren des Cloud-Zeitalters verändert haben. Im zweiten Teil wird das Azure App-Service-Angebot vorgestellt und auf die wichtigsten Features eingegangen.
Viele Wege führen in die Cloud
Cloud-Computing hat sich mittlerweile etabliert und ist in der Welt des Business definitiv angekommen. Firmen erkennen die Vorteile, von welchen sie durch die Auslagerung von Workloads in die Cloud profitieren können. Die klassischen Betriebsmodelle der Cloud haben sich bewährt, wir sprechen nach wie vor von IaaS, PaaS und SaaS.
Bei Infrastructure-as-a-Service (IaaS) spielen virtuelle Maschinen, welche auf der Cloud-Plattform gehostet werden, die Hauptrolle. Der IaaS-Ansatz ist oft der schnellste Weg in die Cloud, aber auch der unspektakulärste. Durch das "Lift and Shift"-Verfahren werden Anwendungen aus dem on-premises Datacenter wortwörtlich in die Cloud verschoben. Werden diese Anwendungen bereits auf virtuellen Maschinen ausgeführt, dann können sie mit minimalem Aufwand in die Cloud umgezogen werden. Unspektakulär ist der IaaS-Ansatz deshalb, weil die verschobenen Anwendungen typischerweise nicht groß von den eigentlichen Stärken der Cloud, wie beispielsweise der grenzenlosen Skalierbarkeit, profitieren können. Die Ursache dafür ist, dass die Anwendungen nicht für die Cloud konzipiert wurden.
Serverless-Computing bettet sich zwischen PaaS und SaaS ein und beschreibt eine Evolution von Platform-as-a-Service.
Mit Platform-as-a-Service (PaaS) stellt der Cloud-Anbieter eine Plattform zur Verfügung, auf welcher Applikationen ausgeführt werden können. Die darunterliegende Infrastruktur, beispielsweise das Betriebssystem und der Webserver, werden dabei abstrahiert, deren Verwaltung wird vom Cloud-Anbieter übernommen. Der Cloud-Nutzer kauft die Pflege der darunterliegenden Infrastruktur als Dienstleistung vom Anbieter und kann sich vollständig auf die Applikation konzentrieren. PaaS-Ansätze sind sehr komfortabel, sind aber immer begleitet von der Tatsache, dass die Abgabe von Verantwortung für Systemteile auch mit einer Einschränkung der Möglichkeiten und der Flexibilität einhergeht.
Beim Software-as-a-Service-Ansatz (SaaS) übernimmt der Cloud-Anbieter die Verantwortung für das gesamte System. Die Applikation wird über das Konzept von Mandanten in Kombination mit einem Abonnement an die Nutzer verkauft. Der Nutzer konsumiert die Applikation aus dem Internet und hat keinen Einfluss auf die Infrastruktur oder allfällige Konfigurationsmöglichkeiten. Die typischen Beispiele für SaaS-Angebote sind Dienste wie Office365 oder Dropbox.
Zu den drei Ansätzen IaaS, PaaS und SaaS ist mittlerweile ein vierter hinzugekommen. Die Rede ist von Functions-as-a-Service (FaaS) und der Idee des Serverless-Computing. Serverless-Computing bettet sich zwischen PaaS und SaaS ein und beschreibt eine Evolution von Platform-as-a-Service.
Während beim PaaS-Modell der Server zwar abstrahiert wird, besteht das logische Konzept des Servers nach wie vor. Der Cloud-Nutzer mietet sich vom Cloud-Anbieter eine virtuelle Plattform, auf der Anwendungen gehostet werden. Dabei kann der Cloud-Nutzer entscheiden, was für eine Leistung diese Plattform haben soll und wie viel er dafür zu bezahlen bereit ist. Das bedeutet, dass die Leistung im Voraus vereinbart und mit einem fixen Betrag pro Minute bezahlt wird, unabhängig davon, wie viel Leistung die Anwendungen wirklich brauchen. Auf der anderen Seite leidet natürlich die Anwendung, wenn sie mehr Leistung braucht als vereinbart wurde.
Beim Serverless-Computing fällt diese Entscheidung, wie viel Leistung gekauft werden soll, komplett weg. Die Verrechnung erfolgt dabei im sogenannten Consumption-Modell, was bedeutet, dass nur wirklich konsumierte Leistung bezahlt werden muss. Typischerweise werden dabei Aufrufe von Funktionen gezählt und monatlich verrechnet. Werden keine Funktionen aufgerufen, dann muss auch nichts bezahlt werden. Die Vertreter von Serverless-Computing in der Azure Cloud sind Azure Functions, Logic Apps und das Event Grid. Bei gewissen Angeboten der Azure Cloud kann auch der Käufer entscheiden, ob er diese im klassischen PaaS-Modell (Bezahlung für ein vereinbartes Leistungsangebot) oder im Consumption-Modell (Bezahlung pro Aufruf) betreiben möchte. Die verschiedenen Modelle sind in Abb. 1 aufgezeichnet.
Der Azure App-Service
Der Azure App-Service ist die Plattform, auf welcher Funktionalität mit dem Platform-as-a-Service-Ansatz in der Azure Cloud betrieben werden kann. Die Plattform ist offen und unterstützt die Programmiersprachen .NET, Node.js, PHP, Java, Python und JavaScript sowie die Betriebssysteme Windows und Linux. Weitere Features sind Hochverfügbarkeit, automatische und manuelle Skalierung und das automatisierte Deployment von verschiedenen Code-Repositories wie GitHub, VSTS oder Bitbucket.
Die Grundlage des App-Services ist der sogenannte App-Service-Plan. Dieser Plan beschreibt die eingekaufte Leistung im Sinn von Memory-, Compute-, und Storage-Ressourcen und legt fest, von welchem Datacenter die eben genannten Ressourcen bezogen werden. Sobald der App-Service-Plan bereitgestellt ist, können darauf Anwendungen, als Apps bezeichnet, instanziiert werden. Eine App kann man sich dabei als Gefäß vorstellen, das Funktionalität beinhaltet. Mehrere Apps können sich dabei den gleichen App-Service-Plan, und somit die Ressourcen, teilen. Das Azure App-Service stellt folgende Arten von Apps zur Verfügung:
- Web-Apps
- API-Apps
- Mobile-Apps
- Logic-Apps
- Function-Apps
Web-Apps
Die Web-App ist ausgelegt für das Hosting einer klassischen Webanwendung, also eine App, welche über den Browser bedient wird und dem Benutzer ein grafisches Interface zur Verfügung stellt. Der Ablauf funktioniert in der Regel so, dass die Web-App im ersten Schritt über das Azure-Portal erstellt und konfiguriert wird. Die Web-App hat eine eindeutige und über das Internet erreichbare URL sowie diverse Endpunkte, über welche ein Deployment ausgeführt werden kann. Im zweiten Schritt wird Code hochgeladen oder automatisch aus einer Entwicklungsumgebung oder einem Quellcodesystem ausgeliefert. Der App-Service unterstützt dabei das Deployment von Code in den Sprachen .NET, Node.js, PHP, Java, Python und JavaScript sowie das Hosting von Docker-Containern. Weitere Informationen zu Web-Apps gibt es in der Azure Dokumentation [1].
API Apps
API steht für Application Programming Interface und bezeichnet eine Schnittstelle, über welche Programmierer mit einem anderen System kommunizieren können. Bei API-Apps ist der Name Programm. API-Apps funktionieren gleich wie Web-Apps, außer, dass sie keine grafische, sondern eine Datenschnittstelle, eben die API, bereitstellen. Technologisch gesehen basieren Azure API-Apps auf dem ASP.NET-Web-API-Framework und sind um die Beschreibungssprache Swagger aus der OpenAPI Specification erweitert. Swagger ist eine Sprache, mit welcher APIs unabhängig von der Technologie beschrieben werden können. Diese Beschreibung gilt sowohl für Menschen als auch für Maschinen und ermöglicht, dass sowohl über die Schnittstelle gesprochen, als auch Code für Client und Server generiert werden kann. Neben dem Code in einer Programmiersprache besteht auch die Möglichkeit, eine Hilfeseite zur Dokumentation der Schnittstelle zu generieren (s. Abb. 2). Die Details zu Apps können auf der offiziellen Startseite und der Dokumentation nachgelesen werden [2].
Mobile-Apps
Das Mobile-Apps-Angebot ist etwas ungeschickt benannt, da es sich nicht um mobile Apps an sich handelt, sondern um das Backend, mit welchem eine mobile App auf dem Smartphone kommuniziert. Grundsätzlich funktionieren Azure Mobile-Apps gleich wie Web-Apps oder API-Apps. Hinzu kommt eine Liste an Features, welche im Kontext von mobilen Anwendungen besonders wichtig sind. Beispiele dafür sind Push-Notifications, Daten-Synchronisation für Offline-Szenarien oder die Authentifizierung mit Social-Media-Accounts wie Facebook, Twitter oder Google. Als besonderes Feature soll "Easy Tables" erwähnt werden. Damit kann ein sogenanntes No-Code-Backend erstellt werden. Dabei kann über das Azure-Portal definiert werden, welche Tabellenstrukturen in der Datenbank vorhanden sein sollen. Die Azure Mobile-App generiert im Hintergrund diese Tabellen und darauf eine auf Node.js basierende REST-API. Dies ermöglicht die Entwicklung von mobilen Apps, ohne dass durch Programmierung ein Backend implementiert werden muss. Die Dokumentation ist unter [3] zu finden.
Logic-Apps
Bei den Logic-Apps verlassen wir den Kontext von Web-Apps und Co. Analog zur No-Code-Backend-Variante bei den Mobile-Apps ist das Beherrschen einer Programmiersprache zur Implementierung von Logic-Apps nicht nötig. Logic-Apps sind Workflows, mit welchen Funktionalität umgesetzt werden kann. Eine Logic-App besteht dabei aus Actions und Conditions, welche wie auf einem Flow-Chart aneinandergefügt werden können. Der Großteil dieser Actions erfüllt kleine Integrationsaufgaben und verbindet sich mit einem anderen System, um dort Daten, beispielsweise die neuesten Rechnungen, abzuholen. Die darauffolgenden Actions und Conditions können sämtliche Daten, welche in vorhergehenden Schritten gesammelt wurden, weiterverwenden. So wäre es denkbar, dass die empfangenen Rechnungen validiert und aufbereitet werden, bevor eine weitere Action diese an das nächste System übermittelt. Die Logic-App-Workflows können in regelmäßigen Zeitabständen automatisch ausgeführt oder auch über Ereignisse aus anderen Systemen gestartet werden. Eine Logic-App, welche einen HTTP-Request empfängt und dessen Inhalt als Email versendet, ist in Abb. 3 dargestellt. Weitere Infos gibt es in der Dokumentation [4].
Function-Apps
Unter Function-Apps kann man sich Code-Snippets in der Cloud vorstellen. Beim Erstellen einer Function bekommt man eine Methode, in welcher Logik implementiert werden kann. Im Gegensatz zu den Logic-Apps muss der Azure-Function-Entwickler sich mit einer Programmiersprache auskennen. Der Entwickler hat dann die Möglichkeit, entweder direkt im Azure-Portal den Code für seine Function zu schreiben oder wie üblich in einer Entwicklungsumgebung zu arbeiten und den Code in die Function hochzuladen. Die Function kann dabei analog zur Logic-App auch basierend auf einem Event aus einem anderen System gestartet werden. Function-Apps können sowohl auf einer App-Service-Plan-Instanz als auch im Consumption-Modell betrieben werden. Die Dokumentation dazu gibt es auf der Function-App-Startseite [5] und der Serverless-Computing-Startseite [6].
Wichtige Features des Azure-App-Services
Der folgende Abschnitt geht auf einige spannende Features der oben erwähnten Angebote ein. Je nach Ausprägung sind diese abhängig vom gewählten Pricing Tier und nicht für alle App-Typen verfügbar.
Skalierung
Einer der wichtigsten Gründe, überhaupt mit einer Cloud-Lösung zu arbeiten, ist auf jeden Fall die Elastizität. Unter Elastizität versteht man die Möglichkeit, dass die zur Verfügung stehenden Ressourcen rasch der aktuellen Nachfrage angepasst werden können. Diese Anpassung wird durch eine Skalierung erreicht, welche entweder manuell oder automatisch ausgeführt wird. Diese Elastizität im Zeitraum von wenigen Minuten macht Cloud-Angebote besonders attraktiv für Workloads, welche Lastspitzen bewältigen müssen. Im Gegensatz zum On-premises-Ansatz muss nicht in Hardware investiert werden, welche die Spitzen zwar bewältigen kann, in den ruhigeren Zeiten aber nur herumsteht.
Es werden zwei Arten der Skalierung unterschieden: Bei der vertikalen Skalierung, dem Scale-up, wird die bestehende Instanz des App-Services vergrößert. Durch ein Upgrade des Service-Plans stehen dem App-Service mehr Prozessorleistung, Arbeitsspeicher und Datenspeicher zur Verfügung.
Bei der horizontalen Skalierung, dem Scale-out, wird die Anwendung auf mehrere virtuelle Maschinen kopiert. Eingehende Anfragen werden von einem Load-Balancer auf die zur Verfügung stehenden Maschinen verteilt. Vorausgesetzt, dass die zu skalierende Anwendung mit einer Verteilung auf mehrere Maschinen umgehen kann, ist der Scale-out eigentlich trivial. Im App-Service kann über einen Slider, welcher die Anzahl zu nutzender Maschinen bestimmt, horizontal skaliert werden.
Einen Schritt weiter geht die automatische Skalierung. Über ein Set von Regeln wird definiert, wann weitere virtuelle Maschinen hinzugefügt oder entfernt werden sollen. So eine Regel könnte lauten: "Es sollen immer mindestens 2 Maschinen im Einsatz sein. Wenn die Prozessoren beider Maschinen zu mehr als 70 Prozent ausgelastet sind, dann soll eine weitere Maschine hinzugefügt werden." Analog dazu kann eine Regel definiert werden, wann Maschinen entfernt werden sollen.
Deployment-Slots
Mit Deployment-Slots kann eine Instanz einer Web-App in mehrere Slots unterteilt werden. Typischerweise unterscheidet man dabei Slots für Entwicklung, Testing, Pre-Production und Production. Jeder Deployment-Slot bekommt dabei eine eigene URL, eigene Deployment-Endpunkte und kann eigenständig konfiguriert werden. Durch einen sogenannten "Swap" können die Inhalte von Deployment-Slots untereinander ausgetauscht werden. So kann beispielsweise der neue Release der Software in den Pre-Production-Slot deployed, dort ausführlich getestet und dann per Knopfdruck mit dem Production-Slot austauscht werden. Diese Vorgehensweise hat den Vorteil, dass für das Deployment in die Produktion keine Dateien hochgeladen werden müssen. Die Dateien werden einfach zwischen den Slots ausgewechselt. Ausserdem kann über das gleiche Prinzip ein Rollback auf die alte Version der Anwendung durchgeführt werden.
Backup & Snapshots
Mit der Backup-Funktionalität können manuelle oder automatisierte Backups erstellt werden. Dabei werden die aktuellen Versionen von Konfiguration, Dateien und Datenbanken als Snapshot gespeichert und können bei Bedarf wiederhergestellt werden. Die Backups werden im Azure Blob-Storage abgelegt und können von dort natürlich auch auf andere Speichermedien heruntergeladen werden.
Monitoring mit Application Insights
Application Insights ist die Monitoring-Lösung für Telemetrie-Daten. Unter Telemetrie-Daten versteht man Daten, welche von laufenden Prozessen an einen Datensammler geschickt werden. Dieser bereitet die Daten auf und stellt sie dem Benutzer in Form von Rohdaten, Tabellen oder Diagrammen zur Verfügung. Der App-Service kann per Knopfdruck instrumentiert werden und schickt die Daten automatisch an Application Insights. Über das Azure-Portal kann auf Application Insights zugegriffen werden, wo verschiedene Reports zur Verfügbarkeit, Performance oder Problemen abgerufen werden können.
Visual Studio Debugging
Der Azure App-Service unterstützt das Remote-Debugging mit Visual Studio. Über die Funktion "Attach to Process" kann der Visual Studio Debugger an einen im App-Service laufenden Prozess angehängt werden. Dabei wird im Hintergrund auf der App-Service-Instanz der Remote-Debugger gestartet. Eine Anpassung der Konfiguration ist nicht nötig. Sobald der Debugger die Verbindung erstellt hat, funktionieren alle Debugging-Tools wie etwa Breakpoints, Watch Window etc. genau so, als wäre der Debugger an einen lokalen Prozess angehängt.
Kudu-Diagnose & Troubleshooting-Tools
Hinter der Option "Advanced Tools" verbirgt sich eine ganze Suite von Werkzeugen und Erweiterungspunkten zur Diagnose von Problemen – der Kudu-Werkzeugkasten. Die Kudu-Webseiten bieten unter anderem folgende Funktionen:
- Informationen zur Umgebung,
- Zugriff auf Log-Dateien,
- Bash- & Powershell-Konsolen auf der App-Service-Instanz, welche im Browser benutzt werden können,
- einen Process Explorer, um sich die Prozesse anzuschauen und
- Werkzeuge, um sich einen Dump des Arbeitsspeichers eines Prozesses herunterzuladen.
Ausblick
Der Azure App-Service hat sich als PaaS-Plattform für kritische, produktive Anwendungen etabliert und entwickelt sich rasant weiter. Es wird spannend sein, zu sehen, wie sich der aktuelle Hype um das Thema Serverless-Computing entwickelt und was in der nächsten Innovationswelle auf uns zurollt.
- Web-Apps-Startseite
- API-Apps-Startseite
- Mobile-Apps-Startseite
- Logic-Apps-Startseite
- Function-Apps-Startseite
- Serverless-Computing in Azure
