Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda

aws.amazon.com

Post reply on HN
Print view View original

81–90 of 164 posts

Re: AWS Lambda

#81

Post by crucialfelix »

numlocked wrote: post #55

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 sa…

Rabbit and celery is the backend system I have now. I was doing a lot of things on demand, event driven, but this resulted in overloading the database ( currently my system constraint ) or in elongating the queue too much. Some event would flood the queue with thousands of tasks. Now I have a periodic task that on each iteration chooses the most pressing task. And the system is stable but I have a bad backlog.

So I'd love to have a reactive task system where I didn't have to worry about the resource usage. Think how much precious developer time I've wasted just managing resource expenditures. Much of my coding this week has been just trying to optimize for this stupid constraint. How many processors do I have, how much disk io, is the memory getting close to swapping ?

I for one welcome our new cloud overlords.

Re: AWS Lambda

#82

Post by jberryman »

numlocked wrote: post #55

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 sa…

I guess maybe part of what you might be missing is that these "Lambda functions" can (will be able to?) be kicked off by all sorts of different AWS events, so it can replace queue + workers where you're generating tasks from your own code, but it might also be able to replace the code that generates those tasks too.

Re: AWS Lambda

#83

Post by jrmcauliffe »

dk8996 wrote: post #64

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.

If you listen to Amazon at their shin-digs, they tell it like all of these new services and features are in response to requests from existing customers.

Re: AWS Lambda

#84

Post by jedberg »

krallin wrote: post #45
joshuahutt wrote: post #13

Earlier quoted context omitted.

One thing I am struggling to understand is how much of my applications can be replaced with Lambda. I think it would be really awesome to make applications that do not have any dedicated instances associated with them, but are entirely based on the various AWS platforms. For some things, it seems like Lambda could be a drop-in replacement, whereas others, it would not quite fit the bill. Do you think it will be possi…

It seems like you're limited to 25 concurrent lambda functions executing (at least at this time). This looks like it's more geared towards enabling you to automate / orchestrate your AWS resources, that run customer-facing code.

The 25 function limit is probably one of those small defaults that's easy to change, like the 20 instance limit.

Re: AWS Lambda

#85

Post by crucialfelix »

notastartup wrote: post #60
MBlume wrote: post #4

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 saw it and was shocked that Python is not yet supported.

Most of the Python things I would want to do have slow startup times. Generally I keep my pythons running. But node is super quick to start.

Re: AWS Lambda

#86

Post by mehh »

spitfire wrote: post #34

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.

Really douche to use a computer science term as your product name, are they going to trade mark that or are the just happy with the confusion it will cause.

Re: AWS Lambda

#87

Post by carimura »

adelevie wrote: post #36

Is this comparable to IronWorker?

[I'm with Iron.io]

Similar, yes. We're excited that developers are seeing the power of the task/worker/lambda being the scalable unit of work rather than server or VM or even container.

Haven't used Lambda much yet but off hand we see many IronWorker advantages:

- Supports all languages - Easily scale to thousands of parallel workers - Integrated logging, error reporting, alerts, auto-retries on failure - Integration with IronMQ our queue service to achieve stream processing and pipelining - A great dashboard to manage your workers/tasks

And many innovations/announcements coming soon that'll make using IronWorker a great choice for developers both on AWS and inside the enterprise firewall.

Re: AWS Lambda

#88

Post by numlocked »

jberryman wrote: post #82
numlocked wrote: post #55

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 sa…

I guess maybe part of what you might be missing is that these "Lambda functions" can (will be able to?) be kicked off by all sorts of different AWS events, so it can replace queue + workers where you're generating tasks from your own code, but it might also be able to replace the code that generates those tasks too.

Now that you say it, I'm sure we'll see wrappers to support this type of thing. For instance, I could imagine a django library that provides a declarative way to wire Django signals to AWS Lambda functions.

lambda_signal(Model, signal_name, lambda_fn_name)

When that signal fired on the model, the model would get serialized to JSON and sent to the lambda function. It'd be fun to whip this up if no one beats me to the punch.

lambda_signal(User, 'post_save', 'sync_to_mailchimp')

Re: AWS Lambda

#90

Post by nightpool »

jameshart wrote: post #24

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...

Lambda is just the brand name.
Post reply on HN