Layer7 API Management Reviews

We have more than 50 applications in the backend. We monitor the infrastructure through a database monitoring tool. Our daily tasks involve working on P1 incidents, managing change requests, conducting patching updates, working on P2 tickets, backend server certificate renewals, etc. 

Layer7 API Management should improve the quota policy for the number of API calls. 

I have been working with the solution for six years. 

Layer7 API Management is stable. 

The solution provides good support, but sometimes, time is taken to solve issues. 

Positive

Layer7 API Management is easy to maintain. 

The product is moderately priced. 

We have large enterprise customers for Layer7 API Management, and I rate it a nine out of ten. 

The most valuable features of Layer7 API Management are integration, ease of use, building APIs easily, and portal straightforward.

The overall cost of Layer7 API Management is high, they can improve it by making it less expensive. It is a stable platform, but Layer7 API vision and future are not clear

We have been using and implementing Layer7 API Management for approximately 10 years.

Layer7 API Management is a highly stable solution.

The support from Layer7 API Management could improve. We do not have a strong Latin American support. The support over the last two years has been poor. The vendor of Layer7 API Management, Broadcom, used to have approximately 500 employees here in Latin America but now they only have approximately 20.

You as customer has to find someone with a lot of experience in API Management so the users can take advantage of all the value the solution has.

The price of Layer7 API Management is too high and should be reduced. However, it is a good solution in the market.

I rate Layer7 API Management an eight out of ten.

The most valuable feature is the basic authentication.

Some areas for improvement would be the security the product provides and the response time when a client is making a call with their payload. 

I've been working with this solution for three years.

There are some issues from the front and backend, but none relating to the API portal.

The scalability depends on configuration, but if that is correct, then the scalability is good.

The tech support is fast and responsive.

The deployment was pretty straightforward.

I would rate this solution as nine out of ten.

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.

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 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 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 CA API Management for our brand mobile app and our outbound traffic. Our brand mobile apps are for Olive Garden, Capital Grill and LongHorn Steak House.

We also use API Management to modernize legacy systems via microservices.

We have our internet application, which is connected to PeopleSoft and other tools so we can export through API gateway. So we have a custom mobile app built for our internal application, where people can check their paychecks, benefits, and other perks, such as gift cards.

One of the main things is the call-ahead feature, where people can call ahead of time with our mobile app to reserve a table at these restaurants. We also have private click-to-call links that are very successful.

Pretty much the whole mobile app is going through our Gateway. People can only access the app through a mutual SSL authentication, plus we make sure that we do geo-location. We also have CA Advanced Authentication to help with this. We put these two tools together to make sure that we are not entertaining anybody outside of our countries that we serve. So security-wise, we feel secure using the gateway.

The out-of-the-box security features are useful. 

Right now, you can just right-click and drag and drop the assertions with the rate limit. That, as well as the x-amount surge protection, is built in so we can bring that in.

On the monitoring side, we need a better way to monitor it. CA has not given a clear understanding of what external tools we can use to do this.

We also need a total dashboard functionality to see how many transactions are going through, where the problems are, etc. There's no out-of-the-box monitoring other than the dashboard, which doesn't give you very much.

Their migration policies are also not the best out there. We just do an export and import of it, which is fairly simple, but they could have made it better.

We do promotions and that's the only time you see some crashes. But overall it's pretty stable product and we haven't had issues with it.

Because we have a physical appliance, we have the capacity with us, but scalability is going to be hard. Our next strategy is for us to figure out if we can use virtual gateways instead of an appliance gateway and then scale horizontally.

As for end users, we have a lot of them. About 200,000-300,000 users have downloaded the application and use it externally. As far as maintaining here locally, it's a team of 5 people.

We are growing. I'm the main implementation architect on the support of it. Now, we have a policy development team, an enterprise architecture team and a performance testing team. Each one of them from their team lend out to us whenever we need it.

I would say we're probably 20 to 30 percent of people have been using it within our organization. We still have a lot of room to go. 

Their support is phenomenal. That's one thing that I like about CA is that they're very good at their support.

There's a big dent right now with the merger with Broadcom. So, it's not working out that well lately. I think they need to get that merger completed quickly to get this all figured out.

This is the first one we've picked and then we were pretty happy with it so far.

It is straightforward, but now we're trying to cache some of the responses and there is no real guidance on how this works.

We had CA Services help us during initial setup and that's about it. 

We see clear ROI with this solution.

I think it's competitive. It's not that expensive when you compare CA with the Oracle product. I also haven't seen the latest pricing for the virtual gateways, but what I have seen seems to be reasonably priced.

We were thinking about the Apache system at that time, as well as the Oracle server and architecture.

I used CA in my previous organization so I'm committed to it. To me, it met our requirements at that time, which helped us choose it for this organization.

At that time, Oracle didn't actually have a gateway. Although they have now acquired a gateway, I think CA API Gateway is more mature. It's been there for a long time, even before CA purchased it, so in this space they are the best. We also did the research and looked at resources like the Gartner Report, and CA API Gateway seems to rank top on the list.

I rate CA API Management as an eight out of ten due to the overall stability of the product. So, we had this implemented and running fine unless we had increased traffic. We never went back and tuned it. In that way, I'm pretty happy with that.

It loses the last two points because of the monitoring, as well as the capacity analysis and planning our day-to-day transaction details.