Last week Aaron Landgraf from MuleSoft published a lengthy blog article “10 Reasons to Walk from BizTalk” trying to showcase MuleSoft is better than BizTalk. I felt some of the facts are completely wrong, misleading and one sided. I always welcome competition, healthy competition is good for innovation, but playing marketing games and bad mouthing … Continue reading Our response to MuleSoft blog “10 Reasons to Walk from BizTalk”
Last week Aaron Landgraf from MuleSoft published a lengthy blog article “10 Reasons to Walk from BizTalk
” trying to showcase MuleSoft is better than BizTalk. I felt some of the facts are completely wrong, misleading and one sided. I always welcome competition, healthy competition is good for innovation, but playing marketing games and bad mouthing a competition is not fair. Generally in these kind of comparisons you compare against what your product have and don’t say a word about the features you don’t have, is it fair?
Let me try to clarify few things from my point of view. My intention here it not to rage a fight against MuleSoft and break the bridges, who knows we might work together with them in the future. But it’s important to give a fair comparison, in reaction to their blog article.
1. Extensibility to Best of Breed
“BizTalk Server promotes a tightly coupled model in which many of the services are bundled within the product. While this is great for compatibility it limits the ability of companies to use 3rd party applications that may provide better functionality. MuleSoft has built Anypoint Platform to be open and extensible to best of breed services and applications…..120+ connectors included and allows developers to quickly build Mule extensions….”
Every part of BizTalk server is completely extensible. Here is the standard high level BizTalk Architecture diagrams showing the overall receive side, send side and processing orchestration.
The receive adapter and transmit adapter (yellow boxes highlighted) are equivalent to MuleSoft’s connector. BizTalk server out of the box comes with majority of the well known adapters like File, FTP, SFTP, HTTP, IBM Related (MQ, AS2 etc), SQL, SAP, Oracle, JD Edwards, Peoplesoft, etc In addition the BizTalk community, third party vendors and customer have built 100’s of adapters since 2004. Here is just couple of example list
Adapter are not the only extensibility point, every single item in the above BizTalk architecture is extensible by third parties. Examples: Pipelines, Pipeline components etc. We here at BizTalk360
have used the underlying Administration API’s and built a completely awesome management and monitoring solution for BizTalk Server.
So, MuleSoft’s comment of “limits the ability of companies to use 3rd party applications
” is not valid. Microsoft is always partner driven company, their core strength is having a robust partner model with enough extensibility points.
2. Support for SaaS and Hybrid Deployments
“MuleSoft provides the industry-leading iPaaS (integration platform as a service) solution, CloudHub. With CloudHub you have complete feature symmetry with on-premises Mule ESB.”
We agree, right now there is no symmetry between the on-premise BizTalk Server and the cloud version “Microsoft Azure BizTalk Services (MABS)
“. They are completely different products, you cannot just build solution on-prem and port it to the cloud. But keep in mind, BizTalk Server is 14 years old product, Microsoft cannot just port BizTalk Server as it is to the cloud and expect it to scale for cloud scenarios. Hence they started “BizTalk Services” from ground-up keeping in mind all the cloud based scenarios. You can do full EDI and EAI based integrations now with “BizTalk Services”. Also there are other challenges in this cloud/on-premise hybrid discussion, unless otherwise you are only doing pure SaaS based integrations (where everything is publicly connected like SalesForce, CRM Online etc), it’s not possible to simply port your on-prem solution to the cloud and expect it to work. What will happen to those legacy systems like SAP, Oralce, IBM AS2 systems that are residing on your data centre’s. How are you going to connect to them? To address these challenges Microsoft invested in technologies like Service Bus Relay
, Azure Hybrid Connectivity
, AppFabric Connect
“BizTalk Services (the cloud version of BizTalk Server) is an untested technology in the enterprise that does not allow for feature symmetry. BizTalk Services only supports SOAP – no REST with very few endpoints, making it extremely difficult to talk to SaaS applications.
This is completely meaning less comment on both points. BizTalk Services was not born overnight, it took Microsoft 4 years to build it, during the period they have brought lot of real world customers as “Technology Adapters” and fine tuned the platform. Regarding the second point, not sure from where the message was picked up “BizTalk Services only support SOAP
“. BizTalk Service only rely on HTTP, it doesn’t matter whether you are dealing with SOAP or REST based payloads, it’s up to implementer to deal with it.
3. Connectivity to Microsoft
“MuleSoft has 11 adaptors/connectors supporting Microsoft technologies, which is more than BizTalk currently supports, and 120+ other best of breed connectors available out of the box.
It’s nice to see wide range of connectors for Microsoft platforms from MuleSoft like SQL, MSMQ, SharePoint, Dynamics family, etc. It’s inevitable you need to build those connectors if you are a integration focused product. Similar to what Microsoft has done to IBM and Oracle products. But the claim “…which is more than BizTalk currently supports..
” may not be true.
4. RESTful and SOAP APIs
“BizTalk Server still hasn’t addressed the needs of the modern enterprise to seamlessly design, build and manage SOAP or RESTful APIs on a unified platform.”
We agree out of the box there is no API Management solution from BizTalk (on-prem). API Management is a big industry of it’s own, and there are various big vendors in the market like Layer 7, SOA Software, Sentinet, Oracle API Managment, IBM API Management, Software AG API Management and many more. Mulesoft acquired ProgrammableWeb and recently Microsoft acquired Apiphany and made it available in Azure API Management. So we believe it’s just a management decision whether you are going to invest in something that’s available through partners or re-invent the wheel building and maintaining it as part of the product. It’s definitely nice to have as part of the product (which may happen given the recent acquisition), but we don’t think it’s a complete show stopper.
From an Integration product perspective its more important to address some core integration problems like EDI, SWIFT, HL7, etc. In lot of integration cases there may not be a need for an API management solution. Ex: If you are integrating an on-prem SAP system with Oracle system. As an integration product more often you are connecting various system together than exposing your systems via API’s. So it’s perfectly safe an API management solution can sit in-front of BizTalk end points and do the job.
The work MuleSoft is doing on RAML
is great, since it gives web service definition similar to SOAP WSDL to understand the API structure. Right now in BizTalk it can only import SOAP/WCF based WSDL files. Having said that the new addition of JSON Wizard in BizTalk Server 2013 R2 simplifies REST based integration. More details here Processing JSON messages using BizTalk Server
5. Access to source code
“MuleSoft provides the world’s leading open source ESB. The source code of our core technology is available for customers and prospects to view and troubleshoot. With BizTalk Server this is not an option.”
This just goes back to the debate of open source vs proprietary software
. There are pros and cons to both and we don’t think it’s a valid discussion. How many of us are fine to troubleshoot a complex core engine source code, make some modifications and run it in production? Having access to source code is nice to have, we feel it doesn’t mean anything.
6. .NET and Java support
“Mule ESB provides a language agnostic platform that allows you to remove the language barriers when looking at new opportunities……………….MuleSoft is not a Java only company, we are constantly building new components and connectors specifically addressing various coding languages, including robust .NET and C# connectivity. BizTalk yet to provide full support for Java based code. In order to connect to Java BizTalk requires a 3rd party bridging application, potentially adding thousands to licensing costs.
In BizTalk it’s not possible to call JAVA code from orchestrations without 3rd party components. The new MuleSoft .NET connector is an interesting concept, ability to call public methods inside a .NET Assemblies. In our opinion this feature is useful if you have lot of .NET assembly assets with complex business logic and you don’t want to spend any time/money to rewrite them in Java. But I’ll not personally agree, if you are Microsoft shop with mainly .NET developers, hoping you can use MuleSoft and continue to build your components in .NET.
I don’t know the absolute details, but based on my research so far. This feature is built using the JNI Bridge technology which allows interoperability between JAVA runtime and .NET CLR (common language runtime), the serialization between layers happens as JSON objects. If this is the case, there will definitely be a performance penalty to pay between cross platform object serializations. Need to keep this into consideration.
7. Developer Tooling
“Customers that have switched from BizTalk Server to MuleSoft tell us that ease of use and productivity is one of the primary factors for changing vendors. ….. With BizTalk Server, advanced development skill and BizTalk certification is required just to properly setup and manage a BizTalk instance.
We agree you need some kind of advanced skill than a normal developer to work with BizTalk, that’s due to the nature of work you are doing. The challenge here is someone who understand the messaging style development instead of traditional development. I’ve not doubt this challenge will exist for MuleSoft as well, you cannot just take a Java developer and ask him to start building integration solutions. Concepts like schemas, maps/transformations, Orchestrations, messaging patterns, exception handling etc will all be new and will require a learning curve.
There are couple of complete false claims from MuleSoft here “lack of productivity tools and BizTalk certification required
” In fact lot of the good BizTalk people I’ve seen never bothered to write any exams. Including lot of Microsoft MVP’s.
8. Pricing Model
“On average, the total cost of ownership of Anypoint Platform is a fraction of the cost of traditional, commercial solutions.
We can only validate this claim if the MuleSoft pricing figures are public. Microsoft BizTalk Server pricing
is public information, it starts with $2,485/core (perpetual, not recurring). The comparison should also be like for like, what will it take for the complete solutions. Example: Including development licenses, QA licenses, Production licenses, Support cost etc. Microsoft BizTalk licenses are free for development and QA if you have MSDN.
“Our award-winning support features 2 hour SLA’s for our top tier clients with access to our team of support specialists that sit next to the engineers and have a direct line to product management. BizTalk offers a 4 hour SLA and a complicated series of call centers before you get to an engineer.
MuleSoft 2 hour SLA is not for everyone and only applicable to platinum customers. It should not be compared against the normal Microsoft PSS (Premier Support Services
) support. If customer want more stringent SLA’s, they should look at Microsoft PMC (Premier Mission Critical
) support. This is the extract from the Microsoft site “With Microsoft Premier Mission Critical Support, you receive enhanced support for your mission-critical solutions through guaranteed response times backed by financial credits, round-the-clock access to expertise, and prioritized access to Microsoft product development teams.
10. Innovative Roadmap
“MuleSoft’s release cadence includes updates to the product every 2 months and major releases every 6 months. The integration roadmap for BizTalk has been publicly questioned by analysts, customers, and partners.
Few years ago there was bit of confusion around future of BizTalk, when Microsoft started to invest more on Microsoft Azure and confusions around competing technologies within Microsoft like Windows Workflow, Service Bus, Azure BizTalk Services etc. But Microsoft commented/committed publicly it will release one major version every 2 years once and one intermediate platform alignment (R2) release every year in the recent BizTalk Summit, London.
What’s not covered in the MuleSoft Blog?
Disclaimer: I’m not a MuleSoft expert, apart from keeping an eye on the general integration industry and reading through their documentation and public sources I do not have any real world experience using MuleSoft. So some of the following analysis may be wrong.
: MuleSoft relies on external open source libraries like Drools, Prova etc. Out of the box they do not have any rules, whereas BizTalk comes with it’s own Rule engine and corresponding tooling around it.
Long Running Transaction/BPM:
When you are constructing real world orchestrations long running transactions support (ex: you submit loan application, it may take anywhere from 2 hours to 3 days for vendor to process it) becomes crucial. BizTalk orchestrations can do it seamlessly without any external work. MuleSoft will require dealing with Queues/JMS by developer
Electronic Data Interchange (EDI) is one major area where integration is crucial, most of the B2B integration involves EDI like X12, EDIFACT. We cannot find enough information on MuleSoft.
The ability to dynamically construct itinerates, call rules, transform messages, resolve end points, global exception handling framework are all part of BizTalk ESB Toolkit, we cannot find any corresponding alternative. The AnyPoint API management can solve certain things.
There is no doubt MuleSoft is fast growing aggressive company with constant innovation. I guess it all comes down to customer choice and their scenario. In my view if you are an existing BizTalk customer or someone who primarily depend on Microsoft technologies, then Microsoft BizTalk Server will be more ideal choice. If you have pressing needs, then evaluate carefully all your feature request and make informed decision.
Original article published at http://blogs.biztalk360.com/response-mulesoft-blog-10-reasons-walk-biztalk/