
Serverless Computing: One Step Forward, Two Steps Back - snaky
https://arxiv.org/abs/1812.03651
======
Jhsto
On the same note, CloudFlare’s approach to serverless computing by leveraging
V8 sandboxing instead of traditional virtualization is fascinating:
[https://blog.cloudflare.com/cloud-computing-without-
containe...](https://blog.cloudflare.com/cloud-computing-without-containers/)

Considering challenges of interconnected cloud computing and common IR (of
which the latter is mentioned in this paper) an interesting distinction
arises: WASM, in comparison to containers, brings us a single language (JS),
and through this, possibly a single “orchestrator” (V8 Isolates). Of course,
this is more or less saying that the world would be a better place if everyone
would be driving a Volkswagen. But this is like a second chance to iterate
such idea and maybe do something about it. Isn't this a step towards the
future of cloud computing?

~~~
zackbloom
Workers are network addressible which seems to directly respond to one of the
complaints in the article. Beautifully, if you call one Worker from another
they have a decent chance of running on not just the same server, but in the
same process. When one Worker calls another its data doesn't even leave user-
space, even if the two Workers are owned by different people. Imagine calling
a third-party API and having your request never even need to leave the process
to be handled.

~~~
hueving
If the request never has to leave the process, that means there isn't anything
the third party API is doing that persists state or calls out to another
backend. In that case, wouldn't it just be better to import this third party
API directly as code and call it for significantly better reliability,
performance, and reduced complexity?

~~~
zackbloom
There are advantages in being able to have a security barrier between your
code and that of your customers, and that you can push releases etc without
having to update every downstream consumer.

More importantly though, we're working on incorporating storage in a
meaningful way.

~~~
jayd16
If the third party code is running in the same process than the security is
managed by V8 (or whatever runtime). Does such a thing exist in other managed
languages? Does anyone know if C# or Java(for example) have the concept of
untrusted libraries?

~~~
heavenlyblue
You could think of "untrusted library" as of a wrapper around an HTTP API. The
code you don't run, but depend upon it's results.

------
sheeshkebab
Am I the only one that thinks severless is about creating a bunch of vendor
locked-in technical debt?

~~~
colllectorof
You're not the only one.

Some time ago I worked with a bunch of people who staked their careers on
moving everything to AWS and converting it to serverless architecture. Here is
just one example of how fishy it was. They used Dynamo. During presentations
to the outgroup, they constatly praised Dynamo as being flexible, scalable and
fast. However, internally they _constantly_ struggled with various limitations
of the database, from limitations of indexing to not being able to get certain
types of metadata.

My point is, the architecture they were designing was heavily bent around
Dynamo's strength and weaknesses. Considering how extreme and peculiar those
strength and weaknesses are, switching to another database would require heavy
re-engineering of the rest of their architecture, much more so than, say,
switching between Oracle, MS SQL and Postgress.

~~~
pavelrub
Not sure I understand this. Why did they choose Dynamo? And what does
serverless has to do with this?

This seems like a simple case of people choosing the wrong tool for the job,
without really understanding its limitations or capabilities.

> say, switching between Oracle, MS SQL and Postgress.

That's because those are all relational DBs that use SQL. If they chose some
other NoSQL DB they would likely have encountered similar "peculiar" strengths
and weaknesses. And I'm still not sure what this has to do with serverless -
they could've have easily implemented a serverless architecture with MySQL or
Postgress on RDS instead of Dynamo. But they chose not to.

~~~
davidjnelson
Aws might have fixed this by now with severless aurora, but as of earlier this
year the issue was connection pools didn’t work on lambda functions due to
their ephemeral nature not being able to keep the tcp sockets open for more
than a few minutes before the functions froze or were terminated.

~~~
dlhavema
We use pools in lambdas to Amazon Aurora and it works out fine. Only limit we
hit was when the db server was configured way too small.

~~~
zedpm
Are you running your Lambdas inside the VPC (and incurring huge cold-start
latency), or are you running your database exposed to the public internet?
I've avoided using Lambda for anything that requires relational database
connectivity because those appear to be the two options, and neither is viable
for me.

------
ciconia
As others here have already noted, serverless is still not fundamentally any
better than good old CGI, and despite recent advances in virtualisation it
still follows the same stateless request-response paradigm.

For me the biggest shortcoming in serverless is that it is actually a poor fit
for modern interactive web apps (and apps in general) with a constantly
changing state.

Technologies such as HTTP/2, websocket and SSE are clearly pointing in the
direction of long-running client-server interaction, yet current serverless
solutions have (to the best of my knowledge) no answer for that.

I think the big challenge is in how to do serverless computing with long-
running processes, in a way that solves isolation and scalability at the same
time.

~~~
nostrebored
What's happening here that an Layer 7 Load Balancer, Multiple Serverless
Functions, and a Websocket can't handle?

AWS released exactly that during the last re:Invent with the Websocket-
integrated ALB being capable of triggering Lambda

~~~
chii
You're basically locking yourself in with a particular vendor if you choose to
use that tech (rather than a standard stack deployable anywhere with compute
power).

~~~
bartread
Going beyond the vendor lock-in, one of the biggest initial draws of
serverless - from speaking with friends - has been simplicity in situations
where state isn't a concern. On the other hand, here we're discussing a bunch
of hoop jumping to get stateful functionality that might more easily achieved
by adding a library such as SignalR, or socket.io into your app.

Whilst this is probably a few screens to set up via the AWS, and can obviously
be automated, you add complexity to development and delivery. Critically you
also make it harder to diagnose and fix problems.

Like anything it's a trade-off: for some apps these issues won't matter so
much, for others they will. For us, it would definitely be a problem.

~~~
redisman
Serverless is a tool with good use cases where your tradeoff-win will be great
scalability. It's not that great for general use (yet) IMHO. You can create a
"session" in redis pretty easily if you're willing to add another database as
a requirement. That way you can share state. It's also very new so the
ecosystem will keep maturing and enabling more use-cases.

------
sytse
I loved the article
[https://arxiv.org/pdf/1812.03651.pdf](https://arxiv.org/pdf/1812.03651.pdf)

It mentions two temporary bottlenecks:

1\. Functions can run only for 15 minutes and experience cold-starts.

2\. You can't use specialized hardware like GPUs.

It also mentions two fundamental bottlenecks:

1\. Serverless functions are run on isolated VMs, separate from data. In
addition, serverless functions are short-lived and non-addressable, so their
capacity to cache state internally to service repeated requests is limited.
Hence FaaS routinely “ships data to code” rather than “shipping code to data.”

2\. Because there is no network addressability of serverless functions, two
functions can work together serverlessly only by passing data through slow and
expensive storage. This stymies basic distributed computing. , With all
communication transiting through storage, there is no real way for thousands
(much less millions) of cores in the cloud to work together efficiently using
current FaaS platforms other than via largely uncoordinated (embarrassing)
parallelism.

Disclosure: We just shipped serverless in GitLab
[https://about.gitlab.com/2018/12/11/introducing-gitlab-
serve...](https://about.gitlab.com/2018/12/11/introducing-gitlab-serverless/)

~~~
scarface74
As far as “bottlenecks”.

Almost all applications have data separate from code. Most implementations
don’t run their applications on the same server as their databases.

Most app servers shouldn’t be “caching state locally” anyway. Once you do that
it makes scaling horizontally harder - you have to Implement sticky sessions.

And in all practicality, I would assume that most people are using EBS for
their storage which is network attached storage.

Two lambda backed microservices work together just like any other
microservices - via known urls and over https.

~~~
Karrot_Kream
> Most app servers shouldn’t be “caching state locally” anyway. Once you do
> that it makes scaling horizontally harder - you have to Implement sticky
> sessions.

Why not? In-memory caches are fast and fairly uncomplicated to write.

~~~
hinkley
You always have to apply pressure to keep the system decoupled or you get a
Ball of Mud. If you switch to micro services and serverless and then have a
high fanout and caches everywhere just to make the numbers work, you haven’t
gotten rid of the Ball of Mud, you’ve just hidden it in plain sight.

Serverless and embarrassingly parallel problems look like pure functions
punctuated by one or two state changes. To get that you should probably be
passing all the data in, instead of communicating out of hand with a cache to
keep your fanout from looking awful (again, hiding the problem).

~~~
dahauns
But who is doing the "passing-in" then, and where does the data come from?
This still sounds like hiding the problem...or more specifically, making it
someone else's problem.

~~~
hinkley
Who does the passing in in development mode? Where does the data come from?

You have this problem anyway, and it blocks you from launching new code. These
out of band communication mechanisms always lead to problems with developer
ergonomics and repeatability.

It's essentially a larger version of the problem of testing pure functions
versus heavy usage of mocks. Passing the data in directly makes testing the
callee very simple.

------
Agebor
I'm not sure if i understand their view on fundamental limitations - they
don't seem fundamental to me:

1\. It does not seem impossible to imagine a function that spawns code close
to data, be it on a VM with a connected fast SSD drive already populated with
data. Also, Lambda-at-edge and Cloudflare workers are already more like
“shipping code to data.”, or " the customer" in this case.

2\. Functions are load-balanced and potentially parallelisable to millions of
invocations. The only missing piece is some kind of parallel-invoke call, to
give each instance of a function a distinct piece of data to process, and an
identifier to save the result under. The identifier could easily refer to a
local disk location, in some future implementation.

Also, another point from the article: "FaaS discourages Open Source service
innovation". seems wrong to me, as it may be said only about current super-
early implementations, reason being, they are new.

In the long-run, I'd expect serverless to help open source, because of a
simplicity of deployment. We will likely have projects working on an
abstraction layer of compute and storage, hiding the underlying cloud or
multi-cloud implementation. (Kubernetes is one candidate, it just needs ideas
in the like of Virtual Kubelet to become more serverless).

~~~
hueving
>Cloudflare workers are already more like “shipping code to data.”, or " the
customer" in this case.

That's shipping code further from the data, unless you store all of your data
on your customers' hardware.

~~~
Agebor
The closest data would be in the datacenter closest to the customer, not on
customer's hardware. But I mentioned it to illustrate that the code already is
location-independent a little.

------
patsplat
Serverless applications suffer from a few under reported drawbacks:

\- Local development is complex. Does one provision a full cloud environment
per developer? Emulate a cloud environment locally? These are solvable but
it's a grind of special cases.

\- Limited customization. Eventually one needs to customize the language /
libraries of the lambda. Again these are solvable with a grind of special
cases.

\- Limited execution model. Not all compute tiers are the same. Some quickly
assemble results from a database. Others run for a long time. Others build up
a model in RAM before delivering results. Serverless optimizes for some but
not all models.

Unlike serverless / lambda, all of the above can be addressed by containers.

\- Containers have orchestration solutions for local development and
deployment

\- Containers are designed to support customization

\- Containers can be deployed to run in many different ways.

Not to be a booster, but in my experience containers are the scalable compute
architecture.

~~~
jiveturkey
> drawbacks:

> ... Serverless optimizes for some but not all models.

How is this a drawback? General purpose things are equally _bad_ at all
things. If serverless is optimal for some models, those are the places you use
serverless!

~~~
patsplat
Please, share the use cases where serverless is the optimal choice.

Because I've tried it. For problems like thumbnail generation which is
literally the canonical example [1]. And even in that case, found myself
switching the workload back to containers to control the exact version of
imagemagick to prevent a color gamut bug.

1\.
[https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example...](https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html)

------
tirumaraiselvan
A much needed paper which goes into the programming model in serverless rather
than the operational model. Although, the first cases study is obviously bad
for serverless (training a ML model) whereas the second case study does not
indicate bad results (using trained ML model) as half a second latency is
acceptable. As the paper itself quotes:

`One might argue that FaaS encourages a new, event-driven distributed
programming model based on global state.`

Yes, exactly. It is not made for cluster computing or data-centric
applications. It is made for making applications more modular, atomic and
compositional with the upside of less ops and more scale and the downside of
lower performance.

~~~
DATACOMMANDER
I think that the authors of the paper would say that, ideally, serverless
would be ubiquitous, the obvious choice for the vast majority of use cases. A
pipe dream? Perhaps. But that’s the dream, and we’ll never be able to make the
dream a reality unless people write papers like this one that highlight the
work that separates where we are from where we want to be.

------
spullara
Going through the article I think they made some mistakes in analysis and also
miscategorized some features.

1) Limited Lifetimes, Stickiness: These is good and leads to good design when
you scale beyond a single server. It prepares you for dealing with the reality
that if you want to run a service 24/7 with no downtime you need to prepare
for things like different versions being in production, failures, and stale
caches.

2) I/O Bottlenecks: If you are parallelizing your workloads you will actually
see more aggregate bandwidth than you could scale up quickly with normal
server hardware. Sure a single Lambda might not have the full amount but you
can run 1000 of them at once.

3) Communication through slow storage: This is not entirely true, you can call
another Lambda directly but yes you can't access a particular instance. That
is a good thing. Designing systems where you need to return to the same
instance is an anti-pattern.

