Chapter 1: Getting started with MLOps and ML engineering

Introduction

The chapter introduction sets out a practical, project-based path from ML experimentation to production systems.

• End-to-end ML engineering path: Describe the book’s progression from MLOps foundations and platform building through pipelines, data preparation, training, serving, monitoring, and LLM systems.
  Why it matters: This path connects the individual tools and chapters to the larger task of getting ML systems into production.
• Practical projects and transferable patterns: Explain that the book teaches production ML engineering through hands-on examples and two real-world-inspired projects, aiming to teach patterns and skills that apply beyond those particular projects.
  Why it matters: The projects are vehicles for learning reusable engineering practices, not ends in themselves.

Key terms: ML life cycle, MLOps, ML platform, ML pipelines, model serving, monitoring, hands-on examples, real-world scenarios, two real-world projects, patterns

1.1 The ML life cycle

Introduces the shared, iterative nature of ML projects and emphasizes that deployment is not the end of the work.

• Iterative ML project life cycle: Explain that ML projects generally follow similar development and deployment steps despite their differences, and that they tend to be more iterative than software projects focused on stability. Describe why a first deployment should not be treated as the end of an ML project.
  Why it matters: This framing helps you recognize deployment as one point in an ongoing ML life cycle.

Key terms: ML life cycle, iterative, deployment

1.1.1 Experimentation phase

This section traces the iterative experimentation phase of an ML project, from deciding whether ML fits the problem through preparing and versioning data, training, evaluation, and stakeholder validation.

• Iterative experimentation pipeline: Explain why the experimentation workflow loops back between steps and why the section recommends assembling those steps into an orchestrated pipeline.
  Why it matters: Experimentation is easier to repeat and troubleshoot when its steps are automated rather than handled manually.
• ML problem formulation: Explain how a team decides whether to use ML and then defines the particular problem the model should solve.
  Why it matters: A clearly chosen problem prevents a team from building a model where a simpler solution would suffice.
• Training data preparation: Describe how data is obtained, annotated, and organized for model experimentation.
  Why it matters: The model needs suitable labeled data both to learn and to be assessed.
• Data versioning for reproducibility: Explain why an ML experiment must account for data versions as well as code versions.
  Why it matters: A model’s behavior can change when its data changes, even if its code does not.
• Automated model training: Describe what training changes in a model and how automating defined training experiments helps.
  Why it matters: Automation makes repeated experiments easier to run and their results easier to reproduce.
• Evaluation and stakeholder validation: Distinguish assessing a model on data outside its training set from confirming that an evaluated model performs as expected for stakeholders.
  Why it matters: A measured score and acceptance by the people who need the model answer different questions.

Key terms: experimentation phase, iteration, orchestrated pipeline, automation, problem formulation, heuristics, high-dimensional data, data collection, synthetic data, annotations

1.1.2 Development/staging/production phase

This section explains how a working experimental model becomes an automated, deployed ML service that is monitored and retrained in production.

• Shift to production priorities: Explain how the focus changes from exploring and refining a model to deploying, maintaining, and improving it in a real-world setting, even though experimentation may continue.
  Why it matters: The change in focus determines the responsibilities and resources needed to keep a model useful in production.
• Automated production pipeline: Trace how a CI or programmatic trigger starts successive automated steps, including data versioning, training, evaluation, validation, and finally deployment. Describe how monitoring can trigger another run when performance falls below a threshold.
  Why it matters: An automated pipeline connects model development to repeatable deployment and improvement.
• Deployment and service readiness: Describe serving a trained model through an inference REST API, potentially containerized with Docker and deployed to a cloud platform. Explain why deployment also requires load testing, possible auto-scaling, versioning, and rollback plans.
  Why it matters: Making a model available is only part of ensuring customers can use it reliably.
• Production monitoring measures: Explain why evaluation results may not hold on live data and describe monitoring operational measures, ML-specific issues such as data and model drift, and business measures of the model's value.
  Why it matters: Monitoring reveals both service problems and declining model or business performance after release.
• Retraining triggers and automation: Describe retraining on a fixed schedule or when a measured threshold is reached, and explain why both training and subsequent deployment should be automated.
  Why it matters: Retraining helps only if a needed replacement model can move through the pipeline and into service.

Key terms: experiment phase, production phase, ethical constraints, security, scalability, robustness, continuous integration (CI), programmatic invocation, Data Versioning, Model Training

1.2 Skills needed for MLOps

This section frames ML engineering as a combination of skills that work together to create reliable ML systems, without requiring expertise in every domain from the start.

