What needs improvement with Mulesoft Anypoint API Manager?

From an API management perspective, MuleSoft's API Manager is not as powerful as some other tools available. Features like monetization and advanced security, which are present in Apigee, are missing. I also want the API Manager to be used as a separate product apart from MuleSoft's other integration solutions. Additionally, the licensing cost is high, and many clients are looking to switch due to this.

I'd like to see improvements in API Exchange. Currently, we can only expose APIs publicly. I want to categorize some APIs and expose them just to internal stakeholders. It would be great if they could log in to a developer portal, see our current APIs, view Swagger or RAML docs, and try request-response payloads.

There are some loopholes in the security policies that could be improved. The tool's robustness ensures who can access the platform. If there is a cracked version, the tool can track that. MuleSoft Anypoint API Manager needs to watch out for compromised licenses.

The setup process could be simpler. We are still discovering some features, and simplifying the initial configuration would be helpful.

The tool already can solve the problems for which it was designed, and it is really hard to have any thoughts over what can be improved in the product, as it is a very niche task. The product's price should be available for public review since it is not currently available for others to see, making it one of the areas where the product has certain shortcomings. The product's price is revealed only when you contact MuleSoft Anypoint.

Overall, it's quite efficient. However, I'd suggest more control over MQ restarts and greater transparency in traffic management.

When discussing potential enhancements overall, it primarily involves making it more user-friendly and lowering the pricing. There are several aspects that could benefit from improvement, or perhaps a few other areas to consider.

The product’s price could be better. They should provide training and development programs to enable the skills and capabilities of users. It would help them build a robust ecosystem similar to Salesforce.

The issues are largely dependent on the scalability of the applications. Some solutions are created for larger customers or clients. Building an application that can be flexible and can be used at any scale is necessary.

The solution is missing a monetization module. One of our key use cases is engaging with third parties, so the solution has a disadvantage because you are forced to enter a contract with another third party just for billing. Moreover, there are readily-available connectors, such as Oracle E-Business Suite, but you will have to pay for that. In that way, the solution might get expensive. These connectors should be easily accessible from the marketplace once you have access to the platform, rather than them reselling other products to you. It now defeats the whole purpose of quickly integrating a finance platform without further costs, and you are then forced to redo an already available connector if the budget does not allow you to purchase that connector.

The solution's price is high.

I don't have any notes for improvements. I'm happy with it. I'd like more monitoring and analyzing features included in the future. It would be helpful to have a dashboard with monitoring and health check visible to users.

The cost model could be improved.

An area for improvement in MuleSoft Anypoint API Manager is the process of applying policies because it's manual. It would be great if MuleSoft could make the process easier, particularly by automating it. I also want to see more features added to MuleSoft Anypoint API Manager. One example is deploying an API without manual intervention to make processes faster.

I'd like an option for having customized policies also. I'd suggest that the product provide some inbuilt customized policies alongside the ability to fully customize. The solution is expensive. They're coming up with lots of new things right now. I'm looking for something like AI-based monitoring in the future.

Monetization and cataloging can be improved. So we are looking for monetization to understand how well we can catalogue.

MuleSoft Anypoint API Manager provides decoupling of the endpoint URL for API and what API consumers/UI /Application will be able to access with a proper authentication mechanism. 

It also provides performance metrics for accessing and consuming the deployed APIs.

The weakness is a steep learning curve to learn and to apply custom compliance.

I think that they can bring some transparency in reference to the terms of the microservices architecture. It is already there, but it is not obvious.

Mulesoft Anypoint API Manager can improve some of the gateway features. We could use some more customization in creating rules. A lot of the policies are related to the APIs rather than the client. If I want to apply a policy based on a client that is not available. The dashboards are configurable, but they are not readily available with the cloud. You can see a dashboard where you can check on what is deployed. For example, a complete view of what it is, such as how much code it takes. It's there in bits and pieces, we can configure it with our credentials, but it is not readily available. If they could add an enhanced visualizer it would be beneficial.

MuleSoft has advanced features but is slower.

In the next release, Mulesoft should make it easier for people who don't have the native connectors to build their own rather than using the APA from the power platform or outlet.

The log management for this solution needs improvement. We would also like to have the capability to monitor usage metrics within the system. Currently, it is available, but only on a case-to-case basis. We would like to have an admin page where we could view and track all our usage metrics.

If they were to develop on MuleSoft it would be a good way of improving API monetization. Together with that I'd like to see the developer portal. It currently comes with a Salesforce connection but it could be integrated better.

