Great video! To access Google APIs and services from on-premises locations, what's the rationale about choosing Private Service Connect vs. Private Google Access?
Private Google Access still uses external IP addresses. It allows access to the external IP addresses used by App Engine and other eligible APIs and services. PSC would let you access Google APIs via internal IP addresses instead, keeping traffic on GCP's private network backbone.
Referring to diagram at minute 1:37, how can traffic stay in Google's network when producers are non-GCP services, i.e. Third-party Partner services, and Customer-owned services? Isn't this a hybrid or multi-cloud connectivity, which requires Interconnect POPs or Edge locations?
3rd party and on-premise services would need to be connected through a VPN or Interconnect VLAN attachment. You can then use PSC to access services using global internal IP addresses (PSC does NATing). More info here: cloud.google.com/vpc/docs/configure-private-service-connect-apis#on-premises
Private Service Connect is used to connect to a Private Service Connect endpoint in your VPC network, which forwards requests to Google APIs and services. Private Service Access is used to connect to a Google or third-party managed VPC network through a VPC Network Peering connection. More info in this handy chart here: cloud.google.com/vpc/docs/private-access-options
Great Video. Love this format. If I have VPC A and Network AA, can PSC allow me to expose a service like a GCE VM / SQL Instance on VPC B Network BB, *and* consumers who reside in VPC A Network AA still have access like normal? This seems to echo what GCP has been evangelizing - think of the network as a bunch of services with endpoints. You control what is allowed to access that endpoint. The consumer origin can be anywhere, and it doesn't matter, as long as they have credentials to access the endpoint.
Thank you and yes - this is the model we are following, though its a slow shift for many customers. Service-centric networking means exactly that - you focus on the service. Network engineers or developers have autonomy to set up connection from a client (consumer) to access a service (producer) (like a VM or SQL instance) in an entirely separate network, as long as they are allowed access through an endpoint. Configuration just means setting up endpoints and service attachments rather than NAT gateways, routing tables, VPNs, etc. Check out my conversation with Networking Specialist, Ryan Pryzbyl to get a good POV on the shift towards service-centric networking: ruclips.net/video/DIXv-wVb69M/видео.html
PSC provides a service-centric model for connecting and is the preferred model for consumer-producer connectivity because of its simplicity, security, and ease of use. VPC peering is still a popular way of connecting VPCs and customers can continue to use it when they want to manage the network themselves.
@@stephaniewong142 For me, both really looks the same from the video.. especially the 2 VM's connecting privately.. Can you create a video comparing the similarities and differences between VPC peering and PSC ?
@@arjunk5959 When you peer two VPCs you are essentially merging both networks. PSC just opens one service to another VPC. In theory this is a far less complex way of managing connectivity between VPCs and it is also far better because generally when you peer VPCs is often because you have a service you want to share with another VPC, etc.
Thanks for your information
Any time
Great video! To access Google APIs and services from on-premises locations, what's the rationale about choosing Private Service Connect vs. Private Google Access?
Private Google Access still uses external IP addresses. It allows access to the external IP addresses used by App Engine and other eligible APIs and services. PSC would let you access Google APIs via internal IP addresses instead, keeping traffic on GCP's private network backbone.
@@stephaniewong142 hook up with you
Theoretically fine, but it would have been more helpful if the step by step walkthrough process has been explained. Please try next time.
Referring to diagram at minute 1:37, how can traffic stay in Google's network when producers are non-GCP services, i.e. Third-party Partner services, and Customer-owned services? Isn't this a hybrid or multi-cloud connectivity, which requires Interconnect POPs or Edge locations?
3rd party and on-premise services would need to be connected through a VPN or Interconnect VLAN attachment. You can then use PSC to access services using global internal IP addresses (PSC does NATing). More info here: cloud.google.com/vpc/docs/configure-private-service-connect-apis#on-premises
Nice content
What is the different between Private Service Connect and Private Service Access?
Private Service Connect is used to connect to a Private Service Connect endpoint in your VPC network, which forwards requests to Google APIs and services. Private Service Access is used to connect to a Google or third-party managed VPC network through a VPC Network Peering connection. More info in this handy chart here: cloud.google.com/vpc/docs/private-access-options
Great Video. Love this format.
If I have VPC A and Network AA, can PSC allow me to expose a service like a GCE VM / SQL Instance on VPC B Network BB, *and* consumers who reside in VPC A Network AA still have access like normal?
This seems to echo what GCP has been evangelizing - think of the network as a bunch of services with endpoints. You control what is allowed to access that endpoint. The consumer origin can be anywhere, and it doesn't matter, as long as they have credentials to access the endpoint.
Thank you and yes - this is the model we are following, though its a slow shift for many customers. Service-centric networking means exactly that - you focus on the service. Network engineers or developers have autonomy to set up connection from a client (consumer) to access a service (producer) (like a VM or SQL instance) in an entirely separate network, as long as they are allowed access through an endpoint. Configuration just means setting up endpoints and service attachments rather than NAT gateways, routing tables, VPNs, etc. Check out my conversation with Networking Specialist, Ryan Pryzbyl to get a good POV on the shift towards service-centric networking: ruclips.net/video/DIXv-wVb69M/видео.html
@@stephaniewong142 thank you.
Is this eliminating the need of vpc peering?
PSC provides a service-centric model for connecting and is the preferred model for consumer-producer connectivity because of its simplicity, security, and ease of use. VPC peering is still a popular way of connecting VPCs and customers can continue to use it when they want to manage the network themselves.
Thanks 👍
@@stephaniewong142 For me, both really looks the same from the video.. especially the 2 VM's connecting privately.. Can you create a video comparing the similarities and differences between VPC peering and PSC ?
@@arjunk5959 When you peer two VPCs you are essentially merging both networks. PSC just opens one service to another VPC. In theory this is a far less complex way of managing connectivity between VPCs and it is also far better because generally when you peer VPCs is often because you have a service you want to share with another VPC, etc.
hi😄😄😄
Google not privacy friendly.... i am not use Google drive because Google not use zero knowledge encryption...