#225 The Full Stack Data Scientist with Savin Goyal, Co-Founder & CTO at Outerbounds

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

What I'm quite excited by these days is that I think that maturity in conversation is coming back in the sense that I think now people are understanding that Gen AI plus predictive AI is a thing. It's not as if one strategy or one approach is going to completely upend. At the end of the day, you need to build machine learning systems Foreign.

Welcome to Data Framed. This is Ritchie. The role of the data scientist is changing. Some organizations are splitting the role into more narrowly focused jobs, and others are going the opposite direction and making the role broader. It's this latter approach, known as the Full Stack Data Scientist, that we're talking about today. The name is derived from the idea of a Full Stack Software engineer, and that's appropriate as the extra duties often include software engineering tasks. In particular, one of the functions of a Full Stack data scientist is to take machine learning models and get them into production inside software. Teaching us about the new role and the intricacies of getting machine learning in production is Savin Goyal, the Chief Technology Officer and co founder of Outer Bounds. He's the creator of the open source machine learning management platform Metaflow. And before out of Bounds, Savin was also a software engineer at Netflix and LinkedIn. I'm excited to hear what he has to say. Hi Sabin, great to have you on the show.

Yeah, thanks Friggy. Thanks for having me.

Excellent. So today we're talking about data science in production, but what does that actually.

Mean to be in production? It's in the eyes of the beholder. At the end of the day, production is a spectrum. It can mean many different things to different individuals in the same organization. Depending on the maturity of your project, your definition of production could be quite different. I remember back at Netflix we had of course the Netflix recommendation system is perhaps one of the most famous machine learning system that's out there and you can imagine, I think everybody would agree that the definition of shipping a model to production means that you're able to run an A B test against that model, against live user traffic. And that is a good definition of production. But there were a lot of other data informed decisions that the organization was also making. And I'm pretty sure that's the same thing across many other companies too where the output of the model informs a business strategy. So in that way, even an offline analysis of a model where you end up generating a Google Doc or end up writing a memo for consumption by, let's say the business team can go a long way. I'm pretty sure a lot of companies in the consumer space, for example Spotify, I believe recently raised their prices or is about to raise prices. And there would have been a lot of statistical analysis and very likely machine learning that might have also gone in in terms of figuring out what kind of pricing strategy or pricing changes across geographies would work well. And that's yet another example of putting models into production where no microservices involved, no high scale, low latency inferencing is involved, but still is as critical to the business as any other machine learning use case.

So it's really, it's not just about putting some data science in a consumer facing app. It could just be, oh well, this is going to be a change prices or something like that.

I like that.

Can you talk me through what are the steps that need to happen to go from this is an internal project, this is going to be something customer facing or otherwise in production.

I think at the end of the day the first question always is that is this model even worthy of being in production? Right. I think there's sort of like a popular statistic, I don't even know if it is accurate that says that there's like X number of models never make their way into production and that X number is obscenely high. There may well be some truth to it, but I think one thing that's most important to understand is that in data science there is an expectation that many of your models will never make their way into production. Because you run some tests, you figure out that yes, this model isn't really worthy of promoting to production or continuing any further development on top of it. And that's okay. That's the nature of data science. What's most important is that are you able to move from one model to the next version of the same model very quickly and effectively or not. So that's basically my viewpoint when it comes to figuring out how to promote a model or what does production actually mean now to Your original question of what are the different levels that are involved? If you think about the life cycle of a machine learning project, it starts out with data. You have certain hypothesis, you look at the data, you train a bunch of models, and then you figure out that in what capacity would you want to consume these models? And if it's a consumer setting where you can run decently powered AB tests, then quite often that is a good next step. But that may or may not be feasible at times. There are times when you just cannot run AB tests. You're not in a situation to do that, and then you can be a little bit more creative in terms of running quasi tests. But when that's also not feasible, then we usually see people invest a lot more heavily around explainability of their outcomes. So, for example, one of the more popular machine learning application, Netflix, is this suite of models called Crystal Ball that allows Netflix to predict the dollar valuation of any piece of content so that they can be a lot more disciplined in terms of how they construct their portfolio. And creating a counterfactual in that particular scenario is going to be very tricky as well as running an A B test can be quite difficult as well. And in those scenarios, then you rely on the explainability of the outcomes of your model, and then you rely on your business judgment at the end of the day. And that sort of is yet another mechanism of figuring out whether the model is worthy of being deployed or not.

Okay. So really a lot of it's about just making sure that you have something that's going to add value before you put it in a place where customers are going to see it. Before we get into the details of how you go about doing all this, I'd like to hear some success stories. So have you come across any cases where companies have invested in putting their data code into production and then they've seen some sort of benefit?

