Monmayuri Ray defines AI as a reduction in the cost of machine prediction and MLOps as a way to reduce the cost of machine prediction transactions.
2
CI/CD for MLOps coordinates data scientists, machine learning engineers, and DevOps engineers through training, deployment, and the rest of the machine learning lifecycle.
3
Teams should start with the business outcome and their current practices before choosing a maturity framework, automating work, or selecting tools.
Summary
Monmayuri Ray explains CI/CD for MLOps through economic, technical, and organizational examples. She describes AI as lowering the cost of machine prediction, while MLOps lowers the cost of the transactions around those predictions. In practice, CI/CD creates an automated way for data scientists, machine learning engineers, and DevOps engineers to collaborate across training, model registration, scoring, containerization, and deployment. Ray is direct about the obstacles. Many data scientists still train models on laptops, version models in spreadsheets, or document experiments in large Google Docs. YAML and Git-based workflows can feel foreign to them. She recommends starting with the desired judgment, action, and outcome, then mapping the existing workflow and maturity before deciding what to change. Automation should give people controlled freedom rather than remove every choice. She also questions vendor claims about best practices, separating concrete recommendations such as version control and continuous training from opinions presented as universal rules.
CI/CD reduces the cost of machine prediction transactions
Ray begins with an economic definition. She describes AI as a drop in the cost of machine prediction, which leads people to use more machine prediction and rely on human judgment as a complement. MLOps moves toward cheaper, increasingly automated machine prediction transactions while keeping human judgment in the decision process. Her technical definition is a continuous, orchestrated way for data scientists, machine learning engineers, and DevOps engineers to collaborate across training, deployment, and the wider machine learning lifecycle. The point is not only to automate a model algorithm. It is to connect the model to the full software development workflow.
MLOps has to fit the whole software delivery system
Ray says a machine learning application can include a front end and other software, so its pipeline must fit into the larger development system. A model may be one part of hundreds of software pipelines. CI/CD has to coordinate the path from continuous training to deployment, while integrating with the surrounding development and operations workflow. She frames this as a longer software development cycle rather than a separate machine learning activity. The practical question is where the machine learning component sits, how it connects to the rest of the application, and how the team orchestrates those dependencies.
Teams should replace an existing strategy deliberately
When companies describe themselves as AI-first, Ray asks what strategy came before and what the new strategy is replacing. She compares this with Google's shift from mobile-first to AI-first. Companies are at different points in application modernization, DevOps adoption, and machine learning deployment, so the right approach depends on their priorities, culture, and people. Ray recommends learning from DevOps culture, sharing knowledge across roles, and starting small. Data scientists may not know Git-based workflows, while DevOps engineers may not understand what makes a model different from a conventional software artifact. Both groups can work together if the organization creates space for that exchange.
The business outcome comes before the maturity framework
Before discussing MLOps or DevOps frameworks, Ray asks what prediction engine the team is building, where judgment enters, what decision follows, and what outcome the system must produce. She maps those questions across data collection, training, feedback, architecture, governance, and the wider workflow. Only after understanding that outcome does she recommend assessing maturity and mapping a journey with a framework. She describes maturity in terms such as crawling, walking, running, or flying. The order matters because a maturity label without a clear business outcome does not tell a team what to change or why.
Automation brings cultural and educational obstacles
Ray describes a workflow in which a code commit triggers a CI pipeline that retrains a model, registers it, scores it, and then passes an accepted result to continuous delivery for containerization and deployment. Many data scientists understand this at a high level but have difficulty adopting it in production. Some still train models on laptops. A second obstacle is YAML. DevOps engineers may treat a CI YAML file as ordinary, while data scientists can see it as unfamiliar and intimidating. Ray argues that tools should make this work friendlier and let data scientists focus on their own work instead of requiring every person to become a YAML expert.
Existing manual practices can be useful starting points
Ray recalls a client who managed model versions with spreadsheets. She also accepts that a spreadsheet or a large experiment document can be an improvement over having no record at all. The goal of modernization is not to replace every familiar practice immediately. Teams should respect what already works and add structure where the current method will stop scaling. A spreadsheet may be adequate for a small number of models, but Ray expects it to reach a limit as data and model counts grow. CI/CD can reduce future risk by introducing repeatable processes before manual discipline becomes impossible.
Ray describes the balance between enabling people and keeping guardrails in place as controlled freedom. Tools should let data scientists work independently while the wider system maintains governance. She connects this to decisions about Kubernetes, containers, serverless systems, and other infrastructure choices. The right level of automation depends on which work is repetitive and which work still needs human creativity. Automation should remove repeated tasks without taking away the ability to respond to new problems. The same reasoning applies to deciding which part of an MLOps workflow to automate first and which parts should remain visible to the people doing the work.
Vendor best-practice claims need careful examination
Ray questions the claim that a vendor has every best practice built into its product. She says the field is still working out how to apply DevOps practices to machine learning, so universal claims deserve scrutiny. She prefers specific recommendations, such as version control, collaboration between data engineers and data scientists, and continuous training, over the broader label of best practice. Teams should ask which parts are automated, which parts remain manual, and how a tool fits their existing workflow and computing costs. The term can become confusing when opinions are presented as settled rules.
"MLOps is a movement that gets us closer and closer every day to cheap, almost automated machine prediction transactions."08:21
Who should watch
You are bringing DevOps engineers into machine learning delivery and need a shared way to discuss models, pipelines, and deployment.
Your data science team still relies on laptops, spreadsheets, or documents for training and experiment tracking, and you need to decide what to automate first.
You are evaluating MLOps vendors that claim to include best practices and want questions that separate concrete workflow support from marketing language.
