Layer7 API Management Reviews

Administration and configuration of the platform API management version 9.2. SaaS, security configuration, design, and implementation of APIs, which are exposed to partners of the company for the execution of business flows. All this is done quickly and easily with minimal effort.

• The API Gateway has allowed us to manage and maintain systems quickly, with great versatility, while solving problems in real-time.
• It allows us to keep clear traceability of the changes made in each of our APIs.
• A large number of security measures have been implemented which make data manipulation more reliable.
• As a SaaS product, control over some configuration elements and environments is lost.

• The speed and versatility in the implementation of APIs without writing a line of code in any programming language.
  
• The solution has numerous configuration options to increase security in communication.
• The administration interface (Policy Manager) is very easy to understand and use.

• This is a punctual need for the characteristics of the business or at the request of some partners: It is the use and configuration of VPNs, which in the current version is not enabled.
• Expose system properties and other configurations via the GUI (Policy Manager).
• Increase tools for manipulation of JSON messages.

It is primarily used for API Security. It has performed very well on the basic security front, but then this product is a suite of products, so it has multiples of products. We are not using all of the subproducts. Now, we are looking for a new use case where we want to use it for mobile apps. That is what we are currently exploring.

The time to go to market has been improved in developing new things while we use this product. We are able to go to market and deploy our functionalities very quickly. We are able to embrace newer security standards. We are able to do that easier because of this product, because of CA API management.

Security is definitely the top one, and other than that, it is a quite customizable product. I have seen that they are coming up with newer features and they are quick, coming into the market very quickly. Compared to other vendors, this product is much faster in coming up with new features, which is good. 

There is still room for improvement for the CA API Developer Portal. It is still not on par with where the competitors are. Other than that, the Core API seems to be very resilient and strong on the security front, but then the CA API Developer Portal is the only piece which I think can be improved. 

It is quite stable. 

We have more than 100 nodes and things are going well so far. However, there are a few cases where we are learning about some outages and that is when getting good visibility of what is actually happening would be the key. In a few of the sessions of in CA World, I was able to get to know more about what additional add-ons we can do, how we can get good visibility, and what is lacking currently. 

We did use technical CA support and it was really nice. 

There were very few scenarios where I was not able to get the answers, or maybe my use cases were maybe unusual use cases that they were not able to come up with the answers. Therefore, we definitely get good responses from the technical team and they are quite responsive.

There was one scenario where they said there is no solution for the kind of requirement that I had. For all of the scenarios that I have come across, they have been able to give me some solution. There was only one scenario where maybe my use case was quite unique.

The solution was already in my company before I came.

I was not involved in the initial setup, but I have been setting up new instances, and it is quite straightforward. 

Getting new security standards so quickly into the product is definitely a new surprise. In the CA World, I am seeing a lot of new subproducts that they are introducing, which I was not even aware of. I think that definitely surprised me that CA is investing in the CA API management product and building new offerings and new solutions, which is really nice. That is where the industry is going and they are putting their time and efforts in the right solution and the right product.

The gateway and the new offerings that they are coming in are very capable. The two points that I am missing are primarily from the development standpoint. 

I would suggest CA API Gateway to my friends in some other companies who are trying to deliver it: more from the security standpoint, the ease of setting it up, using it, and customizing it. Those were the key factors that I would be promoting about this product to my colleagues or friends.

Most important criteria when selecting a vendor: Support and the new features that they bring into the product. Those are the key things based on which we are selecting the CA API Gateway. 

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I use CA Live API Creator to integrate data from a variety of sources, and then to provide an API response to calls from my client applications.

There are a couple aspects of performance. One is just speed and uptime, and it's stellar in that regard. The other is, how much effort is it to put it in place in the first place, and then how much effort is it to keep it operational. That's where its real strength is. I'm able to do things quickly and easily that I couldn't do before.

The benefits are rapid development and deployment of APIs, which means that your information, your ability to handle information, to receive it and to send it, to visualize it, to report on it, to get intelligence out of it, happens fast and happens with accuracy. Faster is better.

