Layer7 API Management Reviews

It’s central to our mobile-first strategy. The API layer is becoming the interface to all of our legacy back-end and all of our new app development is being built on top of our API layer.

Key features – integration with SiteMinder and its ability provide security in general, content-based routing, and ability to turn our existing SOAP service back-ends into new REST-JSON APIs.

As the APIs are built and published and made available to developers, we can build applications on top of those APIs in days and weeks as opposed to months.

In a traditional web application you’re building your UI, your integration layer, your back end, all at the same time, and there are dependencies – you can’t built the UI until you have database access, etc.

With the API model, all that access to the backend is already available so all you have to concentrate on is building a good user experience.

They have really stabilized the API gateway in the last couple of releases. There’s a developer portal that is used to document your APIs that is woefully behind the times, in terms of being able to provide a really good robust experience for the developers consuming your APIs. You can’t document all of the details you need in the current developer portal and really need a separate web site just to document your API.

You need to understand what you want from an enterprise API, what your vision, what your plans are for rolling out an enterprise API, before you just go out and buy a product.

It’s been rock-solid. When we’ve had problems with a gateway – we have a whole group of them – we typically get very good support from CA and production downtime has not happened.

Because it’s a clustered environment, we can scale horizontally as many as we need to go. So far two production gateways that are in a cluster and they’re processing transactions for one of our APIs at 30 calls a second and there’s barely a blip on CPU.

In general, I’d give them about a 7/10 or 8/10. They’re good – sometimes it can take a little while to get to the right person. They tend to come back to us with obvious suggestions, which we try before we call tech support. When we get to the right person we get an answer immediately.

It was an architecture decision to move towards a mobile-first API strategy. We realized that in order to meet the requirements of an API of a really good, strong enterprise API we needed to centralize that. That started us looking at APIM technologies. We scored a number of different vendors and brought in some to do POCs.

Nothing in IS is ever simple. However, the install went very smoothly. The OVA files that you install into your VMware infrastructure -- configuration and getting them set up in the clusters went smoothly (respecting internal processes). The setup and config wasn’t that difficult. There was much more of a learning curve on our end to leverage and learn how to use the API gateway. It’s sort of like a Swiss army knife in that you have to learn how to use which tools and when.

I look for stability in the vendor. I look for their ability to understand our needs. We get a lot of vendors who are not used to working with a Fortune 500 company and the size and complexity of our operation is big and complex. We need vendors that are flexible and who understand that their solution might solve a problem, but that might not solve it the way we need it solve. The flexible vendor that is able to provide multiple solutions typically ends up winning.

We needed a way to secure our externally-facing services. Layer 7 was a lot more lightweight and its security chops were more apparent. For deployment, it needed the ability to go with a VM image because it was not going to be on-premise. It was going to be in a cloud offering in front of our commerce spot.

Because of our experience with our cloud-hosting provider's image requirements versus what CA provided them, I think an area of improvement would be additional form factors for virtualization.

There were some issues during the initial setup. Our cloud-hosting partner required certain things, such as ESXi hosts and images. They were very particular about what kind of image they wanted versus what kind of image CA provided. So what I think would be an improvement would be support for additional virtualized form factors.

CA helped with the architecture, the design, the implementation and it's in place but it's not actively being used because the backing system isn't there yet. I can't tell you qualitatively like, "Oh, yes, it's working very well." I don't know how it's working because nobody's using it. It's waiting for the system to be ready and operational. The implementation, though, was done very well.

Layer 7 was top-of-class in the Gartner Magic Quadrant, Forrester, and all that stuff, so I did the selection process there and looked at a couple of different competitors.

Considering the various features of the API Management suite, the most obvious useful feature that we value the most is that it gives us more security, control and visibility over how our APIs are being used throughout our company and how our users are using it. It gives us more data and information so that we can target where to concentrate our resources a lot better.

The other thing is also it's in the right place at the right time. APIs are a huge thing right now especially with the mobile economy growing as rapidly as it is. The API gateway could not have come at a better time for us.

