Layer7 API Management Reviews

We have the API Gateway deployed in production. The primary use case is for the API Gateway to provide API access, and authentication, and authorization for the APIs we expose through our product. 

I am also looking forward to having the API developer portal deploy as well so we get a bit more insights into the analytics part, and also some of the API lifecycle management associated with it.

I love the API Gateway, especially the architecture, in terms of the composability of the policies. We approach it from a very software-engineering approach.We build on the policies, like legal blocks, and we deploy them throughout different environments. It's been working out great for us.

It definitely helps a lot with the DevOps and the support. Reliability is one thing, and having visibility into who is using which APIs. 

Some of the performance matrix that API Gateway gives off - we monitor them via SNMP traps - and then we tie them into our monitoring system. You can actually monitor some of the latencies and some of the performance aspects of both API Gateways, as well back end services. So having that line of sight surely helps in terms DevOps.

The most valuable feature, as I mentioned, is the composability, because we use a lot of functionalities. 

Also, right now we're looking into the Dockerized version of API Gateway because that would allow us to flow nicely into our Microservice Architecture.

The more automation the better. I think CA is stepping in the right direction. I went through the micro API Gateway presentations here at the CA World conference, on how you can automate more of the policy deployment via the JSON format, so you don't even having to touch the Policy Manager. Because every time you touch something in the Policy Manager you think, "Well, that's a GUI, humans need to go in and do something with it." So if we can automate everything with the APIs, that helps a lot in the DevOps lifecycle, where we want to automate everything.

I've always been a fan of API Gateway. In the past we've used various API Gateways, some of them are open source. It's definitely very reliable and robust. The three years that we have them in production, not a single instance of downtime due to the API Gateway. We have issues, but it's mostly because of API backend issues or low balance issues and such, but API Gateway has been pretty reliable for us.

The scalability has been good. Now we have exposed the APIs, we have a four-node cluster of API Gateways in production. It's been scaling out well for us. I haven't had any issue yet.

I have ended up using technical support several times. I think it's fantastic. I've been working with a particular technical person in CA and he's been really, really helpful. He's been very busy, but the support that he gives me is above and beyond the call of duty.

Even going through the 24/7 support I usually get the answer back within 24 hours.

It was three years back, and at that time there wasn't a lot of automation going on with the API Gateway. It was a lot manuals, so we're using the OVA version of the API Gateway. As time went on, with the API Gateway you can pretty much auto-provision things. But two years back at least, I wasn't aware of that, so there was some manual steps. But even manual it was still quite painless to get it done.

We did do some evaluations against other products. Just to name a few, we looked at Mulesoft, WS02. We went with CA because the solution is simple to implement, it fits our use case well, and in terms of price point it also chimes well with our VPs.

I like that CA is continuing to improve the product, looking for new solutions using the API Gateway. That's something that we're familiar with. And that they're trying to make it work for different types of architectures. As I mentioned, we are moving toward Microservice Architecture and having the Docker form and the micro API Gateway to help with those kind of architectures is really helpful.

I'm an engineer, so from my perspective things have to be simple. If things get way too complicated then maybe you don't have the right solution, or you're not using the right solution to solve the right problem. In that case you may want to look for a different solution.

When selecting a vendor, as an engineer the solution that's offered by the vendor needs to be simple enough to solve my problem in an efficient way. Of course, I don't worry too much about cost because I'm not paying for it, but certainly cost does play a part in terms of licensing scheme.

The solution you choose depends a lot on the use case, so without really understanding a colleague's use case it would be hard for me to recommend anything at all. Definitely, if they want functionality like API management, I would recommend looking at CA to see it fits their use case or not.

The Gateway is most important because it is our strategic front door into the company for all APIs.

The API Gateway for us is now, or is about to be, our central one way in. We have many, many partners who resell our communications services. They provision those services through our systems.

Previously, we would just host it on a number of different application servers, uncontrolled if you like, not as secure as they should have been.

You probably don't know, 18 months ago we had a large security breach, which turned into a large issue with the national press. We now use the Gateway for that single point of entry for all of our API traffic.

As well as the SOA Gateway - that is, the API Gateway; we call it the SOA Gateway - we also are now deploying the developer portal component of the SOA Gateway. That has limitations.

There are two main ways to offer web services to the outside world at the moment. One is RESTful services and one is SOAP-based services. We are predominantly a SOAP service company and the support for SOAP-based services are very limited, almost poor, in the developer portal. All CA's investment is around RESTful services, which is a problem for us.

I would also simplify threat protection, I would improve SOAP support, and I would reduce Professional Services rates. Apart from that, everything's pretty good.