4) No Specialized Hardware: I don't expect this to be a limitation for long.
There is no reason why you couldn't ask for specialized hardware in the
definition of a Lambda and the scheduler take care of it. It will, in fact, be
better than the status quo because parts of your application that don't need
that specialized hardware won't need to pay for it. In a typical larger
application you would probably end up running part of your heavy CPU load
inefficiently on your GPU hardware because it would be convenient. Also, most
of this might be unnecessary in many cases since you would likely take
advantage of a service that was specifically designed to run specialized
workloads. Only if you DIY would need this support. Lambda is especially good
at coordinating such services.

5) Faas is a datashipping arch: Not even true today. Lambda lets you move the
computation to the data like they are with CloudFront Lambda, S3 Batch and
Snowball Edge Compute. It is in fact easier to execute the code near the data
when encapsulated in this way.

6) FaaS Stymies Dist Computing: Maybe they have applications that can afford
to fail at any point and not recover but keeping your global state in a
distributed data storage system is the right thing to do generally, not just
with Lambda. Might not work for HPC but it generally doesn't need to be
reliable in the same way applications do.

At least in section 3.2 they finally seem to understand that most of the
limitations are a good thing and if you are building software that don't have
them you are likely not building scalable, reliable software systems. Also, if
they think that their section 4 is somehow non-obvious to AWS and others they
really aren't paying attention.

