The technical teams have realized over time that around 250-300 APIs have been developed and managing these APIs can be challenging. Some key challenges identified in the existing platform are:
- The requirement for a vendor-specific skill set. Even if there was a process in place to acquire talent externally, they didn’t meet expectations.
- A consequence of the skill set needed to make proper usage of the Mule platform hence requires using a centrally managed development Team to implement the system integrations. If you - as an organization - prefer to go the DevOps way (so to speak) then a centrally managed development Team is an anti-pattern.
- Vendor-specific training programs were too expensive and didn’t meet the level of expectation.
- Access to platform functionalities was mainly GUI based. But the internal developer community preferred a set of APIs to invoke the same functionalities for obvious reasons.
- Around 90% of integrations were simple service-chaining scenarios. The complexity of developing them was too high.
- Lack of accessibility to development-related materials such as libraries and freedom/flexibility to combine with the existing pipeline (based on Git and Java-based open technologies).
- APIs without proper details on usage and performance and how to get the required support in case of a failure.
- Lack of details on ownership, dependencies, and workload/usage patterns.
- No proper governance on the API design, development, and publishing process which made the process of managing API development difficult.
Spending a fortune of money for licenses while not having a properly managed API program that is not future-ready has become a big issue. The customer decided to thoroughly evaluate the best APIM vendors in the market by going through live demos done by the vendors and in-house POCs by the internal teams. After a 4-week long evaluation where they evaluated various aspects including deployment flexibility, licensing approach, and costs, alignment of features with the expected outcome, and product maturity (including several others) they selected WSO2 as the vendor to displace MuleSoft. This was mainly due to the following two factors:
- TCO and overall return on investment (ROI) benefits
- Open-source licensing and flexible engagement models.
We found that the WSO2 API Management platform was considerably more flexible and met our needs more closely than the Anypoint Platform. Our experience with WSO2 was that they were responsive to our needs and the result is a powerful solution to our API requirements.
New Platform and The Benefits.
With the introduction of the WSO2 platform into the stack, the customer was able to achieve several benefits:
- A properly governed API design and implementation process through WSO2 API Publisher with standardized, versioned APIs that has clear ownership.
- Improved developer efficiency through developer self-sign up, automated deployments, and support for Infrastructure as Code (IaC) paradigms through the product level REST APIs available in WSO2 API Manager.
- With better understanding of API usage, performance, and dependencies, business decision-makers and architects could make the right decisions at the right times.
The total cost of ownership advantage WSO2 over MuleSoft depends on multiple factors, for example:
- Much lower subscription cost which means lower operating cost for the similar/comparable functionality provided by these two platforms. This would result in immediate savings.
- A lowered barrier to entry for projects with WSO2’s all-inclusive pricing model compared MuleSoft’s per-connector pricing model, consequently, approvals and additional funding are no longer necessary. This would also result in many more projects delivered in a given period of time.
- The year-over-year savings would be making a positive contribution towards balance sheets and along with other benefits, would translate to better overall performance of a team or business unit.