Azure App Service, virtuelle Maschine oder Container: Wo soll Ihre .NET-Anwendung laufen?

Wenn eine .NET-Anwendung einen alten Server verlässt, ist die erste Frage, wo sie danach läuft. In Azure gibt es für eine Geschäftsanwendung drei realistische Antworten: eine virtuelle Maschine, App Service oder Container Apps. Der häufigste Fehler ist, die virtuelle Maschine zu wählen, weil sie vertraut wirkt, und dann denselben alten Server zu betreiben, nur gemietet.

Wer was macht

	Virtuelle Maschine	App Service	Container Apps
Wer das Betriebssystem patcht	Sie	Azure	Azure
Was Sie verwalten	Alles ab Windows aufwärts	Ihre Anwendung und ihre Einstellungen	Ihren Container und seine Einstellungen
Skalierung	Größere Maschine oder mehr Maschinen, die Sie selbst einrichten	Mehr Instanzen per Einstellung	Automatisch, bis auf null im Leerlauf
Wie Sie bezahlen	Rund um die Uhr, genutzt oder nicht	Für den Plan, rund um die Uhr	Nach Nutzung; nichts, solange auf null skaliert
Passt am besten	Anwendungen, die nur ein ganzer Server bietet	Die meisten Webanwendungen und APIs	Containerisierte Services, Hintergrundjobs, unregelmäßige Last

App Service betreibt auf Windows-Plänen sowohl modernes .NET als auch ältere ASP.NET-Anwendungen auf .NET Framework. Sie müssen die Migration auf .NET 10 nicht abschließen, bevor Sie nach Azure gehen.

Wann eine virtuelle Maschine

• Die Anwendung braucht installierte Software, COM-Komponenten oder Windows-Dienste, die App Service nicht zulässt.
• Sie hängt an speziellen Betriebssystem-Einstellungen oder vollem Dateisystemzugriff.
• Sie müssen einen alten Server schnell verlassen, und der richtige Umzug kommt später.

Seien Sie sich nur bewusst, was Sie bekommen: dieselben Pflichten wie auf dem eigenen Server. Updates, Backups, Überwachung und Sicherheit bleiben bei Ihnen. War ein alter Windows Server der Grund für den Umzug, wie bei Windows Server 2012 R2, löst eine VM mit neuem Windows das Datum, nicht die Arbeit.

Wann App Service

Für die meisten .NET-Webanwendungen und APIs ist das die Standardantwort. Azure patcht Betriebssystem und Runtime, Sie deployen die Anwendung, und Skalierung ist eine Einstellung.

Eine Funktion rechtfertigt es oft allein: Deployment Slots. Eine neue Version wird in einen Staging-Slot deployt, dort geprüft und dann ohne Ausfallzeit mit der Produktion getauscht. Geht etwas schief, tauschen Sie zurück.

az webapp deployment slot swap \
  --resource-group orders-rg --name orders-app \
  --slot staging --target-slot production

Die übliche Falle ist die Plangröße. Ein zu großer Plan kostet jede Stunde jedes Tages. Wohin das Geld meist geht, steht in unserem Artikel zum Senken der Azure-Kosten.

Wann Container Apps

• Die Anwendung läuft schon in Docker, oder sie soll es.
• Hintergrundarbeit, die ab und zu läuft: Importe, Berichte, Verarbeitung von Warteschlangen.
• Unregelmäßige Last. Eine Container App kann auf null skalieren, und solange sie auf null ist, zahlen Sie keine Nutzungsgebühren.

Kubernetes (AKS) ist die nächste Stufe, und für ein oder zwei Geschäftsanwendungen lohnt sich der zusätzliche Betriebsaufwand selten. Sinnvoll ist es für Teams, die viele Services betreiben.

Die Reihenfolge, die funktioniert

1. Schritt 1Bestandsaufnahme: was jede Anwendung braucht
2. Schritt 2Ziel pro Anwendung wählen
3. Schritt 3Zuerst die Testumgebung
4. Schritt 4Produktion, mit Monitoring ab Tag eins

Wählen Sie pro Anwendung, nicht für das ganze Unternehmen. Ein typisches Ergebnis: Webanwendungen und APIs auf App Service, die nächtlichen Jobs in Container Apps und eine alte Anwendung mit COM-Komponente auf einer VM, bis sie neu geschrieben ist.

Richten Sie das Monitoring vor der Umstellung ein, nicht nach der ersten Beschwerde. Wie das geht, steht in unserem Artikel zum Monitoring von .NET-Anwendungen mit Application Insights, Blazor-spezifische Entscheidungen im Artikel Blazor auf Azure hosten.

Wie wir arbeiten

Genau das machen wir. ProCoding ist ein .NET-Studio aus Split in Kroatien, und wir ziehen Geschäftsanwendungen nach Azure um: Bestandsaufnahme, das richtige Ziel für jede Anwendung, der Umzug mit zuerst einer Testumgebung und danach ein wacher Blick auf Anwendung und Rechnung. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Choose an Azure compute service, Microsoft Learn
• OS and runtime patching in Azure App Service, Microsoft Learn
• Set scaling rules in Azure Container Apps, Microsoft Learn