Layer7 API Management Reviews

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.

API gateway.

We can create multiple orgs and set up policies and management. We can also integrate with an APM solution. We have 1000-plus APIs to be built, policies set up, security handling, and API status in one portal. These are the high-level details. The developers in my team would be able to provide further detail.

CA API Developer Portal and API Security policy.

We did an assessment and are continuing with implementation. I would not say it's 100 percent perfect but, currently, all the features we anticipated using are working. The only issue we have is that we have to buy an APM license separately for end-to-end monitoring. That is something we are looking into.

We have not experienced any issues with stability.

We have not experienced any issues with scalability.

Technical support is very good and responsive. We have a dedicated support person. Initially, we leveraged CA Professional Services.

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

Initial setup was straightforward. We were able to set up in five weeks, including policies.

We need to know the ROI three years down the line. In terms of minimizing cost and licensing issues, I would suggest that you not buy piecemeal.

TIBCO Mashery, Mulesoft.

I would suggest you do a PoC with CA, for feasibility.

Administration and configuration of the platform API management version 9.2. SaaS, security configuration, design, and implementation of APIs, which are exposed to partners of the company for the execution of business flows. All this is done quickly and easily with minimal effort.

• The API Gateway has allowed us to manage and maintain systems quickly, with great versatility, while solving problems in real-time.
• It allows us to keep clear traceability of the changes made in each of our APIs.
• A large number of security measures have been implemented which make data manipulation more reliable.
• As a SaaS product, control over some configuration elements and environments is lost.

• The speed and versatility in the implementation of APIs without writing a line of code in any programming language.
  
• The solution has numerous configuration options to increase security in communication.
• The administration interface (Policy Manager) is very easy to understand and use.

• This is a punctual need for the characteristics of the business or at the request of some partners: It is the use and configuration of VPNs, which in the current version is not enabled.
• Expose system properties and other configurations via the GUI (Policy Manager).
• Increase tools for manipulation of JSON messages.

It is primarily used for API Security. It has performed very well on the basic security front, but then this product is a suite of products, so it has multiples of products. We are not using all of the subproducts. Now, we are looking for a new use case where we want to use it for mobile apps. That is what we are currently exploring.

The time to go to market has been improved in developing new things while we use this product. We are able to go to market and deploy our functionalities very quickly. We are able to embrace newer security standards. We are able to do that easier because of this product, because of CA API management.

Security is definitely the top one, and other than that, it is a quite customizable product. I have seen that they are coming up with newer features and they are quick, coming into the market very quickly. Compared to other vendors, this product is much faster in coming up with new features, which is good. 

There is still room for improvement for the CA API Developer Portal. It is still not on par with where the competitors are. Other than that, the Core API seems to be very resilient and strong on the security front, but then the CA API Developer Portal is the only piece which I think can be improved. 

It is quite stable. 

We have more than 100 nodes and things are going well so far. However, there are a few cases where we are learning about some outages and that is when getting good visibility of what is actually happening would be the key. In a few of the sessions of in CA World, I was able to get to know more about what additional add-ons we can do, how we can get good visibility, and what is lacking currently. 

We did use technical CA support and it was really nice. 

There were very few scenarios where I was not able to get the answers, or maybe my use cases were maybe unusual use cases that they were not able to come up with the answers. Therefore, we definitely get good responses from the technical team and they are quite responsive.

There was one scenario where they said there is no solution for the kind of requirement that I had. For all of the scenarios that I have come across, they have been able to give me some solution. There was only one scenario where maybe my use case was quite unique.

The solution was already in my company before I came.

I was not involved in the initial setup, but I have been setting up new instances, and it is quite straightforward. 

Getting new security standards so quickly into the product is definitely a new surprise. In the CA World, I am seeing a lot of new subproducts that they are introducing, which I was not even aware of. I think that definitely surprised me that CA is investing in the CA API management product and building new offerings and new solutions, which is really nice. That is where the industry is going and they are putting their time and efforts in the right solution and the right product.

