Introducing GCP

This section will provide an overview of GCP and its services. Additionally, we will look at the Google Cloud global network infrastructure, which includes regions and zones. Finally, we will describe the concepts of projects, billing, and quotas in GCP.

GCP's global infrastructure – regions and zones

Over the years, Google has invested billions of dollars to build its private network and today can carry 40% of the world's internet traffic every day. The customers who decide to deploy their cloud services on GCP will benefit from the highest throughput and the lowest latency. Google offers connection to their cloud services from over 140 network edge locations (https://cloud.google.com/vpc/docs/edge-locations), as well as via private and public internet exchange locations (https://peeringdb.com/api/net/433). Thanks to Google's edge caching network sites, which are distributed all around the globe (https://cloud.google.com/cdn/docs/locations), latency can be reduced, allowing customers to interact with their cloud services in near real time. In the following diagram, you can see where Google's network has its presence in terms of regions and PoP:

Figure 1.3 – GCP regions and global network

As you can see, GCP data centers are organized into regions and zones around the globe and are interconnected with Google's physical private network. Regions are independent geographic areas that include three or more zones. For example, the us-central1 region includes the us-central1-a, us-central1-b, and us-central1-c zones. In GCP projects, there are global resources such as static external IP addresses:

Figure 1.4 – GCP regions, zones, and global resources

To design a robust and failure-tolerant cloud infrastructure, it is important to deploy resources across zones or even regions. This prevents you from having an infrastructure outage that affects all resources simultaneously. Thus, it is particularly important to know which of the following categories your resources belong to, as follows:

• Zonal resource: This is a resource that is specific to a zone, such as a virtual machine instance.
• Regional resource: This is a resource that is specific to a region and spans over multiple zones, such as a static IP address.
• Global resource: This is a location-independent resource, such as a virtual machine instance image.

Choosing a region and a zone where your resources should be deployed, as well as where data should be stored, is an especially important design task. There are several reasons you should consider this:

• High availability: Distributing your resources across multiple zones and regions will help mitigate outages. Google has designed zones to minimize the risk of correlated failures caused by power, cooling, or networking outages. In the case of a zone outage, it is very easy to migrate to another zone to keep your service running. Similarly, you can mitigate the impact of a region outage by running backup services in another region, as well as using load balancing services.
• Decreased network latency: When latency is a crucial topic in your application, it is very important to choose the zone or region closest to your point of service. For example, if the end users of a service are located mostly in the west part of Europe, your service should be placed in that region or zone.

At the time of writing, there are 24 available regions and 73 zones. Recently, Google announced that five new regions will be available soon in Warsaw (Poland), Melbourne (Australia), Toronto (Canada), Delhi (India), and Doha (Qatar). The full list of available regions can be queried from Cloud Shell, as shown in the following screenshot. Cloud Shell is a ready-to-use command-line interface that's available in GCP that allows the user to interact with all GCP products:

Figure 1.5 – GCP region list from Cloud Shell

The full list of available zones can also be queried from Cloud Shell, which is available in GCP, as shown in the following screenshot:

Figure 1.6 – GCP zone list from Cloud Shell

Each zone supports several types of CPU platforms between Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake, or Cascade Lake. This is an important aspect to know when you decide to deploy your virtual machine instance in one particular zone. You need to make sure that the zone you choose supports the instance that you are willing to deploy. To find out what CPU platform one zone supports, you can use Cloud Shell, as shown in the following screenshot:

Figure 1.7 – GCP CPU platform list from Cloud Shell

When selecting zones, keep the following tips in mind:

• Communication within and across regions will have different costs: Generally, communication within regions will always be cheaper and faster than communication across different regions.
• Apply multi-zone redundancy to critical systems: To mitigate the effects of unexpected failure on your instances, you should duplicate critical assets in multiple zones and regions.

Now, let's look at projects, billing, and quotas.

Projects, billing, and quotas

When cloud users request a resource or service in GCP, they need to have a project to track resources and quota usage. GCP projects are the basis for enabling and using GCP services. Inside a GCP project, users must enable billing to monitor, maintain, and address the costs of the GCP services running on the project itself.

Moreover, projects are separate compartments, and they are isolated from each other. GCP resources belong to exactly one project and they cannot be shared across projects, except for shared VPC networks, which can be shared with other projects. In addition, GCP projects can have different owners and users with several rights, such as project editor or project viewer. They are managed hierarchically using the Google Cloud resource manager, which will be described shortly.

GCP projects have three identifying attributes that uniquely distinguish them globally. These are as follows:

• Project ID: This is a permanent, unchangeable identifier that is unique across GCP globally. GCP generates one at project creation time but you can choose your unique ID if needed. The project ID is a human-readable string that can be used as a seed for uniquely naming other GCP resources, such as Google Cloud Storage bucket names.
• Project name: This is a nickname that you can assign to your project for your convenience. It does not need to be unique, and it can be changed over time.
• Project number: This is a permanent, unchangeable number that is unique across GCP globally. This number is generated by GCP and it cannot be chosen.

Projects can belong to a GCP organization for business scenarios, or they can exist without an organization. This happens when we have an individual private project. However, you can always migrate to a private project inside a GCP organization.

Projects must belong to a billing account, which is used as a reference for paying for Google Cloud resources. This billing account is linked to a payment profile, which contains payments methods that costs are charged for. As shown in the following diagram, one billing account can have multiple projects assigned:

Figure 1.8 – GCP billing and payment profile relation

The cloud billing account is responsible for tracking all the costs that are incurred using the GCP resources for all the projects attached to it. In practice, cloud billing has the following key features:

• Cost reporting: This can monitor, share, and print monthly costs and keep track of the cost trends of your resource spending, as shown in the following screenshot:

Figure 1.9 – Cost reporting in GCP

• Cost breakdown: This shows how many discounts your base usage cost will benefit from in a month. This is shown as a waterfall chart, starting from the base cost and subtracting discounts progressively until you see the final costs, as shown here:

Figure 1.10 – Cost breakdown in GCP

• Budget and alerts: This is very important for setting budgets for your projects to avoid surprises at the end of the month. Here, you can decide the upper limit for a monthly expense and generate alerts for billing administrators to control costs once the trigger is reached. The following screenshot shows an example of a budget of 100 euros with the actual monthly expenses and three thresholds that trigger emails:

Figure 1.11 – Budgets and alerts in GCP

Resources in projects can be limited with quotas. Google Cloud uses two categories of quotas:

• Rate quotas: This limits a certain number of API requests to a GCP resource within a time interval, such as a minute or a day, after which the resource is not available.
• Allocation quotas: This limits the number of GCP resources that are available to the project at any given time. If this limit is reached, the resource must be released so that you can request a new one.

Projects can have different quotas for the same services. This may depend on various aspects; for example, the quota administrator may reduce the quota for certain resources to equalize the number of services among all projects in one organization.

To find out what the quota is for the service you want to use in GCP, you can search for it on the Cloud IAM Quotas page. Here are all the quotas assigned to your project and you can request different quota sizes if needed. As shown in the following screenshot, you can display the actual usage of CPU quotas in all project regions:

Figure 1.12 – CPU quotas in the GCP project

In this section, you learned about the physical architecture of GCP. However, to start using it, you must understand how Google architects the resources that are available to users. This will be described in the next section.