Layer7 API Management Reviews

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.

We've been using it to program intermittently. There's a problem with one version, which saves pretty slowly. Now it's good. Then we found that this is cheaper. The advantages include the coding, as well as getting emails and alerts from them.

I mostly used it when working in the banking sector. There are many bank connections going on every day, especially during the holiday season, which can be kind of tough. We need to straighten the books, which can include how much money came in, how much money was lost, etc. If the information is not there, there will be a problem. We needed a program to keep track of the data.

This solution gives us an insight to the original view. It tells us how much data is there and it provides manuals to use it. So the technician office is there and it gives us some data. For the moment, we can change anything in the software, like enlarging it for example. 

It improved our organization because it gives the management data to discuss for the next course of action and it suggests what to work on, as the next thing.

I published APIs in the CA environment also. That's very good. I haven't done it in my workspace on a personal level, but it's a good thing. I have already published APIs with other solutions, but there is a bit of a difference and that is good for CA. CA is better than Apigee because CA allows you to make changes and is a little generous in terms of where to go with the project. It's good.

It's very good at supporting a large number of APIs or transactions. The transport of APIs is needed. Everything in CA is very easy for developers, because when a developer logs he can view it right away. With other systems, it isn't as easy. I like this. It's going up in the market.

I think it's very valuable because of the support desk in one application. It protects us well. That is very important.

In terms of security, it's mostly been enough until now. I had used them in my local work. I was playing with them and saw that they support everything. It's almost all covered so far.

From the last version, they have added more dashboard support, but there is still a lot they need to improve. The thing is, on the chart you can set it to forty seconds or one minute. That's fine, but if you hold any request it should be clear on the graph. For instance, on the dashboard of the graph it should be written around it. It should say, this is the response time here, etc. In terms of monitoring, it's almost all covered. The interface can be improved, though.

It's really stable. That I can assure you. That is the one thing which I have to fight for with my managers because they ask why we should not move to a different solution. They said another solution is more stable. I told them that they are looking at the market analysis. We should test it ourselves. It's a really major banking project that we're working on.

Scalability is really good because it's very easy to create new users. It's really good.

There are 43 people using CA. We will use CA to its maximum capacity. It has become very popular in my office.

I never needed to use their technical support. If you need it, you could chat with the online support team. That's it.

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.

The initial setup is simple. If you are a novice it could be complex, but if you are good at working with computers it should be very simple. It takes about seven or eight minutes, including configuration.

All we have to do is consider our code and environment for the applications. For instance, what things are going to happen.

We used three people for deployment. One is project development guy that we might move because development is getting smooth nowadays.

We currently have 18 people, of which seven are developers and three are in management. So there are eight people in back-end maintenance.

You can imagine that we are in a gem mine. It costs money to supply the equipment and then we can get 45 gems. It's difficult to know the ROI until you get the gems out.

I would say implement it. If you are new to APIs and things, you won't understand it, but if you have some experience it will be okay.

I would rate this as eight of ten.

We use a combination of Denodo and Layer7 API Management. The APIs are developed on Layer7 and then exported through Denodo. Layer7 provides the security layer, while Denodo facilitates data on demand. That combination is handy, and most organizations have a similar setup. That data is exported to API. The data modeling is done on Denodo and exposed through policies developed on Layer7 API Management.

It's good to have a tool for integrating data between organizations and applications. The combination of Denodo and Layer7 is beneficial. I feel like Layer7 would not be sufficient because most APIs need data on demand. We need to provide data on demand on top of some layers without going back into the native data systems. 

That will help developers not tax something on the line. We just develop on top of those databases or data layers. You prepare a logical data layer to provide an API exposed through Layer7. Using Layer7 and Teams or different applications can consume those data easily. 

API Management makes dealing with APIs easier. It'll help you to move ahead on your API application journey. The solution allows developers to create more advanced security policies

I feel like Apigee's API product is more interactive. You can drag and drop with those, but it's a little more difficult in Layer7. It's less user-friendly compared to that Apigee product. However, the overall user experience is okay. 

We have been using API Management for three years. 

Our deployment is stable. The company was using API Management before I joined. It's pretty stable and people are developing their APIs on it. The integration Layer7 provides works well in our environment.

API Management is scalable. We did some horizontal scaling and adopted a clustered approach, with two or three nodes behind that. We have that kind of scalability in our environment, and we have a hard drive. We're processing millions of jobs a day that are handled well with the cluster setup we have in place.

Solutions technical support actually falls. I mean, in our area, we have to get a team around it, so that some of the APIs won't get fail and the possibilities of capturing the records. Second thing is to deliver the migration of the APIs to higher environment. So this falls API, I mean, under support task and that too includes performing lifecycle management, upgrading the API versions. So last year we did from nine to ten. So this changes are there in the bucket of support and we do handle around that part of task.

