12 ms·

Github and Engineyard part ways

157 points by jcapote 17y ago

mitchellh 17y ago
Does anyone have any idea what host github is moving to?
- jherdman 17y ago
  It doesn't actually say Github is moving. It just says that Github isn't going to be supported by EngineYard in the same way. It's entirely feasible that Github remain at EngineYard. Edit Woops. Looks like I missed the key part of a sentence there. Sorry folks.
  - judofyr 17y ago
    Accordingly, we are currently working directly with their next provider to maintain smooth service as they cut over.
    - jnewland 17y ago
      > From what I understand, we're at the data migration point, and we're waiting on EY for that. s/working directly with/delaying/ http://support.github.com/discussions/site/721-network-feed-and-site-speed#comment_368351 http://support.github.com/discussions/site/721-network-feed-...
  - jcapote 17y ago
    "Accordingly, we are currently working directly with their next provider to maintain smooth service as they cut over." "Provider" really sounds like they are talking about infrastructure
  - deleted 17y ago
    [deleted]
  - teej 17y ago
    That's exactly what the article says: "However, in the end, the best arrangement for them was moving."
- pjhyett 17y ago
  We're moving to Rackspace.
  - judofyr 17y ago
    Cloud or dedicated/managed?
    - pjhyett 17y ago
      Real hardware and lots of it. Once we get moved over and everything's humming along nicely, we'll do a writeup or two about the new infrastructure.
      - jnewland 17y ago
        Nice, I'm really looking forward that to that. I'd love to hear about the transition too - big moves aren't easy, as I'm sure you guys know.
  - datums 17y ago
    that was my guess, you guys have a big dev following, rackspace has marketing money that can be reallocated to hosting github. good luck
  - lsb 17y ago
    What FS will you use? SSDs?
  - jasonjwwilliams 17y ago
    That'll be great...and hopefully address one of concerns about having our private repos sitting on ATAoE storage.
    - tmornini_ey 17y ago
      What concerns are those?
seiji 17y ago
I think they could have worded this better: "GitHub offers the largest free storage quota among the big SCM hosters, and we came to the conclusion that we didn’t want to subsidize that quota for non-Ruby developers." It sounds odd Engine Yard hosts an entire for-profit company for free just in exchange for some complimentary accounts. My imagination tells me GitHub is tired of being slow and Engine Yard couldn't do anything more to help them. Instead of the news being "GitHub Leaves Engine Yard Because It's Too Slow" the news is "Engine Yard Kicks GitHub To The Curb Because GitHub has Non-Ruby Repos." I don't see either headline being positive towards Engine Yard.
- jeremymcanally 17y ago
  > It sounds odd Engine Yard hosts an entire for-profit company for free just in exchange for some complimentary accounts. Well, sort of. It's really a value trade-off. EY offers its customers something that would cost them $50 a month, so it's costing Github (customers) * $50 to offer that. They exchange the lost value for added value in hosting (i.e., they're "losing" a few thousand a month in free accounts for our customers, so we'll offer them free hosting to continue to offer that). It's simple barter.
  - jhancock 17y ago
    Very excited to see GitHub continuing to grow and EngineYard and GitHub handling their barter deals so cordially. Both companies are class acts!!!
- jcapote 17y ago
  That assumes that Github is slow because of their hosting (Engineyard) and not because of how it's written. I dunno, it could go either way for me: "Engineyard drops Github for being too costly" vs "Github needs better hosting, so we're dropping Engineyard"
  - jhancock 17y ago
    Its probably more about costs for both sides. I doubt that EY is _slow_ without regard to cost. Just that instead of rewritting GitHub's web app to deal with inherent performance issues, it makes more sense to throw more hardware at the problem. There does come a point where owning more of your server stack makes more financial sense.