The gateway and the new offerings that they are coming in are very capable. The two points that I am missing are primarily from the development standpoint. 

I would suggest CA API Gateway to my friends in some other companies who are trying to deliver it: more from the security standpoint, the ease of setting it up, using it, and customizing it. Those were the key factors that I would be promoting about this product to my colleagues or friends.

Most important criteria when selecting a vendor: Support and the new features that they bring into the product. Those are the key things based on which we are selecting the CA API Gateway. 

CA has incredible reach in the market across industries. To have the opportunity to partner with CA has been great for us, a great exposure. They have got a very compelling platform that enables organizations to easily develop and roll out mobile applications. 

A lot of their customers have come and said, "We'd like to be able to enable these mobile applications with biometric authentication capabilities." It is really a nice blend. We are able to provide that capability to enable that platform to deliver that to their client base.

Our solution has been around for several years now. It is FIDO certified. It has got compliance certification from the government, so it is very stable. The underpinnings of Samsung Pay deployed in South Korea. There are five and a half million consumers using that platform. That is one of the largest biometric deployments probably out there today. Then, we are a global organization, so we have deployments throughout the world and across different industries. 

The solution is already supporting about five and a half million consumers in South Korea, so it is scalable. Today, there is a server element to that solution. From the client's side, it is SDK-based, but there is a server element. We can support about two million users on each server, then you can nest servers together. 

We have no concerns about scalability at this point.

We have not gone into production yet. We have not had direct experience with CA's tech support. I can tell you that our development and our technical folks have been working very closely with their development teams. They have teams in India that we work with and teams in Vancouver that we work with. It has been a really good experience for us. Because it is global, you have got to be around the clock to some degree. So far, there have not been any issues. We have a US-based tech support team that as this thing goes into production with clients, we will be leveraging that team as well as the CA team.

There is a server element and a client-side element. The server side installation is fairly straightforward. We don't provide hardware for the server installation, but we provide specifications, then we will help an organization work through it. In pretty much a day or two, you can get a server stood up and working. 

On the client side, it is integrating. You're taking this SDK, and you're integrating into native mobile apps. The complexity of that depends upon what you are trying to accomplish. Certainly, with simple use cases, we have had people spin this up in days. As you get more complex in the use cases, you might be looking at weeks. However, this is not a three to six month type of implementation timeframe. It is more of a three to six-week type of implementation timeframe.

I do not have a lot of competitive information on other mobile access or mobile API gateways. So, it is hard for me to say how it ranks against other competitors. I will say that it seems like it is deployed in dozens, if not, over a hundred different companies. That says for itself that it is a very strong product. 

I would put it up in the eight to nine category out of a 10, if I had pinpoint a number.

Most important criteria when selecting a vendor: CA is extremely appealing because of the reach that they have across industries, and they are pretty deep in many industries. They bring some brand recognition to the table, and obviously Samsung has a very strong brand as well. You combine those two brands, and that just creates a compelling offering which will get the attention of companies out there. 

Obviously, the support piece is important, the product stability, and how robust that product are very important to us. We look at that on a number of different dimensions.

We use this as a Cyber security appliance and also as a centralised API management platform for partners.

We've got all sorts of threat protection in the API Gateway, from DDoS through to SQL injection and things like that. These are standard features that we use within policies that we drive out the Gateway.

We've got a security policy fragment that we know is consistent across all the APIs we expose via the gateway. Also, as it's a fragment, we can add to it at any point, as new vulnerabilities are discovered, which will then secure all the services/apis that use it. This gives us greater agility and confidence that our APIs are secure.

Security is the fundamental use of the gateway so the security assertions are heavily used and are consistent. We also use it to broker asynchronous messaging across DCs transforming between messaging technologies to provide real time updates for customers in a really secure way.

Also, the actual management of APIs is fundamental to us, as we're a heavy API user/provider. So, obviously, a centralised management platform is important.

We have cases open around the SQL injection capabilities that need improvement. Cross-origin resource sharing policies need to be made a common assertion in the Gateway, that's not there at the moment out of the box (although it is available as a policy fragment). 

