In this course, you will get an overview of the GCP services available in various categories, such as compute, storage, and networking, and you will also see hands-on examples showing you how to create virtual machines and web apps using the Google Cloud Console and gcloud command-line interface.
- Describe some of the GCP services available in various categories
- Use the Google Cloud Console
- Use the gcloud command-line interface
- Anyone who would like to learn more about Google Cloud Platform
- General technical knowledge
- A Google Cloud Platform account is recommended (sign up for a free trial at https://cloud.google.com/free/ if you don’t have an account)
The GitHub repository for this course is at https://github.com/cloudacademy/gcp-overview.
So what is Google Cloud Platform? It’s a collection of online services that organizations can use to build, host, and deliver applications. The best part is that GCP runs in Google’s data centers, so you can take advantage of Google’s global network and vast experience with serving applications to billions of people around the world.
Not only does this approach save you the trouble of having to build and maintain your own on-premises IT infrastructure, but it can also save you money because you only have to pay for what you use, and you can scale your GCP resources up and down as needed.
For most applications, you need three core elements: compute, storage, and networking. Let’s start with compute. One of the most common ways to run applications on GCP is to use virtual machines, or VMs for short. These are machines that run either Linux or Windows. Google’s service for running VMs is called Compute Engine. If you currently have an application running on a Windows or Linux server, then the most straightforward way to migrate it to GCP is to do what’s called a “lift and shift” migration. That is, you simply lift the application from your on-premises server and shift it to a virtual server in the cloud. Compute Engine is known as Infrastructure-as-a-Service because it runs traditional IT infrastructure components that are offered as a service.
Google also has what’s known as a Platform-as-a-Service offering called App Engine. This platform lets you host web and mobile applications without having to worry about the underlying infrastructure. After creating an App Engine app, you can just upload your code to it and let GCP take care of the details. It even scales the underlying resources up and down automatically. For example, if your app isn’t getting any traffic, App Engine will scale the number of underlying VMs down to zero, and you won’t get charged until your app starts getting traffic again.
In most cases, using App Engine is a better solution than using virtual machines, but there are times when it makes more sense to use VMs. For example, if you have an application that’s not a web or mobile app, then you can’t use App Engine, so you’ll have to use a VM.
These days, the hottest compute technology is containers. These are self-contained software environments. For example, a container might include a complete application plus all of the third-party packages it needs. Containers are somewhat like virtual machines except they don’t include the operating system. This makes it easy to deploy them because they’re very lightweight compared to virtual machines. In fact, containers run on virtual machines.
Google provides a variety of ways to run containers. The simplest way is to use Cloud Run. This service lets you run a container using a single command. If you have a more complex application that involves multiple containers, then you’ll probably want to use Google Kubernetes Engine (or GKE for short), which is a container orchestrator. It makes it easy to deploy and manage multi-container applications.
Another hot area is known as “serverless”. The term “serverless” is a bit misleading because it still involves servers. It just means that you don’t have to know anything about the underlying servers that run your code. That sounds like App Engine, doesn’t it? Yes, App Engine can be considered serverless. The same goes for Cloud Run. But the GCP service that’s most associated with the term “serverless” is Cloud Functions.
While App Engine and Cloud Run are typically used to deploy applications, Cloud Functions is used to deploy individual functions. Cloud Functions is event-driven, which means the function gets executed when a particular event occurs. For example, you could configure a function to be triggered whenever a new file is uploaded to a particular storage location.
Speaking of storage, let’s move on to GCP’s storage options. The simplest one is called Cloud Storage. It’s referred to as object storage, but really it’s just a collection of files. It’s not like a normal filesystem, though, because it doesn’t have a hierarchical folder structure. It has a flat structure. It’s typically used for unstructured data, such as images, videos, and log files.
One of the great things about it is that it has multiple storage classes: Standard, Nearline, Coldline, and Archive. Standard is for frequently accessed files. Nearline is for files you expect to access only about once a month or less. The advantage is that it costs less than Standard as long as you don’t access it frequently. Coldline is for files you expect to access at most once every three months. Archive is for files you expect to access less than once a year. It has the lowest cost.
All four storage classes give you immediate access to your files. This is different from some other cloud providers where the lowest cost storage can take hours to access.
If you need a more traditional file storage option with a hierarchical structure, you can use Filestore. It lets you create NFS-compatible file shares that can be mounted on your virtual machines or containers.
Now let’s look at databases. If you’re currently using MySQL, PostgreSQL, or Microsoft SQL Server, then Cloud SQL is your best bet. It’s a fully-managed service for each of those three database systems. These are all relational databases that are suitable for online transaction processing.
The problem with relational databases is that it’s very difficult to scale them to handle high-volume, high-speed data. In contrast, NoSQL databases can easily scale to handle massive amounts of data. The downside is that most NoSQL databases are designed for much simpler use cases than relational databases, such as storing key/value pairs.
Google offers many NoSQL databases, including Bigtable, Firestore, Firebase Realtime Database, and Memorystore. Bigtable is best for running large analytical workloads. Firestore is ideal for building client-side mobile and web applications. Firebase Realtime Database is best for syncing data between users in real time, such as for collaboration apps. Memorystore is an in-memory datastore that’s typically used to speed up applications by caching frequently requested data.
Cloud Spanner is a unique database because it seems to combine the best of both worlds. It’s a relational database that’s massively scalable. So why wouldn’t you use it for all of your database needs? Well, mostly because it’s more expensive than the other options. Also, if your application is written specifically for a particular database, such as SQL Server, then Cloud SQL would be a better choice, unless you can rewrite it to work with Cloud Spanner.
If you need a data warehouse, then BigQuery is the right solution. It’s something you use after data is collected, rather than being a transactional system. It’s best suited to aggregating data from many sources and letting you search it using SQL queries. In other words, it’s good for OLAP (that is, Online Analytical Processing) and business intelligence reporting.
That’s a lot of storage and database options. Now let’s move on to networking. When you create a virtual machine on GCP, you have to put it in a Virtual Private Cloud, or VPC. A VPC is very similar to an on-premises network. Each virtual machine in a VPC gets an IP address, and it can communicate with other VMs in the same VPC. You can also divide a VPC into subnets and define routes to specify how traffic should flow between them.
By default, all outbound traffic from a VM to the Internet is allowed. If you also want to allow inbound traffic, then you need to assign an external IP address to the VM.
If you want VMs in one VPC to be able to communicate with VMs in another VPC, then you can connect the VPCs together using VPC Network Peering.
If you want to create a secure connection between a VPC and an on-premises network, then you can use Cloud VPN, which stands for Virtual Private Network, Cloud Interconnect, or Peering. A VPN sends encrypted traffic over the public Internet, whereas Cloud Interconnect and Peering communicate over a private, dedicated connection between your site and Google’s network. Cloud Interconnect is much more expensive than a VPN, but it provides higher speed and reliability since it’s a dedicated connection. Peering is free, but it’s not well-integrated with GCP, so you should usually use Cloud Interconnect instead.
There are plenty of other network services available as well, but the ones I’ve covered are enough to give you a good high-level understanding of GCP networking.
Google also provides a wide variety of other services outside of the core compute, storage, and networking categories, such as in hot areas like artificial intelligence and DevOps. I’ll go over some of those later.
The easiest way to understand how GCP works is to actually use it, so in the next lesson, we’ll create a virtual machine. If you’re ready, then go to the next video.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).