14 ms·

Moving my serverless project to Ruby on Rails

350 points by pcr910303 6y ago

k__ 6y ago
Understandable. 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 https://dev.to/fllstck/serverless-myths-56dc
- simplecto 6y ago
  Serverless functions for a distributed monolith. What a beautiful house of cards.
  - k__ 6y ago
    Yes. The orchestration vs choreography problem. https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/ https://theburningmonk.com/2020/08/choreography-vs-orchestra...
Lammy 6y ago
I'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 :)
- joelbluminator 6y ago
  I think it's past the latest hate cycle to good all boring now, kinda like php but with a bit of a better rep. I'm not sure actually why php and ruby are so despised.
  - Nextgrid 6y ago
    > php I personally quit PHP around 2013 because of the inconsistent standard library. I spent more time looking up the docs than developing because the language just wasn't intuitive compared to let's say Python. However, beyond that, PHP has some pretty great frameworks nowadays (and I am forever grateful to Laravel for teaching me the concepts of an MVC framework, which proved useful when I switched to Django).
  - jaredcwhite 6y ago
    I'm a committed Rubyist but I'd jump into using PHP/Laravel in a heartbeat if I couldn't use Rails any more. It seems way more sensible and well-designed than the terrible state of affairs you find in JS backend land. (shudder!)
- ksec 6y ago
  It is a combination of factors. It is not that Ruby suddenly popular again, the scaling issues is still there, Scaling not impossible but mostly have to do with being expensive. If you are an average dev in UK or US with 100K+ Salary of course scaling is cheap. But not everyone has that luxury or operate on the same budget. But the combination of Ruby and Rails getting faster and Hardware is finally getting cheaper. ( 128 Core EPYC, on a 2 Socket Server Changes the Unit Cost of Core per VM across the whole industry ) Along with wages rises across other part of the world. And the world has finally woken up to may be Javascript Ecosystem isn't exactly what they have hoped for in the backend.
jspash 6y ago
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 hipsterism to the JS community and marvel as they reinvent wheels over and over again.
- deleted 6y ago
  [deleted]
- rualca 6y ago
  > (...) 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 also ignoring experience, and prior onboarding into a language stack, which automatically means odds are anyone onboarding into the project will quickly be up and running. Speaking as someone who was forced to onboard into a Ruby project just because a predecessor jumped on the bandwagon, the experience was an unmitigated disaster. A minor onboarding task that consisted of tweaking a hard codes settin in a module required me and a couple of colleagues to spend a few days a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with idiomatic Ruby, d) learning how to troubleshoot and debug Ruby applications, e) properly setup a software dev environment, and f) finally fix the issue. 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. How does can this sort of snafu pass off as the right tool for the right job?
  - derwiki 6y ago
    It sounds like more than RoR. Anecdata counterpoint: I’ve worked on a few RoR projects that were well architected and only took me a few days to fully ramp up.
Dunedan 6y ago
> 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.
- alerighi 6y ago
  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.
  - k__ 6y ago
    Thundra offers online and offline debugging. Also, AWS SAM CLI allows to run things locally.
dkobia 6y ago
You can have the best of both worlds with Ruby Jets https://rubyonjets.com/ 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.
nobody0 6y ago
X as a service seems easier at first because complexity is hidden, but it's not going away. Old boring stacks can still go a long way for small/medium projects.
deleted 6y ago
[deleted]
mt42or 6y ago
"You don't need serverless"
- deleted 6y ago
  [deleted]
knodi 6y ago
Serverless for web apps have one big issues. The cold starts of lambda(s) can be over .5-1 seconds at peek times (us-east-1) any way.
- k__ 6y ago
  Thete are multiple solutions to that problem. 1. API Gateway and AppSync integrate directly with many other AWS services, no Lambdas needed, and thus no cold-starts. 2. Lambda has provisioned capacity. 3. Other cloud providers like Cloudflare offer FaaS without cold-starts.
  - ricketycricket 6y ago
    > 2. Lambda has provisioned capacity. I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?
    - k__ 6y ago
      I think so, that's why I usually try to avoid it. But I guess it's the last resort if you absolutely have to use a Lambda without cold-start
    - freehunter 6y ago
      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 football). There’s going to be times when no one is using your application but when they do, there are going to be dozens or hundreds of people suddenly using it. So the first person that logs on hits the provisioned Lambda instantly and then AWS warms up the rest of the Lambdas as more traffic comes in.
      - VWWHFSfQ 6y ago
