>> Hey, friends. Do you know that Azure Stack
enables you to run Azure services in
your data center even if
that data center is on a ship at sea?
But don't think of it as a replacement for Azure.
It's an extension to Azure.
I'm here with Ultan Kinahan to learn
about it today on Azure Friday.
Hey, friends.
I'm Scott Hanselman, and it's
another episode of Azure Friday.
I'm here with Ultan and we're going to
talk about Azure Stack.
This is some hybrid cloud possibilities.
So, the hybrid cloud. What does that mean?
>> Hybrid cloud really is the ability to
bring Azure services into your data center.
So, we've released Azure Stack.
We're coming up in almost a year now.
We released that last September
at Ignite down in Florida,
and the momentum around us has been tremendous.
It has clearly been a hard requirement for
customers out there to have Azure services in
their data centers to meet
regulatory requirements like just workload requirements,
latency, lots of different issues that we've come across.
Lots of workloads that have
just really kind of surprised us as
well like the thought of
Azure Stack on a ship sailing at sea,
in a desert, on trucks,
all sorts of really kind of bizarre scenarios,
but it's fantastic to see that we're able to
meet those needs of our customers.
>> So it's like Azure on the move,
on an oil rig somewhere.
>> It is exactly.
>> That's crazy.
>> Which was really quite fascinating.
>> So, this isn't a replacement for Azure.
This isn't for someone who says,
"I can't use Azure."
>> Absolutely not. No. We've had conversations like this.
If customers come to us and ask for
those needs as well, to be honest,
we tried to deflect them back to
something like Hyper V or something, which is
better suited for those requirements
which are just virtualization workloads.
>> Sure.
>> Stack is Azure.
So, we're bringing pure Azure services into
your data center like IaaS capabilities,
yes, but more importantly, the PaaS capabilities.
So, that's what we really want to try and position and
just kind of direct customers in the appropriate way.
>> I was meeting with a large customer
recently and they were telling
me that in order to get
a virtual machine in their data center,
they had to actually fax
IT for permission and then they would
go and install IaaS and do all this kind
of stuff to put a web app on it.
>> Right.
>> But when we think about Azure,
we think about something that is
elastic, that is programmatic.
So being able to go and do
the same kind of right-click publish
and Git deploys and stuff to Azure app service,
but it's on a piece of hardware I can touch.
>> Absolutely.
>> That's really interesting because the cloud,
when you think of the Cloud,
it's not something you can visit.
>> Yes, correct. So, it's a complete game changer for us,
bringing those capabilities to customers.
But what's really cool with what we've done is we've
integrated this with Visual Studio as well.
So, we're all familiar with how you can go and very
easily deploy from a Visual Studio to Azure.
We've now replicated that for Azure Stack.
So, we even have an Azure Stack repo
where you can go and pull all of
the pre-canned templates and
immediately start building solutions.
Now, those templates can be
deployed to either Azure or Azure Stack.
>> Okay. So ARM,
the Azure Resource Manager,
exist in both places because it is Azure.
>> Absolutely. So, we've taken the code from Azure,
plugged that into Azure Stack to
enable that identical ecosystem.
So, it's the same portal experience,
same look and feel,
and then even from the Dev Ops side,
like Visual Studio, et cetera,
you can then easily just deploy to either endpoint.
>> Azure moves fast.
The Azure APIs move fast.
The versioning of what's going on,
those APIs moves fast,
and it can move fast because it
can also be backwards compatible.
But I would assume, if I were going to have
an Azure Stack in my office,
I might not want to move it so fast so I would
assume that the versions may not necessarily line up.
>> They do not line up. No. So, Azure Stack
is behind the most current builds of Azure.
>> On purpose?
>> On purpose. To be honest,
I'm not sure I ever see them lining up in full parity.
Some of the services might.
>> If only for a moment and then one would go.
>> Yes, because we are,
as Microsoft, an Azure-first company as well.
Everything we build is going to be for Azure
first, and will later trickle down to Azure Stack.
But all of the services that are going to come to
Azure Stack are also based on customer demand.
So, it's quite interesting to see what's coming in.
Like IoT is a really, really big one,
very heavy ask from all of our customers out there.
When you think about oil fields like
oil rigs and ships and certain scenarios,
IoT is required to light up a lot of those capabilities.
So, a few months ago,
we did announce IoT Hub is coming to Azure Stack,
and so that's going to drop
at some point in the not too distant future.
That's actually going to bring other services as well,
our requirements for IoT Hub,
things like CosmoDB, stuff like that.
>> Oh, I see, complimentary service.
So, the customer says, "I want
IoT Hub on Azure Stack," and say, "Well,
these are the three or four services that are
most complimentary that make IoT Hub shine."
>> Yes.
>> We'll bring them all over.
>> Are more so required for
IoT Hub to be able to operate.
>> There's just something, I'm going to take
some machines I've got lying around and have Azure,
it seems like Azure would need to be more
formal in its requirements.
>> Absolutely more formal.
The only way to get this is to go to your favorite OEM.
So, yes, we're very public about who we're with.
We're with HP, Lenovo, Cisco,
Huawei, and there's a bunch
of them out there that we're working with.
They're the ones that are going to deliver
your Azure Stack to you.
So, once you go and buy your Azure Stack thru the OEM,
they'll actually come and install this.
They'll rack it, configure it,
and integrate that into your network,
and then hand you the keys to your cloud.
>> What does it look like?
Do you have a picture of the Stack?
>> I do. Absolutely. So, here is
just kind of like a breakdown
of what this kind of looks like.
So, we start with the redundant power supplies.
They're going to be in all configurations.
Then we have the redundant top of rack switch,
which is up here as well.
There are going to be 10, 20, 40 gig connectivity.
>> I'm guessing, just because of
what you said in the last two items,
that redundant is going to come up multiple times.
>> Redundant is going to come up multiple times.
But interesting that you
asked that because these two next ones,
the BMC which is a baseboard management controller,
is not redundant nor is the HLH.
These two pieces of the configuration,
we don't really feel that they need to be redundant.
They're not going to impact any workloads.
If one of them goes offline or we lose one,
we can just very easily replace it.
>> I see. So things that need to be redundant
are clearly redundant like
power supplies and top of rack switches.
>> Absolutely. From there,
we just add old and old static configuration as well.
We've quite a large matrix
of what we can support in there.
It starts at four physical servers and
scales up to 16 times 12.
Today, we're going to 16 very shortly,
and then you can have configurations from 12 to 28 cores
from 256 gigs of RAM
up to one and a half terabytes of RAM per node.
So you can actually build this thing out quite large.
But a lot of customers ask as well, that's not an off.
We are working to bring
multiple scale units to this as well.
So, what we're looking at here this picture is actually
diagramming the scale unit or a physical rack of servers.
We're going to be able to add
multiple racks of servers to
your own personal region of Azure in the future.
>> That's kind of a great way to put it.
I like that, my own personal region.
I put things in [inaudible] and I
might put things in Hanselman kitchen,
and just have a rack right there next to the fridge.
>> Absolutely.
>> Are you saying that I can have
four as a minimum or up to 16 in a single rack?
I assume as a company, I could
start out with four-
>> Absolutely.
>> -and have some empty space in
my rack, and then fill it in if I want to as well.
>> You can, absolutely. That's something
that we're having to work and guide
customers through quite heavily is sizing correctly.
People look at this very frequently and say,
well, four servers are not enough.
The reality is, it might be enough if you
actually break your application
apart and look at this correctly.
We don't want to just over subscribe unnecessarily.
>> Well, how much care and feeding does this require?
I know that some people, some personalities,
some companies culturally want
total control, and they
put that in there so that they can know everything.
But this is kind of a nice balance.
You control the hardware.
But do you have to care about the software?
Does Azure heal itself, fix itself, upgrade itself?
>> It has all of the self-healing
capabilities you would expect,
like there's a tremendous amount of
automation built into the Azure Stack platform.
Now, when you buy this,
you're actually buying services as well
from Microsoft and from your OEM.
We will take care of this platform for you.
Any issues arise, you pick up
the phone, you call Microsoft.
We'll go through a process of
allowing us access to your system
for a small period of time in
order to be able to remediate the issues.
>> Right. This is not just a pile of EMs.
>> It's not, not at all.
So, yes, we have all the data underneath the covers but
you have to learn about creating offers and plans,
and managing the capacity.
These are the things that we do at Microsoft on
the Azure public cloud that
people just have never really seen.
>> Oh, that's really interesting. So, you just
made me think about when you said plans,
I think of app services,
and as someone who uses app services extensively,
I make app service plans
which is kind of the VM underneath,
but it's really more of a capacity planning thing.
>> Exactly.
>> That plan, a basic or standard or premium,
might not be what big company needs.
They would make their own plan.
>> Exactly yeah, and when you go and sign up with Azure,
you'll be familiar with going in,
creating a new subscription.
You're going to subscribe to an offer.
Our offers in Azure are basically ala carte.
You can spin up any service you wish to do.
An organization might have a different view on that.
They might want just an IaaS plan,
a database plan, an app service plan, et cetera.
So you can create your own offers
specifically around those services and capabilities.
>> You mentioned that it has ARM and
has Visual Studio. Do you have a demo of that?
>> I do, absolutely. So, let's bounce out of this
and jump right over into my Azure Stack.
So here, what I actually really quickly
like to do is I typically start in the Azure portal.
So we can see, it's the Azure portal
right up here on the top left.
>> It looks like the Azure portal.
>> Yes, absolutely. But now,
we can jump into Azure Stack.
The name changes right here. So, we're in.
It's the same ecosystem,
very same experience, touch and feel, et cetera.
>> Does that mean I can go AZS, log in,
and use all the same tools and
call the same APIs I'm used to using?
>> You can. Like we have different drag commandlets
for Azure Stack so we have our own PowerShell modules.
So it's like AZS versus AZ.
>> That makes sense.
>> Absolutely.
>> Cool.
>> So, this is the tenant portal that
your typical users and your organization would use.
Then, we also have this brand new dashboard,
[inaudible] the Administration dashboard.
This is something that doesn't exist in Azure,
built specifically for Azure Stack.
But here, if you take a look down the blade on
the left side here, we create offers,
plans, manage capacity, my region
management so I can have
multiple regions theoretically right here,
marketplace management, et cetera.
>> It's a terabyte of RAM.
>> Yes.
>> That's just lovely.
This is the part where I ask you for
a review unit that you can
ship over to my kitchen and I
will have a Stack in my house.
>> Absolutely. Shoot me an email.
>> All right. So, it is as Azure,
this means I actually am sitting here and
I realize I already know the Azure Stack.
>> Absolutely.
>> Because I already know Azure, I understand the portal.
>> You do. So, it's a very easy experience to
translate into to bring into
your environment and on-board too.
It is the administration piece where
there's just some learnings have to happen there.
But we will work very closely
with all the customers on-boarding around us as
well to make sure that transition is
smooth and that they understand the process.
>> Cool. Well then, in closing,
let's do something cool in Visual Studio.
>> Absolutely. So, pull up "Studio" here.
So, I have something already
pre-built just to save us some time here.
>> All right.
>> But what I've done is, I've pulled a template in
here from the Azure Stack Github repo,
so all of these are pre-built, predefined.
And this one here,
it's a very simple one where it's going to
deploy just a virtual network.
But one thing I do like to call out here is,
something that we talked about a few
minutes ago is this API version.
So, this is different.
Now, why is this so important is,
when you're developing for Azure and Azure Stack,
you want to be sure that you're developing
toward your right API versions.
That way, you don't have hiccups when you try
to deploy to Azure or Azure Stack.
>> So then, I want to pick one that is
the lowest common denominator between the two?
>> You do. So, like if you're doing your dev test,
just your development work in Azure today,
we do have a policy that you can
apply to an Azure subscription.
It essentially converts that subscription into
an Azure Stack compatible subscription.
So that way you can be assured anything you
develop in that Azure subscription
is going to be compatible.
>> That's a clever idea. So then,
if I did something that was not going to be
Azure Stack compatible at a different API level,
it would kick back an appropriate error and then warn me?
>> Absolutely.
>> That's clever. So as an organization,
I would make my hybrid cloud API versions consistent
across the rack in
my kitchen and the stuff
that's happening in Azure Proper?
>> Absolutely. You're going to get
updated APIs every time
we push out an update of Azure Stack,
and in there, there's going to be service updates.
Those service updates could contain API updates as well.
So you almost have
the ability very easily to stay current.
>> Cool.
>> Okay?
>> All right.
>> So, with that said,
we're then able to just easily
come in here and choose "Deploy",
just do a new deployment.
It goes in the "Reconciles" on my Azure subscriptions.
Sometimes unfortunately it takes a moment,
but what it's doing is pulling up everything
and then I can just deploy to
my Azure's Friday subscription.
I could choose any other one.
So if I choose this one just as an example,
create a new resource group,
it's going to be called AzS-Friday Demo.
Let's just call it 2, so it's easy to tell them apart.
But now you will notice,
my location, I only have one region.
>> Yeah.
>> For Azure, I would have
a multitude all around the world.
>> I only have one kitchen with my new Azure Stack in it.
>> Absolutely.
>> All right.
>> So, just go, create my Resource Group in
disk deployment and off it goes and does its job.
>> And that right click experience,
that deploying experience, that's the same,
I'm going to see the same thing if I'm
looking at Azure or an Azure Stack,
I just need to be conscious of which one I'm pointing.
>> Absolutely. That's one thing
that you have to be always conscious of,
is you will have to deploy to two endpoints.
There's no magic one endpoint for both environments.
>> That wouldn't even really make sense, it makes-
>> Absolutely.
>> As a hybrid cloud, I want to be conscious
about where my customer data is,
and how data flows between them.
>> Without a doubt. Absolutely. So, then
we're just able to easily
come back into the tenant portal,
go over take a look at our resource groups.
Hopefully, we see Demo2 right there.
>> Demo2, already coming through.
>> Yes. And our new virtual networks
should be populating here just momentarily.
>> That's interesting that you point
out the virtual network, too,
because one of the things that I think people that write
applications and people like me that make
apps for app service don't think about is,
they'll put a Pass service
out on top of a virtual machine.
But because we're not IT people,
we're dev, we don't
think about software-based networking.
It's so powerful,
software based networking is eating the world.
>> Yes. Absolutely.
>> No one's moving wires
and pulling stuff to make this happen,
you're actually creating virtual networks,
virtual name- IP address spaces
that are all appropriate for my network.
>> Yes. So, we certainly like to
think we're making it easier for everyone.
>> That's fantastic. Where do people go
to learn more about this and to possibly get one?
Do they call their OEM or is there a website?
>> So, you can actually very easily go to azure.com,
and right underneath azure.com,
we have all of our services up there.
So, Azure Stack is under portfolio,
a very comprehensive set
of documentation around it up there,
and we are also publishing all of
our road map items up on the azure.com website as well.
So, all the information you need is right up there.
>> Fantastic. Absolutely great. Thank you for your time.
>> No worries, thank you for having me.
>> All right. I am learning all about Azure Stack and
the power of the hybrid cloud today on Azure Fridays.