The thing with serverless is you’re paying for iowait. In a regular server, like an EC2 or Fargate instance, when one thread is waiting for a reply from a disk or network operation the server can do something else. With serverless you only have one thread so you’re paying for this time even though it’s not actually using any CPU.
While you’re paying for that time you can bet that CPU thread is busy servicing some other customer and also charging them.
I like serverless for it’s general reliability, it’s one less thing to worry about, and it is cheap when you start out thanks to generous free tiers, at scale it’s a more complex answer as whether it is good value or not.
Therefore, would you agree that serverless is more about freeing up your mind as a developer and reducing your number of concerns where possible rather than necessarily cost savings or scaling?
In other words, is it less about better scaling and more about scaling isn’t your problem?
The thing with serverless is you’re paying for iowait. In a regular server, like an EC2 or Fargate instance, when one thread is waiting for a reply from a disk or network operation the server can do something else. With serverless you only have one thread so you’re paying for this time even though it’s not actually using any CPU.
While you’re paying for that time you can bet that CPU thread is busy servicing some other customer and also charging them.
I like serverless for it’s general reliability, it’s one less thing to worry about, and it is cheap when you start out thanks to generous free tiers, at scale it’s a more complex answer as whether it is good value or not.
Therefore, would you agree that serverless is more about freeing up your mind as a developer and reducing your number of concerns where possible rather than necessarily cost savings or scaling?
In other words, is it less about better scaling and more about scaling isn’t your problem?
I mean, does writing in Python rather than C free up your mind? It’s just another abstraction tradeoff.