thismodernlife 6y ago
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 either via Heroku, via the new Digital Ocean k8s app cluster or – and this is my new favourite tool – using Hatchbox.io to deploy apps to Digital Ocean or AWS. It’s a dream!
- luxurytent 6y ago
  Replace Rails with Django and this comment seems to hold true for many in the Django community. Boring can be good.
  - sodapopcan 6y ago
    Boring tech is great if your primary concern is writing business logic. Ideally, this should always be true, but of course the reality is that people's jobs often have them working on products they don't really care for. And of course, it's easy to get distracted by tech anyway. Experience also comes into play when it comes to loving "boring" tech—it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic. I still love refactoring, though :)
    - joelbluminator 6y ago
      > it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic It's comforting to see I'm not alone. I just wanna ship clean code and contribute value to the business, while all the young bucks in my team are more interested in rewriting our REST apis in Graphql (with all kinds of rationalizations). Looks like the younger you are the more eager you are to explore new tech and the older you are the more keen you are in just delivering value in a boring old stack.
nickthemagicman 6y ago
I do know what OP means. Aren't there any good serverless frameworks that simplify this complexity?
ignoramous 6y ago
Serverless has its place. I am not sure if I'd chose to build a shopping cart on Serverless just yet (Next.js' recent forays notwithstanding), but for something that is stateless (like content distribution, capturing metrics and logs, serving static webpages)...oh, is it a breeze. That said, I see many promising upstarts and incumbents in the space trying to make stateful Serverless easier by the day. Things can only improve and improve they will. I'm bullish.
troughway 6y ago
I'm looking at Blazor/wasm nowadays and it's causing me an awful lot of nostalgia when I think back to the early days of Rails (if '08 can be called early days per-se), because of the shit show back then with various tech stacks and the grunt work required to get a site up with some DB backed data source and whatnot. And I feel like today we are back to some kind of a point of having to shoehorn FE/BE tech together unless we use some isomorphic approach which, predominantly, forces the use of JS. And I remember DHH commenting on this regarding Java and saying something to the tune of "Why would I write Java when Ruby is so much better?". Back then I thought such a statement was too indignant, like someone getting on their high horse about a particular kind of building material that is better above all else. But nowadays, I see the wisdom behind it all the same. I just want simple bloody tech that treats the browser as a layout and input handling engine and lets me write code in any language I see fit, whether it's Ruby, F#, C#, Clojure, whatever. I'm hoping Blazor or something like it can deliver on that vision.
- hu3 6y ago
  Server side Blazor is promissing to me. Simpler development by merging frontend and backend into one C# codebase but might not work well on unstable connections due to websockets. Some of my clients fall into this case. I'm keeping a close eye on it. I also need to test how it scales with regards to handling traffic.
polote 6y ago
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
- leptons 6y ago
  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.
0x445442 6y ago
Having worked with AWS serverless for a couple of years, I think the architecture is not well suited for replacing a monolithic application. If horizontal scaling is an issue, I think containers are better suited. Serverless seems to be a better fit for ETL/Data Transformation workflows.
- ledauphin 6y ago
  serverless (well, lambdas) would be very expensive for any truly significant ETL work. if you have long-running jobs of any kind, that's precisely the opposite of where serverless shines.
VWWHFSfQ 6y ago
I pretty much just start all of my projects, no matter how small, with Django. Working with microframeworks or serverless is great at first but as soon as you need any more of the typical features that a webapp requires then you start pulling in dependencies or re-implementing half of Django yourself anyway. First you just need a little url router to some basic views. OK that's great, anything can do that. Now you need to validate some forms. Now you need to manage some session cookies. Now you need to let users reset their passwords. Now you need to look at your data and maybe export a csv. It just goes on and on.
- rangoon626 6y ago
  What you wrote about is something that I really struggled with wrt serverless when I first started learning it. Lambda, at this point, feels to me like doing a php project without using any framework. You are doing it all yourself, all the tedious stuff. I have started to mix Zappa and Django to get the best of both Django and Serverless. So far, I like it. I have not hit any considerable scale yet, so I wonder if Django is too heavy, or just right. It seems fine so far. The other plus - it’s all open source tech, so it’s easy to move away from Lambda if I need to. It’s even better, too, because you CAN break out some more isolated functionality into stand alone lambdas when they start to get clumsy inside a typical Django proj.
rkangel 6y ago
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.
- bdcravens 6y ago
  > You have options like LiveView for your frontend Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)
  - rkangel 6y ago
    The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix. I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smart guy and an excellent developer who's opinion I therefore give some weight to.
    - jaredcwhite 6y ago
      No doubt, but there are some pretty awesome wizards working on StimulusReflex (and CableReady which it sits atop) as well, so I think it mostly depends on if you're keen to program in Elixr or Ruby.
