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

Ruby on Jets: Like Rails but serverless

github.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Ruby on Jets: Like Rails but serverless

#71

Post by capableweb »

cultofmetatron wrote: post #68

maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for…

Couldn't you just disable the garbage collector in those languages? I know you can select a "none" GC in the JVM, you should be able to do the same with other runtimes too.

Re: Ruby on Jets: Like Rails but serverless

#72

Post by mdaniel »

capableweb wrote: post #70
mdaniel wrote: post #69

I wonder if this would help Mastodon (the project, not the generic term) since I thought the recent Twitter flight caused them scaling woes, but I don't know enough of the details to readily know if one lambda per route would help them or not

It'll certainly help AWS to get a lot more profit :) Mastodon is not a single service, but open source software groups/individuals/organisations run. So it's not really accurate to say Mastodon itself had issues with the huge influx of users, but rather some popular instances of Mastodon had issues. Mastodon is supposed to be more decentralized (federated being the way of achieving that) than currently existing socia…

> Mastodon is not a single service, but open source software groups/individuals/organisations run

Yes, as I tried to specify by qualifying "the project, not the noun" but I was on my phone so linking to github.com/mastodon/mastodon was more trouble than I thought necessary. Evidently not

> So it's not really accurate to say Mastodon itself had issues with the huge influx of users, but rather some popular instances of Mastodon had issues.

Understood, and the rails server running on some person's droplet is one trending link away from becoming a "popular instance." I believe Kris Nova's situation fell into that category. I'm not saying the mastodon/mastodon should change their deployment model to require Jets, but if Jets is mostly compatible with Rails, and mastodon/mastodon could write their Rails in a way that allows either deployment model, that seems like a win

Re: Ruby on Jets: Like Rails but serverless

#73

Post by emptysea »

capableweb wrote: post #71
cultofmetatron wrote: post #68

maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for…

Couldn't you just disable the garbage collector in those languages? I know you can select a "none" GC in the JVM, you should be able to do the same with other runtimes too.

Yeah Instagram has some blog posts outlining how they run their python web servers with the GC disabled

Easy enough to restart the processes every once in a while

Re: Ruby on Jets: Like Rails but serverless

#74

Post by travisgriggs »

revskill wrote: post #32
travisgriggs wrote: post #20

Ruby syntax with a focus on fine grained transforming functions. Isn’t that essentially exactly what Elixir/Phoenix tries to provide, but without the Amazon lock-in or price tag?

Because Ruby is OOP, Elixir is functional. Some people just get used to OOP to structure program.

Fair enough. But I did twenty years as a Smalltalk developer, including 6 years being tools/gui lead at one of the commercial vendors.

I’ve played with Ruby, but not enough to get invested. It wasn’t OOP at the level I was used to.

I do Elixir, and it’s the first time I’ve had those “this is so elementarily cool” feelings since my 10 year hiatus from Smalltalk. The thing I like least about Elixir is it’s use ruby-esque do/end and it’s quasi inclusion of new lines as a sometimes relevant syntactic element.

Re: Ruby on Jets: Like Rails but serverless

#75

Post by meekins »

cultofmetatron wrote: post #68

maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for…

Serverless runtimes don't shut down the instance immediately after the invocation is complete but keep it up for an undetermined time depending on many factors (usually ~15 minutes) in order to process a possible new event without the start-up overhead (cold start). This means that in a system with constant traffic some instances may have a surprisingly long uptime. The instance gets destroyed when it throws an error though so a function with a disabled GC would clean the state when it runs out of memory. Slower processing done by memory-starved instances would probably eliminate any minimal performance gain you could get by disabling the GC though. (EDIT: I just realized that with no GC desperately spinning in place the starvation would not have much performance impact so this would actually be a very interesting approach if you can tolerate some invocations erroring out on out of memory errors, sorry!)

In regards to performance optimization of Lambdas, start-up time is the most important factor as cold starts happen also in cases of concurrent requests when no warm instances are available. This means that Go, Node and Python are pretty sweet for serverless. Thanks to recently released Lambda SnapStart feature that launches new instances from snapshots taken after application initialization Java (even with DI frameworks) is a plausible option if you're inclined that way. Previously you had to use a custom runtime and AOT compilation (that rules out any runtime DI stuff) to achieve tolerable performance with Java on Lambda.

Re: Ruby on Jets: Like Rails but serverless

#76

Post by 6figurelenins »

cultofmetatron wrote: post #68

maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for…

> you're really wasting a lot of cpu cycles on building up the garbage collector.

Are you sure you aren't thinking of JIT compiling? The context where I think of "warmup" is (say) Java, where the runtime profiles hot paths to emit optimized machine code.

What would it even mean to "build up" a GC?

Re: Ruby on Jets: Like Rails but serverless

#79

Post by __turbobrew__ »

nixpulvis wrote: post #6

Am I the only one who is kinda irritated with how AWS has effectively created a piecemeal proprietary operating system and slowly started displacing good server ops? All while "supporting" open-source development. I really don't want to be an AWS engineer. I like being able to host my own tools when I want. Sorry for the rant, serverless stuff in general is cool. As a followup... I'm curious if anyone can recommend s…

It’s really not that complex to move off of Lambda. The only lambda specific part your application needs to know about is how lambda arguments are passed. There are plenty of middleware providers out there to convert lambda function invocations to HTTP method calls in your application (mangum and others).

Lambda has supported docker images (OCI) for a while now, so you can build your application into an OCI, set the entry point to a lambda middleware and call it a day.

If you want to move off lambda you only need to change the entry-point to an ASGI server instead of the middleware and change the base image layer to be a standard one instead of the lambda specific one which has the lambda runtime installed. You can even build both images and deploy to both lambda as well as a non-serverless system such as k8s, ECS, swarm, systemd, …

Re: Ruby on Jets: Like Rails but serverless

#80

Post by __turbobrew__ »

meekins wrote: post #67
veidr wrote: post #23

Earlier quoted context omitted.

Well for some values of "meaningful" OK, sure. But lots of times a plastic bucket, even with a leak, is a better tool for the job than an extruder, mold, and warehouse full of polymer. I had to build a parallel CI pipeline once that was like: when this, run a FaaS function, then when this that or whipesnicket, run one of these other functions, then run this thing that moves some things from here to there and posts th…

I stopped using the Severless framework when CDK came out. For simple cases it's still fine I guess but a lot of time I found myself falling back to plain CloudFormation (ugh) or relying in plugins with questionable maintenance status. I would not recommend it for new projects and even AWS SAM makes applying some best practices like least privilege principle easier.

CDK is pretty good, the one main painpoint is that some resources are not supported so again you are going to revert to writing cloudformation. I really wish one of AWS’ criteria for “done” when a mew resource is added is that it must be added to the CDK.
Post reply on HN