与 Cloudhub 相比，MuleSoft RTF 架构和对内核的理解

Question

Hi we are planning to migrate to Mule4 from Mule3 and I've few questions related to sizing of cores compared to Cloudhub vs RTF.

Currently we installed Mule Runtimes on AWS(on-premise). 2 VM Machines of 2 Cores each. so that is 4 Cores subscription. Clustered them as ServerGroup. Deployed 40 applications on both.

Question 1) So My understanding is we are using 2 cores to maintain 40 applications and other 2 cores for high availability. Let me know if this is correct and If the same 40 apps have to be moved to Cloudhub with HA do i need 8Cores?

coming to RTF, i guess we need to have 3 controller and 3 worker nodes. suppose if i take AWS VM Machine of 3 Core capacity. It will be 3X3 = 9 cores using and I can deploy the same 40 applications on those 3 VM machines. (it could be more than 40 apps as well ).This is with high availability

When it comes to cloudhub if i need to deploy 40 apps with high availability (each app deployed on 2 cores) it would take 8Cores. and I cannot deploy not single application more than 40.

Question 2) RTF though i have 4 core VM machine i can deploy 50 or 60 apps. but for cloudhub if i take 4core subscription i cannot deploy more than 40 apps. Is this correct?

Answer 1

yes, you're right. Currently (Dec 2021), the minimum allocation of vCores when deploying applications to Cloudhub is 0.1 of a vCore, so to your 1st question, yes, correct, you would strictly need 8 vCores, assuming 2 workers per application for a "somewhat" high-availability. A true end-to-end high-availability would more likely need 3 workers, so that if one dies, you would still have HA within the other 2.

To the second question, when you deploy in RTF and even Mule runtime directly to say a VM or a container, you have more flexibility in terms of how much of a vCore portion you need to allocate for your applications. Your MuleSoft account manager would be able to articulate with you as to how much that would mean.

Last but not least, you could also think of different deployment models and cost-savings approaches, which depending on your scenario could mean using say service mesh, so you drastically reduce the number of vCores you use and also you can come with a strategy of grouping endpoints/resources of different applications in a single one. Example: if you have 2 different applications, both related to customer data or somehow the same domain, you could group them together.

Ed.