Which Azure Deployment Model Should You Use?
Which Azure Deployment Model Should You Use?
This breakdown of Azure Service Fabric, VMs, containers, and Azure App Services considers each one's functionality and usefulness for cloud deployments.
Join the DZone community and get the full member experience.Join For Free
Microsoft Azure is a great platform to use, but how do you go about deploying your applications to the cloud and using them? There are several different options for deploying your applications in the Azure cloud and which one(s) you use and where you run them depends on the amount of control and portability you want to have. In this article, we will review the four primary Azure deployment models.
How to Run Your Applications in the Azure Cloud
Here are the four main ways to deploy your applications in Azure.
Azure Service Fabric
You can deploy your applications inside of Azure Service Fabric. This is the layer of ‘magic’ that has been powering services like Azure SQL Databases and App Services for years and is now available for you to use yourself. When I say that Service Fabric is a layer of magic, I mean that it provides capabilities that really seem magical. When you deploy your application in Azure Service Fabric, it becomes automatically load-balanced. It becomes self-healing. It scales automatically. It is highly available. And when you deploy a new version of your application, it is upgraded without downtime and you can revert the deployment. You get all of this out-of-the-box.
Typically, Azure Service Fabric is marketed to run a microservices architecture, which it is really good at. But you can also run anything else on Azure Service Fabric. You can run any executable in Service Fabric.
However, setting up service fabric and running your applications in it is not a trivial task. You really need to know what you are doing and that makes sense for the amount of magic that you get from it.
Also, Service Fabric only provides the capability to run applications. It doesn’t provide features like authentication and deployment slots, like Azure App Services does.
You can run the Service Fabric framework anywhere — on-premises, on your own computer, in Azure or in another cloud. It is not Azure specific.
When you need a lot of control, or when you are lifting and shifting applications to the cloud, you can run them in virtual machines. You can install everything that you need to run your application on a virtual machine. You can control everything from the OS to antivirus. This also means that you are responsible for those things. You need to make sure that your application stays available, performant, and secure. This is not an easy task, and it’s a tradeoff between control and responsibility.
Like VMs, you can use containers when you need a lot of control. They allow you to install whatever software you need to run your applications, and they are a lot faster to deploy than virtual machines. Think of containers as processes, where VMs are operating systems. Containers can spin up and start in seconds, which is useful if you want to spin one up for testing and then get rid of it.
You can run them on your own machine and anywhere else. This way, you can always be sure that the environment that you are working in is the same everywhere.
You can run containers in Azure in a lot of different services. Microsoft wants you to be able to eventually use containers for every scenario. You can run containers in Azure in Azure Container Service, Azure Container Instances, Azure Service Fabric, and Web App for Containers:
Azure Container Service is able to run and orchestrate containers on cloud resources, which enables you to easily scale. You can use Docker containers (and later Windows containers) and popular orchestrators like DC/OS, Docker Swarm, or Kubernetes with Azure Container Service.
Azure Container Instances is a more lightweight offering in Azure that allows you to run a container without any orchestration.
Azure Service Fabric also provides a place to run containers in the cloud. It comes with its own orchestrator, making it a competitor with orchestrators like DC/OS, Docker Swarm, and Kubernetes.
Web Apps for Containers allows you to use Linux-based containers to deploy your application into an Azure App Services web app. This way, you can make sure that the environment that you use locally is exactly the same as the one in the cloud.
This might help you to understand which Azure Service is suited for your container needs:
|Scale and orchestrate containers using Kubernetes, DC/OS or Docker Swarm||Azure Container Service|
|Easily run containers on Azure with a single command||Azure Container Instances|
|Develop microservices and orchestrate containers on Windows or Linux||Azure Service Fabric|
|Deploy web applications on Linux using containers||Web Apps for Containers|
Azure App Services
When you don’t need full control and want to focus on just building your application, you can run your application in Azure App Services. You can just deploy your application to App Services and it runs, no need to worry about the OS or antivirus. Some of the App Services even go as far as to take care of the scaling for you, as they are serverless.
There are several App Service types:
- Web apps for hosting your web application or API in.
- Mobile apps for hosting a backend for your mobile applications in.
- Function apps that run one or more Azure Functions.
- Logic apps, in which you configure a workflow with triggers, connectors, and conditions. These also scale automatically and can be triggered by outside services
The main advantage of using App Services is that they offer a lot of additional capabilities out-of-the-box, like auto-scaling, authentication, and deployment slots. These are all Platform-as-a-Service providers.
A disadvantage is that you don’t have control over things that are installed in the environment (like .NET Framework versions). You can’t access or install anything on the underlying servers.
Where to Run Your Applications?
The options that you have to run your applications in the cloud can sometimes be used to run your applications on-premises or in other clouds than Azure. Being able to only run in Azure is not always the best option, and sometimes you need to mix and match in a hybrid fashion.
Additionally, there is the Azure Stack, which has recently become available. Azure Stack is Azure in a box. You buy it and put it in your own datacenter and you are running Azure on-premises. It is an extension of the public cloud over which you have full control.
The idea is that you can run any Azure Service in Azure Stack, and that it is exactly the same as the public cloud offering. This allows you to host services and data that need to be on-premises in your own datacenter, with the option to later-on move them to the public cloud. However, Azure Stack is still evolving, and you can’t run every Azure service on it yet.
Deploying to Azure: Putting It All Together
So where and how do you deploy your applications? This matrix sums it up:
|Runs where?||Control over what’s installed||Don’t worry about OS||Additional PaaS features|
|Azure Service Fabric||Anywhere||X|
|Azure App Services||In Azure and on Azure Stack||X||X|
You can mix these technologies and even places to create the solution to matches your requirements. You don’t have to pick just one.
Picking the right Azure deployment model is crucial. It all depends on what your requirements are and what your team is comfortable with. If you aren’t sure, Azure App Services are a great starting point.
Published at DZone with permission of Barry Luijbregts , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.