It is really helpful for managing [the] scaling of systems with need and utilizing resources when needed. Also, DevOps support for deployment plans is quite useful when deploying applications. Monitoring systems with graphQL and utilizing them in APIs is quite helpful when used in Microservices systems to identify system capabilities and user utilization of applications.
The range of policies that enable the APIs to loosely couple it with security, rate limit, retry, etc. are good. We can easily tie authentication mechanisms to external and other internal services without having to modify the backend.
Cost - the upfront cost is a bit restrictive. I've been told it is because there are a few underlying VMs that are running this service. So if you're just starting out with API management, it can be an expensive proposition. Value increases as you add additional APIs. If you're using Azure B2C for the developer portal, you'll require Standard or Premium since they support AAD integration.
Security granularity - at time of writing, APIM doesn't support breaking out operations to products. For example, if you have an API that has a GET and a POST operation, and you want the POST operation to require a different subscription. There is a work around, but it makes management a bit messy.
Developer and Publisher portal - it's a little weird. Microsoft hasn't migrated all the publisher portal functionality into the "native" Azure portal. So some of it feels a little weird - especially when working with the content management side of things for the developer portal.
Scaling - while it's easy to scale up, the cost of APIM ramps up very quickly. Standard -> Premium is a 4x jump.
Akamai [API Gateway] helps better in terms of representation of graphQL and its consumption in monitoring system making a package for deployment speed with monitoring and scaling application with all services and utilizing most of a system without much knowledge of other aspects. Also, [a] user-friendly system helps people to handle [the] system with necessary options
Decrease in time required for deployment and monitoring by significant amount causing less support resources needed
Scaling applications on month-end at high usage time has reduced TAT time for issues and no of issues occurring
Quota enforcement has allowed [managing] multiple systems and their needs in respective stakeholders hands and reduced infra teams involvement in [the] management of reoccurring problems
It’s really pay as you go, so it's not that costly to get in and try it out. There’s no expensive client to buy and manage, but you do need to stay on top of the rapidly changing Azure environment to be sure you upgrade or adjust when needed.
It’s not great having more than one API tool, but it’s ok to spread out your work, as you always want the right tool for the right job. For example, if you are a Salesforce-heavy organization, I’d go with Mule over Azure.
It was easy getting an external consultant access to the tool to build their own API for a project they were working on for us.
