Layer7 API Management Reviews

We primarily use Layer7 API Management to monitor stuff. I'm the one who installs it. They sent me a TAR file, I unloaded it to TAR, brought it up, and made everything work. I gave it the three different network configurations to talk to the three different domains, and then I turn it over to the guys, and they do what they got to do with it.

The best part about it is that it doesn't stop if something is missing during the installation. It looks for it on its own. I don't have to be there to do it physically.

I've been using Layer7 API Management for about three months.

Layer7 API Management appears to be stable. No one has called me to say that it's not working.

Layer7 API Management is a scalable solution.

The initial setup wasn't that hard. You got all the Postgres and all those other little add-ons. It makes sure you've got this installed and that installed. There are prerequisites for what it needs before it gets up and running, but that's a piece of cake.

It all depends on how good your developers are. I know Nutanix and VMware. If you want to do a quick setup with VMware, they have everything preloaded, everything comes in one package, and everything needed for your application to work is already loaded into the bundle.

With SolarWinds, everything is configured for their SolarWinds app, and it's like having a Windows disc with the little features you can add. It's like, if you install the software for Windows or some of these other applications, you can break it down to where you can add in features as needed.

I'd rate it an eight out of 10, no solution is perfect.

We use Layer7 API Management for digital banking: for signing, validation, transactions, etc.

We are a partner, so there are roughly 40 people inside my company working with Layer7.

The mobile access gateway (MAG) is tremendous.

Its ID authentication is a little outdated. I think they should start using face ID.

They need a multifactor authentication solution for the API layer and the other layers, as well. Today, we don't have face recognition for the gateway. We don't have palm recognition either. This would add a needed additional security layer.  

I have been using this solution for roughly two to three years.

This solution is very stable. Once you have the other patches applied it's really stable.

Layer7 API Management is very scalable.

Overall, I would give their technical support a rating of six. It was better before Broadcom acquired it from CA. If they improved their response time, I would give the technical support a higher rating.

The initial setup is very easy.

We have implemented this solution for three banks. One bank took three months and another took six months to fully implement due to an additional security layer.

It really depends on the size of the bank and the number of transactions that you have to validate, the board members, and the customer flows within the bank.

If you wish to implement Layer7 API Management, it is paramount that you understand, first, what you need.

Most of the time, the customer doesn't understand the power of APIs and how they should be managed inside an organization. If your customer doesn't have a plan, it doesn't matter what solution they use — nothing will work.

Overall, on a scale from one to ten, I would give this solution a rating of nine.

We had a test version, which was more of an on-prem version, and we also had some on the Docker for a live API creator. 

We are a security service company, and we provide a lot of solutions in that space. We were just trying to have a frictionless authentication product, so we were working on that. We were looking for a Gateway that can serve in an API, and we've already got an open-source solution.

We loved the portal part the most, which had monetization and showed how people were using the stuff. It is a good product as a whole and has a lot of microservices and granular features.

The delivery is bulky in terms of implementation. Its price could also be better. It is a very good product as compared to CA API, Google API, and WSO2 API, but its price is high.

From the cloud-native perspective, some new features need to be added. It could also be made simpler to implement.

We have been using this solution for four to five years.

Technical support was okay. We were getting good support. We had access to the portal, and the support was good enough.

It was a little complex initially. We struggled a bit initially to understand this solution, but later on, it was okay. I do not exactly remember the issues, but initially, our team was facing a lot of problems in terms of virtualization.

It was very high at that time. We are a Broadcom CA partner, and we got it only for testing purposes. We didn't pay anything for it.

I would recommend this solution to others. This is one of the good solutions for microservices and APIs and for people who need to go the digital way. There are a lot of other solutions that are coming into the market, and the infrastructure landscape is changing.

I would rate Layer7 API Management a six out of ten.

This product is used to expose some internal APIs to help us automate different activities.

It is helpful to have a central API that is hosted and managed.  It reduces costs and customers, suppliers, and vendors receive a uniform interface.

The license model and the cost of licensing can be improved. Especially given that we are in a stable operational mode.

We have been using Layer7 API Management for five or six years, and we have been actively using it this year.

It has been working quite well for a long time.

It's been working for us, from a scalability perspective. It's implemented within a central group, so there are just a couple of roles that run it. The APIs we host are stable.

We are in a stable maintenance mode, so we haven't had to engage customer service/technical support for some time.

We did not use another similar solution prior to this one.

It's a complex product, but I would say that the initial setup is straightforward.

Our in-house team handled the deployment.

We have a handful of IT admins and app admins who specialize in maintaining Layer 7 

It is a pricey product, although priced to the market. 

Overall, this is a good product. It's been stable and working for us, and our main difficultly is people calling out the price point on it.

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'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.

In my company, we use CA API Management for banks in the financial markets. Our primary use case is for the basic protection of the APIs. We also use the authentication feature.

One of the main ways that CA API Management has improved our company is that we do not require a lot of people to work in developing new security code when they are programming for the APIs. They leave all the responsibility to CA API Management. 

In this manner, our developers can focus on just writing the code and on important business.

I work for an information security company. CA API Management is capable of using tokens for authorization to manage access control for the APIs.

One improvement for CA API Management would be better integration with the web access console. Better integration of the web access console would be great.

