Microsoft Azure API Management Reviews

They're doing integration work between a lot of different on-premises business platforms, like Salesforce and NetSuite. We're doing integration work, but we're putting all of our APIs into the Azure cloud and using that API manager at this time.

We're pretty much using all of the monetizations features out of the API manager so we can put up a portal and have a dev portal and then a prod portal and do rate limiting.

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.

I have been using this solution for a year. 

We haven't had any issues with stability. Those things are pretty solid.

I haven't dug too deeply into how to scale it yet. My current customer doesn't have a high volume of stuff yet.

In terms of users, there are only two or three of us engineers that deal with it directly. We're running several dozen APIs that are production APIs.

I give technical support a solid B rating. They're not bad on doing support at all. They're not necessarily fast, but they're not bad.

It's very straightforward to set it up. It really is. That's one of its strengths, that it's very easy to get started.

The versioning makes deployments more complicated than you would like, so you have to build some of your own toolings.

Licensing is the tricky part. For Azure, if you have your Azure subscription, the API Management is a free tool. There's no extra cost for that. 

My advice would be to choose wisely. Look around. That's the free entry stuff, so that's why I'm kind of looking around for another tooling solution, to see if I can get more full-featured support.

In the next release, I would love to see them actually support out of the box, like a canary deployment pattern, or out of the box just a blue-green rolling deployment pattern. Right now, how you want to do your deployments, you've got to tool it yourself.

I would rate it a seven out of ten. They're not bad.

The integration with Azure Active Directory is a good security feature for authentication and authorization. There is multifactor authentication. You can also use all of the Azure AD features integrated with API Management. 

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. 

I have been using this solution for two to three years.

It's on the cloud, we don't have any hiccups or problems with the stability. 

The technical support is pretty good. Sometimes it's slow. It depends on each case. Sometimes they need to engage with the US and there's a big time difference between there and Australia so it takes longer. 

Our public APIs are mostly in Axway. B2C APIs are a combination of Azure and AWS. Cost is a big difference. Axway offers two solutions. One on-prem and the other option is cloud. It's not a SAS solution, they host us in AWS but we can push the costs for version upgrades. It's much more expensive than Azure or AWS.

You have to read about how to do it four or five times and then you can implement it. It's a publicly accessible API so it needs a security layer and then you can secure it. Otherwise, anybody can access it. You need proper controls, authentication, and authorization. You need to sort this out first. 

I would recommend doing a combination of AWS API Gateway and Azure API Management. You can authenticate APIs in Azure Active Directory and from there you expose all of your serverless components and use them as a backend with Azure. But it depends on what your use case is. It can be used as a combination or as a standalone. 

I would rate it an eight out of ten. 

To make it a ten, there should be better analytics features so we can know how our product is performing. 

It's more of a subscription driven consumption based model, where the APIs are developed to connect backend ERP systems such as SAP and deployed into a library for consumption by both internal and external consumers. The APIs are exposed to the consumers that get onto the API gateway and identify the needed API from the library, use the instructions to subscribe, quickly test and connect to the backend SAP to get the expected information/transaction processed.  Prior to this solution there was an age old EDI interface solution.  This is enabling the customers to be more flexible with their integration architecture and be more agile as it reduces the IT integration dependency and provides a better user experience.

This is part of Techwave application modernization strategy to bring solutions that can bring agility and flexibility to customers and be able to decouple business with huge IT dependent solutions.  This is helping us to help our customers migrate away from the age old EDI technology to the latest API and microservices based architectures.

It is enabling two things. First it is helping our customers get on the path of application modernization and be on the digital journey.  Secondly, it is enabling them to provide a better customer experience and adoption with their end consumers. 

The consumers have easy access to information than before (when it was EDI based processing).  Consumers had to reach to their IT for any new changes and integrate and/or had to download/email/phone to access/process the transaction with their customers.  Now it can be well integrated into their portal applications and/or integrated directly into their applications through API management, which makes them more digitally connected and better user experience.

The most valuable features are the ease of use and the self-enablement through subscriptions for our consumers. Consumers can get into the API gateway library and register to an API from the catalog directly. 

Once the API is developed and added to the library with the registration documentation, it becomes pretty easy for consumers to access and understand the benefits and use of the API.  

The library acts as the central repository of all our APIs and use and access is pretty intuitive.

It's very easy to learn for a person not familiar with API.

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.

I have been using this solution on a particular engagement for close to a year now.  However, we at Techwave have been using API manager in other areas as well for some time.

As it is a SaaS model, we always end up having the latest version in use.

The stability is great, as mentioned earlier it is backed by Microsoft Azure platform and that brings good stability as it is and being the cloud solution we do not have to worry about scaling either.

Monitoring of the usage and understanding the throughput is much easier with these API platforms than with the older EDI transaction based backend operational monitoring. The visualization reports on consumption is very easy and the analytics driven from these visualization can be used in your ROI discussions and management decision process, if needed.

