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 : )
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.
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 value was: "+ event['key1']
I agree, it is only really useful to use like this for certain scenarios.
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.
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.
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.
Other AWS services are a bigger concern for lock-in, like the DB stuff, EBS and so on.
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: 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.
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.
Note that there are some limits regarding the size of the zip you upload [1].
How is this different from what Azure Mobile Services and many others have been offering for the past 2 years? To me it seems the author is proclaiming Platform As A Service is entirely new (look, no spinning up AWS instances!) while this has been around for quite some time, just Amazon is getting into it more seriously recently.
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.
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.
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.
* 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.
If you run your own webserver, I think you can stop stuff like that more efficiently / without the expense, eg at the nginx level.
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).
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.
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.
You're a bit mixed up there. Kilowatt is a quantity (unit of energy), kWh is the rate.