-
Book Overview & Buying
-
Table Of Contents
Mastering Cloud Development using Microsoft Azure
By :
In the Setting up the development environment section, we saw how much value resides in off-shoring the development environment (later called DevEnv) in the cloud by building VMs with development tools instead of using the local computer.
This pattern also highlights some hidden advantages:
This pattern leads to a consideration: "Do we still need powerful IT stuff to run development environments?". Since the DevEnv is remote, we can use any device supporting the RDP protocol (for Windows VMs) or the SSH protocol (for Linux ones). The next step is to use a mobile phone, a tablet, or a thin client.
Microsoft Thin PC, for example, is a reduced Windows 7-based OS project with minimal functions and a RDP client. The purpose of this OS is to run on legacy computers with outdated hardware, enabling the consumption of even complex applications through the Internet and the remote desktop. For more information, refer to the deployment guide here: https://www.microsoft.com/en-us/download/details.aspx?id=26676.
Under this hypothesis, we can build a workstation with almost any device connected to the Internet.
Nobody really wants to develop with Visual Studio and multiple open windows on a smartphone display. However, Project Continuum by Microsoft lets users use their continuum-enabled devices as workstations by connecting them to a TV or a PC monitor. The idea behind this is the thin client pattern, where services or applications are available on the Internet through HTTP or RDP. At this link, there is an accessory for Windows Phone devices that makes the magic happen: http://www.microsoft.com/en-us/mobile/accessory/hd-500/.
That said, CloudMakers wants to enable its workers to have the same facilities that they have in their office while on the move. Luke also has a Surface 2 RT tablet, which is very useful for basic office usage and for Internet usage/e-mail and less useful for development due to its ARM-based processor architecture (Surface RT has a specific version of Windows compiled for ARM).

This is the final result of a correct deployment of RemoteApp. In this case, the company user (blurred) has access to a bunch of applications, which are not running from its local environment but are provided through an abstraction on Remote Desktop Protocol instead.
Until this point, the remote development environment requirement can be easily fitted by the VMs created in the previous part of the chapter: Luke just has to connect to them from the Surface, and that's it! However, as a CTO, he identifies some drawbacks in the previous approach, as follows:
Finally, and this is both an advantage and a disadvantage, each user is the administrator of the remote VM, with these two main categories of possible consequences:
As Luke plans to extend this pattern to the whole company, it emerges that it is not really sustainable in terms of the management effort (the time spent to activate/deactivate or support people), consistency (some VMs are different from others), and security.
Let's introduce Azure AD before explaining RemoteApp, and let's start identifying what Azure AD is not. It is not the managed version of the Windows Server Active Directory. Despite its resemblance in name, Azure AD is just an IAM service managed and hosted by Microsoft in Azure. We should not even try to make a comparison because they have different scopes and different features. It is true that we can link Azure AD with an on-premise Active Directory, but that will be just for the purpose of extending the on-premise AD functionalities to work with Internet-based applications.
Azure Active Directory is a growing Identity and Access Management (IAM) service (now with B2C features), with great integration options for custom applications; different applications (and the various services of Azure itself) can use Azure AD as their IAM solution in order to provide authentication/authorization.
It is a good practice to group multiple subscriptions (related to the same organization or logic group) into the same Azure Active Directory (AD).
To create a new Azure AD tenant, we need to move to the old portal (https://manage.windowsazure.com) and proceed as follows:

We create the Azure AD tenant for the CM company.
This directory will host the users of the company in order to provide them with authentication/authorization of services.
If we plan to centralize the access rules for online resources, Azure AD can help us by providing a single identity for our users, created one by one (or through REST APIs), as follows:

This creates a new user
Complete coverage of the capabilities of Azure AD is beyond the scope of this book. However, some advanced topics can be found in the next chapters.
Microsoft tries to solve the issues of the scenario mentioned earlier, implementing a layer of abstraction between the user and the actual VM performing the work. RemoteApp is this layer, completely based on existing technologies (such as RDP), and enables users to connect to applications instead of VMs.

This is the architecture overview of how RemoteApp works
To start from the beginning, we should:
A pricing note
RemoteApp has an elastic pricing model, just like many cloud services. However, it has a strong requirement: a minimum of 20 users (at the time of writing). This is due to how the service is internally provisioned; if you have less than 20 users, you would still be billed for 20. If you compare the service to a medium-sized instance (or even a small one) per user, it is probably still more convenient. However, this is an aspect that should be considered before implementation.
As for the Azure AD tenant, even the RemoteApp collection can be created only from the old portal (https://manage.windowsazure.com).
Classic versus Resource Manager: the hidden issue
Earlier in this chapter, we recommended that you create new resources by always using the Resource Manager mode and not the classic one. This is because the Resource Manager mode is the new one, and hosts new features and investments. However, there is a strong separation between these two areas: so strong that, for example in the old portal (which is based on the classic model), there is no way to reuse components created in the new way.
As an example of this, try to look at storage accounts or custom VM images in the old portal:

This screenshot has been taken in the same subscription where the storage account and the custom VM image were created previously. Remember this behavior and plan your deployments accordingly.
As a quick fix for the lack of the VM image in the old portal, proceed as follows:


This creates a RemoteApp image based on the generalized VM image
Finally, to complete the creation process, go to REMOTEAPP COLLECTIONS and create a new collection based on the custom image you've just registered.
If all went well, you can now do the following:

Selecting RemoteApp programs

Updating the VM image through the Update wizard

The file system seen by a RemoteApp application is the remote file system, which is persisted across different sessions and image updates
Change the font size
Change margin width
Change background colour