Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking serverless with FLAME

fly.io

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Rethinking serverless with FLAME

#101

Post by jrmiii »

chrismccord wrote: post #73
jrmiii wrote: post #67

Earlier quoted context omitted.

So, Chris, how do you envision the FLAME child understanding what OTP children it needs to start on boot, because this could be FLAME.call dependent if you have multiple types of calls as described above. Is there a way to pass along that data or for it to be pulled from the parent? Acknowledging this is brand new; just curious what your thinking is. EDIT: Would it go in the pool config, and a runner as a member of t…

Good question. The pools themselves in your app will be per usecase, and you can reference the named pool you are a part of inside the runner, ie by looking in system env passed as pool options. That said, we should probably just encode the pool name along with the other parent info in the `%FLAME.Parent{}` for easier lookup

Ah, that makes a lot of sense - I think the FLAME.Parent{} approach may enable backends that wouldn't be possible otherwise.

For example, if I used the heroku api to do the equivalent of ps:scale to boot up more nodes - those new nodes (dynos in heroku parlance) could see what kind of pool members they are. I don't think there is a way to do dyno specific env vars - they apply at the app level.

If anyone tries to do a Heroku backend before I do, an alternative might be to use distinct process types in the Procfile for each named pool and ps:scale those to 0 or more.

Also, might need something like Supabase's libcluster_postgres[1] to fully pull it off.

EDIT2: So the heroku backend would be a challenge. You'd maybe have to use something like the formation api[2] to spawn the pool, but even then you can't idle them down because Heroku will try to start them back. I.e. there's no `restart: false` from what I can tell from the docs or you could use the dyno api[3] with a timeout set up front (no idle awareness)

[1] https://github.com/supabase/libcluster_postgres

[2] https://devcenter.heroku.com/articles/platform-api-reference...

[3] https://devcenter.heroku.com/articles/platform-api-reference...

Re: Rethinking serverless with FLAME

#102

Post by jrmiii »

seabrookmx wrote: post #100

I'm firmly in the "I prefer explicit lambda functions for off-request work" camp, with the recognition that you need a lot of operational and organizational maturity to keep a fleet of functions maintainable. I get that isn't everyone's cup of tea or a good fit for every org. That said, I don't understand this bit: > Leaning on your worker queue purely for offloaded execution means writing all the glue code to get th…

Yeah, I think this was more inward focusing on things like `Oban` in elixir land.

He's made the distinction in the article that those tools are great when you need durability, but this gives you a lower ceremony way to make it Just Work™ when all you're after is passing off the work.

Re: Rethinking serverless with FLAME

#103

Post by jrmiii »

chrismccord wrote: post #76
imafish wrote: post #75

Having dealt with the pain and complexity of a 100+ lambda function app for the last 4 years, I must say this post definitely hits the spot wrt. the downsides of FaaS serverless architectures. When starting out, these downsides are not really that visible. On the contrary, there is a very clear upside, which is that everything is free when you have low usage, and you have little to no maintenance. It is only later, w…

I talk about FLAME outside elixir in one one of the sections in the blog. The tldr; is it's a generally applicable pattern for languages with a reasonable concurrency model. You likely won't get all the ergonomics that we get for free like functions with captured variable serialization, but you can probably get 90% of the way there in something like js, where you can move your modular execution to a new file rather t…

> functions with captured variable serialization

Can't wait for the deep dive on how that works

Re: Rethinking serverless with FLAME

#104

Post by jrmiii »

thefourthchime wrote: post #98

I created something similar at my work, which I call "Long Lamda", the idea is that what if a lambda could run more than 15 minutes? Then do everything in a Lambda. An advantage of our system as is you can also run everything locally and debug it. I didn't see that with the FLAME but maybe I missed it. We use it for our media supply chain which processes a few hundred videos daily using various systems. Most other te…

> you can also run everything locally and debug it. I didn't see that with the FLAME but maybe I missed it.

He mentioned this:

> With FLAME, your dev and test runners simply run on the local backend.

and this

> by default, FLAME ships with a LocalBackend

Re: Rethinking serverless with FLAME

#105