We've been using the solution for two and a half years.

It is very good in terms of stability and functionality, it just lacks a little bit in terms of SOAP services.

We're only receiving 200,000 calls a day at the moment, and we're increasing that to about 1,000,000 calls a day, which is a lot of traffic compared to some customers but I'm sure it's not much compared to others. The performance is fine.

We raised a couple of tickets which just went through the standard process and we got a really poor response. But then I contacted the account manager and we got an excellent response and service.

In terms of the ultimate outcome and the service we receive now, I'd rate it really high, you know, 8 or 9 out of 10. But there's been one incident in particular which I would rate down at 2 or 3 out of 10. The way I feel now, I would rate it at an eight or a nine, mostly a nine. There was one incident which did not go through the account management team, which was not optimal.

The one incident which I would rate very low was just a really unprofessional, incorrect response. As soon as the account manager saw it, he was very apologetic. He got it all sorted out, no problem. They know about it and our account guys know about it. I think the support team know about it. I don't really think it's worth bringing it up again.

We introduced the API Gateway. I wasn't here at the time, by the way, but we didn't use anything in terms of that. We bought it really for our protection and security capabilities. So the main thing is the API, the whole API management piece. We did go out to tender; we invited about six, or evaluated about six, different solutions and selected CA.

I wasn't here for the setup.

I would say CA are a good company to work for. I would say that the Professional Services people are fairly expensive but pretty good. I would say that the Gateway is a good tool but you need to be careful of the limitations for SOAP services. Also try and get over to CA World because that's good fun.

The product has a user-friendly interface. There are customization options, unlike the previous version, where we had to do manual coding. We use the configuration wizard to set it up. It saves us a lot of time.

There could be more integration options included in the product. It needs active connections added in the present version.

We have been using Layer7 API Management for three months. At present, we are using the latest version.

It is a stable product.

We have 12 Layer7 API Management users in our organization.

The initial setup process is easy. The deployment time depends on the custom applications. It takes time to integrate configuration to explain the process to small business vendors.

There are various licensing models for Layer7 API Management. We have to buy additional licenses to get new versions.

I rate Layer7 API Management an eight out of ten. It takes time to learn and understand the product.

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.

CA has incredible reach in the market across industries. To have the opportunity to partner with CA has been great for us, a great exposure. They have got a very compelling platform that enables organizations to easily develop and roll out mobile applications. 

A lot of their customers have come and said, "We'd like to be able to enable these mobile applications with biometric authentication capabilities." It is really a nice blend. We are able to provide that capability to enable that platform to deliver that to their client base.

Our solution has been around for several years now. It is FIDO certified. It has got compliance certification from the government, so it is very stable. The underpinnings of Samsung Pay deployed in South Korea. There are five and a half million consumers using that platform. That is one of the largest biometric deployments probably out there today. Then, we are a global organization, so we have deployments throughout the world and across different industries. 

The solution is already supporting about five and a half million consumers in South Korea, so it is scalable. Today, there is a server element to that solution. From the client's side, it is SDK-based, but there is a server element. We can support about two million users on each server, then you can nest servers together. 

We have no concerns about scalability at this point.

We have not gone into production yet. We have not had direct experience with CA's tech support. I can tell you that our development and our technical folks have been working very closely with their development teams. They have teams in India that we work with and teams in Vancouver that we work with. It has been a really good experience for us. Because it is global, you have got to be around the clock to some degree. So far, there have not been any issues. We have a US-based tech support team that as this thing goes into production with clients, we will be leveraging that team as well as the CA team.

There is a server element and a client-side element. The server side installation is fairly straightforward. We don't provide hardware for the server installation, but we provide specifications, then we will help an organization work through it. In pretty much a day or two, you can get a server stood up and working. 

On the client side, it is integrating. You're taking this SDK, and you're integrating into native mobile apps. The complexity of that depends upon what you are trying to accomplish. Certainly, with simple use cases, we have had people spin this up in days. As you get more complex in the use cases, you might be looking at weeks. However, this is not a three to six month type of implementation timeframe. It is more of a three to six-week type of implementation timeframe.

I do not have a lot of competitive information on other mobile access or mobile API gateways. So, it is hard for me to say how it ranks against other competitors. I will say that it seems like it is deployed in dozens, if not, over a hundred different companies. That says for itself that it is a very strong product. 

I would put it up in the eight to nine category out of a 10, if I had pinpoint a number.

Most important criteria when selecting a vendor: CA is extremely appealing because of the reach that they have across industries, and they are pretty deep in many industries. They bring some brand recognition to the table, and obviously Samsung has a very strong brand as well. You combine those two brands, and that just creates a compelling offering which will get the attention of companies out there. 

