statmike/vertex-ai-mlops: a notebook library for Google Cloud ML and agent workflows

What problem the notebook collection solves

Google Cloud's AI platform has been renamed repeatedly. The README traces the line from Cloud ML Engine to AI Platform to Vertex AI, and notes that as of April 2026 it is presented as the Gemini Enterprise Agent Platform. Each rename accompanied a scope change: custom model training first, then a unified platform with AutoML and managed notebooks, then a combination of model building, agent development, orchestration, and governance. For an engineer joining a project today, that history is a trap. Tutorials and Stack Overflow answers written against AI Platform import paths and resource names do not map cleanly onto the current surface. This repository exists to give a current, worked example for each piece of that surface, so you can see the resource names, the client library calls, and the service wiring in one place instead of assembling them from release notes.

The audience is narrow but real. It is for someone who has a Google Cloud project, understands Python, and needs to move a model or an agent from a notebook to something that runs on a schedule. The README describes each notebook as a hands-on workflow you can learn from, adapt, and use as a starting point. That is the correct framing. Nothing here is a library you import.

How the repository is organized, and what that implies

The layout is the mechanism. The README splits the material into top-level groups, each of which maps to a phase of work rather than to a software module. MLOps holds 74 notebooks: 32 on serving, 21 on feature stores, 13 on pipelines, 3 on model evaluation, 2 on model monitoring, and 1 on experiment tracking. A separate data+ai group holds 40 notebooks, 32 of which cover BigQuery AI functions, with the remainder on Dataflow and Dataproc. The README also references workflows spanning Managed Airflow, Cloud Run, GKE, Spanner, AlloyDB, Cloud SQL, Memorystore, Firestore, and Bigtable, positioned as feature stores, vector search backends, or SQL inference endpoints.

That structure tells you how to use it. There is no shared package, no setup.py, no CLI. Each notebook is self-contained and demonstrates one service interaction. The serving directory alone covers online endpoints (dedicated, shared, and private with PSC), batch inference through Vertex AI, Dataflow, Dataproc, and Airflow, SQL-based inference in BigQuery ML, AlloyDB, and Spanner, and deployment to Cloud Run, GKE, and Cloud Functions. The breadth is the point: the README states the goal is to show how these services work together, not in isolation. The cost of that breadth is that consistency across 470+ notebooks cannot be assumed. Treat each one as its own artifact.

Running a notebook: what you actually need

The material does not include an installation section, a requirements file listing, or a pinned environment, so any command you run comes from the individual notebook rather than from the repository root. What the README does establish is the execution context. These are Jupyter notebooks targeting Google Cloud services, which means a Google Cloud project with billing enabled, the relevant APIs turned on for whichever service the notebook uses, and credentials available to the notebook kernel. In practice that is either a Vertex AI Workbench instance or a local environment with the Google Cloud CLI authenticated.

Because the repository has no releases, no tags, and no package manifest in the supplied material, there is no version to pin. If you clone it, you get the state of the main branch at clone time. The README's own download link points at raw.githubusercontent.com for the readme file specifically, which is a hint about how the author expects the content to be consumed: file by file, not as an installed dependency. Budget time for the environment per notebook. A BigQuery AI functions notebook and a GKE serving notebook have almost nothing in common in terms of prerequisites, and the repository does not abstract that difference away.

The feature store material is where the depth is

Most of the collection is one notebook per topic. The feature store section is the exception, and it is worth calling out because it shows what the repository looks like when the author goes deep rather than wide. Of the 21 feature store notebooks, the README describes a 15-notebook sequence on building a self-managed Bigtable feature store. The listed topics are serialization, sync patterns, history, schema evolution, vector search, replication, and a recommendation engine capstone.

