Layer7 API Management Reviews

What I felt was when we reviewed it along with the multiple other vendors in the market was that the operational side of API Management is pretty simple, so that we can ramp it up very fast in our organization. The way the product is built was really good. 

It simplifies the operational cost because it is self contained in one container, or one image, so when we wanted to scale, when we wanted to deploy a new Gateway, you could literally do it in like 2 to 3 hours or less than 30 minutes. If you have an automated way you can spin up an automated way.

We also have the ability to deploy it in the cloud if we wanted to. That is one of the very powerful things for us to get the buy-in from our operations team. 

The API Management has few products - Gateway, Portal. So far both Gateway and Portal are good but we would like to see a bit more improvements on the Portal side like giving a polished look for the documentation on the Portal. The Gateway is kind of solid.

Today it is not that straightforward to generate a document, even the data generate, and it's not really auto-generating it from the Gateway. I would like to see an auto-generation of the documentation. 

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.

It was not that complex. It's pretty straightforward and easy to set up. There are a few optimizations and nuances that you may not be able to do as a starter, but you should be able to get help from CA support to do those. 

We have a process to follow to pick up a vendor. We look at the company to see how the company is doing, what is the market presence for them and the maintainability, manageability, supportability, scalability, and whether they are meeting all the functional requirements. We have an individual line item for every section of this and we score them individually, that's how we pick our vendors.

On a scale of one to ten, I would give CA API Management a nine. The scalability of the Gateway is pretty straightforward and easy, because it's simply contained within as an image, or as a simple container form. You can easily deploy and add, and it supports a cluster architecture so that you can add new nodes on the go and it automatically gets all the things that is already available, so that is pretty neat.

I would always go back and look at the business benefit behind it rather than the technical aspect. We have to think from the business standpoint, "Why do you need API Management? Do you want it to be more of an API company or you're selling your API, or you want to do an omni-channel approach? Or what is the reason, are you simplify the integration?" That drives lots of real value and that gives you full feasibility why you wanted to bring in an API Management solution. I would recommend to analyze that aspect before you try to purchase an API Management solution.

We are using Layer7 API Management as an enterprise service bus, ESB, and B2B security gateway.

There is not a comparable solution on the market to Layer7 API Management. It has been useful for our organization.

The most valuable feature of Layer7 API Management is that their policy is really easy to develop and it is flexible.

The UI design could be improved in the next release.

I have been using Layer7 API Management for approximately six years.

The solution is stable.

Layer7 API Management is scalable.

We have two people in my company that uses this solution. We are will need to train more people.

We are attempting to expand usage but because we cannot find resources, we will try to change to some other product. We were using it for a long time. It's a little difficult to transfer every feature that we have, but we are still open to finding another product, such as NGINX. We are on the POC of NGINX, but it keeps changing. The organization is trying to stop using this product as we have a lack of resources, but right now we found that some of the features cannot transform easily. Then we want to expand, I'm confused as well about what we are doing.

The initial installation was straightforward. We split the release and the patching takes a few minutes with a few mouse clicks. We automate most of the process.

We have an in-house team that does the implementation.

There is an annual license for the use of this solution. I think we are paying for some support maintenance fees, included in that license. I don't know how it works. They should provide more information.

We have been evaluating NGINX. I have found NGINX has a better UI than Layer7 API Management. Most of the features that NGINX has are already supported in Layer7 API Management.

We have found it's really difficult to find the right resource in our Canadian market. It is more difficult to hire new developers who can support Layer7 API Management.

My advice to those wanting to implement this solution is if they have the right resource, this is a really nice product and I recommend it because it's really flexible and that they can build and customize with the vendor directly. I really am with this product.

I rate Layer7 API Management a nine out of ten.

One valuable feature is the ease of development of the policies for the product. It's very easy to have a brand new developer come in and develop a policy to expose our APIs.

It's benefited us greatly in allowing us to expose our APIs to external third-party vendors in a secure fashion.

I would like to see the GMU, the automated deployment framework, available in some sort of graphical interface. This would allow options, outside of automation, so you could see things graphically.

The product is becoming more stable as the product has become more mature. At this point, it's a pretty stable product.

On the scalability perspective, the product has no issues. It's able to scale out horizontally and vertically and has posed no problem for us. We have a pretty large implementation.

