Getty Images/iStockphoto
Break down the Google Cloud resource hierarchy
Admins can use Organizations, Folders, Projects and Resources to manage employee access within Google Cloud. But first, they must understand the distinctions between each level.
Project organization is a topic that has plagued engineers for as long as projects have existed. From code-level organization to infrastructure management, getting everything right can be both overwhelming and satisfying. The proliferation of cloud services only exacerbates the challenge.
Despite being one of the most popular cloud providers, Google Cloud's organizational hierarchy can be confusing. Within the hierarchy, admins have Organizations, Folders, Projects and even Resources. On their own, each of these words make sense, but within the larger Google Cloud picture, the lines between them can feel blurry.
To better understand Google Cloud's resource hierarchy, let's break it down into its individual components. Then, we'll explore their uses and how they fit together.
Google Cloud Organizations
Organization is the top-level node in Google Cloud's structure. Every Google Workspace account has only one Organization associated with it. If you think of your Google Cloud account as a computer, the Organization is the hard drive on which all other components are stored.
Google Cloud Folders
Following along with the computer analogy, a single hard drive can contain many folders, just as a single Google Cloud Organization can contain many Folders. Each Folder can also contain its own set of Folders, enabling admins to create multiple layers of organization. Depending on how carefully admins lay things out, this could lead to confusion. Folders are where most of the actual organization is in a Google Workspace. They are a freeform hierarchy, meaning admins can use them in whatever way makes the most sense for their company.
Some businesses segment by region, some by department and others by team. From there, admins can further divide things by use case, environment or even owner. The possibilities are endless, but a general best practice is to map your Folder hierarchy to a real-world analog. If Folders mirror the way a company is structured, it is much easier to find the relevant Projects and Resources.
Google Cloud Projects
Every Google Cloud Folder can have one or more Projects in it. Again, to follow the computer analogy, there may be an executable within a folder on your hard drive that requires certain resources, such as CPU and RAM. Similarly, a Project is a collection of Resources that together make up an application or a service. While there are no hard rules for which Resources admins place into a single Project, a good rule of thumb is to create a new Project for each individual application environment.
For example, a single SaaS product may be composed of a database, a web server and some object storage. The production environment for this product would need one Project. If developers wanted a staging environment, they might create a second, isolated Project within the production Project's Folder. The same would go for a testing environment, a development environment and even a research and development environment. Projects can create precise boundaries between Resources.
Google Cloud Resources
Found at the bottom of the hierarchy, Resources are instances of specific Google Cloud products, such as compute instances and storage buckets. Always think of a Resource as a single-purpose entity, devoted to serving a specific function for its Project. While shared Resources are possible, they can make the organizational hierarchy confusing. They can also create complex interdependencies that can be difficult to unwind later. Leaning into Google Cloud's organizational structure can help create a scalable application architecture.
Hierarchy benefits and drawbacks
Google Cloud's hierarchy is flexible enough that companies can organize their workspace any way they choose.
The flexible Folder structure enables admins to manage access to Projects and Resources. When employees or groups of employees have access to a Folder, they have access to the nested Folders, Projects and Resources as well. This is helpful when following an organizational method that mirrors a company's real-world structure, as administrators can easily divide employee access by location, department or other facets.
While Google Cloud's organization hierarchy is flexible, it still encourages a logical organization structure. In a single-cloud environment, this is easy to achieve. But what about a multi-cloud or hybrid cloud interface? In this instance, keep in mind your own organizational schema. When organizing entities that move across different clouds, consistency is key. The Folder hierarchies and Project names should match, both inside and out of Google Cloud. Otherwise, it might be difficult to reconcile exactly where Resources are.
The flexibility that makes Google Cloud's resource hierarchy so useful can also create trouble. There's no right way to use it, but the wrong way is to implement it without thorough planning.
Think about your needs and write them down. Use logical naming conventions and avoid non-human identifiers. Automation systems may be able to understand what Folder #102934847 is, but employees won't.
Start simple and focus on the Folders and Projects first. Think about who needs access to the underlying Resources. Consider how those access needs might change in the future and give yourself room to grow. Remember, the more complex something is, the more difficult it is to change.
