Windows Azure Pack Framework Explained
With the launch of System Center 2012 R2, the System Center suite has evolved yet again. In my first post, I began with a look at an overview of System Center, as we investigated the different components that have come and gone over the years. Adopted into this suite as part of the R2 wave we introduced the Windows Azure Pack (WAP), which I described in my second post. Today I’ll go over the Windows Azure Pack (WAP) framework.
WAP Framework: Introduction
On its initial public reveal this component was not officially part of the suite and was offered primarily for use by hosters. After a lot of persistence – mostly attributed to the horrible track experience of its predecessor components, which included Dynamic Datacenter Toolkit for Hosters, SCVMM 2008 Portal, SCVMM Self-Service Portal 2.0 (SSP), and the System Center 2012 SP1 Cloud Services Process Pack.
This “pack” is truly a framework build to mirror the same technology framework that is currently implemented on the Microsoft Azure platform exposed as the Self Service Experience. There is one key different in this framework in that the new pack has added an additional portal and supporting APIs, which are used to offer an administrative experience for working with the portal. Both the User and Administrative portals and the APIs are fully documented, customizable, and extensible. Microsoft are already offering an SDK that contains a number of samples to get us started with the emblements.
We will take this one step at a time. Before we start considering extending the framework, we will start with what we have been provided by Microsoft.
In an earlier post, we determined that there are seven main components to a WAP framework; while accurate, these components form the framework’s foundational functionality. There are a number of additional components that are delivered as part of this release, including authentication and usage services to allow us to integrate with other services such as ADFS for both on- and off-premise authentication, or Cloud Cruiser for billing service. In the coming posts we will clear up the purpose of each of these components and dismiss the myth of requiring seven machines before we can deploy the Windows Azure Portal – rest assured, one machine is more than enough.
The graphic below, is based on a Microsoft illustration created to help us visualize the WAP Portal and the rest of its framework. These are depicted as both the Service Management Portal, and the Service Management API. In some upcoming posts we will explore these portals, API, and comprising components in great detail – and, of course, install an environment with which to get acquainted.
Below the Service Management API layer, in this modified version of the graphic we are able to observe the main extensions Microsoft have made available with the R2 version of the pack, including support for provisioning websites, virtual machines, databases from both MS SQL and MySQL, PowerShell workflow-based Service Management Automation, and an on-premise implementation of the Azure Service Bus.
Based on the architecture of the framework, these extensions can be enabled at will, and over time additional extensions will be provided either from Microsoft, or they’ll be developed based on the published API and Software Development Kit. Microsoft have stated that where appropriate service extensions currently available in Windows Azure may be ported back to the WAP.
Each extensions is structured to a defined pattern, exposing an API that will integrate with the Service Management API. These APIs are not new to us, as we have previously observed the API with the ODATA interface for Orchestrator, and the Service Provider Framework, which was introduced with System Center 2012 SP1.
The Windows Azure Pack is a very important addition to System Center 2012 R2, and we will spend quite some time covering all of the functions and features hidden in this amazing framework as we investigate the latest changes to the Windows Server System Center ecosystems.