AWS Lambda Makes Serverless Applications a Reality | Hacker News Reader

AWS Lambda Makes Serverless Applications a Reality

techcrunch.com

55 pointspanabee52 comments

It's funny we tested lambda + Amazon gateway api this week at work.

It's awesome!.. Until you have to deal with the cold start issue. Our first call takes about 1.5 seconds; and then all other calls take about 50-80ms.

Your container stays in cache about 5-10 minutes unless it is called back, there are no guarantees.

This micro service is not called often and for us 1.5 seconds is never acceptable.

You could use a scheduled cron task in Lambda to make requests to keep your API hot.

Yeah we thought about that, but is it reliable? We were really not sure we could always get rid of the cold start issue.

AWS Lambda function schedules are driven off the same fault-tolerant, highly available service that powers SWF. (So...yes, they're reliable :)

Is keeping it hot with a cron job reliable though?

Give SNS/SQS a look for polling solutions for API Gateway. We got around it by having a health check call in our set up.

You could potentially use that task as an availability test too.

Our issue was price. Boss did the math for our use case, around a million hits/sec 24/7, and it worked out to billions of dollars. We're building a solution (on aws) for a little less than that.

It's good the boss can do that sort of math. That's why you need him and why he is called the boss.

Why do I have a feeling that you are the "boss" in this picture? :)

There's the performance issue on startup, then there's the cost issue with the typical case. With the "round up to the nearest 100ms" pricing, your example ends up overpaying 20-50% for the _typical_ case. If you have any serious use of your app, you are better off with DIY on EC2 or using Heroku.

Take a look at the JAWS stack which makes heavy use of Lambdas:

https://github.com/jaws-framework/JAWS

Previous JAWS HN post ~4 months ago:

https://news.ycombinator.com/item?id=10005415

Has anyone using Lambda gotten Amazon to substantially increase the limits on concurrent jobs? We asked for 10k and they gave us 1k. The article posted in this thread and other sites use words like "limitless" and "massive," but 1k concurrent requests is ... tiny. We're hesitant to keep building around this architecture because of the limit.

How does one version control the scripts and easily deploy them? How does one test them on one's own computer when developing them? Must the scripts be uploaded into AWS after every change if testing is to be done?

It's very easy to test scripts locally - here's my quick and dirty SNS->lambda tester script - https://gist.github.com/alexbilbie/cd1a1309bd7267d860b0

Deployment is easy too; I've got a two line bash script that zips the code then uploads it using the AWS CLI.

Versioning documentation can be found here - http://docs.aws.amazon.com/lambda/latest/dg/versioning-alias...

I use this to run/test locally, and then deploy. I also upload binaries, so do use the AWS upload but it's quick via a script within the deploy helpers.

https://github.com/motdotla/node-lambda

I spent my last week figuring this out. I tried several of the open source packages mentioned above including jaws and node-lambda. In the end, I use node-lambda for local testing. If you configure your package.json file correctly you can get VS Code to run and debug, which was a life-changer for me. However, "node-lambda deploy" was breaking something between the API Gateway and Lambda, so eventually I switched to using a package.json deploy script that uses the AWS command line to zip & upload the working directory.

I just stumbled onto this Lambda example project today, looks pretty interesting: https://github.com/awslabs/simplebeerservice

If Lambda is able to expand the /tmp disk space from 500MB to a few GB I think that will further make the adopter better on my end. I have a requirement in which Lambda is a perfect solution except the disk space is not enough. Of course I can further divide the work into smaller chunks. If you have use distributed task library like Celery, just think of that no longer tie to your application, and you can run on event based (S3, SNS, email notification via SNS). It's quite awesome. You can probably build a public API using Lambda and API Gateway.

However, once you start using Lambda, like distributed system, testing becomes a challenge if you are used to testing everything you own in one or two monolithic codebase. I wish someone could come up with a mock version of AWS :-)

