Boomi Molecule: The Dilemma of Maintaining Operational Capacity at Low Costs and its Solutions

In a traditional on-premise integration development lifecycle, the emphasis is primarily put on the functional requirements of the interface and the business goals. The production environment is optimized with basic supportability features such as notifications or logging or both. Other operational aspects take a backseat and may be implemented as budget and time allow.

Many of us would agree that several non-functional requirements such as availability, reliability, performance, and reliability are an afterthought when an individual integration application is designed. Such operational, non-functional requirements are addressed by previously designed capacity planning of runtime components. At the time of integration design and development, these factors are ignored since we have overprovisioned hardware with good enough CPUs, RAM, and Disk space. The application infrastructure optimization, which includes clustering of the servers and managing multiple data centers among more, has already taken place at the time of the initial installation of the software via the Predictive Capacity of the said environments.

If you have come across architects or product owners who may presume that the performance testing and scalability testing of the interfaces is overkill at an individual project level, we aren’t surprised. However, this approach of ‘Predictive’ Capacity Planning in the beginning and subsequent stages of ‘Monitor and Adopt’ Capacity Planning will only work to a certain stage of growth until aspects of supportability, reliability, and cost of such a strategy come into question. That is when a comprehensive re-design of the platforms/environments is called for.

Essentially, cloud-native technology platforms have evolved to solve the same set of problems across several integration tools. The focus of this article is on Dell Boomi in particular.

Operational Stability Vs. Scalability Challenges in Dell Boomi

Dell Boomi is an Integration, API Management, and MDM Software that’s currently leading the Integration Platform as a Service (iPaaS) market and is well-suited for organizations of all sizes, the reason being its cloud-native functionality, the ability to increase business agility through no-code/low-code integration implementation mechanism and integration packs (recipes of pre-built integrations) for reusability, and low-cost compared to other similar providers.

Molecule, a clustered runtime engine of Dell Boomi’s integration software, is a multi-node runtime to allow processes to run concurrently and achieve load balancing with higher uptime. Dell Boomi Molecule supports a single-tenant model (a dedicated infrastructure for the tenant), but the nodes of the Molecule are installed on multiple server instances are grouped using shared storage, and the load balancing or the uptime is orchestrated by the head node. 

Though Dell Boomi’s one of the finest strengths is being cloud-native, from the available information, it may not be surprising to say that a majority of the existing Dell Boomi Molecule installations by the organizations are still hosted on-premise, and some of them are operating on Windows Operating System. This arrangement can be significantly risky, and a few of the operational complexities that companies may be experiencing today can be attributed to the same.

The essential aspects of the Boomi Molecule infrastructure and functionality such as the shared storage, frequent I/O operations, and disk storage access needs, associated with the runtime execution of the process, can cause resource contention frequently on the servers. The problem gets worse when the number of nodes that need to be scaled out to handle the desired transaction volume on the Molecule conflict on the same file system.

Is Your Dell Boomi Molecule Runtime Environment Unpredictable at Times? 

Do you see weird runtime exceptions happening on your Molecule environment? And, do you have a hard time figuring out the causes of the issues? Or, do you notice some challenges that make you suspect both your underlying Molecule infrastructure as well as your integration processes?

If yes, we assume that you may be spending considerable time and money troubleshooting the errors, investigating the root causes, making frequent support call to Dell Boomi Team, restarting the molecule nodes very often, creating and working on multiple work-around mechanisms to triage the issues, and restoring functionalities to ensure business continuity. 

Revisit Your Boomi Molecule Infrastructure Now

We would perhaps address the exceptions in your Molecule Infrastructure in the similar fashion as mentioned above. To some extent, we may even demand tools for operational support or monitoring requirements. 

However, to think of these challenges differently, we would encourage revisiting the infrastructure setup.

We aren’t saying that a proper root cause analysis isn’t the need of the hour. We are solely relying on our experience with customers where we practically learned that there are easy ways to solving the Molecule infrastructure challenges.

While most customers are satisfied with the choice of Boomi Molecule as their iPaaS platform, choosing trade-offs for critical operational aspects such as scalability and cost-efficiency has been a big concern. 

The Best Solution Approaches

We trust that a touch-down approach in solving the unpredictability of the Molecule infrastructure can be of great benefit, especially when the errors are not specific, and you have spent hours and hours in troubleshooting already.

Motivated by the Dell Boomi’s documentation suggestion that the stability of the Private molecules is unpredictable with Windows environments, we recommend that you suspect the Windows environment compatibility with Boomi Molecules and think if migration to Linux OS can be a possibility.

While we are almost certain that these would solve several challenges that you may have currently, we don’t deny the fact that some errors can be unique and must be treated with experience. This is when you should consult a Dell Boomi Integration Architect.

On the other hand, achieving scalability is a pain point in traditional integration platforms where vertical scalability is the only possibility. But, in Boomi’s case, we can choose to increase the nodes of the Molecule to 10. 

However, this may worsen the disk contention in accessing the shared storage, and hence not be considered a well-thought solution in general. 

Given such a scenario, we would say – what’s better than leveraging the cloud-native functionality of Dell Boomi and moving to a cloud partner? Our experts have seen and been a part of the AWS cloud implementation for several Boomi customers, and they endorse the AWS cloud for such implementations. 

AWS cloud provides better infrastructure efficiency than that of the shared on-premise infrastructure, allows the right sizing of the nodes, and scales in or scales out on demand. 

We will be rolling out more information on this subject in our upcoming webinar. If you are interested to know more, register now.