Revisiting the discussion on mounting volumes in functions

[fadams]

Hello,
The discussion in this thread: #320 is pretty interesting, but I've been pondering some of the arguments.

Now I can generally sympathise with the take from @alexellis and others that some use cases for this might be considered "an anti-pattern for functions which are short-lived and stateless. This will encourage stateful behavior and assumptions." however I do also think that's slightly presumptuous, because not all volumes are the same and not all use cases necessarily have volumes mounted read/write

A scenario that I am thinking of might include a function that makes use of a machine learning model. Now in this case the function might of itself have short lived and stateless behaviour but that behaviour could depend upon a potentially very large, perhaps multi GB, model.

Now clearly one could argue that an approach might be to build the function containing said model, however that then results in a very large container which might be OK if the lifecycles of the model and function are intrinsically linked, but I rather suspect that there are advantages to them being rather more decoupled in many circumstances and certainly in my organisation the lifecycles of model creation and usage would seem to be somewhat orthogonal which points to a number of advantages in being able to create a model as a volume and have a function mount the volume.

So, TBH, I think that there is more nuance to this discussion than simply volume mounts = stateful = antipattern. I think that there are a number of equally good arguments for keeping containers as small as possible - these things are rarely totally black or white and I think that the danger of making a framework overly opinionated one way or the other risks making it unnecessarily unsuitable for a number of use cases.

None of this is to say that I disagree with the principals that have been espoused and I'm certainly a big fan of the 12FA and serverless manifestos, I'm just suggesting that when you build a compelling framework you'll inevitably find stakeholders trying to make creative use of it and it's worth bearing that in mind.

[alexellis]

Duplicate of #320

[alexellis]

Thanks for your thoughts @fadams

What is your specific business use-case? Can you run us through it?

I'm going to close the issue since we already have one tracking it and don't have persistent volumes / claims on the roadmap.

[fadams]

I thought that I'd explained the specific use-case above namely that functions based on machine learning can often depend on extremely large models of multi-giga byte size and that it is pretty much just as much of an anti-pattern to be pushing around multi-GB containers as it is mounting volumes and moreover it is very often the case that the lifecycles of model creation and model usage in ML are quite different so having the model stored as a read only volume mounted to a relatively small container tends to make logical sense.

This does not equate to the function in question necessarily having stateful behaviour.

Given that functions in OpenFaaS seem to be visible as K8s pods I'd have assumed that it wouldn't be a technically huge issue and not including them seems to be more of a philosophical issue.

That's OK, but I think that there are definitely a number of legitimate use-cases in this space that I'd say merit some reasonable discussion and even if its not in the roadmap. I think discussion around this is useful too because other people might may well be facing similar situations and discussion might help identify potential alternative approaches.

Like some of the contributors in the original thread I'm spending an undue amount of time and energy trying to convince my management that a serverless architecture is the way we should be going and it makes life a whole lot easier when one is able to field compelling responses to this type of question.

Another observation that I'd make is that whilst efficiency is fine you do seem to be awfully quick at closing issues/questions. TBH I very much doubt that too many people end up engaging in discussions marked as closed (I only stumbled across #320 serendipitously by accident whilst searching for something else). I'd say that an open source project is as much about fostering a community as it is about the code and closing off issues this quickly where a number of stakeholders have expressed legitimate interest in the topic comes across as a bit, well, dismissive really.