Azure Stack Validation Environment – Part 2: Quotas, Plans, and Offers

Artykuł
11/16/2017

Azure Stack

Building an end-to-end validation environment

Part 2: Quotas, Plans, and Offers

By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.

Azure Customer Advisory Team (AzureCAT)

This article is Part 2 in the Azure Stack Validation Environment series:

Part 1: Overview
Part 2: Quotas, Plans, and Offers (this article)
Part 3: Subscriptions
Part 4: Services and Resource Manager
Part 5: Putting it all together

E-Book - This series of blog posts is available as an e-book on Azure.com:

Azure Stack: Building an end-to-end validation environment

Quotas, plans, and offers

The bulk of the design decisions you need to make once Azure Stack is installed are related to the configuration of the services offered to your users. In Azure, services are designed, deployed, and offered to various regions by Microsoft engineers and administrators. In Azure Stack, the cloud operator deploys these services and makes them available to subscribed users using quotas, plans, and offers. Each of these elements is connected and defines both the capabilities and quantities that users can consume. The related items required to offer services in Azure Stack include regions, subscriptions, services, offers, plans, and quotas.

Quotas determine the amount of resources a user can consume.
Plans allow administrators to group services and their quotas to be offered to users.
Offers allow administrators to group plans to be offered to users.

Figure 6 shows a diagram outlining how these elements interact.

Figure 6: Quotas, plans, and offers in Azure Stack

There are some basic steps you must follow when designing your solutions in Azure Stack:

Deploy the Azure services you want to deliver to your users.
Create quotas to define the amount of resources you want users to be able to consume from these services.
Create plans that contain the desired services and applicable quotas.
Create offers that align to the plans.
Create add-on plans as needed.

Once you have completed this, your users can create subscriptions aligned to the offers you have created. Let's dive into each of these components, look at how each works, and identify some things you will want to keep in mind when offering services on Azure Stack.

Quotas

After you have identified the services you wish to offer to your users (see Services), you need to determine how much of each service your users may consume. To do this in Azure Stack, you must configure quotas for each resource provider. Note that you can set only the upper limits for quotas.

It is critical to keep in mind the amounts of each resource, such as storage and public IPs, that you have available in your environment, and how much quota is assigned. This awareness ensures you do not exceed capacity unexpectedly. A basic view of capacity within the infrastructure can be reviewed in the Administrative portal by selecting Region Management > Local (Region) > Resource Providers, and selecting Capacity.

Figure 7: Capacity within the infrastructure as seen in the Administrative portal

Additionally, you can review the configured quotas by selecting each resource provider.

Resource Provider	Configurable Quotas	Default Quotas
Compute	Yes	Default
Key Vault	No	Unlimited
Network	Yes	Default
Storage	Yes	Default
MySQL	Yes	None
SQL	Yes	Default BasicDefault StandardDefault PremiumDefault Admin
App Service	Yes	Default

In most cases, you will have several different quotas that align to the needs of different business groups or customers. Several resource providers offer a default set of quotas, which often have the maximum amount of resources available that can be configured for a resource provider.

NOTE: Quotas may not necessarily align with the actual resources available in your Azure Stack environment.

It is highly recommended that you review the default quotas and add your own to meet your organization’s needs best. For example, your organization may want to configure quotas based on the various business units that consume resources, for instance, to have specific quotas for developers. You may also choose to configure quotas based on a specific application.

When defining your quotas, keep in mind the following:

Infrastructure resources: The amount of compute, storage, and network resources available in your Azure Stack environment.
Resource providers installed: Each resource provider, except Key Vault, has quotas that must be configured. All resource providers consume at minimum compute, network, and storage resources.
Number of subscriptions: Each subscription consumes resources, most notably compute, storage, and network. Depending upon the services offered to them, they could also consume other resources, such as SQL databases. It’s important to keep track of your total allocation of resources and services across subscriptions.
User requirements: Designing quotas specific to an application is a relatively easy process because the compute, storage, and network requirements of the application are known. To create quotas for groups of users, you should understand their resource usage patterns: whether they deploy a set of resources with limited growth or with a predictable growth rate, and if they tend to be volatile users, like developers—deploying and deleting on a regular basis.
Applications: Each application instance requires a specific group of resource providers and a known amount of resources. This quota tends to be the easiest one to define.

