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

111–120 of 153 posts

Re: Rethinking serverless with FLAME

#111

Post by crabmusket »

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…

JS kind of has inter process built in with Web Workers and the channel messaging API- I wonder whether it'd be possible to essentially create a "FLAME Worker" with the same API as a web worker but backed by distributed execution!

Re: Rethinking serverless with FLAME

#112

Post by jvans »

antod wrote: post #108
hinkley wrote: 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…

> There's valuable learning (and empathy too) in having to see your own decisions and creations through their whole lifecycle.

This is so true. It's extremely enlightening to watch a design go from design docs to implementation and then finally the maintenance phase. A lot of problems that could happen never do and some unexpected ones pop up along the way.

Re: Rethinking serverless with FLAME

#114

Post by jedberg »

I’m a huge fan of Serverless. I’m also a huge fan of simplicity.

My advice to anyone starting out on a purely web adventure: run your monolith on lambda. Just upload your whole app as your lambda. Use dynamodb for storage.

When your app gets popular, then optimize. Make a separate lambda for the popular part. Spin up a relational database or maybe an auto scaling group.

But start with a monolith on lambda. Get all the benefits without the downsides.

Re: Rethinking serverless with FLAME

#115

Post by quaunaut »

jrmiii wrote: post #103
chrismccord wrote: post #76

Earlier quoted context omitted.

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

That's just standard erlang/elixir- because all values are immutable, when a new anonymous function is defined it copies the current value of the external variables into it.

You can do it right now even without Flame, just by opening two Elixir nodes, then it's as simple as

```elixir

iex(first_node@localhost)> name = "Santa"

iex(first_node@localhost)> Node.spawn_link(:other_node@localhost, fn -> IO.puts "Hello #{name}" end)

Hello Santa

#PID

```

Note that while the string interpolation and `IO.puts` was run on `other_node@localhost`, it still did stdout from the first node- this is because it was the one that called `Node.spawn_link`, making it the 'group leader'. Outside of which stdout it went to, all the work was done in the other node.

Re: Rethinking serverless with FLAME

#116

Post by azurelake »

jrmiii wrote: post #103
chrismccord wrote: post #76

Earlier quoted context omitted.

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

Probably not too much to say that’s specific to FLAME. Closures are serializable and can be sent as messages to actors on the BEAM with a few caveats.

From a quick look at the code, this looks the magic line: https://github.com/phoenixframework/flame/blob/main/lib/flam...

Re: Rethinking serverless with FLAME

#117

Post by Rapzid »

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…

You can monolith on lamba if you don't care too much about cold starts or can manage it..

Put another way, you can monolith and minimize spend on AWS; it's not either or.

I'm using asp.net these days and even a chunky app published ready to run with optimized ef models starts relatively quickly.

Re: Rethinking serverless with FLAME

#118

Post by quaunaut »

hinkley wrote: post #89

> Also thanks to Fly infrastructure, we can guarantee the FLAME runners are started in the same region as the parent. 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…

> 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 misunderstanding, but why would it go across the country when it's guaranteed to run from the same parent? Just deploy the app in the region you want, and now its Flame pools will be deployed in the same region.

If you want to switch the region it runs in, you can also easily just contact the other cluster to tell it to pick up the work.

Re: Rethinking serverless with FLAME

#119

Post by moduspol »

arianvanp wrote: post #87

One thing I'm not following how this would work with IAM etc. The power of Lambda to me is that it's also easy to deal with authorization to a whole bunch of AWS services. If I fire off a flame to a worker in a pool and it depends on say accessing DynamoDB, how do I make sure that that unit of work has the right IAM role to do what it needs to do? Similarly how does authorization/authentication/encryption work betwee…

I'm interested in following this project, but I'm also quite skeptical of how much is being abstracted here.

I still feel like Kubernetes might be the most profitable thing to ever happen to AWS for the same reason--and not because of EKS (their hosted Kubernetes control plane).

Re: Rethinking serverless with FLAME

#120

Post by imiric »

jedberg wrote: post #114

I’m a huge fan of Serverless. I’m also a huge fan of simplicity. My advice to anyone starting out on a purely web adventure: run your monolith on lambda. Just upload your whole app as your lambda. Use dynamodb for storage. When your app gets popular, then optimize. Make a separate lambda for the popular part. Spin up a relational database or maybe an auto scaling group. But start with a monolith on lambda. Get all th…

That advice sounds to be opposite of simple for someone starting out a new project. In addition to focusing on their core stack, they would also need to deal with Lambda details and its restrictions. How would they work around the 15 minute execution limit, for one?

My advice would be to start with a plain old monolith. Even launch with it. Once, and if, you have workloads that a) make sense to run as an isolated function, and b) would help offload some processing from your main app, consider splitting it and using a Lambda.

Doing so prematurely, or worse, starting with it, opens the door to complexity you just don't need early on.

Post reply on HN