I wrote the apex(1) tool and created https://apex.sh/ping/ with Lambda, in general it has been great, has scaled flawlessly since launch (granted I'm only doing ~8M requests / day).

Conceptually I think it's great for pipelines or use-cases like this, VMs are generally a terrible level of abstraction for a lot of problems, and the Lambda style promotes better architecture because of this.

The connectivity between Kinesis/SNS and friends is great. I'd agree that Lambda is not currently a good fit for "regular" apps, APIs should be fine now that the proxy stuff is in there, though there's slight latency.

No need to worry about gracefully stopping or restarting daemons, just push new code and the old stuff goes away, it really is a great abstraction that way. Basically replace anything you'd use a Go channel for, with more Lambda or SNS->Lambda if you need retries and backoff, it'll spare you a lot of code.

I find the workflow great as well, the slowest part for me is compiling the Go binaries, the rest is virtually instant. Especially now with all this needlessly complex Docker stuff it's refreshing to use something simple.

Cost is prohibitive for sustained use, so make sure you price things out properly, it sounds very cheap until you look at say a constant 100 requests/s behind API Gateway. It's easily 300-400% what you'd pay on EC2.

Cold-start is really a non-issue in most cases, it seems to take very little to keep a function warmed, so unless you get zero traffic (which would be dirt cheap on a t2.micro anyway) you'll be fine.

We gave it a run in prod and abandoned it quickly. We were using it for parallel file processing (S3->lambda for CPU-heavy task->return a few numbers in a JSON).

Last I calculated, it's nearly 5x the cost of comparable t2 on-demand EC2 instances. That can be mitigated if you have spiky traffic where you'd need to turn on several EC2 instances for less than an hour but are stuck paying for the full hour, or if you can scale to zero for extended periods of time.

Critical to us: you don't have the ability to serve concurrent requests from a single lambda worker, so if you're waiting for async IO (e.g. downloading from S3) then you're wasting money you wouldn't be wasting with EC2. You end up with one file per lambda worker, whereas we could handle about five files concurrently on a normal VM because of async IO. -- For us lambda was prohibitively expensive at scale. I suspect a fair number of people reporting significant savings vs EC2 had over-provisioned instances.

I wrote a blog post about how we process Hearthstone log files into replays for https://hsreplay.net

https://hearthsim.info/blog/how-we-process-replays/

TLDR: AWS Lambda is awesome if you have indeterminate-but-high amounts of small CPU-bound tasks you want to be able to do in parallel, as soon as they are needed. Awesome for file processing (eg. image resizing) for example.

But being stuck on Python 2.7 sucks. PLEASE Amazon, announce Python 3 support already.

Using Python for an API call that is basically a thin wrapper around one of our supplier's (not very good) APIs running ~500k requests per day. We've had problems twice with 500 errors for all requests at night when they do maintenance on the API gateway/lambda hardware and don't tell us (in both cases they announced new features the next morning). We reported it to support both times and got "we're sorry, but since it's all good now there is nothing to do" as the response both times. Left a bad taste in our mouth and so we haven't deployed anything new to it and probably won't for a while despite it working well otherwise.

We tried about a year ago and gave up after too much wasted effort on getting any kind of a good dev/CI/CD pipeline going. Mainly due to lack of tooling. Things like environment variables, etc.

Taking another look now on some side projects, to get a sense of if all the of the issues have been addressed.

But the big ones were lack of env variables, and the tooling was atrocious.

I really like the concept, and the current serverless (serverless.com) framework has been simplified, runs based on cloud formation, and also allows the project to be run as an express server, and potentially with additional plugins on a competing serverless architecture.

Don't use it if you require low latency - performance is abysmal and the bottleneck is Lambda overhead that you cannot influence. Also, if you don't have a high traffic function, cold start is also an issue, at least when using Java. There is a "hack" to avoid this issue: create a cloudwatch check that triggers your function every minute or so. This sounds weird but if you consider that this is good practice, this gives you an overview how production-ready Lambda is. Nice thing is that is's pretty cheap though.

