6 ms·

"trust and safety as a service" So... what was the Service Level Agreement? and the Terms Of Service? People get all hyped by -aaS stuff, but services do go d

by jarfil 8y ago

"trust and safety as a service" So... what was the Service Level Agreement? and the Terms Of Service? People get all hyped by -aaS stuff, but services do go down, and if you aren't the one controlling when and how they will go up, then you better have a contract with the Service Provider on some terms you like. Even then, prepare for when they go down, because they will sooner or later, for shorter or longer periods of time. I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage.

lainga 8y ago
Welcome to the world of third-party Twitter clients. Not content with screwing over businesses relying on Twitter's API, it seems, they have now set out to screw over any company relying on any other third-party API as well.
pvg 8y ago
I find it silly to rely on some service, any external service This is always trotted out and it's, by this point, a completely content-free thing to say. Short of removing yourself from the economy and society in general to live off potatoes grown in your own dung, you're going to rely on some external services and the fact that, for the most part, the parties you do business with will behave responsibly. When they behave very irresponsibly, unpleasant things happen and people quite reasonably complain.
- deleted 8y ago
  [deleted]
- bastawhiz 8y ago
  Exactly. You want reliable CAPTCHAs? CDN service? Malware detection? Customer support software? Website uptime monitoring? Accounting software? Analytics? Email delivery? Good luck building and running all that yourself.
  - im3w1l 8y ago
    All of those can be bought and then self hosted except for CDN.
    - mortenjorck 8y ago
      That definitely solves the building part.
    - jtms 8y ago
      hosted where? On a VPS, in a data center, or in your closet? All of these depend on third party services and good luck keeping them up and running as well as someone who makes just that ONE little thing their entire reason for existing.
      - y4mi 8y ago
        I don't agree with the parent either (I'd rather use a SaaS if it makes sense) its also not as easy as you make it sound. For starters, most smallish companies I know of use housing for their servers. So, they actually do own the hard metal servers and have full access to them. Both over SSH and on the console for debugging purposes. The housing provider generally replaces HDDs in case of disk failures. naturally, you're still dependent on electricity and internet, but even that can be mitigated by spreading your servers across several locations. All of that is obviously possible with AWS, GCP or other VPS hosts, but doing it yourself is not that much harder if you've got an experienced ops person that wants to bother with all of that. but i repeat... Its often not worth the time investment to get that system properly set up. Just renting VMs or going straight into dockerized microservices is an increasingly better alternative
      - jarfil 8y ago
        > On a VPS, in a data center, or in your closet? Yes, any of those sounds like a good enough plan B. You don't need it to be perfect, just good enough to avoid getting stranded in a pinch. Then you can start shopping around for someone who does that one little thing much better than you do. That way it no longer is a show stopper and rather just an optimization problem.
- JdeBP 8y ago
  You've constructed a straw man, by removing an important part of that sentence and indeed the rest of what you are replying to.
  - 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.
- jarfil 8y ago
  No. Whether it's potatoes or servers, having a single point of failure with no plan B in place, is silly. Your local restaurant going out of business is no reason for you to starve to death, you just go to another one, or to a grocery store, or indeed grow your own food if you're in some post-apocalyptic world or got no money... but somehow a service provider going out of business is reason enough for your production to stop? No, just no.
- tripzilch 8y ago
  > This is always trotted out and it's, by this point, a completely content-free thing to say. Only if you pretend there are no companies that do in fact responsibly nail this stuff down. There's plenty. Your argument seems to be that nobody does it because it's hard.
consp 8y ago
> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. There are pretty solid SLA's for that. We provide some services as kind-of-saas but the SLAs are watertight. Usually in those kind of sla's you can't sell the company (or move assets) without guarantee of delivery of the contract. In some cases they (the contract holders) even own you if you screw up and go under.
BinaryIdiot 8y ago
> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. I'm curious; what would you have these companies do in such a scenario? If 100% uptime is impossible then what you seem to be suggesting is that people should never use third party services or if they do use them they must not be in a critical path. Are you suggesting everyone should do everything in house?
- lambda 8y ago
  Use free (FLOSS) software. If you have to use non-free software, buy software, not services. If you have to buy services, always have a well-tested fallback path for when that service is not available.
  - s73v3r_ 8y ago
    Care to point out the FLOSS equivalent of what Smyte did?
    - lambda 8y ago
      You missed two thirds of my comment. This was in order of preference. If you can, use free software that you can fix and support yourself if need be. If not, buy the software and run it yourself, so you can at least control its operation. The last option is to by SaaS, and if you do, you need to have contingency plans in case it goes away. You should take this risk seriously, and factor it in to your decision when buying SaaS, and invest the engineering resources to make sure you aren't overly dependent on it.
