So the backend becomes a repository of small lambda-modules.. on a testing perspective, that's pretty cool. I agree that it could be the next big thing as new libraries leverage that.

Basically, there's no more "Platform as a service".. there is just "your code" that gets executed whenever. You can upload a new module without touching the other modules.

Something worth exploring in my next hackathon : )

It's really just a more fine-grained PaaS, not significantly different than a bunch of tiny Heroku apps (the ~1 second cold start time is significantly better than Heroku's though)

If the environment the lambda-modules run in isn't PaaS, how would you categorize it?

I've used http://www.Webscript.io in the past which is essentially just like AWS Lamda to make static sites 'dynamic' with no backend.

The real question here is still: why doesn't Amazon offer a GET interface to Lambda? It's so, so, so close. So almost. They offer POST (through a work-around with S3), why not GET?

That is the real destination. With lambda serving GETs, we can remove the "for a single page app" from the title. AWS is so close to fulfilling the promise of its cloud: let developers worry about code.

Since lamba is already handling the backend api calls, couldn't you just host the html and js in s3/cloudfront and not have to host anything?

It is a bit slow still. Jitsu[1], which starts unikernels is fast enough to do per request image booting, but Amazon seem to have a 1s cold start which is just a bit slow.

[1] https://github.com/mirage/jitsu

Ah, so there is a 1s cold start. I couldn't understand how they managed to get a container (which I imagine they are using?) running "within milliseconds". I guess the millisecond claim only holds for concurrent requests then?

Seems so for the measurements I have seen yes. Concurrent or close before it has been shut down.

This is the one thing I need to make them useful! This would make Lambda's so much easier to invoke, without needing to build custom code to put together an SQS message or similar.

What's the typical latency for a request when you use lambda, such as for this example?

My anecdotal experience is that it's about ~1 sec. for a "cold" request, and on the order of 10s of ms for repeated requests thereafter.

p99.9 was 100ms for me. p50 was 10ms.

Did 100k requests. Did these tests back in November during the preview. I imagine it has different latency now so those numbers are probably close to useless.

the first time i found it to be about 1-2 seconds, afterwards it's more 0-1s

Naive question: how does his example differ from a server responding to HTTP requests, that would take a JSON event as an argument and return a json version of:

    "the value was: "+ event['key1']

I suppose the AWS wins in term of set up and easiness of deployment. Anything else?

It differs in that you don't have to worry about scaling up that HTTP server, or pay for the machine hosting that HTTP server. With Lambda, you only pay per requests, current rate is $0.20 per 1 million requests.

Is there also any limit on machine resources that a single request can use? I'm curious about cases in which requests might need non-trivial amount of computational power.

You pay for request time too, measured in 100ms increments. And you pay more for more CPU/RAM.

I don't think I'd trust building directly on it for the 100 req/sec limit and whatever latency it introduces, but it seems like it would complement heroku dynos really nicely farming out processor-intensive stuff like bcrypt.

I think it is 100 concurrent requests per account. That is pretty low IMO. I think it was intended for things that are CPU intensive and short-lived. If it needs to pull from a data store and process, it likely isn't a good idea for lambda to begin with, right?

I agree, it is only really useful to use like this for certain scenarios.

All of those limits are typically to protect users from being over charged if they fat-finger something. Most limits like that can be lifted with a support ticket. I'm not sure if this is one of them but I think it's likely.

You are correct; that limit can be raised. Just ask!

Could the limit also be lowered, for damage control?

Does nobody else look at this and worry about the vendor lock in implications?

If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.

I don't worry about lock in in this particular case. At the platform level there is an element of implicit lock in because nobody else offers this exact service.

However, the application level can be easily moved to another platform. You could host the handler function code on an EC2 instance or bare-metal server. Little would change in the app code, except the API endpoint to which requests are sent.

So IMHO there is no lock in in the traditional sense, but there is a switching cost if you want to move to another platform.

>At the platform level there is an element of implicit lock in because nobody else offers this exact service.

That's kinda what I meant (although there seem to be some similar variants with totally different APIs).

Anything similar will use a different API, as well. Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code.

>So IMHO there is no lock in in the traditional sense

Lock-in doesn't mean that it's impossible to move to a different platform, it just means that there's a high cost. To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2.

Actually, it seems like this is Amazon's real business strategy with things like this. They want you to use all of their different services like this, SQS, SES, Elastic beanstalk, their hosted database thing. Individually the costs of moving away from all of them is not that high, but add them all together and it becomes immense.

> Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code.

That's true. I think we're essentially on the same page here.

I guess I'm still using the old definition of lock in. Poor example: a proprietary Microsoft format that can only be understood by MS software. There is literally no alternative to using MS software if you want to access files created using this format.

