Open source middleware: is Mule ESB the Next Big Thing?

Some of you may or may not know that I have been busy with a Mule ESB implementation last year. Partly because I had some time in which I could help a client and partly because it never hurts to dive into a new technology and see for yourself what it’s like. It never hurts to know what else is on the market, especially in open-source-land.

Getting lost in an open source world

My journey last year started with examining open source middleware solutions and finding the best one for my client. They wanted to go open source, so BizTalk, Tibco, IBM and Oracle were no option. I used Gartner’s Magic Quadrant for On-Premises Application Integration Suites to find the solutions to compare. I ended up comparing Mule, Red Hat, Talend and WSO2.

I spent evening on evening getting the tools to work. I haven’t had so much problems installing things, since the first time I tried to install Linux back in the 90s. Which platform should I choose? Red Hat? Fedora? Ubuntu? And what do all those abbreviations mean? I ended up in exactly the same mess installing these middleware solutions, mainly because it lacks documentation.

As an application platform you can either use JBOSS. Or you can use Tomcat. Or Apache. Or some kind of distribution of Apache. But you’ll first need to install Java 1.7, or 1.8, make sure you manually change the PATHs.  Then you’ll need to setup Maven, to deploy stuff. Or maybe you don’t need to setup Maven and just go with a different framework. Uhm… it’s too much for this closed (but more and more open) Microsoft fellow 🙂

It soon became clear that the best open source solution out there was Mule. It wasn’t the cheapest, but it appeared to be the one the farthest down the road when it comes to installing, development and maintenance. It works with Eclipse and comes with a workflow tool, a visual mapper and a portal to maintain your runtime environment. It’s also a “one click” install (just download, unpack and start). So the client went for Mule. Little did I know.

Mule ESB

MuleSoft is putting out ads like there’s no tomorrow. It’s everywhere. They are writing blogs almost stating that there’s no better middleware solution than Mule ESB. I have experienced it first hand and let me start by saying that

Mulesoft themselves may think Mule is the Next Big Thing, I am afraid it may cause a wave of problems for companies once down the road.

It’s quite a bold statement and I must admit I am looking through a Microsoft looking glass. There are things I really like about Mule and there are quite a few things I really don’t like. My biggest concern isn’t about developing in Mule, on the contrary, that’s all fairly OK. Runtime, that’s my concern. Mule has done a good job when it comes to development, but if it wants to play in the big league, it has a long way to go when it comes to runtime.

It’s almost impossible to find out what’s going wrong in a flow without opening numerous logfiles and don’t even think of resuming a flow if a dependent system is down. Closing single ports/connectors isn’t possible and if a system changes its IP address, you need to redeploy your solution.

Pricing

Why is Mule so mysterious about their licensing fees and licensing model? Why can’t they just publish ‘m up on their website, just an indicating what it will cost? Just like Microsoft does with BizTalk. I think it’s quite suspicious. A company that uses an open source platform and is not quite that open when it comes to money.

Since Mule will adjust quotes based on, uhm, nobody knows, I will try and give you an idea how it works. Mule uses a subscription based fee. That means you will pay a fee every year for the use of Mule ESB. You get a license key, which you will be loading into your system every year. And you pay a fee for every environment, be it production, acceptance, test or development. Production being the most expensive, and you can always go for a free community edition for development.

All and all you are probably looking at a $20,000+* annual license fee for a single production environment (4 cores, 8 GB RAM) and little over $10,000 a year for other environments (ACC, TST). Add it up and you are looking at about $40,000 a year – for a company in the public sector by the way. So if you consider that BizTalk has a $40,000 one-time fee (and that’s around $16,000 for companies in the public sector, like hospitals or schools), you may want to reconsider the general thought that open source is cheap. Even if you add probably around $25,000 for SQL Server, BizTalk will still be cheaper if you’re not planning to upgrade within two years.

* This is the number I’ve got from Mule for a company in the public sector. Since they are not transparent about their licensing fees, it’s impossible to tell whether the fees differ per sector or maybe per company.

Documentation

I have my doubts when it comes to Mule’s documentation. I am always trying to find stuff that can’t be found. And if there is an example, please offer examples I can actually use. It resulted in a lot of trial-and-error programming. Also server installation documentation is lacking. A walk-through about installing Mule ESB and best practices would be very helpful! 

