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

71–80 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#71

Post by VWWHFSfQ »

freehunter wrote: post #59
ricketycricket wrote: post #48

Earlier quoted context omitted.

> 2. Lambda has provisioned capacity. I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?

It’s more like you have one Lambda instance that is always running (sure think of it like one server) that can serve the first page instantly while the other ten thousands Lambdas take half a second to warm up. That first Lambda responds instantly so it hides the half second response for the rest of the application. It really makes sense if you have traffic that spikes at certain times per day (think like fantasy foo…

We experimented with Lambda and found it completely unsuitable for any workload that has a "thundering herd" problem. If you go from zero to 1,000 requests/second then it can take up to 30 minutes to fully scale for that inbound traffic. And pre-provisioning for that sudden peak concurrency is very expensive. I think Lambda probably has its place in some kind of backoffice task runner architecture, but it's really not good for serving web traffic that might be occasionally spiky.

Re: Moving my serverless project to Ruby on Rails

#72

Post by rkangel »

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 concurrency of the BEAM to manage it)

* You have options like LiveView for your frontend. You don't have to use it, but it's there.

I agree with what you said about testability for Lambda style architectures. How do you spin up an offline version of some or all of that to see if it works? The BEAM world is nice for me because you can run a similar architecture of separate things (albeit all in one language), but have a much better testing setup.

Re: Moving my serverless project to Ruby on Rails

#73

Post by nitrogen »

awestroke wrote: post #57
erikrothoff wrote: post #54

Earlier quoted context omitted.

Curious what part of Rails you didn’t find scalable? Our Rails frontend servers run on cheap VMs that are easily scaled horizontally.

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

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.

Re: Moving my serverless project to Ruby on Rails

#74

Post by tutfbhuf »

erikrothoff wrote: post #62
awestroke wrote: post #57

Earlier quoted context omitted.

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

Really? Our frontend servers handle 50 rps and cost $20 each and are nowhere near peak utilization. If anything ever needs scaling its the database. What level of traffic are you talking about?

For example a newspaper with customizable content, 1 petabyte (70% video) per month and avg. 2k request per second.

Re: Moving my serverless project to Ruby on Rails

#75

Post by sam0x17 »

For those in this predicament, consider mine -- I'm about to migrate a non-serverless collection of nodejs microservices to Rails via Ruby on Jets, which apparently has full support for running standard Rails apps these days. I can't imagine something more powerful than a Rails app running in a Lambda.

Re: Moving my serverless project to Ruby on Rails

#76

Post by sam0x17 »

Also consider giving Crystal lang a look, in particular the Amber and Lucky web frameworks. Amber in particular is designed to feel just like Rails and accomplishes that pretty well in my opinion.

Crystal is designed to feel like Ruby but to be "fast like C". I think in reality by adding a type system it manages to be better than Ruby.

Small but very welcoming community with a number of startups and companies running things in production. Crystal itself is doing well with the 1.0 release looming very soon.

Re: Moving my serverless project to Ruby on Rails

#77

Post by k__ »

VWWHFSfQ wrote: post #71
freehunter wrote: post #59

Earlier quoted context omitted.

It’s more like you have one Lambda instance that is always running (sure think of it like one server) that can serve the first page instantly while the other ten thousands Lambdas take half a second to warm up. That first Lambda responds instantly so it hides the half second response for the rest of the application. It really makes sense if you have traffic that spikes at certain times per day (think like fantasy foo…

We experimented with Lambda and found it completely unsuitable for any workload that has a "thundering herd" problem. If you go from zero to 1,000 requests/second then it can take up to 30 minutes to fully scale for that inbound traffic. And pre-provisioning for that sudden peak concurrency is very expensive. I think Lambda probably has its place in some kind of backoffice task runner architecture, but it's really no…

And you couldn't directly integrate with other services?

Re: Moving my serverless project to Ruby on Rails

#78

Post by nitrogen »

Dunedan wrote: post #7

> A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email… Or, you know, just do related functionality in the same AWS Lambda function. While I would probably do the sending of an e-mail asynchronously as well (as AWS Lambda function triggered by a DynamoDB stream), the indirection over SNS to write something to DynamoDB see…

One of AWS's major flaws is that it provides an encouraging UI that almost begs new teams to create a special snowflake manual configuration.

The AWS UI should ideally be refactored to be a frontend for an infrastructure as code service like CloudFormation.

One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.

Re: Moving my serverless project to Ruby on Rails

#79

Post by mattmanser »

neurostimulant wrote: post #49
xwdv wrote: post #39

Earlier quoted context omitted.

All you need is one weekend to really learn a useful amount of Node and React. You can’t spare it?

What's the benefit of moving from Rails to Node and React productivity-wise? On the backend side, Rails comes with an ORM, authentication, templating system and many more out of the box, while on Node you'll need to mix and match a bunch of 3rd party libs or roll your own, which might be a good thing depending on your priorities but certainly kills productivity. On the frontend side, you can always use react with rai…

Even in mid-sized projects there's usually one or two pages with sufficiently complicated front-ends that it's worth having something like React in your toolbox, though it might be Vue or Svelte.

You don't have to make the whole app a SPA to use these tools. You can just use it in those few pages that really need it.

Re: Moving my serverless project to Ruby on Rails

#80

Post by erikrothoff »

tutfbhuf wrote: post #74
erikrothoff wrote: post #62

Earlier quoted context omitted.

Really? Our frontend servers handle 50 rps and cost $20 each and are nowhere near peak utilization. If anything ever needs scaling its the database. What level of traffic are you talking about?

For example a newspaper with customizable content, 1 petabyte (70% video) per month and avg. 2k request per second.

I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video. But 2k requests per second with mostly text content being shuffled around sounds absolutely doable with Rails. The cost benefit of easier development should definitely not be understated as well.

But that being said, the primary driver for tools should be what the developers know and ease of access finding developers who know this technology. If the city you work in mostly has PHP developers, PHP is a great choice. Similar for Java, Haskell, Lisp, etc. My point is that the tool ”Rails” definitely is adequate for this problem (minus streaming video...). Look at Shopify, Github or any other massive Rails app

Post reply on HN