6 ms·

> how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. So

by Volpe 15y ago

> how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. So how many? I've hardly heard of this as the 'norm' for growing companies on rails... ? This sounds like 'Does Rails Scale' FUD. Getting your app into production is not a pain point at all, services like heroku, or engineyard have made this as simple as 'git push'. Which nirvana of release management are you coming from where this is a 'pain point' ?

gtani 15y ago
I've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.
- nirvdrum 15y ago
  Given how different the two of those can handle things, particularly with dependencies, that strikes me as a bad idea. I'm not even sure I'd trust it to CI. This isn't academic either. I'm contemplating moving to JRuby. I really think I'd be more comfortable with my local dev environment matching my deployment environment.
philwelch 15y ago
Heroku exists because Ruby deployment is a major pain point and developers are willing to embrace serious architectural limitations and high rates in exchange for willing this problem away. I'm not down on Heroku at all, I think they're brilliant, but "use Heroku" isn't a universally viable technical solution to this problem.
- Volpe 15y ago
  Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deployment is always going to be a task that is required. Rails has for a long time had pretty good solutions to this. I'm objecting to the parent stating that deployment is a serious pain point for rails. I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?
  - deleted 15y ago
    [deleted]
  - regularfry 15y ago
    Rsync.
  - flocial 15y ago
    I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple. But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word. I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
  - nasmorn 15y ago
    PHP. I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy. For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
    - bad_user 15y ago
      Deployment of PHP is the same as deployment of static HTML Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team. For rails you need to understand version control, webservers and scripting No shit - those things are required in PHP too, unless you're building a contact form. you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life. Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
- bad_user 15y ago
  Heroku exists because Ruby deployment is a major pain point No dude, Heroku exists because dealing with hardware, OS configuration and updates and maintaining a scalable infrastructure (that can be upgraded to how many servers you want, or downgraded) with a sane deployment workflow is a major pain in the ass, no matter the dev tools you're using. In fact, I found the deployment story of Rails (with the help of Rvm, Rake, Bundler, Capistrano and Passenger) to be the best one yet and no other environment can really match it (although you get pretty close with Python, Django, VirtualEnv, Pip, Fabric and mod_wsgi for example). And I'm not using something like Heroku btw, as I consider it to be seriously overpriced - I'm maintaining my own Linux servers on top of EC2 (which still involves pain, that I can handle nonetheless, but then again I also have sysadmin skills). Deployment for me is literally just "git push && cap deploy".

by Volpe 15y ago

gtani 15y ago

I've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.

nirvdrum 15y ago
Given how different the two of those can handle things, particularly with dependencies, that strikes me as a bad idea. I'm not even sure I'd trust it to CI. This isn't academic either. I'm contemplating moving to JRuby. I really think I'd be more comfortable with my local dev environment matching my deployment environment.

philwelch 15y ago

Heroku exists because Ruby deployment is a major pain point and developers are willing to embrace serious architectural limitations and high rates in exchange for willing this problem away. I'm not down on Heroku at all, I think they're brilliant, but "use Heroku" isn't a universally viable technical solution to this problem.

Volpe 15y ago
Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deployment is always going to be a task that is required. Rails has for a long time had pretty good solutions to this. I'm objecting to the parent stating that deployment is a serious pain point for rails. I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?
- deleted 15y ago
  [deleted]
- regularfry 15y ago
  Rsync.
- flocial 15y ago
  I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple. But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word. I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
- nasmorn 15y ago
  PHP. I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy. For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
  - bad_user 15y ago
    Deployment of PHP is the same as deployment of static HTML Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team. For rails you need to understand version control, webservers and scripting No shit - those things are required in PHP too, unless you're building a contact form. you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life. Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
bad_user 15y ago
Heroku exists because Ruby deployment is a major pain point No dude, Heroku exists because dealing with hardware, OS configuration and updates and maintaining a scalable infrastructure (that can be upgraded to how many servers you want, or downgraded) with a sane deployment workflow is a major pain in the ass, no matter the dev tools you're using. In fact, I found the deployment story of Rails (with the help of Rvm, Rake, Bundler, Capistrano and Passenger) to be the best one yet and no other environment can really match it (although you get pretty close with Python, Django, VirtualEnv, Pip, Fabric and mod_wsgi for example). And I'm not using something like Heroku btw, as I consider it to be seriously overpriced - I'm maintaining my own Linux servers on top of EC2 (which still involves pain, that I can handle nonetheless, but then again I also have sysadmin skills). Deployment for me is literally just "git push && cap deploy".