If workloads are to be set up in the Azure, there are various options. To make the choice easier, Microsoft provides the Compute Decision Guide (see picture above). It differentiates between Lift&Shift and Cloud Native and gives recommendations for individual services.

The Decision Guide is a good help for a first classification. However, it does not take sufficient account of the following points, which should be taken into account in a real transition or a new structure.

Hint 1: Not Driven by Requirements

The Decision Guide is primarily technology-driven, i.e. if it is a microservices architecture, Azure Functions, Container Instances or AKS is recommended. If it is not a microservice architecture, App Service is recommended.

However, the choice of technology should be based on the requirements. The guide does not take any requirements, i.e. if a non-microservice solution has to scale particularly well, an AKS or a service fabric can also be considered, for example. If the requirement is to be as cost-effective as possible, a reserved VM may be cheaper for a microservice solution than container instances.

The requirements should have the most important influence, the technological aspects should be considered afterwards.

Hint 2: No separation of Compute Workload

The guide appears to run through a single compute workload. Often users don’t understand that it has to be traversed multiple times for different workloads or parts of the same workload.

VMs often contain multiple workloads. For example, some of them require full control and should remain on a VM. Other workloads can be changed into functions or containers. As a result, the advantages of higher-quality services can be used and the VM with the old workload can be significantly smaller.

The separation also creates a decoupling that allows independent patching or further development. Different SLAs or scaling strategies could also be implemented.

Hint 3: Storage Missing

There is a separate Storage Decision Guide, which distinguishes, for example, whether it is a relational database and then it recommends SQL Database. Both guides are detached from each other and that fits in many cases.

However, storage and compute can be mutually dependent. A classic example would be a VM with SQL Server. If possible, this should be moved to the cloud as SQL PaaS. This move from VM to PaaS is completely missing. If the change to PaaS is not possible for reasons of compatibility, an SQL Managed Instance should be used. This option is not covered in this guide and not in the Storage Guide. If the managed instance cannot be used, the only option is to install the SQL server on a VM. This whole decision-making process is missing from this guide.

Hint 4: Services are Missing

This Compute Decision Guide covers many basic services and has been expanded and updated many times. However, some compute workloads can also be migrated to other Azure services or converted to the services mentioned for other reasons.

A typical example are backend jobs. These can be implemented with Azure Automation and Runbook, for example. Another possibility would be the implementation with Logic Apps. These two compute services are not mentioned in the Decision Guide.

In addition, backend jobs could also be implemented with container instances. However, the Decision Guide only provides this for event-driven workloads.

Hint 5: Full Control with VM only

In the branch Build new, the guide contains a reference to a VM if full control is required. Very often a solution based on containers can also be seen as full control. Everything can be freely defined/configured within the container. Only the dependency on the Docker version would be specified by Azure and is usually negligible due to the advantage of a managed Docker.

So before a VM is chosen for full control, an attempt should be made to implement the solution in a container. This means that there is no need to update the operating system later and patching is easy when the container is rebuilt.

Hint 6: Containerize with App Services is missing

The branch to App Services is only recommended if the architecture is not based on microservies. But managed runtimes can be made available with App Services, for example .NET, IIS or Tomcat.

A solution with Microsoervices does not necessarily have to run on Kubernetes or other orchestrators. Microservices often require a specific runtime (Java, .NET) and could also run directly on app services. Alternatively, app services also offer the option of including one or more containers. Another benefit is the scalability that comes with app services. For security, public access can be restricted with IP restrictions, VNet integration, or simple authentication.

A solution with 3 microservices can therefore be easily implemented with 3 app services. Each service can be scaled and deployed independently.

Hint 7: Service Fabric can do more

Service Fabric is recommended for old .NET applications or if Service Fabric know-how already exists. However, since Service Fabric can also orchestrate containers on both Windows and Linux nodes, it is its powerful tool.

It is a proprietary system from Microsoft that can be provisioned in Azure or OnPrem. It can run .NET assemblies directly, but can also run containers. There are libraries for Service Fabric to directly implement stateful or stateless services and resilience.

Service Fabric can also be used when full-fledged orchestration is required. At the same time, existing applications can be operated and it offers all the features for operation (Blue Green Deployment).

Hint 8: Keep an Eye on Preview Services

A new preview service is e.g. the container apps. On the one hand, preview services should not necessarily be used for productive environments, especially since they do not offer an SLA. On the other hand, the preview phases are not always long and the migrated workloads are often tested for their cloud capability before they go into regular operation.

It can therefore make sense to consider Preview Services. The workload may have to go through a test phase anyway or does not yet need productive operation. Preview services are also usually very stable and close the gaps of currently missing services. The rapid development of the cloud in particular should also have an influence on the selection of compute workloads.