First published on MSDN on Nov 22, 2017
Part 5: Putting it all together
By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.
Azure Customer Advisory Team (AzureCAT)
This article is Part 4 in the Azure Stack Validation Environment series:
E-Book - This series of blog posts is available as an e-book on Azure.com:
Now that we have reviewed the core capabilities and features of Azure Stack that are required to deliver services to your users, we’ll look at design decisions and then steps to building an end-to-end validation environment for your installation.
In our example, we will use an imaginary enterprise customer called Contoso. Like many enterprises, Contoso contains several business units which independently operate when consuming services from IT while still adhering to corporate IT standards. Figure 23 is a diagram of the high-level organizational model for Contoso. The company has four departments: Human Resources (HR), Finance, Information Technology (IT), and Development.
Figure 23. Contoso organizational design for this example
Contoso wants to deploy their first Azure Stack scale unit as a lab environment in a single datacenter to provide each business unit access to on-premises Azure services for their applications. Contoso envisions two primary users of Azure Stack, their IT department and their departments that align to the other business units within the organization. Contoso’s departments typically require different services or quantity of resources on the Azure Stack based on their application’s needs. At Contoso, HR and Finance both have specific applications that they require, and IT and Development use standard services as they build and deploy applications into the cloud. In addition to Azure marketplace images, Contoso’s departments are required to use internally certified operating system images for the development of their applications. Operationally, Contoso has established naming conventions for resources they provision in their datacenter, so they wish to extend similar requirements to resources deployed in Azure Stack. Aside from the benefits consistent naming provides towards achieving standardization, Contoso wants to ensure that resources created in the environment are traceable by department, operating system, and application. To help drive adoption of this new service, a trial offer should be made available to each department to support an early learning experience.
As we walk thru the design decisions in the following sections, we will refer to this business scenario and explore how different capabilities can be used to address Contoso’s needs. Keep in mind that while these decisions are specific to the creation of a lab, the same considerations are required when designing your production deployments.
In our example, we will focus on the customer-owned deployment model, based on Contoso’s primary business units. It is important that we understand the department’s applications and services because they will impact our design decisions. As we move through the process of designing the solution, we also need to consider the plans and offers that will be required by each of these departments, as well as determine how regions will be utilized when this functionality becomes available. Given that Contoso has a single datacenter we’ll focus on a single region deployment of Azure Stack.
An outline of the single-region deployment applications required by each group is listed below.
|local.azurestack.external||Human Resources||Multiple websites using a MySQL backend.|
|Finance||A single commercial off-the-shelf finance application using a backend SQL Database.|
|Information Technology||Core IT services, no specific applications.|
|Development||Responsible for maintenance and upgrades to the HR websites and the Finance application.
Investigating the inclusion of Key Vault capabilities to new applications.
To provide redundancy for administration, we will also add a second administrator to the Default Provider subscription.
|Region||Azure Stack Operators||Co-administrators|
Contoso has determined the following high-level goals when designing their subscriptions:
From a subscription perspective, Contoso will use a hybrid subscription model to support the distinct needs of their departments. HR and Finance will use a self-service subscription model publicly visible offers. In contrast, the IT and Development departments will have delegation enabled, so the subscriptions will be created for each business unit, and a delegated administrator will manage each teams’ user subscriptions.
Contoso has defined naming standards they require their users to follow and in the table below we have defined the naming for each department’s subscriptions. Based on those goals, we will use the following naming convention values which will be used in each subscription:
The following naming conventions will be used for each Azure Stack object type:
|Object Type||Naming Convention||Example|
|Subscription||[cloud]-[business unit]-Subscription-[optional: sequential number]||CAS-IT-Subscription-01|
|Quota||[cloud]-[resource provider or service name]- [optional: service tier]||CAS-AppSvc-Premium|
|Plan||[cloud]-[business unit]-Plan-[optional: sequential number]||CAS-IT-Plan|
|Add-on Plan||[cloud]-[resource provider or service name]-AO||CAS-KeyVault-AO|
|Offer||[cloud]-[business unit]-Offer-[optional: sequential number]||CAS-IT-Offer|
|Tag||[authorized tag name]: [authorized value]||Dept : CAS-IT|
Based on these goals and standards, the resulting design decisions are reflected in the following worksheet:
|Business Units||Subscription Name||Subscription Administrator|
|Information Technology||CAS-IT-Subscription||IT Admin|
To support a wide range of Azure services to each of the business units, additional resource providers will need to be deployed. We will include the following resource providers in our solution to enable provisioning of both IaaS and PaaS services to user subscriptions.
For Contoso’s business units to access services, we need to create offers and plans, and align quotas to each plan. When we design our offers, we must be aware of the services required by each business unit’s applications.
First, let’s review the needs of each of Contoso’s business units. HR has some websites that use MySQL as a backend database tier. To meet their application needs, they require the AppService and MySQL resource providers, as well as compute, storage, and networking resource providers. These websites do not use a lot of resources, so we will set quotas at 50% of the defaults; this will support both current and future needs and can be increased as required. Finance, on the other hand, relies heavily on an off-the-shelf cloud-ready application that uses SQL server as its database. Like HR, their usage is not projected to be overly heavy, so we will set quotas at 50% of the defaults. To support the needs of both HR and Finance, along with the default IaaS services, we will be required to deploy the optional SQL/MySQL resource providers.
Next, we can look at the needs of Contoso’s IT and Development division. Contoso’s IT department manages all the operational tasks required for their datacenter environment, as well as consuming resources for deployment and quality testing of the company’s applications. From a quota perspective, the IT department would be permitted to consume services using the default limits of each resource provider while development is restricted to 75% of the default values. IT is also responsible for ensuring that any custom images the company requires are made available in the marketplace. The Development department develops and maintains all the applications that Contoso requires. They work closely with IT on the release of these applications across the company. Both departments require all the IaaS services, as well as the additional resource providers accessed by HR and Finance. Development is looking to enable Key Vault capabilities for business applications in the future and will require this resource provider for applications which are under development.
Base offers and plans
The following goals have been identified when designing Contoso’s offers, plans, and quotas:
Based on these goals, the resulting design decisions are reflected in the following worksheet:
|Offers||Advertised /Assigned||Assigned Users||Plans||Base Services||Quota Name||Quota Limits|
|50% of defaults
|50% of defaults
|100% of Defaults
|75% of Defaults|
|2 virtual machines
4 x IP
|Add On Plans||Quotas||Quota Limits|
|App Service Plan||CAS-AppSrv-AO||CAS-AppSvc-Premium|
|Key Vault Plan||CAS-KeyVault-AO||Unlimited|
To provide their business units with the operating system images Contoso requires, we will download any available images using Azure Marketplace syndication and upload any custom images to Marketplace in Azure Stack.
Contoso has determined that for their Development subscriptions, they will assign an administrator to manage users and resources. They will also use a custom URL for their delegated site.
HR and Finance, however, will rely upon the IT team to provision offers to them and manage their users. Offers for both business units will be set to public , so they are visible to all the business units, and each will select the appropriate offer.
|Business Units||Delegated Administrator||Custom URL|
To support standardization of billing and the ability to trace resources back to their owners, Contoso will implement resource tags. Contoso will apply resource tags on each resource to identify business unit to enable chargeback or billing for each group and to identify any virtual machine operating system being deployed.
Resource tags associated with operating systems will be performed during provisioning. However, tagging of resources within the business units will be based upon corporate policy with the expectation users will tag their resources. Should resources without tags be found, the IT department can tag them using PowerShell.
Because there will be multiple administrators of the Azure Stack solution across the IT organization, we will use locks for all IT and Development offers to prevent accidental deletion.
|Tag Name||Tag Value||Tag Scope|
|Dept||CAS-Finance||All Finance resources|
|CAS-HR||All HR resources|
|CAS-IT||All IT resources|
|CAS-Dev||All Development resources|
|Operating System||WS2016||All Windows Server 2016 virtual machine resources|
|WS2012R2||All Windows Server 2012 R2 virtual machine resources|
|Application||Application name||Resource groups for each application|
|Lock Name||Locked Resource||Lock Value|
In the preceding sections, we created several tables of information based on design decisions that represent the high-level design for this lab. We will use that information to build a solution that delivers an enterprise Azure Stack environment following these steps.
Now that we have reviewed our design decisions based on our organization’s requirements, we can create the initial Azure Stack logical design. The diagram in Figure 24 shows an example of a finished solution that can be implemented as a validation environment with the Azure Stack Development Kit and in the production scale-unit deployment of Azure Stack.
Figure 24: Envisioned Contoso Azure Stack solution
Azure Stack extends the power of Azure to your organization’s datacenter, enabling development of hybrid solutions using Azure Services, and offering a range of new possibilities for your users’ applications and services. Like most IT solutions, you must carefully plan when implementing an Azure Stack deployment, so your users can get started developing applications quickly and easily.
In this article, we have discussed some of the key decisions you encounter around the topics of Azure subscriptions, quotas, plans, offers, and administrative role design. Next, we use these decisions to model an environment with the Azure Stack Development Kit, enabling users and developers to gain hands-on experience prior to the deployment of your first Azure Stack scale unit.
We hope this has provided you with the necessary information to help your organization get the most out of Azure Stack.
For more information, see the following resources:
This article is Part 5 in the Azure Stack Validation Environment series:
That's the conclusion of our series! For the eBook download, see Azure Stack: Building an end-to-end validation environment .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.