9 comments

[ 0.23 ms ] story [ 32.0 ms ] thread
Looks interesting, what if I need to write some logic (pre/post prediction) in the prediction server?
In this category I’m a big fan of https://github.com/bentoml/BentoML

What I like about it is their idiomatic developer experience. It reminds me of other Pythonic frameworks like Flask and Django in a good way.

I have no affiliation with them whatsoever, just an admirer.

Big fan of projects like BentoML, the whole ML space is powered by some truly great projects. What we've tried to do with truss is create an experience that is optimizing for simplicity and universality. Our roadmap begins to deviate away from projects like BentoML, and so creating truss was very much motivated by the need to continue this mindset as we march down through that roadmap.

context: I am one of the contributors

Superb product and team.

Worth looking into if you’ve done any engineering work around deploying ML models as a or within a service.

This looks promising. It feels like for non ML engineers it’s very hard to figure out how to use models as part of vanilla CRUD codebase.

For instance in a Rails app the ML model services would probably be served as a completely external service API generated with something like Truss wrapped in a service class that just exposes the outputs and handles errors/input validation!

This is likely to share its name with the next Prime Minister of the UK...
Looks great! What is the argument to use this over MLFlow model packaging and serving?
Truss contributor here

MLFlow is awesome; it's powerful and flexible and extends through multiple valuable portions of the ML cycle.

Truss aims to be simpler to use in both straightforward and complex cases, requiring fewer lines of code but more importantly coming in later in the modeling process. Truss is opinionated and focused.

But interoperability is important to us and we are looking into ways to connect Truss and MLFlow.