It really allows us to do things that we just weren't doing before, things that we always talked about doing. Some things that we talked about doing for decades.

One of the things that we talked about doing for decades was the ability to bring data together from different sources, sources that maybe wouldn't otherwise be available. Maybe they were not ours to own. Maybe they were in a place where we just couldn't connect securely to them and enforce our security policies. What we can do is, as those things have developed APIs, we can consume APIs so we're building an API to consume an API to deliver an API. People can keep their roles and responsibilities, they can be responsible for their data integrity, and yet we can use that information to do what we need to do.

The most valuable feature is that it enables me to present data in the format that the client wants to consume it. That client might be a visualization tool, that client might be a report, that client might be a customer's API requirements.

The challenge is, how do you get the data structured in the way they want it, as opposed to how do you get them to change. My job isn't to make them change, my job is to give them what they want. Honestly, when you give people what they want, it's easy. When you try to get people to change what they're doing, it's hard.

The latest version that just came out at the first of October really was a powerful move in the right direction. I was very, very pleased with that because it allows now beginning to use information of things. We've got this IOT infrastructure that we can plug into, and for my use cases there are a lot of outdoor sensors that provide valuable information to my customers.

As we've brought on MQQT, and other ways of talking to those sensors, that just makes my life easier. I'd to continue to see them expand the scope of the product. But I can say that I've been extremely pleased with the work they're doing. They're not sitting around, every six months we get a release with major improvements.

Larger organizations have a real challenge. They have to control all the people that touch their data, and when it goes wrong - you've seen it on the news recently - it ends up being major headline news story. "Equifax exposes data to 150 million customers." That's intolerable to these customers.

What happens is that the companies that are working with that type of data have extremely rigid policies for who can get access to what. As we continue to develop the product in that regard, we would like to see continued integration with other CA products that accomplish that goal. I'm not saying that it doesn't do it now, I'm just saying that scenario where there can be continuous improvement.

I've used it for four years and I have not had any issues with downtime or with performance. That's partly because it's leveraging networks; modern networks are stable. Ultimately, people want their Netflix and their movies over the networks. There is a lot of money going into uptime, and performance, and speed of mobile networks, of physical networks, that we just leverage.

We benefit because of the performance of those networks. All we're doing is leveraging public networks to move data securely.

In my use case, I've not dealt with the type of data that usually responds to the scalability issue. Generally, when people ask that question, they're talking about scalability of hits, scalability of users. Where, all of a sudden now, you have tens of thousands of records happening within a very short period of time - will this scale? I don't have tens of thousands of records happening in split seconds. However, I do know that the product's been tested to that and has demonstrated outstanding scalability results in that regard.

There are other aspects of scalability. You might consider how well can I bring on new customers, how well can I scale my development team, how well can I handle additional API integration. Because of the efficiency of the product actually doing that, pulling data from disparate sources, and integrating it into the response format that I want, that my customer demands, that's so easy. It's 10 times, 40 times, 100 times faster than the way we used to do it, and that makes it very scalable.

I use the technical support extensively. I actually read the documentation. I know that's not something that people normally do, but I actually read the documents. One of the guys said, "If so and so, whoever writes it, knew that, she'd kiss you." And I said, "Well, maybe we shouldn't go there, but... "

I actually call them, and they've been wonderful because I have their cell phones, I can text, I can call. They probably don't want everybody to do that, but they want their products to succeed, they want me to succeed, and I want to work with a vendor that wants me to succeed.

You look where your pain is. If you can perceive pain, you know what you need to do. Where does it hurt? That's what you need to work on.

A different solution didn't exist. You developed things in code. You used C++, you used Java, because that was the only way to do it, to build it yourself. Now, much of the lifting is done, but the extensibility is still in the product. What you're forced into, or what you have the opportunity to take advantage of, is a system that has done a lot of the hard and mind-numbing, repetitive tasks; simplified so many of the things that you would have to do. Incidentally, that creates an opportunity for a mistake. Those things are automated, but the extensibility is still there on the product, so you can still do the things that are specific to your business's needs.

