Premium Blend

Up to now, services were mostly available online from a public cloud. Although Windows Server, System Center, and Windows Azure Pack are components for a hybrid cloud, setting up a private cloud required great know-how and effort – something that Microsoft certainly changes with Azure Stack.

Objectives

The virtualization layer plays only a minimal role in this first version of Azure Stack, so it is of interest to companies whose classic virtualization is based on a hypervisor other than Hyper-V. The added value of Azure Stack is found in the other layers and the cloud services it enables, for which virtualization is ultimately only a means to an end. In other words, infrastructure as a service (IaaS) should complete platform as a service (PaaS) and not serve as the primary solution.

Microsoft does not regard Azure Stack as a playground for customers with the urge to handle their own servers, but rather as a highly integrated solution with software and hardware components that are mostly hidden from admins and that have been defined, validated, and, above all, put through their paces by Microsoft and selected hardware manufacturers. This self-contained concept is designed to provide companies the greatest possible consistency with the Azure cloud model (Figure 1).

The ecosystem for creating, managing, and using all Azure components should be the same across the different Azure environments. Azure Stack belongs to an Azure environment as well as Azure Public, Azure Government, Azure China, and Azure Germany. All users should have the same set of tools available for all landscapes, which should make it easier to switch between environments, especially from Azure Stack to Azure Public. Microsoft understands this as consistency in its cloud model: The deployment of virtual machines (VMs) or entire workloads looks the same no matter which Azure environment is addressed.

Delivery Specifications

Initially, Azure Stack is available from original equipment manufacturer (OEM) partners Cisco, Dell EMC, HPE, Huawei, and Lenovo. In the first version of July 2017, the available services are still manageable. Azure Stack could only be operated in one region and with a scale unit [1] that consisted of 4 to 12 physical servers provided by the above-mentioned OEM partners. Functionally, Azure Stack [2] offered the following with the general availability (GA) release:

• IaaS: Azure Virtual Machines (A, D, and Dv2), Azure VM scale sets, Azure Storage (blobs, tables, queues), Azure networking (virtual networks, load balancer, VPN gateway), and Azure Key Vault.
• PaaS: Azure App Service (Web Apps, Mobile Apps, API Apps), Azure Functions, MySQL, and SQL Server RP. In 2018, standalone Azure Service Fabric cluster (IaaS VMs) and Azure Container Service (ACS) engine support (Docker Swarm, Mesosphere DC/OS, Kubernetes container management templates) will be added.
• Azure Identity: Azure Active Directory (AAD), multitenant support, and Active Directory Federation Services (ADFS) support.

The licensing of Azure Stack is similar to the licensing of Azure, wherein services are charged according to their use. The price is lower for Azure Stack, but you have to take into account the hardware and operation costs. Alternatively, you can license Azure Stack in full beforehand.

Availability is heavily dependent on OEMs who sell and deliver the solution. Where Azure Stack is not currently available, Microsoft intends to add the software and hardware packages later with the help of additional OEMs and thus achieve greater availability than the initial 46 countries worldwide.

What Azure Stack Is Not

Azure Stack is not a substitute for a private cloud or virtualization platform that administrators can customize and configure. As mentioned before, Microsoft delivers Azure Stack as an integrated system that is preconfigured and protected against external influences and changes for security reasons. Azure Stack's degree of customization is therefore narrow and limited to the workloads.

Therefore, although discussions about the Azure Stack architecture are informative, they not as important as in private cloud deployments. Azure Stack comes from all OEM partners in the same configuration – only the hardware components are specific to the manufacturer. This model is not very popular with many IT managers when it comes to setting up a local infrastructure that needs fine tuning, but only in this way can Microsoft ensure the alignment of Azure Stack with Azure and its continuous updates. Additionally, Azure Stack's delivery configuration protects against unsigned third-party code execution.

Despite the efforts for consistency, Azure Stack differs from the public Azure offering (Table 1), above all, in its available services, API version, functions, and scaling. For most companies, the cloud offers almost infinite resources, which pays off especially in scenarios with high-performance computing or machine learning, for which resources are only used – and thus paid – for a certain period of time.

The enormous elasticity of Azure's public offering, which can easily grow more than several hundreds or thousands of cores and shrink again hours later, is not yet provided by Azure Stack – on the basis of physical resources – even if these resources, with Azure Stack, would be idle after use.

