Where and how to deploy your Microsoft Azure services

The Azure services that you choose to work with determine your deployment options, and vice versa. Therefore, it is important to understand the deployment options that you have in Azure and what their ramifications are.

The DevOps mindset

Delivering fast and reiterating fast is crucial to creating great software. Therefore, your new code should be merged with your team's code, and that should be deployed and tested as fast and as often as possible to see if everything works and that what you've build is what the user needs.

Many of the Azure services that we've looked at so far in this book are able to have code automatically delivered to them, often through a Continuous Delivery (CD) pipeline that you set up within the service.

Besides the native capabilities of Azure services, you can use Visual Studio Team Services to build, test, and deploy your application. You can easily create new build and deployment pipelines in Visual Studio Team Services as well as do things like automate load-testing and swap deployment slots into production.

Azure Resource Manager Templates

All of the Azure services that introduced in this guide are based on Azure Resource Manager. We can use this to script our environment into Infrastructure-as-Code (IaC), using Resource Manager templates. These templates are JSON files that describe what you want to deploy and what its parameters are.

You can create Resource Manager templates in Visual Studio and Visual Studio Code using the Azure Resource Group project template. You can also generate Resource Manager templates from the Azure portal by clicking the Automation Script button, which is available on the menu bar of every resource in the Azure portal. This generates the Resource Manager template for the given resource and even generates code for creating the resource using the Azure command-line interface (CLI), Windows PowerShell, .NET, and Ruby.

After you have a Resource Manager Template, you can deploy it to Azure by using Windows PowerShell, the Azure CLI, or Visual Studio. Or, you can automate its deployment in a CD pipeline using Visual Studio Team Services.

You use Resource Manager templates to deploy applications to run on the Azure platform, either in the public cloud or on-premises, on Azure Stack.

A great example of deploying resources to the cloud using Resource Manager is the Deploy To Azure button that you can find in many GitHub repositories, as illustrated in Figure 5-1.

Figure 5-1: One-button deployment of an Azure Logic App using an Resource Manager template in GitHub

Azure Service Fabric

Another way to run your applications is to run them on Azure Service Fabric. Service Fabric is the foundation that Microsoft uses to run many Azure resources and to make them highly available, performant, and self-healing. You can now use Service Fabric yourself, to host your own services.

You can use the Azure Service Fabric SDK to create applications for Service Fabric. You can also run any executable in Service Fabric and you can even use it to host containers.

Service Fabric is amazing at making your applications just as performant, reliable, and secure as many Azure services, and you can use it anywhere: you can deploy Service Fabric in Azure, on-premises, on your own computer, and even on Virtual Machines (VMs) in other clouds.

After you have deployed your application in Azure Service Fabric, it provides you with benefits such as these:

• Load balancing
• Automatic scaling
• High availability
• Self-healing
• Replication and failover
• Rolling upgrades
• And automatic rollback

Containers in Azure

Containers is one of those technology buzzwords that flies around the news. But, they are more than just buzz—they are actually very useful for running your applications. A container is basically a lightweight VM that starts and stops much faster than a VM and is therefore much more useful for development, testing, and running applications in production.

The major benefit that you derive from containers is that an individual container is always the same. You run a container locally when you develop your app, and you use the same container configuration in the cloud or anywhere else. Your entire team uses the exact same container configuration, so you know that the infrastructure is the same for everybody and in production. With containers, the ageold developer's fallback statement, "works on my machine," now means that it will also work in production.

There are many technologies for running containers, and Docker is one of them. Azure can run and manage containers for you with Azure Container Instances and Azure Container Service, and even in Services Fabric and Azure App Service running on Linux.

Table 5-1 shows which service you can use for a given scenario when using containers. Table 5-1: Choosing which Azure service to use for containers

Note Keep in mind that when you use containers, you are using an infrastructure as a service (IaaS) product and that you are responsible for the operating system (OS), patching, load balancing, and so on.

Azure Stack

If you need your applications and data to remain on-premises, but you still want to benefit from the power that Azure has to offer, Azure Stack is the product for you. Unique in the industry, Azure Stack is an extension of Azure that you host in your own environment. Essentially, it is Azure-in-a-box.

You use Azure Stack in the same way as you do Azure, with the same Azure portal experience and the same APIs with which you can use the Azure CLI, Windows PowerShell, or your favorite IDE.

You can run things like Azure App Service and Azure Virtual Machines on Azure Stack. Everything is exactly the same as in the public cloud, only now you are running it on-premises. And if you decide to move to the public cloud, you simply push services from Azure Stack to Azure.

Where to deploy, when?

Table 5-2 summarizes the deployment options for Azure. Note that using all of the platform as a service (PaaS) services that we have discussed in this guide is possible only when using the Public Cloud with Resource Manager templates or on-premises with Azure Stack. Table 5-2: Comparing Azure deployment options