The UI on it is actually better than SiteMinder. It has a much more IDE type of feel to it.

The API Management suite for us is still fairly new as it's not as expanded as SiteMinder is. However, the potential for it to expand is still there. As an organization we can see that this is another one of those products that will be ubiquitous in the near future, just as SiteMinder is.

Organizationally speaking, it will fill a lot of the gaps where we are developing in new spaces, especially in mobile spaces, and it's going to be adopted globally in the near future in my prediction.

I don't have enough experience to say what I would like to see improved because I'm still building it into my repertoire right now.

I wouldn't say, however, that the setup is simple. It's mildly complex, but given the documentation and the linearity of it, it was fairly straightforward.

It deployed just fine.

It's stable, lightweight, works as expected and we don't see any problems with it.

We can see that it will scale very easily as well. It handles traffic efficiently, no hiccups there, and we're happy with it.

No experience of technical support on API Management so far. However, if I may also add that the support team on it in terms of sales and product management from CA is excellent.

API Management setup was very straightforward. I was involved with that, and the documentation was helpful.

The problem with API Management is it's solving a problem that not many people understand. If you look at the options in the market, there's not much. I would a to a it only advise to get it because it's actually very friendly in what it's trying to do in terms of UI. The learning curve is very short and it's something that you can rely on to work properly.

Security is the most valuable feature for us. We have a lot of threat protections turned on and I think the gateway has inherent security protections for DDoS and a whole list of other security risks. We also have the ability to customize the security of each product that we're doing, which has been really helpful. 

It also provides some load-balancing features. We can choose which traffic goes to which back-end server and the gateway will help us manage all that.

I think it's protecting and exposing our internal APIs externally. We have a lot of different types of back-end technologies that use the APIs -- REST, UIs, and GUIs. So using the API product creates a single set of APIs, even though in the back-end they're much different.

The UI is very dated. I've talked to some of the development and product managers about that, and I think it's a known issue. It's early 2000's technology. We would like to see something online and a better UI that's easier to use and more intuitive.

Reporting could use some enhancements as well. We just moved to the 8.4 version from 7.1, and they've got a new reporting tool called ESM. We're just now starting to use that, so maybe that's going to provide what we need; it's to be determined.

The deployment's taken a little longer than we expected.

We're exposing probably fifty different products externally. We've got thousands of requests, probably, per hour that come through. It's a lot of batched products -- people will run a job and it's sending a lot of things. We have a lot of traffic. The gateway itself has been stable. Downtime has usually been something like the network equipment around the gateway itself, but the gateway itself has been fairly stable.

We have development test-production environments, so to get it on our infrastructure under our own management tools, there's a lot of bureaucracy. So it's not just a push-button type deal; it requires a lot of coordination, tickets, firewall changes, provisioning hardware, things like that. All that to say that the initial setup was not straightforward but rather complex.

There were several other options evaluated, but I wasn't a part of that.

I saw some things this week at CA World which I think will make the product better, more intuitive to use with a better interface and easier deployment. There are things I saw on the road map that they'll address in the near future.

I would advice that someone go through the self-training before just jumping in. I learned from co-workers as well.

The published API is easy. We don’t have any idea how to create or add value to the API to aggregate security, and we want to add the CA API gateway.

The API gateway is a great solution.

In two months, we want a new API publishing system to be opened. We need them to have fixed the issues of the API gateway by then.

We had no issues with deployment, but it's not a stable solution.

It's not stable. I want to publish new APIs with a socket, but it’s not stable enough for this. They need to fix this bug in order for it to be stable.

We introduced it on triad, but we haven’t tested the scalability of it yet. We'll know more in the coming weeks as we test the system.

We always consult with technical support.

I used to use a proxy to publish APIs, and now we want to use the CA API gateway, as it's more advantageous.

The initial setup was easy, but I had some issues with the software. I want them to simplify the upgrade method.

The most valuable aspects for us are the security features, such as OAuth and access control. Furthermore, it's a flexible tool that performs well.

