Windows Azure BizTalk Services – The “Dedicated” Model

The recently released Windows Azure BizTalk Services is described as a dedicated service. In this post, we’ll cover what dedicated means, and what all can be achieved in a dedicated service, which otherwise would have been difficult to do so in a multi-tenant service.

Windows Azure BizTalk Services is an Enterprise Application Integration platform running in Windows Azure. It enables (with its current feature set and the additional features which we plan to light up shortly) running integration workloads end-to-end in Azure. Integration workloads are subject to certain requirements and constraints - things such as predictable performance, compliance criteria, etc. We’ll now see how this is achieved in Windows Azure BizTalk Services.

Dedicated Compute

When you sign up for BizTalk Services, no matter what SKU you choose, you get your own Virtual Machine(s). The amount we provision for you depends on what SKU you choose and how many units you scale out to. But essentially, the processing power of the VM is entirely yours. Depending on whether you need to validate-transform 100 messages a second or a 1000 messages a second, whether your messages are 10kb in size or a 100kb in size – once you determine how much compute power is needed to process a specific workload size, it is very easy to calculate how much you need to scale up or scale down as your workload requirements change.

This is a clear advantage over a multi-tenant service, where processing power and memory are shared amongst workloads (belonging to different customers) which happen to be running on the same virtual machine. An increase in compute cycles used by the workload of one customer can result in reduced available resources for the workloads of other customers on that same machine.

User Code Execution

Since we provide you with your own set of dedicated virtual machines, this gives you the advantage of being able to have your custom code execute on that machine. Custom code written by other customers’ will not execute on your virtual machine (just as your custom code will not execute on theirs’). A poorly written .NET function by some other customer that hogs the CPU and RAM will only affect that customer’s machine – not yours; your code and processing will continue unhindered.

Additionally, your custom code is your Intellectual Property. Since it only executes on your machine, no other customer has access to it.

Message Processing Security

Having your own dedicated virtual machine again helps here. Your messages are only processed on your machine, and only through code which either you (your custom code) or we (Microsoft - Windows Azure BizTalk Services) have authored. Rogue code cannot get access to your messages.

Additionally, since we set up a dedicated endpoint for you, you can provide your custom SSL certificate which will be used to authenticate your endpoint to the clients sending Messages to your bridge endpoint.

Configuration Security

When you configure a Bridge and its associated Artifacts, there may be various pieces of data which need to be kept confidential. In your Bridge you may be routing to an external Web Service, whose credentials are part of the configuration. The Maps which you use in the Bridge may be your Intellectual Property which you need to protect.

Every customer using BizTalk Services gets a separate dedicated database (we provision this internally) in which your configuration is stored. This includes your Bridge configuration, your artifacts such as schemas and transforms, your custom code assemblies, your partners and agreement configuration – basically everything. Even the certificates that you upload for communication with your external partners.

All this configuration data is encrypted, and the encryption keys and certificates are unique per customer. Thus, even if the encryption key of one customer gets lost, it doesn’t compromise your configuration data. We also have the ability to roll over the encryption keys for each customer independently.

Better Monitoring and Diagnostics

With a dedicated service, it becomes much easier to diagnose production issues. For example – if you see the message processing throughput is lower than what you expected, you can quickly navigate to the Azure Portal, select your BizTalk Service deployment, and take a look at the performance counters for your service. We can easily collect this data and display it to you since only your code and your messages are processed on your dedicated virtual machines.

Control over hotfixes / service updates

With BizTalk Server, we’ve generally released newer versions every 2 years. With BizTalk Services, we plan to have much shorter release cycles – a roll out of new features keeping with the cadence of other Azure Services, and an even shorter release cycle for rolling out hotfixes.

We understand that for enterprise customers, picking up every latest release is at times not possible. Testing and upgrading takes time when mission critical applications are being run. With BizTalk Services, we give you the flexibility to choose when you want to accept a hotfix release / feature release. You are free to continue using the release which you are on for as long as it’s supported, while you test out the newer release in a separate staging deployment. And when you’re ready, with a single click, your deployment can be upgraded to the new version where newer features will light up and annoying bugs have been fixed.

This is again something possible only in a dedicated service – since we can have different product versions deployed for different customers depending on which version each customer has tested and needs.

Summary

It should be clear the advantages of the dedicated model that has been adopted for Windows Azure BizTalk Services. It is truly a Managed Enterprise Service – you get a Service managed by Microsoft in terms of infrastructure, installation, configuration, updates; while you yet have all the requirements of an enterprise application solved – data isolation and security, decide when to upgrade versus not, predictable performance, etc.