ZACH SEILS: Welcome, everyone.
Good afternoon.
Thanks for joining
our session today.
This session is cloud networking
for the hybrid enterprise.
My name is Zach Seils.
I'm here with my
colleague Matt Nowina.
Matt and I are both
networking specialists
in the customer
engineering organization
within Google Cloud.
So we work on a daily basis
with customers such as yourself
to help kind of onboard
them, understand networking
within Google Cloud how
to best take advantage
of our networking features, and
more specific to this session,
how to best integrate with your
existing on premise networking
environments.
We do have the Dory Q&A
enabled for this session.
So if you have the Next app,
you can click on Dory Q&A
and pop questions into the app.
We want to make sure we have
enough time for all the content
in the presentation.
So we're not going
to do live Q&A today.
But the Dory is open through
the end of the month, so
through April 25.
So if you have questions
during the session,
if you have questions after the
session when you get back home,
pop them into the app.
Matt and I look forward to
interfacing with you online,
and we may even blog about
a few of the questions.
We'll see what happens.
So a quick summary of
what we're going to cover
in the next 50 or so minutes.
I'm going to start
out by talking
about familiar networking
concepts that everyone
is familiar with from
your on-premise networking
environment, and how those
map into the Google Cloud.
So if you have kind of direct
correlation between things,
I'll make the
connections for you.
And I'll really highlight
how some of those things
are different in the
cloud versus what
you may be familiar
with in terms
of your on-premise network.
Next I'm going to
hand it over to Matt.
Matt is going to talk about
some common enterprise
designs and some recommendations
for how you can approach those,
talking in a little bit more
detail about the features
that I've talked about, how
you actually leverage those
based on our recommendations.
And then finally, we're
going to come back together
and we're going to talk
about some best practices.
So what we typically
recommend to customers
as they start their journey
towards Google Cloud.
All right, so let's
jump right in.
Again, I'm going to start with
kind of some common networking
concepts, and I'll
map those into what
their equivalents are inside of
the Google Cloud environment.
This is the current state
of Google's global backbone
network.
So we have our own
private backbone network.
It's one of the largest private
backbone networks in the world.
One of the unique benefits
of cloud networking
is that within a few minutes,
through configuration
that you define, this basically
becomes your infrastructure.
So you can extend your
on-premise network environment
literally across the
globe based on which
cloud regions you deploy compute
and other workloads into.
And that's really the premise
of this presentation, which
is how do you extend your
on-premise networking
environment with things
that you're familiar with,
but do so in a way that's
scalable, manageable,
and hopefully with as little
design and operational burden
as possible.
So again, essentially, this is
basically your backbone network
completely under your control.
Let's start with some very
familiar kind of constructs.
Though your on-premise data
center environment undoubtedly
is made up of physical
network devices.
These devices are
commonly purpose specific.
So whether we're talking about
a core switch, or an access
switch, or maybe a
firewall, whether it's
physical or virtual, these
devices in your network
are often put together in
a very specific topology
based on those capabilities.
And where those
devices are placed
and how you connect them
is very relevant to how
the network performs and
what capabilities it has.
Now data center topologies
have evolved over time.
You had your traditional three
tier kind of core distribution
and access networks.
And you had this
resurgence recently.
You have cost-based fabrics
where you have spine and leaf
networks.
But generally speaking in your
on-premise network, topology,
at least the physical topology,
is generally fairly static.
So it doesn't change that much.
So we have the concept
here of the device.
We have the concept of placement
being very relevant, important
in terms of what those
capabilities are,
and how they apply to the
things that you're actually
connecting to the network.
Next, we have
different capabilities
for how you virtualize that
physical infrastructure.
So for example, you have
virtual LANs, or VLANs,
that allow you to provide
virtual segmentation
within your physical topology.
You can even have isolation from
an IP forwarding perspective.
So for example, you can
have VRFs, Virtual Routing
and Forwarding instances,
and historically there's
been some providers
specific implementations
of these capabilities.
So for example, maybe Virtual
Data Centers, or VDCs,
and various different types
of overlay and underlay
technologies.
The premise here
is really the same.
How do I basically
virtualize and isolate
different capabilities on
top of the same physical
infrastructure?
So here, again, we have the
virtualization concepts--
VLANs, IP forwarding domains,
like VRFs, and sometimes
Virtual Data Centers, or VDCs.
Moving on, we have what I refer
to as kind of network identity.
So when you talk about how you
identify systems, particularly
from a network perspective,
it's no surprise
we start talking about IP
addressing and subnets,
and these kind of exist
pervasively everywhere.
They're in the public
internet, they're
in your private network, they
obviously exist in the cloud.
But what I'm specifically
talking about in this context
is the importance of what
an IP address actually means
about the identity of a system.
Like, I know these
range of IP addresses
are my database servers, or
these range of IP addresses
are the DMZ where I
want to kind of apply
a certain type of
traffic controls.
And placement is also
important here, right?
Oftentimes where something
connects to the network
says a lot about what it is and
implies what types of access
it has or it will allow.
And much like there's
a low rate of change
with physical networks, there's
typically a pretty low rate
of change with the number
of subnets and VLANs and IP
addressing schemes
that you configure
in your on-premise network.
I mean, certainly they
change and expand over time,
but they're generally
not changing
at a high rate of volume
on a daily or weekly basis.
Now, if we've gotten this far
and your thinking, great, Zach,
IP addresses and subnets.
I'm super happy I
came to your session.
Just be patient please.
I promise we're
actually going to help
you think about these constructs
in a different way in the cloud
that hopefully makes your
cloud journey a little bit more
simple from a
networking perspective.
Next, we have various different
types of traffic controls
from a data center perspective.
So you have firewalls.
These again can be physical
or virtual devices.
You have network-based
access control lists.
You may apply these at
various points in the network.
So these are more like
very network-centric.
You create these based on IP
addresses, subnets, interfaces,
et cetera.
Sometimes you have
host-based filtering
through agents or other
things you actually
install on the endpoints.
And finally, more recently,
you have kind of I
think an emergence of what I
call drop by default fabrics
or networks, where
multiple hosts are
connected to the same network.
And whereas they may
have historically
been able to automatically
talk to each other
if they could discover
each other, that's
no longer the case.
These networks or
fabrics actually
drop most unicast
traffic by default,
which requires that
you must explicitly
configure what communication
is allowed across that network.
So I've got here a set of
controls for how I actually
identify and filter traffic.
So that's where we kind
of came from, right?
We have the devices.
We have the importance of
placement of those devices
based on their functionality.
We have the network-based
virtualization technologies.
We talked about VLANs.
We talked about VRFs.
We talked about access
control capabilities.
And so, now it's start to map
these into their equivalents
inside of Google Cloud.
So the first one is
really the device.
What does a device mean?
What is the equivalent of
your on-premise network
switch in the Google
Cloud environment?
And there really isn't one.
So this is funny, for the
first one there's really
not a direct equivalent.
And this is really a
byproduct of the fact
that most everything inside of
the Google Cloud environment
is heavily software-driven
and globally distributed.
So there's really no call into
I have this network switching
device, what is its
equivalent in the cloud.
It just doesn't exist.
Now that being
said, we do actually
surface some
capabilities as devices.
This is primarily from a
configuration and management
perspective.
So for example, when
you're setting up
routing between your network
and the Google Cloud network,
you configure that routing using
something called Cloud Router.
Now Cloud Router is presented
to you as a thing you configure,
but it's not actually a device.
Behind the scenes it's
actually a distributed set
of software processes that
live within a particular cloud
region.
So you're not actually
configuring a device.
You're basically
providing a configuration
that we then program these
software processes with
and distribute them
across the infrastructure.
In a similar fashion, you
have the VPC firewall,
the native firewall built
into the virtual private cloud
in Google Cloud.
We present this to you from
a configuration perspective
as a single global
list of rules.
So it's very simple
to configure,
you can kind of see everything
in one list or one page.
But in reality,
what we're doing is
we're taking those rules
that you configure,
and we're actually pushing
them down and programming them
at the host level on
the individual machines
where your virtual
machines are scheduled.
So really no equivalent
from a device perspective,
but we do kind of
manifest that in a way
that's convenient for you
for both configuration
and management.
Next is mapping for network.
So we have our
physical network, we
have virtual networks in
our on-premise environment.
What's the equivalent
in Google Cloud?
And this is the VPC,
Virtual Private Cloud.
This is our global
VPC, and it's really
kind of a direct correlation
with your IP forwarding domain
on-prem.
A lot of customers have
just a single IP forwarding
domain, which is you have one
routing space, one IP space,
and there's a lot of
similarities between that
and the VPC in the cloud.
So for example, the IP
addressing inside of a VPC
and inside one of your
forwarding domains on-prem
has to be unique.
You generally avoid
duplicate IP addressing.
Likewise, you don't generally
automatically connect
to networks together without
some explicit configuration.
So in your on-prem
environment, you
may establish connections
between networks.
You may establish BGP routing
protocols between networks
to actually explicitly
make communication happen.
Very similar in the
VPC environment--
VPCs are isolated
in that they do not
communicate with other
VPCs inside the cloud
unless you do something
explicitly to make that happen.
One interesting
thing about the VPC
is it's a global
construct in Google Cloud.
And what that means is
that the scope of the VPC,
how big of a geographic
area it actually covers,
is completely dependent
on how you deploy
workloads in the cloud.
So for example, if you start
out by deploying your workloads
in one cloud region, that's
really the scope of your VPC.
But as soon as you start
deploying workloads
in other cloud regions
across the globe,
the network's scope
immediately expands
to include that entire network.
And so this is actually
pretty unique to Google Cloud,
and it's actually a really,
really nice implementation
because it allows you to
basically instantly grow
your network in global
scope, kind of going back
to that global backbone
slide that I presented
at the beginning, with a single
routing and firewall policy.
So your network, your
VRFs on-prem, they
map into VPCs in the
cloud environment.
Next, we have the
concept of VLANs.
So we only use VLANs in a very
limited fashion in the cloud.
We don't use them actually
within the data center
switching fabric, meaning you
don't put your virtual machines
inside of a specific VLAN.
We only use VLANs to actually
virtualize the connectivity
back to your
on-premise environment.
This is specifically
with a product
we have called Cloud
Interconnect that
allows you to have
high speed, low latency
access from your network
to Google's network.
But you can actually create
multiple virtual links
across those physical
circuits and terminate
those in different VPCs
in different locations
across the world.
That's it.
There's no VLANs anywhere
else in our environment.
There's no VLAN numbering.
You need to think
about making sure
that you put access lists or map
interfaces to a certain VLAN.
That just doesn't exist in
the cloud environment today.
Next, we have subnets.
So show of hands,
who in the room
remembers deploying
workloads in Google
Cloud before we had
VPCs and subnets?
Anyone?
A few people.
So it's true.
It used to be one
big flat IP space
across that entire global
backbone I mentioned.
But as customers
started connecting
to our environment in more
different geographic locations,
we needed the ability
to provide them
with optimized access
from a routing perspective
to the closest
cloud region where
they're deploying workloads.
And that's really the
purpose of the subnet inside
of Google Cloud.
I would advise you
to think about it
as less of an
isolation mechanism,
less of a segmentation
mechanism,
and more of an identity
regionally for instances
that you deploy in
certain cloud regions.
So for example, you
can deploy resources
in a cloud region
on a single subnet
so long as that
subnet is big enough
from an IP addressing
perspective to handle
all of your workloads.
So all of your
Kubernetes clusters,
all of your virtual
machines, et cetera.
That's really the
genesis, that's
the primary purpose of subnets.
That are really not intended to
be kind of a first-class entity
to identify systems.
It's about efficient routing
between your environment
and our environment.
So your subnets, they map
into subnets in Google Cloud,
but the purpose of
Google Cloud subnets
is really about regional
identity or regional proximity
of resources.
Then we have IP addresses.
So our IP addresses
within your VPC,
they're original constructs.
So you create a subnet
within a particular region,
and it has a unique set of
IP addresses for that region.
We also have public
IP addresses that
are used for our global
load balancers that
are internet-facing.
For the regional
IP addresses, these
are by default automatically
managed by the cloud.
So we automatically allocate
IP addresses to machines,
we automatically
allocate IP addresses
to Kubernetes pods, et cetera.
So I want to actually
ask you to do something.
As you kind of go
through this session,
I want you to think about what
if you don't have the ability
to explicitly define the
IP address for a given
virtual machine?
This is already very
common in Kubernetes.
You can't specify that
a Kubernetes pod has
an explicit static IP address.
Assume you can't do that
with a virtual machine.
How are you going to
handle forwarding?
How are you going to
handle access control,
micro segmentation?
We're going to talk about some
of these things a little bit
later.
And finally, the equivalent
for the firewalls
in your environment or in
general access control,
we have a number of products.
These are, again,
globally distributed,
and they really kind of
span layer three controls,
so building access controls
based on IP addressing,
all the way up to
layer seven controls.
So does this user, who's
part of this group,
have the right access
to actually interface
with this cloud API?
So there's a complete
spectrum of access controls
that cover a lot
of different parts
of the stack from the
network all the way up
to the application level.
So again, this is
important when we
start talking about
segmentation and the ability
to kind of abstract how
we identify and control
a system, separate from
where it's actually
placed in the network.
And so with that, I'm
going to turn it over
to Matt, who's going to talk
about some common enterprise
design scenarios and how
we can approach those.
MATT NOWINA: Thank
you very much, Zach.
I don't know how many of
you are public presenters,
but this is normally
the part where
you get stuck looking
into the lights
and forget everything
that you've prepared.
But what we really want to
talk about at this next stage
is how do we start mapping
these analogs into Google Cloud
solutions specifically.
So here you get a
snapshot of what
the Google Cloud
networking product
portfolio looks like today.
There's 20+ products
and services all focused
on enabling your
journey to the cloud.
We've grouped these into
different sections that
represent the way that
customers are thinking
about the cloud-- so connecting,
scale, optimize, security,
and modernize.
And so, what we're going
to do in this next section
is we're going to touch through
a series of these products
and sort of answer questions
that customers come to us with.
So in this section, what
we're going to focus on
are the Cloud
Interconnect VPN and VPCs.
So one of the first
things that customers
think about when
they're coming to us
is how do I take advantage
of this new network.
Oftentimes when you have
on-premise environments,
you have fixed infrastructure
and fixed locations,
but you don't have the way a
way to extend your applications
to where your customers are,
improve the speed and latency.
And so, that's where, as
Zach was mentioning before,
global CPC comes into play.
This is a way of
simplifying the ability
to connect to all of the
regions where you deploy things,
makes it simple for you
to enable replication
across your applications,
as well as leveraging
Google-managed services that
are built from the ground
up on a multi-region deployment
model and the associated
availability.
The next thing, once we've
started to map out the network,
we start to think about,
well, how do we fit this
into our operational model.
So by show of hands,
how many of you
no longer have dedicated
networking or security teams?
So there's a few.
And we know the
industry is moving
towards DevOps models
or DevSecOps models,
but until we fully
move into that,
we have to think
about how can we
take our workflows in our
on-premise environment today
and map those over to the cloud.
This is where shared
VPC comes into play.
So shared VPC is
designed around the idea
that we have different teams
that deploy our applications
and different teams that
manage our networks.
And we don't just want to give
free rein to the application
teams to deploy networks
as they see fit.
We still want to have
some level of control.
So shared VPC is
enterprise friendly.
It's a centralized
model, and it allows
you to centralize
your administration
and auditability.
So now we've got a global VPC.
We have a deployment
model that works.
As Zach mentioned before,
we want to look at--
I mean, we're a
hybrid enterprise.
How are we going to
interconnect into GCP?
And it's important to note
that you need different models
depending upon what
you're going to rely
on that hybrid connectivity for.
Are you just doing management?
Do you need to do batch data
loads at certain times of day?
Or, is this going to become
a mission critical part
of the application?
This is where things like
Cloud VPN, Cloud Interconnect
come into play, and being
able to map your requirements
and your costs to the
exact implementation.
So what does it look
like when we start
to put these things together?
This is an example--
a zoomed in, simplified
example here-- but starting
on the left-hand side, you
can see an on-premises network
with four dedicated connections
coming into Google Cloud.
These are coming into
two separate regions
that are both accessible
through the global VPC.
That VPC is stored within
a shared VPC host project,
and we can share
individual subnets out
to the service projects.
So again, it's a
relatively simple way
of leveraging
physical connectivity,
ensuring a four nines
SLA, and giving you
centralized administration.
So from here, one of the
other common questions
that we get, and I was sort
of confused when I first
heard this, but there's
some customers who
are surprised to hear that our
managed services are typically
hosted on the internet,
on external IPs.
Now Zach and I would probably
be among the first to argue
that simply putting
something on a public IP
really is about accessibility
and not security.
But for customers
that have invested
in these interconnects,
that want
to leverage this private
connectivity for accessing
the managed services,
it makes sense
to have an option to do so.
And so, that's where we start to
introduce private Google access
and private service access.
So what these are are ways
of extending those managed
services to your
on-prem environment.
I'll pause as people
take pictures.
But what it really
looks like is this.
So that same interconnect
model that you had before,
what you're now
able to do is to--
as a part of your dynamic
peering with Google,
you're able to advertise
a restricted VIP back
to your on-premises environment.
So this is a special IP range
that will come from your VPC
to your on-premises environment.
And then through
the use of DNS you
can swing services over
to that restricted VIP.
The three basic models
for four using this are--
the first is to do an
enterprise-wide scening
of start at GoogleAPIs.com
to the restricted VIP.
If you don't want this to
apply to all of your services,
what you may choose to do
is implemented DNS view.
So a view only for
certain clients
implementing the exact
same redirection,
or you can even implement
it as a host based level.
So we've talked
about connectivity.
Now I want to spend just
a few minutes on security,
and more specifically
on our Cloud Armor IP,
VPC firewall rules, and
cloud firewall rules.
So no one is going to consider
leveraging a cloud service
provider if they don't
have complete faith
in the implementation
of firewalling.
GCP VPC firewalls provide
a micro segmentation model,
because they are
effectively implemented
at the host-based level.
What that means is two instances
running on the same physical
host cannot connect to one
another without traversing that
firewall.
And the default stance of that
firewall is a deny ingress.
At the same time, these
rules are stateful.
So they're simpler to maintain
then more traditional stateless
ACLs.
And we can see the
segmentation model implemented
in the following slide.
So again, this is a
relatively simplified model
here, but when I started
thinking about this--
I have a question.
How many people have
had to implement 802.1x
in an on-premise environment.
So there's a few people.
This was port-based
network access control.
So this was introduced at a
time when we no longer knew
what endpoint was going
to plug into what switch,
so where in the network
they might be, and be
able to dynamically configure
that port with the associated
rules for that endpoint.
Well, the same thing can be
done with CPC firewall rules.
Through the use of tags
or service accounts,
you can have your
endpoints inherit the rules
that they need in order to
access the correct endpoints.
And you can do this
very similar to 802.1x,
but without the pain of
having to manage TACACS.
So with this combination
we have granular rules
that are applied
dynamically within our VPC,
and then as we start to
push out towards the edge,
we have Cloud Armor and
Identity Aware Proxy.
Cloud Armor will extend our
defense in depth strategy
by adding layer seven DDOS and
web application firewalling
to our apps.
And IAP provides a way of
extending our applications
to only specific users.
In fact, we also
introduced quite recently
a blog post that
talks about using
IAP in place of bastion hosts.
So now you can open up 22
to your individual hosts
that you want to manage,
but ensure that's only
exposed through to
certain identities
without the need of having
a separate management host.
Then the next part, and this
is a really critical one
because we've all heard
repeatedly these stories
about misconfigurations
of access rules
on a managed service
that end up exposing data
to unauthorized clients.
So how do we address this?
Well, Google's actually taken
a two-pronged approach to this.
The first is a set of open
source security tools called
Forseti, which give you the
ability to establish inventory
policies and remediation
actions whenever changes are
made within your environment.
And the second is
VPC Service Controls,
which allows you to establish
a trusted perimeter model
around your VPCs and projects.
So this is what it
looks like in practice.
So here we have a project in
the VPC, and the associated
services that we
want to protect.
We also, through
the same mechanism
of that private Google
access, have the ability
to extend these services to
our on-premises environment
and say, that's a part
of our trusted perimeter.
So when VPC Service
Controls is enabled,
only resources from
within the perimeter
can interact with
those services,
and they can't be
used to copy those
to any external
unauthorized projects
and prevent access
from the internet.
So this protects against
that misconfiguration.
Lastly, all of these
security controls are great,
but centralized logging and SIM
solutions are not going away.
So this is where VPC
flow logs and firewall
logs come into play.
The VPC flow logs provide
you with NetFlow style data,
TCP dumped information
without the payload
that gives you information
about the flows within your VPC
environment.
And firewall logs
gives you insight
into what's being allowed and
blocked by your VPC firewalls.
So now that you have a sense
of the various products,
the analogs to the on-prem,
what the options are
in GCP, what we
want to do is try
something a little different.
As network
specialists, Zach and I
get the chance to see
many different customer
configurations.
And then this next section,
we wanted to try and verbalize
the thought process
that we go through when
considering different sets
of customer requirements.
Before we start
that, I just wanted
to give you a few quick
points in terms of VPC design
pre-work and recommendations.
So the first is identifying
who your stakeholders are.
This can vary depending
upon who you're
trying to design this VPC for.
Is it for an individual
application, a line
of business, your
entire organization?
It's important to
understand who you're
trying to address, and
make sure that you really
understand their requirements.
The second is to start with
security objectives and not
security controls.
Many times we see
customers come to GCP
and say, how do I do X in GCP,
rather than thinking about why
they're doing X. So by starting
with the security objectives,
you have a very
clear understanding
of what you're trying
to achieve and what
your options are in the cloud.
The next is understanding how
many VPCs you're going to need.
And I don't mean coming
up with a static number,
like 5, 6, 7, 10.
The important thing
here is to understand
what you're trying to achieve,
where your scale and quota
limits are going
to play, and get
an overall understanding
of what magnitude you're
going to have to address.
And lastly, think simple.
Don't design things
just because you can.
I mean, we all know that
simplicity is directly
correlated with supportability.
So keeping it to
exactly what you need
is going to be important.
Anything you want to
add on this slide?
ZACH SEILS: I think the point
of number three is relevant.
It's not a static number
you're trying to get.
It's really a
pattern that you're
trying to use so that you can
grow and scale your network
environment inside
the cloud in the most
efficient manner possible.
MATT NOWINA: So let's start
with a simple scenario here.
Zach, what do you see in
this initial scenario?
ZACH SEILS: Sure.
So again, the idea here
is this is basically
our day job, right?
So how do we kind of think
about approaching this out loud?
So obviously here I've
got a single VPC, global,
pretty straightforward.
Looks like I have both
development and production
workloads in the same VPC.
They're across
different regions,
so they're in different subnets.
Single project, which
is also relevant when
we look at how we scale out.
And the other thing
that's apparent
here is it looks to me
like this is predominantly
a cloud isolated workload.
I don't see any hybrid
connectivity back
to the on-premises environment.
So those are kind of the things
that initially pop out at me.
MATT NOWINA: Any
best practices you
think we can take
away from this design?
ZACH SEILS: Yeah.
I mean, I think a couple here
that really resonate with me,
something you just mentioned,
which is start out simple.
So I think this is a
very common approach
that customers who are
either new to cloud
can take just so they kind of
get their bearings in the cloud
environment.
Or, even customers that
are coming from other cloud
providers, and
they're just trying
to get familiar
and have experience
with how some of our networking
constructs may differ.
So for example, the global
VPC, how does it actually
behave in practice?
So simplicity is a key one here.
I think the other one
here, too, is just
the small number of subnets
with larger address ranges.
There's no really reason to
kind of over-rotate and start
creating a bunch of
subnets within a region.
You can start with one with
adequate IP address space.
We have a great feature
where you can actually
grow the size of
your existing subnets
in a completely hitless manner
to the VMs that are already
deployed.
This doesn't preclude you from
creating multiple subnets.
This is just what we see and
what we recommend for customers
who are just getting started.
One nice thing
here is that things
are relatively programmatic
and easy to deploy and manage
inside of Google Cloud.
So even for core
infrastructure, stuff
that takes a lot of
planning and a lot of effort
to implement in an
on-premises environment,
they can actually be pretty
disposable and pretty easy
to kind of delete
and recreate inside
of the cloud environment.
So I think overall a
good starting point.
One thing I do
notice here, though,
and I think a pretty common
recommendation as customers
start to scale in
the cloud, is really
kind of starting to segregate or
put more kind of firm isolation
between development and
production workloads.
MATT NOWINA: So you
mean something that
looks a little more like this?
So in this design,
there is a couple
of things that jump
out to me right away.
I mean, the first is
exactly what you've
sort of identified there.
We've moved from a subnet
model as an isolation
boundary between our
different environments,
and into VPC level.
So at VPC level, we've now
segregated firewall rule
management into
two separate VPCs.
And then the other
big one that jumps out
is the hybrid connectivity.
So here we can
see that we've now
deployed cloud routers,
dedicated interconnect,
and VLAN attachments into
each of the individual VPCs.
ZACH SEILS: Yeah.
I mean, just a point kind of
on the hybrid connectivity.
If you notice here, we have
actually separate connectivity
coming from on-premises
into each VPC.
And this has virtual
connectivity.
So if you're using
VPN, for example,
these are separate VPN tunnels.
If you're using
interconnect, this
can be the same physical circuit
that you pair Google's network
on, but different logical
connections, those interconnect
attachments I
mentioned previously
that terminate in the
separate projects.
You kind of extend the isolation
of the different environments
all the way through
the connectivity back
to your on-premises environment.
So it's really a clean kind of
separation which works well.
MATT NOWINA: And as you've
mentioned in previous slides,
because we now have
separate independent VPCs
and there is no inherent
connectivity between them,
we need to start thinking
about how does our application
deployment look, where
are our build servers,
where are we actually
deploying from.
If we're deploying from
on-premises, this works.
We've got connectivity
between them.
But if the build servers are
sitting in one of those VPCs,
we now have to
start to look at VPC
peering or connecting
those VPCs together
in order to allow for that build
process or that deploy process
to succeed.
And when we start to think
about those peering, that's
what we need to
start thinking about,
well, what are the aggregate
resource requirements
when we mesh these
two VPCs together.
So when you think about
this design, what's
the next logical extension?
Where do people go from here?
Especially if we
wanted to sort of align
with that workflow
framework from earlier.
ZACH SEILS: Yeah.
So one thing I noticed
when Matt asked
who doesn't have network
or security teams anymore,
there was like a few hands.
And so, if I assume the inverse,
I assume that most of you
still do.
And so, one thing that we see
if we go to the next slide
is this concept of shared
VPC that Matt talked about.
And so, to me,
shared VPC is as much
an organizational construct
as it is a set of technologies
that you leverage in the cloud.
And what I mean by
that is that shared VPC
is designed for
organizations where
you want to maintain
centralized administration
and control of the network
and the security functions
in the cloud.
And so, shared VPC does that.
Shared VPC is still
fundamentally a single VPC,
but it's a single
VPC that can be
leveraged by multiple
projects, and it
has a curated set of
permissions, IEM permissions.
So there is a specific role for
network admins in the shared
VPC, and they control,
as you might imagine,
creating subnets, establishing
hybrid connectivity,
establishing routing policies.
There is an explicit
role for security admins
in the shared VPC
model, who control
firewall rules, et cetera.
So if your organization
is structured in that way,
and that's an
organizational construct
you intend to carry
over into the cloud,
the shared VPC is a really
nice model for this.
So here you can see we've got a
couple of things in play here.
We've got actually
multiple different VPCs all
still within a single project.
And then the shared VPC model,
we call this a host project.
So your host project has all
of your networking and security
stuff--
the VPC, the firewall
rules, the connectivity back
to your on-premises
environments.
And then you have one or
more service projects.
Service projects are
separate projects
that are usually given to the
application or development
teams.
In those separate projects, they
can spin up their own compute,
they can spin up their
own Kubernetes clusters,
they have the autonomy to manage
their workloads themselves.
And these service projects
attach to the shared VPC
to leverage those resources.
So the networking and security
teams maintain control
over the network and security,
the application teams,
they manage their workloads,
they manage compute,
they manage Kubernetes
clusters, et cetera.
So I mean, in terms
of best practices,
just thinking kind of thinking
about this a little bit--
number one is I like simplicity.
So we've got a
pretty simple model.
It's still the single VPC
kind of model, if you will,
which again kind of just
reinforces the point
that we want to
kind start to think
about non-networking constructs
as the primary identifier
for workload.
So we don't want just
the fact that you
happen to be connected to
a VPC to say everything
about what you can do.
There's a better way to
address that, which we're going
to talk about in a little bit.
Another nice thing
about shared VPC
is you actually have
pretty granular control
on which portions of the VPC
are visible to the service
projects.
So for example, you can say
this particular group of service
projects for service
XYZ, they can only
see this particular subnet
or set of subnets in the VPC.
So you can kind
of help people not
make mistakes in terms of
deploying their workloads
in the wrong location.
So this works really well.
It's actually a
very common thing.
It's pretty popular with
enterprise customers,
mostly, as I
mentioned, because of
that organizational alignment.
But a question, I guess,
back for you is what if you
need to kind of scale this out?
Because fundamentally we're
dealing with a single VPC,
what if things go
really well and you
need to kind of scale up
to maybe tens of thousands
of virtual machine instances?
MATT NOWINA: Yeah, so
I think that's when
we start to see a move towards
this model, where now we
are separating out
the host projects
and going with a single
VPC per host project.
This allows us to
more accurately align
VPC and project quotas to
an individual host project,
and allow them to scale
independently of one another.
So no longer are you
going to be worried
about if a dev resource
spins up things
that your project relies
upon, because now they're
managed independently.
The other big thing that this
design starts to introduce
is segregation at the IEM level.
So in the previous models when
you're using the security admin
role, within that
host project you
would have had the ability
to modify firewall rules
across any of the VPCs.
In this model they're now
independent of one another.
So we can have different users
mapped to each of those host
projects, and we're starting to
see a scale out pattern here.
What we're talking about is
building that host project
segregation at the
environment level.
So prod, test, dev.
But we could continue to
make this more granular
if our application
requirements demand it,
where we can create host
projects on individual line
of business or application.
ZACH SEILS: So
just so I'm clear,
I just want to make sure I
understood one thing you said.
So the segregation of
the IEM permissions,
that's because the
permissions are associated
at the project level?
MATT NOWINA: Correct.
ZACH SEILS: OK.
So by moving into
separate projects here,
you're giving your ability to
kind of delegate administration
to different parts of
the cloud environment.
MATT NOWINA: That's right.
As we continue to move out
in this scale model, what
you can see is now
we are increasing
the number of cloud
routers, increasing
the number of VLAN attachments.
And while it's a software
defined network on the Google
Cloud side, on the
on-premises side
we need to think about
how we're going to be
managing those connections.
So what if it's a pain
on the on-premises side?
What can we do to help
optimize for that?
ZACH SEILS: Yeah,
it's a great question.
It's a frequent feedback
we hear from customers.
It's like, it's great.
The network in the cloud
is software defined.
I can spin things up and delete
things with relative ease.
But when it starts to talk
about hybrid interconnectivity
with your on-premises
environment,
that may not always
be the case right so
getting the
appropriate permissions
to change configuration add
additional interfaces create
new BGP peers.
Sometimes customers
want to avoid this.
And what they're
really after basically
is trying to leverage not only
the same physical connectivity
with the Google Cloud network,
but the same logical or virtual
connections with the
Google Cloud network.
And so, we move on to
a different scenario
here, which the actual
VPC structure here, which
dev test and prod in
multiple projects, that
really stays the same.
The one big difference
here is we've actually
leveraged another VPC
that we're terming here
in this presentation
a connectivity VPC.
Now, this is not a separate
type of VPC that you check a box
and say, I want this
to be connectivity.
This just happens to be
a normal VPC that we're
using in a very specific way.
So what we've
actually done here is
we're actually moving all of
the hybrid connectivity out
of the individual
environment-based projects,
and we're putting that
into this connectivity VPC.
And then we peer
the connectivity VPC
with all of those
environment-based projects.
So this actually
relies on a feature
that we've just
recently released
called VPC peering custom routes
that allows us to propagate
routes that are
learned dynamically
from your on-premises
environment across VPC
peering relationships.
So the routes that you
advertise into the Google Cloud
environment that
specify what networks
in your on-prem
environment are going
to be reachable
from the cloud, we
can now propagate those
routes all the way down
to these environment-based VPCs.
So a pretty powerful
capability, nice way
to not only leverage the
same physical connectivity,
but to really remove a lot of
the kind of hybrid connectivity
constructs out of
those environment VPCs.
Another common thing
I see as customers
grow, a lot of customers,
especially larger enterprises,
they may have multiple business
units or business entities
inside the organization.
And those entities pretty much
want to operate autonomously
within the cloud, except
when it comes to paying
for hybrid connectivity.
They almost always
want to share that.
So I want to use the same
kind of high speed connections
I have with the Google
Cloud environment
even though I may be an entirely
different business entity.
So where we have
this segregation here
by environment type, like
dev, test, and production,
you could also think about that
to be separate logical business
entities or small peer groups of
VPCs for a particular business
entity.
Name them whatever you want.
Inevitably in that case,
there's almost always
services that you want to share
across those business groups,
whether it's active directory,
or source code repositories,
or the CI/CD pipeline,
those resources
are also a good fit for
this connectivity VPC
because it has peer to access
to all of those downstream VPCs
as well.
So this acts--
again, this is really
just about how you
use the networking
constructs in the cloud versus
just going and saying this
is going to be like
a connectivity VPC.
The scope and use
of the VPC really
defines its purpose inside
of the cloud environment.
MATT NOWINA: So it's
not like you're limited
to a single connectivity VPC.
This is actually a
scale-out pattern.
ZACH SEILS: Yeah, you
could scale it out.
I'm working with
one customer now
where they have 13 independent
business entities inside
of their organization.
Each one has their own kind of
connectivity VPC, if you will,
and then they have a set of
small group of downstream VPCs
that are environmentalized,
so dev, stage, production,
et cetera.
So I think we kind of--
we have one more, right?
One more.
So I think maybe we'll do
a little curve ball here,
just thinking about
what customers commonly
kind of come to us with.
I'm going to give this one
to you just because I can.
So what if a customer needs
to bring a third-party network
capability or device into the
cloud as a virtual machine?
MATT NOWINA: Why would
you ever need that?
ZACH SEILS: Let's
just say it's needed.
How would that
influence and change
the way you're doing VPC
design and some of the things
that we've talked about?
MATT NOWINA: So I
mean, wouldn't it
be nice if there were cloud
native solutions for everything
we wanted?
But I mean, the reality is
that for any number of reasons
there are going to be times when
you need to bring appliances
into the cloud.
You need to start to think
about what those deployment
models look like.
Now, the icons are a
little small at this point,
because we're starting to
group these things together.
But what we wanted to
sort of call out here
is the idea that
typically, these devices
require multi-NICs.
So you can think of an NGFW that
you wanted to do layer seven
inspection on, or
something that's
going to act as a router
between your various VPCs.
But there are specific
rules within GCP
that actually require us
to modify the VPC design.
So here, what you're seeing
is that multi-NIC requires
different VPCs for each
of the interface cards,
and all of those VPCs have
to be in the same project.
ZACH SEILS: So sorry,
Matt, just one second.
So when you say
multi-NIC devices,
you're talking about a virtual
appliance for a security vendor
or something?
So it's multiple interfaces.
MATT NOWINA: Exactly.
ZACH SEILS: OK.
MATT NOWINA: Yeah So the best
practices, the considerations
you need to bring into
play when you're thinking
about these devices, though,
is how are you routing traffic
to those devices, are you
modifying the default route,
what are the implications to
accessing managed services when
you're no longer using
the default internet
gateway, instead using
a third-party device,
as well as thinking
about high availability.
So how are you ensuring
that this device
is up and forwarding packets?
How do you health check it?
Each one of these are
important considerations,
but there is a deployment
pattern for using these devices
within GCP.
ZACH SEILS: Good stuff.
So I think we've covered a
number of different scenarios.
I think this is
pretty commonly what
we see from customers in
terms of how they start
their journey really specific
to networking inside the cloud.
Again, the premise here
is just start simple.
It's easy to kind
of expand and evolve
over time as your requirements
here need change in the cloud
environment.
There's no reason to kind of
overly engineer from a design
perspective.
Also, think less about
the traditional networking
constructs like placement in
the network and IP addresses
and subnet membership as really
kind of primary identifier
of a particular workload.
As Matt mentioned,
we have capabilities
within the firewall to
do micro-segmentation
that can actually follow a
particular virtual machine
instance or humanities
pod regardless
of where it happens to be
instantiated in the network.
So this makes actually
creating the policies
and maintaining those policies
inside of our environment
much, much more simple
by leveraging these kind
of abstractions for identity.
And so, I think that--
we have something else, right?
You have something else
you want to talk about.
MATT NOWINA: So I almost
wish I had a black turtleneck
on for this part.
As much as Zach and
I would like to think
that a 40-minute presentation on
some example of VPC deployment
scenarios would be enough
for you to sort of rethink
your designs, we actually
have gone one step further.
So we believe that as a
cloud service provider,
the obligation is on
us to provide best
practices for these things.
You would have seen,
as we were going
through these
deployments, that we
had different sets
of best practices
that go down the side.
So I am very pleased to
announce during this session
that we have just made live our
VPC best practices and design
guide.
So the links that
you see up here
are links to all
the things that we
think are important when first
moving into your VPC design
decision.
So we want you to
start by thinking
about your organization, your
line of business, your project.
What are you trying
to design for?
And then use these links.
So bit.ly/NET201-VPC for our
VPC best practices guide.
NET201-ENT for best practices
for enterprise organizations.
NET201-POLICY for understanding
policy design as it
applies to enterprise customers.
You may have also noticed
in the past few months
we launched a new Coursera
course for networking
in the Google Cloud Platform.
We encourage you
to use that if you
want to continue to
get your hands dirty,
understand how these different
components work together.
And then get started
today, build something,
understand that this VPC
design that you implement now
uses all the information that
you have available to you,
but it may not
apply in the future.
There may be iterations,
and that's OK.
And lastly, showcase
your skills.
So another thing
that we've worked on
in the last few months is to
launch the Google Certified
Professional Network Engineer.
And I've been told there's
some pretty cool swag if you
decide to go and write the test
either today or in the future.
Additionally, we
have a special guest
with us today who's actually
the author of the VPC best
practices--
Mike Columbus, who will be
signing autographs if anyone
wants.
Mike, put your hand up.
He's over there in the audience
if anyone wants to talk to him.
But
ZACH SEILS: Also, Matt, you also
worked on the certification.
MATT NOWINA: Yeah.
ZACH SEILS: Perfect.
So one more slide.
Again, the Dory's open.
It will stay open through
April 25, as we mentioned.
Please add your questions
there now or in the future.
We really look forward to
engaging with you online.
And take the survey.
Let us know how we did, let
us know what things you want
to hear about in the future,
whether it's in print, online,
whether it's in the
future Next sessions.
We really, really appreciate
you taking the time
to come to our
session, and we hope
you enjoy the rest
of your week at Next.
MATT NOWINA: Thank
you very much.
[MUSIC PLAYING]