Yeah, yeah. I think Netflix has always been sort of the poster child for machine learning adoption. And this was, gosh, like maybe a decade ago or something when they first spoke publicly about the impact of recommendation system on their bottom line. And even at that point, I think there was a paper at one of the more prominent machine learning conferences where basically we came to the conclusion that the Netflix recommendation system was helpful to the tune of more than a billion dollars to the company's top line. And that's really impactful. And now basically, if we move forward a decade later, where exactly sort of the biggest impact has been made, have been sort of the long tail of machine learning applications A lot of organizations, of course, if you're, let's say, new to machine learning, then you end up focusing on your tent pole use cases. So for example, for Netflix it would be their recommendation systems, for Facebook or Google it would be their advertising or search systems. And that's great, that's where you'll derive the largest value. But as you sort of mature up then there are a lot of internal business processes, a lot of other consumer interfaces that can be made a lot better with machine learning. And, and the aggregate effect of that usually ends up surpassing the tenpold use case. And that is something that we have seen quite often not only at Netflix, but of course we have a popular open source project called Metaflow, helps organizations build machine learning models and deploy that in production as well. So we have been able to see the impact across other companies too. So there are companies like 23andMe, who use machine learning as well as data science to predict traits and outcomes using genetic data. And that has been quite remarkable in terms of just doing first rate medical research. We have companies in similar space like Medtronics focused on surgical AI. And that's yet another area. If you just look at drug discovery or automated surgeries, the amount of value that can be generated and the actual real world impact to people's lives is really great. Another example that I came across during the pandemic was this company called Zipline. They build automated drones that are responsible for bulk of drug supplies, including Covid vaccines in sub Saharan Africa. And their drones are modeled like they are powered through machine learning algorithms as well. And, and at the end of the day, of course, we look at sort of the big tech sector and how sort of interesting consumer applications are made, that is always getting the limelight. But when you look at these real world impact that is actually really shaping people's day to day, I think that's been sort of a lot more rewarding and enriching to just see from the sidelines at times.

Absolutely. So some very different examples there, I suppose. The Netflix example where you're getting a better movie recommendation, it's a small benefit, a lot of people there because it's scaled so much. Whereas on the other extent the idea of AI surgeon, that's helping one person a lot. So you've got very different use cases there. All right, so let's get into a bit of depth on some of these steps that are involved in like before you deploy your code. So what sort of tests do you.

Need to perform on your model so.

That you know it's ready to go live.

I think it depends. As with anything else, I mean of course nowadays if, let's say the Netflix recommendation start serving crappy recommendations, then it'll become a social meme. So in many ways the amount of due diligence that somebody needs to push out a new machine learning model for recommendation systems for popular services like Netflix, Spotify and whatnot is considerably higher. But nobody is really going to lose their life, right? It's not a life altering thing. If you push out a bad ML model versus if you're looking at let's say the healthcare space or the fintech space, then any kind of bias or any kind of issues with the model can have life altering outcomes. So the bar really goes up significantly. And fortunately or unfortunately that varies from industry to industry as well as the application that you're actually using it. So there isn't sort of a one size fits all answer. But the most important thing always is that as a data scientist or as a data professional, do you have full understanding, full view of how exactly a model is actually going to be used and are you able to sort of control and observe those outcomes and really iterate from that? And we've seen that as sort of one of the more primary failure mechanisms. Where you can imagine if, let's say putting a model to production or doing data science involves many, many individuals in an organization on one single project, then many of these important concerns become nobody's problem because there is no one single individual who has complete control over the end to end process. And, and that's been sort of one of the biggest push that we have been advocating for that. How do you essentially make your data scientist a full stack data scientist or an end to end data scientist so that they have full control around the model, the kind of data that they are building these models on. When are these models actually getting rolled out? What are the impact of these models on real world outcomes and not just statistical measures?

She's saying one of the biggest problems then in terms of maybe like quality control is going to be the fact that there's lots of different people doing different stages of the workflow. So in order to eliminate that, you have one person who's responsible from end to end.

This is going to be a full.

Stack data scientist, I presume. Do you want to tell me more about this role and what it would involve?

