4 ms·

I have been running a product since 2015 and I feel the author's pain. The original tech I used was Ruby on Rails, and it was great (back in Rails 5). However,

I have been running a product since 2015 and I feel the author's pain. The original tech I used was Ruby on Rails, and it was great (back in Rails 5). However, with Rails 7 and all the other changes since 2015, the debt was pretty overwhelming. Updating dependencies became difficult. Deploying a new server felt impossible. It felt like it was held together with toothpicks and glue. Afraid to update X because Y would break. I couldn't update Y or Z would break. Unlike the author, my product was making actual money ($XXX,000). I ended up completely rewriting the product from scratch (took ~3 months). I just swapped the old Rails service out for the new service on April 1st. I stuck to "simple and boring" tech for the new stack. No more Rails, etc.

asvitkine 4y ago
What was the new tech stack?
binarymax 4y ago
Lol I thought the appeal of rails was that it is “simple and boring”! Congrats on having the gumption to do a rewrite. I’m curious what are the more detailed decisions you took to better future proof? Given how often things shift in our world, I feel like anything I choose now will just end up being obsolete and annoying to maintain in a 5+ year timeframe.
- nullbytesmatter 4y ago
  Great question-- and may be worth a detailed/thought out blog post some day! To future proof the service I wanted to use tech that was based on the fundamentals. This boiled down to no special tooling, no special build process, etc. Furthermore I cut out all dependencies I could. I got my third party dependencies down to two (postgres + nginx). Practically speaking this meant: no node, no yarn, no ruby, no webpack, no sidekiq, no redis, etc. The entire service is now Nginx, Postgres and a single binary that has html/css/js/assets embedded inside of it. The entire product is a single Go binary that connects to postgres-- that's it. I could probably do without Nginx, but it has been nice for a variety of reasons and has never given me a headache. My tech/decisions may not be for everyone (that is why I didn't share them initially) but it works incredibly well for me and most products I build.
  - binarymax 4y ago
    Thanks for the reply! Would enjoy a blog post. I'm guilty of embedding HTML inside of a Rust binary, but it was more do fix an immediate dependency hassle and never thought about it as a long term solution...but maybe it's not such a crazy idea after all.
art-vandelay 4y ago
What stack did you end up moving to?
the_biot 4y ago
IMHO the solution to retaining control of an app that wants to sprawl out is to set up the dev and prod environment via ansible/puppet/similar, into an otherwise bare VM or container, with only a forward proxy to reach it. Doesn't mean your application isn't going to sprawl, but you will at least have a complete list of all its moving parts at all times, and changing them out can at least be done in a controlled way. Still, it sounds like SSLPing's problem (and yours) was mostly bitrot, and no amount of ansible will cure that.
ezekg 4y ago
I'm curious what was so hard about upgrading from Rails 5 to Rails 7. The upgrade from 5 to 6 was smooth for me, and 6 to 7 was even smoother. Seems like a rewrite would be way more effort.
- nullbytesmatter 4y ago
  There were many factors. Rails itself isn't too bad to upgrade, but the problem boiled down to various Rails engines (active admin, etc). There came a point where I sat down and had to decide if it was worth de-tangling the mess and potentially breaking a lot of things to upgrade Rails and the various dependencies (only to do this again in 5 years), or possibly build things in a way that would work regardless of the dependencies. Sure-- the rewrite was more effort up front but the hope was the long term compounding benefits would be worth it. I don't generally advocate for rewrites but in this case I went for it (and actually got it done).
phendrenad2 4y ago
Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Also, the main benefit of the framework (keeping a sane structure while multiple developers' are making code additions) isn't any better than just ad-hoc sharing standards and practices amongst the team. So, it's better to use a simple nodejs server or even plain old php pages. Once you get past a certain number of developers, the constant overhead is something that still needs to be dealt with, but relative to the human-hours of your entire team, it's much smaller. Also, the team is no longer able to ad-hoc share architectural goals, and so having a framework in place that enforces them scales much better. Starting with a framework is tempting because everyone thinks that they'll get big. But what if you don't? Maybe it's better to have a little passive income than crash and burn. On the other hand, if you do get big, the tradeoff is that you'll need to rewrite with a framework. That's another opportunity to crash and burn, so it's debatable which is better. Personally I think that Twitter has demonstrated how to do the "start dead-simple and rewrite as the team grows" method.
- epalm 4y ago
  > Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Many years ago I used to write projects with Python/Django. The Django project releases 3-year LTS versions with 3-month overlap. LTS versions are supposed to ease the constant upgrade overhead, and hitting a 3 month window every 3 years doesn't seem too bad, especially when they also release documentation specifically guiding you from one LTS version to the next. Does Ruby/Rails not do this?
  - phendrenad2 4y ago
    3 years isn't all that long. There's still Fortran and Cobol in the wild from 40 years ago. Most people in silicon valley will have worked on a 20 or even 30 year old codebase at some point. And why do I need to upgrade Django? Did the fundamental principle of MVC change? No, the developers of Django just didn't like some Python 3.8 syntax and decided to rip it out and replace it with some shiny new thing in 3.9. They stopped backporting security fixes to the old Django version, the one with the totally-gross Python 3.8 syntax. So now, to use the latest Django version, you need to upgrade Python minor version also. Easily avoided if you rolled your own framework. (Of course, sometimes you don't have a choice, because maybe Python deprecated some perfectly-good syntax between 3.8 and 3.9 because the devs didn't like it anymore). Another thing is, that's every 3 years for Django. If you start stacking other 3rd party dependencies on top of Django (even something as simple as a MongoDB ORM), you'll have a separate, secondary upgrade schedule for that library.

asvitkine 4y ago

What was the new tech stack?

binarymax 4y ago

Lol I thought the appeal of rails was that it is “simple and boring”! Congrats on having the gumption to do a rewrite. I’m curious what are the more detailed decisions you took to better future proof? Given how often things shift in our world, I feel like anything I choose now will just end up being obsolete and annoying to maintain in a 5+ year timeframe.

nullbytesmatter 4y ago
Great question-- and may be worth a detailed/thought out blog post some day! To future proof the service I wanted to use tech that was based on the fundamentals. This boiled down to no special tooling, no special build process, etc. Furthermore I cut out all dependencies I could. I got my third party dependencies down to two (postgres + nginx). Practically speaking this meant: no node, no yarn, no ruby, no webpack, no sidekiq, no redis, etc. The entire service is now Nginx, Postgres and a single binary that has html/css/js/assets embedded inside of it. The entire product is a single Go binary that connects to postgres-- that's it. I could probably do without Nginx, but it has been nice for a variety of reasons and has never given me a headache. My tech/decisions may not be for everyone (that is why I didn't share them initially) but it works incredibly well for me and most products I build.
- binarymax 4y ago
  Thanks for the reply! Would enjoy a blog post. I'm guilty of embedding HTML inside of a Rust binary, but it was more do fix an immediate dependency hassle and never thought about it as a long term solution...but maybe it's not such a crazy idea after all.

