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.
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
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.
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.
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.
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
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.