I rate Layer7 API Management eight out of 10. There's a steep learning curve, and I have spent two or three years looking at the documentation that comes with it. It's a bit difficult compared to some other products like Apigee.

We use it as a gateway for protecting some of our critical infrastructure out on the grid. We have six data centers and it is implemented in each one of them, protecting our grid.

We have several applications that talk to the grid, and they pass through that gateway to get out there, ensuring that we terminate connections from the lower security environment and reestablish credentials for the higher security environment.

Being able to protect our communications protocols, from the back office out to the substations that control the device, is helpful.

We use a pretty simplistic approach and it does what we need it to do for terminating connections and then reestablishing what we needed to do in a DMZ. All of those features are pretty good. We don't really use the full-blown API management solution which they offer, more just the gateway components.

From a security standpoint, it works great. It is the right solution for us. It's lightweight, a software-appliance configuration which was easy to deploy and configure. It is what we need. It does well protecting APIs against vulnerabilities.

It is okay for incorporating identity access control with OAuth.

The entire lifecycle management approach needs improvement: from the API management, development, deployment, some of the settings around the quotas, and some security policy applications, etc. for the APIs. We found the Apigee platform a lot more robust in that area.

The solution is very stable. There have been no issues.

Scalability is fine for what we are doing.

Tech support is pretty good. They're pretty responsive. When we have an issue we give them a call. They jump on, help us find the root cause and provide a solution, or they talk us through configuration items.

We're big CA users, so we have all sorts of their products within our environment. It benefits them to be responsive.

The deployment for CA's API Management, the way we're using it, took a couple of months and then we were operational. Our planning was typical Waterfall-type planning, at the time. We had a problem and targeted the problem with that solution. Our problem concerned security, protecting our grid-control area.

It took three FTEs for what we are doing. We also have a support structure around that. There's a whole team that manages the infrastructure and configurations of the policies. Since it has been up and running, it has required about one FTE to maintain it.

We just worked with CA and our own resources. 

We haven't seen ROI from their gateway solution, other than protecting us from vulnerabilities. In that regard, it's kind of hard to monetize things. We have definitely benefited with cost savings from some of CA's other products.

For what we are after, the pricing is okay. It is competitive.

For an API management solution, we chose the Google Apigee Edge platform. We went a different direction because CA was somewhat limited on some of the lifecycle management things that we were looking for. We use Apigee for modernizing legacy systems and for monetizing APIs, among other things.

We were one of the earlier adopters of the gateway technologies. I don't remember what we compared CA to back then. Lately, it has been between Apigee and MuleSoft and CA. We did that comparison.

We evaluate every five years. We see if we need to stay where we are or go in a different direction. Technology changes quite quickly.

CA API Management is a pretty solid product for what we are using it for. It's been good. It has served our purpose and kept us out of trouble.

Evaluate what's out there in the industry. Make sure that you chose the right product for your use cases.

I would rate this solution at about six out of ten, overall. At the time when we were evaluating it, it was about the complete lifecycle management. We were looking to build APIs to legacy systems, using IDE deployment strategies - all of those things were lacking. Products like MuleSoft and Apigee had better, more robust software development approaches for both mobile as well as web-based or batch processing.

Our primary use case for this solution is opening up our APIs to the development community so they can help us innovate some of our banking products. We've demoed CA API Management and we've done one proof of concept with it, but we are not using it on an ongoing basis.

We are a bank, and any API management tool helps us find the right partners to build new products in new markets. Given that we are going down the path of open banking, this type of tool is, perhaps, going to be one of the integral components of our tech deployment.

• Containerization
• The monetization module 

They're quite unique for an API tool. 

Although we didn't test the monetization, the flexibility of the tool could be quite useful. Right now, we're not looking to monetize any of our open APIs for the next few months, but it will be a focus for banks in a year or so. The nimbleness of the monetization tool is very good, where you can just drag and drop elements that would make up the monetization.

In addition, the development time and rollout time are pretty quick.

This is not specific to CA's tool, but API tools in general. There are two schools of thought: There is the "Apigee" school of thought that says that we don't need hardware to implement security, and there's the "API Connect" school of thought which says some sort of an enterprise service bus would be critical to the success of the API management tool. 

I find this hardware reliance is a bit archaic. The biggest reason I would want to get an API management tool is to get rid of the hardware. If I have to have the hardware and put the tool on top of it, that makes it a bit cumbersome for us because the maintenance of the hardware, for any enterprise service bus, is in hundreds of thousands of dollars per year.

It needs to go into virtualization.

One of the reasons that we chose to go with another tool was because we found that CA API Management was crashing quite often. We called technical support about this, but since the deployment time was so short, we only called them a couple of times before we made a decision.