The developer portal needs to fully supported SOAP services (including WSDL publication with security), it would certainly push adoption for us.

Verbose logging in production has caused us a couple of issues, never enable this in production! In addition pay attention to name servers for DNS.

Scalabillity, like most things, is in the hands of your own business to implement. The gateway is flexible and can be scaled to the level you see fit. Be aware though, verbos logging will bring your platform down in seconds, so only use in non-production environments.

We have a few cases open. I'd say I'd give an average rating of around 7/10 for technical support. Some people have been very helpful and others not quite so.

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.

The setup was complex, definitely complex. As above, don't underestimate the effort required to build a HA/FT instance of this for both the Gateway and the Developer Portal. Be aware of additional licenses for your warm standby. Ensure you get plenty of non-production licenses.

Both. The vendor team seemed technical enough. Note: Ensure that your in-house teams and the vendor supplied staff are fully aligned to make deployment efficient. Deploying the gateway platform is a full project and would need managing as such.

There has a been a lot of confusion with pricing and licenses, especially around the number of cores. In addition, don't underestimate the effort required to build a HA/FT/DR instance of this for both the Gateway and the Developer Portal. Be aware of additional licenses for your warm standby. Ensure you get plenty of non-production licenses.

I don't remember all the evaluated options. We reviewed, it must have been six or seven, maybe more, API management vendors.

I would say that, although the Gateway is geared up for managing SOAP services, the developer portal isn't. It's a gap for us, which means the developer portal isn't quite as good as we thought it was going to be for managing SOAP services ( which we have quite a lot of). They're not discoverable in the portal, as are RESTful services.

I use CA Live API Creator to integrate data from a variety of sources, and then to provide an API response to calls from my client applications.

There are a couple aspects of performance. One is just speed and uptime, and it's stellar in that regard. The other is, how much effort is it to put it in place in the first place, and then how much effort is it to keep it operational. That's where its real strength is. I'm able to do things quickly and easily that I couldn't do before.

The benefits are rapid development and deployment of APIs, which means that your information, your ability to handle information, to receive it and to send it, to visualize it, to report on it, to get intelligence out of it, happens fast and happens with accuracy. Faster is better.

It really allows us to do things that we just weren't doing before, things that we always talked about doing. Some things that we talked about doing for decades.

One of the things that we talked about doing for decades was the ability to bring data together from different sources, sources that maybe wouldn't otherwise be available. Maybe they were not ours to own. Maybe they were in a place where we just couldn't connect securely to them and enforce our security policies. What we can do is, as those things have developed APIs, we can consume APIs so we're building an API to consume an API to deliver an API. People can keep their roles and responsibilities, they can be responsible for their data integrity, and yet we can use that information to do what we need to do.

The most valuable feature is that it enables me to present data in the format that the client wants to consume it. That client might be a visualization tool, that client might be a report, that client might be a customer's API requirements.

The challenge is, how do you get the data structured in the way they want it, as opposed to how do you get them to change. My job isn't to make them change, my job is to give them what they want. Honestly, when you give people what they want, it's easy. When you try to get people to change what they're doing, it's hard.

The latest version that just came out at the first of October really was a powerful move in the right direction. I was very, very pleased with that because it allows now beginning to use information of things. We've got this IOT infrastructure that we can plug into, and for my use cases there are a lot of outdoor sensors that provide valuable information to my customers.

As we've brought on MQQT, and other ways of talking to those sensors, that just makes my life easier. I'd to continue to see them expand the scope of the product. But I can say that I've been extremely pleased with the work they're doing. They're not sitting around, every six months we get a release with major improvements.

Larger organizations have a real challenge. They have to control all the people that touch their data, and when it goes wrong - you've seen it on the news recently - it ends up being major headline news story. "Equifax exposes data to 150 million customers." That's intolerable to these customers.

