✳flâneur — a map of the web's best reading

Rethinking Serverless with FLAME · The Fly Blog

fly.io · 3,794 words · saved by 1 readers

Serverless/FaaS had a couple things going for it. Elastic Scale™ is hard. It’s even harder when you need to manage those pesky servers. It also promised pay-what-you-use costs to avoid idle usage. Good stuff, right? Well the charade is over. You offload scaling concerns and the complexities of scaling, just to end up needing more complexity. Additional queues, storage, and glue code to communicate back to our app is just the starting point. Dev, test, and CI complexity balloons as fast as your costs. Oh, and you often have to rewrite your app in proprietary JavaScript – even if it’s already written in JavaScript! At the same time, the rest of us have elastically scaled by starting more webservers. Or we’ve dumped on complexity with microservices. This doesn’t make sense. Piling on more webservers to transcode more videos or serve up more ML tasks isn’t what we want. And granular scale shouldn’t require slicing our apps into bespoke operational units with their own APIs and deployments

Author Name Chris McCord @chris_mccord @chris_mccord Imagine if you could auto scale simply by wrapping any existing app code in a function and have that block of code run in a temporary copy of your app. The pursuit of elastic, auto-scaling applications has taken us to silly places. Serverless/FaaS had a couple things going for it. Elastic Scale™ is hard. It's even harder when you need to manage those pesky servers. It also promised pay-what-you-use costs to avoid idle usage. Good stuff, right? Well the charade is over. You offload scaling concerns and the complexities of scaling, just to end

Explore this link on the map →

related reading