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 ;
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!
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 ;
- “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.
- “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;
- “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.
- “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”.
- “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.
- “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.
Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;
To here ;
By using a CI/CD pipeline.
Flow of the day
What will we be doing today?
- Kick-off a VSTS build once a change has been made to our Github repo
- Build a container via VSTS
- Publish the container to an ACR (Azure Container Registry)
- Kick-off a VSTS release once the build succeeded
- Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath
Sound cool? Let’s get to it!
Remember the last time you went shopping for a shirt? Then you surely also recall the moment in time when you were looking to find the right shirt size for yourself…
You probably also noticed that sizes might differ a bit depending on the context. A woman’s size vs & men’s size is totally different. There are geographical differences… and some people just like to wear cloths that have more “free space”.
So is today’s post about buying cloths? Hell no… 😉 But it’s to point out that there are analogies between finding the right shirt for you, and finding the right Azure Virtual Machine. Today we’ll delve into the aspects that will guide you a given T-shirt size in Azure ; for instance, why choose an FS1 above an A1_V2, where they both have 1 core & 2GB of memory. Though there is a price difference of 10€ per month on them.
During the weekend I saw the following tweet passing by …
Apparently, a hosting company (allegedly) got all their data wiped by an ex-admin. Now I can imagine people thinking that this is something that is part of the territory when it boils down to cloud. So I wanted to write a blog post entailing what you do to set up a governance structure in Azure. Here I’m aware that the above tweet is more related to the security aspect of governance, it’s a part of it nevertheless.
Let’s get started on our scope… IT Governance can cover a lot of ground. In essence, the goal is to assure that the investment in IT generates business value and the risks that are associated with IT projects are mitigated. Though I found that CIO.com has a nice definition on it ;
Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results. An IT governance framework should answer some key questions, such as how the IT department is functioning overall, what key metrics management needs and what return IT is giving back to the business from the investment it’s making.
So let’s take a look at how we can put an enterprise-grade structure around the management of Azure!
TL;DR = Azure Enterprise Scaffold
For those who want to skip the post below… When talking about governance in Azure, the best place that summarizes it the following page in our documentation ; “The Azure Enterprise Scaffold“.
From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…
Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!
Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉
In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?
- We’ll be creating a kind of service user in Azure which Terraform will use to log in.
- We’ll be authoring a small configuration file that will serve as the input for our network
- We’ll be applying that configuration file.
Seem simple enough? Let’s get started!
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!