That sequence is the most useful thing in the repository for a team that has outgrown the managed option, because it addresses the questions the managed service does not answer for you: how you serialize features, how you keep the online and offline copies in sync, how you handle a schema change without breaking serving, and how you replicate. It also demonstrates the trade-off directly. Building on Bigtable means you own the sync logic, the history, and the schema migration path. The managed Vertex AI feature store notebooks sit alongside it, so you can read both approaches against the same problem. Whether the self-managed path is worth it depends on your latency and cost constraints, and the notebooks give you the mechanics rather than a recommendation.

Where this repository is the wrong tool

The most important limitation is that nothing here is maintained as software. There are no releases, no changelog, and no compatibility matrix in the supplied material. The last push is dated 2026-09-07, and the README itself notes that the platform was rebranded in April 2026. A notebook that was correct when written can drift out of date as service APIs change, and there is no signal in the repository telling you which notebooks have been revisited since a given API change. If you copy a snippet into a production pipeline, you are the one who owns verifying that it still matches the current client library.

There is a second, less obvious failure mode. The repository is a teaching artifact, so the notebooks are written to be read. Code that is clear in a notebook is often not code you want in a scheduled job: credentials handling, retry logic, and error paths are usually simplified or omitted in favor of demonstrating the happy path. A team that lifts notebook cells directly into a pipeline will discover this at the worst time. The realistic use is to read the notebook, understand the service interaction, and then write your own code against the current SDK. Finally, the entire collection is Google Cloud specific. If your data lives in another cloud or on premises, the BigQuery AI functions and Vertex AI Pipelines material does not translate.

How it compares to Kubeflow and Airflow as a starting point

The natural alternative for the pipeline portion is Kubeflow Pipelines, which the repository itself uses through KFP in its 13 pipeline notebooks. The difference in approach is worth being precise about. Kubeflow Pipelines is a system you deploy and operate: you write components, compile them, submit them to a cluster, and the platform handles scheduling, artifact tracking, and retries. This repository teaches you how to author those components in the Vertex AI Pipelines context, including control flow, I/O, scheduling, notifications, and testing. It is not a substitute for Kubeflow Pipelines or for Managed Airflow. It is the material you read before you write your first component.

The same relationship holds for the orchestration examples. The README describes workflows that integrate Managed Airflow for orchestration, and the serving section includes batch inference through Airflow. If you already run Airflow, those notebooks show a Google Cloud specific integration pattern. If you are choosing an orchestrator, this repository will not make the decision for you, and it does not claim to. The distinction to hold onto is that Kubeflow and Airflow are runtime systems with upgrade cycles and operational burden, while this is a body of examples that describes how to talk to them.

Licence and the cost of keeping it current

The repository is Apache-2.0. That permits commercial use, modification, and redistribution, and it includes a patent grant. It also requires that you preserve the licence and attribution notices, and that you state significant changes if you redistribute modified material. For a team copying notebook snippets into an internal repository, the practical obligation is to keep the attribution intact where the code is recognizable. This is a description of the licence text, not legal advice; if the snippets end up in a distributed product, have counsel look at it.

Maintenance cost is the real expense, and it falls on you rather than on the project. Because there are no releases, there is no upgrade path and no deprecation window. When a Google Cloud API changes, you find out when a notebook fails. The mitigation is to treat the repository as a reading list tied to a specific task. When you need to serve a model on GKE, open the GKE serving notebook, extract the pattern, and write your own code. Do not fork the repository and try to keep 470 notebooks green. The Apache-2.0 licence gives you the freedom to copy; the absence of releases tells you not to depend.

Editorial conclusion

Adopt this repository as a reference library if your team already runs on Google Cloud and needs worked examples of Vertex AI serving, BigQuery AI functions, or feature store patterns before writing your own code. Do not adopt it if you need a versioned package with an API contract, a supported pipeline you can call from CI, or anything that works outside Google Cloud. Before committing, open the specific notebook for the service you care about, check whether its APIs still match the current documentation, and confirm the license terms for any snippet you copy into a production repository.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. statmike/vertex-ai-mlops on GitHub