Layer7 API Management Reviews

It serves our development purposes, enabling the connection of both external and internal clients, for example.

It's a comprehensive tool that allows us to perform all the necessary tasks in one place. With other middleware API management tools, we might need multiple tools and layers to achieve the same results. This tool provides a single platform for managing security, real transformation, connectivity, and development, eliminating the need for additional add-ons.

It's quite satisfactory. However, I don't focus much on the cost perspective, but I understand that clients are often concerned about costs. They might be exploring other options due to the high cost associated with our current package.

Currently, we don't have any major issues, and any past issues we encountered were promptly resolved. Perhaps in terms of improvement, we could explore more robust connectivity options, but for our current needs, it's been solid. As for my company, we might consider migration, and there are tools like GMU migration, provided by the same vendor, which could potentially help us in that regard.

I have been using Layer7 API Management for the past eight years.

It is stable, as per our observations.

I've been primarily utilizing the on-premises version, and it has proven to be scalable as we've added more clients. However, I haven't yet ventured into the cloud aspect, so there's potential for further exploration in that regard.

It's not overly challenging. The documentation is quite comprehensive, and the support from the dot command is also reliable. Overall, it's a comfortable experience, and I haven't encountered any significant issues or concerns.

I would rate it an eight out of ten.

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. 

On-premises

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.

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.

Three to five years.

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.

I work for a major healthcare company, it's amongst the top ten Fortune 500 companies and we've been leveraging CA API Management to make our healthcare business services available on the Cloud. To make them available on the Cloud and to enable our healthcare capabilities to be consumed by different consumers in real time across a plethora of channels.

We are leveraging CA API Management - we chose it by doing a huge comparison across different competitors. CA API Management helps us to securely consume various services and also the biggest thing has been to do monetization of services. We have certain rules that have been defined where you basically say that this specific healthcare capability is of greater value and we put a dollar amount to it as to which consumers can consume how much and based on its usage and all that.

CA API Management has been the driver for our digital transformation. It's interesting these days, the entire business is heading towards a completely distributed platform where the consumers are everywhere. You have business to business consumers, you have API management consumers and you have mobile consumers. At the same time, you have data providers that are growing heavily. You have data analytics placed platforms and then companies are heading towards providing helping consumers to make analytics-driven decision. Let the data drive the decision so now you're the middleware industry around microservices is facing its own challenge on how to meet the scores upstream and downstream from these back-end services. That's where the microservices platform, CA API Management heavily helps to make sure that you provide your services on the part.

With scalability, it comes to resiliency. If you cannot scale you're not resilient. If you're not resilient your performance is worse. If your performance is worse your API and services are not available.

Fine lines of availability is one of the key criteria's in the industry - 99.99% availability. That means 6 hours downtime in a year, so can you really ensure that everything is interlinked. If we talk about software architecture, quality attributes from these are all interlinked. I would say that eventually, it comes down to your customer satisfaction from there on. So that's our number one goal.

Right now, scalability is our main goal. Maybe they're not the problems but from the standpoint of onboarding a new API on Layer 7, that's fairly simple. I see that it's an extremely user intuitive and user-friendly software. Our operational personnel who have barely have any experience could get on with it and help the enterprise register as many API's as possible from the get-go.

We've been using it for the past 2.5 to 3 years. However, now we have come to a point where our scale is growing and organization is unable to keep up with the needs of the consumer so we are constantly working with CA API Management's operational personnel. They are helping us out but these are our challenges to be very honest.

It is very good software from the standpoint of making an API commercializable and making an API accessible. The security industry is extremely complex, to provide various security capabilities to an API that's fairly simpler. However, we are facing challenges in scaling the CA API Management software so we have seriously faced certain challenges when if your API usage goes beyond a certain limit, say 100,000 transactions per minute, I'm just throwing out a number, I can't provide you the real number but we are facing seriously challenges in scaling, in clustering the CA API Management software and then making sure that we can reliably meet our transactions as your usage grows on the Cloud.

