11–20 of 137 posts
The YAML config, IAM permissions, generating requests and responses, it's all so painful to get anything done.
Admittedly I speak as a software engineer primarily building CRUD apps, where frameworks have had decades of development. I can see use cases for event-driven applications where serverless may make life easier. But for CRUD, currently no chance.
First most companies thought they needed to do containers before serverless, and frankly it took them a while to get good at that.
Second the programming model was crap. It's really hard to debug across a bunch of function calls that are completely seperate apps. It's just a lot of work, and it made you want to go monolith and containers.
Third, the spin up time was a deal killer in that most people would not let that go, and wanted something always running so there was no latency. Sure workload exist that do not require that, but they are niche, and serverless stayed niche.
How about cost at scale? Amazon itself shifted Prime Video from serverless to mostly containers and it resulted in huge savings.
Without a link and a breakdown that makes no sense. We switched from blue to square and saw a honey suckle savings. Amazon runs both and serverless is a billing model. Many serverless runtimes consume containers. Serverless, like microservices are a design philosophy.
> Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
> The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.
Because most applications have 27 active users per day and a $10/month VPS can handle 100000.
Separately, when you factor in data privacy, your decision making tree will certainly change quickly.
Every time I try to solve a problem with anything other than Rails, I run into endless issues and headaches that would have been already solved if I just. used. Rails.