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.
Improvements to My Organization:
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.
Room for Improvement:
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.
Other Solutions Considered:
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.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Nov 30 2015