The Cloud Dictionary of Pain: Five Of Google Cloud’s Toughest Topics

Hello! Welcome to Cloud 101. Please take your seats and check to ensure your seatbelt is securely fastened.

Google Cloud sits alongside Azure and AWS as one of the top platforms for cloud computing. And rightfully so—Google built a lot of the modern internet to begin with! It even has its own custom technology baked into its infrastructure, such as the Tensor Processing Unit (or TPU). So while there may be differences between clouds, like AWS and Azure, there are a lot of unique things about GCP that might make it a great option for your work.

But, like all clouds, there’s a whole lot going on and a lot of services to choose from. And those individual services all have specific nomenclature that goes with them. Some of it’s intuitive, some of it can be a little confusing. But beyond knowing how they work, you have to know what they’re called in the first place.

At ACG, we want to teach the world to cloud. And that means making sure everyone on your team can “speak cloud” in the first place—and understanding some of the basic challenges you’ll face when implementing cloud tools. We’re here to help you achieve that baseline cloud fluency with your team. To do that, we’ve built a cloud dictionary of some of the most challenging topics you’ll run into it. Given the difficulty here, we’ve decided to name this the Cloud Dictionary of Pain.

Get the Cloud Dictionary of Pain

Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.

We analyzed 2.7 million responses to thousands of quiz questions on our platforms to identify some of the most challenging cloud infrastructure topics. We looked for questions where learners fell below a 60% success rate and, based on the topics in those questions, have outlined more than a dozen challenging topics that learners can, at times, struggle to decrypt—at least in some specific scenarios.

Today we’ll be covering Cloud Identity and Access Management, Google Cloud Run and Cloud Functions, Instance Groups, Snapshots, and VPC Networks and Subnets.  This list is a subset of dozens of terms and topics we attacked across all three major cloud platforms: AWS, Microsoft Azure, and Google Cloud. You can find our complete walkthrough to Google Cloud's thorny topics in the full Cloud Dictionary of Pain. 

With all that out of the way, let’s get started!

Identity and Access Management (or IAM) is your frontline defense for your cloud services. Security will be at the top of mind for basically everyone running a cloud operation—and it should be on top of mind for you as well. Google manages permissions and identity and access management with Cloud IAM and Cloud Identity. 

Cloud IAM is a unified resource access management system for both users and services. Identities can come in many forms, such as Google accounts, unmanaged accounts, service accounts, and collections of these items—such as Google Groups and G-Suite domains. 

There are three critical elements to IAM. 

• POLICIES: A set of rules that governs who can do one or more tasks with specific resources. We can decide who can do what on which resources. 

• ROLES: A collection of permissions assigned to identities or members. 

• RESOURCES: Made up, well, your resources. It can be your projects, folders, cloud services, or parts of those services like instances or buckets.

Google refers to Cloud Identity as a nice alphabet soup acronym dubbed “identity as a service” (or IDaaS). Cloud Identity started with G-Suite with a separate administrative portal but now integrates with Google Cloud. One of its main benefits is it can securely allow people outside your organization access to specific resources within your organization. It also enables single sign-on (or SSO).

Lots of abstraction! Cloud Identity creates what Google calls “folders” for one or more Google Cloud Projects. You might have a folder for your developer team and your live team. You can apply policies to your folders, where all resources within the projects in those folders inherit permissions from those policies. On top of all this, IAM can quickly become one of your points of failure in managing security. 

The scope of your IAM policies represents a large part of the surface area for Bad Things To Happen. You might misconfigure the permissions you’re giving a third party for your resources or set policies too broad. Or you might just lose the password altogether. Setting specific, robust IAM policies is one of the best ways to protect your cloud operations from breaches and bad actors.

A Cloud Guru learners missed tough questions related to identity and access management 50.5% of the time.

Looking to learn or level up your IAM skills? ACG offers cloud courses and hands on labs that will help you explore Identity and Access Management in depth on Google Cloud Platform.

App Engine isn’t Google’s only serverless product. Google also has three others: Cloud Functions, Cloud Run, and Cloud Run for Anthos. Cloud Run operates on event-driven code. Instead of App Engine, something has to trigger them. You can think of Cloud Functions as the glue between the various services, whether they’re on Google Cloud or third party. It scales automatically and is extremely low cost— Google bills you for execution time to the nearest 100 ms. 

You can use Cloud Run for containerized apps, like those found in Google Kubernetes Engine. Cloud Run also scales on-demand and is suitable for continuous integration/continuous delivery. Unlike App Engine, use can use any language, library, or binary—even something completely custom. There’s also Cloud Run for Anthos, which enables hybrid multi-cloud apps. Cloud Run for Anthos runs on Google Kubernetes Engine. You can use custom domains, integrated logging, and monitoring services.

There are a lot of serverless services from Google Cloud! And each is best for different scenarios (including App Engine, which we reviewed earlier). Let’s review really quickly:

• APP ENGINE: HTTP applications, such as modern web applications, to host front-end, back-end, or both. 

• CLOUD FUNCTIONS: Event-driven code, like third-party apps and API integrations, such as Twilio and Stripe. It also works well with IoT products for real-time processing, data collection, and processing. And it integrates with a large number of services in Google Cloud, making it work well for real-time processing.

•  CLOUD RUN: Container-based operations, including mature technology stacks. It’s useful for internal company-only applications in addition to regular robust websites. You could also use it to, for example, create invoices monthly created by a cloud scheduler task. 