- heipei 6y ago
  I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?
sam0x17 6y ago
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.
sam0x17 6y ago
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.
- freedomben 6y ago
  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?
  - Can_Not 6y ago
    I've used crystal (mostly kemal) for almost 1 year and the updates have not been too often and have not broken much.
  - sam0x17 6y ago
    Crystal itself has stabilized quite nicely. Amber/lucky are a bit slow to update, but all of my production apps use either Kemal or Spider Gazelle which are too lightweight to matter in that regard.
cayblood 6y ago
Did you consider Step Functions for taming some of this complexity?
nickjj 6y ago
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.
- helsontaveras18 6y ago
  Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development). Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud. Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.
grose 6y ago
I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP server and let an adapter handle the lambda bits[1]. During development you run it as a regular HTTP server and connect directly to localhost. To deploy it all you need is a shell script that zips and uploads your binary to lambda. All state is stored in DynamoDB. One log stream for everything. The downside is dealing with AWS events. There’s a few ways to handle it. You can write it into your monolith, toggling behavior with say an environment variable. You can sometimes work around it, for example avoiding the S3 file uploaded event by having clients ping your HTTP API on upload completion. Of course, there are trade offs for all the techniques. You can easily reconfigure a lambda to retry on failure but you’d have to manually implement that client-side. You can also always just add another lambda if you’re ready. To put it another way: you probably don’t need to write that record to a queue which gets written to DynamoDB, whose stream calls another lambda etc etc. Just do that stuff within a regular old HTTP handler until the fanciness is absolutely necessary. For personal projects, I appreciate how serverless scales to zero. I don’t have to worry about axing projects with minimal usage. [1] for example https://github.com/akrylysov/algnhsa https://github.com/akrylysov/algnhsa or https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy
- earthboundkid 6y ago
  This is what I’ve been doing with Go on Netlify (which is a wrapper around AWS Lambda). https://blog.carlmjohnson.net/post/2020/how-to-host-golang-on-netlify-for-free/ https://blog.carlmjohnson.net/post/2020/how-to-host-golang-o...