Obviously, the support piece is important, the product stability, and how robust that product are very important to us. We look at that on a number of different dimensions.

The primary use case would be services for APIs that we are going to expose either internally, within the enterprise, or at the outside edge of the enterprise.

Most valuable might be the security assertions, the policy assertions that are able to be bound somehow to the APIs.

We are a company with a rather complex process when it comes to integration of applications. Our expectation - we are only about to get this product into  a productive state so we are not using it productively at the moment - so the expectation is that it will simplify the on-boarding of either internal or external developers when they are using our APIs.

The solution is divided into their Gateway and to their Developer Portal components. For the Gateway component, our expectation was that it is provided as a Docker image, but it turned out that it was not supported in production up to the version that we are currently using. But the next version is obviously provided as a complete containerized version for production, which is quite good.

On the other hand, the Portal provides some questions so to speak, at the moment, because as we decided on the product last year, at the end of 2016, and it turned out that CA completely rewrote the Portal solution and the current version of it is not at the level of the functionality of the previous 3.5 version. That's quite a problem for us because we expected some functions in the Portal which are currently not available. Unfortunately, the new version is also not being introduced here at CA World, so I'm somewhat doubtful as to whether it will be provided this year. So it will probably be available only next year.

We are not in the production state at the moment so I cannot say anything about its stability.

We have quite good support by the guys from sales support so far but, as I said, as we are not in production yet, we cannot evaluate the normal support services.

It's a completely new solution for us as we were not dealing with REST-based APIs up to that point, and internally we are used to using SOAP Vitsa-based web services instead, as the major application technology. Now it's more and more moving to the REST-based approach with some kind of mircrosource architecture concepts that are being introduced, so we need to look for another solution or some kind of add-on to a existing integration infrastructure.

I was not directly involved but I was on the side getting feedback from the guys who were doing the real set up. It was a mixture out of straightforward implementation or installation and rather complex stuff. We're dealing with a specific installation image that was due to the fact that we were using specific combination of hardware, software and operating system.

Without naming them, they are the top contenders in the well-known ratings, so the ones that you find there were used as a basis for evaluation and, from then on, we did some deep-dives into the functional capabilities of these products and then decided on a shortlist. Those vendors were then were evaluated by our procurement concerning the financial aspect of the old stuff.

When considering the most important criteria when selecting a vendor, of course there are all kinds of functional criteria according to the product that we are evaluating. On the other hand, it's important, of course, that the vendor is stable. And because we are a large company, it is for us important that the vendor also provide some kind of stability due to its size and its footprint internationally.

Brand name isn't a big consideration for us. On the other hand, you have different analysts' reports that are quite important for us, as we don't have time and budget, from an architecture point of view, to evaluate all existing solutions in detail. So we have to have a starting point, which of course is the analysts' ratings and then, with some products, we usually do some kind of PoC and workshops to find out if they match our requirements.

I would actually divide my rating into two parts. The CA Gateway solution I would rate at nine out of 10, based on its mature capabilities in all the areas that are relevant for us. On the Portal, I would give only four out of 10 because I actually I don't quite understand the CA market strategy in that area, and the fact that the current version doesn't provide the same capabilities that they used to have with 3.5. There are some major capabilities that we miss there and which have not been introduced in the current 4.x version schemes; we're waiting for that to happen.

I would advise you plan a thorough PoC with the top two or three contenders on the list to find out about not only the functional criteria on the paper, but also how the product works and looks and feels in real life.

We modified our architecture to focus on microservices. This allows us to have a front door where we can separate and abstract services from APIs. We can use the API Gateway as the entry point to our enterprise. We can actually monetize our services, our APIs, and build a generic integration architecture using RESTful APIs.

It allows us to centralize the triple A functions: authentication, authorization, and audit. It gives us scalability. We can focus on delivery in a hybrid cloud model without exposing any of our back-end services to the market. It's very secure, very powerful, and has a great deal of complex functions that are native in the solution so that we don’t need to write code to do it.

They are getting there. Docker-based containers are there now, but it is not completed, I think. There are still some gaps between what we currently have and what the Docker model is. We are going for a pure cloud solution, so I want more emphasis on the hybrid model; deployment strategies that allow me to have on-prem and in-the-cloud interactions using the API Gateway, possibly even defining extended VIPs that we can load balance across the two platforms.

They are moving forward, of course, as they go away from the virtual clients and get to Hazelcast. The roadmap could be a little clear for us because I'm making decisions now for the next generation of architecture. It's a little hard to discern where they're headed.

The stability is excellent. The product is very good.

