
Serverless Architectures - runesoerensen
http://martinfowler.com/articles/serverless.html
======
mpdehaan2
One of the bigger problems with serverless architecture (beyond catastrophic
lack of good debugging and development tools) is the idea of managing multiple
users, working on multiple code branches, and all needing environments that
somewhat closely mirror production. This leaves servless as a decent way to
hook an event callback to some AWS event (new file uploaded to S3, etc) but
IMHO not anything that approximates any kind of business logic - or anything
that will need to be iterated on by more than one developer. I feel it is a
massive reach to market this to anyone at this point, and if this catches on,
would really make me hate programming compared to what local development in
VMs feels like - where I have much greater tools. It's inefficient both for
the developer and at runtime.

~~~
wcummings
First we need a common standard for the serverless pieces of code to talk to
the app server and gateway... maybe we could call it a common gateway
interface. Then maybe someone will write an apache module for it.

~~~
rapind
I laughed at the CGI reference, but TBH pub/sub + microservices feels really
awesome and clean so far. Combined with DB as a service it's even better IMO.

~~~
sp527
I was thinking DBaaS as well, which is the part that's usually under-
emphasized. NoSQL for specific tasks and (sharded if needed) relational with
stored procedures for anything complex. When you think of Postgres as its own
(heavily optimized) server, it changes the game. For most apps, at that point
you just need a passthrough layer exposing endpoints, which is usually a dead
simple nodejs app behind a balancer. The rest of the heavy logic is then
offloaded to the client. This is why full-stack makes sense now more than
ever. It's getting so easy there's almost no excuse anymore.

~~~
wcummings
>This is why full-stack makes sense now more than ever. It's getting so easy
there's almost no excuse anymore.

There's a plenty of good reasons to avoid SPAs.

~~~
sp527
I'd like to hear one. Server side rendering if/where needed, don't overload on
NPM modules, drop jQuery entirely, react lib served by a CDN. SPAs fail in the
hands of amatuers. They excel as a way of instituting rigor in dynamic site
development when wielded by people who know what they're doing.

------
themihai
The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to
lock you not only on specific platform APIs but also on a single programming
language(i.e. javascript) like it wasn't worse enough to have a single
language on the client.

~~~
davidw
Once you've written a bunch of code in a language, you're pretty much locked
in - without a massive effort - in any event.

~~~
safeignorance
In almost all cases, there's a significant difference in the sort of risk that
comes from B/FaaS dependencies and the sort of risk that comes from PL lock-
in. The former leads to technology lock-in and _vendor lock-in_ , while the
latter almost never[1] leads to vendor lock-in.

Technology lock-in without vendor lock-in isn't that huge of a liability. A
popular PL under an appropriate license isn't going to disappear tomorrow, and
its creator doesn't have the power to hold your business at gunpoint.
Conversely, B/FaaS providers upon which you _truly_ depend definitely can
extract (or by disappearing simply destroy) much more value than you
originally anticipate.

[1] If you use Wolfram Language or Matlab then your choice of PL causes vendor
lock-in, but most PLs aren't like this.

~~~
davidw
I agree - "vendor lock-in" seems like a valid point, although I don't know the
details of many of these services. "Locked into a programming language" is
something that will probably happen kind of naturally anyway.

------
zippy786
I truly hope that people stop misleading the mass with buzz words. We already
have too many of them being used for clickbait. I don't get why a simple
client-server architecture would not suffice the "serverless". Software
engineering and architecture design used to be cool in the past with useful
design patterns. Now it's full of tricks/buzz words that promise the users of
silver bullets that help them to manage code and servers. In reality, no such
silver bullet exist and such tricks/architecture fail every day. I've noticed
that martinfowler.com is one such place that seems to provide such empty
promise of a silver bullet!

