First published on MSDN on Nov 14, 2017
Part 1: Overview
By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.
Azure Customer Advisory Team (AzureCAT)
This article is Part 1 in the Azure Stack Validation Environment series:
E-Book - This series of blog posts is available as an e-book on Azure.com:
Azure Stack is an extension of Azure, bringing the agility and fast-paced innovation of cloud computing to on-premises environments. Organizations can now build modern applications across hybrid cloud environments, balancing the right amount of flexibility and control. Building a validation environment is critical to the success of any deployment of Azure Stack as it helps lay the foundation for cloud architects, operators, and developers within your organization as they plan their environment. Azure Stack differs from traditional on-premises virtualization solutions in four key areas:
In this guide, we will provide you with the necessary information to help you plan for the end-to-end Azure Stack validation environment using the Azure Stack Development Kit. We will cover many of the core concepts required to build a functional Azure Stack environment, including subscriptions, services, quotas, plans, and offers. You will learn about the constructs and configurable options available in Azure Stack, and see how to tackle the key considerations that go into planning a successful implementation.
This content is based on our work with early adopter customers and is not intended to be prescriptive guidance. Our goal is to help you understand the foundational elements of Azure Stack to assist you in evaluation and planning. You will find information relevant to the following three scenarios:
To provide a truly hybrid environment for cloud developers, Azure Stack provides on-premises versions of several popular Azure Services. These services include the commonly referenced cloud computing models:
These models can be combined and integrated to build complex, robust solutions for different audiences and use cases. The combination of on-premises IaaS and PaaS services is the primary difference that Azure Stack can bring to your organization since Azure Stack extends these cloud-native services to your datacenter.
PaaS services in Azure Stack are fundamentally different than traditional on-premises virtualization solutions or platforms that host traditional operating systems for developers. They provide an Azure-consistent experience and API that can be consumed by your developers regardless if they exist on-premises or in Microsoft-owned datacenters. These services include App Service (which includes Azure Web Apps, Mobile Apps, API Apps, and Functions), Key Vault, SQL, and MySQL, to name a few. All Azure Stack PaaS services require IaaS to be in place to offer this service to your customers.
Within Azure, services are deployed by Microsoft within an Azure region and made available to subscriptions with defined service limits. In Azure Stack, you own the regional planning, deployment, and configuration of these services and the allocation of these services to your subscribed users. Azure Stack subscriptions, services, quotas, plans, and offers are the building blocks used to provide Azure Services to your users. These constructs are connected and define the capabilities and quantities that a user can consume. Figure 1 is a logical diagram of this interaction between these capabilities and shows what is available in a single region.
Figure 1: View of how components interact
A high-level overview of this relationship is as follows:
By selecting an offer, the services within the associated plan and the quotas assigned to those services are assigned to the user.
There are two key categories of Azure Stack deployments, each with many common decisions, but some individual considerations:
Customer-owned models (enterprise):
Service provider-managed models:
For both service provider scenarios, customers may choose to consume Azure services using an existing connection to the provider’s network or provide their own connection to these services. In most service provider scenarios, the Azure Stack subscription is created, owned, and managed by the service provider, but the customer consumes cloud services by interacting directly with the Azure Stack cloud footprint. The service provider may choose to provide managed services for the customer application workloads deployed on Azure Stack, but this is not required.
In Azure Stack, a scale unit is a defined collection of compute (servers), storage, and networking that represents a unit of capacity expansion, an Azure fault domain, and a homogenous set of hardware. A scale unit is always associated with a single Azure Stack region, and in future updates, scale units can be combined within a given region for enhanced scalability.
Azure Stack uses regions to represent sets of scale units that share a common physical location and are logically managed by a single administrative entity. Multiple regions are optional; you may, for instance, decide to deploy a single Azure Stack instance to meet your business requirements. However, if you have multiple locations and datacenters, or you need to separate the services you offer for compliance reasons, you can elect to have multiple regions in your solution.
In Azure, regions are service-defined boundaries that help users make decisions about where they host workloads within the public cloud. Azure Stack brings new flexibility to both enterprises and service providers, by allowing you to define regions based on your organization’s or customer’s needs.
Regions allow you to architect your Azure Stack solution to physically manage the delivery of services and applications in a way that is visibly exposed to your users. Regions enable you to deliver services with the following factors in mind:
Like Azure, many of the capabilities in Azure Stack are region dependent. For instance, marketplace items, role-based access, resource providers, quotas, offers, plans, and resource groups are deployed on a per-region basis. You can configure users to access multiple regions and different services in each, however, when you do this consider latency and workload segregation requirements.
As you design your Azure Stack solution, it is important to understand the number of regions and their placement, as well as the user base that will access each. As new functionality is released, and regions become available, your early planning will allow you to quickly add the regions you require.
An Azure Stack cloud is a single instance of Azure Resource Manager and defines a delineation of management in an Azure Stack deployment. A cloud may contain one or more regions consisting of one or more scale units that are managed under a single set of Resource Manager endpoints. These can be retrieved by enumerating the endpoints and metadata associated with the Azure Stack instance of Azure Services using the PowerShell cmdlet Get-AzureRMEnvironment , as illustrated below in Figure 2.
Figure 2: Using the PowerShell cmdlet Get-AzureRMEnvironment
The relationship of each of these elements (scale unit, region, and cloud), using a single region, is shown in the diagram in Figure 3.
Figure 3. The relationship between regions, clouds, and scale units
Azure Stack has two general types of users:
By default, the Azure Active Directory (Azure AD) account that you use to deploy Azure Stack, will become the primary management account. This account will also be the subscription owner for the "Default Provider Subscription." It is recommended that additional management users be added with rights to manage Azure Stack via the portal or PowerShell.
The administrator used in delegation scenarios is a user account with increased rights enabling the management and configuration of delegated offers for their users. Traditionally, delegated administrators should be part of your overall Azure Stack design. To add additional Azure Stack operators, they must be configured in the Default Provider Subscription as subscription admins. Three levels of delegated rights are available:
|NOTE: By default, the user that signs up for a subscription will become a subscription administrator.|
The Azure Marketplace in Azure Stack is the location where your users will access Azure Stack resources. Items that are available to Azure Stack users in the Marketplace include, but are not limited to, virtual machines, networking components, storage, databases, and websites, depending on the resource providers installed. The four types of offerings you can bring to market on Azure Stack for your users are:
Users are presented Azure services based on the subscribed offers that have been defined by their Azure Stack administrator. Figure 4 shows a user’s view of the Marketplace in Azure Stack.
Figure 4: User’s view of the Marketplace in Azure Stack
Administrators can also use Marketplace to provision Azure resources in the Default Provider Subscription to support your internal operations. For your users, however, the items that are available are either provided through installed resource providers, custom images, or syndicated items from the commercial Azure Marketplace. You can think of the Marketplace as the catalog of all the items that are available for selection by a user. When designing Marketplace, you first need to determine the requirements of your users. In an enterprise, you will likely need to contact the various business units to determine their use cases and requirements for Azure services. For service providers, you need to consider the needs of your specific customer base.
To provide Azure Marketplace items, they must be syndicated through Marketplace by the Azure Stack operator. Getting syndicated requires Azure Stack registration with a public Azure subscription. Registration of Azure Stack with Azure can be performed using an online or offline process. For Azure Stack operators, this is one of the first steps that should be performed after Azure Stack is initially deployed. Once added, Marketplace items can be made accessible to Azure Stack subscription users through Marketplace management. The types of items that can be syndicated from Azure include virtual machine images, virtual machine extensions, and vendor pre-built solutions. Figure 5 shows the Administrator’s view of Marketplace management in Azure Stack.
Figure 5: Administrator’s view of Marketplace management in Azure Stack
In addition to syndicated items from Azure, you may have custom virtual machine images that contain configurations and settings that are specific to your organization’s users. You can easily add things like Linux images, additional operating system virtual machine images, and custom images to the Marketplace without using the syndication feature. Read Deploy Linux virtual machines on Azure Stack for information on adding Linux images, as well as instructions to create your own Linux image.
An important point to consider is that all Marketplace items are visible to all subscribed users in Azure Stack. You can regulate this to a certain degree when you design your offers and plans, but it requires careful planning. For instance, if a specific set of users does not need access to deploy SQL databases, you can create an offer that does not include that service. You must also ensure that all offers are not public.
For deployment of Marketplace resources in Azure Stack, you may also be able to use the templates available for Azure. Resource Manager templates allow you to declaratively describe the resources that are deployed to an Azure resource group. The easiest way to do this is to use Azure Stack-specific Resource Manager templates . However, each template must be reviewed carefully to ensure the parameters, variables, resources, and schema match those that are available in the current version of Azure Stack. To assist with rationalizing the differences between Azure and Azure Stack Resource Manager templates, a template validation tool is available in the Azure Stack tools repository . The template validation tool provides offline analysis of a specified Resource Manager template and provides reporting on potential compatibility challenges between the template’s use across Azure and Azure Stack environments.
For more information on the Marketplace, please see the following resources:
One of the most important design goals for Azure Stack is providing consistency with Azure to support an unparalleled hybrid experience for organizations that are looking to embrace and leverage Azure Services across premises. The consistency between Azure and Azure Stack is built at the API level, so you can use familiar tools to build solutions and manage Azure Stack including the Azure portal in Azure Stack, Azure PowerShell, the Azure cross-platform command line tools (CLI), Visual Studio, or the Azure API natively.
The portal is an excellent way to start using both Azure and Azure Stack and remains a good option for experimenting and performing one-off tasks. By contrast, command line tools excel as you move towards a more DevOps approach to managing your applications and services in an automated fashion.
The portal allows administrators to do the following:
· Manage access.
· Manage accounts.
· Manage subscriptions.
· View usage summary.
· Provision/de-provision Azure Stack resource providers.
· Create plans and offers.
· Manage co-administrators on subscriptions.
· View the health of Azure Stack.
The portal is the method most users will use to initially access the services and solutions you offer in Azure Stack. Once the user logs in, the portal is "scoped" based on their credential and the access rights you have defined for that user. For example, a general user will access the portal and sign up for a subscription to begin to consume Azure services from your instance of Azure Stack. Based on the plan and quota parameters you define, they will be given access to compute, storage, and network resources. These are the minimum services required to be able to deploy a virtual machine, storage account, or network as a user. Additional resource providers can be added, such as SQL Server resource provider, and access for your users provided via plans.
Users will be able to sign up for subscriptions through the offers created by the administrator and deploy compute, network, and storage as well as any other enabled services.
For information on using PowerShell and cross-platform command line tools, please see the following resources:
This article is Part 1 in the Azure Stack Validation Environment series:
The next article in this series is Part 2: Quotas, Plans, and Offers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.