Layer7 API Management Reviews

We had all those three layers from API: the gateway, mediation, and monitoring. We had implemented that on CentOS operating system. 

After that, we deployed some test APIs for patient-related activities in healthcare. We were querying the patient appointments from the patient database and then passing it on to a mobile app. That was the small experience I had. 

We had this API M dashboard on which and the APM gateway server on which we deployed all these APIs, a couple of APIs only, not much. I just initiated that project, implemented them, the UAT, and the protection domain, and then deployed a couple of sample APIs. After that, I left the role. I don't have any detailed experience, because we were not able to implement many APIs because the site was just starting up.

This product improved our time to market. Because we are a government healthcare organization, we are supposed to expose our patient data to the national command center and other mobile apps. We were able to expose our data securely. That was an advantage of Layer7 API.

The most valuable feature was the gateway because it has a good dashboard which shows all the hits, misses, and issues, how often you are viewing, what was the response time, etc. The gateway was very easy to deploy.

The dashboard was pretty simple. It had all the features, but the usage load was less initially. Now, the use cases slowly increase. 

Layer7 API Management should have more stability towards the operating system. I think we were planning to go to version 11, and then Layer7 API Management said you need to move from CentOS to some other operating system. This sort of stability needs to be there. They can't keep forcing the customer to completely change the OS. They should have some stability on the platform in terms of the roadmap. Layer7 API Management should give a clear roadmap of the product and where it is going, and they should not change the underlying layers.

Layer7 API Management should also have an online, direct support mechanism wherein we can directly raise a ticket in the global center, and then somebody should come online to provide support if necessary.

I used it for three years. I used version 10.x. 

The product was stable overall. 

It was scalable because we had a clustered server on a free load balancer. Whenever there was a load, we could add one more node horizontally and put it under the load balancer. So the load will get distributed.

It was scalable for our use case. It supported us very well. It was for patient appointments, and it really helped.

There were around six end users. Two of them were administrators, two were developers, and two were integration engineers.

The customer service and support were good but not excellent. They have some issues in terms of manpower, and they have support from Dubai. They do multiple projects, and that's why sometimes it's a bit difficult, but it's fine.

Neutral

We didn't work on anything instead of Layer7.

It was pretty easy because we were supported by Layer7 team, and we were able to deploy it very easily.

Deployment time: One week for UAT and another week for the production.

We already have a middleware known as Rhapsody. We were able to easily integrate Layer7 with Rhapsody. 

I would definitely recommend it. Overall, I would rate the solution an eight out of ten. It was good for the healthcare industry. 

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.

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.

We have one Global customer using Layer7 API Management for their entire API management. They have exposed APIs to their external partners and vendors through a marketplace. However, Layer7 API Management is primarily used as a gateway solution, and its management capabilities are not as strong as those of other solutions available. As a result, the customer also uses Apigee for API management tasks. Apigee has been used throughout the customer's API program, including building the marketplace, monetizing APIs, and developing a developer portal.

In 2017, when we started working on Layer7, Apigee was the only competitor, which is still emerging as one of the great solutions for repair management. Layer7 was working out well for our needs. You can do many transformations. There's a lot of scripting admin layer gateway layer. It needs to be treated more as an anti-pattern because you don't do much scripting as the gateway layer. We use Layer7 extensively because of old legacy services and to recreate new modern services. Our customers are moving away from Layer7 because its management piece is not great. The monitoring and monetization parts are not coming out sooner. Other players like Mule or Apigee are coming up.

Building the marketplace on layer7 is not so easy. It's not so easy to do some onboarding workflows.

I have been using Layer7 since 2017.

The solution is very stable.

Since the tool is on-premise, it was not scalable.

I have used Mule and Apigee before.

The initial setup is easy compared to Apigee.

We have about 30-40 engineers to deploy the solution.

The product has a yearly license, which is not so pricey.

The solution is difficult to maintain because we have to do many scripting in layer7. A lot of Java code was written, and transformations were done.

When selecting an API management solution, we carefully consider various parameters, including the specific needs of our customers. For instance, if a customer requires a comprehensive API management solution with advanced features, Layer7 API Management is an excellent choice. However, if a customer needs a basic gateway solution with limited reporting capabilities, we can accommodate their needs on their preferred cloud platform, AWS. Moreover, we have extensive experience implementing enterprise solutions with the necessary investment capacity and specific requirements. Additionally, we prioritize solutions that enable seamless integration within hybrid architectures. To ensure we make informed recommendations, we conduct thorough comparisons based on over 45 parameters, drawing insights from our current implementations and customer feedback. Our approach is adaptable and may evolve based on evolving requirements.

