
Serverless computing: economic and architectural impact - adzicg
https://blog.acolyer.org/2017/10/19/serverless-computing-economic-and-architectural-impact/
======
keithwhor
Great piece. I think the future of FaaS architecture still isn't widely
understood (see: slim vs fat function discussion below) mostly because people
are going to great lengths to shoehorn old architectural styles into FaaS
platforms.

To be honest, I think AWS Lambda (and Azure Functions / etc.) nailed the
compute and economic model, but only got halfway there WRT abstraction layer
and ideal development for serverless functions themselves. There's an
opportunity here to introduce millions of new software engineers to a
programming model where they no longer have to think about _how_ their web
services run and can treat remote function calls like first-class citizens of
their development environment.

In fact, this is what we've built and we're continuing to iterate upon at
StdLib [1]. One of the most common pieces of feedback we receive from our
customers is; "this is everything serverless should be." We have an open
source Gateway specification called FaaSlang [2] that makes local development
a breeze and perfectly in sync with production functions, as well as providing
automatic error (type, parameter) checking at the request level, before
function execution. We've only been able to get here by "throwing the baby out
with the bathwater" and reimagining backend web development with serverless
functions from the ground up.

Disclaimer: I'm the founder of the company and pretty gosh darn excited about
the future of this space. Check us out if you get the chance, you won't be
disappointed. :)

[1] [https://stdlib.com/](https://stdlib.com/)

[2]
[https://github.com/faaslang/faaslang](https://github.com/faaslang/faaslang)

------
FooHentai
Nice article. One gripe:

>For example, a 200ms service task that needs to run every five minutes would
need a dedicated service instance (or two!) in a traditional model

This feels like such a straw man. Under what traditional model would you spawn
off an entire server instance for such a minor function? You'd slap it in as a
service on an existing host. Hosts which for a long time now have been
virtualized on consolidated hardware, not bare metal.

Serverless can bring big benefits for certain workloads, but hyping it up by
misrepresenting the alternatives seems a dishonest attempt to justify
investment in the big architectural changes you have to make to get there.

~~~
jotto
> Under what traditional model would you spawn off an entire server instance
> for such a minor function

I think that's the point - would you rather run your own VPS and manage the
logs/errors from a cron job? Or simply write code that conforms to their
contract and not worry about logs, errors, and whether it can scale or will
fail to restart itself.

~~~
dx034
Or have another vps/server with spare capacity where this makes sense to run
as well? In most cases, such a function will be closely related to other
functions and can be grouped with them.

------
vikiomega9
> "… serverless platforms today are useful for important (but not five-nines
> mission critical) tasks, where high-throughput is key, rather than very low
> latency, and where individual requests can be completed in a relatively
> short time window. The economics of hosting such tasks in a serverless
> environment make it a compelling way to reduce hosting costs significantly,
> and to speed up time to market for delivery of new features."

The crux so to speak. I wonder if this type of planning makes sense though?
Can't I argue that good design, which imo has been around for ages and
collected well in canonical books, aid in improving time to market for new
features?

~~~
adzicg
(I'm one of the coauthors of the paper referenced in the post)

For me, charging for actual usage instead of reserved capacity actually aids
in implementing those good design guidelines that were collected in books,
such as low coupling and high cohesion of code, and this is what we wrote
about in the paper as well. charging for reserved capacity creates financial
incentives to bundle tasks and features into applications, creating runtime
coupling (eg sharing the same /tmp dir, reusing security roles etc), even
though they are designed to be isolated. charging for actual usage removes
that incentive, so stuff that was designed to be isolated stays isolated when
deployed.

~~~
brianwawok
If you give me a monolith with well isolated packages vs a serverless app
across 400 lambdas and ask me to fix a bug, i can bet you which one i can find
it faster.

Separation of concerns is easy to do without lambda or microservices. If you
want separation of concerns write good code. Don't move your environment to a
locked in circus.

~~~
wahnfrieden
I've seen surprisingly little on running "fat" services in a serverless (like
AWS Lambda) environment. We're doing this at work pretty successfully so far:
Django projects with many endpoints within a single Lambda function. There are
limitations to work with (50MB compressed code) but they're quite manageable
for some time, and so far a nicer problem to deal with than all the things we
give up by abandoning serverless. So try adjusting your example to something
like a dozen lambdas for an engineering organization of 50 devs, with each
lambda service boundary roughly matching the team and product structure.

Serverless enables the extreme (many tiny services with minimal upfront cost)
but doesn't require it.

~~~
zengid
That might be a catchy phrase. "Fat functions", or a single function that
holds a lot of endpoints in a single lambda (or another platforms' version of
cloud functions). Have you had any issues with requests getting timed out, or
managing the 'health' of the fat function?

~~~
wahnfrieden
No unusual timeout issues - our "fat function" has only marginal overhead,
just the WSGI layer and method dispatching code to route the request to the
appropriate view/controller. This should be single digit millisecond overhead.

For health, there's certainly more noise now: we can look at overall
invocation error rates (a metric lambda gives us), but they're across several
endpoints within the lambda function. This is still an open question for us,
but solvable.

------
sytse
The serverless graphic had more arrows than the server based one. I'm not sure
that is an argument for serverless being simpler.

The serverless functions take up to 1s to boot. It is not fair to compare that
to a VM that is on all the time. We should compare it to a container that is
booted on demand. Right now only Heroku does that. At GitLab we're considering
adding idling by sponging requests [https://gitlab.com/gitlab-org/gitlab-
ee/issues/3712](https://gitlab.com/gitlab-org/gitlab-ee/issues/3712)

~~~
wahnfrieden
The article covers this: "[...] tasks, where high-throughput is key, rather
than very low latency [...]"

------
wahnfrieden
Note that this point:

>You can’t run a fully simulated Lambda environment on your local machine.

... is now partially solved via SAM Local:
[http://docs.aws.amazon.com/lambda/latest/dg/test-sam-
local.h...](http://docs.aws.amazon.com/lambda/latest/dg/test-sam-local.html)

