4 ms·

I think this is a bit too harsh. Sure, it has a few rough edges, and not everyone's idea of prime time is the same, but Lambda is perfectly suited for lots of u

by adzicg 10y ago

I think this is a bit too harsh. Sure, it has a few rough edges, and not everyone's idea of prime time is the same, but Lambda is perfectly suited for lots of use cases that do not depend on very low latency -- for example, file conversions, async tasks where users can wait a few seconds such as payment processing, automating incoming e-mail workflows etc. We've been running APIs on it for six months with no issues, and are now in the process of moving the entire backend from heroku to Lambda. So far, no major issues. Regarding Lambda being a building block, I actually like that. Werner Vogels points out [1] that one of the key lessons from 10 years of AWS is that the market wants primitives, and that the higher-level toolkits emerge from that. A ton of third-party helpful stuff is already out, such as apex, serverless and so on. We built a toolkit[2] that lets people use Lambda and API Gateway from JavaScript very similar to lightweight web frameworks (eg api.get('/hello', function (request) {...}) Documentation is there, just not in the most sensible places, and the whole pipeline is optimised for Java processing (eg Velocity VTL for API Gateway transformations allows people to do everything they need, as long they know the Java collections API executed below). [1] http://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html http://www.allthingsdistributed.com/2016/03/10-lessons-from-... [2] https://github.com/claudiajs/claudia/ https://github.com/claudiajs/claudia/

himlion 10y ago
I will definitely check out claudiajs. Nice work!
messel 10y ago
The heroku-> lambda path is what I was considering - so would love to hear more about any pain points etc. edited nvm read claudia.js. Reviewing that vs apex.run now. Thanks for open sourcing that deployment tool.
- adzicg 10y ago
  one potential pain point is warmup time. if your app isn't doing anything, the first request may take a few seconds. it seems that once it's running, this is quick, as the VM is reused. another thing is that although Api GW can behave like a web server for most things, some things are more restricted than with a fully programmable server. for example, you need to declare all HTTP response codes upfront, so that the pipeline can be configured. There can be only one success code (so eg returning 204 when there is no content and 200 with content from the same endpoint isn't trivial). the third thing, that several commenters mentioned on this page, is that if you want to use API Gateway, processing binary data requires S3 or something else for storage. We currently let people convert files by using ApiGW + Lambda to get a signed URL for S3, then post to S3, another Lambda converts it into PDF and saves back to S3, and the client polls S3 to pick up the result. It's fantastically scalable with that design, much better than posting a file to heroku and then getting a synchronous response, but it takes a bit of rearranging the code to work.

by adzicg 10y ago

himlion 10y ago

I will definitely check out claudiajs. Nice work!

messel 10y ago

The heroku-> lambda path is what I was considering - so would love to hear more about any pain points etc. edited nvm read claudia.js. Reviewing that vs apex.run now. Thanks for open sourcing that deployment tool.

adzicg 10y ago
one potential pain point is warmup time. if your app isn't doing anything, the first request may take a few seconds. it seems that once it's running, this is quick, as the VM is reused. another thing is that although Api GW can behave like a web server for most things, some things are more restricted than with a fully programmable server. for example, you need to declare all HTTP response codes upfront, so that the pipeline can be configured. There can be only one success code (so eg returning 204 when there is no content and 200 with content from the same endpoint isn't trivial). the third thing, that several commenters mentioned on this page, is that if you want to use API Gateway, processing binary data requires S3 or something else for storage. We currently let people convert files by using ApiGW + Lambda to get a signed URL for S3, then post to S3, another Lambda converts it into PDF and saves back to S3, and the client polls S3 to pick up the result. It's fantastically scalable with that design, much better than posting a file to heroku and then getting a synchronous response, but it takes a bit of rearranging the code to work.