We will take a deeper dive into the presentation layer of the amazing Google Cloud Platform (GCP) today. The presentation layer has to do with the flow of data through the system, between the user, business logic, and the storage services – in other words ‘the network’.
This blog post is a deeper look at the 8-step process an-8-step-process-to-architect-solutions-on-the-google-cloud-platform-gcp.
GCP uses a software defined network that is built on a global fiber infrastructure that makes GCP one of the largest and fastest networks.
The Google network consists on regions and zones. A region is a specific geographic location and contains one or many zones.
Virtual Private Cloud or VPC is Google’s managed networking functionality for your Cloud Platform resources. As we know Projects are used to organize infrastructure resources, but what’s interesting and unique is that each projects can have up to 5 networks. These networks do not have IP ranges. GCP’s networks are global and we can segregate the resources into sub networks. There are 3 different types of networks – default, auto mode and custom mode. An auto mode network can be converted to a custom mode network but not vice versa.
Networks are used to isolate systems in the Google Cloud Platform. In the picture below, A, B, C and D are virtual machines. A & B can communicate across regions because they are in the same network. C & D have to communicate via an external Google edge router even though they in the same region because they are in different networks.
Subnetworks can extend across zones in the same region. A subnetwork is simply an IP address range and you can distribute IP addresses within that range. In the picture shown next, even though the two virtual machines are in different zones, they will be able to communicate with each other using the same subnet IP address.
In GCP, as mentioned earlier, networks do have any IP ranges. So the subnetworks do not need to fit into an IP address hierarchy like you would in an op-prem environment. We can use subnetworks to group and manage resources like different environments (marketing, ERP, dev, test etc).
Each virtual machine can have two IP addresses assigned, one is an internal IP address assigned via DHCP (Dynamic Host Configuration Protocol). Each virtual machine that starts up and any service that depends on it gets an internal IP address. DNS is scoped to the network, so we can get it to translate web URL’s and VM names of hosts in the same network, but it can’t translate hostnames from VM’s in another network within GCP.
The other IP address that is assigned is external and is optional. So if your machine is external facing, then it makes sense to use it. The IP address is assigned from a pool (ephemeral) or use a reserved IP address making it static. External IP addresses are billed even if they are not attached to running VM. They key in GCP is that the external IP address is unknown to the VM making it secure.
Domain names can be hosted on GCP using a managed service called as Cloud DNS. If you have multiple services running on a VM and we want to assign each service a different IP address, then we can do that by a feature called Alias IP ranges.
Every GCP network has routes that let instances in a network send traffic directly to each other. But you also need firewall rules to be to be set to complete this process. Firewall rules protect VM instances from unapproved connections both in bound (ingress) and outbound (egress). A route is also created when a subnet is created and this allows the VM’s on the same subnet to communicate internally.
Here’s some billing information from GCP.
When designing the GCP architecture for your needs and for the cloud in general, the location of the resources with the cloud network is significant.
Here are some sample statistics for context on location:
- Sending a 2kb packet over a 1 Gbps network – takes 0.002 milliseconds.
- A round trip with a GCP datacenter – takes 0.5 milliseconds.
- Send a packet across continents say, California-Italy-California – takes 150 milliseconds.
- In general, no more than 6-7 round trips are possible between the US and Europe per second.
These statistics help you determine whether you need to push the data closer to where your users are or locate your application in multiple data centers.
The Google Cloud Platform (GCP) uses load balancers to get user traffic to application servers with capacity in the closest region to the user. Google’s load balancers can also scale services by distributing traffic over multiple servers and by triggering autoscaling.
Google provides several load balancing services that offer different location controls and traffic distribution methods.
With GCP’s global load balancers, we can get a single external IP address that allows you to route your traffic to multiple regions or data centers where your data centers exist. These global load balancers support both IPv4 and IPv6 externally, but only offer IPv4 down to the VM’s. Google offers not just HTTP, but also SSL and TCP. With SSL, there is a choice to simply act as a proxy but still offer SSL certificates. With the TCP, we can get intelligent routing to our application that may be anywhere in the world.
In addition to the global load balancers, GCP also offers network and internal load balancers. These load balancers are regional in scope. With the network load balancers, they maintain session affinity so that in case you are scaling up due to growth/network traffic, they maintain the session before the service shuts down. The health checks are offered periodically to see if are any issues. The internal load balancers are designed for backend services. They communicate on the internal IP addresses instead of a fixed external IP address.
Often we will have a combination of global load balancers and network/internal load balancers. The internal load balancers determine the growth or shrinkage (autoscaling) of the clusters that support your application.
So how do you chose the right load balancer for your needs? As usual Google provides us with a nice decision tree.
GCP does allow assigning external IP addresses to virtual machines but it goes against best practices. We get only 7 static IP addresses per GCP project, so putting them on a load balancer is highly recommended by Google. If you plan to use network or internal load balancers then you can use any of the available external IP addresses. For GCP’s global load balancers, they have a set of reserved IP addresses with configured BGP (Border Gateway Protocol) routes. This way customers can enter a Google network within 250-500 miles of any major city in the world. These global IP addresses cannot be assigned to a regional resource and this makes setting up DNS and firewall rules much easier – we can specify a range of external Google IP addresses to only be allowed access to internal services and vm’s.
Let’s discuss Google CDN’s (Content Delivery Network) now, which is pretty awesome by the way. Here Google responds to user request from a location that will provide the lowest latency. The edge network receives the user request and passes it to the nearest Google data center. The data center generates a response that provides the best experience for the user at that time. Your application retrieves the required content and this can come from multiple locations – Google data centers, Edge PoPs (points of presence), and Edge Nodes (global cache). You will need to turn on HTTP(S) load balancing to access CDN. The other advantage is cost, you can save 50% of your egress (outbound traffic) fees by using CDN.
Most often, customers over the last year have hybrid clouds including other cloud providers. GCP offers options to handle that with dedicated interconnect options.
The other option is by using VPN’s. All of this possible due to the GCP Cloud Router.
In summary, the Google Cloud Platform offers you a complete range of industry leading networking solutions for the cloud.