I'll give you one where it benefits us, in the real world, where it's -not- just horizontal scalability. Almost all of my team's efforts are internal applicati

I'll give you one where it benefits us, in the real world, where it's -not- just horizontal scalability. Almost all of my team's efforts are internal applications. They're high throughput ad related functionalities, but fundamentally another business client says "hey, we have a user, we need an ad", and all our stuff works to fill it. We are, as such, on an internal VPC in AWS. This is fine. But we sometimes need to allow for client code run outside of the network to be able to securely change out our stuff; think ad partners modifying their inventory. We can add an API on top of one of our services, but then we have to deal with authentication and proxying. We can certainly authenticate and proxy those requests into the network ourselves. But that creates some fun and interesting risks and issues; we're building something explicitly to bypass the safeguards of running in a private subnet in our own VPC, and tunnel traffic from the big wide world into the depths of our own network (which is also connected to our corporate network). We can also spin up a new service on a server that lives outside the VPC; however that has the downside that we're paying for an instance for a very low traffic service, and it still requires support. Or, we use a Serverless paradigm. The website hits API Gateway/lambda endpoints, authentication is provided via Cognito, and it all leads to the lambda executing against a single resource (S3, Dynamo, whatever) to modify data that our services read from. No entering our network, and all security relying on security primitives Amazon owns and maintains (they are far better equipped to handle it than we are). And it will cost us pennies, while leaving our existing infrastructure unaffected.