Ultimate DevOps to MLOps Bootcamp - Build ML CI/CD Pipelines

This lecture walks through the complete local environment setup you need before writing any code: minimum hardware requirements (2 CPU cores, 4GB RAM, 10GB disk, with 4-8GB RAM recommended), Docker or Podman for containerizing the model, MLflow, and the FastAPI and Streamlit apps, and dev tools including Git, a terminal, and Visual Studio Code with Python, Jupyter, and Docker extensions. You'll see a live walkthrough of validating Python, pip, and Git installations, plus installing UV, a fast, Rust-based Python package and virtual environment manager used throughout the course instead of conda or a standard venv. We also cover why per-project virtual environments matter for avoiding dependency conflicts between projects. This sets up the next lessons, where you'll install Docker or Podman, set up the project repository, and configure MLflow for experiment tracking.

This lecture shows you how to set up a Python virtual environment with UV, the fast, Rust-based package and environment manager used throughout this project, so you can run the course's Jupyter notebooks with the correct Python version and library dependencies. You'll see how to initialize a virtual environment pinned to a specific Python version with uv venv, activate it, and confirm the version change with python --version. We then install all required libraries, data manipulation, numeric operations, scikit-learn, XGBoost, and visualization tools, defined in a requirements.txt file, using uv pip install -r requirements.txt, watching UV install dozens of packages significantly faster than pip or conda. You'll also learn why the venv directory is added to .gitignore, keeping the virtual environment out of version control while your dependencies stay pinned and reproducible. This lecture is essential for anyone setting up isolated, reproducible Python environments for machine learning projects.

This lecture walks you through installing and validating Docker (or Podman) and Docker Compose, the container tooling used throughout this MLOps Bootcamp for packaging models, running MLflow, and later deploying to Kubernetes. You'll learn how to create a Docker Hub account for storing and distributing model and application artifacts, download Docker Desktop, and validate the install by running docker version and checking for both client and server output. We also cover an important licensing consideration: Docker Desktop's free tier doesn't cover most business use, so if you're on a work laptop, Podman Desktop is presented as a fully Docker-compatible, alias-friendly alternative with no such licensing restrictions. Finally, you'll see why Docker Compose is essential for running multiple connected containers, like a FastAPI model server and its client app, and for setting up local dev container environments. This sets up the next lesson, where you'll clone the project repository and launch MLflow with Docker Compose.

This lecture walks through the House Price Predictor project scaffold so you know exactly what goes where before building out the MLOps pipeline. You'll see the data directory (raw and processed CSV data), Jupyter notebooks used by data scientists for exploratory analysis and feature engineering, and the src directory where machine learning engineers convert notebooks into production scripts for data processing, feature engineering, and model training. We cover the model config file, the key handoff artifact between data scientists and ML engineers, the models directory where trained models and preprocessors are stored, and the FastAPI application that wraps the trained model for inference, packaged with a Dockerfile and paired with a Streamlit app for prototyping and visualization. Understanding this structure is essential for MLOps engineers, since in most real organizations the model, notebooks, and application code already exist, and your job is to containerize, package, deploy, and monitor them in production.

This lecture walks you through forking and cloning the House Price Predictor project repository, then launching MLflow, the open-source experiment tracking tool you'll use throughout the course to log models, compare algorithms, and monitor training metrics. You'll fork the upstream repository to your own GitHub account (required so you can commit your own changes), clone it locally, and navigate to the deployment/mlflow directory. From there, you'll launch MLflow with a single docker compose -f command, troubleshoot port conflicts (the project defaults to port 5555 to avoid clashing with services on port 5000), and validate the container is running with docker compose ps. Once MLflow is up, you'll access its web UI locally to explore experiment tracking, model comparisons, and performance charts, setting the stage for the model training and experimentation work coming up. This lecture is essential for anyone setting up a real MLflow tracking server with Docker Compose.

