Tag: CloudHub

Adrian Hsieh on Tuesday, May 12, 2015

Fast and Slow through the Air


Handling endpoints with disparate speed when the platform is in the cloud

A fairly common integration requirement is to accumulate data coming in real-time or near real-time, hold and consolidate the records, then send the transformed messages to another system on a fixed schedule (e.g. daily etc.) for business reasons, especially if the endpoints are legacy systems. For on-premises integration platforms, this use case is rather straightforward to implement. For cloud-based integration platforms though, which are generally geared toward real-time processing and lack access to local file storage, this requirement does seem to pose some technical challenges. Fortunately for CloudHub, with the built-in persistent queue feature and the Mule Requester Module, the implementation is as easy as doing it with legacy on-premises platforms.

Fast and Slow

Fast and Slow can play nice together

We’re pleased to announce that for the second year in a row, Gartner has named MuleSoft a Leader in the Magic Quadrant for Enterprise Integration Platform as a Service (iPaaS). CloudHub, the cloud-based integration component of Anypoint Platform, was evaluated in the Magic Quadrant.

Ken Yagen, our vice president of products, noted, “Digital transformation requires enterprises to rapidly integrate SaaS applications and digital services from
business partners with their existing back office systems. This calls for broad API-led connectivity and deployment on a platform that seamlessly connects the cloud and traditional data centers. Gartner’s recognition is a testament to CloudHub’s leadership and significant role in an enterprise’s hybrid integration strategy.”gartner-mq-ipaas-diagram

Steven Camina on Friday, February 27, 2015

Light Up the Internet of Things


IoT Lights demo @ MuleSoft HQ

To liven up the 2nd floor of the MuleSoft SF office, we decided to showcase a slightly modified version of the IoT demo we gave in last year’s Chicago and New York MuleSoft Summits. The demo we have listens for any mentions of @mulesoft on Twitter. If found, a Mule app running on a Raspberry Pi makes the lights glow. Initially dim, the lights glow brighter with more mentions.

Now let’s dive into the specifics of this fun little demo we’ve created.

The genesis of this demo was a brainstorming session for a MuleSoft Summit keynote presentation. We wanted to show something that showcased IoT in conjunction with MuleSoft technology. We decided to simulate home automation via APIs, which essentially means using Internet of Things APIs to control the “things” around one’s home. In our case, the “things” we were controlling were Philips Hue light strips (which we shaped to form the MuleSoft logo). In addition, as is typical in many IoT architectures, we used a “controller” closely located to these “things” – think of how a Nest device (controller) manages the heaters (things) around a home. In our case, the controller we used was a lightweight Mule app running on a Raspberry Pi, which connects to both the external network to receive information, and to the internal network to control the lights.

I am excited to announce release 39 of CloudHub! This release is based on a lot of user feedback, and contains a beta of our redesigned user interface as well as one of our most requested features – CPU & memory.

Redesigned Experience

We’ve been hard at work the last few months building a revamped user interface which helps you be more productive and integrates seamlessly with the Anypoint Platform for APIs. We’re excited to preview some of that work today. You’ll notice a clean, modern interface that makes it easier to get things done. For example, the the home page now provides easy access to your applications, settings, and logs at a glance. It now also has a handy summary of resource utilization and the number of recent transactions processed.

This is the third post on the Gradle Plugin Series, and a lot has happened to the plugin since the first article of the series was published. Today, I’m announcing exciting new features useful for tackling enterprise users’ needs. For more information on how to get started on building apps with gradle, please check the previous blog post and specially the project’s readme file. Now let’s get started.

Fine tuning Mule Dependencies

This plugin is designed to be future-proof and still remain concise, so we’ve introduced a DSL for customizing the mule dependencies to be included as part of the build. This allows users to (in a very concise way) fine-tune the modules, transports and connectors included when unit-testing, compiling your code and running your app.

In this post we are going to discuss a few emerging trends within computing including cloud based Database platforms, APIs and Integration Platform as a Service (iPaaS) environments.  More specifically we are going to discuss how to:

  • Connect to a Microsoft Azure SQL Database using Mule ESB  (for the remainder of this post I will call it Azure SQL)
  • Expose a simple API around an Azure SQL Database
  • Demonstrate the symmetry between Mule ESB On-Premise and its iPaaS equivalent CloudHub

For those not familiar with Azure SQL, it is a fully managed relational database service in Microsoft’s Azure cloud.  Since this is a managed service, we are not concerned with the underlying database infrastructure.  Microsoft has abstracted all of that for us and we are only concerned with managing our data within our SQL Instance.  For more information on Azure SQL please refer to the following link.


In order to complete all of the steps in this blog post we will need a Microsoft Azure account, a MuleSoft CloudHub account and MuleSoft’s AnyPoint Studio – Early Access platform.  A free Microsoft trial account can be obtained here and a free CloudHub account can be found here. To enable the database connectivity between MuleSoft’s ESB platform and Azure SQL we will need to download the Microsoft JDBC Driver 4.0 for SQL Server which is available here.

Mariano Gonzalez on Tuesday, March 25, 2014

Batch Module Reloaded


With Mule’s December 2013 release we introduced the new batch module. We received great feedback about it and we even have some CloudHub users happily using it in production! However, we know that the journey of Batch has just begun and for the Early Access release of Mule 3.5 we added a bunch of improvements. Let’s have a look!

Support for not Serializable Objects

A limitation in the first release of batch was that all records needed to have a Serializable payload. This is so because batch uses persistent queues to buffer the records making it possible to processes “larger than memory” sets of data. However, we found that non Serializable payloads were way more common that we initially thought. So, we decided to have batch use the Kryo serializer instead of the Java’s standard. Kryo is a very cool serialization library that allows:

  • Serializing objects that do not implement the Serializable interface
  • Serializing objects that do not have (nor inherit) a default constructor
  • It’s way faster than the Java serializer and produces smaller outputs

Introducing Kryo into de project did not only made batch more versatile by removing limitations, it also had a great impact in performance. During our testing, we saw performance improvements of up to 40% by doing nothing but just using Kyro (of course that the speed boost is relative to the jobs characteristics; if you have a batch job that  spends 90% of its time doing IO, the impact in performance won’t be as visible as in one that juggles between IO and CPU processing)

Today I will introduce our performance test of the Batch Module introduced on the Mule’s December 2013 release. I will guide you through the test scenario and explain all the data collected.

But first, if you don’t know what batch is, please read the great Batch Blog from our star developer Mariano Gonzalez, and for any other concerns you also have the documentation.

Excited? Great! Now we can start with the details, this performance test was run on a CloudHub’s Double worker, using the default threading profile of 16 threads. We will compare the on-premise vs cloud performance. Henceforth we will talk about HD vs CQS performance. Why? On-Premise and CloudHub users will be using by default the HardDisk for temporal storage and resilience but, this is not very useful on CloudHub as if for any reason the the worker is restarted, the current job will loose all its messages, then if  Persistent Queues are enabled the Batch module will automatically store all the data with CQS (Cloud Queue Storage) to achieve the expected resilience.

We are all very proud to announce that Mule’s December 2013 release shipped with a major leap forward feature that will massively change and simplify Mule’s user experience for both SaaS and On-Premise users. Yes, we are talking about the new Batch jobs. If you need to handle massive amounts of data, or you’re longing for record based reporting and error handling, or even if you are all about resilience and reliability with parallel processing, then this post is for you!

CloudHub Release 34 is now live! With this release we’ve made a number of improvements to CloudHub to make managing your integrations easier. These include the ability to promote applications from sandboxes, monitor workers for problems, create secure environment variables, and scale applications vertically, as well as horizontally.