[pkkp]

A neat idea, but the resultant vendor lock-in here worries me. I've heard horror stories of the amount of effort required to move away from PaaS platforms like Heroku (I believe Genius is one such tale) due to architecture-specific components like jobs, but this seems to take that reliance to a whole new, all-inconclusive level.

This might be neat or a quick weekend or hackathon project where you just want to Get Shit Done, but I can't imagine anyone ever committing fully to the platform and having no second thoughts.

An open architecture built on this sort of idea would be nifty, but tools like Docker have almost reduced the sysadmin components for a lot of simple projects to something that's not too far from this anyhow, from an ease of use perspective.

[ac360]

I understand this concern. This is where JAWS comes in. The best way to do Lambda development, is to make AWS Lambda a thin wrapper around your own separate code, to keep that code re-usable, testable and AWS independent.

JAWS generates scaffolding to encourage this for you. As a result, your code ends up looking just like a traditional application framework's code.

I just did a talk on JAWS @ Re:Invent to over 600 people. The line was out the door. Honestly, I didn't hear "I'm only going to use this for a hackathon project" once, except for now. Instead, all I heard was, "OMG we don't have to deal with servers!!! We will use this for everything!!!". And there were huge enterprise companies there.

I'm a Docker lover, but Lambda has a huge head start in many areas. Super fast spin-up times, orchestration handled for you, the ability to containerize functions/endpoints not just applications, and pay per use pricing. All of this comes with Lambda out-of-the-box.

[alexbilbie]

Lambda functions are just small Node scripts wrapped up in a Docker container and then executed on a custom scheduler. I don't think it would be too difficult to port to another platform.

[lsaferite]

And Java classes.