This lecture shows you two ways to open and work with the Jupyter notebooks in the House Price Predictor project: launching a standalone JupyterLab server, and running notebooks directly inside VS Code using your UV virtual environment. You'll see how to install and launch JupyterLab, open existing data engineering, EDA, and feature engineering notebooks, and understand why notebooks (built from cells) differ from plain Python scripts, since a single notebook can mix Python, markdown, shell commands, and even R or SQL cells in one flow. We also cover selecting the right kernel and Python environment so notebooks execute with your project's dependencies, debugging a broken file path by editing and re-running a cell, and why running notebooks in VS Code is often simpler than switching to a separate JupyterLab browser tab. This lecture is essential for getting comfortable with notebook-based data science workflows before diving into data engineering and feature engineering.

This wrap-up lecture recaps everything covered in the Use Case and Environment Setup module: understanding the House Price Predictor use case and MLOps workflow, validating your hardware, Python, VS Code, and dev tool setup, installing Docker or Podman as your container runtime, launching MLflow with Docker Compose for experiment tracking, and exploring the project's code scaffold, notebooks, and data directories. It reinforces why setting up a proper Python virtual environment with UV matters for reproducible dependency management, and encourages you to experiment with the provided Jupyter notebooks in VS Code before moving forward. This summary closes out the foundational setup module and previews what's next: diving into data engineering, exploratory data analysis, and feature engineering, where you'll build hands-on MLOps skills with the annotated code provided in the course.

This module intro sets the stage for exploring data science and machine learning from a DevOps engineer's perspective. Just as a DevOps practitioner needs to understand an application's language, build tools, and workflow to contribute effectively, you'll learn how data scientists and data engineers work so you can collaborate meaningfully as an MLOps engineer rather than working in a silo. You won't be writing heavy data science code, instead, you'll explore the existing project notebooks hands-on and learn core concepts like feature engineering, model experimentation, and the resource requirements behind running experiments. This lecture frames the ML workflow, from making sense of raw data to producing a trained model, that you'll dive into throughout this module covering data engineering, exploratory data analysis, and feature engineering.

This lecture explores the raw-to-clean data journey from a data engineer's perspective, using the House Price Predictor dataset as a hands-on example. You'll learn what data engineers actually do: sourcing data (from transaction logs, third-party sources, or platforms like Kaggle), checking for null values and data type issues, running sanity checks like rejecting negative prices or square footage, analyzing statistical distributions with pandas and matplotlib, detecting and removing outliers, and dropping duplicates. Using a Jupyter notebook, you'll walk through loading the raw CSV data, exploring its shape and structure, and running a real data-cleaning script that filters extreme outliers and writes out clean, processed data, watching the dataset shrink as skewed values are removed. This lecture gives DevOps engineers transitioning into MLOps a practical, high-level understanding of data engineering fundamentals, since data quality directly determines model accuracy and performance.

This lecture puts you in the shoes of a data scientist performing exploratory data analysis (EDA) on the cleaned House Price Predictor dataset. Using a pre-built Jupyter notebook and the same virtual environment set up earlier, you'll load the data, review its shape and statistical summary, and visualize the distribution of house prices with matplotlib. You'll build a correlation heatmap to see which features, like square footage and number of bathrooms, most strongly relate to price, create scatter plots to confirm linear relationships, and use bar charts to check how balanced the data is across locations and bedroom counts. This hands-on walkthrough shows how data scientists use EDA to decide which features matter, whether a relationship is linear, and which algorithm and hyperparameters to consider next, giving DevOps engineers transitioning into MLOps a practical understanding of the data science workflow before diving into feature engineering.

This lecture breaks down what feature engineering actually means, using the House Price Predictor dataset to demonstrate the core techniques. You'll learn how to derive new engineered features from existing columns, like price per square foot, property age from year built, and a bed-to-bath ratio, and understand why the same transformations must be replicated in a preprocessor at inference time. We also cover splitting a single feature into multiple ones, such as breaking an address into street, city, and zip code, and why that matters for capturing location-based pricing trends. Finally, you'll learn about encoding, converting categorical values like small, medium, and large into numbers machines can understand, including one-hot encoding and how this concept extends to vector embeddings used in LLMs and vector databases. This lecture builds the conceptual foundation before you apply these feature engineering techniques hands-on in the project notebooks.

