Acesta e primul din patru articole despre Azure Container Apps. Aici răspundem la întrebarea fundamentală: merită să treci de la App Service la Container Apps? În părțile următoare acoperim configurarea și scaling rules, integrarea Dapr și pipeline-ul complet de CI/CD cu GitHub Actions.
Ce ai deja cu App Service
Dacă ai urmărit seria până aici, aplicația ta rulează probabil pe Azure App Service: stateless, cu configurație externalizată, Managed Identity pentru resurse și Key Vault pentru secrete. App Service e un PaaS excelent — deploy simplu, scalare automată, certificate managed, slots pentru blue-green. Pentru multe aplicații, e alegerea corectă și rămâne așa.
Întrebarea nu e „care e mai bun în absolut”, ci „ce problemă concretă am pe care App Service nu o rezolvă bine”. Fără o astfel de problemă, migrarea e complexitate fără beneficiu.
Ce e Azure Container Apps
Azure Container Apps (ACA) e un serviciu managed pentru rularea containerelor, construit peste Kubernetes și KEDA, dar fără să te expună la complexitatea Kubernetes. Îți dă containere, scalare bazată pe evenimente (inclusiv scale-to-zero), revizii pentru deployment-uri controlate și integrare Dapr — toate fără să administrezi un cluster.
Practic, e la mijloc între App Service (simplu, dar limitat la modelul lui) și AKS (putere maximă, dar administrare completă de cluster). ACA îți dă o bună parte din puterea Kubernetes fără costul operațional.
Comparație directă
| Criteriu | App Service | Container Apps |
|---|---|---|
| Unitate de deploy | Cod sau container | Container (obligatoriu) |
| Scale-to-zero | Nu (min 1 instanță) | Da (0 instanțe fără trafic) |
| Scalare pe evenimente | Metrici HTTP/CPU/RAM | KEDA: cozi, HTTP, CPU, custom |
| Microservicii | Un serviciu per plan | Multiple apps în același environment |
| Service discovery intern | Nu nativ | Da (DNS intern între apps) |
| Dapr | Nu | Da, built-in |
| Revizii / traffic split | Slots | Revizii cu split procentual |
| Complexitate | Minimă | Medie |
| Cost la trafic redus | Fix (plan alocat) | Variabil (poate ajunge la 0) |
Când are sens să treci
- Ai deja containere — dacă aplicația e containerizată (sau vrei să fie), ACA e un fit natural. Dacă rulezi cod direct pe App Service și ești mulțumit, containerizarea forțată doar pentru ACA e efort în plus.
- Trafic intermitent sau bursty — scale-to-zero înseamnă că nu plătești pentru instanțe inactive. Un job care rulează câteva ore pe zi sau un API cu trafic sporadic beneficiază direct.
- Scalare pe evenimente — vrei să scalezi în funcție de lungimea unei cozi (Service Bus, Storage Queue), nu doar CPU/RAM. KEDA face asta nativ.
- Arhitectură de microservicii — mai multe servicii care comunică între ele, cu service discovery intern și, opțional, Dapr pentru pub/sub și state management.
- Deployment-uri cu traffic splitting — vrei canary releases reale (10% trafic pe noua revizie), nu doar slot swap.
Când NU are sens
- O aplicație monolitică simplă cu trafic constant — App Service o servește perfect, iar scale-to-zero nu aduce nimic dacă oricum ai trafic non-stop.
- Echipa nu are experiență cu containere — ACA adaugă un strat de Docker, registry, imagini de gestionat. Dacă asta e complexitate nouă, evaluează dacă beneficiul o justifică.
- Depinzi de funcționalități specifice App Service — anumite integrări, extensii sau WebJobs care nu au echivalent direct în ACA.
- Vrei cel mai simplu model de operare posibil — App Service rămâne mai simplu de administrat pentru scenarii standard.
Ce păstrezi din ce ai deja
Vestea bună: dacă ai urmat principiile cloud-native din seria asta, migrarea e mai ușoară decât pare. Tot ce ai construit se transferă:
- Managed Identity — Container Apps suportă atât system-assigned cât și user-assigned identity, exact ca App Service.
DefaultAzureCredentialfuncționează identic. - Key Vault —
AddAzureKeyVaultși secretele funcționează la fel; ACA are și un mecanism propriu de secrete la nivel de app. - Configurație externalizată — variabilele de mediu se setează pe container app, la fel ca Application Settings.
- Stateless design — e chiar mai important în ACA, unde scale-to-zero și scalarea rapidă presupun că nicio instanță nu reține stare.
- Health checks — ACA folosește liveness și readiness probes, exact endpoint-urile
/health/liveși/health/readype care le-ai construit deja.
Cu alte cuvinte, disciplina cloud-native pe care ai aplicat-o pe App Service e exact ce face migrarea la Container Apps aproape trivială la nivel de cod. Diferența e mai mult în infrastructură și deployment.
Ce urmează
În partea a doua trecem la practică: crearea unui Container Apps environment, deployment-ul unei aplicații .NET containerizate, configurarea și scaling rules cu KEDA (inclusiv scale-to-zero și scalare pe coadă).
Apoi, în părțile 3 și 4, integrarea Dapr pentru comunicare între servicii și pipeline-ul complet de CI/CD cu GitHub Actions spre Container Registry și Container Apps.
Întrebări? Scrie-mi la contact@ludoprogramming.com.