And books? There are exactly two (or maybe three) books on the market. Both books only handle the basics. “Mule ESB Cookbook” was useless to me. Most of the stuff in there were so basic they should have called it “Mule ESB for dummies”. The other one “Mule in Action” is much better, but still handles the basics and wasn’t much help to me once I started developing.

Anyone claiming that BizTalk documentation is lacking, should really reconsider. Microsoft provides us with extensive documentation and an Installation Guide. Besides that, BizTalk has a strong community publishing articles, videos and organizing numerous events.

The not so big community

Mulesoft claims to have a big and active community backing the company. The truth is that it’s not quite that big. And I can easily proof it. If my blog posts are ending up on the first page of search results on Google, I either have a tremendously good nose for SEO or – and this is my guess – the community isn’t that big really!

I have come across numerous problems I couldn’t find a solution for. The easiest of problems can’t be solved with Mule’s documentation and there’s no blogpost about it? Good luck with that one! Hopefully my few posts can help you along the road 🙂

Development

Mulesoft uses Eclipse for its development environment and calls it Anypoint Studio. I like the openess of Eclipse, the ability you can plug nearly anything into the environment. But I really don’t like working with Eclipse itself. It has become more and more bloated over the years and has a look and feel to I really don’t like. It just throws you back to the Windows NT era. There’s a reason why Android developers rather work with ItelliJ.

Mule is offered in a download, bundled with Eclipse. You unzip the download and can start working in Mule instantly. That’s really fantastic! (and I am not kidding this time). OK, the only thing you need to take care of is getting the right Java JDE in place, but haven’t we done that more than once in our lifetime?

Debugging

Another thing I really like about Mule is the debugging capability. You don’t need to go through a deployment process. Eclipse will start an instance of Mule ESB Server and you can instantly test and debug your solution. It’s great and really helps speed up the development process.

The Visual Mapper

Render it useless. You can use it for mapping a few fields that are on the same level. When it becomes just a little bit harder, or nodes are on different levels, you can’t use the mapper anymore. I also ended up having to recreate my map several times, e.g. when I replaced the source or target object. There’s no way of mapping EDI, HL7 or other more advanced standards and don’t even think of calling managed code from the mapper. It’s just impossible. No, in the end everybody ends up using Java to transform their payload.

Mapping in Java works pretty well in Mule and is a good alternative. So what’s my biggest problem here? The visual mapper is an enterprise feature and it’s useless.

Flows

Developing flows is pretty easy. It’s just like every other “drag-and-drop” development tool, just drag shapes onto a canvas. Mule uses XML to store the flows, which makes it easy to go into the code and do some stuff. And believe me, you will have to go in there more than once if you are developing for Mule. Not everything is supported by the flow designer and has to be done in the XML source. If you want to use Spring features, you will end up in the XML source itself. Add namespaces, undocumented XML nodes etc.

Flows use one single payload, that changes all the time. If you do a service call, you’re original payload will be replaced with the new one. If you do a mapping, it’s the same thing. Luckily you can preserve payloads in variables, but if you are using a lot of variables, it’s hard to keep track of all of ‘m. What did you name the variable again? And what is in it?

The flow designer is also not without bugs. Sometimes you try to drag a shape, maybe even re-arrange your flow. But be careful! Clicking away from the flow and coming back may cause your changes to get lost. It happened to me more than once. After this happened to me a few times, I am only rearranging my shapes in the XML source, making sure nothing breaks.

Ow and one more thing. Horizontal scrolling? Who thought of that? Probably a Mac user with a magic mouse or trackpad. As long as most of the mice in the world are equipped with a vertical scrollwheel, I want have a pane that scrolls vertically (or make sure the pane scrolls horizontally if the scrollwheel is used).

And there’s this other thing as well. Zooming? Not possible. This of course only becomes a problem with bigger flows.

Runtime

But I am not concerned about development in Mule ESB. My biggest concern is its runtime environment. I just wouldn’t want to be the bloke maintaining it, because it’s damn hard to know what’s happening on your server. And having a stable production environment is way more important than the time it took to develop something.

