Google Cloud Platform Overview

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 resources

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
contained in
Google's data centers
around the globe.
Each data center location is in a region. Regions are available in
Asia, Australia, Europe, North America, and South America.
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,
zone a in the East Asia region is named asia-east1-a.

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.

Projects

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. A project can't access another project's resources
unless you use Shared VPC or
VPC Network Peering.

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

Google Cloud gives you three basic ways to interact with the services and
resources.

Google Cloud Console

The Google Cloud Console
provides a web-based, graphical user interface that you can use to manage your
GCP projects and resources. When you use the Cloud 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.

Command-line interface

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
to manage
both your development workflow and your GCP resources. See the gcloud
reference for the complete list of available
commands.

Built-in authorization for access to GCP Console projects and resources.

Client libraries

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.

Pricing

To browse pricing details for individual services, see the
price list.

To estimate your total costs for running a specific workload on GCP, see the
pricing calculator.