I'm curious if anyone has deployed a real app at any scale on Lambda/API Gateway. So far in my experience, the default limits and throughput are far lower than would be remotely useful for a moderately busy webapp. And to hit those rates would be outrageously expensive.
That may improve over time. But even more than that "serverless" is misleading. True, you don't have to personally manage the servers that are running your code, but that means that your operations team is actually inside Amazon. They have economies of scale, but that means they also don't always notice when one of their servers isn't performing up to par. More than once we've had to ask our support reps to get Lambda instances behind the scene restarted. At that point I start to wonder what the point is at all.
This is a problem even with EC2 unfortunately, maybe less so, and you can actually do something about it which is nice haha. At very least boot up a new node etc. There's definitely a certain amount of trust required for them to do a good job, but frankly having their team of developers on my side is great for a single person team, so far at least. I'll definitely write about any issues I have in prod.
I recently built a small service running on Lambda as part of a data pipeline. It doesn't get called very often, so it's well within the free tier. It's far from core functionality, and we wanted to just stick it somewhere where we wouldn't have to worry about it.
I would second what meddlepal said in a sibling comment about tooling and documentation. Everything is a little undercooked. I can see something like Apex being hugely useful here.
Given the current pricing it does seem hard to imagine large-scale systems running entirely on Lambda. But I imagine that will change.
I completely agree with TJ that we are headed for a new paradigm in server-side computing that looks a lot more like Lambda than Docker or Chef. We're racing towards a much higher level of abstraction. It's too early to tell if it will be an AWS product that emerges as the dominant platform for this new paradigm, or if a new player becomes dominant.
I just had a miserable experience trying to get a microservice written in Python running on Lambda. The tooling and documentation isn't there yet. It was so bad that I finally just did it over to deploy on two t2.micro instances with an ELB and auto scaling. Much easier deployment model that everyone understands.
The guys at http://acloud.guru are running their platform on Lambda/Firebase, and have given a few talks about how they've managed to achieve it. Disclaimer: I know a founder of theirs.
I'm pretty sure they have another post coming in the near future too.
I am impressed by how fast they built their platform given the size of their dev team. We (I'm a course author there, not developer) also use Lambda for custom slack bots too.
I would be thrilled if they provided an update, but Benchling's CRISPR search is what originally got me excited about Lambda. It's an incredibly compelling use case, as it enabled one second searches at any level of demand. And, their hosting costs dropped from thousands of dollars on EC2 to $60 on Lambda.
Yes, several production services including one serving an API and another a server side rendered JS app. API gateway + Lambda has some rough edges but the scalability has been great.
I'm deploying a new segmentation engine that runs on top of Lambda (input from Kinesis, output to SQS and Cassandra). There are definitely a few gotchas and rough edges but after the first invocation things are super fast. It's nice not having another set of boxes to manage. And our Lambda costs themselves come to a couple bucks a day, tops.
i'm working on MindMup, and we're moving almost all our APIs gradually to lambda and api gateway. we have two APIs running there in production at the moment. the benefit is being able to interact with the rest of the AWS stack easily (we use S3 to upload documents for exporting and heroku to process them at the moment, and dynamodb for storing user accounts and license information). ideally, at the end of the migration, we'll just kill all the heroku exporting and licensing services. should be cheaper as well, because we will be able to kick off lambda functions on s3 events instead of polling for s3 changes from heroku.
everything is versioned (so different api endpoints for staging, prod and development can talk to different versions of the lambda function), which is a big plus.
the api gateway stack is highly opinionated, as in it's good for JSON data parsed using Java on the back end (API gateway uses velocity). our strategy is to use it as a nodejs backend, so there was a lot of magic involved in the setup. it's not well documented and it discovering things like "$input.json('$') means entire body" is not easy. also we wanted to return errors as HTTP codes, not just in the JSON message body.
the setup initially was horrible and magic, but it's luckily automatable. I got it working well so that a single lambda function can receive calls from multiple api paths (so we can deploy an entire API at once, and manage dependencies simply), and that all the environment configuration is in the api gateway, not lambda (so a single function can be invoked with production/staging/development environment parameters).
it took me a while to figure out exactly how to pass things up and down the stack, and we ended up building something similar to apex (but significantly simpler due to a limited use case). a single command-line request packs up everything, uploads lambda, creates and configures the API gateway functions, manages versions and permissions, so it's relatively easy to create a new JS function tied to a URL in the API gateway now. It kind of looks like sinatra. we might end up opensourcing that if I get a chance to clean it up.
That may improve over time. But even more than that "serverless" is misleading. True, you don't have to personally manage the servers that are running your code, but that means that your operations team is actually inside Amazon. They have economies of scale, but that means they also don't always notice when one of their servers isn't performing up to par. More than once we've had to ask our support reps to get Lambda instances behind the scene restarted. At that point I start to wonder what the point is at all.