> He seems to miss a lot of the potential value that the serverless architecture model brings to the table.

Its a code evaluation platform, running containerized under the hood, and with a large markup by Amazon. Companies have offered this for years before AWS, but AWS is tooting the horn louder than people have before.

Is it useful? Yeah, sure. Is it revolutionary? Oh come on now.

Just like "the cloud" is just timeshare on someone else's computer, this is simply code management and execution abstracted a few more layers up.

EDIT: Sorry I'm not on the hype train folks.

The infrastructure isn't revolutionary, I believe IRON.IO and others have similar platforms.

The innovative aspect of AWS Lambda is the triggers hook into a variety of popular AWS services, e.g. S3, Kinesis etc, with very little setup required from the developer, along with an easy interface and setup process. It abstracts away from containers and operating systems.

Google and Microsoft have recently launched beta versions offering 'Lambda' like functionality. AWS has led on this one, I don't think you can argue against that.

I'm with Iron.io, thanks for the mention. Interesting to see the architecture/patterns so front and center all of a sudden, it's what we've been doing for a while now.

Very true that a key benefit of AWS Lambda is the ability to hook into the internals, but to the article's point, that's a pretty significant level of lock-in. We recommend to our customers who want a similar level of functionality hook up the internal events to SNS, at which point a job can be triggered on our end.

We operate across any cloud, standardizing through Docker images as the unit of code. It's "serverless" to the developer in that the only configuration is setting the event triggers. Of course there's compute involved, but it's outside of the development lifecycle.

Another major piece of this puzzle that people overlook is AWS API Gateway, which provides a web gateway to Lambda. It's a newer product (and quite poorly PM'd, quite frankly), but it's an important part of the puzzle that no other cloud function provider has yet.

I've not used API Gateway, but I believe Microsoft support invoking their 'Azure Functions' style lambda service via HTTP calls

https://azure.microsoft.com/en-us/documentation/articles/fun...

You can do that with Lambda as well. The API Gateway is an abstraction in front of that giving you more control then connecting to Lambda directly.

I tried to build a serverless contact form by hooking up AWS Lambda function into S3 HTTP API event source and it's hard to configure and not working well. In any case it's not an alternative to HTTP Request triggers in Google Cloud Functions or Azure Functions.

For some reason I can't reply directly to your comment, but from that chart it looks like you can invoke a function, but not pass it any input, which makes it vastly less useful, and means that it can be used for serverless web frameworks.

I figured that the truly innovative aspect here was the pricing model. Other similar services expect your "containers" to run 24/7. Lambda runs your container for as long as the request takes, and only charges you for that. It's like what Heroku was originally trying to do with its Aspen Ruby stack, plugging everyone's apps as handlers into Passenger and only (quickly) spinning them up when they get requests.

You've been able to do the same thing forever by just writing everything as (non-F/non-WS)CGI scripts, or as isolated PHP servlets. But nobody ever charged for those by tracking CPU time, rather than just imposing a monthly fee + caps.

@snockerton thanks for the kind comments. No that was NOT (by any means) how I have approached the post. Arguably the attempt of humor in the article and the picking of a misleading title may have misled the readers to think I was dismissive with the technology. But that wasn't the intent. I do find Lambda (and Serverless in general) very intriguing and I agree on the potentials.