Azure API Management : What about Multi-Region & VNET Integration?

Introduction

Yesterday I received a question whether the combination of Multi-Region & VNET Integration is supported for Azure API Management. My gut feeling told me yes… Though it seems our documentation wasn’t 100% clear on the matter. So I did a quick test to see if it was possible.

Azure : “My first REST API Call”-tutorial

Introduction

For today’s post, we’re going to do a REST call towards an Azure API. For this we’re going to create a “Servce Principal” and afterwards use the credentials from this object to get an access token (via the Oauth2 Client Credentials Grant) for our API.

 

Protocol Flow

What’s the flow going to be?

1. The application does a clients_credential call. Here it’ll provide ;
   1.  it’s application id as a client_id
   2. it’s secret as the client_secret
   3. choose “clients_credentials” as the grant_type
   4. set the “resource” to “https://management.azure.com”
2. AAD will return an access token
3. You can now call the API adding an additional header ;
   1. Header Name = Authorization
   2. Header Value = “Bearer *accesstoken*”
4. The API will return a response

(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service )

 

Now let’s see how that would look in reality?

Understanding the budget impact of Azure Networking on your architecture

Introduction

Today’s post will be about “demystifying” the possible network costs you might incur when using Azure services. Once you understand the basics behind the billing model, you’ll soon find that you can tweak these to your advantage!

 

Cost Drivers

When looking towards the costs, there are several pricing pages you should visit to know the cost drivers of your architecture…

• Azure Bandwidth : https://azure.microsoft.com/en-us/pricing/details/bandwidth/
• Azure Virtual Network Peering : https://azure.microsoft.com/en-us/pricing/details/virtual-network/
• Azure VPN Gateway : https://azure.microsoft.com/en-us/pricing/details/vpn-gateway/
• Azure Express Route : https://azure.microsoft.com/en-us/pricing/details/expressroute/

Though I can feel you… It’s not always easy to understand when what is triggered.

 

Updates (!)

• 23/08 – Updated HL overview to v2.0 to include costs due to zone architecture
• 23/08 – Source files for the drawing can be found here.

 

High Level Overview

Underneath you can find an overview of the possible cost drivers. We’ll go into depth on the individual flows in this post.

Serverless On-Demand Scaling : Pushing the pedal when you need it…

Introduction

A lot of workloads are driven by peak consumption. From my experience, there aren’t the amount of workloads that have a constant performance need are in the minority. Now here comes the interesting opportunity when leveraging serverless architectures… Here you only pay for your actual consumption. So if you tweak your architecture to leverage this, then you can get huge gains!

For today’s post, I’ll be using VMchooser once again as an example. A lot has changed since the last post on the anatomy of this application. Here is an updated drawing of the high level architecture ;

Underneath you can see the flow that’ll be used when doing a “Bulk Mapping” (aka “CSV Upload”). The webapp (“frontend”) will store the CSV as a blob on the storage account. Once a new blob arrives, a function will be triggered that will examine the CSV file and put every entry onto a queue. Once a message is published onto the queue, another function will start processing this message. By using this pattern, I’m transforming this job into parallel processing job where each entry is handled (about) simultaneously. The downside of this, is that there will be contention/competition for the back-end resources (being the data store). Luckily, CosmosDB can scale on the fly too… We can adapt the request units as needed; up or down! So let’s do a small PoC and see who this could work…