3scale API Management Reviews

The use case is that the organization I work for wanted to work with APIs but they didn't actually know what to do. They knew that it was a good thing to have an API management product. We are now trying to establish an API-first approach for both internal and external APIs, and we use it to provide financial information via APIs.

The deployment is a hybrid. We deploy the gateways in our own OpenShift cluster, provided by a vendor, but not on the cloud. And we have the RHOAM (Red Hat OpenShift API Management) solution for the management part, and that runs on AWS.

Since we introduced the gateway, the API management has given us the ability to get on top of things. It's not just the infrastructure but also the implicit organizational process. Now, things have to go through our API management team, the one that handles the API gateway. And that means we are able to get a handle on what is actually about to be designed and what is allowed to be published. That's the main benefit. The path for how something gets published in our organization has to go through the part of the organization that's actually managing the API gateway. That means we are able to discuss how to design our APIs to make sure they will be a good fit with all the other APIs that we provide.

The gateway is the most valuable feature because it makes it possible for us to gather all traffic into one proxy, which is a good thing.

It also gives us the possibility of using different policies, but we haven't done that to a very big extent.

The comprehensiveness of Red Hat's API management is important, although we are only using a small part of it, the gateway part. I believe it is important and that we will utilize it even more.

We tried to use the portal, but we decided that it wasn't enough. The content management system (CMS) is not easy to use if you want to customize things, and it's hard to get someone who has the knowledge to work with the CMS. The CMS is not good because it's hard to see what's about to be released. Also, you can't test the whole thing at one stage, rather you have to update different fragments of the content, and there's no way to look at the whole picture before you release it. You can end up limbo with some of the content in development, so we decided to build our own portal.

Also, the use of Liquid scripts is not that nice. It does its job, but it hasn't been well documented and it has cost us quite a lot of hours just to understand how to do things. When you do understand how to do them, it's quite easy, but it hasn't been well documented.

We have been using 3scale API Management for three years.

We have not been in the new environment for that long time. We've been up for about a month and we don't have that much traffic on that one. But the stability seems fine. The stability in the new environment looks promising.

In the older environment, we have had some issues but they are not because of the gateway. They were caused by a lack of resources in the OpenShift data center. The cluster didn't have enough resources and we had some downtime. 

When it comes to support cases, to technical feedback and real support—and not just, "Oh, it would be good to have this feature"—but actual help, there have been a lot of tasks ping-ponging, and that has not been a nice experience. It has taken a lot of time to get small things done, both on our side and from Red Hat.

If they really wanted to support us, it would have been better if they had actually scheduled a meeting with us. The pre-sales team was super at supporting us, but when we bought the product and still needed some support, it was really hard to get it through support cases.

Neutral

The deployment process is not that complex, but we have had issues with operators that have been hard to configure with our GitOps strategy. We want to deploy everything based on Argo CD with GitOps, and it hasn't been possible to do that with the operator part of the gateway. We've run into a few issues there.

We did the deployment in another part of the organization at first, and now we have done it in our target environments, with our target vendors. I wasn't involved in the first round, with version 2.5, but I have been involved in deploying the later version.

The time it took for deployment doesn't have as much to do with Red Hat as it has to do with our setup with GitOps and our vendors. The installation process is quite fast, but figuring out the issue with the operators and why that is not working has cost us quite a lot of time. But overall, the installation part is quite smooth.

We have one gateway for customer-facing, external APIs, proxying all the traffic from the customers, partners, external parties. And after some consideration and talking back and forth with Red Hat, we decided to have an internal gateway for internal APIs and that one is available for all internal applications. Internal applications are internal to the organization, but they don't have to be in the same network. They could be on an external network. And we may not have made the right decision there. We had a bit of a problem understanding why we should have internal APIs. Because we are going with API-first, we believe that we should externalize all APIs.

I don't have exact figures, but we have definitely had return on investment using 3scale.

I don't think that 3scale is very expensive.

We were choosing between Apigee and 3scale. The feature set of Apigee was a lot larger and we thought that it was best-in-class, but 3scale also looked promising and the price was lower and we are also really a Red Hat shop. All of that pulled us in the direction of 3scale.

