Choosing Your Azure Deployment Model

You’re ready to start deploying and migrating applications into Microsoft’s Azure cloud platform — but there are four deployment models to contend with. Which should you choose? Each has strengths and weaknesses depending on the service you are setting up. Some might require more attention than others, but offer additional control. Others integrate services like load balancing or Operating Systems as more of a Platform as a Service.

Learn the differences between Azure Service Fabric, Azure Virtual Machines, Azure Containers, and Azure App Services, and when you might want to choose one over another. Green House Data is also ready to help you decide which of your business applications belong in which bucket — and we can help you administrate them, too.

Azure App Service

For native web apps, Azure App Service is likely your best choice, as it offers built-in features like load balancing and traffic managers. You don’t need to configure or install an operating system or antivirus — your app just runs and scales appropriately (scaling is dependent on the App Service you choose).

Azure App Services include Web Apps, Mobile Apps, Logic Apps, Azure Functions, and Azure Webjobs.

Web Apps are built for ASP.NET web applications and create web servers to run .NET, PHP, Pythos, Node.js, Java, and other common application types running under Windows or Linux. Mobile Apps are used as a backend for mobile applications, connecting via SDKs for IOs, Android, Windows, and Xamarin; they also have native integration for offline data sync and push notifications.

Logic Apps are not made to host applications; rather they are used to automate business practices via logif processes. A Trigger like a new message starts a queue workflow, which connects to third party APIs like Office 365 or your existing business apps. Unlike most of the other App Services, which require a monthly commitment, Logic Apps are only paid for when they run.

Azure Functions are small applications that generally only run intermittently or for short periods. You configure how and when they run, either from specific actions taken within your Azure environment or simply on a set schedule. They are used to automate and extend applications, process data, and integrate various systems. Order processing, file maintenance, and scheduled tasks are all good fits for Functions. Functions can be triggered by HTTP requests, timers, GitHub events, webhooks, databases, and Azure actions. They can also be paid for on a consumption plan, where they are only charged when they run.

WebJobs are similar to Functions, except they do not autoscale and they run inside a web or mobile application. They also run when triggered by a specific action or queue.

All App Services include simple authentication, help enable continuous delivery, connect to on-premise or cloud resources including apps and databases, can scale on demand, and use deployment slots that enable testing and migration to production without downtime.

Azure Service Fabric

The other primary Platform as a Service in Azure is Service Fabric, which is used by Microsoft for their own Azure SQL databases as well as the underlying PaaS for the App Services described above. Any application can run in Service Fabric, though the primary focus is on cloud-native microservices. It does not include authentication or deployment slots like App Services do, but you can run the Service Fabric on-premise or with another hosting provider as well as in the Azure cloud, making it a great fit for hybrid deployments.

Choose Service Fabric if you are creating a new application or re-architecting your existing apps to move to microservice architectures. Autoscaling, self-healing features, and load-balancing are built-in, start small and allow your app to scale. Support is included for WebAPI through Open Web Interface for .NET and ASP.NET Core.

You gain more granular control over the underlying infrastructure with Service Fabric compared to App Service, including remote access to servers and server startup configuration. However, you don’t need to worry about patching the OS or managing the virtual machine configurations.

Virtual Machines

Azure VMs are pure Infrastructure as a Service (IaaS) unlike Service Fabric and App Services, which are PaaS. They therefore do not include load balancing, antivirus protection, or auto-scaling features. While you must maintain those aspects of your VMs, you also gain more control over the server itself. It functions as the equivalent of a physical server, just hosted within Microsoft’s Azure pool.

Azure VMs are configured via server images that include everything within the server: configuration, operating system, and installed applications. You can download and work on images locally and then upload them to the Azure cloud.

PaaS applications can be instantly provisioned. An Azure VM can take minutes or even hours to configure and spin up. While they are the most complex to manage, they are the most customizable option.

Legacy applications that will not be redesigned for the cloud are an ideal fit for VMs. “Lifting and shifting” your existing images is also relatively easy to do with VMs. Consider VMs if you have highly custom VMs built in Windows or Linux that are complex. Generally speaking, VMs are the easiest migration path to the cloud, as you can use all the existing applications you run on-premise.

Azure Containers

Finally, Azure offers a container service. You may be familiar with the magic of containerization, in which an app can be easily migrated across various platforms and services. Windows Containers work with Azure, on-premise, in other virtual environments like VMware, on Amazon Web Services, you name it. Containers can also run in Azure VMs, container-specific Instances in Azure, and even Service Fabric or Web Apps for Containers.

Docker containers are supported, as are Windows containers. They are quicker than VMs to deploy and easily scaled, but you must handle the configuration and scaling yourself, similar to VMs. Container Instances or VMs will require you to orchestrate scaling and management yourself. Service Fabric includes an orchestrator.

You can usually modernize your applications more easily with containers than re-architecting for the web, packaging them by removing any dependencies that aren’t compatible with Docker and preparing for cloud devops practices.

In general, any new services and applications should be chosen or developed with cloud-native technologies like App Service or Service Fabric in mind. This makes things easier on your admins, as they can focus on services and applications rather than the underlying infrastructure.

If you have specific security requirements or need to move existing applications, using a container or pure IaaS VM might be the way to go. With a VM, it’s not just less work because you do not need to re-architect the app. There is also less to learn when deploying a VM, since it functions largely in the same manner as a physical server.

Depending on your environment, you may want to mix and match from these deployment models in order to gain the most advantages from the Azure cloud.