Yeah. So you can imagine, you know, like if we let's say harken back to the 70s or the 80s and this might even be true today as well, in many places, shipping software was really expensive shipping software of any kind. So of course, you know, you had your development team composed of software engineers, then you had a testing team composed of QA engineers, then you had a different group of people who were focused on shipping software through sort of these release managers, and then you had your database admins and application Architects and SREs in the mix as well. And that raise the cost of doing anything. In software engineering, of course, there are plenty of areas where having specialized roles makes a lot more sense. Of course, definitely when you sort of get to a certain level of scale as well, it's a lot more important to make sure that you have multiple eyes. But if you have five or seven of these different roles involved for every single project, then doing even the most simple thing becomes a lot more expensive, a lot more time consuming. And that's been one of the biggest promises of the modern DevOps movement as well as the advent of the cloud, that how can you have basically one single software engineer who can run the entire gamut? I mean, of course there isn't an expectation that overnight they're all significantly skilled at building front end as well as backend and being an expert around CI cd, but the tooling has evolved and matured where you can have an expectation that a small software engineering team can return outsized returns. And we are basically hoping for the same thing on the data science side of the house as well. That how do you basically ensure that it's not only these tenfold use cases that are reserved for machine learning and you can ensure that a single data scientist or a small team of data scientists can really deliver outsized business impact by running the entire life cycle of a data science project. So imagine all the way from how do you figure out what data does an organization have? Is that data available in the right format? Does that data have the right quality? Can I access that data in an interactive manner so that I can play around with that data and really understand what are the possibilities that that data has encoded? Then at the same time, do I bring in sufficient business skills to the table? Do I understand the business perspective that my organization is involved in so that I can marry my data science skills with this business perspective and start to figure out, you know, what are the best ways for me to optimize this specific business problem? And what we have seen historically is that data scientists come from quantitative disciplines that may not be software engineering related. Right? And that's where sort of one of the first bottleneck presents itself that if let's say you're playing around with a lot of data or if you're in an organization where you know everything needs to happen within a certain space, specific governance boundary of either your data warehouse or within a specific cloud. And how do you interface with that cloud? How do you interface with all of the engineering and business architecture? Complexity is sort of one of the big areas where people see declines in productivity and that then necessitates specialized roles to come in and you oftentimes end up in a problem where things fall through the cracks or certain important things around, like how do you figure out if the right thing is happening? Unfortunately becomes nobody's problem because there's no one single individual who has complete end to end perspective. So that's one of the big reasons why we ended up creating MetaFlow back at Netflix, which is like an open source machine learning platform. And it's geared towards ensuring that a data scientist can become this full stack end to end data scientist and they can control more of their destiny. And that should in theory then allow them to iterate on their machine learning models, on their data science projects a lot more quickly. And in that scenario you're then also able to gradually move the interface between data science teams and other software engineering teams. If you realize like a decade ago when I started my career, data scientist role used to be limited to prototyping on a laptop. And then there would be teams of engineers who would take that prototype, scale it out and then deploy it and off you go. Right. And the scenario there was that, of course, as you scale out your model training on a lot of data, then many of the statistical guarantees that a data scientist was looking out for may no longer hold true. And the software engineering team doesn't really understand the intention behind anything that a data scientist was trying to do. The data scientist has no idea what got shipped into production. And it was sort of like anybody's guess if even the right thing was happening in production. And now we are sort of getting into a point where a data scientist should be able to, let's say, expose an API to their work. Maybe that API is a model, maybe that API is an actual rest endpoint that you can call into. Maybe that API is a memo that has been written for consumption by sort of other teams. But at least sort of that provides a lot more control, a lot more visibility to a data science team, sort of like shipping off their work, lots to cover there.

And we'll certainly get into MetaFlow later. But it sounds like when you've got this Idea of a full set of data science. They need the data science skills, they need software engineering skills, they need business skills. This seems like it's going to be quite difficult to hire for, and I'm wondering whether there's a trade off between having a large number of more specialized individuals versus having this generalist who can do everything.

Do you want to tell me how.

Like a data team's going to be comprised? Then I presume you wouldn't want all full stack data scientists or all more specialized individuals. You can mix the two. How does it work?

I think the answer is better tooling. At the end of the day, of course, if the expectation is that we are able to find somebody who is really great at engineering, really great at data science, really great at business sense, that's proverbial unicorn. You may be able to find a few, but definitely that's not a strategy that can scale out. Now, two out of three is something that would be desirable. Finding somebody who is equally good at data science as well as understanding the business intimately. I think that in many ways is the minimum bar on hiring an exceptional data scientist. But paired with great tooling, you can definitely ensure that the level of abstraction that they are working on, at least the accidental complexities of the cloud, can be taken care of for them. And then you can expect that this particular data scientist to then take care of the business complexities and the data science complexities. So that's basically sort of where I see many data science teams to be moving towards as well. I think that's sort of one of the big reasons why many companies have also invested in their internal ML platform teams as well, where the entire prerogative of these themes is to provide these set of tools internally, sort of like a point of leverage, so that every single data scientist is insulated from the harsh reality of engineering. But the interesting dynamic there is that how do you build tools that are really good at navigating around this fact that there is some amount of complexity that a data scientist would want to take care of and then there is some amount of complexity that they would want the tool to take care of. And how do you sort of thread that balance? It's always an interesting question.

