From Your Device To Google Cloud API: Networking Basics

The initial connectivity available would depend on where you are connecting from and what device you’re using. Your connection request has to go from point A (being your device) to point B (the Google API) where authentication happens to allow access. In your home or your Enterprise network this involves a series of steps, possibly multiple connection mediums (ethernet or wireless) and several nexthops (router connection points your traffic traverses on its journey). It’s all an intricate synergy of DNS, IPV4, IPV6, routing protocols, NAT, firewalls and more.

As you can see from the very get-go, networking is involved, even if the tooling hides much of its complexity. On the Google end there needs to be a reliable API endpoint that is available for whenever a customer wishes to connect. These APIs are built on Google’s planet scale network currently comprising 29 cloud regions and 88 zones. The Google private backbone is built on a robust fiber, low latency network which ensures excellent performance.

Drilling down a bit further, when a customer decides to adopt Google Cloud, the organization has to be on-boarded into the cloud. This comprises setting up the environment, billing, IAM, networking, security and more. There are several options to help you get started (Google Cloud Setup Checklist, Cloud Foundation Toolkit)
From a networking point of view, when a new project is created in your environment it automatically creates a default Virtual Private Cloud (VPC). A VPC is a virtual representation of a physical on-prem environment. In Google Cloud VPC are global and networks are regional. For administrative and other purposes you can disable the automatic creation of the default VPC when a project is created by using the Organizational Constraint policy constraints/compute.skipDefaultNetworkCreation.
You can design your VPC with the following network modes:

• Auto mode network; The default network which is created when a new project is created is an example of an auto mode network. You can also select an auto network manually when configuring your environments.

• Custom mode networks; These allow you full control over all configuration.

The networking and routing which occurs within the GCP environment is all software defined and includes several capabilities similar to on-prem environments, including firewalls, DNS, DHCP, NAT, Router, VPN, load balancers, private networks (RFC1918), public IP addresses just to name a few.

If we look at microservice-focused environments like Google Kubernetes Engine (GKE), we also have a bit of networking involved. In GKE all Services, Nodes, containers and Pods are assigned IP addresses. These IP addresses are assigned from various address pools, and for Nodes, containers and pods they are ephemeral. Outside of the default address assignment there are a few options to customize your addressing, like flexible pods CIDR and multi pod CIDR.

For services in GKE you are assigned a stable IP address. Examples of common services are ClusterIP, NodePort, LoadBalancer, ExternalName and Headless. Ingress allows you to expose your application for HTTP(S) traffic and can be configured for internal and external cases. As you can see there are quite a few points where networking is involved in GKE and other services.

Without going into an exhaustive list of networking functionality in GCP you can be certain that your experience is backed by a very strong world class network with premium and standard tier service. Remember, networking is a core component in your cloud experience even if it’s not obvious to you.

To learn more about Google Cloud networking check the following links:

• Explore Networking in Google Cloud today.
• Also check out A year in review: Advancements in infrastructure at Google Cloud

Want to ask a question, find out more or share a thought? Please connect with me on Twitter or  Linkedin and send me a message.