What Goes on in the Background

For a detailed explanation of the system, it is helpful to first explain a few terms:

1. Test Drive Solution's Azure ARM Deployment Template - An Azure ARM deployment template which contains all the Azure resources that comprise a solution being built by the publisher.

2. Test Drive instance - All resources running in Azure which are the product of executing a "Test Drive Solution's Azure ARM Deployment Template".

3. Types of "Test Drive instances" -

   • Hot: A running instance

     • PROS: These instances are running even before a user requests them. This makes the user request appear to have an immediate response to get access to the test drive. [Note: We highly recommend having at least one hot instance so that most your users will have the highest quality experience with the least amount of waiting time]
     • CONS: These instances are running all the time. So even when they are not being used by any user, they will cost money to the publisher.

   • Warm: A "stopped" instance (See image for more details)

     • PROS: These are instances that are deployed and in a stopped (deallocated) state, so when a user requests them, we just have to change the instance to a "running" state and assign it to the user. This increases the chances that the user will not leave the site and will actually try the solution.
     • CONS: When requested by a user, it takes longer than a Hot instance to assign it to a user because the solution has to be "started"

   • Assigned: A running and assigned instance given to a customer

     • Assigned instances are deleted once a user manually stops a test drive or the test drive period expires.
     • An assigned instance is never shared among users, not even after a user's test drive period expires.

   • Cold: Cold instances are the result of a user requesting a "test drive", and the system not finding a "Hot" or "Warm" session to assign to that user. In these cases, the system will start a full deployment using "Test Drive Solution's Azure ARM Deployment Template", and the session will become an assigned instance to the user only when the deployment is completed.

     • PROS: These test drive instances are created only when users request them. In other words, they only cost money to the publisher when a user is using it.
     • CONS: Deployment might take a long time and users might not want to wait and could simply leave the test drive.

4. Publisher's Azure Service Principal - The publisher's subscription information that is going to be used by the Test Drive system to deploy "Test-Drive instances" on behalf of the publisher.

5. Deployment Region - An Azure data center

6. Maximum Number of Concurrent Instances - The maximum number of concurrent instances than can be running in a given "Deployment Region". For a given "Deployment Region", the addition of "Assigned" + "Warm" + "Hot" instances will never be greater than this number.

Test Drive Example

Let's say a publisher wants to publish a Test Drive that shows users how an Azure "Windows Server 2016" VM works, and the publisher provides us the following information:

1. Deployment Regions - Japan East and South US
2. Maximum Number of Concurrent Instances - 6
3. Number of Hot Instances - 2
4. Number of Warm Sessions -1

Legend:

[H] represents a hot test drive instance

[W] represents a warm test drive instance

[A] represents an assigned test drive instance

[-] represents a test drive instance that could be created if requested by the user.

When the test drive gets published, the publisher's subscription will look like this:

• [H][H][W][-][-][-] Japan East
• [H][H][W][-][-][-] South US

For a total of 4 = 2x2 "Hot" and 2 = 2x1 "Warm" Test Drive instances in the publisher's subscription. And 6 = 2*3 more Test Drive cold instances which could be created depending on users' requests.

Assigning a Test Drive Instance to a User

When a user requests a Test Drive instance by clicking "Start Free Test Drive", the following logic is used to assign a Test Drive instance to a user:

1. Find a "Hot" Test Drive instance in the "Deployment Region" selected by the user and assign it to the user.
2. If there are none, find a "Warm" Test Drive instance in the "Deployment Region" selected by the user and assign it to the user.
3. If there are none, verify if the "number of concurrent instances" for that "deployment region" hasn't been reached, deploy a new Test Drive instance, and after the deployment is completed assign that new Test Drive instance to the user.
4. If there are none, show the user a message saying that there are no Test Drive instances available for that deployment region and ask the user to pick a different deployment region.
5. Replenish "Hot" and "Warm" Test Drive instance making sure that "Assigned" + "Warm" + "Hot" instances don't exceed the "Maximum Number of Concurrent Instances"

Different Scenarios for Assigning a Test Drive Instance to a User

Starting Point:

• [H][H][W][-][-][-] Japan East
• [H][H][W][-][-][-] South US

Scenario 1: A user requests a test drive in the South US region

• [H][H][W][-][-][-] Japan East

• [A][H][W][H][-][-] South US

  One hot Test Drive instance is assigned to the user and a new hot Test Drive instance gets created.

Scenario 2: Next 3 users request test drives in the Japan East region

• [A][A][A][H][H][W] Japan East

• [A][H][W][H][-][-] South US

  Two hot and one warm Test Drive instances are assigned to the users and two new hot and one new warm Test Drive instances get created.

Scenario 3: Next 2 more users request test drives in the Japan East region

• [A][A][A][A][A][W] Japan East

• [A][H][W][H][-][-] South US

  Two hot Test Drive instances are assigned to the users no new hot or warm Test Drive instances are created since the max for that region was reached.

Scenario 4: Next the test drive period for one of the Assigned Test Drive Instances in the Japan East region expires

• [A][A][A][H][A][W] Japan East

• [A][H][W][H][-][-] South US

  The assigned Test Drive instance gets deleted and a new Hot Test Drive instance gets created.