I definitely wanted to talk about tools in a bit, but just to press you on this idea of teams then. So if someone says, am I regular data scientist, I want to become a full stack data scientist, what needs to happen to take that extra step?

I think the question there is that if you're not this full stack data scientist Then what kind of data scientist are you? And my colleague here at Outer Bounds, his favorite term is laptop data scientist. Somebody who is very well adept with, let's say the Pythonic ecosystem or just everything that's available on the machine learning side of the house and is able to understand the characteristics of the data and get their work done. So there's that aspect. And then on the other side of the house you need to figure out as an organization, how do you actually ship value through data science, Right? And then there's the gulf of complexity that you need to cross in between. And one way is that yes, you become equipped at handling that gulf of complexity all by yourself. And example here would be, let's say you want to train many different machine learning models using GPUs and you're constantly iterating on different hypothesis and that GPU form very likely is not going to be your laptop, it's going to be something in the cloud. Let's assume that, you know, it's kubernetes, the most popular computer orchestrators out there. Now on one side I can have an expectation that maybe my data scientist understands the nitty gritties of Kubernetes ecosystem and how to sort of run these kubernetes pods reliably and manage them and monitor them and when things go wrong, knows his or her way around debugging these failures. But it's a very complicated landscape and unfortunately, if it was only kubernetes that people had to worry about, life would still be easy. Then you also have to worry about that. Okay, I have my data that needs be to, to come from somewhere, needs to go somewhere else. Couple that with kubernetes. How do I think about that? I'm constantly experimenting. Reproducibility can be a big problem. If, let's say my colleague is running into a failure, I'm supposed to help them out. But if I cannot reproduce or replicate that same failure, what are my odds of even being capable of helping them out one bit? The complexity very quickly multiplies and there are now multiple tools in the space that sort of help in this specific area. So making themselves well apprised, the latest and greatest tooling would be one. I think as practicing software engineers, it falls on us as well to really understand where the world is headed, what are the new paradigms around engineering? And I think it's the same thing that I think most data scientists also understand that for them to sort of stay relevant, they also need to sort of equip themselves with, if not necessarily the details of every single thing out there, at least sort of understanding what are the layers of abstractions that are available on top of these building blocks that can help them get their work done.

So really just make sure that you're on top of the latest tools that's going to stand you in good stead for improving your skills. Okay, so let's talk about MetaFlow, since you're the creator of it. So to begin with, can you tell me, what does MetaFlow do?

MetaFlow is an open source ML platform. To put it succinctly, it helps you train, deploy ML models and target it towards essentially building ML systems. I think, you know, in this conversation we have spoken a lot about data science and machine learning per se, but at the end of the day, an organization is trying to build a system and a machine learning model is only a part of that system. So how do you basically get to building these systems which can oftentimes be complex, they may cross team boundaries, they may interface with significant engineering infrastructure. How do you basically ensure that a data scientist or a team of data scientists is capable of doing all of that is basically what strikes to do.

Okay, so it's just going to help you take the sort of steps into getting your code into production. Now, I know there are just dozens and dozens of MLOps tools, so can you talk me through how MetaFlow fits into this larger ecosystem?

