MLOps is an organizational capability that combines engineering practices with cultural change, rather than a collection of tools.
2
Teams should start with the production bottleneck they have, such as model deployment, data pipelines, or feature management, and build from there.
3
Machine learning systems need continuous testing because their data, outputs, and business conditions change after deployment.
Summary
Srivatsan Srinivasan explains why machine learning production work extends far beyond model training. He estimates that the algorithm is only a small part of the overall effort, which also includes data collection, feature engineering, deployment, monitoring, and pipelines. He recommends that organizations treat MLOps as a capability and begin with the bottleneck that is slowing them down. The conversation covers how CI/CD concepts carry over from software engineering, with additional artifacts such as models and data distributions. Srinivasan separates performance testing, model reliability checks, and live data monitoring, and explains why delayed ground truth makes production evaluation difficult. He discusses feature stores, AutoML, model release patterns, Kubernetes, and hybrid cloud deployment. He also distinguishes the experimental nature of ML development from the more conventional software work involved in integrating and deploying a trained model. His advice is practical and candid about the cost, complexity, and limits of current tools.
Srivatsan started his AIEngineering channel because most available material focused on building models rather than engineering complete ML systems. He describes the algorithm as only about 20 percent of the full machine learning effort. The rest can include data collection, data engineering, feature engineering, model deployment, monitoring, pipelines, and feature stores. His focus is connecting academic model building with industry systems that can run in production. The channel therefore concentrates on the engineering details that appear after, or alongside, model development.
Organizations should build MLOps around their actual bottleneck
Srinivasan says an MLOps capability can take years to build because it includes technical work and cultural change. He advises teams to find the area that is causing the most delay. If data scientists can produce models but handing their artifacts to software engineers is slow, the first investment should be a CI/CD pipeline and better model deployment. If many teams repeatedly create similar data pipelines, a feature store can centralize base and aggregated metrics. The problem determines which capability should come first.
ML CI/CD adds model and data artifacts to familiar DevOps ideas
Srinivasan describes MLOps as ML plus DevOps, with additional artifacts that need to move through the process. These include the model and the data distribution used for monitoring. He recommends that ML engineers learn core DevOps concepts and then apply them to their platform, whether that is a cloud provider or an on-premises Jenkins setup. The concepts remain similar across tools. The platform-specific work is mainly in descriptors, YAML, and Terraform, while the team must also define how ML artifacts reach the software engineers who deploy them.
ML teams need shared responsibilities instead of a mythical full-stack person
Srinivasan argues that a production ML project usually needs data engineers, ML engineers, and software engineers working together. He calls the idea of a full-stack data scientist a myth because one person cannot realistically give equal attention to model quality, business return, experimentation, and production engineering. He advises engineers learning DevOps to focus on concepts that transfer between Google Cloud, AWS, and on-premises systems. Tools can be learned quickly once those concepts are understood, but the division of responsibilities still matters.
Testing must cover performance, model reliability, and changing data
Srinivasan separates ML system testing into several areas. Performance testing checks whether the model can meet its service-level target under the expected load, which requires decisions about CPUs, GPUs, memory, and scaling. Reliability testing runs sample records before deployment to confirm that the model output still matches expected results. Production data testing compares incoming and baseline distributions with statistical measures such as population stability index or the KS test. Because labels often arrive late, especially in fraud detection, production testing cannot rely on immediate ground truth. It has to continue after deployment.
Current drift detection is weaker for NLP and computer vision
Srinivasan says drift detection has not matured enough for complex data such as NLP and computer vision. For NLP in particular, it can be difficult to identify drift directly in the input data. Teams may therefore need to watch model output and focus on model drift instead. This limitation affects the tools available to production teams. The discussion also covers the fact that a model can appear better on an aggregate metric while losing performance on a rare or expensive class, which makes model iteration and backward compatibility harder to assess.
AutoML is useful as a baseline, with limits on cost and control
Srinivasan presents Google Cloud AutoML and BigQuery ML as ways to create a baseline quickly. A team can compare models and hyperparameters without moving data from BigQuery into a Python notebook. He does not present AutoML as a replacement for data scientists. Instead, it can narrow the search and let people spend more time on feature engineering and experimentation. He also points out that the service can be expensive and that Google Cloud may require the model to use its deployment path, which limits the option of moving the model to a team's own Kubernetes cluster.
Deployment choices depend on the serving pattern and the required latency
Before choosing a serving tool, Srinivasan says teams should decide whether the model runs as a batch job, responds to real-time API or streaming requests, or runs at the edge. Flask can work when latency requirements are less demanding, while high load or larger payloads may call for Kafka or another streaming platform. He gives an example of a business process that cuts off model inference after 10 milliseconds and makes a default decision. For organizations that need portability across cloud and on-premises environments, he recommends Kubernetes because the same deployment approach can support hybrid infrastructure.
Model development is experimental, while model deployment resembles software delivery
Srinivasan distinguishes the ML development lifecycle from the software engineering lifecycle. Software development usually implements defined functional transformations, while ML development involves feeding data into experiments and observing probabilistic results. The distinction becomes smaller after a model is trained. At deployment time, the model is a software artifact that must integrate with other systems and produce predictions. The architecture still becomes more demanding as latency falls, since every hop needs suitable performance, scalability, reliability, and failover behavior.
