While this information is now well known and has been covered by both Richard Seroter and Saravana Kumar, I wanted to throw my 2 cents out there as I was away on vacation when this information was released. Now that I am back, I have had some time to watch Tony Meleg’s presentation from the 2011 World Partner Conference. I have a feeling that this “talk” will be one of those that is referenced for years to come. Much like we continue to bring up certain “Scott Woodgate” talks.
A New Platform is born
For the past couple years, Microsoft has put significant emphasis on cloud computing and providing software and platform services that run in Microsoft’s data centers. From a platform perspective, these investments have been made to Azure. Today we have capabilities to run Web and Worker roles, SQL and Azure Storage, Caching and relay messaging in a production environment.
Microsoft continues to invest in this platform and is increasing the amount of capabilities that are provided in this platform. We are now starting to see some of the “middleware” capabilities being introduced in the form of CTPs that include Workflow, Pub/Sub and Queues. A future CTP will showcase additional “integration” capabilities including pipelines that will host message transformations.
New Platform’s impact on BizTalk
It has been very clear that Microsoft is betting on the cloud and as a result all new software investments will occur in the cloud first and then make its way to on-premise. The first example of this strategy was the release of CRM 2011 which was available in the cloud prior to making its way into on-premise.
To align with Microsoft’s cloud strategy, some tough decisions had to occur in order to include BizTalk functionality in the cloud. A key area that had an impact on BizTalk’s ability to move to the cloud was in the area of Workflow. A decision had to be made as to which “Workflow-ish” technology Microsoft would pursue between Windows Workflow Foundation and Xlang. The driver for this decision was Microsoft’s desire to reduce the amount of duplication of efforts across their platforms. As you can see from Tony’s presentation, Xlang did not make the cut. In my opinion, it makes sense to decide upon Windows Workflow as it can be used outside of BizTalk and is already used in other platforms like CRM and SharePoint. Tony does mention in his presentation that removing the Xlang Orchestration engine from BizTalk is like performing a major heart surgery and will take several years to fulfill.
Microsoft also has aspirations of ensuring symmetry between cloud and on-premise versions of its software. The current BizTalk architecture just didn’t provide a good fit especially when consider the desire to reduce the duplication of efforts across platforms. It was pretty clear that Workflow would be the engine of choice being a .Net based technology and its adoption by other platforms.
Another area that is at the top of customer’s “ask list” was more flexible messaging options. While BizTalk’s current durable messaging is a core requirement for many customers, the ability to by-pass durable messaging in order to increase performance is a core requirement for others. We have the ability to perform non-durable messaging with WCF and WF today so once again this is a natural fit over trying to change the existing BizTalk messaging engine.
Platform end state
Below is an image that I snagged from Tony’s presentation. It represents the new platform’s “end-state” in terms of capabilities. Within this diagram you should be able to find existing BizTalk capabilities and their alignment to the new platform including:
- Adapters
- Rules
- Pub/Sub
- Transformations
- Pipelines
- BAM
- TPM
We also have some enhancements or new capabilities not found within BizTalk natively like Caching, Web Apps, Workflow and the new Composition Model and AppFabric App Manager. I have discussed a few of the Composition Model and AppFabric Manager on my other blog http://www.MiddlewareInTheCloud.com and am looking forward to “BizTalk” app development being able to leverage these features. I was reminded of the convenience of the Composition Model when I recently deployed a BizTalk application to multiple servers that included deploying Web Services. The BizTalk deployment model could be optimized in my opinion when it comes to distributed deployments. Yes there are tools that help like MSBuild and the BizTalk deployment framework but it should be simpler. I would love to see the simplicity that the AppFabric Application model provides to “BizTalk” applications.
Timing
Tony asks people to “lower expectations” and “think long term”. Microsoft recognizes that they will not be able to move existing BizTalk functionality to this new platform in either the cloud or on-premise any time soon. It will take multiple releases to achieve the goals of the platform. Their timeline is somewhere around 5 years. In the mean time Microsoft is going to continue to release versions of BizTalk Server. Yes, you read that right…BizTalk is not dead. However, Tony cautions that we will not see a lot of innovation being baked into the new BizTalk bits. The updates to BizTalk server will be to align to updated platforms like Windows Server, SQL Server and Visual Studio. Updates may also include bug fixes or key customer asks that are reasonable to implement. However, the innovation will occur in this new platform.
In the short term, we will see features of the new platform being rolled out in the form of CTPs. We shouldn’t expect the new middleware features to hit production until sometime in 2012.
(another image that I swiped from Tony’s presentation)
Migration
As we move from our existing platform to the new platform, we should be expect some pain. Obviously Microsoft will take reasonable steps to ensure of smooth transitions to the new platform but we can expect some challenges along the way. There will not be an “easy button”.
Guidance (my opinion – take it as is without warranty)
The first piece of advice is: DON’T PANIC. It is still early and nothing is written in stone at this point. Microsoft has mentioned that this is a long term strategy and it will take multiple releases to address the vision. In the mean time they will continue to support and release more BizTalk. From a personal perspective, I am responsible for a Middleware team at a good sized Energy Distribution provider. We run BizTalk 2009 and I can confidently say that our business runs on top of BizTalk. If BizTalk goes down, many parts of our business slow down if not grind to a halt. We have been making significant investments in BizTalk for over 5 years. My intentions are to continue use BizTalk. We have an upgrade planned in the next 8 months and that will be a BizTalk upgrade. Most likely 2010, but if a newer v.Next release miraculously appears we will consider it.
From a developer perspective, this news is a bit of a wake up call. It is time to start diversifying your skill set. Microsoft is providing initial looks at this technologies through CTPs. Get involved! Download the bits, try them out and get familiar with some of the new concepts and models. I don’t think there is any reason to be really nervous though. The underlying core integration skills that you have built up over the years will not be for nothing. Some of the terminology will change, the toolset will probably change but many existing integration patterns will continue to exist whether there is a “cloudy thing” or not. If anything, I think there will be a lot of new opportunities for developers with Microsoft Integration skill sets. There will be a lot of existing BizTalk –> New Platform migrations that will need to occur in the next 3-10 years. Who better to work on these projects than people with BizTalk experience who have adopted the new technology.
