Layer7 API Management Reviews

We started off exposing REST APIs to other business units and our external partners by doing legacy integration.

The Gateway is a security control point and a way to drive standardisation.

Live API Creator is used very successfully by one of our businesses to run all their APIs. Other BUs use the Live API Creator to create the easy, "quick win" APIs, which do not make sense to host on the ESB or where resources are not available to do it quickly.

We handle some SOAP services where we are only interested in adding additional security and metrics on top of the SOAP services. We even transform JSON REST to SOAP where legacy internal ESB systems are not able to use REST.

We have seen a huge uptake in routing messaging services, like SMS and WhatsApp. The Gateway currently serves to standardise these into a single API view with multiple channels.

It is assisting in the uptake of JSON REST services. For quick wins, we are doing the basic transformation on the Gateway and handling all the security ingress and egress of the Gateway. The Gateway technology is an IdP for our APIs as well as in multiple different back-end auth providers.

By handling the security in the Gateway, we can standardise JWT on all internal systems, but do so in a phased approach. E.g migrating from LTPA to JWT.

We adopted SCIM v2 as a user payload standard inside JWT.

It is also assisting in standardising our APIs across the group.

We are leveraging the platform to enforce error code standardisation to RFC 7807.

Developers are now empowered to deploy their own APIs instead of our legacy way of routing everything via a central IT team. This drives the DevOps way of working as the portal exposes all functionalities via APIs once our businesses are integrated into the portal in Jira for external workflow.

The Gateway is extremely flexible, which was one of the big plus sides.

We had to do a lot of custom integrations which the Gateway made quite easy. E.g. we have shortcomings in our existing legacy product stack so we leveraged the CA Gateway to handle these. (This is not necessarily just a technology limitation but a licensing limitation as well.) The Gateway is capable of integrating into the legacy IBM space. This was one of the reasons the product was chosen.

The capability to extend the Gateway functionality into reusable components is a big plus for us.
As we start integrating more platforms we face small behavioural differences between different technologies. The gateway lets you change very low level features to to change or add to the base functionality. As an example in one of our legacy systems we proxy the other system token endpoint. That way we could control the behaviour of the token endpoints and let different systems that interpret the RFC slightly differently, behave the same.

A big win for CA was the expertise of the local country support plus having support staff on site in a matter of hours, if required. This is not a product feature, but having local support was one of our deciding criteria for choosing the product.

The Portal lacks maturity. Since the move from Portal 3.x to 4.x, a lot of features were removed. It is slowly coming back. I can see a lot of changes are done in the "background" to decouple components and make it more flexible. Those changes are just not getting to the UI side quick enough.

The CA Portal concept of multi tenancy does not align with their other products (or how most people see it) and that caught us off guard. CA/Broadcom is addressing this though. I have seen an uptake in feature development since the Broadcom acquisition of CA. It seems that a lot of our concerns were taken up and are being addressed. My rating would have been better if it was not for the Portal. The Gateway I would give a 10 out of 10.

For feature improvements, the way the Portal handles the security of APIs needs a total rework. Luckily, we could customise this layer to work for us but it would have been nice if the options were out-of-the-box. As the product set is very customisable, I would like to see an environment where customers could share and upload customised components or "assertions".

Approximately two years.

The product is stable. The Gateway is the most mature out of the product set.

We had some issues initially with Live API Creator, but they were resolved by understanding the product behaviour and how it functions. Once the back-end databases were aligned, the stability was okay.

CA was quite quick in fixing any issues with the product. The issue was rather with our side not deploying the fixes that we requested at the same speed as it was resolved.

The release intervals are very short, and you should plan for that. If your company still has a long interval view, then you will have to adapt.

Up until now, we have not hit scaling issues with what we have.

It was difficult to determine the initial requirements purely because of the complexity of our business. As a federated business, each business has could opt to go their own route. Luckily for us, the adoption was very good and we had a good uptake by all the different business units.

We implement a shared infrastructure to lower costs. We are therefore very weary of what gets deployed on a gateway to avoid impacting the bigger business. I assume purely from a control point some business units might want to adopt their own gateways and not based on performance.

It is very good. I found the in-country skill and speed of response good.

For our scenario, I think this was/is a game changer.

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

The complexities came into areas where our company wanted to change the default behaviour in the deployment model of the product. Try and stick to the vendor recommendations as close as possible. If it is different to your architectural norms, then challenge your own standards as well.

Our initial understanding of the product's multitenancy made us deploy in a specific way. It could have been done better if we had understood it more clearly.

We implemented in a phased approach. One environment was done by the vendor team. Then, we used that as training where the in-house team could deploy the last environment without the vendor team being onsite.

Keep in mind the product licensing outside of the vendor stack, e.g., if you opt not to use the embedded SQL.

If you do a TCO of more than five years, then you will see a big jump in costs for some vendors.

Make sure you cater for all environments. We went in with three environments but some businesses that came onboard later on required up to five. This probably depends on the complexity of your business. 

