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.
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.
In a previous blog post I demonstrated how to create a multi-region setup for Azure API Management (APIM) using a Standard tier. There I mentioned Terraform as an alternative for ARM templates and in this blog post I'd like to explain how to create a full set of APIM resources using Terraform instead of ARM templates. Infrastructure as Code I suppose everybody working with Azure and automated resource creation is familiar with ARM or Azure Resource Manager templates.
Azure API Management (APIM) comes with different pricing flavors and different features per flavor. Most companies like to have the Premium pricing tier as that one supports more scaling options, VNET integration and multi-region support. However with a price tag of about USD 34000 per year it's also an expensive solution. It even becomes more expensive when customers learn that for each of the deployed regions of their multi-region solution, they pay an addional USD 34k.