Azure API Management caching catch

It's a best practice to store secrets in Azure Key Vault, and when you need them in an Azure API Management policy, we use managed identities. Accessing Key Vault to read the secret can be simply done with this piece of policy: <send-request mode="new" response-variable-name="keyvaultResponse" timeout="20" ignore-error="false"> <set-url>https://didago-kv.vault.azure.net/secrets/my-secret/d24b7ce4e3a54343b9cf0da3b6bfe156/?api-version=7.0</set-url> <set-method>GET</set-method> <authentication-managed-identity resource="https://vault.azure.net" /> </send-request> The response contains the secret and can be read and stored in a local variable like this:

Azure API Management debugging policies

During Integrate conference about six months ago, Microsoft showed us the work they had been doing to add debugging capabilities for polices in API Management. This was in private preview back then, but at Ignite earlier this month the public preview was released. So why is this such an important capability? One of the main issues with SAAS services in general is, although you can extend the functionality, that code is difficult to diagnose issues.

Azure Event Grid solution design for high availability

Azure Event Grid is in many companies the backbone of their event driven architecture. When you have users from all over the world and cannot afford outage, then you need to design for high availability (HA). You can implement HA at many levels. From having multiple copies in a single data center all the way to copies across regions and even continents. The bigger the distance between the copies, the lower the risk of having an simultaneous outage due to for example a natural disaster.

Azure Functions and deployment slots

In a previous blog post I discussed deployment slots for Azure App Service. A great way to be able to do A/B testing and to achieve zero-downtime deployments. However back then this didn't work for Azure Functions. The portal for Azure Functions was very much different from App Service and support for deployment slots was not fully implemented. This screenshot is just from a couple of months ago, but still remember this one?

Azure API Management self-hosted gateway

Shortly after Microsoft acquired Apiphany, which we know as Azure API Management today, I was working at a customer with Apigee, which is owned by Google today. Back then, Apigee was way ahead of APIM in functionality and one of the interesting parts was their Edge microgateway which could be installed on any device. At the London conference Integrate 2019 Microsoft announced they were working on a similar thing and in April this year Microsoft GA-ed the Self-Hosted Gateway.

Strategies for deploying versioned API's

There are many blogs discussing API versioning, but most of them focus on the way it is visible to API consumers. Regarding that, in the end it all boils down a kind of to personal preference and you'll end up with either: URL versioning (https://api.company.com/v1/controller or https://api-v1.company.com/controller) Query string versioning (https://api.company.com/controller?version=v1) HTTP Header versioning (api-version: v1) You can find a recent blog about this here. However, I'd like to focus on what you want to achieve with versioning and what that means for your code and deployment strategy.

Deploying Azure API Management using Pulumi

If you follow my blog you'll have noticed I've been playing with Terrafom a lot lately. The main reason is I like the infrastructure-as-code approach and because it solves a couple of problems I experienced with ARM templates. I cannot say Terraform is the holy grail, but a lot better than ARM in my view. Recently I a colleague pointed me to a new kid on the block: Pulumi. A big difference between Terraform and Pulumi is the fact that Pulumi really is infrastructure-as-code.