MLOps — Who, What, Why, Where?

It’s taken me a long time to get my head round DevOps — is it a methodology/approach to work or is it a set of tools and technologies?

Do the Infrastructure/Network team take ownership or is it part of the Software Engineering teams responsibility?! Well, it seems it depends on who you ask. So maybe I don’t have my head round it just yet …

Now we have the explosion of Machine Learning Operations, or MLOps in the world of Data Science and I am back to square one.

It’s a topic which has come up a fair bit on How AI Built This — the data podcast hosted by yours truly, shameless plug — and I’ve been lucky enough to speak to people much, much smarter than me about it — like the team at Fuzzy Labs.

Here is a summary of what I’ve picked up:

What is MLOps?

Ask 10 Data Scientists, you may well get 11 answers. Here is Nvidia’s definition: “MLOps is a set of best practices for businesses to run AI successfully”.

As I understand it — and remember, I am a simpleton — MLOps holds the key to bringing Data Science projects in line with for example, software engineering best practice and thinking about reproducibility as standard.

On a yet-to-be released episode of How AI Built This — another plug 😉 — I chatted with Erik Arne Mathiesen-Dreyfus about how it would be unheard of to have a Software Engineering team not making use of Version Control or even just not having a shared code base for future projects.

However, in Data Science, this is often the case. The nature of the job is to hack together solutions, see what works and run with it, eventually something makes its way into production. And for the next project, you start all over again.

However, to really move forward and have a business impact, which let’s face it is the main goal for most — MLOps is going to be key or it certainly seems that way.

Who is responsible for MLOps?

Ah, a proverbial can of worms.

Some say a good data science team will implement these practices into their day to day role to some extent, or at least champion best practice.

Some say it’s a totally different job and the rise of ML or AI Engineers has paid testament to that school of thought.

An interesting comment Erik made on the show was that it is a job that needs doing just now, and yes, ideally you’d have an MLOps team, but if you can’t get the headcount budget from the business, you will need to pick up the slack. Over time, and as tooling becomes better, it will be more likely you can shuffle the pack and have a team organised in a slightly different way.

At the end of the day, it will definitely fall within the Data Science team’s remit, because it directly impacts their models.

Tooling:

Much like DevOps maybe 10 years ago, we’re still in the infancy of MLOps tooling. There are some cool companies like Valohai in Finland doing interesting things and I’ve had some great conversations with companies in the UK looking to solve some of these problems.

As we get more sophisticated tooling, I think MLOps will become the norm for most data science teams and blogs like this won’t exist!

So watch this space I suppose!

Team Structure & Job Titles:

This is harder to put down on a blog, but it’s probably worth thinking about if you are in charge of a data science team or work as a Data Scientist. If you love this part of your job, there is going to be huge demand for your skills — which is great news.

If you are managing a team, it would be prudent to think how you can make the most of the skills you have and maybe not expect them to be a model builder, a Data Engineer, a Software Engineer and an MLOps specialist.

In my humblest of opinions, we need to move away from the title of “Data Scientist” — it is far too catchall. MLOps Engineer, Data Engineer and maybe something like Product Data Scientist, or Research Data Scientist?! Having them working closely together and maybe even with some crossover is fine — but understanding they all play slightly different parts.

And there you have it — my hot take on all things MLOps. Let me know what you think!