Azure Serverless Compute Options

Introduction
A bit less than a year ago I blogged my opinion on “Cloud Native”, where the objective of today is to provide a bit more nuance to this previous post. Let us categorize it as “progressive insights”, due to having these type of discussions on a virtually daily basis. Therefore I wanted to share this with a broader audience, as I expect this is valuable to all. Where I will also try to make it a bit more tangible to link it to “Serverless” options in Azure.

Azure Networking ; Service endpoints, Private links and VNET Injection

Introduction

Today’s post is inspired by the combination of a twitter thread from earlier today… and having had the same conversation with a customer earlier today too! Truth be told, there are a variety of networking options when integration Azure Services with your VNET (Virtual Network). So let us go over them!

 

The different options

When you want to integrate PaaS services, you have several options on how to integrate them into your VNET ;

• Service Endpoints
• Private Link
• Deploy inside of a VNET (“VNET Injection”)

 

Now lets us take a look at the differences by using the following schematic ;

 

You will see that both the “SQL Managed Instance” and “Azure Kubernetes” service reside inside of the virtual network. This is what used to be called “VNET injection”, and where you deploy the service directly into the VNET. Typically you give each of those services their own subnet, without any other things inside of it to avoid interoperability issues. Though from then on you can leverage private traffic within your VNET and have hybrid integration scenarios (aka “Connect to On Premises”).

When looking towards the “Azure Storage”, you can see two colors ;

• Purple indicates a “Private Link” & “Private Endpoint”. The private link is the line from the service to the dot. Where the dot is actually the private endpoint, which will have a private ip belonging to the range of the subnet (within the VNET) it belongs too. This means that the service will be able to connects you privately and securely to a service powered by Azure Private Link. The nuance difference between “VNET injection” and “Private Link” is that the first is used for resources dedicated to you (AKS Workers, SQL Managed Instance, …) and the latter is used for services that share resources underneath (AKS Master Nodes, Azure SQL DB, Azure Storage, …). This will also allow you to connect to services in a hybrid integration scenario.
• The orange link depicts the concept of a service endpoint. It extends your virtual network private address space to a shared service. The endpoints also extend the identity of your VNet to the Azure services over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network. If you want to understand more of the mechanics underneath, check the following post from when I took my first glance at them. Important to know is that the service will still have its public IP, and that you will leverage that to connect to it. It is used to connect from inside of the VNET to a public endpoint, while you can configure the firewall of the public service to filter on your private range. It cannot be used to connect to a service in a hybrid integration scenario.

 

Not all options work for all services!

Though be aware that not all services have all options available… Check the documentation of the services at hand and the above options. I know this makes it a bit complex at times. Though the capabilities are constantly evolving! And sometimes network integration is also only unlocked in premium editions of a service. For example, in the past you could only get a fully private scenario for App Service by leveraging the Isolated edition (or “App Service Environment”). This made it possible to inject the service into your VNET. Though it had a starting cost of about 1k USD… With the arrival of Private Link/Endpoint, this is not a requirement anymore. Where the API Management does still require either the Premium (Production) or Developer (Non-Production) variants of the service to unlock VNET integration.

 

Closing Thoughts

Things might be confusing at times. Though I hope this brief post helps you position the different options you have in terms of network integration.

• Service Endpoints ; Connect in a hardened way from a VNET to a shared service
• Private Link ; Give a shared service a private endpoint in your VNET
• Deploy inside of a VNET (“VNET Injection”) ; Deploy a service privately for you into your VNET

Traffic Light Protocol alike Security Reference Architecture for Azure

Introduction

The way how organizations categorize/handle classified information can vary significantly. Where it can go from about 6 categories towards a more “limited” set of 3 to 4 categories. Where you see that some government organizations have even tried to reduce this in an effort to make it more accessible.

 

So for today, we’ll be looking at how we can handle sensitive/classified information in Azure. And to ensure you that you Azure implementations can facilitate sensitive data.

 

Side Story : Security should be like a roundabout

