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

Moving my serverless project to Ruby on Rails

frantic.im

Post reply on HN
Print view View original

171–180 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#171

Post by Lio »

dasil003 wrote: post #129
ffdjjjffjj wrote: post #51

Earlier quoted context omitted.

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…

This very much depends on the use case. If you are truly CPU-bound than yes, ruby is a bad choice. Similarly, if you are IO-bound or otherwise need a lot of concurrency ruby is not great. I also think it's problematic for large code bases with hundreds of developers. However, there is a huge swath of web apps and APIs that just need to pull a bit of data from a DB or two, munge it together and send it to the client.…

Could you go into more detail about what you see as issues with IO bound tasks?

My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL.

Is there some other issue related to that?

(JRuby provides fully multi-threading for cpu bound tasks without GVL).

Re: Moving my serverless project to Ruby on Rails

#172

Post by namelosw »

heipei wrote: post #110
rkangel wrote: post #72

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but with a few extra powers: * Elixir is a great functional programming language * When your backend needs to do more complex or longer running work it's just more Elixir rather than complicated architecture involving task queues etc. (because you have the concurre…

I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the cas…

Kill at any time is dangerous for stateful Erlang / Elixir workloads. But there are several patterns:

1. Some process group libraries can handle graceful shutdown, which migrates the processes to other nodes. When you kill one of the nodes, it's process goes to other nodes in like tens of seconds.

2. Invent some virtual actor pattern like Microsoft Orleans.

3. Just backup processes states to external storage. Even not for shutting down nodes scenarios, people still tend to backup process state to ETS or stateful processes so that stateless processes can crash-then-revive without troubles.

Re: Moving my serverless project to Ruby on Rails

#173

Post by erikrothoff »

FpUser wrote: post #137
nitrogen wrote: post #73

Earlier quoted context omitted.

Rails handled Black Friday and Cyber Monday traffic for an ecommerce company I used to work for just fine. If you are making money, it's worth the cost of 50 lowend VPSes autoscaled (we could have done with a lot less, too). If we were using Java it would have taken us three times the people and four times as long to build the site, and we all would have been laid off.

For rare events this concept works fine. For large sustained loads using more language/runtime could save a fortune.

Do you have a real world example? For example, what are you spending on a single app server? And how many RPS should it handle?

Re: Moving my serverless project to Ruby on Rails

#174

Post by theshrike79 »

nickjj wrote: post #99

I've been tinkering with Serverless (on AWS) for some client work recently and my view is about the same as this post. Every complaint he listed is what I encountered too. It's one of the most unfriendly dev experiences I've seen in ~20 years of development. OP's post contains: > What started as a simple function, grew into a bunch of serverless functions, SNS topics, S3 buckets, DynamoDB tables. All bound together w…

> And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services.

Yep, this matches my experiences with AWS too.

The stuff that you THINK might cost an arm and a leg, are actually really cheap. Billions of lambda calls with thousands running concurrently? meh. Huge SNS/SQS-queues? Meh. Terabytes of data stored in S3? A drop in the bucket.

BUT.

Too many PUT-operations on S3? $$$$$expensive$$$$$ Too much IO on an Aurora instance? Pucker up! Need some sane network configuration? Prepare to pay up the wazoo for gateways.

Yes, all that can be worked around, but it's really non-intuitive to actually see where the pain points in a project will eventually be.

Re: Moving my serverless project to Ruby on Rails

#175

Post by neurostimulant »

Dunedan wrote: post #68
neurostimulant wrote: post #53

Earlier quoted context omitted.

Ugh, I rewrote my serverless service for exactly these reasons. It felt magical the first time where you can deploy a service without spinning up a server so I put up with all these annoyances. But then docker gains popularity and suddenly there is no practical advantage in using serverless anymore, at least for me. I rewrote the service in django, packaged it as a docker image, then run it on any platform that can r…

What you do with CloudFlare Workers can be done on AWS with Lambda@Edge [1]. [1]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.htm...

