Is Apigee API management better than Mule API Aanagement? What is exclusive about Apigee API mangement that Mule does not have

Not applicable
 
Solved Solved
3 6 17.5K
1 ACCEPTED SOLUTION

nmunro
New Member

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.

  • Ease of development was really the deciding factor:
    • I opened an Azure account and deployed a simple SOAP service and then set about attempting to proxy the service from our final 3 options. I only needed an afternoon to get something up and running in Apigee because of the UI and the documentation. It was a basic test but it gave us a good feeling that we had a powerful tool at our disposal (and I'd say that's been borne out over the last 18 months - as we learn we are seeing more depth to the Apigee "ecosystem" than we were aware of at the time).
  • One other factor is what we termed "other features" and in our case that was Apigee-127.
    • As we didn't have Apigee at the time we couldn't get connected easily to our SAP system. I knocked up a simple front end going through apigee-127 to a service exposed by SAP that we used to demo at our parent company HQ in Japan - this allowed us to show something that felt "real" to colleagues more familiar with SAP and also show analytics and so on.

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.

View solution in original post

6 REPLIES 6

nmunro
New Member

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.

  • Ease of development was really the deciding factor:
    • I opened an Azure account and deployed a simple SOAP service and then set about attempting to proxy the service from our final 3 options. I only needed an afternoon to get something up and running in Apigee because of the UI and the documentation. It was a basic test but it gave us a good feeling that we had a powerful tool at our disposal (and I'd say that's been borne out over the last 18 months - as we learn we are seeing more depth to the Apigee "ecosystem" than we were aware of at the time).
  • One other factor is what we termed "other features" and in our case that was Apigee-127.
    • As we didn't have Apigee at the time we couldn't get connected easily to our SAP system. I knocked up a simple front end going through apigee-127 to a service exposed by SAP that we used to demo at our parent company HQ in Japan - this allowed us to show something that felt "real" to colleagues more familiar with SAP and also show analytics and so on.

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:

  • We have a scenario where we send SAP material (products) updates to Saleforce.com.
  • On the face of it we'd be good if we had Anypoint because they have a connector for such operations: https://www.mulesoft.com/exchange#!/sap-salesforce-material-product-broadcast?types=template&searchT...
  • However, in our case, we instead proxy the salesforce.com API using Apigee and our SAP system is the API consumer (client). We now have an API in Apigee that we could use for an application/system other than SAP to send material updates or, if in future we replace SAP we don't have to worry about whether or not there's a connector available for any new system.
  • In terms of performance without a connector: at times we have 10s of thousands of material updates from SAP and we don't see any issues.
  • In terms of "user friendliness" for me or my colleagues as API developers this is not a complex development - I don't think we wish we'd had a ready made connector at the time we did the development.

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

Not applicable

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

Not applicable

(oops... thought the first go at that hadn't posted 🙂