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.
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
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)
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 ;)
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
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.
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.
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!
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.
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.
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.
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.
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.
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.
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 ;)
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.
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?
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.
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 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.
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)
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.
54 comments
[ 2.4 ms ] story [ 90.6 ms ] thread[1] https://gist.githubusercontent.com/mpdehaan/d979252b9c69cfd1...
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 ;)
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...
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.
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 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.
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.
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.
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.
Sometimes you have several "devops" people in a small team dealing with orchestrating these "serverless" deployments so as to reduce latency etc.
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
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 :-)
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.
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.
https://github.com/jaws-framework/JAWS
Previous JAWS HN post ~4 months ago:
https://news.ycombinator.com/item?id=10005415
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...
https://github.com/motdotla/node-lambda
I've never used Heroku before and got a production ready API out the door in no time.