Hacker News Reader

Comment by shaunpersad | Hacker News Reader

I don't get why Lambda gets all the love while Google Cloud Functions doesn't.

I've tried both, and GCF is vastly superior in many ways.

1) Developer experience is pretty terrible in Lambda, whereas GCF is compatible with Express.js to the point where you can simply pass in an Express app instance to it (which makes vendor lock-in a moot point as well). Develop your app more or less like you normally would, and just export it to GCF. Job done.

2) Deploying is a simple cli command away, even with native binaries.

3) No API Gateway necessary for HTTP functions.

4) It's now compatible with Cloud SQL so you don't have to give up your traditional database.

5) No crazy IAM permissions hoops to jump through to get anything to work.

Disclaimer: I'm not affiliated with Google.

View on HN

I think you get people who are "all-in" on AWS and there are probably fewer people "all-in" on Google.

I agree that developer experience in Lambda is crap, I am a Ruby person though and my language of choice is not on their supported list. You can do it, but the runtime I found[1] looks like a toy and hasn't been updated since 2015.

Google Cloud Functions on the other hand has this[2] (yay! ruby support) but I can't get excited about it, because we are "all-in" on AWS and it's politically impossible to suggest more diversity in this environment. I am however very excited about KNative, as I've been following the Riff project for a minute and it was looking really good (and the same people that built Riff, eg Pivotal, are in the drivers seat of building Knative now, as I understand it.)

Scale to zero! Bring your own runtime... lots of nice features. But number one is, I can run it on my existing Kubernetes environment, and use it to make my deployments leaner and my base cluster scale can be smaller. Hand-in-hand with that, I can carry it with me to another cloud provider if need be.

It works anywhere Kubernetes works, which is everywhere, and I think it will be a while before our non-ephemeral (non-serverless) workloads are going to start going away. And I'm not even stuck with Knative or Riff if I don't like it! There's also kubeless, which includes some degree of Ruby support too.

(NB: I haven't actually tried "rumbda" and it looks like I'm exaggerating about how long it's been since an update, I don't want to talk shit, but when I found "traveling ruby" in there and issues such as "ruby 2.3/2.4 not supported" I basically stepped away, as I have no existing entanglements with Lambda and no desire to get into any new ones. It might be fine, maybe just needs some love. I'd rather work on an open platform...)

[1]: https://github.com/kleaver/rumbda

[2]: https://cloud.google.com/ruby/

> I don't get why Lambda gets all the love while Google Cloud Functions doesn't.

Lambda existed first and was already all in on AWS. I haven't even tried GFC because of those facts. However I probably will now.

>Native binaries

Is this common practice? I've looked for guides on this without much success, but is it basically, just static link your binary and then write a thin js wrapper to invoke it and hope it is the right architecture? Anyone know how multithreading would work? Is it more cost effective to multithread or just spawn separate lambdas?

The serverless.com framework helps addressing #2,#3,#5. There are other frameworks that help addressing #1. Not sure what kind of compatibility or incompatibility do you have in mind for #4 - you could access RDS from Lambda if you really want.

I think "all the love" is related to the fact that you can enjoy the variety of AWS services (which does not exist to the same extent on GCP, at least yet), and integrate them together relatively easily. Also, from developer perspective, AWS documentation and SDKs are by far superior to those of GCP (at least from my experience).

GCP does have many advantages around specific features/services - but at large, AWS is (still) much more capable and mature.

Disclaimer: I am the author of the above article :-)

I feel the same about Azure Functions but I think its all dependant upon which provider you're in bed with at the time. If some one has plenty on AWS and is happy with those resources on AWS they will likely try or use Lambda

I'll respond to you and GP. Lambda is more challenging to use than Azure Functions and GCF. I should know, I use Lambda every day. To be honest the overall developer experience with almost any tool on AWS is more painful compared to Google Cloud or Azure.

I think the reason AWS gets all the love is, GCF only came out of beta very recently. Azure doesn't generally get as much press as AWS or Google Cloud.

As a secondary issue, "why use something with a poorer developer experience"? My answer: AWS's tools are quite complicated but it's also clear to me that Amazon takes AWS very seriously. My interactions with Google Cloud's products, support, and account management have left me with concerns about their long term commitment. This is a personal gut feel. I trust Amazon and Bezos' commitment to AWS. Focus and commitment are things we're all aware Google has had issues with in the past. As far as Microsoft is concerned, I see the great strides they're making and I would consider Azure for future projects. I'm growing to trust Nadella's Microsoft. It's clear they're betting the farm on multi-platform and cloud. Time will tell. Again this is just a personal viewpoint.

Lastly, once you climb the hill of learning IAM, CloudFormation, etc... you can be quite productive.

>I don't get why Lambda gets all the love while Google Cloud Functions doesn't.

The cynic in me says that a in lot of cases this has something to do with people ensuring their own job security. A lot of AWS technologies I've looked into seem to be way, way more complicated to get started with than they should be. There is a also this curious incongruity of people sinking tons of time into "figuring out" how to make something prod-ready in AWS, while saying the technologies they are using are "simple" and "easy to use".

GCF has no Python.

Chalice for AWS makes local testing and deployment a breeze.

It has Python support now: https://cloud.google.com/functions/docs/quickstart#functions...

Really interested that you mention native binaries. Is this possible and convenient? Do you need an ugly javascript shim or can gcf now accept and run a (static?) binary directly too? What kind of protocol do you need to support in your binary to receive and respond to the requests?

Reply on news.ycombinator.com