BizTalk Server vNext (2016) – What 6 things would you like to see?

Ok so there has been a little talk at the London BizTalk Summit about 2016 being the next expected release for BizTalk Server.

If I could choose 5 things id like to see in it they would be:

  1. No limit on no. Apps in BizTalk Standard Edition
  2. Ability to consume Swagger
  3. Support on Azure IaaS
  4. AMQP Adapter
  5. API App Addins
  6. Proper Azure BizTalk Developer Machine

 

No limit on no. Apps in BizTalk Standard Edition

This one really bugs me!  There is a rule in BizTalk Standard Edition that I can only have 5 applications.

The result of this means that when a customer uses BizTalk Standard Edition they have to build their code bases and application deployments differently to how they would build them if you had BizTalk Enterprise Edition.  This means if you start with BizTalk Standard and want to migrate to Enterprise Edition then the way you have set up your solutions needs to change or you will find the management and maintenance experience to be poor.

I believe a much better way to restrict the usage of BizTalk Standard Edition would be to limit the number of BizTalk Host processes you can have, or better yet you can only deploy it to a single server anyway so there isnt really a need to further restrict anything.  I would hope this would be a very simple restriction to remove.

The value of this means customers can easily upgrade to BizTalk Enterprise and know they have build their stuff to best practices which will just migrate easily, or alternatively downgrade if required and know they wont need to refactor any code.

Ability to consume Swagger (or expose)

The new latest and greatest integration stuff is about API’s that expose Swagger.  This provides a contract which should make it possible a BizTalk developer to add a reference to a Swagger service in a similar way to what we would do for a WSDL based SOAP interface.

It would also be cool to expose Swagger on any REST services we expose from BizTalk.

I believe this would be a significant statement of support for newer styles and make it much easier to integrate BizTalk with API Apps and Azure API Management.

Support on Azure IaaS

One of the biggest challenges for BizTalk customers is how to create a reliable infrastructure which matches best practices.  This can be a difficult task to get right and getting it wrong can be expensive and something you dont notice until later.  This is one of the key reasons why BizTalk is perceived to be difficult to implement.

If we had support for fully H/A BizTalk set ups on Azure IaaS then it would be possible to create a scriptable BizTalk / SQL environment which could be built in a similar way to how a Sharepoint Farm can be created in Azure.  Lets be real about this, some customers need a super high performing environment tuned like an F1 racing car, but many customers could use a BizTalk setup which was build on Azure which met the performance characteristics Azure could achieve and it would be absolutely fine and could use a VPN to come on premise.  This could make the implementation of BizTalk for 80% of customers a commodity task rather than a specialist task.

The biggest blocker to this is still the clustering support for SQL.

If Microsoft were able to solve this or to offer official support for customers to use Data Keeper then it would be possible to create this out of the box BizTalk setup which would significantly lower one of the biggest barriers for customers implementing BizTalk but it would also simplify support because many customers would be using the same base environment.

AMQP Adapter

I think the integration story between BizTalk Server and Service Bus (on premise and cloud) is fundemental to future BizTalk implementations.  Combining BizTalk with an external queue gives a great way to create decoupled and flexible BizTalk solutions.

An AMQP adapter would give us a protocol adapter support for Service Bus which removes the dependancy on the service bus dll which BizTalk struggles to keep up with the pace of change.  Moving this to a protocol adapter would remove this dependency and allow BizTalk to connect to service bus messaging and service bus event hubs at protocol level.

An AMQP adapter would also provide support for integration with customers using different message broker vendors who also support AMQP 1.0.

API App Addins

Many of the new features in the integration stack are being created in the API App and Logic app space.  If we had widgets in BizTalk which we could easily configure to work with Azure integration assets then this would give us the ability to combine BizTalk on premise with BizTalk in Azure.  Some examples of how we might do this include:

1. Azure API App Mapping Pipeline Component

We can add a BizTalk pipeline component which would allow us to configure it to call out to an API App and allow us to host a map in the cloud which is called from BizTalk

2. Azure API Rule App shape in Orchestration

A shape in the orchestration designer which can be configured to easily call out to a rule app in Azure or perhaps a widget in the BizTalk Server rules designer which allows us to delegate the rule call to an API app so its easier for the rule to change in isolation

I think this could be potentially delivered as a hybrid cloud accelerator or something where addons are installed to BizTalk to make it easier to deliver solutions which combine the use of BizTalk and Azure.

Proper Azure BizTalk Developer Machine

Setting up new environments for a customer is a pain and one of those time consuming tasks which means customers are doing stuff that they dont perceives adds value.  The BizTalk Developer image in Azure is something where a customer should be able to easily spin up machines for development purposes.  The problems I have with the images are:

1. They seem to regularly expire

2. They seem to have the SQL evaluation image

3. They are always released ages after a new product release

4. They are sometimes only available on a MSDN azure subscription

My assumption in the past was that Microsoft was cautious customers might use them for non development purposes.

The problem here is that a customer often has a team of developers with MSDN who want to work as a team so work on a shared non-MSDN (usually an ent agreement) subscription so the team development effort can work together and eat out of a corporate agreement.  A customer should be able to easily spin up a number of BizTalk servers for development which can be relied up on to work for the long term to support the team.  Not having to install these from scratch is a big cost saver and would mean the entire development environment can be easily scripted.  This would significantly reduce those barriers to entry for new customers or a migration project.

 

Anyway theres a few thoughts of things id like to see, its about things which lower customers barriers to entry and things which add features of strategic value to BizTalk Server.

 

Would love to hear what others think are key

You May Also Like

About the Author: michaelstephensonuk