------
iamleppert
Having your functions be stateless is actually an asset and forces you to
write your code in a way that doesn’t make assumptions about the state of some
cache, which makes it inherently more reliable.

Cold starts aren’t much of a problem if you have non-interactive workloads, or
can design UI’s in such a way to let the user know the first interaction will
be slow but the rest fast, and if your modality allows for such. These
problems tend to go away with any moderate scale in any event.

The time limits I’ve found to be an asset as well, and forces me to think
about how to structure my task into discrete and well known units of work.
This makes development harder but leads to an overall more reliable system
where any one invocation failure won’t seriously jeopardize the larger task
and can easily be recovered. You can’t say the same for a process that’s been
running for hours and suddenly dies without committing its work.

That said, I’d love to have serverless GPU functions. I’d love to be able to
somehow run shaders over superresolution images. That would be amazing for me
working in the mapping world.

------
amelius
If a marketing term means exactly the opposite of what you think it means
(that's some hefty server they've got there), then you probably should look
elsewhere anyway. Unless you enjoy dealing with a community and support team
that speaks an inverted lingo, of course.

~~~
millstone
Only programs that talk to servers can be serverless.

In two years we'll discover the benefits of running serverless workloads on
the client and there will be a new name for that.

------
cnbeining
Some questions:

1\. The authors are quoting exact performance metrics and limits, which is
making the article more about "Amazon Lambda" rather than "Serverless
Computing".