omouse 17y ago
Don't offer a free storage quota or limit how many projects you can host. There, problem solved. The people who leave will no longer be a drain on your servers and the people who stay will be paying for the maintenance of those servers.
- matthewcford 17y ago
  That would kill the majority of open source projects hosted on github, free hosting for public repos is one of the reasons it's so great. I'm willing to pay for private repos, but if I had to pay for my public ones too, I'd just not host them on github.
  - DannoHung 17y ago
    I'd be willing to pay Github for some other premium service besides private repos (they're not of much use to me, tbh). Uhh... can't think of anything off the top of my head that I really need or want though... OH, wait, I know, how about Bespin integration?
  - omouse 17y ago
    Maybe those open source projects should charge a fee as well?
    - wizardofoz 17y ago
      No, people should donate more to open source projects.
- deleted 17y ago
  [deleted]
- bestes 17y ago
  I'm a paying GitHub customer and having big projects like Ruby on Rails and Perl hosted there makes me very comfortable. I figure if they can handle the big stuff, they can handle me! Plus, I use as much free software as everyone else and am happy to help out indirectly (by being a paying customer). I expect prices will rise soon as well. I'm not sure anyone has mentioned this yet, even though it seems inevitable. Still, I think GitHub is fantastic and I'm planning to increase my usage.
stephenjudkins 17y ago
When evaluating hosting providers, the quote Engineyard gave us was tremendously expensive. They offered a great deal of value-added services, but we found that it would be cheaper to go with the second-most expensive option (Amazon EC2) while also hiring a qualified full-time sysadmin. Whether this was a wise choice or not given our experience with EC2 is up for debate. But even if we had gone with Engineyard and had no problems at all it would be hard to justify a couple developer's salaries for it.
- lsb 17y ago
  Just out of curiosity, what were your options that were cheaper than EC2, and why'd you reject them?
  - Periodic 17y ago
    Please, write it up and post it to HN! It deserves its own discussion.
  - stephenjudkins 17y ago
    There were several hosting services that were a good deal cheaper. It costs $576/mo to run an extra large EC2 instance fulltime, while purchasing a server with similar specs only costs $2k or so. The data center across town could give us an equal number of server power for much cheaper. We're in our own data center right now, in another city, and we simply have a contractor we pay to go in and occasionally replace broken equipment. It really is quite cheap to do it this way. Various hosts offered greater degrees of managed services at various prices. None really offered the flexibility that EC2 offered, or offered that much over simply colocating our own servers. With less traffic or fewer servers I can see many of these hosts being a great deal. There also were several places that gave us completely screwy quotes that I can imagine were only meant to trick CEOs who don't know any better. One example is a place that offered us the use of an HTTP load balancer for the "low, low price" of $1000 a month. A lot of places offered expensive managed services, but when talking to the people who would serve us it was clear they didn't know what they were talking about. We did not seriously consider these places. To Engineyard's credit, they were only managed host who sounded like they had knowledge that would be really valuable to us. They also made clear that they would devote significant resources to getting our site working smoothly. We would have paid a premium for this service, but not the premium they asked. EC2 offers an amazing amount of flexibility that we found highly valuable. A sysadmin and developer spent most of a day diagnosing an issue with a DB server that ended up being a flaky drive. In EC2, we would have simply killed the server, fired up a new instance, waited an hour for its replication to catch up, and returned it to the rotation. To return to EC2 we would have to drastically reduce the load on our MySQL instances, since we found that EBS volumes had somewhat unpredictable and not that great performance. Reducing our reliance on MySQL is something we're doing anyways, since on its current course it would have been difficult and expensive to continue scaling up in any data center.
