3 ms·
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, possib
by 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 agoRather 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 agoGreat news, Chris, sorry to misrepresent. So, the new Github architecture is shared nothing?
- antonovka 17y agoSo, the new Github architecture is shared nothing? This is a pet peeve of mine -- what does "shared nothing" even mean? A database, a "NoSQL" key store, and memcached are all sharing something, and that something is a contention point. Specifically in this context, how do you implement transactional SCM semantics without sharing something (such as a distributed lock system?).
- oomkiller 17y agoShared nothing usually means that each node in a system shares no source data with any other node, it has it's own discrete database/disk/etc. However, these systems commonly share a communication link, so they can tell eachother about changes made on their database/disk etc. With a truly shared nothing platform, an entire node can go down and all of the other nodes continue to operate normally (except from the increase in load as users are migrated from the dead system to the live systems). The bad part about shared nothing is quite simple, it's damn hard to do, and harder to get right. One of the biggest problems is handling conflicting data between nodes. You either have to handle the conflict with your application, or your database needs to automatically choose the best copy (based on date etc).
- seiji 17y agoI much prefer being talked to this way instead of hearing about "non-Ruby repositories."
- liquidcool 17y agoPersonally, I like hearing about both the technical and the commercial reasons driving a business decision. The fact that GitHub did not serve Ruby projects exclusively (or primarily) was an important factor to EY - why should they neglect to mention that?
- dschobel 17y agoAgreed. That bit sounded a bit pathetic when the issues were clearly technical and not ideological. Are we really to believe that EY would have facilitated GitHub's growth had the repos remained overwhelmingly Ruby?
- rit 17y agoThis is a much more... reasonable explanation than "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.". Which had me honestly scratching my head. Then again, I prefer Mercurial and Python, so to each his own I suppose.
- rapind 17y agoI applaud the transparency of EY here. This is far more honesty than you get from most hosting companies. I'm also pleased that github is upgrading since I've noticed gradually decreasing performance for about a year now which prompted me to setup my own private repo server (but I missed the github front-end). Kudos to github for doing something about it.
- jasonjwwilliams 17y agoWould have been nice to see a joint statement (or at least concurrent statements) out of EY and Github. This way it looks like EY is just trying to beat them to the punch...either out of bad blood or to get in front of any potential bad PR.