MuleSoft Anypoint API Manager alternatives and competitors

We have an open banking initiative in Indonesia. We are mandated by a regulator's bank in Indonesia to open up our services to other institutions, not only banks, but also financial technology (FinTech) companies and startups as well as eCommerce or other industries.
Thereby, they can consume banking services through an API, such as our funds transfers, mobile banking services, or a bill payment, like electricity, water bills, college, and so on, through an API to their applications. It is not obligatory that you need to download our mobile banking in order to do these transactions, but you can do the transaction using other applications, such as the FinTech or eCommerce application that the customer currently has. Those use cases, for the open banking readiness for Indonesia, utilize webMethods API Gateway and standardized services of API for fund transfer, debit credit transfer, bill payments, and opening up a savings account using online applications. Those are pretty much the use cases for webMethods API Gateway in order for us to connect it with FinTech startups, eCommerce, and other institutions who would like to consume banking transactions through Mandiri.

Since we are a very highly regulated industry, which is a bank in Indonesia, we are not allowed to host any financial transaction outside of the Indonesian region. So, the solution must be deployed on-premise inside of our data center.

Are you using multiple products from this vendor?

We are using multiple products to build the end state of our service-oriented architecture (SOA). This is all orchestrated as a big building house. Those SOAs have many capabilities inside of them on the integration side, such as webMethods Integration Server. (Read my webMethods Integration Server review here.) There is also webMethods API Gateway and Software AG Apama. Those modules inside of Software AG complement the building blocks of SOA.

We also use it to complement other products in the markets outside Software AG, such as Kafka as well as all event processing and streaming. This is in combination with the capabilities (and beyond) of what Software AG stacks can do.

I find the native integrations between Software AG products to be very useful from a plain vanilla standpoint. Though, when we implement native integrations, there needs to be slight customizations to fit them into our core legacy system, and that needs to be integrated with other systems. For plain vanilla capabilities, it is sufficient enough.

The native integrations between Software AG products also have good performance in terms of transactions per second (TPS). These are acceptable in terms of the volume and speediness of a transaction that we can produce as well as being combined with the efficiency of using the hardware, memory, and CPUs.

If you combine the commodity hardware and performance as well as the plain vanilla capabilities of internal products that Software AG has, then there is a good price per value.

It gives you a one-stop service for your integrations area. You can really rely on one vendor, then you don't have to worry about sustainability or support. This is all guaranteed by Software AG as a single stop service from them. Whereas, when you need to combine other vendors, then you need to monitor each of their solutions, sustainability, product roadmaps, etc. Then, this becomes your technology liabilities, which is something that we consider. From the integration, we are selecting a good strategic partnership with one vendor in order to maximize our productivity. Thus, we don't have to worry how we can monitor each respective vendor if we do a best of breed combination of many vendors, just to do an integration.

By selecting Software AG and using multiple products, this saved us about 72 percent, which has definitely given us more agility.

Because we were already accustomed with webMethods Integration Server way before the webMethods API Gateway, they were almost the same. We just converted our knowledge from the prior WSDL into RESTful JSON standard messages. Therefore, the learning curve was very smooth because the environment that the developers use was still the same: My webMethods Console. It uses the IDEs coming from that, saving us a lot of time with the learning curve on new technologies.

Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API.

You can carefully select what services can be consumed by the outside and what services can only be consumed internally. Also, you can see what the fallback scenario is, if some services are customized and what is the impact analysis, e.g., what is the impact to other services that depends on certain services that we are currently automizing. These are very critical capabilities for API implementation in any organization. You do need to have good API governance for it, not only tools, but also all the procedurals. You will need all the standard operating procedures for starting a development of API up to deployment into production.

webMethods API Gateway provides an engagement platform for managing hackathons. Our last hackathon was in 2019. We developed several services in the cloud using a sandbox environment, so it does not connect with our real life production environment. We created some accumulated transaction behavior, so hackathon developers could connect it with our box services within the sandbox environments. It does provide good freedom to host competition in an isolated environment.

At Mandiri, we divided webMethods API Gateway into two layers, the external API gateway and the internal API gateway. The external API gateway is for Mandiri channels and our core partner channel for feedback, eCommerce, and other institutions. With their channel, they like to connect and consume services. webMethods API Gateway gives you a sense of security and quite adequate minimum security to secure services, e.g., DDoS attacks, man-in-the-middle attacks, and queries for SQL injection. These are already built inside of webMethods API Gateway. 