What happens is that the companies that are working with that type of data have extremely rigid policies for who can get access to what. As we continue to develop the product in that regard, we would like to see continued integration with other CA products that accomplish that goal. I'm not saying that it doesn't do it now, I'm just saying that scenario where there can be continuous improvement.

I've used it for four years and I have not had any issues with downtime or with performance. That's partly because it's leveraging networks; modern networks are stable. Ultimately, people want their Netflix and their movies over the networks. There is a lot of money going into uptime, and performance, and speed of mobile networks, of physical networks, that we just leverage.

We benefit because of the performance of those networks. All we're doing is leveraging public networks to move data securely.

In my use case, I've not dealt with the type of data that usually responds to the scalability issue. Generally, when people ask that question, they're talking about scalability of hits, scalability of users. Where, all of a sudden now, you have tens of thousands of records happening within a very short period of time - will this scale? I don't have tens of thousands of records happening in split seconds. However, I do know that the product's been tested to that and has demonstrated outstanding scalability results in that regard.

There are other aspects of scalability. You might consider how well can I bring on new customers, how well can I scale my development team, how well can I handle additional API integration. Because of the efficiency of the product actually doing that, pulling data from disparate sources, and integrating it into the response format that I want, that my customer demands, that's so easy. It's 10 times, 40 times, 100 times faster than the way we used to do it, and that makes it very scalable.

I use the technical support extensively. I actually read the documentation. I know that's not something that people normally do, but I actually read the documents. One of the guys said, "If so and so, whoever writes it, knew that, she'd kiss you." And I said, "Well, maybe we shouldn't go there, but... "

I actually call them, and they've been wonderful because I have their cell phones, I can text, I can call. They probably don't want everybody to do that, but they want their products to succeed, they want me to succeed, and I want to work with a vendor that wants me to succeed.

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.

I'm going to assume that this question is asking, "Was I involved when we got on board with this product?" Yes, because I bought it. They were there for support but the question is not relevant because it's so easy. It's deploying a WAR file. If you can deploy a WAR file, you're done.

Where I got involved with CA on this product, there were not really competitive products. Since that time, there probably are some companies that have come out, but honestly, I am busy enough, I don't really look because there's no reason to divorce myself from CA on this product.

When selecting a vendor, there are a couple of things that you have to look at. One is: Are they going to be around? That's always a concern because if you've committed to something and the rug gets pulled out from under you, then you're scrambling. Depending on the time that happens, you might not have the time or the money to scramble. What if you're in the middle of a big implementation? CA has been around since the beginning. They're a four billion dollar a year company, something like 13,000 employees, I'm not worried about that. Yet they're easy to work with.

There are a couple of products that I work with that have not let me down, and there are a lot of products that have. I always use Microsoft Excel of an example of this. Excel is a wonderful product, you can do so much with Excel, it's an incredibly powerful product. But there are many times where Excel just leaves me short. I just can't do what I need to do with it. It has limitations, fundamentally.

There are a couple of products that I've worked with in my life that I haven't run into that. Maybe I still will someday, I don't want to be delusional, but this product, when I've had a need, I've been able to get it to work and that's nice, I like that.

It's hard for me to give tens, but I would give it a 10 out of 10.

My advice would be: Focus on its extensibility because of that exact issue we just discussed. There are so many times when you look at a product that is a tool to make something easier. Maybe you're building a web-based application. There are a number of tools on the market that make that a drag-and-drop opportunity or a drag-and-drop process. Those tools are great for the weekend warrior, you can get something done quickly. Maybe you're a high school kid and you want to build an app for something. (Access database would be like that too. You can get a database and it's not that hard, and you can make a form, but they're not enterprise class). 

This product, at first blush, looks something like it's one of those weekend warrior tools, but it's not. It's an enterprise-class tool with the kind of usability that you wouldn't expect. And with that usability - how do you have your cake and eat it too? Well, it's because of the product's extensibility. It's very well-integrated with your existing Java library of processes and procedures, as well as your ability to write new extensions to it. You get so much of the base functionality but you don't give up the ability customize.

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.