Solved! Go to Solution.
Hi @dj1,
I don't imagine you'll get an answer other than "yes!" to your first question on here so I'll skip past that to your second question 🙂
About 18 months ago when we were making our decision on which API management platform to select, Mulesoft's Anypoint was a very close second to Apigee.
When I look back at the vendor matrix and how we scored the platforms we had 9 to start with and the final 3 were Apigee, Mulesoft and MS Azure API management.
In the end with our scoring, there was just half a point in favour of Apigee over Mulesoft.
We considered API Product/Package, Analytics (both admin and developer), policy support, Mobile BaaS, development language support, documentation and community, other features, and of course, cost (although we didn't have cost data for either apigee or mulesoft at the time we made a decision).
What separated the two was BaaS, although we didn't have an immediate use case, and ease of development.
Again, looking back at the notes, we never managed to get as successful a test with Anypoint.
There are some other lesser reasons, Anypoint being more than "just" an API management platform and we didn't want another ESB/integration tool, our java skills - not sure about now but at the time Mulesoft required some java for custom work whereas apigee offered nodejs and javascript.
So for us our decision making about what apigee had that mulesoft did not was probably quite subjective, although we tried to apply some objectivity by attempting to build some demos.
Hi @dj1,
I don't imagine you'll get an answer other than "yes!" to your first question on here so I'll skip past that to your second question 🙂
About 18 months ago when we were making our decision on which API management platform to select, Mulesoft's Anypoint was a very close second to Apigee.
When I look back at the vendor matrix and how we scored the platforms we had 9 to start with and the final 3 were Apigee, Mulesoft and MS Azure API management.
In the end with our scoring, there was just half a point in favour of Apigee over Mulesoft.
We considered API Product/Package, Analytics (both admin and developer), policy support, Mobile BaaS, development language support, documentation and community, other features, and of course, cost (although we didn't have cost data for either apigee or mulesoft at the time we made a decision).
What separated the two was BaaS, although we didn't have an immediate use case, and ease of development.
Again, looking back at the notes, we never managed to get as successful a test with Anypoint.
There are some other lesser reasons, Anypoint being more than "just" an API management platform and we didn't want another ESB/integration tool, our java skills - not sure about now but at the time Mulesoft required some java for custom work whereas apigee offered nodejs and javascript.
So for us our decision making about what apigee had that mulesoft did not was probably quite subjective, although we tried to apply some objectivity by attempting to build some demos.
Hi @Neil Munro,
Thanks for your reply!
But just trying to extract more info on your answer! Can we really categorize Apigee BaaS as part of API management?
2nd the connectors in Mule like AWS, Salesforce, Workday, Majento and of course SAP and many more, aren't they more user friendly?
I have never worked on Apigee 127, but it would be great if you could throw some light on it too.
Thanks
Dinah
Hi @dj1
Apigee BaaS might not be considered part of API management but it is still a feature available to us as an Apigee customer that is exclusive to Apigee (vs Anypoint).
I think you could ask the same about the Mule connectors - can we really categorize those as part of API management?
On the subject of the connectors: if by "user friendly" you mean that they assist integration developers with connections to systems then I agree somewhat, although I think it's more a matter of preference than a clearly defined "user-friendliness". You wouldn't, for example, allow a customer/API consumer access to a connector (would you?). There would still be a requirement for an API proxy for the API consumer to make use of anything the connector does.
I would also say that without some careful thought to your design, the connectors might be restrictive.
Here is an example that we have in production:
Apigee does have some connectors https://github.com/apigee-127/volos-connectors and I have tested the Salesforce.com connector but when it came to actually building with Apigee we just proxied the salesforce.com APIs and our own services in Apigee. It was straightforward and easy enough.
Apigee-127 is a subject in itself and my reply here is already a bit wordy! Have a look here http://docs.apigee.com/api-services/content/apigee-127 and there's also a section on the forum https://community.apigee.com/spaces/12/index.html. Apigee-127 is another tool that "might not be considered part of API management" in terms of Apigee Edge (but it can integrate with Apigee Edge therefore I consider it to be a feature exclusive to Apigee) - however, you can use this even if you aren't an Apigee customer.
Thanks @Neil Munro
That was indeed useful!
Will get back to you if I need more clarity when I bump into another scenario.
Thanks again
Dinah
Hi @Neil Munro, ... I know I'm replying to quite an old thread here, but maybe you'd answer me a quick question now you have another year with Apigee under your belt?
I was wondering if with hindsight, were you to already have had Mulesoft Anypoint within your estate managing your integrations, would you still have added Apigee (or one of its other competitors) in addition to Mule, or would do you think you would have successfully extended Mule out to deliver you API Management requirements?
Many thanks if you get a chance to respond
SB
,hi there @Neil Munro, I know I'm adding to an old post, but a really quick supplementary question now that you've had another year of play, if I may...
... If you had already got MuleSoft Anypoint in your estate, managing your integrations, would you still have added Apigee (or one of the others you assessed) or do you think you would have extended out Mule's capabilities to meet your requirements?
Many thanks in advance if you are minded to reply 🙂
PCG
(oops... thought the first go at that hadn't posted 🙂
User | Count |
---|---|
3 | |
2 | |
1 | |
1 | |
1 |