It has a good role definition and scope for its services. Expected channels can only access what type of services, and we can define those as per our contract with prospective partners. So, it boils down to the architecture: How do you like to architect the integration and partnering with other institutions? It depends on that. However, the system itself gives you that flexibility.

webMethods API Gateway gives us a set of rules and good security for securing outside work to connect with our services. It has good minimum security measurements built-in. However, webMethods API Gateway itself has very minimum API governance. You need to have a central site in place to have full-fledged governance, which is one of their modules.

The solution provides a fully customizable portal that has built-in testing and collaboration capabilities. Because it is similar with other well-known products in the market, the process doesn't have specific requirements. We do have a good adoption rate. We only have two weeks of learning and customizing the behavior to developers. By the third week, every developer can actually develop by themselves.

Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others. 

One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services. 

With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.

With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.

We have used it for almost three years, since 2017.

How do you get money from selling or offering your financial services to the other partners or institutions? It comes down to monetization. How do you monitor usage of certain particular protection or usage of services? I do see a lack of capabilities inside of the monetization area for them. They have a cloud infrastructure that is pay per use type of a thing. If you already use 1,000 transactions per se, then you can be charged and billed. I see room for improvement there for their side on that particular capability of the monetization.

We have evaluated other solutions, such as Apigee and MuleSoft, back in 2016. but since we already have Enterprise Service Bus that is using the integration server, which is collecting and managing all the integration services inside, we wanted to see the end-to-end picture of the service itself. It was very logical that you need to have end-to-end monitoring and trend deployment from the service deployment, up into exposing the external world using webMethods API Gateway. We see those advantages from using webMethods compared with other solutions, such as Apigee or MuleSoft, because of the continuation of the architecture. We would also like to expand those into our separating stacks.

In every implementation of webMethods API Gateway, I strongly suggest that you need good API governance. webMethods has their API governance all built inside of your license. It is a continuation between the services using the webMethods Integration Server and webMethods API Gateway, exposing those services into the outside world. You need to have good governance for that.

I would rate this solution an eight (out of 10).

Our use cases for IBM API Connect include the banking sector, where they use the solution to integrate with third parties, so all of the third-party connectivity for the banks happen through IBM API Connect.

We also built the government service website, for example, e-Government services, and the government published all services between the government entities and the businesses, so there are two connections: government to government and government to business. All the services and entities were published and consumed through the IBM API Connect gateway.

What's best about IBM API Connect is the excellent administration. The development tool that builds the API is also very simple, and user-friendly, and it doesn't consume too much time.

Another valuable feature in IBM API Connect is its good reporting feature, particularly for operations, but the most valuable feature of the solution for the customer is security. IBM API Connect provides a DMZ and a security gateway between the external and internal environment, so you can publish your API safely.

IBM API Connect can also integrate with any tool or middleware that works on open standards without the need for development or coding, so integration with the solution is easier.

Technically, I haven't faced any issues or areas for improvement in IBM API Connect. There wasn't any concern that the customer asked that we couldn't resolve or achieve. I'll need to check with the technical team if there was any issue with the solution, but from the top of my head, I haven't faced anything that the customer requested or anything that needs enhancement in IBM API Connect.

The implementation of IBM API Connect is complex, as it's an enterprise solution with many components that require more than one person. It's not a single product that you work on, and this is an area for improvement, but normally, it's good.

Having a more structured model for IBM API Connect support is also room for improvement that would help customers better.

I've been working with IBM API Connect for the last five years.

IBM API Connect is a stable solution. It's used in government services, and my team barely receives calls about the solution. IBM API Connect is also used in major banks here in Jordan, and it's stable. There are no complaints about it.

IBM API Connect is a scalable solution. It's deployed based on the Hybrid Entitlement model in IBM which gives the customers five million API calls per month, and if the customers need more, it's just a matter of buying an additional license to make it ten million API calls per month, so customers can build any environment that meets requirements and do production HADR tests without paying a lot more for the license.

As IBM API Connect is subscription-based, it's good, and it allows customers to scale as much as needed without exceeding the number of API calls. Most of the customers do not reach that limit anyway. If a customer needs to go beyond the limit, he can get a CPU-based license, but at the moment, I haven't had any customer who needs a CPU-based implementation of IBM API Connect.

