Microsoft Azure API Management Reviews

We use this solution because when there is a technical requirement sometimes there are technical constraints that need to be overcome, and that is best resolved through the API component. My organization predominately uses Microsoft solutions and this is why we are using this particular solution.

I have found this solution to be easy to configure, simple to use, and flexible.

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.

I have been using Azure solutions for approximately four years.

The solution is stable.

The solution is scalable because it is a cloud service offering.

I have previously used Apigee and Mulesoft.

Since this is a cloud-based solution you have to abide by those financial limits, this creates some different challenges compared to other solutions.

My advice to those wanting to implement this solution is in all technology areas, each solution is use case-specific. If you are already working on the pure Azure Stack, then APIM is something that I would suggest. Unless you have a very complicated API development use case I would not try to deploy, for example, Mulesoft or Apigee on Azure. Assuming you are working on a full Azure Stack solution. 

Since it is use case-specific, rather than trying to build out. I would rather use the other repertoire of Azure to do the API development, as opposed to trying to deploy other solutions under the platform and develop from there.

My philosophy is always, use what is available, rather than trying to reinvent the wheel. Mulesoft may be powerful, but it is putting the cart on top of the wheel and try to build something on the cart. It is not a native approach.

I rate Microsoft Azure API Management a seven out of ten.

We primarily use the solution to manage our APIs.

The ease of use of the solution is excellent. It's a very user-friendly solution. 

The initial setup is quite straightforward. 

We found the solution to be very stable.

The solution can scale if you need it to.

Technical support is very helpful.

The solution has very fair pricing.

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.

I've been working with the solution for five years or so. It's been a few years at this point. 

We have found the solution to be quite stable. There are no bugs or glitches. It doesn't crash or freeze. Its performance is reliable. 

The solution scales well. If a company needs to expand it, it can do so with relative ease.

We have about 15-20 users on the solution so far.

Technical support has been very good. They are quite helpful and responsive. We are very satisfied with the level of support provided to us.

The initial setup is straightforward. A company shouldn't have any problems during the process.

The cost of the solution is very fair. It's not overly expensive. It offers very good value.

We are Microsoft partners.

I'd recommend the solution to other individuals and organizations. Overall, I've been quite satisfied with its capabilities.

I'd rate the solution seven out of ten.

We have company-wide APIs which are hosted in Niger, and some of the external clients access the applications via the API, and we provide the post-data information. The clients get their data from our larger API.

The way the API management handles the calls and call throttling is excellent. 

The API management and the hosting of the API platform are great.

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.

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

The stability of the solution is good. We haven't had any issues. I can't recall bugs or glitches. It doesn't crash or freeze. It's reliable.

The scalability of the solution is very good. If a company needs to expand it, it should be able to do so quite easily.

Currently, we have between 500-600 users in our organization on the solution.

We haven't really used technical support too often. Therefore, I can't really speak to their level of knowledge or responsiveness to issues.

We previously used IBM Open Shift. We switched due to the fact that the company was going to Azure and we didn't want multiple clients.

The initial setup isn't too difficult and doesn't take too long. You need to handle it to have the management gateway. Of course, every time it is deployed, then it needs to be configured to work with API. That could take some time.

For the deployment and maintenance, the size of the team you need depends on the project. We had a couple of developers on ours, for example.

I assisted with the implementation. I tend to handle it myself.

It's my understanding that the licensing is very clear. However, I'm not involved in it in any way, and therefore, I'm not sure what the cost structure is. 

We're just a customer. 

We do plan to continue to use the product going forward.

I'm not sure if I would recommend the solution. It depends on how their organization and architecture is, and if they're doing on-prem or cloud, depending on the requirement. It's very hard to say.

That said, I would rate it overall at eight out of ten.

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.

We use it to manage the API. We have a backend API with service in the backend. We use API Management in the front to manage the vendors. They can do their own testing. It's quicker for us to put in the specifications so we can knock off the responses. We build the specs and then get an external developer to start the development without the web service being ready. 

