Friday, May 8, 2015

Microsoft Azure Stack with a strong ARM

How did God manage to create the world in only 6 days?
-          He had no legacy!

With that, I would like to explain what the new Microsoft Azure Stack is all about.

As many of you already know, we have all been part of a journey over the last couple of years where Microsoft is aiming for consistency across their clouds, covering private, service provider and public.
Microsoft Azure has been the leading star and it is quite clear with a “mobile first, cloud first” strategy that they are putting all their effort into the cloud, and later, make bits and bytes available for on-prem where it make sense.
Regarding consistency, I would like to point out that we have had “Windows Azure Services for Windows Server” (v1) and “Windows Azure Pack” (v2) – that brought the tenant experience on-prem with portals and common API’s.

Let us stop there for a bit.
The API’s we got on-prem as part of the service management APIs was common to the ones we had in Azure, but they weren’t consistent nor identical.
If you’ve ever played around with the Azure Powershell module, you have probably noticed that we had different cmdlets when targeting an Azure Pack endpoint compared to Microsoft Azure.

For the portal experience, we got 2 portals. One portal for the Service Provider – where the admin could configure the underlying resource providers, create hosting plans and define settings and quotas through the admin API. These hosting plans were made available to the tenants in the tenant portal with subscriptions, where that portal – was accessing the resources through the tenant API.

The underlying resource providers were different REST APIs that could contain several different resource types. Take the VM Cloud resource provider for example, that is a combination of System Center Virtual Machine Manager and System Center Service Provider Foundation.

Let us stop here as well, and reflect of what we have just read.

1)      So far, we have had a common set of APIs between Azure Pack and Azure
2)      On-prem, we are relying on System Center in order to bring IaaS into Azure Pack

With cloud consistency in mind, it is about time to point out that to move forward, we have to get the exact same APIs on-prem as we have in Microsoft Azure.
Second, we all know that there’s no System Center components that are managing the Hyper-Scale cloud in Azure

Let us take a closer look at the architecture of Microsoft Azure Stack

Starting at the top, we can see that we have the same – consistent browser experience.
The user facing services consists of hubs, a portal shell site and  RP extensions for both admins (service provider) and tenant. This shows that we won’t have two different portals as we have in Azure Pack today, but things are differentiated through the extensions.

These components are all living on top of something called “Azure Resource Manager”, which is where all the fun and consistency for real is born.
Previously in Azure, we were accessing the Service Management API when interacting with our cloud services.
Now, this has changed and Azure Resource Manager is the new, consistent and powerful API that will be managing all the underlying resource providers, regardless of clouds.

Azure Resource Manager introduces an entirely new way of thinking about your cloud resources.
A challenge with both Azure Pack and the former Azure portal was that once we had several components that made up an application, it was really hard to manage the life-cycle of it. This has drastically changed with ARM, where we can now imagining a complex service, such as a SharePoint farm – containing many different tiers, instances, scripts, applications. With ARM, we can use a template that will create a resource group (a logical group that will let you control RBAC, life-cycle, billing etc on the entire group of resources, but you can also specify this at a lower level on the resources itself) with the resources you need to support the service.
Also, the ARM itself is idempotent, which means it has a declarative approach. You can already start to imagine how powerful this will be.

In the context of the architecture of Azure Stack as we are looking at right now, this means we can:

1)      Create an Azure Gallery Template (.json)
a.       Deploy the template to Microsoft Azure
b.      Deploy the template to Microsoft Azure Stack

It is time to take a break and put a smile on your face.

Now, let us explain the architecture a bit further.

Under the Azure Resource Manager, we will have several Core Management Resource Providers as well as Service Resource Providers.

The Core Management Resource Providers consists of Authorization – which is where all the RBAC settings and policies are living. All the services will also share the same Gallery now, instead of having separate galleries for Web, VMs etc as we have in Azure Pack today. Also, all the events, monitoring and usage related settings are living in these core management resource providers. One of the benefits here is that third parties can now plug in their resource providers and harness the existing architecture of these core RPs.

Further, we have currently Compute, Network and Storage as Service Resource Providers.

If we compare this with what we already have in Azure Pack today through our VM Cloud Resource Provider, we have all of this through a single resource provider (SCVMM/SCSPF) that basically provides us with everything we need to deliver IaaS.
I assume that you have read the entire blog post till now, and as I wrote in the beginning, there’s no System Center components that are managing Microsoft Azure today.

