"a real serious business would have created an infrastructure that will provide paying customers a better redundancy for their accounts"<p>He should apply the same argument he makes against Github to his own business. Putting together a Gitosis or similar setup mirrored to Github would have given him and his paying customers the necessary redundancy to deploy when one of the hosts is down.<p>EDIT: Figure while I'm here and it's not OT I should give a well-deserved shout-out to Gitosis which has made my life a lot easier the past two years or so:<p>Gitosis setup is a one-off, very low maintenance install (you add repositories and users by committing config changes and public keys to a git repository -- hardly anything out of your regular workflow). Once set up, mirroring to github or another service is a one-liner in your post-receive hook.
Ignoring the fulminating a bit and concentrating on the substantive issue, there is a real leap in expected level of service once you start taking money from people, and again when you start hosting Mission Critical apps. (What an overused buzzword -- but a <i>true</i> overused buzzword!)<p>Saying "He shouldn't have had anything Mission Critical on Github, he should have designed his infrastructure competently" is besides the point. Properly designing a fault-tolerant workflow involving git isn't something which is in the easy reach of everyone, and some people would prefer to pay money than to deal with the hassle of doing it themselves. (And trust me, it is a hassle. I have my own gitosis server because I had a business necessity to host my OSS on my own domain. Holy bleeping heck I lost a day of my life to getting that working. That's close to $1,000 of engineer time replicating something very close to what every git hosting company offers for $9 a month.)<p>People who don't have the skills and don't have the desire to set up a fault-tolerant git infrastructure pay other people to do it for them. Other people being... well... Github. That means that Github has acutely more sensitive uptime demands than somebody's blog on OSS topics or even paid services in less critical contexts. One reason my business is in a less critical context was because I knew that the constraints I was working under made it unreasonable for me to offer customers the assurance that they could build their businesses on me.
Git is decentralized. There's <i>no way</i> Github can affect your ability to deploy. Code can only be pushed there meaning it was written and exists somewhere else.<p>There's also no way to run your own private SSH or git server without paying a minimal monthly fee. Any such server or Internet connection will go down occasionally.<p>Nobody is going to stop you from finding an alternative that suits you better. Good luck.
<i>shrug</i><p>Well, I kinda agree, but if github is really a mission critical piece of your company, then perhaps you should be hosting your own repository.<p>Or at least mirroring it somewhere? Isn't that half the point of using git over svn?
This is really harsh and it sounds like he's looking for a scapegoat on why he is behind on client projects, "i delayed 3 client deploys in the past week due to Github’s downtime".<p>GitHub is very transparent about their issues and from looking at their blog ( <a href="http://github.com/blog/597-a-note-on-the-recent-outages" rel="nofollow">http://github.com/blog/597-a-note-on-the-recent-outages</a> ), "Following three months of near 100% uptime, we’ve just been through three major outages in as many days."<p>The outages weren't "days long" so those delays in deploying a client's project shouldn't have been significant. If the client expected a deployment during a short window it is irresponsible for the development company to keep the code only in a single location. I cover this in a post about availability on my blog ( <a href="http://www.bretpiatt.com/blog/2009/10/03/availability-is-a-fundamental-design-concept/" rel="nofollow">http://www.bretpiatt.com/blog/2009/10/03/availability-is-a-f...</a> ).
We just had a discussion about this a couple of hours ago. If your deployment depends on an external service, your deployment is broken.<p>You're using git. Have a fabric script that pulls down the remote repositories that you need, and rsync's them to your servers. This works locally or on a remote box. If github is down, pass in local directory to sync instead. This way you can always push.<p>He built his infrastructure wrong, and is trying to blame someone else. Sorry, but you are just as much at fault, if not more, than github.
I think i need to clear it up a little bit. (Yeah, it's my post).<p>I agree that the post came off a bit too harsh maybe, but as far as reliability for a payed service goes, github was yet to provide a decent level.
Ever since Github outages started (a while ago, even on EY's age) i decided to push into 2 separate locations and therefore giving Github a further chance (2nd location is another paid account on Unfuddle.com) but the delay on deployments was due to simple need on our side that resulted in the need to push another change to github (updating a vendored private gem) while this process may probably not be perfect it does not remove any responsibility from github as a payed service to provide a better way of supporting payed accounts.<p>i will review my internal processes further more to see if there's a better way of doing them, but as far as continuing a payment to an unreliable service.. that part is over.
He makes some decent points about Github's response to their reliability issues, but that's about where it ends. This rant can be summed up as: Github is unreliable and they should work on this, pushing free users to the back burner in favor of their paying clients. Whether or not you agree with that, the rant was a bit unnecessary.
I think this article is being a bit harsh and overly dramatic. However, he does have a point in that the github folks should probably try to architect things such that their paid service is isolated from any mishaps that come from the free service.
I don't currently have anything hosted at Github, but I use them regularly to check out other people's code and their uptime history is disappointing. I know that they always explain what caused the downtime and I'm glad that they do. Explain what's wrong isn't enough, though. It seems like they have a poorly designed system that can be brought down by almost any piece failing. Their latest outage makes it sound like they don't know how to build a fault tolerant system at all. They have the parts there, like DRBD, but when things go wrong everything breaks anyway. It's like making backups but never testing them so that when you need them it turns out that they can't actually be used to restore anything.<p>It seems that they have the part that most companies miss, the communication, but that doesn't make up for the lack of reliability.
This kind of feels like another "don't know how to use my tools" kind of post.<p>I was doing some critical work during the last time. I had to collaborate with another developer and he was unable to push through github. So we exchanged code a different way.<p>I was also doing EC2 tests of the code we were working on during this window. I didn't have trouble getting that deployed (via git, no less) during this time.<p>It's easy to do the lazy thing and rely on centralized systems when it's <i>completely</i> unnecessary just to avoid a small amount of work to <i>greatly</i> increase the reliability of your platform.
Yes, it is pretty bad for github to have so many problems in so few days and if he isn't happy with the service he should leave.<p>However, seems like he doesn't really understand how to use Git if github being down is barring him from doing his job or deploying his work. Having a single point of failure while using a distributed version control system is incompetence on the developer more so thann it is a problem github being down. Github provides you a lot of nice features and fancy web based interfaces and some social aspect to coding, but to rely solely on it shows a lack of understanding and removes many of the benefits git provides a developer.
Not sure what the big deal is.<p>Customer doesn't feel like the price they are paying is worth the value and leaves.<p>Only difference is that there are alternatives to this "critical service."<p>Had this been a rant about the electric company going down in the snowstorm no one would have cared because it was understood these things happen.<p>Have an absolute need for power no matter what? Better get yourself a backup generator. Just because you pay for a service doesn't mean it won't go down. Just means you should expect them to fix it ASAP.
I pay github for a private repo I rarely use, however I really depend on them for my development as all the open source libraries and documentation I use are stationed there. I don't see switching to something else as an alternative.<p>So what can we do to help them keep their servers up for the community's benefit?
Just use gitorious <a href="http://gitorious.com" rel="nofollow">http://gitorious.com</a>. If you are not satisfied with the hosting, install locally <a href="http://blog.alexgirard.com/git-gitorious-on-ubuntu" rel="nofollow">http://blog.alexgirard.com/git-gitorious-on-ubuntu</a>
Ouch, that font is hard on the eyes. I have minimum font sizes for readability, but even turning it down, jeez.<p>Thanks again to the Readability marklet!
It's the Internet. Everyone has downtime, even Amazon.<p>My only complaint about Github is how my profile is turned into a giant ad for github when a non-logged-in user visits it. I think it's really underhanded to use a paying customer's profile page to convince random people to sign up for github. If they want to, they will figure it out, just like the other million users.
The large amount of grammar and spelling errors make me question if the author is at all interested in a "real serious business". And WTF is up with the horrendous comma usage? It's similar on his Nautilus6 and LinkedIn websites, too.<p>Also, how precisely did temporary downtimes prevent deploys? At best, it appears they would've been delayed by a couple hours, and the great part about Git is that you can work around something like that pretty easily. Granted, downtime is annoying, but his extended difficulties seem to largely stem from his own mistakes, and for $7/month he's not exactly paying top dollar to guarantee uptime.<p>Learn too spell: <a href="http://iampaddy.com/spell/" rel="nofollow">http://iampaddy.com/spell/</a>