Hey, friends. I'm Scott Hanselman, and
this is Azure Friday.
I'm here with.
We're talking about the Azure Instance Metadata Service.
>> Yes.
>> What is that?
That's a complicated thing.
>> Well, when any VM or
any infrastructure service component comes up in Azure,
you need to know some metadata about it, right.
Today you could source that metadata from when you're
deploying that VM and
you're burning that information in the VM itself.
It kinda gets complicated.
Simple scenarios, like I wanna run an encryption service but
I don't want to enable 2048-bit encryption in the Asia region.
I just wanna enable in the United States.
How do I detect where my VM is gonna be running, right?
It's a very simple problem.
Tell me which region- >> I guess I'd have
to query the VM and ask it.
And I'd have hundreds of resources I'd have to be asking.
>> Exactly, or the VM queries some information about itself,
and gets hey, I'm running in US, or I'm running in Asia, right?
Another simple scenario,
I'm gonna run a data workload like Cassandra.
And I want some safety in my deployment.
I wanna be able to find out, tell me which racks these VMs
are running so that I can spread my data across.
So how do I get the information about fault domain or
update domains that Azure has to provide for
safety from within the VM?
All this information today gets sent from outside.
So what Instant Metadata Service does,
it's an unauthenticated endpoint available only to Azure VMs
which you can query on a VM IP address, 169.254.169.254.
And it gives you information about running the VM.
>> It lets you know if you are in the matrix or not.
>> Exactly, let me quickly show you a quick demo.
>> That's cool.
>> So it's only available from inside?
>> Inside the VM.
>> And it tells you about yourself.
>> Exactly, so I'm right now logged onto an Azure VM.
>> Okay. >> So that's VM,
I'm simply gonna call an endpoint.
>> What a clever idea.
Okay, so let me break this down.
So there's your well-known number.
>> Exactly, exactly >> It's easy to memorize once
you've figured it out, cuz it looks like one of those
didn't-get-an-IP-address IP addresses.
>> Exactly, it's an internal IP, and it is actually an IEEE
known IP address which is kept for internal purposes only.
>> Is it?
>> Yes. >> Okay, so
this is a reserved ISP at the entry level.
>> It's a standard level.
>> And then a very easy to understand and versioned API.
>> Exactly, so
you start with the top level namespace like metadata, right,
and then you get the instance level view y/instance.
>> Right. >> And
all the APIs are versioned, as you can see.
>> Yes.
>> These versions are in a documented outside, and
we don't actually allow latest.
Now here's a quick question.
Why wouldn't you allow latest, right?
Azure runs in 36 different regions.
And we also have Azure Stack.
Think about a developer, what does latest really mean for
the developer, right?
>> Yeah.
>> I mean, it can confuse more than actually create realities.
>> So what I've done, I've just used a simple JQ utility which
that really formats the JSON.
>> Right, the JSON.
>> The interface, the API, actually gives you a JSON back,
right?
You could also get a text back.
I'll show you a quick example of that.
So let me break it down as to what you get today.
So you get both at a top level,
you get a compute as well as network level information.
So in compute, you're looking for what location the example
that I gave you before, location mirroring.
I'm actually running on west central US right now.
This VM's running in west central US.
The name of my VM, right, which was created, which is
different than potentially the host name that you chose in your
startup scripts, right, the kind of OS that this is running.
And as I said about the fall domain and update domain,
this is telling you that this is running on a fall domain,
update domain of 0, right?
Now if this VM wasn't available to dissect, and
I'll give you a quick example shortly,
you would see that these numbers would be different.
I also get to know what the publisher of this OS is, right?
So I know this is a canonical publisher, and
I know the version of Google that I'm running.
>> What if this changed internally?
If I apt to get dist-upgrade- >> Yes.
>> Would this know?
>> Actually, it won't.
That's a very good question.
>> Cuz this is where it came from.
>> Exactly, this is what the platform thinks you are.
>> Yeah. >> Azure wants to respect your
VM's privacy.
We don't actually go poking around within the VM to find
out if you have changed certain things.
>> Indeed, so
that's the version of the image when it was created.
>> Exactly, and
then here's another interesting data point that is provided.
It's called VMID.
VMID is a unique identifier for the running VM in Azure for
its life cycle.
So if you shut down, you start it again.
The idea will remain the same.
Unless you destroy the VM, you won't change the ID.
This is irrelevant for many telemetry scenarios.
So if you are running datalog.
On your VM, it needs to know that this instance of VM is
different than that instance of VM.
>> Yeah, I understand.
>> This VM ID gives you that information.
>> I had a customer ask me recently who was creating
a product that they wanted to license.
>> Right. >> On a VM by VM basis.
>> Correct.
>> Could this be used for them?
>> Exactly.
This enables that scenario that you can use VM ID, and
I'll show you what's coming down the road in our preview version
shortly, where you can have even more data
points to actually tied the licensing together.
>> It's really great that you're telling me about this because I
can tell you that there have been times when I've wanted this
information and I've ended up hard coding it in
environment variables in order to get it.
>> Exactly and I'm here to solve your problem, right?
>> I appreciate it.
>> I totally understand that that is not maintainable unless
something becomes crazy.
The other important thing that I wanna talk about is the VM size.
We actually give you the size of the VM.
Now why is this relevant, you may ask, right?
Think about SAP, you're running a big SAP workload, right?
And then you make a support call to SAP.
SAP will wanna know,
tell me what size of the VM you're running.
Maybe you're running it on a standard A2 and being cheap.
But SAP is never supposed to run on that kind of configuration.
>> I see a tool that could detect it was running in Azure
could even then pop up a warning and
suggest maybe you don't wanna do that.
>> Yep.
>> So I could make my application Azure aware by
querying that internal address.
>> That is correct.
The other thing that I want to quickly talk about is the other
network [INAUDIBLE] information.
As you can see, I'm giving you both the internal private IP
address but also the public IP.
With a VM running on Azure,
you actually do not know what the public IP for that VM is.
And so because all the magic happens at a layer that's much
higher than what the VM is running.
So this allows you to know what IPs I'm responding to, so
you can do some clever things in terms of your internal telemetry
and internal failovers.
So with that said, I wanna just quickly talk about some
semantics that the API provides, because you would see a JSON and
say, okay, but I'm a short scripter, right?
I don't want to deal with JSON,
what am I going to do with this, right?
And so the API also allows you to specify a format,
specify it, which will give you a response back in text.
Now this is giving you a text response at each level the data
represents.
So right now I'll give you the top level entries of
the computer network, right?
If you change the API and actually go down the path, where
after instance I say /compute, it will let you discover
the other data points that are available we can compute.
And so on and so forth.
So if I'm just interested in say, the author or
the name of the VM, right?
>> Or just the public IP or whatever.
>> Exactly.
>> You simply path your way down there,
which makes your cell scripting much simpler.
>> Exactly, and a real-life example for this is what
Cassandra Deployments on Azure is already doing.
So here's the, an example of deploying Cassandra, right?
>> I see it right there.
>> And it tries to get the file domain.
So then the nodes are coming up, it tries to get the file domain,
and based on file domain, it tries to make sure that whenever
it's deploying any data set,
that replica sets have kept In different fault areas.
So that if one fault domain goes out, which means one rack going
down, in terms of an Azure perspective,
you don't lose all of your data.
So this is a real-life example of what solutions are already
using metadata service for.
>> Will this ever be presented to app service so
I can understand the VM that my app services inside?
Cuz could see there would be a lot of value in a similar-
>> So today,
from calling metadata service from the internal VM is open to
anybody from within the VM,
as long as they can query this endpoint.
Now, within our VM administrator may choose not to allow every
user from internal VM like an app service user to query
the metadata endpoint.
But it's a policy that the administrator of the VM
controls.
From an Azure point of view from the internal VM you can call
metadata and get into some information about this.
And this is actually by design because we kept this interface
unauthenticated because authentication is the VM, right?
And any component that is coming in,
new information can do interesting things.
Going forward, real quick on another set of
examples that you can do with the metadata endpoint,
I just want to give you what is coming in future.
So, We are letting the version, right?
As you can see the version was 0402,
you have a new version that is gonna come out, right?
Right now this is a preview version 0701 but
the release version is gonna be 0801.
>> Okay.
>> I just wanna give a quick sneak peek in terms of
what's gonna come from a user point of view So-
>> I see tags that's new.
>> Exactly, right?
So you get to see the tags of the running VM.
So if you add a tag, you get to see it here.
>> So I can stick my own metadata in there and
funnel it in.
>> Absolutely.
>> Very cool.
>> And then the other thing that's gonna come in,
is this subscription ID, and the resource group name.
So you could actually create the resource ID
which is subscription, a resource group name and
the VM name, to actually go and talk to ARM
if you have the right principles available within the VM.
So this is something that will unblock
a lot of the licensing scenarios that you talked about earlier,
and also frankly, have richer telemetry.
So you actually know if I'm an IS3 publishing information
marketplace, like Cisco.
They would want to know how many different subscriptions
are using my image, right?
They get to know this right away.
So, this is something that's gonna come shortly.
We're gonna continuously update the service to add more and
more data points.
And connect back with us on feedback.azure.com or
send us an email at azuremds@microsoft.
>> Very cool, so people can start using this right now,
certainly the April version is around,
the August one coming soon.
>> Correct, exactly, so this API is available.
It's generally available on all of public Azure.
It's going to be available shortly in all of our
national sovereign Clouds, like the government Cloud in
the United States and German, or China Cloud.
And once the new one is available,
the docs that are published in Microsoft Docs,
which let me take a quick sneak peek.
Will get updated to allow you to have up to date information to
what is available and what's not available and
embed all the sources that are available today.
>> Fantastic.
>> And all the service semantics that are also a part of this.
I give you a quick demo of a resting point you wanna know
what happens, what is my throttling rate,
what is my QPS and other things.
All those details and
[INAUDIBLE] are available in the docs.
>> Fantastic thank you so much for hanging out with me today.
I am learning all about the Azure instance metadata service
here on Azure Friday.
[MUSIC]