alexellisuk 6y ago
How are you finding managing infra for rails? Is disaster recovery quick for you? I'm the author of openfaas and hear what you say about the fragmentation for using AWS Lambda. We recently made a rails-esq version of OpenFaaS for users who have a single small app like yourself. I would be interested in your impressions. It's all open source and is a bit more of a more modern stack. On the upside it uses containers and you can write in any language. https://www.openfaas.com/blog/faasd-tls-terraform/ https://www.openfaas.com/blog/faasd-tls-terraform/
weeboid 6y ago
One thing you have to realize, is that "enterprise" architectures are as much about workforce management as they are about efficiency, or scalability, or et al. There's a limit to how reduced data, and functions that work on data, and the transports and relationships between it all, can get. Let's call this residual mass "goo". Well, the goo has to go _somewhere_.
g8oz 6y ago
Has anyone tried TruffleRuby in a project yet?
desireco42 6y ago
I moved to Phoenix and it is wonderful. Except... Ecto just isn't as easy as ActiveRecord and you can't do things the way you would prototype things in IRB. So, yeah, on one hand, I have crazy performance and LiveView etc, but on other, it is huge hassle just to hack around the way I did before.
techthumb 6y ago
In OO systems, we often talk about "Simple Objects & Complex Interactions" v/s "Complex Objects & Simple Interactions". In my experience, being at either extreme becomes counter-productive. To me, it comes down to finding the "happy middle" for your project. Monolith v/s Micro-services/Serverless are similar. Neither extreme is productive. There exists a happy middle depending on the situation.
akhilcacharya 6y ago
Seems to me that the ideal would be a heavier-weight convention-over-configuration framework that "compiles down" to Cloudformation + Lambda code.
liquidwax 6y ago
AWS Amplify[1] actually has neat tooling for serverless projects and lets to deal with just the core of your product and worry less about infra. Admittedly, it helps if you know the underlying connections but in my experience that's true with rails too. Building a blog with rails isn't the same as a more complex product. [1] https://aws.amazon.com/amplify/ https://aws.amazon.com/amplify/
helsinkiandrew 6y ago
I’m not sure the issues experienced are due to serverless rather than the architecture chosen. A monolithic app vs services. Why split up the serverless functionality into separate functions connected with SNS etc? You can call the same ruby code from a single serverless lambda endpoint invoked from a http call in the same way you would from a rails process. Rails is great, but you could run Rails on a serverless architecture (AWS) too if you really wanted to, and you could create a multi service architecture of Rails components that would be equally hard to maintain and develop.
ptman 6y ago
You could probably deploy your RoR service using Google Cloud Run.

350 points by pcr910303 6y ago

k__ 6y ago

Understandable. 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 https://dev.to/fllstck/serverless-myths-56dc

simplecto 6y ago
Serverless functions for a distributed monolith. What a beautiful house of cards.
- k__ 6y ago
  Yes. The orchestration vs choreography problem. https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/ https://theburningmonk.com/2020/08/choreography-vs-orchestra...

Lammy 6y ago

I'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 :)

joelbluminator 6y ago
I think it's past the latest hate cycle to good all boring now, kinda like php but with a bit of a better rep. I'm not sure actually why php and ruby are so despised.
- Nextgrid 6y ago
  > php I personally quit PHP around 2013 because of the inconsistent standard library. I spent more time looking up the docs than developing because the language just wasn't intuitive compared to let's say Python. However, beyond that, PHP has some pretty great frameworks nowadays (and I am forever grateful to Laravel for teaching me the concepts of an MVC framework, which proved useful when I switched to Django).
- jaredcwhite 6y ago
  I'm a committed Rubyist but I'd jump into using PHP/Laravel in a heartbeat if I couldn't use Rails any more. It seems way more sensible and well-designed than the terrible state of affairs you find in JS backend land. (shudder!)
ksec 6y ago
It is a combination of factors. It is not that Ruby suddenly popular again, the scaling issues is still there, Scaling not impossible but mostly have to do with being expensive. If you are an average dev in UK or US with 100K+ Salary of course scaling is cheap. But not everyone has that luxury or operate on the same budget. But the combination of Ruby and Rails getting faster and Hardware is finally getting cheaper. ( 128 Core EPYC, on a 2 Socket Server Changes the Unit Cost of Core per VM across the whole industry ) Along with wages rises across other part of the world. And the world has finally woken up to may be Javascript Ecosystem isn't exactly what they have hoped for in the backend.

jspash 6y ago

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 hipsterism to the JS community and marvel as they reinvent wheels over and over again.