Defining quotas typically requires discussions with the various user groups within an enterprise, including developers of the applications consuming these services to precisely determine their needs. In most cases, it is recommended that this is periodically reviewed as usage patterns change or new services are offered in your Azure Stack environment. For service providers, defining quotas is more aligned to the offerings you would like to make available to the customer base.

Although you can create quotas at the same time you define your plans, we recommend creating quotas separately. This way, you can be sure to deploy exactly the quotas you need.

Read the article Plan, offer, quota, and subscription overview for step-by-step instructions when you are ready to configure quotas.

Plans

You use plans to create the groupings of services offered to users, along with their applicable quotas. Most designs include more than one plan. Each plan is tied to a specific set of quotas based on the services offered in that plan.

The first step to designing your plans is to understand the following:

Services to be included in each plan.
Differences between how these services are provided to users.
Users who will access each plan.
Whether users are assigned to specific plans and offers, or you advertise them instead.
Quota limits required for each service in a plan.

You can configure users to consume one plan or multiple plans within a single subscription. This option may be beneficial when a user requires more or different services that are not offered within a single plan or these services are differentiated in some way such as quota, performance, and capability.

Two distinct types of plans can be configured on Azure Stack:

Base plan: Contains the core services to be offered to customers.

o One base plan can be added per offer.

Add-on plan: Contains additional services that can be added to a base plan.

o Used to extend compute/storage/network to a base plan.

o Can add multiple add-ons to a base plan.

o Cannot be used in an offer by itself. To do this, it would need to be created as a base plan.

For a service provider, add-on plans could be upgrade offerings to a base plan. Although combining everything in a single plan may be optimal in some cases, you may want to have a base plan, and offer additional services using add-on plans. For instance, a service provider could decide to offer IaaS services as part of its base plans, with all PaaS services treated as add-on plans with additional charges or to upsell additional services. Similarly, a small organization might decide that one base plan is sufficient, but also offer SQL as an add-on to select users, or for select applications that require it.

Plans can also be used to control consumption of resources in your environment. For example, if you want your users to be mindful of their resource usage, you could have a relatively small base plan (depending on the services required) and as users reach capacity, they would be alerted that they have already consumed the allocation of resources based on their assigned plan. From there, the users may select an available add-on plan for additional resources.

Naming and organizing plans

Like other Azure services, establishing a naming standard within your organization is recommended when configuring plans. Among other benefits, this allows you to easily identify its purpose and track the use of defined plans. Plans have both a display name and a resource name, where the resource name may not contain spaces and must consist of letters, numbers, and a small set of nonalphanumeric characters. Figure 8 shows an example of the creation and naming of a new plan.

Figure 8: Creation and naming of a new plan as seen in Administration Portal

While naming conventions are subjective, it is recommended to include the type of plan, business unit, sizing, customer name, or the application for which the plan is designed. Below are a few high-level examples of plans. You can modify them to fit your specific needs. These examples show base plans only; add-on plans could easily be included.

Figure 9: Enterprise business unit-based plans

An enterprise may organize its plans based on departments, as shown in Figure 9.

Figure 10: Enterprise application-based plans

The example in Figure 10 is based on applications deployed within Azure Stack that are available across business units within an organization.

Figure 11: Service provider-based plans

Figure 11 shows a service provider example that represents customers accessing a service provider infrastructure to obtain IaaS/PaaS services.

As you can see from the above examples, plans can get quite complex. Each plan you create has some administration required, and as you add more plan options, the planning calculations for resource consumption become more difficult.

Read the article Create a plan in Azure Stack for more information and step-by-step instructions.

Offers

Your users access the resources they require by selecting an offer when creating a subscription. When an Azure Stack user uses the portal to sign up for a new subscription, they can only select a single offer. Once the subscription is created, they can select additional add-on plans. As an Azure Stack operator, you create the add-on plans and make them available, so your users can get the additional resources they require for their solutions.

At a minimum, an offer must contain at least one base plan. You can add multiple base plans and add-on plans to an offer, providing the users who consume this offer with exactly the resources they require. All users subscribed to a specific offer have access to the plans and associated quotas that are contained in the offer.

When creating a subscription, you must align it to an offer. Thus, the offers and plans that you want to align to your various subscriptions must be in place first.

Read the article Create an offer in Azure Stack for more information and step-by-step instructions.

