3 ms·

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) I've created a whole photo shar

>(I am strongly convinced lambda should be used as a glue to automate AWS infrastructure and any other uses is just abusing it) I've created a whole photo sharing website in AWS Lambda, including a complete user accounts system (register, login, forgot password, email verification, profile photos, etc), social aspects, as well as other things like youtube video search and transcoding in the same system. I also had to create my own Lambda build system because what was out there wasn't what I wanted. I wanted to be able to hit save on a file and have it repackage my Lambda on AWS (using a Lambda to create the lambda) including shared code in 'Layers'. Kind of a "live-reload" for Lambda. It's all working very efficiently. This was a lot of effort though, but now that I've got a basic system I can extend it to any kind of website. My photo sharing site for friends costs me about $0.25 every few months, and that is mostly/all the cost of storing gigabytes of photos on S3. No, it doesn't see a lot of traffic, and that's exactly why I chose Lambda to build this site on, because I don't have to run an EC2 instance for my photo sharing site 24/7 if nobody is using it. It's worked out exactly how I wanted, costs me practically nothing to run every year. And, if I did build a system with a ton of active users, Lambda handles the scaling of that. Another reason I spent the time to create this build system and write all the code to handle user accounts, etc.

rrdharan 6y ago
> And, if I did build a system with a ton of active users, Lambda handles the scaling of that. This is a bold claim to make without verifying it. > Another reason I spent the time to create this build system and write all the code to handle user accounts, etc. But did you also spend the additional time to scale test it and verify it won’t break in confusing and annoying ways when scaling / spiking up? (see the other discussions re: connection pooling above). The reason a lot of folks are skeptical is that in practice there don’t seem to be a lot of great examples of stateful services using a “pure” serverless lambda pattern but with arbitrary dependencies that actually do scale smoothly and don’t break in annoying ways such that you end up building something more complicated than just using App Engine or Heroku...
- dolni 6y ago
  > > And, if I did build a system with a ton of active users, Lambda handles the scaling of that. > This is a bold claim to make without verifying it. I mean, Lambda's ability to scale is a well documented thing. It will happily do more if you ask it to. The real scaling problem is your wallet, because Lambda is damn expensive once you have any somewhat serious compute requirements.

rrdharan 6y ago

> And, if I did build a system with a ton of active users, Lambda handles the scaling of that. This is a bold claim to make without verifying it. > Another reason I spent the time to create this build system and write all the code to handle user accounts, etc. But did you also spend the additional time to scale test it and verify it won’t break in confusing and annoying ways when scaling / spiking up? (see the other discussions re: connection pooling above). The reason a lot of folks are skeptical is that in practice there don’t seem to be a lot of great examples of stateful services using a “pure” serverless lambda pattern but with arbitrary dependencies that actually do scale smoothly and don’t break in annoying ways such that you end up building something more complicated than just using App Engine or Heroku...

dolni 6y ago
> > And, if I did build a system with a ton of active users, Lambda handles the scaling of that. > This is a bold claim to make without verifying it. I mean, Lambda's ability to scale is a well documented thing. It will happily do more if you ask it to. The real scaling problem is your wallet, because Lambda is damn expensive once you have any somewhat serious compute requirements.