10

I have recently inherited the previous director of devops duties in managing a transition from Heroku/AWS to GCP. I'm wondering what is best practice for organizing projects in GCP.

Should the be organized by production, staging, and QA environments? Should they be organized by each individual self contained front-end project or middleware project? If so, where do databases live in that function? The middleware project?

You can see how many core questions can lead to adjacent questions.. does anyone have best practices here about how they organize their GCP projects in the enterprise?

Corollary question: how does your project organization affect cost or inter-networking?

Thanks!

Dan
  • 203
  • 2
  • 5

3 Answers3

5

Speaking primarily from the Google App Engine (GAE) perspective.

My preference is for environment-driven project split. This might be of interest: Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?

I wouldn't go for architecturally-driven project split unless there are serious reasons for doing so (if you feel you have such reasons you should ask with details):

  • probably difficult (if not impossible) to avoid inter-project bandwidth charges
  • added configuration complexity for inter-operation between projects (GCP pretty much considers them completely isolated/standalone, except maybe for shared IAM permissions). Possibly relevant: Google app engine access cross project resources

Depending on the GCP products used there may be sufficient support for architectural splits inside the same project. At least GAE does IMHO.

My GAE apps are all standalone and do not use inter-networking at all, so no costs from this perspective. There are still networking (bandwidth) costs for accessing various GCP-provided infra/services, but those are irellevant/unavoidable from the project split perspective.

Dan Cornilescu
  • 6,780
  • 2
  • 21
  • 45
4

Google's recommended best practice is to create an Organisation within GCP so that you get access to folders, then model the hierarchy of your organisation within GCP:

Sample Organisation Structure

Some guidance/rules:

  1. there should only be one organisation that represents the entire organisation; configuring directory sync is very painful otherwise.
  2. folders should represent business units
  3. projects should represent instances of an app or component
  4. use different projects for each environment, because each environment is generally an instance of an app or component
  5. fully qualify the names of each folder or project, because GCP often doesn't show the full path to the project. Consider there are intentionally two applications named mgmt-prod in the above diagram. However, because they are called amido-ops-pmo-mgmt-prod and amido-people-mgmt-prod it's easy to tell just from the project name what they are.

The significant advantage of this model is that you can create a group called TechOps and give it audit or read permission at the Organisation level. Those people will have access to the entire estate. Equally, you can also grant granular permissions at the folder and project level based upon business requirements.

Richard Slater
  • 11,747
  • 7
  • 43
  • 82
2

We have two projects: production and staging. Later runs dev, qa also. And for billing purpose, we tag resources accordingly.

Hungry Mind
  • 121
  • 1