The course is part of these learning pathsSee 4 more
Google Cloud Platform: Fundamentals
If you’re going to work with modern software systems, then you can escape learning about cloud technologies. And that’s a rather broad umbrella. Across the three major cloud platform providers, we have a lot of different service options, and there’s a lot of value in them all.
However, the area that I think Google Cloud Platform excels in is providing elastic fully managed services. Google Cloud Platform to me, is the optimal cloud platform for developers. It provides so many services for building out highly available - highly scalable web applications and mobile back-ends.
For me personally, Google Cloud Platform has quickly become my personal favorite cloud platform. Now, opinions are subject, but I’ll share why I like it so much.
I’ve worked as a developer for years, and for much of that time, I was responsible for getting my code into production environments and keeping it running. I worked on a lot of smaller teams where there were no operations engineers.
So, here’s what I like about the Google Cloud Platform, it allows me to think about the code and the features I need to develop, without worrying about the operations side because many of the service offerings are fully managed.
So things such as App Engine allow me to write my code, test it locally, run it through the CI/CD pipeline, and then deploy it. And once it’s deployed, for the most part, unless I’ve introduced some software bug, I don’t have to think about it. Google’s engineers keep it up-and-running, and highly available. And having Google as your ops team is really cool!
Another thing I really like about is the ease of use of things such as BigQuery and their Machine Learning APIs. If you’ve ever worked with large datasets, you know that some queries take forever to run. BigQuery can query massive datasets in just seconds. Which allows me to get the data I need quickly, so I can move on to other things.
And with the machine learning APIs, I can use a REST interface to do things like language translation, or speech to text, with ease. And that allows me the ability to integrate this into my applications, which gives the end-users a better user experience.
So for me personally, I love that I can focus on building out applications and spend my time adding value to the end-users.
If you’re looking to learn the fundamentals about a platform that’s not only developer-friendly but cost-friendly, then this is the right course for you!
By the end of this course, you'll know:
- The purpose and value of each product and service
- How to choose an appropriate deployment environment
- How to deploy an application to App Engine, Kubernetes Engine, and Compute Engine
- The different storage options
- The value of Cloud Firestore
- How to get started with BigQuery
This is an intermediate-level course because it assumes:
- You have at least a basic understanding of the cloud
- You’re at least familiar with building and deploying code
- Anyone who would like to learn how to use Google Cloud Platform
Welcome back to Google Cloud Platform: Fundamentals. I'm Ben Lambert, and I'll be your instructor for this lesson. In this lesson, we're going to talk about Cloud Platform projects, Identity and Access Management, and interacting with the Google Cloud Platform. Let's start with projects. All the Cloud Platform resources belong to a project.
Projects are the basis for enabling and using services, including managing APIs, enabling billing, adding and removing collaborators, and enabling other Google services. Each project is kind of its own thing, consider it like a box. Each box can have its own services and resources inside. Projects are billed and managed separately.
Now this is something I really like because we're able to use the concept of a project to break things down by their purpose. For example, you could have a project that is for your production web application, and then you could create another project that serves as a playground for developers. That would allow them to try out new things without worrying about making changes that would impact your production application. Because they're in completely separate projects.
Or you could break things down into separate projects such as development, test, and production. Allowing you to use these different environments at different points in your continuous integration and continuous delivery process. Projects have three different types of identifiers. They have the project name, the project number, and the project ID.
The name is something that you can set. It's basically a user friendly identifier for your project. And it should allow you to recognize at a glance, what that project is. The project number is something automatically generated for you by Google. And it can't be changed. And the project ID is something that you can initially set, but, once it's set, you can't change it.
These IDs have a globally unique scope, which means if I create one with a value of my-awesome-ID, then you won't be able to use that for yours. And if you created it first, I couldn't use it for mine. You can find these identifiers in the console under the IAM & Admin section, and then under the Settings option.
You can interact with projects in two ways. One is through the Cloud Console, which is the web user interface we saw in our last lesson. After we created and logged into our account. And the other is through the Google Cloud Resource Manager API.
It allows you to get a list of all projects associated with and account, create new projects, update existing projects, delete projects, and even undelete or recover projects that you don't want to delete.
Okay, now let's actually create a project so that you can see the entire process. And in the end, we'll delete it, so you can see that process too.
I'm here on the Google Cloud dashboard, and to create a project, or to even change a project, you can click on this project selection dropdown. So clicking on the dropdown, I can select New Project, and it's going to open up this form here, where we can set our project details. Clicking the edit link for this project ID will show us the ID, so we can change it here. Cause remember, if we don't change it now, we will never be able to change it. So if it's important for you to change that ID, you'll want to do it when you create the project.
Okay, I'm gonna copy this and paste it into the ID field. And clicking off is gonna cause it to check the ID. Notice this ID isn't available. Again, project IDs have to be globally unique. So if you can't think of one, or setting and ID isn't important, just let Google take care of that for you. This location field here, we can actually set an organization and I don't have any. However, you may in your setups. Let's create this by clicking Create.
Once this form loads, we'll be able to switch over to our newly created project and actually start creating resources inside of it. Okay, so here it is. If I click on the project dropdown again and click on the project we just created, we can now set this as our active project. To look at the settings we can go into the project settings. Which we could also access under the IAM & Settings menu. And this is where we can see the project name. We could edit that if we want to, we can see the project ID and number, which are not editable. And if we click Shutdown at the top, we can actually remove this project. We need to paste in the ID, as a kinda a security check to make sure that we really want to do this. So I'm going to copy this here, and paste it in. Alright, cool, we'll click Shutdown, and this will go about the process of actually shutting down this project. Alright, so that's project creation at a high level.
Now, once you have a project, you want engineers on your team to actually be able to interact with the different resources in that project. So for that, we need to be able to set them up with permissions. And for that, we have two forms of rules. Primitive roles and predefined roles.
Primitive roles, as the name suggests, are the original roles. Predefined roles are the newer, more granular roles. There are three primitive roles and they're concentric. Meaning that the less permissive roles are included in the more permissive roles. Starting with the least permissive, the viewer role, can view aspects of a project. The Editor role, which includes the viewer role, can perform actions that change the project's state. This includes things such as, configuring services and deploying applications. The Primitive Role with the most permissions is the Owner Role, which includes the Editor and Viewer, and it has the ability to invite members and remove members, as well as delete a project.
Now, what if you need finer grain control over your resources that the Primitive roles provide? Well, that's where identity and access management predefined roles come into play. Identity and access management is usually abbreviated as IAM. And it's used to determine who can do what, to which resource.
In Cloud IAM, you grant access to the following types of identities, we have Google accounts, service accounts, Google groups, and Google app domains. Let's go through these. A Google account is a developer, administrator or any person who use the Google Cloud platform. A service account is an account that belongs to your application, instead of an individual user.
It allows you to specify the account that your code runs as. This lets your applications interact with Google Cloud services, such as Cloud Storage and BigQuery, without the need to provide credentials in your code. You can create as many service accounts as you need in order to represent the different logical components of your applications.
A Google Group is a named collection of Google accounts and service accounts. Every group has a unique email address associated with the group, that you can find on the Home page of the group, by clicking the About link. Groups will allow you to apply policies to multiple users so that you can change the access controls for a group of users, all at the same time.
And next, we have Google App Domain. Google App Domain represents a virtual group of all the members in your organization. So if you use Google Apps, you can associate your email account with your domain, which allows you to use an email address from your own domain, rather than the Gmail domain, while using Gmail under the hood.
So you can specify an identity by using any domain that is associate with a Google Apps account. We said previously that IAM is about who can do what, to which resource. So these identities that we just talked about are the "who" portion of that. And roles and permissions are the "can do what" portion. And that makes resources the "to which resource" portion.
Resources are things such as projects, virtual machines instances, Cloud Storage, etcetera. Permissions determine what operations are allowed on a given resource. For Cloud IAM, permissions are represented in the form of <service>.<resource>.<verb>, an example of this would be something like pubsub.subscriptions.consume, where pubsub is the service, subscriptions is the resource, and consume is the verb.
So if you wanted to call a particular method, then you'll need permissions for that method. Here's another example, if you wanted to call the publish method of the pubsub service, you would need pubsub.topics.publish permissions. So permissions allow you to determine what operations are allowed on a resource. However, you can't assign permissions to a user directly.
Permissions are assigned to roles. So a role is just a collection of permissions. When you grant a role to a user, you grant them all of the permissions that role contains. So that's Identity and Access Management, at a very high level. Next, let's talk about interacting with the Cloud platform. We talked about the console a bit throughout the lesson.
It's the user interface that we interact with Google Cloud platform with. However, it's not the only method available. There are three ways to interact with the Google Cloud Platform. First is the Cloud console, that's the web interface we've used so far. Then we have the Cloud SDK, which is the software development kit, which can be run either locally or via Cloud Shell. And then we have the REST-based API.
The Cloud console provides you with one centralized user interface to interact with all of your projects. With the ability to access product APIs and create and manage projects. It also has some developer tools loaded, such as the Cloud Shell, which will allow you to interact with the Cloud source code repositories, and the Cloud SDK.
The Cloud SDK provides command-line tools such as gcloud, gsutil, and BigQuery. We'll be using the SDK throughout the course so let's review the different commands that it provides. We have gcloud, which manages authentication, local configuration, developer workflow, and interactions between the Cloud platform APIs.
We have the gsutil command, which is the Google storage utility command. It provides command-line access to manage Cloud Storage buckets and objects. We have the bq command, which is the BigQuery command. It allows you to run queries, manipulate data sets, tables and entities in BigQuery, through the command line.
And finally, we have the kubectl command, which orchestrates the deployment and management of Kubernetes container clusters on gcloud. The SDK is available as a doc or image and via the Cloud Shell. We've mentioned the Cloud Shell a couple of times now, but what exactly is it? Cloud Shell is a browser-based terminal, which means you get command-line access from your browser.
It works by starting up temporary, virtual machine instances running Debian-based versions of Linux. So you'll get five gigabytes of persistent storage, that's attached to your home directory. The Cloud SDK is preloaded along with some other useful tools and programming languages. A feature I really like is the web preview, which allows you to run the development server in the Cloud Shell, and view the results in your browser.
And that's really cool. So having all of this allows you to create and manage Compute Engine instances, create and access Cloud SQL databases, manage Google Cloud storage data, interact with hosted or remote Git repositories, including Cloud source code repositories, and build and deploy Google App engine applications.
And you can also preform other management tasks that are related to projects, resources, etcetera, using gcloud and other commands. And finally, we have the REST APIs. Which give you programmatic access to products and services. The different APIs can be enabled through the console. Each API will have its own daily quotas and rates. And if you need to increase these daily limits, you can contact Google, and have them increase these caps for you.
In order to help out when using APIs, you can use the API explorer. The API Explorer is an interactive tool, that allows you to easily tryout these Google APIs in your browser. So you could execute requests for any of these methods and see the responses in real-time. There are also client libraries that are built around the REST APIs, allowing you to more quickly integrate with your project in the programming language of your choosing. Many of the Google Cloud services provide the raw building blocks for us to create our own applications and processes. However, we're not required to create everything on our own. GCP provides us with a marketplace that we can use to install different applications, let's check it out.
I'm on the dashboard, so I'll start by clicking the menu here, and at the top of the list, notice this marketplace. If you've used Google Cloud in the past, or maybe just checking out the documentation, you might remember this as Cloud Launcher, same product, new branding. So if you notice any references to Cloud Launcher anywhere, just know that it's synonymous with the marketplace.
So you can see on the list here, we have a lot of different solutions. On the left-hand side, we have some filters. The right-hand side contains the results. And we have this search bar at the top. These solutions here are capable of creating and configuring different Google Cloud resources.
One of the cool things with the marketplace, we can actually use this to deploy containers to our Kubernetes Engine clusters. So as an example, imagine you wanna use the Datadog service to monitor your containerized applications. You could actually install the agent as a container on the cluster.
For this demo, let's create a Compute Engine instance with a LAMP stack pre-configured. LAMP stands for Linux, Apache, MySQL, and PHP. So let's search for this. Notice that we have several options here in the list, and we can further filter these down to show just the solutions that are not going to incur additional usage fees. So for this, let's select the one that's provided by Google.
On the left-hand side, we have details about the different GCP resources that this solution is going to use. The center text provides a description and some useful links. And the far right shows a price estimation.
Now clicking this launch button brings us to this form, which is basically a version of the Compute Engine instance creation form. Let's leave all of these default settings and just create this. Behind the scenes, this is going to use the Google Cloud Platform Deployment Manager. So it's going to run through all the steps to create our LAMP environment. And this can take a few moments, so I'm just going to fast forward and I'll see you in a second.
So here it is, it's complete. Notice that we have all of our details on the right-hand side here. And clicking on this link is going to open up the default Apache landing page. And it seams to be working.
So what has this actually shown us? What have we learned from this? The marketplace can make it easier to find and deploy specific solutions. One thing to keep in mind, some of the solutions in the marketplace are going to cost additional revenue. You're not just going to be charged for the resources you used, but some sort of additional rate. Though, as you can tell, the marketplace will make it easier to install different types of solutions, with just a few clicks. Let's summarize what we've covered.
Google Cloud Platform uses the concept of projects for tracking resource usage. Enabling billing, managing permissions, and enabling services and APIs. It uses Identity and Access Management to determine who, can do what, to which resource. And you can interact with the Google Cloud Platform via the web user interface called the Cloud Console, via the Cloud SDK, and the REST API.
Alright, that's going to do it for this lesson. Thank you so very much for watching. I hope this has been helpful and I will see you in the next lesson.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.