What needs improvement with Microsoft Azure API Management?

The pricing model needs improvement, as some enterprise features are expensive.

Latency is an area that needs improvement, especially for multi-tenant applications. This was a big issue for us three years ago, particularly when working with Azure Data Centers. Although this problem is not as significant now, improving latency further would be beneficial.

Microsoft Azure API Management could be improved by enhancing the preview feature, specifically the workspaces. The feature should allow for better delegation of permissions to specific groups without affecting others. The service is extensive and expensive, and this added flexibility would make it more manageable and less prone to errors.

The solution's data mapping and orchestration are very code-intensive or require callouts to external systems. They seem suboptimal for the more complex use cases.

The solution's deployment process could be slightly improved in terms of time. Additionally, they should enhance AI capabilities and more advanced integration features with other platforms.

Documentations for implementing certain product features are very difficult to find. Information regarding some features of Microsoft Azure API Management cannot be found through searching on the Internet; it can be understood, discovered, and learned hands-on while using the solution. Documentations for the product should include examples of implementation.

The solution's integration suite needs improvement.

Price is the first thing that comes to mind. It's quite expensive, which could be a barrier for some users. So, pricing is an area of improvement.

The solution’s security and performance could be improved.

They need to work on the third party integrations.

VNet integration facility is only available in the premium version so that is a drawback.

Microsoft Azure API Management needs to improve stability.

There is a limitation of 32 kb of data in the APIs. Having the limitation increase would be a benefit.

The product needs to introduce a developer portal.

There is room for improvement in the user interface and workflow for hosting APIs, especially third-party APIs. Another area of improvement is the pricing model. The solution has an add-on cost, and if we want to leverage some of the features, we are forced to buy it. So, cost-wise, it's not ideal.

I'm not sure if there are certain areas needed for improvement. I haven't explored its shortcomings. So far, the requirements have been met. Maybe the customization could be a bit better. My team found difficulty in migrating APIs from one platform to this platform. We could export and import properly. We made a complete API for a UAT environment, and when we moved the APIs, we ran into issues. They don't have a standard local IP. They only have a public IP.

When comparing the API Gateway of Microsoft Azure API Management with those of Apigee and Vital Mikram, which are other API management solutions, I prefer, Vital Mikram, the others are similar. I would like to see more integration with other platforms, as well as increased security.

We need better integration with VNet. It would be nice to not only configure it through the interface but also with an ARM template or something like that. Maybe it's possible, but it's not that easy to find. It took us time to get used to the interface. Now that we run it, it's a little bit hard to have a testing environment and the production environment and keep it synced. If you can do that through a script, that would be far easier. However, there was a time thing on our side. We couldn't get it done, and in the end, we just set it up manually. The licensing tiers can be misleading. It would be ideal if there was a way to add monetization into the mix so that we could more easily sell our APIs.

The API gateway can be very complex. We had difficulty managing end users for a very, very complex project. I am not sure that another API gateway would have better handled this difficult project.

An area for improvement in Microsoft Azure API Management is deployment, in particular, the deployment of versions in Oryx. The development to production instance isn't adequate for me and needs to be improved. To explain further, the specification for the API needs to be deployed from development to production through scripts, and the scripts need to be done manually or need a lot of manual intervention. The process isn't automatic or click-and-point, so you need a technician. Microsoft Azure API Management lacks automation, which is another area for improvement. In the next Microsoft Azure API Management release, I want to see the automatic deployment of its versions.

In terms of the flexibility of API Management, it's quite a complex solution when compared with Apigee. If they could come up with an easy way of enhancing, that would be a great help, particularly for those consulting.

API Management's price could be lower.

It would be better if it were easier to transition to Azure from JIRA. For example, there are different nomenclature that must be addressed when you shift to Azure from JIRA. JIRA's storage, tasks, and epics are treated differently from Azure. Here they might become functions, which is not an option in JIRA because that nomenclature difference is there. JIRA has sub-tasks, but sub-tasks don't exist in Azure. The nomenclature and the linking between Epics and a function and a story are different, and people may have to learn to adapt to the new nomenclature.

What would make Microsoft Azure API Management better are more APIs. They keep updating their APIs, but it would be better if the solution had more APIs for the services and more integration with other platforms.

The scalability of this solution could be improved. The volume which the API Management task service can handle needs to be improved. Cost wise, this solution could be optimized.

In the next release, Azure APIM should include deployment in various environments and CI/CD for deployment. They could also improve their access management portal.

Microsoft Azure API Management's most valuable features are the microservices we used to use. They were API callers to receive communication with the network and building system, to complete the request. The response would be through the processing system.

Azure API Management could be improved with better integration with all of Microsoft's tools. They should also provide basic cybersecurity tools in the package.

An improvement would be to provide more information about additional prices and the onboarding process.

I don't really have anything in mind at the moment in terms of areas of improvement. It does what we need it to do for the most part. Technical support could be more helpful and responsive. They are quite slow. The documentation around the solution is lacking. Users will need to do a lot of digging and googling in order to get the answers they need. The premium version is very expensive.

Microsoft Azure API Management should have the ability to allow multitenancy. While the solution works well for us, I would like to see simple or integrated reporting built into the solution. There is always room for improvement.

It could be more user friendly for developers. It would be nice if developers could view things more easily.

The only complication I encountered was configuring the authentication in the API Management. That was a little difficult for me, but it gets better after that. I could that the UI could be improved. All services have the use of Visual Studio to do the coding and to change the configuration. It would be beneficial to include that with Microsoft Azure API Management.