I've used Lambda in production under pretty high throughput conditions before. It's fairly stable – given that we were using Kinesis to feed into it (which was a pain to setup).

Recently, I've been using stdlib (https://stdlib.com) to do function-services since it's a lot easier to get started with it a bit more intuitive for newcomers to understand.

We use Lambda and API gateway for all production[1] requests. HTML, Server side rendered JS, API calls. All through lambda. There are some rough edges. We wrote our own framework/deployment tool[2] to fix some of them. AWS has been making lots of improvements too. Many in just the last few months. This setup was much harder to run when we first started a year and a half ago. Overall our team is super happy. It is cheaper and simpler to operate than our previous ec2+Opsworks setup. We get code to production faster and spend more time on actual business problems vs infastructure problems. I also pretty much agree with everything Ben Kehoe said in this article: https://serverless.zone/serverless-vs-paas-and-docker-three-....

[1] www.bustle.com and www.romper.com do a combined XX million unique visitors per month.

[2] https://github.com/bustlelabs/shep

I started with a manually-packaged Python function and credstash [1] to store credentials for non-AWS services. It gets invoked nightly by CloudWatch and has been bulletproof for months. I recently built a microservice [2] for Election Day with Flask and deployed it behind API Gateway with Zappa [3]. Lambda isn't for every use case, but for those it is, I'm bullish.

[1] https://github.com/fugue/credstash

[2] https://topics.arlingtonva.us/2016/11/voter-registration-sea...

[3] https://www.zappa.io/

You can check out my talk at AWS E-Business Day. For ~50 minutes we are talking how we switched to serverless architectures for one of the largest online retailers of Europe and our learnings.

https://www.youtube.com/watch?v=WYVamFcphxo

I use it for one of my clients to send an average of 400k browser push notifications, competitors send then in 40 minutes. With Lambda + kinesis firehose(16 shards) my solution is able to send them in less than 4 minutes.

I've been using Lambda in production for multiple things.

I'm not using Apex or any of the other frameworks, just plain Go code wrapped by the JS function.

It's really awesome to work with, you just deploy a function and quit worrying about it.

Things like callbacks, message monitoring and stuff like that.

Example:

Monitor SNS messages for auto-scaling and send a message to slack when something fails. https://github.com/KensoDev/sns-lambda-notifier-golang

We use it at https://iotsky.io/ for all backend interaction with aws IoT.

Wrote a blog post about it too: https://medium.com/@iotsky/how-we-built-the-iotsky-backend-u...

I wrote Gimel[0] - an A/B testing backend using Labmda and Redis (it can also work with Google BigQuery w/Kinesis).

It's used in production for a few months now and we're really happy with it. It provides a negligible-cost replacement to Optimizely for us.

[0] https://github.com/Alephbet/gimel

It has been good for us, although our use case has mainly been ETL pipelines which seems quite a good fit, especially when you connect it up to Kinesis Firehose/Kinesis or S3 notifications.

The main issue we've seen is, even at the "top" tier (1536mb) the CPU performance doesn't seem very good, it's difficult to tell as they abstract you away from what is actually going on under the hood.

Main advantages: easy to deploy, no infrastructure worries if your problem fits, event based triggers means you don't have to write any of that code, fits well in the AWS ecosystem.

I've seen people making serverless websites and things like that, but I'm not convinced Lambda is a good fit for such a thing (happy to be proven wrong)

Didn't get to prod. Looked at it around Juneish 2016. High error rates, no SLA, slow boot times, no tooling, deeply inadequate logging.

My technical recommendation is as follows: "No".

It works remarkably well if you use a development toolchain (serverless and claudia are both good though I prefer the latter).

My only gripe is that API Gateway (APIG) charges $3.5 per million requests and there is no other way to invoke lambda functions over HTTP. Had to scale back my micro-service ambitions because of this.

I use Lambda in production as a replacement for a cron server. So far, all it does is keep my cache warm. So far, no complaints. It was actually TJ Holowaychuk's blog posts on his use of Lambda that got me to give it a shot.