Azure Stack Validation Environment - Part 1: Overview

  • Article

Azure Stack

Building an end-to-end validation environment

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:

Introduction

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:

  • Hardware and Software Modernization. Organizations familiar with traditional storage and networking solutions need to learn how software-defined networking and storage models will affect IT service delivery.
  • Workload Composition. You will need to review current workload architectural models and determine how faster, standardized design and deployment cycles will affect your application and data platforms.
  • Workload Management . Azure Stack will enable you to adopt a technology lifecycle model that moves at the speed of public cloud releases.
  • Operations. Azure Stack will require your organization to introduce new operational processes, service models, and oversight that can help your teams make the most of your deployment, immediately.

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:

  • Architecting for the enterprise. Enterprises are likely to deploy self-service solutions to meet the needs of their organization and the internal divisions they currently support. While these must be properly secured, the focus tends to be on enabling business outcomes, reduced time to market, solution cost, availability, and scoping the solution to provide scalability in a cost-effective manner.
  • Architecting for the service provider. Service providers tend to design solutions that are directed at the specific market they are targeting. Services must be available, secure in a multi-tenant environment, billable, and deliver value to both the customers and the service providers themselves.
  • Architecting for the DevOps scenario. This scenario applies to either enterprise or service provider solutions and deploys the base services for consumption by developers. Developers are interested in rapidly standing up development environments, integrating with the wide range of tools in use by the organization, and creating applications that can be efficiently deployed to the cloud and updated on a continuous basis. For more information on DevOps, read the article What is DevOps?.

Overview and getting started

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:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)

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:

  • Users sign up for a subscription.
  • Users can browse the available offers and select one for their subscription.
  • Each offer is associated with a base plan, and each plan has specific quotas assigned for the resources within the plan.

By selecting an offer, the services within the associated plan and the quotas assigned to those services are assigned to the user.

Deployments

There are two key categories of Azure Stack deployments, each with many common decisions, but some individual considerations:

Customer-owned models (enterprise):

  • Application owners hosting their application in a dedicated Azure Stack instance. A cloud scenario where an application development team within a customer environment wants to take advantage of Azure Stack capabilities to host their application and make the most of the services managed by enterprise IT.
  • Application divisions (business units) hosting their services in a shared Azure Stack instance. A cloud scenario where an application development division within a customer environment wants to take advantage of Azure Stack capabilities to host their suite of applications and development/test environment using services managed by enterprise IT.
  • Enterprise IT extending their datacenter infrastructure to Azure Stack . A cloud scenario where a mature enterprise IT organization wants to extend their existing physical or virtual environment to Azure Stack to support a large number of growing IT requirements for their organization and its customers.

Service provider-managed models:

  • Shared instance. A cloud scenario where the service provider offers a shared deployment of Azure Stack Azure services to users across multiple organizations. This model applies to a customer base that can coexist with other users in a multi-tenant Azure Stack environment.
  • Dedicated instance. A cloud scenario where the service provider offers a dedicated deployment of Azure Stack to provide Azure services to users in a single organization. This model applies to a customer base that, due to regulatory compliance constraints or data sovereignty requirements, cannot leverage a shared deployment of Azure Stack.

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.

Scale units

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.

Regions

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:

  • Network latency : If response time for your applications is a concern, it is important that you deploy applications in close proximity to your users. If you have multiple locations, deploying applications closer to the user improves their experience. Azure Stack will provide methods for ensuring users are directed to the correct region. You must also consider synchronization of data if applications reside in multiple regions.
  • Availability : Applications need to be highly available and implementing multiple regions in Azure Stack enables you to reduce the impact of an outage. If an outage occurs, users can be redirected to a secondary region, maintaining the availability of the application.
  • Workload segregation : In some environments, workloads must be kept isolated for security reasons. In Azure Stack, you can deploy multiple regions to provide boundaries between such applications.
  • Scale : In large environments, your Azure Stack requirements may exceed the capabilities of a single Azure Stack region. In this case, you can use multiple regions to meet customer scale requirements.

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.

Clouds

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

Roles

Azure Stack has two general types of users:

  • Azure Stack Operator: Configures and manages resource providers, offers, plans, services, quotas, and pricing.
  • Azure Stack User: Acquires (or purchases) services that the Azure Stack operator offers. Users can provision, monitor, and manage services to which they are subscribed.

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:

  • Owner: Manages everything, including access to resources.
  • Contributor: Manages everything, except access to resources.
  • Reader: Views everything, cannot make changes.
NOTE: By default, the user that signs up for a subscription will become a subscription administrator.

Marketplace

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:

  • Existing pre-built solutions
  • Virtual Machine images
  • Azure Marketplace syndication
  • Custom pre-built solutions (consisting of one or more images)

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:

Interacting with Azure Stack

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.

Using the portal

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.

 

Azure CAT Guidance

"Hands-on solutions, with our heads in the Cloud!"