This is a scalable solution and my impression is positive. Consumption is increasing. The scalability doesn't seem to be a challenge because it's a cloud-based solution. Scaling the bandwidth or the capacity is not going to be a challenge.

Our customers are using this solution and I can't disclose the number of users, but we have good usage.

We provide technical support and haven't gotten to a point where we couldn't solve an issue.

We have not contacted the Microsoft technical support yet. I am sure that they would be good but we can't comment in that area as we have not been in that situation.

In this particular customer, they were using EDI-based transaction processing. We have been able to transform them into the API journey.

EDI technology is of the past and API is the modern technology that has been leading in the digital transformation, enabling them to have consumption across various platforms. Whether it's a cloud, on-premises, or an applied solution.

Because we are trying to move away from the EDI, the initial setup wasn't that complex. The interfaces were already there in the EDI. This engagement is more to transform existing EDI-based approach to an API-based one. The business logic, more or less, is there. This initiative is more to help us decouple technical stack from the business process.

The API manager is managing the business interactions, whether it is the consumer onboarding or the customer decoupling them from the IT based EDI processing. 

The EDI would require that the customer technology team and the company technology team communicate and work together to integrate the interface. Whereas here you don't need to worry about it. It's simple as a business consumer signing up for an API, and all they need is a link to click and get the URL into their space and then they are done.

It's an easier way to integrate their API. If you want to make it into a more robust application, that's a different process, but consumption-wise it's easier. 

For those who do not want to integrate it into their applications, we have been giving them an application that they could just install from an App Store on their portal. This application will then expose the APIs available for use.  All they need to do is subscribe and get going.

Implementation was pretty simple in this particular engagement. We had a vision of how the API is going to be consumed and how many were needed. We paced ourselves in an agile model with a simplified storyboard and a proper velocity mapping of the activity.

It took anywhere from three to four weeks for each API to get them ready and we took it at our pace. We had released approximately ten API's in less than six months.

We had a six-member team for deployment, including the BA and project management. In the post-deployment, we only need three people to maintain.

We implemented this solution for our customer as an implementation partner.

We have not yet measured the ROI on this engagement yet.

It's being paid monthly.  It is comparable and falls in the mid range in the competitive landscape.

We have evaluated WSO2, APIGEE, MuleSoft with API Manager

API and microservices based architectures is the modern architecture to enable organizations for digital growth.  With that said Microsoft Azure is definitely is in the top quadrant in this space and are investing to grow this service portfolio by leaps and bounds every day.

Based on our customer ecosystem and the predominant technology stack in use, the decision with Microsoft platform aligns well with their transformation roadmap. There is going to be some level of Microsoft cloud solutions in play. 

Each customer has to conduct an assessment on the need for a platform based on the technical debt they are carrying along with people and process.  They need to take a look at the existing ecosystem, software technology stack, current ERP, and the applications that need to be integrated into API based platforms. 

I would suggest Azure API Manager should be in your selection process.

I would rate this solution a nine out of ten.

Our primary use case is for managing internal APIs, for ordering process APIs and in general process APIs, and resource manipulation APIs. We need an API management to get a better overview, and this is one use case with analytics parts. Another use case is security, being able to rotate API keys and to manage access at a signature point. Finally, we also have the developer portals with the self-service capabilities so that developers can request access to APIs through a developer portal and manage their own keys.

We are still in the ramp-up phase, so currently we have actively two or three guys using it. We're planning to increase usage. We're in partnership with Microsoft and I'm an enterprise architect. 

It's not the best product on the market which makes it difficult to pick a particular point that we like the best. It could be the integration in the Azure portal. In the Azure cloud it's directly connected with Azure ID, so if you stay in the Azure ecosystem, this user concept is an advantage. The solution also allows you the possibility to use VPN technology and things like that to connect your gateway directly with on-prem services and that's a valuable feature. And compared to other solutions the price is outstanding. 

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.

I've been using this solution for seven months. 

The SaaS offering is stable but the hybrid isn't stable yet. It's under development.  

By definition it's scalable, but I know there's a hard limit in requests per second. But this is officially documented in the price of the product so it is scalable but with limits. I believe for a scalable solution, probably KANN Enterprise would be best.

For beta, customer service was kind of difficult. But I think that we haven't gone further than the first level. It's a process, they first have to narrow down your requirements, it's not direct access to support with direct feedback. It will take time. 

This is the first solution we evaluated and we chose it mainly in order to gain experience which is why we called it an experience project rather than a proof of concept project. We figured out that for our productive usage, we will select a different vendor.

I believe the initial set up is straightforward via the Azure portal. But setting up the policies for the APIs and all of that, I can't say. I've had feedback from a colleague working with it that at some point he wished things would be easier but I don't have first hand experience. 