Can you mount an EFS on the lambda instance (I don't know, but that comes to mind as a possible solution), possibly via a java NFS daemon or something in userspace?

I have never done that before but I imagine no, you are not supposed to have access to the operating system and know where the instance is. Similar to SNS and SQS, you don't get an IP of your SQS. I could set up an EC2 instance with some storage, but that goes back to my current design. If you do get that IP :-) contact AWS. That's probably a million dollar vulnerability. I'd suppose underneath they run container/lxc! Also, sadly, EFS is only available in us-west oregon :|

Appreciate the feedback/suggestions! We'll take a look at expanding the disk space, probably as part of the "power level" adjustment that already affects memory, CPU power, etc.

One minor feature request would be to allow Scheduled Events every minute. My current solution is EC2 -> S3 file every minute, but it's a kludge.

There is : http://www.slideshare.net/AmazonWebServices/cmp407-lambda-as... but I kinda dislike the whole complexity). This is a new feature.

Why can't I access EFS? That seems like the best solution to this.

I used to work at Iron.io they have a product called IronWorker which gave 10GB temp disk. They allowed you to use your own docker containers also. they have a priority queueing system however and come at a premium over lamdba pricing due due to being more feature rich.

custom docker image use came with the overhead of burning in your instances though which I don't think is publicly available yet on the service.

We have used a combination of AWS Lambda + Amazon ECS, which is kind of similar what you're describing. We are working now to extend the abstracted library that empowers developers to choose programmatically what service to use: https://www.npmjs.com/package/deep-resource ;)

My contribution to the Lambda application construction party:

https://github.com/exratione/lambda-complex

Lambda Complex is a Node.js framework for applications that run entirely within Lambda, SQS, and other high abstraction layer AWS services. It is well suited to non-realtime content generation and other types of application driven by message queues and which require enforced concurrency limits. Examples include high volume generation of static content from data or other types of workflow initiated in response to messages placed into SQS queues.

We're considering using API Gateway and Lambda for our upcoming API service. Would love to hear feedback from anyone who's tried it. From the linked article, I got one gist [1] which wasn't very favorable for the API Gateway + Lambda setup.

[1] https://gist.githubusercontent.com/mpdehaan/d979252b9c69cfd1...

Depends on your use case and what language you are currently using. We are using nodejs and have built our own collection of libraries: https://github.com/MitocGroup/deep-framework

And here is an example: https://github.com/MitocGroup/deep-microservices-todo-app

Based on our experience, currently AWS Lambda is amazing for data / content / asset management use cases. Cold start is a known issue, which I hope AWS will solve sooner rather than later, because a lot of customers are complaining about it ;)

How is the 0.10.x version of Node treating you? That's what's keeping me off of Lambda at the moment. I guess I could use Babel before deployment, but what about external libs?

I'm thinking of the following workflow:

1. Write/debug with TypeScript -> ES6 on Node 5

2. Compile to a single file (not sure if I can use tsc or Babel for this -- basically just inline all the imports)

3. Transpile the resulting single file to ES5

I'm not sure if it's going to work, though...

I'll be honest, performance is not the best one :) That's why for the time being, we're using a combination of Lambda with ECS. Please don't quote me on that, but I have a feeling that by the time we're building the work-arounds, mine and your problems will be solved by the services ;)

Here is a practical approach, how we do it:

1. We write everything in ES6, following code styling from Airbnb - https://github.com/MitocGroup/javascript

2. Every Lambda is separate npm package, therefore npm is managing all the dependencies; We include node_modules folder into the .zip file and upload it to AWS

3. Using Babel, transpile ES6 to ES5 - https://github.com/MitocGroup/deep-microservices-todo-app/bl...

4. To support 0.10.x, we're requiring Babel Polyfill - https://github.com/MitocGroup/deep-microservices-todo-app/bl...

As anticipated, the performance is not the best one, but functional for some of our use cases where time is not a constrain. That's why the combination with Amazon ECS is perfect complimentary match when AWS Lambda doesn't perform well, as required by the application.

Thanks so much for posting this! I was really curious and found this to be helpful.