2\. The authors mentioned a "15-minute lifetime" problem. Although it could be
concerning that cache may be invalided sooner than running the same code on
other infrastructures, a use case like this could easily migrated by using
container. Not to say this number could be adjustable - this is a limit that
is set by AWS rather than some theological limit. Thus using this problem to
attack the serverless computing idea would be unfair.

3\. The authors mentioned low IO problem. As public cloud is a shard
infrastructure, it is only reasonable for end users to assume a baseline IO
performance when using the platform - and this applies to any service that any
public cloud provides, currently and in the future. It would be more
beneficial if AWS could reveal the baseline performance in number, as this
would assist developers with planning.

4\. The author attacked serverless computing about its "Communication Through
Slow Storage". This is probably not avoidable and is common practise in modern
developing and should not be used to attack the idea of serverless computing.
AWS do provide u-12tb1.metal EC2 server that comes with 12TB of RAM for this
use case, though.

5\. The author mentioned that currently serverless has "No Specialized
Hardware". Again, this is a attack on AWS Lambda rather than serverless
computing, and is a particular function that could be easily added. (I have a
feeling that Cloud TPU could be used with Google Cloud Function, but it's a
assumption.)

6\. The authors also attacked that "FaaS discourages Open Source service
innovation." Supposedly one can only imagine that more software projects would
be PORTED TO serverless, and there should be no real issue running them as
standalone application. I lost track of what the authors are trying to argue.