Another fallacy is that all the new Windows Server 2016 features have been added to Azure Stack. Although the closed system is based on Windows Server 2016, Microsoft decided to maintain consistency before functionality: In Hyper-V, for example, "shielded VMs" are a very popular scenario for hosters, and not only from a security point of view. However, because Azure does not currently support shielded VMs, this feature is not available in Azure Stack for consistency reasons.

Azure Stack Scenarios

With Azure Stack, Microsoft is pursuing the goal of maximizing customer productivity by allowing developers to deploy applications in the same way, whether the application is running in the public cloud, in the local data center, in both places at the same time, or just here and there.

Microsoft provides some usage scenarios [1] for Azure Stack, in which the Azure Resource Manager (ARM) acts as a unified toolset to deliver services through self-service portals and APIs [1]. The strategy is close integration of Azure Stack and popular DevOps tools (e.g., Visual Studio Team Services, Jenkins, Chef, and PowerShell) with Desired State Configuration (DSC), using the same steps to deploy, configure, and manage across all Azure environments, whether globally or locally.

Scenarios that include continuous delivery of applications and services are predestined for Azure Stack, and IT organizations that regularly develop and roll out new versions of their applications with the help of a good Azure development life cycle can integrate Azure Stack into this cycle. Test deployment of applications and even application development in Visual Studio are well integrated with Azure Stack. Visual Studio shows Azure Stack as one of the available Azure environments, which makes it possible to deliver and roll out code to Azure Stack for development and testing and push it to Azure using the same mechanisms when the application is ready.

Non-connected or only partially connected infrastructures represent a somewhat more complex scenario. Examples include environments in which parts of the infrastructure are never or seldom connected to the Internet or the rest of the network (e.g., oil rigs, cruise ships, mobile camps in crisis areas). Here, Azure Stack offers benefits because it can run offline and provide local applications and services without the need for a permanent Internet connection to Azure. Applications can be written once and used on both platforms. It is even conceivable that the same application in Azure and in the semi-connected Azure Stack on a drilling rig will always synchronize data when the connection is in place and act autonomously as soon as no data line is available; it's all a question of application development.

Applications with sensitive data are another scenario. For example, applications that contain personnel data, identification data, or business-critical information should not be migrated into the cloud. The application is developed and tested in the cloud on Azure, where critical data is not used, but the application is deployed using the same mechanisms in Azure Stack for production.

Not only does Azure Stack support its own applications and workloads, it also supports many of the packages available in the Azure Marketplace. Microsoft checks these and then makes them available for download and integration into Azure Stack. Administrators of Azure Stack have access to the required packages for their own deployments. Obviously, Microsoft wants to offer IT organizations that use the packages available in the Azure Marketplace the same packages in the Azure Stack Marketplace.

Planning

As interesting as the use case scenarios are, in the end, the application must suit your company. Simply rolling out Azure Stack to own an in-house cloud will in most cases not bring the greatest possible added value. Azure Stack can be versatile, but it's not a jack of all trades, so precise planning is necessary.

Microsoft regards the cloud as a model rather than a place to store data and applications. With cost, agility, and scalability as drivers, the cloud has quickly catapulted itself to the forefront of CIO attention. The cloud is changing system landscapes and the cloud-first approach allows companies to dismantle old architectures and drive digital transformation forward. Azure Stack supports this model by taking Azure to the company data center. Even though the cloud is often a good solution from an IT point of view, privacy concerns make it unwise and legislation makes it difficult to work in the public cloud – which is why Azure expansion with Azure Stack can make sense.

The distribution model is not typical for Microsoft. Usually, Redmond delivers the base system with APIs that often provide complementary functions through partners or the community. Azure Stack, on the other hand, is a comprehensive, holistic approach. As mentioned above, Microsoft only delivers Azure Stack as an integrated system by OEM partners in selected markets. This means that Azure Stack only exists as a package of software and hardware and cannot be installed on its own. The OEM partners deliver, install, and build the bundle for the customer.

However, Microsoft provides a very good opportunity to try out the Azure Stack Development Kit (ASDK) [6] in a limited form. The limitations were chosen so that no productive solutions can be built with the ASDK, but IT organizations can evaluate the most important functions very well, especially software-defined data center topics. The limitations of the ASDK are mainly based on an installation that is limited to a single node and therefore does not cover high availability – referred to as a "One-Node Dev Kit." A further limitation can be found in Release Management, because with each new ASDK version, the kit has to be completely reinstalled. Nevertheless, the ASDK trial version gives you good insight into the function, management, and operation of the infrastructure and future workloads.

