AWS Lambda

  • I’ve had a chance to use the service for a couple of weeks. My quick summary review is that it’s a little tricky setting up the IAM roles and security groups, but once you have that going, it works great! I see a ton of potential here in transforming the way people use AWS.

    I also put together the Netflix use cases in the keynote so if you have any questions I’ll try to answer them!

  • Right now the only language/runtime supported is js/node, but they intend to include others.

    (figured people would want to know this, and you have to scroll a ways to find out, so)

  • I'm so torn - on one side this is a very neat thing that'll save a lot of boilerplate, and on the other it screams of vendor lock-in.

  • I wish they hadn't named the units of computation "Lambda functions". Cause, you know there's already something known as a "Lambda function" in computer science.

    But kudos for Amazon for furthering the datacenter-is-the-computer approach. It is simply the right thing to do.

  • Holy mind blowing awesomeness, this changes everything, yet I feel like this was such an obvious thing to do. So obvious that I can't believe it is real. This, ladies and gentlemen, is why AWS defines the cloud, they are so far beyond everyone else and still innovating, even and the most basic level.

  • Something I want: AWS Lambda code which responds to S3 PUTs by issuing Cloudfront invalidations. Anyone want to write this?

  • Seems like a much more interesting announcement than the container service. Can see the architectures of dozens of our systms collapsing down with this.

  • This is way cool especially considering S3's event notification will enable a ton of interesting workflows: https://news.ycombinator.com/item?id=8602955

  • Should I think of this essentially as an abstraction that can replace my asynchronous task queue + workers (e.g. RabbitMQ + Celery workers, obviously assuming you aren't using MQ for additional messaging)? I hate managing those pieces and would be happy to hand that infrastructure to Lambda, but are there additional benefits or use cases that are opened up?

    I guess I would have expected others to describe this the same way ("replaces your distributed task queue"), but since I'm not seeing that description I wonder if I've misunderstood.

  • You can rip out quite a bit of logic into separate services with this.

    Will definitely be interesting to see how Lambda actually works.

    Try out Blockspring, you can play around with your usecase now (and no vendor lock-in).

  • Is it me or AWS is releasing too many services... there is a service for everything. I wounder if they are just throwing stuff out there see what sticks... kinda like landing pages.

  • Claiming that your code is a 'lambda function' makes it sound sexy, but.. isn't it really just a procedure? Unless I'm missing something and there is some higher-ordered capability for composing AWS lambda functions together in a way that permits the platform to perform lambda reductions or optimize resource allocation...

  • I'm excited for this. This replaces what I wanted to use SQS for. SQS always felt like too much vendor lock-in to me to justify not using something like RabbitMQ or Beanstalkd.

    With Lambda, the resource consuming the queue is managed for me - that is huge. Also, the pay by time model is perfect for this - instead of managing when to stop/start resource intensive instances, I don't even have to think about the problem. I only get charged what I used, which can be crucial during growth stages of a business or prototype.

    The big penalty is the vendor lock-in, but this tips the scales for me for certain things.

  • > You can use any third party library, even native ones. [1]

    I realize they are starting with node.js, but I wonder how this will work? It sounds like they plan to support arbitrary dependencies. Will you upload a Docker container with your necessary dependencies? They talk about milliseconds until your code is running, and containers may be (?) slower than that. Or am I hoping for too much.

    [1] http://aws.amazon.com/lambda/details/

  • One difficult part of doing event triggered processing is in the progress reporting and keeping the code related to it simple. I wonder how they deal with that.

  • I'd pretty much given up on AWS for compute and moved most everything to Linode and some bare metal servers, but this service looks very compelling for discrete compute tasks.

    The ability to pay only for the fractions of seconds actually used, and the ability to scale quickly without provisioning (or over-provisioning) EC2 instances, is awfully attractive.

    Plus, Amazon has priced this pretty aggressively — i.e., it looks shockingly cheap.

  • How is this different from CGI?

  • Good stuff. Basically it seems to do the bind+listen for you if you are the trigger subscriber. If you are the trigger generator, then it does socket.write for you. But the big deal is that you dont pay for 'listen', just pay for the function execution. The one thing that will surely happen with this is that the code written will be 'locked in' to run only on aws territory.

  • undefined

  • All these announcement are making me feel sorry for all the other players in the cloud game. The other guys don't even come close.

  • This looks quite interesting, and a lot more fun to work with than maintaining a pool of servers ready to handle events and spinning up new ones based on capacity.

    Anyone know of any similar mechanisms for the OpenStack world, or more generally for any cloud infrastructure other than AWS?

  • I tweeted that it's a PITA to transcoded uploaded media yesterday and today AWS solve the problem!

    I HAVE THE POWER

    https://twitter.com/kaihendry/status/532783437225025537

  • Full-circle back to mainframe era.

  • Is this comparable to IronWorker?

  • undefined

  • It sounds like this is essentially what Joyent's Manta is, which we've been using in production for the last year and have found to be absolutely fantastic. Are there differences that I'm not seeing?

  • How is it different from Google App Engine? Conceptually the two seem very similar to me, that is, developers do not have to worry about the underling infrastructure at all---just write code and deploy.

  • I finally have stored procedures and triggers for my DynamoDB database!

  • Haven't had much time to read the docs. Sorry if it's already evident, but does it allow for running Lambda code on cron as opposed to listening to some event?

  • I love that it uses Node.js to start, but does it support NPM?

  • AWS Lambda announcement video: https://www.youtube.com/watch?v=9eHoyUVo-yg

  • Does AWS Lambda supports cron-like periodic triggers?

  • This reminds me of http://www.Webscript.io

    Similar single event -> function service

  • It would be nice if a lambda could respond to web requests. Maybe an Elastic Loud Balancer could be an "event-source".

  • Would this be useful for build services like setting up a jenkins instance using lambda compute resources as slaves?

  • From a casual glance: it's kind of like Heroku but with Node.js, and it scales automatically?

  • Huh? Shared server infrastructure? That's really what this sounds like. Welcome to web hosting in 1999 guys. Most of the point of AWS was that you have your own dedicated resources. Sure, this is a scaling solution, but revolutionary?

  • Amazon Echo (voice interface of IoT) + Amazon Lambda (the cloud services of (IoT) = Amazon disrupting home appliance IoT products.

  • Sounds a bit like Mirage OS to me (http://www.openmirage.org).

  • How to get this on private cloud?

  • IaaS -> PaaS slowly but surely

  • How can it compare to zappier?

  • What about dependencies. What if you need a specific environment setup first in order to process. Would you end up paying 1 minute for each request just so that it can start installing bunch of stuff? Is it possible to just setup a VM of some sort and use that environment each time?

    If thats possible Lambda would be like PiCloud but without Python, and will stick around (hopefully).