There are a couple of ways to implement infrastructure as code and create Azure resource in an automated way. From Azure point of view, the most commonly known way is using ARM templates. Everybody who has worked with ARM templates knows that they're are complex to work with and impossible to debug, especially for larger deployments. Microsoft tried to improve the experience, by providing validation tools, but working with complex JSON structures remains like working with YAML, it's really hard.
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:
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 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.
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?
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.
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.