The ASDK comes with an automated installation script that installs Azure Stack on a single, properly sized machine and configures it according to preselected settings. The recommended hardware configuration [7] of the node for meaningful testing should include a 16-core machine with at least 128GB of RAM, multiple network interfaces, and four or more disks.

Adopting Azure Concepts

Many of the concepts and functions from the public Azure are critical for developers to offer their workloads internally. Developers are primarily concerned with services and supporting components, whereas IT administrators are more interested in providing the same controls, security settings, and high availability for applications as in traditional virtualization environments (Figure 2).

Only at second glance does it become clear that basic functions from the public cloud are also useful locally and that many questions regarding infrastructure, architecture, or hardware no longer have the same relevance, which makes it easy to enforce the chosen cloud model consistently, with all its definitions and operational decisions.

Role-based access control is also available in Azure Stack. Access to resources can be controlled per user and resource as in Azure. The users either come from the local Windows Active Directory (AD) or from the Azure Active Directory (AAD), where Azure Stack can offer single sign-on (SSO) via AAD or ADFS. Integration into the productive AAD is a good solution, because Azure Public integrates into it.

To provide resources with additional information (e.g., to identify support staff, define the user of a resource by name and email address, or identify a cost center), you can store tags. As with a public cloud, these can be freely selected.

If you equip resources in Azure Stack with locks, they prevent unwanted attempts to delete or change a resource. Before changing or deleting, the lock must be removed explicitly, which cannot be executed by everyone. Privileged users take an additional step to remove the lock.

Another feature is availability sets, which focus on the high availability of applications and the distribution of redundant components among multiple physical hosts. The sets ensure that not all of the components required for the service or application to function are found on a host. Patching hosts, which requires a reboot, cannot affect an entire service.

Because only a subset of Azure services is available on Azure Stack, possibly in an older API version, it is important to maintain compatibility between the cloud platforms. Microsoft's Azure Stack Policy Module [8] is a very helpful and important tool for maintaining consistency with Azure Stack in an Azure subscription.

This module allows you to create an Azure Policy that limits the Resource Types and Services in the selected Azure subscription according to availability in Azure Stack, which means that only the locally available functions can be used in Azure.

Updates and Development

Microsoft has a clear plan as it updates and enhances Azure Stack in relation to the other Azure environments. The public cloud is the top priority. Features and bug fixes can be updated more quickly, because Microsoft has a firm grip on the cloud by collecting user feedback from all over the world; collecting telemetry data on the use, enjoyment, and frustration of features and the Azure portal; and implementing telemetry and suggestions directly into innovations. (See the box "The Customer Is Always Right.")

Azure Stack will receive updates twice a year to stay current with public Azure environments. As soon as Microsoft provides information about the next release (often referred to as a "Post-GA update"), it will appear on the official Azure Stack Roadmap [9]. At the time of print, version 1.0 (i.e., the GA release), update 1802, is current. Owners of Azure Stack are allowed to skip a version, but must install the next update to continue receiving Microsoft support. The IT manager can't wait too long to install updates, because the complete toolset for administration and usage is also updated. In the worst case, the consistency and concurrency of Azure Stack with Azure is lost.

For the development of applications, it is worth taking a look at the versioning of resources, because not all Azure versions of storage functions, VM extensions, and scaling definitions make it to Azure Stack. For this reason, all Azure resources are assigned a version number, which you can read with a PowerShell command for both Azure and Azure Stack:

> Get-AzureRmResourceProvider | Select ProviderNamespace -Expand ResourceTypes | Select * -Expand ApiVersions | Select ProviderNamespace, ResourceTypeName, @{Name="ApiVersion"; Expression={$_}}

Conclusions

With Azure Stack, Microsoft wants to offer more than just a platform for the private or hybrid cloud. With the "cloud as a model," Microsoft has learned from the past: If the integration of developer tools, test routines, rollout procedures, and processes does not work, customers will not migrate because of the high costs. Azure Stack tries to avoid this problem. As a small, albeit currently limited, Azure for your own data center, the focus is on integration and consistency of all available tools, which are also available for the public Azure; therefore, it is highly interesting for IT managers who want to take a closer look at Azure and support development, testing, and offline scenarios in a highly integrated way.