Academmia

Application Hosting Options in Azure: Web Apps, Containers, and Virtual Machines

az-900•mixed•

Azure architecture and services

Application Hosting Options in Azure: Web Apps, Containers, and Virtual Machines

Short Summary

In this lesson, you’ll compare three common Azure hosting options: web apps, containers, and virtual machines. You’ll learn what each option is best at and what you’re responsible for managing in each model. By the end, you’ll be able to match a simple requirement (like “no OS management” or “must control the OS”) to the right hosting choice.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define the hosting models behind web apps, containers, and virtual machines.
  • Differentiate the three options by control level and management responsibility.
  • Identify when Azure App Service is a better fit than running your own servers.
  • Choose a container-based option when portability and consistent runtime matter.
  • Explain how the Shared Responsibility Model (SRM) still applies to “managed” services.

Core Concepts

When I choose how to host an application in Azure, I’m choosing a responsibility boundary: how much Azure manages for me, and how much I manage myself. A simple rule of thumb is: more control usually means more management work.

Web apps with Azure App Service

Azure App Service is a managed platform for hosting Hypertext Transfer Protocol (HTTP)-based applications such as websites and web Application Programming Interfaces (APIs).

This is commonly described as Platform as a Service (PaaS):

  • Azure manages more of the underlying infrastructure and platform components.
  • I focus mostly on my application code, configuration, and deployment.

I typically choose App Service when I want to move fast and avoid managing servers and operating system updates.

Containers

A container packages an application and its dependencies into a portable unit that can run consistently across environments.

A key idea: containers typically share the host Operating System (OS) kernel, which keeps them lighter than running a full guest OS per workload.

In Azure, “containers” is the packaging model, and I can run containers using different services. A beginner-friendly example is:

  • Azure Container Instances (ACI) — a simple way to run containers in Azure without managing virtual machines directly.

For more complex apps with many services, orchestration can help. One option is Azure Kubernetes Service (AKS), but at the fundamentals level the important idea is: orchestration adds capabilities and also adds operational decisions.

Virtual machines

Azure Virtual Machines (VMs) provide on-demand compute where I choose and manage the guest OS (Windows or Linux) and what runs on it.

This is commonly described as Infrastructure as a Service (IaaS):

  • Azure manages the physical datacenter hardware.
  • I manage OS configuration, patching strategy, installed software, and many day-to-day operational tasks.

I typically choose VMs when I need OS-level control, have a legacy workload, or need customization that doesn’t fit well into a managed platform.

Shared Responsibility Model (SRM)

No matter which hosting option I pick, “managed” does not mean “I do nothing.”

Azure can take responsibility for parts of the platform, but I still own things like:

  • my application security decisions,
  • identity and access choices,
  • secrets and configuration,
  • data protection and safe coding practices.

Practical Understanding

Practical Situation 1: “I want to deploy a website and API fast, and I don’t want to manage servers”

A team has a straightforward HTTP website and a Representational State Transfer (REST) API. They want quick deployment and don’t want to handle OS patching or server maintenance.

How to think about it: This points to a managed web hosting model like Azure App Service, where the platform is managed for you. You focus on application code, configuration, and deployment, instead of VM-level operations.

Common misunderstanding: “Because it’s managed, I don’t need to think about security.” You still own application security choices, identity, secrets, and configuration.

Practical Situation 2: “I need the same runtime everywhere, and I want to ship the app with its dependencies”

A team wants the application to behave the same in dev/test/prod. They care about portability and consistent runtime behavior.

How to think about it: This is a classic container fit: package the app and dependencies into a container image and run it on a suitable container service. Containers are often a middle ground between a fully managed web platform and full VM control.

Common misunderstanding: “A container includes a full OS like a VM.” Containers usually share the host OS kernel; they’re not the same as running a separate guest OS per instance.

Practical Situation 3: “We have one container to run, and we don’t want to manage Kubernetes”

A workload is already containerized, but it’s a single container job or a small service, and the team doesn’t want the overhead of operating a cluster.

How to think about it: In Azure, containers do not automatically mean Kubernetes. ACI is a simpler way to run containers directly without a Kubernetes cluster when the workload doesn’t need full orchestration features.

Common misunderstanding: “Containers require AKS.” AKS is one option for orchestration, but it’s not required to run containers.

Practical Situation 4: “This legacy app needs a specific Windows Server version and custom software installed”

An application requires OS-level customization, specific OS versions, or specialized agents/drivers that don’t fit well into a managed web platform.

How to think about it: This is a strong signal for VMs (IaaS). VMs give you the most OS control and flexibility, but you take on more management tasks (patching, hardening, monitoring, and maintenance).

Common misunderstanding: “I can use any hosting option and just ‘make it work’.” These options are not interchangeable; strict OS requirements usually push you toward a VM-style model.

Common Pitfalls

  • Mistake: Assuming web apps, containers, and virtual machines are interchangeable for all workloads. Correction: Choose based on required control, portability needs, and how much infrastructure management you’re willing to own.

  • Mistake: Confusing containers with virtual machines and assuming each container has its own full operating system. Correction: Containers typically share the host OS kernel; virtual machines run a full guest OS per VM.

  • Mistake: Believing that using App Service or container services removes all customer responsibility for security and configuration. Correction: Azure can manage parts of the platform, but I still own application security decisions, configuration, and operational choices.

  • Mistake: Forgetting that virtual machines usually require the most management effort. Correction: VMs provide the most OS control, and that comes with more responsibility (patching strategy, OS configuration, installed software maintenance).

  • Mistake: Thinking containers can only run in Kubernetes. Correction: I can run containers without Kubernetes using simpler options such as ACI, when orchestration isn’t needed.

Check Your Understanding

  1. Take a simple web API you’ve built before. Which responsibilities would you prefer Azure to manage, and which would you still want to control yourself?
  2. Explain (in your own words) why containers are considered “portable,” and what exactly is being made portable.
  3. List two requirements that would push you toward a virtual machine instead of a managed web app platform.
  4. Describe a situation where running containers without Kubernetes makes sense, and why orchestration would be unnecessary overhead.
  5. For each hosting option (web apps, containers, VMs), write one sentence that starts with: “I would choose this when…”

Further Reading