Private and public offers

Offers can have one of three states: public, private, or decommissioned. An important decision is whether your offers are private or public. By default, all new offers are set to a private state. The choice to leave an offer private and assign user subscriptions to it is up to the administrator creating this offer. One reason to maintain an offer as private is to ensure that administrative oversight is required to subscribe to specific offerings (see Advertised and assigned offers). User subscriptions must be assigned to private offers by the cloud administrators, increasing the workload to manage this on an ongoing basis. To help mitigate this, you can use delegation (see Delegation), in combination with private offers, to assign the rights necessary to make delegated offers available to users.

When you make an offer public, all users can see and select it when they sign up for a subscription. It is the simplest method of providing offers that will be visible to all of your users when creating subscriptions.

Decommissioned offers are an important part of planning the lifecycle of an offer or set of offers in your Azure Stack environment. Decommissioned offers are those offers that are available to existing subscribers, but new subscriptions are unable to select. As you plan the long-term use of your offers, you may wish to transition users from an originally designed offer to new offers in your environment. Discontinuing additional use of the original offers while maintaining service for existing users of those offers is key towards maintaining continuity of service for your users.

Advertised and assigned offers

Offers can either be advertised or assigned. When you make an offer advertised, it is visible to all users accessing the portal and follows the self-service model for obtaining services. Therefore any user with rights to access the portal can add an advertised plan to a subscription. Advertised offers must be set to public state as outlined above.

To create a subscription and configure an advertised offer, follow the instructions in Subscribe to an offer.

Assigning offers allows you to configure multiple offers that are not visible to your users and perform directed assignment to support your desired usage pattern. For users to access the offer, you must assign their user ID to the offer. Once assigned, a user will see the new subscription and have access to the resources and quotas aligned to the offer when they access the portal.

Cases where assigning offers will benefit you:

As a service provider, you want to assign company specific offers to customers.
Within an enterprise, you want to ensure only users of a specific business unit have access to an offer.
You want to manage tightly the resources that users can consume.

As mentioned earlier, there is an overhead to this approach as every user must be assigned to the applicable offers by an Azure Stack operator. You should carefully think before you define your offers as assigned and depending on your ability to manage this on an ongoing basis, use this approach in a limited fashion.

Delegation

Delegation provides the ability to put other non-administrative users in charge of creating offers and signing up users based on offers that the Azure Stack operator defines. As a service provider, you may want to offload the creation of offers and signing up users to authorized resellers that are purchasing your services. In an enterprise, you can delegate the same ability to add users and create offers to the various divisions, or subsidiaries. This offloads to local resources the day-to-day operations of the administrator tasked with operating Azure Stack.

Configuring delegation is relatively easy, with significant benefits for the operator. There are three roles used when setting up delegation:

Azure Stack Operators: An administrative user who manages the Azure Stack infrastructure, creates an offer template, and delegates the offer to others.
Delegated Provider : A standard user who creates offers based on the delegated offer and assigns users to subscriptions.
Azure Stack Users: A standard user who signs up for offers, or can be assigned the offers.

Figure 12 shows a diagram of how the delegation process works:

Figure 12: Delegation process

Read the article Delegating offers in Azure Stack for step-by-step instructions on configuring delegation.

Figure 13: Properties and custom URL created when configuring delegation

Important points

Role-Based Access Control (RBAC) can be configured to secure access to these (and other) resources.
Any changes to offers apply to all users consuming the offer.
Offers that are public are visible to all users.
Quotas can be configured that exceed the capacity of your infrastructure, causing the provider to run out of resources.
Additional capacity can be applied to a quota. However, users already consuming the current plan and quota will not see the updates for up to an hour.
When a user adds an add-on to an existing subscription, the additional resources could take up to an hour to appear.
To add resources immediately, you may need to configure a new add-on for users to consume.
When a user runs out of capacity, they receive errors as they try to create new resources within their subscription.
To change plans, users require a new subscription.
When a plan or offer is decommissioned, users already consuming the plan and quotas continue to have access to those resources.
When a plan or offer is removed, users already consuming the plan and quotas continue to have access to those resources.
If you change a quota amount to reduce it, users already consuming more than the new quota amount continue to receive the quota they already are consuming but are not able to add more resources.
Changes to a quota, plan, or offer are global and impact all users.