As MuleSoft continues to innovate its offerings to meet the evolving demands of digital transformation, its recent shift to a consumption-based pricing model has caught the attention of many businesses. This new approach marks a departure from the traditional vCore-based pricing structure and allows organizations to pay based on actual usage, measured through key metrics such as Mule Flows, Mule Messages, and Data Throughput.
However, understanding the documented metrics alone may not be enough for businesses to accurately estimate and control their costs. This post delves into both the official and hidden factors that can impact consumption, helping organizations make well-informed decisions and manage their budget effectively under MuleSoft’s new pricing model.
Overview of MuleSoft’s Consumption-Based Pricing Model
MuleSoft’s shift to a consumption-based pricing model introduces a new level of flexibility for organizations, particularly medium-sized businesses. Under the traditional model, customers were charged based on the number of vCores (virtual cores) they committed to, often leading to situations where businesses paid for resources they didn’t fully utilize. With the new model, customers only pay for what they use, making it possible to scale usage—and costs—more accurately with business needs.
Currently, only select opt-in clients are provided access to this new model, but it’s expected to expand as MuleSoft refines the approach. The key metrics for this pricing model include:
- Mule Flow: A flow represents a sequence of events within a running Mule application that is triggered by an event source or routed through APIKit. The model aggregates flows based on a peak concurrency calculation—the highest number of flows existing in a single hour during the month.
- Mule Message: Each event that triggers a process in MuleSoft generates a Mule message. These messages, which contain the core information processed by the runtime, are counted throughout the month to measure total usage.
- Data Throughput: The volume of data transferred in and out of MuleSoft’s infrastructure for an application constitutes data throughput. This metric is crucial in data-intensive applications, where high data volume can drive up consumption.
Understanding these metrics is the first step in navigating the new pricing model. However, it’s equally important to recognize the other factors affecting consumption that may not be documented, to better manage and predict costs.
Beyond Documentation: Hidden Factors That Affect Consumption
Beyond the metrics MuleSoft officially documents, there are additional factors that impact consumption—and thus your costs. Being aware of these can help you avoid unexpected expenses and optimize your MuleSoft implementation. These hidden factors include integration architecture, API design choices, the use of certain components, and CPU usage.
- Integration Architecture: The architecture you choose for your APIs can have a significant effect on consumption. An API-led connectivity model, which involves breaking down integrations into System, Process, and Experience APIs, is popular but may increase message counts and flow usage. In this structure, each layer processes messages independently, leading to a cumulative increase in consumption.
- API Design Choices: The design of individual APIs impacts the number of flows and messages. For instance, having multiple flows to handle different parts of an API request can lead to higher consumption, as each flow generates messages and throughput independently. Simplifying flow designs where possible can help reduce these numbers.
- Components and Event Sources: Certain components and event sources are heavier on consumption. For example, the Scheduler component creates a Mule message each time it’s triggered, which can quickly add up. Similarly, event-driven sources like Anypoint MQ, which produces messages at regular intervals, can increase your monthly message count. The size of payloads handled by components also affects data throughput
- CPU Usage and Scaling: Adding more vCores or replicas can increase your consumption by multiplying the number of flows and messages processed. While vCores do not directly impact data throughput, each additional vCore or replica adds to the flow and message count. Thus, while scaling can improve performance, it also drives up costs.
These factors underscore the importance of understanding your MuleSoft environment holistically, not just from a documented metrics perspective. Let’s take a closer look at how specific configurations affect usage.
Testing the Impact of Various API Settings
To investigate how different configurations impact consumption, we conducted a series of tests using multiple API setups. The goal was to understand how API design choices, flow configurations, and request sizes affect usage, particularly for metrics like flows, messages, and data throughput.
The MuleSoft Anypoint Platform provides a usage report page that allows businesses to monitor consumption daily, with a three-day delay. For instance, usage on November 10, 2024, becomes visible on November 13, 2024. By deploying several APIs with minimal designs and testing with various request sizes and volumes, we observed distinct patterns in consumption.
These tests confirmed that certain API settings and design decisions lead to significant fluctuations in consumption. For example, APIs with more complex designs and frequent triggers had much higher flow and message counts, as well as increased data throughput, compared to simpler setups. Such insights are invaluable for businesses aiming to optimize their MuleSoft configuration under the new pricing model.
Key Findings and Observations
Here are some key findings from testing different configurations in the consumption-based model:
- Architectural Design Choices: A three-layer API-led connectivity model (System, Process, and Experience APIs) can triple the consumption of Mule Messages and increase both flow count and data throughput. Additionally, even “stopped” flows in an API still contribute to consumption, highlighting the need for careful flow management.
- Component and Event Source Effects: The Scheduler component generates a Mule message every time it triggers. Similarly, all flows generated by APIKit, including routers and endpoint flows, count toward monthly usage. Choosing components thoughtfully and understanding their consumption impact can help manage costs.
- CPU and Replica Scaling: Increasing replicas or vCores for an application multiplies flow and message counts. However, while higher vCores generally don’t increase data throughput, they do affect flow and message metrics. This insight reinforces the need to scale only as necessary, based on actual workload demands.
These findings illustrate that effective resource management is crucial for keeping costs in check under MuleSoft’s new model.
Practical Recommendations for Optimizing Consumption
To help businesses optimize their consumption and control costs, here are some practical strategies:
- Minimize Unnecessary APIKit Flows: Only create separate flows for essential tasks or complex logic. Reducing the number of flows lowers the overall flow count and message generation, helping you avoid inflated consumption.
- Optimize Architectural Design: While a three-layer API design has its benefits, it’s not always necessary. For simpler use cases, consider consolidating flows to reduce message and flow counts. This approach can yield significant cost savings.
- Reduce Idle or Stopped Flows: Review your APIs regularly to archive or remove deprecated flows. Since even “stopped” flows count toward consumption, keeping only active and necessary flows deployed will help manage costs.
- Limit Scheduler Frequency: If you’re using Schedulers, reduce the frequency to lower message count. Whenever possible, replace schedulers with event-driven triggers. For instance, using event-based mechanisms to react to data changes can be more efficient than frequent polling.
- Control CPU and Replica Scaling: Avoid adding more vCores or replicas than needed, as each replica increases the flow count and message generation. Only scale up based on actual demand, to prevent unnecessary cost increases.
By implementing these strategies, businesses can align their MuleSoft usage with their budget and make the most of the flexibility offered by the consumption-based model.
Conclusion
MuleSoft’s consumption-based pricing model offers businesses a cost-effective alternative to traditional vCore-based pricing, allowing them to pay only for what they use. However, as our findings demonstrate, multiple factors beyond the documented metrics influence consumption, potentially impacting costs.
By being aware of both the documented and hidden factors that affect consumption, businesses can make informed decisions that optimize their MuleSoft usage and align it with their financial goals. The flexibility of this model, when paired with strategic management, enables organizations to scale their integrations efficiently while controlling costs.
For more details on MuleSoft’s pricing model and official documentation, visit MuleSoft’s official documentation.