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

91–100 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#91

Post by zerubeus »

alerighi wrote: post #10
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…

The impossible to replicate the production environment I think was referred to impossible to replicate locally, on your machine. At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. Having each time to upload some code to debug it is time consuming. Also you have to rely only on logs to debug, you obviously cannot use a debugger, and thus the solution i…

I think you never heard about SAM/Serverless Framework, this is why you suffer.

Re: Moving my serverless project to Ruby on Rails

#92

Post by jes5199 »

prh8 wrote: post #89
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…

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

it seems like a lot of my career has been optimizing SQL queries in Rails apps... which is often just adding the correct indexes. Kind of a lot of Rails devs just don’t know to do that

Re: Moving my serverless project to Ruby on Rails

#93

Post by JohnBooty »

prh8 wrote: post #89
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…

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

Yes, this matches my experience. I've been doing Rails full-time for about 6 years and any "slowness" has been the result of some problem, not Rails itself. 99% of the time this is an uncached n+1 query situation, or some beastly slow database operation that needs to be moved to background processing, things that would be problems in any framework or even some sort of bare-metal asm solution that nonetheless relies upon an external storage layer. =)

In a CRUD app the Rails layer should be extremely thin and the storage layer(s) should be doing nearly all of the heavy lifting.

There is a level of traffic at which even a "properly" thin Rails layer becomes the bottleneck, relative to many other frameworks.

TechEmpower benchmarks suggest it is around 2,500 requests per second in their "multiple queries" benchmark. In a more real-world scenario that might be 1,000 req/sec or less.

https://www.techempower.com/benchmarks/#section=data-r19&hw=...

If one is attempting to serve more requests than this per minute then yes, perhaps Rails is the bottleneck. Admittedly, Rails' large memory consumption relative to other frameworks means it can be tough (well, technically easy, but expensive) to scale horizontally at this point.

Re: Moving my serverless project to Ruby on Rails

#94

Post by s_fischer »

Dunedan wrote: post #31
claudiusd wrote: post #16

Earlier quoted context omitted.

Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset". There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.

Yes, absolutely. And to be honest to get started with it for a software developer which doesn't have any "cloud" experience is pretty rough. Suddenly that developer needs to have a understanding of AWS in general, IAM, CloudFormation and all the services which can be utilized to avoid having to write custom code. It's a steep and long learning curve.

Fully agree. The problem gets even worse at bigger orgs where there's a separate, security oriented, team which is responsible for setting/managing IAM roles and KMS keys. I think the AWS ecosystem can be very discouraging for younger engineers in these situations. A innovative PoC in your downtime seems a lot more daunting when you need to learn about 4-5 AWS services that are unrelated to code execution and you have make a request to devops for a new IAM role just to locally test out a prototype that you built over the weekend.

Re: Moving my serverless project to Ruby on Rails

#95

Post by murphm8 »

freedomben wrote: post #85
cpursley wrote: post #56

Earlier quoted context omitted.

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.

Do you have any recommended books or tutorials?

Re: Moving my serverless project to Ruby on Rails

#96

Post by zerubeus »

Dunedan wrote: post #24
rualca wrote: post #20

Earlier quoted context omitted.

> At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. AWS's Serverless Application Model explicitly supports local testing. https://docs.aws.amazon.com/serverless-application-model/lat... Which problems did you experienced?

SAM is able to run AWS Lambda functions locally and to emulate some API Gateway behavior. It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. As Serverless applications often rely on such additional AWS services, the ability of SAM to run AWS Lambda functions locally doesn't really help for running such applications locally.

You guys don't even take the time to do a simple search... https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

You can have pretty much all the services locally if you want you can even have a step function locally

Re: Moving my serverless project to Ruby on Rails

#97

Post by squam »

rualca wrote: post #29
schnable wrote: post #22

Earlier quoted context omitted.

If you knew Ruby and not the Python, the whole scenario would have been flipped.

> If you knew Ruby and not the Python, the whole scenario would have been flipped. That's why popularity matters. The odds that any random kid already has experience with Python are far greater than him knowing Ruby.

Not popularity, but familiarity. You don’t have to play the odds if you already know what tools your team has experience with.

Re: Moving my serverless project to Ruby on Rails

#98

Post by zerubeus »

claudiusd wrote: post #16
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…

Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset". There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.

I'm just really sad reading all this comments, knowing that some people will take the decision based on them, PLEASE DON'T, most of the commenters have no idea about what they are talking about.

Re: Moving my serverless project to Ruby on Rails

#99

Post by nickjj »

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 with plenty of YAML glue, schema-less JSON objects passed around and random hardcoded configs in AWS console.

With SAM, it's still a ton of boilerplate too.

And honestly, even most simple functions are going to use SNS topics, S3 buckets and CloudWatch so you can see your logs. Probably a datastore too. Or if you want to access the Lambda over HTTP instead of an SNS trigger, then you'll need something like API gateway or a load balancer too.

It's even more fun if you decide to write to an RDS instance that's locked down by IP address and inside of a VPC while at the same time your Lambda needs external internet access. The amount of hoop jumping to get all of that to work was unreal. And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services.

The infrastructure complexity was more than anything I've ever experienced in any tech stack. But I thought the goal of Serverless was to avoid infrastructure?

Then there's the whole problem of wanting to wire up your main non-serverless service wanting to trigger a Lambda using SNS topics. That's fine until you want to be able to develop the project locally, except SAM and other comparable tools don't mock out SNS. So now you're stuck either having to pay to have your dev environment running on AWS or set up something like localstack to mock out a bunch of AWS services (which isn't free either btw).

The messed up thing is, after all that, it was to be able to run about 20 lines of Python business logic. All it did was call out to a 3rd party API service and store the results into a database.

Re: Moving my serverless project to Ruby on Rails

#100

Post by cambalache »

murphm8 wrote: post #95
freedomben wrote: post #85

Earlier quoted context omitted.

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.

Do you have any recommended books or tutorials?

For the language and the framework the official tutorial/documentation are pretty good.

Also Pragmatic Programmers has very good books on both, written by the creators.

I love Phoenix but I will disagree with the OP in 2 points.

Yes probably Elixir/Phoenix will manage better thousands of concurrent connections, but if you are doing personal projects or are a start-up that condition is irrelevant in the meantime. So that only lefts us with the big established applications. That does not mean Phoenix is not good, it only means you will not notice a difference with Rails for most of your projects.

The second thing, that OP failed to mention is that the Rails ecosystem is at least an order of magnitude larger. From the gems available, job opportunities,developers available, instructional material, SOP for many tasks and so on.That is boring, but valuable.

Post reply on HN