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.