datums 17y ago
Bottomline, it's a business decision, I'm sure if staying with EngineYard was an option they would have gone that route. Moving to EC2 is probably a lot cheaper than other pricey, like RackSpace solutions. It's part of growing up, you sometimes have new friends, but never forget those you grew up with. I wonder how many new EY customer use their github accounts ?
davidw 17y ago
> We identified the bottlenecks and supported GitHub and the community by making patches to ssh to allow key lookup in MySQL rather than a text file. That remains, to this day, one of the finest examples of Engine Yard support and it makes me extremely proud just thinking of it. This seems... odd to me. It doesn't feel like the right boundary between businesses. From a hosting provider, I expect good, steady service, reboots, a root console, and that they'll fix anything that's on their end (hardware, for instance). Patching ssh is development work, and is something I would expect to pay for to meet specific goals, but not something that comes as part of my hosting package. I mean, what if you are just cruising along, and don't need any deep hacking over a couple of months. Is your money being wasted? With actual developers, I could redeploy them to do other things. Can I do that with EY? They seem like really good, sharp guys, but I don't quite get the business, I guess.
- tedunangst 17y ago
  Maybe the developers building apps that run on EY aren't the best developers to be patching ssh? Is your money wasted if you hire a lawyer on retainer and don't ask enough questions?
  - davidw 17y ago
    EY publicizes their Ruby expertise, not their 'hack on security-critical crypto code' expertise, and while it's impressive, and to their credit that they were able to do it, it still leaves me thinking that a fixed monthly fee is the wrong way to pay for that kind of talent. > if you hire a lawyer on retainer and don't ask enough questions? At a certain point, yes.
- tmornini_ey 17y ago
  From our perspective, it was a matter of helping our partner and the Ruby community succeed. We're working really hard to make Ruby on Rails succeed. This is just one of the many ways that we've pitched in to help it do so. If, during that downtime, when the "Twitter's problems are Ruby on Rails" FUD was running high, would anyone believe that a Github scale failure wasn't a Ruby on Rails problem? We weren't willing to test it, so we solved the problem, i.e. we put our money where our mouth is -- That Ruby on Rails scales just fine, the bottlenecks are generally elsewhere.
tmornini_ey 17y ago
Hey all. Wanted to chime in the discussion. My blog post is direct and to the point. There's honestly no mystery about this, I laid out all the details, possibly excepting one. We designed our infrastructure offering 3 years ago. We knew that the vast majority of websites would produce nearly read-only file I/O. GFS's less than stellar write performance isn't a problem in that typical case. Along comes Github, and they have an entirely different disk I/O profile to the rest of our customers. Github was built on a shared-something architecture because GFS made it quick and easy to get up and running, developing features, and attracting users. This is a good thing! Github has been very vocal about their dislike of the GFS filesystem we use for shared filesystem access. GFS doesn't scale forever, and we've never suggested it does. It could scale far larger than it has at Github, but fizx hit the nail on the head: we weren't willing to do it for free, and Github was unwilling to pay our price. We warned Github many, many moons ago that given their growth rate, in order to scale their application smoothly and inexpensively, a shared-nothing architecture was eventually going to be needed. We offered to help them with that architecture, as we saw Github running wonderfully atop a cloud service such as EC2. Rather than do the re-architecture now, they've chosen instead to move to a vendor who can provide them a high performance, high availability, non-commodity, proprietary network file server infrastructure. I suspect it will work well for them, and we'll all enjoy a faster Github. :-) From my perspective, I really want everyone to understand that there's no bad blood on the EY side, and hopefully none on the Github side. Business is business, decisions need to be made each and every day.
- defunkt 17y ago
  Rather than do the re-architecture now, they've chosen instead to move to a vendor who can provide them a high performance, high availability, non-commodity, proprietary network file server infrastructure. I suspect it will work well for them, and we'll all enjoy a faster Github. :-) GitHub has been working on a re-architecture since our last major feature release, which was GitHub Issues in April. And we can't wait to roll it out.
  - tmornini_ey 17y ago
    Great news, Chris, sorry to misrepresent. So, the new Github architecture is shared nothing?
calambrac 17y ago
Jesus Christ, there's a lot of drama-mongering in this thread. Grow the fuck up, it's a business decision that both sides had an interest in seeing happen.
callmeed 17y ago
Does this mean I'll no longer get a free GitHub account as an EngineYard customer? EDIT: N/M, found the answer. Does this mean I can have a free GitHub account because I'm also a Rackspace customer :)
yesimahuman 17y ago
Engine Yard and Github's business relationship aside, is anyone else sick of everything these days being about the tool or language people are using? For some reason we hear more from the Ruby side than any other about how great their language is, but frankly the only thing that matters are the products made from it. I don't know, I'm just kind of sick of Ruby fan boys.
- adw 17y ago
  I'm a Python guy, and that community's both sinned against and sinning. You have prominent Ruby guys claiming there's no momentum - Youtube, Friendfeed, Dropbox, loads of newspapers - behind the language. But, then, I'm chippy enough to notice... It's the Perl community who just seem to get it done. Amazon and BBC iPlayer have more traffic than most of us, I bet!