Their capacity is a lot bigger than we are. We haven't reached a limit or even challenged it yet.

The support has been excellent for us. We had quite a bit of hand holding to get started as you’d expect with any new technology, especially in an organization like ours, which isn't on the leading edge. We have moved from behind center to the leading edge of technology, as we are using this tool set in the cloud. We are using it with open-source software. We are using virtual machines. There are lots of opportunity here to learn things, and they helped us every step of the way.

We were using a Delphi application.

I wasn't involved. I worked with the technician who adopted the technology. I conducted our schedule and attended all the sessions. I selected the technology for the enterprise. It is complex. It's a complex scenario but it's not cumbersome or overbearing. Anytime you adopt a new architectural model, you are going to have challenges. It's as good as things get when you start dealing with something this complex.

I was actually brought into my company to define an architecture that takes them forward because they had a very large ball of mud application that was a compiled executable, and they dumped it on file servers all around the country.

We’re the largest company in our market and the application we have been using is old. I came in and defined a forward-looking architecture. An API Gateway is the centerpiece of any microservices solution.

We looked at Axway, Forum Systems, and CA API Management. We also looked at IBM DataPower, which really wasn't for us. We had ruled out CA because it was too expensive. Then they came to the table and said, "Why not us?" Then we had that whole conversation. I asked if they could make it affordable, and they did.

Our most important criteria when choosing a vendor is their ability to carry the feature set, to support its implementation. Clearly price made a difference. They reached out to us with a number we couldn't refuse; so they made it attractive. We were about to pull the trigger on another API solution, and CA met us more than halfway.

We knew that this technology, which I've used before, was the best in the world. We just didn't think we could afford it. They made it affordable. How could we pass that up? It's absolutely the best technology in this space. There is no doubt about that. That's why we really wanted it, but we didn't think we could afford it. It has been the market dominator forever, and the API Gateway has the most features. It’s the most stable. CA has taken that to the next step. They know how to use the product. Every time we call, somebody's got an answer for us.

Clearly this is the solution to have, but you need to have an internal appetite for the upcoming technology. It's not a keep-the-lights-on kind of tool set that would enable you to just turn it on and let it do its own thing. You need to have an administrator who understands it. There are so many opportunities to let it help you that don't come right out-of-the-box and grab you. You need to learn how it enables some of the tips, tricks and traps. Put a good engineer on it and give them the education they need. The device does so much.

The most valuable feature is that the API gateway is very strong in security. Most of the enterprises have exposed their back-end services as APIs and everything is okay if the APIs are accessed internally within the enterprise. However, now with all kinds of mobile channels and omnichannel customer experience, the APIs get exposed to the outer world; at such a time, you need something so that you can secure your data. You don't want to be in the news that something bad has happened. Thus, API gateway acts like a security gateway.

It has the ability to enforce security policies on APIs so that the user transaction is secured. Thus making sure that the transaction is a real one and not an unauthorized/hacked transaction.

Whenever there is a new API development our organization does not need to worry about the security aspects in regards to the API because it's already in place.

In my opinion, the policies need to be simplified so that developers are able to understand and taking that into consideration they can build their APIs. The support and maintenance needs to be simpler.

They need to provide more knowledge and it should not be that only CA is able to provide that service. There is need to pass on the knowledge to the enterprise users.

At our organization, we're still not into production but we have some references from other industries like the telecom industry. What we have seen is that there are some initial hiccups, as you encounter with any new technology.

However, once you have proper organizational structure in place to support and manage API gateway appliance, things become smoother.

We have used the technical support and it is excellent. CA is accessible since they have dedicated resources. They provide access to the engineering team and their service is good.

I was involved in the decision-making process to adopt the solution. Initially, we had a normal NetScaler load balancer. However, the challenge with that tool was once your APIs get exposed to the internet/the mobile phone, how to pass the username and password from your mobile phone to your back-ends.

The mobile experience demands that you don't want users to authenticate every time they want to use the application. For example, the Facebook user experience is such that once you enter your username and password you are logged in and whenever you come next time, the token gets refreshed. A similar kind of experience is what we were looking for and that demands API management.

I was not involved in the setup of this product. Since I was an architect, I brought the product in our organization, made people aware of it, socialized it within the enterprise with different stakeholders and now they're leveraging it.

We considered other vendors like IBM DataPower and also looked into Apigee, which is now taken over by Google.

We came up with a reference architecture, so there's got to be some standardization in regards to how you want to build APIs, expose the APIs, naming conventions and so on.

The way to manage the policies needs to be simplified and developers need to be trained. In my opinion, CA API Gateway in that security space is very ideal and it's one of the best out there.