One thing that could be improved is to remove the dependency of Kubernetes as an external L4 load layer balance. It would also be useful if APIM could integrate internally with Kubernetes right out of the box.

Microsoft Azure API Management could improve by having better integration with third-party solutions. In an upcoming release, there should be more focus on API lifecycle management, such as MuleSoft provides and the API gateway is not comprehensive enough, we need to put a lot of extra effort doing manual work.

The licensing fees should be cheaper.

If I compare this solution to others I have used in other phases of my life, having APIM being an Azure resource, it is easy to configure and deploy. However, this conversely reduced the flexibility. The difficulty is how do we configure it in a manner that a larger enterprise would probably want it to be. This creates a bit more complexity, working around the constraints of the resource itself. If comparing it to other solutions, it is more of a legacy design with an older approach. The various level components are still around resembling an on-premise type of design similar to other solutions, such as Apigee or Mulesoft. They are still predominantly carrying some legacy design. Which might be suited for organizations where they have a more complex network layout. APIM is easy to deploy, but on the other side of that, it is constrained to how Azure has designed it to be. In an upcoming release, if not already added through an update, I think dynamic provisioning of the resource would be useful. Many times these API platforms, including others, such as Apigee, are still predominantly revolving around developers. The onboarding and the API life cycle are still revolving around humans. In this context, I would not suggest DevOps, but at least automation of common pipelines. If the platform can better support this in the workflow to provision and commission an API that would be beneficial as we work towards a more automated deployment concept. Even though there are templates, graphics, and API management commands right now, you are still in a way programmed deeply, customizing that workflow, as opposed to it being part of the platform itself.

From my understanding, there are some constraints around governance and service-to-service intercommunication managing priorities and our own governance. Examples include, how you manage all your clusters, the entire service communication, and having more tolerant experts.

The lack of wording in the API could be improved. In the API you need to delete the suffix. It is annoying that you need to have a suffix. We can add a suffix at the API level, not at the operation level, and that could be improved on. There are a couple of features that are lagging.

The developer portal can be improved. There should be more resources available for the developers. Better integration with third-party products would helpful.

We haven't used API model that much, so I'm not in a good position to say recommendations as we are still exploring the Azure API management. We need more time to fully take in the solution before pointing our its flaws. The documentation could be improved for the customer. The instructions on the district API and the initial stages of working with the solution need to be documented better so that users are more informed and they can have an improved experience.

Pricing is definitely an aspect that can be improved. They should offer an additional free tier. For example, if there was a tier for new accounts created, it may help their services by getting people onboarded. Once you will give access to someone and they try it they'll see, "Okay, it works and you can pretty quickly add something on top of it". After that, the client will end up staying, and probably paying. The cost is also complex in terms of calculating how much everything will ultimately be priced at. It's not straightforward as it takes into account multiple factors. Technical support could be more flexible and try to meet the client's needs a bit more effectively. The solution needs to provide more use cases so that we can refer them to clients. It will help answer any questions in relation to performance and load management.

They should improve the inbuilt policies that they have and that should properly create a deployment architecture as well.

They're trying to implement versioning and trying to be able to manage different versions of your API all at the same time, but they're not doing that just quite right yet.

Other products offer more customization options.

There is always room for improvement. There should be more analytics abilities so you can know how much traffic there is. Log Analyzer isn't well integrated with this solution.

In terms of improvement, it would be helpful if they could develop an on-premises option.

R&P, the publishing process could be improved. They are currently restructuring it, I believe. I'm not technical but we noticed that the old developer portal got deprecated and they're introducing a new one. It's not polished and still requires some development. It's the same with the publisher portal which I believe they've now integrated into the Azure portal. They're just starting to work with hybrids so it still requires input. It would be helpful if they were to include additional features and clearer configuration when it comes to API policies.

The portal where we publish the APIs could be improved. Maybe this is because we didn't configure it. It is quite easy to bypass API management because we have a lot of information shared on the portal, where we publish our APIs. I worry there is potential for a security breach in the API publishing. There needs to be more security available on terms of the way we publish them.

Nothing in specific but there is always some improvements that can be made to user interface to enhance and improve the UX experience. As Microsoft adds more an more services to the stack will help and enable to ease the API platform integration with other ERPs and various platforms for us. There are more APIs coming out with lot more enhanced services that include IOT connected device integrations. Any help in understanding available API protocols and edge protocols easier will help us building our solutions faster. We do see different services are being added day by day. We are not using all of services at this point, but we are leveraging few at a time and building our solutions. This is part of the evolutionary and exploratory based journey to transform the ecosystem of the customer to a digitally connected growth organization.

This solution is only available as a cloud-based deployment and it would be very helpful to have an on-premises version. This is driven by the fact that some of our clients have specific requirements and they do not want to be on the cloud. I would like to have an administrator's option that shows me API usage and can generate bills that I can send to my customers. Currently, our customers can see the usage but not how much it is going to cost. For example, assume that you get 100 calls for free and then 100 more free each month, but after than, each call costs twenty cents or one cent, whatever the price is. The administrator can generate reports when the bills are available and can charge them to the customer. This could be done with a monetization module, which would be better than the manual calculations that we have to do now.

The API management has come a long way. Would like to see better scalability and performance. Performance is important for us.

Multi-tenant functionalities is missing from the system, especially when it comes to purpose specific requirements such as CI, branding, language, content structure. If you're aware of the details of API Management provided by Azure, there are two areas. One is for developers, and the other is for consumers. In order to support the best, or all the different use cases we have, the multi-tenant support would be appreciated.

The developer console for external users could be improved, especially in the testing site. I would like to see the security management for the APIs to be more granular.