• Complementary ML engineering skills: Explain that building reliable ML systems draws on skills from different domains, and that an ML engineer should understand how those skills fit together rather than expect to master everything immediately.
  Why it matters: This perspective makes the range of skills ahead easier to approach and connects them to the goal of reliable ML systems.

Key terms: ML engineer, MLOps, reliable ML systems

1.2.1 Required skills for ML engineers

This section outlines the software engineering, ML and data, and automation skills that ML engineers need to build reliable systems.

• Production software engineering skills: Explain why ML engineers need experience deploying nontrivial software, debugging failures, and finding and fixing performance gaps.
  Why it matters: An ML model must work reliably as part of a deployed software system.
• Practical ML and data skills: Distinguish practical familiarity with ML frameworks from deep expertise in algorithm internals, and describe why the ML life cycle also calls for data engineering skills.
  Why it matters: Building a model is only part of the job; obtaining usable training data is often harder.
• Automation and reproducible experiments: Explain how automation reduces mistakes and speeds iteration, and why reproducible experiments matter across development, staging, and production, especially for auditing.
  Why it matters: Repeatable results make model behavior easier to verify and trust.

Key terms: software engineer, debugging, performance gaps, ML life cycle, TensorFlow, PyTorch, scikit-learn, training data, data engineering, automation

1.2.2 Prerequisites

This subsection reassures readers that they can learn the skills for ML engineering gradually and outlines the path from Kubernetes basics to an ML platform and ML systems.

• Incremental skill development: Explain that the range of ML engineering skills need not be mastered all at once because complex problems can be broken into manageable pieces.
  Why it matters: You can approach the book without feeling that you must already know every tool.
• Kubernetes to ML systems pathway: Describe the proposed sequence: learn Kubernetes basics, use them to set up an ML platform, then build ML systems on that platform, with a tour of MLOps tools to help readers get started without unnecessary detail.
  Why it matters: This sequence shows how the upcoming material builds toward working ML systems.

Key terms: manageable pieces, range of skills, Kubernetes, ML platform, ML systems, MLOps tools

1.3 Building an ML platform

The section introduces an ML platform as the foundation for reliable ML services and explains how the book will build one incrementally around Kubeflow.

• Incremental platform construction: Explain how the book starts with Kubeflow on Kubernetes, introduces notebooks and Kubeflow Pipelines, and adds components when use cases reveal gaps, such as a feature store.
  Why it matters: Building around real needs makes a complex platform easier to understand and adapt.
• Platform boundary and fit: Describe what the figure’s platform boundary separates from surrounding data systems, and explain why the depicted architecture is a guide rather than a one-size-fits-all design.
  Why it matters: The mental map helps you follow the book’s components without assuming every organization needs the same architecture.

Key terms: Kubeflow, Kubernetes, Jupyter Notebooks, Kubeflow Pipelines, feature store, ML platform, mental map, data warehouse/lake, batch/streaming processors, one-size-fits-all

1.3.1 Build vs. buy

This section explains why building an ML platform from scratch is worthwhile even when an organization already uses a vendor platform.

• Value of building a platform: Justify setting up an ML platform from scratch at least once, even if the organization already uses a vendor platform such as SageMaker or Vertex AI. Explain how integrating open-source tools teaches you to customize the platform, understand how its tools work together, and overcome limitations.
  Why it matters: Hands-on assembly gives you skills that using a ready-made platform may not develop.

Key terms: ML platform, build vs. buy, open source libraries, Amazon SageMaker, Vertex AI

1.3.2 Looking ahead: From MLOps to LLMOps

This subsection previews how a traditional ML platform extends to support LLMs and explains how to evaluate tool choices.

• Traditional platform and LLMOps extensions: Explain that the traditional MLOps platform remains the foundation for LLM systems, with added capabilities for document processing, retrieval, safety, prompt management, cost optimization, and specialized monitoring.
  Why it matters: The platform skills developed first—pipeline orchestration, deployment, and monitoring—still apply when the book turns to LLM systems.
• Pragmatic tool selection: Describe the book’s tool recommendations as starting points rather than definitive choices, and explain how short proofs of concept and use-case needs help select suitable tools.
  Why it matters: Trying a tool early can expose limitations before it becomes costly to change course.

Key terms: MLOps, LLMOps, vector databases, semantic search, guardrails, prompt management, proof of concept, open source tools, community support

1.3.3 Tools used in this book

This section introduces the tools and roles used to automate ML pipelines, share features, track models, and deploy ML services.