I have absolutely used technical support. They have been pretty good, especially when more complex issues are escalated. They've got some resources that do a wonderful job in helping us come to a resolution.

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 was involved in the installation and implementation. I think it was lacking some documentation around performance tuning and getting the product operationalized so that it could maintain itself. The documentation is still a little bit lacking in those areas. The documentation is available on demand, or on informal places like community chat groups where you can get information, but as far as in the product documentation itself, it's lacking in those areas.

When selecting a vendor, look at the partnership with the company. See if they're able to listen to you about your needs. See if they are able to respond quickly. See that the product provides good value. Work closely with the vendor to make sure you get things set up correctly. If you don't, you'll be very disappointed.

It’s a way for us to secure our externally-sourced API calls that come into the organization. The two things are 1) protocol translation where we can let a REST call come in and get converted to some legacy protocol, and 2) security token translation support because we need to convert a standard industry token to something an internal system will understand.

It provides a simple endpoint for applications to call and for customers to call, so it reduces a lot of the complications of API services. Most of these APIs the user never sees, like a mobile app that does something below the water line, or another partner is calling our application – such as an order purchasing system at another customer, whose app calls our app. It eliminates the need to deal with users in a lot of cases, so if users don’t have to deal with the system it’s convenient for them. It helps us automate as well.

One item that we’ve had discussions – and they’ve fixed some of it – you had to buy extra products, specifically the CA Mobile API Gateway, to get certain types of token support even though you didn’t need that product for anything else.

So, foundational token support should be part of the base product and you shouldn’t have to buy the mobile feature to get those features. For example, in order to get OAUTH we had to buy the MAG product, but I think they’ve fixed that now. But we’re not sure they’ve fixed everything.

I think it’s a solid product. We’ve had some issues with the proprietary hardware that we’re running it on, but we’re getting rid of that and going to VMs, so the issue will probably go away. At one point in order to do certain types of upgrades to not only do it through a web interface, but we had to get deep into the system – multiple things we had to do in order to upgrade so it wasn’t as seamless as we had hoped.

It's not been an issue.

I think they’ve got really sharp people. When there’s a serious problem, they’re quick to triage and get an authoritative person to respond quickly.

Pretty straightforward; the biggest issue was the initial hardware that we purchased. CA sold the product on a certain kind of UNIX box, but those boxes weren’t appropriate for the solution – it was well before CA took over.

We knew we needed some kind of API security gateway to basically sit on the edge of our network and police what could get in, and do other things like translate API calls. We wanted a simple API call to be translatable to multiple backend system. Before we were just using traditional web proxy servers, not really API focused.

We knew we needed some kind of API security gateway to basically sit on the edge of our network and police what could get in, and do other things like translate API calls. We wanted a simple API call to be translatable to multiple backend system. Before we were just using traditional web proxy servers, not really API focused.

We used IBM DataPower at the time. Both HP and Oracle were OEMing the Layer7 product at the time, and the fact that HP was OEMing it was certainly a factor. We were looking for someone that’s innovative; someone we can trust to be a long-term partner.

It fits in well with our other security middleware. We’re also a SiteMinder customer so there are some synergies there. When CA bought Layer 7, that was a good thing for us, and we sort of fell into those kinds of synergies.

They should make sure they find a product that supports industry security standards, and has good management capabilities, good manageability.

My company is a CA partner. We do implementations for end-customers, using CA API Management. So my company doesn't use the product, but we install, configure, and implement the product for our end-customers.

Primary use for the solution is to have access to APIs that are generally difficult and not available. An example would be critical APIs that should be available 24/7 but they are not available most of the time, because of one or another constraint. That is where the API Management solution is used to the maximum by end-customers.

Let me give you an example from one of my customers, a tier-two telco in the UK. This customer was getting an API that was available to their developers for only two hours a day, and because of this restriction, they had to plan everything precisely for their developers to access the API in those two hours.

Now, with the CA API Management implementation, the third-party API is available to this customer 24/7. It's available any time the development team requires access to the data or the information. This result has quickened the development pace and the testing cycle, and it has saved a lot of our dollars for my end-customer.

Security is the most important parameter of the solution, for me, because whenever you are exposing your APIs to third-parties, it is critical that the data remains anonymous and that data is retained within the system, that it is not leaked. CA API Management provides good security features and that is very critical.

The CA API Management solution has good security features, but when it comes to being used in areas like enterprise integration, where it is being used as middleware for all the IT environments, that particular feature is quite limited. It doesn't support as many protocols as an industry standard, competing product should.

No issues with stability.

I have never had any issues with scalability.

I would rate tech support at nine out of 10.

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.

