There's a customer who wanted to migrate their API from their on-prem environment to Azure. They're looking at utilizing Azure API to manage all their other APIs. We just started with migrating one of their APIs. They're still working with it, still trying to learn the difference between what they had for on-prem and Azure. We are in the process of actually migrating a lot of their APIs.
Access control is the most valuable aspect. It's the main reason really why a lot of clients are moving - as we are able to deploy multiple APIs and be able to also segregate who's got access to which API, who's got access to the other API. That centralized management is what the customer is really looking for.
The initial setup was okay.
The solution isn't missing anything. For the use case that we have right now, it's perfect. It offers everything that you'd look for in an API Management solution.
There's a new developer portal that's been added before they rolled out the new updates. I haven't really checked it out, however, the developer portal that they introduced is better than before. They've really improved on that one. If you are using the old portal, it's not as good.
We have two different customers. The other customer wants us to move completely, to migrate their APIs to Azure. The other one wants to manage their APIs, which are running on-prem. I've explored that in the flexibility, in terms of integration with an on-prem environment. The integration could be improved for those on-prem use cases.
The integration with other API gateways is where they might try to improve.
Support could be better.
I started using the solution six months ago.
In terms of stability, I have seen that it is packaged into four different plans. If I'm not mistaken, there should be basic, standard, conception, and developer. I wanted to try to avoid deploying a lot of units, it uses a concept of compute units or scaling units. I was using the conception tier, which is not designed to be highly available. I was testing features, I didn't mind the level of availability. I suspect that if you choose the high-end SQL, it's most likely to be available. However, in terms of cost, I'm yet to find that out.
If you compare the SQL, and that's one that really supports scalability across regions, it's good. It's very scalable.
We have ten developers using the solution right now.
We do plan to increase usage.
Microsoft is huge, and when it comes to support, it's not so great as compared to, if you have something software specific. Whenever you ask them a question, they assume you to know everything. It's challenging to get the level of support that you'd want.
Neutral
We used to use Kong.
Kong is more of an on-prem API gateway, and this one is cloud-based. And given that many customers are migrating to the cloud, it was actually one of the reasons why we're convincing the customers that we have used their APIs to migrate to the cloud.
The initial setup was pretty straightforward.
I have a basic understanding of the API fundamentals. Those were what I was looking for; that's what I was looking for first, just to see if my understanding of the fundamentals. With my level of knowledge, it was fine.
For someone with basic knowledge, you can deploy the solution within a week.
There is some maintenance needed. However, that person is supposed to be someone who's more DevOps inclined.
We handled the initial setup in-house.
I've been using the conception tier. If you choose the lower-end tiers, it'll be fine, cost-wise. However, those tiers are just for development purposes; they're not really for the production environment. I would suspect if you move onto the higher tiers, it'll be pretty pricey.
I was looking into Azure API Management and the equivalent and in AWS.
I wanted to compare the functionality between Azure API Management and Amazon API Gateway, as there's a customer that wants AWS API Gateway instead of Azure. I just wanted to see if the features are similar. I'm looking into that now.
We're a Microsoft partner.
The role that I have right now is a role where I'm a deployment engineer for cloud services, so depending on what the customer wants, someone's migrating from their on-prem, from VMware, the Linux, the Hyper-V to Azure, someone has to design highly available solutions, like applications that are tiered, that is three-tiered or two-tiered. Some want to utilize API Management. With API Management, we don't have a lot of customers on that front, as they sort of don't understand how it works. Right now, it's an area where we've worked with two of our biggest customers that have got multiple APIs on their on-prem environment. I've got basic experience, especially on what an API is and the benefits of Azure API Management as compared to what they have.
We're using the latest version of the product.
We are completely moving our customers from their on-prem APIs. It's a complete cloud solution; they don't want any hybrid solution.
I'd rate the solution six out of ten based on the level of knowledge I have. The learning curve is pretty high. It's API Management and it also supports API gateways. It didn't decentralize those features, so the learning curve that's there for someone is a bit much.
I would recommend the solution to others.
I work as a software engineer on the WSO2 API management and WSO2 identity and access server, using version 2.6.
At my company, Jio India, I have been one of the main people driving adoption of WSO2. In the beginning, we used WSO2 on virtual machines to handle the API and IAM requirements for more than 40 applications. Now we are currently in the process of migrating to WSO2 version 3 with Kubernetes as our orchestration system.
It has helped us manage and scale our APIs in one solution, which is important to us as a large enterprise with over 40 applications relying on various APIs.
One of the great things about WSO2 API Manager is that it is so easy to adopt. And because it's an open source solution, we're able to extend the implementation any time to suit our applications better.
From a product perspective, the first thing is that although the documentation provided by WSO2 is good, it could be much better. We're in the middle of a complex migration, moving away from VMs to Kubernetes with the latest version of WSO2 and good documentation is essential to us right now.
If you are doing some basic implementation, that's easy enough to do with the current documentation, but suppose you are stuck with an error or you're engineering a complex scenario. In this case, when diving deep into the documentation, it's very helpful to find more information on how things are connected, what each file does, and what the various configuration settings do.
Although they do have paid support which may help in cases where documentation is lacking, we aren't paying for a support license at the moment so we would definitely like to see better documentation for those in our kind of situation. Especially since we're using WSO2 API Manager to such a large extent.
Beyond documentation, they have provided a caching mechanism which I believe could also use some improvement. Once you have set up and implemented WSO2, caching becomes very important and I think they could work on the cache parameters, etc., to make it easier to work with.
Regarding the code itself, there are some bugs which we have encountered among the many different enterprise-level scenarios we have faced. Once again, because we are not paying for the licensed version, it becomes more difficult to request changes and bug fixes to the WSO2 codebase. So, for example, when we find a bug, we would like to be able go to GitHub and get better help on creating a solution that we can quickly push into production.
I have been using WSO2 API Manager for about five years now.
In terms of orchestration, it's very scalable. Especially when using Kubernetes to handle the orchestration. When we are creating our deployment architecture, we can easily define all sorts of parameters. For example, we can change the CPU parameter, memory parameter, etc., as needed.
We don't have a license with WSO2 so I couldn't connect with the WSO2 team for technical support. I was the main engineer who drove adoption of it at my company, and during initial setup, editing of the product, and implementation, I obtained a lot of support from Stack Overflow, LinkedIn WSO2 groups, Slack conversations, and GitHub.
From a deployment perspective, initially, we had started with our deployment on VMs (virtual machines), which we understood would take some time to get right. Thankfully, WSO2 provided many sane defaults in the initial setup, including defaults for authentication and so forth, which saved us some time.
But as we migrated our deployment from virtual machines to orchestration using Kubernetes, it became a bit more complex. It took us a long time to figure out the best way to configure the orchestration, since there are multiple ways of doing it with Kubernetes. Another complicating factor in the orchestration setup is that we have to always keep in mind where our users are located, so that there won't be any negative impact on their end.
Keeping all these points in mind, we finalized deployment by creating our own API manager image which we could deploy in Kubernetes. This image was based on our previous VM setup, which we simply reused. However, it was still a challenging task to get everything correctly configured for the Kubernetes orchestration, especially since we were in the middle of simultaneously migrating 15 different implementations.
Now that we have mostly finalized the deployment architecture for our APIs, it's much easier moving forward. We know exactly how to deploy the base image, and there's not much work to do now except for changing parameters around and so on.
We are implementing WSO2 API Manager without any paid support licenses so we do mostly everything in-house.
We have not opted for the paid version of WSO2 but we have implemented the free and open source WSO2 software to a great extent and it is working as per our expectation.
When we started looking into it, we compared WSO2 products with a few other products including MuleSoft, Tyk, Kong, Nginx, and Express Gateway. Obviously each product has some pros and cons, but out of those products, we liked WSO2 and KONG. Again, both have their limitations, but as an enterprise business we found WSO2 more easy to adopt.
WSO2 API Manager is a good solution for enterprise API management and, even better, it is free to use the software. If you are doing complex implementations, however, it might benefit you to go with a paid license which will help when you discover any bugs or need extra support that the documentation cannot provide.
I would rate WSO2 API Manager an eight out of ten.
My company has a good impression of IBM DataPower Gateway. What I like about it is that because it's an appliance, it's a turnkey solution that's very fast and out of the box.
Compared to other gateways, I also like that IBM DataPower Gateway is function-rich. For example, for one of the projects, there was a need for specific transformation and security features available in IBM DataPower Gateway out of the box, so my team just needed to configure the appliance. There was no need for separate development, and I found it quite neat.
Another valuable feature of IBM DataPower Gateway is that it's easy to integrate with other products.
An area for improvement in IBM DataPower Gateway is its price point because it's a relatively expensive product. Sometimes, when the customer use case is just a very small subset of what's being offered in IBM DataPower Gateway, then the product can be expensive, making my company lose some of the opportunities because of the expensive pricing.
A lower price point for IBM DataPower Gateway, even if that results in a less feature-rich version, would be appreciated.
In terms of additional features that I'd like to see in the next release of IBM DataPower Gateway, nothing specific comes to mind because IBM constantly improves its standards and provides quarterly updates to the product, so it's quite fine.
I've been working with and supporting IBM DataPower Gateway locally for six years now.
From a technical point of view, IBM DataPower Gateway performs quite well, so my team had no concerns at all in terms of performance, reliability, and stability. When deploying IBM DataPower Gateway for banks and other financial institutions here in Hungary, I've observed that you can almost forget about it because it's a good product with no issues.
IBM DataPower Gateway is a scalable product, but Hungary is a relatively small market, so even the smallest size is sometimes too big for the customer. Scaling the product downwards would be better because it's more suitable for small businesses. IBM DataPower Gateway is less applicable to mid-size and large businesses.
We had no issue with the technical support for IBM DataPower Gateway. In the past few years, we had to open just very, very few tickets that were answered promptly. There was even one case where the physical appliance had a hardware issue. The power supply had to be replaced, and the replacement came automatically within the promised timeframe, so support was okay.
The initial setup for IBM DataPower Gateway was straightforward. The hours and effort dedicated to the implementation of the product were quite low compared to other products, though not necessarily gateways. You can do most of the implementation steps, and IBM DataPower Gateway requires a relatively easy configuration, and as it's out of the box, you can just customize it.
The total cost of IBM DataPower Gateway would depend on the configuration, but in my experience, it can amount to 60,000 Euros per box, even for the virtual version. Usually, customers need high availability and a non-production environment, so the total price for IBM DataPower Gateway can be quite a lot. It can be 200,000 Euros or a similar figure.
IBM DataPower Gateway is still in an early phase with us, especially because of its price point. As some of our customers need a less functional and less costly solution, we're looking at other alternatives on their behalf, such as Kong API Gateway and WSO2, but we don't have too much experience with those solutions.
My company is a system integrator for IBM DataPower Gateway and other solutions in Hungary. My company also provides customer-side consultancy for some projects, particularly providing expertise for customer deployments and other related areas.
Just a few people use IBM DataPower Gateway within my company. There's a team of ten people that covers other solutions and competency levels as well. Only one or two people utilize IBM DataPower Gateway full-time.
What I'd tell others who want to implement IBM DataPower Gateway is that it's a reliable product.
My rating for IBM DataPower Gateway is nine out of ten. Technically, it's okay. It's only the price point that needs improvement because it's a bit expensive in some cases.
My company is an IBM partner.
3scale API Management is used for routing the internal application within the company.
To me, the most valuable feature of 3scale API Management is that it lets you add a backend to the product.
I also like that you can integrate it well with OpenShift clusters, making 3scale API Management a useful solution.
What I'd like to improve in 3scale API Management is its route-limiting feature. Currently, I don't know how to do that effectively on the solution, but in Kong, I know how to do it, so I would love to see route-limiting being easily done on 3scale API Management.
It would also be good if there was some authentication that you could do from 3scale API Management because Kong offers that functionality out of the box.
What I'd love to see in the next release of 3scale API Management is the ability to integrate more plug-ins easily onto the platform, so you'll be able to extend it, and even do customs management. If Red Hat could offer that extension where it allows the internal organization where 3scale API Management is deployed on-premise to integrate its tools on top of 3scale API Management and provide an API for that, that will make the solution very powerful.
My experience with 3scale API Management is more than one year.
3scale API Management is a very stable solution.
3scale API Management is a very scalable solution.
The technical support from 3scale API Management is exceptional. Whenever my team tries to get assistance, the response is almost instant because my company is a Red Hat partner. The support platform is interactive and the documentation provided is detailed. Information about 3scale API Management is well-documented.
In my previous company, I used Kong, and in my current company, I'm using 3scale API Management, but I prefer Kong.
3scale API Management has reasonable pricing, judging from its competitor, Kong. My organization pays yearly for the 3scale API Management license, though I'm unable to give the exact figure because every single day there are new clusters deployed. I'm in charge of three to four clusters in my team, but give or take, it costs a few thousand lakhs.
I use 3scale API Management in the company I currently work in, but in my previous company, I used Kong.
I'm a consultant for 3scale API Management, so my customers use this product.
I belong to a large organization, and around fifty to one hundred people use 3scale API Management, while twenty to thirty administrators maintain it.
My rating for 3scale API Management is seven out of ten.
