RX Patient Tools
Use these quick guides before reading the article, or return to them when you need help preparing questions for a doctor.
Dapr integration in the Azure API Management (APIM) service is now available. This new capability enables operations teams to directly expose Dapr microservices as APIs and make those APIs discoverable and easily consumable by developers with proper controls across multiple Dapr deployments—whether in the cloud, on-premises, or on the edge.
Since its initial release last year, Dapr has been helping developers build stateless and stateful applications with any language or framework. By codifying the common microservice patterns, like service discovery and invocation with build-in retry logic, publish-and-subscribe with at-least-once delivery semantics, or pluggable binding resources to ease service composition using external APIs, Dapr is quickly becoming the de facto runtime for modern, distributed applications.
The larger number of Dapr deployments across multiple environments also comes with the increased complexity of API management. Using the Dapr integration in Azure API Management announced today, users are now able to apply the self-hosted gateway feature of APIM to manage all of their Dapr APIs, along with other APIs, in a single interface. This allows developers to decouple APIs from their backend service lifecycle. The more than 50 built-in policy templates can quickly accelerate the API management with things like TLS connection termination, payload formation, throttling enforcement, and caching across their deployments via an always up-to-date portal.
Using API Management with Dapr APIs
To illustrate the Dapr integration in APIM, we are going to walk through the process of securely and reliably exposing a public API that allows users to invoke a specific method on a single service deployed in Dapr. This is a common service invocation scenario where users may have any number of Dapr services, but only a small subset of them need to be available externally.
APIM supports two other Dapr building blocks, pub/sub, and resource bindings. See our reproducible demo at the end of this page for an in-depth walk-through for each one of these use-cases.
API Configuration
To define an API you can use any of the formats supported by APIM. In the example below, we are using the OpenAPI specification format.
You can import this file into APIM using either the Azure CLI shown below, or the APIM service in Azure portal:
API Operation Policy
To integrate this API with our Dapr microservice we will use a simple policy. The APIM policies encapsulate common API management functions and are composed into a series of steps that are sequentially executed on each request. These policies can be defined inside of inbound, outbound, and backend blocks. To configure the “/echo” operation invocation to be forwarded to Dapr API, we will define out a policy within the inbound section.
The “<base />” element at the beginning in-lines all the policies defined higher up in the chain at the API or even APIM service level (e.g., throttling or authorization). Placing that element before all others ensures that APIM evaluates it before forwarding the invocation to the back-end service.
Routing the inbound request to Dapr is as simple as setting the backend service using “backend-id” attribute to “dapr” that tells APIM to forward the invocation in its original format to the Dapr API implemented by the Dapr sidecar container running alongside self-hosted gateway. The “dapr-app-id” and “dapr-method” attributes allow us to set the Dapr application ID and method name where we want this API invocation to be forwarded.
The entire service discovery and actual invocation, including possible protocol translation between HTTP and gRPC, retries, distributed tracing, and error handling, are all done by Dapr. And since the external mapping of the API user invocations to Dapr is done in APIM policy, it can be easily and safely remapped to any other version as the API implementation evolves over time.
As that service evolves and potentially has additional versions, which may require different payload formats, APIM can manage the entire process through either its revisions, for non-breaking changes, or versions, in cases where API consumer opt-in is required.
Self-hosted Gateway deployment
To enable APIM to manage the APIs exposed by your Dapr services you will need to deploy and configure the self-hosted gateway into your Kubernetes cluster using these steps. To enable Dapr support in the gateway, you first augment the Kubernetes deployment template with a few Dapr annotations:
These annotations tell the Dapr control plane to inject a Dapr sidecar into the APIM gateway pod, which gives it the ability to invoke the Dapr API. To learn more about the Dapr Kubernetes sidecar configuration see Dapr docs.
The self-hosted gateway by default deploys two replicas to ensure availability during upgrades. Once ready, each replica will now have a second container (daprd) in the pod.
With the APIM gateway configured, you can invoke the “echo” service using the cluster ingress, while giving the operators the ability to manage their Dapr APIs using a single interface.
Give it a try!
This post only covers the service invocation capability of the Dapr integration with APIM. You can find a full demo repo with step-by-step instructions on how to configure this and other Dapr APIs integrations in APIM on GitHub. The complete reference of APIM Dapr integration policies can be found on the Microsoft Azure site. We are excited to see what you can build with this Dapr and APIM gateway integration. You can reach us either in the Dapr community Gitter channel or in our community calls.
