Welcome back. In this lesson we're going to be talking about projects. If you completed the Google Cloud platform fundamentals course then this lesson is going to be a bit of a review. However since projects are the starting point for all of our work, it's worth going over again.

Projects are used to create isolated environments. It's used to create different applications or different environments for a single application. As an example, if we had an application called pizza-time then we might have a project for development named dev-pizza-time and another for staging called staging-pizza-time and one for production named production-pizza-time. So, we can enable services and resources that are linked to a specific project and each project is billed separately. Though it can use the same billing account, if we want to.

Once we have a project, we'll need to be able to identify it and we'll have different mechanisms to do that. Projects have three identifiers. We have the name, which is the human friendly identifier. There's the ID, which is kind of the developer's ID. It's the identifier that we used on the command line tools, or passed into any URLs. And then we have the project number. And this is a Google generated number used behind the scenes to identify our projects. Keep in mind some of the automated emails that Google sends out are going to use this number as the project reference.

We can find these different identifiers on the settings tab of the IAM & Admin page. Let's imagine you received an automated email from Google informing you that your project is violating the terms of service and they provide you with the project number. Well, for most of us we don't pay attention to that number. So, if you have a lot of projects then going through each of them to find that can be a pain and this where the G cloud command line tool comes in. You can run the G cloud projects list command to get a listing of all of the projects and it will show the name, ID, and number for each of them. And this is going to make it easier to zero in on the correct project.

Okay now that we can find projects by name, number, or ID, let's move on to talk about project resources. First, what do I mean, when I say resources? In this context, resources are things such as virtual machine images, disk snapshots, networks, and other components that we use to create our infrastructure and applications. And resources have different types depending on where they can be accessed from. Let's list off the different types of resources and then let's go into them each a bit more. We have global resources, regional resources, and zone-based resources.

Just in case you need a quick refresher about regions and zones. A region is a geographic area in the world and regions have zones inside of them. And those zones are basically data centers that are physically inside of that geographic region.

So, starting at the bottom of our list. If a resource belongs to a zone then it lives in just one zone. And it can interact with other zone-based resources that live in that same zone. Some example of zone-based resources are things such as instances and disks. This makes sense when you consider that a single running VM is only running on one server and while it could be moved to another server it runs on one at a time. So, zone-based resources are things that aren't likely to be distributed across multiple servers.

Moving up the list we have regional resources, which are resources that are accessible inside of a given region. As an example, a static external IP address is a regional resource. You can assign it to any instance that's running in the same region. And recall that instances are zone-based meaning zone-based resources can interact with resources that have a broader scope.

And then we move to the top of the list and we have global resources. Global resources are accessible by any resource in any zone within the same project. These global resources are things such as virtual machine images, or persistent disk snapshots. Being global means that we have these resources to use in any zone. So, if we create a custom image then we can use that in any zone that we choose.

Like I mentioned at the beginning, we're going through this stuff again even though we've covered it in the fundamentals course because this is important to understand. Understanding the resource types will help us to make conscious decisions about how we allocate them and where we allocate them. For example, if we're going to use a VM image, which is a global resource, to create a virtual machine instance and we need to choose which zone that instance is going to run in. And depending on the application and architecture that could impact latency for some users. So we need to understand where resources will run and what they'll have access to.

Okay, so we have projects that will serve as an isolated environment for us to enable and use different resources in. And once we start using different resources we need to think about potential quotas and limits that we may run into. Quotas determine the amount of a given resource that we create per project or region. And limits determine things such as, how many requests we can make against a given API in a certain time frame. For the most part the quotas are to protect us from accidentally allocating let's say a million VMs and going broke. Or from those same million VMs causing latency issues for the rest of the Google Cloud Platform customers. Now of course that's an exaggerated example to make a point, however the quotas are there to help us. So, if you need a quota cap increased you can create a support ticket because most of the quotas can be increased.

Let's move on from projects and resources now to talk about how we interact with the Google Cloud Platform as a whole. We have three options. We can use the Cloud Console, the SDK, and the rest API. We can use the Cloud Console, which is the web user interface and it will allow us to do just about everything we need, however some tasks need to be done in code or on the command line. An example of this is, we can look at the different Cloud data store indeces, however we can't create them from the console. We need to upload an index configuration on the command line.

And that leads us to our second way of interacting with the Google Cloud Platform and that's the Cloud SDK. That's a suite of command line tools and that extends to Cloud Shell, which is a Google provided web-based terminal that has the Cloud SDK pre-loaded. It's basically a Debian VM that you can access through you web browser and this is a very cool feature to me. Actually this one saved me a weekend. I was visiting some family and I was a couple hours away from home and I was without my laptop. I got an IM from a coworker letting me know that some of the users for our product were getting an 500 error on the profile page. However, my father-in-law let me use his Mac and I was able to log into the console, launch Cloud Shell, and then use it to pull the latest code from source control. I skimmed through the logs, I noticed the problem, and used nano to fix the issue. And then committed it back to Git. And then from there the CI process kicked off and deployed the code. This resolved the issue for the users thankfully and saved my weekend.

Cloud Shell has Git and several programming languages pre-loaded in addition to the Cloud SDK. So, it also gives us five gigs of persistent storage mounted to our home directory. And that allows us to install any tools that we may need to use. And now there's a new update that Cloud Shell even has a web based code editor. So, that's really cool. Not needing to install a bunch of things locally or for me driving two hours home was just fantastic, so I'm rather partial to Cloud Shell.

The third way to interact with Google Cloud is through the Rest API. Just about all of the functionality of the platform is exposed via Rest API and these different APIs are gaining functionality on a regular basis. Google provides us with a tool as well to test out this functionality and it's the aptly named API Explorer. It's going to give us a simple to use interface for testing things out.

Let's actually check it out. Check out here we have this list of all of the different APIs. So, we scroll through you can see there's quite a bit. And now let's pick something. Let's go with the translate API cause that's a nice one to show as a demo. And we can translate some texts from English to let's say Italian. So if we try translating Hello, and let's just set these variables here. Okay great. Now let's run this. And we scroll down and we can see the output of Ciao. So we can use this to test out all kinds of APIs and I like to use this when I'm learning a new API, to kind of figure out the mechanics of it.

Alright let's wrap up the lesson here. We've covered projects, we talked about resources and how to interact with them, and now these are going to be the basis for all of the things that we're going to do with the Google Cloud Platform from here on out in the following lessons. In our next lesson we're going to talk about Virtual Machine Instances. So, if you're ready to keep learning then let's get started.