I've been working on a mostly serverless application for about 8 months now, and at this point I'm tired of hearing about "no more servers or containers to manage." I honestly miss containers at this point. It seems like its going to be a lot more simple and easier to maintain, but my experience has been that you are just trading one set of complexities for another.
I just started learning elixir last week, because I couldn’t believe the amount of work required to have scaling background jobs etc in JS land. And Im baffled at how many problems just don’t exist in the space - or are solved WAY more elegantly. FLAME is like the icing on this delicious cake.
i am using Gleam which is bassically elixir if it had a little bit of rust syntax and had a geat type system gleam compiles to Erlang so you get the same powers of otp here too
tried elixir after the Jose interview and it seemed super tough, The pattern matching is a new concept to me but the potential seemed limitless. Props to elixir devs
7:28 thats a fair take, its also what makes elixir and erlang world so great because you could have a machine running some elixir or erlang code to maintain and give database connections from a pool and as long as your lambda is running on the same network or cluster, you don't need to worry about it that much
@@kp8752 yeah indeed that whole concern is basically meaningless - ecto is already solving pooling, and since FLAME just lives in an already - allegedly - well written application...
I do think it's very cool, but on the other hand it only really matters when you app is already at a big scale. I'm happy with my nextjs docker container spun in google cloud run.
I have only one problem with all of these solutions. They do not provide localized price for devs from Bangladesh or nearby countries. How am I supposed to pay 25$ a month when I made only 200$ for entire project.
My take is that this couples an abstracted version of infra with your code. That might be acceptable in some scenarios but not most. In any case if your app is not used by hundreds of millions of users, you'll get far with a monolith, so most people don't need to solve this problem anyway.
I don't think this goes against the monolith pattern. Its more about when you have long-running/compute heavy tasks that you want to run as part of your monolith - even small/hobby apps will need to handle these types of workloads. To solve that you often have to add some type of message-broker + software to process workloads, handle enqueuing of tasks as-well-as taking care of the results as they come back to your monolith. The blog post uses lambda + API Gateway + SQS consumer + processor as an example of one pattern used to solve this, but every language/runtime has their own popular solution to this problem too - they all involve extra overhead in terms of tooling and setup.
Elixir/Erlang indeed is much different than any language in the sense it offers the tools to manage infra in your code (you can literally create queues, key/value memory storages etc) However often you don't need to worry about them, if you want, you can just run all your code using simple primitives of the language and literally create a monolith (And with good DX), but in the case you need scale you have all the tools that the language offers to you (which is why Elixir is so good for scaling apps) Also, application code and infra are not necessarily separate things, often we need to scale one part of the app due to business requirements, Elixir offers a easy way to that using code
If the Lambda 15-minute timeout is too limiting for a use case, consider using Fargate as a scale-to-zero, serverless option for longer running tasks. It's billed for a minimum one minute and per-second granularity versus Lambda's millisecond billing, so you may not want to use it for
Seems to have a bit of similarity to how Apache Spark was conceived, but for javascript... I think that part is actually really interesting... I've done a lot of stuff with spark, and having good bindings for something like that but with the Javascript runtime would be interesting. Not sure those CPU bound use cases are a really good fit for the JS runtime though?
I don't think you'd use this for an API, you'd use this for when you need to process something and the server load for it is spiky or unpredictable. But honestly, it's great.
So you integrate this magic and then 5 years down the line when they decide to hike prices or change the api you have major problems. Yeah idk I think I will just spin up a new docker container on any provider of my choice instead if I need more processing power and invest a bit more engineering effort upfront
I've been looking at elixir the last week and funnily FLAME is kinda one of the least impressive things. I'm not saying it's bad - it's great - but putting it into perspective people have been using Celery with Python for years. I'd argue that FLAME is better than Celery in a few ways (transparency of file handles/streams for one), but the ease and core value proposition is quite similar. The big thing here is escaping AWS Lambda brain.
Akka is just a "poor man's Erlang." That is, it's an adaptation of Erlang's actor model for Java. Elixir is built on top of BEAM itself (the Erlang runtime), so the actor pattern is built into the core of the language.
if its creating a copy of the app to run the generate_thumbnail function, why couldnt they just auto scale and load balance the original app to begin with? Seems like cart before horse.
Im having problem in t3-stsck im using app router version yesterday it work fine but now it giving : Error querying the database: FATAL: remaining connection slots are reserved for non-replication superuser connections But i set max connections to 300 what i do?
You probably have a leak for your DB connections _somewhere_. Look for places where you're retrieving connections from the pool and then not releasing them.
Im confused, so in the javascript general flow, it says, extract the elastic function into its own file, and provided the arguments are json serializable, it will work. But, how is that different than extracting the functions and making a microservice?
It's talking about potential work that needs to be done and one idea for a solution to do an implementation in javascript land, but the library only exists in elixir as of now.
But the implementation they are describing in javascript sounds the same architecturally as a microservice, not sure what flame would buy over microservice in JavaScript in that case. For elixr it makes sense because it can have multiple instances of the app running and remotely run individual methods within the running application.
What happened to just using a single server? I meant servers now can have terbytes of RAM, and hundreds of cores. That's not enough for your apps ? are you google? using serverless or FLAME or whatever scale solution just adds overhead making your server inneficient resulting in the need for more servers & scale, it is a self fullfilling prophecry. Maybe stop using javascript on the server & that will solve all your scaling issues.
Pretty much will never happen, unless Go creates some mechanism to have strict, zero-shared-state, immutable version of a goroutine. Erlang/Elixir are functional languages that have no mutable state, full stop, so message-passing concurrency across machines is just a higher-latency version of same-machine concurrency; you never have to worry about mutexes or anything. There might be a way to implement this in Rust, but it wouldn't be a one-line code change like FLAME here.
In the future we will look at the serverless obsession in the same way we know look at the kubernetees / microservices obsession. A great solution for someone's problem, that got pushed to everyone.
I've been working on a mostly serverless application for about 8 months now, and at this point I'm tired of hearing about "no more servers or containers to manage." I honestly miss containers at this point. It seems like its going to be a lot more simple and easier to maintain, but my experience has been that you are just trading one set of complexities for another.
I just started learning elixir last week, because I couldn’t believe the amount of work required to have scaling background jobs etc in JS land. And Im baffled at how many problems just don’t exist in the space - or are solved WAY more elegantly. FLAME is like the icing on this delicious cake.
i am using Gleam which is bassically elixir if it had a little bit of rust syntax and had a geat type system
gleam compiles to Erlang so you get the same powers of otp here too
tried elixir after the Jose interview and it seemed super tough, The pattern matching is a new concept to me but the potential seemed limitless. Props to elixir devs
7:28 thats a fair take, its also what makes elixir and erlang world so great because you could have a machine running some elixir or erlang code to maintain and give database connections from a pool and as long as your lambda is running on the same network or cluster, you don't need to worry about it that much
Yeah I’m pretty sure ecto already handles his complaints
ecto is dope
@@kp8752 yeah indeed that whole concern is basically meaningless - ecto is already solving pooling, and since FLAME just lives in an already - allegedly - well written application...
I'm very excited about this, this makes me think about several ideas to build along with axon
I do think it's very cool, but on the other hand it only really matters when you app is already at a big scale. I'm happy with my nextjs docker container spun in google cloud run.
I have only one problem with all of these solutions. They do not provide localized price for devs from Bangladesh or nearby countries. How am I supposed to pay 25$ a month when I made only 200$ for entire project.
found your twitter first and thought it sucked pretty bad, then found your channel and you know what, i think it got me turned around
My take is that this couples an abstracted version of infra with your code. That might be acceptable in some scenarios but not most. In any case if your app is not used by hundreds of millions of users, you'll get far with a monolith, so most people don't need to solve this problem anyway.
I don't think this goes against the monolith pattern. Its more about when you have long-running/compute heavy tasks that you want to run as part of your monolith - even small/hobby apps will need to handle these types of workloads. To solve that you often have to add some type of message-broker + software to process workloads, handle enqueuing of tasks as-well-as taking care of the results as they come back to your monolith. The blog post uses lambda + API Gateway + SQS consumer + processor as an example of one pattern used to solve this, but every language/runtime has their own popular solution to this problem too - they all involve extra overhead in terms of tooling and setup.
Elixir/Erlang indeed is much different than any language in the sense it offers the tools to manage infra in your code (you can literally create queues, key/value memory storages etc)
However often you don't need to worry about them, if you want, you can just run all your code using simple primitives of the language and literally create a monolith (And with good DX), but in the case you need scale you have all the tools that the language offers to you (which is why Elixir is so good for scaling apps)
Also, application code and infra are not necessarily separate things, often we need to scale one part of the app due to business requirements, Elixir offers a easy way to that using code
Straight fire 🔥 theo
Everyone considering this has to remember one point: this is beta / 1.0.
Let's keep watching this space, but it really is interesting.
If the Lambda 15-minute timeout is too limiting for a use case, consider using Fargate as a scale-to-zero, serverless option for longer running tasks. It's billed for a minimum one minute and per-second granularity versus Lambda's millisecond billing, so you may not want to use it for
The best solution i've seen as a complement to serverless functions that simplifies infrastructure is temporal.
Dark mode please
You can use an ECS Task for the chunky tasks
Seems to have a bit of similarity to how Apache Spark was conceived, but for javascript... I think that part is actually really interesting... I've done a lot of stuff with spark, and having good bindings for something like that but with the Javascript runtime would be interesting. Not sure those CPU bound use cases are a really good fit for the JS runtime though?
Flame isn’t for JavaScript. Its scaling function calls on the Elixir backend.
I don't think you'd use this for an API, you'd use this for when you need to process something and the server load for it is spiky or unpredictable. But honestly, it's great.
So you integrate this magic and then 5 years down the line when they decide to hike prices or change the api you have major problems. Yeah idk I think I will just spin up a new docker container on any provider of my choice instead if I need more processing power and invest a bit more engineering effort upfront
100%
i wish he said something about azure durable functions.
Flame runner.. mmmmMk we will see. Sounds funky. Hope we don't make donkeys of ourselves
Windmill is another interesting new tool you should check out.
how about using kafka as a queue system with upstash?
I've been looking at elixir the last week and funnily FLAME is kinda one of the least impressive things. I'm not saying it's bad - it's great - but putting it into perspective people have been using Celery with Python for years.
I'd argue that FLAME is better than Celery in a few ways (transparency of file handles/streams for one), but the ease and core value proposition is quite similar.
The big thing here is escaping AWS Lambda brain.
Reminds me quite a bit of the akka actor pattern 😅 everything old is new again
Akka is just a "poor man's Erlang." That is, it's an adaptation of Erlang's actor model for Java. Elixir is built on top of BEAM itself (the Erlang runtime), so the actor pattern is built into the core of the language.
if its creating a copy of the app to run the generate_thumbnail function, why couldnt they just auto scale and load balance the original app to begin with? Seems like cart before horse.
Yes! Flavorful apps!
FINE... i'll like and subscribe 😇
FLAME seems pretty cool, I'm excited to look at it a bit more
What's the difference between FLAME and just... forking a process?
Im having problem in t3-stsck im using app router version yesterday it work fine but now it giving : Error querying the database: FATAL: remaining connection slots are reserved for non-replication superuser connections
But i set max connections to 300 what i do?
You probably have a leak for your DB connections _somewhere_. Look for places where you're retrieving connections from the pool and then not releasing them.
@@radiozradioz2419 this problem in my prod database in local database it work fine
Hi
js community: "we're not going to do dumb stuff anymore."
...
js community: **does more dumb stuff**
Elixir is the way!
Say hi from Chile,
Im confused, so in the javascript general flow, it says, extract the elastic function into its own file, and provided the arguments are json serializable, it will work. But, how is that different than extracting the functions and making a microservice?
It's talking about potential work that needs to be done and one idea for a solution to do an implementation in javascript land, but the library only exists in elixir as of now.
But the implementation they are describing in javascript sounds the same architecturally as a microservice, not sure what flame would buy over microservice in JavaScript in that case.
For elixr it makes sense because it can have multiple instances of the app running and remotely run individual methods within the running application.
@@nightshade427 Yeah pretty sure the javascript version just wouldn't have the same benefits as the elixir version, unless it is compiled.
What happened to just using a single server? I meant servers now can have terbytes of RAM, and hundreds of cores. That's not enough for your apps ? are you google? using serverless or FLAME or whatever scale solution just adds overhead making your server inneficient resulting in the need for more servers & scale, it is a self fullfilling prophecry. Maybe stop using javascript on the server & that will solve all your scaling issues.
Doesn't Julia do that?
I'll wait until they have something in Python/Go
Pretty much will never happen, unless Go creates some mechanism to have strict, zero-shared-state, immutable version of a goroutine. Erlang/Elixir are functional languages that have no mutable state, full stop, so message-passing concurrency across machines is just a higher-latency version of same-machine concurrency; you never have to worry about mutexes or anything. There might be a way to implement this in Rust, but it wouldn't be a one-line code change like FLAME here.
I'd bet money that this'll be dead in 5 years. Stick with traditional infrastructure.
I put a reminder in my calender for december 2028
Meanwhile you can stick to angular
In the future we will look at the serverless obsession in the same way we know look at the kubernetees / microservices obsession. A great solution for someone's problem, that got pushed to everyone.