Integration PaaS, Mule iON in private beta – Brief Note

Yesterday, MuleSoft announced a private beta for their PaaS platform, Mule iON, squarely focused on helping people do integration tasks around cloud-based applications and services. They call the concept “iPaaS,” an “integration platform as a service.” You can check out a bulleted, if high-level, feature list in yesterday’s press release.

“i” is for “integration”

I like this narrow focus on integration instead of just a general PaaS. It’s what you’d expect from MuleSoft’s background is in ESBs (Mule), Tomcat support (they seem to have built a new business around their “Tcat” server), and the open source world around the kind of tasks and applications (Java, mostly) you build around a bus.

Cloud Creep

I spoke with Ross Mason and Mahau Ma today, going over the announcement but mostly about the types of applications and work-loads they’re seeing people use in cloud-based projects. Some key take-aways:

• From the customer/user point of view, everything is wrapped up in iON. While it runs on a public cloud, the end-user interacts with the iON platform without needing to go muck with the underlying cloud.
• Last year, MuleSoft started providing Mule Cloud Connect (see an interview on the topic here) to help integrations between cloud and on-premise (and cloud-to-cloud, I guess). With all of the SaaSes out there (and Salesforce in particular, it seems), Ross said there’s been a big demand for integrating data between services. As he put in on the Mule blog a short while ago: “One of the drivers for Mule Cloud Connect was that we are seeing that traditional three-tiered application architecture is outmoded – Web applications today require integrating multiple data-sources and services, both in the cloud and behind the firewall, and presenting rich data to the browser in real-time.”
• This need for integration hits on something I’ve been starting to see: cloud-use is infectious in your architecture and even how you run your project. I’ve had a handful of conversations with people who’ve mentioned that once they use cloud for one part of their application (if only delivery), using it for more parts (all the way down to build and ALM) starts to look more attractive. To build on Ross’ comments from that blog: if you’re integrating your on-premise application with data in Salesforce, chances are good that you’ll start to wonder why you don’t move that on-premise thing into the cloud as well.
• As ever, Conway’s Law probably fits especially well here: you’d expect remote, distributed teams that are not centralized to build architectures that are equally “cloud-y.” For example, you could see how virtualized teams who work on cloud-deployed applications would really like moving all their version control to the cloud as well to places like GitHub.

And, indeed, that last point and the resulting transition is what Mule looks to be going after.

Disclosure: both MuleSoft and Salesforce are RedMonk clients, as is GitHub.