I'm going to assume that this question is asking, "Was I involved when we got on board with this product?" Yes, because I bought it. They were there for support but the question is not relevant because it's so easy. It's deploying a WAR file. If you can deploy a WAR file, you're done.

Where I got involved with CA on this product, there were not really competitive products. Since that time, there probably are some companies that have come out, but honestly, I am busy enough, I don't really look because there's no reason to divorce myself from CA on this product.

When selecting a vendor, there are a couple of things that you have to look at. One is: Are they going to be around? That's always a concern because if you've committed to something and the rug gets pulled out from under you, then you're scrambling. Depending on the time that happens, you might not have the time or the money to scramble. What if you're in the middle of a big implementation? CA has been around since the beginning. They're a four billion dollar a year company, something like 13,000 employees, I'm not worried about that. Yet they're easy to work with.

There are a couple of products that I work with that have not let me down, and there are a lot of products that have. I always use Microsoft Excel of an example of this. Excel is a wonderful product, you can do so much with Excel, it's an incredibly powerful product. But there are many times where Excel just leaves me short. I just can't do what I need to do with it. It has limitations, fundamentally.

There are a couple of products that I've worked with in my life that I haven't run into that. Maybe I still will someday, I don't want to be delusional, but this product, when I've had a need, I've been able to get it to work and that's nice, I like that.

It's hard for me to give tens, but I would give it a 10 out of 10.

My advice would be: Focus on its extensibility because of that exact issue we just discussed. There are so many times when you look at a product that is a tool to make something easier. Maybe you're building a web-based application. There are a number of tools on the market that make that a drag-and-drop opportunity or a drag-and-drop process. Those tools are great for the weekend warrior, you can get something done quickly. Maybe you're a high school kid and you want to build an app for something. (Access database would be like that too. You can get a database and it's not that hard, and you can make a form, but they're not enterprise class). 

This product, at first blush, looks something like it's one of those weekend warrior tools, but it's not. It's an enterprise-class tool with the kind of usability that you wouldn't expect. And with that usability - how do you have your cake and eat it too? Well, it's because of the product's extensibility. It's very well-integrated with your existing Java library of processes and procedures, as well as your ability to write new extensions to it. You get so much of the base functionality but you don't give up the ability customize.

Mainly for our API gateway. We use it for onboarding APIs and then getting those internally. We have them through the B-to-B channel, we have them through a member channel, and then internally as well, to service our APIs.

It has performed pretty well. We've had an issued with scaling, internally, when we slammed it one time with a very, very high rate of transactions; we're talking like 65 million an hour. Whenever we did that we weren't ready for it yet, so we had to back out, but it's been good.

It's pretty easy to use, and once we have templating set up we can add new APIs, at least through the gateway, and apply the security to them; it takes a minute. 

We actually have it automated in our Dev environment, where developers can come in and fill out a form with an internal tool. They specify their API, the endpoint they want, this is what they want, and boom, it creates it in Dev and then they can move it up to test and then put in a request to get it to product.

We've used it for so long that I really can't say that it's improved the way our company works, but it works very well for us.

I'm mostly involved in using the OTK for OAuth security. We use the OAuth for all of our reactive APIs, for B-to-B to come in, and we're starting to onboard those now. 

It's been pretty easy to use so we enjoy that, other than a couple of challenges we're having with it currently.

It would be nice if we could create APIs directly from Swagger files. We're doing that ourselves with a middle layer. But if you could integrate with open API Swagger specs, and then just create a Swagger and upload it to the gateway and it would create all my API template policy, and would apply the OAuth restrictions, the types of security restrictions I have on there, that would be pretty cool.

Stability has been fine for us in tests. We have a challenge around some log rolling and it bringing it down in tests, but in production it's been great.

The scalability has been good. We haven't had to scale up a whole lot, even with all the extra transactions we're running through it. We're in the area of about 2 and 1/2 million OAuth tokens issued per hour, and it's performing fine with that.

