This article is contributed. See the original author and article here.
As companies continue their cloud journey, they are more and more adopting a microservice architecture as part of their application modernization. In this blog post, we have Walter Oliver (@walterov) who is a Program Manager in the Azure Stack Hub team to explore how Azure API Management Gateway on Azure Stack Hub can help in the hybrid strategy for these services.
While some of the applications are being deployed on Azure, companies face challenges with operational consistency when it comes to those apps that must remain on premises. That is one of the scenarios where Azure Stack Hub (ASH) can provide the platform where to host their on-premises applications, while keeping operational consistency. Enterprises are increasingly using Kubernetes on Azure Stack Hub as their choice for their microservices, as they seek increased autonomy for their development teams, flexibility, and modularity. But the process of decoupling single tier monolithic applications into smaller API services brings new problems: how do you know what are these services? Do they meet the security requirements? How are they accessed and monitored?
Azure API Management (APIM) helps address these issues. APIM is part of the Microsoft hybrid strategy, it will help you in:
- Publishing a catalog of APIs available and control access to them
- Preventing DOS attacks for externally available APIs
- Implementing security policies
- Onboarding the ISV partner ecosystem
- Supporting your microservices program with a robust internal API program
Challenges to API Management on Premises
However, since the Azure API Management service is on the cloud, utilizing it implies a round trip to the cloud and then to the on-premises service to service every call. In some cases, this is acceptable, but in many it is not (figure 1).
Figure 1. API Management without self-hosted gateway
To solve it the Azure APIM team created the API Management self-hosted gateway. The self-hosted gateway, as the name implied, can be hosted locally in your data center (figure 2).
Figure 2. API Management with self-hosted gateway
Running the Self-hosted Gateway in Azure Stack
The APIM’s self-hosted gateway feature enables Azure Stack Hub customers (and customers in general) to manage their on-premises microservices APIs on a central portal in Azure. The self-hosted gateway is a containerized, functionally equivalent version of the managed gateway deployed to Azure as part of every API Management service.
Now you can deploy it inside Azure Stack Hub as a Linux -based Docker container from the Microsoft Container Registry. This means that you can hosted inside the AKS-engine-deployed Kubernetes cluster inside ASH. In cases where you have microservices APIs exposed to applications inside the Kubernetes cluster all the calls happen locally with minimal latency and no extra data transfer costs. More importantly, it also ensures that compliance is maintained since there are not round trips to Azure. Yet, all the benefits of utilizing APIM from Azure remain: single point of management, observability, and discovery of all APIs within the organization.
For complete documentation on AIPM self-hosted gateway see the overview here. To provision the gateway in APIM in Azure follow the instructions here. To deploy the gateway containers in Kubernetes follow the instructions here.
Considerations when running the gateway in Azure Stack Hub
- A common question is whether there is a need for opening ports for inbound connectivity, the answer is no. Self-hosted gateway only requires outbound TCP/IP connectivity to Azure on port 443, it follows a pull model, not a push model for communication. Connectivity is required so that information such as health reporting, updates, events, logs, and metrics can be transferred. This also implies that when there is no communication with Azure, the data does not flow, yet the gateway continues to operate as expected.
- When running the gateway container in your Kubernetes cluster with the configuration backup option, you will notice an extra managed disk being created in the cluster, this is the disk where the configuration backup is stored. This is particularly useful in case that connection to Azure can become unavailable. Notice that the gateway container is not meant to be run on an ASH stamp that will be disconnected from the internet or is planned to be disconnected most of the time. In fact, if the stamp is disconnected temporarily and for some reason the gateway container is stopped, Kubernetes will try to restart it but if the option of running with backup configuration was off, it will fail. In those cases, you need to ensure that connectivity to Azure is restored.
- Another question is whether that Gateway container automatically discovers the available APIs. The answer is that they are not, you must explicitly go to the Azure APIM portal and register the APIs you need to manage.
- In the case that you have APIs in another Kubernetes cluster (or anywhere in your data center) that you would like to manage you can publish them via the same gateway container or provision and deploy another gateway instance
- Deploying a new microservice and publishing its API or applying changes to an existing one is something that is better formalized in a CI/CD Pipeline. Getting familiarized with the available operations will be useful, see the reference here. For a guide on how to architect a CI/CD pipeline with corresponding repo see this blog.
Azure’s API Management service is very helpful for managing large microservices deployments, now the self-hosted APIM Gateway makes it very appealing for including APIs deployed on premises. The documentation provided online in Azure covers the basic concepts, provisioning, and deploying of self-hosted gateways, the summary provided above is an introduction to the subject tailored to Azure Stack Hub customers. Subsequent posts will include a sample deployment of an API and its publishing through APIM on Azure.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.