[MUSIC PLAYING]
CARTER MORGAN: Welcome to this episode
of "VME End to End," where you have a VM enthusiast
and a former VM skeptic--
so now, you have two VM enthusiasts-- talking
about all things VM related.
Brian, welcome to the show.
I'm super excited and a little bashful to have you here today.
BRAIN DORSEY: Likewise.
So you're convinced?
Sweet.
CARTER MORGAN: You have convinced me.
You know what?
Cloud VMs seem relevant.
They seem useful.
They seem a lot of fun.
So I guess what I want to know is, how do I get started?
Do I have to travel back in time?
Find a dusty manual somewhere, blow it off,
look up instructions?
If I want to use this, where do I go?
What do I do?
BRAIN DORSEY: Come on, man.
We're in the cloud now.
So it's a web world, so I think a great place to start
is on the web.
So there's a Cloud console at cloud.google.com
that is a website that you can manage all the cloud,
and in there, Compute Engine.
So I think it's a really good place to see what's possible
and to explore, learn, get some visualizations on what's
going on with the machines.
CARTER MORGAN: And there is a command line,
though, if someone like me is a little more--
BRAIN DORSEY: Oh, yeah.
CARTER MORGAN: Just checking.
Tell me about it.
BRAIN DORSEY: I know you want to go
for efficiency and automation and the like,
there's definitely a command line,
and it uses the same API behind the scenes.
CARTER MORGAN: Do they interact with each other at all,
or are they just two separate tools with the same API?
BRAIN DORSEY: So they're primarily separate tools,
but there's some neat bootstrapping stuff.
One high level is there's actually
a command line embedded in the web UI, so you can hit a button
and get a command line interface off
of, actually, a little VM that we run for you.
But in addition to that, any of the Compute Engine pages
you're on, when you go to, say, create a new VM--
fill out a bunch of things, make a bunch of decisions,
if you scroll to the bottom, there's
a link to get the exact GCloud syntax that
would do the same thing as you'd just set up in the web.
CARTER MORGAN: Oh, that's very cool.
Then you could go into that web shell and use it.
All right, I can see--
BRAIN DORSEY: Copy-paste, go.
CARTER MORGAN: --how that could be useful-- very useful.
One of the things I'm wondering about
is, I come from, again, Container World,
and I'm used to using something like Docker, where
I can declaratively say, this is what
I want my image to look like.
I want it to have this layer.
I want it to have this set of tooling.
Is there anything like that for VMs or Google VMs?
BRAIN DORSEY: Absolutely, and in particular,
people use a lot of Terraform for that.
But I want to take a step back [INAUDIBLE]
some of the things people do on VMs are manual.
And for a long-lived VM, a manual
setup and take some backups, that is a reasonable thing
to do for a one-off.
But as soon as you start having multiple copies of that
or more complex setup, you start wanting automation.
So there are multiple different tools
that use the same APIs to create VMs and configure
the networking and the like.
In particular, Terraform is very, very common.
I think it's also worth checking out Pulumi, and both of those
will let you set up a configuration,
declare how you want things to look, and push that out.
And part of the reason I think this is so important--
so it's important for production to be
able to make things consistent.
But in addition to that, testing is really hard.
Almost nobody can afford to run a full test environment that's
the size of production.
And in physical machines, it, as far as I know, almost never
happens.
But if you have things automated,
you can run a test of a smaller number of machines
or the same number of machines for a shorter amount of time
for way less money.
You're going to be talking 1% or parts of a percent of what
it costs to run a production and do a completely
valid test in the same environment using
the same tools.
So that's really powerful.
CARTER MORGAN: Oh, wow, that's really cool.
And I've actually seen that pattern a lot in Kubernetes.
I talk about Kubernetes a lot because that's my context.
But in Kubernetes, you have this ability
to automate what happens when you do certain actions.
So if I wanted to release some code
and have it go to a small staging area
before it went out fully to production, you could do that.
And what I'm hearing--
tell me if I'm wrong here, but it
sounds like you can do that same thing,
but on a different scale.
You might be able to do that with your entire cloud
infrastructure using some of the tooling you were talking about.
BRAIN DORSEY: Yeah, that's pretty much it.
So people use things like Terraform
to declare the setup of things like--
including a Kubernetes cluster itself, maybe
buckets for storage, maybe a database, some VMs,
like I mentioned.
And you've got your entire setup all scripted out
and repeatable and ready to go.
CARTER MORGAN: See, that's amazing.
And this is one of the reasons why I'm
happy that I've been convinced.
Something I am curious about, though,
is, if I already had my own system--
maybe I switched over to VMs from on prem.
I have my own way of accessing my workloads, my VMs,
all of that-- can I still do it?
For instance, if I had an SSH key,
I was using those to access my system,
can I still use those on Google Cloud?
BRAIN DORSEY: Absolutely, and this gets back to-- the VM
is just a computer, and it's the most compatible thing
we have in cloud.
So if you can do it on a computer,
chances are extremely good you can do it on a VM.
So yes, you can log in with just user accounts and passwords.
You can log in with SSH keys, whatever you've normally
been doing.
For SSH keys, we have a couple of things to help out a bit.
So if you've got automation you've been using,
you can keep doing that for managing keys.
We also have a way where you can push keys up
into the project level and have them be available on the VMs.
And if you're not running something like that,
you're already logging into Google Cloud with a Google
account, so you can essentially delegate
the rights to log into a machine,
and then we will create the SSH keys to make
that happen and make it work.
CARTER MORGAN: Wow, so there's a lot of power there.
I guess-- so there's flexibility.
I can use tooling I already know.
At this point, there's really nothing
that's leaving me or stopping me from signing up and using this.
And then I guess I just--
BRAIN DORSEY: Let's do it.
CARTER MORGAN: I don't know.
I set it.
I let it run.
I get the promo.
I win the day.
I drive off in the nice car.
BRAIN DORSEY: [LAUGHS] It's all done.
CARTER MORGAN: All done.
BRAIN DORSEY: You know software doesn't work that way.
Things change.
The context around it-- you've got new versions.
Maybe the load changes up and down, that sort of thing.
Yeah, so things change, and I think
some of the stuff we've talked about already helps with that.
So when you talk about groups of machines
and a managed instance group getting bigger and smaller,
that helps with load changes over time.
If we decide to do some work, like some planned work,
on the host machine, or the kernel
needs an update or something like that,
we'll do a live migration to move
the VM to another machine with no downtime,
and then do that work.
CARTER MORGAN: That's transparent to me,
it sounds like.
BRAIN DORSEY: Exactly, so that'll
help with some changes that need to happen at the data center
level.
And then when changes happen to your software,
you'll need to update it and do versions.
So if you've got a system you're already using for that,
you can probably continue doing that.
Another pattern that I think is pretty common
in cloud, but not other places, is you build up the whole disk
image, including the software, and then call that version A.
And then you build up another disk image
with a new version of software, call that version B.
And then you can rotate that into one of these groups
and upgrade that way.
And if something goes wrong, you can just
go back to the old image.
CARTER MORGAN: This is why I'm convinced,
because all of these features that you're talking about
are the features that I was like,
oh, this is why I love Kubernetes.
It's so easy to use, it's--
And it's all of them are in the VM world.
BRAIN DORSEY: So I strongly believe
that most of the advantages we get from a cloud native
architecture and that sort of thing
can be done in VMs on the cloud.
So that brings those features, those abilities,
to workloads that might be a lot of work to migrate or require
coordination with another team that may not exist anymore
or with an external company or something you can't do.
And so you can get a bunch of the same benefits
to those workloads as well.
CARTER MORGAN: Wow, so like I said at the very beginning
of the episode, I'm convinced.
I'm going to go try this.
And if you're watching this at home, one,
thank you so much for watching us talk
about VMs for six episodes.
But two, go and try this out.
And then, Brian, you've led the direction of the conversation
so far.
What we need to talk about next, where
do you think we should go from here at this point?
BRAIN DORSEY: So I think we've hit a pretty good baseline
of fundamentals, but I think where
we go next really depends where people want it to go.
So I would love if folks who watched this long-- again,
thank you--
commented below to say, here's what
I'd love to learn more about, what
I'd love to go deeper on, I'd like to see an example of,
or could you bring in another expert to talk about something,
those kinds of things.
CARTER MORGAN: So let's do that.
If you're watching this at home, leave a comment below.
Tell us what we should explore next, like I don't know,
security or any other topics, and we'll take a look
and see where we're going to go in the future.
Thanks again for watching.
That's the end of this season, and that's the end
of "VME End to End" for now.
Thanks, Brian.
[MUSIC PLAYING]