3 ms·

github being down was a big pain for me today, and I'm surely not the only one...

by 33degrees 10y ago

lsh123 10y ago
I was mainly referring to Twitter, Spotify, Netflix, Amazon :)
tehlike 10y ago
why? were you trying to fork new repos or just your usual commit/push flow?
- eropple 10y ago
  Downvoting this post is kinda shitty, because it's just obliquely pointing out something that nearly every developer should already know--that having a single point of failure for your builds and your tests (the only reason Github being down should impact you) is a bad, bad idea. Your code should be building and deploying from git remotes you control, if you want to be using push-as-build CD. If you have dependencies, bring them in-house on your own Artifactory, gem server, npm mirror, whatever. Controlling the entirety of your deployment stack is not just a good idea, it's a requirement for safe and sane operations.
  - speedplane 10y ago
    In a perfect world, we would all operate our little empire, where we control every piece of infrastructure, and would not be reliant on any other provider. Alas, maintaining that infrastructure has costs... enormous costs, and to get a product to market quickly, you often can't do it on your own. Maybe industries like banking, defense, and healthcare are different, but for the majority of us, we just can't afford to build our own basic internet infrastructure and compete in the marketplace.
    - eropple 10y ago
      You're not building "basic internet infrastructure". You're standing up Gitolite next to your CI system and Gemcutter or Kappa or pick-a-Maven-repo-including-Wagon-over-FTP. It costs about twenty bucks a month to do both these tasks. If they're running on separate machines. Which they don't have to be. The idea that a git remote is "basic internet infrastructure" that should be out of your hands because you're shipping a product raises ignorance to worshipful levels. If you want to use Github for collaboration, that's fine! But if your deploys, etc., are being held up by something out of your control that isn't systemic failures with the provider in which you're deploying your software, you done screwed up.
  - otterley 10y ago
    Are you aware of some well-built systems for enabling that? What you're describing, while simple in concept, is not so simple to set up. There's tooling to be written and authentication to synchronize.
    - eropple 10y ago
      I...just do it? I don't find it to be complex at all. Use one or another method of user authentication for SSH (I use SSSD, but no solution can be really universally recommended), launch gitolite (a six line Chef recipe), do the same for Boxcutter or whatever you need. I tend to think that the problem isn't complexity, the problem is the current developer culture being so predicated on it's easy, you don't have to understand things that having to understand things borders on anathema. Yes, doing this does require understanding how your tools work, but that doesn't make it complex. And you should know anyway. Or pay me. My rates are reasonable. =)
      - otterley 10y ago
        I've been doing this for 20 years now, and little has changed. It's not that developers don't think they have to understand things; it's that their incentives are to understand things that are relevant to the problem domains of the products they are working on. Reliable and efficient deployment strategies are not usually in their problem domains.
        eropple 10y ago
        They may not have been in their problem domains twenty years ago (though they were for me from the start, albeit merely fourteen or so years ago =). I think that the future is obvious and that the expansion of the "stack" to the underlying runtime infrastructure is a foregone conclusion; this is ignored at a developer's own peril. (As it happens, I was a developer first--but I was managing my own infrastructure, too, and so from a very early age I had to be damned comfortable with doing that. Now the industry is pivoting there as "devops" becomes more and more of a thing.)
  - tehlike 10y ago
    Thanks - I was exactly thinking this when i asked the question. If git is advertised as a DVCS, then it's hard to understand why the practice is to rely on a central authority that you don't own. It could go down anytime like it did yesterday. [edit: last sentence].

github being down was a big pain for me today, and I'm surely not the only one...

lsh123 10y ago

I was mainly referring to Twitter, Spotify, Netflix, Amazon :)

tehlike 10y ago

why? were you trying to fork new repos or just your usual commit/push flow?

eropple 10y ago
Downvoting this post is kinda shitty, because it's just obliquely pointing out something that nearly every developer should already know--that having a single point of failure for your builds and your tests (the only reason Github being down should impact you) is a bad, bad idea. Your code should be building and deploying from git remotes you control, if you want to be using push-as-build CD. If you have dependencies, bring them in-house on your own Artifactory, gem server, npm mirror, whatever. Controlling the entirety of your deployment stack is not just a good idea, it's a requirement for safe and sane operations.
- speedplane 10y ago
  In a perfect world, we would all operate our little empire, where we control every piece of infrastructure, and would not be reliant on any other provider. Alas, maintaining that infrastructure has costs... enormous costs, and to get a product to market quickly, you often can't do it on your own. Maybe industries like banking, defense, and healthcare are different, but for the majority of us, we just can't afford to build our own basic internet infrastructure and compete in the marketplace.
  - eropple 10y ago
    You're not building "basic internet infrastructure". You're standing up Gitolite next to your CI system and Gemcutter or Kappa or pick-a-Maven-repo-including-Wagon-over-FTP. It costs about twenty bucks a month to do both these tasks. If they're running on separate machines. Which they don't have to be. The idea that a git remote is "basic internet infrastructure" that should be out of your hands because you're shipping a product raises ignorance to worshipful levels. If you want to use Github for collaboration, that's fine! But if your deploys, etc., are being held up by something out of your control that isn't systemic failures with the provider in which you're deploying your software, you done screwed up.
- otterley 10y ago
  Are you aware of some well-built systems for enabling that? What you're describing, while simple in concept, is not so simple to set up. There's tooling to be written and authentication to synchronize.
  - eropple 10y ago
    I...just do it? I don't find it to be complex at all. Use one or another method of user authentication for SSH (I use SSSD, but no solution can be really universally recommended), launch gitolite (a six line Chef recipe), do the same for Boxcutter or whatever you need. I tend to think that the problem isn't complexity, the problem is the current developer culture being so predicated on it's easy, you don't have to understand things that having to understand things borders on anathema. Yes, doing this does require understanding how your tools work, but that doesn't make it complex. And you should know anyway. Or pay me. My rates are reasonable. =)
    - otterley 10y ago
      I've been doing this for 20 years now, and little has changed. It's not that developers don't think they have to understand things; it's that their incentives are to understand things that are relevant to the problem domains of the products they are working on. Reliable and efficient deployment strategies are not usually in their problem domains.
      - eropple 10y ago
        They may not have been in their problem domains twenty years ago (though they were for me from the start, albeit merely fourteen or so years ago =). I think that the future is obvious and that the expansion of the "stack" to the underlying runtime infrastructure is a foregone conclusion; this is ignored at a developer's own peril. (As it happens, I was a developer first--but I was managing my own infrastructure, too, and so from a very early age I had to be damned comfortable with doing that. Now the industry is pivoting there as "devops" becomes more and more of a thing.)
- tehlike 10y ago
  Thanks - I was exactly thinking this when i asked the question. If git is advertised as a DVCS, then it's hard to understand why the practice is to rely on a central authority that you don't own. It could go down anytime like it did yesterday. [edit: last sentence].