If you want to significantly impact how your developer portal will work, then you shouldn't think about 3scale as your base for the developer portal. If you just want something out-of-the-box, then 3scale would be sufficient. The consideration should mainly be around the portal.

Overall, it's the organizational things that make you succeed or not. We could probably have managed the API transformation path that we're into, trying to go to API-first, even without the gateway, but it would be a bit harder because it wouldn't be a natural thing to have someone proxying all the things that go not only into the infrastructure but also into the organization. That's the crucial part for success with API management. The product has helped us to get there, but theoretically, it could have been done without the gateway as well. It helps, but it's not a silver bullet.

Setting the portal aside, since we have decided not to use it, and just rating the parts that we are using, I would give 3scale a seven out of 10. But we haven't even tried the Fuse part. That could be a strong addition if you want the ability to integrate as well.

Our primary use for 3scale is for promising internal and external exacts, as well as providing HIT to computers.

One of the most valuable aspects of this solution for us is its ease of deployment. Also the fact that it's not adding a lot of features like ESP or similar features is good. It's okay with just being a gateway.

We haven't been working so long, so we are just starting to use it. I believe the CMS part of it has room for improvement though. That is where you write a couple of things if you want to publish your API. It's based on liquid scripting, which doesn't seem like the obvious ones to script with.

I would also like to see it work with open API specification 3.

It seems stable. It does what it does and it doesn't have that many features, but it seems to be working when you're using those features.

We will see about scalability when we begin to use it more, but all the ops files are done by four people. That's including all other ops as well, so I can't say exactly how much it would take, but it should fit into the ordinary work. We are planning on increasing the usage of 3scale, extensively I think, but we're just in the beginning.

I have a case right now actually. They have been answering, so it has been fine so far, but I haven't used it a lot.

We checked Apigee, but it mainly failed for us. The way we wanted to write it required a cloud and our organization was not ready for pre-cloud solutions. It wasn't a good fit. It was possible to run it on prime, but that seemed like quite a big installation and ops to be running.

I would say the initial setup is straightforward. I haven't been doing the installation by myself. The operation people have done that, but it went well and we had no problem with that.

They said it should take just an hour or two, and we were laughing. That's what it should've taken, but I would say that they were done in a week. I think when you come to a new environment, it's not just the product. It's other things as well. So I would say that one week is pretty efficient.

We had some assistance from Redhat, but it was quite straightforward. We didn't bump into any issues at all. It was on Openshift, so it was straightforward

I would rate 3scale as a seven or eight out of ten. I've had more issues with supporting it. Also, the CMS and Open API specification issues I mentioned above. Those things could be better or simpler.

We are a solution provider and this is one of the products that we implement for our clients.

This is a container platform with a developer portal.

3scale API Managment provides a platform facilitating Trusted Service Providers communicating with the service provider securely and efficiently. Greatly enhance direct business transactions and application to application communications

The most valuable features are the gateway and security features.

It would be helpful to improve the customization features so that the customer can do it based on their own needs.

Some of the portal features are in need of improvement. The API onboarding process is quite primitive. It may not fit for an enterprise who is trying to manage their API users and the approval process. The development portal needs to better address this functionality.

API management functionality should be improved so that the partner can better group it, and use it.

We have been using 3scale API Management for one year.

As we are new to this product, I'm not sure about stability. At this stage, it has been okay. We have not experienced any serious issues or crashes.

We have done some scalability and performance testing in our office, and it has been pretty good. We have eight people in the company who are working with it.

The majority of our customers are large companies and I would say that this solution is more enterprise-driven. The entry point and required skill set are quite high.

We have been in contact with technical support and so far they have been good. With the cases we have logged, they have given us responses quickly.

I have used similar solutions and I find that 3scale is more technical-driven. It uses great technologies and it is still easy for us to customize ourselves.

In terms of API management features, I think that it is less rich than the other major competitors. The way they manage the API is different, which is something that they can improve.

The initial setup is complex at the beginning because there are a lot of steps that we have to follow. Two to three people are needed for deployment and maintenance, at least.

It takes approximately six months to deploy.

This is a product that I like, and have a lot of interest in learning. It is one that I recommend to our clients. 

I would rate this solution a seven out of ten.