art-vandelay 4y ago

What stack did you end up moving to?

the_biot 4y ago

IMHO the solution to retaining control of an app that wants to sprawl out is to set up the dev and prod environment via ansible/puppet/similar, into an otherwise bare VM or container, with only a forward proxy to reach it. Doesn't mean your application isn't going to sprawl, but you will at least have a complete list of all its moving parts at all times, and changing them out can at least be done in a controlled way. Still, it sounds like SSLPing's problem (and yours) was mostly bitrot, and no amount of ansible will cure that.

ezekg 4y ago

I'm curious what was so hard about upgrading from Rails 5 to Rails 7. The upgrade from 5 to 6 was smooth for me, and 6 to 7 was even smoother. Seems like a rewrite would be way more effort.

nullbytesmatter 4y ago
There were many factors. Rails itself isn't too bad to upgrade, but the problem boiled down to various Rails engines (active admin, etc). There came a point where I sat down and had to decide if it was worth de-tangling the mess and potentially breaking a lot of things to upgrade Rails and the various dependencies (only to do this again in 5 years), or possibly build things in a way that would work regardless of the dependencies. Sure-- the rewrite was more effort up front but the hope was the long term compounding benefits would be worth it. I don't generally advocate for rewrites but in this case I went for it (and actually got it done).

phendrenad2 4y ago

Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Also, the main benefit of the framework (keeping a sane structure while multiple developers' are making code additions) isn't any better than just ad-hoc sharing standards and practices amongst the team. So, it's better to use a simple nodejs server or even plain old php pages. Once you get past a certain number of developers, the constant overhead is something that still needs to be dealt with, but relative to the human-hours of your entire team, it's much smaller. Also, the team is no longer able to ad-hoc share architectural goals, and so having a framework in place that enforces them scales much better. Starting with a framework is tempting because everyone thinks that they'll get big. But what if you don't? Maybe it's better to have a little passive income than crash and burn. On the other hand, if you do get big, the tradeoff is that you'll need to rewrite with a framework. That's another opportunity to crash and burn, so it's debatable which is better. Personally I think that Twitter has demonstrated how to do the "start dead-simple and rewrite as the team grows" method.

epalm 4y ago
> Frameworks like Rails come with a constant upgrade overhead cost. If you're a solo developer, or even a small (<5) team, that overhead is likely to dominate your development time. Many years ago I used to write projects with Python/Django. The Django project releases 3-year LTS versions with 3-month overlap. LTS versions are supposed to ease the constant upgrade overhead, and hitting a 3 month window every 3 years doesn't seem too bad, especially when they also release documentation specifically guiding you from one LTS version to the next. Does Ruby/Rails not do this?
- phendrenad2 4y ago
  3 years isn't all that long. There's still Fortran and Cobol in the wild from 40 years ago. Most people in silicon valley will have worked on a 20 or even 30 year old codebase at some point. And why do I need to upgrade Django? Did the fundamental principle of MVC change? No, the developers of Django just didn't like some Python 3.8 syntax and decided to rip it out and replace it with some shiny new thing in 3.9. They stopped backporting security fixes to the old Django version, the one with the totally-gross Python 3.8 syntax. So now, to use the latest Django version, you need to upgrade Python minor version also. Easily avoided if you rolled your own framework. (Of course, sometimes you don't have a choice, because maybe Python deprecated some perfectly-good syntax between 3.8 and 3.9 because the devs didn't like it anymore). Another thing is, that's every 3 years for Django. If you start stacking other 3rd party dependencies on top of Django (even something as simple as a MongoDB ORM), you'll have a separate, secondary upgrade schedule for that library.