Part of the Orange Group

Back to Blogroll
Systems Integration

4 min read

How to choose the best implementation model in MuleSoft?

Article written by:

  • Krzysztof Hałasa

    Systems Integration Architect
How to choose the best implementation model in MuleSoft?

Cloudhub or Hybrid? Anypoint Platform Clustering or own HA model? Shared resources or independent micro-applications? Each Mulesoft implementation, as well as the first project, starts with the same question – “what will be the best approach for an incoming initiative?”. Let me consider pros and cons of different implementation models that I find the most interesting.

Cloudhub implementations

Cloudhub is a Platform-as-a-Service solution which  enables deploying Mule Services without provisioning and managing servers – Anypoint Platform handles everything. Using Anypoint Platform Runtime Manager, a developer can specify the number and size of workers for the Service, create VPC and Load Balancer for the solution. Behind the scenes, Mulesoft provisions virtual machines on AWS, handles application deployment and enhances monitoring. Time to market for such implementation is very short. Moreover, High-Availability and auto-scaling is available with just a few mouse clicks in Mule Application settings in Anypoint Platform.

As great as the Cloudhub is, it has its limitations. First,  a minimum number of assigned cores for application, that is 0.1, defines a size of a license needed for such implementation. For example, having three-layered Integration Platform model, you need at least a 0.3 core for only one data flow between integrated systems. It is easy to calculate that a big three-layered ESB will be quite expensive using Cloudhub.

Second, creating a separate virtual machine for each application makes having shared configuration between them impossible. It has a great operational impact, such as a need to upgrade each app separately during Mule Version Upgrade, handling credentials and mule connector versions for each service independently, or even repetitive bug-fixing – if the issue is related to defected Mule connector version used in multiple applications. Implementing services in Cloudhub requires mature, stable and well-designed CI/CD procedures to avoid human errors related to property and configuration maintenance.

Cloudhub Deployment is a very good solution, if each application is designed to be a separate, encapsulated service, providing one business functionality. Applications are not related to one another, so any change  made to one app does not impact other ones. Such services can have separate auto-scaling procedures, running separate mule connector versions or even separate Mule Runtime Versions (both 3.x and 4.x in the same Anypoint Platform environment). Cloudhub is also a very good start point for migration between Mule versions, or running a proof of concept or seasonal services, without a need to provision the whole environment.

Hybrid implementation with domain-project based applications

In Mulesoft nomenclature, “Hybrid” implementation means self-provisioned Mule Runtime Servers as a deployment target. Servers are being provisioned on Cloud or on premises by a solution owner and, by means of using Anypoint Runtime Manager Agent, they can be connected to Anypoint Platform. Key advantage of such a solution is that there are no core limitations per application; having just as many cores as our server has, we can deploy as many applications as Mule Server can handle, rapidly reducing licensing cost in comparison to Cloudhub. Using Mule Domain Project, the developer can connect multiple Mule applications together, allowing them to share resources and connector versions, which is an approach impossible to deploy while using Cloudhub. Pros of such a design are easier changes in Mule Runtime Versions and configuration credentials – the developer needs to change only one Mule Project instead of many (sometimes hundreds!) of Cloudhub-prepared applications. Shared resources provided by Mule Domain Project also allow Mule Services to use VM Queue as a method of communication between one another, using internal server memory instead of HTTP traffic – which is more secure, faster and allows preserving processed data if servers are in cluster.

Hybrid implementation also supports Anypoint Runtime Manager clustering on self-provisioned servers. Clustering allows Mule Runtime Servers to share memory grid, enabling high-availability for working applications and data being processed. Shared resources between applications are available only on Hybrid implementation with Mule Domain Projects, which is one of the biggest advantage of this approach.

A hybrid-implementation approach, even using domain-project based applications, also has several disadvantages. The main one is the fact that there is a more complicated design of Deployment Pipeline and release procedures. First, Mule Domain Projects cannot be deployed through Anypoint Platform Runtime Manager – packages containing domain projects need to be deployed via SSH directly to a Server. Second, if you want to achieve auto-scaling, you need to design Deployment Pipeline to take care of connecting servers you provide to Anypoint Platform Cluster.

Another disadvantage not related to Deployment pipeline is reduced out-of-the-box monitoring for Mule services and servers. The Cloudhub server, being fully-provisioned by Mulesoft, cannot be accessed via SSH, so all necessary metrics, logs and alerts are possible to be easily implemented on Anypoint Platform. Hybrid implementations, can be provisioned on different server configurations, with different operational systems, and have the Anypoint Platform monitoring reduced to minimum (like the number of errors for services, response time, or CPU usage or heap memory for servers). For more advanced monitoring, there is an additional development on Anypoint Platform to be done, or even a decision to be made concerning choosing a different monitoring platform.

Hybrid implementation for domain-project based applications, using clustering on Anypoint Platform, is a perfect solution for more complex ESBs, with highly reusable components. Such a design enables running hundreds of applications without a significant impact on Mulesoft License. The platform as a whole is easy to migrate between Mule 4.x versions, allowing switching depreciated components quickly in Domain Project, without any changes in Mule applications. Spending some effort on well-designed Deployment Pipelines, most of disadvantages can be minimalized, resulting in a mature ESB platform with High-Availability and possibility to scale up, running on custom network setup.

Hybrid implementation for independent applications

A combination of Cloudhub and Hybrid-domain-based approaches is an interesting deployment methodwhich is independent services, just like ones on Cloudhub, but running on self-provisioned Mule Runtime Servers. Having such an approach, we can have separate functional services with shared credentials (the same config file for multiple applications on a direct place on the server). Applications can communicate via HTTP, but while being on local machine, it is much faster than traffic via Internet (like it is on Cloudhub). What is more, applications can be containerized and managed by Anypoint Platform, using Runtime Fabric, which will enable encapsulation and separation between them. The disadvantages not eliminated by mixing both approaches are a need to migrate each application separately during Mule version migration (which can be quite a big con) and some additional work  that remains to be done to enable autoscaling and ensure HA on self-provisioned servers. Such a design does not gain a lot from Anypoint Platform, only basic monitoring of servers and services and serviced deployment.

Having the biggest disadvantage of Cloudhub approach, a need to configure Mule connectors versions and the Mule Runtime version separately for each application, this method is worth being considered for Community Mule Runtimes. Using Docker and encapsulating Mule services, there is a way of building a cloudhub-like solution using opensource deployment and monitoring tools. Without Mulesoft License, Anypoint Platform is unavailable, but with some effort, most of its functionalities can be incorporated to a self-driven platform. The question remains to be answered: is it worth to build such a solution, while having well-tested and maintained Anypoint Platform by Mulesoft?

Conclusion

As it always is with most of IT products and approaches, each design has its pros and cons. Cloudhub implementations are very easy to build and monitor, but more difficult to configure or adjust to specific requirements. This deployment method is good for Mule “micro” applications which are working separately to provide a specific business function. Hybrid implementation gives us more flexibility regarding network configuration and possibility to build large ESB solutions without increasing license costs. This option is also easier to configure and manage regarding Mule Runtime versioning, platform credentials and mule connectors upgrades.

Let's talk business

Subscribe to our newsletter.

Receive the latest updates from us.