Context

Azure Cloud gives us a variety of possible hosting options to run our IT workloads.  One of our customers recently asked us to create a decision tree to determine the correct Azure hosting solution based on a few well-defined decision criteria important for the organization. The decision tree guides the solution architect or infrastructure architect in which compute solution is a good fit for hosting a certain workload on Azure cloud.

Note:

• This decision tree is indicative and should be created based on the requirements, culture, size and budget applicable in your organization.
• As a starting point, we started with the “Azure Compute Decision Tree” and tweaked it to our own needs.

Selection/Decision Criteria

It is important to list all the criteria, important for your organization to decide upon a compute solution and give proper weights to it. These criteria and the importance of it depend typically on your IT strategy, culture, budget…etc. Some criteria in making a decision could be:

• Portability: Are workloads easy portable between cloud vendors or other hosting solutions of the same cloud vendor.
• Flexibility: Is fine-tuning of system settings possible? To what extend can we control the infrastructure?
• Network security: What are the possibilities to secure the network. Can we run the workload in our own isolated Azure Virtual Network (VNET)? Is IP filtering possible? And is this possible at a reasonable cost.
• Deployment: Is it easy to integrate the solution in automated deployment pipelines?
• Business models: Dedicated resource tiers vs consumption-based pricing tiers.
• Operational Model: Going from a highly-operational-intensive model, where you are responsible for patching, monitoring and upgrading to a NoOps model.
• Scalability:  Does the solution supports autoscaling? How easily can we scale our workloads?

Hosting Options

We identified the following Azure cloud hosting solutions all having their own advantages and disadvantages:

VMs (IaaS)

In this cloud compute model, you need to provision your own virtual machines on hardware provided by the cloud provider. It gives you maximum flexibility in configuring your setup. You can choose between an infinite list of infrastructure- (e.g. if you need to have GPUs for running your workloads…) and OS configurations (e.g. Windows 2016 server). The technology is also similar as on-premise servers which facilitates a lift-and-shift approach where you move your existing on-premise workloads to the cloud.

On the other side, this compute model is, depending on your type of workloads, a pricy model since you are responsible for operational expenses like patching and monitoring. And if you need to isolate your workloads, which is a common habit, you need to run them on different virtual machines increasing costs even further.

Some workloads also tend to fluctuate in load or have abrupt unforeseen peak loads in which they need to scale fast. Although a certain level of scalability is possible to achieve using network techniques like Load Balancers and Virtual Machine Scale Sets, this is not foreseen out of the box and relatively cumbersome to set up.

AKS (K8SaaS)

Azure Kubernetes Service (AKS) is the managed container orchestration platform of Azure based on the open-source container orchestration platform Kubernetes. The service allows you to run your cloud native applications in a feature rich container environment managed by Azure and takes advantage of the scalability features of Kubernetes. You can isolate your workloads in the cluster to a certain extent by defining network security rules and resource quotas for each workload, optimizing resource utilization of your worker nodes and thus optimizing costs. As Kubernetes is the standard for running containers, it has a rich ecosystem of tools, frameworks and has excellent language support!

Although the service is managed by Azure, we have a great amount of flexibility to choose the infrastructure and the network topology we need. You can deploy Azure AKS easily into your own virtual network (VNET) and protect it with Azure network security tools like NSG’s and Azure Firewall.

Today, Azure AKS is still a free service where you only need to pay for the worker nodes hosting your workloads the service itself (the Management Plane) is free of charge.

All these nice advantages come with a big downside.  Hosting a cluster, even if it is managed by Azure, requires a certain level of expertise and sufficient Kubernetes knowledge. Things will go wrong without a doubt, and you need to manage these issues fast and smoothly. Both your operation- and your development teams should be trained to handle this increased complexity and new way of delivering applications.

Additionally, often forgotten when choosing the right cluster size, a big chunk of your resources is reserved for Kubernetes and Azure system PODs (containters). Take this into account when planning your cluster.

APP Services (PaaS)

In this compute model you bring your application code and you just deploy it on the application runtime your cloud provider provides. You don’t need to care about the hardware, the Operating System, servers and the network.

This model has some very attractive advantages like auto-patching and auto-scalability. It has also some cheap tiers including a free tier, but consumption-based pricing is not available (you pay per compute unit: CPU + memory).

Although it is very useful for standalone workloads, but if you need to integrate your workload into an existing network and need to make use of VNET integration it will be very expensive.

APP Services Containers (cPaaS)

Azure APP Services for Containers is built upon the Azure APP Services infrastructure described above, with the difference that in this model we deploy containers. Both Windows as Linux containers are supported, and you can even deploy container groups = deploying multiple containers in one runtime to share the same host, network, storage and lifecycle. For example, you can run a web application in one container and a NGINX proxy server in another container providing additional services for your application container.

Again, since no consumption-based pricing is available and VNET integration is pricy, this solution is typically used for stand-alone, long-running workloads.

Azure Container Instances (cPaas)

Azure Container Instances (ACI) is the easiest way to run containers in Azure. It is a fully managed hosting environment for container workloads that er billed only for the time you use them (billing by the second)! There are significant cost savings for services that don’t require constant up-time charges at an always-on rate. It runs serverless compared to Azure Functions but without the high cost of VNET integration.

However, it lacks the features we have in APP Services for Containers (e.g. SSL offloading, monitoring, …etc) and automated deployments requires Azure ARM templates. At our current customer we only use them to run short-lived jobs.

Azure Functions (FaaS)

Azure Functions is the serverless platform of Microsoft Azure delivering event driven cloud computing to our development teams. Developers can author, publish and run snippets of their code (= functions) in the Azure cloud without managing web servers or containers.

The biggest advantage is the ability to scale automatically and even to zero instances if needed, saving compute costs. VNET integration is possible at a reasonable cost but then you have to pay for reserved resources (always-on).

Although warmup times are significantly improved over the years, extra latency is possible when scaling from zero to a running instance.  Functions are not portable to other cloud providers although this was not a showstopper at our customer to use Azure Functions.

The workloads are typically short-lived (there is a maximum run time limitation applied) and intended for event-driven use cases.

The Decision Tree

If we take all these advantages and disadvantages and we mix it with our IT strategy we can draw the following (simplified) decision tree for hosting our workloads on Azure:

Author: Bert Meuris