Layer7 API Management is the first solution that I worked with, after which I moved to AWS API Management, in which I don't have much experience presently. Many of the features are not there in the AWS API Management compared to Layer7 API Management. Currently, I work with AWS API Management as per the client's requirements. I migrated from Layer7 API Management to AWS API Management.

We also use API Apigee which is more complex. You have to know XML coding and tags, for example. With Layer7 you drag and drop assertions and name them. With Apigee, after selecting the policies, you need to write some logic into it.

For APIs, we were using Broadcom API Gateway. We were using Dell Boomi iPaaS, we were using F5 load balancing, and a web application firewall. All of these components we have in our organization. We may be able to reduce the number of solutions.  

Broadcom is actually the same product as the CA Technologies API gateway. CA (Computer Associates) was bought out by Broadcom. So now the CA API is the Broadcom Layer7 management solution which they are updating and improving. We stayed with the product when the product changed names.  

I have used Mule and Apigee before.

This is the first one we've picked and then we were pretty happy with it so far.

I prefer Layer7 API Management over Apigee. Apigee has a portal-based capability which is better than Layer7 API Management.

No. Not a solution that support the full API management methodology.

The solution was already in my company before I came.

We weren’t using a solution previously, but alongside of this tool, we were using Apigee Edge and 3scale API Gateways. Each one of them is designed for a different purpose. We were looking at them as complementary products and not as replacements.

Our organization moved to this product because Cisco stopped supporting its gateway.

In terms of using this solution to modernize legacy systems via microservices/APIs or developing a new platform for mobile/IoT, we haven't used CA's API tool, but the API tool we are using right now is helping us replace some of the old, monolithic systems. It's helping bring a more agile approach to our API development, our exposure of microservices to the world.

TIBCO Mashery which was good any for API gateway, but needs more monitoring and easier methods for setting up policies.

We work with a few other vendors, I don't want to name them but they are leading vendors in the API Management space. We picked the CA solution for a few reasons, because we have some legacy protocol that's being supported only by CA API Management and that is the reason why we picked it. Another reason why we picked it is the operational management is much simpler when compared to other vendors.

We didn't have a previous solution specific to this. We had some other products where there was some overlap with this product, but none of the products accomplished what this did. We had a specific need.

There were multiple products that were specialized in different things, but they could do some of the stuff that this product could do. This solution is very narrowly focused on API management.

I still use multiple solutions. I use some open-source solutions, I use some of the competing enterprise solutions, and I use CA as well. It really depends on what my end-customer really wants. It depends on the use.

I'd used it before, so when we created our mobility team, with me as the manager, I knew that this is the device I was going to have to put in front of all my services in order to make them reusable.

It was once we'd actually standardized and built everything out, then we made room for the device, so it was just no more than procuring the device, and putting it in place at that point.

When I’m selecting a vendor, I want to look for somebody who cares about me as a customer. I want to find somebody who actually wants our solution to work. I think the team has been fantastic at that. I look at what other customers think about the support and, have they gotten anything good from their support teams? I look at that.

I think the last thing that I would look at would be price, to be honest, because I care more about the solution. Is it going to work for us? It's a partnership. When I meet a vendor, and we're actually going to put in one of their tools, or we're going to use a tool, or an appliance or whatever, to help us, then that to me is a partnership, and we're in this solution together. That's what I really, really got from CA.

We have ELA with other product vendors, like IBM and Oracle. However, we thought CA might be a good option based on their support within the account. The CA folks who are working, partnering with us within the account and our organization, they have been very reachable and very cooperative.

So even though we have licenses with IBM and Oracle for the same kind of products, API management, we are going ahead with CA just because of the trust that they were able to build. 

Initially we were using MuleSoft Enterprise Service Bus (ESB) before we switched to CA API Management.

It was an architecture decision to move towards a mobile-first API strategy. We realized that in order to meet the requirements of an API of a really good, strong enterprise API we needed to centralize that. That started us looking at APIM technologies. We scored a number of different vendors and brought in some to do POCs.