We didn't take it to scale, but from what I've read and from the literature that was provided to me, it seems that it's built for large transactional orders.

Our interactions with technical support were okay; nothing to write home about.

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.

The setup was a bit complex in the beginning, but I think that's for true for any technology that you want to implement for the first time.

The deployment took six to eight weeks. We had a roadmap that we were following, as an implementation strategy. I can't go into what that process was. For the deployment, we had five FTEs on our side and the implementation team had another two or three, and there was also a manager.

Once it was deployed it took four people to maintain it and for API development. And then we had a team of 40 Intel developers who were using it off and on.

We used a local implementation partner to help set it up.

For the business case that we have, we would have made no money on this within the first 36 months. We would probably have started seeing return on investment when there was traction in the developer community for our APIs. Once we would have a couple of good implementations with the e-commerce companies, then we'd see a return on investment.

I also feel that from a resource-reduction and right-sizing perspective, eventually we would be able to bring that down a little bit because we would need internal product teams to be that active in the long-term.

We weren't comfortable with the pricing of licensing. It was slightly more expensive than its competitors.

We found that API Connect had superior features. The security protocols in CA's product, for financial services, weren't as good as those in API Connect.

With respect to supporting a large number of APIs and/or a large number of transactions, we didn't use it for a large number of transactions. It was a PoC so we only used it for limited connectivity. But from what I've read and from what I've heard from other users, the volume management and traffic flow management is actually pretty good for CA's tool.

I would rate the solution at six out of ten, overall. It didn't meet all of our needs.

I was doing all B2B integrations. The security features provided by the gateway are really cool. The tool can handle all complex security requirements. On-boarding APIs is very agile and fast.

In my last position, the core services were exposed to the consumers via the ESB layer. They had plenty of issues with protecting those services and keeping the back-end services hidden from their consumers.

Using this tool helped them to provide a unique endpoint, with no change to the consumers. It allowed them to change their services without affecting the customer interfaces.

I would like to see this amazing product have the following enhancements:

• Continue integration and delivery (10 points)
  Currently the tool provides REST APIs, but they are not easy to use. They need to be reviewed and enhanced. The documentation is good, but there are not enough examples.
• Monitoring and reporting (20 points)
  The Admin dashboard provided by the tool is amazing. However, this doesn't allow the service owners to view their services. The gateway admins are always struggling to provide reporting and monitoring status. We need to provide monitoring and reporting out-of-the-box for the management and service owners. We can do custom development, but not every company has time to do so. The Admin dashboard is not business friendly and it doesn't provide rich reporting features.
• RAD - Rapid Application Development - Development environment (5 points)
  The policy editor, at first glance, seems complicated and it scares developers. I would like to see it easier to understand. Maybe it could have a visual drag and drop, like with Borland C++ Builder.

We have been using this solution for eight years.

I did not encounter any issues with stability.

There were scalability issues in Amazon AWS, but not in the private data center.

Technical support is agile and responsive.

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.

I was involved in the installation, and it was easy for me.

We evaluated MuleSoft, Apigee, and 3scale.

CA API Gateway provides rich policy sets in regards to XML and REST services. This baby is great for all B2B integrations and it’s a very agile component to set up and use. You can set it up with complex security requirements on your service side in less than an hour. (I am very biased about this. No product can do that at this speed.)

The most valuable feature is security, which is the most important to our company. Then comes performance, scalability, and I see tremendous performance value without compromising the security. It gives us peace of mind, for example there are so many penetration attacks happening, DDoS kind of attacks happen in our API infrastructure if you don't have the security. With the out of the box security features from CA API Management, I can focus on the business logic to deliver the real value to the consumers, without worrying about the security. It's very stable, we've been in production for the last year and we didn't have a single production incident because of the API Management solution. I'm really happy with that actually. It's very stable and very reliable.

I see a lot in the developer portal. It's not that flexible the way we want it to be, so it's kind of out of the box and we can only do the standard features that they have. If you want to customize, it's a little bit hard for us, so I really want to see some flexibility in the developer portal. For the monitoring module, I also want to see some stability in the ESM module.

Scalability is really good and they could do an average transaction size of probably 50-100KB with around 20,000 transactions per second, which is really impressive. Initially we thought we needed many licenses, but we ended up using only one part of the licenses.

Technical support is really good. Their level 1 and level 2 support is really good. Sometimes when we try to add new features, when the team really gets stuck and we open the ticket, we usually get a response within a few hours.

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.

Initial setup is good. It's straightforward. It's not that tough and it's an appliance, so that kind of took away wireless installation and base installation time, so our IT infrastructure team really loved it.

We looked at Apigee, Axway, Intel Mashery and a few more vendors.

