This post was originally published here
By Bill Chesnut
This is the 1st of a multipart series of Blog Posts to help companies understand Migrating BizTalk to Azure Integration Platform as a Service (IPaaS).
Should I be migrating from BizTalk to Azure iPaaS? This is a question I am being ask more and more lately for a couple of different reasons.
BizTalk development has always been a very specialized skill set with a limited number of resources available in the market, so companies are now starting to look at Azure iPaaS as a viable alternative to BizTalk in terms of finding developers with the correct skill sets.
There are 3 other reasons many companies are looking at moving from BizTalk to Azure iPaaS:
- cost, consumption pricing instead of product licensing;
- location of data, many companies are dealing with their consumers over the internet, so having their integration resources in Azure makes more sense;
- Infrastructure, companies are seeing the advantages of not having to maintain their own infrastructure and using Platform as a Service (PaaS) and Software as a Service (SaaS) offerings as a cost-effective alternative.
Unlike the BizTalk middleware products that covered most features required for all integration scenarios, Azure iPaaS is a collection of Azure services that may or may not be utilised for each scenario.
The base components that make up Azure iPaaS are Service Bus, Logic Apps, API Management and Event Grid. For some integration scenarios you may also use services like but not limited to: SQL Database, Storage, Function App, Web Site (hosing your WebAPI or WebJobs), Cosmos Db and Virtual Machines. In this series of blog posts, I will look at the different scenarios and the Azure services required.
Instead of spending time here to explain each of the Azure iPaaS services, I have included links to Azure documentation on each product/service mentioned:
All Azure Product/Services can be found here: https://docs.microsoft.com/en-us/azure/#pivot=products
Before you jump full steam into migrating from your on-premises (or cloud hosted) BizTalk to Azure iPaaS, there are a few things that you need to look at to see if the migration makes sense:
- Location of your data
- Sensitivity of your data
- Security Policies for accessing cloud-based resources
- Location of consumers/partners
Let’s look at each of these items in detail:
Location of your data, if most of your data currently used by BizTalk is located inside of your data center it would be hard to justify moving all of that data to and from Azure to use Azure iPaaS.
If your data is from your consumers/partners and it is coming in and going out via the internet, iPaaS can be a great solution in terms of cost, scalability and availability.
Sensitivity of your data, again this will relate back to the first item, if the data is coming in and going out over the internet, your company has already accepted the risk, so iPaaS will be a viable solution, otherwise, a risk assessment will need to be undertaken.
Security Policies for accessing cloud based resources can sometimes be one of the hardest nuts to crack, it requires educating your management to the benefits and security safe guards of Azure. It also means designing your iPaaS solution to use some of the additional security features available in Azure. The final point to look at is location of consumers/partners, again if everyone using the integration service of BizTalk are located inside of your data center, having them traverse to Azure and back for data does not make sense, but if many of your consumers/partners are outside of your offices or mobile users, Azure make perfect sense for availability and scale.
Once a company has decided that moving to Azure iPaaS makes sense, the next item to consider is the structure of their existing BizTalk integration solution, does the existing BizTalk solutions follow best practice:
- having incoming data mapped to an internal/canonical format
- processed in BizTalk using the internal/canonical format
- then mapped back to the outbound format before leaving BizTalk
if so, this will make the migration to Azure iPaaS a less disruptive and staged process.
This series will continue with the following blog posts:
- Migrating inbound messaging to Azure using Logic Apps, Event Grid, Service Bus and the BizTalk Claim Check Pipeline component that I have built.
- Migrating outbound messaging to Azure, using the same tooling as inbound
- Choices for message archiving in Azure
- End to End Monitoring of Azure iPaaS
- EDI (EDIFACT, X12 & AS2) Capabilities of Azure iPaaS
- Azure iPaaS CI/CD
Thanks for taking the time to view this blog post.
Cross Posted on: http://www.sixpivot.com.au