What is our primary use case?
We primarily use the solution for our APIs. We are moving from monoliths to API architecture and we have approximately 10,000 to 12,000 APIs across banks, which are hosted on this product. It also provides us a gateway service to ingress the traffic as well as whole policy management where stuff is taken care of from the PC Any Point. It also has some API-level runtime policy management, which we use.
What is most valuable?
The gateway service to ingress the traffic is great.
The whole policy management has been great.
It has some API-level runtime policy management, which is useful for us.
The solution is extremely mature.
You can scale the solution.
What needs improvement?
The only drawback is that, due to the fact that we are going into a completely API structured way of working, it is very tightly coupled with the vendor solutions. For example, the run times. What happens is when you have to do a change or you have to do anything, you have to rip off all the APIs and rebuild it.
If you see the features, they are really good in one sense, however, they have a certain drawback when you get into the operational way of working. We definitely need APIs to have policies at runtime. They provide a feature where there's a lot of policy on authorizations, however, the only problem is the runtime.
When the runtime upgrades, we have to basically publish a new build pack and then do all the rebundling. When we were 2000, 3000 APIs, it was okay. However, when you start going up to 10,000 to 12,000 APIs, it was too much.
The whole cost is an issue. Deploying to production is not a very easy job in that bank as we go through the whole change process. The whole tight coupling of the product is a problem.
As a bank, we didn't want to take any risk of getting so much tightly coupled with any vendor product. It should be replaceable as required. That's the only reason we are now changing products.
The upgrade is a very messy process. Mule 3.X to 4 or 4.2 requires you have to rewrite the APIs. It is not just upgrading the build pack with a runtime. That is something that gets us scared a lot. They came back and told us when we move to four run times we had to upgrade. You had to rewrite the APIs. The APIs cannot just work in a straightforward manner. There is a lot of change and we have approximately 5% Mule APIs and then the rest are boot APIs. While, now, that means 5,000 APIs need rewiring, after two years, we might have 20,000 APIs. They should have a proper way of having backward compatibility.
The initial setup is complex.
If they are going with that control pane in a cloud, which is a very good feature and it is a managed service, they should give it 24/7, 100% uptime. They should also spin it across multiple regions. Currently, they are just the US and the EU is coming up. However, they should add, for example, China or Asia, et cetera. We operate in more than nearly 40 countries. Every country has a lot of its own governance and compliance and regulatory checks or some, where we cannot host to the cloud.
For how long have I used the solution?
We have used the solution for three and a half to four years at this point.
What do I think about the stability of the solution?
We have a massive set up and definitely, there are sometimes a few issues, which come here and there, however, we manage to build a resiliency inside that.
What do I think about the scalability of the solution?
We have scaled from a few hundred APIs to 10,000 APIs. Just on the retail part, the gateway service runs more than 125 million transactions per day. It's a huge setup we have.
The only drawback back again is that their gateways are pretty heavy on hardware. Therefore, we spend a lot of money on the hardware. If you compare with Kong, Kong actually can just replace everything with two VMs. We have 500 VMs running for us as gateways. It has scalability, however, it will cost you, which is a problem.
How are customer service and technical support?
Technical support has been helpful. There were also people embedded in my team.
Which solution did I use previously and why did I switch?
We are migrating from Mule to Kong now. We just have signed the contracts and we are basically getting the thing set up. It is a big project and it is going to take maybe another three to four months to roll it out to non-production and maybe another five months into production as we need to get everything in compliance and clear.
How was the initial setup?
The initial setup, if you go back three or three and a half years, definitely, for us, was complex. As a bank, we run through a lot of securities. Since then, they have matured the process. They worked with us, to do some upgrades. Kong also will have to do a few things for us, once we migrate. Currently, we are already finding some issues, which Kong is trying to help us and fix it. However, Mule took a bit of time to set up. If we were to do it now, it would be easy.
They have come up with API management and cloud hub, which is the manual service. We have not used it much, however, there are some use cases from a different part of the bank that tried it out. It's a good option as you get rid of the whole operational management side of the whole control pane. The control pane we are running is a PC 1.7.3 or something, which is old and coming up on the end of support.
The cloud hub may solve the problem of the control pane, even though they have some issues with the maintenance windows and stuff. Due to the fact that the policies are cast in the control pane, and run times can struggle, if the control pane goes down or needs maintenance because we need a hundred percent of availability in some way or other, it needs to be resilient also. The maintenance windows can cause trouble for us in banking.
What's my experience with pricing, setup cost, and licensing?
We originally signed a three-year licensing agreement.
There's room for improvement on the licensing. They could do better.
What other advice do I have?
I'm not sure I would recommend the solution to everyone. The approach we have taken is, we have moved out completely from the Mule APIs to Spring Boot APIs. We will decouple the whole vendor locking and stuff. However, it depends on the use case for each company. There is no good and bad product. These guys are both very mature products. Depending upon the use case, you will have to consider how you will handle scaling, for example, or other challenges.
Everything has a drawback and plus and minus, so pros and cons. Even Kong is a new product. It may be a good performer, and very lightweight, with low infrastructure needs. We don't know.
Our cyber is very strong. Like us, people will have to evaluate, depending upon their use cases, all the pros and cons of security and see how it fits.
I'd rate the solution at a seven out of ten.
Which deployment model are you using for this solution?
On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.