
Cloud Programming Simplified: A Berkeley View on Serverless Computing - adjohn
https://rise.cs.berkeley.edu/blog/a-berkeley-view-on-serverless-computing/
======
agentultra
It’s also great for vendor lock in and rent extraction. At least in its
current iterations. I’m fairly certain Amazon isn’t going to make it easy to
run your “serverless” applications on anything but their infrastructure.

What would be more interesting would be languages and runtimes that run on the
next network that is distributed, peer-to-peer, and able to be trusted. And
easier to program for than they are today in their current iteration.

 _Edit_ : which is where I thought the BOOM group was going back in 2012 or
so.

~~~
meekins
The interface between Lambda and your business logic is usually very thin so
in case of simple REST APIs migrating from platform (as long as the target
platform has a compatible language runtime) to another or to be executed in a
web app framework is rather easy.

Serverless applications' reliance on other proprietary services like Cognito,
DynamoDB etc is another thing however...

~~~
tsimionescu
The problem is also that Lambda works really poorly with anything that is NOT
Cognito and DynamoDB. For example, we were using some CouchBase we deployed
ourselves - however, that meant that the Lambda now had a network interface in
a private subnet, and start times skyrocketed, especially for concurrent
access. When we also started doing our own authentication with yet another
Lambda, request times for cold lambdas (which also means every new concurrent
connection, remember) almost doubled.

There's also the fact that most of the code isn't really gone, it's just
transformed from web server logic to lambda deployment/configuration logic.

The biggest win all told seems to be security - at least with Lambda you don't
need to worry about staying on top of OS updates and the likes. I'm not at all
convinced that we gained much of anything else.

Oh, and one thing that's rarely discussed is how much development&qa costs
skyrocket when you have a larger team developing a fully serverless
application, each with their own setup and running a few performance tests
every few months...

~~~
scarface74
We use lambdas all of the time with ElasticSearch, Aurora (Mysql), etc.

------
jacques_chester
For the paper being introduced, the direct link is:
[https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-...](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf)

I agree with a lot though I think they overegg the possibilities for data
performance at the as-a-Function level.

Some more specific reactions:

> _Put precisely, there are three critical distinctions between serverless and
> serverful computing ... 3. Paying in proportion to resources used instead of
> for resources allocated._

I've taken to calling this "buying capacity vs buying consumption". You need
to think about which you need (they touch on this in the fallacies section).

An ambulance is idle almost constantly. When I was a kid they were built on
F150s and vapourised ten litres every time you glanced at them. But when I
need one I don't care about the idleness and resource costs, I want to come to
my aid ASAP. What I _don 't_ want is the paramedics converging from random
locations on electric scooters rented on-the-fly.

> _In acritical departure, [AWS Lambda] charged the customer for the time
> their code was actually executing, not for the resources reserved to execute
> their program. This distinction ensured the cloud provider had “skin in the
> game” on autoscaling, and consequently provided incentives to ensure
> efficient resource allocation._

I'd say yes and no. Yes, it provides an incentive to the platform provider.
But there is a much, much bigger incentive to achieve platform lockin through
data services. Keeping the function alive after the first invocation is a
subsidy. I would bet folding money that Amazon are tracking this cost and
weighing it against their market strategy.

> _By allowing users to bring their own libraries, serverless computing can
> support a much broader range of applications thanPaaS services which are
> tied closely to particular use cases._

I'm not sure if the authors are familiar with buildpacks, despite citing
Heroku. They don't mention buildpacks anywhere.

Disclosure: I work for Pivotal, we do a bunch of stuff in this area, including
Buildpacks and Knative. But nothing is forward looking, personal opinion,
consult your dr etc etc

------
coderintherye
>We expect serverless computing to become simpler to program securely than
serverful computing, benefiting from the high level of programming abstraction
and the fine-grained isolation of cloud functions

In my view, that's the really key bit. Securing systems is an endless task,
even (or especially) if they are cloud hosted.

~~~
redisman
Right now serverless is definitely not simpler than a monolith. It's "simple"
if you squint but any real workloads have you dealing with high concurrency
for almost all tasks that a single monolith could handle with a single
instance.

~~~
Cthulhu_
You are right and I'm glad you're mentioning it, and the general skepticism
about serverless; it's not a golden hammer, its applications are limited, and
not every problem should be (can be?) solved with a serverless architecture.
The same goes for microservices, which is another gold hammer that people
picked up and started to apply to a lot of problems - I've seen a few projects
where microservices was the initial architecture, while all of those would've
been better off with a monolith for the first two years of operation (before
any significant load) to figure out the actual problem to be solved.

------
choppaface
I'm surprised a Berkeley survey would neglect to mention PiCloud, which may be
defunct but cloudpickle is still used heavily today (e.g. in Spark). The paper
also appears to neglect the issue of code deployment, which can be a major
undertaking and hidden cost of any web-based application, especially if the
app has particular system dependencies.

There are (private) solutions out there for moving parts of running JVM
programs across machines. Wouldn't one expect a forward-looking view of
Serverless to encompass serialization and transport of the compute
environment?

~~~
wmf
_moving parts of running programs across machines_

Why is this desirable and what is the magnitude of the benefit?

~~~
choppaface
One application is fault tolerance. If you need to take a machine down, you
can move the node (JVM program) to some other machine. So similar to pausing a
long-running Lambda function, moving it elsewhere, and resuming it.

------
crazyforbytes
Does anyone else not feel so good about a future of computing where everything
but the application layer is rented from Jeff Bezos?

~~~
dman
I agree with you on this, it is a moral dilemna I think about every day.
Programming was one of the few professions where the practitioner owned/had
access to their tools in their own spare time. Across history and professions
this is a rare property, and I fear that we might lose this in the next 10-20
years.

Disclaimer: Views expressed are my own and do not reflect any positions held
by my employer.

~~~
scarface74
What I have access to with AWS just using their always free tier and their
cheap offerings is more than I ever could have dreamed of 5 years ago, let
alone as a hobbyist in my bedroom doing 65C02 assembly in the 80s.

------
rlyshw
>[serverless computing] closely parallels past advances in programmer
productivity, such as the transition from assembly language to high-level
programming languages

Is this serious? The author seems to imply that we can just abstract away the
entire internet in the same way we abstracted away copper wires.

~~~
TomMarius
But we did, didn't we? How is modern serverless different from shared LAMP
hostings of the past?

~~~
scarface74
Shared lamp hosting didn’t give you the security, scalability or isolation
that lambda gives you.

~~~
TomMarius
The implementation was lacking, but the concept is nearly identical.

------
joshe
Great paper, I've only gone through about 10% of it, but it offers a lot that
the vendor docs and industry talks don't.

Btw, this is David Patterson one of the inventors of RISC fame. Great podcast
with him here (mostly about new Tensorflow chip and history):
[https://softwareengineeringdaily.com/2018/11/07/computer-
arc...](https://softwareengineeringdaily.com/2018/11/07/computer-architecture-
with-dave-patterson/)

Worth noting that he's at Google, but it looks like he had AWS reviewers.

------
suyash
The paper is a good read for those fairly new to Cloud Computing, even though
it was published about 10 years ago!

~~~
justincormack
This is not that paper it is a new one on serverless.

