MLOps depends on team structure and communication as much as it depends on tools and technology.
2
Model packages should be designed around performance, scaling, and the needs of the production system rather than textbook patterns.
3
Versioning, reproducibility, automation, deployment, and related MLOps practices can recover systems after infrastructure failures and support compliance changes.
Summary
Marouen Hizaoui and Mo Basirati share project stories from insurance and retail clients with different levels of technical and MLOps maturity. They argue that MLOps is a set of concepts and practices for building reliable, efficient machine learning systems, rather than a particular product or platform. Their examples focus on isolated data science and operations teams, model packaging that created unacceptable latency, a retail model that remained stuck outside production, data regulation problems discovered before launch, and the accidental deletion of shared infrastructure. Cross-team programming, shared standards, incremental architecture, decoupled components, monitoring, versioning, reproducibility, and automation helped address these problems. The speakers are direct about the limits of general recipes. Architecture depends on the product, and pipelines should be separated or combined according to service-level requirements and component dependencies.
MLOps principles matter more than a particular platform
Marouen Hizaoui describes MLOps as concepts and best practices for building reliable and efficient machine learning systems. He lists six categories: versioning, testing, monitoring, automation, deployment, and reproducibility. Platforms may provide some of these functions, but the value comes from applying the underlying ideas. The speakers choose to explain those principles through client stories instead of giving a long description of each one. Their clients range from large technology companies to insurers, retailers, and other firms where machine learning supports a core business rather than being the main business.
Separated data and operations teams create production problems
In one insurance project, the data science and operations teams had different managers, budgets, tools, and environments. The teams communicated with different stakeholders and had different ideas about versioning. Data scientists also did not always know the production requirements around performance and security, while operations had limited contact with business and domain experts. This produced misunderstandings, longer feedback loops, and sometimes complete model redevelopment. The speakers used cross-team pair programming, short alignment meetings, shared packaging and versioning standards, and guidelines for starting projects. They recommend cross-functional teams where possible, or making development and production environments as similar as possible.
Model packaging must account for production performance
A document-classification system processed several images and objects in each document. The first model package put preprocessing, an embedding model, logic, and classification into one sequential component. With three images and five objects, this took about 11 seconds, while the requirement was roughly two to three seconds. The team split the package into preprocessing and filtering, embedding, and classification components. They then parallelized the stages and used horizontal scaling with Kubernetes. Prediction time became about 2.5 seconds, largely independent of the number of images and objects. The speakers advise excluding hard-coded logic from model packages and taking performance requirements seriously, since a simpler model that runs fast may fit the product better.
A retail client had models with good performance for routing customer questions, but the models had remained in a registry for months. The project had a clear business benefit, yet the team did not know how to turn the models into a working product. Mo Basirati says their definition of a product is something in production that delivers value. The team returned to the business case, clarified the scope with technical and business stakeholders, and designed an initial architecture. They implemented and tested the system through several cycles. Their approach was incremental, with simple components first and additional components added as the product moved toward its goal.
Architecture should grow incrementally and include MLOps practices from the start
The retail system did not follow a single large plan from models to a finished service. The team began with a small architecture and added components step by step while keeping MLOps principles in place by design. They even established monitoring before continuous integration and continuous delivery because they wanted to get a manually deployed version into production, observe whether it delivered value, and improve the process afterward. Mo Basirati says this architecture later supported a third generation of the product without downtime. He also stresses that an architecture gives the team a view of the whole product, which makes upgrades and targeted changes easier.
Decoupled components make compliance changes manageable
A European retail project was nearly ready to launch when the legal team found that some components did not meet data regulation requirements. Because the product had a decoupled architecture, the team could identify the affected components and design focused fixes instead of rebuilding the entire system. Versioning, reproducibility, automation, and deployment practices made the changes straightforward to roll out. The speakers treat data privacy as a requirement that needs attention during product design, especially for machine learning systems that process data. They also argue that architecture should make it possible to understand where a compliance concern enters the product and what needs to change.
Reproducibility and automation can recover shared infrastructure
Several teams shared AWS infrastructure owned by a data engineering team. Policies and access management were incomplete, and an accidental deletion removed a major part of the platform, including running and scheduled jobs that supported recommendations, campaigns, customer care, model registries, and schedulers. Recreating everything manually would have taken years. Versioning, reproducibility, automation, and deployment allowed the team to roll back and recreate the missing jobs. The services were running again in less than one business day. The example gives the speakers a concrete reason to apply MLOps practices even when the tools feel inconvenient or the investment seems unnecessary.
Pipeline boundaries depend on service requirements
In the audience discussion, Mo Basirati says there is no universal answer about whether feature extraction, machine learning, and software pipelines should be combined. The first consideration is the service-level requirement, including whether the system is real time, near real time, scheduled, or batch. Components that do not need to run together should generally be decoupled. If a model only works with a particular preprocessing step, packaging those parts together may be appropriate, provided the resulting product meets its runtime constraints. The decision should follow the product's dependencies and delivery requirements rather than a fixed rule.
"The idea is not exactly new, however the importance of it surged in the last few years as machine learning and data products became more and more abundant."Marouen Hizaoui08:36
Who should watch
You have separate data science and operations teams and production failures keep appearing at their boundary.
Your team has trained models but has not yet turned them into a product that runs in production.
You share infrastructure across teams and need practical reasons to invest in versioning, reproducibility, automation, and deployment.