The technical support for IBM, in general, isn't the best. You'll need to understand the internal setup of IBM or you need to have a partner who understands the IBM setup to get the best support from IBM. There's a program that IBM offers, the AVP, where a consultant is set aside for you or the customer, and that consultant will provide support to you.

For the technical support focused specifically on IBM API Connect, the team is good. The team of engineers is responsive and knowledgeable.

We haven't worked with other solutions similar to IBM API Connect, but we're considering another alternative from Open Source, though we haven't decided which product we want to work with.

The initial setup for IBM API Connect wasn't complex, but for the new model or the containerized model, the setup for the three nodes or containerization wasn't as easy as the normal on-premise setup or the traditional way of implementation, so the first time my company implemented the new model, it was complex. The complexity wasn't because of IBM API Connect, but it was because of the RedHat OpenShift platform beneath it, though after my team did it once, the next implementation became easier and simpler.

The price for IBM API Connect is reasonable. It's $20,000 to $30,000 yearly for a subscription, and the pricing could vary around $40,000 per year, per subscription. Its price is reasonable for customers who have around sixty million API calls yearly for unlimited environments.

I haven't evaluated other options, but I've heard about Apigee and that it's a good solution. I've heard that Apigee is technically better than IBM API Connect, but I don't have the facts on why it's better. What I heard from the customer is that Apigee is costlier than IBM, and that customer paid hundreds of thousands of dollars in Jordan. The customer contacted my company for a POC for IBM API Connect, so it seems that the customer didn't get value from Apigee based on the money he paid.

There's also MuleSoft, but I didn't see a real implementation in Jordan where there's anything extra or different from what IBM API Connect provides, and I have no idea about MuleSoft pricing.

The Jordan government accepted IBM API Connect because of the security and stability of the solution, and in terms of project implementation, it was the best project implemented that's based on DataPower and API Connect.

I'm still working with IBM API Connect.

I'm an implementer, system integrator, and reseller of the solution.

Mostly I have mid-size and enterprise customers for IBM API Connect, though I also have small-sized customers. My customers use the solution.

Most of the customers here in Jordan prefer an on-premise deployment for IBM API Connect, but my company also has cloud implementation, one public and one private, then the rest is on-premises.

My advice to people who want to start implementing IBM API Connect is to always start small. You need to understand the value you want to gain from implementing the solution, focus on business values and achieve those, then start to grow bigger later. Don't start with a big environment when implementing IBM API Connect that wouldn't result in any business value. Starting small with real business values that will touch on business needs is good advice for anyone who wants to implement IBM API Connect.

My rating for IBM API Connect is nine out of ten because it's a good IBM product. It's one of the products you can easily sell.

I work as a software engineer on the WSO2 API management and WSO2 identity and access server, using version 2.6.

At my company, Jio India, I have been one of the main people driving adoption of WSO2. In the beginning, we used WSO2 on virtual machines to handle the API and IAM requirements for more than 40 applications. Now we are currently in the process of migrating to WSO2 version 3 with Kubernetes as our orchestration system.

It has helped us manage and scale our APIs in one solution, which is important to us as a large enterprise with over 40 applications relying on various APIs.

One of the great things about WSO2 API Manager is that it is so easy to adopt. And because it's an open source solution, we're able to extend the implementation any time to suit our applications better.

From a product perspective, the first thing is that although the documentation provided by WSO2 is good, it could be much better. We're in the middle of a complex migration, moving away from VMs to Kubernetes with the latest version of WSO2 and good documentation is essential to us right now.

If you are doing some basic implementation, that's easy enough to do with the current documentation, but suppose you are stuck with an error or you're engineering a complex scenario. In this case, when diving deep into the documentation, it's very helpful to find more information on how things are connected, what each file does, and what the various configuration settings do.

Although they do have paid support which may help in cases where documentation is lacking, we aren't paying for a support license at the moment so we would definitely like to see better documentation for those in our kind of situation. Especially since we're using WSO2 API Manager to such a large extent.

Beyond documentation, they have provided a caching mechanism which I believe could also use some improvement. Once you have set up and implemented WSO2, caching becomes very important and I think they could work on the cache parameters, etc., to make it easier to work with.

