Contemporary Views on Serverless and Implications
m.subbu.org
m.subbu.org
Players who jump on the term train are complicit in milking the confusion of people for gain. And that's perhaps much of the reason why we haven't unlocked the concept's value. To move forward, it would be useful to clear the air at the start, but the direction that consultants, customers, cloud providers, and developers will take the message is far from certain.
Edit: I will say, the term “serverless” itself is certainly sticky and will continue to grow into a larger catch-all term for managed compute innovations over the next few years or more. I think it’s also likely that, from a sales perspective, the term falls out of favor for more specific (and descriptive) types of offerings that all fall under the serverless umbrella — which is pretty much what this article addresses.
Don’t be surprised to see different types of conferences that move away from the “serverless” branding itself as the space continues to grow.
On the Berkeley paper:
>For a model training problem: “Lambda’s limited resources and data-shipping architecture mean that running this algorithm on Lambda is 21×slower and 7.3× more expensive than running on EC2.”
Did Amazon pitch that Lambda is always the better solution that EC2 for every problem set?
An experienced engineer or architect must be able to weigh the pros and cons to decide on which solution is correct. Lambda, FaaS etc doesn’t solve every use case. Is the author just trying to point out this specific fact or is it a frustration that Lambda isn’t a silver bullet?
>It is foolish to assume that we’ve all the serverless primitives necessary to solve all current and future programming problems.
Who is arguing we have them all?
Nope, which is why they have things like https://aws.amazon.com/batch/ as well. I don't know why the paper picks on lambda either.
Don’t just complain. If you know of a better way, tell us or go do it yourself.
If you're small then serverless provides no real advantage over Docker or a VM with a small footprint that's easy to update.
If you're large enough that you want automated infrastructure scaling, well, technical considerations as far as things such as latency, service dependencies and data storage become complex enough that you're going to need a bunch of custom components and people who can manage them.
It seems like FastCGI has come around again, except that it's way costlier and more difficult.
Things like edge caching and a few latency-sensitive self-contained functions are a few of the very real use cases for this (which CloudFlare and others seem to be working on), but aside from that it's another specialty application that seems to be taking over for no particular reason, much like iterations of NoSQL and other faddish garbage.
A less-capable AI may be able turn clear and unambiguous specifications into working code - but someone needs to create those clear and unambiguous specifications.
By analogy, creating a perfect camera will not put artists out of business.