Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My short history of Engine Yard and my Resignation

brainspl.at

Post reply on HN
Print view View original

11–20 of 76 posts

Re: My short history of Engine Yard and my Resignation

#11

Post by rossedwards »

mileszs wrote: post #8
jasonkester wrote: post #4

Well written. I had never heard of the author or his company, yet unlike so many of the articles that come through here, it had enough context baked in that you could follow it without a Google search. I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?

I'm not positive as to what you specifically are referring. There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard. There was a time when administering a Rails app was a much more hairy proposition than it is today, though.

Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.

Re: My short history of Engine Yard and my Resignation

#12

Post by keeran »

jasonkester wrote: post #4

Well written. I had never heard of the author or his company, yet unlike so many of the articles that come through here, it had enough context baked in that you could follow it without a Google search. I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?

Rails doesn't need any hand-holding any more. Apache+Passenger take care of most cases, Nginx+unicorn/mongrel take care of the rest.

Big, heavy traffic apps require special attention, but then that's the same for all big/heavy apps.

Re: My short history of Engine Yard and my Resignation

#13

Post by betageek »

rossedwards wrote: post #11
mileszs wrote: post #8

Earlier quoted context omitted.

I'm not positive as to what you specifically are referring. There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard. There was a time when administering a Rails app was a much more hairy proposition than it is today, though.

Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.

mod_rails/Passenger changed the game on deployment of Rails - Rails deployment is no harder than PHP if you use Passenger/Apache. Most of the 'Rails is hard to deploy' opinions are just relics from the bad old days.

high volume/high availability setups can be complicated, but that's the same all over...

Re: My short history of Engine Yard and my Resignation

#14

Post by thibaut_barrere »

jasonkester wrote: post #4

Well written. I had never heard of the author or his company, yet unlike so many of the articles that come through here, it had enough context baked in that you could follow it without a Google search. I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?

It doesn't need that level of hand-holding, really, these days. A few years back it was a bit more difficult. Today the options are well known and really usable by a beginner (eg: passenger).

EngineYard brings a premium service, but none of my customers have been interested to pay the premium. They all go on SliceHost, Joyent, or home-hosted machines.

Sidepoint: around me, most non-rubyists developers don't deploy their apps themselves, whereas all the people I know who work with Rails or Sinatra do deploy themselves. I believe this may be thanks to Capistrano et al, maybe.

Re: My short history of Engine Yard and my Resignation

#16

Post by mileszs »

rossedwards wrote: post #11
mileszs wrote: post #8

Earlier quoted context omitted.

I'm not positive as to what you specifically are referring. There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard. There was a time when administering a Rails app was a much more hairy proposition than it is today, though.

Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.

Interesting. I'm a full-time Ruby and Rails developer, and I host/manage a few Rails sites personally. I'd beg to differ with whom you've been speaking. As betageek said, mod_rails makes it a breeze, plus it can be used with either Apache or Nginx.

Re: My short history of Engine Yard and my Resignation

#17

Post by mechanical_fish »

davidw wrote: post #5

I still don't entirely get their model. They have all this rails deployment expertise, but you pay a more less flat fee every month, whether you're drawing on their knowledge a lot or a little. I think I'd prefer to pay less for hosting, and have some experts on retainer for when they're really needed. They're cool people in any case, and I wish them good luck.

A. If you are paying a monthly fee, what difference does it make if that fee is called a hosting cost or a retainer?

B. You will ultimately either pay more, or get less value, if you decouple your expert support from the specific hardware platform that your expert support understands best and lives with every day.

C. If you only pay your experts when there is an emergency, there is no incentive for anyone to help you avoid having emergencies. Nor will there be anyone but you to look out for emergencies before they happen, or prevent emergencies by doing routine work like testing and applying patches. And you will have to get really good at finding freelance experts and convincing them to drop everything, reorient to your system, and fix your problem in a matter of minutes as your server is in flames; you may have to pay premium prices for that. It might be cheaper to just pay the insurance bill.

Disclaimer: I work at Acquia on Acquia Hosting, a product which is like an EngineYard for Drupal.

Re: My short history of Engine Yard and my Resignation

#18

Post by donw »

Oh wow, memories... my first sysadmin job had our servers in the same datacenter, in 2000. It was originally called Wavve, and had been built with dot-com VC, so they had all the toys -- biometric identification, massive stacks of batteries, Starbucks-inspired architecture, riot-proof glass...

Re: My short history of Engine Yard and my Resignation

#19

Post by bl4k »

dabeeeenster wrote: post #10

"We just were victims of our own success and could not deploy customers fast enough to get free time to build the automated system that AppCloud is today." This is a really hard problem IMHO. Obviously it depends on your business model, but I've found it at times an unsolvable problem...

hire contractors (or setup a team) and isolate them from the rest of the business. happens in both small and large companies all the time.

Re: My short history of Engine Yard and my Resignation

#20

Post by davidw »

mechanical_fish wrote: post #17
davidw wrote: post #5

I still don't entirely get their model. They have all this rails deployment expertise, but you pay a more less flat fee every month, whether you're drawing on their knowledge a lot or a little. I think I'd prefer to pay less for hosting, and have some experts on retainer for when they're really needed. They're cool people in any case, and I wish them good luck.

A. If you are paying a monthly fee, what difference does it make if that fee is called a hosting cost or a retainer ? B. You will ultimately either pay more, or get less value, if you decouple your expert support from the specific hardware platform that your expert support understands best and lives with every day. C. If you only pay your experts when there is an emergency, there is no incentive for anyone to help yo…

> A. If you are paying a monthly fee, what difference does it make if that fee is called a hosting cost or a retainer?

I have more latitude when I put the pieces together: hosting here, retainer there.

> C. If you only pay your experts when there is an emergency, there is no incentive for anyone to help you avoid having emergencies

That's a fair point, but on the other hand, it also seems that if you're paying an 'expert surcharge' on your hosting, your incentive is to get as much out of that as possible, whereas the experts, getting a flat fee, can't act as de-facto consultants without eating up all their margins that way. There's something of a conflict there. How do you guys define exactly what your role is?

Also, presumably someone is developing the code to be hosted there. The better they are, the more likely it is that they'll be able to do a good deployment and monitor it on an ongoing basis.

Post reply on HN