
Serverless Architectures - nu2ycombinator
http://martinfowler.com/articles/serverless.html
======
stickfigure
By this definition, we've been running "serverless" on Google App Engine for
most of a decade.

* We don't monitor how many instances are running and don't really care. Our "functions" are http endpoints. GAE spins up or down instances to meet the load. Our interface with "instances" is just the size of the bill at the end of the month.

* Async task processing is also just an http endpoint function. We even have a little bit of syntactic sugar so it looks like we're just adding functions to a queue.

* We have no ops or devops staff. We just deploy code that implements functions (http endpoints).

* Persistence is also scaled by Google; there's no database server, just an API to read/write data that scales infinitely (or at least, scales with linearly our bill, not limited by the dataset).

It sounds to me like the article is trying to distinguish between "serverless"
and PaaS by describing PaaS done poorly. For the longest time, GAE didn't even
expose the # of instances servicing your app. They've exposed a lot more of
the underlying constructs since, but you can still ignore them unless you're
trying to hyperoptimize your bill.

~~~
osipov
If GAE has had "serverless" for most of a decade, then why did Google decide
to create Google Cloud Functions?
[https://cloud.google.com/functions/docs/](https://cloud.google.com/functions/docs/)

~~~
hassy
Because Lambda/Cloud functions are meant for scripting tasks in your cloud
environment, not for building full-fledged apps.

(Lambdas couldn't even be triggered with HTTP calls when AWS Lambda launched.)

~~~
vikeri
I spoke to a solutions architect on AWS who said that their recommendation for
building a new backend service (eg. a REST API) is to use API gateway and
Lambda. I definitely got the impression that he meant full-fledged apps.

~~~
zippergz
I have done some (small-ish) projects with API Gateway and Lambda. Lambda
itself is pretty nice. The API Gateway is a pain, and has a lot of rough
edges. Especially if you need to do anything other than standard JSON in and
out. I’ve spent way more time than I’d like to admit futzing with mapping
templates and models to try to get stuff to work the right way. And then
dealing with errors from the Lambda function in a sensible way is a headache
all its own.

I generally really like AWS and I use it for a ton of stuff, but I very much
welcome competition and innovation in this space.

------
loup-vaillant
What kind of evil genius devised a term that suggests peer-to-peer, to
describe something that relies more than ever before on central services and
authorities?

It feels like "intellectual property" all over again —which suggests the rules
used for rival goods can be used for ideas, hence ignoring the difference
between moving and copying.

~~~
ewindisch
Because the main premise of "serverless" is function-as-a-unit-of-deployment,
it's actually quite suited for distributed computing and works quite well in
decentralized architectures. Using serverless, it's easier than ever to build
"hybrid" clouds constructed of resources both locally and on public clouds
(Google, Amazon, Azure, BlueMix, and others).

We can even deploy that code to IoT devices and embed it inside of desktop and
mobile apps.

Serverless _frees_ us from lock-in, but it does not have its _own_ state, so
it's easy to become locked into various web services. However, it's also easy
enough to rely on your services (microservices) for state, avoiding lockin to
other IaaS/SaaS products.

~~~
Joeri
Unless and until there is a standard for function-as-a-service so you can move
your functions between services at a moment's notice, you're very much locked
in; and locked in without any guarantees of quality of service.

~~~
ewindisch
I am involved daily in precisely an effort to do just this. The differences
between the big 3-4 providers is relatively marginal (call arguments and
versions of interpreters such as NodeJS). Take it as a plug if you must, but
being able to handle the former is one of the goals of
[https://github.com/iopipe/iopipe](https://github.com/iopipe/iopipe).

The version of language runtimes is where the most lock-in will occur, and
really, that's kinda marginal, too. Language runtimes should be as stable and
standard as, say, the Linux kernel's userland interface. If language runtimes
can't deal with this, then they'll fail.

------
mikegerwitz
There are a number of things I find alarming about this (which is nothing
new):

Firstly, the author is encouraging the conversion of traditional web pages to
single-page web applications, which means that users would now have to
download actual software to use the website rather than using the software
that they already have and trust: their web browser.

Perhaps most alarming is the acknowledgement of this:

> One of the main benefits of Serverless FaaS applications is transparent
> production runtime provisioning, and so open source is not currently as
> relevant in this world as it is for, say, Docker and containers.

This highlights the major issue of SaaSS/SaaS, and FaaS takes it to the
extreme:

[https://www.gnu.org/philosophy/who-does-that-server-
really-s...](https://www.gnu.org/philosophy/who-does-that-server-really-
serve.html)

Not only does the user not have control (as in the case of SaaS), but in the
case of FaaS, the actual author is relinquishing the same control.

These suggestions all "make sense" from an architectural perspective
(depending on who you ask, and depending on the software being written). But I
plead for others to consider whether this is necessary in their particular
instance; it's the default thinking now-a-days: want to write a program? Want
a wide audience? Want it to scale? Put it on the Web, make it a service, store
it and all user data on someone else's computer, and call it "the cloud".

I expressed my opinions and concerns at LibrePlanet 2016:

[https://media.libreplanet.org/u/libreplanet/collection/resto...](https://media.libreplanet.org/u/libreplanet/collection/restore-
online-freedom/)

~~~
mikebroberts
Hi Mike,

Article author here. Don't worry, I'll be laying on some cold, hard, reality
later in the series. I definitely _don 't_ encourage SPAs universally and I'll
be talking extensively about the concerns of handing over responsibility to
vendors.

~~~
mikegerwitz
Thanks for the reply, Mike; I'm looking forward to reading your opinions, and
I'm glad you'll be discussing it.

From a technical perspective, your article was very informative, and I did
learn from it, so thank you for the information.

------
infodroid
It is misleading that the HN title suggests the author is Martin Fowler, but
this is not the case for this guest article. The actual author is Mike
Roberts, the article is hosted on Fowler's site.

~~~
Tomte
Yes, but that's probably because the HN submission bookmarklet puts the site
name behind the dash.

It annoys me every time I'm submitting something. But evidently not enough to
finally edit the bookmarklet.

~~~
jrs235
Ditto about the annoyance. Never thought about editing the bookmarklet... I'm
going to do that now!

~~~
jrs235
Here's is my slight change to the bookmarklet code. It's not fool proof and
and I'll have to see if it actually results in me editing submitted story
headlines less often or not. It basically takes the substring of the document
title from the start until it finds the first hypen (-) or pipe (|) which are
what seems like most sites use when appending the site name.

    
    
      javascript:window.location="http://news.ycombinator.com/submitlink?u="+encodeURIComponent(document.location)+"&t="+encodeURIComponent(document.title.substring(0,document.title.search(/[-|]/)).trim())

------
gmazza
Serverless = new name for PaaS.

VPS (virtual private servers) were available (and largely ignored) for quite a
while before 2006, when AWS came along with the catchy word "cloud". This
single word changed everything. Same technology all of the sudden became cool,
and everybody started using it.

Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally
start seeing all the benefits (true scalability, efficient resource
utilization, timely and painless software upgrades, et c.)?

[1]
[https://en.wikipedia.org/wiki/Platform_as_a_service](https://en.wikipedia.org/wiki/Platform_as_a_service)

~~~
osipov
Since serverless is a kind of a PaaS, it offers many of the same benefits.
However, unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes
focused on supporting long running applications and services, serverless
frameworks offer a new kind of a platform for running short lived processes
and functions, also called microflows.

The distinction between the long running processes and microflows is subtle
but important. When started, long running processes wait for an input, execute
some code when an input is received, and then continue waiting. In contrast,
microflows are started once an input is received, and are terminated by the
platform after the code in the microflow finishes executing. One way to
describe microflows is to say that they are reactive, in the sense that they
react to the incoming data.

~~~
atrudeau
Sounds like inet.d, or CGI behind a webserver.

~~~
gmazza
...or socket-activated systemd service [1, 2]

[1] [http://0pointer.de/blog/projects/socket-activated-
containers...](http://0pointer.de/blog/projects/socket-activated-
containers.html)

[2] [https://developer.atlassian.com/blog/2015/03/docker-
systemd-...](https://developer.atlassian.com/blog/2015/03/docker-systemd-
socket-activation/)

~~~
osipov
That's true, but for a public cloud service, you wouldn't let random people
run arbitrary code based purely on inet.d or systemd socket activation.

~~~
gmazza
Why not? RedHat will let you run arbitrary binaries just fine on OpenShift -
both long-running/worker/"PaaS" and on-demand/per-request/"FaaS".

Obviously this is tightly locked down with cgroups.

~~~
osipov
How would you modify systemd unit files for each user of your public cloud?
How would you manage the sockets once you have more users than sockets on a
server?

~~~
icebraining
You can create systemd units using the D-Bus API instead of files, though I'm
not sure those can be socket-activated.

As for having more users than sockets, is that really likely, considering
there are 64000 available ports?

------
Spearchucker
The API gateway made me smile. In the 90's we had message queues. In the 00's
we had service busses. Today we have API gateways. All they do is route
requests - they're all the same thing.

There's merit in serverless, no doubt. There are many things that worry me.
Not owning the infrastructure means I don't get the telemetry I'd like, making
triage difficult. Direct access to the database is a good idea said nobody
ever. And at what point does my own infrastructure become more cost-effective
than cloud?

Those concerns don't invalidate the applicability or relevance of serverless
though. I think its value as a protyping tool, or to validate a proof of
concept is huge.

~~~
marktangotango
The vast majority of web sites on the internet today don't need much
infrastructure, they're low traffic blogs, web sites for the hair salon down
the street, or a landing page for a non software corporation. Facebook fills
this role for a lot users, and they in turn sacrifice their data and privacy
to a souless corporation. Don't forget the $billions dollars industry of
shared hosting providers out there. A lot of businesses still pay $10 a month
for a shared server, mysql, and php.

Why should this be the case? Why should it cost anything to have an online
presence today? Why shouldn't users own their data? In my personal opinion,
these types of FAAS (function as a service) and mBAAS (mobile Backend as a
service) the article is talking are an enabling technology in this regard.

~~~
jeswin
Even if it costs nothing, Facebook is a far better option for hair salons and
other similar small businesses. Facebook drives engagement and views, while
nobody will bother with a self hosted website. The oft repeated lesson here is
that convenience trumps privacy for the vast majority of users. If you look at
the last decade, in spite of there being robust, self-hosted solutions for
syndication and engagement such as RSS, pingbacks, OPML etc, in the end closed
systems won.

Maybe there is a secret ingredient to making it work again, but we don't know
what that is. Yet.

~~~
marktangotango
I think the secret sauce may be in things like 'call ahead seating' or 'get in
line, online' that some restaurants and hair styling places do now. You don't
typical get that capability on facebook, and it's a differentiator.

~~~
icebraining
Thing is, why would a hair salon (which presumably has no advanced technical
skills) choose to write or purchase software to run on their FaaS service,
instead of simply registering an account on a SaaS service that takes care of
everything for them, and even integrates with FB?

------
kabes
How did this came to be known as serverless? It just seems to be an extreme
case of microservices running on someone else's computer?

~~~
Skinney
I think it might have something to do with the fact that the payment model
isn't connected to a server instance, but how often your code is run. Heroku,
GAE etc. are server-oriented. Your code is running on a dyno or an instance,
and you pay based on the number of instance-hours you use. In AWS Lambda, or
Azure Functions, you pay for the number of requests you process and the time
spent processing those requests, how many instances are spent processing those
requests are irrelevant. It's a serverless payment modell.

------
stephenr
Why not MTTaaS - Misleading Technology Terms as a Service.

~~~
paulddraper
See, I though it was Multi-Troop Transport as a Service
([http://starwars.wikia.com/wiki/Multi-
Troop_Transport/Legends](http://starwars.wikia.com/wiki/Multi-
Troop_Transport/Legends)).

So +1

------
Mister_Snuggles
The serverless architecture appears to have many servers provided by different
people instead of having no servers, as "serverless" leads me to think. Is
this just trading wrangling a server farm for wrangling contracts with 3rd
party service providers?

Am I missing something?

~~~
zippy786
Serverless is just a buzzword similar to NoSQL to gain traction, nothing new!

------
jtwaleson
If your PaaS supports scaling down to zero (Heroku free tier, Cloud Foundry
somewhere in the future) and resuming on incoming traffic, it's basically a
much better version of FaaS. The way you deploy code, the way services are
coupled to the app etc is much better.

~~~
Skinney
Heroku is much slower at resuming on incoming traffic, because it has to boot
up a dyno to serve your code. A cold start on Heroku usually takes 30 seconds
(for me anyways). A cold start on AWS Lambda takes 2-5 seconds, which the user
won't notice on my services because the frontend is served from S3 and
rendering is client side.

And the way services are coupled to the app is about the same. I've used both
Heroku and AWS a bit, there really isn't that big a difference here, except
that Heroku as a lot more third party services that can be connected.

~~~
jtwaleson
Sure, it's designed to be faster to boot up, but Heroku could optimize their
startup time.

~~~
Skinney
Difficult to do. Cold start time is slow on the free plan because they have to
start a "server". They don't need to do this with the paid plan, but then
again, you're paying for uptime of a server. Serverless don't need to do this.

------
Animats
It's just outsourcing. It "depends on 3rd party applications / services (‘in
the cloud’)" It's like Salesforce's "No Software".

A real serverless architecture would be federated, like BitTorrent or Bitcoin.

------
TorKlingberg
Is Google App Engine an example of serverless? The user does not really think
about servers, and the code is mostly written as event handlers. The
abstraction is a bit leaky though, and you can tell that there are instances
being spun up and down.

~~~
spriggan3
Uploading PHP scripts on a remote server provided by an hosting company is
"serverless". I don't have to manage the server /s

That buzzword means absolutely nothing.

------
winteriscoming
As someone previously noted about serverless architecture -
[https://twitter.com/jf/status/739971456302350336](https://twitter.com/jf/status/739971456302350336)

------
i_have_to_speak
Ah, the PetStore example brings back memories! Wonder how many people remember
it?

~~~
mikebroberts
Welcome to Old Developers Club. :)

~~~
asimuvPR
Not old, but seasoned with salt (white hair). :D

------
jlward4th
In regards to Stateless and 12 Factor...

> This has a huge impact on application architecture, albeit not a unique one
> - the ‘Twelve-Factor App’ concept has precisely the same restriction.

While 12 Factor does say that processes should be stateless I've never thought
it really meant it. Connection Pools and in-memory caches are pretty typical
in 12 Factor (or all non-serverless) apps. And for me that is what makes
serverless kinda silly. Some global state is actually pretty useful when you
can avoid the overhead of initializing things or going over the network.

~~~
osipov
Serverless apps should be stateless but should work in conjunction with
stateful apps. Unlike Heroku, Cloud Foundry, OpenShift, and other traditional
PaaSes focused on supporting long running applications and services,
serverless frameworks offer a new kind of a platform for running short lived
processes and functions, also called microflows.

The distinction between the long running processes and microflows is subtle
but important. When started, long running processes wait for an input, execute
some code when an input is received, and then continue waiting. In contrast,
microflows are started once an input is received, and are terminated by the
platform after the code in the microflow finishes executing. One way to
describe microflows is to say that they are reactive, in the sense that they
react to the incoming data.

~~~
icebraining
But how is this different from coding in, say, Django?

In Django you write a "view", which is just a Python function that is started
when an HTTP request is received, and terminates by returning an HTTP response
object. Then there are models, but these are just a translation layer between
the Database and the view function, they don't keep state either.

I don't see how a Django view isn't a "microflow". It seems to me that the
architecture is exactly the same, it's just that you don't get to choose the
web framework.

------
amelius
The article totally skips (serverless) _federated_ architectures, which are
more interesting, in my opinion.

~~~
LionessLover
At the bottom of the article:

> This is an evolving publication, and I shall be extending it over the coming
> days and weeks to cover more topics on serverless architecture including
> some things commonly confused with serverless, and the benefits and
> drawbacks of this approach.

You can send a tweet to the author:
[https://twitter.com/mikebroberts](https://twitter.com/mikebroberts)

------
Touche
With this type of architecture, aren't you creating latency by separating out
the "backend" from the database? In the traditional approach the backend
server and database are in the same datacenter, but it seems that's often not
the case in FaaS approach, what are the ramifications of that?

~~~
SideburnsOfDoom
If you were on AWS, I would expect the Lamdba fn to be running in the same
datacenter as the backing dynamodb table, or at least in the same region.
dynamodb response times are pretty good - typically under 10 milliseconds.

~~~
Touche
Thanks, is this something you have to be aware of when setting this all up or
does Amazon do this for you?

~~~
SideburnsOfDoom
AWS is far from simple, and there is a lot to learn. For a start, you will
need to know what a Region and Availability zone are:
[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-
reg...](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-
availability-zones.html)

Roughly speaking: A region is a geographic location (e.g. eu-west-1 is in
Ireland and eu-central-1 is in Frankfurt, Germany) The "Availability Zones"
are separate datacenter buildings in that region connected by fat pipes.

For fault-tolerance, it is common to make sure that all of app's parts run
across multiple availability zones in the region. This will happen without
much manual config.

Crossing regions is very different - it's not going to happen automatically,
they're pretty much isolated from each other. Only a few extremely-highly-
available apps (e.g. netflix) have engineered to cross regions. See
[https://www.infoq.com/presentations/netflix-failure-
multiple...](https://www.infoq.com/presentations/netflix-failure-multiple-
regions)

------
agentgt
We sort of do this for a JVM with the exception that it is the JVM and you
really can't be rebooting it all the time.

What we do is use a message queue and extreme thread isolation. Are internal
framework is sort of analogous to an actor framework and/or Hystrix but is
stateless through out. Messages are basically functions that need to be run.

That being said because our whole architecture is message driven and uses a
queue with many client implementations we have been experimenting with OCaml
Mirage and even some Rust + lightweight container because of the serious
limitation of booting up the JVM.

------
joefkelley
The one thing I haven't seen discussed in the serverless world is state as
optimization.

For instance, if I have a machine learning application that has to access a
very large trained model, I would like to load that model into memory at
application startup. Loading from disk at every "function call" would be too
slow. So would making RPC calls to some external "model cache" service.

Does AWS Lambda / similar have some sort of overridable "init"?

~~~
jedberg
That would be a case where you wouldn't want to use a purely serverless model.
You'd want a persistent server that loads the data and then exposes it as an
API for your other serverless functions.

That being said, it's important to remember that Lambda doesn't reload your
function for _every_ function call. It loads it on the first call and then
keeps it active for a few minutes as long as there are still requests coming
in, so you'd only have to deal with that initial load once in a while (or
almost never if your function is active enough).

Unless you had a way of extracting your model into a very fast database.

------
krislig
"1\. Often require vendor-specific language, or at least vendor-specific
frameworks / extensions to a language"

...

"(1) is definitely not a concern for the FaaS implementations I’ve seen so
far, so we can scrub that one off the list right away."

That point do not make any sense to me. You have to follow the AWS Lambda
programming model which is specific to AWS Lambda, so either way you are tied
to some libraries and patterns which are vendor-specific.

------
ecthiender
I think the word serverless makes more sense in p2p/decentralized
architectures, than in platforms using pre-built servers.

------
zippy786
[http://martinfowler.com/articles/serverless/sps.svg](http://martinfowler.com/articles/serverless/sps.svg)

Is there something wrong that the client browser is connecting directly to the
database, so JS -> MySQL direct connection won't expose credentials ?

~~~
losteric
It doesn't say "MySQL database".

The client could conceivably connect to something like an ElasticSearch
database (JSON API), setup with no auth/read-only permissions and appropriate
rate-limiting.

~~~
zippy786
You are really talking about a very small use case if you say the only
database that could be used would be no auth/read-only considering most
database requires auth for security and most apps need to write.

~~~
detaro
And then you use a "function" behind the gateway for the parts that need to
write or need to see things that need authentication. Just like in the
diagram...? Nothing says that you can _only_ allow public access to a
database.

------
eazel7
Wrong. All wrong. Serverless is like what is the server standing on before the
server? That is serverless. Peer to peer mesh discovery protocols, for
example. Serverless implies no server. Buzzz buzzzzz buzzzz buzzzz. Sexless
sex.

------
MichaelMoser123
So the web page now has to contact a lot of servers. That means more round
trips and worse security - more endpoints means a bigger surface for attacks.
Also you know what data is on what server - you just have to inspect the
javascript source code. Is this a good idea?

------
api
Trouble is most of these are completely single vendor and closed. If you build
your app for Lambda, theoretically you've built it to run on _one_ computer:
the AWS lambda "main frame."

~~~
jaegerpicker
That's not really true. Lambda apps are just a collection of node.js modules
that are defined at the function level. I can and have easily port a Lambda
app to a node.js express app, infact I did so for a Lambda app that was non-
trivial (400 functions defined) in about half a day.

------
findjashua
s/serverless/zero-ops/g

------
k__
How does this work with WebSockets?

Like, a bit more than FaaS, but less than PaaS?

~~~
jkarneges
Raw WebSocket handling could be delegated to something like Pushpin [1]
(disclaimer: author). This way, the backend doesn't have to maintain any long-
lived connections of its own, but it retains a similar level of control over
each connection that a full backend would have had.

As an experiment, we built a chat app like this (using Stamplay as the FaaS)
and it actually worked.

[1] [https://github.com/fanout/pushpin](https://github.com/fanout/pushpin)

~~~
k__
Interesting. But I need my own server to run pushpin?

~~~
jkarneges
That or you can use Fanout Cloud which provides Pushpin-as-a-service.

------
dreamdu5t
Serverless now means "servers in the cloud" ? So what do we call apps that
don't use servers!? I'm actually writing one right now...

------
guylepage3
I feel blockstack.org offers the best serverless technology.

------
Aaronik
#content { margin: auto; }

y/w :D :D

------
qaq
shared hosting reinvented :) Name is way cooler though

------
known
Torrent ?

