[MUSIC PLAYING]
CARTER MORGAN: Welcome to another episode
of "VM End-to-End," a show where we have a former, maybe even
reformed VM skeptic and a VM enthusiast, my friend
Brian, together to hash out all things VMs.
Brian, thank you for being here.
What is this episode about?
You just told me it's special, I had to be here,
and that was it.
BRIAN DORSEY: Yeah, I think you're going to like this.
It's where I admit that VMs might not always be the answer.
CARTER MORGAN: Can you say that one more time?
BRIAN DORSEY: VMs might not always be the answer.
It depends.
And so with that in mind, I wanted
to bring in an expert colleague of ours
who has been a sysadmin, who has run
all kinds of different machines, and who's
now focused on serverless.
Welcome, Katie.
KATIE MCLAUGHLIN: Hello.
Thank you for inviting me, Brian.
CARTER MORGAN: Yes.
And Katie, I'm extra excited.
I don't know if you-- yeah, you just
heard what Brian said about maybe VMs not always
being the answer.
Didn't you get to play around with the Migrate for Cloud Run
tooling?
KATIE MCLAUGHLIN: I did.
Brian, have you heard about this one?
It's very cool.
BRIAN DORSEY: Honestly, I think I heard about it.
And let me make sure I'm right.
Is this the thing that claims to be
able to make containerized setups out
of what's running on a VM?
KATIE MCLAUGHLIN: Yes, and it works.
I've tried it.
BRIAN DORSEY: Wait, OK.
OK, I have to admit, I was so skeptical of this.
It's so much often considered an anti-pattern.
And you can't just lift this whole VM into a container.
Containers aren't VMs, all this sort of stuff,
that I didn't actually look at it as carefully as I probably
should, because it didn't pass my is-this-real test.
So how was I wrong about that?
KATIE MCLAUGHLIN: I had the same sort of thought.
It's like, but if I've got a complex VM that's
got all these different services-- some of them
are socket-driven, some of them are
port-driven-- how am I going to take that from a VM
and put it into a container?
But I found that it was actually really cleverly done.
What I did was, I built a very special bespoke crystalline VM,
and I installed Postgres from system packages.
I set that all up.
I set up a Django website on there.
I had a whole bunch of user uploads on there.
So it was a very bespoke VM.
And then I ran it through Migrate for Cloud Run.
And that was able to containerize the VM,
identify what services were running.
And then I had the choice to disable all the services
and then re-create them.
Well, not recreate, redefine the services.
There's a particular YAML that you can define--
services-confic.yaml-- where, like you would define a whole
bunch of systemd services, you can define new services.
So I disable all the services that's
running on this containerized VM.
And then I declare a new one, which is just
my web service on a port.
And then when that's running in Cloud Run,
all I do is say, see that port?
Go listen to that.
One thing I did find, though-- that this worked really
well when combining it with the database migration service.
So I could take my locally-running Postgres
database and then migrate that into Cloud SQL.
So I could migrate my VM twice.
But it meant that I was able to go from one very
special VM that if it went away, I'd be very sad,
into managed Cloud SQL and then into a container in Cloud
Run that can scale to zero, survive restarts, all
that kind of fun.
It was actually really neat.
I'm interested in sharing more about that
to some of our customers.
CARTER MORGAN: There's two things
I want to ask about here.
One, first, you defined the mapping
between ports and sockets and whatnot.
But two, you said that you had a VM,
or you wrote a custom bespoke VM,
and then you transitioned it into a more managed service.
Why?
Why would you go up the stack that way?
KATIE MCLAUGHLIN: Well, Carter, what do you
want to have to worry about?
CARTER MORGAN: Me, personally?
Nothing.
I want to write code, and I want to be done with it.
That's what I want to worry about.
KATIE MCLAUGHLIN: For brand-new greenfield projects
or proof-of-concept projects, you
can do that straight away with Cloud Run, where
it's such an abstraction on top of the VM
on top of the Kubernetes on top of everything.
You just need to containerize your code and go run it.
But there are going to be brownfield projects
where you're going to have something that exists.
And if you want to pull it up into a serverless system,
you're going to have to do that migration step.
But with managed services, you don't
have to worry about a number of things.
Like, who were you talking with the other day?
Was it Gabe?
About databases?
BRIAN DORSEY: Yes, it was.
He talked to us about databases, hosted,
how to decide when to host on a VM,
and some database migration stuff.
KATIE MCLAUGHLIN: Yeah, in my bespoke virtual machine,
I would have to worry about maintenance and system package
updates, and backups of my database.
Once I'm in Cloud SQL, that's all there by default.
What do you want to have to worry about?
CARTER MORGAN: OK.
Well, let's get an example.
Let's ground it in reality.
Say one of our two co-hosts on this show
was writing a small back-end application.
No front end.
It just uses APIs, goes from a command-line type deal.
Where would I want to run that?
Or, sorry, where would our co-host, whoever it is,
want to run that?
KATIE MCLAUGHLIN: Well, Carter and/or Brian, it depends.
It sounds like you may not even have to worry about Cloud Run,
because with Cloud Run, you would
have to have a container that listens on a port
and then serves stuff.
But it sounds like if you've just got a function,
you might just want to go straight
to Cloud Functions, where you just
supply a function, a method, a function
description with parameters.
And then it gives you--
it returns data.
And just copy, paste that up into Cloud Functions,
and everything else is handled for you.
CARTER MORGAN: Mm-hmm.
Can I ask a question?
Brian, I see that you've got something on your mind,
so let me sneak this one in.
I'm very used to with, say, Kubernetes, just putting
a web app in a container and running that.
What is the difference between Cloud Run, which
I'm not really familiar with, and something like a Kubernetes
there?
KATIE MCLAUGHLIN: Cloud Run is just managed Kubernetes.
Shh.
CARTER MORGAN: Oh, so then GKE, basically.
KATIE MCLAUGHLIN: Yeah, Cloud Run
runs on top of Knative, which itself
runs on top of GKE, which itself runs on top of VMs, which
itself runs in Google data centers, which itself
runs on servers.
You don't have to worry about so many things
when you move up this abstraction stack.
You're still using the underlying technology,
but you don't have to worry about it.
BRIAN DORSEY: I love what you just
said there-- abstraction stack.
I like to think about it--
you talk about Cloud Run, and we've got App Engine and--
or, sorry.
You were talking about functions,
and we've got App Engine and Cloud Run and Kubernetes
and VMs.
And like you said, if you've got a greenfield thing,
you probably want to start at the top of this abstraction
stack and work your way down.
And if you have something existing that's already
running in a VM or on a computer somewhere,
it's probably going to be easiest to start
towards the bottom.
Nice.
KATIE MCLAUGHLIN: Yeah, it's very nice.
I remember, back in the day, if I
wanted to try to get logs or debug a machine,
I would have to physically go to the data center and wheel
out a little trolley and plug in a keyboard and mouse.
Nowadays, depending on where in the stack I am,
I either SSH directly into the machine,
or I go into Cloud Logging, and everything is already there.
I don't have to physically drive to where my machine is anymore.
I don't have to worry about that.
My life is very much better now I do not
have to physically go and plug in keyboard and mouse
into servers.
CARTER MORGAN: Right.
Yeah, I can relate to this.
Being in the military, I used to work on some very old computer
technology.
I'm glad I don't have to deal with that anymore.
But there's something I wanted to dig into a little bit
deeper here.
Your thought process behind thinking about,
well, what do you want to have to worry about,
and what do you have to manage--
is that based on what resources the application is touching?
For example, if the application is
touching a web port or a WebSocket,
then you might have to use Cloud Run as opposed to a serverless.
KATIE MCLAUGHLIN: It depends.
If you have a system that relies on specific GPUs,
you might have to choose a service
where you can define those.
The Cloud Run container contract is just, tell me
what port on this container I should listen on,
and I will serve that for you.
You can have anything you want inside that container.
I have colleagues that have put Fortran
into that container and COBOL into that container.
As long as it listens on a port, it's fine.
But if you need to start worrying
about not just one container, but multiple containers,
you might want to drop down into GKE
and handle your orchestration at that level.
If you want to have to worry about specific types of CPU
architecture, you might need to drop down into VMs.
But if all you want to do is, when
someone goes to my HTTP URL, they get back a response,
then some of these higher-level abstractions
are going to be the solution for you.
But you don't just have to choose one.
You can mix and match.
CARTER MORGAN: Ooh, Brian.
BRIAN DORSEY: OK, so actually I'm
inspired by Katie's picture-painting here,
and the it depends.
So what if we--
we'll keep with the theme of VMs,
because that's this conversation.
But compare and contrast.
If you were going to use functions versus VM,
when would you use functions instead?
When would you choose a VM?
When would you combine them?
And go through the whole abstraction stack one at a time
and dig into each.
CARTER MORGAN: I am so here for this,
because as soon as you said that,
my first question was, oh, wait.
I can use serverless and VMs together
in the same application?
What?
Is that a thing?
So yes, I want to go, and I want to find out
what tools I can use in place, or begrudgingly with, VMs,
if that's what I need to do.
BRIAN DORSEY: Awesome.
Katie, would you be up for coming back
and dig deeper on some of these?
KATIE MCLAUGHLIN: (CHANTING) Season 3.
Season 3.
I'd love to.
BRIAN DORSEY: Take that as a yes.
CARTER MORGAN: Season 3.
Well, if you're watching at home,
I just want to say, thanks for sticking with us for so long.
Next season, it sounds like we're
going to go on a little bit of an adventure
and explore different use cases for some of these abstractions
on top of VMs and when you might want to use them.
So thank you so much.
Katie, thank you for being here.
Brian, as always, thank you.
Yo.
So if you are at home watching this,
I'm sure there's a couple things that we talked about today
that maybe spurred your thoughts, some questions
that you have about VMs and using them
with some of these different tools and services.
So drop those in the comments.
We'll check those out.
And stick around, because next season,
it's going to get weird.
That's "VM End-to-End."
Thank you.
[MUSIC PLAYING]