Tools? Yeah, yeah. So I can walk you through what even prompted us to start the project in the first place. Now, of course, you know, many of these tools, they've taken a life of their own and they cater to different markets or different use cases. What MetaFlow is targeted towards is a practicing data scientist. So it is not a low code, no code solution. It is a solution that's targeted towards a data scientist who either understands Python or R really well and also brings in that data science understanding to the table. So we are not in the business of teaching people how to DO data science. MetaFlow is a tool that enables people to do data science well. So that's sort of the big thing here. We started working on MetaFlow back in 2017. So, gosh, it's like now close to seven years. And we were at a spot back at Netflix where Netflix was now looking into investing in machine learning across the entire life cycle of their business. Right. So not only like, how do you do recommendations well, but how do you construct a portfolio of content that is going to drive your subscription base higher and higher up? How do you figure out what is the best content that's available? How do you leverage economies of scale in either licensing or producing that content? How do you take these bits and stream it to people's TVs and mobile devices so that they have an amazing streaming experience? How do you fight fraud? How do you take care of pricing challenges? You can imagine if you start thinking about all the places where you can start investing in from a machine learning standpoint at a company like Netflix, it's really in many ways like a kid in a candyland. And the other sort of interesting aspect was that while Netflix is usually lumped into this cohort of FAANG companies, and there's sort of a connotation with FAANG scale, I think Netflix is a lot more closer to your average company that is on the public cloud. But it's sort of just a whole bunch of different interesting problems that Netflix is trying to solve that adds to that complexity. So we were now getting to a spot where the solutions, the tools that we had built for our recommendation systems have served us really well. They were predominantly built on top of the JVM stack that was pretty popular in sort of the early to mid 2010s. And now we were coming to a spot where the number of people who were excellent at engineering, at data science, at business, were very few. And of course, now if you have to start investing in many different areas of data science, you have to then pick and choose your battle. And we said that, okay, of course we can't skimp on hiring the very best data science talent that's available. But then somebody has to come in and really pave over that gulf of engineering complexity. And then the goal for us was that, okay, how do we basically realize the stream of making our data scientists full stack data scientists, scientists. How do we basically provide them solutions where they can get all of their work done on their laptop, but we can bring the cloud to their laptop? Right? So you can basically sort of imagine, can I provide hundreds of thousands of CPU cores and hundreds and thousands of GPUs and terabytes and petabytes of RAM to your laptop so that you don't have to become a cloud engineer to scale out your machine learning projects? How do we ensure that people can take a graduated approach? Because you can imagine not every single project will be a humongous scale machine learning project, but then at the same time, every single machine learning project will help or will go much better if there is some amount of discipline baked in. Right. I think there have been plenty of times when we have run into this issue where something works on my laptop but does not work on my colleague's laptop. Or I'm able to install a version of Pytorch today, but not able to install the same version of PyTorch two days later on a transitive dependency has changed and something is subtly off and I'm trying to figure out what went wrong there. So it's sort of like a barrage of small little problems as well as some rather nefarious problems as well, particularly on the compute and the data side that you have to start worrying about as a data scientist. And our goal was that, okay, can we ensure that they don't necessarily have to worry about it and can they just squarely focus their efforts and energy on ranking the data science complexity? That's what their expertise is in. And if, let's say Netflix as an organization is expecting them to spend a lot, much more time wrangling nefarious issues with like how do I move data from my data warehouse to my GPU instance so that my GPU cycles are not wasted? That's not a thing that a data scientist should be focused on very early in data science project, because you don't even know at that particular point if the approach that you are taking for your machine learning model is even worth it. But if you take an aggregate view, if you have hundreds of data scientists all running GPUs suboptimally, then that expense really adds up to a non trivial number that as a platform engineering team I do indeed have to care about. But if you can codify all the best practices and provide a user experience that is a lot more human centric, that works with the data scientist that a data scientist doesn't have to fight against, then it becomes a lot more easier where by default all the right things happen on the engineering side of the house. The data scientists, their freedom of choice in terms of how they want to navigate the web of data science complexity is preserved and the organization then gets to benefit both from cost optimization because ML can become expensive at times if you're not careful about it, as well as making sure that you're able to innovate quite actively and quite quickly.

One thing you mentioned is the idea of working on a laptop. There's been a huge trend in the last decade or more about everything is going into the cloud. So the idea of working on a laptop sometimes, but also having access to these large scale compute that's in the cloud that sort of indicates some kind of hybrid computing is that the approach you push for or Is there like a reversal of the in cloud trend?

