The ultimate step beyond FaaS will be invocations as a service. Sure, you can provide a function API, just like the Go Lambda runtime does, but really you're uploading an RPC server. Allow ppl to package that in a container and boot it fast, and voila.
-
-
I've got one other practical reason. But I think it is not for public twitter.
-
A *lot* of customers say they love the built in language model and just want better library capabilities. That’s not the same as containers and many do no want some container format model they need to deal with
-
But like I’ve been saying, that’s just a tooling issue. They’d only need to “deal” with it in the same way they do zipfiles. You think most Java Lambda devs really know the structure of them?
-
So what does a “container” format offer up? What does it solve?
-
Reproducibility. You can look out there at all the blog posts with ppl explaining how to compile things for Lambda – I'm sure you've seen them. I mean – AWS Sam Local uses docker-lambda just to try to reproduce the env reliably!
-
Yup and these are solvable problems without containers. I’m not sure they are the key here as they don’t really provide that much and introduce bloat and overhead themselves that need tooling
-
Well the key needs to be something. As more and more ppl use Lambda for a wider variety of things, like ML, they're running into more and more issues with its restrictions and specificity.
-
You're also locking ppl out who want to use other languages. Sure you could develop them yourselves. Have 50 different Lambda runtimes. OR one container runtime, and some libraries so they can just compile functions if they want – like Go.
- 1 more reply
New conversation -
-
-
That's demonstrably false – the Go Runtime is a perfect example. It's *more* generic than the other runtimes – it just runs a binary you upload. That literally could be a docker binary – they'd just need to optimize some things (like they do with mounting /var/task etc)
-
The business lock-in for Lambda isn't the packaging or code structure – it's the fact that it integrates so well with all the AWS services, you just can't help but want to use it.
-
Well, that and the fact that it deploys so quickly and scales like the bejesus. And yeah, there'd be some challenges to get docker containers to cold boot as fast – would need to pre-mount (like it does currently with /var/task) for example. Maybe place some restrictions?
-
I bet internally there are all kinds of strange reasons Lambda is built the way it is. I can only speculate. But I don't think the arch of the go runtime makes what I said obviously false.
-
I'd also guess a similar internal debate to what we are having happened. "long term business goals" vs "dev ux" vs "we needed Go support yesterday!"
End of conversation
New conversation -
-
-
There is a huge difference, actually: event handlers and step functions
-
Difference between what? Event handlers and step functions are just how the process is invoked from the outside – nothing to do with the model internally
-
Difference between running the code and running containers.
-
So then I'm not sure what you mean – you could keep event handlers and step functions even if you're using a serverless containers model
-
There is nothing to keep with lambda, but with containers it’s a typical heavy lifting effort to developer http handlers.
-
Go Lambda does the same thing – just uses gob rpc instead of http
A container could do the same thing if that was really a bottleneck, though I imagine it's a micro-optimization (a Node.js http server starts in ~10ms)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
I do realize they can be much more, but you just described so many containers.
It'd be the same business model as Lambda is right now