Live data from Hacker News

Moving my serverless project to Ruby on Rails

frantic.im

81–90 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#81

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…

Have you talked to AWS about why that's the case? AWS Lambda should handle that order of magnitude just fine, as you have an initial burst concurrency quota of at least 500 requests per region (which you also can request to get increased). After that scaling should be additional 500 concurrent requests per minute. [1]

[1]: https://docs.aws.amazon.com/lambda/latest/dg/invocation-scal...

Re: Moving my serverless project to Ruby on Rails

#82
post #50

Lambda is a product for big non agile companies who want to show they can be agile. If you are a single developer there are barely any reason to use it

I'm a single developer and I'm glad I chose serverless for my project. I never have to worry about scale, and for a single developer that's important, as there aren't 10 other developers to leverage when scale becomes an issue after the fact.

I also don't have to pay for what I'm not using, also important for a single developer. If I had chosen a more traditional approach of using EC2 to host a server, I would be paying quite a lot more for my project to sit idle on an EC2 instance 24/7/365 if I'm not getting enough traffic to support paying for the idle server.

Re: Moving my serverless project to Ruby on Rails

#83
post #28

Earlier quoted context omitted.

If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. There might be no “silver bullet”, but aws serverless is like rusted bucket.

> If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA. Is it? For me it's working fine. What problems are you facing when writing CloudFormation templates and what better alternative to declare infrastructure do you suggest? Most problems I see are people being not aware of the possible attributes of resources or doing indentation mistakes when it's a YAML template. Most of these problems c…

Going from something like Puppet with a few VPSes to CloudFormation with serverless is a huge jump in complexity and boilerplate.

Re: Moving my serverless project to Ruby on Rails

#84

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…

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

Rails is great if what you’ve got is read-mostly cachable content being served up. In an environment with high rates of incoming data, most of which can’t be reliably cached, things get more interesting and you start needing to scale horizontally a lot more and leaning on the database.

Re: Moving my serverless project to Ruby on Rails

#85

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…

Elixir (with Phoenix) really is the sweet-spot for a productive framework that's fast, scalable and easy to pick up for a Rails developer: https://medium.com/coryodaniel/from-erverless-to-elixir-4875...

Second this. I did rails for years and liked it a lot, but there were pain points, particularly as a project scaled.

Elixir/Phoenix solves a lot of these pain points and is a joy to work with. If you like Ruby/Rails then you already know quite a bit of Phoenix. Schedule yourself 4 hours to follow a tutorial or book.

Re: Moving my serverless project to Ruby on Rails

#86
post #11

Earlier quoted context omitted.

> (...) I’ll have mature teammates who understand the right tool for the right job. I Honest question: what leads you to believe that Ruby on Rails, or even Ruby, is the right tool for the right job? You didn't even mentioned the job, so why do you automatically assume Ruby is the right tool? Additionally, by ignoring popularity you're also ignoring availability of documentation and examples and mindshare. You're als…

I too have had experience after experience where every Ruby on Rails project in maintenance mode is a complete disaster. It seems like it’s great for quickly building things, but it is unmaintainable, unless you wrote the thing. I am very flexible otherwise, but Ruby on Rails is banned from any project I’m involved in.

My experience is the opposite - Rails projects tend to have tests and maintaining is easy because the test suite is end to end and means something.

That said, Rails projects without tests aren't fun. Besides missing tests, I've also seen fat controllers, bad schema design, and not using Rubocop make more issues with maintenance, but usually I interpret as lack of understanding how to use Rails, not Rails being to blame.

Re: Moving my serverless project to Ruby on Rails

#87
post #76

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…

I jumped on Crystal early and had significant pain, even just building hello worlds. After too much wasted effort I decided to punt and return at 1.0

Has Crystal stabilized?

Re: Moving my serverless project to Ruby on Rails

#88

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…

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.

Re: Moving my serverless project to Ruby on Rails

#89

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…

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…

CPU load being the ceiling in Rails is typically the sign of sloppy development. Most well done apps it will be the database.
Post reply on HN