This hands-on lecture walks through applying feature engineering concepts directly in a Jupyter notebook using the cleaned House Price Predictor dataset. You'll build three new engineered features from the existing columns: house age (current year minus year built), price per square foot (price divided by square footage), and bedroom-to-bathroom ratio, complete with error handling for division. You'll visualize the distribution of each new feature with matplotlib, understand why price per square foot is a strong standardized metric for comparing properties, and save the engineered dataset for the next step. This lecture also highlights a critical MLOps consideration: any feature engineering logic applied here must be replicated in a preprocessor at inference time, since new incoming data won't already have these derived columns. By the end, you'll have a feature-engineered dataset ready for model experimentation.

Set up a list of candidate algorithms — linear regression, random forest, gradient boosting, XGBoost — and define the hyperparameter grid each one should search over. You will see how to give parameters like number of estimators and learning rate a min-to-max range, wire the grid into GridSearchCV with cross-validation, and pick the regression scoring metrics that decide the winner. By the end you can build a tuning grid that hands back the best model and its parameters, all tracked in MLflow.

Run the full experiment across every algorithm and read the results together — R-squared, RMSE, mean error in real dollar terms — to see why gradient boosting comes out ahead. You will re-run with tweaked hyperparameters like more estimators and watch how that changes both accuracy and compute cost, then compare every run side by side in MLflow. You walk away able to run hyperparameter tuning, choose the best model, and export a model config that the ML engineer picks up for training.

Walk through the handover point where the data scientist's model config and notebooks become the ML engineer's job. You will see how notebooks get turned into proper feature-engineering and training scripts, why a pickle model file needs a FastAPI wrapper before anyone can call it over REST, and where Streamlit fits for a quick client UI. By the end you understand the containerization goal for the module — packaging both services with Dockerfiles and a Docker Compose spec for local dev.

Turn the experimentation notebook into a lean training script that skips the expensive search and just trains the one chosen model from the config the data scientist handed over. You will run train_model.py against the model config and dataset, watch it train gradient boosting fast, and see the trained model plus preprocessor land as files while the run registers in MLflow. You come away able to retrain on demand with fixed hyperparameters and produce a deployable model pickle.

Write a Dockerfile that packages your trained model together with its FastAPI service into one container image. You will see why the Dockerfile goes at the repo root, not inside src/api, so the build context can reach your model files, and how to copy the code, install requirements.txt, expose port 8000, and launch the app with uvicorn. By the end you can build the image and know how to check where the pickled model needs to sit inside the container.

The container built fine but crashes on a pickle load error, and here you learn the exact way to track it down: read the logs, run the image with an interactive bash shell, check the copied files, and reproduce the failure by hand. You will trace the root cause to a numpy, scikit-learn, and joblib version mismatch between training and serving, pin the requirements, rebuild, then validate the running FastAPI through /docs and a curl request that returns a real price prediction.

Package the Streamlit front end as its own container image, keeping the Dockerfile inside the streamlit_app directory since no model files are needed this time. You will copy app.py and requirements.txt, expose port 8501, launch with streamlit run, then tag the image with your Docker Hub username and push it to the registry with docker login and docker image push. By the end you can build, test-run, and publish a Streamlit image, and you will see why it still needs the FastAPI endpoint wired in.

Read through the FastAPI app that wraps the trained model and exposes health, predict, and batch-predict endpoints, plus the inference code that loads the model and preprocessor and returns a prediction. You will see how the preprocessor rebuilds the engineered features an incoming request is missing, and how the Streamlit client talks to the API through an API_URL environment variable — a detail that matters once you containerize. By the end you understand the full request-to-inference path before packaging both apps into containers.

Tie the FastAPI model service and the Streamlit app together in a single docker-compose.yaml so any teammate can launch the whole stack with one command. You will write the services block with build context, image tags, and ports, and pass the API_URL environment variable so Streamlit reaches FastAPI by service name instead of an IP address. After docker compose build and up, you test live predictions end to end and push both images to Docker Hub, solving the classic 'works on my machine' problem.

