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.

How to estimate the costs of your Azure Kubernetes Service (AKS) cluster?

Introduction

Aside from the variety of technical questions, a very common discussion around Azure Kubernetes Service (AKS) is … “What will it cost me?”. In today’s post we’ll dissect how the pricing dynamics work and how you can optimize the cost for your cluster(s). Where this might not be rocket science, I do have noticed some organizations struggling with this. So with this I hope to help those out… 😉

Is Azure a tier 3 datacenter? And what about Service Levels in a broader sense…

Introduction

Everyone who has been working with cloud, and involved with tenders, has had the follow question (in one form or another) ; “Has the cloud datacenter achieved a tier 3 (or higher) classification? In today’s post we will delve into the specifics linked to the ask ; Why do organizations ask the question, and how does it related to cloud?

What is a “Tier 3 Datacenter”?

To better understand the concept of data-center tiers, it is important to understand that several organizations (like the Telecommunications Industry Association (TIA) and the Uptime Institute) have defined standards for data-centers.

Uptime Institute created the standard Tier Classification System as a means to effectively evaluate data center infrastructure in terms of a business’ requirements for system availability. The Tier Classification System provides the data center industry with a consistent method to compare typically unique, customized facilities based on expected site infrastructure performance, or uptime. Furthermore, Tiers enables companies to align their data center infrastructure investment with business goals specific to growth and technology strategies.
Source ; https://uptimeinstitute.com/tiers

Which typically consists of several tiers…

Four tiers are defined by the Uptime Institute :

• Tier I : lacks redundant IT equipment, with 99.671% availability, maximum of 1729 minutes annual downtime
• Tier II : adds redundant infrastructure, with 99.741% availability (1361 minutes)
• Tier III : adds more data paths, duplicate equipment, and that all IT equipment must be dual-powered, with 99.982% availability (95 minutes)
• Tier IV : all cooling equipment is independently dual-powered; adds Fault-tolerance, with 99.995% availability (26 minutes)

Source ; https://en.wikipedia.org/wiki/Data_center#Uptime_Institute_-_Data_Center_Tier_Standards 

So it is a classification for organizations to understand the quality of the data-center, and be able to take a given availability into account. Though it is important to understand, that this relates to “datacenter housing” (colocation) and not to the cloud service models! Why is this statement important? As on top of that housing, additional services will be delivered by cloud providers to achieve service models like IaaS, PaaS, SaaS, …

UPDATE (2020) ; Azure Datacenter Tier = Higher than Uptime “Tier IV” Institute’s DC Tier standard