deleted 6y ago
[deleted]
rualca 6y ago
> (...) 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 also ignoring experience, and prior onboarding into a language stack, which automatically means odds are anyone onboarding into the project will quickly be up and running. Speaking as someone who was forced to onboard into a Ruby project just because a predecessor jumped on the bandwagon, the experience was an unmitigated disaster. A minor onboarding task that consisted of tweaking a hard codes settin in a module required me and a couple of colleagues to spend a few days a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with idiomatic Ruby, d) learning how to troubleshoot and debug Ruby applications, e) properly setup a software dev environment, and f) finally fix the issue. 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. How does can this sort of snafu pass off as the right tool for the right job?
- derwiki 6y ago
  It sounds like more than RoR. Anecdata counterpoint: I’ve worked on a few RoR projects that were well architected and only took me a few days to fully ramp up.

Dunedan 6y ago

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

alerighi 6y ago
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.
- k__ 6y ago
  Thundra offers online and offline debugging. Also, AWS SAM CLI allows to run things locally.

dkobia 6y ago

You can have the best of both worlds with Ruby Jets https://rubyonjets.com/ 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.

nobody0 6y ago

X as a service seems easier at first because complexity is hidden, but it's not going away. Old boring stacks can still go a long way for small/medium projects.

deleted 6y ago

[deleted]

mt42or 6y ago

"You don't need serverless"

deleted 6y ago
[deleted]

knodi 6y ago

Serverless for web apps have one big issues. The cold starts of lambda(s) can be over .5-1 seconds at peek times (us-east-1) any way.

k__ 6y ago
Thete are multiple solutions to that problem. 1. API Gateway and AppSync integrate directly with many other AWS services, no Lambdas needed, and thus no cold-starts. 2. Lambda has provisioned capacity. 3. Other cloud providers like Cloudflare offer FaaS without cold-starts.
- ricketycricket 6y ago
  > 2. Lambda has provisioned capacity. I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?
  - k__ 6y ago
    I think so, that's why I usually try to avoid it. But I guess it's the last resort if you absolutely have to use a Lambda without cold-start
  - freehunter 6y ago
    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 football). There’s going to be times when no one is using your application but when they do, there are going to be dozens or hundreds of people suddenly using it. So the first person that logs on hits the provisioned Lambda instantly and then AWS warms up the rest of the Lambdas as more traffic comes in.
    - VWWHFSfQ 6y ago

thismodernlife 6y ago

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 either via Heroku, via the new Digital Ocean k8s app cluster or – and this is my new favourite tool – using Hatchbox.io to deploy apps to Digital Ocean or AWS. It’s a dream!

luxurytent 6y ago
Replace Rails with Django and this comment seems to hold true for many in the Django community. Boring can be good.
- sodapopcan 6y ago
  Boring tech is great if your primary concern is writing business logic. Ideally, this should always be true, but of course the reality is that people's jobs often have them working on products they don't really care for. And of course, it's easy to get distracted by tech anyway. Experience also comes into play when it comes to loving "boring" tech—it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic. I still love refactoring, though :)
  - joelbluminator 6y ago
    > it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic It's comforting to see I'm not alone. I just wanna ship clean code and contribute value to the business, while all the young bucks in my team are more interested in rewriting our REST apis in Graphql (with all kinds of rationalizations). Looks like the younger you are the more eager you are to explore new tech and the older you are the more keen you are in just delivering value in a boring old stack.

nickthemagicman 6y ago

I do know what OP means. Aren't there any good serverless frameworks that simplify this complexity?

ignoramous 6y ago

Serverless has its place. I am not sure if I'd chose to build a shopping cart on Serverless just yet (Next.js' recent forays notwithstanding), but for something that is stateless (like content distribution, capturing metrics and logs, serving static webpages)...oh, is it a breeze. That said, I see many promising upstarts and incumbents in the space trying to make stateful Serverless easier by the day. Things can only improve and improve they will. I'm bullish.

troughway 6y ago