Of course, you know the. There are many benefits of being in the cloud. For example, if, let's say all your data is in the cloud, you don't want any of that data to ever leave the cloud. It's like one big reason, purely from a security standpoint, why everything would want to happen in the cloud. But your laptop can still be the interface to that cloud. So from that point of view, you might still be accessing all your resources through the laptop, but the code that you might be writing might actually be running entirely in the cloud. And the data may never actually show up on your laptop and everything might happen through your ID or through your browser. So that's one universe and then the other universes. At times the problem may not be sort of the problem that you're trying to solve, require very steep computational resources or managing a lot of data. The data could be enough to fit in your laptop. It may not be super sensitive. You could use something like Scikit Learn or many other popular frameworks to build your machine learning models. I mean, the number of things that my MacBook can do these these days, I mean, it's just beyond imagination. But then what you still sort of need at that particular moment is still some discipline, right? You still want to figure out how you're going to catalog your experiments. You still want to figure out what is the best mechanism for you to ensure so that you know, you're able to understand how your models are behaving. Or if you need to course correct, then you're able to do that easily many times. One definition of productionizing your model can be that, okay, whatever work you have done on your laptop. Now, of course, at the end of the day, you're going to shut your laptop closed and you're going to go back home. But maybe you want to sort of run that model training process every single night, every single week. Maybe when new data shows up, how do you sort of push that into the cloud? I mean, it could be your on prem infrastructure as well, right? But basically, how do you sort of take something that is running on your laptop and reliably run it elsewhere? That can be one definition of productionizing your machine learning model in a variety of projects. And that can be a big activity where a lot of organizations may sync a lot of resources, where the data scientist was able to prototype something on their laptop, but now just this process of converting their wares into something that can be run outside their laptop can be an activity that is sort of measured in months or quarters. And for us that was another goal that okay, can we sort of take all the work that a data scientist is doing, whether that work is in the cloud or whether it is in the laptop, but it is available in a format such that it can be run anywhere else almost immediately so you don't have to sort of like, you know, at least then worry about this process of okay, I had something that was running, but now I need to go back to my manager and ask for another one month before so that I can come back, address all of my pain points and issues and refactor my code so that it's not worthy to be pushed in production. But can we sort of just flip the script such that the infrastructure basically allows you to do all the right things from the outset?

Certainly that's like anything involving package management, like environment and just having things not working from one machine to another. That can be incredibly frustrating if you've got to deal with this manually. So the idea of reproducibility is one important aspect of getting things in production. Another thing seems to be scalability. So once you could go into production.

Like you maybe got your model being.

Accessed by millions of people, how do you make sure that your code is going to be scalable?

I think in many cases, especially on the consumer side of the house, many times it might not be feasible to understand what kind of scalability requirements you're gunning for in the first place. In many cases it is indeed possible, especially if, let's say this model is a subsequent version of a previous model. But if you're on a net new project, especially on the consumer side of the house, that virality loops involved, the kind of scale that you may run into may quite be unpredictable. I mean, at the end of the day it sort of like all boils down to the question of project management and just like software engineering skills that if you are deploying a model, let's say in this case, if you're talking about recommendation systems, right, I mean, because that's one area that I'm very well familiar with. If you think through users tastes and preferences. So if you're, let's say on Spotify or if you're on Netflix, then there isn't a lot of brand new content that is coming in very, very quickly as well as your tastes are not really changing very quickly either and you already know what your entire user base looks like and what their preferences are so you can pre compute those recommendations and then just serve those recommendations from a database. So you're not like doing any kind of live model inferencing. And that has amazing scalability benefits. Very simple, straightforward approach. But of course it may or may not work in many use cases. So my recommendation for folks is if you already understand what your scalability metrics are that you're trying to achieve, then there's always sort of an architecture that's possible. Of course, you know the amount of expenditure that you're willing to incur in that project is also a big input to that. But don't overthink it, don't prematurely optimize it. There's plenty of hacks and approaches that people can take to at least sort of buy more time before you really understand what kind of next scalability benchmarks you need to be going for. I think there's a similar scalability hurdle that is present on the model training side as well at times. And that's sort of, in many ways a silent killer for many organizations where usually sort of a deployed model first, it's sort of like generating business value. So you want to really make sure that that, that works well. And there's a lot of light that's shown on those use cases. And then you have, let's say, some models that you're training that would be consumed directly in production, and people are also sort of ensuring that, yes, you have, let's say, all sorts of alerts and observability that's instrumented so that those models are actually generated on time with reliable results. But the third sort of bucket, where you have teams of data scientists who are actively experimenting, that can be a big cost vector as well. And what we have seen many times is that the overall cloud costs for experimentation can be orders of magnitude higher than your cost that a deployed model is incurring at times, because you may have hundreds of models that you're experimenting with, but only a few models or maybe tens of models that are deployed in production. And the unfortunate reality is that with experimental models, it's also very hard to sort of ensure that from a cost efficiency standpoint, you have complete awareness of how you want to actually optimize that model training, or if you want to, let's say, scale out that model training, then what kind of engineering effort would be needed as well? So one interesting example that comes to mind here is that I was working with a data scientist and they basically, I guess you can debate whether this was a good reason or not, but they were basically trying to predict what content is going to be popular in any given geography. At any given moment so that the content distribution network, the CDN infrastructure, can be seeded with the right kind of content. Right. So imagine if you know you are a company like Spotify and you know that certain kind of music is going to be popular in certain geography at certain ours, or if you're a company like Netflix who is releasing a brand new show and they have done a significant amount of marketing in let's say, Australia, then you would want to make sure that people have an amazing experience streaming that content and you don't run into rebuffer loops or anything of that sort. Right. And they wanted to do build these models for every single neighborhood in the world and they decided to build 60,000 models in one shot. Each of those models required a container with a gpu. And now this is immense amount of compute that you're running. Right. And ahead of time you don't even know what is the ROI of this entire effort going to be. And if, let's say it is just to a data scientist, it can be a significant engineering challenge all by itself that how do you run this much amount of compute without being a professional cloud engineer? And even for a single professional cloud engineer, this can be sort of like oftentimes a bridge too far. And with MetaFlow they were able to run that compute very seamlessly. And at the end of the day they also got a nice bill of here's how much money that you have spent. And of course, you know, when you start spending so much amount of money, some eyebrows are oftentimes raised. And so of course, you know, people wanted to understand whether the spend was worth it. And you can imagine, you know, in this case, obviously the amount of capital that this company was able to save in terms of their CDN optimization was, was well worth this expense of running 60,000 GPUs fully engaged for multiple days. Many times it may not be. And just like, you know, having that perspective at times as well that okay, you may want to scale, but is that scale actually linked to your business outcomes or not? And be a lot more important too?

