4 ms·
Your article mentions the reason you chose client code vs docker images, which I understand and can agree with. However, is there any plan to support docker im
by allcentury 10y ago
Your article mentions the reason you chose client code vs docker images, which I understand and can agree with. However, is there any plan to support docker images in place of client code?
What you're suggesting [initially] is very similar to what the folks at iron.io did but I'd really want to ship containers all around, not pieces of code. Iron.io addressed that a little too late in my opinion and their feature set around docker leaves a lot to be desired.
IMO, AWS Lambda and Google Cloud Functions are going to support docker in the near future, they have to if they want their ecosystem to be adoptable by all.
- soamv 10y agoSo we've started by focusing on improving the whole workflow, which is why we're operating at the source level. But we have occasionally heard the use case for working at the image level, and it has pros and cons, so we're thinking about it. I'd like to learn more about what you're trying to do -- did you consider just using Kubernetes Deployments and Services? Or are you saying you'd like to combine the on-demand start with working at the image level? Is this basically a resource optimization use case?
- chaosagent 10y ago(not GP) I'm actually building something that would require running large amounts of containers of varying usage (some almost never used, some constantly queried) that serve up webapps and other network services, and being able to run services inside of containers instead of functions from fission would be awesome.