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.