Architectural role of Google Cloud projects

How your team chooses to organize services into projects plays a major determining factor in the overall architecture of the systems you will build. Since all resources in a project roll up to centralized permission management and billing, a common pattern in larger organizations is to create projects associated with business cost centers or departments. For example, in a given organization, you may have an IT cost center for an inventory management department and another for a customer service department, each with separate budgets. In this case, it may be ideal to create separate projects for each department to simplify team management and payments.

Projects are often separated further based on product teams within the same organization, often for reasons of budgeting or access control. The division of projects based on organizational structure makes it easier to secure data and APIs by limiting access to those with a valid need. This both minimizes opportunities for malicious users and lowers the risk of development teams accidentally stepping on each other's toes.

Another common pattern is to create separate projects based on the application development life cycle. By splitting projects into development life cycles, teams can create isolated environments for development, QA, and production services. As with projects based on organization structure, life cycle-specific projects offer an ideal primary layer of security by drawing clear boundaries on resource access.

For services, this means that non-production systems cannot (unintentionally or maliciously) affect production systems. For team members, this provides a clear way to implement a strategy of separation of concerns. In both cases, this can help prevent compromised credentials and resources from affecting production services or accessing sensitive data. Much more detail will be provided on this in Chapter 3, APIs, CLIs, IAM, and Billing.