I'm looking at Blazor/wasm nowadays and it's causing me an awful lot of nostalgia when I think back to the early days of Rails (if '08 can be called early days per-se), because of the shit show back then with various tech stacks and the grunt work required to get a site up with some DB backed data source and whatnot. And I feel like today we are back to some kind of a point of having to shoehorn FE/BE tech together unless we use some isomorphic approach which, predominantly, forces the use of JS. And I remember DHH commenting on this regarding Java and saying something to the tune of "Why would I write Java when Ruby is so much better?". Back then I thought such a statement was too indignant, like someone getting on their high horse about a particular kind of building material that is better above all else. But nowadays, I see the wisdom behind it all the same. I just want simple bloody tech that treats the browser as a layout and input handling engine and lets me write code in any language I see fit, whether it's Ruby, F#, C#, Clojure, whatever. I'm hoping Blazor or something like it can deliver on that vision.

hu3 6y ago
Server side Blazor is promissing to me. Simpler development by merging frontend and backend into one C# codebase but might not work well on unstable connections due to websockets. Some of my clients fall into this case. I'm keeping a close eye on it. I also need to test how it scales with regards to handling traffic.

polote 6y ago

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

leptons 6y ago
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.

0x445442 6y ago

Having worked with AWS serverless for a couple of years, I think the architecture is not well suited for replacing a monolithic application. If horizontal scaling is an issue, I think containers are better suited. Serverless seems to be a better fit for ETL/Data Transformation workflows.

ledauphin 6y ago
serverless (well, lambdas) would be very expensive for any truly significant ETL work. if you have long-running jobs of any kind, that's precisely the opposite of where serverless shines.

VWWHFSfQ 6y ago

I pretty much just start all of my projects, no matter how small, with Django. Working with microframeworks or serverless is great at first but as soon as you need any more of the typical features that a webapp requires then you start pulling in dependencies or re-implementing half of Django yourself anyway. First you just need a little url router to some basic views. OK that's great, anything can do that. Now you need to validate some forms. Now you need to manage some session cookies. Now you need to let users reset their passwords. Now you need to look at your data and maybe export a csv. It just goes on and on.

rangoon626 6y ago
What you wrote about is something that I really struggled with wrt serverless when I first started learning it. Lambda, at this point, feels to me like doing a php project without using any framework. You are doing it all yourself, all the tedious stuff. I have started to mix Zappa and Django to get the best of both Django and Serverless. So far, I like it. I have not hit any considerable scale yet, so I wonder if Django is too heavy, or just right. It seems fine so far. The other plus - it’s all open source tech, so it’s easy to move away from Lambda if I need to. It’s even better, too, because you CAN break out some more isolated functionality into stand alone lambdas when they start to get clumsy inside a typical Django proj.

rkangel 6y ago

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.

bdcravens 6y ago
> You have options like LiveView for your frontend Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)
- rkangel 6y ago
  The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix. I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smart guy and an excellent developer who's opinion I therefore give some weight to.
  - jaredcwhite 6y ago
    No doubt, but there are some pretty awesome wizards working on StimulusReflex (and CableReady which it sits atop) as well, so I think it mostly depends on if you're keen to program in Elixr or Ruby.
heipei 6y ago
I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?

sam0x17 6y ago

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.

sam0x17 6y ago

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.

freedomben 6y ago
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?
- Can_Not 6y ago
  I've used crystal (mostly kemal) for almost 1 year and the updates have not been too often and have not broken much.
- sam0x17 6y ago
  Crystal itself has stabilized quite nicely. Amber/lucky are a bit slow to update, but all of my production apps use either Kemal or Spider Gazelle which are too lightweight to matter in that regard.

cayblood 6y ago

Did you consider Step Functions for taming some of this complexity?

nickjj 6y ago

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.

helsontaveras18 6y ago
Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development). Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud. Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.

grose 6y ago

