MuleSoft CloudHub Versus On-Premise Implementations

MuleSoft’s ESB (Enterprise Service Bus) product suite is offered in three primary forms: licensed On-Premise version, PaaS (Platform as a Service) Anypoint Platform (Cloud Hub), and MuleSoft CE. For the purpose of this post the focus will be a comparative analysis of CloudHub and On-Premise. Pros and cons exist for both products, and each have distinctive features that should be considered during the decision-making process for your organization. In a nutshell, it can be factually stated that some of these features are:

Features
CloudHub
On-Premise
Technical Details
Configurable VPC, Whitelisting
Yes
Yes
CloudHub offers a nice interface for you to set up your Virtual Private Cloud, whitelist connections to your Virtual Private Cloud (VPC) and much more. Furthermore, you can set your own in your datacenter, with your network team and proper allocation of time and resources.
Load Balancing
Yes
No
CloudHub version comes with a load balancing feature that allows configuration of load balancing after you set a VPC in your environment. With the on-premise version, you would need to purchase your load balancer, licenses and hire an expert to set it all up and additionally have this resource work in close collaboration with your Mule resources.
Hands-Off Server & Host Management
Yes
No
CloudHub (CH) as the name implies is all cloud based and you don’t have to worry about anything (they just hand you the tab). On the other hand, the On-Premise version requires you to have all of your infrastructure set up and ready on your own with your resources (you know how that goes, right?)
Simple Vertical Scaling of your Applications
Yes
No
CH allows you to add more vCores and workers to a particular application with, literally, a couple of clicks; this is a very cool feature. With On-Prem, on the other hand, you need to buy your server, commission it, install all the prerequisite,s and much more just to add one more server.
Customizable Hosting Settings
No
Yes
On-Prem does offer the flexibility to set up your load balancing, domains, VPC, and anything you want to do to your environment as you will be building it in your own data center. With CH you get many features, however, they are only customizable to a certain extent and you’re limited by what CH allows you to do in the web interface.
High Availability Architecture
Yes
Yes
You can implement this in both versions of the product. However, note that for On-Prem you would need to configure your Mule Management Console or Anypoint Runtime Manager and have the necessary servers you want and need for you HA set-up. With CH it’s just a couple of clicks.
Custom log4j for Logging
No/Optional
Yes
CH only offers limited customization of log messages, where with the On-Prem version you can configure and append your log4j.xml, as well as roll your logs as you please.
One Click Trivial Mule Runtime Upgrade
Yes
No
Upgrading Mule On-Premise is painful. You must install the new Runtime, move all your projects to the server again, make sure you have the applicable Java version, all environment properties, domains additional dependencies, and more on each of your servers to upgrade. In CH, it is as simple as a dropdown (a couple of clicks, you just have to make sure you test properly in your local environment with the correct runtime).
Application Properties Management
Yes
Yes
You can have externalized properties files in both versions of the product. One cool aspect of CH is that each application has a properties tab in which you can specify properties and then restart your application. This allows for very quick and painless property changes that developers tend to make.
On the Fly Process Kickoff and/or Scheduler Modification
Yes
No
Schedulers (poll components) can be enabled/disabled, changed or kick started immediately during runtime without changing the underlying application pretty neat if you have application integrations that need to fire on a schedule. This feature is not available for On-Premise.
Automated Alerting System
Yes
Yes
Both versions allow for automated emails when thresholds are not met on your desired infrastructure metrics.
Clustering Specific Servers
No
Yes
With On-Prem, you can cluster specific servers that you have in your infrastructure and set them accordingly. With CH you can only scale on a per-application basis and not with specific workers (you only supply the amount of vCores and workers you need and the replication and clustering is taken care for you).
Static IP Assignment
Yes
Yes
Both versions offer simple ways to create static IPs. CH interface, again, is just a couple of clicks but you can do the same with your network team’s help and coordination.

General Pros and Cons of CloudHub versus On-Premise:

Based on the table above, the CloudHub version looks like the no-brainer option, right? However, like anything in this world, really nice features and convenience does not come cheap. The CloudHub option only allows up to 10 applications per vCore and each vCore is expensive. However, from the experience acquired by working with CloudHub over many years, some of the features might be worth paying for (depending on your particular situation). Overall, MuleSoft’s CloudHub, as with many similar cloud-based technologies has tremendously evolved over the last few years, giving customers almost all of the features as if the solutions were implemented in your data center. Among the most useful features implemented on CloudHub are: VPC offering, custom firewall rules, proxy server implementation, and out of the box load balancing (for more details please see these mulesoft runtime manager docs). The only real technical drawbacks are the fact that you would not be able to access local file systems, transfer files among applications, and there are some constraints while using objectstores (in memory DB). There are alternative cloud solutions, like using Amazon queues, S3, and other cloud technologies to mitigate the impact. With that being said, customers usually don’t need a whole lot of extras when facing a particular CloudHub limitation.

