Web-Anwendungen über Azure App Services (hochverfügbar) betreiben

Dem Vorteil der unkomplizierten Migration stehen nachher alle Nachteile von IaaS gegenüber. Dazu zählt, dass Sie sich dann um das Patching der Gastsysteme, der Laufzeit­umgebungen (.NET, Java/Tomcat, Node, etc.), des Web-Servers oder der Datenbank selbst kümmern müssen.

Soll eine Web-Anwendung hochverfügbar sein, dann müssen Sie außerdem einen Load-Balancer und mehrere Instanzen des Web-Servers einplanen, was auch bei den Kosten zu berück­sichtigen ist.

Verwenden Sie für den Load-Balancer ebenfalls Azure-VMs, dann müssen Sie auch diese hoch­verfügbar gestalten und ggf. Lizenzkosten für F5 oder andere Anbieter einkalkulieren. Hier hilft dann Azure Migrate nur noch bedingt.

Trotzdem ist eine solche "Lift & Shift"-Migration immer die erste Wahl, wenn Sie keine Zeit oder Expertise haben, den Quellecode Ihrer Web-Anwendung für die Cloud anzupassen.

Es gibt aber durchaus auch andere Migrations­muster. Microsoft liefert in seinem Cloud Adoption Framework Beispiele für die Migration von Anwendung nach Azure. Das Umpacken (Refactoring) erfordert zum Beispiel nur minimale Änderungen der Anwendungen, sodass Sie eine Verbindung mit Azure-PaaS herstellen und Cloud-Angebote nutzen können.

Features von Web Apps

Unter dem Strich bietet das Bereitstellen von Web-Anwendungen auf einem PaaS wie Azure App Services, Amazon Elastic Beanstalk oder Red Hat Open Shift zahleiche Vorteile. Diese sind bei Azure:

• Verhältnismäßig hoher SLA von 99,95 Prozent ohne zusätzliche Redun­danz­­maß­nahmen
• App-Service ist ISO-, SOC- und PCI-konform
• Entwickler können die Azure Identity Platform nutzen, um die Nutzer ihrer Apps via Azure Active Directory, Google, Facebook, Twitter oder Microsoft-Konto zu authentifizieren.
• Unterstützung für alle wichtigen Sprachen und Frameworks einschließlich PowerShell-Scripts und der Möglichkeit, ausführbare Dateien als Hintergrund­dienste auszuführen
• Alternative Bereitstellung von Apps in Docker- oder Windows-Containern
• Globale Skalierung und Verfügbarkeit
• Devops und CI/CD-Integration mit Unterstützung für Azure DevOps, GitHub, BitBucket, Docker Hub oder Azure Container Registry zur fortlaufenden Bereitstellung von Apps einschließlich Unterstützung für Staging-Umgebungen
• Visual Studio- und Visual Studio Code-Integration
• Über 50 Konnektoren zur Integration von SaaS-Lösungen wie SAP oder Salesforce und anderen Internetdiensten (zum Beispiel Facebook)

Der Azure Marketplace sowie die Azure Quickstarts enthalten zahlreiche Anwendungs­vorlagen für Web-Anwendungen auf Basis von Azure App Service wie Drupal, Joomla oder Wordpress.

Service-Pläne für App Services

Unter Azure App Services versteht Microsoft eine Sammlung von Diensten für moderne Anwendungen, darunter Web Apps, Static Web Apps, Mobile Apps, containerisierte Web Apps oder API Apps. Im Prinzip gehören auch die Server-losen Dienste Logic Apps und Function Apps dazu.

Während Sie bei den beiden Letztgenannten die Wahl zwischen Server-los und bereitgestellt haben, rechnet Microsoft die Web-Apps über einen so genannten App Service-Plan (ASP) ab. Ein solcher definiert die Infrastruktur bestehend aus einer Reihe von VM-Instanzen bzw. Scalesets (mit Load-Balancern), die zum Hosten einer Web-Anwendung benötigt werden.

Im Gegensatz zu IaaS kümmert sich Microsoft komplett um die Bereitstellung und den Betrieb der Web-Apps und der zugehörigen Service-Pläne, also auch um die Hardware-Basis. Das umfasst auch die Pflege und das Patching der Laufzeit­umgebung oder das automatische Sichern der Web-Anwendung.

Sie müssen sich als Entwickler nur noch um den Code kümmern. Unterstützt werden die Laufzeitstapel .NET, Java, Node.js, PHP und Python für Windows sowie .NET Core, Node.js, PHP oder Ruby auf Linux.

Service-Pläne sind in unterschiedlichen Familien (Free, Shared, Basic, Standard, Premium und Isolated) und Größen (F1;D1;B1/2/3;S1/2/3;P1/2/3 usw.) verfügbar, die sich in Funktionen und Leistung (enthaltene Hardware) unterscheiden.

Hinzu kommt eine Reihe interessanter Funktionen wie die Unterstützung für benutzerdefinierte Domänen und SSL, automatische Skalierung, Bereitstellungs-Slots und globaler Lastausgleich mittels Traffic Manager. Außerdem sichert Microsoft die Web-Apps täglich.

Um Kosten zu sparen können Sie nach Belieben auch mehrere Web-Apps auf dem gleichen Service-Plan ausführen. Bei den Plänen der Free- und Shared-Familie teilen sie diesen ohnehin mit anderen Kunden.