• Kubeflow pipeline components: Explain how Kubeflow Pipelines connects stages of the ML life cycle: each stage is a component that can receive data from an earlier component and pass results downstream.
  Why it matters: This is the basic pattern behind the automated pipelines built later in the book.
• Feature store serving modes: Describe how a feature store ingests already-transformed data, catalogs and stores reusable features, and serves them offline for training or batch inference and online for real-time inference. Explain how using a feature store helps avoid training-serving skew caused by differences between training and inference transformations.
  Why it matters: Reusable, consistently served features reduce duplicated preparation work and discrepancies between training and inference.
• Experiment tracking and model registry: Explain that MLflow tracks training runs and manages a model registry, capturing the trained model along with artifacts, metadata, and training parameters for reproducibility. Describe how the registry supports promoting models from staging to production and can supply a model served by an ML service.
  Why it matters: Recording what produced a model makes it easier to reproduce runs and manage which model reaches production.
• Automated model deployment flow: Trace the example deployment flow: a CI/CD trigger builds an ML service's Docker image and pushes it to a container registry; Kubernetes manifests reference that image and are applied to deploy the updated service. Explain that deployment makes a model available to receive inputs and return outputs, while raising portability, scalability, performance, and reliability concerns.
  Why it matters: The flow connects a model that works in development to an updated service others can use.

Key terms: Kubeflow Pipelines, pipeline component, downstream components, feature store, Feast, feature registry, feature storage, feature server, offline, MLflow

1.4 Building ML systems

This section introduces two contrasting ML projects as a way to practice transferable system-design patterns across the ML life cycle and into production operations.

• Contrasting ML project types: Describe the two kinds of systems the book will use—one involving images and one involving tabular data—and explain that their different challenges illustrate practices that can transfer to other projects.
  Why it matters: The examples are meant to teach reusable approaches, even if neither matches your own project.
• Project life cycle scope: Explain that the projects are approached like collaborative system-design work: they cover essential parts of the ML life cycle and end with operational concerns, including data and model monitoring and model explainability.
  Why it matters: A reliable ML system requires attention beyond building the model, especially after it is in operation.

Key terms: ML platform, ML systems, images, tabular data, ML life cycle, monitoring, data, model, model explainability, pair-programming

1.4.1 Introducing the ML projects

This subsection introduces three projects as a way to experience the full ML life cycle, including iteration, changing requirements, and the continued value of core MLOps concepts.

• Three-project learning approach: Describe how three projects provide experience with a range of real-world ML problems across the life cycle, from data preparation through monitoring and model retirement.
  Why it matters: The projects are intended to connect platform tools to the work of building ML systems from start to finish.
• Iterative project progression: Explain that ML projects revisit earlier steps when results disappoint and that evolving requirements can prompt a change in tools or techniques. Describe how the book’s projects progressively introduce tools, reusing some while considering alternatives to others.
  Why it matters: Real ML work requires revising both the solution and the tools rather than following a fixed sequence once.
• Adaptable MLOps framework: Explain why core MLOps concepts remain useful across ML project types, domains, and stages even when particular life-cycle steps are skipped or combined.
  Why it matters: The concepts provide a way to structure large ML projects without treating the life cycle as a rigid recipe.

Key terms: three projects, ML life cycle, model retirement, iterative, data preparation, Kubeflow Pipelines, project requirements, core MLOps concepts, ML project life cycle, engineering framework

1.4.2 ML projects

The section introduces three projects that show how ML platform practices apply to image detection, tabular recommendations, and a retrieval-augmented documentation assistant.

• Image and tabular projects: Describe the OCR and movie recommender projects, including how their data types shape the work: the OCR project builds a labeled ID-card dataset, trains and fine-tunes a detector, then deploys it as a service; the recommender uses tabular data to explore feature stores, drift detection, model testing, and observability.
  Why it matters: These two projects provide different settings for applying the same ML engineering ideas.
• RAG documentation assistant: Describe DakkaBot as a natural-language assistant for company documentation and trace its planned path from document ingestion and vector embeddings to retrieval-augmented generation. Explain that it extends the earlier MLOps foundation with document processing, semantic search, prompt engineering, and production concerns such as safety, cost, and evaluation.
  Why it matters: DakkaBot shows which familiar production practices carry over to LLM applications and which new concerns arise.

Key terms: OCR, ID cards, movie recommender, tabular data, feature stores, drift detection, DakkaBot, Retrieval-Augmented Generation, RAG, document ingestion

1.5 Summary

The chapter summary connects the iterative ML life cycle, complementary engineering skills, and platform tools to the book’s projects and its later extension from MLOps to LLMOps.