Live data from Hacker News

Moving my serverless project to Ruby on Rails

frantic.im

21–30 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#21
post #11
post #6

Every time I read that one of the “downsides” of RoR is that it “doesn’t sound cool” I know I’m in the right place! I’ll have mature teammates who understand the right tool for the right job. I won’t have to work with magpie developers with an acute case of not-invented-here syndrome. Granted Rails isn’t the answer to everything. I’ve been loving what we can accomplish with elixir/Phoenix. But I’ll leave the hipsteri…

> (...) 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…

> If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.

That's my opinion but after maintaining some large Rails apps and large Django apps, I would still take Rails any day. Just the testing quality and the batteries included makes it worth it, whereas the main downsides of Rails (speed and lack of typing) are also there anyways on a Django project.

That aside, if people building the project don't have any experience with what they are doing, it will be messy regardless of the framework or the language.

Re: Moving my serverless project to Ruby on Rails

#22
post #11
post #6

Every time I read that one of the “downsides” of RoR is that it “doesn’t sound cool” I know I’m in the right place! I’ll have mature teammates who understand the right tool for the right job. I won’t have to work with magpie developers with an acute case of not-invented-here syndrome. Granted Rails isn’t the answer to everything. I’ve been loving what we can accomplish with elixir/Phoenix. But I’ll leave the hipsteri…

> (...) 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…

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

Re: Moving my serverless project to Ruby on Rails

#23
post #20

Earlier quoted context omitted.

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…

> 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?

"AWS's Serverless Application Model explicitly supports local testing."

It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server.

The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have documentation for every runtime they officially support:

https://docs.aws.amazon.com/serverless-application-model/lat...

It doesn't allow you to test any of the interesting bits, which is what the blog post was alluding to.

- What happens if I have an SQS Lambda with 100 concurrency and a few of the containers get into a bad state? Do the other ones keep going or does the whole thing grind to a halt?

- What happens if I have a Lambda that consumes from 50 Kinesis shards and some of the containers get into a bad state?

- What happens if my Lambda throws an exception, what happens to my SQS message or Kinesis record?

If you outsource the plumbing you can't actually test the system locally you can only test "units" of it and in a lot of cases you either have to do remote tests with print debugging to figure out what's going on or what is more common is blindly assume the plumbing works how you intend, ship it to Prod and then fix problems as they occur.

Re: Moving my serverless project to Ruby on Rails

#24
post #20

Earlier quoted context omitted.

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…

> 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.

Re: Moving my serverless project to Ruby on Rails

#26
post #24
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.

[deleted]

Re: Moving my serverless project to Ruby on Rails

#27
post #23
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?

"AWS's Serverless Application Model explicitly supports local testing." It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server. The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have docume…

> It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally.

Sounds like you're mixing up how a test pyramid works.

AWS SAM supports running unit tests locally. Your remarks refer to integration tests. Integration tests are expected to be performed on environments that mimic either subsets of the production environment, or the whole production environment.

https://docs.aws.amazon.com/whitepapers/latest/serverless-ar...

Re: Moving my serverless project to Ruby on Rails

#28
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…

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 can be avoided by using cfn-lint [1] to ensure the template is valid.

[1]: https://github.com/aws-cloudformation/cfn-python-lint

Re: Moving my serverless project to Ruby on Rails

#29
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…

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.

Re: Moving my serverless project to Ruby on Rails

#30
post #27
post #23

Earlier quoted context omitted.

"AWS's Serverless Application Model explicitly supports local testing." It doesn't provide any additional capability that was already there. Ie, I could already run my arbitrary function from the CLI by building a simple wrapper that reads a JSON file and sends it in. Or wrap it in a simple HTTP server. The debugging story using that tool is worse than how I would already do it pre-SAM and they don't even have docume…

> It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. Sounds like you're mixing up how a test pyramid works. AWS SAM supports running unit tests locally. Your remarks refer to integration tests. Integration tests are expected to be performed on environments that mimic either subsets of the production environment, or the whole production environment. https://docs.aws.amazon.com/whi…

What about manual tests? You know, just running the app on your machine and check if it works/how it works.

You're forced to either share the aws resources with other devs or provision separate resources for each dev which is a big PITA.

Post reply on HN