TIBCO Cloud API Management vs. WSO2 API Manager

Mashery is great when it comes to deployment to your own datacenter and when it comes to managing third party API's like Salesforce using Mashery Cloud version. I would be a little bit more careful when deploying it on Kubernetes as it was not designed for it. New version 5 is re-architected to run more on natively on Kubernetes, but we have not tested it yet.

Incentivized

It's free! No argument can win a fight with that! And it's the only reason I gave it a 5. If you have no money to spend, and a simple environment you'll have a nice product. But free does come with a price. After 5 years we're still struggling with ports, and analytics (it just won't work without any errors caused by some configuration somewhere). An API Manager should work out of the box. The only configuration expertise that any developer wants to invest in, is the configuration of API's. Not the product itself... Anyone who've seen the training material, just for installing this thing will agree that this is not the way to go. Of all the API Managers out there (we've tried 4), WSO2 is the only one were you need to know how this dragon of a java application works internally. Did I already mention the humongous amount of config files?

Incentivized

• Easy integration of the TIBCO Cloud Mashery developer portal allows simple onboarding and user and application management.
• Configuration of TIBCO Cloud Mashery is both flexible and focused to address the main tasks for an API Management solution.
• The built-in OAuth Token capabilities provide a quick start to properly manage application access.

Incentivized

• Authentication based on OAuth 2.0 and HTTP Basic Authentication.
• Rate Limiting applied at different levels like Subscriber, API, Resource and Backend.
• Monitoring by exporting the metrics in Prometheus and traces in Jaeger.
• Mediation to perform transformation, orchestration etc.

Incentivized

• The "Control Center" admin dashboard is not performant. We have a lot of configuration data in Mashery (many endpoints, many plans, many users, many keys, etc.) and the website struggles with the volume of data it has to deal with.
• Their systems have limitations that make it more difficult for us to operate the way we would like. For example, there is a limit to the number of API Definitions we can create, as well as a limit to the number of Endpoints we can define in a Plan.
• Their support organization leaves a lot to be desired. Responses are slow, and when they do come they are often inadequate. We have to re-phrase the question to get them to answer it differently, or we have to repeatedly follow up to ask for additional clarifying information.

Incentivized

• Better QA testing prior to releases rollout
• Better support needed

Incentivized

Ease of use.

Incentivized

i find some of the package adding and key are complex . UI experience is bad . Every step need front and backward navigation too much. It would be better if endpoint itself contain package and key addiction option

Incentivized

Support has been good overall.

Incentivized

Initially it was difficult to understand . after few day , it was easy

Incentivized

I've really only looked at Mashery since it has been around a very long time and has a rich feature set. I do know our platform teams are looking into AWS gateway but not sure this product has everything we need.

Incentivized

Providing better capabilities comparing the overall API lifecycle management, especially the availability of API Integration layer and a strong identity layer of their own which provides an end-to-end API ecosystem that would be advantageous in terms of a large software development initiative.

Incentivized

• As a API Mediation layer it has helped with the troublesome port setup with internal and external clients. Meaning it made that easy to the client that they know where to go for access to an API.
• The interactive documentation is very well put together and has reduced the time that developers have to go back and forth with each other to figure how to call the API.

Incentivized

• We've moved away from legacy SOAP services where nobody knew what services was used by who. WSO2 eliminated at least 90% of time spend on any service.
• Creating API's (or actually creating the API Management layer...) is so simple that new developers can get away with it in no time. Again, real time gainer.
• Since creating API's is so simple, developers are very fast in adopting a kind of "Domain thinking". In comparison with Azure API Manager: Azure does not demand knowledge of "how" the product works, but it's definitely more difficult to get an API up and running in Azure. And for some reason, azure does not promote clean domain driven architecture. Domain Driven architecture is the greatest time saver strategy possible. And WSO2 fits nicely in there.

Incentivized