It seems to work pretty well. Sometimes it takes a little longer to get answers than we would like, especially to some low-level ticket where we just had some questions about why this thing is working that way or that way, not high priority stuff. It would be great if we could get those answered in a day or three, instead of two weeks.

I was not involved in the initial setup but I am involved in the OTK upgrades.

Well when we went from 9.1 to 9.2 it was pretty straightforward. The OTK, however, is a complex upgrade. They tend to change the schemas on the database behind it, between the versions, which can be a pain to have to migrate all of our existing clients from one database schema to the other. It also means working with the DBAs to set up side by side schemas so we can get them moved and switched over in a fully available.

I don't really select the vendors, but my most important criteria would be

• available support
• industry use of the tool
• that it can solve all the problems I need it to solve, as many out-of-the-box without customizing it as possible.

CA is great. It depends on your use case of course, how much you want to go with that, because it can get pricey and depends on the size of your company. I've got a bunch of friends with little start-ups, so it's nothing they would be able to onboard, but I would definitely tell them to check it out.

We have a full, classic, API gateway currently. We want to leverage it to use the microservices, with the help of micro API gateway, to support our business or e-commerce platform, the API traffic. That's our main our goal, to move further toward a microservice with a Docker container.

We implemented it in a non-prod and it is good. But we want to move into production going forward. Performance-wise it’s good, and we are not seeing any issues.

The benefit is maintaining the security of the APIs and securing the transfer volume of the enterprise for any business transactions.

The main feature is the security, and then the performance of the APIs is good. The monitoring part is also helpful.

We are looking for improvements related to integration. We want to see them add integration tools to the CA bundle. That would be helpful.

Stability-wise it's good. We are not really seeing any issues. We have had CA products for almost four years, and until now we haven't see any outage or any impact of the gateway.

Scalability is good. With the new/future version of the gateway, we can easily scale up or scale down the gateway instance in the Docker container.

Technical support, the CS support, is good. They respond promptly. They give guidance and they give recommendations to improve the platform performance.

We were previously using a different API gateway. We had some issues with those servers. We did some evaluation in the market. I evaluated server software and IBM DataPower and Intel products. Finally, based on all the features, like security, we decided that the CA product is the best suited to the needs of Motorola's business.

I was involved in the initial setup. We brought in CA Professional Services to help start the infrastructure in our installation.

It was not complex, documentation-wise it is good. CA maintains the documentation very nicely, so based in the documentation we were able to set up the environment. It is all straightforward.

The main thing we look at when selecting a vendor is what partners are using them and how successful they are in that business with the product. Then we'll look at industry ratings. Based on that we will consider if we need to go with that product or not.

I rate it a nine out of 10 because the product is not only one product, API Gateway. If I want to monitor the gateways, I need to go with other CA products. It's not like a package, it is multiple products. So if it was a complete bundle, then I would rate it better.

I would recommend going with it.

Security. We have a lot of APIs, a lot of web services inside Motorola, and we wanted to have a solution which can secure all our APIs.

So far it has been doing well. But we are looking towards microservices technology. And we heard here, at this CA World conference, that they are coming up with a microservices API gateway. That is something that we would be interested in looking into. 

But as far as far as the classic API gateway goes, I think it is definitely doing well. We were bought by Lenovo, and eventually Lenovo, which did not have this solution, has also been convinced to use it. So overall, as one company, both Lenovo and Mortola will be using this product.

It can be scaled, especially the current version. It can be scaled as we need. And it can be used in different regions. We have different data centers in the U.S. and Beijing. We use it on-premise, on-cloud, and it can be hosted and used at any place and scaled across the regions. That's the primary benefit we have seen; other than providing security and the performance.

What we had before, Forum, obviously was not reaching our performance requirements. This really helped us, because every API that we get from external or from internal goes through this layer first, and it should not be a bottleneck. That was the problem we had before. Now it's no longer a bottleneck. It's more like a throughput, this process is less than 10 milliseconds for any particular API. 

So the number of transactions that we are able to process per second and the number of instances that we can use are benefits. 