As for the On-Premise version of the Mule Runtime, there are some things to consider. In my opinion, the most burdensome is the time and knowledge required to correctly install, maintain, and upgrade the Mule Runtime, in addition to also the version of Java SDK/OpenJDK, operating system and all other components your application stack is going to need. This requirement might not seem like a large burden for the technical or the computer geek types, like most of us in the IT industry, however, from a CIO/executive management and human resources perspective it is a real nightmare and a potential point of failure that should be avoided, especially if all it takes is some dollar bills upfront. Additional to this cost is: the load balancers, firewalls, and all the other network components that might be necessary to make your application compliant with your organizational and departmental standards. Furthermore, as an on-premise installation will take place in your data center you would be responsible to ensure they are done correctly and properly maintained for the entire lifetime of your Enterprise Server Bus (ESB) needs. Having all the needed elements installed and implemented correctly and by qualified individuals is a lot easier said than done for many reasons, but that’s a topic for a later discussion. The point here is that correct installation and best practices will involve a whole lot more than just a couple of clicks and unzipping files.

Have You Ever Seen a Hybrid Unicorn?

With the rise of services such as Amazon EC2 web services platform and Windows Azure, among many others, there are “hybrid options” that some organizations have been able to successfully leverage. In my own, very subjective opinion, the most prominent and common option is to install a Mule Runtime with an on-premise license in a cloud-based Linux server such as those offered by Amazon Web Services. With this “hybrid solution” you avoid some of the limitations by both the CloudHub and the on-premise installations, but not all of them.

With the hybrid solution, you eliminate the constraint of only being able to deploy up to 10 applications per vCore. Additionally, hand installing an on-premise Mule Runtime to a cloud-hosted server can avoid several of the drawbacks mentioned above such as need for load balancing, firewall, proxy servers, API gateways, and all the other disadvantages of a physical hosting server (services like Amazon offer these solutions out of the box at very affordable pricing). However, a hybrid solution still does require qualified resources to install the Mule Runtime, Java, and all other components that your particular solution would need, but in my honest opinion, this is not a bad middle ground solution if you are required to go this route.

Myths and Pitfalls:

1. CloudHub does not offer the necessary security features our executives and upper management would like.

   False. Today, with cybersecurity and data protection being a major concern for most companies, CloudHub has features that enable its customers to implement a Virtual Private Cloud, API proxy layers, Secure Socket Layers, API security protocols using LDAP, Oath2, etc., static IP custom firewall rules, secure properties placeholders, and many more components and features that can keep your application stack and your data very secured. Additionally, CloudHub is widely used in the banking, financial, and healthcare industries successfully where sensitive data is sent back and forth for countless transactions.

2. We can get all needed on-premise components easily installed by our staff.

   Easier said than done. Even though on average most IT teams are fairly competent at ESB installation, testing does require certain levels of expertise that are not all that common. A Mule DevOps Engineer must be really familiar with the intricacies of the Mule server, Linux, HTTP ports, networking, firewall, mule startup properties and sometimes many other technologies like Maven and Artifactory in order to install, maintain, monitor, and upgrade a Mule environment.

3. An enterprise ESB solution can be done inexpensively.

   Regardless of what ESB technology you use, and whether you decide on a cloud-based technology or an on-premise solution, an ESB implementation requires significant labor, materials, and expertise to be successfully implemented.

4. Network team will be able to implement what is necessary very quickly and inexpensively for an on-premise solution.

   Probably one of the most common pitfalls. Network problems like port openings, firewall rules, and load balance testing, among many others, are by their own nature difficult and can be tricky to solve. More often than not, it takes a very proficient and knowledgeable Mule resource, in close communication and coordination with a network resource, to detect and resolve a network issue. Wrong resources aiming to solve issues of this nature may actually cause your entire implementation to fail.

5. With CloudHub we can ensure that our platform will be up 100% of the time and it will be 100% reliable.

   Nothing in life is 100% guaranteed, and neither is CloudHub. Even though it’s a very reliable platform and seldom goes down, the truth is that it has happened in the past and undoubtedly will happen in the future. MuleSoft does have proactive monitoring and alerting as well as outstanding after incident analysis and report to its customers, however, like any other company run by humans, systems are not 100% perfect and things can and do go wrong.

6. Changes to an application and deployments are a lot easier in CloudHub as compared to On-Premise.

   Solid best practices and a release management policy must be implemented in your team regardless of which implementation you choose. Yes, CloudHub does facilitate some aspects of the deployment process, however, bad practices and rogue deployments of apps can easily cause lots of headaches.

7. Architecture is much simpler in CloudHub compared to On-Premise.

   False. The architectural advantages of CloudHub rely mostly on the hands-free maintenance and scalability aspects of an application stack. This allows for your architects to focus and shift more towards the architecture of your actual solution application rather than on the infrastructure architecture of your organization.

About the Author

Rene Lucena is an Integration Solutions Architect with Mountain State Software Solutions (ArganoMS3). He graduated from the University of Oklahoma with a Bachelor of Science in Computer Engineering and has since accumulated 14+ years of experience with in IT positions including those in Gaming, Web Development, Research, Hardware Design and Troubleshooting, Analysis, Test Engineering, Sales, Project Coordination, IT Software Procurement, DevOps, SQL Development, IT Governance, SDLC, Test-Driven Development, APIs and Leadership. He also has the honor of being a Mule Certified Developer.

Disclaimer: This article specifically and factually outlines the features of a CloudHub implementation and those features as compared to an On-Premise solution. Despite the definite advantages to using CloudHub, it is important to note that CloudHub is not necessarily the right architecture for every organization. Every organization is different, and the specific needs of your organization will help to determine whether CloudHub or On-Prem is right for you. Consultants at ArganoMS3 are fully equipped and trained to assist your organization in choosing the best architecture for your needs and to support you through both CloudHub and On-Prem implementations. For more information about choosing the right solution for you please contact us at contact@ms3-inc.com.