3 ms·

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your server * Scaling an app globally. * Coping with outages in a data-centre/availability * Worry about load-balancing & scaling infrastructure

deleted 9y ago
[deleted]
tyingq 9y ago
Except for max run time limitations and recurring long startup times, sure. No free lunch.
twic 9y ago
This is exactly what PaaS's like Heroku have been doing for years, right? Isn't Lambda just an even more locked-in PaaS?
- viraptor 9y ago
  Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.
  - gitgud 9y ago
    You can redeploy a Heroku app to many other servers and platforms relatively easily. However, I'm not sure you can do the same with AWS Lamda Functions. To mean, this means it is like a lock-in.
    - viraptor 9y ago
      It's just code with basic function entry point. You may get your parameters and configuration in a different way, but not much else changes. There are only so many ways to call some code.
methodin 9y ago
And a huge plus - not having to pay if nothing is using it (generally).
- blowski 9y ago
  The downside being that you pay a lot more if it gets used a lot.
  - alpha_squared 9y ago
    Which is probably when you need to re-architect, anyway. There are also several optimizations that can be made along the way to reduce costs. I think there are plenty of ways to think of problems from a serverless standpoint that really don't need to go the traditional server route. I also think there are plenty of use cases where serverless may very well be a problem, that's okay.

deleted 9y ago

[deleted]

tyingq 9y ago

Except for max run time limitations and recurring long startup times, sure. No free lunch.

twic 9y ago

This is exactly what PaaS's like Heroku have been doing for years, right? Isn't Lambda just an even more locked-in PaaS?

viraptor 9y ago
Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.
- gitgud 9y ago
  You can redeploy a Heroku app to many other servers and platforms relatively easily. However, I'm not sure you can do the same with AWS Lamda Functions. To mean, this means it is like a lock-in.
  - viraptor 9y ago
    It's just code with basic function entry point. You may get your parameters and configuration in a different way, but not much else changes. There are only so many ways to call some code.

methodin 9y ago

And a huge plus - not having to pay if nothing is using it (generally).

blowski 9y ago
The downside being that you pay a lot more if it gets used a lot.
- alpha_squared 9y ago
  Which is probably when you need to re-architect, anyway. There are also several optimizations that can be made along the way to reduce costs. I think there are plenty of ways to think of problems from a serverless standpoint that really don't need to go the traditional server route. I also think there are plenty of use cases where serverless may very well be a problem, that's okay.