• CLOUD RUN FOR ANTHOS: Good for enterprise-grade CI/CD pipelines so you can continuously build new content. It’s suitable for integrating on-premise services, executing your applications closest to customers (or “at the edge”). 

Your operation may work best with one, or multiple, or none whatsoever. So you’ll have to determine the best approach to take when choosing whether to go serverless.

A Cloud Guru learners missed tough questions related to serverless operations 48% of the time.

Looking to learn or level up your cloud run skills? Check A Cloud Gurus many courses and hands on labs, including ones for Cloud Run, Google's fully managed serverless platform.

Things might start to get a little out of hand once you start spinning up dozens, or hundreds, of Google Compute Engine instances. You can get around the complexity here by batching together instances into groups—buckets of instances where you can try to make changes to a bunch of them all at once. There are two types of instanced groups that Google offers. 

• UNMANAGED GROUPS: collections of instances with different configurations, which you can use to apply load balancing to existing configurations. 

• MANAGED GROUPS: collections of instances that are identical that you can manage as a single unit. If you need to make changes to all of them at once, it’ll make more sense to run it as an instance group. If there are health problems, the managed instance group will automatically recreate that instance.

There are advantages and disadvantages to both. If you want the benefits of managed groups, you’ll have to ensure that all the instances are identical. And you’ll probably run into plenty of scenarios where you’re running multiple identical instances! That makes it friendly and convenient when you want to handle auto-scaling and health checks for your instances. 

But you might frequently run into scenarios where you’ll use unmanaged instance groups. They’re not uniform, so you won’t get some of the features of managed groups. You don’t get auto-scaling or update support if you’re running an unmanaged instance group. But you can still enable some batch processes, so you’ll want to group them anyway.

A Cloud Guru learners missed tough questions related to instance groups 46.5% of the time.

The primary backup method in which a compute engine takes a snapshot of an instance or attached disk, creating a backup of that disk. You can take that snapshot in any disaster recovery situation and create a new instance or disk. You can create a Google snapshot while an instance is running. You can create a restored snapshot or instance in a completely different zone, and you can create a snapshot from a boot disk or an attached disk.

Snapshots operate as incremental backups, which can save you a fair bit of money. A snapshot does not create a new backup of a disk. Instead, it’s an incremental backup: the second snapshot copies the changes from the first, the third from the second, and so forth. You generally want to reduce activity whenever you can. 

You can create a snapshot when an instance runs, but you want to make sure your disk is consistent and isn’t changing too much while the snapshot is in process. You might want to pause operations that write data or unmount the disk completely. You also probably want to schedule a snapshot when there isn’t a log of data changing or if there isn’t a log going on with your application.

A Cloud Guru learners missed tough questions related to Snapshots 50% of the time.

The GCP VPC (say that five times fast) is a virtualized network that provides ipv4 connectivity for GCP resources, such as infrastructure as a service and Google Kubernetes Engine. It’s the central foundational component of all other networking functions. VPCs create a virtualized global network instance to consume resources in all GCP locations. It’s an implemented software-defined private network on Google Cloud—which means no routers, switches, servers, and tripping over tangled cables. 

This allows you to customize and scale your services rapidly, and all communication between resources within that network has no exposure to the public internet. The VPC relies on the Google Global Network for connectivity, divided into GCP regions—or data center locations in various geographic locations. 

Google also offers premium and standard networking tiers in the VPC. GCP also requires an IP range assigned in a specific region (called a subnet). Regions can also speak to one another via Routes that allow communication between those networks. Google Cloud assigns all this infrastructure based on availability zones. A Google Project can contain one or more VPC networks, creating configurations within each region. 

In a VPC, you can consume resources in all regions by creating a subnet within one region. Subnets use the Google global network, building subnets within a zone. We use the VPC to assign a subnet to one, multiple, or all regions. Each IP range provides IP connectivity for our infrastructure in those data centers. And unlike other cloud providers, subnets can span multiple availability zones within a region.

While VPCs exist within projects, projects separate users—while VPCs separate systems. You can use shared VPCs that allow you to connect multiple projects to a single VPC network, making it possible for them to communicate with one another. 

Let’s say you have multiple GCE instances in the same project but across numerous VPCs. The resources in one VPC cannot communicate with the resources in another VPC without VPC network peering. However, resources within one VPC can communicate over a private network within multiple regions. There are also two tiers of networking: premium and standard.

Here are some of the differences: 

• PREMIUM-TIER DATA: goes through Google’s network, with the user’s traffic entering Google’s network at the nearest location and exiting at the global edge. This is sometimes referred to as “cold potato” traffic. 

• STANDARD-TIER TRAFFIC: goes through Google’s network through peering, ISP, or transit networks in the region where you’ve deployed GCP resources. This is sometimes referred to as “hot potato” traffic.

A Cloud Guru learners missed tough questions related to GCP VPCs 42.2% of the time. 

We hope after going through these examples, you’re getting a taste of just how hairy the cloud can be. It has its own custom dictionary to go along with its sprawling urban environment of products.

We can empathize how complicated the cloud can be and hope we can provide some guidance. Then again, we didn’t write down the rules. (Well, we wrote the questions—we are genuinely sorry about that.)

You can find our full walkthrough to Google's thorny topics in the full Cloud Dictionary of Pain. You can also find their equivalents—and what makes AWS and Azure uniquely tortuous—in our AWS and Azure Dictionary of Pain. You will also find our full methodology.