Azure has enough compute services that the wrong question can make the design harder than it needs to be. Asking \u201cShould we use Kubernetes?\u201d or \u201cCan this run on virtual machines?\u201d starts with a product. A better architecture starts with workload characteristics: operating-system control, application shape, scaling pattern, deployment model, state, networking, compliance, and the amount of platform management the team is prepared to own.<\/p>\n
That decision process sits squarely inside AZ-305<\/a>. Microsoft\u2019s current Azure Architecture Center still frames compute selection as a technology-choice exercise across virtual machines, App Service, Azure Functions, Azure Kubernetes Service, Azure Container Apps, Container Instances, Batch, and other options. The objective is not to find the most advanced platform. It is to choose the least operationally expensive platform that still satisfies the workload\u2019s real constraints.<\/p>\n The first question is how much of the operating environment the application genuinely needs to control. Azure virtual machines provide maximum control over the guest operating system, installed software, agents, drivers, and network behavior. That control is necessary for some legacy products, specialized middleware, or migration scenarios. It also means the team owns patching, hardening, capacity management, and more of the availability design.<\/p>\n Platform services remove parts of that responsibility. App Service abstracts the operating system for web and API workloads. Azure Functions goes further for event-driven execution. Container Apps provides a managed container application environment without requiring teams to administer Kubernetes directly. AKS keeps Kubernetes as the orchestration model while offloading the control plane to Azure, but the workload team still owns substantial cluster and application operations.<\/p>\n This is the practical distinction behind virtual machines and containers<\/a>. Packaging an application in a container changes deployment and isolation, but it does not automatically tell you whether you should operate a Kubernetes cluster, use a managed container platform, or stay on VMs.<\/p>\n Migration strategy can influence the first compute choice. A legacy application might move to Azure VMs because that preserves compatibility and shortens migration risk, even if the long-term target is a managed platform. Architecture records should distinguish \u201cmigration landing point\u201d from \u201cstrategic runtime\u201d so that a temporary IaaS decision does not become permanent by default.<\/p>\n A conventional web application with predictable HTTP traffic often fits App Service well because deployment, TLS integration, scaling, and platform maintenance are built into the service. An event-driven function that runs briefly when a message arrives may fit Azure Functions. A containerized API composed of independently deployable services might fit Container Apps or AKS depending on its orchestration requirements.<\/p>\n Batch and high-performance computing workloads have different needs. They may care more about scheduling large pools of compute, specialized hardware, or job throughput than about serving interactive web traffic. A database appliance or vendor product may require VM-level control because the support model assumes a specific operating-system environment.<\/p>\n Do not let a shared programming language hide those differences. Two applications written in .NET can have completely different operational shapes. Compute selection should follow runtime behavior and support requirements, not the development stack alone.<\/p>\n Licensing is another constraint that can favor or eliminate a compute option. Commercial software may be licensed by core, host, or operating-system instance and may not support containers or serverless execution. Verify vendor support before redesigning around a platform model that the software supplier will not certify.<\/p>\n Every layer Azure manages is a layer the workload team does not have to patch, monitor, or recover manually. That is a strong reason to prefer managed services when they meet the workload. Platform abstraction can reduce toil, standardize deployment, and narrow the number of configuration decisions that can drift over time.<\/p>\n The tradeoff is constraint. App Service has a defined hosting model. Functions has execution and scaling characteristics that differ from a long-running service. Container Apps abstracts cluster infrastructure, which is helpful until the workload needs a Kubernetes-specific capability the platform does not expose. Architecture should therefore evaluate whether a managed service\u2019s boundaries are compatible with the application before treating abstraction as an unconditional benefit.<\/p>\n The cloud advantage is not simply moving servers to someone else\u2019s datacenter. The broader Azure cloud model<\/a> becomes more valuable when teams use managed capabilities deliberately and reduce undifferentiated infrastructure work.<\/p>\n Team capability is part of the decision. A platform that requires specialized skills creates incident-response and upgrade obligations even when the application is simple. If only one engineer can operate the chosen runtime, the compute architecture has an availability risk that will never appear in an Azure SLA. Prefer platforms that match the organization\u2019s operating maturity or fund the capability required to run them.<\/p>\n AKS is appropriate when the application or operating model genuinely needs Kubernetes: rich scheduling, Kubernetes-native tooling, cluster-level extensibility, sophisticated service meshes, custom controllers, portability requirements, or a platform engineering model built around Kubernetes APIs. Those capabilities can be powerful at enterprise scale.<\/p>\n They also create operational responsibility. Teams still need to design node pools, upgrade strategy, networking, ingress, identity, observability, workload security, autoscaling, policy, and cost management. Using AKS for a small set of straightforward stateless APIs can create more platform than the application needs.<\/p>\n Container Apps should be considered when the team wants container portability, revisions, scaling, and microservice patterns without managing a general-purpose Kubernetes environment. Understanding pods and containers<\/a> helps clarify why a container image is only the packaging unit; the orchestration layer is a separate design decision.<\/p>\n Container orchestration also affects release design. AKS and Container Apps both support progressive deployment patterns, but the tools and operational controls differ. If the organization already has Kubernetes policy, observability, service-mesh, and GitOps standards, AKS may integrate naturally. If not, managed revisions and environment-level controls can make Container Apps easier to govern.<\/p>\n Azure Functions is a strong fit when work starts from events such as messages, timers, HTTP requests, storage changes, or event streams and when each unit of work can be executed independently. Consumption-oriented scaling can align cost closely with activity, and the platform can handle rapid changes in demand without a permanently provisioned server fleet.<\/p>\n Serverless can be a poor fit for workloads that need long-lived processes, tight control over local state, unusual networking requirements, or predictable always-on compute where another pricing model is simpler. The architecture should also consider cold-start sensitivity, concurrency, downstream throttling, and whether burst scaling could overload a database or external dependency.<\/p>\n The right pattern often combines services. Functions can process asynchronous events while a web application runs on App Service and a specialized worker runs in a container. Enterprise architecture does not require every component to share the same compute platform.<\/p>\n Serverless cost models deserve explicit testing. Consumption pricing can be excellent for intermittent workloads but less attractive for continuously busy processes. Premium or dedicated plans can change the economics and remove some cold-start concerns. Model expected execution duration, concurrency, memory, and network dependencies rather than assuming \u201cserverless\u201d automatically means cheaper.<\/p>\n Compute is inseparable from availability design. VMs might require availability zones, scale sets, load balancers, patch orchestration, and explicit health management. Managed platforms often provide built-in redundancy features, but architects still need to understand how instances are distributed, how scaling works, and what happens during a regional fault.<\/p>\n Autoscaling is useful only when the application can scale horizontally and its downstream systems can keep up. A stateless API can often add instances easily. A stateful legacy application with local session data may require architecture changes before adding more servers is safe. Moving to a scalable platform without fixing state management simply relocates the bottleneck.<\/p>\nBegin with the control boundary<\/h3>\n
Match the service to the application shape<\/h3>\n
Use managed platforms when their constraints are acceptable<\/h3>\n
Choose AKS only when Kubernetes requirements justify it<\/h3>\n
Serverless works best when execution is naturally event-driven<\/h3>\n
Availability and scaling should influence compute choice early<\/h3>\n