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).

Figure 2: Azure Stack provides an administration interface for the environment-specific configuration that is identical to Azure's.

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.