We were using the ESB solution, we were using SOAP services and then we wanted to move to REST based services so that we could open up our internal assets to our customers directly.

You look where your pain is. If you can perceive pain, you know what you need to do. Where does it hurt? That's what you need to work on.

A different solution didn't exist. You developed things in code. You used C++, you used Java, because that was the only way to do it, to build it yourself. Now, much of the lifting is done, but the extensibility is still in the product. What you're forced into, or what you have the opportunity to take advantage of, is a system that has done a lot of the hard and mind-numbing, repetitive tasks; simplified so many of the things that you would have to do. Incidentally, that creates an opportunity for a mistake. Those things are automated, but the extensibility is still there on the product, so you can still do the things that are specific to your business's needs.

We had API gateways before, we just divested from IBM and went with CA.

It was a gap in our company. We knew we had APIs that we wanted to leverage and work with our trading partners, for them to access it. But working with our security team, we knew that we didn't have a good way of exposing them securely. That was a roadblock for our business. We couldn't make them accessible because of polices. API Gateway filled that gap and enabled us to use best practices to expose our APIs.

The trigger, effectively, was that we had a partner, we'd done a commercial deal. The partner wanted to integrate, we wanted to integrate with the partner, but the partner had a legacy sort of application that they weren't able to do this integrating to five APIs. They wanted one interface, and they didn't want to on-board any of the logic, they wanted that to be done somewhere else, hence the CA API Management tool that does that for us. They make one call, it goes away, does all the connections, all the session affinity, with all the underlying APIs, and that partner can just make the calls as they want. They deployed it on desktop, on tablet, mobile's coming as well now, and we use it for other partners as well.

We were using a Delphi application.

Previously, we were using OAG - Oracle Application Gateway. The CDCI was not that good with that. The continuous delivery and continuous integration are not readily available and there are a lot of bugs in the code, in the product. In comparison to that, the CA tool is less buggy.

There were a few reasons for choosing this vendor. The first being the continuous delivery and continuous integration, which was one of the major things we were looking for. Next, we wanted to look at the portal and the API itself; how do you manage the APIs, giving access, access control and all those aspects. The third thing we were looking at was security. So, these are 3 different things that we were considering whilst selecting a vendor.

I was involved in the decision-making process to adopt the solution. Initially, we had a normal NetScaler load balancer. However, the challenge with that tool was once your APIs get exposed to the internet/the mobile phone, how to pass the username and password from your mobile phone to your back-ends.

The mobile experience demands that you don't want users to authenticate every time they want to use the application. For example, the Facebook user experience is such that once you enter your username and password you are logged in and whenever you come next time, the token gets refreshed. A similar kind of experience is what we were looking for and that demands API management.

We have used WSO2, Kong, MuleSoft, and other open-source products.

We were using the API Gateway before. 

The industry is moving is to be more API-oriented and more self-service oriented, which is why we invested in a new solution.

We were transitioning from another product, DataPower. We switched because of the native support for APIs in API Management.

We were using Vordel Gateway, but it lacked the flexibility and integration capabilities that CA API Gateway provided at the time.

When we looked at this emerging API management need seven years ago, we looked at the Gartner recommendations and then looked at our organization’s needs at that time and kind of picked CA right from the beginning.

We have multiple solutions in house. This is the one we choose for now for certain products. There weren't really better products and there's only certain product groups in the market, and we only pick the best-in-breeds. CA was one of them.

For me, the most important quality in a vendor is technical support. I want support from end-to-end, including documentation, technology, and written materials that I can download and review myself and then reapply.

We were not using a different solution before. We were looking in the markets for solutions which would help us give this level of scalability, based on the nature of business that we have.

We never had a product like this because API management was always a discussion and we never knew how to implement it. When we saw this product and figured out that they had the features we wanted, then we took our time to perform due diligence and figured out this was the right product for us.

