STEPHANIE WONG: Business agility is about consuming services
and applications.
With more and more SaaS and services being consumed,
you don't have to reinvent the wheel to be productive.
Google Cloud Private Service Connect
is the solution to help you accelerate
your consumption of these services in the Cloud
securely, simply, and quickly.
Stay tuned.
[MUSIC PLAYING]
Services like ERP SaaS applications, database
as a service, financial data sets, log analytics, and file
sharing have increasingly enabled companies
to stay ahead.
That trend and the migration to Cloud
will only continue for enterprises.
But diverse services means more complexity.
Services all live in different networks and environments.
Application developers want to simply connect to and consume
each service, rather than spend time tinkering
with routing tables, IP addresses, and NAT rules.
In addition, security has only become
more fundamental to all aspects of company operations.
Most companies have requirements to restrict traffic
to private networks, not allowing public IPs
in order to reduce vulnerabilities.
Google Cloud Private Service Connect
vastly simplifies service connectivity
so you can consume services quickly
with minimal management.
It's a fully-managed solution.
It lets you setup private connectivity to your own,
third-party, and Google services across networks
that belong to different groups, teams, projects,
or organizations.
If you're trying to set up connectivity for a workload
to consume data from services like a GKE
private master, Cloud Spanner, Cloud
Storage, or a financial dataset on a private network,
PSC lets you simply set up an endpoint from your network
and a target service.
If you want to expose a service like a log streaming
application to be discoverable, you simply
set up a service attachment.
Private Service Connect enables service-centric networking
by creating an abstraction layer on top
of our traditional network capabilities
to make the network completely transparent.
It helps you consume services faster,
achieve a service-driven environment, secure your data,
and simplify network management.
Private Service Connect is secure.
Traffic doesn't traverse a public internet.
Your services interact like they're
on their own private network.
Simple and performant.
It takes care of network configuration,
so you don't have to worry about routing
tables, IP addresses, and unnecessary coordination
between teams.
You don't need to configure proxies in your network
and it provides line-rate performance.
Agile.
It lets you focus on the service,
instead of network management, so dev teams
are empowered to easily set up connectivity
on their own, unburdening network engineering teams.
Both teams can independently get up and running
and be more productive.
For the demo today, I already created all the networking
resources, instances, internal load balancer,
and Cloud Storage bucket represented
in this diagram for simplicity.
We're going to show how a client in the consumer VPC
can access a new service in the producer VPC
through a private Service Connect endpoint and service
attachment.
When the client sends traffic from its source IP
to the endpoint, the Private Service Connect
will send the allowed traffic from the client IP
to another address in the producer subnet
where the Private Service Connect service attachment is,
then to the internal load balancer forwarding
rule to forward traffic to the backend servers.
I'll then show the client also accessing a Google API--
a Cloud Storage bucket--
through another Private Service Connect endpoint.
I'll start with the producer VPC with two subnets.
10.0.2 is the producer subnet that hosts our web servers,
then the PSC subnet gives access from the consumer
network to producer services being exposed.
To show you the routes, I can verify
that there is no connectivity from the consumer VPC
to the producer VPC, just a default route to the internet.
I only have firewall rules that allow traffic from those two
subnets, plus the health check ranges
to make sure my service is healthy.
If I head over to Private Service Connect and then
the Publish Services tab, I can see the psc-producer service.
It's configured to automatically accept all projects,
and staging-web is my consumer project already connected.
This exposed service is the load balancer
as a backend with a private IP of 10.0.2.10,
and in frontends, our web server instances, which
is the service we're exposing.
Now I'll show my consumer VPC with a single subnet
and different private IP.
And I also have no firewall rules setup here
on the consumer side.
Under Routes, there's nothing but the subnet route.
I deleted the default route to the internet
to show Private Service Connect enabling connection
to Google APIs--
in this case, our storage bucket.
Under Private Service Connect, you
can see here there's two connected endpoints.
The psc-consumer endpoint targets the web servers
we have on the producer VPC.
This endpoint ends in .100.
The pscga endpoint targets all Google APIs.
This endpoint ends in .111.
When the pscga endpoint was created,
it also created a new DNS private zone
with DNS name p.googleapis.com.
It doesn't create any records, but you can now
use Private Service Connect to target
Google APIs using this domain and you
get automatic DNS resolution.
Next, I'll navigate to the consumer-client VM
with only an internal IP and I'll
SSH into it using Cloud Shell.
To show the client using Private Service Connect to reach
the web servers in the producer VPC,
I'll run a curl command to the web server
in the producer VPC subnet using its local endpoint
ending in .100.
And I can see I can access the server.
Now let's provide connectivity to Google APIs
with Private Service Connect.
I can query our storage bucket using the Private Service
Connect endpoint-- pscga--
by doing an nslookup for storage-
the PSC endpoint name .p.googleapis.com.
And it returns the pscga endpoint IP, 100.111.
I also have my gsutil client configured
to use this private endpoint, and now I
can list the bucket content.
Just to prove that's the content, if I navigate
to the consumer-psc-bucket page in the Console,
it's the same file.
Going back to the consumer VPC's Firewall Rules page,
you can see the psc-subnet rule now has a hit count of 1,
because the session I just established.
The connectivity between the client VM,
and producer backends, and the storage bucket isn't explicit,
but it's enabled by Private Service Connect.
It happens privately and securely
through Google's backbone network.
With Private Service Connect, you
can consume services faster and stay ahead of the curve
because it's a fully-managed solution,
meet compliance and keep traffic secure, simplify your network
and move to the Cloud faster, leverage a strong and growing
list of third-party vendors and partners,
and get performance and scale to keep up
with your growth and the competition.
Check out cloud.google.com/private
service connect to learn more, and check out the links below
for code labs and guide.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]