It's challenging at this point because the healthcare API marketplace is growing.

CA API Management has been chosen as the platform for the entire firm so now as the APIs are growing the API management product capability also has to grow. Some of the challenges we are facing is sometimes you have mainframe systems and these mainframe systems are incredibly slow to respond. Now your product has to be capable of keeping your response times open for that duration, so that's one challenge. The ability to scale up, we face that beyond 90,000 or 100,000 transactions, the product has this limitation and it cannot scale. We are seriously facing challenges around response time per transaction and our business demands .1 milliseconds of response time. However, we are seriously reaching up to 3 seconds for some of it. I think internally we have to make this serious call around leveraging CA API Management for certain kind of transactions. Maybe segregate the platform so there are different architecture strategies for it, different approaches for it and we can really achieve it but we need to tune it a lot better.

Technical support are definitely extremely knowledgeable. However, we have faced some challenges where in our initial discussion we don't get a level 1 support. You want the guy with the most knowledge to be there right up front so it gradually takes 3 or 4 levels but the good things is our internal staff is coming up to speed on this but otherwise CA API Management have great knowledge, they built the product so they are very helpful.

If I'm looking for an API management vendor then I would look at the API management vendor's capability, their products capability to make their services available on the Cloud, monetization, security, availability, performance, resiliency, being flexible enough to provide different security integration mechanisms to different APIs, how flexible that software is and user intuitiveness.

My operational personnel should be able to be running from the get-go. I think these are some of the key attributes that we really look at. We did a comprehensive analysis on CA API Management followed by Apigee, followed by SOA software. We did a comprehensive analysis of balance score card by comparing the capabilities and the attributes across all these softwares on a scale of 1 to 10 and then the scorecard came in such a way that CA API Management stood out on every scale for us.

I think cost was also one of the key factors. We figure that Apigee and other software were on a higher scale from the cost standpoint, so I think that played a major role.

The product overall on a scale of 1 to 10 - from a scalability standpoint I would give it an 8. I would certainly give 8, because although I would have loved to go 9 or 10, no product in this world can scale any needs from the get-go but the customer service and the technical support has been outstanding. They have been very helpful so at least they are helping us out. Considering CA from an holistic perspective, not just the product, their ability to meet our needs, their ability to support us, their ability to answer our calls, and answer our specific technical questions, I think I would rate them an 8.

People tend to support what they have done in the past. It's always the case. If you ask a mainframe programmer he would say mainframe is the most rock solid stable platform in this world. I would say because we have lived in CA API Management I would say absolutely you have to use CA API Management.

Jokes apart, the customer has to know the capability of API management software. I see a lot of people asking me if I decoupled services in API management. API Management software's purpose is not to do decoupled services. It's to make your services available on the Cloud. It acts as a security gateway so that your consumers can access your services. One needs to know what he's looking for. These are the fundamental characteristics of an API management software. If you compare those characteristics CA API Management leads the industry.

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.

On-premises

We use the product for HTTP traffic. It supports DNS and FDP protocols. 

The product supports more than just HTTP protocols; it also caters to JMS and FTP protocols.

The solution should prioritize ease of use and align with the growing trend of cloud-native environments. Customers are increasingly leaning towards cloud-native solutions, and while you can configure your topology in the cloud as a private solution, having a more inherently cloud-native approach is crucial.

Layer7 API Management also should feature built-in policies to minimize the need for extensive code writing. It needs to include more plug-ins. 

I have been using the product since 2018. 

I haven't seen many issues with the product's stability. 

I rate the product's scalability a seven out of ten. 

Layer7 API Management's deployment was straightforward. 

Layer7 API Management is cheaper than Apigee. 

I would choose Layer7 API Management's alternatives since it is not current. I rate it a five out of ten. 

On-premises

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.

On-premises