Once your app is containerized, the next step is automating the build, test, and publish steps in a pipeline, and this module sets up that workflow for MLOps. You will see why this is a CI workflow and not CI/CD (real continuous delivery starts later with Kubernetes and tools like Argo CD or Flux), and where DAG-based tools such as Argo Workflows, Kubeflow, Metaflow, and Airflow fit. The module uses GitHub Actions as the simplest starting point, with guidance on when to reach for heavier tools.

Get a clear mental model of GitHub Actions before writing any YAML: events that trigger a run (on: push to main, pull requests, schedules, tags), jobs that map to your pipeline stages, runners that give each job a fresh Ubuntu sandbox, and the steps inside a job. You will learn the difference between uses (pre-built actions like checkout and setup-python from the Marketplace) and run (your own scripts), plus the with option for passing inputs such as a Python version, so you can read and structure a workflow file.

Write your first working workflow file under .github/workflows and watch it run on GitHub. You will scaffold the name, on: push trigger, and a job that checks out the code, sets up a pinned Python version, and installs dependencies, then commit selectively (Dockerfiles, compose, configs) and push so Actions picks it up. Along the way you will catch a common mistake (the workflows directory needs the trailing 's') and confirm a green run, setting the commit-push-observe loop you will reuse for every later stage.

This lesson extends our MLOps CI workflow in GitHub Actions by adding data processing, feature engineering, and model training steps to the pipeline. We reuse the existing Python scripts for cleaning raw house price data, generating engineered features, and training the regression model, wiring each one into its own workflow step from the repository root. After committing and pushing the updated YAML, we watch the GitHub Actions run in real time: the data processing and feature engineering jobs complete successfully, producing clean and feature-ready datasets, but the model training step fails with a connection refused error because MLflow experiment tracking isn't running inside the CI runner. This lesson demonstrates practical CI/CD debugging for machine learning pipelines and sets up the MLflow tracking fix covered next, making it a useful reference for GitHub Actions, MLOps automation, and CI pipeline troubleshooting.

Here we fix the MLflow connection error from the previous lesson by launching an MLflow tracking server directly inside the GitHub Actions runner using Docker. We add a setup step that pulls the MLflow image and starts the container with docker run, mapping it to a local port so the training script can reach it, followed by a cleanup step that stops and removes the container and image once the job finishes. Along the way we debug a real YAML indentation error that breaks the workflow file, showing how to read GitHub Actions error messages and locate the exact failing line. After the fix, the full pipeline runs end to end: data processing, feature engineering, and model training all succeed, producing a trained model pickle file ready for packaging. This lesson is a hands-on guide to running MLflow in CI, fixing GitHub Actions YAML syntax errors, and building reliable automated ML training pipelines.

With training working, this lesson adds container image build and publish stages to the GitHub Actions pipeline using the Docker Build and Push action from the GitHub Marketplace. We walk through the marketplace listing, compare running raw docker build/push commands versus using a dedicated action, and configure Docker Hub login, build context, and Dockerfile path as workflow inputs. A key best practice covered here is tagging images with the unique GitHub commit SHA instead of the latest tag, so every build produces a traceable, immutable image version. We also preview the need for Docker Hub username and access token secrets, setting up the next lesson on configuring registry credentials securely. This is a practical walkthrough for anyone learning to automate Docker image builds and publishing inside CI/CD pipelines using GitHub Actions for machine learning or general application delivery.

A recap of the MLOps CI pipeline you built iteratively with GitHub Actions, from triggers, jobs, and runners to a realistic multi-stage, modular workflow that mirrors how real pipelines are written. You will leave clear on why this is CI and not CI/CD: it builds and publishes the image to a registry like Docker Hub, but deployment hasn't happened yet. That deployment story, and your move into Kubernetes, starts in the next module.

Understand why Docker Compose is fine for local dev but not for production inference, and why you move to Kubernetes to scale a model service horizontally as requests grow from thousands to millions. You will see how Kubernetes gives you scalability, availability, load balancing, and fault tolerance by default, and how its ecosystem (Seldon Core, Prometheus) supports advanced rollout strategies like A/B, canary, blue-green, and shadow deployments. This sets up deploying your FastAPI model and Streamlit app with native Kubernetes primitives.

