How to maximize usage of Mulesoft resources?
Undoubtedly, Mulesoft is a best integration and API management platform, which help to increase speed to market and lower implementation cost by promoting the APIs reusability and use of many out of the box connectors. Mulesoft offers two pricing models i.e. subscription based pricing model and usage based pricing model but it is important to consider various aspects while designing integration solutions using Mulesoft to reduce the annual subscription or usage based cost.
The given below are some of the considerations, which would help in the efficient utilization of the resources and reduce overall operational cost for an organization.
Automate Life of APIs in Sandbox Environments :
Most of the time, not all APIs are required to be in running state 24x7 in the sandbox environments. It is imperative to define strategy for managing life of APIs in the sandbox environment. This strategy would help in the effective usage of resources and at high level it should cover following points.
1. Identify APIs for 24x7 uptime - APIs such as foundation APIs or utility APIs or common APIs, which are required to be in running state all the time in the Sandbox environment.
2. Create a framework to maintain APIs schedule - It is important to have a framework in place to capture and maintain schedule of each API in the sandbox environment. It could be simple spread sheet to capture details like name of API, API schedule covering when API needs to be in running state, start and end date of API schedule, API owner details, etc.
3. Update and Maintain schedule for each API - Update schedule for each API using the framework defined in the above step. Platform admin should be responsible to keep schedule up to date for each API. All APIs identified for 24x7 uptime can be excluded from this or should have schedule updated to keep them in running state for 24x7 and for rest of the APIs, it should be aligned with the projects development and testing timelines submitted by project manager or product owner.
4. Utility to automate life of APIs - Create a utility, which will execute every 5 mins or on defined intervals to read the schedule of each API and then start or stop the respective API based on the schedule. It will also notify the API owner on starting and stopping of API so that owner can take necessary action to renew schedule, if required.
Design 3 Layered Architecture by Choice; not Forced:
Mulesoft’s 3 layered architecture provides great level of agility, reusability and flexibility through loose coupling but enforcing all three layers impulsively for every use case may turned out to be inappropriate and expensive. It is very important to have guidelines in place for creating each layer based on the enterprise or organization level goals and vision for the integration landscape. The given below are some of the points to be considered while defining these guidelines.
1. Experience APIs at domain level or partner level - In general, creating experience API at domain level is preferred unless there is a need to provide experience specific to the partner. This would also help in enforcing security best practices specific to particular domain such as APIs in finance or HR domain would need more security controls and restrictions. Hence, clear guidelines need to be defined for when to create domain level and when to create partner level experience APIs.
2. Process APIs are not mandatory for every use case - Process APIs should be created only for specific business purposes and hence just ask simple question to yourself, “Do we really need process API created for this use case or requirement” ? Include process API only when there is a need to combine data or orchestrate system APIs calls to implement specific business process.
3. Define right level of granularity for System APIs - Microservices approach has multiple advantages but creating very fine grained microservices would leads into cost disaster. Hence, clear guidelines and processes needs to be in place to control the granularity of the System APIs without impacting reusability, agility, scalability, and maintainability.
Discrete Schedule for Batch Jobs:
Typically, batch jobs have a liberty to adjust the schedule unless there are very strong dependencies on source or target system. Hence there is a great possibility of grouping batch jobs, which performs relevant tasks into single application without impacting agility and maintainability. Once batch jobs are identified to group into single application then try to define discrete schedule for each batch job so that the execution of those batch jobs is not overlapping. This will help in allocating optimum capacity and fully utilizing the allocated capacity to the application.
These are some of the techniques, which would help to maximize the usage of Mulesoft resources and reduce the annual subscription or usage based cost.