Der Isolated-Plan hostet Apps in einer privaten, dedizierten Azure-Umgebung und eignet sich für Apps, die eine sichere Verbindung mit dem lokalen Netzwerk oder zusätzliche Leistung und Skalierung erfordern. App Service-Pläne rechnet Microsoft immer sekundengenau ab.

F1 empfiehlt sich auch, wenn Sie einen ursprünglich verwendeten, größeren Plan eine Weile nicht benötigen, denn im Gegensatz zu IaaS lassen sich PaaS-Dienste nicht pausieren. Eine Azure-VM können Sie (automatisch) herunterfahren, solange Sie diese nicht brauchen.

Das Downsizing klappt freilich nur, wenn der kleinere Plan auch die im größeren enthaltenen Features abdecken kann. Andernfalls müssten Sie Funktionen vorab gezielt deaktivieren.

Azure Compute Units (ACUs)

In jedem Fall gibt Azure die Compute-Leistung von Service-Plänen in Form so genannter ACUs an. Hierbei handelt es sich um dedizierte Compute-Ressourcen, die zum Ausführen von Anwendungen im App Service-Plan benötigt werden.

Insofern ist die ACU ein guter Vergleichswert, um beurteilen zu können, wie leistungsfähig ihr Service-Plan im Vergleich zu dedizieren Azure-VM-Größen ist.

Derzeit ist der ACU-Wert für eine kleine Azure-VM vom Typ Standard_A1 mit dem Wert 100 geeicht. So können Sie an den anderen SKUs leicht ablesen, wie die gewählte ACU leistungs­technisch (im Vergleich zu konkreten CPU/Core-Angaben) dasteht. ACUs nutzen Intels Turbo-Technologie, um bei Bedarf Leistungs­steigerungen durch Übertaktung zu erzielen.

Individueller Code

Jede Web-App wird mit einer Standard-Homepage (hostingstart.html) bereitgestellt. Sie haben aber die Wahl, ihren individuellen Code entweder im Verlauf des initialen Deployments oder im Anschluss daran via CI/CD-Pipeline (Azure Devops/Azure Pipelines, GitHub, Bitbucket) automatisiert aus ihrem bevorzugten Quellcode-Repository einzuspielen bzw. zu aktualisieren.

Alternativ können Sie Code manuell via FTP/FTPS bzw. direkt über die Konsolen­verbindung hochladen.

Microsoft beschreibt zahlreiche Bereitstellungs­varianten für die unterstützen Sprachen-Frameworks und Technologie­stapel ASP.NET, Node.js, Java, Python, Ruby, Static Website und auch für Wordpress in seiner sehr guten Dokumentation.

Beim initialen Bereitstellen der Web-App wählen Sie zunächst, ob Sie Code veröffentlichen oder Ihre Web-App in einem Container bereitstellen bzw. eine statische Web-App erstellen möchten. Letzteres ist ein eigenständiger Azure-Service.

Beim Veröffentlichen von Code wählen Sie dann den gewünschten Laufzeitstapel und die Region aus. Den zugrunde liegenden App-Service-Plan können Sie vorher oder direkt hier beim Konfigurieren der Web-App erstellen. Microsoft schlägt automatisch einen Plan (Premium V2 P2v2) für 62,18 Euro/Monat vor.

Je nachdem für welchen Laufzeitstapel und welche OS-Plattform Sie sich entscheiden, können Sie im Bereitstellungs­assistenten ggf. schon Ihre CI/CD-Integration mit GitHub als Quellcode-Repository und GitHub Actions als Build-Anbieter einrichten.

Andere Kombinationen von Quellcode-Anbieter und Build-Service können Sie später im Bereitstellungs­center konfigurieren. Der App Service bringt in jedem Fall auch einen eigenen Build-Service mit.

Nach Fertigstellung der App finden Sie auf der Übersichtsseite oben rechts die Anwendungs-URL und ggf. den von Azure erzeugten FTP/FTPS-Hostnamen nebst zugehörigen FTP-Nutzer, falls Sie ihre App doch klassisch betanken möchten.

Die URL führt dann zur standardmäßigen Startseite des Service und hört auf den DNS-Suffix azurewebsites.net. Benutzerdefinierte Domänennamen können Sie später wahlweise mit Hilfe eines CNAME-Records bei Ihren eigenen DNS-Registrar erzeugen oder Sie erwerben eine exklusive Domain für Ihren App-Service mit Hilfe des Azure-Dienstes App Service-Domäne für einen Festpreis für 11,99 USD pro Jahr.

Auf dem Service-Plan selbst ist die hostingstart.html bei einem Linux-Unterbau etwa unter /home/site/wwwroot zu finden. Das können Sie leicht verifizieren, wenn Sie sich unter https://<app_name>.scm.azurewebsites.net/webssh/host mit Hilfe der so genannten Kudu-Konsole via SSH mit Ihrem Webserver verbinden.

Wenn Sie eine Web-App erstellen, generiert der App Service stets eine zweite, begleitende HTTPS-geschützte App, die unter der angegeben Kudu-URL erreichbar ist. So könnten Sie auf diesen Weg ihren individuellen Code auch mit klassischen Unix-Tools bereitstellen.

Vorrangig dient Kudu aber dazu, zum Beispiel IIS-Speicherabbilder oder Docker-Protokolle herunter­zuladen oder IIS-Prozesse und Website-Erweiterungen zu verwalten. Kudu selbst ist ein Open-Source-Projekt.