GoogleCloudPlatform/professional-services: a reference repository, not a product

What the repository actually is

This is a monorepo of solutions and tools written by Google Cloud's Professional Services team, with Python as the primary language. It is not a library you install and import. The README describes the examples folder as containing "example solutions across a variety of Google Cloud Platform products" and tells you to "use these solutions as a reference for your own or extend them to fit your particular use case." That sentence sets the contract: you read the code, you adapt it, you own the result.

The intended reader is an engineer or consultant already working inside Google Cloud on a customer problem. The catalogue is dominated by BigQuery: migration utilities for Oracle and Snowflake DDL, a DDL validator, a translation validator, an audit log anomaly detector, a billing dashboard, a cross-project slot monitor, and a data consolidator aimed at Cloud FinOps work. Outside BigQuery there is an Anthos Service Mesh multi-cluster federation example, a GitLab CI/CD guide for Anthos, a Bigtable change-key example, an audio content profiling pipeline, and a bigdata generator for stress-testing. Each entry is a separate folder with its own scope.

The disclaimer at the top of the README is not boilerplate. It says the repository and its contents are not an officially supported Google product. Whatever support expectations you have, attach them to the individual solution's own documentation, not to this repository.

How the folders are laid out and how you consume them

There is no shared runtime and no single entry point. The top level holds examples/, tools/, helpers/, colab_notebooks/, cloudbuild/ and license-templates/, plus a Makefile, a cloudbuild.yaml and contributing documents. Each solution lives in its own subdirectory and carries its own README, dependencies and deployment story, which is why the repository-level README is a catalogue rather than a manual.

That structure has a practical consequence. Nothing at the root tells you whether a given folder still works against the current API of the service it targets. The only build and format machinery at the root is the Makefile, which runs helpers/format.sh and helpers/check_format.sh. The repository README does not document a rollback path for anything, because there is nothing deployed centrally to roll back.

The consumption pattern is cloning the whole repository and working inside one folder. The README links a Cloud Shell editor URL that opens the repository directly, and a local clone follows the same shape. The repository URL appears in that Cloud Shell link as https://github.com/GoogleCloudPlatform/professional-services.git. From there, read the README inside the specific folder you care about. The root README does not reproduce per-solution install steps.

Installing and running one solution: the bqman CLI

The closest thing to a packaged tool here is bqman, listed in the README as a "Command-line utility for automated provisioning and management of BigQuery datasets and tables." It is a Python tool, so the working assumption is a virtual environment plus the folder's own dependency file. The repository README does not spell out install commands, and it does not name a requirements file or an entry point, so those details have to come from the README inside tools/bqman itself.

What the repository does document at the root is its own Makefile targets. If you are contributing back rather than just consuming a folder, the formatting and test targets are the ones to know:

make fmt
make test
make help

The README's Makefile comments describe `make fmt` as formatting files including the README, `make test` as testing whether all files are properly formatted, and `make help` as printing help for targets with comments. There is also a `make push_ci_image` target, which the Makefile comment shows running gcloud builds submit inside the cloudbuild directory to tag gcr.io/cloud-eng-council/make. Run these from the repository root after cloning, and expect `make test` to fail if your edits break the repository's formatting conventions.

For bqman itself, the repository README stops at the one-line description. Treat the install as undocumented at this level and read the folder's own README before assuming a command name or a dependency file.

Where this repository will let you down

The biggest limitation is stated by the project itself: not an officially supported Google product. There is no compatibility promise, no deprecation policy visible at the repository level, and no release feed. The repository metadata returned no releases at all, so there is no version number to pin your adaptation to. You are tracking the main branch of a collection of independent folders.

The second limitation is heterogeneity. A folder like bigquery-generic-ddl-migration-utility and a folder like anthos-service-mesh-multicluster share a parent directory and nothing else. Different languages, different deployment models, different maturity levels. Treating the repository as a coherent suite and planning a single upgrade path across it will not work.

The third is the mismatch between the repository name and what people search for. Anyone arriving here looking for a professional services firm, a salary, a tax treatment or a university course is in the wrong place entirely; this is a code repository for Google Cloud practitioners. If you need a supported migration product with a support contract, this repository is the wrong tool, and the disclaimer at the top of its README is the reason.

Alternatives and how they differ in approach

The obvious comparison is Google Cloud's official client libraries and the gcloud CLI. Those are supported products with versioned releases and documented interfaces. The difference is scope: a client library gives you an API binding and nothing else, while a folder in this repository gives you a finished workflow (an Oracle DDL migration, a slot monitoring dashboard) built on top of those bindings. You trade support for a head start.

A second alternative is writing the pipeline yourself against the BigQuery API. For a one-off DDL conversion that is often cheaper than reading someone else's utility, because you avoid inheriting code you did not write and cannot get fixed. The repository's value shows up when the workflow is fiddly rather than hard: cross-project slot aggregation, audit log anomaly detection, group-to-row-level-access synchronization. Those are the cases where a reference implementation saves days.

A third alternative is Terraform or another infrastructure-as-code tool for provisioning. bqman provisions BigQuery datasets and tables from a command line; Terraform manages them as declared state with a plan step. If you need drift detection and reviewable changes, declarative state is the better model. If you need a quick scripted bootstrap inside an existing Python workflow, bqman is closer to hand.

Licence, attribution and the cost of adopting a folder

Everything in the repository is Apache 2.0, and the README points at the LICENSE file for the detailed terms. In practice that means you can copy a folder into your own codebase, modify it and ship it, provided you keep the licence and notice obligations intact. The files themselves carry the Apache header, as the Makefile in this repository does, so the attribution is already embedded in the source you would be copying. This is a description of the licence text, not legal advice; your own counsel decides how it applies to your distribution.

Upgrade cost is the part people underestimate. Because each folder is independent and there are no releases, there is no changelog to read when you want to pull in upstream fixes. Your realistic options are diffing the folder against your fork occasionally, or accepting that your copy has diverged permanently. For a small utility that is fine. For a folder you have built a production pipeline around, budget for owning it outright.

The root Makefile is the only shared machinery. It sets SHELL to /usr/bin/env bash and declares the fmt, test and push_ci_image targets, with fmt and test delegated to scripts under helpers/. Those scripts check the repository's own formatting conventions, not your adapted copy, so a folder you have moved into your own repository is outside their scope entirely.

Editorial conclusion

Adopt this repository as a source of reference implementations and starting points, not as a dependency. Teams doing BigQuery migrations, DDL validation, FinOps consolidation or Anthos multi-cluster work will find a matching folder under examples/ or tools/ and can lift the approach. Teams that need a supported product with an SLA should not treat any folder here as one: the README says plainly that the contents are not an officially supported Google product. Before you commit, verify three things in the specific folder you picked: whether it has its own README with install steps, what its own requirements or dependency file pins, and whether the code reads credentials from your environment or expects a hardcoded project. The repository-level README does not answer any of those questions for you.

Frequently asked questions

Official sources

1. Official README
2. Project repository