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:
If the connectivity between the remote development environment and the company deployments is low-latency and high-speed, then every operation between them can be easier and the productivity witnesses a boost compared to local environments.
If you are in the middle of a complicated debugging session just before the office closes, you can disconnect from the remote VM and continue debugging from anywhere else (even from your home computer).
Your data is generally more secure in terms of availability than a personal workstation. A remote VM can obviously be accessed from the Internet (directly or through a VPN), along with the potential issues related, but a personal computer can also be stolen or damaged (backups are always our best friends in such scenarios).
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.
Note
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.
Note
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:
As the provisioning is one VM per user, with each new employee Owen needs to:
Run the scripts to build the VM (we'll learn later which kind of scripts)
Tell new users the appropriate credentials
In the case of reimaging, Owen has to set up an appropriate backup-restore solution for the personal archives on the remote machine
Users need to maintain (at least) two different accounts: one for the company and one for the newly created VM
In the case of software updates, each user has to manually update their VM
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.
Tip
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
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:
Create an Azure Active Directory tenant for the organization (we did this in the previous section).
Create a custom VM image with the complete development environment (we can use the previously created one).
Activate RemoteApp and assign users.
Note
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).
Note
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:
Create a new storage account from the old portal.
Note the credentials for both the old and new storage accounts (the storage account name and one of the access keys).
Install this software: http://www.cerebrata.com/products/azure-management-studio/introduction in the trial mode.
Configure the two storage accounts (despite being created under different methods, they are equal from an API's perspective).
Copy the blob and paste it into the Classic Storage Account (the operation is almost immediate if accounts are in the same data center).
Create a Custom Image and, in order to enable RemoteApp using your image, import the VM image into the TEMPLATE IMAGES tab of the RemoteApp section of the old portal.
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:
Publish individual programs.
Selecting RemoteApp programs
Assign individual users to the RemoteApp collection (through the USER ACCESS tab)
Create multiple collections to accommodate different types of users
Update the VM image by simply running the Update wizard (custom user data is retained between sessions and between updates)
Updating the VM image through the Update wizard
Connect from your iPad/iPhone through the dedicated RemoteApp application.
The file system seen by a RemoteApp application is the remote file system, which is persisted across different sessions and image updates