Does "high switching cost" == "lock in"? I think it is a grey area. I would not consider myself locked in to Lambda if I had made the decision to host my app there, although I do see there is a high switching cost.

However, if I used RDS Postgres and Amazon decided to prevent me from creating database dumps to migrate to a self-hosted Postgres, then I would be very unhappy because that would be an arbitrary restriction with no purpose except to keep me on AWS.

> To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2.

I agree completely with this. Let's say this was implemented on EC2 instances running Ubuntu, and configured with something like Salt or Puppet. The cost of moving to a Digital Ocean box would be negligible.

I wouldn't say that's a big concern. Because you control the binaries that run on AWS Lambda, it wouldn't be too hard to move the event-based logic of invoking a function to your own custom task queue.

Other AWS services are a bigger concern for lock-in, like the DB stuff, EBS and so on.

Configuring this thing is not that trivial even if everything run on it does belong to you. All of that configuration is stuff that you'd have to re-implement when moving to a different platform.

Some time ago, when Lambda was in its early preview, I've created awsletter [1], a newsletter system w/o any old-style backend components - only AWS SDK for browser, S3 and Lambda. Pretty the same idea - utilize "invoke function" calls to realize backend actions.

[1] https://github.com/jelz/awsletter/

How does the pricing compare with say X amount of tasks that run for 1 second each compared to what you could expect from 1 hour on a medium ec2 instance?

EDIT: I see it offers "The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month. " What is a GB-second ;)

Re: pricing -- good question I'm going going to test that.

Re: gigabyte seconds: It's how much memory (RAM) you're using:

128mb RAM (lowest possible value) for 10s == 1 GB/s

1gb RAM for 1s == 1 GB/s

I think it's a pretty clever way to (somewhat) directly correlate compute cost with power (energy). If you remember what John McCarthy said when he imagined that computing would be a public utility one day (http://www.technologyreview.com/news/425623/the-cloud-impera...) I think this is about as close to that as we're going to get for a little while.

Doesn't this terminology come from power utilities where a kilowatt hour is kW.h. as in kilowatt × hour. Not kilowatt / hour. So why is a GB second, a GB / second and not GB × second?

It is a GB x second -- I've just seen it written more commonly as GB/s. I think we need a better abbrv for it... gBs?

Then it should be GB.s or GBs.

GB/s gives a different meaning. For example I could use 600 GB in the first second, then 400 GB in the second second. All together its 1000 GB.s, at an average of 500 GB/s for 2 seconds.

This is not perfect because kilowatt is a rate so kWh is a quantity. But GB is already a quantity. So a GB.s doesn't make sense either. It would need to be an equivalent memory rate usage × time in order to get memory quantity. Like avg GB/s × s.

> This is not perfect because kilowatt is a rate so kWh is a quantity.

You're a bit mixed up there. Kilowatt is a quantity (unit of energy), kWh is the rate.

Minor quibble, but still important: 128 * 10 != 1024. Eight seconds @ 128mb is the equivalent value to using 1gb for a second.

Thanks I get it now, nice reference :)

This makes me think that Amazon should build a service that acts as a virtualized "pre-fork worker model" server (a la [g]unicorn) and transparently scales WSGI/Rack/etc application processes across machines.

How hard is it to pull in extra dependencies for the script ?

There are a few answers in the FAQ around this: (none specifically answering the "easy" part): http://aws.amazon.com/lambda/faqs/

My own experiences of working with Amazon services suggest that this will probably be great for some use-cases and very complex and unpleasant for others, and will probably be updated every six or twelve months in a fairly drastic way which will make it hard to find helpful documentation. Maybe I'm just feeling cynical today, though.

I think AWS is betting big on Lambda (I work there). So I think you'll see a lot of continued innovation around the service. They're pretty intense about consuming customer feedback and iterating on it so if you have an idea or desire that you would like Lambda to incorporate I'd definitely shoot them an email/ticket -- it's not a black hole.

AWS has a couple of issues with Lambda. If you use a binary its very difficult to talk to the process. No port binding means its nearly impossible to talk to processes without prohibitive changes (named pipes are a solution but it requires extensive code changes to existing apps)

It is certainly an amazing product. Would be interesting to know how Amazon designed it, specially for security. Does anyone know if they just put all requests in a queue and spin up containerized environments for each request?

Is it possible to have the same thing but over websockets? As Lambda can also listen to DynamoDB, it would be quite interestig to have an ability to forward this kind of events to browser clients.

How would this use differ from Amazon's elastic beanstalk?

With beanstalk, you're paying in terms of multiples of server instances at all times, even if nothing is hitting your servers. With Lambda, you pay only for the execution time of your function, which is only when a request is made.

I like the idea of Lambda. I have some linux binaries that I would like to run on demand. I wonder if this is possible.

