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.

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!

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…

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

Rancher : Docker Lifecycle Management – Or how to upgrade containers?

Introduction

It’s all fun & games to create & deploy containers. And the “pets vs cattle” thingie is also cool… Though what about the lifecycle management? That’s something we’ll be handling today!

What will we be doing today?

• Create a small dummy container
• Setup a source respository (at BitBucket) for that dummy container
• Setup an automated build (linked to the source repository) on your docker hub respository
• Deploy a service on rancher
• Update the source
• Upgrade the service to the latest version
• Enjoy life even more!

What will already need to be setup?

• A host with docker installed
• Have rancher installed

Xmas Tech Cookbook : Docker Swarm & Rancher Walkthrough

Objectives of this post

• Install Docker on all machines
• Setup a Docker Swarm
• Setup Rancher to manage the lot

Test Scenario

For this walkthrough I’ll be using 4 x Azure A0 Machines with Ubuntu 14.04TLS on them. Three of those will serve as docker hosts and one will be my Rancher management tooling. The docker hosts will be put into a swarm. For easy reference (and as a basic enterprise simulation), I’ve setup my docker hosts in a seperate subnet compared to the rancher.