Layer7 API Management Reviews

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

I sell this solution to a variety of clients in digital banking, insurance, and health care.

There are many security policies within this solution that help to prevent attacks. We are also able to implement MTLS to allow us to lock a channel from the application from the backend. There are authentication flows inside of the gateway that help us a lot to implement customers improved user experience. 

I would also like the next release to support FAPI-CIBA because there are laws in Brazil that require companies that operate in a digital manner to support CIBA and FAPI. This is more for authentication flows.

I have been a partner with Layer7 since CA Acquisition 

I have never had any concerns in regards to the scalability of the solution as it is able to handle more than 25,000 transactions per gate. We currently have seventy people working with the solution but for one simple gate implementation, only one engineer/technician is required.

The support that is available is only for technical issues, they are not able to help you with your use case.

The initial setup is a piece of cake.

Most of my customers have been able to see an ROI.

Be sure to research this product and its functionalities well prior to moving forward with the solution. Many of my clients will have issues with the solution in regards to their use cases.

This solution is easy to deploy and view data in API but you must have a solid plan to manage the environment.

I would rate it a ten out of ten. 

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.

We use it for public API security.

The governance of the new business models generated by the APIs has been simplified and is improving the daily control over them.

• Current security models which are the focus of the industry. 
• The product documentation helps the client and/or user to evolve quickly while using the tool.
• Support has efficiently combined with the forum.

The portal is an important point in the lifecycle of the APIs. Right now, the portal lacks many features. We hope that the new version will have them and that there will be a quality jump, which is needed.

None.

There is no real problem. However, as the number of instances increases, its complexity of installation increases if you do not use the OVA.

Support through the forum is very good and efficient for partners.

I work in a consultancy, so we do projects with other products. However, our partner product is with CA Technologies.

They have different installation models. Therefore, there are always small drawbacks. Fortunately, if you use the OVA, your installation is direct.

We are a partner with our own prices.

We evaluated the following solutions: IBM, WSO2, and Oracle.

Begin by using the installation offered on an OVA, then in production environments make use of your own installation, e.g., in CentOS.

We use this as a Cyber security appliance and also as a centralised API management platform for partners.

We've got all sorts of threat protection in the API Gateway, from DDoS through to SQL injection and things like that. These are standard features that we use within policies that we drive out the Gateway.

We've got a security policy fragment that we know is consistent across all the APIs we expose via the gateway. Also, as it's a fragment, we can add to it at any point, as new vulnerabilities are discovered, which will then secure all the services/apis that use it. This gives us greater agility and confidence that our APIs are secure.

Security is the fundamental use of the gateway so the security assertions are heavily used and are consistent. We also use it to broker asynchronous messaging across DCs transforming between messaging technologies to provide real time updates for customers in a really secure way.

Also, the actual management of APIs is fundamental to us, as we're a heavy API user/provider. So, obviously, a centralised management platform is important.

We have cases open around the SQL injection capabilities that need improvement. Cross-origin resource sharing policies need to be made a common assertion in the Gateway, that's not there at the moment out of the box (although it is available as a policy fragment). 

The developer portal needs to fully supported SOAP services (including WSDL publication with security), it would certainly push adoption for us.

Verbose logging in production has caused us a couple of issues, never enable this in production! In addition pay attention to name servers for DNS.

Scalabillity, like most things, is in the hands of your own business to implement. The gateway is flexible and can be scaled to the level you see fit. Be aware though, verbos logging will bring your platform down in seconds, so only use in non-production environments.

We have a few cases open. I'd say I'd give an average rating of around 7/10 for technical support. Some people have been very helpful and others not quite so.

We use Microsoft IIS in other areas to expose services against a load-balanced cluster. So we have these bulk security components within it. They've never been compromised but we thought we'd would add an off-the-shelf security appliance to add an additional layer that also comes with API management capabilities.

The setup was complex, definitely complex. As above, don't underestimate the effort required to build a HA/FT instance of this for both the Gateway and the Developer Portal. Be aware of additional licenses for your warm standby. Ensure you get plenty of non-production licenses.

Both. The vendor team seemed technical enough. Note: Ensure that your in-house teams and the vendor supplied staff are fully aligned to make deployment efficient. Deploying the gateway platform is a full project and would need managing as such.

There has a been a lot of confusion with pricing and licenses, especially around the number of cores. In addition, don't underestimate the effort required to build a HA/FT/DR instance of this for both the Gateway and the Developer Portal. Be aware of additional licenses for your warm standby. Ensure you get plenty of non-production licenses.

I don't remember all the evaluated options. We reviewed, it must have been six or seven, maybe more, API management vendors.

I would say that, although the Gateway is geared up for managing SOAP services, the developer portal isn't. It's a gap for us, which means the developer portal isn't quite as good as we thought it was going to be for managing SOAP services ( which we have quite a lot of). They're not discoverable in the portal, as are RESTful services.