The main thing is whether the product is really good. Look at the Forester and Gartner reports and how the support is, because a lot of good products are out there but we have seen in the past that we don't get good support. These are the major criteria I look at.

Rating: for CA API Management I would give it a 9 out of 10, but for the developer portal I would give it a 6 out of 7. ESM I would give a 5 out of 6.

It's definitely a great product, I would ask to have an open mind and check out the features. I haven't seen any problems, and I have seen so many problems in my previous product, with ESB, so it's definitely a top notch product.

We are using it for controlling all web services, traffic, or API traffic. All connections are going through the Layer7 API gateway. That is done for the purpose of security, management, and governance.  

The ability to control the web services. Actually what it is being mostly used for is to control the access. Most of the access is being controlled through IP filtering, IP whitelist. In addition to that, we are moving slowly towards using more client certificates.  

The user interface — what they call the Policy Manager — is somewhat poor but I think that is because of the technology they have chosen. It is a Java desktop. The user interface for a Java desktop is difficult to make and it is not easy to make it look flashy. If they move to a web interface, that is another problem.  

It cannot match the native Windows interface, but it is okay. It needs to be improved, I guess. That is the only thing I believe needs to be improved in Layer 7. It needs to be easier to navigate and use.  

I have been using Layer7 for almost seven years.  

Layer7 is absolutely stable. It impresses me as a product because it never goes down. It always does what it is supposed to do.  

The organization is connected through Layer7. It is just there in between the applications, so there are no end users. It is maintained by a very limited staff and I think that is a really nice thing about it. There are just three people using it in the sense that they are acting as operators. You can say that one person is doing it full time, the other two are doing it incidentally and being back up to the main role. This limited team is made up of one dedicated admin and the other two are architects. The integration architects do internal integration consultancy. But they also act as a backup for the admin.  

Layer7 is fully rolled out so there are no plans to further expand usage. We cannot go any further.  

There is a technical support representative that we use in the Netherlands and they are okay. They do their work and it has all been fine. There was only one time in the beginning that we did have contact support in the United States, but this was a very specific issue and it was the only time we had to do it.  

The thing is that the product is doing what it is supposed to do so there is no need to really call support. The only service calls we make to support are for moving to new releases. We need to do some preparation and get educated so that nothing goes wrong. But instead of going through all the upgrade documentation, we hire someone to do it for us. They do it in a day when it would take five days if we did it by ourselves.  

There are some complexities to the installation, of course, but I do not think it is very complex overall. On the other hand, I would not say that it is straightforward. What we did was have the Layer7 people come to help us get educated. There was a company representative from the Netherlands who came to help us with courses and learning about the product and he explained things well. That was sufficient in order to get started.  

There were no initial shocks or difficult things with the installation. It ran fairly smoothly.  

But I say that it is not simple because it is not a minor effort. You have to prepare and do things as you roll it out. It is not enough to just connect it, put on the networks, and plug-and-play. You need a somewhat educated staff of people who are technically savvy enough to work with the product. But if you do everything right, then you will not have any trouble.  

The part that is the most complex is where you have to define policies. In that case, you have to know what you are doing. If you want to accomplish some things that are more innovative then you need to understand everything.  

The deployment developed gradually. We deployed five different instances and we worked on them one-by-one. It went pretty smoothly and according to our plans. We just started with one connection, then we added another connection, and then we could see what it was doing and how it behaved. You have to understand what it is doing before slowly moving into the next step.  

When you introduce a gateway, you need to reroute all the connections. You need to inform the users that they have to change the addresses in their programs. It is really a major operation. The exercise is a healthy one because you end up having to put everything in order. So the deployment itself has a value.  

We bought the product long ago. At that time it was a reasonably low price and it was a perpetual user's license. There was no need for additional licenses.  

It was a great deal if you look at it in that perspective. I think that there are some costs for maintenance that we are being charged, but that is not really something to worry about and it seems fair.  

On a scale from one to ten where one is the worst and ten is the best, I would rate this solution as a nine-out-of-ten. In order to rate it 10, it would need to be perfect. What I find other people saying is that the product portal for API development lacks some features. People who need that functionality are not impressed. They say it is lagging behind the competition. That is not my experience so I do not know anything about it. I have to guess they are right from their first-hand experience.  

What I do not know — but it could be a potential problem — is when you have to deploy the products in the cloud. That might be an issue. Because it is best-of-breed, you are not going through Microsoft or Amazon or Google. That means that you are not working with a solution native to those platforms. You may need to implement an infrastructure product somewhere in the hosting platform — for example, in Microsoft cloud — and I think it is kind of a challenge.  

Layer7 has published on their site that this can be done. But the cloud companies will probably do things in order to help promote the use of their own products and by that measure discourage customers from using products like Layer7. That might be a problem for the people who want to use the Layer7 API Management.