Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure provides 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 you choose a compute service for your application.
Architecture
Use the following flowchart to select a candidate compute service.
Download a Visio file of this architecture.
The previous 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 known as rehosting. For more information, see Azure cloud 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 that you select in the previous section, see the following overview documentation:
Azure App Service is a managed service for hosting web apps, mobile app back ends, RESTful APIs, or automated business processes.
Azure Batch is a managed service for running large-scale parallel and high-performance computing (HPC) applications.
Azure Container Apps is a managed service built on Kubernetes, which simplifies the deployment of containerized applications in a serverless environment.
Azure Container Instances is a service for running a single container or group of containers in Azure. Container Instances doesn't provide full container orchestration, but you can implement containers without having to provision virtual machines (VMs) or adopt a higher-level service.
Azure Functions is a service that provides managed functions that run based on a variety of trigger types for event-driven applications.
Azure Kubernetes Service (AKS) is a managed Kubernetes service for running containerized applications.
Azure Red Hat OpenShift is a fully managed OpenShift cluster for running containers in production with Kubernetes.
Azure Service Fabric is a distributed systems platform that can run in many environments, including Azure or on-premises.
Azure VMware Solution is a managed service for running VMware workloads natively on Azure.
Azure Virtual Machines is a service where you deploy and manage VMs inside an Azure virtual network.
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 any software and applications on those VMs. This model is the closest to a traditional on-premises environment. Microsoft manages the infrastructure, and you 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. App Service and 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.
Note
Azure Functions is an Azure serverless compute offering. To see how this service compares with other Azure serverless offerings, such as Azure Logic Apps for serverless workflows, see Choose the right integration and automation services in Azure.
There's a spectrum from IaaS to fully managed PaaS. For example, Azure VMs can automatically scale by using virtual machine scale sets. This capability isn't strictly PaaS, but it resembles the management features in PaaS.
There's a trade-off between control and ease of management. IaaS provides the most control, flexibility, and portability. However, you have to provision, configure, and manage the VMs and network components that you create. FaaS services automatically manage nearly all aspects of running an application. PaaS provides partial management while requiring some user configuration.
Service | Application composition | Density | Minimum number of nodes | State management | Web hosting |
---|---|---|---|---|---|
Virtual Machines | Agnostic | Agnostic | 1 2 | Stateless or stateful | Agnostic |
App Service | Applications, containers | Multiple apps for each instance by using App Service plan | 1 | Stateless | Built-in |
Azure Functions | Functions, containers | Serverless 1 | Serverless 1 | Stateless or stateful 6 | Not applicable |
AKS | Containers | Multiple containers for each node | 3 3 | Stateless or stateful | Agnostic |
Container Apps | Containers | Serverless | Serverless | Stateless or stateful | Agnostic |
Container Instances | Containers | No dedicated instances | No dedicated nodes | Stateless | Agnostic |
Azure Red Hat OpenShift | Containers | Multiple containers for each node | 6 5 | Stateless or stateful | Agnostic |
Service Fabric | Services, guest executables, containers | Multiple services for each VM | 5 3 | Stateless or stateful | Agnostic |
Batch | Scheduled jobs | Multiple apps for each VM | 1 4 | Stateless | No |
Azure VMware Solution | Agnostic | Agnostic | 3 7 | Stateless or stateful | Agnostic |
Notes:
1 For Azure Functions, the Consumption plan is serverless. For an App Service plan, functions run on the VMs allocated for that plan. Choose the correct service plan for Azure Functions.
2 Higher service-level agreement (SLA) that has two or more instances.
3 Recommended for production environments.
4 Can scale down to zero after the job completes.
5 Three primary nodes and three worker nodes.
6 When you use durable functions.
7 See Hosts.
Networking
Service | Virtual network integration | Hybrid connectivity |
---|---|---|
Virtual Machines | Supported | Supported |
App Service | Supported 1 | Supported 2 |
Azure Functions | Supported 1 | Supported 3 |
AKS | Supported | Supported |
Container Apps | Supported | Supported |
Container Instances | Supported | Supported |
Azure Red Hat OpenShift | Supported | Supported |
Service Fabric | Supported | Supported |
Batch | Supported | Supported |
Azure VMware Solution | Supported | Supported |
Notes:
1 Requires App Service Environment or a dedicated compute pricing tier.
2 Use App Service Hybrid Connections.
3 Requires an App Service plan or Azure Functions Premium plan.
DevOps
Service | Local debugging | Programming model | Application update |
---|---|---|---|
Virtual Machines | Agnostic | Agnostic | No built-in support |
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 |
AKS | Minikube, Docker, others | Agnostic | Rolling update |
Container Apps | Local container runtime | Agnostic | Revision management |
Container Instances | Local container runtime | Agnostic | Not applicable |
Azure Red Hat OpenShift | Minikube, Docker, others | Agnostic | Rolling update |
Service Fabric | Local node cluster | Guest executable, Service model, Actor model, containers | Rolling upgrade for each service |
Batch | Not supported | Command-line application | Not applicable |
Azure VMware Solution | Agnostic | Agnostic | No built-in support |
Note:
1 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 apps.
Scalability
Service | Autoscaling | Load balancer | Scale limit3 |
---|---|---|---|
Virtual Machines | Virtual machine scale sets | Azure Load Balancer | Platform image: 1,000 nodes for each scale set. Custom image: 600 nodes for each scale set. |
App Service | Built-in service | Integrated | 30 instances, 100 with App Service Environment |
Azure Functions | Built-in service | Integrated | 200 instances for each function app |
AKS | Pod autoscaling1, cluster autoscaling2 | Load Balancer or Azure Application Gateway | 5,000 nodes when you use uptime SLA |
Container Apps | Scaling rules4 | Integrated | 15 environments for each region (default limit), unlimited container apps for each environment and replicas for each container app (depending on available cores) |
Container Instances | Not supported | No built-in support | 100 container groups for each subscription (default limit) |
Azure Red Hat OpenShift | Pod autoscaling, cluster autoscaling | Load Balancer or Application Gateway | 250 nodes for each cluster (default limit) |
Service Fabric | Virtual machine scale sets | Load Balancer | 100 nodes for each virtual machine scale set |
Batch | Not applicable | Load Balancer | Core limit of 900 dedicated and 100 low-priority (default limit) |
Azure VMware Solution | Built-in service5 | Integrated6 | 3 to 16 VMware ESXi hosts per VMware vCenter |
Notes:
1 See Autoscale pods.
2 See Automatically scale a cluster to meet application demands on AKS.
3 See Azure subscription and service limits, quotas, and constraints
4 See Set scaling rules in Container Apps
5 See Scale Azure VMware Solution
6 See VMware NSX
Availability
Service | Multiregion failover option |
---|---|
Virtual Machines | Azure Traffic Manager, Azure Front Door, and cross-region Load Balancer |
App Service | Traffic Manager and Azure Front Door |
Azure Functions | Traffic Manager and Azure Front Door |
AKS | Traffic Manager, Azure Front Door, and Multiregion Cluster |
Container Apps | Traffic Manager and Azure Front Door |
Container Instances | Traffic Manager and Azure Front Door |
Azure Red Hat OpenShift | Traffic Manager and Azure Front Door |
Service Fabric | Traffic Manager, Azure Front Door, and cross-region Load Balancer |
Batch | Not applicable |
Azure VMware Solution | Not applicable |
For guided learning on service guarantees, see Azure architecture and service guarantees.
Security
Review and understand the available security controls and visibility for each of the following services:
- AKS
- App Service
- Azure Functions
- Virtual Machines for Linux
- Azure VMware Solution
- Virtual Machines for Windows
- Batch
- Container Apps
- Container Instances
- Service Fabric
Other criteria
Service | TLS | Cost | Suitable architecture styles |
---|---|---|---|
Virtual Machines | Configured in VM | Windows, Linux | N-tier, big compute (HPC) |
App Service | Supported | App Service pricing | Web-queue-worker |
Azure Functions | Supported | Azure Functions pricing | Microservices, event-driven architecture |
AKS | Ingress controller | AKS pricing | Microservices, event-driven architecture |
Container Apps | Ingress controller | Container Apps pricing | Microservices, event-driven architecture |
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 |
Service Fabric | Supported | Service Fabric pricing | Microservices, event-driven architecture |
Batch | Supported | Batch pricing | Big compute (HPC) |
Azure VMware Solution | Configured in VM | Azure VMware Solution pricing | VM workload based on VMware format |
Consider limits and cost
Along with the previous comparison tables, do a more detailed evaluation of the following aspects of the candidate service:
Contributors
Microsoft maintains this article. The following contributors wrote this article.
- 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.