Learn the Kubernetes building blocks you need to serve a model: the pod as the unit of deployment (and when to co-locate a sidecar like a monitoring exporter with your model), deployments that maintain replicas for scaling and availability and enable versioned rollouts, and services for exposing pods externally or wiring them together internally by DNS name. You will understand why Streamlit and the FastAPI model run as separate pods so they scale independently, ready to write your first deployment and service manifests.

Deploy your Streamlit frontend on Kubernetes using kubectl create deployment, and watch how a Deployment spins up a ReplicaSet that keeps your pods running. You will scale the frontend up and down with kubectl scale, delete pods to see them come right back, and understand how Deployments give you scalability and self-healing for your inference stack.

Deploy your FastAPI model on Kubernetes with its own Deployment and a NodePort service, running two stateless replicas. You will map container port 8000 to a NodePort, see how the service load balances requests across pods, and reach the FastAPI docs endpoint to confirm the model is live and serving predictions.

Turn your imperative kubectl create commands into reusable YAML manifests using the --dry-run=client -o yaml trick. You will generate Deployment and Service specs for both the model and Streamlit, save them into your project, and understand the apiVersion, kind, metadata, and spec structure so you can version control everything and later ship it with Argo CD.

Get a map of this autoscaling module before you build it. You will see how horizontal pod autoscaling, vertical pod autoscaling, and KEDA fit together, and why you first set up Prometheus and Grafana for monitoring. These same scaling techniques work for any Kubernetes workload, not just ML models.

See the goal for this module: scale a FastAPI model deployment based on incoming prediction requests. You will learn why you need a Prometheus and Grafana monitoring stack to track latency and request rates from the baked-in model, and how capacity scaling differs from ML monitoring concerns like data drift and bias detection.

Install a full monitoring stack on Kubernetes using Helm and the kube-prometheus-stack chart from Artifact Hub. You will add the Prometheus community repo, run helm upgrade --install into a monitoring namespace, and expose Grafana and Prometheus on NodePorts. One command brings up the pods, services, and prebuilt dashboards you need to start monitoring.

Log in to Grafana and explore the dashboards the kube-prometheus-stack ships with, from cluster and node metrics to per-namespace CPU and memory. You will see how Prometheus acts as the time-series data source behind Grafana, run PromQL queries directly, and understand what FastAPI model metrics you still need to add for scaling decisions.

Understand how Kubernetes autoscaling works before you configure it. You will compare horizontal scaling with the Horizontal Pod Autoscaler against vertical scaling with the Vertical Pod Autoscaler, see why resource requests and limits matter, and learn how KEDA and its scalers let you scale on custom metrics from Prometheus, not just CPU and memory.

Install KEDA with Helm into its own namespace and prepare your model deployment for autoscaling. You will add resource requests and limits to the pod spec in model-deploy.yaml, apply the change, and confirm the redeployed pod carries the millicore CPU and memory limits KEDA needs to make smart scaling decisions.

Watch a real debugging session where Prometheus stops scraping metrics during load tests, and see how to work through it with ChatGPT by feeding it the scaled object, service monitor, and target configs. You will learn to run FastAPI metrics on a separate thread and port, expose it in the Dockerfile and Kubernetes service, and point the ServiceMonitor at the new metrics endpoint to fix the data gaps.

Set up a Vertical Pod Autoscaler for your model deployment and watch it right-size CPU and memory requests instead of just adding more pods. You will install the VPA controller in the kube-system namespace, write a VPA config with min and max resource ranges, and run it alongside your Keda-driven HPA. After this you can tune resource requests and limits automatically and decide when horizontal and vertical scaling work best together.

A recap of the observability and autoscaling module: installing Prometheus and Grafana with Helm, instrumenting your FastAPI model wrapper for latency and request metrics like p95, and scaling with Keda-based HPA plus a Vertical Pod Autoscaler. You will leave with a clear picture of how monitoring feeds scaling decisions, and how the same approach applies to ML models and gen AI apps running on Kubernetes.