Yeah, I can see how you certainly want to just speak to some other people before you fire up 60,000 GPUs and run them for a few days? Yeah, probably best to get our business alignment first.

First.

So I'm getting the big theme. Just don't do calculations that you don't need to do and just make sure you have metrics around like how performant you need things to be. I think we talked a little bit about reproducibility about scalability. The other aspect of things in production seems to be robustness, because as soon as things touch users, they're going to give you stupid impulse, things will behave in weird ways. Do you have any tips for how to make your data programs, models, whatever, more robust?

Yeah, of course you have to think through robustness, through the entire layer of the ML infrastructure stack in many ways. So of course there's a thing that, okay, does your model actually encapsulate the behavior that it is trying to predict? Have you taken into account things like seasonality and all of that? So I sort of put all those concerns on the data science side of the house that a data scientist needs to sort of worry about in many ways versus as a tool builder. What I like personally to focus on more on is that is the underlying infrastructure robust enough? Because many times if your infrastructure gives way and you're unable to, let's say, generate a fresher version of the model, then your model performance is going to take a hit and that will have a direct sort of hit to the business KPIs as well. And then the question becomes that, okay, how do you sort of get to a point where your infrastructure is robust? But then more importantly, of course, in the age of cloud, you can't promise 100% uptime for any piece of infrastructure and you can sort of increase your robustness rates. But I think, as you pointed out, right, like dependency management can be a big issue. So today you are able to install Pytorch, tomorrow you may not be able to install the same version the exact same way. And what do you do at that particular point? And the big question then becomes, how do you quickly recover from these errors? Or how do you quickly recover from these failure mechanisms? If, let's say you have training pipeline to train a model, but that training pipeline to train that model depends on yet another upstream pipeline that is generating some embeddings. Now if that embeddings pipeline is failing for whatever reason, of course your downstream model training pipeline cannot execute and there may be other processes as well that are dependent on it. So it becomes very imperative to figure out what is the quickest way to be able to diagnose what went wrong with your embeddings pipeline and how do you basically recover from that failure so that your subsequent pipelines can start executing. And that is oftentimes one of the areas that can be quite under invested in an organization where doing machine learning is so difficult at times, involves so many different moving pieces that the focus is on Getting the happy path, focus, working, and not necessarily focusing a lot on when that happy path is not quite happy, when failures happen, how do you sort of recover from that? And the complexity arises from the fact that so many different things can fail, right? I mean, a lot of people these days, they try to find cheaper GPU resources, so they end up going to, you know, a cloud provider that might not be sort of one of the more prominent hyperscalers. And then they unfortunately realize that the machine machine that they are buying, it was advertised to have four GPUs attached to it, but unfortunately only has three working GPU drivers. And that's why certain things are slow or failing, and then figure out how to recover from it, right? Or your data changed for whatever reason. And now middle of the night, you have to wake up and you have to sort of step through your work, and even replicating what failed can be at times really tricky. And then figure out that, okay, this was the actual change in data that was the cause for trouble. Either patch your pipeline or wake up the person who was responsible for the upstream data pipeline so that they can fix the error. And that becomes sort of one of the bigger themes that as an organization, how do you basically recover from these errors? Your mtr, how do you work that down? And that was like, one area that we sort of focused on quite a lot. And I think that sort of like, also pairs into this notion of reproducibility as well, that while, yes, you want to reproduce the good behavior of the model so that you have more trust in that model, but you also need to be able to reproduce the failure patterns somewhat reliably. Of course. I mean, there's a lot of stochasticism involved in failures as well, but at least for certain class of failures, if you're able to reproduce them reliably, then you also stand a shot at being able to fix those quickly and move on.

