Hello there everyone.
In this session,
we're going to talk about an
operational expense burden
that, I'm quite sure, like me,
some of you have been living with for,
perhaps three decades.
Specifically, I'm talking about the operational expense
of managing loads of servers.
My name is Dean Wells. I’m a program manager
in the Azure Compute Team,
and I'm going to walk you through a product
that's been in the making for the past two years or so.
Customers have been telling us for years
—and I was one of those customers as of about 12 years ago—
that IT management is complex.
I completely agree.
It is indeed.
So some of the things that they specifically point to
are the reduction of OpEx costs,
that's operational expense.
It's hard to maintain their operational security,
so they'd like to improve that, make it easier.
They'd like to be able to optimize operations
with reliable automation
And again, they would like to use the cloud for this,
but keeping pace with cloud innovation
is a problem in and of itself.
We also decided to have a chat with the developers.
We learn from them that most have a laptop and a dev box.
The dev boxes usually are high-horse powered servers
and unfortunately
they spend a decent chunk of their time
managing operating systems.
That is not desirable.
And then from the IT folks
all the way up the IT management chain,
we heard the feedback that
anything that can simplify
or reduce that human operational expense burden
of managing operating systems
is a differentiator for them.
If we get into some of the details,
customers told us there was no motivation
to refactor their LOB workloads.
Many assumed you had to do that
or, you're just moving it
to run it somewhere else.
And they said that provided little more than
just a different place to run the VM.
There was no OpEx improvement.
And again,
they cited this same factor we referenced earlier on,
that the pace of change in the cloud
makes it hard for them to maintain lockstep
with the updates to the services or new services.
So the lessons that we learn from this are
there are line-of-business apps
still out there,
millions of them,
running on classical computing architecture,
and by that, I mean it's a VM
or a bare metal box.
It's got an operating system on it.
It's got a workload on top of that.
And it may be part of some cluster
or some N-tier application.
This is still a pervasive way
of running computing technology
on-premises as well as in the cloud.
They told us that these line-of-business apps
aren't going to go anywhere quickly,
so from that I can infer there's a long tail.
Microsoft is actually a fantastic example of this.
We have over 5000 line-of-business applications,
some of which
quite literally look like they were written in 1988,
and I'm sure the developer
of that application is now blaming me
for ridiculing his app.
But hey ho, there we go.
Last, but not least,
what could we do
in Azure to simplify this?
What can we do to add value to
these classical computing scenarios
that you can't already get on-premises today?
So we came back and we asked ourself,
what's missing?
We looked at the two ends
of our service stack in Azure where we've got IaaS--
Infrastructure as a Service—
at the bottom end of it
where you literally rent virtual machine
compute hardware from us in a virtualized solution.
And at the top end of that stack,
we've obviously got our PaaS solutions,
where you can pull on cloud APIs
to make development far, far easier
and implement things with elastic scale,
all of those good things.
And then there's the software as a service front.
The canonical example customers give us is,
when we replaced their Microsoft Exchange clusters
with what at the time was Exchange Online and Office 365
and is now coined as Microsoft 365,
that was the panacea
of cloud computing's value to them.
Can we do anything like that
for infrastructure as a service VMs
where they're still running in this classical compute mode?
Well, we figured we could.
We initially sort of toyed with the idea,
and we called it operating system as a service
and you can see it sits nicely on the pyramid there,
in between IaaS and PaaS and SaaS.
The goal of this would be to replace repetitive,
day-to-day ops tasks
with something I referred to as
an exception-only management model.
What this really means is,
rather than you doing the same
human labor,
repetitive tasks on a daily and/or a weekly basis,
the only time that you'll hear from us,
a service that's picking up that slack for you,
is when an exception occurs that we can't handle.
In every other case,
if it's a healthy steady state,
the operating system management burden
becomes a hands-free thing of the past,
because we're doing that work for you.
This is what we like to refer to as Automanage.
So the first of our features is
going to be around Azure best practices
for virtual machines.
That basically means we intelligently onboard
your virtual machines
to a select, curated set of services
according to whether they are
dev/test or production virtual machines.
Today, we're doing something
along the lines of 11 services,
and by the time we reach general availability,
that will be up in the 21 or 22,
I think, at last count.
So key takeaways:
What exactly does Azure Automanage
virtual machine best practices do for you?
So first up,
we intelligently onboard you to select
best-practice Azure services.
We configure each of those services
per that product group’s own set of best practices.
We also configure the guest operating system
per the baseline configuration
that Microsoft has been doling out now
for years with Windows,
and that baseline config
changes with each different version
of Windows Server that's released.
We automatically detect for drift.
If somebody changes the Azure Backup configuration
and it falls outside the scope
of our definition of best practices,
then we are going to drag it,
nicely,
or kicking and screaming if it prefers,
straight back into conformance
with the best practices definition for that service.
And we do this
for the VM's entire life cycle.
Last, but not least,
the onboarding experience is point, click, set, forget
in the portal,
and we obviously also support Azure Policy for at-scale scenarios.
By the time that we're at general availability,
we will also support things like
Python, Go, Cloud Shell,
PowerShell cmdlets with their own module specific to Automanage,
all of those good things.
So if we take a look at VM best practices today,
it does actually exist.
So Azure Automanage's VM best practices feature
is not something entirely new.
It is entirely new in that it's done in code.
The way it existed on Azure in the past,
and still does today,
is in the form of a best practices white paper
that lives in the Cloud Adoption Framework.
If you wanted to implement
Azure virtual machine best practices today,
you would simply browse to the white paper
in the Cloud Adoption Framework.
It's prescriptive guidance, but it's lengthy.
It can take anything upwards of 6 hours
to complete every single one of those tasks manually
So obviously, building automation around that
would be fantastically valuable.
In addition, the white paper is a one-off set of steps.
If it drifts from that configuration
because somebody changed it after the fact,
the white paper isn't going to jump in
and put it back for you.
Automanage virtual machine best practices
obviously will.
So I think rather than continue to talk about this,
what I'd like to do is give you a demonstration
where I'll walk you through a
couple of the portal onboarding experiences.
I'll talk to you about the differences
between dev/test
and production environment VMs,
because you get to tell us
which one it is
and we will choose that curated set of services
according to that particular role in life.
For example, a dev/test machine,
that may be a short lived VM
may only live for a day or two.
You wouldn't really want it onboarded to Azure Backup,
incurring fees from storage of backups in the Backup vault
That's the kind of stuff there.
And then last but not least,
I'll walk you through exactly what our preferences model
allows you to control
about the entire onboarding experience
and the things that we would remediate over time.
So let's jump into a demo.
Here I am in the Azure portal.
All I'm going to do is type in “autom”
and it will bring up Automanage — Azure machine best practices.
This takes me to the main landing page for Automanage.
You can see here that I've got six machines,
five of which are already automanaged,
one of which is in a pending state.
I'm able to click on the pending state
and figure out why it's not yet completed,
and in this particular case it says
the machine was automanaged whilst it was turned off.
Subsequently we're waiting for you guys to turn it back on
and we’ll then complete the Automanage process
and onboard it to all of the services
that make sense for that particular machine.
You'll also notice here
that we support both Windows and Linux.
We don't really care which version of Windows Server
it is that you're running.
For Linux, we support the most popular distros and versions.
So let's go ahead and onboard a new virtual machine
to Azure machine best practices.
We’ll do a couple of them in one go.
So the first thing I need to do is.
click on Enable on existing VM
and then this brings me into the page where I get to choose
which virtual machines, what the configuration is, etc.
So let's start with the machines I'd like to onboard.
You'll notice here we've got the standard
Azure filtering capabilities in place.
You'll also notice that the machines here are listed as eligible,
and I can also check a box that says,
show me the ineligible virtual machines.
This is us assessing all virtual machines
over which you have administrative control,
and making a pre-assessment
as to whether they are eligible or otherwise.
This machine here,
this particular Linux one, is ineligible, as you can see,
because it's currently running in a region
that we don't support.
That is simply because we're only in Public Preview.
By the time we hit general availability, of course,
all regions will be supported.
So, I'll go ahead and de-check that.
Show me only the eligible ones,
at which point I'll choose
one Windows
and one Linux,
and I'll click on Select.
Next, I need to tell Automanage
whether the machine is dev/test
or prod.
The reason for this is,
if we take a look at the comparison between those two choices:
Here's Production.
You'll notice here that it onboards
to all these services and that list will grow
somewhere around 20
by the time we hit general availability.
But if I take a look at Backup,
you'll notice that for the production environment,
I do onboard machines to Backup.
If however, I change the environment to Dev/Test,
you'll notice that Backup disappears from the list.
This is because backing up virtual machines
incurs a fee
to store the backup data in the Backup vault
A dev/test machine may only be alive for three hours.
There's really no reason to back it up.
Hence, for dev/test profiles
we optimize for that workload,
and potentially, for that very short lifetime.
So we'll go ahead and say Prod.
What I'm going to do is
specify my configuration preferences.
If you leave it as the default,
that is indeed Azure Best Practices,
and we will onboard those VMs
per a white paper
named Azure Best Practices for Virtual Machines
that exists in the Azure Cloud Adoption Framework.
If, however, you've got a couple of things you'd like to change,
you can click on Create new preferences,
at which point you give it a name,
and I'll call it Dean11 because I'm a genius.
I'll say it's in that Subscription.
I'll select my standard Resource group.
I'll say it's in the East US region
and right now we support customizations for Backup,
and for Azure IaaS antimalware.
In the case of Backup, for example,
I can specify the frequency, the time zone,
all of those good things.
In the case of Azure IaaS antimalware,
I can configure these basic details in the same way
as you would if you were onboarding manually.
In addition though I can switch it off.
The reason for this is
we found that many customers work with
third-party antimalware technologies,
and they're happy with that particular product,
in which case we've allowed you
to switch off the use of Azure IaaS antimalware
so that it doesn't block you from using Automanage
for the rest of the valuable services
that we onboard you to.
So at this point I would simply go ahead and click Create
and I would click Enable.
That will return me back
to the grid view.
Within a couple of minutes,
those virtual machines will be onboarded to Automanage.
In addition, I can also create automanaged virtual machines from scratch,
so here we are on our operating system’s preview page
that I happen to have up.
I'll click on Create.
This will take us to precisely the same
Azure VM create flow as you're used to.
I'm going to give my virtual machine
the name of DEANO11
—I think I used for the preference—
so we'll use that same number here.
I’ll also select the Windows Server Azure Edition.
This is a Generation 2 VM.
Click on Management
and what you'll notice here is
I have the ability
to have Automanage turned on from day one.
For Windows Server Azure Edition,
it will automatically default
to a production automanaged VM
such that when the machine is created
it will automatically be onboarded
to all of those best practices, services,
and configured and automanaged
from that point forward
across its entire lifecycle.
To reiterate, again, if it drifts
from that configuration,
we will drag it back in
using our remediation technology
to make sure that it is continually configured
to our specification that adheres to
Azure best practices.
I can also do this as well if I
come back to here and I select
this one here, for example,
let's go with Ubuntu,
and I then come back to
Management,
you'll notice that we don't automatically
enable Automanage for every OS release.
For the moment,
that's only for Windows Server Azure Edition.
You'll also notice because Automanage is disabled,
the controls we’re used to having
over which services you onboard to after the creation process,
just that one-time onboarding exercise,
they’re still enabled for you.
If however, I come back up here and I select Production,
because Automanage onboards you to Azure Backup
and monitors that across the entire lifecycle
of your virtual machine,
we no longer allow you to switch Backup off.
That wouldn't make any sense
because the moment machine was born
we would automatically fix it
and onboard it to Azure Backup anyway,
So no reason to present that option.
Last but not least,
obviously I'm showing you the portal
onboarding experience here
for both new VMs
and for existing VMs.
By the time we release the product into general availability,
we will support additional onboarding technologies
such as Python, Go,
direct submission of ARM templates,
Azure Policy, PowerShell,
all of those good things.
So hopefully that was helpful.
Let's go through and show you specifically
which operating systems we support.
Obviously we support Windows Server 2012
2012 R2, 2016, 2019
and the stuff that comes thereafter
and on the Linux front
we support what we consider to be
the dominant distros running in Azure today,
which basically spans SLES
CentOS, RHEL, and Ubuntu,
and the versions are listed there in
little speech bubbles for you.
Let me show you a couple of the differences
that are currently in play today.
We're still in Public Preview at this point,
so hopefully we’ll iron out these differences
as we get closer to general availability.
I certainly don't want to go through this entire table with you
because I think that might well bore you senseless,
but consider this as a table
that you could go and take a look at
after the fact
because I think this would be valuable
for you to understand exactly
what we do for each of the environments.
dev/test and production,
and the differences for each of those environments
between Windows and Linux.
So a few quotes just to throw out at you
from the last Ignite session
where we delivered this and it was basically the
announcement for Automanage best practices.
We've obviously made some substantial progress since then,
but even without Linux support
we still received a plethora of
very, very positive feedback.
My personal favorite here is “Automanage is the bomb.”
I couldn't agree more
and then obviously “Automanage is on fire, fire, fire.”
That made me laugh,
so therefore that's also high on my list.
This is a great summary of
the kind of feedback we've been receiving.
We've got a large number of customers already onboarded
trying Automanage out
in its Public Preview release.
We're still in Public Preview today,
and if you'd like to come and give it a shot,
I've got some links here for you on screen
to get you started,
as well as some deep dive links
that will take you into how do you onboard
at scale using Azure Policy for example.
What things can you affect,
what things can you configure
using the Azure portal, etc.
So that's everything that I have for you today.
I hope you're as excited about the product as I am.
Thank you very much for listening.