Another great announcement on PDC was the Virtual Machine Role feature. This feature is added to Azure with the primary goal to move existing applications to the cloud.
The feature allows us to upload our own VHD (virtual hard disk) with the Operating System on it (Windows 2008 R2 Enterprise). This machine could have your application pre-packaged and installed. After doing this, you are now able to spin up multiple instances of that machine.
BizTalk on VM Role?
Being a BizTalk Server architect that is highly interested in the Azure platform, I immediately thought about a scenario where I could have my own BizTalk Server in the cloud, on Azure. But, knowing some of the limitations of the Azure platform, I knew I would have a lot of potential issues.
I listed these issues and added the various workaround or solutions for it. This post is a post, based on the PDC information and can contain incorrect information. Consider it as some early thinking and considerations.
No MSDTC support with SQL Azure
- Problem description
- BizTalk Server relies heavily on SQL Server and uses MSDTC to keep transactional state across databases and with the adapters.
- SQL Azure does not support distributed transactions and also introduces more latency to the database queries.
- Solution
- SQL Server will need to be installed on the VHD image locally
- Consequences
- It won’t be possible to build a multi-machine BizTalk Server Group through the VM role.
The OS image is not durable
- Problem description
- All changes that are being made after a Virtual Machine instance is started will be lost, once the instance shuts down or fails over. (there is only one VHD, but multiple instances are possible -> concurrency issues)
- This means all database state (configuration, tracking, process state) will be lost if an instance fails.
- Consequences
- It won’t be possible to have a stateful BizTalk Server configured or to host long running processes on a VM Role BizTalk Server
- We will need to expose BizTalk Server capabilities as services to a stateful engine (Workflow?)
The Virtual Machine name will be assigned by the Windows Azure fabric controller
- Problem description
- Since it is possible to have multiple instances of a VM running, these instances will get a specific Computer Name assigned by the Azure Fabric controller.
- It is very hard to change the computer name of a BizTalk Server machine
- Solution
- We will need to automate the BizTalk Server configuration, using a Silent Install, once the VM is initiating.
- Consequences
- One of the biggest painpoints in setting up BizTalk Server in a VM role will be to configure the BizTalk Server instance on the fly as a startup task.
- Starting / restarting a BizTalk VM Role instance will take a considerable amount of time
Licenses are needed
- Problem description
- BizTalk Server and SQL Server licenses are needed for each instance that is running
- Solution
- Since everything will be installed on a single box, we could use a standard edition of BizTalk & SQL
- Consequences
- There is no big pricing advantage, except for the operational cost
- Only 5 applications will be supported , when using the standard edition
General conclusion
If we succeed in setting up BizTalk Server on VM Role at all, it will be a BizTalk Server with the following limitations:
- No support for long running transactions
- Single box machine
- Stateless BizTalk box
Considering that integration as a service is on the roadmap of Microsoft (see session at PDC), we should only consider it as a temporary solution to have BizTalk Server configured on a VM Role. If we do this, then we should just see it as a BizTalk Server that exposes its various ’short running / isolated’ capabilities as a service. (flat file parsing, transformation, pub/sub, connectivity, EDI)
Sam Vanhoutte, Codit