Moving my serverless project to Ruby on Rails
1–10 of 189 posts
Re: Moving my serverless project to Ruby on Rails
#2Understandable.
As I wrote in my last article [0], serverless advocates pushed too much FaaS in the last years.
FaaS is awesome, but should be the last resort, if you throw too many functions at a problem you can easily end up with a distributed monolith, which is often worse than a regular one.
Re: Moving my serverless project to Ruby on Rails
#3I've seen a lot more discussion of Ruby recently than in past years, and maybe I'm just finding what I'm on the lookout for, but either way it makes me happy :)
Re: Moving my serverless project to Ruby on Rails
#4Understandable. As I wrote in my last article [0], serverless advocates pushed too much FaaS in the last years. FaaS is awesome, but should be the last resort, if you throw too many functions at a problem you can easily end up with a distributed monolith, which is often worse than a regular one. [0] https://dev.to/fllstck/serverless-myths-56dc
Serverless functions for a distributed monolith.
What a beautiful house of cards.
Re: Moving my serverless project to Ruby on Rails
#5Understandable. As I wrote in my last article [0], serverless advocates pushed too much FaaS in the last years. FaaS is awesome, but should be the last resort, if you throw too many functions at a problem you can easily end up with a distributed monolith, which is often worse than a regular one. [0] https://dev.to/fllstck/serverless-myths-56dc
Serverless functions for a distributed monolith. What a beautiful house of cards.
Yes.
The orchestration vs choreography problem.
https://theburningmonk.com/2020/08/choreography-vs-orchestra...
Re: Moving my serverless project to Ruby on Rails
#6Every 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 hipsterism to the JS community and marvel as they reinvent wheels over and over again.
Re: Moving my serverless project to Ruby on Rails
#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 seems overly complex.
Why would you do something asynchronously with a Serverless architecture you'd do synchronously with Ruby on Rails?
> […] and random hardcoded configs in AWS console.
Just don't do that. A Serverless application will always be a pita if it relies on manual configuration. Ensure all relevant configuration is part of Infrastructure as Code (e.g. CloudFormation or Terraform).
> Impossible to replicate production environment
If the project is set up properly with Infrastructure as Code replicating the production environment is as easy as it can possibly get. And because it's Serverless, if an environment isn't used, it usually doesn't even incur notable costs.
There is no silver bullet and I believe Serverless as well as other approaches have their place, but what I miss are similar posts about great experiences with Serverless applications. I for myself wouldn't want to go back and I'm really happy with the problems Serverless applications solve.
Re: Moving my serverless project to Ruby on Rails
#8Every 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…
[deleted]
Re: Moving my serverless project to Ruby on Rails
#9You can have the best of both worlds with Ruby Jets https://rubyonjets.com/. Build micro services inside of a monolith. Might not make sense, but you're essentially building one app that deploys to micro services in AWS, in your favorite language and a framework that is essentially Rails.
Re: Moving my serverless project to Ruby on Rails
#10> 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 is to insert a ton of print statements in the code and remove them, which is not a problem to me (I usually do that even in code that I debug locally) but the service to read these logs (ColoudWatch) is not great at all, you don't even have all your logs in one place, it's a mess.
I think serverless is overrated, sure it maybe the right tool for a simple project, but when the complexity grows it's best to use other more classical solutions.