Problem with current Mulesoft implementation
Sometimes, Java coding is used instead of standard codes in Mulesoft.
The same happened with one of our clients. Their system integrator partner did most of the coding in Java in Mule. A lot of the things were nonstandard and non recommended. Due to this, their one application was running on 2 vCores. Where two workers were working on one vCore each. It was consuming a license of two vCores for one application. There were only twenty-eight to thirty APIs/ functionalities coded in that application.
Even though the application was running on two vCore, it was often running out of memory. Even the basic things which can be handled perfectly in Mulesoft were also coded in Java. For eg: database queries, database insert, updating something in the database, etc.
They coded data transformation also in java. Mostly java and Mulesoft functionality were in use. Such as connection was defined in the database connector and Java class was also redefined in the same connection. As a result, memory consumption of that app was high.
Challenges faced by client
There were two major challenges
- High application cost- The running cost was almost more than $200000 per annum with having only twenty five to thirty functionalities.
- High memory consumption
How did we resolve the issue using Mulesoft?
We started optimizing the application. We replaced Java code with the out of the box standard components of Mulesoft. Initially there was a code of seven to eight thousand lines on one XML file. We split that code into multiple XMLs. As it is very important in Mulesoft to make the code readable. Also, we used DataWeave and database components.
We used 2 workers of 0.2 vCores each with high availability because we were able to manage the memory much more efficiently.
Results
We enabled the same application to run in 0.4 vCores instead of 2 vCores and saved the client’s 1.6 v cores i.e., saved almost more than $160,000 per annum in licensing costs. We also provided them peace of mind as the application was mostly operating at 40-60% of total memory consumption. The peak value recorded was just 65%.
Conclusion
Efficient partners do not work just for the sake of recommendations. They work with the motive to serve the clients more than what they expect. TCIs proficient team can provide pain-free services to the clients and TCI IT services can ensure this as we have already done in the past. We would love to do the same for you. Get in touch.