In the following document the datacenter classifications have been documented (Link updated in 2021; https://azure.microsoft.com/mediahandler/files/resourcefiles/azure-standard-response-to-rfi-on-security-privacy-and-compliance/Azure%20-%20Standard%20Response%20for%20Request%20for%20Information%20-%20Compliance%20Privacy%20and%20Security.pdf

From generation 1 the datacenters have been designed to meet the customer SLAs and service needs of 99,999%. Given that a tier 4 datacenter is designed towards a customer SLA and service need of 99,995%, we can state that an Azure Datacenter exceeds the expectations of a tier 4 datacenter.

Cloud Native Options – Personal experience when moving from Serverless to Containers

Introduction

Over the last months I have migrated VMchooser from a purely serverless implementation towards a container based one. The main reason for me to do this, was (like always) the learning effect that comes with such a refactoring. This post will run you through the various aspects that I encountered and hopefully give you a better understanding between both implementation options of a CloudNative architecture. I will divert a bit from the pure “X vs Y” comparison and also touch topics that typically come with the business discussions when thinking about both in terms of a strategic approach.

 

CloudNative?

First of all… In terms of semantics, there are some definitions floating around. When you look at the CNCF, then it seems to solely revolve around containers. Though when you look at Azure, the definition broadens up a bit… In reality, it depends a lot on the context of the person/organization you are speaking too. So do not be surprised if for some organizations the scope of CloudNative is “limited” to containers. Where for others this might be about leveraging the PaaS cloud services in a “Serverless” manner.

 

It kinda makes me think about the following “cartoon” (Source ; Simon Wardley) from a few years ago ;

Anyhow, be aware that there are different views on the semantics of “Cloud Native” and be crisp on your own when making conscious decisions.

 

Strategic Design Principle ; Portability

The design principle of software portability is high on the radar with about every organization I talk to. Here I always highlight two dimensions to take into consideration ;

Leveraging Azure Tags and Azure Graph for deploying to your Blue/Green environments

Introduction

For this post I am assuming you are pretty familiar with the concept of deployment strategies (if not check out this post by Etienne). Now these are typically seen from an application deployment level, where platforms (like for instance Kubernetes) typically have out-of-the box mechanisms in place to do this. Now what if you would want to do this on an “infrastructure level”, like for instance the Kubernetes version of Azure Kubernetes Service. We could do an in-place upgrade, which will carefully cordon and drain the nodes. Though what if things go bad? We could do a Canary, Blue/Green, A/B, Shadow, … on cluster level too? Though how would we tackle the infrastructure point of view of this? That is the base for today’s post!

 

Architecture at hand

For today’s post we’ll leverage the following high level architecture ;

This project leverages Terraform under the hood. Things like DNS, Traffic Manager, Key Vault, CosmosDB, etc are “statefull’ where its lifecycle is fully managed by Terraform. On the other hand, our kubernetes clusters are “stateless” from an Infrastructure-as-Code point-of-view. We deploy them via Terraform, though do not keep track of them… All the lifecycle management is done on operating on the associated tags afterwards.

 

Community-Tool-of-the-day

The drawing above was not created in Visio for once. The above was made leveraging CloudSkew, which was created by Mithun Shanbhag. Always awesome to see community contributions, which we can only applaud!

Taking the Azure Data Box Gateway (preview) out for a spin!

Introduction

At the last Ignite conference, three new additions joined the Data Box family. In today’s post we’ll take one of those out for a spin, being the “Data Box Gateway“. This one comes as a virtual appliance that you can run on top of your own physical hardware.

 

So where does it fit into the picture?

• Cloud archival – Copy hundreds of TBs of data to Azure storage using Data Box Gateway in a secure and efficient manner. The data can be ingested one time or an ongoing basis for archival scenarios.
• Data aggregation – Aggregate data from multiple sources into a single location in Azure Storage for data processing and analytics.
• Integration with on-premises workloads – Integrate with on-premises workloads such as backup and restore that use cloud storage and need local access for commonly used files.

 

Let’s take it for a spin!

So let’s make it a bit more tangible and see what the user experience is in setting it up & using it. Start by searching the Azure Marketplace for Data Box Gateway.

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.

VMchooser now supports Azure Migrate Exports

Introduction

The “BulkUploader” module of VMchooser has existed for quite some time. It is without doubt the most loved capability by all the visitors/users. Though where many are accustomed to working with the CSV Input file, do know that you can now also use the export files of Azure Migrate! For today’s post, let’s go through the process…

 

Let’s take a look

Go to your Azure Migrate project

Taking a glance at Rancher’s ability to manage the Azure Kubernetes Service (AKS)

Introduction

Pfew, it’s odd to admit that it has been a while since I’ve posted about Rancher. Though today is as good a day as any to pick up that thread… So today we’ll go through give or take the same objective as in the past, where we’ll notice that the integration has improved significantly with the arrival of AKS! Let’s get today’s post underway and deploy AKS from our Rancher control plane.

Preparation

Before the below started, I already had the following things ready ;

• A service principal with appropriate rights
• Installed Rancher 2.0

Replatforming Azure Functions into an Azure Functions Container

Introduction

A while ago I talked about  “Faas/Serverless” in relation to vendor lock-in. Today we’ll be continuing in that road, where we’ll be doing a small proof-of-concept (PoC). In this PoC, we’ll be replatforming existing Azure Functions code into an Azure Functions container!

 

Things to know

Since Azure Functions 2.0 (in preview at the time of writing this post), you are able to leverage containers. Though be aware that there are several known issues. Do check them out first before embarking on your journey!

 

Testdriving 2.0

So first, we’ll start off with testing the Azure Functions Core Tools!  If you’re looking to follow this guide, be sure to have the Azure Functions Core Tools installed, which also depends on .NET Core 2.0 and Nodejs. Once you have those installed, do a “func –help”, and you’ll see what capabilities are at hand…