by nu2ycombinator on 6/17/16, 7:57 AM with 143 comments
by stickfigure on 6/17/16, 2:50 PM
* 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.
by loup-vaillant on 6/17/16, 11:39 AM
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.
by mikegerwitz on 6/17/16, 1:07 PM
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...
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...
by infodroid on 6/17/16, 9:48 AM
by gmazza on 6/17/16, 10:38 AM
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.)?
by Spearchucker on 6/17/16, 9:22 AM
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.
by kabes on 6/17/16, 9:33 AM
by stephenr on 6/17/16, 9:19 AM
by Mister_Snuggles on 6/17/16, 2:33 PM
Am I missing something?
by jtwaleson on 6/17/16, 10:37 AM
by Animats on 6/17/16, 9:17 PM
A real serverless architecture would be federated, like BitTorrent or Bitcoin.
by TorKlingberg on 6/17/16, 10:39 AM
by winteriscoming on 6/17/16, 2:15 PM
by i_have_to_speak on 6/17/16, 12:43 PM
by jlward4th on 6/17/16, 12:42 PM
> 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.
by amelius on 6/17/16, 10:44 AM
by Touche on 6/17/16, 11:40 AM
by agentgt on 6/17/16, 1:22 PM
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.
by joefkelley on 6/17/16, 4:55 PM
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"?
by krislig on 6/17/16, 7:37 PM
...
"(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.
by ecthiender on 6/17/16, 7:47 PM
by zippy786 on 6/17/16, 2:55 PM
Is there something wrong that the client browser is connecting directly to the database, so JS -> MySQL direct connection won't expose credentials ?
by eazel7 on 6/19/16, 2:29 PM
by MichaelMoser123 on 6/18/16, 4:56 AM
by api on 6/17/16, 5:41 PM
by findjashua on 6/17/16, 4:35 PM
by k__ on 6/17/16, 6:45 PM
Like, a bit more than FaaS, but less than PaaS?
by dreamdu5t on 6/18/16, 12:26 AM
by guylepage3 on 6/18/16, 5:21 PM
by Aaronik on 6/17/16, 11:09 PM
y/w :D :D
by qaq on 6/17/16, 1:10 PM
by known on 6/17/16, 1:10 PM