Post by stuartaxelowen »

chrismccord wrote: post #33
willsmith72 wrote: post #15

Pretty cool idea, and that api is awesome. > CPU bound work like video transcoding can quickly bring our entire service to a halt in production Couldn't you just autoscale your app based on cpu though?

Thanks! I try to address this thought in the opening. The issue with this approach is you are scaling at the wrong level of operation. You're scaling your entire app, ie webserver, in order to service specific hot operations. Instead what we want (and often reach for FaaS for) is granular elastic scale. The idea here is we can do this kind of granular scale for our existing app code rather that smashing the webserver…

If you autoscale based on CPU consumption, doesn’t the macro level scaling achieve the same thing? Is the worry scaling small scale services where marginal scaling is a higher multiple, e.g. waste from unused capacity?

Re: Rethinking serverless with FLAME

#106

Post by p10jkle »

imafish wrote: post #75

Having dealt with the pain and complexity of a 100+ lambda function app for the last 4 years, I must say this post definitely hits the spot wrt. the downsides of FaaS serverless architectures. When starting out, these downsides are not really that visible. On the contrary, there is a very clear upside, which is that everything is free when you have low usage, and you have little to no maintenance. It is only later, w…

I'm working on something that I think might solve the problem in any language (currently have an sdk for typescript, and java in the works). You can avoid splitting an application into 100s of small short-running chunks if you can write normal service-orientated code, where lambdas can call each other. But this isn't possible without paying for all that time waiting around. If the Lambdas can pause execution while they are blocked on IO, it solves the problem. So I think durable execution might be the answer!

I've been working on a blog post to show this off for the last couple of weeks:

https://restate.dev/blog/suspendable-functions-make-lambda-t...

Re: Rethinking serverless with FLAME

#107

Post by tlivolsi »

chrismccord wrote: post #13

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 :)

On an unrelated note, what syntax highlighting theme did you use for the code? I love it.

Re: Rethinking serverless with FLAME

#108

Post by antod »

hinkley wrote: post #81
imafish wrote: post #75

Having dealt with the pain and complexity of a 100+ lambda function app for the last 4 years, I must say this post definitely hits the spot wrt. the downsides of FaaS serverless architectures. When starting out, these downsides are not really that visible. On the contrary, there is a very clear upside, which is that everything is free when you have low usage, and you have little to no maintenance. It is only later, w…

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 at the time.

Rather than just painting the previous crowd as incompetent while simultaneously making worse decisions you'll never experience the consequences of.

Moving on every 18-24 months leaves you with a potentially false impression of your own skills/wisdom.

Re: Rethinking serverless with FLAME

#109

Post by katzgrau »

hinkley wrote: post #81
imafish wrote: post #75

Having dealt with the pain and complexity of a 100+ lambda function app for the last 4 years, I must say this post definitely hits the spot wrt. the downsides of FaaS serverless architectures. When starting out, these downsides are not really that visible. On the contrary, there is a very clear upside, which is that everything is free when you have low usage, and you have little to no maintenance. It is only later, w…

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…

And don’t forget that the developer fought like hell to use that new process, architecture, pattern, framework, etc

Re: Rethinking serverless with FLAME

#110

Post by josevalim »

seabrookmx wrote: post #100

I'm firmly in the "I prefer explicit lambda functions for off-request work" camp, with the recognition that you need a lot of operational and organizational maturity to keep a fleet of functions maintainable. I get that isn't everyone's cup of tea or a good fit for every org. That said, I don't understand this bit: > Leaning on your worker queue purely for offloaded execution means writing all the glue code to get th…

Wouldn’t you lose, for example, streaming capabilities once you use Celery? You would have to first upload the whole video, then enqueue the job, and then figure out a mechanism to send the thumbnails back to that client, while with FLAME you get a better user experience by streaming thumbnails as soon as the upload starts.

I believe the main point though is that background workers and FLAME are orthogonal concepts. You can use FLAME for autoscaling, you can use Celery for durability, and you could use Celery with FLAME to autoscale your background workers based on queue size. So being able to use these components individually will enable different patterns and use cases.

Post reply on HN