MLOps vs DevOps - What's Different?

A lot of candidates walk into platform and MLOps interviews assuming the job is just DevOps with Python notebooks. Interviewers ask this question specifically to find out if you understand that, and why that assumption falls apart in production.

The answer interviewers want

DevOps deploys code. Code does the same thing today that it did yesterday, unless someone changes it. MLOps deploys models, and models change behavior over time even when nobody touches the code. The data flowing through them shifts, and the model's predictions drift with it.

That difference forces MLOps to add three things DevOps pipelines don't normally need:

• Data versioning - you need to know exactly which dataset trained which model version, not just which commit built which artifact.
• Model monitoring - tracking whether the model's predictions are still accurate, not just whether the service is up.
• Retraining pipelines - automated or semi-automated processes to refresh the model when its performance degrades.

The real difference, though, isn't the tooling. It's what you watch. A DevOps pipeline cares about system health: is the service up, is latency acceptable, are error rates normal. MLOps has to monitor business metrics on top of that: is the model's accuracy holding up, is conversion rate dropping, is the recommendation engine still recommending things people actually click. A model can pass every infrastructure health check and still be quietly wrong.

Why interviewers ask this

This question separates people who've only shipped application code from people who've actually operated a model in production. Anyone can recite "CI/CD for ML." Interviewers want to hear that you understand model behavior degrades silently, and that uptime dashboards won't catch that. It's a quick way to test whether you think in terms of system health only, or whether you also think about output quality over time.

Follow-ups to expect

How would you detect that a model needs retraining? You'd watch business and accuracy metrics for the model's predictions, not just service health, since a model can be fully "up" while its predictions quietly degrade.

Why does data versioning matter if you already version your code? Because the model's behavior depends on what data trained it, not just what code built it. Without tracking the dataset version alongside the model version, you can't reproduce or debug a given model's behavior.

What happens if you only monitor system health for a model in production? You'd catch outages and latency problems but miss the model itself going wrong, since accuracy and business-metric drift don't show up in infrastructure dashboards.

The common wrong answer

The typical wrong answer is "MLOps is just DevOps plus Jupyter notebooks and some extra YAML for training jobs." That misses the core point entirely: the thing being deployed changes behavior on its own over time, which is why monitoring has to extend beyond system health into whether the model's outputs are still good.