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

81–90 of 92 posts

Re: Ruby on Jets: Like Rails but serverless

#81

Post by andrew_ »

michaelcampbell wrote: post #60
andrew_ wrote: post #54

Earlier quoted context omitted.

if this is powering your primary API and you have 24/7 traffic, fargate can actually be cheaper in some circumstances. there's nuance in lambda config, including concurrency, temp space, and memory. pay for usage is nice until it's not.

> ... is nice until it's not. Like everything, no? This is akin to saying "All tautologies are tautological." Your sentence preceding this one laid out some issues; you probably could have left it at that .

could have done without the editorial critique as well.

Re: Ruby on Jets: Like Rails but serverless

#82

Post by andrew_ »

soxocx wrote: post #58
andrew_ wrote: post #53

Earlier quoted context omitted.

provisioned concurrency pretty much nukes the concern.

This is not as trivial as you make it sound. You would need to know the amount of functions you want to have provisioned at all times, if you need more, cold starts will occur. In addition this creates base costs, which would not exist otherwise.

I would argue that if you needed n number of functions, where n is unknown, or n cannot be set to a reasonable number that can handle traffic, and cold starts are unacceptable, you would be using the wrong bit of infrastructure.

Re: Ruby on Jets: Like Rails but serverless

#83

Post by suction »

e12e wrote: post #63
michaelcampbell wrote: post #59

Earlier quoted context omitted.

I had to look up "omasake", but I admit I still don't understand its use in this context. ELI5?

It's "omakase" (in the words of Wikipedia) : > Omakase is a Japanese phrase, used when ordering food in restaurants, that means 'I'll leave it up to you' (from Japanese 'to entrust' (任せる, makaseru)) See the article: "Rails is Omakase" by David Heinemeier Hansson on Dec 27, 2012 https://dhh.dk/2012/rails-is-omakase.html > Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the…

[dead]

Re: Ruby on Jets: Like Rails but serverless

#84

Post by aa_memon »

sam0x17 wrote: post #77

former CTO @ Arist (YC S20). We were able to get all the way through series A using Ruby on Jets and it continues to be a major driver behind Arist's growth. Tung, the guy behind it, is simply fantastic.

Having used it what are your thoughts on whether Jets replaces rails vs using alongside rails for certain types of workloads?

Re: Ruby on Jets: Like Rails but serverless

#85

Post by pgib »

I've been using Jets for a small project, and it's mostly been great. Coming from a Rails background, it was a very quick way to get a bunch of stuff running without any ongoing costs or babysitting. The documentation is pretty good, though there has been a few times where I've gotten a little stuck and have had to dig through the source to figure it out. Overall, I'm grateful for its existence.

Ultimately though I don't think I'd use it beyond a proof of concept or without some sort of clear idea for how it will sustain itself.

https://github.com/boltops-tools/serverlessgems/issues/6

Re: Ruby on Jets: Like Rails but serverless

#86

Post by nixpulvis »

__turbobrew__ wrote: post #79
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…

Looking at Ruby on Jets, it seems the entire routing layer is also in AWS. Entry points are kinda a big deal, just like calling conventions.

Re: Ruby on Jets: Like Rails but serverless

#87

Post by dgb23 »

brianshaler wrote: post #35
fishnchips wrote: post #28

Earlier quoted context omitted.

Nothing prevents you from routing everything to a single function, no need to even split by controller. The disadvantage of having a huge number of Lambdas is the ratio of cold starts. The advantage is that you can granularly tweak resource utilization on a per-operation basis.

> granularly tweak resource utilization on a per-operation basis This is a really good point. Either I took a thorny path learning Lambda or they don't make it terribly obvious that when you pre-allocate larger amounts of RAM (thus more $$$ in GB/s cost) you also gain substantially better CPU performance. So when you have a compute intensive task with a low memory footprint and want to improve latency, you may actual…

I don’t know how this works. But I’m curious:

Wouldn’t it be more cost effective to have one big address space than a lot of fine tuned ones? Even if you’re stateless, you could benefit from the fact that utilization spikes can be handled with less overall redundancy. Assuming the dollar cost is proportional per allocation.

Re: Ruby on Jets: Like Rails but serverless

#88

Post by soxocx »

andrew_ wrote: post #82
soxocx wrote: post #58

Earlier quoted context omitted.

This is not as trivial as you make it sound. You would need to know the amount of functions you want to have provisioned at all times, if you need more, cold starts will occur. In addition this creates base costs, which would not exist otherwise.

I would argue that if you needed n number of functions, where n is unknown, or n cannot be set to a reasonable number that can handle traffic, and cold starts are unacceptable, you would be using the wrong bit of infrastructure.

I agree. Usually it is a a trade-off between cold starts and the costs of `n` warm functions.

Re: Ruby on Jets: Like Rails but serverless

#89

Post by sam0x17 »

aa_memon wrote: post #84
sam0x17 wrote: post #77

former CTO @ Arist (YC S20). We were able to get all the way through series A using Ruby on Jets and it continues to be a major driver behind Arist's growth. Tung, the guy behind it, is simply fantastic.

Having used it what are your thoughts on whether Jets replaces rails vs using alongside rails for certain types of workloads?

We leaned really heavily into Jets and found it to be a drop-in replacement for most things we take for granted in Rails. There was some tinkering around that had to be done to get OAuth and a few other things to work properly, but Arist has now paved the path for future orgs to do this easily with patches to Jets and some additional tooling that is easy to find from issues in the Jets issue tracker. The whole abstraction around "ApplicationJob" for spawning trigger-based lambdas in addition to the regular web-serving lambdas is much better and more powerful than having to deal with things like Sidekiq. The fact that every resource gets its own lambda is also very powerful.

Re: Ruby on Jets: Like Rails but serverless

#90

Post by elif »

rco8786 wrote: post #41
benevol wrote: post #39

It looks like Ruby on Jets makes you 100% dependent on 1 company: AWS/Amazon; not an evolution I'd welcome.

Is that like, weird? How many companies are realistically hosting their compute/data across multiple providers for the sake of diversifying that risk? Certainly some, but a tiny minority right?

Every startup I've worked for has had at least 3 data centers in different cities.
Post reply on HN