Actually most of the work in Projects these days are managed via the use of APIs. However the security and management of APIs is a key aspect which is being done through Azure API Management or shortly APIM. Mostly it is used across the organizational levels. Through Azure API Management, we have mostly integrated different kinds of APIs right from Agricultural based APIs to Banking and Finance data APIs.
Pros
Management of APIs
Security of the API through Azure AD, AD B2C etc.
Providing an outer layer through APIs
Cons
The rate-limit-by-key policy need to be properly adjusted to maximize the benefits
Likelihood to Recommend
Wherever we want to maintain the security of the API and the ingredient data is very confidential, we must use this service. Also, if we would like to manage a large number of API at one go, we must use it. However, for few general APIs, we can avoid the Azure API Management use due to the overall cost strategy.
VU
Verified User
Professional in Information Technology (10,001+ employees)
We use it for letting teams access synchronous services and microservices both for internal and external network users. It's extremely simple to make an API available. We can build infrastructure and APIs using Terraform.
Pros
Easy commissioning of APIs.
Great policies to control access.
Easy mock services for testing.
Cons
We cannot automate the network infrastructure easily. At least we had issues with creating end to end APIM using Terraform.
Likelihood to Recommend
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.
We are lightly managing and pushing out a few APIs to internal customers using Azure API Management. We are exploring pushing them out to a few of our external partners, but have not done so yet. It is a small catalog of APIs we are managing, but they work well and are easier to keep track of with this tool. It helps keep our policies in order and therefore users know what to expect.
Pros
The policy management process is very good. Without solid policies, you run the risk of poor performance or miscommunications. We’ve been very successful with our API catalog as long as we maintain solid policies.
Along with the policies, the security is very easy to manage, and you can control things from a simple Azure dashboard, including groups and levels.
The seamless connection to Azure App Service and Service Fabric is a great bonus, as everything is kept within an easy to manage portal with a common look and feel.
Cons
Lack of robustness is a bit of an issue. Several other providers offer more options and capabilities, but then, they are lacking in interface ease.
As with anything Azure, pricing is really hard to stay on top of. I always find that you really don’t know what you’re paying for until you get the bill. Having an excellent Azure Administrator can help resolve that.
Integrating with app services outside of Azure can be a challenge, or at least much more challenging than just using Azure App Services.
Likelihood to Recommend
If you are an Azure Cloud shop, or are moving in that direction, this is a great tool to start using. You can try with a few small APIs; we began with building some internal APIs that allow us to connect some of our SQL DBs to the Azure Maps service, and we had great luck and things have been running smoothly for six months now. We are expanding the use internally and looking to expand further to external partners as well.
VU
Verified User
Manager in Finance and Accounting (10,001+ employees)
API Management is being used to externalize, modernize, and secure our API set. As part of our strategy to open up and integrate more with our clients and patients we chose to leverage API Management as our main gateway to health data and submission of orders. API management takes away a lot of the headaches associated with externalizing web services and API sets. Things like versioning, enabling both XML and JSON even though the back-end service is only XML, providing a developer portal and subscription keys... there is a lot more that makes this well worth the costs.
Pros
Developer portal - while a little rough around the edges, it works well and provides a tidy UI for externalizing your APIs. Developers can register themselves and request and manage subscriptions to products/APIs. The site is customizable too - though that process is a little cumbersome. The sign-up process even has customizable email templates for verification.
Flexible - there are a lot of customizations that are possible through the use of API policies. This could be transforming XML to JSON or vice versa, modifying headers, restricting parameters, redirecting to different end-points depending on the message body... the sky is the limit as to what you can do.
Management - the structure of how APIs are managed is well thought-out. It makes it quick to start standing up new APIs and versioning them. Additionally, the analytics provided are also very helpful in diagnosing possible bottlenecks or unusual usage.
Cons
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.
Likelihood to Recommend
<div>APIM is useful for the standard scenarios:
</div><div>1) Securing your back-end APIs - If you have a legacy back-end web service that has a basic authentication scheme, you can add some additional security by placing APIM in front, and requiring subscription keys. Leverage your existing firewall to ensure only your APIM instance can communicate with your back-end API, and you've basically added a layer of protection.
</div><div>
</div><div>2) Lift and shift - there are always going to be clients that don't want to update their clients to use a newer API; in some cases you can make a newer API look like an older one by implementing some complex policies in APIM. You can also do the opposite, making older APIs look new, such as making an XML back-end accept both JSON and XML.
</div><div>
</div><div>3) Centralizing your APIs - if you've acquired another company and want to make their API set look as if it's a part of the larger whole, APIM is an easy way to provide a consistent front-end interface for developers.
