It’s so inspiring to learn from practitioners and thinkers. Getting to know the experience gained by researchers, engineers, and entrepreneurs doing real ML work is an excellent source of insight and inspiration. Share this interview if you like it. No subscription is needed.

Share

👤 Quick bio / Ran Romano

Tell us a bit about yourself. Your background, current role and how did you get started in machine learning? 

Ran Romano (RR): My name is Ran Romano. I am married + 2 and live in Israel. I started my professional path at the intelligence cores of the Israel Defence Forces (IDF). I was always curious about the relationship between engineering and data science and the impact of merging both disciplines to deliver complete solutions. Later, during my time at Wix, I got the opportunity to feed my curiosity by founding and leading the team responsible for building Wix’s Internal ML platform, which is designed to allow efficient and continuous delivery of ML models to production. Nowadays, I lead Qwak’s engineering & product teams and leverage my experience and domain expertise in order to build a world-class ML Engineering platform.

🛠 ML Work  

Could you tell us about the vision and inspiration for the Qwak platform? What are the important gaps between data science and ML engineering that Qwak tries to bridge?

RR: Qwak, at its core, enables data scientists and ML engineers to build, deploy, maintain and monitor ML models & features in production with minimal engineering friction. One of our main pillars, and an approach we highly advocate for, is a production-first approach for applying ML models to business needs. DS teams should not spend months iterating on models within their playground but strive to deploy and test their models as fast as possible in the wild and iterate quickly while in production, having their model already delivering value.

So we’ve built our platform around the notion of decoupling DS teams from their engineering counterparts in order to allow them to run experiments faster and more independently. We want them to be able to work and not have to go back and forth continuously and waste precious time and resources.

One of the unique capabilities of the Qwak platform is the Build system which unifies several elements of the lifecycle management of ML models. How is Build system for ML models different than for traditional software applications? 

RR: Qwak build system adds “traditional” build processes to machine learning models and allows data scientists to build an immutable, versioned, and tested production-grade artifact. Our build system standardizes an ML project structure that automatically versions data, code, and parameters for every model build. 

The Qwak build system takes its inspiration from traditional build tools while at the same time augmenting ML-specific capabilities like experiment tracking, code parameters, and data versioning. The great thing about the build system is that it leverages best practices forged over the past decade in the DevOps world and applies them to the ML engineering world. 

Model serving is another area of focus of the Qwak platform. Could you explain the key challenges of serving ML models at scale? What are some of the key differences that ML engineers should consider when serving real-time, batch, or streaming models?

RR: One of the key challenges we observe in ML serving space is the attempts to deploy hundreds or even thousands of similar purpose models simultaneously in a manageable fashion. In most cases, that means training the same model but for hundreds or thousands of different datasets. For example, a B2B company with multiple customers would be better off training a model per customer rather than training a single generic model for all customers alike. For that end, Qwak provides “Model Per Dimension” type deployments which enable a cost-efficient, scalable, and manageable solution to deploy large numbers of models.

Qwak Serving allows deployment of any type of model to production with, in most cases, a single click, aiming to reduce the friction between data science and engineers. At its core, it simply provides a faster way to put your models into production. The serving mechanism enables teams to deliver prediction services in a fast, repeatable, and scalable way – including advanced metrics, logging, and alerting capabilities. 

One of the main advantages of our build system is that its product, a deployable artifact, is completely deployment agnostic. Thus allowing a seamless deployment experience to either batch, real-time, or streaming inference. This means the engineer does not have to stick to a single deployment method which is usually a business-related requirement.

The MLOps space can be divided between: platforms that focus on a standalone capabilities (ex: feature stores); companies like Qwak that combine several MLOps capabilities into a single platform; incumbents like AWS Sage Maker or Azure ML that want to provide every single feature of MLOPs pipelines. How do you see these three segments of the market evolving in the near future?

RR: We see it as a classic problem of best-of-breed vs. best-of-suite. With a best-of-breed approach, you get a composable architecture that could potentially increase the flexibility of your home-grown ML Platform, however at the cost of needing to maintain much “glue code” in order to piece together different components which are naturally not designed to work together as a single coherent platform. And we see a trend of these single silos companies expanding into other domains in the ML pipeline to offer a complete solution. 

On the other hand, cloud providers tend to deliver an all-encompassing toolchain that covers the entire ML domain for feature engineering to AutoML solutions without any specific focus. This tactic, as I learned firsthand from my time in Wix, of providing rudimentary building blocks forces ML teams (like my team at Wix) to build their own infrastructure on top of the ML infrastructure the cloud providers provide.

💥 Miscellaneous – a set of rapid-fire questions 

Favorite math paradox?

Simpson’s paradox - even though it’s not a real paradox :) 

What book can you recommend to an aspiring ML engineer?

Not just for ML Engineers - Principles by Ray Dalio. 

Is the Turing Test still relevant? Any clever alternatives?

To a much lesser extent than in the past. I like the approach of the Marcus test.

Is P equals NP?

No