3 ms·
imo, if containers are the future ( very plausible ), then, things like Aws lambda are just as plausible if only just a bit further out. I think this is the ca
by andyidsinga 11y ago
imo, if containers are the future ( very plausible ), then, things like Aws lambda are just as plausible if only just a bit further out.
I think this is the case due to granularity of workloads and what apears to be a continuum in the workload container from metal > vm > containers > lambdas (as first class workloads).
fun stuff
- TheIronYuppie 11y agoDisclaimer: I work at Google on Kubernetes True, lambda is DEFINITELY an advance, but it's more like the salmon at a buffet that includes steak and chicken. Some applications will need just the ability to run code (lambda), some will need defined environments (containers) and some will need total isolation (VMs/bare metal). You'll see a mix of all of these in every mature environment - some things do not fit. For example, it's super unlikely that you'd be able to run a trading app on Lamdba (needs 10GB/sec of direct network access & memory); similarly it'd be totally unnecessary to run a thumbnail processor on bare metal (though you could, of course).
- andyidsinga 11y agogood points but I'm not sure anything about the fundamental lambda architecture prevents it from being applied to high bandwidth or low latency uses. especially if lambda functions are orchest rated to run in the metal ...think: kernel module implements lambda, then add orchestration glue up in user land