MuleSoft: Do You Have an Extra Mule Under the Hood?
A while ago, I was involved in a project which was the creation of new features for an existing system. In the evening, we clarified requirements with stakeholders about what needed to be implemented for that new undertaking. The following morning, I received an impatient call from one of the stakeholders asking when we would deliver such valuable functionality.
Nowadays, being competitive for a company means adapting to new realities and embracing new business opportunities at high speed. As a result, the most frequently asked question from businesses is how quickly you can deliver it.
Microservice architecture offers enormous benefits, whose main key feature is to deliver a requested change faster and without fear.
A Traditional Approach
There are many ways to structure your MuleSoft application, but I would like to show one I like the most. It is handy when you need to separate a logic in the future and, in other words, keep it under the hood until an actual need emerges.
Let’s look at the traditional way of designing the application. By traditional, I mean a straightforward approach where all related logic and functionality reside in a single application. This approach is simple and easy to start off, especially when, as a designer, you do not have a holistic view of how an application will play out later.
This traditional approach usually looks like this:
With peace in mind (vCore=0.1).
There are certainly some other ways to depict it:
Or as a MuleSoft application:
The Pros and Cons of This Approach
Pros
- All logic is in a single application.
- Less consumption of vCores at the outset of a project.
Cons
- Readability
- It is harder to make changes without impacting the rest of the functionality.
- You always need to scale up the entire application rather than the required piece of functionality.
- You know nothing about dependencies inside the code. Hopefully, each part of an app does not depend on one another, and the code review did not miss that.
A Separation of Concerns Approach
My favorite approach would look like the one below when we group functionality logically by applying some rules:
- Keep common configuration and functionality at the root of the application or inside a separate shared group.
- Functionality from one group must not leverage functionality from other groups unless this functionality is at the root of the application or in the shared group.
Taking and applying these simple rules helps us to turn our traditional application into such a picture:
This is when you are hiding an extra mule under the hood but not using it immediately.
Please remember not to call functions (flows/subflow) in the "operations" group from inside the "search" group and vice versa. If you need this, you can just create a separate group for the shared functionality or externalize it by adding a dependency to the POM file.
You can go ahead and deploy it. If you need to scale it up in the future, then you can create a new application from it simply. The initial structure can be split or extracted from the original application without fear of breaking it.
This is a picture of the new approach:
There are certainly some other ways to depict this:
vCores = 1 (10 x 0.1 vCore) for read + 0.1 for write operations
Or as a MuleSoft application:
You pulled out the extra mule and scaled it up as a new application, which was a fast and painless process.
Other use cases
In real life, we can have various scenarios when a single application contains multiple responsibilities under the hood, such as:
- When the layers of experience and process, system and process, and system and experience are combined.
- When a single experience layer serves as a single entry point for multiple consumers.
- When a process layer has a complex queue-based orchestration (the SAGA pattern).
Conclusion
Usually, at the project's beginning, you have a vague idea of how an application will play out in the near future. Still, applying this principle (separation of concerns principle) to some key functionality aspects will help you hedge against painful future changes or make them gracefully and without fear of breaking an original application.
Easy work and simply done. :)
