81–89 of 89 posts
Reminds me of the classic bumbling quote: "Why don't they just host GitHub where they host the status page?"
"Why don't they make the whole damn plane out of the black box?"
It's amazing how often github actually goes down - 90% of the time they don't log it on their uptime / status page - it got so bad at one point I added it to our Nagios monitoring to prove a point to our devs that they shouldn't rely on external services for builds when our internal git(lab) server hasn't gone down once this year.
How does one depend on Github for builds if git is, um, distributed?
Earlier quoted context omitted.
"Why don't they make the whole damn plane out of the black box?"
I'm always impressed that life support systems on star trek fail, but artificial-gravity never ceases to work.
It's amazing how often github actually goes down - 90% of the time they don't log it on their uptime / status page - it got so bad at one point I added it to our Nagios monitoring to prove a point to our devs that they shouldn't rely on external services for builds when our internal git(lab) server hasn't gone down once this year.
How does one depend on Github for builds if git is, um, distributed?
BTW the official standing on dependencies in Go is to actually fork all deps you need, possibly using submodules or even vendorizing by adding src/* to your project VCS.
Earlier quoted context omitted.
By the time you're talking about 99.9% uptime there is only 9 hours downtime a year so there isn't much wiggle room for failure. There is never a reason any one person should assume they can do better than a third party because you're likely sleeping 2920 hours a year. Basically, you're never good enough on your own. If you care about uptime you're going to need to pay good money for it.
I think the general consensus for running infrastructure in house isn't superior uptime but superior control. Generally, you don't care if GitHub [or your inhouse equivalent] is down when no one is working. Also, if it goes down in the middle of the night and the first guy in fixes it...the difference between 1 man hour down in the morning vs. 20 man hours during the day across an entire team is significant. There ar…
Earlier quoted context omitted.
I think the general consensus for running infrastructure in house isn't superior uptime but superior control. Generally, you don't care if GitHub [or your inhouse equivalent] is down when no one is working. Also, if it goes down in the middle of the night and the first guy in fixes it...the difference between 1 man hour down in the morning vs. 20 man hours during the day across an entire team is significant. There ar…
> Generally, you don't care if GitHub [or your inhouse equivalent] is down when no one is working. It is fortunate, then, that all GitHub customers are in the same timezone!
It might not be affordable for daily works, but perfect for critical issues.
Earlier quoted context omitted.
I'm always impressed that life support systems on star trek fail, but artificial-gravity never ceases to work.
Probably there are a handful of gravitons or something embedded right in the floor, or there is massive inertia to the system. We tend to forget that not all solutions require active power.
(theoretically, if I could cache every repo I visit using squid-proxy, even if github has an hour downtime I can still access the repo's I visited in the past, not perfect, but it's something!)
Earlier quoted context omitted.
Of course there is - pushing directly to the server. Which is hosted on a third party, the third party itself is hosted on another third party, and that third party probably relies on a couple of other third parties. And if my patch brings down the service I get a bunch of emails - which are sent to my email address, which is also hosted on a third party. And that email found its way using an MX record from my DNS re…
> Do you really run an operation where you have soldered together all of your servers, created a data center inside your headquarters, within which you run all of your mission critical CI/testing/deployment services? Because unless you're one of a handful of tech companies, The contrary. You represent the handful that didn't, and the "handful" of tech companies you suggest is much larger than you think. Based on this…
I'd still like to see an actual cost breakdown, because to me hiring a full-time staff of 5 or 10 people to run such an infrastructure, at $80,000/year or more a pop, seems like it could quickly get just as expensive or more expensive than outsourcing those costs to another organization.
There has to be some reason Netflix is able to justify placing their entire high bandwidth streaming operation on AWS, a third party that relies on full virtualization.