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

51–60 of 92 posts

Re: Ruby on Jets: Like Rails but serverless

#51

Post by rco8786 »

benevol wrote: post #45
rco8786 wrote: post #41

Earlier quoted context omitted.

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?

It's not only about hosting across multiple providers for the sake of diversifying that risk. It's an unhealthy situation to be fully dependent on 1 single provider. It creates monopolies (instead of diversity and choice) which means less freedom, and/or more corruption and unhealthy conditions for all involved.

No I get the concern. I’m asking how many companies are realistically mitigating that risk, today. Like why is RoJ being called out for it here, when building systems that are tightly tied to various cloud providers is a pretty common thing (and dare I say the risk is even a bit overblown).

Re: Ruby on Jets: Like Rails but serverless

#53

Post by andrew_ »

fishnchips wrote: post #28
jacobn wrote: post #3

Does it really make sense to map each controller method to a lambda? Wouldn’t it make more sense to have gateway route to a single function per controller and then do the method routing inside that function? You’re going to get a lot of lambda functions otherwise.

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.

provisioned concurrency pretty much nukes the concern.

Re: Ruby on Jets: Like Rails but serverless

#54

Post by andrew_ »

danfritz wrote: post #38
fishnchips wrote: post #29

Earlier quoted context omitted.

Given how trivial it is to set up serverless Rails using something like ECS Fargate, the benefit of running specifically on Lambda is lower than migrating off a tried and tested technology.

With lambda you pay for what you use. It scales endlessly and is quite cheap. Depending on your typical usage and load it can be a huge cost saver (also mentally) as lambda will scale. With ECS Fargate it costs money even without any traffic and you are responsible for correctly implementing auto scaling. I'm coming from 10y rails dev background and now full stack typescript. Thinking in pure lambda functions is a br…

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.

Re: Ruby on Jets: Like Rails but serverless

#55

Post by jrochkind1 »

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?

It's not just ruby syntax, it's ruby. Maybe some people want the ruby ecosystem, or just don't want to leave what they are used to.

I haven't used Elixir, I couldn't say how similar it is to ruby, but my understanding is that it is a pretty different language despite some syntax similarities. Perl and C have some syntax similarities, but...

Re: Ruby on Jets: Like Rails but serverless

#56

Post by eddieroger »

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?

I think it's more than you realize because it was more than I realized. It only takes getting burned by a cloud provider once to get the execs to notice, then they talk about lock-in, and the good ones try to avoid it. Plus, remember people move companies and take their knowledge with them. It's the kind of thing that gets talked about in CIO circles [0], so it's more than a tiny minority.

0. https://www.protocol.com/enterprise/target-cio-mike-mcnamara... (Disclaimer: I work for Target but not currently on cloud stuff, though did previously)

Re: Ruby on Jets: Like Rails but serverless

#58

Post by soxocx »

andrew_ wrote: post #53
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.

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.

Re: Ruby on Jets: Like Rails but serverless

#59

Post by michaelcampbell »

revskill wrote: post #47
rco8786 wrote: post #42

I used Ruby on Jets for a small project a while ago. It worked really well, however I got the impression that the project was somewhat stalled and maybe losing support. Has that changed? edit Yea the github activity is still pretty concerning. But Rails seems to be having a little bit of a renaissance so maybe it will pick up here also.

Because people don't think it's Sinatra like, but omasake like Rails.

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

Re: Ruby on Jets: Like Rails but serverless

#60

Post by michaelcampbell »

andrew_ wrote: post #54
danfritz wrote: post #38

Earlier quoted context omitted.

With lambda you pay for what you use. It scales endlessly and is quite cheap. Depending on your typical usage and load it can be a huge cost saver (also mentally) as lambda will scale. With ECS Fargate it costs money even without any traffic and you are responsible for correctly implementing auto scaling. I'm coming from 10y rails dev background and now full stack typescript. Thinking in pure lambda functions is a br…

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 .

Post reply on HN