Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

111–120 of 149 posts

Re: Serverless Architectures

#111

Post by osipov »

hassy wrote: post #105
osipov wrote: post #81

Earlier quoted context omitted.

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/

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.)

Here's how Google defines Cloud Functions: "Lightweight Event-based Microservices".

Google Cloud Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment.

Where is the reference to scripting?

Re: Serverless Architectures

#113

Post by SpaceCadetJones »

gmazza wrote: post #14

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 scalabilit…

I'm confused, how does "serverless" play into this? I opened this expecting something about p2p architecture

Re: Serverless Architectures

#114

Post by Joeri »

ewindisch wrote: post #85
loup-vaillant wrote: post #27

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.

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…

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.

Re: Serverless Architectures

#115

Post by nathankunicki »

osipov wrote: post #111
hassy wrote: post #105

Earlier quoted context omitted.

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.)

Here's how Google defines Cloud Functions: "Lightweight Event-based Microservices". Google Cloud Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment. Where is the reference to scripting?

He is correct though, it's even in the sentence you quoted:

"...single-purpose functions that respond to cloud events..."

They are meant to react to events within your infrastructure, rather than being public facing application endpoints.

Re: Serverless Architectures

#116

Post by orasis »

hassy wrote: post #105
osipov wrote: post #81

Earlier quoted context omitted.

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/

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.)

I'm building a full fledged app. http://blog.improve.ai/ Once there is an Express type framework on top of Lambda and API Gateway, it will be a natural development model.

Re: Serverless Architectures

#117

Post by ewindisch »

Joeri wrote: post #114
ewindisch wrote: post #85

Earlier quoted context omitted.

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…

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.

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.

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.

Re: Serverless Architectures

#118

Post by jkarneges »

k__ wrote: post #112

How does this work with WebSockets? Like, a bit more than FaaS, but less than PaaS?

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

Re: Serverless Architectures

#119

Post by lostcolony »

Spearchucker wrote: post #62
SideburnsOfDoom wrote: post #61

Earlier quoted context omitted.

Why would a lambda fn be considered untrusted client code? If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.

API Gateway in AWS can't directly talk to the DB. It has to either hit a mock (where a canned response is sent back), a lambda function, or serve as an HTTP proxy. You may of course be referring to the more abstract concept of an API Gateway that then talks to a backend DB directly without passing through intervening code, and yes, that would be stupid. But you hardly need serverless infrastructure to achieve that level of wrongness; even with a server in between, you can easily achieve the equivalent of that by taking a SQL string from the client verbatim and executing it against your DB.

Re: Serverless Architectures

#120

Post by 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.

Post reply on HN