Given what "An Update on " usually means, I can only assume this means that Github has decided to no longer provide availability. Not particularly surprising given current trends I guess
An update on GitHub availability
201–210 of 266 posts
Re: An update on GitHub availability
#202Earlier quoted context omitted.
I mean its Microsoft and its Azure. How much can go wrong clicking yourself a few/hundred non autoscaling normal VMs? There is so much workload running on Azure, i never heard of VMs go away. If Microsoft can source hardware for Azure, Microsoft can source hardware for Github.
there's a lot that can go wrong with a hypervisor, even including hiding hardware issues from the guest OS. We don't think about it because we've been quite spoiled with excellent virtual machine platforms (KVM, Xen and even VMWare). Those that have worked a lot with VirtualBox will be aware of this, it can be deeply unnerving that VM technology is the default way to deploy things after you've spent sufficient time w…
HyperV looks like VirtualBox but it's not. It's type 1 like KVM is.
Re: An update on GitHub availability
#203Hah, love that now they say "Our priorities are clear: availability first, then capacity, then new features" when 6 months ago, it was seemingly exactly the same except Azure supposedly was gonna save them: > GitHub Will Prioritize Migrating to Azure Over Feature Development - GitHub is working on migrating all of its infrastructure to Azure, even though this means it'll have to delay some feature development. > In a…
This seems uncharitable. Priorities aren't exclusive, especially at scale across large engineering orgs like GitHub. It could be that these are the top level priorities, but teams or individuals who aren't able to contribute to these priorities will work on other things like new features.
No, but they are ordered generally, and in this case they are explicitly saying that availability should come first
Re: An update on GitHub availability
#204Hah, love that now they say "Our priorities are clear: availability first, then capacity, then new features" when 6 months ago, it was seemingly exactly the same except Azure supposedly was gonna save them: > GitHub Will Prioritize Migrating to Azure Over Feature Development - GitHub is working on migrating all of its infrastructure to Azure, even though this means it'll have to delay some feature development. > In a…
If they had not added or changed any features to GitHub for the past 5 years, nobody would be upset, and yet, they keep changing it. It's a website that doesn't need to be reworked every five minutes. I assume the main development teams maintaining GitHubs codebase are ran by managers who cannot justify their jobs unless they deliver new features for the sake of delivering new features to keep their jobs going, and /…
>What's a bigger joke is Microsoft has Azure DevOps which looks like it might be abandoned?
My favorite was trying to figure out how to publish debug symbols with NuGet packages to Azure DevOps artifact feeds. Horrible documentation and I was never able to get it figured out.
Re: An update on GitHub availability
#205Earlier quoted context omitted.
there's a lot that can go wrong with a hypervisor, even including hiding hardware issues from the guest OS. We don't think about it because we've been quite spoiled with excellent virtual machine platforms (KVM, Xen and even VMWare). Those that have worked a lot with VirtualBox will be aware of this, it can be deeply unnerving that VM technology is the default way to deploy things after you've spent sufficient time w…
HyperV looks like VirtualBox but it's not. It's type 1 like KVM is.
i meant in terms of bubbling up hardware issues.
Re: An update on GitHub availability
#206Earlier quoted context omitted.
As a business user, our costs have gone up while service has gone down dramatically. Meanwhile our marginal cost to GitHub has hardly changed. Where our costs to them have increased, they mostly charge us per cpu minute, so obviously aren’t making any kind of loss on our account. I’m sure they’re experiencing scaling issues across the platform, but it’s unacceptable for that to have a negative impact on us when we're…
I'm curious how Azure DevOps reliability has been for comparison. My current job is managing stories in DevOps with SCC in GitHub ent. While I like Github slightly more, have been curious about the decision.
We use Azure DevOps at work for few things. It's been pretty rock solid since all agents don't recommend it and it's different architecture.
It's also legacy at this point since Microsoft is pouring all resources into GitHub but for most people/companies, they could probably use Azure DevOps just fine.
Re: An update on GitHub availability
#207Earlier quoted context omitted.
This seems uncharitable. Priorities aren't exclusive, especially at scale across large engineering orgs like GitHub. It could be that these are the top level priorities, but teams or individuals who aren't able to contribute to these priorities will work on other things like new features.
Agree that priorities aren't exclusive and there may be teams/individuals that aren't able to contribute if they stay in their current teams/roles Where it becomes questionable though is when enough progress isn't being made on the top priority (reliability). If Github is being true to their word, they need to be pulling people off of teams that are working on features to work on reliability so that top priority gets…
Sure, but frontend devs fundamentally cannot contribute to the structural reliability issues.
The person who rewrote the issue page view probably doesn't know anything about multi-cloud scaling for millions of users with Azure-crippling throughput. That's an incredibly specialized set of knowledge and experience that is utterly disjunct to frontend work.
But at the same time, given the state that GitHub is in, I personally wouldn't want to allow any devs to push anything to prod that doesn't immediately affect stability. I'd completely freeze frontend work until the infrastructure is more stable. But then again I write C for microcontrollers so what do I know?
Re: An update on GitHub availability
#208Earlier quoted context omitted.
There was somewhat recently a post here about how priorities, pressure, and management subverted Dave Cutler's vision for Azure (which was to have near zero human involvement) - my Google fu isn't strong enough to find it. Supposedly, someone running over or opening a serial to a rack/VM is now typical operational procedure.
This one? https://isolveproblems.substack.com/p/how-microsoft-vaporize...
That's the one!
Re: An update on GitHub availability
#209Earlier quoted context omitted.
Agree that priorities aren't exclusive and there may be teams/individuals that aren't able to contribute if they stay in their current teams/roles Where it becomes questionable though is when enough progress isn't being made on the top priority (reliability). If Github is being true to their word, they need to be pulling people off of teams that are working on features to work on reliability so that top priority gets…
Sure, but frontend devs fundamentally cannot contribute to the structural reliability issues. The person who rewrote the issue page view probably doesn't know anything about multi-cloud scaling for millions of users with Azure-crippling throughput. That's an incredibly specialized set of knowledge and experience that is utterly disjunct to frontend work. But at the same time, given the state that GitHub is in, I pers…
I don't know their architecture but I would bet if FE devs wants to contribute to availability in a capacity-constrained world (as GH CTO mentions) they could focus on profiling and optimization, backend-access patterns for example, caching, etc. Maybe they already have people dedicated on that but if they are coming out of a "new features first" operating regime I would bet there's some fruit to pick there.
Re: An update on GitHub availability
#210> we started working on path to multi cloud. Is this microsoft stating that they aren't able to get acceptable reliability from Azure? (I mean, I think a lot of us have heard that, but it's interesting to hear it from microsoft themselves).
> multi-cloud
XXXXL size project. May not ever deliver. But if it fails, it will only do so after years grinding through people, resources, etc.