ARM concepts in Azure Stack for the WAP Administrator — Offers, Plans, and Subscriptions
Hello Readers! This blog is part 3 of the series "ARM concepts in Azure Stack for the WAP Administrator." In this post we'll discuss how the plans, subscriptions, and add-ons concepts you are familiar with in Windows Azure Pack (WAP) map to the brand-new Microsoft Azure Stack Technical Preview 1.
Note Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
I'm including the table of contents for this series of post so that you'll find it easier to navigate across the series:
Table of contents
- Introductory post, and some first information on the Azure Stack POC architecture and ARM's role
- Cloud Service Delivery
- Plans, offers, and subscriptions—this post
- Resource deployment methods using the portal, Visual Studio, APIs, or CLI
- Packaging and publishing templates on Azure Stack
- Multi-tier applications with ARM
- In-guest configuration with ARM, and technologies such as Virtual Machines Extensions, including PowerShell Desired State Configuration (DSC)
- Troubleshooting IaaS deployments in Azure Stack
We will update the post with links to the new posts, as we publish them. With no more delay, let's get started!
Plans, Subscriptions, and Add-ons in WAP
A service administrator in Windows Azure Pack (WAP) makes cloud services available to tenants via a plan. A plan defines two major items:
- The service or services offered to the tenant (for example, virtual machines, SQL databases or websites).
- Quotas for the services offered (for example, create up to 5 virtual machines, or deploy up to 5 SQL databases).
A plan can have one or more add-ons, which are optional services offered to tenants. Tenants can choose to include add-ons in their subscription, or not. An add-on can increase the quota of existing services in the plan, but it cannot provide any additional services not available in the plan.
Tenants consume the cloud services defined in the plan via a subscription. The tenant can subscribe to a plan and add-ons if the plan is public, or the service administrator can create subscriptions for tenants when the plan is private. Each subscription is associated with only one plan, but a tenant can subscribe to one or more plans.
Let's assume that a WAP service administrator wants to offer three new IaaS plans to tenants: Bronze, Silver, and Gold. The difference between the plans is the quotas assigned to them. In this example, the Bronze plan has a quota of 3 VMs, Silver has a quota of 15 VMs, and the Gold plan has a quota of 50 VMs. The administrator will also create a "Platinum" add-on that increases the plan quotas by 25 VMs, and also gives access to both Windows and Linux VM roles. When a tenant subscribes to one of the plans they will have the option to choose the Platinum add-on.
To create the plans and add-on, the service administrator needs to do the following:
- Create a new plan and add the Virtual Machine Clouds service.
- Configure the Virtual Machine Clouds service by indicating the VMM server, the virtual machine cloud, and the quotas for the plan.
- Steps 1 and 2 are repeated as many times as necessary; in our example, the administrator will need to create and configure three plans.
- Create one or more add-ons to increase quotas or offer premium items and link them to the plan.
The picture below shows the three plans in WAP:
The same procedure would apply if the WAP service administrator would like to offer other cloud services, such as websites, just making sure that the additional cloud services are selected in step 1 above and also that service and quotas are properly configured.
To subscribe to the Bronze plan, the tenant just needs to select it from the Add Subscription wizard in the WAP tenant portal as described in the screenshot below:
Once subscribed, the tenant will have access to the cloud services defined and configured in the plan. In this example, the tenant will have access to the Virtual Machine Clouds service in the WAP tenant portal, and the tenant can acquire add-ons published by the service administrator as shown in the example below:
After the subscription is created, the tenant can provision cloud resources via the WAP portal:
Now that we have looked at how plans and subscriptions work in WAP, let's take a look at how that compares to Azure Stack.
Offers, Plans, Subscriptions, and Add-on Plans in Azure Stack
Microsoft Azure Stack provides great flexibility for service administrators to provide cloud services to tenants. In Azure Stack, service administrators make cloud services available to tenants via an offer. An offer is defined as one or more base plans, and optionally, one or more add-on plans.
Plans in Azure Stack can function as a base plan or as an add-on plan. A base plan in Azure Stack is basically the same as the quotas you get with a plan in WAP (quotas in base plans are included by default when a tenant subscribes to the offer). Add-on plans in Azure Stack are similar to add-ons in WAP, with the key difference that add-on plans in Azure Stack can be used as a base plan or as an add-on plan.
Tenants consume the cloud services defined in the offer via a subscription. Tenants can subscribe to multiple offers, but please note that each subscription applies to only one offer.
The relationship of plans to an offer is depicted in the picture below. The add-on plans are shown with dashed lines to indicate that they're optional.
An Azure Stack plan defines the services being made available to tenants, the region where the tenants will use those services, and the quotas for the services. In other words:
- A plan can consist of one or more services
- The service can be available in one or more regions
- Quotas must be defined for each service per region
Let's describe this in a picture:
In the picture above we can see the different components; let's review them in detail:
Services represent the cloud services to be offered to the tenant, such as compute, storage, or network.
Region is the Azure Stack location from which tenants can consume cloud services. This is the same concept we have in Microsoft Azure, where a region could be West Europe or East US, but in Azure Stack they could be Zurich, Paris, or Chicago, for example.
Note In the single-node Azure Stack Technical Preview 1 POC there's only one region: local.
Quotas define the limits of resources that a tenant can provision or consume. For example, a quota may allow a tenant to create up to five VMs. Quotas can be set to unlimited.
Note Only the Storage Resource Provider (SRP) quotas are enforced in Azure Stack Technical Preview 1.
For more information, see Services, plans, offers, and subscriptions in the Azure Stack Technical Preview documentation.
For a quick reference, the picture below depicts an offer created in Azure Stack (in this example, the Building Clouds Offer) by a service administrator, which includes a couple of base plans and one add-one plan.
And the picture below depicts a tenant subscription to the offer above, and that the tenant has included the add-on plan:
That's it! From here tenants can start deploying cloud resources in their Azure Stack subscriptions in the same was as they would do it in their public Azure subscription!
Conclusion
Microsoft Azure Stack provide a flexible model for service administrators to offer cloud services to tenants. In particular, plans as implemented in Azure Stack allow service administrators to expose services to tenants in a very flexible and granular way. The list below describes a few of the many possibilities:
- Create an offer with a single plan and in this plan all the services (compute, network, storage) are defined across all regions with unlimited quotas.
- Create an offer with multiple plans. Each plan defines a service (for example, one plan for compute, one for network, and one for storage) in all regions, with standard quotas. Then include an add-on plan to lift the quotas to unlimited.
- Create an offer with multiple plans. Each plan defines the services available per region (if you've three regions you define three plans). Then the quotas for the services are defined depending on the capabilities on each region.
- And many more!
I hope these examples are enough to give you an idea of the tremendous flexibility built into Azure Stack. In future blog posts my colleagues and I will be exploring some of the many options available to you.
We would love to hear your feedback on this topic. How are you planning to build your offers and plans in your Azure Stack environment?
Victor