GitOps has become the default way to handle release engineering and continuous deployment on Kubernetes. This intro sets up what the module covers: what GitOps is, why it fits ML model deployment, and how Argo CD puts it into practice. You will know what to expect before moving from concepts into hands-on implementation.

Learn the four principles of GitOps: declarative configuration, storing desired state in Git, applying approved changes through a pull-request workflow, and using a software agent like Argo CD or Flux to continuously reconcile the cluster. You will see how these principles map onto deploying a containerized ML model wrapped in FastAPI, and how the same ideas extend beyond Kubernetes to infrastructure-as-code tools.

Put GitOps principle two into practice by getting all your Kubernetes manifests under Git version control. You will check status, commit and push your model, Streamlit, Keda scaled object, VPA, and service monitor YAML, organize them with Kustomize, and set up main and release branches with a pull-request flow. After this your repository holds the desired state, ready for Argo CD to deploy from.

Understand how the Argo CD Application custom resource works: a source pointing at your Git repository and branch, and a destination cluster and namespace to deploy into. You will see why Application is a CRD rather than a native Kubernetes object, how to list it with kubectl get crds, and how the application controller keeps your cluster in sync. This prepares you to define deployments without hand-writing much YAML.

A wrap-up of the GitOps module: the four principles, writing manifests as code, version controlling them in Git, adding branch-based workflows, and running Argo CD as the agent that deploys to Kubernetes. You will see how this final piece connects your ML CI workflow to automated continuous delivery, and where to go next with Argo rollouts, events, and release strategies.

This lecture breaks down what MLOps actually is and why most machine learning projects fail to reach production. We explore the gap between the data science world of Jupyter notebooks and clean, static datasets, and the real world of scale, latency, and constantly drifting data, using a restaurant analogy to explain why consistency and repeatability matter. You'll learn the five core MLOps practices: revision control for code, models, and data (including tools like DVC and MLflow), pipeline automation with CI/CD, orchestration with Kubernetes and Argo, continuous monitoring for model and data drift, and governance. We also cover the ML lifecycle from experimentation to training, deployment, and retraining, MLOps maturity models, real-world case studies from Netflix, Uber, Airbnb, and Facebook, and how MLOps is evolving into LLMOps and Agentic AI Ops as foundation models and autonomous agents reshape AI operations.

This lecture traces the historical evolution from MLOps to LLMOps to Agentic AI Ops, starting with the first neural networks in the 1960s, the AI winter, and the rise of expert systems in the 1980s. We cover the deep learning breakthrough led by Geoffrey Hinton, the growth of GPU and TPU compute power, and how DevOps principles gave birth to MLOps between 2015 and 2018 with practices like version control, CI/CD for ML, monitoring, and governance. You'll then see how the transformer architecture and the 'Attention Is All You Need' paper led to GPT and the large language model revolution, introducing new LLMOps challenges around prompt engineering, fine-tuning, vector databases, embeddings, semantic search, and retrieval augmented generation (RAG). Finally, we look ahead to Agentic AI Ops, autonomous agents, agent-to-agent communication protocols, and why AI platform engineers need skills spanning MLOps, LLMOps, and Agentic AI operations.

This lecture compares three approaches to AI, traditional machine learning, large language models, and Agentic AI, and explains when to use each and how to operationalize them with MLOps, LLMOps, and Agentic AI Ops. You'll see where traditional ML still excels (fraud detection, demand forecasting, recommendation systems, image classification), where LLMs shine (content generation, translation, chatbots, prompt engineering, RAG, vector databases), and where autonomous agents take over (multi-step workflow automation, tool integration, task planning, orchestration). We break down the core components and unique challenges of each: data drift and model reproducibility in MLOps, hallucinations and context and token limits in LLMOps, and reasoning failures and safety guardrails in Agentic AI Ops. The lecture also debunks common myths, such as 'MLOps is just DevOps for ML', covers how to evaluate performance for each approach, and looks at the road ahead including AutoML, edge deployment, fine-tuning, and multi-agent orchestration for AI platform engineers.

