MLOps roles remain unclear because data scientists often lack software engineering experience and companies do not know who should deploy a successful prototype.
2
Marian recommends buying a managed service or using existing open source software before building an internal system from scratch.
3
Monitoring needs to begin early because production data can change sharply, as the COVID-19 disruption showed.
Summary
Marian Ignev discusses the parts of MLOps that receive too little attention. He starts with team structure. Data scientists understand algorithms, statistics, and neural network architectures, while tools such as Docker may be unfamiliar to them. Companies then struggle to decide whether deployment belongs to a data scientist, backend engineer, CTO, or a dedicated machine learning engineer. Marian connects this problem to the youth of the field and its lack of standardization. For tooling, he advises teams to buy a service when speed and reduced risk matter, or use open source when cost, security, or ownership matter. Building from scratch should come later, after the team understands the problem. He also argues that monitoring must cover data drift, concept drift, and infrastructure signals. COVID-19 exposed models trained on patterns that no longer matched customer behavior. His advice for teams starting monitoring is direct: move forward, learn from each step, and avoid waiting for a perfect plan.
MLOps emerged because companies had a deployment gap
Marian says he initially wondered who should handle the work of bringing machine learning and AI into production. His companies mostly dealt with DevOps, infrastructure, and deployments, but he saw a gap in professionals responsible for machine learning deployment. He describes MLOps as the role that naturally emerged to fill that gap. His own path began with servers and infrastructure, including a failed hosting company built around 42 rack servers in his kitchen. He later worked at SiteGround, a Bulgarian telecom company, and CloudStrap.io before starting SashiDo.io and TeachableHub, a managed service for machine learning models and deployments.
Companies still do not know who owns machine learning deployment
Marian says there is no agreed definition for machine learning roles or their responsibilities. Data scientists study neural network architectures, algorithms, statistics, and mathematics, but may have little software engineering experience. A tool such as Docker can therefore feel like a serious challenge to them. Companies can also find different people describing themselves as machine learning engineers while focusing on different areas, such as deep learning or computer vision. After a data scientist builds a successful prototype, the company may still not know whether deployment belongs to that person, a backend engineer, or the CTO.
Deployment looks simple in tutorials while production needs monitoring
Marian criticizes deployment articles that reduce the task to importing a model, putting it behind Flask, and running a server. Those examples can make deployment look like ten lines of code. They usually leave out monitoring, data drift, and concept drift. He gives the example of a large e-commerce business where a small change in model accuracy could have a large financial effect. During COVID-19, some customers had models built around offline retail patterns, while products accumulated in physical-store warehouses and online demand changed. Without monitoring, the businesses could not see that the model's assumptions had stopped matching reality.
Teams should choose managed services or open source before building internally
Marian describes three broad choices: build the system yourself, buy a ready-to-use service, or combine open source software and host it. His preference is to buy a service when it brings speed and reduces risk, provided the company can later migrate and retain its intellectual property. He warns that a small internal project can grow into a large maintenance burden. A simple microservice may accumulate additions until many people work on it, only for the team to discover later that an existing open source project or product does the job better. Building internally makes more sense when the team has experience, the problem is unique, and no suitable option exists.
Marian says the tooling ecosystem is young, with many ideas still being explored and many tools that should remain open source or free. He expects the focus to shift after the field develops more basic infrastructure and common tools. At that point, teams can spend more attention on productivity, quality, quantity, and business results instead of selecting and assembling tools. Demetrios Brinkmann adds that users currently face a confusing collection of tooling categories and landscape diagrams. Marian agrees that even people who try to follow new developments closely can struggle to understand what each project does and how it will fit with AWS, Azure, Kubeflow, or existing systems.
Small, focused tools have a better chance of fitting into existing stacks
Marian's advice to tooling companies is to start small and simple. A product should focus on a narrow problem where it can offer more value than alternatives. A small component is easier to integrate with existing systems. A broad, full-stack product may require a company to change many processes before it can test the product. This approach also gives buyers a clearer reason to use the tool. The conversation connects this advice to the difficulty of reading MLOps landscape diagrams, where companies may see many products without understanding which specific problem each one solves.
Standardization should exist even if the first standard is imperfect
Marian argues that having a standard matters more than choosing the perfect standard at the beginning. He repeats advice from his partner Pablo: if a team makes a mistake in its structure or standardization policy, it should make that mistake consistently. A consistent mistake is easier to find and replace. He says developers often create an initial protocol, improve it after a short time, and leave the old version in place. That creates systems with many versions of the same thing. Monitoring multiple versions of data outputs or logs then becomes much harder.
Monitoring should cover common signals before company-specific ones
Marian says many companies assume monitoring can wait until a model reaches production. He connects monitoring to standardization because much of what teams need to monitor is shared across companies, even though some signals are specific to a business. For computer vision, teams need knowledge about which model and data signals matter. Infrastructure monitoring also has familiar basics, such as IOPS, VRAM, CPU, disk health, and other server signals. Marian sees room for products that provide these defaults and add domain-specific monitoring through SDKs. Teams can start with a basic setup, learn from its results, and later build or change the solution.
The first monitoring step does not need to be perfect
When Vishnu Rachakonda asks how a computer vision team should begin model monitoring, Marian gives a simple answer: move forward. Every step provides information for the next one, and there is no need to be afraid of choosing the wrong first step. He describes a case where monitoring reveals that production data differs from training data. That discovery can lead the team to methods such as active learning and to a better understanding of how the system should be updated. His advice is to avoid overthinking the starting point and use the process to learn.
"If I can buy a service that will bring me speed, reduce risk, and stuff like this at the beginning, and after that if I want to host it myself, I should be able to do it."21:35
Who should watch
You are deciding whether machine learning work belongs with data scientists, backend engineers, or a dedicated MLOps team.
Your team is choosing between a managed service, open source software, and an internal build for deployment or monitoring.
You have a model approaching production and need a practical starting point for monitoring data drift, concept drift, and infrastructure signals.
