Years ago I was told that serverless would be cheaper than running your own servers. It seems like it’s not necessarily cheaper, but just a different way of designing a solution. Would you agree with that assessment? I have never used serverless. Every place I’ve worked needed tightly controlled data so on premises only.
Meanwhile I host my personal website on dirt cheap VPS.
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?
It’s cheaper if you don’t have constant load as you are only paying for resources you are actively using. Once you have constant load, you are paying a premium for flexibility you don’t need.
For example, I did a cost estimate of porting one of our high volume, high compute services to an event-driven, serverless architecture and it would be literally millions of dollars a month vs $10,000s a month rolling our own solution with EC2 or ECS instances.
Years ago I was told that serverless would be cheaper than running your own servers. It seems like it’s not necessarily cheaper, but just a different way of designing a solution. Would you agree with that assessment? I have never used serverless. Every place I’ve worked needed tightly controlled data so on premises only.
Meanwhile I host my personal website on dirt cheap VPS.
When you have 0 usage, serverless can be up to 100% cheaper than a VPS.
That difference propels its ROI into huge values, on business models that can scale up to sigle-digit dollars a month.
Meanwhile, the risk that you get a $100000 bill out of nowhere is always there.
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.
It’s cheaper if you don’t have constant load as you are only paying for resources you are actively using. Once you have constant load, you are paying a premium for flexibility you don’t need.
For example, I did a cost estimate of porting one of our high volume, high compute services to an event-driven, serverless architecture and it would be literally millions of dollars a month vs $10,000s a month rolling our own solution with EC2 or ECS instances.
The applications I’ve built weren’t designed for serverless deployment so I wouldn’t know. It seems like you pay a premium for the convenience though.