STEPHANIE WONG: For an
on-prem developer looking to migrate to the cloud,
one of the first things you have a need for is
to set up a network. But there are some
key differences between your traditional
on-prem network setup and the cloud's
software-defined networks or virtual private clouds. In this episode of GCP
Networking End-to-End, I'll be covering
what a VPC is, how it differs on Google
Cloud Platform, and how to set one up. Stay tuned. [MUSIC PLAYING] A VPC stands for
Virtual Private Cloud, and is a private, isolated
virtual network partition that provides managed networking
functionality for your Google Cloud Platform-- GCP-- resources. You can think of a VPC
as a virtual version of your traditional
physical network. It lets you set up
private communication between your virtual
machines and the cloud, including firewall
rules and routing, so that you're protected from
external and unwanted access and limit public exposure
of your instances. In a traditional VPC,
the scope is usually bound to a geographic region,
like US West versus US East, and all the work
and communication between VMs in that region are
expected to stay contained. If you want to move beyond
that, connect workloads across regions,
you need to somehow have a way to provide
for private connectivity to ensure your workloads
aren't compromised, which usually means
leveraging a VPN connection across public
IPs of the regions. While this seems fine
in theory, in practice, the overhead and costs
associated with your deployment grows with each new
region that must be added. Imagine scaling to
hundreds of projects with massive numbers
of VPNs and VPN gateways to stitch together. On top of that, you have to add
multiple routers in each VPC and use them across
VPN tunnels to provide dynamic advertisements or BGP
sessions for your subnets. Subnets is just a fancy way of
saying an IP segment in a VPC, while BGP is the protocol that
helps route traffic to subnets. Now you have a sprawl of
many routers and BGP sessions you're managing. Now while a task can
be easily automated, network management can still
include the responsibilities of coordinating policies
that cross multiple admin domains, teams, and resources
like organization, security, projects, networks,
and endpoints. This might be fine
if your company needs complete isolation between
VMs in different regions. But if you're like
most companies who want to distribute your
workloads across regions and reduce latency when
traversing the public internet, you'll want those VMs to
be able to communicate across a private network. This is where Google Cloud
Global VPC comes into play. A single Google Cloud VPC
can span multiple regions without communicating
across the public internet. It provides the same
private gateways for your on-prem
hardware, but also gives you global
scope between regions, sharable configuration
between your projects, and near-real-time logging
to monitor your application. It also lets you increase
the IP space of any subnet without any workload shutdown
or downtime, not to mention a full suite of
support services, like shared VPC, Cloud Router,
firewall support, VPC peering, and an industrial-strength VPN. But I'll get to all of
that in a later episode. Now, the really cool thing
about GCP's VPC system is that it allows your
VMs to communicate across regions without needing
the extra overhead of VPNs to do so. This is all done using the same
global underlying network that powers search,
YouTube, and Gmail. This means that Google handles
your traffic under the hood by dynamically advertising
routes across the VPC, so you don't have to. Google Cloud VPC is
ideal for situations where you're hosting
globally distributed multi-tier applications by
creating a VPC with subnets, or connecting GCP-hosted or
externally hosted databases to Google's unique
machine learning services by creating a VPC with
subnets and VPN access, or even disaster recovery
with application replication, create backup GCP
compute capacity, then revert back to it
once the incident is over. As such, using GCP VPC means
that you have a simplified network with a single global
VPC with regional segmentation, meaning fewer VPNs and routers. You have simplified management. A single security policy
can be applied globally. There are fewer
network constructs to break and troubleshoot. With that in mind, let's
do a quick walk-through of how to set up a VPC for
your existing on-prem config using the Google VPC. First, go to the
VPC Networks page in the Google Cloud
Platform console. Now you see we have a
default VPC with subnets in each region created. In a true hybrid setup,
it's common to get rid of the default
VPC, as you already have an on-premise network
with an IP address scheme setup, which means the default
VPC might have overlapping IP ranges. Click Create VPC Network,
enter a name for the network. We'll choose Automatic for the
subnet creation mode for now. Now for this example, Auto mode
is an ideal situation for us since it makes setup easier. When using Auto mode, the
VPC will create a subnet automatically-- again, a fancy
way of saying a block of IP addresses for a region-- where the subnet IP falls
within predefined IP ranges so that we don't have
to do the math ourselves. Again, you can select Custom
to avoid overlapping IP ranges to your on-prem network. Note also that I didn't
create VPC in a region. It's global. But you do select
region for a subnet. Now, in the Firewall
Rules section, you can select one or
more predefined firewall rules that address common use
cases for connectivity to VMs. Likewise, you can
create your own rules, or use none if you like to
roll the dice on security. We'll be covering
more on firewall rules in a later episode. Again, for simplicity's
sake, we'll choose the dynamic routing
mode for the VPC network, and then we click Create. Now to test if our VPC
network is working properly, we're going to create a
new instance in a region, and then ping it to see
what its IP address is. Let's go to the Compute Engine
tab, and create an instance. Now I'm going to leave
all this as default for the sake of brevity. The important thing
is down under Show More and the Network tab. We click Network and
change it from Default to vpc1, which you can see
changes the subnetwork. Let's click Create. And once it's spun
up, you can see that it's internal
IP address matches that of what our subnet was. Even with increasingly complex
networks and workloads, you can map your on-premise
network topologies in Google Cloud. Stay tuned for the next piece. And remember,
optimizing your network means freeing up your bandwidth. [MUSIC PLAYING]