We used Apigee and API Connect. I found that CA is more stable than the others. When you are deploying code, you also need the previous versions. With CA I can track all the changes. It's more stable and reliable.

As a systems integrator, we use several API management products, with CA being one of our key tools.

I work in a consultancy, so we do projects with other products. However, our partner product is with CA Technologies.

We use Microsoft IIS in other areas to expose services against a load-balanced cluster. So we have these bulk security components within it. They've never been compromised but we thought we'd would add an off-the-shelf security appliance to add an additional layer that also comes with API management capabilities.

We were using an in-house built solution which used Tomcat servers and were quite complex. We wanted speed which is the key for success in the current marketplace, so CA did deliver that. We wanted that speed. We were able to really get up and running fairly quickly because it is mostly configuration driven as opposed to doing things from scratch.

We did not use another similar solution prior to this one.

I don't know if we had a previous solution before going with API Managment. We have a number of CA products. Some of them, we started with the CA product and some of them we started with other products and then switched to CA because of their high availability and high reliability. We are not looking to switch it. It’s nice and stable.

We didn't have a previous solution.

No.

This is the first API gateway product we’ve used, and we looked for a vendor who has a reputation for establishing long-term partnerships.

We didn't use other solutions before this one.

We were using an IBM product. We switched because we had some constraints, technical issues, support issues, and some other issues like use cases.

It's a completely new solution for us as we were not dealing with REST-based APIs up to that point, and internally we are used to using SOAP Vitsa-based web services instead, as the major application technology. Now it's more and more moving to the REST-based approach with some kind of mircrosource architecture concepts that are being introduced, so we need to look for another solution or some kind of add-on to a existing integration infrastructure.

We didn't use any previous solutions in production. We tried different products in the prototyping phase more than five years ago. This one fits our needs the best.

Previously, there was only SOAP services. When you are making an API call with SOAP services, It has a lot of impact on the application by taking too much of the bandwidth. 

Now, all the users are filling our their forms in the back-end with form data into JSON, and sending the information to the REST services.

People want the REST services. There are already existing applications which are running on the SOAP services. Rather than losing their businesses, with the help of CA API management,  they can have both their REST and SOAP services in the back-end.

We did have a previous solution, but the lack of a feature set, only cloud-based implementations, and lack of customizations drove us towards CA.

I did not try any other solutions previously.

When we first started on the Gateway, it was a different company, then CA bought it. The difference from that other company, which might have been a smaller company, from there to CA has just been the responsiveness and that extra level of training and other support that we are getting from CA. 

We were using Forum before, but we wanted a much more flexible solution that scales and has better performance. That's why we chose CA's API Gateway, to resolve our security, and provide the best performance for all the APIs that we have.

We introduced the API Gateway. I wasn't here at the time, by the way, but we didn't use anything in terms of that. We bought it really for our protection and security capabilities. So the main thing is the API, the whole API management piece. We did go out to tender; we invited about six, or evaluated about six, different solutions and selected CA.

The only solution I use is CA APIM and it’s the best. I haven't even thought
of switching into another one.

We were previously using a different API gateway. We had some issues with those servers. We did some evaluation in the market. I evaluated server software and IBM DataPower and Intel products. Finally, based on all the features, like security, we decided that the CA product is the best suited to the needs of Motorola's business.

We didn’t use a solution before this one. CA is the best in the market in terms of stability, scalability, and policy development. They are the best at achieving custom scenarios related to clients (customization) in all perspectives, besides the current API Portal 4.1, as it is not yet matured enough. There is nothing to worry about in the 4.1 portal.

Previously, we chose to use CA-provided solutions (AuthMinder and RiskMinder), which includes (JSP-based) user interfaces. Also, because we have to make our own designs (RIA-JavaScript-based), that’s how it came into the picture.

We used Layer 7 before CA acquired it.

This was the first tool that we used for API Management.

No. Selected after extensive "beauty contest."

I used to use a proxy to publish APIs, and now we want to use the CA API gateway, as it's more advantageous.