------
stochastician
I actually agree with many of the suggestions in the paper, but of course am
biased as these are my colleagues and we disagree on some of the interesting
capabilities of modern serverless architectures (see
[https://arxiv.org/abs/1810.09679](https://arxiv.org/abs/1810.09679) ) . But
it comes across like this DeWitt/Stonebraker piece from back in the day,
"MapReduce: a major step backwards"
[https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...](https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html)

------
bitL
If I were a Machiavellian dominant player trying to keep my advantage in
distributed systems, I'd invest into serverless propaganda to mislead everyone
performance/cost-wise, keep my dominant position and get people doing real
performant distributed systems for cheap due to market hunting slow/costly
fad.

~~~
abledon
How does someone grow up to be Machiavellian ? Bad childhood ? Extreme
circumstances forcing them to always default in to a ruthless uncaring
attitude?

------
chillaxtian
Does anyone know why lambda is taking off, compared to heroku style PaaS?

Heroku style still removes the burden of managing servers ("serverless"), but
doesn't lock you in as much. You could easily move your own server process to
a different provider.

Is it just because Amazon doesn't offer anything similar to heroku?

~~~
chrisco255
A number of reasons. For one, you pay per execution with Lambda (and other
similar services like Azure Functions and Cloudflare Workers)...and the costs
can be dramatically lower. Here's a great article by haveibeenpwned author
explaining how they support 141 million requests a month at 2.6 cents per day:
[https://www.troyhunt.com/serverless-to-the-max-doing-big-
thi...](https://www.troyhunt.com/serverless-to-the-max-doing-big-things-for-
small-dollars-with-cloudflare-workers-and-azure-functions/)

Besides cost, automatic scaling is something traditional PaaS does not offer.

------
brightball
I honestly don’t understand why this hasn’t been PHP’s niche for years. It’s
exactly what the language has been doing for years. That’s why PHP hosting is
so cheap.

------
SlowRobotAhead
I’m not sure I would call it two steps back.

I think it’s quite obvious that every web application everywhere doesn’t need
a full OS install chugging along all day everyday waiting for things like
mouse input or having its own patches for services that will never be used.

It’s first gen tech. Really curious to see where it goes.

~~~
colemickens
I mean, where do we think the functions are executing now? It's not like
Ubuntu Server is running Xorg, or has libinput installed, nor have any of
those things ever been operational or developmental considerations on any
"non-serverless" app.

Or maybe you're in a super cutting edge functions deployment where you're
actually deploying microkernels? Seems orthogonal to me, and doesn't seem to
address the data locality, etc issues brought up in this article.

There are so many people in this thread saying stuff like "PaaS doesn't allow
auto-scaling" and I just don't really know what's going on. It's baffling to
me. I guess if all you know is an archaic build process and manual deployment,
then it looks great. But I'm willing to bet most of these function platforms
bottom out on containers-on-k8s-on-vms anyway.

I am increasingly, increasingly convinced that people don't really need or
want "serverless". They want the final step in the build/development process
that they thought they were going to get with Docker -- they want to write
code and have it running somewhere. I really don't buy that Serverless/Lockin
are the right or best way to that future.

~~~
SlowRobotAhead
>They want the final step in the build/development process that they thought
they were going to get with Docker

This isn’t my area, so I don’t know - but why didn’t people get that with
Docker?

~~~
DATACOMMANDER
They didn’t get the magic functionality they wanted because magic isn’t real.
Coming from a devops background with more of an emphasis on “ops” than “dev”,
my (admittedly biased) opinion is that a lot of developers believe three
things simultaneously:

1) Ops people are bitter, power-tripping killjoys who couldn’t make it as
developers and do nothing but click buttons and think up ways to make the
lives of developers difficult.

2) Ops/infra really isn’t as difficult as ops people would have you believe,
and some day very soon all the ops people will be replaced by code.

