Taking a peek at the Azure Management Groups

Introduction

A few days ago the “Azure Management Groups” got into Public Preview. The pitch as mentioned to the docs ;

You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management.

During the current preview, policies aren’t yet part of the preview. Though they will be included later on. So for the moment you can use them to setup a unified access management structure for your governance.

 

Taking a peek

So let’s take a look at how it looks?

Continue reading “Taking a peek at the Azure Management Groups”

Advertisements

What does it look like to deploy a DevOps project into Azure for a Java Application?

Introduction

A few months ago “Azure Devops Projects” was released. As I haven’t had the time yet to test-drive it, I was still sceptic towards the service from a naming perspective. In full disclosure, for me DevOps is about three aspects ; People, Processes & Products (“Tools”). The last part is typically, and maybe surprisingly, the most easy part to do. That being said, as I tried this service, I must admit that this service reduces the friction to set up an end-to-end project. This is where the Azure Devops Project shines! It guides you in a step-by-step manner to set up the end-to-end project for a variety of languages and deployment methods.

 

A brief walk-through

As we all know, the proof of the pudding is in the eating. So let’s see what the flow looks like in reality?

Continue reading “What does it look like to deploy a DevOps project into Azure for a Java Application?”

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.

Continue reading “Azure API Management : What about Multi-Region & VNET Integration?”

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?

Continue reading “Azure : “My first REST API Call”-tutorial”

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…

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

 

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.

Continue reading “Understanding the budget impact of Azure Networking on your architecture”

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…

Continue reading “Serverless On-Demand Scaling : Pushing the pedal when you need it…”

Azure Active Directory : Group integration for daemon / server applications (aka Service Principals)

Introduction

Today’s blog post will be how you can leverage the authentication scenario of a Daemon, Service User or Server Application when our application/API is using Azure Active Directory for its authentication flows.

“An example of a daemon application is a batch job, or an operating system service running in the background. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.”

In essence, a “daemon application” will do a “clients credentials grant” whilst using an Azure Active Directory Service Principal. The “application id” of the service principal will serve as the “client_id” and a generated “secret” will service as the “client_secret”.

In addition to this, we want our application to grant permissions (authorization & identification) based on the group memberships of Azure Active Directory. Where this is pretty straightforward for our basic user objects. This requires a bit of attention when wanting to achieve the same for our service principal.

Continue reading “Azure Active Directory : Group integration for daemon / server applications (aka Service Principals)”