I can't comment on lambda@edge as it wasn't available when I was still using aws lambda a few years ago. My current use case is probably supported on lambda@edge if I were still on aws as I'm mostly only use them to implement smart caching and routing.

Re: Moving my serverless project to Ruby on Rails

#176

Post by stepbeek »

treis wrote: post #69
awestroke wrote: post #57

Earlier quoted context omitted.

Scaling horizontally is not cheap. A faster language needs fewer replicas.

Compared with developer time servers are cheap. Even for a single developer being 10% quicker at development equates to dozens to a hundred servers.

I never understood this until I was self-employed. I now feel this in my soul.

Re: Moving my serverless project to Ruby on Rails

#177

Post by sodapopcan »

joelbluminator wrote: post #112
sodapopcan wrote: post #46

Earlier quoted context omitted.

Boring tech is great if your primary concern is writing business logic. Ideally, this should always be true, but of course the reality is that people's jobs often have them working on products they don't really care for. And of course, it's easy to get distracted by tech anyway. Experience also comes into play when it comes to loving "boring" tech—it took my around a decade before I was sufficiently jaded that almost…

> it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic It's comforting to see I'm not alone. I just wanna ship clean code and contribute value to the business, while all the young bucks in my team are more interested in rewriting our REST apis in Graphql (with all kinds of rationalizations). Looks like the younger you are the more eager you are to expl…

Ha, ya, my work recently mandated moving everything to graphql. My team started a greenfield project so there was no need to convert anything, though the learning curve was high with apollo. Graphql is nice, but as the only consumers of our API, I don't see it as a win over REST. At this point, though, we're proficient enough that it doesn't get in our way.

Re: Moving my serverless project to Ruby on Rails

#178

Post by joelbluminator »

sodapopcan wrote: post #177
joelbluminator wrote: post #112

Earlier quoted context omitted.

> it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic It's comforting to see I'm not alone. I just wanna ship clean code and contribute value to the business, while all the young bucks in my team are more interested in rewriting our REST apis in Graphql (with all kinds of rationalizations). Looks like the younger you are the more eager you are to expl…

Ha, ya, my work recently mandated moving everything to graphql. My team started a greenfield project so there was no need to convert anything, though the learning curve was high with apollo. Graphql is nice, but as the only consumers of our API, I don't see it as a win over REST. At this point, though, we're proficient enough that it doesn't get in our way.

> but as the only consumers of our API, I don't see it as a win over REST.

Same story here. Our company is the only API user, why go through all that trouble? Donno.

Re: Moving my serverless project to Ruby on Rails

#179

Post by stepbeek »

julianrubisch wrote: post #88
faizshah wrote: post #61

Earlier quoted context omitted.

Is there a good way to turn your rails app into a mobile app these days? I remember seeing something from turbolinks showing a way to make hybrid mobile apps using turbolinks.

Yep, turbolinks. We’re all waiting for TL6 though to revive the android adapter.

It’s been a while. I tried to hack something like this together - without having done any android dev before - and I understand why it’s taking a while. It’s not as simple as I’d imagined it would be.

Re: Moving my serverless project to Ruby on Rails

#180

Post by dosethree »

Lio wrote: post #171
dasil003 wrote: post #129

Earlier quoted context omitted.

This very much depends on the use case. If you are truly CPU-bound than yes, ruby is a bad choice. Similarly, if you are IO-bound or otherwise need a lot of concurrency ruby is not great. I also think it's problematic for large code bases with hundreds of developers. However, there is a huge swath of web apps and APIs that just need to pull a bit of data from a DB or two, munge it together and send it to the client.…

Could you go into more detail about what you see as issues with IO bound tasks? My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL. Is there some other issue related to that? (JRuby provides fully multi-threading for cpu bound tasks without GVL).

"My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL."

All IO operations in ruby are subject to the GIL (global interpreter lock).

Post reply on HN