3) Someone else should write the code that’s going to automate the ops people
out of existence.

These developers are like highly specialized scientists who think that their
PhDs make them experts on everything. They have no idea what happens to their
code once they commit it and they don’t care to learn, but they’re pretty sure
that it can’t be all that complicated.

Ops will—like everything else—eventually be eaten by software, but the people
who drive that transformation sure as fuck won’t be JavaScript specialists who
can’t troubleshoot their inability to connect to the VPN. They’ll either be
systems/infra people who can code, or well-rounded coders who understand that
infra is actually nontrivial (or a group comprised of both).

If it seems like I have a problem with devs, it’s honestly only because a
vocal minority of devs have a big problem with me.

------
orthecreedence
I love how everyone always shat on PHP (the original serverless
technology...convince me otherwise) and now everyone is scrambling to reinvent
PHP.

~~~
mypalmike
Does PHP automatically scale infrastructure to meet demand? Can you bring up
1000 instances of your service for spikes in volume? And then scale back down
when the spike is over? Without writing code?

Nobody is reinventing PHP.

~~~
CamTin
Totally stateless PHP apps (retrieving and storing state at the top and bottom
of each request) plus autoscaling based on CPU load starts to look pretty
close to Lambdas + scheduled tasks to keep them "warm". This is how most LAMP
apps are/were built, notably Wordpress.

The real pain point in any auto-scaling/cloud/serverless application is and
will probably always be the stateful bits. I think the first cloud provider to
really figure out this killer bit will be the ultimate winner of the cloud
wars. It will probably look something like Amazon's "Aurora Serverless" but be
even more frictionless.

------
bfirsh
Here's a web version if you're on a phone: [https://www.arxiv-
vanity.com/papers/1812.03651/](https://www.arxiv-
vanity.com/papers/1812.03651/)

------
karmakaze
TL;DR

3 WHY SERVERLESS TODAY IS TOO LESS

(1) Limited Lifetimes. After 15 minutes, function invocations are shut down by
the Lambda infrastructure. Lambda may keep the function’s state cached in the
hosting VM to support “warm start”, but there is no way to ensure that
subsequent invocations are run on the same VM. Hence functions must be written
assuming that state will not be recoverable across invocations.

(2) I/O Bottlenecks. Lambdas connect to cloud services—notably, shared
storage—across a network interface. In practice, this typically means moving
data across nodes or racks. With FaaS, things appear even worse than the
network topology would suggest. Recent studies show that a single Lambda
function can achieve on average 538Mbps network bandwidth; numbers from Google
and Azure were in the same ballpark [26]. This is an order of magnitude slower
than a single modern SSD. Worse, AWS appears to attempt to pack Lambda
functions from the same user together on a single VM, so the limited bandwidth
is shared by multiple functions. The result is that as compute power scales
up, per-function bandwidth shrinks proportionately. With 20 Lambda functions,
average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a
single SSD [26].

(3) Communication Through Slow Storage. While Lambda functions can initiate
outbound network connections, they themselves are not directly network-
addressable [...] can only communicate through an autoscaling intermediary
service; today, this means a storage system like S3 [...]

