Our response to MuleSoft blog "10 Reasons to Walk from BizTalk"

|  Posted: August 3, 2014  |  Categories: BizTalk Server

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.

choosing integration platform

You can download the entire article as a PDF document.
Our response to MuleSoft blog “10 Reasons to Walk from BizTalk”.

1. Extensibility to Best of Breed

MuleSoft Comment: 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….”

Our Reaction: 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.

biztalk-architecture
biztalk-receive biztalk-send

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

Hybrid CloudMuleSoft Comment: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.”

Our Reaction: 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

MuleSoft Comment: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.

Our Reaction: 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

MicrosoftMuleSoft Comment: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.

Our Reaction: 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

SOAP Vs RESTMuleSoft Comment: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.”

Our Reaction: 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

Architectural Thoughts on JSON

5. Access to source code

Source CodeMuleSoft Comment: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.”

Our Reaction: 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.
<

You can download the entire article as a PDF document.
Our response to MuleSoft blog “10 Reasons to Walk from BizTalk”.

6. .NET and Java support

Java vs .NETMuleSoft Comment: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.

Our Reaction: 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

Developer ToolsMuleSoft Comment: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.

Our Reaction: 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

PricingMuleSoft Comment:On average, the total cost of ownership of Anypoint Platform is a fraction of the cost of traditional, commercial solutions.

Our Reaction: 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.

9. Support

SupportMuleSoft Comment: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.

Our Reaction: 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 Comment: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.

Our Reaction: 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.

Rules Support: 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

EDI Support: 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.

ESB Support: 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/

BizTalk360 Free Trial

You can download the entire article as a PDF document.
Our response to MuleSoft blog “10 Reasons to Walk from BizTalk”.
Author: Saravana Kumar

