Layer7 API Management Reviews

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.  

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.

RESTful API implementation and exposure.

Being a key partner of CA, the strong product has helped us make joint pitches to multiple enterprises and to implement an efficient API gateway for enterprises, enabling them to manage the end-to-end lifecycle of APIs.

API discovery using CA Live API Creator is helpful for integrating with multiple backends, for discovering and kickstarting the API creation process. It is a very good feature.

Mobile app capabilities are good for building mobile apps to consume developed APIs.

API Portal capabilities are very nice, up to and including the ability to do monetization. Security features are exhaustive, with several adapters to all leading identity suites.

The development toolkit used for creating APIs should be more online and user-friendly. 

Deployment and tracking could also be improved. Tools like Apigee provide a complete online experience along with RESTful APIs, to manage all activities. It is a very nice and user-friendly solution compared to CA.

No issues with stability.

No issues with scalability.

Technical support is very good. Response times are very good. As a partner, technical support is available via phone and email as well as in several countries.

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

Setup was ok. CA was always available for any support issues.

Pricing is competitive. CA is ready to offer attractive discounts.

Apigee, IBM API Connect, and MuleSoft are some of the other key products we have evaluated and used.

CA API suite is a strong solution with very good security capabilities and end-to-end lifecycle management of APIs. It has been proven over the years and is a very good option for implementing the API gateway for an enterprise.

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.

Our clients use the solution for a secured layer to protect their API. Most of them have two kinds of API, the frontend, and backend.

There are many beneficial features in this solution that protect against attacks, such as SQL, injection, and the internet.

The Policy Manager tool that is used to manage the solution is very heavy to use because it is based in Java. Sometimes it takes a long time to load. There could be some improvements to it. If they could make Policy Manager on a web page that would be a good alternative.

I have been using the solution for approximately three years.

I have found the stability very good.

When I have used technical support they helped me a lot. Sometimes they took a long time to respond because we had very complex issues that we asked them for help with, but I think it is a very good service.

The initial setup was very easy and straightforward. However, the first and second time we did it was a bit complex because we were not used to the installation.

We have done the implementation and the time it takes depends on the client's use case. You can do the installation and have some APIs working to generate some values for the clients in approximately 30 days.

This solution is a bit more expensive than competitors.

My clients evaluate others solutions before they chose this one, such as AWS, and Apigee from Google. The most common option that they evaluated was Apigee because of the price.

The main difference was AWS and Apigee to this solution is they have a lower price but they do not have all the features that this solution has. It depends on the client, they have to decide between what features they want to implement. If there are not many features to implement they can go with Apigee or AWS, but if there are more complex implementations they try to go with Layer7.

I would recommend this solution to others. I really like the solution.

I rate Layer7 API Management a nine out of ten.

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.

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.

It’s central to our mobile-first strategy. The API layer is becoming the interface to all of our legacy back-end and all of our new app development is being built on top of our API layer.

Key features – integration with SiteMinder and its ability provide security in general, content-based routing, and ability to turn our existing SOAP service back-ends into new REST-JSON APIs.

As the APIs are built and published and made available to developers, we can build applications on top of those APIs in days and weeks as opposed to months.

In a traditional web application you’re building your UI, your integration layer, your back end, all at the same time, and there are dependencies – you can’t built the UI until you have database access, etc.

With the API model, all that access to the backend is already available so all you have to concentrate on is building a good user experience.

They have really stabilized the API gateway in the last couple of releases. There’s a developer portal that is used to document your APIs that is woefully behind the times, in terms of being able to provide a really good robust experience for the developers consuming your APIs. You can’t document all of the details you need in the current developer portal and really need a separate web site just to document your API.

You need to understand what you want from an enterprise API, what your vision, what your plans are for rolling out an enterprise API, before you just go out and buy a product.

It’s been rock-solid. When we’ve had problems with a gateway – we have a whole group of them – we typically get very good support from CA and production downtime has not happened.

Because it’s a clustered environment, we can scale horizontally as many as we need to go. So far two production gateways that are in a cluster and they’re processing transactions for one of our APIs at 30 calls a second and there’s barely a blip on CPU.

In general, I’d give them about a 7/10 or 8/10. They’re good – sometimes it can take a little while to get to the right person. They tend to come back to us with obvious suggestions, which we try before we call tech support. When we get to the right person we get an answer immediately.

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.

Nothing in IS is ever simple. However, the install went very smoothly. The OVA files that you install into your VMware infrastructure -- configuration and getting them set up in the clusters went smoothly (respecting internal processes). The setup and config wasn’t that difficult. There was much more of a learning curve on our end to leverage and learn how to use the API gateway. It’s sort of like a Swiss army knife in that you have to learn how to use which tools and when.

I look for stability in the vendor. I look for their ability to understand our needs. We get a lot of vendors who are not used to working with a Fortune 500 company and the size and complexity of our operation is big and complex. We need vendors that are flexible and who understand that their solution might solve a problem, but that might not solve it the way we need it solve. The flexible vendor that is able to provide multiple solutions typically ends up winning.