From our perspective, the most important aspect is the ability to scale without compromising performance as well as security. That’s the most important aspect, and that’s one of the reasons why we chose the CA product, because it does scale for our needs to grow without compromising performance.

Also, security is very key. We are in a marketplace that companies are being hacked, so we didn’t really want to compromise in any of the security aspects of it.

Good performance and ability to scale not only for now but also in the near future as we organically grow the company.

When we thought about the API platform as a whole, our intention was to provide the solution both for our internal customer as well as for our external customers. What we mean by that is we are a very geo-spread company and there are internal folks who also leverage the same services which are currently consumed by our external customers. So the intention when we thought about this whole solution and the future perspective was to have a single platform that caters the niche for both, without trying to deploy them in a very indifferent way. We have seen in other places and even in the past that you have a solution and deployment that provision for internal users and separately for external users. That was too much cost: maintenance and redundancy. We wanted to bring them together as a whole and that’s the aspect which we like the most using the proxy aspects of it and the ability to configure the different end-points. We point out based on the user base which end-point we hit on without a compromise in any of the scalability, performance and security aspects but at the same time using a single platform per se.

The additional features are to keep up with the security aspects. That’s one aspect, the market is changing. As we started several years back and where we are today, the technology and the security aspects have pretty much changed starting in the good old days with the PKI, SSL, now with the OR, etc.

One thing that I would really look up to is keeping up with all of the evolution and security aspects of it as new features that can be added. The second one is provisioning the users. Right now we do not have a user friendly provisioning utility per se, so we have to do it behind the scenes. Having such a feature would certainly help in the long run, because it could do a lot of internal effort that we have to do in terms of development and maintenance aspects of it if we were using something out of the box.

We are pretty happy with the stability. We had our challenges from the beginning, that’s part of the learning curve that we go through no matter what product we choose. But as we learned a little bit more about the product, and as we started leveraging the key features and the functionality of what it can bring to the table, I think we are pretty happy.

We are able to scale both horizontal and vertically, so we have an internal user base as well as external user base and we are able to provision both for those user needs. We are able to even segment it. One of the features that we like the most is the ability to have a form of servers which provide that scalability and un-scalability at the same time we being able to curve out a part of it exclusively for internal users as well as for external users, but if time demands we can bring that together to scale it. That’s the part which really added a lot more value to the business.

They’re pretty handy and they’re very knowledgeable folks from our experience perspective. In the initial days when we ventured into this product, they said we were in the learning aspects of it so we didn’t know all aspects of every feature and functionality. We did follow up many times. They were patient, they were trying to provide reasonable answers and guide us to the right path and where we could go to look for more information, so it was very helpful.

We were using an in-house built solution which used Tomcat servers and were quite complex. We wanted speed which is the key for success in the current marketplace, so CA did deliver that. We wanted that speed. We were able to really get up and running fairly quickly because it is mostly configuration driven as opposed to doing things from scratch.

Every project starts with something small but in our case we also started small, but eventually it grown into a big elephant in the room, so that’s how we got into. Right now we realize we can be small at the same time as we can be a big elephant in the room. We try to find that medium aspects of it where rubber meets the road and what we really need. It’s not too complex at this point of time. We are scaled down to accommodate what we want to begin with.

The stability of the company and the customer base are the two most important aspect because we want to make sure the company is going to be around for years to come.

Also, who is there customer base at the moment. We want to make sure and learn from their experiences. We don’t want to be a guinea pig to begin with.

Rating: I would say CA is around a nine plus. I would strongly recommend them. The first think I’ll tell anyone is to do your homework because wherever you venture into a new product, there are lots of unknowns and those unknowns are what makes people feel, “Well, this is humongous. It’s too complex.” I would say to first learn the product and what the product has to offer and see how does that benefit your business needs. Then go for it, but with the product suite that we are current using, I would strongly recommend them because it did deliver what we want and we are very happy with it.

It has built-in identity management so that when someone logs into the UI, it can confirm their identity and give them access to what they need to see.

Overall, it's a great tool and they keep building in more and more capabilities.

It provides us a needed level of security in restricting access for the user. It’s able to make multiple API calls while looking like it’s just making one.

I was hoping that there would be some deeper dive Gateway training than their two day workshop and the self-paced study provided. The only course that focused on the Gateway was a Sales Certification course, for which I never did get my certificate, and it was only a short intro to the Gateway and the Portal. There was nothing that I could find that was more in depth than that.

Some of the speakers at CA World spoke about how they used the Gateway, but mostly it was mentioned that partners were using it. So it would be good if there could be more deeper dive Gateway training during the Pre-Conference training sessions.

We've had no issues with deployment.

We've had no issues with stability.

We' have no issues with scalability.

They are great, very helpful, and they make sure that you know that they are there to support you. They're responses and have always provided us with solutions.

The initial setup was very straightforward.

I believe that they evaluated several different products and this was the best to fit our needs.

Definitely do your research and, if possible, take the two day workshop to show you how to use the tool.

Also, get recommendations from people and get their feedback.