- carbon8 17y ago
  "we hear more from the Ruby side than any other about how great their language is" Um, that crown unquestionably goes to a big chunk of the python community right now. Reddit alone provides a steady stream of both extreme fawning over python and vitriol targeted at ruby, and your comment and its upvotes demonstrate that it's present here, as well. It's also quite a colossal double standard to complain about Ruby-specific hosts considering the existence of GAE, all the django-targeting hosting companies http://www.google.com/search?q=django+hosting http://www.google.com/search?q=django+hosting and all the companies providing language-specific services for PHP, Java and every other mainstream language.
  - yesimahuman 17y ago
    I'm not complaining about the hosts, I'm complaining about the extreme focus we put on the language being used rather than the products being made.
    - carbon8 17y ago
      "I'm complaining about the extreme focus we put on the language being used rather than the products being made." What "extreme focus on the language"? Simply mentioning "Ruby" in the context of a Ruby-only hosting company's decisions does not constitute "extreme focus" any more than mentioning "Python" or, more recently, "Java" when discussing the Google App Engine. It's completely uncontroversial to anyone who doesn't have an axe to grind. Also, the services provided by the companies (or as you put it, "the products being made") are Ruby and Git hosting, with EY also maintaining several Ruby implementations. I'm not sure how you could say anything about EY's "products being made" without mentioning Ruby.
jwr 17y ago
I think it's rather funny that this would never be news if not for the keywords. I mean, a customer changes a hosting provider for business reasons. Yawn. Who cares. But, drop in "Ruby" and "Git" and see it as front page news on HN with a discussion going off on tangents.
llimllib 17y ago
Silly question: the GFS referred to here is Global File System (http://www.redhat.com/gfs/ http://www.redhat.com/gfs/) not Google File System, right?
- tmornini_ey 17y ago
  You are correct, sir.

157 points by jcapote 17y ago

mitchellh 17y ago

Does anyone have any idea what host github is moving to?

jherdman 17y ago
It doesn't actually say Github is moving. It just says that Github isn't going to be supported by EngineYard in the same way. It's entirely feasible that Github remain at EngineYard. Edit Woops. Looks like I missed the key part of a sentence there. Sorry folks.
- judofyr 17y ago
  Accordingly, we are currently working directly with their next provider to maintain smooth service as they cut over.
  - jnewland 17y ago
    > From what I understand, we're at the data migration point, and we're waiting on EY for that. s/working directly with/delaying/ http://support.github.com/discussions/site/721-network-feed-and-site-speed#comment_368351 http://support.github.com/discussions/site/721-network-feed-...
- jcapote 17y ago
  "Accordingly, we are currently working directly with their next provider to maintain smooth service as they cut over." "Provider" really sounds like they are talking about infrastructure
- deleted 17y ago
  [deleted]
- teej 17y ago
  That's exactly what the article says: "However, in the end, the best arrangement for them was moving."
pjhyett 17y ago
We're moving to Rackspace.
- judofyr 17y ago
  Cloud or dedicated/managed?
  - pjhyett 17y ago
    Real hardware and lots of it. Once we get moved over and everything's humming along nicely, we'll do a writeup or two about the new infrastructure.
    - jnewland 17y ago
      Nice, I'm really looking forward that to that. I'd love to hear about the transition too - big moves aren't easy, as I'm sure you guys know.
- datums 17y ago
  that was my guess, you guys have a big dev following, rackspace has marketing money that can be reallocated to hosting github. good luck
- lsb 17y ago
  What FS will you use? SSDs?
- jasonjwwilliams 17y ago
  That'll be great...and hopefully address one of concerns about having our private repos sitting on ATAoE storage.
  - tmornini_ey 17y ago
    What concerns are those?

seiji 17y ago

I think they could have worded this better: "GitHub offers the largest free storage quota among the big SCM hosters, and we came to the conclusion that we didn’t want to subsidize that quota for non-Ruby developers." It sounds odd Engine Yard hosts an entire for-profit company for free just in exchange for some complimentary accounts. My imagination tells me GitHub is tired of being slow and Engine Yard couldn't do anything more to help them. Instead of the news being "GitHub Leaves Engine Yard Because It's Too Slow" the news is "Engine Yard Kicks GitHub To The Curb Because GitHub has Non-Ruby Repos." I don't see either headline being positive towards Engine Yard.

jeremymcanally 17y ago
> It sounds odd Engine Yard hosts an entire for-profit company for free just in exchange for some complimentary accounts. Well, sort of. It's really a value trade-off. EY offers its customers something that would cost them $50 a month, so it's costing Github (customers) * $50 to offer that. They exchange the lost value for added value in hosting (i.e., they're "losing" a few thousand a month in free accounts for our customers, so we'll offer them free hosting to continue to offer that). It's simple barter.
- jhancock 17y ago
  Very excited to see GitHub continuing to grow and EngineYard and GitHub handling their barter deals so cordially. Both companies are class acts!!!
jcapote 17y ago
That assumes that Github is slow because of their hosting (Engineyard) and not because of how it's written. I dunno, it could go either way for me: "Engineyard drops Github for being too costly" vs "Github needs better hosting, so we're dropping Engineyard"
- jhancock 17y ago
  Its probably more about costs for both sides. I doubt that EY is _slow_ without regard to cost. Just that instead of rewritting GitHub's web app to deal with inherent performance issues, it makes more sense to throw more hardware at the problem. There does come a point where owning more of your server stack makes more financial sense.

omouse 17y ago

Don't offer a free storage quota or limit how many projects you can host. There, problem solved. The people who leave will no longer be a drain on your servers and the people who stay will be paying for the maintenance of those servers.

matthewcford 17y ago
That would kill the majority of open source projects hosted on github, free hosting for public repos is one of the reasons it's so great. I'm willing to pay for private repos, but if I had to pay for my public ones too, I'd just not host them on github.
- DannoHung 17y ago
  I'd be willing to pay Github for some other premium service besides private repos (they're not of much use to me, tbh). Uhh... can't think of anything off the top of my head that I really need or want though... OH, wait, I know, how about Bespin integration?