Overall, I rate the solution a seven out of ten.

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 this solution for security as well as for monetization. I'm a certified CA API management professional and a user of this solution. We are vendors of Layer7.

I like the simplicity of developing APIs.

The development portal could be improved. Following Layer7's acquisition of Broadcom, the technical support and sales teams have not been good and both those areas need to be improved. I'd also like to see the latest code support with open API specs and JavaScript which is lacking. 

I've been using this solution for six years. 

This is definitely a stable solution. 

The product is scalable, up or down, according to your needs and there are no issues. We receive somewhere between 30,000-60,000 hits per day. 

Technical support is responsive, but since the merge with Broadcom the support has not been as good. They're not interested in getting on a call to quickly try to resolve an issue.

Neutral

We also use API Apigee which is more complex. You have to know XML coding and tags, for example. With Layer7 you drag and drop assertions and name them. With Apigee, after selecting the policies, you need to write some logic into it.

The initial setup is very simple. It's straightforward and you can just go through the mock ups step by step and implement. I do the deployment myself, it's very simple. 

The cost depends on how many licenses you are trying to acquire. There is 
a perpetual licensing fee, and then you pay annually for support and maintenance. The price is competitive with other solutions. 

We use a combination of Denodo and Layer7 API Management. The APIs are developed on Layer7 and then exported through Denodo. Layer7 provides the security layer, while Denodo facilitates data on demand. That combination is handy, and most organizations have a similar setup. That data is exported to API. The data modeling is done on Denodo and exposed through policies developed on Layer7 API Management.

It's good to have a tool for integrating data between organizations and applications. The combination of Denodo and Layer7 is beneficial. I feel like Layer7 would not be sufficient because most APIs need data on demand. We need to provide data on demand on top of some layers without going back into the native data systems. 

That will help developers not tax something on the line. We just develop on top of those databases or data layers. You prepare a logical data layer to provide an API exposed through Layer7. Using Layer7 and Teams or different applications can consume those data easily. 

API Management makes dealing with APIs easier. It'll help you to move ahead on your API application journey. The solution allows developers to create more advanced security policies

I feel like Apigee's API product is more interactive. You can drag and drop with those, but it's a little more difficult in Layer7. It's less user-friendly compared to that Apigee product. However, the overall user experience is okay. 

We have been using API Management for three years. 

Our deployment is stable. The company was using API Management before I joined. It's pretty stable and people are developing their APIs on it. The integration Layer7 provides works well in our environment.

API Management is scalable. We did some horizontal scaling and adopted a clustered approach, with two or three nodes behind that. We have that kind of scalability in our environment, and we have a hard drive. We're processing millions of jobs a day that are handled well with the cluster setup we have in place.

Solutions technical support actually falls. I mean, in our area, we have to get a team around it, so that some of the APIs won't get fail and the possibilities of capturing the records. Second thing is to deliver the migration of the APIs to higher environment. So this falls API, I mean, under support task and that too includes performing lifecycle management, upgrading the API versions. So last year we did from nine to ten. So this changes are there in the bucket of support and we do handle around that part of task.

I rate Layer7 API Management eight out of 10. There's a steep learning curve, and I have spent two or three years looking at the documentation that comes with it. It's a bit difficult compared to some other products like Apigee.

Layer7 API Management can be deployed on the cloud and on-premise.

We are using Layer7 API Management to expose APIs and to do security checks, which is similar to a reverse proxy.

The most important features of Layer7 API Management are the basic security functionality and validation checks. Additionally, it integrates well.

Layer7 API Management could improve by assing more portal-based capabilities.

I have been using Layer7 API Management for approximately two years.

Layer7 API Management is stable.

We have four people using this solution in my company.

The solution is scalable.

The support from Layer7 API Management is proactive.

I prefer Layer7 API Management over Apigee. Apigee has a portal-based capability which is better than Layer7 API Management.

The initial setup of Layer7 API Management is not complex. The process took approximately 10 to 15 minutes.

The price of Layer7 API Management is reasonable compared to Apigee.

This is a good solution. However, it would be ideal if they had a technical team because there is a need for some basic coding knowledge. It requires comprehensive Java knowledge.

I rate Layer7 API Management an eight out of ten.