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

71–80 of 153 posts

Re: Rethinking serverless with FLAME

#71

Post by jabradoodle »

bob1029 wrote: post #61
ryanjshaw wrote: post #24

Earlier quoted context omitted.

This looks great. Hopefully Microsoft are paying attention because Azure Functions are way too complicated to secure and deploy, and have weird assumptions about what kind of code you want to run.

> weird assumptions about what kind of code you want to run Those "weird assumptions" are what makes the experience wonderful for the happy path. If you use the C#/v4 model, I can't imagine you'd have a hard time. Azure even sets up the CI/CD for you automatically if your functions are hosted in Github. If your functions need to talk to SQL, you should be using Managed Identity authentication between these resources.…

A cloud vendor where using some of the most popular languages in the world makes your life harder is a genuine reason to dislike something.

Re: Rethinking serverless with FLAME

#73

Post by chrismccord »

jrmiii wrote: post #67
chrismccord wrote: post #64

Earlier quoted context omitted.

This is actually a feature. If you watch the screencast, I talk about Elixir supervision trees and how all Elixir programs carefully specify the order their services stop and stop in. So if your flame functions need DB access, you start your Ecto.Repo with a small or single DB connection pool. If not, you flip it off. > It's probably a non-issue, the number of things done at initialization could be kept minimal, and…

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

Re: Rethinking serverless with FLAME

#75

Post by imafish »

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, when you have built a hot mess of lambda workflows, which become more and more rigid due to interdependencies, that you wish you had just gone the monolith route and spent the few extra hundreds on something self-managed. (Or even less now, e.g. on fly.io)

A question for author: what if not using Elixir?

Re: Rethinking serverless with FLAME

#76

Post by chrismccord »

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 than wrapping it in a closure. Someone implementing a flame library will also need to write the pooling, monitoring, and remote communication bits. We get a lot for free in Elixir on the distributed messaging and monitoring side. The process placement stuff is also really only applicable to Elixir. Hope that helps!

Re: Rethinking serverless with FLAME

#77

Post by solatic »

chrismccord wrote: post #51
gitgud wrote: post #47

> It then finds or boots a new copy of our entire application and runs the function there. So for each “Flame.call” it begins a whole new app process and copies the execution context in? A very simple solution to scaling, but I’d imagine this would have some disadvantages… Adding 10ms to the app startup time, adds 10ms to every “Flame.call” part of the application too… same with memory I suppose I guess these concern…

The FLAME.Pool discussed later in the post addresses this. Runners are pooled and remain configurable hot for whatever time you want before idling down. Under load you are rarely paying the cold start time because the pool is already hot. We are also adding more sophisticated pool growth techniques to the Elixir library next so you also avoid hitting an at capacity runner and cold starting one. For hot runners, the o…

Cold start time is the issue with most serverless runtimes.

Your own mission statement states: "We want on-demand, granular elastic scale of specific parts of our app code." Doing that correctly is fundamentally a question of how long you need to wait for cold starts, because if you have a traffic spike, the spiked part of the traffic is simply not being served until the cold start period elapses. If you're running hot runners with no load, or if you have incoming load without runners (immediately) serving them, then you're not really delivering on your goal here. AWS EC2 has had autoscaling groups for more than a decade, and of course, a VM is essentially a more elaborate wrapper for any kind of application code you can write, and one with a longer cold-start time.

> Under load you are rarely paying the cold start time because the pool is already hot.

My spiky workloads beg to differ.

Re: Rethinking serverless with FLAME

#79

Post by ed »

isoprophlex wrote: post #74

Whoa, great idea, explained nicely! Elixir looks ridiculously powerful. How's the job market for Elixir -- could one expect to have a chance at making money writing Elixir?

Yep! Elixir is ridiculously powerful. Best place to look for work is the phoenix discord which has a pretty active job channel.

Re: Rethinking serverless with FLAME

#80

Post by chrismccord »

solardev wrote: post #78

Superficially, this sounds similar to how Google App Engine and Cloud Run already work ( https://cloud.google.com/appengine/migration-center/run/comp... ). Both are auto-scaling containers that can run a monolith inside. Is that a fair comparison?

They handle scaling at only highest level, similar to spinning up more dynos/workers/webservers like I talk about in the intro. FLAME is about elastically scaling individual hot operations of your app code. App Engine and such are about scaling at the level of your entire app/container. Splitting your operations into containers then breaks the monolith into microservice pieces and introduces all the downsides I talk about in the post. Also, while it's your code/language, you still need to interface with the mount of proprietary offerings to actual accomplish your needs.
Post reply on HN