So why do we have 3 different resource providers in Azure Stack for compute, network and storage, when we could potentially have everything from the same RP?

In order to leverage the beauty of a cloud, we need the opportunity to have a loosely coupled infrastructure – where the resources and different units can scale separately and independent of each other.

Here’s an example of how you can take advantage of this:

1)      You want to deploy an advanced application to an Azure/Azure Stack cloud, so you create a base template containing the common artifacts, such as image, OS settings etc
2)      Further, you create a separate template for the NIC settings and the storage settings
3)      As part of the deployment, you create references and eventually some “depends-on” between these templates so that everything will be deployed within the same Azure Resource Group (that shares the same common life-cycle, billing, RBAC etc)
4)      Next, you might want to change – or eventually replace some of the components in this resource group. As an example, let us say that you put some effort into the NIC configuration. You can then delete the VM (from the Compute RP) itself, but keep the NIC (in the Network RP).

This gives us much more flexibility compared to what we are used to.


So, Microsoft is for real bringing Azure services to your datacenters now, as part of the 2016 wave that will be shipped next year. The solution is called “Microsoft Azure Stack” and won’t “require” System Center – but you can use System Center if you want for managing purposes etc., which is probably a very good idea.

It is an entirely new product for you datacenter – which is a cloud-optimized application platform, using Azure-based compute, network and storage services

In the next couple of weeks, I will write more about the underlying resource providers and also how to leverage the ARM capabilities. 

Stay tuned for more info around Azure Stack and Azure Resource Manager.

Monday, May 4, 2015

Azure Site Recovery: Generation 2 VM support

For almost a year ago, Microsoft announced the preview of a cloud service that has turned out to be the leading star when it comes to Hybrid Cloud scenarios, out of the box from Microsoft.

Microsoft Azure Site Recovery let customers extend their datacenter solutions to the cloud to ensure business continuity and availability on-demand.
The solution itself is state of the art and covers many different scenarios – and can rather be seen as their “umbrella” when it comes to availability and recovery in the cloud, as it has several different offerings in different flavors under its wings. 

Besides supporting DR protection of VMware and Physical computers (newly announced), Azure Site Recovery is considered as mandatory for organizations that need DR for their Hyper-V environments, regardless whether the cloud or a secondary location on-prem is the actual DR target.

Just recently, Microsoft announced support for protecting Generation 2 Virtual Machines to Azure.
This is fantastic good news and shows that the journey towards cloud consistency is established for sure.

Let me add some context before we look into the details.

I’ve been working with the brilliant Azure Site Recovery Product Group at Microsoft for a long time now, and I have to admit that these guys are outstanding. Not only do they ship extremely good quality of code, but they also listen to feedback. And when I say listen, they actually engage with you and really tries to understand your concern. In the end of the day, we are all on the same team, working towards the best experience and solution possible.

During TechEd in Barcelona, I was co-presenting “Microsoft Azure Site Recovery: Leveraging Azure as your Disaster Recovery Site” ( ) together with Manoj, and this is when our real discussion started.
Using Azure as the secondary site for DR scenarios makes perfect sense and many customers would like to take benefit from this as soon as possible. However, we often saw that these customers had deployed their virtual machines as Generation 2 VMs – which wasn’t suited for the Azure platform. This was a blocker and the amount of Gen2 VMs were increasing every day.

Earlier in January this year, I made a community survey around the topic and the result was very clear:

Yes – people would love to use Azure as their secondary site, if there was support of Generation 2 VMs in the Cloud.

I am glad to say that the Product Group listened and now we can start to protect workloads on Gen2 VMs too.
But, how does this work?

When you enable a VM for protection, the data is sent to an endpoint in Azure, and nothing special has happened so far.

However, the ASR service will perform a conversion in the service at the time of failover to Gen1.


Let me explain further.

In case of a disaster where you need to perform a failover to Azure, the VM(s) is converted and started as Gen1, running in Azure.
The ASR backend services used during failover has the conversion logic. At failover time, backend service reads Gen2 OS disk and convert the disk to Gen1 OS disk (hence the requirements of the OS disk in Azure).
If you need/want/have to failback to your on-prem Hyper-V environment, the VM will of course be converted back to Gen2.

For more details – check out the official blog post by one of the PM’s, Anoob Backer