In the previous posts about the Windows Azure Pack, we looked at what the Windows Azure Pack is and how it compares to Windows Azure.
Now, I am going to look at the components that make up the Windows Azure Pack. The components are the pieces of the Windows Azure Pack software that you need to install. As we previously saw, there are internet facing services that the WAP offers. Because of this, Microsoft designed the WAP in a way that allows to separate it’s services into components that can be place in different parts of you network. This is done mainly for security reasons. If you don’t offer the WAP service directly to the internet, you could also put all the components into your intranet. But still for scalability reasons, you would place the components onto multiple server. Here’s a diagram of the components:
Let’s briefly look at each of these components:
SQL Server: Of course you will need a database server that holds all the management information and configuration of you WAP environment. There will be multiple databases that the WAP setup will create for you.
WAP Admin Site and WAP Admin API
The WAP Admin Site and WAP Admin API allows the WAP administrator to administer and to maintain der WAP infrastructure. There the Admin would add the VM clouds, the web site clouds, the mySQL or SQL server services and would manage them via Site and the APIs. The admins create bundles of these services and put them into plans, which they can offer to consumers as subscriptions. The plans contain the services with their restrictions and quotas.
The WAP admin Site is the WAP Admin portal talks directly to the WAP Admin API and exposes this management functionality.
The Tenant API provides the functionality that the Tenant Site needs to execute the required management tasks. It’s also used to create the subscriptions for the tenants, where the they define what services they want to subscribe to. Therefore, it’s placed into the high privileged service area.
The Tenant Site basically is the portal for the end user that allows the end user to subscribe to your plans and to create and manages their resources. This Tenant Site portal talks directly to the Tenant API in order to do this.
Tenant Public API
The Tenant Public API allows API access to create and maintain resources in the realm of a particular subscription. So you can use these APIs to create applications that manages your resources directly from the application without the need to use the Tenant site.
Tenant Authentication Site
The Tenant authentication Site is a build-in mechanism to allows ASP membership users to authenticate against this site. You can simple create users based on email addresses for the authentication into the WAP.
So far, we have looked at the internal components of the WAP system. These components build the framework for the workloads or services you want to offer using the WAP. In the previous posts we have looked at the different services that you can offer with WAP which are called Providers in WAP terms. In the diagram above, I listed Web Sites, Service Bus and VMs. Some of these Providers are installed out-of-the-box when you install the WAP system, other must be installed manually.
Identity Federation is the key components to make the WAP enterprise ready. With ADFS you can plug in different identity providers that can be used for the WAP system. In an enterprise, you would use Active Directory so that your customers can use their Active Directory credentials to log in to the tenant site and the administrators to log in to the admin site.
Scale-out and High Availability
Now that we have very briefly looked at all the components that make up the WAP system, there is still the question about scale-out and high availability. Generally, you should scale-out the components that gets the most traffic. These are normally the tenant components. Additionally for high availability, all tiers of the WAP system should be made highly available if the services are critical to your business.
There are many components to the WAP system. Theoretically you can install all of them on the same server. However, scalability reasons, you should distribute them onto multiple systems. Additionally, if you want to provide WAP services to the internet, you would separate the tenant components from the admin components. If you want to provide WAP services only to your internal enterprise customers, you want to set up ADFS and connect your Active Directory to the authentication site.
In the next post I will look at the installation of the WAP system.