~~~
collyw
I am reading about this trying to think what it could be useful for. (I am
sure there are some, I don't see any use for it with my work).

"Serverless" seems to be the pricing model. It still runs on a server.

------
skewart
I'm cautiously optimistic that the vendor lock-in will fade away over time.
Hopefully open source frameworks can provide a jQuery-like abstraction layer
over all of the vendor-specific implementation details. Of course, there are
lots of challenges when you start getting into deeper architectures - queues
triggering layers of lambdas interacting with various caches and data stores.
But I we'll see best practices emerge that help people keep things simple and
flexible.

For testing it should be possible to run everything in a mock vendor system on
your local machine - not that such a system exists today, but theoretically it
could.

Overall, my sense is that Serverless architectures will never be useful for
everyone. They'll always be better for smaller, simpler systems that don't see
tons of traffic. The Serverless community should focus on these use cases. The
thing is, there are tons and tons of apps that are over served by all the
flexibility EC2 provides. And there is another set of unborn apps that haven't
been created only because the barrier to setting up and managing the backend
was a _little_ too high. I'm really excited to see serverless bring these apps
to life.

~~~
themihai
I actually think the opposite. Serverless architectures are the future for
most of the app servers that need a language agnostic API. Maybe I didn't get
it right but to me BaaS is just a PaaS with a common API interface(i.e.
authentication, input/output serialization, cache etc).

~~~
beat
There's a pragmatic definition buried in the article... if you can't spin up
your app in 20ms and run it for half a second effectively, it's PaaS, not
serverless.

------
tomc1985
We used to have serverless architecture... it was called standalone desktop
apps! No servers, no backend, no nothing, just you and the code. It was great!

~~~
smt88
It wasn't great. Updating apps was a huge pain, which meant that bugfixes were
fewer and farther between. You couldn't sync preferences/settings between
computers. Remember getting a new computer or wiping one? You knew you had
hours of work ahead of you, just reconfiguring it. Did you write a shell
script to do that for you? Too bad, it did something weird along the way, and
now you have to spend hours figuring out what's wrong.

And don't even get me started on installing dependencies...

~~~
tomc1985
It honestly wasn't so much of a bother. Updates were really the only pain
point but then programs received updates periodically at best. (Talking dial-
up era here) The cost of distribution motivated developers to release much
higher-quality code, relatively-speaking, as not doing so cost you more (in
terms of disks+shipping, additional bandwidth, etc) and well as earned a much
greater amount of ire from your users.

If you were smart you had a system for dealing with migrating between
computers. Maybe it was a script, maybe you knew which folders to copy, maybe
you were extra careful with where you saved everything. Maybe you didn't care.

Some of the modern shit is nice (I fondly</s> remember setting up a personal
Active Directory+Exchange server to get a private LDAP sync, compared to
Google now) but as a whole the current model encourages carelessness and
mindless profiteering. There's too much of the equation nowadays in control of
people who want to charge you for it, whereas before the user was had control.
I miss the days when it was considered rude to require a network connection
unnecessarily.

Plus, nowadays a product you love can turn to mush and there's nothing you can
do about it save stop paying for it (and lose its services in the process),
which will never amount to anything unless people do it en mass. Features
regularly disappear because some bullshit business reason or another, or some
user metric said only 2% of people used it. Well, fuck those 2% guys right?!?
Before, if I didn't like your patch I could just revert to the old install
discs. Nowadays I have to pray you don't alter your deal further.

edit: and don't get me wrong, as a developer the evergreen model is great. But
as a power user, I hate it.

edit2: not to say older software didn't have its crap. Lots of fussy stuff to
deal with. But compare the initial release of Windows 3.1 to Windows 10...

------
tschellenbach
There's a big difference between Paas, where you hand over control of your
backend. Compared to Faas, where you just outsource a small part of your
infrastructure.

FaaS solutions like algolia, getsentry, getstream.io. mapbox, layer, keen.io,
twilio, stripe etc only run a small part of your application. They scale well,
are more reliable and often more cost-effective than an in-house solution. If
you're ever not happy with them it's easy to switch to an alternative. If
Algolia no longer works for you, simply switch to Elastic. If you're not happy
with Mapbox, use google maps. No longer like, getstream.io, use Stream-
Framework. It's relatively easy to change since you're not handing over your
entire backend.

Also see my post on HighScalability about this:
[http://highscalability.com/blog/2014/12/22/scalability-
as-a-...](http://highscalability.com/blog/2014/12/22/scalability-as-a-
service.html)

~~~
nostrademons
Twilio, Stripe, etc. aren't what the article is referring to as FaaS (which,
incidentally, I've never heard of outside this article but seems pretty
descriptive). They're talking about things like Amazon Lambda, Google Cloud
Functions, and Parse Cloud Code, where you _write code_ that runs on a third-
party service. The entry & exit points of the code are under the control of
hosting provider, which distinguishes it from PaaS, where they normally take a
well-known platform that'd work fine on your laptop and then perform hosting
and administration.

