In the end of 2019 Microsoft announced a new feature in API Management (APIM) called self-hosted gateway.
We have tried it and here are our thoughts and conclusions.
Self-hosted API Management gateway overview
The self-hosted gateway feature is still in preview and available in Developer and Enterprise tiers at no extra cost during the preview period. The Development tiers is limited to one self-hosted gateway deployment for evaluation purpose.
This new feature extends the APIM support for hybrid and multi-cloud scenarios and enables organizations to manage their APIs from a single centralized APIM instance no matter if the APIs are hosted on prem or across different cloud instances.
The self-hosted gateway brings the possibility to deploy a containerized version of the APIM gateway component to the same environment as the APIs are hosted in. All self-hosted gateways are managed from one single APIM instance in Azure, the same instance as they are federated with to be exact. This gives organizations great value by providing visibility and a unified management experience across all gateways. API traffic can be optimized by placing self-hosted gateways close to the APIs. Self-hosted gateways make it possible to use APIM without requiring all API traffic to take the round trip via Azure.
Each APIM service is composed of the following key components:
- Management plane, exposed as an API, used to configure the service via the Azure portal, PowerShell, and other supported mechanisms.
- Gateway (or data plane) is responsible for proxying API requests, applying policies, and collecting telemetry
- Developer portal used by developers to discover, learn, and onboard to use the APIs
By default, all these components are deployed in Azure, causing all API traffic (shown as solid black arrows in the picture below Figure 1) to flow through Azure regardless of where the backend APIs are hosted. The operational simplicity of this model comes at the cost of increased latency, compliance issues, and in some cases, additional data transfer fees as an effect of taking the round trip via Azure.
Deploying self-hosted gateways into the same environments as backend APIs and adding them to the APIM service allows API traffic to flow directly to the backend APIs (shown as solid black arrows on the picture below Figure 2), which improves latency, optimizes data transfer costs, and enables compliance while retaining the benefits of having a single point of management and discovery of all APIs within the organization regardless of where their implementations are hosted.
The self-hosted gateway is a containerized version of the managed gateway that is deployed to Azure as part of the APIM service. It is available as a Linux-based Docker container via Microsoft Container Registry. It can be deployed to Docker, Kubernetes, or any other container orchestration solution running on a desktop, server cluster, or cloud infrastructure. The containerized gateway has almost equivalent functionality compared to the managed version in Azure.
Connectivity with Azure
In order to set up and configure a self-hosted gateway you need to allow for outbound TCP/IP traffic on port 443 towards Azure (seen as blue dotted line in picture above in Figure 2). Every self-hosted gateway must be associated with a single APIM service in Azure. A self-hosted gateway cannot be associated to multiple APIM.
This is needed for:
- Reporting its status by sending heartbeat messages every minute
- Regularly checking for (every 10 seconds) and applying configuration updates whenever they are available
- Sending request logs and metrics to Azure Monitor, if configured to do so
- Sending events to Application Insights, if set to do so
If connectivity to Azure is lost, the self-hosted gateway will be unable to receive configuration updates, report its status, or upload telemetry.
The self-hosted gateway is designed to ”fail static” and can survive a temporary loss of connectivity to Azure. The self-hosted gateway can be deployed in two different “modes”, with or without local configuration backup turned on. If local configuration backup is turned on, self-hosted gateways will regularly save a backup copy of configuration on a persistent volume attached to the container or pod.
When configuration backup is turned off and connectivity to Azure is interrupted:
- Self-hosted gateways that are running will continue to function using an in-memory copy of the configuration
- Stopped self-hosted gateways will not be able to start
When configuration backup is turned on and connectivity to Azure is interrupted:
- Self-hosted gateways that are running will continue to function using an in-memory copy of the configuration
- Stopped self-hosted gateways will start using a backup copy of the configuration
As soon as the connectivity with Azure is restored, each self-hosted gateway affected by the outage will automatically reconnect with its associated API Management service and download all configuration updates that occurred while the gateway was ”offline”.
Evaluation
In order to evaluate this new feature, we did the following set up and configuration:
- Created a local REST service (Weather Forecast service) and hosted it on a local server on prem using the IIS
- Published the Weather Forecast service in API Management (Azure)
- Provisioned a self-hosted gateway in Azure API Management
- Deployed a self-hosted gateway to Docker Desktop on a Local Server on prem (same server as used in step 1)
- Blocked all IP addresses to access the Weather Forecast service in the IIS
- Whitelisted the IP address used by the self-hosted gateway (IP for the gateway that was deployed in step 4)
- Associated Weather Forecast Service with self-hosted gateway
Standard set up
Figure 3 represents a sequence diagram showing the communication for a “standard” API Management set up where no self-hosted gateways are used. As shown in the diagram below each request made by the client is routed to the API Management gateway in Azure (as shown in Figure 1). In order to get this solution up and running you need to make sure that communication is allowed between Azure API Management and the Weather Forecast service on your on prem server. You are also depending on a working connection between Azure and the local IIS server. This set up is the most common configuration and enough for most of the use cases.
In our case this was not working as we blocked all IP addresses to access the Weather Forecast service in the IIS on the local server except the IP for the self-hosted gateway. This config made it impossible to access the Weather Forecast service via the Azure gateway as seen in Figure 4.
Calling Weather Forecast service directly
As above steps were not working we tried the next step, to access the Weather Forecast service directly (point to point). As seen in Figure 5 we ran into problems again, this tim a 401.503 error “Unauthorized” was returned. This error was intentional and completely by design to prevent point to point integration where API Management is by-passed.
Calling Weather Forecast service via Self-hosted gateway
By adding the self-hosted gateway to the equation, we were no longer exposed to failures in connectivity with Azure (same concept as shown in Figure 2). As the IP address for the self-hosted gateway was whitelisted in the IIS our requests to Weather Forecast service were successful when using the local gateway as seen in Figure 6.
This kind of set up could be very useful for on prem to on prem communication where the client and API are in the same physical network. Here it makes no sense to take the round trip via Azure, both from a cost perspective (related to traffic) but also for latency and overall performance perspective.
Summary and conclusion
We have tried the new self-hosted gateway and can clearly see some use cases where it brings great value to fill some gaps to achieve a more robust solution. The self-hosted gateway is a great addition to a very powerful product. This new feature is very useful when you still want to manage your APIs from a single centralized APIM instance in Azure no matter if the APIs are hosted on prem or across different cloud instances. The self-hosted gateway makes it possible to deploy a containerized version of the APIM gateway component to the same environment as the APIs are hosted in. This option is very useful for scenarios where you still would like to use APIM for all its benefits but cannot expose the solution to vulnerabilities caused by connectivity issues with Azure or when you cannot allow traffic to be routed outside of the local network due to security regulations.
Don’t hesitate to contact us if you want to know more or if you need assistance in evaluating if a self-hosted gateway solution is something for your organization.
