asl-ml-immersion: Google's ASL Bootcamp Notebooks, and What They Assume About Your Setup

What the ASL repository is actually for

This is courseware, not a framework. The README describes it as AI and Machine Learning content meant to be run on Google Cloud, maintained by Google Cloud's Advanced Solutions Lab team. That framing matters, because it tells you the intended consumer is someone sitting in a bootcamp, not someone adding a dependency to an application.

The repository splits into three modules. asl_core covers model architectures (the README lists DNN, CNN, RNN, transformers and SNGP) across tabular, image, text and time-series data, implemented mainly in TensorFlow and Keras. asl_mlops covers operationalizing TensorFlow, Scikit-learn and PyTorch models on Google Cloud's Agent Platform, including training, tuning, serving and Kubeflow pipelines. asl_genai covers generative AI and agent systems built on Gemini and agentic frameworks such as Google ADK.

Each module carries its own environment and its own requirements.txt, and the learning material lives under a contents folder organized by topic. Inside each topic folder there is a labs directory and a solutions directory. The labs notebooks contain TODOs for the learner to fill in; the solutions notebooks are the reference implementation. That labs/solutions pairing is the single most distinctive design decision in the repository, and it is also the reason the repository is not useful as a code sample library: half the notebooks are deliberately incomplete.

The labs and solutions split, and why it constrains reuse

If you open a file under a labs folder expecting working code, you will find gaps. The README is explicit that you use the labs notebooks to test your coding skills by filling in TODOs and refer to the solutions notebooks to verify your code. There is no third variant that is production-shaped.

This has a practical consequence for anyone evaluating the repository as a source of reference implementations. The solutions tree is the part worth reading, and the labs tree is the part worth teaching from. Copying a labs notebook into a project and running it top to bottom will not work, and nothing in the repository structure warns you at the file level. You have to know the convention.

The other structural element worth noting is the kernels directory under asl_core. The README describes it as containing kernel scripts needed for certain notebooks. That is a hint that a subset of the material depends on custom compiled operations rather than pure Python, which in turn means those notebooks are sensitive to the environment the setup script builds. The scaffolds directory is described as sample code to accelerate AI/ML projects, which is the closest thing to reusable project material in the tree.

Provisioning: setup_env.sh, make, and the kernel names

The documented path starts in Cloud Shell. You clone the repository and run the setup script:

git clone https://github.com/GoogleCloudPlatform/asl-ml-immersion.git cd asl-ml-immersion bash scripts/setup_env.sh

The script prompts for an environment and offers four choices: Agent Platform Workbench, Cloud Workstations, both, or skip. Choosing skip provisions only the project infrastructure (APIs, IAM, buckets) and leaves the notebook environment to you, following the linked Google Cloud documentation for creating a Workbench instance or a workstation. The script then asks whether to attach an Nvidia T4 GPU. The README notes that accelerators are not required in most notebooks but that some recommend them.

The second stage happens inside the running environment, not in Cloud Shell:

git clone https://github.com/GoogleCloudPlatform/asl-ml-immersion.git cd asl-ml-immersion make

That make target is what builds the virtual environments and the Jupyter kernels. The README names three kernels: ASL Core, ASL MLOps and ASL Agent. You select one per notebook, and the README notes that on Cloud Workstations the kernels appear under Select Kernel then Jupyter Kernels, with a fallback of Python Environment and the left arrow if that menu is missing.

For terminal work, the README gives one concrete example of activating a module environment and running an ADK agent:

source ./asl_genai/.venv/bin/activate adk web ./asl_genai/notebooks/building_agents/solutions/adk_agents

Two details stand out. First, the venv path is per-module (asl_genai/.venv), so activating the wrong one is an easy mistake. Second, the example points at a solutions notebook directory, which reinforces that the solutions tree is the executable one.

Where this repository breaks down

The most obvious limitation is that it is not a distributable artifact. There is no package, no versioned API, no installable module. Adoption means cloning a repository and running a provisioning script that creates cloud resources in your project. If your team's workflow is pip install and import, this repository has nothing for you.

