Microsoft Azure is a great platform to use and it has many services and features. 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 4 primary Azure deployment models.
Here are the 4 main ways to deploy your applications in Azure:
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 Operating System 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.
Virtual Machines can be rolled out using images that describe everything that is installed on the Virtual Machine. You can also use these on-premises and on your own computer, but getting these to the cloud is a relatively slow process. You need to upload multi-gigabyte images and after that, it can take minutes for a Virtual Machine to be provisioned and fully started. You need to consider this when using Virtual Machines. They provide the most flexibility and the most complexity.
Like Virtual Machines, 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 light-weight 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 |
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 Operating System 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:
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.
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 that 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.
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 | ||
| Virtual Machines | Anywhere | X | ||
| Containers | 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 that 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.
No matter which one you choose, always make sure you’re monitoring and continually improving your applications. Stackify Retrace is a full lifecycle management tool that can help you do just that. Check it out.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