(4) No Specialized Hardware. FaaS offerings today only allow users to
provision a timeslice of a CPU hyperthread and some amount of RAM [...] no API
or mechanism to access specialized hardware. However, [...], hardware
specialization will only accelerate in the coming years.

~~~
karmakaze
While each of the above points are mostly quite factual, I don't personally
find any of them to be restricting. We run a mixture of stateless and stateful
services and serverless is suitable for the stateless ones.

The original problems for network security being solved by running functions
in a VPC and secure connections to databases and even connection pools makes
pretty much everything work.

~~~
sanxchit
Running functions in a VPC cause them to have cold starts of ~5 seconds.
Connection pools need to be centralized to be of any use, since lambdas scale
automatically.

~~~
therein
I found myself in the middle of migrating a startup's entire "something"
ingestion pipeline to be entirely done on Lambdas. For our purposes of one
data block per every 10-20 minutes, and then processing and ingesting that
data, Lambdas work perfectly, and about 10x cheaper than using ECS or EC2.

------
hurricaneSlider
I really wish that one of the big cloud providers was building out actors as a
service. That would address a lot of the shortcomings of FaaS, whilst still
having many of the important benefits.

------
iamtomcat
One way to get around vendor lock-in if you're worried about it, is to use a
shim that translates the proprietary code to a basic http interface. So you
just write your code as it it were a basic interface. There are tools like
apex up, [https://github.com/apex/up](https://github.com/apex/up) which do
this already, though at the moment only support aws, but could eventually be
setup to push to any provider.

~~~
styfle
Another alternative is ZEIT Now 2.0 which is supposed to be cloud-agnostic
serverless. It puts a few more layers of abstractions between the developer
and the cloud providers.

[https://zeit.co/blog/now-2](https://zeit.co/blog/now-2)

~~~
omnimus
People will argue that there is vendor locking with Now 2.0 - it has its own
config file and way of doing this.

But i am running express and the config is tiny, just few lines. If you use
some cloud db provider for db that you can host yourself (like postgres or
mongo in my case). You can move to your infrastructure without any pain.

Mind you using Express is not the "ideal" way Zeit seems to push. It is
exactly like with PHP - you are supposed to use simple files and leave routing
to webserver. I think they forget that there is no PHP framework that uses
this. All of them use the "Front controller" pattern and webserver basically
routes everything to it. There must be reason for this.

------
dragosbulugean
Came to conclusions really close to these when I investigated FaaS/Lambda a
couple moths ago. Here's the blog post (faster read):
[https://archbee.io/blog/why-serverless-is-not-there-
yet/](https://archbee.io/blog/why-serverless-is-not-there-yet/)

~~~
popasmurf
We have found the same when working on our own projects. Within the last few
months a friend and I have been working on our own FaaS:
[https://3clouds.io/](https://3clouds.io/) We believe it solves about 90% of
those issues - it's currently under heavy development and not ready to be used
in production yet, but we think we are on to something here. Check it out, let
us know what you think.

~~~
dragosbulugean
Interesting that you have the Docker option. I wish big cloud providers would
be able to allow us to provide a Docker image to run as serverless. And not be
as expensive as AWS Fargate..

------
suyash
If you want to avoid vendor lock in, may I recommend open source FN Project -
you can run anywhere as it's container native serverless platform.
[https://fnproject.io](https://fnproject.io) (Full Disclosure : My company
supports development of this project).

------
WhitneyLand
If you can write a paper like this, however right or wrong, that’s the
standard for Berkeley Computer Science often cited as one of the best programs
out there?

It’s nothing bad per se it just seems closer to nice blog post than research.

~~~
jahewson
It’s basically an opinion piece - CIDR is an unusual conference and encourages
this:

[http://cidrdb.org/cidr2019/](http://cidrdb.org/cidr2019/)

~~~
WhitneyLand
Maybe the perception has less to do with the paper or Berkeley that than a
possible bias against Software Engineering research.

I’ve always perceived it, maybe unfairly, as one of the least rigorous topics
in Computer Science, and more removed from more foundational insights that can
have eventually have more important, broader impact or increase fundamental
understanding that enables advances in other areas.

If any of the conjecture is true, it wouldn’t be a criticism of any researcher
in this area or their capabilities.

Maybe it’s just a matter of maturity. How rigorous can I expect theory to be
when th top software companies in the word still have trouble estiming
delivery and complexity of software implementations?

We may just not know enough yet.

------
Myrmornis
One thing that stops me seriously thinking about serverless is : what would my
application's test suite look like if the application made heavy use of AWS
lambda?

~~~
scarface74
It should look just like it does now:

Production:

Lambda handler -> business logic

Test

Test function -> business logic.

Testing a lambda function is no different than testing an controller in an MVC
framework.

------
8bitsrule
"Cloud" = back to dumb terminals & mainframes. Giant step back.

Edit: and pulling content from two dozen separate servers ... madness^2

~~~
DATACOMMANDER
Yeah, simpler to just serve all content from the file server sitting in your
garage. After all, you tested your site from the laptop on your kitchen table,
and everything loaded just fine.

------
tyteen4a03
Why does serverless remind me of PHP?

~~~
TeMPOraL
Maybe because a making a "lambda" is quite like putting some code in a .php
file and uploading it to a LAMP server, except it's pay-as-you-go and it
autoscales.

------
zygotic12
One size never fits all. The end.

~~~
DATACOMMANDER
Not exactly. The authors are part of the (large) camp that envisions
serverless eventually becoming ubiquitous. In that sense, they hope that one
size _will_ fit all, some day.

~~~
bartread
> In that sense, they hope that one size will fit all, some day.

Nothing new under the sun there. And, that being the case, they're likely to
be disappointed.

------
InGodsName
I built an Adtech platform on Lambda recently:

It's processing 9 billion events per week.

1\. We used Firehose which pushed the data to s3

2\. Go binary on Lambda transformed the data into Parquet format

3\. Used Athena to query this data

4\. Using Lambda to adjust the machine learing data based on the ariving data
in batches.

5\. Using Lambda to query athene/bigquery for data dashboard queries. Again
using Go binary for max performance.

All this made our platform 10x cheaper.

~~~
Jupe
Yep, there are workloads that benefit from the FaaS model, but not all.

In my case, the cost / hassle of high-availability, scaling, no need for
state, time-based triggers, and more, made Lambda an easy decision to make:
and it's working quite well. A cron-triggered job every minute is still in the
"free" tier, so even better!

------
zozbot123
Interesting article. It has often seemed to me that efforts such as Urbit
(urbit.org) deserve our attention, precisely because they might _actually_
deliver on the 'serverless' premise to a far greater extent than current
solutions.

~~~
akhilcacharya
Really? Isn’t urbit based on a computation model multiple orders of magnitude
less efficient than KVM?

------
i_phish_cats
Oh look a bunch of academics telling developers how to do their job, again.

------
aub3bhat
Translation for those not proficient in Academese: Serverless computing a
novel paradigm enabled by a large cloud provider, does not matches our past
research, thus we argue why it's not the right thing.

This is classic "if theory does not matches practice lets change the practice"
approach, which is far too common in academic systems research.

I trust AWS with knowing what its customers truly want (in terms of
performance and cost) and what it can provide,Since AWS has real financial
stakes in its success.

A decade ago the same researchers would have mourned emergence of cloud
computing as a wrong thing and instead asked for P2P computing since that's
what they had spent the decade before doing research on.

~~~
hliyan
I'm afraid your "translation" does a disservice to all the potential readers
of the paper, to those who want to decide whether to use serverless computing
at present and to the authors.

Quoting from the conclusion of the paper:

"Taken together, these challenges seem both interesting and surmountable. The
FaaS platforms from cloud providers are not fully open source, but the systems
issues delineated above can be explored in new systems by third parties using
cloud features like container orchestration. The program analysis and
scheduling issues are likely to open up significant opportunities for more
formal research, especially for data-centric programs. Finally, language
design issues remain a fascinating challenge, bridging program analysis power
to programmer productivity and design tastes. In sum, we are optimistic that
research can open the cloud’s full potential to programmers. Whether we call
the new results “serverless computing” or something else, the future is
fluid."

