Live data from Hacker News

Ask HN: What are the alternatives to Amazon Lambda?

news.ycombinator.com

11–20 of 78 posts

Re: Ask HN: What are the alternatives to Amazon Lambda?

#11
Google App Engine includes pretty much the same thing, except it's more mature since it's been around for ages. (JS isn't among its supported languages though — Go, Java, Python, PHP — but IIRC they may have recently added some kind of language-agnostic runtime.)

Re: Ask HN: What are the alternatives to Amazon Lambda?

#12
post #4

Isn't most of the draw of Amazon Lambda that you can hook everything else into a simple api hosting service? I doubt there are any direct competitors, at least at that scale. Here is a discussion: https://www.quora.com/Are-there-any-alternatives-to-Amazon-L...

+1 one of the draws for Lambda is that it has easy integration with other AWS tools (Kinesis, DynamoDB, SNS, even CloudFormation) and is really low-cost since you only pay for execution time.

Re: Ask HN: What are the alternatives to Amazon Lambda?

#13
post #9

Newbie question: what does "Amazon Lambda" have to do with functional programming? (Because the name suggests there is a connection).

"With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. "

I.e. wrap your code as if it were a lambda function, and pass it to us. It will work when we call it just as well as when you do in the original environment.

Sounds like a better name would be "Amazon Macro", though. This is because the "lambda" (user's application) likely refers to features of the hosting environment and is influenced by them; it is not referentially transparent to place code on a server, even if the grunt work of setting up the surroundings is done by a "macro".

"Lambda" is a hot buzzword though, as some notable Blub languages have been scrambling to integrate them, whereas "macro" has a stained reputation.

Re: Ask HN: What are the alternatives to Amazon Lambda?

#14
post #9

Newbie question: what does "Amazon Lambda" have to do with functional programming? (Because the name suggests there is a connection).

Actually not much. Its called lambdo because you can deploy functions to the cloud, but those functions can be written in a non functional style

Re: Ask HN: What are the alternatives to Amazon Lambda?

#15
post #14
post #9

Newbie question: what does "Amazon Lambda" have to do with functional programming? (Because the name suggests there is a connection).

Actually not much. Its called lambdo because you can deploy functions to the cloud, but those functions can be written in a non functional style

Tjo-fa-de-rittan lambo?

Re: Ask HN: What are the alternatives to Amazon Lambda?

#16

Iron Workers: http://www.iron.io/worker/ Most new breed Docker hosts like http://tutum.co can give you a quick DIY version. But in general they (Amazon) are (currently) the best of breed and I have only positive things to say having used the JS and Java versions.

Have you noticed any downsides to using Lambda over running a persistent Node server? Is there overhead in execution time, for example?

Re: Ask HN: What are the alternatives to Amazon Lambda?

#17
What about Azure Service Fabric [1]? It seems a bit different that it doesn't even require you to have S3* /database storage. You have access to in-memory distributed and resilient data structures [2] right in your code.

They seem to provide Chaos and Failover tests (à la Netflix Chaos monkey but out of the box.)

[1] https://azure.microsoft.com/en-us/campaigns/service-fabric/

[2] https://azure.microsoft.com/en-us/documentation/articles/ser...

*or Azure S3's equivalent

Re: Ask HN: What are the alternatives to Amazon Lambda?

#18
One thing that strikes me as having really promising possibilities for doing something Lambda-esque is systemd socket activation [1]. You can essentially have no running services, and systemd will hold open a socket (port/unix/etc) and then it will spin up a given service if a request is made on that socket.

As long as you build your "service" to handle a single request and shut down (maybe have an external db-access service to avoid add'l connection overhead), I'd imagine you get something very similar to what Lambda offers - high density, on-demand computing.

[1] http://0pointer.de/blog/projects/socket-activated-containers... and http://0pointer.de/blog/projects/socket-activation.html

Re: Ask HN: What are the alternatives to Amazon Lambda?

#19
I started trying to use Lambda and found a few immediate issues.

1) It does not work with anything inside VPC. EG: RDS Databases cannot be used. This severely limits why you'd use this on AWS for larger apps.

2) Trying to get it working for a real app is a bit of a gun show. Debugging was a pain, you cant really write any unit tests easily that I found. Local development was confusing.

3) Lambda forces you to use old technology. Node .10x, Python 2x.

4) You're using code that will only ever work on AWS. If you don't like vendor lock-in then look elsewhere.

If you don't need VPC access take a look at Heroku and background workers. They scale independently from the front-end main app. No servers to manage, just git push heroku master. You can write them in pretty much any language you want. Heroku supports the latest stacks and languages.

Re: Ask HN: What are the alternatives to Amazon Lambda?

#20
post #16

Iron Workers: http://www.iron.io/worker/ Most new breed Docker hosts like http://tutum.co can give you a quick DIY version. But in general they (Amazon) are (currently) the best of breed and I have only positive things to say having used the JS and Java versions.

Have you noticed any downsides to using Lambda over running a persistent Node server? Is there overhead in execution time, for example?

There's a warmup time when a function is first executed in a container that can be up to 2 seconds depending on what libraries you include (you pay for this time [1]). After the first execution, your function environment will stay "warm" for 10-15 minutes and it will only take 10-150ms to execute your function on a new event.

The other big downside is every time your function goes "cold" you pay the cost of all the extra (anything not in standard lib, ImageMagick, or the AWS Nodejs SDK) libraries you need.

The upside is that you only pay for the time your code actually runs. I've replaced a cronjob server and saved ~90% on the bill to run my jobs. Mostly they were scheduled backups and other misc integrity checks on AWS and 3rd-party infra, so nothing that intense.

More limits/downsides: http://serverlesscode.com/post/aws-lambda-limitations/

1: the cost for 2 seconds of execution time on a 512-MB execution environment is 0.00001668 USD, so it's not likely to break the bank. If you have a high-traffic function it's likely to stay "warm" pretty much all the time. And if your function is low-traffic, it's likely you fit inside the free tier.

Post reply on HN