- omouse 17y ago
  Maybe those open source projects should charge a fee as well?
  - wizardofoz 17y ago
    No, people should donate more to open source projects.
deleted 17y ago
[deleted]
bestes 17y ago
I'm a paying GitHub customer and having big projects like Ruby on Rails and Perl hosted there makes me very comfortable. I figure if they can handle the big stuff, they can handle me! Plus, I use as much free software as everyone else and am happy to help out indirectly (by being a paying customer). I expect prices will rise soon as well. I'm not sure anyone has mentioned this yet, even though it seems inevitable. Still, I think GitHub is fantastic and I'm planning to increase my usage.

stephenjudkins 17y ago

When evaluating hosting providers, the quote Engineyard gave us was tremendously expensive. They offered a great deal of value-added services, but we found that it would be cheaper to go with the second-most expensive option (Amazon EC2) while also hiring a qualified full-time sysadmin. Whether this was a wise choice or not given our experience with EC2 is up for debate. But even if we had gone with Engineyard and had no problems at all it would be hard to justify a couple developer's salaries for it.

lsb 17y ago
Just out of curiosity, what were your options that were cheaper than EC2, and why'd you reject them?
- Periodic 17y ago
  Please, write it up and post it to HN! It deserves its own discussion.
- stephenjudkins 17y ago
  There were several hosting services that were a good deal cheaper. It costs $576/mo to run an extra large EC2 instance fulltime, while purchasing a server with similar specs only costs $2k or so. The data center across town could give us an equal number of server power for much cheaper. We're in our own data center right now, in another city, and we simply have a contractor we pay to go in and occasionally replace broken equipment. It really is quite cheap to do it this way. Various hosts offered greater degrees of managed services at various prices. None really offered the flexibility that EC2 offered, or offered that much over simply colocating our own servers. With less traffic or fewer servers I can see many of these hosts being a great deal. There also were several places that gave us completely screwy quotes that I can imagine were only meant to trick CEOs who don't know any better. One example is a place that offered us the use of an HTTP load balancer for the "low, low price" of $1000 a month. A lot of places offered expensive managed services, but when talking to the people who would serve us it was clear they didn't know what they were talking about. We did not seriously consider these places. To Engineyard's credit, they were only managed host who sounded like they had knowledge that would be really valuable to us. They also made clear that they would devote significant resources to getting our site working smoothly. We would have paid a premium for this service, but not the premium they asked. EC2 offers an amazing amount of flexibility that we found highly valuable. A sysadmin and developer spent most of a day diagnosing an issue with a DB server that ended up being a flaky drive. In EC2, we would have simply killed the server, fired up a new instance, waited an hour for its replication to catch up, and returned it to the rotation. To return to EC2 we would have to drastically reduce the load on our MySQL instances, since we found that EBS volumes had somewhat unpredictable and not that great performance. Reducing our reliance on MySQL is something we're doing anyways, since on its current course it would have been difficult and expensive to continue scaling up in any data center.

