Choosing Between Azure VMs, App Service, and AKS

Overview and What You Will Learn

In this lab, you will deploy the exact same simple web application three different ways - on a raw VM, on App Service, and see the conceptual difference AKS would add - so the trade-offs between control, operational overhead, and scaling become concrete rather than theoretical.

Why This Matters in Production

An engineering team at PhonePe builds a simple internal reporting tool and deploys it on a full virtual machine they now have to patch, monitor, and manage forever, when App Service would have handled the exact same workload with zero server management and automatic scaling included. The wrong compute choice does not fail outright - it just quietly costs more engineering time every month for the rest of the application's life.

Core Principles

Each compute option trades control for operational simplicity, and the right choice depends entirely on what the workload actually needs.

The decision comes down to three questions: does the workload need full OS-level control or custom software that App Service can't run? Is it a single application or many coordinated containerized services? And how much operational overhead is the team actually equipped to take on long-term?

Detailed Step-by-Step Practical Lab

1. Create a Resource Group:

2. Deploy a simple app on a raw VM, taking on full responsibility for the OS:

3. Deploy the same conceptual app on App Service instead, with zero OS management required:

4. Compare what each option required so far - notice the VM path needed you to manage the OS layer entirely yourself, while the App Service path had Azure handle it:

5. Consider when the picture changes: if this reporting tool needed to become five interdependent containerized services - a web frontend, an API, a background worker, a cache, and a queue processor - all needing coordinated scaling and service discovery, that complexity is what justifies moving to AKS instead of either the VM or App Service path.

6. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Reaching for AKS by default because it feels like the more "serious" or scalable choice, then discovering the team is now managing Kubernetes cluster upgrades, node pool sizing, and networking complexity for a workload that was really just one simple web application that App Service would have handled with far less ongoing effort.

Tip

Start with App Service for any standard web application unless a specific, concrete reason requires full VM-level control. App Service's built-in scaling, deployment slots, and zero OS maintenance overhead outweigh the flexibility of a raw VM for the large majority of web workloads.

• VMs are the right choice for a genuine, specific need - legacy software requiring a particular OS configuration, custom kernel modules, or workloads needing hardware-level access App Service and AKS don't expose.
• AKS earns its place once you have multiple interdependent containerized services needing coordinated scaling and service discovery - not simply because "containers" sound more modern than a VM or App Service deployment.

Quick Reference & Troubleshooting Commands