As mentioned, this is the only option we looked at. We chose Azure because it's easy to deploy and it's cheap. It's a good starting point and if they develop it further, it might be good for productive usage, especially if you are planning to use it as an API management platform for the services that are running in Azure. I think then there's no question.

I would rate this product a six out of 10.  

Using an API management tool was new for us and it's definitely brought us a lot of value since implementation.

The way the solution integrates with other Azure services is its most valuable aspect.

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.

We've been using the solution for three years now.

The solution is quite stable. We have no issues with it. there have been no crashes and we haven't experienced bugs or glitches. It's been quite reliable.

The solution is totally scalable. If a company needs to build out the solution to expand it, they can do so easily.

Support is very good. We have a direct line of contact with Microsoft product management's technical support. Contacting Microsoft has been very easy. It's perfect.

I did not participate in the installation. However, from the information I have received, it was quite difficult. It wasn't difficult because of the solution itself but because, for us, it was a totally new solution. We had no experience with it. If a company has a lot of experience with Azure API Management, it would be rather straightforward.

The pricing of the product is reasonable. It was one of the selling points for us when we were looking for a solution for our company.

We did evaluate a few other solutions before ultimately going with Microsoft. We looked at MuleSoft, for example, but it was a totally new environment for us. Another solution didn't have the level of maturity we wanted in a cloud product. Microsoft was also new, however, we had a lot of contacts there and we had all of their interfaces. After looking at the pricing and features, it ended up being the best option.

So far, we've been very happy with the solution.

I'd rate it eight out of ten overall.

We are publishing microservices using API management. We have created various packages and policies that we are applying over there. We have also created a portal for developers so that they can see what we are doing.

The most valuable feature is the developer portal, which has source code examples in various programming languages to help developers learn the API.

It is possible to combine APIs and make a new product, which is a very good feature.

It is very user-friendly and easy to use. 

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.

I have been using Azure API Management for almost one year.

I think that this is a stable solution.

Microsoft handles the scalability so you don't need to worry about it.

Microsoft's technical support is okay. On a scale from one to ten, I would rate them an eight.

Your first response will be fast but after that, it will be slow. Then, the technician might just say that they are not the right contact. From opening the ticket until final closure will take time. Generally, it takes the experts some time to comment. Unfortunately, everywhere is like that.

We did not use another API management solution prior to this one. We were developing applications and then moved into APIs.

The initial setup is very simple. Within a few days, one can understand completely how to use it. It does not require deployment because it is available on the cloud and everything is ready. In fact, there is no installation at all.

It will take some time to onboard your API and define your policies, such as those for security. It should take about ten minutes to get up and running.

We considered other options; however, our client is mainly a Microsoft shop and they were already using Azure for various things. As such, we did not fully evaluate other options. 

This is absolutely a solution that I would recommend for others.

I would rate this solution a nine out of ten.

We use the product for managing APIs - for internal as well as for external communication.

Furthermore we enable transparency, governance and re-use.  

- Being a PaaS component it helped reducing maintance efforts
- Homogenous solution for information exchange between internal and external stakeholders 

The most valuable feature would be the easy integration into the entire Microsoft environment, like Access Directory, the collaboration tooling, the development tooling, basically the integration into the Microsoft universe.

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.

I've been using the product for about three years. 

The product is stable, it's good. It depends a little bit on the tier, on the different settings, and different customizations that are possible. But in general, it's a stable solution.

Technical support to a certain extent is good, it's available in the internet, if you wish. The moment you need to reach out for serious technical support in terms of incidents, or on-site support, or whatever, it becomes a little more challenging.

The initial setup for us was easy. It helps that we have Azure knowledge within the company.

Understand the different Tiers (from small to large including VNet-integrated express route)

Start small and be aware that the developer version has all features enabled which also requires the highest possible Tier.

Approach API Management in the two areas "tooling" and "governance".

Tooling required end-to-end thinking from a developer, consumer and infrastructure perspective. For each multiple examples can be shared.

For governance start with the obvious fitting to your organization. Do not follow all recommendations from the start, hence expect an iterative approach.

I would recommend this product and would rate it an eight out of 10. 

We use the cloud model. Our primary use case is for integration between different systems. There are many use cases for the API management tool, but the most common scenario is integration between different systems.

The ease of setting up a new solution is the most valuable feature. It's very easy to set up a new solution and to deploy it to production.

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.

It is very stable.

It's quite scalable. We've tested it in different little scenarios and it's quite scalable.

For deployment, I would advise a specialist. There is no need to dedicate any staff to the maintenance of the solution.

I would rate their technical support an eight out of ten. It could use a bit of improvement. 

I previously used RabbitMQ for another project. Both solutions have different approaches. One can work on-premises. On the whole, I still prefer is Azure API Management. I believe it's an easier solution set up and run.

The initial setup was very straightforward and simple. The deployment only took a few hours. 

I deployed the solution myself. 

I would recommend this solution to someone considering it. I would rate it a nine out of ten.