An attempt to sort out the MLOps zoo? In many ML projects I’ve worked across large and small companies -very often- MLOps is either: an afterthought, a WIP idea, or a fuzzy area. Usually, it takes a while for a company to adopt MLOps.
If your goal is to build ML Systems (no just models) and successfully deliver value with ML Products (not just projects) then I guess your need a solid, industrial MLOps approach. One issue: MLOps requires engaging many teams.
IT Man: “MLOps is just DevOps. We can do all this MLOps stuff with a bit of Github, Maven, Jenkins, Prometheus, and K8s. Plus the IT, Data & Engineering teams can support the DevOps Team.”
You: “No. MLOps is not just DevOps; it’s specific for ML.”
IT Man: “OK. So: What’s different in MLOps? Explain like I’m 5 (ELI5.)”
MLOps is not just DevOps. Once you demonstrate the difficulties and subtleties of e.g. orchestrating, syncing stuff like: data versioning, model versioning, feature storing, params opt, model training, monitoring, code & data pipelines, etc then people eventually realise MLOps is specific to ML.
Too much MLOps out there? Unlike 3-4 years ago, today there are literally 100s of startups, platforms each one claiming a piece of the MLOps space. Some of these are just glorified IDEs, not really MLOps. Some cover certain parts of MLOps. And others are specific for certain use cases. Many don’t cover MLOps end2end.
Forget all those MLOps platforms for now. Start elsewhere if you are trying to set up an MLOps team, or trying to improve your existing MLOps approach, or you’re simply entrenched in a DevOps vs. MLOps battle.
Building an MLOps engineering culture in your org. Here are my suggestions:
Start by showing what MLOps is and what it does. Show why MLOps is a specific engineering discipline for ML. You can use (MLOps): Overview, Definition, and Architecture to set the scene.
Define your own MLOps principles. Engage Data, IT, Engineering teams, and get them to discuss and agree on the principles. I really like MLOps Principles It’s a brilliant starting point.
Ask: How mature is our MLOps thingy? Be realistic. Google’s Architecture Team was the first one to explain why MLOps is not DevOps. They described Google’s 3 Levels of MLOps, and why you need e.g. a Continuous Training (CT) pipeline specific to ML. Later Microsoft’s 5 Levels of MLOps was published, which is OK too.
Spread the MLOps word in your org, evangelise why MLOps is required for ML success. I suggest you use Google’s Practitioners Guide to MLOps (pdf.) It’s a great resource!
Good luck, I hope that was useful.
Lazy Sunday? Here’s some low-energy pastimes:
10 Link-o-Troned
A Pythonista *Experience*
beCause of Dennis & Bjarne
Scripting aRt
Love from Julia
(Paren(th)ethical)
ScalaTOR
data v-i-s-i-o-n-s
Distributed de-Entangler
Forschung!
Algorithmic Potpourri
Robots & Cyborgs like <you>
Deep & Other Learning Bits
startups -> radar
ML Datasets & Stuff
Postscript, etc
Tips? Suggestions? Feedback? email Carlos
Curated by @ds_ldn in the middle of the night.