>>You know what I'd love to see us do this year?
>>A giant bowl of bacon with your name on it?
>>Well no, I mean yes, but we did that last year,
you remember that.
>>It was tasty.
>>It was.
What I would really love for us to spend time on
is say, a bit of a comparison between AWS and Azure,
and all the data services they provide.
>>Well if you're gonna do cloud,
then shouldn't you also include GCP?
[Thomas laughs] >>That's funny.
So according to Gartner, I would tell you
that AWS, Azure, and Alibaba are larger than Google--
>>Yeah, that's number three.
>>Right, Alibaba's number three.
We don't have time to talk about all four,
so we're gonna focus on just the enterprise
cloud service providers, AWS and Azure.
>>But if we're gonna do that,
we would need an expert on cloud.
[hydraulics hiss] [epic music]
>>I don't know about expert, but I have been working
with cloud for 10, 12 years or so.
>>So this is Rick Claus from Microsoft,
and he's here to help us spend some time
going through some myths, and
"myth-understandings" about cloud.
>>Okay, that works.
>>Do you have some time for us?
>>I do, I got, four, five questions or so,
then I gotta get back in there again.
>>Oh that's perfect.
>>Because that's about how many we have.
>>So where do you wanna start?
>>How 'bout this one?
Cloud is just not secure, I can't use
it in my organization.
[Rick sighs]
>>Yeah, I hear that one a lot.
That one's actually kind of interesting,
because in all honesty, it's a difficult conversation
to have with customers, because you can't really tell them
that they're not secure, but we've got thousands
upon thousands of people who's sole job
is to ensure that we have security and integrity
at every single one of our regions
across the entire world.
And all with the same kind of consistency in bar,
and quite frankly, we've got it set up
and we understand and have been working in this kind
of fashion in such a way for such a long time
that we've got all these extra learnings,
and best practices, and security principles
that are in place for every single kind of deployment
that's out there, too.
>>I often tell people how the cloud data center
is probably far more secure than the owned
data center they have there, and that comes from a person
who has seen the backup tapes just laying
in people's cubes for anybody to walk off with.
>>I've actually had one issue where I've gone
in just to kind of prove a point,
and I've taken a picture of myself
inside the person's server room to be able to show
in confidence with, here you go,
physical security, one of the first steps,
let's work on that.
>>So that conversation really is about
starting with access control management,
as a part of the migration to cloud.
>>But it's not just that, it's also,
if you look at the Azure Trust Center,
you'll find all the compliance stuff
that you have, the PCI, everything that you need
that most companies don't have.
So for me, with a financial services background,
we only need three or four of those compliance,
Azure has all of those.
And AWS has, I believe, as many as well.
But the fact is, the cloud is truly much more secure
than what people give credit for,
where the security really becomes kind of an issue
is it really always has to do with the end user, right?
It's not necessarily something with the cloud.
So the end user leaves the S3 bucket open,
it's not AWS doing that.
Is that the default setting?
Maybe, but it's still the user,
you could always change that in order to make
things easier for that DevOps-y type person
that just wants stuff to work.
>>So does that conversation begin with someone
who understands AD really well?
Roles and groups, and then basically mapping
that onto IM?
>>It could, I think the conversation starts,
so how I always say it -
Security's a shared responsibility.
So just saying it's that one person
in charge of AD?
No, it's everybody has a responsibility
when it comes to proper security.
>>Well you mentioned shared responsibility.
It's also a shared responsibility of understanding
what you're responsible for as the customer,
and also what your provider is responsible for,
from a security perspective.
So yes, definitely shared responsibility is there.
>>Absolutely.
So OK, next question, next myth.
Cloud is only for developers.
>>Oh, and DevOps, because the dev is before the ops.
>>Okay.
[all laugh]
>>You mean rub a little DevOps on it?
>>Yes.
>>Okay, so yes, absolutely.
It does work for the purposes of doing more
DevOps-type practices and principles,
however, what's actually rather interesting is,
who do you think actually uses the cloud,
and works with the interfaces, and does stuff?
It's not actually the developers.
>>Managers.
[Rick laughs] >>It's not the managers,
or the decision makers.
>>Governance.
[Rick laughs] >>It's the operations folks,
it's the IT pros, it's the people
that are actually looking after the servers,
making sure that they're running.
Are they monitored?
Are they secure?
Have they been deployed correctly?
And then maybe yes, they might be integrated
into CICD pipelines, or maybe no,
because they're not there yet with their own
maturity level inside their organizations.
But it's actually the operations folks.
And go even one up that one, who actually uses
serverless technology the most?
>>Operations folks?
>>It's actually the operations folks
that are using it more.
>>They don't wanna package up whole applications,
they just wanna write a little logic
and have it run.
>>Well no, even more so, they're using serverless
as ways of being able to run their own operations tasks,
without having to go off and having to build
something net-new.
You know what?
Throw some PowerShell commands into that,
have a Bash script that goes off and does
this sort of stuff, that runs on top of serverless
because it's like this and done.
You're paying for the fractions of seconds
that it's actually running.
>>See, I would've thought that the reason
IT operations make up 80% of cloud usage
is because it's a handful of developers
that build something, that all of a sudden
now gets tagged as mission-critical,
and they throw it over the wall,
and now Operations has to support it.
>>Hopefully we're not doing the throwing-
over-the-wall thing anymore.
>>Well isn't that the whole point of operations?
IT exists when technology becomes commodity,
when all your competitors are using the same thing,
and it's about cost management.
So of course, cloud is now just one more tool
that we work with, like everything else,
because it's always gonna end up in IT.
>>Right.
>>Okay here's one, cloud can't be innovative
because it's made out of the same commodity stuff
that we've been running.
Gateway 2000, cloud, same hardware, just faster.
>>So, did cloud run under someone's desk somewhere?
>>That's the thing.
>>There is commodity hardware that's in there.
Absolutely, that's how you get scale,
that's how you've got the ability.
But that's the fabric.
There's also the ability to put specialized
hardware in there.
What's even cooler, is the fact that as you deploy,
for instance IaaS infrastructure, virtual machines,
on top of this fabric, which is running in the cloud,
you automatically benefit from all the changes
that we do with refreshing our hardware
completely seamlessly.
You don't even know that it's happening underneath.
So you now all of a sudden can be running
on top of the latest and greatest AMD hardware,
maybe you wanna go off and try some of the cutting-edge
NVIDIA GPU stuff that's going on.
I mean heck, even before filming this,
we happened to just announce our new six-terabyte
and 12 terabytes of RAM VMs that you can now run
inside of Azure.
>>Can those be dedicated servers?
Or is it shared?
>>That is a virtual machine right on top
of the hardware, the hardware's big enough
to be able to support that as a virtual machine.
>>Oh wow.
>>Those are very special purpose-built ones.
In fact, you can even get special purpose-built stuff
like a Cray computer, you can go off and rent as well.
>>How about quantum?
>>I'm not allowed to talk about that.
[Thomas laughs]
>>Well you are or you aren't, but you haven't decided yet.
[all laugh]
But I was gonna say actually though,
Tom has done a lot with machine learning labs
and the rest of it, and so that aspect
that is truly different was commodity hardware
is not configurable by software.
So for example, hey this model's taking
a really long time to learn, wait a minute, you know what,
I'll just spin up some GPU instances for a couple hours,
go ahead and train these models,
and then turn that off.
So that flexibility, not at all commodity.
>>I think what gets lost, especially when you try
to figure out, when you're looking at AWS or Azure,
it's hard to know and get details about the machines.
They exist, but it's not readily available
and it's not easy to compare.
So, when you go to AWS and you're like,
"What's X to large whatever?"
And you're like, "How does that match
to something in Azure?"
And there's no mapping there to say this one
is this size, because the sizes are never exactly equal.
One has 56 gigs of RAM, the other one has 62
or something.
>>That's kind of a benefit, just from the perspective
of it's flexible for whatever the customers want.
And so maybe AWS is seeing that their customers
are looking for this type of configuration.
What is it?
You're chopping up the CPU, chopping up how much RAM
you have access to, how fast are your disks,
and also what kind of network connectivity you have.
Those four basic principles are stuff
that we've all been working with as people
that work in IT when we're spec'ing out systems to build.
>>Well that's part of the reason
that we see so many of our customers
who the most-used cloud that they use is Azure,
is that they're using our server
and application monitoring tools,
and they will monitor their on-prem existing VMs,
and then they'll set up an instance in AWS,
or wherever, or in Azure, and then they'll compare
the relative performance so that they can figure out
how to set that instance size right.
So that taking and looking at the data,
and figuring out on your own how big
those instances size, is so much easier
for comparing it against what you already know.
>>So you can literally say, "Oh dialed it up too big,
I'm gonna dial it down a bit."
I can step down a notch, restart the machine,
I bring it back up again, I'm now paying less
for that machine.
"Oh I need some more at the end of the month."
Bump that up two or three, and in the machine
learning side, I don't just wanna go big,
I wanna go wide so I can just provision five,
10, 15, 20 more machines, 1,000 more machines,
and I can still use it.
You want that on commodity, but you also want
the options for specialized.
>>I try to tell people, commodity hardware
doesn't mean commodity performance.
Okay, here's another myth for you,
I hear this a lot, cloud requires new skills.
>>No.
[Thomas laughs]
>>I'm sorry, it does not require new skills.
It requires you to pivot your existing skills.
>>What do you mean?
>>Literally, we were having a discussion
about this earlier, he has problems being able
to do subnetting in his head,
and being able to figure out the mask bits,
and then the network bits, and then the host bits,
that sort of stuff.
Well guess what?
That stuff is still applicable now,
because of virtual networking,
because of subnetting, and architectures,
and three-tier architectures if you still happen
to want to use those, that's all still the same.
>>Okay, you outed me about that,
but the other-- [Thomas laughs]
But really, it's really that I find
that you can use the skills that you already have
in ways you wouldn't expect.
In your example, I've come to rely
on our free tool for the subnet calculator
because it's just so handy, and it's just quicker,
and it's sort of double-checking my math.
But the skills that you use to make sure
that applications are performing the way
that you would expect, the sorts of things
that you care about in terms of configuration,
the issues the user faced, the way that you troubleshoot,
some of the interfaces are different maybe,
or you are using programmatic interfaces or APIs
a little bit more, but you're still using
90% of what you've been doing as a part
of operations for your whole career.
So, a lot of it ends up being sort of nomenclature
and taxonomy and the rest of it,
but you drill down to it, and oh it's the same thing
that I've been doing, just on a different
set of servers.
>>Yup, again, I call that a pivot
of your tribal knowledge, the stuff
that you already know.
Very simple.
>>Trying to say that to my database friends,
my data brethren.
The idea isn't that it's a completely new skill for you,
because the database, let's face it,
the request is either running, runnable, or suspended.
It's all the same, it doesn't matter
where that engine sits.
So those basic skills that you have,
especially as a DBA, where you understand disk,
and memory network, and CPU,
all of that still transfers to cloud.
It's just that you also get this benefit
of having the cloud service provider do a lot of things
for you that you don't have to do anymore,
like backups.
Sure, I'm still gonna worry that I can't recover.
Okay, there are ways to get around that,
but you also don't have to be worried
about the configuration, and the reports,
and everything else you've been doing for decades.
Troubleshooting becomes a little bit different,
somewhat easier in some cases,
somewhat more difficult, only because I can't go over
and tell the guy in the Azure data center
to go check on the server, or the rack,
or things like that.
Or I can't RDP to it like I used to.
So you have to just kind of take that pivot and say,
"All right, here are the things I can't do anymore,
here's a long list of stuff I'm still
gonna be able to do, here's the very few
things I can't do."
Just because you can't do those things
is no reason for you to say, "Forget this
cloud stuff," right?
>>Well there's also the aspect of as you become
more experienced and more senior in your career,
doing the skills stuff is not as interesting
as making decisions and actually helping the business
based on knowledge.
So for me, it feels more like it's a pivot
from absolute special virtuoso skills
to being able to expand what you're doing
and expand your scope of influence
based on using knowledge that you've
spent decades collecting.
We have knocked down all the myths about cloud,
and everything should just go to the cloud now, right?
Just all of it, everything.
>>Uh, actually as the Microsoft guy,
I'm gonna say no.
But, there's the but, make sure you do your homework
and your analysis, because there's definitely
workloads that'll benefit from going to the cloud,
there's a lot of them, and there's also workloads
that'll make sense to keep on-premises.
It depends on where your own maturity cycle
is inside your organization to see if you're
ready for it or not.
Maybe I'm gonna be much more cloud-friendly
and less cloud-averse, so I'm gonna go ahead
and look at moving all my stuff in there.
Or maybe I'm gonna be brand-new, start-up,
or a new environment, where I don't have to have
this existing legacy thing.
I can go in and just create it all inside
of the cloud environment, too.
So, not everything should go.
That's why places like co-locations,
and hosters, and stuff like that.
I did a data center tour at Swift when
I was in Las Vegas just recently.
Ooh, that is a nice co-lo facility.
>>It's pretty.
>>Very, very nice co-lo facility.
They built that specifically because they felt
that we needed to have a place
that would have super-great connectivity
and provide access to the public cloud,
but would still give people the ability
to go and to house some of their stuff
still locally where they can go, see, feel,
and touch it because they weren't ready just yet.
>>So just like everything else with technology,
you wouldn't say everything is going to technology X
with cloud any more than you would with anything else.
So, where do you recommend that people start?
How do they step back and maybe look
at applications, or infrastructure
that they haven't considered in a very long time,
or thought of it as monolithic?
Where do they start to stop and figure out
where those lines are to figure out
what good candidates might be?
>>It's again, I'm gonna give you my consulting answer,
it depends.
Really the intrinsic nature of knowing your environment
is gonna kind of dictate which of the easy ones
to go off and start with.
The trick that I wanna remind people of is,
when you're looking at moving something,
like a lift and shift of a particular application
and all the supporting pieces of that application
up into a cloud environment, use that opportunity
to rearchitect it and to make it better,
to leverage some of the cloud technologies.
And also, look at possibly reimagining
what that application's doing,
so you can start to use a managed instance of SQL,
as an example, as opposed to a SQL on top of IaaS.
You're gonna start to use, oh maybe we can break
this part off and make it into a microservice,
as opposed to a gigantic front-end web service
in the front of it.
So you can take advantage of some scale
and that kind of stuff.
>>So not just lift and shift, but move and improve.
>>Ooh, I like that. [Rick laughs]
>>But that's what a lot of our customers are doing,
and what they're doing is having conversations
maybe that they didn't have before with the business.
That thing where you've inherited the system,
it's been running for years and years,
and no one has gone to figure out whether
it's actually meeting its original charter.
So a lot of that seems to be also,
go back and figure out what parts of the business
drove what technology decisions in the first place,
and unbundle that.
And a lot of times, that'll identify
those natural demarc points between different
parts of your infrastructure.
>>I like that.
>>Well Rick, thanks for taking the time
to come here today and help debunk a handful
of cloud myths.
And you know, this cloud computing thing may be legit.
>>Hey man I've been working with it for about 10 years,
I think it is.
>>Yeah, and all you've gotta do is spend a little bit
of time looking at the THWACK community
and when they're talking about,
y'all have been using it for a really long time.
>>So you guys got this, you guys are in good hands.
[hydraulics hiss] [epic music]
>>16,000 milliseconds.
>>Yeah about that.