One specific feature that we need is the ability to authenticate directly to the server with API data. It's not complex nowadays. This is a feature that we need and CA doesn't have it. 

CA API Management can't do the same authentication functionality with the APIs as the other competitive products in the marketplace.

The stability of CA API Management is very good. We have very little problems with the solution. Just once, there were a couple of days that became filled up with logs of reporting information. Overall, CA API Management is certainly stable.

We don't have any problems with scalability. We have only a few customers that have deployed it. We only use it for a total of 4 clients. We don't use it in all of our projects. We work with other technology. 

Our final customer maintains the CA API Management installation and only needs our contractors to make other new improvements.

Technical support is okay. We have opened some cases and all of them were quickly solved.

This was the first tool that we used for API Management.

The initial setup is good. For our requirements, it fits our appliances. 

The initial deployment of the software was two hours, i.e. to have the API data up and running.

We are a reseller company that makes the final setup for our customers. We always do the final installation for our clients.

Our CA API Management license is for five years with no additional cost other than the standard licensing fees.

Nowadays, we are looking at IBM solutions because other customers required it of us.

CA API Management is very helpful. I would rate the product an 8 out of 10. In my opinion, the features are all very good.

Previously, we don't have a security for our web or mobile applications. In a scenario where I have an application that gives APIs to everyone in the world, they can directly access that particular application. However, this allows for different types of attacks on that particular application too. This becomes a problem if a number of users access it, whether they are valid or invalid users, they will see performance issues. If a number of attacks are happening on a particular application, it goes down. So, from a security perspective, CA API Management acts like a reserve proxy.

It makes the end user feel like it is a real system. It does not show the back-end and what the API tool does. CA API management will not let people know that there is an original server running behind the tool. That is the security point of it. 

For use cases, there are databases that some people have to query on. With the help of CA API Management tool, we can give APIs to the end user, and with the help of those APIs, they can access the data instead of the database.

APIs can be developed to provide security. We can show them in one single pane of glass, such as the CA API Management API Developer Portal. It is there that we can provide the monetization for their APIs and what is happening on third-party applications, like Paytm or BookMyShow. 

Customers go to the portal and register there. It is there that they chose their APIs from a list. Based on the registration of the APIs, the customer will be charged.

Our customers will purchase these APIs and give to their application users. The functionality provided by the CA API Management tool is about the work framework, and the API Gateway also provides work functionalities. In the API Gateway, there are features called Solution Kits. These provides work protocol functionalities and the framework. 

In order to develop an API, we'll face so many problems: 

• What method we should use?
• What is the data it should return?
• If I give this API data to the browser, how will it be processed? 

There are so many problems from the perspective of designing an API. However, the CA API Management tool, along with the CA API Gateway, eliminate all our issues.

As an organization grow, you can use CA API Management for authentication purposes through the CA API Gateway. It allows for multiple identity providers with different Active Directories.

It takes an existing service, like JSON or SOAP, and converts it for use on the application (e.g., REST services).

From a security point of view, there are different types of attacks: cross-origin resource sharing, SQL injection, shell scripting, and code injection. These type of attacks can be eliminated with the help of this tool because they are built-in with rules. If I drag and drop one rule called cross-origin resource sharing to the website I want to allow it on, only that website can contact CA API Management regarding this assertion. 

For an OAuth perspective, the application needs to be registered at my API Gateway. Once the application is registered, every time a user requests access to my API Gateway, I have to capture whether it is a valid application or not. Once it is getting validated, only then will it show them the access page for the login page to the application.

Based on the method an API, we need to be able to access that particular API.

They need a workflow for the API Developer Portal, where the process only allows requests to go to the correct person.

The CA Mobile API Gateway (MAG) for mobiles has too much latency.

If an entire cluster fails, we have disaster recovery with this solution. It provides an exact replica.

Because it contains Java, the heap memory needs to be cleaned constantly or problems will occur.

For day-to-day maintenance, two people are enough staff, e.g., checking the logs.

CA API Management is okay when it comes to supporting a large number of APIs or large number of transactions. It has high availability. With the help of a load balancer, we distribute the load among all the API Gateways. In this way, we provide high-availability for all the API Gateways.

We have scaled the product out to different countries, like China and Australia.

Previously, there was only SOAP services. When you are making an API call with SOAP services, It has a lot of impact on the application by taking too much of the bandwidth. 

Now, all the users are filling our their forms in the back-end with form data into JSON, and sending the information to the REST services.

People want the REST services. There are already existing applications which are running on the SOAP services. Rather than losing their businesses, with the help of CA API management,  they can have both their REST and SOAP services in the back-end.

The initial setup is straightforward, like creating and deploying an API. Everything happens in one single loop.

If you install the CA API gateway, it takes about 15 minutes, as it is available in OVA format. If you go with the OVA format, you don't need to do much configuration. Then, it comes up in an internal MySQL database.

The API Developer Portal takes easily an hour to set up.

When we introduce the solution to a new organization, it's not a complicated process. If we describe to them how an API can reduce work in their regular life, then they can easily understand that. When we give this to the customers, they become happy.

We use two people for deployments.

CA API Management has a licensing path. If you want more features, it requires more licenses and more installation time.

Compared to other tools, like Apigee, this is the best tool that I have used.

This product is available on-premise, in the cloud, and Docker.