- jarfil 8y ago
  For any critical service, they should have an alternate provider ready at all times so that they could instantly switch to it. Whether it's another external provider or in house, is not really relevant, although having a bare bones in house alternative for the critical parts is a good idea. What I'm suggesting is that people should use external services for their lower costs, better performance, or extra features, not to 100% depend on any of them.

by jarfil 8y ago

lainga 8y ago

Welcome to the world of third-party Twitter clients. Not content with screwing over businesses relying on Twitter's API, it seems, they have now set out to screw over any company relying on any other third-party API as well.

pvg 8y ago

I find it silly to rely on some service, any external service This is always trotted out and it's, by this point, a completely content-free thing to say. Short of removing yourself from the economy and society in general to live off potatoes grown in your own dung, you're going to rely on some external services and the fact that, for the most part, the parties you do business with will behave responsibly. When they behave very irresponsibly, unpleasant things happen and people quite reasonably complain.

deleted 8y ago
[deleted]
bastawhiz 8y ago
Exactly. You want reliable CAPTCHAs? CDN service? Malware detection? Customer support software? Website uptime monitoring? Accounting software? Analytics? Email delivery? Good luck building and running all that yourself.
- im3w1l 8y ago
  All of those can be bought and then self hosted except for CDN.
  - mortenjorck 8y ago
    That definitely solves the building part.
  - jtms 8y ago
    hosted where? On a VPS, in a data center, or in your closet? All of these depend on third party services and good luck keeping them up and running as well as someone who makes just that ONE little thing their entire reason for existing.
    - y4mi 8y ago
      I don't agree with the parent either (I'd rather use a SaaS if it makes sense) its also not as easy as you make it sound. For starters, most smallish companies I know of use housing for their servers. So, they actually do own the hard metal servers and have full access to them. Both over SSH and on the console for debugging purposes. The housing provider generally replaces HDDs in case of disk failures. naturally, you're still dependent on electricity and internet, but even that can be mitigated by spreading your servers across several locations. All of that is obviously possible with AWS, GCP or other VPS hosts, but doing it yourself is not that much harder if you've got an experienced ops person that wants to bother with all of that. but i repeat... Its often not worth the time investment to get that system properly set up. Just renting VMs or going straight into dockerized microservices is an increasingly better alternative
    - jarfil 8y ago
      > On a VPS, in a data center, or in your closet? Yes, any of those sounds like a good enough plan B. You don't need it to be perfect, just good enough to avoid getting stranded in a pinch. Then you can start shopping around for someone who does that one little thing much better than you do. That way it no longer is a show stopper and rather just an optimization problem.
JdeBP 8y ago
You've constructed a straw man, by removing an important part of that sentence and indeed the rest of what you are replying to.
- 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.
jarfil 8y ago
No. Whether it's potatoes or servers, having a single point of failure with no plan B in place, is silly. Your local restaurant going out of business is no reason for you to starve to death, you just go to another one, or to a grocery store, or indeed grow your own food if you're in some post-apocalyptic world or got no money... but somehow a service provider going out of business is reason enough for your production to stop? No, just no.
tripzilch 8y ago
> This is always trotted out and it's, by this point, a completely content-free thing to say. Only if you pretend there are no companies that do in fact responsibly nail this stuff down. There's plenty. Your argument seems to be that nobody does it because it's hard.

consp 8y ago

> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. There are pretty solid SLA's for that. We provide some services as kind-of-saas but the SLAs are watertight. Usually in those kind of sla's you can't sell the company (or move assets) without guarantee of delivery of the contract. In some cases they (the contract holders) even own you if you screw up and go under.

BinaryIdiot 8y ago

> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. I'm curious; what would you have these companies do in such a scenario? If 100% uptime is impossible then what you seem to be suggesting is that people should never use third party services or if they do use them they must not be in a critical path. Are you suggesting everyone should do everything in house?

lambda 8y ago
Use free (FLOSS) software. If you have to use non-free software, buy software, not services. If you have to buy services, always have a well-tested fallback path for when that service is not available.
- s73v3r_ 8y ago
  Care to point out the FLOSS equivalent of what Smyte did?
  - lambda 8y ago
    You missed two thirds of my comment. This was in order of preference. If you can, use free software that you can fix and support yourself if need be. If not, buy the software and run it yourself, so you can at least control its operation. The last option is to by SaaS, and if you do, you need to have contingency plans in case it goes away. You should take this risk seriously, and factor it in to your decision when buying SaaS, and invest the engineering resources to make sure you aren't overly dependent on it.
jarfil 8y ago
For any critical service, they should have an alternate provider ready at all times so that they could instantly switch to it. Whether it's another external provider or in house, is not really relevant, although having a bare bones in house alternative for the critical parts is a good idea. What I'm suggesting is that people should use external services for their lower costs, better performance, or extra features, not to 100% depend on any of them.