datums 17y ago

Bottomline, it's a business decision, I'm sure if staying with EngineYard was an option they would have gone that route. Moving to EC2 is probably a lot cheaper than other pricey, like RackSpace solutions. It's part of growing up, you sometimes have new friends, but never forget those you grew up with. I wonder how many new EY customer use their github accounts ?

davidw 17y ago

> We identified the bottlenecks and supported GitHub and the community by making patches to ssh to allow key lookup in MySQL rather than a text file. That remains, to this day, one of the finest examples of Engine Yard support and it makes me extremely proud just thinking of it. This seems... odd to me. It doesn't feel like the right boundary between businesses. From a hosting provider, I expect good, steady service, reboots, a root console, and that they'll fix anything that's on their end (hardware, for instance). Patching ssh is development work, and is something I would expect to pay for to meet specific goals, but not something that comes as part of my hosting package. I mean, what if you are just cruising along, and don't need any deep hacking over a couple of months. Is your money being wasted? With actual developers, I could redeploy them to do other things. Can I do that with EY? They seem like really good, sharp guys, but I don't quite get the business, I guess.

tedunangst 17y ago
Maybe the developers building apps that run on EY aren't the best developers to be patching ssh? Is your money wasted if you hire a lawyer on retainer and don't ask enough questions?
- davidw 17y ago
  EY publicizes their Ruby expertise, not their 'hack on security-critical crypto code' expertise, and while it's impressive, and to their credit that they were able to do it, it still leaves me thinking that a fixed monthly fee is the wrong way to pay for that kind of talent. > if you hire a lawyer on retainer and don't ask enough questions? At a certain point, yes.
tmornini_ey 17y ago
From our perspective, it was a matter of helping our partner and the Ruby community succeed. We're working really hard to make Ruby on Rails succeed. This is just one of the many ways that we've pitched in to help it do so. If, during that downtime, when the "Twitter's problems are Ruby on Rails" FUD was running high, would anyone believe that a Github scale failure wasn't a Ruby on Rails problem? We weren't willing to test it, so we solved the problem, i.e. we put our money where our mouth is -- That Ruby on Rails scales just fine, the bottlenecks are generally elsewhere.

tmornini_ey 17y ago

