This overview is designed to help you understand the overall landscape of Google Cloud Platform (GCP). Here, you'll take a brief look at some of the commonly used features and get pointers to documentation that can help you go deeper. Knowing what's available and how the parts work together can help you make decisions about how to proceed. You'll also get pointers to some tutorials that you can use to try out GCP in various scenarios.
GCP consists of a set of physical assets, such as computers and hard
disk drives, and virtual resources, such as virtual machines (VMs), that are
Google's data centers
around the globe.
Each data center location is in a global region. Regions include Central US,
Western Europe, and East Asia. Each region is a collection of zones, which
are isolated from each other within the region. Each zone is identified by a
name that combines a letter identifier with the name of the region. For example,
a in the East Asia region is named
This distribution of resources provides several benefits, including redundancy in case of failure and reduced latency by locating resources closer to clients. This distribution also introduces some rules about how resources can be used together.
Accessing resources through services
In cloud computing, what you might be used to thinking of as software and hardware products, become services. These services provide access to the underlying resources. The list of available GCP services is long, and it keeps growing. When you develop your website or application on GCP, you mix and match these services into combinations that provide the infrastructure you need, and then add your code to enable the scenarios you want to build.
Global, regional, and zonal resources
Some resources can be accessed by any other resource, across regions and zones. These global resources include preconfigured disk images, disk snapshots, and networks. Some resources can be accessed only by resources that are located in the same region. These regional resources include static external IP addresses. Other resources can be accessed only by resources that are located in the same zone. These zonal resources include VM instances, their types, and disks.
The following diagram shows the relationship between global scope, regions and zones, and some of their resources:
The scope of an operation varies depending on what kind of resources you're working with. For example, creating a network is a global operation because a network is a global resource, while reserving an IP address is a regional operation because the address is a regional resource.
As you start to optimize your GCP applications, it's important to understand how these regions and zones interact. For example, even if you could, you wouldn't want to attach a disk in one region to a computer in a different region because the latency you'd introduce would make for very poor performance. Thankfully, GCP won't let you do that; disks can only be attached to computers in the same zone.
Depending on the level of self-management required for the computing and hosting service you choose, you might or might not need to think about how and where resources are allocated.
For more information about the geographical distribution of GCP, see Geography and Regions.
Any GCP resources that you allocate and use must belong to a project. You can think of a project as the organizing entity for what you're building. A project is made up of the settings, permissions, and other metadata that describe your applications. Resources within a single project can work together easily, for example by communicating through an internal network, subject to the regions-and-zones rules. The resources that each project contains remain separate across project boundaries; you can only interconnect them through an external network connection.
Each GCP project has:
- A project name, which you provide.
- A project ID, which you can provide or GCP can provide for you.
- A project number, which GCP provides.
As you work with GCP, you'll use these identifiers in certain command lines and API calls. The following screenshot shows a project name, its ID, and number:
In this example:
- Example Project is the project name.
- example-id is the project ID.
- 123456789012 is the project number.
Each project ID is unique across GCP. Once you have created a project, you can delete the project but its ID can never be used again.
When billing is enabled, each project is associated with one billing account. Multiple projects can have their resource usage billed to the same account.
A project serves as a namespace. This means every resource within each project must have a unique name, but you can usually reuse resource names if they are in separate projects. Some resource names must be globally unique. Refer to the documentation for the resource for details.
Ways to interact with the services
GCP gives you three basic ways to interact with the services and resources.
Google Cloud Platform Console
The Google Cloud Platform Console provides a web-based, graphical user interface that you can use to manage your GCP projects and resources. When you use the GCP Console, you create a new project, or choose an existing project, and use the resources that you create in the context of that project. You can create multiple projects, so you can use projects to separate your work in whatever way makes sense for you. For example, you might start a new project if you want to make sure only certain team members can access the resources in that project, while all team members can continue to access resources in another project.
If you prefer to work in a terminal window, the
Google Cloud SDK provides the
gcloud command-line tool,
which gives you access to the commands you need. The
gcloud tool can be used
both your development workflow and your GCP resources. See the gcloud
reference for the complete list of available
- A temporary Compute Engine virtual machine instance.
- Command-line access to the instance from a web browser.
- A built-in code editor.
- 5 GB of persistent disk storage.
- Pre-installed Google Cloud SDK and other tools.
- Language support for Java, Go, Python, Node.js, PHP, Ruby and .NET.
- Web preview functionality.
- Built-in authorization for access to GCP Console projects and resources.
The Cloud SDK includes client libraries that enable you to easily create and manage resources. GCP client libraries expose APIs for two main purposes:
App APIs provide access to services. App APIs are optimized for supported languages, such as Node.js and Python. The libraries are designed around service metaphors, so you can work with the services more naturally and write less boilerplate code. The libraries also provide helpers for authentication and authorization.
Admin APIs offer functionality for resource management. For example, you can use admin APIs if you want to build your own automated tools.
You also can use the Google API client libraries to access APIs for products such as Google Maps, Google Drive, and YouTube.
You can also take advantage of some tools to help you evaluate the costs of using GCP.
The pricing calculator provides a quick and easy way to estimate what your GCP usage will look like. You can provide details about the services you want to use, such as the number of Compute Engine instances, persistent disks and their sizes, and so on, and then see a pricing estimate.
The total cost of ownership (TCO) tool evaluates the relative costs for running your compute load in the cloud, and provides a financial estimate. The tool provides several inputs for cost modeling, which you can adjust, and then compares estimated costs on GCP and AWS. This tool does not model all components of a typical application, such as storage and networking.