Saravana Kumar is the Founder and CTO of BizTalk360, an enterprise software that acts as an all-in-one solution for better administration, operation, support and monitoring of Microsoft BizTalk Server environments.

  • Mike Stephenson

    Hi Saravana

    Thanks for writing this, I have been following Mulesoft for a while now and really like what they were doing but theres a couple of articles which have come out from them recently which I found a little but distasteful and reflect badly on them as a company. Mulesoft always used to talk a lot about the good things that their products did and integration concepts in general which in my opinion made them stand out and look like thought leaders.

    The recent article and case study seems to have changed their angle to competitor bashing which I wonder if it has something to do with large investments in Mulesoft last year which has potentially created a new commercial pressure (a guess on my part?).

    That said when you step into the space of competitor bashing and put forward a “Car Salesman View” of your competitors products and how it relates to your own then you need to be pretty sure about your story otherwise it can reflect as badly on yourself as it does on your competitor.

    The problem with these kind of articles though is a lot of people take them as gospel without understanding the true capabilities of each product and how they may be implemented the same or differently in each product.

    Lets get to the point, if you are comparing BizTalk Server and Mulesoft ESB then your not comparing apples with apples. They are implemented very differently but do some of the same things and each does things that the other does not.

    BizTalk Server comes from a heavy duty EAI integration back ground and has evolved over the years to try to solve some of the more modern integration problems and has a road map where newer features will be build as iPaaS in Azure because it offers a better long term direction but there is still a need for BizTalk Server because there are some integration problems which are just better solved that way.

    Mulesoft is a newer product which is an “out of the box ESB” which doest tick all of the boxes for features that an “ESB is supposed to have” so fills these gaps by using Best of Breed products in combination

    Both products do some things really well, both products have limitations, both products can be implemented poorly.

    What Mulesoft had until now done really well was talk about integration concepts and how they would implement then and that really made themselves look great. They kicked Microsofts ass at this big time in the integration space but the 2 new articles leave a bit of a sour taste in my opinion.

    In addition to the product overviews which I think you have made some really solid statements about, I also wanted to comment about the case study which I found bizzare (url: http://www.mulesoft.com/sites/default/files/case-study-sumitomo.pdf)

    In the case study the customer was having a problem which was due to a poorly implemented BizTalk solution. Mulesoft (or their implementation partner) seem to have done what many vendors will do which is to go in and say “our product will fix all of your problems” then this time the solution has been implemented better and many of the problems are fixed. The vendor reinforces the customers perception that it must have been the products fault. I dont have too much of an issue with this because thats the way business often goes but I find it bizzare that they would put out there a case study which goes into this story in the way it does. Please read it for yourself and form your own opinion but some of the key things that stuck out for me were:

    – There were frequent system outages

    – Regular live data loss

    – The system outages ended up with a manual process which became a business as usual process every three days

    – Mulesoft did not require an additional database

    – The migration took 6 weeks

    There is only a certain amount of information in the case study but lets discuss a couple of key things here:

    1. SCAO IT Dept

    If you are the CTO of SCAO you have a new vendor who has basically told the world via a case study that the IT operations team are not good and are incapable of supporting a highly available SQL Server. In addition to this rather than working out what the real problem is and coming up with a plan to fix it your IT team have just created a new complete hack of an operations process which has become business as usual. I think this is pretty shocking and I would have thought this would do serious damage to SCAO in terms of their reputation to have this broadcast to the world. But as sometimes happens in IT if everyone can blame the product then no one is to blame and everyone keeps their jobs. If it only took 6 weeks to migrate then a new BizTalk Server could have been set up correctly and migrated to in less time than this surely.

    2. Data Loss

    Going on the assumptions we have made above then Mulesoft has a significant advantage over BizTalk (in this scenario) in that it doesnt have any persistence so it cant lose any data anyway. If something goes down then it must be someone elses problem? It sounds like if there is no persistence requirement then Mule might be a good fit for the customer, but I wonder what happens when one of the applications has a maintenence window and the others are pumping messages into Mule and it has no where to send them. Maybe this is not an issue but if SCAO doesnt do operational testing, which the root cause problem suggests they dont, then I wonder if this is something they will findout later to be a problem. If that happens then we can just add a best of breed message queue or database from another vendor for what ever it costs and hope that the customers operations team is capable of managing it.

    I think there is a couple of lessons here for Mulesoft:

    1. If your going to do case studies around competitors focus on what you did well, dont make it personal and dont bash your competitors.

    2. If your going to compare your product with others then dont fall into the car sales man trap – apologies to any car sales men 🙂

    I think in both cases to the un-informed reader you look great but to someone with a little bit of knowledge or who can read between the lines of the marketing BS you actually come across in a way which I dont think fits with your values.

    Good response to the article though Saravana and I think you put a well balanced piece out

    Cheers

    Mike

    • Leonid Ganeline

      Mike,

      You made a very good point. This discussed article is the “Car Salesman View” and it is laughable and funny. I could hardly imagine CIO which will consider this article seriously.

      • michael stephenson

        Leo
        You’d be surprised!

        I mean if as Rob says they dont have retry capability. Surely that would be a deal breaker every time?

        • Rob Fox

          There’s a retry mechanism (if the adapter supports it!), but you can’t initiate it yourself. It will simply retry 3 times and then fail and end with an error. In BizTalk I can resume a flow or port where it was left stranded. And that’s just what Mule needs to work on next.

          • gfepi

            what do you do when the message fails? Is there a possibility to backup to Another location in case of failiure?

          • AJ

            One can explicitly define how to handle message failures. One common method is to send it to a DLQ (or some storage that serves the same purpose)

    • Nick Heppleston

      Interestingly, the case study you reference on the Mulesoft website has been taken down – says it all really.

    • cyrill g

      No data loss because nothing is persisted!? Sounds more like data is always lost in case of a failure in the mulesoft integration layer or connectivity issues. This simply moves the responsibility for error handling and recovery to the client.

  • Murugesan Mari Chettiar

    I completely agree with the points here and it is a great response to Mulesoft.

    Mulesoft should try to market their product on it strengths.

  • Rob Fox

    Hey Saravana. Nice article. I do agree with Mulesoft that you will get started faster than on BizTalk (I develop for both platforms), but indeed still need integration skills there and surely understand messaging. The flow-debugging feature of MuleSoft is really good and overall the community does a great job developing adapters. Microsoft should manage their community better (e.g. make 3rd party adapters easily available, e.g. through the website). And of course the BizTalk team should have added REST support way sooner. MuleSoft’s mapper though is really crap compared to BizTalk’s.

    Where Mulesoft really needs development though, is on its runtime environment. It’s so hard to manage or pinpoint problems. I have to go and look into several logfiles (text) to pinpoint where something is failing (mostly other systems as you know). It’s also impossible to change your configuration on the fly. You will need to do a new deployment (which is faster than deploying to BizTalk, but it’s still weird). And retries? Never heard of it!
    And of course some knowledge of TomCat, JBoss or Maven can come in handy as well, it just as much buys into other products here.

    I always advice a company based on what I know. Small orchestrations are probably developed faster in Mule. Do I only need some routing setup with a mapping? Hmz, maybe BizTalk will be faster here. And for big projects? Development will probably be just as fast (or slow), since you spend 80% talking about your solution and 20% implementing it 🙂

    • michael stephenson

      Thanks Rob that is really useful to get some real world feedback on those.

      I always wondered if there was a use case for Mule Cloud Hub + BizTalk Server. Bringing together the best of both worlds. Maybe down the line when BizTalk Services vnext is out there we will have a similar capability where we have light weight cloud based integration which can be combined with the heavier weight enterprise features which are needed for other cases.

      Its really useful to hear those gaps because my comment about Car Sales Man view really fits with that as you never hear those kind of things mentioned and in demo’s you only ever get someone doing the “look how easily I can connect sales force to a web service” in a point to point fashion but lets call it an ESB kind of demo.

      • Rob Fox

        Mule development is really easy, especially if your knowledge of open source technologies is up-to-date. But integration is not just about development. It’s also about how to manage your solutions and the messaging that is flowing through it. How can you make sure something get’s delivered? Etc.

        So for runtime I think BizTalk does a better job (manageability), but for development of flows (orchestrations!) I would say Mule does a better job, especially debugging. On the transforms side, Mule’s visual mapper is inferior to BizTalk’s visual mapper. So it all depends on each client’s use cases.

        • Rob, have you looked at Adeptia ESB and its Data Mapping interface. It has the browser based visual mapper that allows non technical users to setup integration solutions quickly without having to write code.

    • Rob, BizTalk has been supporting REST with the HTTP port for many years.

      • Rob Fox

        Of course BizTalk supported REST through the HTTP or WCF-HTTP adapters, but did it also support JSON? And I never forget the time I needed to develop a custom WCF-binding to be able to do a simple GET 😉

        I think BizTalk really missed the first few boats on the API thing, but they are catching up.

        • Rob, I had to refresh my memory on this, but we only needed to pass XML to the Ruby REST service, not JSON. So, you are probably correct on the JSON portion of the statement.

          • Az Aza

            Implementation of custom WCF adapter that receives JSON files takes approximately 3 Hrs.

    • saravanamv

      Rob, “You will need to do a new deployment” does that mean there is no concept of binding files?

      • michael stephenson

        or even an admin console to change stuff or see whats happening?

        • Rob Fox

          There’s a console (MMC – website) in which you can track your flows. It’s either track everything in a flow or track nothing. It’s a farily good way of tracking flows as they pass by. But if you are not tracking, you won’t be able to see what just happened and you will have to go into the log files (ow man! That’s like 1998 all over again haha).

          And indeed, to answer your question, you can’t change your flows configuration (ports) through this console. You’ll have to go into the file described above and do a redeploymoment.

      • Rob Fox

        There’s a configuration file you can use. You put the configuration file in a static directory on the server and do your deployment (which holds a reference to the file in the directory). The runtime application will hold the values specified in the directory. You can update the file, but need to redeploy your application in order to get those new values into your application.

        The only problem here is that I searched for hours and hours in Mule’s documentation on how to use something like binding files. They should promote these best practices way better than they do now. It just doesn’t make sense.

  • Tarun Kumar Garg

    Thanks Saravana for detailed response.

  • This is a great dialog. At SnapLogic, we wrote a series of posts on integration platform as a service (iPaaS) requirements and why some of the traditional approaches of the ESB won’t fly in the cloud. I know this discussion isn’t cloud-specific, but it is focused on the modern social, mobile, analytics, cloud (SMAC) requirements. With the pressures for greater speed and agility driving a rethinking of integration in the enterprise, I’d love to get feedback from this audience on what we believe you should look in a modern integration platform:

    http://www.snaplogic.com/blog_what-to-look-for-in-a-modern-integration-platform/

    • michael stephenson

      would you be interested in presenting at a UK Connected Systems User Group webcast session sometime, maybe you can tell us more about snaplogic and some of your thinking around this space and it could be a good forum to begin with engaging with this audience?

      drop me a line on twitter @michael_stephen if you would like to discuss

      Cheers
      Mike

  • Interesting discussion, as we are currently doing research which EAI/ESB-tool to choose for our company (worldwide). During our project we setup a shortlist of 3 possible candidates: BizTalk, Mule and WSO2. As we are in the PoC-phase I think this discussion of a comparison between BizTalk and Mule can be used by us to challenge the BizTalk and Mule-consultants some more 🙂

    @Rob Fox : didn’t know you where into BizTalk and Mule! Need to talk to your girlfriend some more 😉

    • Rob Fox

      Ow haha. It’s a small world after all. You know where to find me if you have any questions regarding the subject. I will hit you up on facebook!
      I wouldn’t recommend WSO2 btw, since its installbase is quite little over here, thus a small community. Haven’t worked with it though.

      • 🙂

        And yes, I know WSO2 has a small install base, but their tools look very interesting and they have a integration _suite_, so all the integration questions can be handled within 1 framework (Carbon). But will see during the PoC if they can handle our process in a good way.

        • Rob Fox

          Let me know what your experiences were with WSO2! We dropped WSO2 in a comparison with Mule, Fuse and Talend because of the adoption, but also because it seemed overly complex compared to the others. It kinda wants to do everything and wasn’t right for the use case with that client. Good luck!

    • MikeStephensonUK

      Hi Cyril

      This is not 100% applicable but I think it might help you. We were recently doing a similar thing to what your doing but around API management rather than EAI/ESB. One of the things I did was to create a challenge for the vendors. It was basically a small set of sample use cases that we asked them to demonstrate that they could implement and to talk us through how they would do it. This was really useful to us because one of the vendors really stood out above the others. This can help to identify issues with the products but also the vendors capability.

      I think if I was trying to sell a BizTalk solution and in a compete against mule I would be trying to get a customer to be thinking about durable publish and subscribe patterns, long running processes, and recoverability scenarios. I think if I could get the customer to include these scenarios in their key requirements then it would highlight weaknesses in Mule and push things in my direction. I think Id also show the customer how I can change settings at runtime without re-deployment and maybe some dynamic stuff based on rules execution or something like that.

      If I worked for Mule I would be trying to do similar but be focusing on the fact biztalk requires more infrastructure stuff, that development might be a little easier.

      I think if your a customer you need to think about a small number of scenarios which are important to you and then try to make sure the vendors demonstrate the products capability and their own competence to talk about it and also actually do it.

      Hope this is useful and if you want to some more info on the API comparison let me know im sure i can dig out some of the ideas it was based on

      Cheers
      Mike

      • Hi Mike,

        thank you for your opinion!
        We are doing something like you also did, we I think we go a little bit more further with it.
        We asked the 3 vendors to do a Proof of Concept of a process which is very important to us. We gave them a process flow and description of the _as is_ situation. Then we asked them to come over to us and tell us how they would ‘migrate’ the current situation (spaghetti) to a situation where their tool is in place. After this we’ll setup _together with the consultants_ the process flow in their tool. This way we can see how they think, how they work (discussion, development) and what the tool is capable of (technical, overview of developed work, debugging/track/trace).
        We already had one (BizTalk) of the PoC’s and 2 more to come in the next 3 weeks. I really am curious how Mule and WSO2 can implement our process as their are some things which aren’t standard available in Mule and WSO2 (like EDI-message handling), but are in BizTalk.

        • gfepi

          No EDI-message handling? that means you need an external EDI partner

          • It’s depending what you mean by ‘external EDI partner’.

            Message receiver/broker: In BizTalk you have an AS2-server included, but this is not the case in Mule/WSO2. X.400-messaging is in none of the tools included which means you always need an external tool including a connector (for BizTalk there is a tool from Quibis to setup a connection to a X.400-mailbox)

            EDI Interpreter (understand EDIFACT (in our case) and convert it to XML): this is also included in BizTalk (and yearly updated), but for Mule/WSO2 you’ll need an external tool called ‘Smooks’. (a Mule sales manager informed me that from the next major version ‘a EDI-interpreter’ will be included).

  • Akshay Shaha

    Thanks Sarvana, Micheal for this article which will remove the confusion on the concerns raised in Blog related to BizTalk.
    Thanks Rob for the real world experience with MuleSoft.

  • Sajith C P

    Very interesting article and some really nice real world experiences from the community. Thanks to Mike and Rob for sharing your views. The case study that Mike is referring to can be downloaded from http://www.mulesoft.com/case-studies/soa/sumitomo. I cant stop laughing when SCAO says “We were able to move from our legacy BizTalk solution to MuleSoft’s more complete Anypoint Platform in just six weeks. The entire process was seamless to our end users.” BizTalk is already Legacy..LOL

  • Saravana, nice article. Thank you so much for this absolutely necessary clarifications. Giuseppe

  • Dustyn Lightfoot

    Hi Saravana,
    Great article .. thanks.
    I was just wondering what you meant by “The ability to dynamically construct itineraries”?

  • End user site

    Mulesoft need to be thinking about how prospective customers will view their article. I’m always wary of vendors who run these sorts of campaigns as it doesn’t inspire trust.

  • Hello everybody,
    What about the overhead of BizTalk vs MuleSoft?
    We are currently using BizTalk 2010 and consider migrating to another vendor (open source is not a must).
    Our main problem with BizTalk is the overhead it takes for even the simplest orchestration (due to the fact that BizTalk is statefull). In most cases we do not have the need for statefull workflows.

  • Denis Forzy

    Many thanks for this post, I’m in competion with mulesoft in the company where I work.
    I try to convince bizTalk is the good platform but I can’t provide enough arguments, this post help me. don’t hesitate to give more information.

  • Hi Saravana, very nice article. It was refreshing to read through the item by item analysis on the key integration features of Biztalk and Mule. Each have their pros and cons.

    In the context of allowing non-technical users be able to setup solutions I would like to have you look at Adeptia which is a browser based Integration software meant for business users to collaborate and configure integration solutions. Adeptia supports EDI translation, graphical Mapper and process designer, monitoring, long running transactions, human workflows.

  • Great to see someone with BizTalk expertise to defend a good matured product, recently I had the opportunity to work on Mulesoft anypoint platform, so I thought I can give my perspective here, First of all the person who wrote the article about BizTalk from Mulesoft corp seems to be lacking knowledge about Service bus concept, Mule ESB doesn’t have Publish-Subscribe support, it has a concept called VM’s which is sort of more like a Queue mechanism, so I don’t event know how they can call it a ESB without pub-sub architecture, Secondly AnyPoint platform is a light weight compared to full fledged EAI tool like BizTalk, it has better interface in API management space, so its wrong to compare API management software with EAI products, there is no comparison yet all, also the author should have compared Mulesoft Anypoint platform with Azure API management if he really wanted to take on Microsoft.

    • glawson6

      Mule supports Pub-Sub with JMS topics. Please read up on this and not misinform readers.

  • MSBassSinger

    Saravana, this is an excellent article. My only suggestion is that you invest in someone fluent in English (American or English) to clean up the article for English-speaking readers. Another suggestion is to locate someone in Microsoft that is knowledgeable on Mulesoft. I am sure they have someone that provides competitive analysis from a technical perspective.

  • Rajeev Singh

    Hi Sarvanan,

    Thanks for writing this Blog. We have a requirement for on prem Biztalk 2013 where
    Customer has asked to leverage the API management and Microservices separately and propose them with the Technical Diagram. Going through many arcticls, I can see
    Microsoft has started supporting RestFul Services as an API but could not see
    any thing on API management for Biztalk 2013.

    Even for Microservices, it’s only for Azure.

    The way IBM has it’s own API catalog like API Publishing, API discovery, Market Place, API
    metadata, does Biztalk 2013 supports all these?

  • mule esb enterprise

    It’s a great blog. It’s also about how to manage your solutions and the messaging that is flowing through it.I wonder if it has something to do with large investments in Mule soft last year which has potentially created a new commercial pressure.

  • Rohini

    Hello Everyone,I am Learning mule esb 3.7 and created one mule project using anypoint studio.Now i wanted to run my mule project 24/7 ,but i dont know how to do that .please help me

  • >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.

    An open caution to anyone who reads these words – it’s an easy thing to say…

    As a parallel example, as a Microsoft evangelist I touted the extensibililty of SQL Server Reporting Services since it was introduced in 2003. “Every part of Reporting Services is completely extensible” I would say. Well a few months ago I had the opportunity to put my money where my mouth was – the best solution for a given project was to create a custom data processing extension for SSRS.

    It was a nightmare. Essentially the extensibility was on life support. Capabilities and documentation pretty much all dated back to SQL Server 2008, and very little had been updated to reflect the new SharePoint integration. There was no consideration in the documentation for working with projects across different architectures either. An extension had to work in the Visual Studio IDE, with the Visual Studio rendering engine, and with SSRS in SharePoint, each of which runs on different versions of the .Net Framework (not documented anywhere)

    We eventually junked the project because we could not make it stable across environments.

    A great promise, but don’t bet money on extensibility until you can talk to someone who’s actually written the code to do so. Also validate documentation and support.

  • Royal Ram

    thanks

  • yes, the paid R&D team seldom does anything new, they will only be only basking under the glory of the things achived as a 22 year old,

  • ok get your point now, but the unfortunates have already moved to IBM IIB or Oracle long back, no need to worry about loss of business to Mule now. Only the cash strapped are adopting this change for cost of maintaince and licencing now.

  • Run Without The Mules

    We have been developing on multiple ESBs for many years, in particular on mule, enough to know that Mulesoft has more unfixed bugs than they claim to have connectors. If only half of the connectors would work properly or handle load… Also that Mulesoft marketing is selling smoke and mirrors. Landgraf often writes blog contents without facts in search of a negative angle he can’t even comprehend. He should better try to sell Mulesoft based on their product strengths. Unfortunately there is no particular products strength that other open or closed source ESBs don’t already have. The world of ESB is very leveled, every product is equally good as its competitors, it is just a dirty marketing battle. Mulesoft documentation seems to be geared towards marketing weenies and beginners more than for experienced developers. Everything passes the POC sniff test, but you are so remote from deploying anything in production. CTOs should learn how to smell the Mulesoft slimmy message, I am always surprised to hear the reason why a client selected an ESB vs. another one. Whether they are aware of it or not, CTOs keep buying in exactly the same vendor lock-in BS as with other vendors. Mulesoft is not trying to sell a better product, they are just fueling their upcoming IPO. Don’t fall for it, ask the right questions and negotiate aggressive license prices. After all there is no catalog price… do your homework, call the client list, request evidence of what they paid for and ask to pay less. We also have experienced Mulesoft support SLA to know that unless you dropped a load of $$$ in licenses you are likely to find your own answers before support solves it for you.
    We get hired for cross ESB comparisons 9 times out 10, feel free to hit us with your questions. At the end of the day every ESB is a great tool, don’t listen to Landgraf… he badly needs a hair cut.

    • EJC

      Hi Run. I’d love to pick your brain wrt ESB comparison. Can we chat?

  • Thanks foe sharing info on Our response to mule esb blog “10 Reasons to Walk from BizTalk

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top