[MUSIC PLAYING]
CARTER MORGAN: Welcome to this week's episode
of "VM End to End," where we have a VM skeptic
and a VM enthusiast come together and hash out
all things Cloud VMs.
Brian, thanks for being here.
BRIAN DORSEY: Absolutely.
I think today is networking, right?
CARTER MORGAN: It is networking, because last time,
you left me off feeling really good about VMs.
And I'm like, this can't stand.
We've got to go deeper and figure it out.
So could you tell me, from a big-picture overview, what
is networking like once you're using Google's
infrastructure and all that?
BRIAN DORSEY: Yeah.
And honestly, I think this is one of the main reasons
to consider running a virtual machine in Google
Cloud, because the traffic back and forth to the machine
runs mostly across the network that Google built
to serve traffic for things like Gmail,
and YouTube, and the like.
So I think that's the big reason.
CARTER MORGAN: When you say the network Google built,
that's a very precise set of terminology.
It sounds like someone actually picked up tools and built
hardware for this.
BRIAN DORSEY: Yeah, and ran undersea fiber cable,
and built a whole bunch of things.
So we've got cables we've laid and leased space
on other cables, all to reduce the latency,
because the faster your information
gets to people, the more--
we've just seen research that people bounce off
of pages that are slow.
So you want to be fast--
as fast as you can be.
CARTER MORGAN: OK.
So then what's this like for people that aren't on Google?
Say, what is the network like taking Google Cloud out of it?
What's it like for a piece of traffic?
What happens?
BRIAN DORSEY: Yeah.
So if you've got a machine that's
somewhere in a data center, or actually even on a home network
somewhere, and somebody else connects to it,
it'll jump across a bunch of hops and different routers
and machines on the internet.
And the packet makes its way there and then makes its way
back.
And we've kind of forgotten what an amazing piece of technology
this is, the internet itself.
It can route around problems and get the traffic there.
And it may take a different route,
depending on how busy things are and other stuff.
But it does mean that there is kind
of an unpredictability in the route and the timing
that that takes.
So there's a certain amount of variation that happens there.
So one of the things we do is built out dedicated networking.
And the traffic will come out of a Google machine,
go across Google's network, and then pop out somewhere close
to the end user--
still on the public internet, but fewer
hops between them and the actual service.
And I think that's the key benefit, I guess,
both for Google's services and for yours that run here.
And so I think at a high level that it comes down
to consistency, predictability of that.
And then there's another fun thing
that we'll dig into here of just some
of these networking pieces we offer as a service,
rather than a particular piece of hardware that's doing it.
CARTER MORGAN: I've heard of software
as a service and infrastructure as a service.
I've never heard of networking as a service.
What does this mean, Brian?
BRIAN DORSEY: Yeah.
So the industry term for it is software-defined networking.
And the networks that your VMs see
are an entirely software-defined thing
and running on top of the networking fabric
that runs the data center.
So we've got this extremely high-speed,
well-interconnected physical network.
And we run a software-defined network on top of that.
And that allows things like firewalls and load balancers
to be provided, like again, this slice of a data center,
instead of a slice of a particular computer.
The data center is the firewall and the data center
is the load balancer.
CARTER MORGAN: A firewall is a box that you plug in between--
wait, so what do you mean the firewall is a data center?
BRIAN DORSEY: Yeah.
So instead of a box that you plugin one side of the network
and the other side of the network, the firewall
that you're using for your VMs, and for deciding
what ports are open, and that sort of thing,
there are a set of rules.
And then instead of those rules going
to one box that's in between, the implementation
of the software-defined network itself enforces those rules.
And that's distributed across the whole data center.
CARTER MORGAN: And so instead of having,
oh, my box can't handle more, Google
can handle all of this for you.
So you get firewall at scale--
firewalls at scale.
BRIAN DORSEY: Exactly.
And where that becomes really important
is the load balancer at scale.
And it seems really counterintuitive.
So instead of a particular box that traffic hits
and it spreads it around to a whole bunch
of backend machines, right?
CARTER MORGAN: Right.
BRIAN DORSEY: Again, you're setting rules.
But still, it provides this endpoint.
It provides one IP address that you see and routes the traffic
to all of them.
But there's not just one box doing it.
CARTER MORGAN: I need to know how this works,
because this is what Google--
like Gmail, YouTube uses all this.
BRIAN DORSEY: Exactly.
CARTER MORGAN: How?
BRIAN DORSEY: And in fact, we're configuring those same load
balancers.
And luckily for us, Google published a paper about this.
And the infrastructure is called Maglev.
So let's put a link to that paper down below.
But at a really high level, it allows multiple computers--
an arbitrary number of them, so you can just
keep adding them-- to all implement
the same exact load-balancing rules in sync
so that when you change the rules or one
of your backend machines needs to go offline,
you bring a different one up, all of the load balancing
cluster, essentially, handles that for you.
And there's distributed hashing and a bunch of neat stuff
that makes that possible that's listed in that paper.
CARTER MORGAN: You're giving me homework.
I got to go read about this now.
So this last episode, we touched on networking a little bit
and you brought up Managed Instance Groups,
if I'm correct.
BRIAN DORSEY: Yep.
CARTER MORGAN: This is the technology
that makes that possible.
BRIAN DORSEY: Yeah.
So Managed Instance Groups, I think,
are the next level on top of that.
So once you've got the ability to route traffic
to a whole bunch of different computers,
how do you figure out which computers,
and whether they're working, and that sort of thing?
That's where Managed Instance Groups come into play.
CARTER MORGAN: OK.
And so something I keep hearing just repeatedly,
everyone says global.
Global.
Google has a global network.
I don't necessarily know what that means.
Can you help clarify?
BRIAN DORSEY: Yeah.
And I guess I made the claim that your Managed Instance
Group could have machines that are spread around the globe,
right?
CARTER MORGAN: Right.
BRIAN DORSEY: So at some level, it means exactly that.
So our network-- we've put down fiber,
and we have data centers that are
in lots of different places, and really
fast, as fast as possible.
You still have light speed there.
CARTER MORGAN: There are physics.
BRIAN DORSEY: But as fast as possible interconnect
between them.
And I think the key concepts to take away
as you're planning your system is that we group
things in a hierarchy.
So at the top, you've got global,
an IP address that could be accessed
from anywhere in the world.
And then regional, which might be
something like Europe or North America
or Asia, something like that.
And then zonal.
And conceptually, that's kind of like a data center.
It's at least a interconnected set of hardware--
machines, networking, power, redundancy--
that is all one unit.
And the idea is that, if there is a failure in one zone,
it shouldn't affect another zone.
So you can choose to put things in different zones
and trust that they're unlikely to have the same issue that
affects each other.
CARTER MORGAN: OK.
So then you get data redundancy and backups, all of that,
from zones.
BRIAN DORSEY: Yeah.
So that's how you build reliability into your system
so that you can keep things separate.
And the Managed Instance Group can cross those.
And it's really useful.
And I think one key thing to just keep
in the back of your head is that communication
tends to be faster within a zone and cheaper.
CARTER MORGAN: Things are closer together.
BRIAN DORSEY: And it takes a little extra time
and costs a little more money to cross between zones.
CARTER MORGAN: I think at this point,
we've talked about high-level benefits
of using Cloud's networking.
I can't poke any holes in the argument just now.
It looks like it's very useful for VM users.
But I know that can't be all of the benefits.
So what I'm curious about, what are the other core concepts?
We've talked high level.
Are there any lower level concepts that you're
like, this is really cool?
BRIAN DORSEY: Yeah.
So we've already talked about firewalls, load balancers,
that sort of thing, which implies public IP addresses.
But I think there's a couple of other,
I don't know, just words, like terminology,
that we should talk about a bit.
CARTER MORGAN: What you got?
BRIAN DORSEY: And one of those is VPC networks.
And then the other concept is how
you connect to these networks from other places.
CARTER MORGAN: OK.
I hear virtual private cloud all the time.
I'm confused, because I thought that's what a Google Cloud
network--
BRIAN DORSEY: Cloud is?
CARTER MORGAN: Yeah.
What is Virtual Private Cloud?
BRIAN DORSEY: I think in this context,
it's easiest just to think of it as the collection of services
that provide networking for us.
So a VPC network is a security boundary, if you will.
It's the name of our networking bits.
CARTER MORGAN: So everything.
BRIAN DORSEY: So kind of everything.
But to be more concrete, since that's kind of vague, when
you create a project and you create a VM, by default, there
is a network that is created.
And so we just call that the default network.
And it provides private, nonroutable IP addresses.
So the public internet is all on the main pool of IP addresses.
And there's a couple pools that are never meant to be routed.
So routers will never send them across the public internet.
So we use one of those, the 10-dot series of networks,
as a default and expose that to you.
And all of your VMs, by default, live on that network,
wherever they are.
So whatever zone they're in, they're
all on the same 10-dot network.
CARTER MORGAN: Oh wow.
So I can just address them like they're right next to me
everywhere?
What about-- OK, here's an interesting one.
So if I have a VPC, and you have a VPC, 10.1.1--
is that shared?
Or do we get our own separate one?
BRIAN DORSEY: Yeah.
So that is a nonroutable private address space,
so you can't ever have collisions with other people.
And my 10.1.1.1 will be different than yours.
And the things will never move across that way.
CARTER MORGAN: That simplifies a lot of networking.
BRIAN DORSEY: Yes.
CARTER MORGAN: OK.
I want to be skeptical but that--
OK.
BRIAN DORSEY: OK, so let me add one onto that.
CARTER MORGAN: Yes.
BRIAN DORSEY: Another thing along those lines
is that when you create a VM, you give it a hostname.
And we automatically provide DNS of name lookup
based on those names for all the machines.
So you can just ping another VM by its hostname
wherever it is in the world, in whatever network,
and it just simplifies a lot of things in automation.
CARTER MORGAN: Yeah, OK.
What about if I wanted to bring on my own IP address, so public
IP address?
Because this is all private.
Is there a way to do that?
BRIAN DORSEY: Yes.
Yep.
There sure is.
And so we have both this concept of ephemeral IP addresses.
So if you just make a machine and say,
I want to have a public IP address,
and I don't care what it is, you can do that.
And then most of the time, you actually want
a kind of long-lived address so that maybe you
can give it a DNS entry and make it mywebsite.com,
instead of a series of numbers.
And those can be either attached to a particular VM when
you startup--
and if you just have one computer, that's handy.
But often, you actually attach it to the load balancer.
And the load balancer becomes that long-lived, stable
endpoint, and the machines come and go behind the scenes.
CARTER MORGAN: OK, that's smooth.
So how do I get started with this?
How do I take--
say I have something, an on-prem system.
I want to connect to Google Cloud's network.
How do I do this?
BRIAN DORSEY: Yeah.
So I'll take that in two phases.
So getting started, the networking is there by default.
And then you add the pieces as you need them-- rules, or load
balancers, or what have you.
But this connectivity bit, that's interesting.
So the main one I talked about so far
is via the public internet.
And we try to get off the internet as quick as we can,
but things are routed across there.
And that's using just the normal wide-open protocol.
So you may want to use something that's
encrypted these days, that sort of thing, if you can.
But it's running across the public internet.
Usually, that's not what people want when you think about,
hey, I want to connect my servers to the Cloud.
And so we have a couple of different ways of doing that.
One is setting up a VPN, a Virtual Private Network.
And we have a hosted IPsec VPN termination.
So you can use the IPsec protocol, using
whatever hardware or software you have,
and connect that to the Cloud network.
And then your machine's on one end
and your Cloud machines can just talk to each other,
as if they're on the same network.
CARTER MORGAN: And then you said that was two of the main ones.
There's another?
BRIAN DORSEY: And then there's another.
So that's still running across the public internet,
but encrypted.
So it's safe, but occasionally, you
have a use case where you need to get the latency down
as low as you possibly can.
And there's nothing that really beats co-location.
You put the machines in the same places, right?
So we have something called Cloud Interconnect that allows
you to get rackspace in--
CARTER MORGAN: Inside a warehouse?
BRIAN DORSEY: --a hosting provider.
Well, inside a hosting provider that we
have a connection with or with partners who do the same.
And so you get right there, where
the network's terminated, and never leave their private data
centers.
CARTER MORGAN: All right, Brian.
I got to be honest.
It's getting hard to be skeptical at this point.
You're doing a good job.
It sounds cool.
I guess I have-- if I had to ask one last question,
it's going to sound like a gotcha,
but I don't mean it to be.
What are the advantages or why would someone
want to work at this level, the infrastructure level,
over working at, say, the Kubernetes level?
Where I could still work with the Cloud load balancer,
but a lot of choices have been made.
I don't have to deal with all the nitty-gritty.
BRIAN DORSEY: Yeah.
And there's some real big advantages
to having a curated experience.
Kubernetes sets a bunch of stuff up.
It handles authentication even between the connections
and gives you these nice abstractions.
And so you get this endpoint you can connect to.
So if you're already running a cluster,
I think you should keep doing that.
That said, there's a lot of apps that
just don't run in Kubernetes, maybe yet or maybe ever.
And sometimes, you want to use a lot of these same patterns.
And I think this static endpoint of a load balancer in front of,
even if it's just one machine, is actually
a very useful pattern.
And so I think it's worth keeping that in mind.
There's a few additional options.
I don't think those are super key.
But I think this compatibility with other things that
are going on-- if you've got a bunch of services
in Kubernetes, and you want to add a few more that are not
in Kubernetes, it's really useful to be able to do that.
And then I think what we talked about earlier, where
sometimes you have a system that just doesn't have
as many moving parts and you don't necessarily
want to setup a whole cluster to do that, it's a really nice way
to get similar patterns with way less complexity.
CARTER MORGAN: That makes a lot of sense.
And I like what you said about Kubernetes
as a curated approach to Cloud.
You don't always want or need that curation.
And so it sounds like working at this level,
you get a lot of great power--
great power.
You get power.
You get flexibility.
And that comes with responsibility.
So if you're a strength trainer or a Yogi,
know that you have responsibilities.
BRIAN DORSEY: Actually, exactly that.
And I want to just riff on that for a moment.
I think that concept you described
there is true across the VMs.
So you get a little more control and you
have to do a little more, or you can kind of
work up the layers, if that's the right fit for you.
CARTER MORGAN: Right.
This is why I like talking with you, Brian.
We riff, and it makes me very happy.
Thinking of these riffs in the future
and why I think we should do this again,
you said you want to talk about security in the future.
So let's definitely do that.
What else do we need to talk about?
BRIAN DORSEY: Yeah.
I think the next thing I want to talk about,
just because I'm so excited about them, is the disks.
I want to go into more detail about how they work
and what extra capabilities they give you
that you might not be thinking of.
CARTER MORGAN: You really love disks.
BRIAN DORSEY: I do.
CARTER MORGAN: You know what?
All right.
Next episode, why don't we talk about disks?
BRIAN DORSEY: Let's do it.
CARTER MORGAN: All right.
Well, y'all, thank you all for listening and checking this
out.
Brian, you're slowly but surely convincing me.
I'm not happy to admit it, but here we are.
Thank you again for coming in and talking.
BRIAN DORSEY: Thank you much.
See you all next episode.
[MUSIC PLAYING]