What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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".
For how long have I used the solution?
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
No. Not a solution that support the full API management methodology.
How was the initial setup?
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.
What about the implementation team?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?