This video and post are part of a One Dev Question series on MLOps - DevOps for Machine Learning. See the full video playlist here, and the rest of the blog posts here.
If you're delivering software, DevOps has become a must-have. It's not just something you should do, but something you must do if you want to compete.
Along those lines, if you're working on machine learning projects, MLOps is not just another buzzword that can safely be ignored. Applying MLOps can mature your projects and lead to better outcomes.
It's becoming a recurring theme in this series, but it's true - it's easy to think of ML projects as significantly different than traditional software projects. The day to day work is different, so surely the surrounding processes can be different!
For example, the work of producing a predictive model is often done by a smaller team or even a single person, rather than a team of engineers. So why bother with source control?
It's also really common for the deployment cadence to be much slower in an ML project. Teams just don't deploy that often and it can take some time to get a result you're happy to release.
All this begs the question - why care about MLOps at all? The work doesn't mirror what happens in traditional development, so why are we trying to force ML projects into the DevOps mold?
First, it's worth revisiting Microsoft's definition for DevOps:
DevOps is the union of people, process, and products to enable continuous delivery of value to the end user.
As I mentioned earlier in the series, the real focus of DevOps is delivering value. Not code, not bug fixes, not scalability - but value. So the definition absolutely includes ML projects. There is value in a better predictive model.
So while we're saying "MLOps", we really mean "DevOps for ML", and the same benefits should apply. As long as we're conscious of the differences between the two specialties.
I'm often asked about the tangible benefits of DevOps practices (and MLOps practices). Sure, things can be deployed quickly, but what's really wrong with a hard deployment if you only do it every few months?
I could speak for hours on that topic, but it all boils down to one thing:
Let experts focus on what they're best at.
The way to do this is to make sure all the surrounding aspects of their job just work. That's things like managing engineering environments, managing production environments, versioning and collaborating on code, executing experiments and training runs, testing, validating, and versioning predictive models, packaging those models into a deployable form, and deploying them in safe ways.
If all that stuff just falls away, data scientists can focus on the data science. Machine learning experts can focus on creating good predictive models, and know that their experiments will run consistently, they'll get the information they need to make decisions, and if they produce something good, it can be deployed without a fight.
Sound familiar? It should - these are all exactly the same benefits as DevOps. There's plenty of research out there by experts such as Dr Nicole Forsgren, Gene Kim, and Jez Humble that shows there are measurable, tangible benefits to doing DevOps.
DevOps overlaps heavily with MLOps. You could even argue (and I do) that it's the same thing, just with a slightly specialised focus. MLOps is solving the same problem as DevOps - delivering value to end users.
One tool that's extremely good at managing the MLOps lifecycle is Azure Machine Learning. As well as features that make creating models easier than ever, it can manage pipelines, track experiment and model versions, and even package and deploy to production.
If you want to get started with Azure Machine Learning, the best place to get hands-on experience (for free) is Microsoft Learn. The "Build AI solutions with Azure Machine Learning" learning path is an awesome in-depth resource.
And of course, there's the usual collection of comprehensive documentation on Microsoft Docs to answer any additional questions you have along the way.