Hearts out to all the GitHub SREs who get to fix this, and all the SREs at GitHub’s customers who get to spend the next week convincing management and their peers that moving git in house won’t result in fewer outages.
Additionally any potentially disruptive work like upgrades etc can be scheduled outside of business hours so that they won't impact users
Something tells me that if you can schedule upgrades "outside of business hours", your scale is small (because in a global company, it's always "business hours" somewhere), which makes the cost argument even more prominent.
And any large business will already be doing Backups, DR etc for their existing systems.
Any? Are you sure?
If you work in a large business that needs git but doesn't have backups and has no disaster recovery plan at all you're going to have much bigger things to worry about than a git repo being offline.
Gonna call BS on that.
It can achieve better uptime, if you ignore the downtime for upgrades, the downtime for configuration errors, the downtime when the disk fills up...
Btw, you cannot compare a scheduled maintenance window with an unplanned downtime ... maybe in the middle of an important deployment.
Bitbucket Server
Besides the last one, the others you can schedule when developers are not actually working on something, or give a headsup so developers can be prepared in case of errors.
In the case of GitHub, Microsoft deploys changes whenever they want, whenever you want it or not.
That's because GitHub is used by millions of people every day all over the world. Business hours for them are around the clock. No matter when they update, if it breaks something, many people will hear about it regardless of when the break was deployed.
So 10 minutes a month for upgrades, zero time for the rest because you are managing it just fine.
I'd be interested to see if there is any correlation there.
Although I guess the benefit is that the CTO gets a psychological lift of looking over Jeremy from IT's shoulder when he tries to fix the issue rather than being at the mercy of some engineers which the company can't fire.
Some wiz-bang new graduates calling themselves Engineers probably haven't a clue - sure, but for everyone else, you probably still have folks employed that did just that on a professional level.
It's not hard - and often it's less expensive. Particularly for a turn-key paid product like Github Enterprise or GitLab.
I've been running self-hosted software, and GitLab in particularly, for over a decade at various jobs.
It almost never goes down. It fact, its up way way way more often that GitHub!
Not add new features every week? Seriously, you cannot tell me that you cannot run a minimal version of a git repo service much more stable than that. I blame the need for new shiny stuff.
Ya'll make me laugh. Don't add any features and "This thing is dead, nothing new in years, find an alternative" But a company actively adds new features their customers are asking for and you're upset that they're adding new features.
Pick a lane.
I know the comments of these posts before I even open them. HN is an echo chamber of predictability.