Think of it as the API vs SPI distinction that we used to have back in
Windows-land. API-only services like Twilio or Stripe are usually just called
SaaS.

------
spotman
Would have liked to see some real cost analysis, other than it should save you
money, because that is only true if scale is small to medium.

That's the thing, I guess the demographic that lambada is going for it will
save money, but along with the mentioned vendor lock in, when you really need
to have something on and processing requests non stop the costs savings really
evaporate.

It's weird to me that the serverless thing catches on when it seems to be best
suited for projects in their infancy without need for 24/7 request processing
, or things out of the critical path like image resizing or things of this
nature. But entire apps? Feels very much like going back in time to shared
hosting.

I could see it saving money until about 1m requests a day and then a sharp
drop off where you are hemorrhaging cash after that...

With modern auto scaling systems that aws and gce provide I bet most shops
don't stand to save any more money than with a normal modern day refactor.

At the end of the day this leaves you more rope to hang yourself with. It
makes it easier to run slow or poorly thought out code. 1000 processes might
be cool but is never as cheap as 2 working correctly that accomplish the same
thing, as an extreme but actual example of a situation I helped unwind with
GAE, which was serverless before the buzzword.

------
eloycoto
I'm early adopter of serverless applications, few weeks ago was released a
tool that make manage our Amazon lambda applications even easy.

