Hacker News Reader

Comment by PopeDotNinja | Hacker News Reader

I haven't played w/ Lambda, or serverless, much yet. I've always imagined it being used for quick & dirty functions that too trivial to warrant a full blown application. Is there a compelling case for deploying a full-blown Rails app in a lambda, especially when something when deploying a Rails app in a container on ECS is fairly straight forward? That sounds like a lot of code for something that sounds a lot like a simpler function call.

View on HN

The biggest benefit to me has been about flexibility and the shift to a more event-driven way of writing and scaling apps. Which together seem to evolve into a more functional programming like approach to services communicating.

Write a function and deploy it. Want that function exposed via an API? Easy. Want it to be fired in response to an object being uploaded to S3? You can do that too. All it’s concerned with is inputs and outputs. How you compose them is up to you. And if the there’s zero need for a function to be running it’s not running, you’d don’t have ECS containers sitting around idle waiting for work.

The trade off atm is visibility into how & where exactly a given function is being used within a codebase(s).

It's all about scalability. With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can scale from minimal to maximal without any intervention whatsoever, and only for the hot parts of your code. Deployment is even more refined than with containers.

I sincerely hope to get to work with this stuff soon; no use case for me at present.

With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user.

You can do that with containers and VMs too. Potentially with fewer worries about cold start latency (at least with Lambda).

Fargate is an interesting sort of middle ground.

Reply on news.ycombinator.com