[MUSIC PLAYING]
STEPHANIE WONG: Hey, everyone.
Welcome back to "Eyes on Enterprise,"
where I bring in Googlers to talk about the technology
landscapes that are shaping how enterprises adapt,
modernize, and scale.
I'm Stephanie Wong, and today, I'm
bringing back on Brian Dorsey.
He is a developer advocate for Compute,
and we're going to be talking about how you should rethink
your VMs, which I'm excited to hear about,
because I'm unsure of what you actually mean by that.
BRIAN DORSEY: Excellent.
Let's do it.
STEPHANIE WONG: Let's start by examining our assumptions
about VMs.
What are some of those assumptions?
To me, a VM is a virtual computer.
You have CPU, memory, disks, networking.
What else is different here?
BRIAN DORSEY: Yes, that's exactly it.
It's relevant, though, that it's the base of many,
many of our other services.
It is super common in architectures.
Everybody's running some VMs.
But if you're only thinking about it as a classic VM,
you might be leaving time and money on the table.
STEPHANIE WONG: Oh.
Time and money.
That's everyone's top-of-mind, right?
BRIAN DORSEY: Yep.
STEPHANIE WONG: Interested in hearing more,
but as I imagine, don't Google Cloud VMs typically fit
in that model?
BRIAN DORSEY: At a high level, yes.
It is an abstraction of this CPU network disk RAM.
But we're used to thinking of that
as a slice of one computer, and it's really
a slice of resources that are across the whole data center.
That enables a whole bunch of agility and reliability
that you wouldn't notice otherwise or you might not get.
STEPHANIE WONG: I imagine this is the basis of what
you mean by rethinking VMs--
slice of a data center.
Can you dive into more about how that's
truly different than otherwise?
BRIAN DORSEY: Yeah.
An example of that is, when you buy a computer,
it's a big decision.
You buy it, and you have it three to five years,
or whatever, and you're stuck with that shape.
When you turn on a VM in the cloud,
you're really setting the configuration for that machine
right then.
And if you turn it off, you can keep the disk around, the boot
disk, and then you can just turn it back on with a completely
different configuration.
So you can be like, oh, I've got a two-core machine.
Or, now I've got a 25-core machine or a 250-core machine,
and maybe I only want that for an hour or a day.
That kind of thinking gives you a bunch of flexibility
to be able to respond to peak loads,
to do reports that need a big crunch
at the end of the month--
whatever it is, without building a lot more complexity
into the system.
STEPHANIE WONG: Google is a huge company,
and we have a large amount of Compute power in the data
center.
What's possible with this amount of infrastructure?
BRIAN DORSEY: I think the classic thing
that people talk about is scaling out, right?
You've got one service.
Then you run it on multiple machines,
and you can scale out really well.
That's true.
But also, I think things have snuck up on us a little bit.
The level that you can scale up to has gotten huge.
Our largest VMs are, currently, 416-core machines
with 12 terabytes of memory, large disks,
and that sort of thing.
So the limit that you can scale a given machine up to,
like a database, is quite high, and if you
do keep it to one machine, you simplify things a bit.
I was shopping for hard disks recently,
and the largest one I could find was 14 terabytes.
You can get a machine with almost that much memory
as you'd normally buy for disks, so there's plenty of room
to scale up as well.
And for apps that have been around for a while,
scaling out could mean a whole re-architecture.
Or scaling up, you could just turn a dial,
and it can really help solve a lot of problems
and save time and money.
STEPHANIE WONG: Why does scale-up actually
matter in this case?
BRIAN DORSEY: Some of the concrete examples
are, like, a database, which can get really complex when you
start trying to [? short ?] it.
Another common use case for the really big machines
is things like SAP HANA which is a large in-memory database.
It just has to run on one machine.
Things like that.
I think it just gives you more headroom to keep things running
that you don't--
it's not the time to do a big re-architecture
for the organization, but it does need
to grow with your organization.
You can do that more easily.
STEPHANIE WONG: You mentioned VM reboots.
How fast is that, actually, on Google Cloud?
BRIAN DORSEY: It's actually pretty quick.
We can start a machine from scratch, boot the OS,
get to your code running in 20 to 30 seconds.
For a lot of situations, that is plenty fast.
And that's from nothing.
There's no planning, no talking to another team
for provisioning.
It's just ready to go.
STEPHANIE WONG: I've worked with VMs before,
and that usually involved deploying the hypervisor
and deploying the VM on VirtualBox or VMware,
for example--
a lot of steps, I concur.
So is it easier here, in this case?
BRIAN DORSEY: Yeah.
I think the main thing is not worrying
about management of all of the machines underneath.
You actually don't have to worry about the Tetris game of trying
to fit your VMs in with the right other VMs,
or whether you have space for them.
That sort of thing.
That still happens, but it'll happen on the back end.
You don't have to worry about it.
STEPHANIE WONG: What does this all mean, practically?
BRIAN DORSEY: You can make the machine that's exactly
the right shape for your workload
and not leave idle machines running,
because they cost money.
You can actually make it the right shape.
The other place this plays out is--
when you're running all your own stuff,
you're always trying to keep the most
utilization of the hardware you can,
because you've paid for it.
You want to use it, right?
If you can make a machine that is exactly
the right shape for your workload,
you automatically get the right utilization.
In fact, we'll even recommend-- oh, hey, this machine
isn't getting as much use as it could be.
You might want to make it smaller.
Or vice versa.
It seems to be slammed.
Maybe it needs to be a little bigger.
That sort of thing.
STEPHANIE WONG: Yeah.
You're moving away from the mental model of "How do I
make the most use of this box that I've already
deployed, procured, and paid for" versus, "OK.
I've deployed it, but I can actually
backtrack and redeploy using a different shape,
so I can optimize for the CPU utilization, memory,
and all these other things."
BRIAN DORSEY: That's true both with the planning--
you don't have to overcommit early on in a project.
But I think, again, where it's not so obvious,
is that time scales can be short, too,
so you can reboot it and run it for an hour in the bigger
shape, or a certain time of the month, or what have you.
STEPHANIE WONG: We talked about scale-up.
What about scale-out cases?
BRIAN DORSEY: This is like the classic sweet spot for Cloud,
where you have multiple computers cooperating
to do things.
We have tools built in to Compute Engine
to help you scale up and down.
There's a thing called managed instance groups that
connects to a load balancer, and you can, either automatically
or on your config, decide how many machines are actually
behind that load balancer.
It can be one, or it can be 20, and that can automatically
scale up or down or be on a dial.
You basically call an API for how big or small
you want it to be.
In addition to that, there are cases
where you want to be doing batch workloads
or where those machines don't all
have to be running that much, and it really
helps us out, for planning, if we can schedule things.
So we offer a very large discount
on machines that don't live that long.
They're called preemptible VMs.
Basically, these VMs can never live more than 24 hours
per machine, but they are an 80% discount in many cases,
so you can be looking at a fifth of the costs of another thing.
If you've got a batch workload, or if you've
got a system with very little state on the particular worker
machines, you can save a lot of money that way.
STEPHANIE WONG: Let's talk about access to the VMs.
Previously, I remember having to SSH into VMs or RDP
into a Windows machine, and then I'd
have to save my session login info
and target the public IP address of the VM.
There are multiple steps, and it wasn't always straightforward.
Is this the same with Google Cloud?
Are there easier ways to access your VMs here?
BRIAN DORSEY: Yeah, or maybe you create
a jump box that's behind the firewall you VPN into,
or something like that, right?
If you need to, you can still do all of those things.
It's very flexible.
And if you've got processes in place, you can keep doing them.
But we also have a couple of tools
to make things easier than that.
When you're using the web console,
you're already logged-in and authenticated with Google.
You've got a user.
We know who you are and that you have access to that project.
There's actually a web-based command line console.
You can just click a button on any VM,
and it will send an SSH key back and forth,
and you can log right in.
STEPHANIE WONG: Nice.
BRIAN DORSEY: That's super handy for one-off situations,
emergency things, or on a tablet when you're out, or whatever.
On the other hand, there is a strong need
in large organizations to keep careful track of who's
allowed to log in where and automate that.
There's a system called OS Login that basically delegates
the "who's allowed" part of it into the overall permission
structure of Google Cloud, which is called IAM.
You can basically delegate that there.
Users can pick their own SSH key,
but the central group can decide who's
actually allowed to log in to which boxes with that key.
STEPHANIE WONG: Is this making it easier
for administrators, who are always
trying to manage public-private key pairings
and sharing it out with their teams?
How does it make it a little bit easier?
BRIAN DORSEY: You can just avoid a bunch of potential mistakes
or grunt work of dealing with all of those,
and I think, on top of that, you can audit it better.
You can tell exactly what the current configuration is,
or you can change it on the fly.
STEPHANIE WONG: Let's talk about disks.
When I think of disks, I imagine you have a boot volume.
You have additional volumes for more storage.
Is that how they work on Google Cloud, too,
or different in this case?
BRIAN DORSEY: This is another example of "yes, and more."
STEPHANIE WONG: "Yes and."
BRIAN DORSEY: "Yes and."
Your model's right.
You've got these disks that you can attach or detach
between multiple machines.
But they are, again, a slice of a data center.
The disks are actually, by default,
network-attached storage, but they're not
attached to some particular machine out there.
They're attached to hundreds or thousands of machines
to get the data back.
So you get very consistent performance,
you get a lot of flexibility to change things very quickly,
and it enables features like--
if your disk fills up, you can just make it bigger.
It also enables things that are really not obvious.
Normally, a disk is in a particular physical location.
Since these are already spread out,
we've got a mode where we actually
spread the blocks across two zones or across a whole region.
You can have what looks like one disk to the VM
actually living in two physical locations,
so you get a whole bunch of disaster recovery crisis
mitigation without actually changing the app at all.
Essentially, what you get is the 80-20 of a SAN.
You get a lot of the features you
want out of a SAN-based disk, but in the cloud.
The other thing that I think is maybe not so obvious is that--
we think of a computer as this physical box,
but in our Cloud VMs, the disk is really the identity.
A boot disk has the operating system and all your software
and everything, and the computer part
is what happens to be configured currently.
When you turn it off, that part all goes away.
And when you turn it back on, we give you a new computer
off the same disk.
That changes the way you think about reliability, resiliency,
flexibility, that sort of thing.
STEPHANIE WONG: You can have persistent storage
for whatever operating system and files that you already
have on that.
And then, if you decide that you want to reboot,
and you want to reshape your VM, for example,
then you still have everything persisting there.
BRIAN DORSEY: That's how it works,
so you know what we're talking about earlier.
It's because that disk lives on, past the config.
STEPHANIE WONG: This all sounds great,
but are there any gotchas or any caveats
here that we should be aware of?
BRIAN DORSEY: Of course.
There's always trade-offs in the world of tech.
And I think one of the things that's not super obvious
is that everybody wants to use disks differently in the cloud.
Some people have tons of storage.
Some people want really high throughput.
And the way we balance all of that out
is by actually connecting, like on a real disk, the throughput
to the size of the disk.
It's not obvious.
We don't think about it that way when we buy a real disk.
But there's a certain amount of storage
and a certain amount of I/O that you
get when you buy one of them.
We extend that out through the whole platform,
so one of the things that can be a gotcha is--
you go to do a performance test.
You pick a small disk, because you're just doing a test,
and it doesn't work that well.
And you're like, what?
This thing sucks.
It's important to look at the docs
and pick the right-size disk for your throughput target.
The short version is that larger disks are faster,
and they are a network disk, so that
uses a certain amount of the network, which
also uses some of the CPU.
The number of CPUs affects the overall throughput,
and the size of the disk does.
So take a look at those docs and make sure
that you size it right for the workload you're trying to get.
STEPHANIE WONG: Let's talk about a scenario
where you want to take a snapshot of a VM
for disaster recovery or any other use case related to that.
Is a different on Google Cloud?
Because I imagine you still have to take a snapshot.
What can it enable you to actually do?
BRIAN DORSEY: This is where their being network-attached
storage is huge, because we can take a snapshot without hardly
affecting the actual usage of the disk at all,
and that snapshot can be used to make a new disk anywhere
in the world, globally, in the same system.
If you're just trying to do straight backups,
or you want to make another copy of it
somewhere else for reliability, redundancy reasons,
that's really straightforward.
Additionally, if you're trying to build a full-on disaster
recovery situation, it might make sense
to think about the overall system a little differently.
It may make sense to have the database online and doing
a database-level replication, maybe to a smaller instance,
and then the rest of the system behind one of these autoscaling
groups, where it only gets bigger, to full size, when
it's actually running.
This sort of thing is something I've talked
to a couple of folks about.
They are thinking, oh, I want to do disaster recovery
in the cloud.
We have 25 machines running the full thing on our side
or in another zone.
We need 25 machines for the disaster recovery site,
and it's the obvious, straightforward way
to think about it, model it.
But likely, you probably only need
one or two machines running all the time,
and the rest of them--
you can take advantage of the flexibility
and just make them exist when you actually have a disaster.
STEPHANIE WONG: And if that were to occur,
I'd imagine that there is a pretty fast ability for it
to become active?
BRIAN DORSEY: Yep.
It's the same thing we were talking about earlier, where
the individual machines are up in 20, 30 seconds,
and they're behind the same load balancer,
so they just scale up to deal with the new traffic.
STEPHANIE WONG: We talked a lot about a lot of things--
VMs.
We talked about load balancers, disks, rethinking VMs entirely.
What can people do to get value out of Cloud right now?
BRIAN DORSEY: That's, in fact, the reason
I'm excited about this, because VMs
are almost always the next step for people
who are getting into Cloud.
It's closest to the architectures they currently
have.
You can run almost any software there.
So they're the next step.
And if you're building up that architecture,
it really helps to dig a little deeper on these,
because you can simplify or maybe leave whole parts of it
out and still get the same reliability or more, and more
flexibility out of it.
That's where the saving time and money comes in.
I really encourage people to go take a look
at the architectures they're thinking about,
connect them to the features we have to simplify them,
and see where you can save some time and money.
STEPHANIE WONG: Awesome.
Well, that's great words to end on.
And also, I want to thank you for coming back on the show,
because I think you have--
BRIAN DORSEY: Thank you.
STEPHANIE WONG: --so much good insight
into shifting your mental model of how
to think about Cloud and VMs.
[MUSIC PLAYING]
Thanks again.
Everyone, again, please join us next time
for "Eyes on Enterprise," and we'll see you again soon.