I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP server and let an adapter handle the lambda bits[1]. During development you run it as a regular HTTP server and connect directly to localhost. To deploy it all you need is a shell script that zips and uploads your binary to lambda. All state is stored in DynamoDB. One log stream for everything. The downside is dealing with AWS events. There’s a few ways to handle it. You can write it into your monolith, toggling behavior with say an environment variable. You can sometimes work around it, for example avoiding the S3 file uploaded event by having clients ping your HTTP API on upload completion. Of course, there are trade offs for all the techniques. You can easily reconfigure a lambda to retry on failure but you’d have to manually implement that client-side. You can also always just add another lambda if you’re ready. To put it another way: you probably don’t need to write that record to a queue which gets written to DynamoDB, whose stream calls another lambda etc etc. Just do that stuff within a regular old HTTP handler until the fanciness is absolutely necessary. For personal projects, I appreciate how serverless scales to zero. I don’t have to worry about axing projects with minimal usage. [1] for example https://github.com/akrylysov/algnhsa https://github.com/akrylysov/algnhsa or https://github.com/awslabs/aws-lambda-go-api-proxy https://github.com/awslabs/aws-lambda-go-api-proxy

earthboundkid 6y ago
This is what I’ve been doing with Go on Netlify (which is a wrapper around AWS Lambda). https://blog.carlmjohnson.net/post/2020/how-to-host-golang-on-netlify-for-free/ https://blog.carlmjohnson.net/post/2020/how-to-host-golang-o...

alexellisuk 6y ago

How are you finding managing infra for rails? Is disaster recovery quick for you? I'm the author of openfaas and hear what you say about the fragmentation for using AWS Lambda. We recently made a rails-esq version of OpenFaaS for users who have a single small app like yourself. I would be interested in your impressions. It's all open source and is a bit more of a more modern stack. On the upside it uses containers and you can write in any language. https://www.openfaas.com/blog/faasd-tls-terraform/ https://www.openfaas.com/blog/faasd-tls-terraform/

weeboid 6y ago

One thing you have to realize, is that "enterprise" architectures are as much about workforce management as they are about efficiency, or scalability, or et al. There's a limit to how reduced data, and functions that work on data, and the transports and relationships between it all, can get. Let's call this residual mass "goo". Well, the goo has to go _somewhere_.

g8oz 6y ago

Has anyone tried TruffleRuby in a project yet?

desireco42 6y ago

I moved to Phoenix and it is wonderful. Except... Ecto just isn't as easy as ActiveRecord and you can't do things the way you would prototype things in IRB. So, yeah, on one hand, I have crazy performance and LiveView etc, but on other, it is huge hassle just to hack around the way I did before.

techthumb 6y ago

In OO systems, we often talk about "Simple Objects & Complex Interactions" v/s "Complex Objects & Simple Interactions". In my experience, being at either extreme becomes counter-productive. To me, it comes down to finding the "happy middle" for your project. Monolith v/s Micro-services/Serverless are similar. Neither extreme is productive. There exists a happy middle depending on the situation.

akhilcacharya 6y ago

Seems to me that the ideal would be a heavier-weight convention-over-configuration framework that "compiles down" to Cloudformation + Lambda code.

liquidwax 6y ago

AWS Amplify[1] actually has neat tooling for serverless projects and lets to deal with just the core of your product and worry less about infra. Admittedly, it helps if you know the underlying connections but in my experience that's true with rails too. Building a blog with rails isn't the same as a more complex product. [1] https://aws.amazon.com/amplify/ https://aws.amazon.com/amplify/

helsinkiandrew 6y ago

I’m not sure the issues experienced are due to serverless rather than the architecture chosen. A monolithic app vs services. Why split up the serverless functionality into separate functions connected with SNS etc? You can call the same ruby code from a single serverless lambda endpoint invoked from a http call in the same way you would from a rails process. Rails is great, but you could run Rails on a serverless architecture (AWS) too if you really wanted to, and you could create a multi service architecture of Rails components that would be equally hard to maintain and develop.

ptman 6y ago

You could probably deploy your RoR service using Google Cloud Run.