In this post I thought I would share some of the thinking around some of the design decisions which lead to the evolution of the Azure hosted integration platform to go the way it did. Its important to remember here that the journey for each customer is probably going to be different. We will all have different goals and different skills and preferences which will influence our technology choices. The thing that is common to all of us though is that if we have a desire to leverage Azure then we can all have the same extensive set of tools and technologies available to us and its then a case of which ones we choose to use. There will be bits we can not put in the cloud and the on premise stuff is likely to fall into the situation we are used to where every customer is slightly different, but for those assets in the cloud we can potentially start to see more common approaches across customers.
Ok so with that out of the way lets look at some of the specific design decisions.
BizTalk Server vs BizTalk Services vNow
In an ideal world I would be able to quite easily use BizTalk Server and BizTalk Services side by side and just use the best of each product for each integration scenario. The reality is that cost is a major issue that makes this not viable for many customers.
In general we would use BizTalk Services if we had EDI requirements because the EDI solution for BizTalk Services is pretty good and offers a lot of value which could justify the extra cost.
We didnt have EDI requirements anywhere on our roadmap so this decision became pretty simple because the rest of the features offered by BizTalk Services didnt add enough value to the integration platform to justify the cost of using it. With BizTalk Services vNow the most likely scenario where we could have used BizTalk Services would be if EAI bridges could have been used as an alternative to custom WCF to create the application Service Proxy web services. Conceptually this would have been a good fit but having some experience with MABS I dont think it would have been that easy to implement the proxy with a bridge and the ALM support for MABS is currently weak which means it would have been a thorn in our sides that didnt meet the standards we used elsewhere in the integration platform.
One feature in MABS which we feel could help us at present is Hybrid Connections but again we felt that we werent convinced the pricing options at present worked that well for us and at the time we could have used it Hybrid Connections could not be used from an Azure Virtual Machine.
We are however eagerly awaiting BizTalk Services vNext to see what opportunities this may open up for us. One of the biggest challenges with BizTalk Server is the difficulty that some customers have in being able to effectively set up or manage their environment. If we are able to off load a lot of that to Microsoft then there are obvious benefits to be had.
BizTalk Server in Azure IaaS vs BizTalk Server On-premise
A later section will discuss the version of BizTalk decision and there is a lot of overlap between that decision and this one.
Unfortunately at the present time there is a difference in what you can achieve with a BizTalk Server setup hosted on premise with one hosted in Azure. The key differences are around the high availability story with Azure having limitations in support for Network Load Balancing and Failover Clustering. There are also expected limitations in performance around storage throughput.
For some customers this could be an issue and for others this may not be a problem or be something you can design around. There are significant benefits offered by Azure and its a trade off decision as to which way you would go.
In the platform we were building we knew that the requirements we were aware of were based around moderate workloads and the high availability requirements were not excessively demanding. Based on this we felt that Azure was a good choice to host our BizTalk Server setup.
We felt that if the types of work load we needed to process changed there was always the option to have a BizTalk setup on premise which could work with the Azure hosted one or replace it. We would do this if we had workloads which meant that we needed it on premise but by default we would try to use the Azure hosted one as much as possible for our default approach.
BizTalk Standard vs BizTalk Enterprise
Now that we had decided that BizTalk would be hosted in Azure and based on the workloads we had, choosing BizTalk Standard Edition was a pretty straightforward choice. We would always be able to change this later if required but for now this was a good way to go.
On the Azure Enterprise Agreement, BizTalk Standard was a very competitive price.
Design Decisions Summary
Hopefully you can see that the design decisions we made above seemed quite logical for the scenario we were in. The most important underlying theme to these decisions is that we know things may change and what is a good decision now may need to be changed in the future. For example BizTalk Services vNext may offer a set of features which we decide means we will change our approach to try to use BizTalk Services by default for a number of scenarios that we had previously been using BizTalk Services for. With this in mind we need to make sure that our design and implementation approach is done in a way which will let us move and change things to best leverage the platform. Maybe in the future we will have a lot of stuff in BizTalk Services and reduce our usage of BizTalk Server to only niche use cases which BizTalk Services does not have features to support.
The thing to remember in a cloud based environment is that things are going to be changing all of the time and you need to be able to adapt to get the most out of this. If you are working with an organisation who is adverse to this kind of risk and is fearful of change then you need to be moving more of your stuff on premise where you can control the pace of change.
