<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Google Cloud on Jhooq</title><link>https://jhooq.com/series/google-cloud/</link><description>Recent content in Google Cloud on Jhooq</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Jhooq</copyright><lastBuildDate>Fri, 09 Oct 2026 10:40:00 +0000</lastBuildDate><atom:link href="https://jhooq.com/series/google-cloud/index.xml" rel="self" type="application/rss+xml"/><item><title>Google Cloud Private Service Connect (PSC) Explained - Publish a Service with a Service Attachment and Consume It Through a PSC Endpoint</title><link>https://jhooq.com/gcp-private-service-connect/</link><pubDate>Fri, 09 Oct 2026 10:40:00 +0000</pubDate><guid>https://jhooq.com/gcp-private-service-connect/</guid><description>
&lt;br/&gt;
&lt;p&gt;This is the last post of my Google Cloud networking series, and it is about the tool I find the most elegant of them all - &lt;strong&gt;Private Service Connect&lt;/strong&gt;, or &lt;strong&gt;PSC&lt;/strong&gt;. With &lt;a href="https://jhooq.com/gcp-vpc-peering/"&gt;VPC peering&lt;/a&gt; we connected two whole networks. With &lt;a href="https://jhooq.com/gcp-shared-vpc/"&gt;Shared VPC&lt;/a&gt; we put many projects on one network. PSC does something much more surgical - it lets one team &lt;strong&gt;publish a single service&lt;/strong&gt;, and any other team &lt;strong&gt;consume it over a private IP inside their own VPC&lt;/strong&gt;, with the two networks never being joined at all.&lt;/p&gt;</description></item><item><title>Google Cloud Shared VPC Explained - Host Project, Service Project, networkUser and Cloud NAT (gcloud and Terraform)</title><link>https://jhooq.com/gcp-shared-vpc/</link><pubDate>Fri, 09 Oct 2026 10:30:00 +0000</pubDate><guid>https://jhooq.com/gcp-shared-vpc/</guid><description>
&lt;br/&gt;
&lt;p&gt;In the last two posts we connected networks with &lt;a href="https://jhooq.com/gcp-vpc-peering/"&gt;VPC peering&lt;/a&gt; and &lt;a href="https://jhooq.com/gcp-cross-project-vpc-peering/"&gt;cross-project VPC peering&lt;/a&gt;, and both times we ran into the same wall - peering is not transitive, and every team still has to build and maintain its own VPC. In this blog post we are going to look at the way enterprises actually solve this on Google Cloud - &lt;strong&gt;Shared VPC&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;With Shared VPC there is only &lt;strong&gt;one network&lt;/strong&gt;. One project (the &lt;em&gt;host&lt;/em&gt;) owns it, and other projects (the &lt;em&gt;service projects&lt;/em&gt;) simply borrow its subnets. The network team runs the network, the app teams run workloads on it, and nobody peers anything. We will build it end to end - host, service project, IAM, firewall, a VM in the service project sitting on the host's subnet - and then one Cloud NAT so that every workload in every service project goes out through a single egress IP.&lt;/p&gt;</description></item><item><title>Google Cloud Organization Setup with Cloud Identity Free - Create an Org and Move Your Projects Under It</title><link>https://jhooq.com/gcp-organization-setup-cloud-identity/</link><pubDate>Fri, 09 Oct 2026 10:20:00 +0000</pubDate><guid>https://jhooq.com/gcp-organization-setup-cloud-identity/</guid><description>
&lt;br/&gt;
&lt;p&gt;When I started the &lt;a href="https://jhooq.com/gcp-shared-vpc/"&gt;Shared VPC&lt;/a&gt; lab I hit a wall on the very first command - &lt;code&gt;gcloud compute shared-vpc enable&lt;/code&gt; simply does not work on a standalone project. Shared VPC, Organization Policies, folders, hierarchical firewall policies and org-level IAM all need one thing first - a &lt;strong&gt;Google Cloud Organization&lt;/strong&gt;. And most of us who started with a personal Gmail account and a couple of projects do not have one.&lt;/p&gt;</description></item><item><title>Google Cloud Cross-Project VPC Peering - Peer Two VPCs in Different Projects (gcloud and Terraform)</title><link>https://jhooq.com/gcp-cross-project-vpc-peering/</link><pubDate>Fri, 09 Oct 2026 10:10:00 +0000</pubDate><guid>https://jhooq.com/gcp-cross-project-vpc-peering/</guid><description>
&lt;br/&gt;
&lt;p&gt;In the &lt;a href="https://jhooq.com/gcp-vpc-peering/"&gt;previous post on Google Cloud VPC peering&lt;/a&gt; we built a hub-and-spoke inside a single project. But in a real company that is almost never how it looks. The network team owns a &lt;strong&gt;hub&lt;/strong&gt; in one project, and every application team has its &lt;strong&gt;own project&lt;/strong&gt; with its own VPC. So in this blog post we are going to peer two VPC networks which live in &lt;strong&gt;different projects&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;The good news - it is the same peering primitive. The three things which change are the &lt;code&gt;--peer-project&lt;/code&gt; flag, the fact that each side is created in its own project with its own permissions, and the Terraform, where we need &lt;strong&gt;two providers&lt;/strong&gt;. And at the end we will hit the transitive trap again, which bites much harder across projects.&lt;/p&gt;</description></item><item><title>Google Cloud VPC Peering - Hub and Spoke Setup Step by Step with gcloud and Terraform</title><link>https://jhooq.com/gcp-vpc-peering/</link><pubDate>Fri, 09 Oct 2026 10:00:00 +0000</pubDate><guid>https://jhooq.com/gcp-vpc-peering/</guid><description>
&lt;br/&gt;
&lt;p&gt;In this blog post we are going to look at &lt;em&gt;&lt;strong&gt;Google Cloud VPC Network Peering&lt;/strong&gt;&lt;/em&gt; - what it is, when you should use it instead of Shared VPC or a VPN, and then we are gonna build a complete &lt;strong&gt;hub-and-spoke&lt;/strong&gt; lab step by step. Two VPC networks, two VMs with no public IP at all, and by the end of the post the hub VM pings the spoke VM over an internal IP, privately over Google's backbone.&lt;/p&gt;</description></item></channel></rss>