One of BizTalk’s main pros might be that it’s database driven. You always know what’s happening on your server. It comes with a downside too, it has a negative performance impact. Mule on the contrary is very fast, because it isn’t database driven. But it makes it very difficult to know what’s going on. In many cases, especially in an asynchronous world, insights might be more important than speed.

MMC – Mule’s very lightweight console

Mule’s runtime can be managed from MMC – an enterprise feature. And you can uhm… do some stuff with it. The most important things you can do are (1) register servers, (2) deploy, start and stop entire applications, (3) track some stuff (but only if enabled) and (4) set some alert rules. Ow and you can manage MMC users! 😐

In a nutshell, it’s not very useful and this also is an enterprise feature.

Tracking

Mule doesn’t track activity of your flows. Sure it can track your flow’s activity, but only after you enable it. And if you enable it, it can cause such a big load for the server, you can only enable it for a short while. It makes it impossible to know if your flow is working or not. You can only react after damage has already been done. Maybe if you log enough stuff, you might be able to find out what went wrong.

There’s also nothing like BizTalk’s BAM in Mule. BAM is sort of a BI tool to help you get real insights regarding your messaging system. Since Mule lacks tracking and something like BAM, insights are just impossible out of the box. You will need to take care of that yourself (writing stuff to a database for instance). And taking care of it yourself, exactly, has a negative impact on development time.

Flow control is abysmal

In Mule, a flow is a flow and either works or it doesn’t work and if something’s wrong, it will return an error. There’s no possibility of resuming flows that couldn’t connect to a database, or an SMTP server that was down. You have to implement this retry and resume behavior yourself. Route errored messages to a certain queue for instance, since you don’t want the source system to resend all those messages because of connection errors on your side. Implementing this behavior yourself, will of course have another negative impact on development time.

Then there’s the problem of starting or stopping ports (or call it connectors). You may want to disable, or queue up messages, going to a certain system, e.g. if it’s down for maintenance. But it can’t be done. Only on the receiving (activating) side. It has to do with the same problem I mentioned in the previous paragraph. You can’t resume flows, it’s basically one atomic transaction.

Pub-sub (publish and subscribe) is also unknown in Mule ESB. You have to develop a flow, even for the simplest of routing mechanisms. It’s weird. But maybe it was a deliberate choice and you should go with JMS. But then you can’t easily transform the messages.

(Re)Deployment and configuration

Deployment is straightforward and very fast in Mule. You can either go for hot deployment or go for manual deployment in MMC for instance. It’s a good thing that deployment is fast, for you can’t change configuration on a deployed service! That’s right, you can’t change an IP addresses, a computer name, a port, usernames or passwords on a deployed service. You need to redeploy the entire service. This isn’t a big problem if it contains a single service, but what if it contains many flows? It will cause downtime for all those flows.

And a different weird thing has to do with HTTP. You can only use one IP Port per container/application. So if you have several flows in several applications, you won’t be able to use the same port for HTTP. So there’s just one application that can use 8080, another 8888 etc. Apparently this issue may have already been taken care of in Mule 3.5, but I haven’t been able to test that.

Connectors / adapters

Let’s end with a positive note, favoring Mule. The number of connectors is amazing! You can connect to nearly anything out there! Just keep in mind that most of the connectors are built by the community and may not have been fully implemented or tested thoroughly.

Conclusion

All and all I don’t like Mule ESB too much, but I guess you’ve noticed that. Not a lot has been written and told about Mule, so I decided to make this blogpost. In my opinion Mule ESB just misses key features that should be present in a middleware platform. Think of features like tracking and being able to queue up messages whenever it’s needed. I also shouldn’t have to ask the party consuming my service to resubmit messages if some of my dependent services go down. All this will just result in a runtime environment that’s hard to maintain.

Development wise Mule has done some good things! Debugging is a joy and also design and development is fairly easy, but not without bugs. The visual mapper is useless, but mapping in Java is a good alternative. Documentation is really not on par with other (non-open source) systems. Mulesoft really needs to work on that and provide extensive installation guides and best practices.

Of course BizTalk isn’t without problems as well. I still don’t get why some screens in BizTalk are still not resizable for instance. And debugging isn’t quite as easy as in Mule for sure. But BizTalk is really easy to maintain in a runtime environment. And that last bit is really important. That’s what your customers are using!