I know being on call is like a standard feature of being a software engineer. Waking up at like 3am to try and fix some data pipeline, or even worse, having to wake your colleagues up as well to say, okay, can you help me debug this at 3:00am that seems like something I wouldn't want to do on a regular basis. So can you talk me through what sort of processes should you put in place to make sure that you don't have regular failures?

How can you improve that reliability? The thing is, at the end of the day, if, let's say you have one simple strategy here is if you have a pipeline that is running, let's say, every week. And if it is super critical, then you may want to run that pipeline every day, but only consume the output every week so that then at least if it fails in between, then it's not something that you need to wake up in the middle of the night. You have an entire business day or an entire week or like half a week on average to actually fix up the issue before it becomes a burning issue. So playing with that frequency, the sort of arbitrage on the training side is almost always useful. Of course, it comes with extra costs as well, and many times that cost may well be worth it. Because if it is not super urgent, then why even wake up in the middle of the night? You can wake up during business hours and address it. On the model inferencing side, I think many, many techniques exist from the software engineering standpoint, but the one thing always is that always have sensibility faults. So if for whatever reason your machine learning system is down, you can always fall back on heuristics or certain rules so that the end customer experience isn't impacted. I think that's one of the more common failure mechanisms that I end up seeing, unfortunately, where because a machine learning system is down, the sort of immediate customer impact or something is broken. Many times it's unavoidable. But the systems can be designed in such a way that the user may get a subpar experience, but at least the critical functionality is not entirely impaired.

Okay, so you want to kind of fail gracefully and just maybe cut off one bit that's not working and have everything else work. All right, nice. Before we wrap up, what are you most excited about in the world of MLOps at the moment?

I think definitely a couple of years ago, especially when ChatGPT came out, there was this conversation going on on Twitter or X that, you know, is this the death of data science? Will data scientists as a job function even exist? And I think what I'm quite excited by these days is that I think that maturity in conversation is coming back in the sense that I think now people are understanding that gen AI plus predictive AI is a thing. It's not as if one strategy or one approach is going to completely upend. At the end of the day, you need to build machine learning systems. These machine learning systems may be a combination of machine learning many different models which might be built using a variety of different ways. So even if you're building a recommendation system, your recommendations could be coming from, let's say, a deep learning model. But somebody still needs to convince the end user that those recommendations are indeed worth their time. And that sort of compelling narrative could be derived from an LLM. And the album art could again be sort of some genai image model that could convince you that, yes, that particular content or that particular song is definitely sort of worth your attention. So I think now people are really sort of warming up to the idea that it's like multiple ML models all working in cohesion that actually drive a strong consumer experience or are able to enable an organization to optimize their internal business processes. And that's always exciting from a machine learning system point of view that, you know, how do you then think tackle this increased diversity or increased complexity in any system?

So having just like really complex systems of lots and lots of different models all working in harmony. Yeah, that maybe sounds like not step one if you're trying to start putting things in production, but maybe that's a very good end goal to work towards. All right, super. Do you have any final advice for organizations wanting to start getting their machine learning in production?

Yeah. So, of course, you know, machine learning, at the end of the day, it's not a silver bullet, it's experimentation at the end of the day. And you may end up investing a lot in data science and not really see any results for a really long period of time. And what really matters is ensuring that you have a plan before you start investing in ML. You have the right expectations, the right time horizon, and more importantly, you have either the right support structure around data scientists. And this could be sort of in the form of ensuring that you have people who understand infrastructure as well as data science really well and are able to work well with one another. Or in the absence of that, you're able to invest in great tooling from the onset so that your data scientists at the end of the day are able to experiment a lot more effectively. Because the one sure way of failing in machine learning is by not being able to experiment enough. If your data scientist is only able to ship one version of a model in a week, a month, or a quarter, whatever that time horizon is, that may just not be enough. If you're able to really sort of ensure that their iteration loops are measured in minutes or maybe hours, then that is a good way of ensuring that the quality of your machine learning model continues to go up eventually to a point where it may beat certain predefined rules or heuristics, and then that's when you start reaping the benefits of your investment in machine learning.

Yeah. That sounds like a great advice. Thank you very much for your time, Savid.

Yeah, thank you. Thanks for having me. It.