Live data from Hacker News

Rethinking serverless with FLAME

fly.io

151–153 of 153 posts

Re: Rethinking serverless with FLAME

#151

Earlier quoted context omitted.

> If customers think this is a feature and not a bug, then I have a very different understanding about what serverless/FaaS is meant to be used for. My division is pretty much only looking at edge networking scenarios. Can I redirect you to a CDN asset in Boston instead of going clear across the country to us-west-1? We would definitely NOT run Lamba out of us-west-1 for this work. I'm not sure how you're misundersta…

> just Every solution is easy when you oversimplify the problem. None of what you said is true if you care about persistent state in the app. Local reads and distant writes are how you avoid speed of light problems.

Yes, I understand, I do distributed systems for a living, after all. But if you keep adding stipulations without actually describing the problem you're not actually looking for an answer, you're looking to be contrarian.

Re: Rethinking serverless with FLAME

#152

Author here. I’m excited to get this out and happy to answer any questions. Hopefully I sufficiently nerd sniped some folks to implement the FLAME pattern in js , go, and other langs :)

How is this fundamentally different from how something like Sidekiq instantiates a Rails codebase to run background jobs?

Re: Rethinking serverless with FLAME

#153
post #108
post #81

Earlier quoted context omitted.

A pattern I see over and over, which has graduated to somewhere between a theorem and a law, is that motivated developers can make just about any process or architecture work for about 18 months. By the time things get bad, it's almost time to find a new job, especially if the process was something you introduced a year or more into your tenure and are now regretting. I've seen it with a handful of bad bosses, at lea…

That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years. There's valuable learning (and empathy too) in having to see your own decisions and creations through their whole lifecycle. Understanding how tech debt comes to be, what tradeoffs were involved and how they came to bite later. Which ideas turned out to be bad in hindsight through the lens of the people making them…

I am in a long-term-career place and it has its challenges (mostly no leverage on pay...) but the level of knowledge and expertise and proficiency of most people is astounding, allowing to do a whole lot with very little people, and to build on knowledge, experience and yes, lots of code and tooling too. Most everything you're thinking about in the domain, has been done at least twice, and you can pick people's brains on the most obscure but important topics and get a pretty good idea on the actual challenges.

It can get hard to separate ideas from execution, to 'forget' about the pain of a horrible technical move that still managed to be a commercially success, or to forget the pain of a badly-timed big decision that exploded in your face.

Post reply on HN