4 ms·

Indeed, it's spurred a discussion of an over-simplification of the issues. I don't think anyone is suggesting never to outsource, or even that the answer to "b

by mmt 8y ago

Indeed, it's spurred a discussion of an over-simplification of the issues. I don't think anyone is suggesting never to outsource, or even that the answer to "build vs. buy" is always "build". The point is not having a critical dependency on a single vendor. I don't think anyone is even saying "never", either. The question is one of risk. The risk of your tax accountant "going down" (or being crooked or something) is sufficiently low, and the cost of making that redundant is sufficiently high, that I don't think anybody does that. This could even apply to general accounting software, though one might argue that's not critical in the same way and/or more easily replaceable. There's a sibling sub-thread that essentially implies, if not outright states that there's no choice but to "buy" in "build vs. buy". Although it may be true that building is no longer a practical choice due to time/cost, under certain circustances, it by no means eliminates the risk if there's only one vendor. It's also a decision that can end up having tremendous costs at scale, if not re-evaluated, especially with even a soft version of vendor lock-in, like AWS.

pvg 8y ago
That's not what the comment I replied to said, though. It just said it's 'silly'. If they had said something specific about, let's say, npm and made some reasonable and knowledgable comment or even speculation about how in this particular case they'd mis-assessed risk, that would be a pretty interesting comment. As it is, it's just a clone of the same tedious comment we get in droves in every thread about some multi-party outage. They're generic and free of insight.
- deleted 8y ago
  [deleted]
- abiox 8y ago
  > It just said it's 'silly'. you did not include "so much that if it goes down it would cause a prod outage" in your quote, which is why the strawman claim was put forth.
  - pvg 8y ago
    It doesn't really change the quality of the comment. There is nothing inherently and outright wrong with such a dependence, whether it causes an outage in prod or not. In some cases it matters (maybe you're making a nuclear reactor) in many, it's a completely sensible tradeoff. Reflexively saying 'zomg you depend on something else and this is bad' every single time something is affected by a problem in another thing is 100% uninteresting. Including or not including 'in prod' or 'in bed' doesn't make it any more interesting or clever. It's just lazy grousing.
    - mmt 8y ago
      > There is nothing inherently and outright wrong with such a dependence This is yet another strawman. The original commenter found it "silly", which, I agree, was a poor choice of wording. Perhaps "overly risky" would have been better. I don't know. I just take the most charitable reading, per the guidelines. It also comes after an exhortation to have a contingency plan, so it's at least implied that the "silliness" isn't inherent merely to the dependence but to the dependence without such a plan. > in many, it's a completely sensible tradeoff Is the tradeoff actually considered, though? Or is there just an automatic "we're not a nuclear reactor" decision process? > is 100% uninteresting Were that true, I doubt there would be replies. This is not one of those traditionally emotional/political issues. > Including or not including 'in prod' I (again, charitably) read "in prod" as a metaphor for "business critical". I'm sure we can all come up with examples, even in Internet companies, where one does not necessarily mean the other (or vice-versa). In the instant case, it seems to apply, so it made sense as shorthand. > It's just lazy grousing. I would agree if there were no built-in suggestion on how to avoid the problem at all, but there were. Just because the point has been made before doesn't make it any less valid, until it has been refuted.
      - pvg 8y ago
        This is yet another strawman. Only if 'strawman' means 'thing I disagree with'. The comment says such a dependence is bad and how you have to prepare for it with SLAs or whatever. This isn't universally true at all. I doubt there would be replies. A lot of really boring, trite things generate piles of replies. That's why they should be avoided. Just because the point has been made before doesn't make it any less valid The stated goal of the forum is not 'an exhaustive, if repetitive collection of generically valid things'. Remember that time you wanted to print something and the thing just wouldn't print? That's bad and annoying. It's valid that it's bad and annoying. We probably don't need to talk about it in the general sense every time it happens, though.

by mmt 8y ago

pvg 8y ago

That's not what the comment I replied to said, though. It just said it's 'silly'. If they had said something specific about, let's say, npm and made some reasonable and knowledgable comment or even speculation about how in this particular case they'd mis-assessed risk, that would be a pretty interesting comment. As it is, it's just a clone of the same tedious comment we get in droves in every thread about some multi-party outage. They're generic and free of insight.

deleted 8y ago
[deleted]
abiox 8y ago
> It just said it's 'silly'. you did not include "so much that if it goes down it would cause a prod outage" in your quote, which is why the strawman claim was put forth.
- pvg 8y ago
  It doesn't really change the quality of the comment. There is nothing inherently and outright wrong with such a dependence, whether it causes an outage in prod or not. In some cases it matters (maybe you're making a nuclear reactor) in many, it's a completely sensible tradeoff. Reflexively saying 'zomg you depend on something else and this is bad' every single time something is affected by a problem in another thing is 100% uninteresting. Including or not including 'in prod' or 'in bed' doesn't make it any more interesting or clever. It's just lazy grousing.
  - mmt 8y ago
    > There is nothing inherently and outright wrong with such a dependence This is yet another strawman. The original commenter found it "silly", which, I agree, was a poor choice of wording. Perhaps "overly risky" would have been better. I don't know. I just take the most charitable reading, per the guidelines. It also comes after an exhortation to have a contingency plan, so it's at least implied that the "silliness" isn't inherent merely to the dependence but to the dependence without such a plan. > in many, it's a completely sensible tradeoff Is the tradeoff actually considered, though? Or is there just an automatic "we're not a nuclear reactor" decision process? > is 100% uninteresting Were that true, I doubt there would be replies. This is not one of those traditionally emotional/political issues. > Including or not including 'in prod' I (again, charitably) read "in prod" as a metaphor for "business critical". I'm sure we can all come up with examples, even in Internet companies, where one does not necessarily mean the other (or vice-versa). In the instant case, it seems to apply, so it made sense as shorthand. > It's just lazy grousing. I would agree if there were no built-in suggestion on how to avoid the problem at all, but there were. Just because the point has been made before doesn't make it any less valid, until it has been refuted.
    - pvg 8y ago
      This is yet another strawman. Only if 'strawman' means 'thing I disagree with'. The comment says such a dependence is bad and how you have to prepare for it with SLAs or whatever. This isn't universally true at all. I doubt there would be replies. A lot of really boring, trite things generate piles of replies. That's why they should be avoided. Just because the point has been made before doesn't make it any less valid The stated goal of the forum is not 'an exhaustive, if repetitive collection of generically valid things'. Remember that time you wanted to print something and the thing just wouldn't print? That's bad and annoying. It's valid that it's bad and annoying. We probably don't need to talk about it in the general sense every time it happens, though.