MLOps / ML platform engineer

Pathway version 1 · 35 lessons in 9 modules · shared module: system design (planned)

A curated sequence over the library for a MLOps / ML platform engineer: 35 lessons in 9 modules, from the foundations of the role to its advanced topics.

What the role asks for

Responsibilities

Scope at staff

Technologies

CI/CD and GitOps

Cloud and compute

Data stores and warehouses

Experiment tracking, registry and features

LLM and agent tooling

Languages and frameworks

Pipelines and orchestration

Serving and inference

The path

1. Foundations of the ML platform role

This module sets the base for the ML platform role: what MLOps adds to ordinary software delivery, and the Python, Kubernetes and AWS skills every later module builds on. Each lesson starts with the concept, then moves to how teams run it in production and which tools implement it.

1. MLOps and the ML lifecycle: from experiment to production systemL2
MLOps applies DevOps discipline to systems whose behavior depends on data and trained artifacts as well as code.
2. Python for platform engineering: packaging, environments and testingL2 · Practice
Python is the common language of ML teams, so platform tooling, pipeline components and SDKs are mostly written in it.
3. Kubernetes for ML workloads: containers, deployments and jobsL2 · Practice
Kubernetes is the default substrate for ML platforms because it schedules containers across a shared pool of machines and keeps declared state true.
4. AWS and EKS foundations for an ML platformL2 · Practice
Amazon EKS is the managed Kubernetes service many ML platforms are built on: AWS runs the control plane and the team owns the workloads, the node strategy and the integrations.

2. Data and feature infrastructure

This module covers the data layer under an ML platform: the batch and streaming compute that builds datasets, the stores that hold them, and the feature store that serves the same values to training and inference. Each lesson starts from the architecture and then goes into the operating details a platform engineer owns, such as partitioning, cost, correctness over time and failure recovery.

5. Large-scale data pipelines with Spark and PySparkL2 · Practice
Apache Spark is the default engine for building training sets and feature tables that do not fit on one machine.
6. Storage for ML: lakehouse, warehouse and operational data storesL2 · Practice
ML systems use several stores, each chosen for one access pattern: object storage and lakehouse tables for bulk training data, a warehouse for analytical SQL, a relational database for metadata and transactional state, and a key-value store for low-latency lookups at inference.
7. Feature stores and feature pipelines: offline/online consistencyL2 · Practice
A feature store is the system that defines features once and serves the same values to training and to online inference.

3. Workflow orchestration

Workflow orchestration is the layer that turns individual ML steps such as ingestion, feature computation, training, evaluation and deployment into repeatable, observable, retryable pipelines. This module covers the general-purpose scheduler most teams start with (Airflow), the ML-native orchestrators built around containers and artifacts, and durable execution with Temporal for long-running, event-driven processes.

8. Orchestrating ML pipelines with AirflowL2 · Practice
Airflow models a pipeline as a DAG of tasks defined in Python, and a scheduler decides when each task runs based on a schedule, dependencies and state.
9. ML-native orchestrators: Kubeflow Pipelines, Flyte, Prefect and MetaflowL2 · Practice
ML-native orchestrators treat a pipeline as a graph of containerized, typed steps that produce versioned artifacts, rather than as scheduled tasks that happen to run ML code.
10. Durable workflows and event-driven services with TemporalL2 · Practice
Temporal provides durable execution: workflow code runs as if failures do not exist, because every step is recorded in an event history and the workflow can be rebuilt by replay after a crash.

4. Training infrastructure

Training infrastructure is the part of an ML platform that turns expensive GPU hardware into repeatable, traceable training runs. This module covers how runs are recorded, how GPUs are exposed to Kubernetes, how one job spans many nodes, and how a shared cluster decides who runs when.

11. Experiment tracking with MLflowL2 · Practice
Experiment tracking records what was run, with which inputs, and what came out, so any model can be traced back to its code, data and hyperparameters.
12. GPU compute on Kubernetes with the NVIDIA stackL2 · Practice
Kubernetes does not understand GPUs natively; it learns about them through a device plugin that advertises them as an extended resource.
13. Distributed training across multiple GPU nodesL2 · Practice
When a model or dataset is too large for one GPU, training is spread across several GPUs and several nodes that must start together, find each other and stay in sync.
14. Workload scheduling, capacity management and GPU cluster operationsL2 · Practice
A shared GPU cluster has more demand than capacity, so something must decide which jobs run, in what order, and on whose budget.

5. Model release engineering

Model release engineering covers the path from a trained artifact to a version serving production traffic: how the model is packaged and versioned, what evidence it must produce before promotion, and how automation moves it through environments. The lessons go from registry and evaluation gates through CI/CD and GitOps to progressive rollout and rollback.