Even before microservices API gateway came into the picture, two years back, CA really worked with us and helped us to get hourly pricing, so that we could spin up, spin down instances as we need, like during Thanksgiving or Christmas. So the product, by itself, is great, and the flexibility that CA has given us out of this product is really great.

From the security point of view it provides lot of features, as well as performance. I think it's 4000 transactions per seconds, per node, is what the performance is. So those two are major features that we have been looking for. It does both in a great way.

Microservices gateway is one thing in which we thought would be really good. It has come up, we just have to see how it's going to play out. Obviously, it's not going to replace the classic gateway, although we want to see that something in the microservices gateway that can actually replace classic gateway. That would be really nice. Right now, I don't think it's completely replaceable. It's just a part of it, but eventually they're saying that it will replace. So one day, where we can have a microservices gateway and we will not need the classic gateway at all, that is what we want to see.

We have never had any issues, to be frank. From the time that we had it installed we have never had any issues, whether in the non-prod or in production. So I would give it top rating from the stability point of view.

As mentioned, that's one of the great features, the scalability. We were able to scale up in incidences as needed, and scale down. So again, completely flexible. Top-rate, from the scalability point of view.

We use technical support only when we do the upgrades. My team, we always try to be at the latest and greatest version. Whenever they release, the next week we are already there, both in test and production. So when there's a new release, obviously there are some important technical features of which we are not aware. To learn about them we use the technical team. 

But other than that, from our point of view, as I mentioned, it has been pretty straightforward and pretty stable. We don't have a need to reach out to them, except when there are new features and we are migrating.

They're good. They have been really helping us. As I mentioned, CA as a whole has been a great partner for us and has been helping as we need. Whenever we need their support, they are there. Whenever we need information, they are there.

We were using Forum before, but we wanted a much more flexible solution that scales and has better performance. That's why we chose CA's API Gateway, to resolve our security, and provide the best performance for all the APIs that we have.

It wasn't really all that complex. What we had before was really pretty complex. When compared to that, what we have with CA is not.

We evaluated Forum, obviously. Layer 7 is one we looked into. Axway. IBM, because we use it a lot for e-commerce, so that is an API gateway we have been looking into.

Among most important criteria when selecting a vendor, the first thing is pricing. After that features, obviously, and then the performance and stability.

We would definitely recommend implementing Layer 7. The only reason you might not implement it is if you are looking at open source, but open source comes with its own issues and cons. But if the cost is not an issue, Layer 7 is the top and I would definitely recommend it to anybody.

The primary use case is we are using the API Management Suite. It has the Gateway and Portal, and we are using the Gateway to front all the APIs in FedEx.

The Gateway is performing very well. The Portal is not.

We can get more visibility into our data.

The benefit of the Gateway is that it provides security, authorization authentication, and analytics. These are the main benefits which we are using it for. 

The most valuable, for the Gateway, is it can front our APIs very easily, and it can integrate with FedEx easily, so those are good. 

For the Portal, we are able to manage with APIs and documentation. However, there are a lot of improvements, which could be done on the Portal side.

For additional features, I would like to see how it can be deployed into the cloud platform out-of-the-box and not having to do a lot of the initial setup. If it can be done out-of-the-box, that will make customer's life very easy.

Their upgrade solutions are not straightforward. Therefore, we are running the older version. We wanted to go to the latest and greatest. However, it is really complex going from where we are to the next one. 

It is fairly stable for the Gateway side. However, not for the Portal side.

We have seen that it can scale both vertically and horizontally. 

We have used technical support quite often, and they are really good. We have opened multiple tickets, and they are very responsive, especially for the Severity 1 tickets. 

The initial setup was very complex.

CA Service was helping me with the implementation. 

Initially we were looking into different options. We looked into Apigee, Axway, and CA. We did the whole evaluation, and CA come out to be the winner, because CA is the market industry leader.

From CA's new technologies, it looks like CA is moving in the right direction.

Look to your performance matrix and your benchmarks. What are you interested in? If you are looking for support, this is definitely the best solution. 

Most important criteria when selecting a vendor: Performance is one of the major ones. Security is another. 

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.