With regard to some of those downside, there's definitely a theme in some circles of "lets just take this traditional app and write it in lambda". 15 minute ru

With regard to some of those downside, there's definitely a theme in some circles of "lets just take this traditional app and write it in lambda". 15 minute runtime execution is a limitation, but you could equally write "memory per request is measured in gigabytes" for a traditional server setup. Similarly, you are limited by network bandwidth, but you could equally say that you're limited by SSD bandwidth on a traditional server; serverless makes it easier to fan-out and capitalize on the aggregate network bandwidth between ten functions, whereas doing the same between ten VMs requires... ten VMs. What are the real problems we've run into? - Latency. Bandwidth has never been an issue. Latency is, which includes cold start time but also includes network roundtrips and things like being unable to pool DB connections. - Intermediate services. The article mentions this one, and they suck. "Just put API Gateway in front of it" when all you want is a dumb proxy with SSL makes a nimble little lambda function feel like a lumbering behemoth. SSL demands CloudFront to function, which has a whole new class of behavior you need to learn, and is SO UNBELIEVABLY SLOW to provision and update. Then adding additional behavior like API Keys or DNS all happens outside the function, so instead of managing a single little service you have to manage a single little function + four-to-ten more AWS resources. - Tooling. There's no shortage of it, but IMO the ideal tooling setup for a lambda function is one which feels as light as the lambda itself. Serverless (the framework) isn't that. Its crazy complex. Apex is the closest I've seen a toolchain get, and its pretty great, but might actually be too simple. The CDK shows promise, but also feels too complex. I think the problem here is truly that AWS is just too complex, and there's no way to abstract that complexity in a way that works for the 99% use-case. - Configuration. The big thing I don't get in this category is why can't I map lambda environment variables to values in the Secrets Manager. In order to deploy any environment variable to a lambda, the deployment environment needs access to the value of that variable, which is a security NIGHTMARE. We've instead resorted to loading sensitive configuration at function start, which sucks for performance and cost but security comes first. (We're specifically storing configuration in DynamoDB w/ encryption at rest) Overall, I think the serverless model is really great. But doing it on AWS sucks so so bad, and I don't see a future where it gets better. There's just so much unnecessary complexity on AWS that I'd rather were abstracted away. If I were designing a serverless architecture from scratch, I'd probably opt to build it on Kubernetes with something like knative. But that could have its own host of issues I'm unfamiliar with.