For the last few weeks ive listened in on discussions around how people perceive BizTalk Server and Azure App Service when used for integration. There are some really great comments and opinions out there but also a bunch of questions and concerns in the community with people not really understanding how the two technologies will align.
I thought id share some of my thoughts on this to prompt a discussion.
Ok, so there isnt a black and white answer on this and there needs to be a long and short term view. Rather than doing a feature comparison which Im sure someone will do at some point, I want to look at this from a product positioning and architecture perspective.
As of today we see comments that the Azure App Service is missing various features and isnt enterprise ready, blah blah and so on. Azure App Service at its core as a hosting platform is an enterprise ready platform which has existed on azure for a couple of years now, but on top of that we have the new features which can be targeted towards integration use cases. To call them out for this article they are:
- Custom API Apps hosted on App Service
- Market Place API Apps
- Market Place BizTalk API Apps
- Logic Apps
The first of the list (custom api app) is really not any different to building a WebAPI component in .net and hosting it on Azure Websites so that is pretty enterprise ready and has been around for ages. There are a couple of extra bits in the portal but its pretty much the same.
The other features are the new things.
So today if we want to consider building an integration solution using Azure App Service then we have a combination of new and older features which we can use and they will have an associated level of risk in using them based on how well you understand the feature and how new it is.
If we now start to think about the integration requirement we have and the technology choices we have available to use then we have 3 possible choices:
- Use only BizTalk Server
- Use only Azure App Service
- Use both
When it comes down to this decision I think there are a few different scenarios you could be in which might influence your decision.
Scenario – Existing BizTalk Customer with Large Investment
In this scenario you are an existing BizTalk Server customer and have a well established process for design/build and operation of BizTalk Server solutions. You have a medium attitude to risk and trying new stuff.
Short Term
If you get an integration requirement which is bread and butter for your Integration Team to implement using BizTalk Server then you are most likely to just do it the way you know how. The main reason I expect most customers would do this is that it is likely that the customer will be quite a big customer with a decent sized integration environment and the cost of spinning up new environments on Azure to match all of the things you need would potentially be more work than delivering the feature the way you know how.
That said it is worth doing some R&D with App Service and its integration features because there could be specific use cases which you might find could be implemented easier. An example might be if you were to combine BizTalk Server with an API App for connectivity to SaaS applications.
The key thing to remember is you now have an additional tool in your tool box for integration and its time to start being aware that integration is not just about BizTalk and there is a whole set of tools from Microsoft that you can make work together.
Long Term
The likelihood is with this kind of customer is they are probably focused on the more reliable and robust type of solutions that they would be comfortable betting their enterprise mission critical systems on. This is a strong reason why these customers will still be using BizTalk Server for years to come. At present you have a product support lifecycle going up to 2023, and the introduction of BizTalk 2016 will probably give you a support lifecycle lasting until 2026. This is about as good as you will get from any vendor for a server product so you know your in a good place for 10 years minimum. Microsoft will also have a whole bunch of really big customers who have been using BizTalk for years and who arent going to be changing stuff anytime soon, and also many customers are still using versions of BizTalk like 2006 and 2009 without any problems.
For this kind of BizTalk customer however in the long term you may see opportunities begin to emerge where App Service and its integration capabilities offer a way to deliver lighter weight integration solutions to meet needs that you have previously found difficult to implement. Being able to turn around fast paced agile integration solutions is something where I believe these customers will begin to see the opportunities on App Service. I kind of demonstrated this at the London BizTalk Summit where in the demo we had a new requirement for the business and there was real value to be obtained by delivering this requirement in hours rather than the weeks and months we might be used to. As App Service matures we might find that more and more of these quick win type solutions are able to live beyond proof of concept stage because the platform maturing gives us the ability to scale and manage that quick win solution to the right level, but if not we can just deliver the idea proven on App Service in a more robust way by moving it to BizTalk Server or a combination of BizTalk Server + App Service.
Long term you should view App Service as a way to lower the total cost of ownership of your BizTalk Server estate and to act on integration opportunities quicker and easier and not necessarily as a replacement for it. I think this kind of customer has no pressing need to even begin to think about anything like a migration of existing stuff from BizTalk Server to App Service for at least 5 years by which point you will have seen some real evolution and maturity around App Service. You may see it mature quicker and decide there are benefits of migrating some things but really you should only consider migrating what adds value or lowers cost.
The biggest benefit for this customer would be around introducing new agility to their ability to deliver integration solutions by using App Service alongside BizTalk Server.
Note: As a side note here, not many iPaaS vendors seem to offer product support life cycles for their products. I wonder what commitment they have to a product if you bet on it and the product turned out to be not working out for them. Maybe something to think about
Scenario – Existing BizTalk Customer with Small Investment
Short Term
If I was a customer with a small investment in BizTalk Server then the chances are that right now Id be taking the same view of App Service as the existing customer with a heavy investment in BizTalk. For specific use cases App Service could help me with certain requirements but id be cautious about doing too much with them too much until Logic Apps and the market place apps reach general availability and have a few missing features.
Long Term
In the longer term if I were this kind of customer I would be looking to try to reduce the size of my BizTalk Server estate by moving what makes sense to App Service. The main reason I think this makes sense is that if it was possible to get my BizTalk Server estate downgraded from an enterprise edition to a standard edition then there could potentially be some substantial cost savings. Once I felt App Service was in a position where I was comfortable delivering solutions on it I would be looking to use App Service first for new requirements and fall back to BizTalk Server if I required a feature or something that App Service did not offer.
The biggest benefit to this customer would be the potential total cost of ownership reduction by minimizing their operations costs and licensing costs by migrating some appropriate things from BizTalk Server to App Service and considering App Service for newer features.
Scenario – Customer moving from Competitor (Integration Server)
Often we come across a scenario where a customer has an existing integration platform with another vendor and is migrating to use the Microsoft stack. For these types of potential customers the understanding of the positioning of Microsoft integration stack could have been quite confusing until the autumn of 2014. Hopefully it is now clear that where once a partner would have been trying to sell a BizTalk solution, now they should be trying to sell a Microsoft Integration Solution. This should represent the fact that the tools available to deliver integration solutions have expanded over the years and there is a set of tools available and you can use the things you need to depending on your situation.
Short Term
Most migrating customers have probably already had a BizTalk equivalent product on premise and are initially considering BizTalk Server. Well the great news is that BizTalk Server is your integration swiss army knife that can do most things, but with Azure its really cheap and easy to compliment BizTalk with these other things like API Management and Service Bus and App Service. There is no need to go to another vendor or to go through a huge procurement process its really easy to add these things.
Your also in a good position in terms of product support lifecycle with around 10+ years of committed support as of today.
Long Term
From a long term perspective I think your in a great place with your new Microsoft Integration stack. You have the option to do cloud based or server based implementations (or hybrid) which is one of many company intranet ideas and you have a rich set of capabilities which in places have been around for years and in places have the ability to deal with colossal scale. Your main challenge here is how to decide which of the tools to use where. Its a bit like the football analogy of when the manager has a whole squad of star players available maybe a bit like Real Madrid. The thing is you know all of your players are good but they are good in the right position, you wouldnt for example put Ronaldo in goal!
The biggest benefit to this customer is the ability to have a range of different integration tools supporting pretty much whatever you need to do and you can choose the right ones for your situation.
Scenario – Customer moving from Competitor (iPaaS)
I think one interesting customer scenario we will begin to see in the future is a customer who has migrated from another iPaaS vendor. Some of the reasons this might happen is that they see Azure as a cheaper option. Perhaps offering more than just integration solutions means Azure can offer lower costs. Perhaps a customer already uses Azure for other things and can consolidate by also bringing their iPaaS assets to Azure or perhaps the customer realizes they need more than just iPaaS and the Microsoft stack offers a fully rounded solution without the need to work with many vendors to get all of the things you need.
Short Term
I think in the short term we will not see too many of this type of customer, the main reasons for this are that App Service’s integration is not mature enough yet to compete like for like with some of the competitors and also BizTalk having high availability limitations on Azure IaaS means it would be difficult to just drop back to BizTalk Server when you need to without involving some on premise investments.
Long Term
In the longer term though I believe we will see a lot of this kind of customer scenario. If you look at the current pricing for Azure App Service and compare it with some of the integration specific vendors then it is difficult to see how they would be able to compete on price when they offer no other services.
Im not saying that Microsoft are running App Service based integration as a loss leader, but their view that integration should be a horizontal thing across all of your IT estate means they consider integration to be a commodity service where they will give you a great way to do it because it will help you to use more of our other Azure services rather at some other vendors where integration is their core product or their high value product.
I think we see quite a bit of this kind of thing with API Management where Azure API Management is not yet as feature rich as other vendor’s offerings but there have been large numbers of customers moving to it because the cost savings are enough to mean you dont care as much if there are some feature gaps, knowing that they will be plugged in time.
If you do move to Microsoft with this kind of customer scenario then I think in the longer term you will know you have a good iPaaS platform to build solutions upon, but you will also know if you need to you have the option of introducing the rest of the integration product suite from PaaS or IaaS or On Premise Server level if you need it.
In my opinion the 2 biggest benefits to this customer will be potential cost savings and the range of tools available.
Scenario – Existing Azure Customer (No Integration)
In this scenario I think there will be customers who already use Azure but who do not consider themselves to really do any integration. The reality is they probably do have some integration but it is probably applications that call the API on other applications. For these customers they are now in a position with Azure that they have a platform which will support them in wanting to move towards a more managed way of doing integration.
Perhaps their first step could be introducing Azure API Management to manage and monitor the API’s that they consume or expose so they begin to have visibility and governance around the integration that they do. Once you are on that first step towards a structured approach to how you do integration then on the Azure platform you are in a pretty good place.
Short Term
In the short term it is likely that these types of customers may be one of the more likely to consider the features like API App and Logic App within App Service. They do not really have an investment in an existing way of doing integration and the App Service offers a low cost and easy to implement way to have some integration capability.
For some usage scenarios the API Apps and Logic Apps will really help these customers, offering them ways to handle the new problems they are encountering. Im sure these customers will be some of the ones who will find the limits of the maturity offered by App Service because they will be some of the more aggressive adopters of it. What will be interesting is to see how they handle it when they reach the constraints of App Service in the short term.
The good news for these customers if you have the whole rest of the Microsoft Integration stack available to you. You could use Service Bus, BizTalk Server (on prem or in the cloud) and the whole set of other stuff.
Long Term
In reality I suspect that only a small % of this type of customer will end up using BizTalk Server. From experience I think these type of customers tend to be doing lots of the typical website + SQL database type of projects and BizTalk Server would be more of a strategic investment rather than a project specific one. I think that unless the barriers to entry for setting up BizTalk Server on Azure IaaS come down quite a bit then these type of customers are likely to use custom coded integration to fill the gaps that Logic Apps and API Apps can not fill.
The main benefit for this customer is the ability to do managed integration rather than custom coded integration in a cost effective way. For Integration Consultancies these can be a new type of customer that we will not have worked with before so there could be lots of opportunities in this space.
Conclusion
As I mentioned earlier the aim of this article wasnt to try and do a technical diff of the BizTalk Server vs App Service feature set. I wanted to brain dump some thoughts on how customers in different scenarios might see the positioning of these products and some of the things they should be thinking about to help them to understand what is the right kind of investment decision to make.
At the end of the day to me this decision really boils down to what integration features and capabilities do you need and at what scale, and if you have a set of requirements where there is no feature gap, how much risk are you willing to take on the level of maturity of a product if there is a way to potentially deliver it quicker, easier or cheaper.
Id love to hear others views on this.
Hi Michael, thanks for this. Good write-up.
One comment:
In a lot of scenarios, having a manageable hybrid solution (no matter what you currently use) is crucial. Hybrid can b.t.w. also mean cloud1-cloud2 in my opinion. Doing a big-bang migration (= re-write) of your current integration environment probably is costlier than the savings you’ll make. Even migration from BizTalk 2009 to 2013 is, for an organization with let’s say 50 BizTalk Applications, quite a big project. Therefore, companies will most of the times keep their current environment for that stuff and will build modern apps and integrations with App Service and will have to integratie them with their on-prem (or IaaS) integration middleware. Gradually the application landscape and business processes will change, and new or changing integrations will then have to be recreated in the App Service and the legacy integration solution can be removed. That way, the old integration middleware environment will become smaller and smaller and in the end can be turned off. That way, the migration is executed in business projects and properly financed and properly allocated to a business case. As we all know, building or migration cost is only probably 25% of the total cost. Running and maintaining it the remaining 75%. If the latter cost can be lowered, that’ll be fantastic. We need good management tools for that, that span cloud/on-prem or cloud/cloud. We (Microsoft) should not underestimate that.
Cheers, Gijs
thanks mate i 100% agree with what you say there.
Hi Michael, thanks for ideas.
There are very specific kind of customers, the “developer oriented” customers. Usually they are some sort of software producers.
They have good, smart developers and tolerate risks associated with new software which gives them competitive advantage.
I can see such developer-oriented clients more and more frequently.
For these customers moving from BizTalk Server to Azure App Services is still a matter of pure business evaluation and priorities, no difference from more “classic” type of customers. But because they have good developers they do not have high risks of moving to new advanced technologies, and they probably have different strategies for short and long terms.