Choose an Azure compute service for your application

Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application.

If your application consists of multiple workloads, evaluate each workload separately. A complete solution may incorporate two or more compute services.

Choose a candidate service

Use the following flowchart to select a candidate compute service.

Decision tree for Azure compute services

Definitions:

  • "Lift and shift" is a strategy for migrating a workload to the cloud without redesigning the application or making code changes. Also called rehosting. For more information, see Azure migration center.
  • Cloud optimized is a strategy for migrating to the cloud by refactoring an application to take advantage of cloud-native features and capabilities.

The output from this flowchart is a starting point for consideration. Next, perform a more detailed evaluation of the service to see if it meets your needs.

Understand the basic features

If you're not familiar with the Azure service selected in the previous step, read the overview documentation to understand the basics of the service.

  • App Service. A managed service for hosting web apps, mobile app back ends, RESTful APIs, or automated business processes.
  • Azure Kubernetes Service (AKS). A managed Kubernetes service for running containerized applications.
  • Batch. A managed service for running large-scale parallel and high-performance computing (HPC) applications
  • Container Instances. The fastest and simplest way to run a container in Azure, without having to provision any virtual machines and without having to adopt a higher-level service.
  • Functions. A managed FaaS service.
  • Service Fabric. A distributed systems platform that can run in many environments, including Azure or on premises.
  • Virtual machines. Deploy and manage VMs inside an Azure virtual network.

Understand the hosting models

Cloud services, including Azure services, generally fall into three categories: IaaS, PaaS, or FaaS. (There is also SaaS, software-as-a-service, which is out of scope for this article.) It's useful to understand the differences.

Infrastructure-as-a-Service (IaaS) lets you provision individual VMs along with the associated networking and storage components. Then you deploy whatever software and applications you want onto those VMs. This model is the closest to a traditional on-premises environment, except that Microsoft manages the infrastructure. You still manage the individual VMs.

Platform-as-a-Service (PaaS) provides a managed hosting environment, where you can deploy your application without needing to manage VMs or networking resources. Azure App Service is a PaaS service.

Functions-as-a-Service (FaaS) goes even further in removing the need to worry about the hosting environment. In a FaaS model, you simply deploy your code and the service automatically runs it. Azure Functions are a FaaS service.

There is a spectrum from IaaS to pure PaaS. For example, Azure VMs can autoscale by using virtual machine scale sets. This automatic scaling capability isn't strictly PaaS, but it's the type of management feature found in PaaS services.

In general, there is a tradeoff between control and ease of management. IaaS gives the most control, flexibility, and portability, but you have to provision, configure and manage the VMs and network components you create. FaaS services automatically manage nearly all aspects of running an application. PaaS services fall somewhere in between.

Consider limits and cost

Next, perform a more detailed evaluation, looking at the following aspects of the service:

Based on this analysis, you may find that the initial candidate isn't suitable for your particular application or workload. In that case, expand your analysis to include other compute services.

The following tables contain additional comparison points, which may be useful when choosing.

Hosting model

Criteria Virtual Machines App Service Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Application composition Agnostic Applications, containers Services, guest executables, containers Functions Containers Containers Scheduled jobs
Density Agnostic Multiple apps per instance via app service plans Multiple services per VM Serverless 1 Multiple containers per node No dedicated instances Multiple apps per VM
Minimum number of nodes 1 2 1 5 3 Serverless 1 3 3 No dedicated nodes 1 4
State management Stateless or Stateful Stateless Stateless or stateful Stateless Stateless or Stateful Stateless Stateless
Web hosting Agnostic Built in Agnostic Not applicable Agnostic Agnostic No
Can be deployed to dedicated VNet? Supported Supported5 Supported Supported 5 Supported Not supported Supported
Hybrid connectivity Supported Supported 6 Supported Supported 7 Supported Not supported Supported

Notes

  1. If using Consumption plan. If using App Service plan, functions run on the VMs allocated for your App Service plan. See Choose the correct service plan for Azure Functions.
  2. Higher SLA with two or more instances.
  3. Recommended for production environments.
  4. Can scale down to zero after job completes.
  5. Requires App Service Environment (ASE).
  6. Use Azure App Service Hybrid Connections.
  7. Requires App Service plan.

DevOps

Criteria Virtual Machines App Service Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Local debugging Agnostic IIS Express, others 1 Local node cluster Visual Studio or Azure Functions CLI Minikube, others Local container runtime Not supported
Programming model Agnostic Web and API applications, WebJobs for background tasks Guest executable, Service model, Actor model, Containers Functions with triggers Agnostic Agnostic Command line application
Application update No built-in support Deployment slots Rolling upgrade (per service) Deployment slots Rolling update Not applicable

Notes

  1. Options include IIS Express for ASP.NET or node.js (iisnode); PHP web server; Azure Toolkit for IntelliJ, Azure Toolkit for Eclipse. App Service also supports remote debugging of deployed web app.
  2. See Resource Manager providers, regions, API versions and schemas.

Scalability

Criteria Virtual Machines App Service Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
Autoscaling Virtual machine scale sets Built-in service Virtual machine scale sets Built-in service Pod auto-scaling1, cluster auto-scaling2 Not supported N/A
Load balancer Azure Load Balancer Integrated Azure Load Balancer Integrated Azure Load Balancer or Application Gateway No built-in support Azure Load Balancer
Scale limit3 Platform image: 1000 nodes per scale set, Custom image: 600 nodes per scale set 20 instances, 100 with App Service Environment 100 nodes per scale set 200 instances per Function app 100 nodes per cluster (default limit) 20 container groups per subscription (default limit). 20 core limit (default limit).

Notes

  1. See Autoscale pods.
  2. See Automatically scale a cluster to meet application demands on Azure Kubernetes Service (AKS).
  3. See Azure subscription and service limits, quotas, and constraints.

Availability

Criteria Virtual Machines App Service Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
SLA SLA for Virtual Machines SLA for App Service SLA for Service Fabric SLA for Functions SLA for AKS SLA for Container Instances SLA for Azure Batch
Multi region failover Traffic manager Traffic manager Traffic manager, Multi-Region Cluster Not supported Traffic manager Not supported Not Supported

For guided learning on Service Guarantees, review Core Cloud Services - Azure architecture and service guarantees.

Other criteria

Criteria Virtual Machines App Service Service Fabric Azure Functions Azure Kubernetes Service Container Instances Azure Batch
SSL Configured in VM Supported Supported Supported Ingress controller Use sidecar container Supported
Cost Windows, Linux App Service pricing Service Fabric pricing Azure Functions pricing AKS pricing Container Instances pricing Azure Batch pricing
Suitable architecture styles N-Tier, Big compute (HPC) Web-Queue-Worker, N-Tier Microservices, Event-driven architecture Microservices, Event-driven architecture Microservices, Event-driven architecture Microservices, task automation, batch jobs Big compute (HPC)

The output from this flowchart is a starting point for consideration. Next, perform a more detailed evaluation of the service to see if it meets your needs.

Understand the basic features

If you're not familiar with the Azure service selected in the previous step, read one of the following overview articles:

Consider limits and cost

Next, perform a more detailed evaluation, looking at the following aspects of the service:

Based on this analysis, you may find that the initial candidate isn't suitable for your particular application or workload. In that case, expand your analysis to include other compute services.

Next steps