
Contemporary Views on Serverless and Implications - GordonS
https://m.subbu.org/contemporary-views-on-serverless-and-implications-1c5907c611d8
======
sarcasmic
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.

~~~
throwaway98121
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.

~~~
keithwhor
... 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.

------
throwaway98121
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.

Who is arguing we have them all?

~~~
justinsaccount
> Did Amazon pitch that Lambda is always the better solution that EC2 for
> every problem set?

Nope, which is why they have things like
[https://aws.amazon.com/batch/](https://aws.amazon.com/batch/) as well. I
don't know why the paper picks on lambda either.

~~~
throwaway98121
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.

------
austincheney
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).

------
Daishiman
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.

~~~
pjc50
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.

------
heyjudy
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.

~~~
xsmasher
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.

