Well, the people who dismissed the term 'serverless' early on as trite, misleading, and vague were proven right: these days it's a cloudy notion about something loosely cloud-related, such that posts like need to exist that can clarifying all the possible meanings with one-liners using real terms of art; yet the term clearly has cachet with technical-ish and nontechnical decision-makers as a Solution that unlocks Value and other more-good-than-bad outcomes that are bullet-shaped and made out of silver.
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.
You are right. I anticipate terms like “fully managed compute” may become more descriptive for FaaS offerings (Netlify Functions and ilk), and I’m not really sure what to make of where people will take k8s / on-prem FaaS / data layer offerings (Aurora).
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.
No offense but this comment is very pretentious. I think you’re trying to say you don’t like the term serverless itself. Your writing, on the other hand, tries really hard to sound intelligent and takes 2 paragraphs to state something you could have stated in less than a sentence.
... an ad hominem argument from a throwaway account probably supports the OP’s point, for what it’s worth. I’m not sure you achieved the intended goal here, or what that goal was.
I find this article frustrating. Yes, basically you can classify any managed online service as “Serverless”. Amazon was somewhat clever when using this term for Lambda, although personally I hate it (there are servers in the back end, all that’s changed is who provisions, manages, and supports them).
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.
Lambda is pretty useful. My team had a use case for data pipelines and some quick, easy monitors that do health checks. I despise the term serverless, but yeah... I see posts like this one, and it’s amazing even among seemingly intelligent circles, there are so many folks who will shit on something or a concept with absolutely no alternative or solution from them.
Don’t just complain. If you know of a better way, tell us or go do it yourself.
To me serverless is inverting the traditional client-server model of the web. Provided the right application code the user doesn't need the server. Conversely the server needs the user primarily for business justifications. If there is ever an opportunity for disruption this is certainly it (if done correctly).
Serverless seems to me like another one of those mostly fashion-driven things where the actual use cases are applicable only to a very tiny minority of developers.
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.
CGI and FastCGI are really underappreciated as ancestors for this technology. They also mapped the same problem contours - using VM languages means paying the VM startup time cost.
When AI can code, design, publish to automated infrastructure and get feedback from users, the demand (and salaries) for developers and designers can/may drop precipitously.
My job is applying a rigor of thought to unclear and sometimes conflicting specifications, and figuring out what users/clients "really" want. It'll take strong AI to be able to do that.
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.
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.