Regarding the code itself, there are some bugs which we have encountered among the many different enterprise-level scenarios we have faced. Once again, because we are not paying for the licensed version, it becomes more difficult to request changes and bug fixes to the WSO2 codebase. So, for example, when we find a bug, we would like to be able go to GitHub and get better help on creating a solution that we can quickly push into production.

I have been using WSO2 API Manager for about five years now.

In terms of orchestration, it's very scalable. Especially when using Kubernetes to handle the orchestration. When we are creating our deployment architecture, we can easily define all sorts of parameters. For example, we can change the CPU parameter, memory parameter, etc., as needed.

We don't have a license with WSO2 so I couldn't connect with the WSO2 team for technical support. I was the main engineer who drove adoption of it at my company, and during initial setup, editing of the product, and implementation, I obtained a lot of support from Stack Overflow, LinkedIn WSO2 groups, Slack conversations, and GitHub.

From a deployment perspective, initially, we had started with our deployment on VMs (virtual machines), which we understood would take some time to get right. Thankfully, WSO2 provided many sane defaults in the initial setup, including defaults for authentication and so forth, which saved us some time.

But as we migrated our deployment from virtual machines to orchestration using Kubernetes, it became a bit more complex. It took us a long time to figure out the best way to configure the orchestration, since there are multiple ways of doing it with Kubernetes. Another complicating factor in the orchestration setup is that we have to always keep in mind where our users are located, so that there won't be any negative impact on their end.

Keeping all these points in mind, we finalized deployment by creating our own API manager image which we could deploy in Kubernetes. This image was based on our previous VM setup, which we simply reused. However, it was still a challenging task to get everything correctly configured for the Kubernetes orchestration, especially since we were in the middle of simultaneously migrating 15 different implementations.

Now that we have mostly finalized the deployment architecture for our APIs, it's much easier moving forward. We know exactly how to deploy the base image, and there's not much work to do now except for changing parameters around and so on.

We are implementing WSO2 API Manager without any paid support licenses so we do mostly everything in-house.

We have not opted for the paid version of WSO2 but we have implemented the free and open source WSO2 software to a great extent and it is working as per our expectation.

When we started looking into it, we compared WSO2 products with a few other products including MuleSoft, Tyk, Kong, Nginx, and Express Gateway. Obviously each product has some pros and cons, but out of those products, we liked WSO2 and KONG. Again, both have their limitations, but as an enterprise business we found WSO2 more easy to adopt.

WSO2 API Manager is a good solution for enterprise API management and, even better, it is free to use the software. If you are doing complex implementations, however, it might benefit you to go with a paid license which will help when you discover any bugs or need extra support that the documentation cannot provide.

I would rate WSO2 API Manager an eight out of ten.

I'm a part of a service provider company, and we basically provide all kinds of services for our customers. One of the areas for which we provide services is API management. We work a lot with Apigee, and we have experience and a good team working with Apigee.

In terms of use cases, we've created a good marketplace for one of the clients. They are a logistics company, and they have a lot of vendors and partners with whom they work. So, we have created a marketplace where the vendor's partners can integrate for their shipments and other things. They can integrate their applications into this marketplace.

We have also implemented developer portals where we do the onboarding of developers. They can create their code SDKs, etc.

Currently, we are at a customer site, and we are migrating the on-premise version H to Apigee X, which is the latest one.

The analytics function and the developer portal are the two valuable features of Apigee. The analytics part is very good, and the developer portal is quite rich in features.

The authentication mechanisms are quite easily built into Apigee, which is something that most of the other products have also now started supporting.

iPaaS is something that we would like to see. For example, MuleSoft is kind of an integrated platform as a service (iPaaS), and it provides a lot of out-of-the-box connectors and other such things. This is where Apigee lacks. I'm not sure if that's the roadmap for Apigee, but any improvements on those lines would be helpful where things become easier to implement.

It has been four to five years.

It is definitely stable. Performance-wise, we have not seen any major bottlenecks. What we have realized is that the performance is not just because of the tool itself. If you take any API management tool, the performance also depends on the way the integrations are done. So, if implemented correctly, performance is not really an issue.

With the SaaS model, scalability is there. 

It is suitable for large companies because it is a bit pricey. It is definitely not for small companies, but it might be suitable for medium companies.

We have not been in touch with them much because we mostly have done development, but they do provide good support. Their support during the initial design architecture phase is also very good. So, if you have bought the licenses, they do provide an architect to come in and define the whole architecture. That way, the support is good.