It's a great tool, but I wouldn’t say it streamlined anything. It does just exactly what we acquired for, which is to connect and manage data from our legacy system to the cloud and to mobile. We had some digital channel projects that required back-end integration and needed security on the gateway to handle the throughput that would be coming, so we chose API Management.

I'd like to be able to import a Swagger file through the gateway.

We have been using it for three years.

We've had no issues with deployment.

It has been stable from day one. We haven’t seen anything to suggest it won’t continue to be.

It's scaled just fine.

The online material is fantastic and the CA API Academy videos are excellent.

The initial setup was complex and difficult mainly because we didn’t have heavy Linux support guys.

It takes longer than you would think; timing it is essential.

It’s a way for us to secure our externally-sourced API calls that come into the organization. The two things are 1) protocol translation where we can let a REST call come in and get converted to some legacy protocol, and 2) security token translation support because we need to convert a standard industry token to something an internal system will understand.

It provides a simple endpoint for applications to call and for customers to call, so it reduces a lot of the complications of API services. Most of these APIs the user never sees, like a mobile app that does something below the water line, or another partner is calling our application – such as an order purchasing system at another customer, whose app calls our app. It eliminates the need to deal with users in a lot of cases, so if users don’t have to deal with the system it’s convenient for them. It helps us automate as well.

One item that we’ve had discussions – and they’ve fixed some of it – you had to buy extra products, specifically the CA Mobile API Gateway, to get certain types of token support even though you didn’t need that product for anything else.

So, foundational token support should be part of the base product and you shouldn’t have to buy the mobile feature to get those features. For example, in order to get OAUTH we had to buy the MAG product, but I think they’ve fixed that now. But we’re not sure they’ve fixed everything.

I think it’s a solid product. We’ve had some issues with the proprietary hardware that we’re running it on, but we’re getting rid of that and going to VMs, so the issue will probably go away. At one point in order to do certain types of upgrades to not only do it through a web interface, but we had to get deep into the system – multiple things we had to do in order to upgrade so it wasn’t as seamless as we had hoped.

It's not been an issue.

I think they’ve got really sharp people. When there’s a serious problem, they’re quick to triage and get an authoritative person to respond quickly.

Pretty straightforward; the biggest issue was the initial hardware that we purchased. CA sold the product on a certain kind of UNIX box, but those boxes weren’t appropriate for the solution – it was well before CA took over.

We knew we needed some kind of API security gateway to basically sit on the edge of our network and police what could get in, and do other things like translate API calls. We wanted a simple API call to be translatable to multiple backend system. Before we were just using traditional web proxy servers, not really API focused.

We knew we needed some kind of API security gateway to basically sit on the edge of our network and police what could get in, and do other things like translate API calls. We wanted a simple API call to be translatable to multiple backend system. Before we were just using traditional web proxy servers, not really API focused.

We used IBM DataPower at the time. Both HP and Oracle were OEMing the Layer7 product at the time, and the fact that HP was OEMing it was certainly a factor. We were looking for someone that’s innovative; someone we can trust to be a long-term partner.

It fits in well with our other security middleware. We’re also a SiteMinder customer so there are some synergies there. When CA bought Layer 7, that was a good thing for us, and we sort of fell into those kinds of synergies.

They should make sure they find a product that supports industry security standards, and has good management capabilities, good manageability.

I'd say the API gateway that routes traffic in REST-to-SOAP conversions is a feature we find most valuable. SOAP is a type of web service, and REST is another.

It allows you to much more rapidly expose enterprise services to front-end applications, such as mobile and web.

The products developer portals can be better. It needs a better look and feel.

Also, the user experience for developers to discover and develop APIs needs work.

We've been using it for two years.

It's very good.

We've just started so there's not a lot of traffic yet.

They've been responsive, but they're pricey.

This is the first API gateway product we’ve used, and we looked for a vendor who has a reputation for establishing long-term partnerships.

Initial setup was pretty straightforward.

We also looked at Axway, IBM, and Mashery. We went through a long evaluation and CA's number one strength was the built-in security management features.

As part of your evaluation, make sure that the companies can set up a proof of concept to check real situations.