XenData : When a Windows Volume suddenly gets hybrid towards an Azure Storage Account

Introduction

Today I took the Xendata Cloud File Gateway out for a spin… Why? This little piece of software allows a windows volume to be extended by an Azure Storage Account. And from a technical level, we are talking about blob storage here. So you can leverage hot & cold storage, and even archive storage in the long-term. Imagine that huge exploding file server? Suddenly we can extend our typical Windows File Server with an seamlessly unlimited cloud tier. Whoppah!

Let’s take a look shall we!

A first glance at the preview AKS (Azure Kubernetes Service)

Introduction

Today the new “AKS” (Azure Kubernetes Services) was launched in preview. This is a managed container service. So where ACS used to rely on IaaS and used a set of best practices to deploy the cluster. AKS will go a step further, where it’ll managed the master nodes & provide upgrade tracks.

 

Deploying

Let’s start with deploying an AKS cluster… Here we can select the k8s (kubernetes) version too.

Hardening Azure Functions when exposing them via Azure API Management

Introduction

In my discussions with customers about “serverless”, we often talk about the typical security patterns when embarking on the deployment of functions for Enterprise organizations. A typical combination we see here is where Azure API Management is used in front of Azure Functions. Today we’ll talk about the options at hand here. In essence this will related to a choice where an organization will need to choose between “Fully Isolated” and “Full Flexibility”!

Azure IoT Hub – Generating & using SAS tokens for a device

Introduction

Today we’ll talk about two connection flows you can do with an IoT setup when using keys. An alternative might be to use certificates, but I won’t cover that one today.

When talking about keys, there are two common patterns ;

• one where the IoT device has a symmetric key (used to generate SAS tokens)
• another where the IoT device is only provided with the SAS token (which is generated by another service)

Azure Star / Any Load Balancer or … like we would like to call it “HA Ports”

Introduction

A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.

Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.

Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.

Azure App Service : Deploying a java webapp (geoserver) to Azure

Introduction

For today’s post, we’ll be deploying a java web-app to Azure. Here we’ll be leveraging our well-known “App Service” as the underlying PaaS component to host our web-app.

 

Sample Workload : Geoserver

For today’s example, we’ll be using “geoserver” as the grounds for our little proof-of-concept. In addition, we’ll even trow in the Azure PostgreSQL Database for the back-end store.

Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.