Yes, we short listed CA Layer7 (Broadcom), IBM, and Apigee as our final three. We also looked at other products, including the big open source products in the market e.g. Kong.

We are very happy with the solution. The product set currently falls within our development area and that is a good fit.

Some companies would tend to bundle this with security or networking as the product set also functions as a security device. By placing it in security, you are limiting yourself a lot and will never reach the full potential of all the product's capabilities. You need technical in-house people with development background to run the product set.

Constantly look at all the features. I found that when revisiting components, which were not important a few months prior, you realise in some meeting a question about a "new" capability would come up.

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.

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. 

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.

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 following features are most valuable to me:

• Extracting credentials for authentication
• Security
  
  • This product handles security in their own and unique way. e.g internal identity providers, connect to any LDAP in organization and validate, Certificate checks etc.
  • It can do certificate authentications ( one way, two way).
  • It can read credentials and connect to any LDAP including its own internal identity provider using the credentials
  • It can generate SAML tokens for security
  • It can extract/parse XML/JSON element.
  • Password once stored in cannot be viewed, but can be extracted, this is major advantage when we use basic credential to any system to connect
• Regular Expressions is one area where it has a big advantage for validation of strings

Our organization relies entirely on it for web services and RESTful APIs. Internal applications never get requests if they are not valid or authenticated, which saves the backend server's processing. Big organizations can track demand of services and drives to ROI.

An as-is string API is not available for manipulating, like we do have in Java all operations of String are not present. The hard way is by using regular expressions, which is little difficult to intermediate and beginners.

Some kinds of errors have to be reworked.

Very recently, I saw a connection reset error message for a handshake (for cipher). Many organizations have recently performed the SHA2 upgrade, so handshake errors are not properly recorded in logs.

When backend system sends error message with different MIME layer7 cannot propogate the same message, most of the times it gives blank message, backend error message is never passed to final consumer.

(observed in 8.3 for MIME application/problem+json and with error code 403)

I have used this solution for four years.

ESM gives a hard time. For example, 7.3 to 8.3 migration is hardest. Also, if we have multiple clusters, we don't have a good migration utility. Most of the time, it fails.

Login (Policy Manager) time for clients is usually not fast.

The Information Guide is very brief.

In big industry stability is always challenge, some times internal users report that 3 out of 4 connections are successful and one is never reached to API Gateway, while diagnose report always says system is healthy, restart will make it work again

4/5 they are always on par with requests, some times limitations of API gateway are there to answer by Customer Service

I rate customer service and technical support 8/10.

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

Initial setup was in between straightforward and complex.

We implemented the solution in-house with help from CA.

This is a good tool compared to open source solutions. There still is a lot to be done to improve user experience.

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.

API management, for security.

One of the features that the tool provides is the ability to simply onboard new APIs to an existing security platform. We build all the policies for security upfront, and then we can add those policies pretty simply and straightforwardly to any new API that gets developed in the enterprise. That has been the quickest and easiest thing. 

We're rolling it out across the enterprise as we speak, after that six months or so of heavy usage, and we're finding that the amount of time it takes to secure new APIs has gone down substantially.

The security features are the most important because that's what we're using the application for, specifically.

There is a thick client for configuration that is not as easy to use as you might like. So I would say the design and user experience, from an administrative standpoint, is a little clunky.

There are some really very granular kinds of issues that I've found and they're more related to very specific technical components of the application itself. Aside from these individual complaints that are very bound up with our use cases, I don't have any specific recommendations.

No issues with stability.

In terms of scalability, we haven't encountered any issues. Scalability has been something that we're starting to explore a little bit more now - automated scalability - responding to increases in capacity in the environment. But we haven't had any issues, and I don't necessarily anticipate any issues. CA provides certain containerized versions of their components that are very easy to deploy and scale.

CA has been extremely responsive to any request that we've had for assistance, for support, and for new features. I haven't been able to evaluate the newer version that has recently been released, so we haven't evaluated it yet in terms of feature completeness.

The initial setup was pretty straightforward. They provided us with a container and we got it up and running, and then we just started working on it. You can follow the instructions pretty easily.

We did not have a previous solution, but we did evaluate Mulesoft as an alternative and, possibly, Informatica. We ultimately decided that our relationship with CA, and the type integration with some of the other applications that we had deployed in the enterprise, made the API Gateway a much better option for us.

I would suggest you take a look at all of the components. The API Management Suite that CA offers is broader than simply the API Management Gateway. The Suite has some features, extra components, that really make for a much easier and more accessible way a way of doing API management within the enterprise. There are components like the Mobile API Gateway and Live API Creator. These additional components really expand what the products can do, in a way that makes your value proposition easier to present to the business.

I would say this solution is a solid eight. It does everything that it says that it does. It would get a higher rating if it had a little cleaner interface and was easier to administer, but I think that's a pretty solid rating for a product like this.