We also use it for the security and for the clock in features.

It's easy to use compared to other products. It's easy to set up.

Other products offer more customization options. 

I have been using this solution for six months. 

We haven't had any issues with it since we set it up. It's quite stable. 

We don't need to worry about scalability. We just use it. It works on demand because it's on the cloud. 

We are not a Microsoft shop, we just started using it. We haven't contacted technical support yet. 

I also used Tibco Mashery. There aren't so many differences. The biggest difference is that you can run it on-prem while you can't do that with Microsoft Azure API Management. 

The initial setup was pretty straightforward. It took less than one day, around a couple of hours total. It's pretty quick. I deployed it myself with some product documentation. 

You can't use this on-premise. If you want to run on-premise you would have to get a different product. Other than that, it's easy to use and start up. There is a lot of support available from the community online. You can do a domain name yourself with Microsoft, as opposed to other products where you need to contact support in order to set up a domain. 

I would rate it an eight out of ten.  

I can't give a ten out of ten because I'm not experienced enough with it. So far so good, though. 

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.

The tool helps to manage APIs. 

The tool does what it's supposed to do. 

The product needs to introduce a developer portal. 

I am working with the tool for ten years. 

The solution is stable. 

My company has around 20-30 customers for the solution. Each customer can have about 100 users for the tool. 

Microsoft support is good. We have regular sessions with Microsoft where we can have private previews of new features. 

The tool's setup depends. If you use it in the CI/CD pipeline, then the setup is complex. To deploy the solution, you need to create a template and enable the features. 

There are different tiers for pricing. You can even use the free version. 

I would rate the product an eight out of ten. 

I mainly use Azure APIM for access management.

Azure APIM's best features are its straightforward access management (it's a single point of access for all monitoring and logging and for policy implementation) and its integration with the Azure Cloud infrastructure.

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.

I've been using Azure APIM since 2017.

Azure APIM is pretty stable.

Azure APIM is scalable.

If your services are built on the cloud, I think APIM is the best tool. I would rate APIM eight out of ten.

My primary use case is as part of a multi-channel strategy wherein APIMs are being used with micro-products or third-party clients. Our web application firewall receives all the external and public traffic, and it re-routes to the APIM, which is on the private subnet. The APIM manages both in authentication and authorization service composition layer.

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.

I have been using this solution for around two years.

General support has been very good, but sometimes when immediate support is required, it isn't available.

The initial setup was quite easy as it is a managed service.

I used a managed service to implement.

I would rate this product as seven out of ten.

We have two approaches to how we use the solution. We own the managed services and the other we have customers take the subscription and we manage it. 

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.

I have been using the solution for approximately one year.

The technical support has not been the greatest. Microsoft has been outsourcing its support services and we have quite a few challenges in terms of technical support. We rarely asked them for anything and try to find the solution ourselves. This has been our most recent experience. However, there are certain advantages as well. Now you have a large internet resource pool to support Azure. This balances the support out, but otherwise, if you are looking for very specific support, there will be some challenges for your teams.

The initial setup is not that complex, but there are certain challenges.

We are limited to what choice of solution we can purchase. There are multiple aspects here. If it is a choice that we have to make, then we do it based on the requirement or recommendations, such as GCP, AWS, or Azure platform. However, given the present circumstances, the customer base that I am supporting at the moment is all Microsoft shop customers. Their inclination is always towards Microsoft-based solutions. That is where it has left us with no choice, but to go with Azure. While we still recommend this solution in some cases, for instance, analytics and where we need the big data solutions. We have been pushing for a GCP and in some cases to have AWS as well. For now Azure is the platform and this has been the journey that has left us with no choice but to go with it. Based on the resources that we are leveraging, the price we are paying to use this solution is slightly higher than other competitors. In a few cases, it has its own advantage in some resources. 

I have evaluated GCP and AWS.

I would advise those wanting to implement this solution that they can use this solution if it fits their deployment criteria. However, there are better options available.

I rate Microsoft Azure API Management a seven out of ten.