Hacker News Reader

Comment by osipov | Hacker News Reader

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/

View on HN

I think OP's chief argument is that "serverless" is monopolized by AWS Lambda and the like, and probably unfairly.

The answer is that Cloud Functions and AppEngine fulfill different use cases. There's clearly room for both.

There doesn't appear to be a monopoly on "serverless" and the term has been used by many vendors including IBM at the last Serverless Conference[1].

There is definitely room for many kinds apps in the PaaS space, including serverless as well as microservices. OP was arguing that existing platforms like GAE have been supporting serverless and can continue to do so. However, the premise of the serverless computing movement is that newer platforms (e.g. OpenWhisk, Google Cloud Functions, AWS Lambda) are better for running serverless applications than traditional PaaSes (e.g. Heroku, Bluemix, OpenShift)

[1] http://serverlessconf.io/#agenda

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.

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.

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.

I did this. AppEngine is a far more cohesive and polished service than cobbling together Lambda, S3, API Gateway, SQS and Dynamo (which you'd need to do to actually have a fully functioning site).

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.

Yes.

I'm a massive fan of AWS Lambda, but using it to serve public API quests is just a nightmare. Just because you _can_ do something, doesn't mean you should.

I'm constantly puzzled by why people use Lambda for this - if you don't want to deal with managing traditional services, there's plenty of other options out there (in AWS and otherwise) that are much more suited to the task of serving a website.

Functions looks interesting, but only supports node.js. GAE has the advantage that it support multiple language targets.

Cloud Functions are just the functions. Gae is that and more.

Reply on news.ycombinator.com