Though I don’t remember which conference talk it was… One visual has always stuck with me when talking about security. Imagine security like road infrastructure. Having a complex situation might be needed at times, though it will increase the risk that the drivers (~users) will make mistakes.

Resiliency Patterns in Azure

Introduction

Resiliency patterns in Azure is a very common / return question. Though over the course of time, I’ve noticed there is a lot of confusing around the architectural patterns involved here. This mostly comes down to the basic illusion that HA (High Availability) and DR (Disaster Recovery) are both met when doing a stretched cluster.

 

Overview of all the patterns

 

Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!

Introduction

For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).

 

High Level Setup

So what will we be setting up & testing today?

The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp.  You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.

 

Azure : Is it possible to do a cross subscription network peering?

Introduction

Today I received a question if it was possible to do a cross subscription peering… with one big catch; that it was between the subscription of a service provider and their customer(s). So let’s see what is possible?

 

Update : Oct 2018

At Ignite 2018 it was announced that peering will also be able to work cross tenants.

 

Public Preview Announcement

When we take a look at the announcement, we see the following statement ;

Note that you can peer virtual networks that exist in two different subscriptions as long as a privileged user of both subscriptions authorizes the peering and the subscriptions are associated with the same Active Directory tenant.

Now the from this we can already see that it is possible to doe cross subscription peering. As a requirement, we need a user that is authorized on both subscriptions AND that the subscriptions are associated with the same AAD tenant.

The latter caused a bit of confusion on the requestor part, where the statement was made if a B2B invite would solve this issue. The answer to this is “no”. The B2B invite lies on the authorized user part, and is not related to the tenant of the subscription!

 

Let’s try it out?!?

FaaS & Serverless – Vendor lock-in or not? Consider the cost of the full application lifecycle

Introduction

In my current role at Microsoft, I often talk about the possibilities in regards to application modernization. A typical ask in this space is to what kind of service they should use as a underlying platform for their own services. Where this commonly results in a (brief) discussion about VMs vs Containers vs Serverless/FaaS. Today’s post is about my personal take on the matter.

 

Setting the scene

First let’s start with setting the scene a bit… For today I’ll try to focus on the application modernization landscape, where the same goes for the data platform stack. Here you can pretty much interchange “Functions” with “Data Lake Analytics” and “Containers” with “HD Insights”. Though we’ll not go into that detail, in order to reduce the complexity of the post. 😉

When looking towards the spectum, the first thing to acknowledge is the difference in service models. Here we mainly have two service models in play ;

The anatomy of “vmchooser”… Adding some serverless into the architecture!

Introduction

In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.

 

High Level Architecture

VMchooser has the following high level architecture ;

• Web App : The front-end of the application is hosted on an Azure Web App.
• Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
• Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
• Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
• Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
• API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.

 

Comparing Costs : Is Cloud more expensive than an On Premises setup?

Introduction

In my role as a Cloud Solution Architect, I’m often faced with the statement that cloud is expensive. My reply is always that Cloud is not expensive (more expensive than On Premises) if you take into account all the costs involved. As this is an easy statement to make… I made an effort to create a cost comparison for four different scenario’s (in term of deployment size) and stacked “OnPremises” vs “Cloud”.

In this post we’ll discuss this calculation and ensure that we are comparing apples to apples!

 

Design Decisions

Rancher End-to-End Service Example using an Owncloud-plus-mysql Deployment

Introduction

So what will we be doing today? We are going to leverage the power of the combination between docker containers & the rancher eco system. As a demonstration, we’ll be publishing “Owncloud” with a “mysql” backend. As we tend to like it a bit more secure, we’ll introduce a loadbalancer service as SSL termination. This as we want to keep our “Owncloud” as “vanilla” as possible. We’ll be pointing that service towards the outside world and will make it accessible via the “external dns”.

What can we optimize further about the design? (but is out-of-scope for today)

• Add sidekick containers for backup purposes
• Add data volume containers
• Introduce scalable worker containers (“Owncloud”)
• Introduce convoy for our data containers