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.

In the world of web applications the principle of A/B testing is pretty common (https://en.wikipedia.org/wiki/A/B_testing), and for web API's this can also be used. Azure App Service has a facility called ‘development slots’ which can be used not only for zero-downtime deployments, but also for A/B testing. What is a deployment slot and how can it help with A/B testing? A deployment slot is a separate App Service resource hosted on the same App Service Plan.

You found me! Great, here I'll continue with my blogging endeavours. My older posts can be found here: jpsmit.bloggingabout.net. As much as I'm happy to find solutions on other people's blogs, I hope you can find some solutions on mine. Besides posting hopefully interesting content, I also use my blog for notes-to-self.