Some items are not ideal. For example, they should for sales management, they need better performance in the core processing. The IO blocking isn't ideal. We find that the enterprise level is lacking scalability. We have some hundred Linux boxes and 400 or so APIs and for scaling, we are facing challenges. However, we haven't yet compared it to other ESBs, and therefore it's possible that all ESBs are limited in the same way. They're in the process of evolving right now. There are many changes on the horizon that may prove to be interesting. For example, we've implemented CI/CD and now it's my understanding that the graph scale's also coming.

The pricing is a bit expensive. It would be better if they offered more price-conscious licensing.

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.

The solution is not open source and the market is now open with a lot of options customers can test to explore and investigate. I think the code is something we need to explore. I think licensing costs should be reduced, it's quite expensive.

If you want to see the full-fledged functionality of their analytics engine, you have to pay separately for that. It's not the case with, for example, Apigee. That is out of the box. For MuleSoft, then you need to specifically pay an additional licensing fee be able to get the benefits of the analytics. It would be ideal if they had full-fledged features out of the box versus having to pay for them separately.

With respect to the live help, I have language issues because I can't understand some of the things that I hear.

I would like to see more automation. Our operations are mainly between the IT applications and manual site transfer. Operations are done manually. It should also automate in the operation.

I don't think that Mulesoft is doing an extremely good job. The Mulesoft Anypoint API Manager is too heavy and some platforms are difficult to integrate with. The API gateway and API runtime are too heavy, which means that it is not suitable for microservices.

The initial setup is very complex.

The most important thing that should be improved is that it is too heavy. Even the API gateway and the API runtime are too heavy, which makes it more difficult to integrate. With the talk of microservice nowadays, this is something that needs to be improved. It is not very easy to integrate into other platforms, such as those from IBM.

I think while trying to evaluate the various products on the market, and what could be improved, I'm looking at the indications and analytics and the off-the-shelf dashboards that come with it. Those are things that really catch the eye. At the end of the day, it's the functionalities and the way they integrate with the multi-cloud platforms and other backends that are underpinning the hood. If I have to present an API solution to somebody and if I can show them what are the off-the-shelf dashboards that you get in the analytics profile, that becomes a major eye-catcher to take the discussion forward.

I work with the solution more from a strategy perspective. I don't get into the day to day of how it is run and things like that so I'm not sure if I'd be able to get into features or what may be missing. The pricing is quite expensive. It should be adjusted to make it more affordable for users. When they come up with a completely new version of the solution and there is no direct upgrade for the customer from the older version to the new version there's a lot of work to be done. Whatever time and money you have invested cannot be directly used in the new platform. When they come up with a new version release or a new platform the customers, existing requirements, etc. should be transferred over easier. Migration every time there is a new version is difficult. It's something that they could fix.

The interface could be made more user-friendly. Better documentation to help explain each of the features would be really helpful.

I don't think that it's a negative, but one of the biggest things is this: when they were merging with Salesforce they never said anything about that, they did not give any positive or negative news. They were just silent about that. I think there's something clandestine has been happening over there. I'd like to know what is the future roadmap of Mulesoft is after it got merged with Salesforce. Nobody is giving proper information because I called a couple of Mulesofters and they're not giving information. I don't know whether they're naïve, or they don't want to disclose about whatever it is. That is the first thing they have to address. If they don't address probably they'll lose a lot of their customer base, so they must have to address that. Also, in regards to near future resellers - they have to increase the capabilities for the Kubernetes, for continuous integration. Mostly you can call the DevOps. Still, now there are some gaps out there they have to address for the DevOps capability like continuous integration exclusively for the Kubernetes and Docker. They say that they have complained, but I asked for realistic examples and concerns, and still very few things have to be addressed. That is the first thing that they're going to have to address probably. I had some discussions with those people there. The second thing is they're mostly focusing on the security. I think security plays a vital role in going forward in regards to API stack. Not only for the API stack, but also for the enterprise service capabilities in which security plays a vital role. They're adding a lot of security capabilities over there. That is also one other thing I hope they continue to work on in the future. In addition to that, they're going to add a lot of additional plugins. Plugins in the sense they compiled from Salesforce and a couple of other applications, but they have to address a few more applications. They should take a cue from Webex Desk. If everybody is using Webex Desk, every third-party application, and they want to communicate with Mulesoft, they don't have any plugins. They have worked a lot on the plugins. Lastly, regarding the streaming of data. In terms of streaming of data, I don't rely on Mulesoft. Whenever they do new data streaming or any streaming, the conceptual architecture connects to us, like data streaming and also for video streaming. Because the streaming capabilities are very minimal they don't stream. The capability was not there. I heard that they're addressing this issue, probably in the next couple of months. They're going to address this issue. If they are, then I think this will be one of their biggest achievements. I think it will impact their business and also their challenge. It will impact the whole pipeline also, so they can accumulate more customers.