Yes, cold start (the delay you experience when your code hasn't been used in a while) is a big issue - it means serious additional latency which makes Lambda difficult to use for end-user facing applications. You can get around this by calling the code periodically .. but that defeats the purpose. There are also restrictions around how long your code can run. BUT, if your use case fits within these constraints, it's pretty cool to just deploy your code and forget about all of the administration hassles associated with running it on a server.

My company is building exclusively[0] on Lambda and API Gateway. It's definitely got its warts and you'll be paying an early adopters tax for sure.

My cofounder wrote a tool to help manage Lambda deployments: https://github.com/garnaat/kappa/tree/python-refactor

[0] Well as much as we can. We're building a Slack bot right now so we still need a container running under ECS to maintain the connection to Slack.

I'm so glad you asked this! I just built a service on API Gateway + Lambda in the past two weeks. Here's my unstructured thoughts -

* I love that I don't have to provision any resources. The fact it will scale to volume automatically is a huge win.

* Lambda was a treat to work with. We used it with Python. Both the web console and API interface worked great for us.

* I was able to get Lambda development working end-to-end with a Makefile and the AWS CLI.

* API Gateway was a bear to work with. The concepts are unintuitive, the interface sucks, and the logging is lackluster. I found it difficult to go through the develop/test/deploy cycle on because of these issues.

* API Gateway is brand new. Brand new AWS services have bugs. We hit bugs.

* API Gateway documentation is awful.

* API Gateway had a bug where it stopped logging. If it doesn't log, it is literally impossible to debug. This hard-stopped development for 5 days while they worked on a fix.

* There's an invisible error case where your API doesn't have permissions to invoke the Lambda command. It's easy to hit and annoying.

* API Gateway doesn't support POST requests in the way you would expect. This leads to over-complicated setups for simple use cases.

* I really don't prefer the way mapping templates work in API Gateway.

Overall, our setup is humming along nicely, but it's just 2 routes. I just reviewed the Gist and I agree with many of the concerns expressed in it.

Have you reported any of your issues with the API Gateway to us? Please feel free to send them to me via the contact address in my HN profile and I will share them with the team ASAP!

I went through official support channels with my blocking issues. They have since been resolved.

This is such a great comment (polite, constructive, unbiased). It made me think that I wish there was a site like Ars Technica, but for PaaS/IaaS.

We have encountered consistently HTTP 500 response when creating multiple methods simultaneously. I think they have fixed it by now, but imagine the color of my face when I'm about to present a demo to a pretty large audience and we discover this bug?

I could have just written this comment -- I spent the past two weeks doing the same thing, but in JS, and hit all of the same problems. In the end, I think API Gateway is more trouble than it's worth. I wish Lambda could have an exposed HTTP endpoint. Mapping all of the arguments in and out is so incredibly tedious when developing and things are changing fast.

There's a lot of configuration. Using APIs keys takes like 25 steps. And I haven't really figured out a non really complicated way of creating a session between a web front-end and the API. And uploading code changes is a real PITA. But after that it just works.

As I've been programming an Alex backend I haven't really run into the cold start issues.

I have to admit this sort of Dashboard Driven Programming is quite alien, but there are benefits.

Serverless = using someone elses servers?

I like this explanation: https://www.quora.com/What-is-Serverless-Computing

Quote - Serverless doesn’t mean servers are no longer involved. It simply means that developers no longer have to think "that much" about them. Computing resources get used as services without having to manage around physical capacities or limits.

I actually think people end up thinking more about it.

Sometimes you have several "devops" people in a small team dealing with orchestrating these "serverless" deployments so as to reduce latency etc.

Been having fun playing with Lambda to power various Amazon Echo skills[1]. Definitely easier than having to deploy with something like Elastic Beanstalk, or even App Engine.

We're also using this at mParticle Inc. to allow anybody to add themselves as an integration[2]. The point being that Lambda is a super-easy way to write _some_ server logic, even if it only serves as a proxy to something more complex.

[1] https://developer.amazon.com/public/solutions/alexa/alexa-sk...

[2] https://github.com/mParticle/mparticle-sdk-java

I just ended up using Heroku for an API instead. I was able to use the latest language version and microframework of my choice and still not worry about servers. Setup was way more intuitive than AWS. Testing locally was a known thing and easy. I found wrapping my head around testing API gateway to lambda to aws services a mess. Also all the IAM rules got confusing. I'll probably have another look after it has matured.

I've never used Heroku before and got a production ready API out the door in no time.

Heroku is more like Elastic Beanstalk than Amazon API Gateway. API Gateway is more of a Backend As A Service as I understand it, like Parse.

API Gateway doesn't really encompass Parse's scope, either. It's more of a router-as-a-service that allows you to forward HTTP requests to other AWS services, Lambdas, or your custom backend (+ do some stuff with IAM and auth, etc)

Related submission about unikernels from a few days ago: https://news.ycombinator.com/item?id=10603915

Sounds like an AD for AWS. I wonder which clueless CIO will gobble this up.

Reply on news.ycombinator.com