4 ms·

> If only I could make the same counterargument when my clients complain about downtime. :) If you can't make that argument, then you indeed have a problem. Do

> If only I could make the same counterargument when my clients complain about downtime. :) If you can't make that argument, then you indeed have a problem. Downtimes happen, reducing them gets expensive fast. 95% is fairly simple, 99.999 is extremely hard - it requires redundancy on each and every level. Every time a client demands this, I reframe their request in terms of required engineering effort. Few, if any, actually care about the 9 behind the decimal point after that. The best clients had downtimes already integrated into their operating plans: What happens if we go down, partially or fully, what do we do, how do we communicate and - most importantly, how do we get back up as fast as possible again.

laumars 9y ago
Your point is true for the smaller clients we work with but is an impossible ideology with the larger ones. Without wanting to give away too much identifiable information, my clients include multiple major national publishers, a few international sports bodies, and one household console gaming brand. They are businesses an order of magnitude larger than us and to compete for business you have to make some pretty serious pitches. Sadly uptime is usually one of their primary expectations. In fact one of our sports clients even demanded we have provisions in retain complete uptime during DDoS attacks! (though we did manage to negotiate a compromise on that requirement - thankfully)
- pbecotte 9y ago
  If you are selling your clients those types of guarantees, then you aren't going to be able to rely on a public service with less reliability than your guarantee. Which probably means you are out of luck... I can't imagine it is worth it financially for github or gitlab to pay for too many 9s. Of course, based on your comment, it also sounds like you aren't willing to pay for the type of reliability promises that you are selling, so it seems odd to complain about a free service not doing so.
  - laumars 9y ago
    As stated elsewhere, we are willing and do pay for those services. In fact we moved from self hosting Git (which was free) to a paid hosted solution. So we do currently pay for git hosting and is something I'm happy to continue to do (albeit I have no allegiances with any specific hosting providers). With regards to your first point. Yes you're right about how it's probably not in Gitlabs interest to pay for too many 9s. Maybe Gitlab initially appeared to have worse availability than their competitors because they're more open with their literature so I read more about Gitlab's problems than their competitors. But reading a bit more on Gitlab I found a document about provisioning Gitlab in HA environments, which addresses some of the points I'd been discussing.
- Xylakant 9y ago
  > Without wanting to give away too much identifiable information, my clients include multiple major national publishers, a few international sports bodies, and one household console gaming brand. Which is all fine and dandy - then use a service that provides the required SLA and pay the price (github business or enterprise, have someone host gitlab for you with the required SLA, ...) or store your data redundantly in gitlab and github at the same time (git can do that) and factor the overhead into the bill. I'm not saying a good uptime is impossible - it's just something that will cost (a lot of) money. Bill accordingly. All the while keep in mind that the SLA of the source code hosting should not have any impact on the uptime of the service itself. Clients - especially larger ones - as a matter of fact do understand that the SLA on issue tracking, code hosting etc. can differ from the SLA on the app.
  - laumars 9y ago
    We do pay for git hosting (why does everyone assume that I expect this to be free?) The issue isn't so much with code hosting but more with code pipelining. We can live without being able to do `git push` for 24 hours(see footnote), but having our code pipeline down during a tight release cycle could be detrimental. This obviously isn't Gitlab's problem, just a side effect of the current devops automation culture. But something I need to plan for - or at least have considered and weighed up the cost vs impact to business. Footnote: I'm not implying Gitlab has outages lasting this long. I'm just plucking a figure out of thin air for the sake of a wider discussion regarding HA.
corobo 9y ago
> Every time a client demands this, I reframe their request in terms of required engineering effort Also a good option - reframe their request in terms of cost. They'll back down a 9 or two when you start adding commas to their monthly invoice.

laumars 9y ago

Your point is true for the smaller clients we work with but is an impossible ideology with the larger ones. Without wanting to give away too much identifiable information, my clients include multiple major national publishers, a few international sports bodies, and one household console gaming brand. They are businesses an order of magnitude larger than us and to compete for business you have to make some pretty serious pitches. Sadly uptime is usually one of their primary expectations. In fact one of our sports clients even demanded we have provisions in retain complete uptime during DDoS attacks! (though we did manage to negotiate a compromise on that requirement - thankfully)

pbecotte 9y ago
If you are selling your clients those types of guarantees, then you aren't going to be able to rely on a public service with less reliability than your guarantee. Which probably means you are out of luck... I can't imagine it is worth it financially for github or gitlab to pay for too many 9s. Of course, based on your comment, it also sounds like you aren't willing to pay for the type of reliability promises that you are selling, so it seems odd to complain about a free service not doing so.
- laumars 9y ago
  As stated elsewhere, we are willing and do pay for those services. In fact we moved from self hosting Git (which was free) to a paid hosted solution. So we do currently pay for git hosting and is something I'm happy to continue to do (albeit I have no allegiances with any specific hosting providers). With regards to your first point. Yes you're right about how it's probably not in Gitlabs interest to pay for too many 9s. Maybe Gitlab initially appeared to have worse availability than their competitors because they're more open with their literature so I read more about Gitlab's problems than their competitors. But reading a bit more on Gitlab I found a document about provisioning Gitlab in HA environments, which addresses some of the points I'd been discussing.
Xylakant 9y ago
> Without wanting to give away too much identifiable information, my clients include multiple major national publishers, a few international sports bodies, and one household console gaming brand. Which is all fine and dandy - then use a service that provides the required SLA and pay the price (github business or enterprise, have someone host gitlab for you with the required SLA, ...) or store your data redundantly in gitlab and github at the same time (git can do that) and factor the overhead into the bill. I'm not saying a good uptime is impossible - it's just something that will cost (a lot of) money. Bill accordingly. All the while keep in mind that the SLA of the source code hosting should not have any impact on the uptime of the service itself. Clients - especially larger ones - as a matter of fact do understand that the SLA on issue tracking, code hosting etc. can differ from the SLA on the app.
- laumars 9y ago
  We do pay for git hosting (why does everyone assume that I expect this to be free?) The issue isn't so much with code hosting but more with code pipelining. We can live without being able to do `git push` for 24 hours(see footnote), but having our code pipeline down during a tight release cycle could be detrimental. This obviously isn't Gitlab's problem, just a side effect of the current devops automation culture. But something I need to plan for - or at least have considered and weighed up the cost vs impact to business. Footnote: I'm not implying Gitlab has outages lasting this long. I'm just plucking a figure out of thin air for the sake of a wider discussion regarding HA.

corobo 9y ago

> Every time a client demands this, I reframe their request in terms of required engineering effort Also a good option - reframe their request in terms of cost. They'll back down a 9 or two when you start adding commas to their monthly invoice.