Azure App Service, virtualni stroj ili kontejneri: gdje bi trebala raditi vaša .NET aplikacija?

Kad .NET aplikacija napušta stari server, prvo pitanje je gdje će raditi dalje. U Azureu za poslovnu aplikaciju postoje tri realna odgovora: virtualni stroj, App Service ili Container Apps. Najčešća greška je izabrati virtualni stroj jer djeluje poznato, a onda imati isti stari server, samo iznajmljen.

Tko što radi

	Virtualni stroj	App Service	Container Apps
Tko krpa operacijski sustav	Vi	Azure	Azure
Čime upravljate	Svime od Windowsa naviše	Svojom aplikacijom i njezinim postavkama	Svojim kontejnerom i njegovim postavkama
Skaliranje	Veći stroj ili više strojeva koje sami postavite	Više instanci jednom postavkom	Automatski, do nule kad nema posla
Kako plaćate	Non-stop, koristilo se ili ne	Za plan, non-stop	Za korištenje; ništa dok je na nuli
Najbolje odgovara	Aplikacijama koje trebaju ono što daje samo cijeli server	Većini web aplikacija i API-ja	Servisima u kontejnerima, pozadinskim poslovima, neravnomjernom opterećenju

App Service na Windows planovima pokreće i moderni .NET i starije ASP.NET aplikacije na .NET Frameworku. Ne morate završiti migraciju na .NET 10 prije prelaska u Azure.

Kada virtualni stroj

• Aplikaciji treba instalirani softver, COM komponente ili Windows servisi koje App Service ne dopušta.
• Oslanja se na posebne postavke operacijskog sustava ili puni pristup datotečnom sustavu.
• Trebate brzo napustiti stari server, a pravi prelazak dolazi kasnije.

Samo budite svjesni što dobivate: iste odgovornosti kao na vlastitom serveru. Nadogradnje, backupi, nadzor i sigurnost i dalje su vaši. Ako je razlog odlaska bio stari Windows Server, kao kod Windows Servera 2012 R2, virtualni stroj s novim Windowsom rješava datum, ali ne i posao.

Kada App Service

Za većinu .NET web aplikacija i API-ja ovo je podrazumijevani odgovor. Azure krpa operacijski sustav i runtime, vi objavljujete aplikaciju, a skaliranje je jedna postavka.

Jedna mogućnost često sama opravdava izbor: deployment slotovi. Nova verzija objavi se u staging slot, tamo se provjeri, pa zamijeni s produkcijom bez prekida rada. Ako nešto pođe krivo, zamijenite natrag.

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

Uobičajena zamka je veličina plana. Prevelik plan plaća se svaki sat svakog dana. Kamo novac obično odlazi, pišemo u članku o smanjenju troškova Azurea.

Kada Container Apps

• Aplikacija već radi u Dockeru ili želite da radi.
• Pozadinski posao koji se pokreće povremeno: uvozi, izvještaji, obrada reda poruka.
• Neravnomjerno opterećenje. Container app može se skalirati do nule, a dok je na nuli, ne plaćate korištenje.

Kubernetes (AKS) je sljedeća stepenica, i za jednu ili dvije poslovne aplikacije rijetko je vrijedan dodatnog posla oko održavanja. Ima smisla za timove koji vode puno servisa.

Redoslijed koji radi

1. Korak 1Popis: što treba koja aplikacija
2. Korak 2Odabir cilja po aplikaciji
3. Korak 3Prvo testno okruženje
4. Korak 4Produkcija, s nadzorom od prvog dana

Birajte po aplikaciji, a ne za cijelu firmu. Tipičan ishod: web aplikacije i API-ji na App Serviceu, noćni poslovi u Container Appsu i jedna stara aplikacija s COM komponentom na virtualnom stroju dok se ne prepiše.

Nadzor postavite prije prelaska, a ne nakon prve žalbe. Kako, pišemo u članku o nadzoru .NET aplikacija s Application Insightsom, a izbore specifične za Blazor u članku o Blazoru na Azureu.

Kako mi radimo

Upravo ovo radimo. ProCoding je .NET studio iz Splita, a poslovne aplikacije selimo u Azure: popis, pravi cilj za svaku aplikaciju, prelazak uz prvo testno okruženje i praćenje i aplikacije i računa nakon toga. Prvi korak je besplatan razgovor od 30 minuta.

Izvori

• 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