Hey all. Wanted to chime in the discussion. My blog post is direct and to the point. There's honestly no mystery about this, I laid out all the details, possibly excepting one. We designed our infrastructure offering 3 years ago. We knew that the vast majority of websites would produce nearly read-only file I/O. GFS's less than stellar write performance isn't a problem in that typical case. Along comes Github, and they have an entirely different disk I/O profile to the rest of our customers. Github was built on a shared-something architecture because GFS made it quick and easy to get up and running, developing features, and attracting users. This is a good thing! Github has been very vocal about their dislike of the GFS filesystem we use for shared filesystem access. GFS doesn't scale forever, and we've never suggested it does. It could scale far larger than it has at Github, but fizx hit the nail on the head: we weren't willing to do it for free, and Github was unwilling to pay our price. We warned Github many, many moons ago that given their growth rate, in order to scale their application smoothly and inexpensively, a shared-nothing architecture was eventually going to be needed. We offered to help them with that architecture, as we saw Github running wonderfully atop a cloud service such as EC2. Rather than do the re-architecture now, they've chosen instead to move to a vendor who can provide them a high performance, high availability, non-commodity, proprietary network file server infrastructure. I suspect it will work well for them, and we'll all enjoy a faster Github. :-) From my perspective, I really want everyone to understand that there's no bad blood on the EY side, and hopefully none on the Github side. Business is business, decisions need to be made each and every day.

defunkt 17y ago
Rather than do the re-architecture now, they've chosen instead to move to a vendor who can provide them a high performance, high availability, non-commodity, proprietary network file server infrastructure. I suspect it will work well for them, and we'll all enjoy a faster Github. :-) GitHub has been working on a re-architecture since our last major feature release, which was GitHub Issues in April. And we can't wait to roll it out.
- tmornini_ey 17y ago
  Great news, Chris, sorry to misrepresent. So, the new Github architecture is shared nothing?

calambrac 17y ago

Jesus Christ, there's a lot of drama-mongering in this thread. Grow the fuck up, it's a business decision that both sides had an interest in seeing happen.

callmeed 17y ago

Does this mean I'll no longer get a free GitHub account as an EngineYard customer? EDIT: N/M, found the answer. Does this mean I can have a free GitHub account because I'm also a Rackspace customer :)

yesimahuman 17y ago

Engine Yard and Github's business relationship aside, is anyone else sick of everything these days being about the tool or language people are using? For some reason we hear more from the Ruby side than any other about how great their language is, but frankly the only thing that matters are the products made from it. I don't know, I'm just kind of sick of Ruby fan boys.

adw 17y ago
I'm a Python guy, and that community's both sinned against and sinning. You have prominent Ruby guys claiming there's no momentum - Youtube, Friendfeed, Dropbox, loads of newspapers - behind the language. But, then, I'm chippy enough to notice... It's the Perl community who just seem to get it done. Amazon and BBC iPlayer have more traffic than most of us, I bet!
carbon8 17y ago
"we hear more from the Ruby side than any other about how great their language is" Um, that crown unquestionably goes to a big chunk of the python community right now. Reddit alone provides a steady stream of both extreme fawning over python and vitriol targeted at ruby, and your comment and its upvotes demonstrate that it's present here, as well. It's also quite a colossal double standard to complain about Ruby-specific hosts considering the existence of GAE, all the django-targeting hosting companies http://www.google.com/search?q=django+hosting http://www.google.com/search?q=django+hosting and all the companies providing language-specific services for PHP, Java and every other mainstream language.
- yesimahuman 17y ago
  I'm not complaining about the hosts, I'm complaining about the extreme focus we put on the language being used rather than the products being made.
  - carbon8 17y ago
    "I'm complaining about the extreme focus we put on the language being used rather than the products being made." What "extreme focus on the language"? Simply mentioning "Ruby" in the context of a Ruby-only hosting company's decisions does not constitute "extreme focus" any more than mentioning "Python" or, more recently, "Java" when discussing the Google App Engine. It's completely uncontroversial to anyone who doesn't have an axe to grind. Also, the services provided by the companies (or as you put it, "the products being made") are Ruby and Git hosting, with EY also maintaining several Ruby implementations. I'm not sure how you could say anything about EY's "products being made" without mentioning Ruby.

jwr 17y ago

I think it's rather funny that this would never be news if not for the keywords. I mean, a customer changes a hosting provider for business reasons. Yawn. Who cares. But, drop in "Ruby" and "Git" and see it as front page news on HN with a discussion going off on tangents.

llimllib 17y ago

Silly question: the GFS referred to here is Global File System (http://www.redhat.com/gfs/ http://www.redhat.com/gfs/) not Google File System, right?

tmornini_ey 17y ago
You are correct, sir.