WavebreakMediaMicro - Fotolia
Many businesses expect IT teams to do more without giving them more money -- and, sometimes, cutting an already...
small budget. But new projects mean test and development -- an expensive endeavor in the data center. One way to alleviate this financial strain is to move those test and development workloads into the cloud.
Running a test environment in the data center is expensive, with high costs connected to hardware, software, power and cooling -- not to mention all the time and effort IT spends keeping everything running and properly updated. Instead, administrators can turn to the cloud to develop and test applications in Microsoft's Azure DevTest Labs. This enables companies to trade in hardware expenses and switch to a pay-per-use model. Other features in the service, such as the auto shutdown for VMs, can further control costs.
In this first part of a two-part series, we explain the merits of using a test bed in Azure and configuring a VM for lab use. In part two, we explore ways to manage the VM in DevTest Labs, as well as benefits gained when a workload moves out of the data center.
What is Azure DevTest Labs?
Many businesses maintain an on-premises test environment that emulates the production environment, which lets development teams test code before it is pushed into production. This also enables other teams within the app dev team to perform usability and integration testing.
But a test environment can have slight variations from the production side. It might not have key updates or patches, or it could run on different hardware or software. These disparities cause the application to fail when it hits the production environment. Azure DevTest Labs address these issues, enabling admins to build an infrastructure that is disposable and adaptable. If the test environment requires drastic changes, the team can remove it and build a new one with minimal effort. In contrast, a typical on-premises production setting generally cannot be offline for very long; the investment in hardware, software and other infrastructure requires lengthy deliberation before IT makes any changes.
The team can turn off DevTest Labs when the test period ends so that resources go away, and there are no costs until the service is needed again.
Creating another lab scenario to test a new feature removes the effort to twist and tweak an existing test environment to bring necessary components online, which can cause problems with other testing scenarios. An on-premises test environment requires sizable expense and effort to maintain and keep in sync with production. In contrast, admins can quickly configure a test setting in Azure DevTest Labs.
What are the benefits of Azure DevTest Labs?
The most noticeable benefits to DevTest Labs include:
- Pay as you go pricing: The lab only incurs cost when a VM runs. If the VM is deallocated, there are no charges.
- Specified shutdown: IT staff can configure DevTest Labs to shut down at a certain time and automatically disconnect users. Turning the service off -- for example, shutting it down between 5 p.m. and 8 a.m. -- saves money.
- Role-based access: IT assigns certain access rights within the lab to ensure specific users only have access to the items they need.
How do I get started with Azure DevTest Labs?
To set up Azure DevTest Labs, you'll need an Azure subscription. Sign up for a 30-day trial from the Microsoft Azure site. Go to the Azure Resource Management portal, and add the DevTest Labs configuration from the Azure Marketplace with these steps:
- Select the New button at the top of the left column in the Azure portal. This will change the navigation pane to list available categories of services and the main blade to a blank screen. As you make selections, this will populate with related information.
- In the search box, enter DevTest Labs, and press Enter.
- In the blade that displays the search results, click on DevTest Labs. This will display more information about DevTest Labs and a Create button.
Click the Create button. Azure will prompt you to enter configuration settings for the instance, such as:
- The name of the lab: The text box shows a green checkmark if the value is acceptable.
- The Azure subscription to use
- The region where the DevTest Lab will reside: Pick a region closest to user(s) for better performance.
- If auto shutdown should be enabled: This is enabled by default; all VMs in the lab will shut down at a specified time.
Enter values for these options; items marked with a star are required. Click Create, and Azure will provision the DevTest Labs instance. This typically takes a few minutes to gather the background services and objects needed to build the lab. Click the bell icon in the header area of the Azure portal screen to see the progress for this deployment.
Once Azure provisions the lab, you can add objects and resources to it. Each lab gets a resource group within Azure to keep all the items packaged. The resource group takes the name of the lab with some random characters at the end. This ensures the resource group name for the lab is unique and ensures the admin manages its resources through DevTest Labs.
To find the lab, select the option for DevTest Labs from the left navigation pane. For new users, it might be listed under More Services at the bottom. When the lab is located, scroll down to the Developer Tools section, and click the star icon next to the service name to pin DevTest Labs to the main navigation list.
Click DevTest Labs in the navigation list to open the DevTest Labs blade and list all the labs. Click on the name of the new lab: techTarget -- for the purposes of this article.
This opens the blade for that lab. The administrator can populate the lab with compute and other resources. New users should check the Getting Started section to familiarize themselves with the service.
What components can we put in the lab?
DevTest Labs creates sandbox environments to test applications in development or to see how a feature in Windows Server performs before moving it to a production environment.
Administrators can add components to each lab, including:
- VMs: Azure uses VMs from the Marketplace or uploaded images.
- Claimable VMs: The IT department provides a pool of VMs for lab users to select.
- Data disks: You can attach these disks to VMs to store data within a lab.
- Formulas: Reusable code and automation objects are available to objects within the lab.
- Secrets: These are values, such as passwords or keys, the lab needs. These reside in a secure key vault within the Azure subscription.
Administrators can modify configuration values and policies related to the lab, change the auto startup and auto shutdown times and specify machine sizes that users can create. To find more information on these items, select My virtual machines under MY LAB in the navigation list. Click Add at the top of the blade to insert a VM.
For the purposes of this article, select Windows Server 2016 Datacenter as the VM base image. The next blade shows the following items that are required to build the VM:
- VM name: A unique name for the VM.
- Username: The admin username for this VM -- it cannot be administrator.
- Disk type: Options include solid-state drive or hard disk drive -- SSD provides better performance, but will raise the cost of operations slightly.
- VM size: The number of CPU cores and amount of RAM -- after selecting the one you want, click Select.
You can also select artifacts to install when the VM is created, and configure advanced options for the resource. Find more information about artifacts at Microsoft's Azure documentation site.
For labs with more complex needs, advanced settings let administrators adjust the VM's networking settings and set the VM as claimable.
When you finish the lab VM configuration, click Create. Azure will do its work, which will take some time to complete.
In the next installment of this article, we will look at VM management in Azure DevTest Labs and different testing scenarios within the service.
A Hyper-V lab can help with certification studies
Explore OpenStack's capabilities with a virtual home lab
Keep a test VM from affecting the production environment