This lecture walks through real-world MLOps case studies from Netflix, Uber, and OpenAI. You'll learn how Netflix built Metaflow, a Python-based workflow framework, to give data scientists a faster, more consistent path from experimentation to production, and how Uber's Michelangelo platform centralized feature management and scaled batch predictions 10x across ride pricing, ETA, and driver-rider matching models. We also cover how OpenAI tackled hallucinations in ChatGPT using RLHF (reinforcement learning from human feedback) and a reward model, cutting hallucinations by 40% and improving safety by 63%. The lecture closes with practical lessons on MLOps industry adoption across fraud detection, demand forecasting, document processing, and agentic use cases, plus common pitfalls to avoid, and a quick self-assessment for scoring your own organization's model versioning, deployment automation, monitoring, and collaboration maturity.

This lecture tackles the emerging question of who actually does MLOps in an organization: data scientists, DevOps engineers, or a new specialist entirely? We walk through the AI application lifecycle, from data engineering and experimentation to deployment and monitoring, and explain why 87% of ML projects never reach production. You'll see two organizational models compared, the full-stack data scientist approach versus cross-functional teams with data engineers, data scientists, ML engineers, and MLOps engineers, and why cross-functional teams scale better and reduce burnout. We define two clear career streams: the MLOps practitioner (machine learning and AI engineers who apply MLOps practices) and the MLOps engineer, or AI platform engineer, who owns infrastructure, CI/CD, Kubernetes, and tooling across MLOps, LLMOps, and Agentic AI Ops.

This lecture breaks down how MLOps compares to traditional DevOps and where the two diverge. We start with DevOps fundamentals, infrastructure as code, CI/CD, monitoring and observability, and the plan-code-build-test-deploy lifecycle, then explain why MLOps emerged as its own discipline instead of just being "DevOps for machine learning." You'll learn about the added complexity of data dependency, model drift, experiment tracking, and model versioning and lineage, plus how testing, monitoring, and deployment differ when you're shipping trained models instead of application binaries. We cover the expanded MLOps lifecycle, including data engineering, feature engineering, and experimentation, the layered MLOps platform (infrastructure, data, model, and monitoring layers), and the tooling shift from Git, Terraform, and Prometheus/Grafana to DVC, MLflow, Kubeflow, Argo Workflows, Feast, and model serving tools like TensorFlow Serving, Seldon Core, KServe, and BentoML. We close with the skill-gap opportunity for DevOps engineers moving into MLOps, LLMOps, and Agentic AI Ops.

Understand linear regression through a house price prediction example — how square footage, bedrooms, and age combine into a formula that plots as a straight line. You will learn when regression fits a problem (predicting continuous numbers like prices, temperature, or sales from ad spend) and when it does not. By the end you can spot the kind of simple, explainable prediction task where linear regression is the right first choice.

See how logistic regression handles yes-or-no questions using a disease diagnosis example, where patient risk factors feed an S-shaped curve that outputs a probability between 0 and 1. You will learn what a decision boundary is and how it splits low-risk from high-risk cases. This gives you the judgment to reach for logistic regression on classification problems like spam filtering, loan approval, or fraud detection.

Learn random forest as a second-opinion problem — instead of trusting one decision tree, you ask many and take the majority vote. You will see how each tree gets a slightly different view of the data, why voting cancels out individual bias, and how this reduces overfitting so the model holds up on new inputs. You come away knowing when random forest beats a single tree for tasks like credit risk, fraud, and recommendations, and why data scientists test it against other candidates before committing.

Understand support vector machines through a fruit-sorting example, where SVM draws a clear decision boundary with the widest possible margin between ripe and unripe. You will learn why SVM shines when data is limited or costly to collect and when you need a clean separation between two groups. By the end you can identify good SVM use cases like image classification, text categorization, handwriting recognition, and defect detection.

See how neural networks recognize handwritten digits by passing pixel input through hidden layers that build up from simple edges and curves to full patterns, then predict with a confidence score. You will understand why layered networks handle messy, variable data that fixed rules cannot, and how this same idea underpins large language models and foundation models like GPT. This helps you judge when to reach for neural networks — complex patterns, multimodal image, speech, and text data, and lots of it — and accept lower explainability for higher accuracy.