Azure App Service, en virtuell maskin eller containrar: var ska din .NET-applikation köras?
Flyttar du en .NET-applikation till Azure? Vem som patchar vad i App Service, på en VM och i Container Apps, vad det kostar och hur du väljer per applikation.
Vlado Pandžić · Grundare · Senior .NET-arkitekt
Publicerad · 3 min läsning
Innehåll
När en .NET-applikation lämnar en gammal server är första frågan var den ska köras sedan. I Azure finns det tre realistiska svar för en affärsapplikation: en virtuell maskin, App Service eller Container Apps. Det vanligaste misstaget är att välja den virtuella maskinen för att den känns bekant, och sedan köra samma gamla server, bara hyrd.
Vem gör vad
| Virtuell maskin | App Service | Container Apps | |
|---|---|---|---|
| Vem patchar operativsystemet | Du | Azure | Azure |
| Vad du förvaltar | Allt från Windows och uppåt | Din applikation och dess inställningar | Din container och dess inställningar |
| Skalning | En större maskin, eller fler maskiner som du sätter upp | Fler instanser med en inställning | Automatiskt, ner till noll när inget händer |
| Hur du betalar | Dygnet runt, använd eller inte | För planen, dygnet runt | Efter användning; inget så länge den är nedskalad till noll |
| Passar bäst | Applikationer som behöver sådant som bara en hel server ger | De flesta webbapplikationer och API:er | Tjänster i containrar, bakgrundsjobb, ojämn belastning |
App Service kör på Windows-planer både modern .NET och äldre ASP.NET-applikationer på .NET Framework. Du behöver inte bli klar med migreringen till .NET 10 innan du flyttar till Azure.
När en virtuell maskin
- Applikationen behöver installerad programvara, COM-komponenter eller Windows-tjänster som App Service inte tillåter.
- Den förlitar sig på särskilda inställningar i operativsystemet eller full åtkomst till filsystemet.
- Du måste snabbt lämna en gammal server, och den riktiga flytten kommer senare.
Var bara medveten om vad du får: samma ansvar som på din egen server. Uppdateringar, backup, övervakning och säkerhet är fortfarande ditt. Om skälet till flytten var en gammal Windows Server, som med Windows Server 2012 R2, löser en VM med nytt Windows datumet, inte arbetet.
När App Service
För de flesta .NET-webbapplikationer och API:er är det här standardsvaret. Azure patchar operativsystemet och runtime, du driftsätter applikationen och utskalning är en inställning.
En funktion motiverar det ofta på egen hand: deployment slots. En ny version driftsätts i en staging-slot, kontrolleras där och byts sedan mot produktion utan avbrott. Går något fel byter du tillbaka.
az webapp deployment slot swap \
--resource-group orders-rg --name orders-app \
--slot staging --target-slot productionDen vanliga fällan är planens storlek. En för stor plan kostar varje timme varje dag. Vart pengarna brukar ta vägen går vi igenom i artikeln om att sänka Azure-kostnader.
När Container Apps
- Applikationen körs redan i Docker, eller du vill att den ska göra det.
- Bakgrundsarbete som körs då och då: importer, rapporter, köhantering.
- Ojämn belastning. En container app kan skala ner till noll, och så länge den är på noll betalar du inga användningsavgifter.
Kubernetes (AKS) är nästa steg, och för en eller två affärsapplikationer är det sällan värt det extra driftarbetet. Det är rimligt för team som kör många tjänster.
Ordningen som fungerar
- Steg 1Inventering: vad varje applikation behöver
- Steg 2Välj mål per applikation
- Steg 3Testmiljön först
- Steg 4Produktion, med övervakning från dag ett
Välj per applikation, inte för hela företaget. Ett typiskt resultat: webbapplikationer och API:er på App Service, nattjobben i Container Apps och en gammal applikation med en COM-komponent på en virtuell maskin tills den är omskriven.
Sätt upp övervakningen före bytet, inte efter första klagomålet. Hur går vi igenom i artikeln om övervakning av .NET-applikationer med Application Insights, och Blazor-specifika val i Blazor på Azure.
Så arbetar vi
Precis det här gör vi. ProCoding är en .NET-studio från Split i Kroatien, och vi flyttar affärsapplikationer till Azure: inventering, rätt mål för varje applikation, flytt med testmiljön först och koll på både applikationen och fakturan efteråt. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.
Källor
- 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
Den här artikeln är endast allmän information och inte juridisk, skattemässig, ekonomisk eller annan professionell rådgivning. Scenarier, exempel och beräkningar är illustrativa. Användarvillkor och ansvarsfriskrivning.