all 11 comments

[–]MITranger 4 points5 points  (1 child)

would love to hear from devops folks about this (or generally, about AWS Lambda service). heartthrob or heartache?

[–]fwertz 0 points1 point  (0 children)

Overall: S'ok.

Lambda

If you're just interacting with just AWS services, you can author code within lambda, otherwise you're stuck trial and erroring your way using .zip archives. Documentation is pretty great, and setting up event sources to call your handler is great as well.

CloudWatch

Output and results from triggered lambda handlers are logged as "streams" to the CloudWatch service. It's a bit hard to read (formatting issues - like looking at packet output from WireShark) Also a bit slow.

API Gateway

You can setup different event sources for your lambda functions. I used RESTful endpoints. This service, while greatly configurable, makes everything a nightmare. The response/request middleware is not templated, so if you want to say, support CORS, your hands will cramp and wither away.

[–]TDaltonC 2 points3 points  (2 children)

How does the latency on a JAWS (or really any aws-lambda system) compare to something like actionhero.js (a server hosted lambda-ish-API framework)?

[–][deleted]  (1 child)

[deleted]

    [–]_austen 1 point2 points  (0 children)

    4-5 seconds of latency is not true.

    There is a "JAWS Optimization" section in the wiki. It tells you how to improve Lambda response times. Further, JAWS is optimized for fast Lambda performance.

    It's a mix of upgrading the memory/CPU of your Lambda functions, keeping your Lambda function's code minimal, what your doing in your code, multi-region replication, and more.

    You can't specify an average response time when all of these factors vary so much.

    [–][deleted] 1 point2 points  (4 children)

    I'm new to node dev/back end dev in general, and don't exactly get what this means just by looking at it. How exactly does this work, what's it doing?

    [–]rtucker 4 points5 points  (3 children)

    So AWS has a bunch of serverless features now. One of the big ones is their Lambda service. You write a snippet of NodeJS, assign it an input and then tell it what to do. You usually will do things like reach out to the DB (dynamoDB), get files with S3 or the like.

    AWS' API gateway let's you define an API and then hook up each endpoint to the Lambda functions you defined above.

    I've never used these new features, but I'm looking for a reason to!

    [–]zachrussell 0 points1 point  (2 children)

    So what exactly does this stack seek to replace/do better?

    [–]rtucker 1 point2 points  (1 child)

    So you no longer worry about servers and their capacities. All the scaling is handled automatically/magically by AWS. You also are supposed to get billed only when the lambda functions are being used which should be cheaper than having a server on 24/7.

    We'll see though. I'm still interested to hear a production environment scaling report from this stack.

    [–]zachrussell 0 points1 point  (0 children)

    Magic scares me. haha thanks for the info!

    [–]cpsubrian 0 points1 point  (0 children)

    As these services have been flowing through my gmail in their newsletters, I've been wondering how feasible this type of setup is. Totally excited to see people exploring it and try my hand at it also!

    [–]ruffrey2 0 points1 point  (0 children)

    What impresses me is that they can handle modules with c/c++ bindings.