We work on multiple API management tools based on the requirement of a particular customer. We have worked on Apigee, Dotcom, MuleSoft, to name a few.

Managing an on-premise setup themselves can be a huge overhead for customers. Apigee, I believe, releases patches very frequently, and those upgrades and maintenance activities are quite an overhead. Having said that, it has good support. They provide a lot of scripts through which the installation and other things can be automated, but obviously, we have to tailor those to our needs. On-premise is definitely a little bit of overhead. We have to have a team to manage that, but now with Apigee X going on SaaS, most of the implementations are on SaaS. So, this overhead is minimized a lot, and you just have to do the configurations.

It is a bit on the expensive side. Its licensing cost is a bit high, and that's where we've seen people going back on their decisions.

In the latest version of Apigee, they've broadened the support for socket communication, which was previously missing in Apigee Hybrid.

I wouldn't recommend Apigee for simple situations because sometimes, it does become an overhead. It is overkill for simple situations. If you have very complex scenarios where you are trying to embark on a cloud journey and you still have systems on-premise or some systems are hosted on some other cloud and you want to do an integration, Apigee is really good. It provides support for the mesh architecture, and with that, it becomes quite easy.

The advice that we normally give is that when you are starting on an Apigee journey, you should not think of it just as an API management tool. We try to give it as an enterprise API platform that a large customer with different lines and businesses, such as a bank, would eventually leverage as a whole. You should not treat it in a way where only a particular group is using Apigee. It is an enterprise platform. So, you should treat it as a platform.

I would rate Apigee an eight out of 10.

I lead the integration practices in my organization and have been working in integration for the past 16 years, managing API integrations with various API manager tools such as Kong Enterprise.

We are primarily using Kong for the API gateway functionality. For example, we've had a couple of mobile applications with outbound traffic where we would use the Kong Enterprise gateway to expose the API by applying authorization, authentication, and other security policies.

We have also used Kong for role-based access control mechanism (RBAC) and integrated it with our enterprise directory in order provide it with this form of access control.

There was another particular use case in which we performed some customization, as well. In that scenario, we wrote a Lua script on top of Kong to add an AppDynamics plugin to our web server, for observability and monitoring purposes. 

Kong has been used over a large user base, not only because it's an enterprise application, but also because the mobile applications we worked with were B2C-based in the retail industry, so the number of users was quite high.

There are a few features that I like about Kong when it comes to authentication and authorization. Specifically, being able to use Kong for role-based access control (RBAC), and then further being able to integrate the RBAC mechanism with our enterprise directory, was very useful.

Another nice aspect of Kong Enterprise is the ability to customize it with Lua script, such as when we developed a way to provide observability for our web server with AppDynamics. 

Kong is meant for north-south communications, so it will be interesting to see what solutions they can come up with in the realms of east-west communications, service-to-service communications, and Zero Trust architecture. I believe that if they can provide for these areas, then they will be able to solve the overall integration and security concerns for microservices architecture in general.

I have used Kong Enterprise for a year and a half.

I don't recall that we have faced any challenges in terms of stability. It has been a good, solid implementation.

It is scalable in the sense that, as we started putting things onto the cloud, we added one application and then we scaled up the same instance with Kong for multiple applications, which was where we served everything. And since it was a mobile B2C application focused on the retail sector, the number of users was quite high.

The tech support was good. We mainly used them when we needed help with our Lua plugin installation and they were responsive to our needs. The team we dealt with were based in Singapore.

We previously tried using Apigee, but for our needs, Kong was the right solution.

The setup wasn't that simple. There was definitely a learning curve because Lua as a language was new to us and so we had to learn about Lua script first. At the same time, we also faced some other challenges in the implementation where we had to ask for professional support from Kong Enterprise.

The technical team working on our Kong deployment included three or four people on the infrastructure side and another two or three involved in development.

I don't have any information on licensing costs currently.

We also evaluated different options such as those provided by Mulesoft and others.

Kong Enterprise is a good API gateway and API management product which is based on lightweight and high-performance software. However, there will likely be a learning curve for beginners because they are using Lua script, which is not that popular. Regardless, anybody coming from a core software and integration background should be okay.

It's always good to keep in mind that you should use Kong for the purpose it is meant for, rather than overloading it or overburdening it with use cases that are not appropriate.

I would rate Kong Enterprise a nine out of ten.