3 ms·

I don't see how self-hosting solves the problem of 3rd party vendors unless you're standing up a self-hosting solution as a hot/cold backup to your 3rd party ve

I don't see how self-hosting solves the problem of 3rd party vendors unless you're standing up a self-hosting solution as a hot/cold backup to your 3rd party vendor "in the event of an extended outage". Kinda eliminates all those pennies saved (in theory) for outsourcing to "the cloud" if you have to duplicate your infra. Hybrid has always seemed the most optimal approach, but there's always someone in charge who thinks spending money on safety nets is just wasted money.

theteapot 2y ago
Doesn't it exactly solve "extended outages and forced exits from third party vendors."?
- Over2Chars 2y ago
  Self hosting as an alternative (excluding the 3rd party) or self-hosting as a method of redundancy (in addition to the third party)? If you self host as an ALTERNATIVE to the 3rd party you have all of the same problems - more because you know about them, and the 3rd party can make all these claims you can't verify until they fall over with a "load balancer misconfig" story you also can't verify. If you self-host redundantly to a 3rd party you have no special benefit (it does the same thing) AND the additional cost of a redundant infrastructure. Why not just have redundant 3rd parties (so-called "multi-cloud") if you can't or won't trust your 3rd party.
  - theteapot 2y ago
    I believe the point was protecting against risk of 3rd party falling over. If you self host that reduces the risk. At least you have visibility into the falling over process.
    - Over2Chars 2y ago
      It reduces the risk only if your self-hosted solution also doesn't fall over. It's like saying "I can reduce the risk of my rental car failure by owning my own car", assuming your own car you keep undriven in your garage, doesn't have a dead battery, no gas, flat tires, and proves to be unusable for hauling. The "cloud" was touted as the fix for all that nuisance in self-hosting. Magically Jeff's bit barn would work to five 9s of uptime, and you could sit back and write your code, unshackled to infra. Until Jeff's bit barn went tits up. I say the "cloud" is just another guys data center behind an API. You wanna cloud experience? Put an API in front of your own servers and burn a $100 bill.
hamandcheese 2y ago
Since git is distributed, I wonder if it's enough to demonstrate the capability to spin up an alternative, but not necessary keep it up as a live backup 24/7.
- Over2Chars 2y ago
  If all you care about is insurance, I think you can sometimes merely attest "yeah, it will work" and check a box. No demo necessary (sadly). If you actually care about uptime, then a real demo with usage is likely the better approach: switch over to your "backup" on a regular basis and make sure it works 100% as expected.
  - hamandcheese 2y ago
    My hypothetical universe is "I believe GitHub is too big to fail and want to spend as little resources to please the auditor as is reasonably possible without resorting to fraud". So really what I'm asking is "how strict are these audits really?"
    - Over2Chars 2y ago
      Github is owned by Microsoft so I'm assuming, maybe incorrectly, that they're well funded. Internal audits are always subject to gaps, but if the stated issue is correct "a load balancer config change gone pear shaped" an audit wouldn't have caught that necessarily. Unless the audit wants to test their change control, deployment methods, and redundancy. Are they changing all of their load balancers all at once? Seems non optimal. Maybe change only one at a time, or a small batch. Are they propagating load balancer changes from a canary to production without vetting it's good? Or did they vet it and they were wrong - some difference in their canary or analysis had a short coming? And even if all of that was A-OK why did a mistake (and we all make mistakes) not get reverted quickly? Were there insufficient internal controls to revert small mistakes and keep them from becoming site wide outages? And so on. I suspect these kinds of discussions are happening. Or, maybe not. Who knows? It's a 3rd party, and even if your whole organization's life depends on it you only know what they tell you. Welcome to "the cloud".

theteapot 2y ago

Doesn't it exactly solve "extended outages and forced exits from third party vendors."?

Over2Chars 2y ago
Self hosting as an alternative (excluding the 3rd party) or self-hosting as a method of redundancy (in addition to the third party)? If you self host as an ALTERNATIVE to the 3rd party you have all of the same problems - more because you know about them, and the 3rd party can make all these claims you can't verify until they fall over with a "load balancer misconfig" story you also can't verify. If you self-host redundantly to a 3rd party you have no special benefit (it does the same thing) AND the additional cost of a redundant infrastructure. Why not just have redundant 3rd parties (so-called "multi-cloud") if you can't or won't trust your 3rd party.
- theteapot 2y ago
  I believe the point was protecting against risk of 3rd party falling over. If you self host that reduces the risk. At least you have visibility into the falling over process.
  - Over2Chars 2y ago
    It reduces the risk only if your self-hosted solution also doesn't fall over. It's like saying "I can reduce the risk of my rental car failure by owning my own car", assuming your own car you keep undriven in your garage, doesn't have a dead battery, no gas, flat tires, and proves to be unusable for hauling. The "cloud" was touted as the fix for all that nuisance in self-hosting. Magically Jeff's bit barn would work to five 9s of uptime, and you could sit back and write your code, unshackled to infra. Until Jeff's bit barn went tits up. I say the "cloud" is just another guys data center behind an API. You wanna cloud experience? Put an API in front of your own servers and burn a $100 bill.

hamandcheese 2y ago

Since git is distributed, I wonder if it's enough to demonstrate the capability to spin up an alternative, but not necessary keep it up as a live backup 24/7.

Over2Chars 2y ago
If all you care about is insurance, I think you can sometimes merely attest "yeah, it will work" and check a box. No demo necessary (sadly). If you actually care about uptime, then a real demo with usage is likely the better approach: switch over to your "backup" on a regular basis and make sure it works 100% as expected.
- hamandcheese 2y ago
  My hypothetical universe is "I believe GitHub is too big to fail and want to spend as little resources to please the auditor as is reasonably possible without resorting to fraud". So really what I'm asking is "how strict are these audits really?"
  - Over2Chars 2y ago
    Github is owned by Microsoft so I'm assuming, maybe incorrectly, that they're well funded. Internal audits are always subject to gaps, but if the stated issue is correct "a load balancer config change gone pear shaped" an audit wouldn't have caught that necessarily. Unless the audit wants to test their change control, deployment methods, and redundancy. Are they changing all of their load balancers all at once? Seems non optimal. Maybe change only one at a time, or a small batch. Are they propagating load balancer changes from a canary to production without vetting it's good? Or did they vet it and they were wrong - some difference in their canary or analysis had a short coming? And even if all of that was A-OK why did a mistake (and we all make mistakes) not get reverted quickly? Were there insufficient internal controls to revert small mistakes and keep them from becoming site wide outages? And so on. I suspect these kinds of discussions are happening. Or, maybe not. Who knows? It's a 3rd party, and even if your whole organization's life depends on it you only know what they tell you. Welcome to "the cloud".