Azure APIM Self-hosted Gateway Misconceptions
In this post, I will share some of the misconceptions that I usually get from our customers regarding Azure API Management (APIM) self-hosted gateway, during consultation sessions.
First, let me start with a quick overview on Azure APIM main components and their functions.
Azure APIM main components
Azure Portal: The management plane to design, publish APIs and policies, as well as manage the APIM instance itself
Gateway: The data plane endpoint for the published APIs, it applies the selected APIM policies, and routes these calls to the backend APIs
Developer Portal: The user plane that allows developers to discover and learn about the published APIs
The following are the top 5 misconceptions that I usually get from customers about Azure APIM Self-hosted gateway since it was GA-ed over a year ago now.
Misconception#5: This is Microsoft’s on-premises platform for API Management
Many customers who have been assessing on-premises API management platforms, especially Microsoft shops and those who usually have performance and/or regulatory constraints, mistakenly think that the self-hosted gateway is Microsoft’s solution for a complete, on-premises API management platform which will be hosted, with all its components, within their organizations’ datacenters boundaries.
A self-hosted gateway must be associated with a managed API Management service on Azure. This feature allows for only the Gateway component to be deployed as a docker container to any environment, while the management and developer portal components will still remain on Azure.
Misconception#4: It is self-hosted, so it self-contained – no external dependencies
Following the previous point, the self-hosted docker containers will need frequent, although not necessarily continuous, outbound connectivity to the APIM instance on Azure.
This is mainly required to update the self-hosted gateways with the latest configurations published from the management plane on Azure, as well as for the self-hosted instances to send logs and metrics to Azure.
Although, technically, you can set the configurations once and then leave it running, using a backup copy of the configurations and a persistent volume storage for the docker container, however, I don’t think that this is a common case, as software solutions frequently require change, unless for trivial solutions.
Misconception#3: Azure APIM SLA covers the self-hosted gateway too
There is no SLA provided for the self-hosted API Management gateways. Unlike Azure’s managed APIM gateway, when you deploy self-hosted gateways, it becomes your responsibility to handle scalability, availability, and other operational concerns for them.
In typical production-grade solutions, you will probably need to use a container orchestration tool, such as Kubernetes or Docker Swarm to handle these operational concerns for the containerized gateway instances across a multi-node clusters in your environment(s).
After all, this feature provides you with “self-hosted” gateway instances and although it provides you with more control over these gateways, you also get more responsibilities when compared to Azure managed services. Therefore, these operational responsibilities shift back from Azure to the capabilities and commitments of your datacenters or those provided by the other cloud providers.
Misconception#2: It is self-hosted, so there are no additional charges
At the time of this writing, there is an additional cost to Azure APIM for the self-hosted gateway, it is calculated as a unit price per hour per gateway deployment. This is in addition to the pricing plan for the Azure APIM Premium or Isolated tiers, where the self-hosted gateway feature is available.
However, there is no additional cost for self-hosted gateways’ deployments when you use the APIM Developer tier for non-production workloads.
Misconception#1: I am getting 100% functionality of managed APIM gateway
Not 100%, but close. According to Microsoft’s documentation, self-hosted instances are functionally equivalent to the managed APIM instances, however, you need to be aware of some unsupported functionalities in the Self-hosted instances, such as, built-in caching, Azure monitor logs, among a few others. You can find the complete list of unsupported functionalities here.
Final Thoughts
Hybrid and Multi-Cloud environments, although cool buzzwords, should not be taken lightly, it should be truly justified for the solution’s context and trade-offs should be properly analyzed before committing to these environment setups. Further, these setups do not come without a price, one of which is the added complexity to the overall IT landscape and the accompanied operational overhead, with or without tools.
Azure APIM Self-hosted gateway is a powerful feature that enables organizations with a real need for Hybrid and Multi-cloud environments to have APIM gateway instances that are close to its environments’ API assets and consumers and thus improves the perceived latency, minimizes egress network traffic between environments, and possibly provide a disaster recovery solution for your gateway. Importantly, it provides a unified management plane for a consistent governance and experience over your gateways spanning these environments.
It is also important to highlight that Azure self-hosted gateway was not designed to be deployed in a self-contained manner in given environment. As mentioned earlier, the self-hosted gateway relies on a managed API Management service on Azure, so if you just need an on-premises API Gateway; then you should look for one among many of the powerful API Gateway platforms available that were designed to be hosted in your on-premises datacenters.
Finally, the beauty of cloud platforms along with their wide range of available services, is that you can start small and gradually adapt to your solution as it evolves. When compared to your own datacenters deployments, cloud platforms allow you to easily provision what you need, when you need it. The good old YAGNI principle holds here as well.