Azure offers many ways to host your application code. The term compute refers to the hosting model for the resources that your application runs on. This article helps choose a compute service for your application.
Choose a candidate service
Use the following flowchart to select a candidate compute service.
This diagram refers to two migration strategies:
- Lift and shift: A strategy for migrating a workload to the cloud without redesigning the application or making code changes. It's also called rehosting. For more information, see Azure migration and modernization center.
- Cloud optimized: 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 your starting point. Next, evaluate the service to see if it meets your needs.
This article includes several tables that can help you choose a service. The initial candidate from the flowchart might be unsuitable for your application or workload. In that case, expand your analysis to include other compute services.
If your application consists of multiple workloads, evaluate each workload separately. A complete solution can incorporate two or more compute services.
Understand the basic features
If you're not familiar with the Azure service selected in the previous section, see this overview documentation:
- Azure Virtual Machines: A service where you deploy and manage virtual machines (VMs) inside an Azure virtual network.
- Azure App Service: A managed service for hosting web apps, mobile app back ends, RESTful APIs, or automated business processes.
- Azure Functions: A managed function as a service.
- Azure Kubernetes Service (AKS): A managed Kubernetes service for running containerized applications.
- Azure Container Apps: A managed service built on Kubernetes, which simplifies the deployment of containerized applications in a serverless environment.
- Azure Container Instances: This service is a fast and simple way to run a container in Azure. You don't have to provision any VMs or adopt a higher-level service.
- Azure Red Hat OpenShift: A fully managed OpenShift cluster for running containers in production with Kubernetes.
- Azure Spring Apps: A managed service designed and optimized for hosting Spring Boot apps.
- Azure Service Fabric: A distributed systems platform that can run in many environments, including Azure or on-premises.
- Azure Batch: A managed service for running large-scale parallel and high-performance computing (HPC) applications.
Understand the hosting models
For hosting models, cloud services fall into three categories:
Infrastructure as a service (IaaS): Lets you provision VMs along with the associated networking and storage components. Then you can deploy whatever software and applications you want onto those VMs. This model is the closest to a traditional on-premises environment. Microsoft manages the infrastructure. You still manage the 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 and Azure Container Apps are PaaS services.
Functions as a service (FaaS): Lets you deploy your code to the service, which automatically runs it. Azure Functions is a FaaS service.
Azure Functions is an Azure serverless compute offering. To see how this service compares with other Azure serverless offerings, such as Logic Apps, which provides serverless workflows, see Choose the right integration and automation services in Azure.
There's a spectrum from IaaS to pure PaaS. For example, Azure VMs can automatically scale by using virtual machine scale sets. This capability isn't strictly a PaaS, but it's the type of management feature found in PaaS.
There's 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 falls somewhere in between.
|Service||Application composition||Density||Minimum number of nodes||State management||Web hosting|
|Azure Virtual Machines||Agnostic||Agnostic||1 2||Stateless or stateful||Agnostic|
|Azure App Service||Applications, containers||Multiple apps per instance by using App Service plan||1||Stateless||Built in|
|Azure Functions||Functions, containers||Serverless 1||Serverless 1||Stateless or stateful 6||Not applicable|
|Azure Kubernetes Service||Containers||Multiple containers per node||3 3||Stateless or stateful||Agnostic|
|Azure Container Apps||Containers||Serverless||Serverless||Stateless or stateful||Agnostic|
|Azure Container Instances||Containers||No dedicated instances||No dedicated nodes||Stateless||Agnostic|
|Azure Red Hat OpenShift||Containers||Multiple containers per node||6 5||Stateless or stateful||Agnostic|
|Azure Spring Apps||Applications, microservices||Multiple apps per service instance||2||Stateless||Built in|
|Azure Service Fabric||Services, guest executables, containers||Multiple services per VM||5 3||Stateless or stateful||Agnostic|
|Azure Batch||Scheduled jobs||Multiple apps per VM||1 4||Stateless||No|
- If you're using a Consumption plan. For an App Service plan, functions run on the VMs allocated for your App Service plan. See Choose the correct service plan for Azure Functions.
- Higher service-level agreement (SLA) with two or more instances.
- Recommended for production environments.
- Can scale down to zero after job completes.
- Three for primary nodes and three for worker nodes.
- When using Durable Functions.
|Service||Virtual network integration||Hybrid connectivity|
|Azure Virtual Machines||Supported||Supported|
|Azure App Service||Supported 1||Supported 2|
|Azure Functions||Supported 1||Supported 3|
|Azure Kubernetes Service||Supported||Supported|
|Azure Container Apps||Supported||Supported|
|Azure Container Instances||Supported||Supported|
|Azure Red Hat OpenShift||Supported||Supported|
|Azure Spring Apps||Supported||Supported|
|Azure Service Fabric||Supported||Supported|
- Requires App Service Environment.
- Use Azure App Service Hybrid Connections.
- Requires App Service plan or Azure Functions Premium plan.
|Service||Local debugging||Programming model||Application update|
|Azure Virtual Machines||Agnostic||Agnostic||No built-in support|
|Azure App Service||IIS Express, others 1||Web and API applications, WebJobs for background tasks||Deployment slots|
|Azure Functions||Visual Studio or Azure Functions CLI||Serverless, event-driven||Deployment slots|
|Azure Kubernetes Service||Minikube, Docker, others||Agnostic||Rolling update|
|Azure Container Apps||Local container runtime||Agnostic||Revision management|
|Azure Container Instances||Local container runtime||Agnostic||Not applicable|
|Azure Red Hat OpenShift||Minikube, Docker, others||Agnostic||Rolling update|
|Azure Spring Apps||Visual Studio Code, Intellij, Eclipse||Spring Boot, Steeltoe||Rolling upgrade, blue-green deployment|
|Azure Service Fabric||Local node cluster||Guest executable, Service model, Actor model, Containers||Rolling upgrade (per service)|
|Azure Batch||Not supported||Command-line application||Not applicable|
- Options include IIS Express for ASP.NET or node.js (iisnode), PHP web server, Azure Toolkit for IntelliJ, and Azure Toolkit for Eclipse. App Service also supports remote debugging of deployed web app.
|Service||Autoscaling||Load balancer||Scale limit3|
|Azure Virtual Machines||Virtual machine scale sets||Azure Load Balancer||Platform image: 1,000 nodes per scale set, Custom image: 600 nodes per scale set|
|Azure App Service||Built-in service||Integrated||30 instances, 100 with App Service Environment|
|Azure Functions||Built-in service||Integrated||200 instances per function app|
|Azure Kubernetes Service||Pod autoscaling1, cluster autoscaling2||Azure Load Balancer or Azure Application Gateway||5,000 nodes when using Uptime SLA|
|Azure Container Apps||Scaling rules4||Integrated||5 environments per region, 20 container apps per environment, 30 replicas per container app|
|Azure Container Instances||Not supported||No built-in support||20 container groups per subscription (default limit)|
|Azure Red Hat OpenShift||Pod autoscaling, cluster autoscaling||Azure Load Balancer or Azure Application Gateway||60 nodes per cluster (default limit)|
|Azure Spring Apps||Built-in service||Integrated||500 app instances in Standard|
|Azure Service Fabric||Virtual machine scale sets||Azure Load Balancer||100 nodes per virtual machine scale set|
|Azure Batch||Not applicable||Azure Load Balancer||20 core limit (default limit)|
- See Autoscale pods.
- See Automatically scale a cluster to meet application demands on Azure Kubernetes Service.
- See Azure subscription and service limits, quotas, and constraints.
- See Set scaling rules in Azure Container Apps.
|Azure Virtual Machines||SLA for Virtual Machines||Azure Traffic Manager, Azure Front Door, and cross-region Azure Load Balancer|
|Azure App Service||SLA for App Service||Azure Traffic Manager and Azure Front Door|
|Azure Functions||SLA for Functions||Azure Traffic Manager and Azure Front Door|
|Azure Kubernetes Service||SLA for AKS||Azure Traffic Manager, Azure Front Door, and Multiregion Cluster|
|Azure Container Apps||SLA for Container Apps||Azure Traffic Manager and Azure Front Door|
|Azure Container Instances||SLA for Container Instances||Azure Traffic Manager and Azure Front Door|
|Azure Red Hat OpenShift||SLA for Azure Red Hat OpenShift||Azure Traffic Manager and Azure Front Door|
|Azure Spring Apps||SLA for Azure Spring Apps||Azure Traffic Manager, Azure Front Door, and Multiregion Cluster|
|Azure Service Fabric||SLA for Service Fabric||Azure Traffic Manager, Azure Front Door, and cross-region Azure Load Balancer|
|Azure Batch||SLA for Batch||Not applicable|
For guided learning on service guarantees, see Core Cloud Services - Azure architecture and service guarantees.
Review and understand the available security controls and visibility for each service:
- Azure Windows virtual machine
- Azure Linux virtual machine
- Azure App Service
- Azure Functions
- Azure Kubernetes Service
- Azure Container Instances
- Azure Spring Apps
- Azure Service Fabric
- Azure Batch
|Service||TLS||Cost||Suitable architecture styles|
|Azure Virtual Machines||Configured in VM||Windows, Linux||N-tier, big compute (HPC)|
|Azure App Service||Supported||App Service pricing||Web-queue-worker|
|Azure Functions||Supported||Functions pricing||Microservices, event-driven architecture|
|Azure Kubernetes Service||Ingress controller||AKS pricing||Microservices, event-driven architecture|
|Azure Container Apps||Ingress controller||Container Apps pricing||Microservices, event-driven architecture|
|Azure Container Instances||Use sidecar container||Container Instances pricing||Microservices, task automation, batch jobs|
|Azure Red Hat OpenShift||Supported||Azure Red Hat OpenShift pricing||Microservices, event-driven architecture|
|Azure Spring Apps||Supported||Azure Spring Apps pricing||Spring Boot, microservices|
|Azure Service Fabric||Supported||Service Fabric pricing||Microservices, event-driven architecture|
|Azure Batch||Supported||Batch pricing||Big compute (HPC)|
Consider limits and cost
Along with the previous comparison tables, do a more detailed evaluation of the following aspects of the candidate service:
This article is maintained by Microsoft. It was originally written by the following contributors:
- Ayobami Ayodeji | Senior Program Manager
- Jelle Druyts | Principal Service Engineer
- Martin Gjoshevski | Senior Service Engineer
- Phil Huang | Senior Cloud Solution Architect
- Julie Ng | Senior Service Engineer
- Paolo Salvatori | Principal Service Engineer
To see nonpublic LinkedIn profiles, sign in to LinkedIn.
Core Cloud Services - Azure compute options. This Learn module explores how compute services can solve common business needs.