MLOps applies engineering practices to the full machine learning build, deployment, and monitoring lifecycle, which includes data, training, serving, and changing inputs.
2
Machine learning differs from ordinary software because models are produced from data and code, training is often stochastic, and large datasets and serialized models create different build and packaging problems.
3
Teams should define their use case and constraints before choosing tools, including data quality, serving mode, retraining, drift, explainability, team skills, and budget.
Summary
Ryan Dawson explains why MLOps overlaps with DevOps but cannot be reduced to it. Traditional software starts with code and produces an executable or web service. A machine learning project starts with data and a question, then adds data preparation, training, experiment tracking, model packaging, serving, and monitoring. The model can change when data changes, and live data can drift away from the training distribution. Ryan uses salary benchmarking and fashion recommendations to show why a one-off prediction can become a recurring production service. He also describes Seldon's approach to serving models on Kubernetes, including inference graphs and integrations for monitoring and drift detection. The conversation ends with practical scoping questions. Teams should first understand their use case, then decide whether they need real-time or batch predictions, retraining, explainability, or a larger platform. Ryan is careful not to prescribe one stack because the right choice depends on the problem, existing skills, and budget.
Ryan defines MLOps as what is needed to make the machine learning build, deploy, and monitor lifecycle smooth and safe. The aim is to let teams focus on machine learning and business value instead of repeatedly solving operational problems. He says these challenges are underestimated when people from traditional DevOps do not see the full machine learning lifecycle. The conversation also separates small projects from larger platforms. A company with a few simple models may stitch together a small set of tools, while a larger company with many models may need a broader platform.
DevOps practices apply to ML, but treating the systems as identical hides the work
David and Ryan agree that machine learning should be treated as an engineering discipline and that many DevOps practices still apply. The problem begins when that overlap is taken to mean the systems are the same. Ryan points to the different starting point, the wider lifecycle, and the range of production use cases. David adds that companies can underestimate the work and spend time building an internal solution without understanding the requirements. Ryan says the industry is still experimenting with standards, and open source collaboration may help those standards form.
The machine learning build starts with data and a question
Ryan contrasts a conventional application with a salary-benchmarking model. A normal software project can start with a user story, code, packaging, and a CI pipeline. The ML example starts with employee data and a question about using experience and skills to benchmark salaries. The first model may answer a one-time question, but the requirements change when the business wants predictions for later reviews or another department. The team then needs a predictive function, a way to serve the model repeatedly, and a way to check whether the training data applies to the new department.
Models create different build, packaging, and reproducibility problems
Ryan says the fundamental difference comes from how the system is made. Traditional programs use explicit rules to turn inputs into outputs. Machine learning captures rules indirectly from data, so training is stochastic and may not produce exactly the same result each time. Large datasets may not fit naturally into Git, and a trained model is packaged by serializing it rather than compiling it into an ordinary executable. Training is also a long-running part of the build. The model can perform well on its training data and still fail when live data has a different distribution.
Ryan describes Seldon as a serving solution for models on Kubernetes. A user can provide a model path and the toolkit used to build the model in a Kubernetes custom resource, after which the required lower-level resources are created. Seldon can also use a Docker-based approach when a serialized model is not the right fit. Ryan stresses that serving must be understood within the wider MLOps landscape, which also includes storage, processing, training, tracking, batch predictions, and real-time APIs. The hard part is often choosing what the particular use case actually needs.
Model rollout requires both traffic engineering and business metrics
Ryan uses an online store to explain model rollout. A control model remains live while two new versions receive smaller portions of traffic. The team can compare them after collecting a statistically significant sample, while limiting risk by sending most traffic to the control. Conversion rate may be enough in one case, but another model could recommend products that increase immediate sales while causing customers to leave. David points out that this combines engineering work, such as routing, traffic splitting, monitoring, and rollback, with scientific decisions about experiments and metrics.
Inference graphs keep request transformations close to the model
Ryan explains that raw requests often need preprocessing before a model can consume them, especially for text. The same transformation used during training must also happen at inference time. Seldon uses an inference graph to place these steps into a serving pipeline, so a request can pass through preprocessing, the model, and later transformations before the response returns to the consumer. The graph is directed and acyclic, but it can branch. Ryan gives multi-armed bandits as an example where a component chooses between model variations.
Drift and outliers require monitoring beyond ordinary service health
Ryan defines concept drift as a change in the live data distribution relative to the training data. His fashion example has a model trained during summer that continues recommending T-shirts during winter. Seldon can feed live requests asynchronously to a component that checks whether the data still matches the expected distribution, so the prediction path is not slowed down. A separate outlier detector can identify individual inputs outside the training distribution. Ryan also discusses adversarial examples and explains that a model can be highly confident while being wrong.
Scoping questions should come before selecting a platform
Ryan advises teams to identify their particular use case before choosing tools. His questions cover whether the data exists and is clean, how often new data arrives, whether training connects to continuous integration, how the model will be served, and whether predictions need low latency. Teams should also consider changing data, seasonal effects, online learning, retraining triggers, outliers, and explainability. Platform teams have additional concerns, including the range of internal use cases, deployment ownership, user skills, familiar tools, budget, and whether to buy a platform or assemble one from existing components.
"The ML code is this one little tiny block and then you've got these huge blocks for data cleaning and prep and serving and monitoring stuff."Ryan Dawson14:47
Who should watch
You are coming from a DevOps team and need to understand why deploying and operating machine learning systems adds work beyond a normal application.
Your team is deciding whether a project needs a few connected tools, a serving system, or a broader internal platform.
You need a practical set of questions for scoping data quality, serving, retraining, drift, explainability, team skills, and budget before choosing an MLOps approach.
