4 ms·

Everything was back on track very quickly, no data loss. Github has had major service outages recently as well (just google it to refresh your mind). They'll

Everything was back on track very quickly, no data loss. Github has had major service outages recently as well (just google it to refresh your mind). They'll both have a few issues in the future because nobody is perfect. Come on.

laumars 9y ago
> "because nobody is perfect. Come on." If only I could make the same counterargument when my clients complain about downtime. :) Sadly in the modern world people expect ridiculous uptimes and thus my expectations are just derived from my clients expectations. I don't like that much either but frankly clients often just get their expectations from their customers demands. These days people expect 24/7 uptime so my job is to facilitate that wherever I can.
- mugsie 9y ago
  Sure - but is there any alternatives? Gitlab does have issues, but so do GitHub (and other providers). If your service is taken down by code hosting going away there is issues - unless you are running a code hosting service, or managed DevOps - in which case, the onus is on you to develop for failure (of any provider)
- Xylakant 9y ago
  > 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.
- deleted 9y ago
  [deleted]

laumars 9y ago

> "because nobody is perfect. Come on." If only I could make the same counterargument when my clients complain about downtime. :) Sadly in the modern world people expect ridiculous uptimes and thus my expectations are just derived from my clients expectations. I don't like that much either but frankly clients often just get their expectations from their customers demands. These days people expect 24/7 uptime so my job is to facilitate that wherever I can.

mugsie 9y ago
Sure - but is there any alternatives? Gitlab does have issues, but so do GitHub (and other providers). If your service is taken down by code hosting going away there is issues - unless you are running a code hosting service, or managed DevOps - in which case, the onus is on you to develop for failure (of any provider)
Xylakant 9y ago
> 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.
deleted 9y ago
[deleted]