Windows Azure Pack architecture in comparison to Windows Azure

In the article I will look at the high level architecture of the Windows Azure Pack compared to Windows Azure. This will help to understand how Microsoft was able to provide their vision of 1 consistent Cloud OS platform. So here’s a nice picture that explains:

Windows-Live-Writer-Windows-Azure-PackArchitecture-Compariso_6933- On the left hand side you see the Windows Azure stack and on the right hand side the Windows Azure Pack stack. Let’s look at Windows Azure first.

Windows Azure

At the bottom of the Windows Azure stack is the Windows Azure fabric, the hardware, OS, and services that Windows Azure runs on. Microsoft does not provide too much information how this looks like. However, Microsoft started discussing their cloud server hardware designs:

We assume Microsoft is using some sort of Windows Server with Hyper-V to power the Azure cloud. Microsoft does say that the Hyper-V version that is in Windows Server 2012 R2 is the same version used in Windows Azure. This does not really surprise since most of the new features in Hyper-V seem to be created for Windows Azure on purpose. Windows Azure also uses the same VHD disk format as Hyper-V which allows you to copy VHDs that you created on-premises to Windows Azure and use them there (VHDX is not jet supported).

On top of the fabric sits the service and workloads that Windows Azure offers: Web Sites, VM IaaS, SQL, Service Bus and many more. We don’t know how these are implemented and if these run on standard or customized Microsoft products. However, it does not really matter. What we do know is that Microsoft is updating their services and workload quickly and frequently.

The next layer is the important one: The Service Management API layer. This is a REST API that allows you to get programmatic access to the services below. On top of that sits the Windows Azure Self-service portal. This is the portal that you see when you subscribe to Windows Azure and where you can consume the different Azure services. The portal allows you to configure and manage the available services.


Windows Azure Pack

On the Window Azure side, the foundation for the Windows Azure Pack is of course Windows Server with Hyper-V and System Center. That’s why Windows Server is also called the Cloud OS. Many of the new features in Windows Server 2012 and 2012 R2 are specially target to support cloud functionality. The System Center tools provide the fabric management and monitoring that is required for the services above that layer.

The service and workload layer reveals the familiarity of the Windows Azure Pack to Windows Azure. The Windows Azure Pack offers a subset of the services and workloads that Windows Azure offers. So far there are Web Sites, VMs, SQL and Service Bus. But that’s not all, there is room for more. The WAP is built in a way that allows you to plug more and more services into the Windows Azure Pack.

Now, the Service Management API is where it`s getting interesting. The Service Management API is an implementation of the Windows Azure Service Management API that provides a consistent consumer API that refers to the WAP fabric underneath. Even if the services running in the WAP are not implemented identically as in Windows Azure, the access through the Service Management API is consistent. The Service Management API abstracts the service running underneath. Having this Windows Azure consistent API allowed the reuse of the Windows Azure portal in the Window Azure Pack. It’s almost the same portal as used in Windows Azure. Without this consistent API I would not have been possible to move the Azure portal over to the WAP.

The portal in the WAP looks and feels very identical as the portal in Windows Azure. However, as a service provider you are still able to adjust the portal the way you want it. Or if you don’t like the portal at all, you can use or build your own portal and use the required Management Service APIs.

Additionally to the end user portal view, there is a provider portal view. The provider portal allows the WAP administrator to configure the WAP infrastructure and to define offers (or in WAP terms: plans) that is assigned to an end user.




Looking at the high level architecture of Windows Azure and Windows Azure Pack, you can see that the foundation of the two is different, however the closer you go to the end user experience the close the two become. Most importantly, it’s not just about the user interface, but also about the management APIs that will allow the transition of the offered service and workload between the two. I would expect, that Microsoft is building more and more service and workloads into WAP and that the consistency between the two is getting closer and closer, even in the fabric level. I would not be surprised if the WAP will sometime be a role in Windows Server.


Gunter Danzeisen hat einen Abschluss in Informatik der Technischen Schule. Zusätzlich ist er zertifizierter Microsoft System Engineer (MCSE 2003) sowie zertifizierter Microsoft IT Professional (MCITP 2008).