Navigating the MLOps tooling landscape (Part 3: The Strategies)

[utterances-bot]

Navigating the MLOps tooling landscape (Part 3: The Strategies)

In Part Three of "Navigating the MLOps tooling landscape," I'll talk about some adoption strategies that we can use given the variety of MLOps tools

https://ljvmiranda921.github.io/notebook/2021/05/30/navigating-the-mlops-landscape-part-3/

[tpgmartin]

Hey Lj, really enjoyed reading this series. Had a few questions about this post,

• Seems like the key factor in tools/platforms being categorised as "trial" is relative newness on the scene, would you expect these types of tools to fall into "adopt" as they become more mature?
• For the all-in-one vs piecemeal tech that are categorised as “adopt”, is the movement of piecemeal tools from trial to adopt easier because they are easier to swap in and out, as you say "all-in-one" solutions are "hard-commit"? Is this a fundamental issue with these kinds of solutions? 

Cheers

[ljvmiranda921]

Hi @tpgmartin , thanks for reading!

Would you expect these types of tools to fall into "adopt" as they become more mature?

It's definitely going to be the case. You can draw some parallels with the Gartner hype cycle here as well.

is the movement of piecemeal tools from trial to adopt easier because they are easier to swap in and out

My opinion here may have changed a bit. Before, I'd say a definite yes because you can just swap out piecemeal tools into your overall platform. But remember that "swapping out" means:

• Onboarding time for your engineers
• Writing / re-writing existing code to interface with the new tool's APIs

And usually these activities cost a lot. Recently I've been more comfortable with all-in-one solutions yet still remain to be risk-averse: e.g. use all-in-one solutions from known cloud platforms like GCP, AWS, etc. Yes, they're a hard commit, but I'd rather follow the platform's whims so that I can ship my product / service much faster.

Thanks for the interesting questions!