Typically a BizTalk Server installation has meant an on premises installation using computing resources in your own datacenter. In many companies this often means a virtualized environment providing easier provisioning and management of servers. In other environments, virtual or not, it can take a long time to get the servers provisioned and available to the development team to begin work on a BizTalk solution. When you consider the additional effort of setting up multiple environments (development, test, QA, production), the delays and frustration can be staggering.
While BizTalk deployment has been supported on virtual platforms for quite some time, it was only with the release of BizTalk Server 2013 that deployment in Azure Virtual Machines was officially supported. In this article I will review what that means and the considerations of creating your BizTalk environment in Azure Infrastructure as a Service (IaaS).
BizTalk in Azure IaaS
What does it mean to say that BizTalk Server 2013 (and 2013 R2) are supported in Azure Virtual Machines? First, and important to many, is that Microsoft will provide support services on your BizTalk deployment in Azure the same as if you had it deployed on physical hardware in your own environment. More interesting might be that when you move to Azure you have different options for how you deploy and license your BizTalk servers.
When you have decided to deploy BizTalk in Azure, the first question you will need to answer is how you are going to handle licensing your BizTalk Server. The traditional option allows you to take your current BizTalk processor licenses and apply them to an instances of BizTalk in Azure. To do this you will have to procure the correct number of processor licenses based on the virtual machine size you are going to use for the BizTalk Server instances. For example if you were to use two Windows Server virtual machines with four cores, as shown in Figure 1, then you would need to purchase enough licenses to cover eight cores (2 VMs x 4 cores each).
The cloud is all about provisioning resources and paying for what you use and to that end you can also license BizTalk Server on a pay for use model. In this model when you create virtual machines you use one of the BizTalk Server images (2013 or 2013 R2) as the template for your BizTalk server instances. These images have BizTalk Server pre-installed and provide additional configuration options (more on these in the next section) and have their own pricing per hour that includes the license for BizTalk Server on top of the standard license for the Windows Server OS you are using. When you provision these servers you will see (Figure 2) that the cost is higher than that of a bare Windows OS virtual machine but still provides options for the size of the VM to allow you to configure the processors, memory and other resources required for your needs.
When choosing a licensing model be sure to compare the pricing for Windows Server, SQL Server and BizTalk Server using your existing licenses and using the pay for use model. You can use the Azure Pricing Calculator to check current prices for the virtual machines you plan to setup in your environment.
Setting up the environment
Provisioning virtual machines is only one step in the process. An Azure BizTalk deployment, like any BizTalk environment, must consider network connectivity, security, and recovery. Various topology options are discussed later which will take into account connecting your BizTalk machines to your SQL Server and planning for an Active Directory component of your solution.
While the servers needed are the same there are some advantages to using the BizTalk virtual machine images over installing BizTalk Server in a bare Windows Server image. First, BizTalk is already installed which can save some time. More useful is the BizTalk Provisioning tool which is also pre-installed on each BizTalk virtual machine. The provisioning tool allows you to create an XML file that defines your BizTalk group configuration. You then run a listener process on each BizTalk machine and run a client executable to process the file setting up the databases, hosts, host instances, and features such as business rules and business activity monitoring.
While the provisioning tool makes setting up the BizTalk virtual machines easier, it does not simplify the initial provisioning of all the various machines and network required. One way to manage setting up one or many environments is to use a more recent feature of Azure called Resource Manager. Resource Manager allows you to collect your various application resources into a named group for easier management. While this is often considered when using resources such as websites and databases together it works just as well with a set of virtual machines and a virtual network. There is a gallery of templates for certain resource configurations but you can also define your own template and create a resource group from that template. What this means is that you can create a JSON file that represents your entire BizTalk environment including the virtual network and all the virtual machines in that network and then use that template to create an instance of your environment. Having this template makes it much simpler for you to create and recreate development and test environments without all the lengthy setup.
Sometimes the setup of your environment can’t be captured in a template as you might have additional steps in your setup workflow beyond just provisioning virtual machines and networks. You can leverage tools such as PowerShell to automate tasks inside the virtual machine as well as from your external machine. Because this type of automated workflow is common, Microsoft introduced Azure Automation. With Azure Automation you can define a PowerShell workflow to setup or manage your environment. For a BizTalk environment this might mean scripting the setup of the virtual network and the virtual machines. Once the machines are provisioned your automation Runbook can then invoke commands from the Azure PowerShell cmdlets to manage your resources or invoke commands in the virtual machines themselves. Using automation would enable you to provision the machines and run all the setup and configuration for your environment. For example you might do the following:
- Provision a virtual network and VPN connection to your data center.
- Provision all virtual machines using Windows, SQL, and BizTalk images from the gallery and add them to the network.
- Configure one machine as a Read Only Active Directory domain controller.
- Add all other machines to your domain.
- Copy a BizTalk provisioning tool XML configuration file from Blob storage into your BizTalk virtual machine and replace environment specific values.
- Remotely execute the BizTalk provisioning tool.
Using these tools may seem like overkill for your first deployment but you will wish you had taken the time to use them when you go to setup the second environment. You can literally make deploying a BizTalk environment happen at the click of a button.
Given the various options for networking and the ever changing requirements of integration solutions it is not surprising that there are several different topologies available when using BizTalk in Azure IaaS.
Standalone Azure BizTalk Group
One obvious option is to create an entire BizTalk group in Azure as shown in Figure 3. In this scenario you would create an Active Directory domain controller VM, a SQL VM and one or more BizTalk Server VMs all within the same virtual network and belonging to the AD domain. This model has the benefit that there is no impact on your on premises network or directory services.
In this model there are several options for handling network connectivity or application connectivity back to your on premises resources. Azure Virtual Network or Azure Express Route (preferred for production) can be used to connect your Azure BizTalk group’s network to your on premises network or resources. This gives developers the benefit of working in familiar environment that is similar to traditional BizTalk scenarios. Your network administrators would need to get involved and additional management may be required on their part to manage having those Azure servers “on the network”.
Application level connectivity can be achieved in this model by using Azure Service Bus to connect your standalone BizTalk group with outside resources using relayed or brokered messaging. The benefit of using Service Bus is that is negates the need for setting up the VPN connection between your environments and you can use this same model for connectivity with outside partners. Having the same method of message-based communication can simplify the development and management of your solution. This solution works best with web service resources and not when you have to monitor file locations or other messaging interactions that would require direct access to the network.
Since you are using a standalone Active Directory domain you will not be able to use integrated security when accessing resources in your company domain. Your directory services administrator can manage one-way or two-way trust relationships between your on premises domain and the Azure domain to enable integrated security. You should discuss the security plans with your AD administrators to determine the best solution for your company based on the skill level of staff, rules and regulations, and comfort. If trust relationships are not desired and you want to use Windows authentication then consider the hybrid options discussed next.
A hybrid solution (Figure 4) allows you to take advantage of all the benefits that come with building your BizTalk environment in Azure while reducing the complexity of managing the environment and developing your solutions. In a hybrid solution you would build your BizTalk group in Azure using a virtual network and VPN connection as before, but instead of creating a new Active Directory domain you create a Read Only Domain Controller (RODC) in Azure that is part of your on premises domain. With this model your Azure resource essentially become an extension of your on premises resources.
Because the Azure servers are connected to your network via the VPN connection (Azure Virtual Network or Express Route) there is no need for alternate connectivity solutions such as Azure Service Bus to connect to your on premises data center. You might however use Service Bus to communicate with external partners or systems.
Because the domain controller in Azure is part of your domain all your services can run with domain accounts. Logins can be processed by the domain controller and access to resources can be done using integrated security. The read only domain controller provides the best performance for the remote servers with the least amount of overhead. No trust relationships between domains need to be managed because you are not creating a new domain or forest.
Alternative Hybrid Solutions
Of course these are only two options based on common practices. Leveraging Express Route to bridge your Azure Virtual Network with your on premises network enables many scenarios as the Azure resources become part of your network. For example you can backup your SQL data on premises, or create BizTalk Hosts in Azure that are part of an on premises BizTalk Server Group to isolate certain processing. You might also decide to run applications other than BizTalk and SQL in the Azure data centers as part of your solution. For all these scenarios, be sure to consider the performance cost of network traversal as well as the monetary cost of the resources you are using as you make your design decisions.
Where are we?
In this article we looked at leveraging the IaaS model in Azure to build solutions with BizTalk Server. In the next article we will look more closely at the PaaS model using BizTalk Services to further simplify the provisioning and management of our environment for creating integration solutions.