[https://github.com/jorgebastida/gordon](https://github.com/jorgebastida/gordon)

A few examples can be found here, and it's a good point to start if you're
using Aws Lambda

[https://github.com/jorgebastida/gordon/tree/master/examples](https://github.com/jorgebastida/gordon/tree/master/examples)

------
rwallace
It's sometimes okay to use inexact or uninformative terminology, but it
becomes a problem when words are used to mean their exact opposite. So if you
are going to talk about serverful programs - those which depend on servers and
can't operate without them – that's fine, but please use some term other than
'serverless'.

------
rhinoceraptor
Aren't 'serverless' PAASs just a reinvention of PHP hosting?

~~~
theptip
Adrian Cockcroft: "If your PaaS can efficiently start instances in 20ms that
run for half a second, then call it serverless."

[https://twitter.com/adrianco/status/736553530689998848](https://twitter.com/adrianco/status/736553530689998848)

~~~
kowdermeister
No, call them extremely fast lifcycle servers.

~~~
theptip
That's a lot more syllables than "serverless".

------
be_erik
We're currently exploring lambda for certain applications as well. My coworker
wrote up a nice little post about it:

[https://product.reverb.com/2016/07/16/deploying-lambdas-
with...](https://product.reverb.com/2016/07/16/deploying-lambdas-
with-s3-jenkins-and-gulp/)

------
kuharich
Previous discussion:
[https://news.ycombinator.com/item?id=11921208](https://news.ycombinator.com/item?id=11921208)

------
0xmohit
Previous (recent) discussion at
[https://news.ycombinator.com/item?id=11921208](https://news.ycombinator.com/item?id=11921208)

~~~
runesoerensen
I submitted this link:
[http://martinfowler.com/articles/serverless.html#drawbacks](http://martinfowler.com/articles/serverless.html#drawbacks)
with the title "Serverless Drawbacks", as that was the recently added section.
Guess someone changed it, but it's not a dupe :)

In any case, it seems that "Benefits" has also been added since the last HN
discussion (revision history:
[http://martinfowler.com/articles/serverless.html#Significant...](http://martinfowler.com/articles/serverless.html#SignificantRevisions)).

------
happyslobro
For my first serverless project, I built a service that manages an advertising
account, by analysing ads and optimising the spend spread for a configured
goal. I was surprised to find that one of the most difficult aspects, was in
throttling outgoing API requests. Basically, I needed to avoid abusing a 3rd
party service by hammering it with parallel or rapid fire requests.

I discovered all kinds of weird solutions:

\- Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm
to fire when the queue length was >= 1 for at least one second. Have a variety
of lambdas respond to the alert by checking if the have any work to do, and
then racing to pop the queue and do one operation. I think I needed SNS in
there too, for some reason. Fanout?

\- Build a town clock on an EC2 and have it post "admit one" tokens to SNS.
Nice and simple, but I was evaluating serverless, and adding a server felt
like defeat. Might as well just run the whole thing on that EC2.

\- Have on lambda pop request descriptions from a queue, and sleep for one
second after sending each one. The request responses would have been pushed
onto another queue. All of the other lambdas could just handle the events they
cared about as quickly as data became available. Sleeping in a lambda just
felt wrong, but for one second, it probably would have been fine.

In the end, I was still experimenting and exploring when my estimate loomed
near, so I just wrapped up all of the application code and piped it all
together with delays in loops that made API requests. Deployed it to Heroku in
a hurry with minimal fuss.

What I learned:

\- There are bad use cases for serverless, and I had started on one (SLS
doesn't wait on no one)

\- Serverless does encourage a clean architecture, from a code perspective: I
was able to quickly transform it into a completely different type of
application.

\- AWS's services have lots of little surprises in their feature set: SQS
doesn't fire any kind of event. SNS can't schedule events in the future (maybe
I should have expected that one). Cloud watch events can only trigger a single
lambda.

\- There is a need for a town clock / scheduler as a service in AWS'. How many
people have built that themselves?

~~~
inopinatus
> "\- Push a "please wait" message onto an SQS queue, and set a Cloud watch
> alarm to fire when the queue length was >= 1 for at least one second. Have a
> variety of lambdas respond to the alert by checking if the have any work to
> do, and then racing to pop the queue and do one operation. I think I needed
> SNS in there too, for some reason. Fanout?"

Did you want AWS Kinesis? The integration with Lambda polls the queue every
few seconds and sends batches of records to a Lambda function when the queue
has work to do. [http://docs.aws.amazon.com/lambda/latest/dg/with-
kinesis.htm...](http://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html)

When you evaluate the AWS serverless platform, I recommend looking at
everything that is an event source, sink, or processor: Lambda, SNS, SQS, SWF,
SES, Cognito, IAM, Kinesis, IoT, API Gateway, S3, DynamoDB.

It's a pretty rich palette to work with.

~~~
happyslobro
I did look at Kinesis too, but for my use case, it didn't really help much
over SQS. There is still no way to put a Kinesis event "in the future" so that
I won't see it for a second, and I would have had to set the batch size to 1,
if I was using Kinesis as a means to throttle an activity.

In the spirit of treating this like Lego, I suppose that maybe I could have
uses SES to email itself an HTTP request description, and counted on the email
lag to keep requests spread out over time. But at this point, things are
getting so weird that I think it's time to just admit that "work on something
at a specific pace, then go to sleep for a few hours" isn't the sort of task
that the serverless architecture is well suited for. Serverless is for tasks
that you want done on demand, as quickly as possible, imo.

------
idoco
Sort of related, I've implemented a GitHub pages based serverless app demo,
that uses GitHub API to execute git operations from the browser. Though
slightly weird, I really enjoyed this experiment, and think there might be
something to this concept.

[https://github.com/idoco/GitMap](https://github.com/idoco/GitMap)

------
glic3rinu
I expected the article to be about the goodness of some peer-to-peer
architecture that doesn't require central servers, not a twisted definition of
cloud computing.

------
Sanddancer
One of the big issues here that is only very very slightly glossed over is the
security you give up. The only sort of security filtering you get is AWS' WAF,
which is considerably weaker than a firewall like mod_security with a default
ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a
tiny ruleset with only a few conditions, and outbound filtering doesn't exist
at all.

This lack of firewalling continues up and down the stack. As such, it's a lot
harder to create rules regarding any API calls you make to third party
services, harder to audit how your app interacts with any datastores, and
generally an administrative nightmare. It may be useful for some apps, but
just feels like a nightmare to maintain for any decently sized setup.

~~~
jwatte
The sales pitch is that the fabric vendor does the administration, and people
like you are out of a job.

Because the framework infrastructure is supposed to solve all of that behind
the curtains, so developers cannot shoot themselves in the foot. (Other than
through excessive resource consumption)

------
OldSchoolJohnny
"Serverless" WTF? I thought it would be a cool article on peer to peer mobile
apps that don't rely on a backend server, something I think will be very
popular in future for a variety of reasons.

Please, let's not accept this redefinition of a fundamental and well known
term.

------
klodolph
I recently evaluated these, and I'm dying to use something like this. I would
really love to be able to do this with sandboxed apps written in arbitrary
languages like Go, Haskell, Rust, or even C++. Ideally, I wouldn't be managing
docker containers or VMs to get certain jobs done.

Unfortunately, it's limited to JavaScript, Python, and Java for now. Google
Cloud Functions is similarly limited to JavaScript.

I know that these languages were chosen because they can be easily sandboxed,
but it would be nice to support something more generic without having to
create docker containers for everything.

~~~
nsm
Have you checked out [https://github.com/iron-
io/lambda](https://github.com/iron-io/lambda). Their is a tool for docker
container creation, and also AWS Lambda compatibility.

------
bitwize
So apparently "serverless" means you don't have to requisition a cloud
instance to run the service.

I remember this movie the first time around, when it was called "virtual
hosting". What a revolution -- transitioning from needing a Unix box running
Apache to run your PHP e-commerce site to having your host take care of that
for you -- and everybody else.

Just because you're doing something old "in the cloud" now doesn't make it a
new thing. Just like you can't append "...with a computer" to an existing
method and get something patentable.

~~~
justinhj
Does it matter whether something is new or not? The fact is there are services
such as AWS lambda that people are using and talking about, so we need
terminology for that.

~~~
bitwize
Not really, as long as it's useful. But call it what it is -- hosted services.
Don't make up a new, nonsensical name.

~~~
justinhj
Hosted services doesn't really differentiate what they are. DynamoDB is a
hosted service. So is EC2 and ECS.

~~~
bitwize
Then call it function hosting or business-logic hosting. "Serverless" means
"there is no server" which is demonstrably false. Or should I assume that
words don't mean things?

------
aslom
The main point of serverless is cost - it is not just "Reduced operational
cost" but orders of magnitude difference if one were to build cloud solutions
that can scale the the same level and pay for cloud infrastructure (even if
not used at minimum something must be running ...), monitoring, and people
effort involved on ongoing basis (real cost)

Compare to working with level of abstraction of "entity" (function, could be
bigger) and have it running when needed and scale as needed.

------
gshx
One big challenge is the expense that is otherwise avoided via usage of
connection pooling. Without the hack to keep the backing containers alive,
tearing down and restarting them is expensive and wipes out all hot path
optimizations made by JIT compilers besides having to reestablish connections
and pay the handshake prices. Apart from the simplest of use-cases at this
time, imho this is not an efficient model if sustained performance and low
latency are of interest.

~~~
audleman
I've been wondering this same thing. We use gunicorn to handle our web
requests and it pre-loads our code so it's ready at the drop of a hat to serve
a request. It takes a few seconds to load up our site, so wouldn't Lambda have
to pay that cost with every web request?

I've been going under the assumption that it's just not the right use case for
Lambda, though I'm hoping I'm wrong.

------
buckbova
I wanted a good tutorial/walkthrough on this topic.

Has anyone gone through [https://pragprog.com/book/brapps/serverless-single-
page-apps](https://pragprog.com/book/brapps/serverless-single-page-apps)?

The example material looks good. Overall it could be a bit short.

------
SNvD7vEJ
What a ridiculous and strange definition this is.

Its an architecture that relies on multiple, supposedly distributed services,
all of which are hosted on servers...

Why not just call it "Multiserver" instead.

If they mean "containerless servers" or "microservices", then why don't they
say so?

If they mean "distributed servers" why not call it that.

If they mean that the client relies on multiple services (each hosted on
different servers) why not just call it a thick/fat/stateful client?

Even a database is a remote service (if not embedded), that is run on some
sort of server.

Calling anything serverless is just ridiculous as long as it depends on
services on the network.

This smells really bad of just another attempt at marketing a pointless
definition just to get more business.

~~~
Illniyar
No, the idea is simple - the servers are invisible to the user, he doesn't
know what or how many are in use.

Since the servers are completely abstracted away, they could have just as well
not be - hence serverless.

An analogy escapes me but I sure there are some.

~~~
SNvD7vEJ
So it is about how the user _perceives_ the application?! If so, why is it
called "an architecture"?

Or do you mean that the user don't have to care on how to _configure_ the
application? Then "Zero-configuration" is a better name.

Or do you mean that the application _hides_ that it use services on the net?
Then it is even worse.

~~~
freyr
> _So it is about how the user perceives the application_

The user here is the developer. Here's an explanation from the article:

> _" some amount of server-side logic is still written by the application
> developer but unlike traditional architectures is run in stateless compute
> containers that are event-triggered, ephemeral (may only last for one
> invocation), and fully managed by a 3rd party ... One way to think of this
> is __Functions as a Service. "_

FaaS is probably a better name.

------
hackdroid
There is google's appscript(based on javascript), which could also be termed
as serverless. So ingenious for individual purposes, I have used it as a
database(with google spreadsheet), scraping and saving 1000's of html/xml,
deploying and demoing bootstrap websites. It also has a time limit of 5mins 30
seconds which could be overcome by controlling triggers or by using patt0's
CBL [http://patt0.blogspot.in/2014/08/continuous-batch-library-
up...](http://patt0.blogspot.in/2014/08/continuous-batch-library-update-
for.html).

------
eldavido
Aren't we kind of already there (serverless)?

A lot of web frameworks enforce the shared-not-that-much (not quire "shared
nothing", but close) style of programming where every HTTP request is
essentially just an "event" that hooks into a controller-handler? And if you
want anything to stick around from one request to the next, you keep it in
memcache/db/BaaS/third-party service, not your own process?

I don't think this is as radical a shift as many here might think, especially
given the move to containers is already well underway.

~~~
collyw
Kind of like "schemaless".

------
zpallin
I think a major problem with Serverless architecture, as much as it is
awesome, is that to manage it you would need to be already familiar with the
underlying systems that provide it. Hence, it would imperative that you
already have worked with the architecture you are planning on replacing.

Unless there is some elegant factor to Serverless that I am missing. I just
can't shake the feeling that at the end of the day this is just a sales
tactic.

Nevertheless, I opt to use serverless BaaS solutions whenever I can afford to.

------
EGreg
Why is it called serverless if it uses Amazon Lambda instances?

~~~
jwatte
Because you, the developer, do not buy or pay for "servers," only ephemeral
"code invocations."

~~~
EGreg
Sweet! So by that logic, all static sites are serverless because I pay for
"file hosting" right?

------
cyberpanther
Serverless sounds like CGI evolved past needing a server anymore.

Oh yeah and remember spawning CGI processes for every request never scaled
well. :-)

~~~
zwily
Lambda does keep processes running and reused between requests if they're
coming quickly. You do, however, only get to handle one request at a time
which is not the norm with node backends.

------
srcreigh
One issue people are talking about is vendor lock-in. I would like to note
that this drawback is only valid for non-prototype software. For prototypes,
hackathons, or "one time use" websites, these BaaS tools (such as Firebase)
are essential.

Here is a case study: Last year I was working on an SMS app, QKSMS [1]. We
offered a premium version for $2. We did a promotion on reddit where we gave
away 10k free premium versions. So, take a second and ask yourself: how
quickly do you think you could implement a promo code system + a website for
distributing codes for one time use?

We did it in about 5 hours. It costed about $100. The website was (and still
is) statically hosted on Github. [2] The website source code is ~22 lines of
JavaScript. It pulled 12 promo codes from Firebase; and when a promo code was
removed, it would (in realtime!) collapse it from the list and display a new
promo code at the bottom.

The mobile app code was also very simple. First, check if the promo code is
available (one API call); if so, enable premium and remove the code (another
API call).

The reason why it costed about $100 is because we had too many concurrent
users: the Firebase free plan allows only 50 concurrent users, and at our peak
we were seeing ~500. Since the promo was only for a day, we bought an
expensive plan that got pro-rated for just that day.

It was an extremely successful promotion. [3] The final result was very
interactive. It was amazing to watch the codes disappear in real-time. It was
like a game: you had to be fast to enter the code, because the codes were
being used so quickly.

All in all, I believe we made more money in people buying it anyways (despite
the promotion) than it costed to serve it. And keep in mind we built the
_entire system_ in about 5 hours. And I'm not even a web developer. An actual
web developer could have implemented this in an hour or two.

For reference here is the entire JavaScript powering the promo code website:

    
    
        var all_codes = new Firebase("https://qksms-promo.firebaseio.com/public_codes");
        all_codes.on('value', function(data){
          $('#remaining').text(data.numChildren());
          if (data.numChildren() === 0) {
            $('#status').text('No more codes!');
          }
        })
    
        all_codes.orderByValue().limitToFirst(12).on('child_added', function(data){
          $('#status').remove();
    
          var str = '<div class="code" id="';
          str = str.concat(data.key());
          str = str.concat('">');
          str = str.concat(data.key());
          str = str.concat('</div>');
          $('#wrapper').append(str);
          $('#'.concat(data.key())).hide().fadeIn(300);
        });
    
        all_codes.orderByValue().limitToFirst(12).on('child_removed', function(data){
          $('#'.concat(data.key())).slideUp(300, function(){
            $(this).remove();
          });
        });
    

[1] [https://github.com/moezbhatti/qksms](https://github.com/moezbhatti/qksms)

[2] [http://qklabs.com/qksms-promo/](http://qklabs.com/qksms-promo/)

[3]
[https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_...](https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_ago_today_i_showed_you_qksms_the/)

~~~
moezb
We got around 15,000 downloads that day (compared to the usual 300-500), and
10% converted to paid users

------
rainhacker
If successful this could lead reduction in developers needed in companies that
use say AWS lambda.

~~~
spriggan3
> If successful this could lead reduction in developers needed in companies
> that use say AWS lambda.

How so ? to me it makes development even more complicated, cheaper relative to
hosting fees maybe, but simpler ? I don't think so. What if I want to use
language XYZ not supported by lambda ?

~~~
nawitus
> cheaper relative to hosting fees maybe

Currently serverless is more expensive in the average case from what I gather,
mainly since it's new and there's little competition.

~~~
taurath
If avg case is that you stay within an average load for long periods of time,
then it'll likely be more expensive (given a certain floor of actual load -
for in-dev apps its dirt cheap - you won't have many servers running doing
nothing.

------
up_and_up
How is this different then something like Heroku and their add-on ecosystem?

~~~
snikch
Heroku gives you servers, but manages them for you - so you have long running
processes, for web or worker etc. Lambda allows you to have the process run
for literally the lifecycle of the job (request, streaming job etc.). In fact,
your job can't run for more than a few seconds or it is terminated. Heroku
charges you for the hours your dynos run - but what if they're idle most of
the time? You still pay for them - not with lambda.

------
jokoon
It doesn't seem the author knows how network programming works. This is all
high level abstraction and diagrams, but no simple comparison of what are the
pro/cons, what are the constraints, etc.

------
urza
Also see "Unhosted web apps": [https://unhosted.org/](https://unhosted.org/)

------
hopfog
I'm using the following setup for one of my sites:

Client -> post -> API Gateway -> AWS Lambda -> upload JSON to S3

Client -> get -> S3

Works pretty good!

~~~
themihai
Is it cost effective? I mean roughly.

~~~
Cub3
Very very cheap, as long as you're writing your lambdas as performant as
possible we've costed our app at ~2c / user / month with heavy api / database
/ lambda usage

~~~
themihai
It seems you are estimating the costs per user. I think an estimation per
request and perhaps compared with raw EC2 servers would make more sense.
Anyway, it's encouraging to hear that's cost effective. My experience with
managed/ server-less platforms is quite bad in terms of costs.

------
naveen99
What if the web had the equivalent of 900 numbers. Something like
http900://foo.bar.com

------
sinzone
If you're looking for an open-source API Gateway (less lock-in) with Lambda
Integration then Kong
([https://github.com/Mashape/kong](https://github.com/Mashape/kong)) could be
a useful complementary tool for your serverless architecture.

~~~
snikch
I think you're missing the point of the 'serverless' part, as Kong still
requires you to have a dedicated server to run it. One of the early stage
benefits of the serverless architecture and AWS's api gateway is that you
don't have to pay for resources that you don't consume - so if you've only got
a small amount of customers, you don't have to pay for dedicated instances to
be running.

~~~
sinzone
imho serverless architecture doesn't mean that your app is without servers
100%. Backend still serverless, but everything on top (like an API gateway,
load balancer, service discovery, etc) can have dedicated resources.

~~~
snikch
Fair enough - there are definitely use cases where I could see that making
sense. I love the value lambda provides for early stage, when every penny
counts.

------
ianamartin
The main problem I see here is the problem we run into with every hot new
abstraction of a thing that some people find troublesome as developers.

Someone already mentioned virtual hosting. I'd like to bring up ORMs. There's
this idea that you can forget about the datastore--abstract it away, manage it
in code, whatever. You don't have to learn about databases, table structures,
or SQL if you don't want to. Just think about your models and don't worry
about the rest.

I'm not against ORMS and find them both amazing and useful in certain ways.
What I am against are systems developed entirely by developers who refuse to
think about these things. Especially when I have to come into the situation
after they have left and do something genuinely unforeseeable, like provide
reporting and analytics from the back end, integrate with a third-party
system, or--god forbid--add new functionality.

What you're left with is a dysfunctional, _slow_ , mess that's incredibly
difficult to work with, a data layer that makes no sense unless you're working
with that particular ORM, and no ability to tell exactly where in a quarter-
million lines of code the exact logic you want to fix or modify actually is.

Yes, I'm quite certain that no one would recommend that anyone use serverless
architecture that way. It's the wrong tool for the job. Just like ORMs are the
wrong tool when performance is critical and you need to manage complexity for
30 services from the same data layer.

But someone is going to do it. In reality, probably lots of people will. Some
CTOs will buy into the hype and hire teams of consultants to do it or hire
their actual dev team full of serverless experts.

I'd echo what someone else said to the effect of abstractions are great so
long as you understand what you're abstracting and know when it's a good idea
to do so.

Viewed as a tool for accomplishing a small thing pretty quickly, it sounds
cheap, fun, and exciting.

Viewed as a new way of taking shortcuts around quality infrastructure that's
needed to support large, complex systems, I feel like it's probably a bad
idea.

Given my attitudes above, it's probably not a surprise that I find the
description a bit sketchy. I think calling it Serverless is a misnomer for all
of the many good reasons people have pointed out in this thread. But I also
question calling it architecture.

What I expect we will see in fairly short order is a collection of libraries
or frameworks that resemble PhP not only in function (a service that pops in
and out of existence on demand) but also a language-like form that evolves
rather than being intentionally built--and evolves towards ease-of-beginner
use rather than being guided by a coherent architecture.

And, in the grand scheme of things, that's fine with me. I just hope I never
inherit a system like that.

~~~
collyw
This seems to be true for a lot of "new" tech.

I honestly think people should learn to build standard apps the standard way -
(SQL) database, application layer, html / view layer -then learn to scale the
parts as needed. Its well understood. There are good frameworks and tools
available and plenty of historical examples of how to do things.

Everyone seems to want to jump on the shiny new way of doing things as soon as
they come out. I often ask peoples reason for choosing their architecture -
"thats how we do things these days" or "relational databases don't scale" seem
to be the standard answers.

------
darkboltyoutube
Dangers of Pokemon Go
[https://www.youtube.com/watch?v=B2KXVfnw4rg](https://www.youtube.com/watch?v=B2KXVfnw4rg)

