Academmia

Compare Compute Types: Virtual Machines, Containers, and Functions

az-900•mixed•

Azure architecture and services

Compare Compute Types: Virtual Machines, Containers, and Functions

Short Summary

In this lesson, you’ll compare three common Azure compute models: virtual machines, containers, and serverless functions. You’ll learn what you control in each model, what Azure manages for you, and when each option is a natural fit. You’ll also see how scaling and billing tend to differ so you can pick the right tool for a workload.

Learning Objectives

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

  • Define Azure Virtual Machines (VMs), containers, and Azure Functions in simple terms.
  • Differentiate these compute types by control level and operational responsibility.
  • Contrast typical scaling behavior across VMs, containers, and functions.
  • Select an appropriate compute type for common workload descriptions.
  • Recognize common misconceptions that lead to the wrong compute choice.

Core Concepts

What “compute” means

Compute is where my application code runs. Azure offers multiple compute types because workloads need different trade-offs: deep control vs. simpler operations, always-on services vs. on-demand execution, and predictable capacity vs. bursty event-driven work.

Virtual machines (VMs)

Azure Virtual Machines (VMs) are like renting a server in the cloud.

  • A VM includes a guest operating system (guest OS) (for example, Linux or Windows).
  • I manage OS-level configuration, installed software, and (in most cases) patching and maintenance.
  • VMs are a strong fit for “lift-and-shift” moves of existing server-based apps or when I need OS-level control.

A VM aligns with Infrastructure as a Service (IaaS): I get a lot of control, but I also take on more responsibility.

Containers

Containers package an application and its dependencies into a lightweight unit that runs on a host operating system (host OS).

  • Containers usually share the host OS kernel instead of shipping a full guest OS per application.
  • That typically means quicker start-up and higher density compared to running one full OS per workload.
  • Containers are a strong fit when I want consistent packaging (“it runs the same everywhere”) and faster scale-out than managing many separate VMs.

In Azure, I can run containers using services like Azure Container Instances (ACI), but “containers” is the packaging model, not a single Azure product.

Azure Functions (serverless functions)

Azure Functions are a serverless compute option for running code in response to triggers.

  • Serverless means I focus on my code and configuration, while Azure handles the underlying infrastructure and runtime hosting.
  • Functions are commonly event-driven: a trigger (like a timer, a message, or an HTTP (Hypertext Transfer Protocol) request) causes code to run.
  • This is a great fit for short, discrete pieces of work that run only when needed.

Comparing responsibility, scaling, and billing

A quick mental model:

  • Control

    • Highest control: VMs (full guest OS control)
    • Medium control: containers (app-focused packaging; host details depend on where they run)
    • Lowest control: functions (code + config; platform is managed)

  • Operational responsibility

    • VMs: I typically handle OS patching and maintenance.
    • Containers: “who patches what” depends on where containers run (for example, containers on VMs I manage still means I patch the host OS).
    • Functions: Azure handles much more of the platform work.

  • Scaling style

    • VMs: often scale by adding/removing VM instances (more deliberate, more setup).
    • Containers: often scale out quickly with more instances of the same image.
    • Functions: often scale based on incoming events (how it scales depends on the hosting plan and trigger type).

  • Billing (typical patterns)

    • VMs: commonly billed by provisioned capacity and time (plus storage/networking).
    • Functions: often billed by executions and resource usage on consumption-style plans, or by reserved capacity on other plans.
    • Containers: billing depends on the container service (often based on allocated Central Processing Unit (CPU) and memory over time).

Practical Understanding

Practical Situation 1: When you need OS-level control, think “VM”

You’re migrating an older application that depends on a specific OS version and needs low-level configuration (for example, system settings or special installers). You can’t treat it as “just code.”

How to think about it: This is a VM-shaped problem because you need control over the guest OS and the environment. A VM gives you the closest match to a traditional server while still running in Azure.

Common misunderstanding: “Containers are always better because they’re lighter.” If you truly need OS-level control, a container is often the wrong tool.

Practical Situation 2: When the app is already containerized, think “containers”

Your team already has a container image for the app, and you want portability between environments and faster repeatable deployments. You don’t want to manage a separate VM for each small service.

How to think about it: Containers are designed for this: package once, run consistently, scale out with more instances of the same image. In Azure, a managed container service can reduce how much server work you need to do.

Common misunderstanding: “Containers remove all operations work automatically.” If containers run on VMs you manage, you still own host OS patching and maintenance.

Practical Situation 3: When work happens on events, think “Functions”

A file is uploaded and you need to run code only when a new file arrives—generate a thumbnail, transform data, or send a notification. Nothing needs to run between events.

How to think about it: This is a classic serverless fit. Azure Functions are built to react to triggers (for example, a storage event, a queue message, a timer, or an HTTP request) and run code on demand.

Common misunderstanding: “Functions are a general replacement for web servers.” Functions can serve HTTP requests, but many workloads need steady, always-on behavior.

Practical Situation 4: When the service must stay running, think “VMs or long-running containers”

You need a web server or an API that must be continuously available and run for long periods. It’s not “run briefly and stop”; it’s a steady service.

How to think about it: Long-running services are typically hosted on VMs or container hosting designed for always-on services. Pick VMs when you need OS-level control; pick containers when you want an application-focused packaging model and easier scale patterns.

Common misunderstanding: “An HTTP endpoint means Functions is always the best fit.” An endpoint can be event-driven or always-on; the runtime behavior matters more than the protocol.

Common Pitfalls

  • Mistake: Confusing containers with VMs and assuming containers include a full OS. Correction: Containers usually share the host OS kernel; VMs include a guest OS per VM.

  • Mistake: Treating Azure Functions as suitable for any workload, including constantly running services. Correction: Functions are designed for on-demand, trigger-based execution; steady always-on services often fit VMs or long-running container hosting better.

  • Mistake: Assuming all compute types share the same billing model. Correction: VMs commonly map to capacity-and-time billing, Functions may be execution-based or capacity-based depending on plan, and container billing depends on the container service.

  • Mistake: Believing there is a “one-size-fits-all” compute choice. Correction: Choose based on requirements: OS control (VM), packaging/portability (containers), event-driven work with minimal server management (Functions).

  • Mistake: Forgetting management responsibilities (especially OS patching). Correction: If I manage VMs (or containers on VMs I manage), I own OS patching; serverless and more managed services reduce that responsibility.

Check Your Understanding

  • Describe, in your own words, what you “get control over” with a VM that you usually don’t control with Functions.
  • Explain why containers often start sooner than VMs without using the word “faster.”
  • Write a short workload description (2–3 sentences) that clearly fits Azure Functions, and name the trigger that starts it.
  • Think about an app you’ve worked on: which parts are “always-on service,” and which parts are “run only when triggered”? Map each part to a compute type and explain why.
  • List two questions you should ask before choosing between containers and VMs for hosting a web API.

Further Reading