Ahoy there folks and welcome back. So I was working on a series of blog posts regarding Azure Stack TP3 and just as I was writing the last one, they go and bring out the Azure Stack Development Kit (ASDK) with an updated deployment guide…awesome!
So, I’ll be running through the new deployment with ASDK and posting about my experiences, mainly where the differences are. Instead of diving right into the deployment guides this time, I’ve decided to post an overview of Azure Stack as it may serve to give a better understanding of the core concepts before getting your hands dirty…I know, but trust me, we’ll both end up in a better place because of it as I’m fleshing out my knowledge here while writing it, so it’s purely for selfish reasons 😛
Keep in mind most of this post was written with TP3 in mind, and I’ve made changes where I think they’re required but if I’ve missed any, please forgive me, better yet, leave a comment and I’ll fix it.
Here is a quick list of what will be covered herein:
- Azure Stack Development Kit Architecture
- Azure Stack Scaling
- Azure Resource Manager (ARM)
- Azure Resource Manager (ARM) Templates
- Quotas, Plans, Offers and Subscriptions
Azure Stack Development Kit Architecture
Let’s have a quick look at the Azure Stack Development Kit (ASDK) architecture. This will give us a better idea of where everything fits together when we get into the later sections. This diagram is a modified version of one put out by Microsoft, the ARM layer is highlighted as I’ll be referring back to it later.
Diagram 1:
The following diagram also gives us a look at the logical layout of the ASDK.
Diagram 2:
NOTE: There is no longer a console VM deployed as part of ASDK, you can use the physical host instead or spin a VM yourself and install any admin tools you want to use, Visual Studio etc.
All our interactions with the ASDK will be through either the Admin and Tenant portals or by targeting ARM directly using one of the many available tools. Being that we engineers are a curious bunch though, here’s a quick breakdown of the roles listed in the diagram.
| Role Name | Role Description |
|---|---|
| AzS-ACS01 | Azure Stack storage services. |
| AzS-ADFS01 | Active Directory Federation Services (ADFS). |
| AzS-BGPNAT01 | Edge router and provides NAT and VPN capabilities for Azure Stack. |
| AzS-CA01 | Certificate authority services for Azure Stack role services. |
| AzS-DC01 | Active Directory, DNS, and DHCP services for Microsoft Azure Stack. |
| AzS-ERCS01 | Emergency Recovery Console VM. |
| AzS-GWY01 | Edge gateway services such as VPN site-to-site connections for tenant networks. |
| AzS-NC01 | Network Controller, which manages Azure Stack network services. |
| AzS-SLB01 | Load balancing multiplexer services in Azure Stack for both tenants and Azure Stack infrastructure services. |
| AzS-SQL01 | Internal data store for Azure Stack infrastructure roles. |
| AzS-WAS01 | Azure Stack administrative portal and Azure Resource Manager services. |
| AzS-WASP01 | Azure Stack user (tenant) portal and Azure Resource Manager services. |
| AzS-XRP01 | Infrastructure management controller for Microsoft Azure Stack, including the Compute, Network, and Storage resource providers. |
As mentioned earlier, I’ll be referring back to these diagrams a fair bit when we go into a little more detail on Resource Providers etc…like now.
Resource Providers
If you look back at “Diagram 1”, you will see a section named “Resource Provider Layer” which contains a few of the available Resource Providers in Azure Stack. A Resource Provider (RP) is a web service that gives you the ability to deploy resources under its control through ARM. We’ll cover 3 of the main ones in a little more detail to try and cement their place in the environment.
Compute Resource Provider (CRP)
Called Microsoft.Compute, this RP allows both admins and tenants to deploy Virtual Machines and virtual machine extensions. One example of a virtual machine extension is the hallowed BGInfo that we all know and love 🙂
You can view a list of the VM extensions available in your ASDK environment by running the following PowerShell:
Get-AzureRmVmImagePublisher -Location local | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version | Sort-Object Type | Format-Table -Property * -AutoSize
Network Resource Provider (NRP)
Called Microsoft.Network, this RP provides a whole bunch of Software Defined Networking (SDN) and Network Function Virtualisation (NFV) features. This allows admins and tenants to create virtual networks, network security groups (NSGs), software load balancers etc.
Storage Resource Provider (SRP)
Called Microsoft.Storage (are you seeing a pattern here yet?), this RP is responsible for controlling our storage in the ADSK. You interact with your Azure-consistent storage by means of a secure storage account. This account provides an addressable unique namespace for your storage resources. It delivers four Azure-consistent storage services, these are blob, table, queue and account management. Let’s cover these storage services in a little more detail as it’s important to know the differences and their intended use cases:
Blob Storage:
Stores unstructured data, this can be any type of text or binary data, for example: logs, Images, documents, video files etc. There are 3 different types of blob and they again have different use cases in Azure Stack, these are:
- Block – optimised for streaming and storing cloud objected. Best uses cases would include documents, media files, backups etc.
- Append – Similar to above but are optimised for append operations. An append blob can be updated only by adding a new block to the end. Best use cases would include logging, where data needs to be written to the end of a blob.
- Page – Optimised for storing IaaS VHDs and supporting random writes to VHDs up to 1TB in size. When you deploy an IaaS VM into Azure Stack and attach a VHD, this is stored as a page blob.
Any blobs you create are organised into containers, you can have any number of containers in a storage account and any numbers of blobs in a container (subject to the storage capacity limits of your storage account).
Table Storage:
Table storage is a key-attribute store, meaning that every value in a table is stored with a typed property name. The property name can be used for filtering and specifying selection criteria. A collection of properties and their values comprise an entity. Since Table storage is schemaless (totally a word), two entities in the same table can contain different collections of properties, and those properties can be of different types.
You can use Table storage to store flexible datasets, such as user data for web applications, address books, device information, and any other type of metadata that your service requires. A storage account can contain any number of tables and a table can contain any number of entities (subject to the storage capacity limits of your storage account).
Queue Storage:
In designing applications for scale, application components are often decoupled, so that they can scale independently. Queue storage provides a reliable messaging solution for asynchronous communication between application components, whether they are running in the cloud, on the desktop, on an on-premises server, or on a mobile device. Queue storage also supports managing asynchronous tasks and building process workflows.
A storage account can contain any number of queues, and a queue can contain any number of messages, up to the capacity limit of the storage account. Individual messages may be up to 64 KB in size.
OK, that’s probably enough on Resource Providers for the time being, let’s move on.
Azure Stack Scaling
Let’s have a look at how Azure Stack scales/will scale. As it stands in Azure Stack today (ASDK), we have the choice of a single location/region. This is named “local” and is created by default during deployment, although can be named something more meaningful at GA. At some point post GA we’ll be working with the same concepts currently available in public Azure, these are Regions, Scale Units and Servers.
Have a look at the screenshot below, recently tweeted by David Armour (@Darmour_MSFT), a Program Manager on the Azure Stack team at Microsoft.
So, let’s break that down a little:
Region: Think of this as a location i.e. Toronto (as above)
Scale Unit: Think of this as a “stamp” of Azure Stack resource with each region potentially made up of multiple scale units.
Servers: At GA a scale unit will be made up of between 4 (minimum) and 12 (maximum) servers.
NOTE: Each server that makes up a scale unit has to be identical within that scale unit, however scale unit 1 and scale unit 2 can be made up of different hardware e.g. a different generation of the same server.
Azure Resource Manager (ARM)
This’ll be a fairly meaty one as you can’t really explain parts of it without explaining most of it 🙂
I wanted to include a section on Azure Resource Manager (ARM), because I’m fairly new to it too, it’s VERY important in the grand scheme and it’s bloody awesome! It’s likely I’m going to have a lot of fun building ARM templates in the coming months. Looking back up to “Diagram 1” above, the highlighted section shows where in the “stack” (nuck nuck) ARM fits in.
Soooo, as you can see from the diagram, any and all interaction with Azure Stack is achieved through the Azure Resource Manager layer…so it’s pretty important.
One of the best benefits of ARM is that it’s consistent, so things can change further down the “stack” (again, I know) without necessarily changing the way we as users interact with Azure Stack, and because all tools use a common set of operations you can use whatever one you prefer. Here are a few of them:
- Azure PowerShell
- Azure CLI
- Azure Stack Portal
- REST API
- Various developer tools (Visual Studio as an example)
Using ARM, resources can be deployed using a declarative method (making use of ARM templates, more on this later) where before we’d have used scripts. Declarative syntax is basically telling ARM what you want to do/create without having to write the code to tell the system how to do it. This means your focus shifts from writing code to deploy an infrastructure, and instead to defining the properties of an infrastructure for ARM to deploy into Azure Stack.
Making use of resource groups (more on these below) allows you to deploy, manage and monitor any and all resources that make up your solution. This makes life so much easier, one example of this would be easily tearing down a development environment after use by deleting the resource group that contains all the resources that make up that environment.
Now let’s go over some of the features of ARM in a little more detail individually otherwise we’ll end up with a massive wall of text.
Resource Groups
In the ASDK, any services or applications you deploy will be made up of a whole bunch o’ resources, each of these resources has a type, e.g. Network Adapter, Network Security Group, Virtual Network, Storage Account, Public IP…you get the idea. Resources need to be deployed into a Resource Group, this also lets you logically arrange your resources for example, it’s best practice to deploy all resources that share the same life cycle, into the same resource group e.g. all resources that make up say…your HR development environment should belong to the same resource group, this makes for easier management and MUCH easier decommissioning when the time comes.
Tags
Tags can be applied to resources to group them together logically and can also be applied to resources that exist across different resource groups. These tags can be controlled by policy to keep them consistent, they can also be applied to resources as they’re created when using ARM templates, so that’s good. A good example of tags usage would be to tag any resources that are consumed by say…your Marketing department. This would allow you to easily track the department spend and bill them accordingly 🙂
Azure Resource Manager (ARM) Templates
So I mentioned ARM templates earlier, but what are they and more importantly, what do they do?
The first thing to know about them is that they’re in JSON (JavaScript Object Notation) format, so if (like me until fairly recently) you’ve not had much time working with JSON, it’s worth doing a little swatting up. They are pretty human readable though so understanding them at a basic level “shouldn’t” take you too long. I am by no means an expert on them at this point…YET, but I’m hoping to get there 🙂
ARM templates allow you to repeatedly and more importantly, consistently deploy your resources. You can deploy to Azure Stack using ARM templates from the Azure Stack portal, PowerShell, Visual Studio to name a few methods. When ARM receives an ARM template, it’s parsed and converted to REST API operations, these operations are then passed to the relevant resource provider to be processed (See Azure Stack POC Architecture diagram above).
When you deploy templates using ARM, it’s idempotent. In other words, you can deploy a template at a target environment and if you haven’t made any changes to the template, there will be no changes to the environment. If you have made changes to the template, then only those changes will be applied to the target environment.
Now, you don’t have to start from scratch when authoring an ARM template as there are LOADS already out there and freely available. You can also export the current state of any solutions you created to an ARM template using the Azure Stack portal. This can then be edited as required and used to deploy additional solutions, or even make changes to an existing one. You can also view the ARM template of a solution at the point of deployment, this can be exported too.
The following link is a great resource to get you started with ARM templates and cover everything from a humble single Windows VM deployment to full clusters with load balancers etc. You can also get Azure Stack specific ARM templates HERE
Let’s have a look at a fairly straightforward template, the aforementioned 101-vm-simple-windows template.
NOTE: It’s worth mentioning, that you can actually deploy one of these templates straight into Azure from here…mental 🙂
As you can see in the above picture, an ARM template is made up of multiple files, here’s a quick breakdown of the purpose each listed (in this example template):
- README.md – As the name suggests, this is a file that should well describe the template contents and what it does
- azuredeploy.json – This is the main deployment template file
- azuredeploy.parameters.json – This is a file containing parameters used in the deployment of the template, these can be prompted for at deployment or statically populated.
- metadata.json – This file contains data about the template for its use and publication
Also, if you click the “Visualize” button on the template page, it’ll give you a visuali”s”ation of the resources created when deploying the template…pretty neat.
Let’s have a look at portions of the template itself. I’ve got Visual Studio community edition installed and will be using that to view the template, you can use an editor of your choice though e.g. Visual Studio Code.
azuredeploy.json
The sections marked in red and defined in the azuredeploy.parameters.json file (See below). You will be prompted to enter values for these at the point of deployment.
The section marked in green has been configured with “allowedValues”. You will be prompted with a drop-down menu to select from these allowed values at the point of deployment.
azuredeploy.parameters.json
metadata.json
You’ll remember from earlier that we have the ability to deploy these templates to Azure directly from GitHub if we want to, let’s have a look at that to see the deployment in context.
Again, see the items marked in red, these were defined in the parameters section on the template. The section marked in green is presented as a drop-down of the configured allowed values.
Now look at the section marked in purple, when hovering over the “i”, you receive a popup with a description of the input expected for the field, this is defined by adding a description to your parameter within the template, see screenshot below.
We could sit here all day and speak about ARM but it’s probably time to move on, so we’ll leave it here for the time being. Suffice it to say though, ARM is awesome and it’s definitely worth putting the time into learning to work with as it’s fundamental to Azure Stack…plus it’s just REALLY COOL!
What are Quotas, Plans, Offers and Subscriptions?
It’s quite possible that anyone reading this is already quite comfortable with the concepts in the above title, but DAMN IT I’m gonna go over them anyway. Some of these concepts are true of both public Azure AND Azure Stack, while others aren’t, or at least aren’t exposed to the Service Provider or tenant. Most of the items detailed from here on out are listed because you’ll interface with them at some point as either the Service Provider or as a tenant.
Let’s get started then.
Considering what we’re about to go over in detail, here is a quick screenshot (pinched from Microsoft) that shows the hierarchy of Subscriptions, Offers, Plans and services as it helps illustrate things quite well.
Diagram 1:
The following diagram goes into a bit more detail on the relationship between services, quotas, plans, offers and subscriptions.
Diagram 2:
Services
There are quite a few services and applications we can deliver to our tenants using Azure Stack, if you’ve followed my Azure Stack TP3 guide from the start then at the very least these include:
Using the built in Storage Resource Provider you can also deploy Blob, Table and Queue storage as a Service, which we covered in a little more detail earlier.
Quotas
Quotas can be configured against many of the resource providers available in Azure Stack and are a way or controlling or enforcing usage restrictions against these resources. The screenshot below shows the configurable quota options for the “Microsoft.Compute” resource provider (as an example).
These quotas are associated with a plan (more on plans later) and more than one quota can be created against a resource provider.
Don’t worry if you’re starting to lose track of how everything is interconnected here as it’ll make more and more sense as we go on. The two diagrams at the top of this section illustrate things quite well…go look now, I’ll wait.
NOTE: Diagram 2 follows the build laid out in this series of guides
Plans
So what are plans? As I’ve hopefully illustrated in Diagram 2 above, they’re a collection of services with associated quotas. Multiple services can be associated with each plan and multiple plans can be associated with each offer (more on that later).
Plans can be included in offers in two ways, the first is a base plan and this is included by default when a tenant subscribes to an offer. The second is as an add-on plan, any plan can be added to an offer as an add-on plan and can augment the resources or services available to a tenant subscribing to that offer.
Again, looking at diagram 2 above shows that offer 2 has plan 1 as its base plan, and plans 2 and 3 as add-on plans, adding both additional storage and the ability to deploy MSSQL and MySQL as a Service.
Offers
So now that we know what services, quotas and plans are, where do offers fit in? Offers are a collection of one or more plans and are what your tenants will subscribe to in order to consume services and their associated resources.
Offers can be either public or private (controlled by the service administrator). Public offers, as the name suggests allow users to browse for them and subscribe without further involvement from a service administrator. Private offers are hidden from users and subscriptions to them are created and controlled by the service administrator.
Subscriptions
Last one in this section folks. A subscription is a link between a tenant and an offer (they are “subscribing” to that offer) which gives that tenant access to the offers underlying services and plans. Tenants can have multiple subscriptions but subscription to offer mappings are on a one to one basis.
It’s worth noting that there is also a “Default Provider Subscription” created when deploying Azure Stack, this is where a service administrator can deploy additional resource providers, plans, offers etc.
NOTE: Customer workloads and/or applications should never be run from this subscription
OK, so hopefully you now have a better understanding of “some” of the core concepts of Azure Stack so let’s get on and deploy the thing shall we?
Hope to see you in part 2 when we run through a deployment of the new Azure Stack Development Kit.