15. Model registry, packaging and versioningL2 · Practice
A model registry is the system of record between training and serving: it gives each trained artifact a name, an immutable version, lineage back to the run that produced it, and a state that says whether it may be deployed.
16. Model evaluation: regression suites and release gatesL2 · Practice
An evaluation gate turns the question of whether a model is good enough into an automated, repeatable check that blocks promotion when it fails.
17. CI/CD for models and services with GitHub ActionsL2 · Practice
CI/CD for machine learning extends ordinary software delivery with two extra artifacts, data and models, and a third loop, continuous training.
18. Reproducible environments: GitOps with Argo CD and infrastructure as code with TerraformL2 · Practice
Reproducible environments come from declaring everything in version control and letting automation converge real systems toward it.
19. Staged rollouts: shadow, canary, champion/challenger and rollbackL2 · Practice
Offline evaluation cannot prove a model behaves well on live traffic, so releases are staged: the new version is exposed to production conditions gradually while automated checks decide whether to continue.

6. Serving and inference

This module covers how trained models become reliable inference services: the architecture of online and batch serving, the managed route through SageMaker, and the specialised runtimes used for large language models. It moves from general serving patterns to LLM engines and then to compilation, quantization and edge targets, where latency and cost are won.

20. Model serving architecture: inference APIs for batch and real-time demandL2 · Practice
Model serving turns a versioned model artifact into an inference API with defined latency, throughput and availability.
21. Managed deployment and serving with Amazon SageMakerL2 · Practice
Amazon SageMaker offers managed hosting in which AWS runs the instances, load balancing and health management while the team supplies a container and a model artifact.
22. Serving open-weight LLMs with vLLM and SGLangL2 · Practice
Serving open-weight LLMs is a distinct discipline because generation is autoregressive: each request holds GPU memory for its whole lifetime and produces output token by token.
23. Low-latency inference: TensorRT-LLM, quantization and edge deploymentL2 · Practice
When latency or hardware budget is tight, the model itself is optimised for the target device instead of only scaling the service around it.

7. LLM and agent platform

This module covers the platform layer that sits between application teams and large language models: hosted model APIs, retrieval infrastructure, agent runtimes with tool protocols, and the operational discipline that keeps them measurable and safe. It moves from calling a model, to grounding it in data, to letting it act, to proving that all of it works in production.

24. Integrating hosted LLMs: AWS Bedrock, the Claude API and prompt engineeringL2 · Practice
Hosted LLMs turn model serving into an API integration problem: the platform team does not run GPUs, but it owns access, quotas, cost, latency and the contract that application code uses.
25. Retrieval-augmented generation infrastructure and vector searchL2 · Practice
Retrieval-augmented generation pairs a model's parametric knowledge with an external, searchable store, so answers can be grounded in current and private data and can cite it.
26. Agent architectures, agent frameworks and the Model Context ProtocolL2 · Practice
An agent is a model that decides its own next step in a loop of reasoning, tool calls and observations, as opposed to a workflow whose steps are fixed in code.
27. LLMOps: evals, tracing, guardrails and AI-assisted development with Claude Code and CursorL2 · Practice
LLMOps applies the release and operations discipline of MLOps to systems whose behavior is set by prompts, models, retrieval and tools together.

8. Operating ML in production

This module covers what happens after a model ships: seeing what it does, knowing when it degrades, keeping it reliable, keeping it secure, and paying a sensible price for it. Each lesson starts from the operating principle and then moves to the concrete tools and configuration a platform team uses.

28. Observability: logs, metrics and traces with OpenTelemetry and PrometheusL2 · Practice
Observability is the ability to explain a system's internal state from the telemetry it emits, without shipping new code to ask a new question.
29. Model monitoring: data quality, drift and alertingL2 · Practice
A model can be up, fast and error-free while its predictions get worse, because the data it sees has moved away from the data it was trained on.
30. Reliability practice: SLOs, on-call runbooks and postmortemsL2
Reliability practice turns the vague goal of a stable service into numbers and routines: service level objectives that define good enough, alerts tied to those objectives, an on-call rotation with runbooks, and postmortems that turn incidents into fixes.
31. Security, identity and access, and compliance for ML platformsL2 · Practice
An ML platform concentrates valuable things: training data, model weights, expensive compute and credentials to many systems.
32. Autoscaling and cost efficiency: right-sizing, spot mix and GPU utilizationL2 · Practice
ML workloads are expensive and bursty, so capacity has to follow demand at two levels: the number of pods and the number and type of nodes under them.

9. Designing the platform as a product

An ML platform succeeds only if teams choose to use it, so this module treats the platform as a product with users, paved paths and measurable adoption. It then covers the system design needed to share that platform safely across many tenants, and the written decision process that keeps its architecture coherent.

33. Self-service platforms: golden paths, templates and developer toolingL2 · Practice
A self-service platform lets ML and product teams get a working, compliant project, pipeline or endpoint without filing a ticket.
34. System design for multi-tenant ML infrastructure: isolation, quotas and backpressureL2 · Practice
A shared ML platform runs training, batch and serving workloads from many teams on common clusters and accelerators.
35. Writing and reviewing design docs and architecture decision recordsL2
Platform decisions outlive the people who made them and affect every team on the platform, so they need a written record that can be reviewed before work starts.

Changes

Version 1, 2026-10-12: re-expressed the gigai 0.1.11.10 shipped course as references into the library