The second limitation is the contribution model. The README states plainly that currently only Googlers can contribute, with CONTRIBUTING.md holding the workflow. For an Apache-2.0 repository that is an unusual combination: you have broad rights to the code and effectively no route to upstream a fix. If a notebook breaks against a newer library version, you patch your clone and carry the diff.

The third is environmental coupling. The README says the repository is tested on Agent Platform Workbench and Cloud Workstations. Everything about the setup flow, from the Cloud Shell script to the kernel selection UI, assumes one of those two surfaces. Running the notebooks on a local machine or a different managed notebook product is not covered by the documentation, and the make-based environment build is the only described mechanism for producing the kernels.

Finally, there is the cost dimension, which the README flags rather than solves. It states that this is not an officially supported Google product and that usage of Google Cloud products will incur charges. The setup script provisions APIs, IAM and buckets, and optionally a T4 GPU. None of that is free, and none of it is automatically torn down by anything described in the README.

How it compares to a general notebook collection

The natural alternative is a general-purpose collection of machine learning notebooks, of which there are many, typically organized by library or by technique and designed to be run in whatever environment the reader already has. The difference in approach is not the content depth. It is the coupling to infrastructure.

A generic notebook collection assumes you bring your own runtime and asks nothing of your cloud project. asl-ml-immersion assumes the opposite: it asks for a Google Cloud project, runs a script that enables APIs and creates IAM bindings and buckets, and then builds module-specific virtual environments so that three separate kernel families can coexist. That is a heavier commitment, and it buys you something a generic collection cannot offer, which is the asl_mlops material. The MLOps module is built around Agent Platform training, tuning, serving and Kubeflow pipelines, and those notebooks only mean something inside a provisioned Google Cloud project.

So the comparison is really about intent. If you want to learn a model architecture, a generic notebook will do. If you want to learn how that architecture gets trained, tuned, served and pipelined on Google Cloud, the infrastructure coupling is the curriculum, not overhead. The trade is that you cannot cherry-pick the interesting notebook without also accepting the setup script.

Maintenance, versions, and the Keras split

The release list shows how the maintainers handle library churn. There are two named releases for Keras versions: keras3 (ASL with Keras 3) and keras2 (the repository with Keras 2 notebooks), both dated 2026-01-14. A third release, um_notebook (ASL on Vertex AI User-Managed Notebook), is dated 2024-06-13.

That keras2/keras3 pair is the maintenance model in miniature. Rather than migrating notebooks in place and breaking anyone mid-course, the project keeps parallel tracks. For a bootcamp repository this is sensible: a cohort that started on one Keras major version can finish on it. For an adopter, it means you have to decide which track you are on before you clone, and the README's setup instructions do not themselves branch on that choice. The release tags are the mechanism, and the README does not spell out how to select one.

The um_notebook release is older, and it maps to the Vertex AI user-managed notebook path that the README's manual setup option links to. Its age relative to the Keras releases suggests the primary supported surfaces have moved toward Workbench and Cloud Workstations, which is consistent with the setup script offering those two and not offering a user-managed notebook option by name.

On licensing: the code is Apache-2.0, and the README includes the standard warranty disclaimer. Apache-2.0 gives you the usual rights to use, modify and redistribute with attribution and notice retention. It does not grant rights to Google trademarks or to any Google Cloud service, and the README's own disclaimer states this is not an officially supported Google product. If you plan to redistribute the notebooks inside a commercial training product, that is a question for your own counsel, not something the licence text resolves on its own.

Editorial conclusion

Adopt it if you are running a Google Cloud training cohort on Workbench or Cloud Workstations and want lab and solution pairs you can hand out. Do not adopt it if you need a library, a pip-installable package, or anything that runs outside a provisioned Google Cloud project, because scripts/setup_env.sh is the entry point and there is no supported path around it. Before committing a cohort, verify three things: that make completes and produces the ASL Core, ASL MLOps and ASL Agent kernels on your chosen environment, that the GPU prompt in setup_env.sh matches the accelerators you actually have quota for, and that CONTRIBUTING.md still restricts contributions to Googlers, which tells you how fast an outside fix will land.

Official sources

1. GoogleCloudPlatform/asl-ml-immersion on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases