(upbeat music)
- Coming up on Microsoft Mechanics,
if you're managing infrastructure,
we're going to show you how you can gain more control
over your pre-production test environments by shifting
to Azure and taking advantage of our DevTest subscription
that allows you to pay only for the compute you use.
So I'm joined today by dev test expert,
Steven Murawski at Microsoft,
joining us today from Wisconsin, welcome to Mechanics.
- Thanks, it's great to be on the show.
- Thank you, so the idea of running
pre-production dev/test environments in the cloud
is really not a new one,
so what's new here with Azure DevTest?
- You're right, it's not a new concept,
but what is new is how we might go about it.
Developers have been spinning up
these environments for years.
Now, Azure brings a lot of advantages to this.
It's an open platform, so it supports a lot of choices
for the tools and frameworks that they might be using.
- Right, and sometimes if you're a developer,
it's easier to set these environments up yourself
versus going to the IT department and asking them
for this infrastructure set up for you.
- Yup, but you do need to make sure that,
we're not making trade-offs
in compliance and security of that infrastructure.
Now, we can have the best of both worlds,
where devs can spin up what they need
while they're staying within IT's guardrails
when we bring our existing dev/test environments into Azure.
Or you can build your own dev/test environments
with the right governance from scratch.
In fact, we've got a number of purpose-built services
and dedicated offers to help keep costs down.
- Now to be clear, within Azure you can establish
global governance over your subscription
using things like Azure Policy or Azure Blueprints.
And that will help you govern things like,
maybe the size of your VMs or databases
or other compute that you use for dev/test.
- Exactly, and while there are some differences
in the management experience,
the good news is that there's a lot of consistency.
Most of the scripts, tools and practices
that we're using today can transition right into Azure.
- Okay, so let's make this real for everyone watching.
How do I get started?
- So the first thing that we do
is we need to spin up a DevTest subscription.
This is the pay-as-you go option for the DevTest offer,
but there's an equivalent in the enterprise portal.
Creating subscriptions is easy as clicking activate,
then adding our payment information
and accepting the license agreement.
That starts the sign-up process and flags to Microsoft
that we're not going to be
using this for production workloads.
In most cases, we then won't have to pay for licensing,
just compute, and we won't have to
use our Azure Hybrid Benefits.
After a bit of background processing,
we'll end up in the portal, with our subscription available.
From here, we can spin up multiple dev/test environments
on this one subscription.
- And we also have a calculator that can help you assess
the cost of spinning up a dev/test environment
for your organization, and you can find that
at aka.ms/AzureDevTestPricing.
All right, so now you can use this
to bring your dev/test environment into Azure
or spin up new environments.
But why don't we start with the options
for bringing your existing VMs
or your existing infrastructure into Azure?
- All right, there are two scenarios here.
If you have persistent VMs running on premises,
your best options is to lift and shift those VMs,
bringing your existing resources to run on Azure VMs.
Here, we can use Azure Migrate to migrate those servers.
In this process,
we will first set up an appliance VM on our environment,
which will manage the replication.
Next you'll target all the hosts that you want
to replicate into Azure storage.
Then, once you start replicating,
the virtual machines will continuously replicate into Azure
until you're ready to test and migrate those
into production, right?
I say "production" in quotes because it's dev/test.
- Right, we just did a step by step show with Jeff Woolsey
who went through all of the process in detail
which you can check out at aka.ms/MechanicsAzureMigrate.
- Right, and this is still infrastructure of service,
which means that you'll need to do things
to secure and manage your VMs,
but we're going to be running the compute for you.
Now, the other option is,
if you have a fully scripted dev/test environment,
you can point that automation to Azure
and hydrate your DevTest environment on demand,
bringing with you all your existing scripts and tools.
For example,
here I have a script that spins up a few tests VMs.
I have to start by checking out to make sure
that there's enough memory to start my machines
and that I'm not over-committing
my available processors too heavily.
I've got a simple loop that sets up the VHDX-Files,
sets a few details about the VMs and creates them.
Then, I can apply PowerShell Desired State Configuration
configurations to those VMs in background jobs
and wait for those jobs to finish before the script exits.
Now, to do something similar in Azure,
I run a helper function
to ensure that things like the resource group are there,
but I don't have to go check capacity now.
Then just like the Hyper-V variant,
I provide some VM details
and ask the platform to create them and then, I can tell it
to apply my PowerShell DSC configuration
to those machines, which is going to take a few moments.
At the end, we'll see those jobs are completed.
As you can see, the experience between those is pretty close
and I'm reusing all my existing PowerShell experience.
As I mentioned, Azure is open and supports
a variety of tooling.
If you're provisioning with Terraform, a change in provider
can get you spinning up into Azure environments
with minimal changes.
- All right, so now I know a lot of people watching
are probably setting up a dev/test environment
or trying to set these things up locally
and it hasn't always been an option in certain cases
because there might be things in the way like costs
or resources or even the time it takes
to set one of these up.
But what's the best way to set one of these up from scratch?
- The easiest way is going to be using
the DevTest Labs Service.
This is a free service, and just to be clear,
this isn't Azure Lab Services for classroom management.
This gives us a templated approach
to creating self-service DevTest environments,
with all the right guardrails
to meet our environmental needs.
So for example, in my subscription
I have a few DevTest Lab instances.
Each one has its own RBAC controls,
cost thresholds and configuration.
Let's take a look around
and click on one of the instances, TailwindTradersLabs.
And we'll navigate to the configuration and policy section
where we'll find that just like every other Azure resource,
we can assign role-based access controls.
By assigning DevTest Labs users or groups
with the owner, contributor or DevTest user roles,
we have discreet control of the users capabilities
inside that lab experience.
I'm adding a guest user account as a user for my lab.
Let's save that role assignment.
Now opening up self service can be scary,
especially to anyone with their eye on a budget.
With that mind, let's click into cost trend.
This is where we have a closer view
of the DevTest Labs costs.
We can click on manage target
to define a cost target with thresholds
or we can enable automation to notification.
With webhook support it's easy to tie in Azure functions
or Logic Apps for added flexibility.
This means we have lots of options and are well prepared
to make best use of our Azure expenditures.
Now, something else to keep in mind
is that all the resources that are deployed,
they're just Azure resources in our subscription,
so they do fall under any Azure policies
that we have assigned.
- So now we've got the controls
and the cost management in place,
but, why are we providing then for our developers?
- The developers get self-service machine
and environment creation.
Now let's take a look at how that works.
We start with a base image.
There are lots of images to choose from
on the Azure Marketplace
or we can use our own custom images.
The locations to pull images from
and which images are offered is fully under your control.
So we're going to pick a server 2016 image,
and then we'll configure
the username and password and VM size.
Then we can add some artifacts.
Those are packaged bits of software or configuration
that can be applied to the machine.
For this example, we'll add IIS to the machine.
We'll click add and then click okay.
Back on the create lab resource page,
we'll click create and the machine will begin to provision.
Now, these combinations can be created at provisioning time
or we can create a formula which provides
a base image and any customizations you'd like
as a starting point.
We are not limited to just single machine environments.
Labs can consist of multiple machines and services,
and the required configuration and connections
to represent any application environment.
We'll try that with one of my custom environments here.
These are using behind-the-scenes
Azure Resource Manager templates,
following a practice known as Infrastructure as Code.
There are some defined out-of-the-box,
like a SharePoint farm or we can use someone else's,
from GitHub or Azure Repos,
which we'd set up in the lab configuration.
- Yeah, and that's a great service really
to take advantage of.
Now the other option,
if you're doing user acceptance testing,
maybe on your end points or if you have to emulate
what you have in your on-prem environment
with domain-joined desktops,
you can use Windows Virtual Desktop.
So what I want to do is actually show you
how this is going to work
in the context of user acceptance testing.
Now I have here a Windows 10 Desktop
and It's got an application I want to be able to test.
In our case it's on a domain-joined machine
and it needs to be able to reach data
that's behind it in SQL.
So here if I could go to open the application as a user,
I can see it either in the start menu
you can see there as Contoso invoicing.
The nice thing is because it's WVD,
I can also pin that to the taskbar,
and it's going to launch that app pretty seamlessly,
and I can see just the app window
and interact with it and do all the testing.
What's even more convenient than that in a lot of cases
is being able to actually test this from a browser.
So, I can do the same thing
through the Windows Virtual Desktop web client,
test just the app window or I can test the full desktop.
One thing to note here is that
these are actually domain-joined machines.
So when I log in
it's actually going against my domain controller
and I'm using my domain credentials
and then when I get into this machine you'll see that
it is domain joined,
so it can reach all the different resources
that I have connected to it
because I'm using a virtual network
between my Azure environment and my on-prem environment.
And if you want to migrate
your existing VDI environment into Azure,
we just published a detailed step-by-step
overview at aka.ms/MechanicsAzureMigrate.
So now we've covered your options
whether you want to bring existing dev/test environments
in the Azure or create new ones,
but Steven, what other tips would you give people
who are just getting started with Azure DevTests
and what tools and resources would you point them to?
First, use those dev/test subscriptions.
Azure has some of the most comprehensive
purpose-built services
for DevTest and you can find out more
at aka.ms/azuredevtestpricing.
And then try out DevTest labs for yourself
at aka.ms/AzureDevTestLabs.
- Thanks so much Steven for joining us today.
These are all great ways to get started
with DevTest and Azure.
By the way, if you haven't already subscribed yet
to Microsoft Mechanics, please do that and keep joining us
for the latest tech updates across Microsoft.
That's all the time we have for this show.
Thanks for watching, we'll see you next time.
(upbeat music)