The initial setup was quite straightforward.

I feel the product's pricing is a good value.

In terms of licensing, currently, they are available for as perpetual from CA. What is really important is that they offer the solution as a service, on a subscription or monthly basis,  which will make it more attractive. That is where the market is headed. There are competitors within the industry that are doing that currently. I would encourage CA to do that.

The options that I had were Apigee and Mulesoft.

My advice would be, if it is a really complex integration with multiple protocols, multiple APIs, where security is the key, I think you should look at the CA solution. That is where it fits best. If it is you're looking at it more as an enterprise integrator, that you need to integrate internally within an organization and its IT functions, then I would suggest that you talk to CA and see how best the product can be used; you will consultation.

It's a very stable, scalable product with good security features. It does the job well.

Our primary use case is as an API gateway for authentication and authorization, and then lightweight transformation or lightweight mediation. But it's mostly, authentication and authorization, mostly security-based.

We mostly use this product for our internal customers, so it's not a revenue generator for us. We use it for internal customers to contact the IT systems. In terms of benefits, it's not for external customer satisfaction. It's not that kind of a usage here. The benefit that IT sees is, it is a single developer portal for IT; it has helped us provide an API platform to our customers.

• The lightweight mediation
• Transformation from JSON to XML and XML to JSON
• API portal and API key management
• The Developer Portal
• Some of the key SSL sessions, inside the gateway
  
• Circuit Breaker is a cool feature, too

One area where it certainly needs to improve is the way it allocates requests, in terms of rate limiting. Let's say I have set the rate-limiting to 1000 requests per second and I have four nodes in a cluster. It divides the request into four, that is 250 per node. If I have a node-balancer in front which has the least connection mechanism it sends the first request to a node. It has to improve in terms of API rate-limiting.

Also, there is no native Kafka connectivity. If they provided native Kafka connectivity, that would be good.

We found a lot of stability issues in the 8.3 version. But even after reaching out to the CA engineering team, they were not able to diagnose the issue, so we upgraded it to 9.2. Most of the stability issues have been resolved and we're not seeing that many issues now. So the stability issues have calmed down but we faced a lot of them in 8.3.

The scalability is always an issue, as we cannot add gateways on the fly because there are a lot of moving parts; endpoint connectivity is one of them. If we add more nodes then the rate-limiting feature is affected. This kind of gateway always has the scalability issue. But, I think CA is coming up with its Microgateway, which is in Beta. If they stabilize their Microgateway platform, we could do very well in terms of scalability.

Their tech support is pretty good and their documentation is also good. The community's support is also good, so I would rate them pretty well here.

The setup itself is not that complicated since we used a VM form factor. The software setup, obviously, is a different story. But the network part that goes in, the firewall connection that goes in, and then, the load-balancers, the global traffic managers, all these things are not really that complicated. The gateway setup itself is not that complicated.

It's my manager who takes care of the pricing. But I keep on hearing that it's a little pricey, it's on the higher side. That is what he says. We have around 20 licenses so for that, the pretty is pretty high. That's what he says.

This product existed here before I started with this team so it has been here for last six or seven years. I've only been here for two and a half years. I'm not sure what kind of evaluation took place, what the criteria were for the evaluation. But, I'm pretty sure that they would have evaluated two or three products before choosing CA API Gateway. Our company itself already has two gateways.

I think the main criteria here were in terms of software security, mostly securing the APIs in terms of SQL insertion attacks or XML structure attacks. They were looking more at securing the APIs and CA was probably the best at it.

My advice would depend on the use case. If it's just a proxy solution that you are looking for, I would say don't go for CA API Gateway because API Gateway is much more than that. If you're looking for a complete API developer platform and securing your APIs, then CA API Gateway is a good product.

I give this solution an eight out of 10 because, as an end customer, in terms of managing my API lifecycle, end-to-end, it is pretty good.

Mainly for our API gateway. We use it for onboarding APIs and then getting those internally. We have them through the B-to-B channel, we have them through a member channel, and then internally as well, to service our APIs.

It has performed pretty well. We've had an issued with scaling, internally, when we slammed it one time with a very, very high rate of transactions; we're talking like 65 million an hour. Whenever we did that we weren't ready for it yet, so we had to back out, but it's been good.

It's pretty easy to use, and once we have templating set up we can add new APIs, at least through the gateway, and apply the security to them; it takes a minute. 

