Upcoming Webinar
Cayosoft Shows How Forest Recovery Tech Addresses Survey Issues
Join this webinar and not only learn about what your peers are doing, but also learn about a new patent-pending modern approach to AD forest recovery from Cayosoft.
New episode!
The Scoop on Loop: The Latest Innovations Directly From Microsoft!
Darrell Webster speaks to Rebecca Keys, a Program Manager from the Microsoft Loop team.
Turn Data Protection into an MRR Growth Engine
Security for your customers, revenue for your MSP practice. Access key insights on how to scale your practice with SkyKick’s new eGuide.
MSP eGuide to Package, Sell and Deliver M365 Security Services
Based on input from our top-performing MSPs, SkyKick prepared the MSP Guide to help you navigate the security landscape.

Windows Azure Pack (WAP) Framework Components

In our previous post on Windows Azure Pack (WAP) Framework we spent some time presenting the role in which the Windows Azure Pack plays in System Center 2012 R2 as we begin to start truly delivering solutions as services to our customers. In this post we will take a much closer look at the core components that form the framework of the Windows Azure Pack, and attempt to demystify and explain the seven-server requirement needed to host the framework.

Windows Azure Pack Framework Components

The framework is comprised of a number APIs, which are all delivered through the Web Platform Installer. In total there are five primary APIs used in the core of the framework.

Tenant API
Tenant Public API
Tenant Authentication API
Admin API
Admin Authentication API

The configuration details for all of the APIs is stored in a MS SQL server set of databases. This is accomplished by using an additional site, which is automatically installed as a dependency when the platform installer is used to deploy one or more roles to a server. The configuration site is hosted by default on port 30100 of each server to which a component is deployed. Launch the configuration site; the wizard will ask for the details to access to configuration database, and it will then automatically bind the installed components to the installation. For every additional server you add, simply repeating this procedure will bind the hosted components into the framework.

An immediate benefit of this flexibility is the ability to deploy the framework on as little or as many hosts as you believe necessary to address the scale of your WAP deployment. Also, since the procedure to scale out the deployed is straightforward you can easily start small and grow the environment. All the components are simply IIS websites and are fully support normal load balancing technologies – again, scaling up from one instance.

Components Architecture

The following graphic is designed to help illustrate the relationship between the different APIs and their common hosting SQL database. (WAP supports the ability to deliver MS SQL databases to its consumers – these are not normally hosted in the same instance as the configuration databases for security.)

The five primary APIs maybe deployed in a consolidated single server installation or spread over multiple servers; these APIs can be consumed by customized portals – including services like cPanel and Plesk – which are often utilized by hosters, or bespoke implementations for large enterprises. All the APIs used are fully documented and use standard Rest / JSON interfaces.

Portals

In addition to the five APIs, the WAP solution also includes two preconfigured portals – the tenant portal and the administration portal – both of which are developed as HTML5 applications and are fully extensible using the Service Management API Samples and SDK.

The design of these portals is based on Windows Azure portal and using the above kit, we can also brand the portal as desired to match our organization. A sample theme is also provided in the kit.

Firewalls

The pack is designed to be utilized by both hosters and corporate with the ability to deliver services to our users from both within and outside the boundaries of the elusive firewall. In the case of delivering services to users over the Internet, two of the APIs must be available publically and should be secured using SSL technologies, in addition to the users portal. The components to be exposed outside the firewall are:

Tenant Portal
Tenant Public API
Tenant Authentication API

Providers

In the previous post we discussed the ability of using the WAP environment to deliver multiple services, spanning from virtual machines, websites, and databases. Each of these different services are essentially an extension of the core framework, and are delivered as an extension services “provider.” Over time we can expect Microsoft to enable additional providers, although likely not close to the same cadence as providers are updated and added on the Azure Portal. Through the use of the Service Management API, you can also develop your own providers.

WAP and Getting Started

If there was any doubt in your mind of the requirement for seven servers to deploy an instance of the WAP portal, we should have this addressed. The original reason for the large number of servers is a by-product of the first public release of WAP, previously called Windows Azure Services for Windows Server, which was targeted primary at hosters and was based on their requirement for scale.

As an added incentive, the Web Platform Installer offers an express installation, which will deploy all seven of the core components of the Windows Azure Pack to a single server, including all dependencies ranging from PowerShell Modules to the Configuration site. Simply prepare a new Windows Server 2012 R2 machine, add the IIS component, and allow the Web Platform Installer get you up and running in short time.