You should be able to do that as described here : https://aws.amazon.com/blogs/compute/running-executables-in-...

Note that there are some limits regarding the size of the zip you upload [1].

1: http://docs.aws.amazon.com/lambda/latest/dg/limits.html

Thanks for the links! If my executable relies on .so files in a lib directory, is it possible to set env variables to point to a local path?

Why would you need to do that? Just set DT_RUNPATH when you link the binary and use the $ORIGIN variable to set a relative path.

Is there anywhere that has decent documentation on how to do that? I'm not very good with compiling and linking C, and have been trying to work out some distribution issues with a project I was working on in a compile-to-c language, where it relies on a dynamically linked shared library that I want to distrubute along with it.

I would read section 3.9 of Ulrich Drepper's "How to Write Shared Libraries" [0].

[0] - http://www.akkadia.org/drepper/dsohowto.pdf

Pretty much. Anything that you can compile on the AWS Amazon Linux AMI will run on Lambda.

Lambda is a focused, specialized service for running short-lived processes triggered by events and is one of the many services provided by AWS that have formed the foundation for many companies and other PaaS providers for many years, while Azure Mobile App Service is a packaged and branded collection of services including data storage and push notifications that is similar to backend service providers like Parse and Urban Airship pre-pivot (at least one of which was built on top of AWS), and tries to offer services comparable to a subset of other AWS services including SNS (push notifications), RDS or DynamoDB (databases as a service), among others.

It's also quite strange to spotlight Azure as if it's doing something at all remarkable considering the "Mobile Backend as a Service" market has existed for years and actually seems to be on the decline, at least as a standalone segment.

I mentioned Azure Mobile Services because (as it's node-based) it can be used to implement exactly the same application as the OP, line-for-line exactly the same.

A static webpage, that calls into a javascript based service, you can register a script to run in that service without any infrastructure hassle, because, well, it's a service.

You are right that there are many comparable Mobile Services that can do many other things and might be branded differently, but this just adds to my point: I don't see what's new here, other than that the OP has seen the light on static webapps combined with platform services.

Can this be called RPC? If not, what is the difference? Amaz(on)ing service anyway!

"the future is now, and it's down because somebody used the secret key to drain the poster's bank account"

To be sure, the author specifies that the IAM role being exposed here is only allowed to invoke the function. That's great for the security of the other resources on the account, but still allows a reasonably determined attacker to run up a Bill of Unusual Size quite rapidly.

For instance, the rate limiter currently kicks in at 1000TPS. Assuming the smallest memory size (128MB) and requests <100ms, that's a worst-case spend of roughly $18/day per Lambda function. Not the wallet-melting consequences of, say, accidentally posting AWS root credentials but not great either. Multiply that by the number of endpoints you'd likely want in a single-page app, and it gets expensive.

But the same is true of any backend. Once you know the endpoint being used by the frontend, you can blast the backend with requests and one of two things will happen:

* You will take down the site (a DoS attack). * Or the victim has auto-scaling and you rack up their AWS charges.

This is hardly a unique problem to Lambda.

The biggest difference is ease of rate limiting. With lambda, I imagine the best you could do would be check the IP in a Redis cache at the beginning of each request (if the SDK even includes that info) to minimize the damage. But there would be no way to fully stop an attacker without turning off the service entirely.

If you run your own webserver, I think you can stop stuff like that more efficiently / without the expense, eg at the nginx level.

The question is whether or not the cost per request is higher than if you were running something similar on EC2.

...and that's why CloudWatch allows you to set billing alerts.

You could even route a billing alerts (via SNS) back to a Lambda function, use it to set a flag, and run in a reduced capacity mode if this is a concern.

I always tell my audiences (I work for Amazon) that it should be possible to build a system where you know the actual cost of every web page you generate and every request you serve, and to make sure that each one has the ability to earn its keep (by ultimately driving revenue).

An official example repo (or, less ideally, a tutorial) of how to automate the cost-control would probably go a long way.

I like lambda a lot. I just have to find more use cases for it.

Hey, just a heads up, you posted your AWS secret key. I'd take that down and change your key ASAP. I had my keys compromised before and someone racked up a $5k AWS bill mining bit coins.

> One thing you might note is that we’re exposing our AWS public and secret keys. This is actually not that big of a deal. To make this secure, we actually created a new AWS User and with a Policy specifically preventing everything except the one Lambda Function:

he mentions in the article he created that account specifically to only have the ability to call that one lambda function - which I didnt realize you could restrict to that level.

I like this one better because it demos using google auth to get temporary aws credentials:

https://github.com/cloudnative/lambda-chat

Last message is "Peter Sankauskas Hello". I tried to send some message, and it's saying "Message sent to SNS successfully". But these message never show up in the page.

I'll be talking about this at Gluecon this week. You are right, it is a little broken right now.