We are currently evaluating the integration platform that we want to use to manage (API Gateway / policy management) and build our integrations. Our goal is to reduce time-to-market for APIs, and better manage our API landscape (without letting the platform costs spin out of control). Down to the final two now -- MuleSoft and Azure (we have historically been a Microsoft shop), and the results are too close to call. For those who have gone through a similar evaluation, how did you make your final decision?
Sort by:
At Desjardins when we recently had to select an iPaaS platform, aside from the costs and the use of the Gartner “Guidance Framework for Evaluating Application Integration Platforms , what has been a key factor to make our final decision were the results of those two activities:
Meetings to get feedback from clients and users of the products on the short list;
Demos from the providers in a ‘white box’ mode and we also experimented and tested the product ourselves in our lab-incubator
I’m only wondering why Kong and Apigee were nixed – which requirements (functional or non-functional) they did not meet?
Otherwise, absent the requirements… I would be inclined to go with Microsoft. Mostly due to poor outcomes observed for your stated goals with MuleSoft at (undisclosed clients)
It's a close call, but for me, it would depend on whether we're prioritizing a broad range of features and complex integrations (MuleSoft) or a tighter integration with our existing Azure infrastructure (Azure API Management). If cost is a major factor, Azure might be the way to go, but we'd need to weigh that against the potential need for additional tools or services to achieve the same functionality as MuleSoft.
We had a similar situation when we first started leveraging APIs and conducted multiple gateway evaluations over the years. Currently, as our AWS footprint has increased significantly, we are leveraging AWS' API Gateway. Mulesoft was one of the top vendors we looked at. As was APIGee. Both have robust offerings and rich feature sets - more so than AWS' gateway eg developer experience/portal - but the decision was to go with AWS and fill the gaps with other approaches.
Look at people, processes and technology that would be involved in adopting, implementing and supporting either. As an example, if you have people, processes and technology supporting Azure with great results, then there is your answer. Just one example, standing up a new set of processes and technologies for something as fundamental as CI/CD dedicated to MuleSoft, while Azure has it in other areas than integration will likely not get the overall outcome everyone is looking for.