We actually have it automated in our Dev environment, where developers can come in and fill out a form with an internal tool. They specify their API, the endpoint they want, this is what they want, and boom, it creates it in Dev and then they can move it up to test and then put in a request to get it to product.

We've used it for so long that I really can't say that it's improved the way our company works, but it works very well for us.

I'm mostly involved in using the OTK for OAuth security. We use the OAuth for all of our reactive APIs, for B-to-B to come in, and we're starting to onboard those now. 

It's been pretty easy to use so we enjoy that, other than a couple of challenges we're having with it currently.

It would be nice if we could create APIs directly from Swagger files. We're doing that ourselves with a middle layer. But if you could integrate with open API Swagger specs, and then just create a Swagger and upload it to the gateway and it would create all my API template policy, and would apply the OAuth restrictions, the types of security restrictions I have on there, that would be pretty cool.

Stability has been fine for us in tests. We have a challenge around some log rolling and it bringing it down in tests, but in production it's been great.

The scalability has been good. We haven't had to scale up a whole lot, even with all the extra transactions we're running through it. We're in the area of about 2 and 1/2 million OAuth tokens issued per hour, and it's performing fine with that.

It seems to work pretty well. Sometimes it takes a little longer to get answers than we would like, especially to some low-level ticket where we just had some questions about why this thing is working that way or that way, not high priority stuff. It would be great if we could get those answered in a day or three, instead of two weeks.

I was not involved in the initial setup but I am involved in the OTK upgrades.

Well when we went from 9.1 to 9.2 it was pretty straightforward. The OTK, however, is a complex upgrade. They tend to change the schemas on the database behind it, between the versions, which can be a pain to have to migrate all of our existing clients from one database schema to the other. It also means working with the DBAs to set up side by side schemas so we can get them moved and switched over in a fully available.

I don't really select the vendors, but my most important criteria would be

• available support
• industry use of the tool
• that it can solve all the problems I need it to solve, as many out-of-the-box without customizing it as possible.

CA is great. It depends on your use case of course, how much you want to go with that, because it can get pricey and depends on the size of your company. I've got a bunch of friends with little start-ups, so it's nothing they would be able to onboard, but I would definitely tell them to check it out.

The most valuable features are definitely the security it provides and the ability to code to the roles, so that way, when the people come in, they actually have their roles identified and then, we're able to actually distribute the data through the message, to them. Role usage has really been important for us.

I think the device itself has helped us quite a bit. We're able to do things a lot faster, because of the device. Because we identify the policies, we're able to layer the policies that are already written. People don't have to rewrite code multiple times. We write a policy one time, and then we're just able to just drag it over and reuse it for other things.

I've used the device since it was the Layer 7 device, and it's come a long way. I think from a mobility standpoint, there's a lot of things that we do, and we have to create our own policies.

I think the product's getting better every iteration, and they're adding more and more functionality to it, that allows us more reuse.

I would just like to see where it's going to go through the roadmap, and I think it's got great, great potential.

We have been using it 8-10 months.

It's been very stable for us. We're using it as an appliance, so whenever we need to put new ones in, we just download it, implement it, and then just pull over the configuration files for it. It's been very, very stable for us, and the patching's been fantastic.

It's definitely a scalable solution, so you can create clusters in production. What we've done is, we got a cluster on our main data center, and then we've got one in our backup data center. Then we can add on to that as we need to, and use the load balancing functionality to scale it indefinitely, as much as we need for our load.

The support that we've received has been fantastic. We've been able to talk to people everywhere from pre-sales, actual technical people, whenever we need it. Literally, the support team has been 100% behind us. We get stuck on something for a very, very short period of time before they're there to help us.

They've been easy to contact, not only via the normal contact through the phone number, but even through emails, they're very, very responsive to us.

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.

The setup was very easy. We just downloaded the actual VM appliance; implemented that. There are six or seven steps that you do to configure it for the environment. Once we set up our load balancer and stuff, it was up and running and ready for us to use. It's very, very simple.

The patch process is the same way. All you do is you download the newest version, put it out there, and then just do those six or seven steps, and we're up and running. We can replace it very quickly.

I did some due diligence. I think you always have to do some due diligence, and I looked at some other products. I don't think any of them met my needs, not as good as this product did.

I think it can get better, and it has over the different versions. 9.1 came out, and it offered some more functionality. They've added more products around the solution to make it better, so I think there's always room for improvement. I think it's been very, very stable for us. It's worked every time we've needed it, and it's allowed us to do a lot better for as a company.