Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?

Question

In Naming Developer Environments Google suggests 2 approaches for implementing different CI/CD environments for GAE apps

• based on different services (which used to be called modules) inside the same project/app:

If you choose to create your microservices application by using only multiple services, you can create a single App Engine project for each of your environments and name them accordingly, such as web-app-dev, web-app-qa, and web-app-prod.

• based on different projects/apps:

Alternatively, if you choose to create your microservices application by using multiple projects, you can achieve the same separation between environments, but you'll need to use more projects, such as web-app-dev, web-app-prod, user-service-dev, and user-service-prod. You will need to use code patterns to ensure that the dev projects only call other dev projects and the prod projects only call other prod projects.

The phrasing in the above documentation snippets appears to suggest the 2 approaches would be roughly equivalent, but there is at least one significant difference between the 2 approaches: a project/app based approach ensures data isolation, while a service/module based one does not - the datastore and memcache are shared by all services.

A more detailed comparison between the 2 approaches from the isolation perspective is documented in Comparison of service isolation and project isolation:

The following table provides a comparison between using multiple services and multiple projects in a microservices architecture:

My question is: apart from the above-mentioned differences, are there other advantages of using the project-based approach versus the service-based one? Or anything that may be considered a disadvantage?

Answer 1

The project based approach also allows you to separate billing concerns, and IAM roles.

You could go as far as having different credits cards charged, or just set billing limits independently (who wants prod to go down because a dev bug exceeded your billing limit?). You'll also get separate billing reports, so we can determine what prod vs dev cost you more easily.

The service based approach potentially minimizes additionally administrative work. For example, if for some reason you needed to set up VPNs or other networking aspects, a single project means you only need to configure it once, rather than once per project.