5 ms·

> Sure you'd still eventually need to migrate away but at least you could then do it on your own terms. I think people often underestimate the value of being a

> Sure you'd still eventually need to migrate away but at least you could then do it on your own terms. I think people often underestimate the value of being able to manage their own destiny. They key point here is "manage" though: you have to actually do it - it's an active process. If, on the other hand, you simply stick your head in the sand and ignore the situation it will eventually get to the point where it becomes extremely difficult and expensive to deal with due to a variety of factors such as no clear migration path, loss of institutional knowledge, and so on. I name no names, but worked for one UK company in particular with form here. I'm not making an argument against SaaS (we use a few of them), but it's important to understand the trade-offs you're making in terms of ceding control.

x0x0 8y ago
Sure, but a service like Smyte requires significant expertise to make work well and run. Pretending you can snap your fingers and implement a Sift Science or Smyte is ludicrous. Further, some of the biggest value they will provide is being able to see transactions between vendors. So eg calculating an IP address reputation score by seeing bursts of fraudulent purchases. That is impossible to do in house only.
- bartread 8y ago
  > Pretending you can snap your fingers and implement a Sift Science or Smyte is ludicrous. But that's not what either I or the GP were talking about: we were talking about hosting a product that you'd purchased from another vendor on your own infrastructure.
  - civilitty 8y ago
    Choosing SaaS products that have self hosted licenses or open source alternatives is part of managing your own destiny and making the right trade off. If the former exists, this discussion is moot because there will almost certainly be a commercially supported migration path (or someone didn't do their research and chose the wrong vendor). If it's the latter you're back to having to invest capital into creating an in-house system while learning how to use, scale, and troubleshoot open source software. If neither... god help you.
  - jamespo 8y ago
    But this sort of systems is particularly suited to being hosted by a third party as you benefit from a network effect via the other customers.
    - laumars 8y ago
      I'm not going to argue that these sort of problems aren't ideally suited for SaaS however it is still worth remembering that systems like this have existed before SaaS took off. eg you would host the API yourself but cron a db update every n hours or days. So if the service went offline you still had a local database and API. The obvious downside to that is you don't have real time updates (as well as the usual other benefits that SaaS brings), which is why SaaS suites this kind of business well. But it can be done and was sometimes done this way "back in the old days".
      - dmurray 8y ago
        Having the db freely available makes it a lot easier for a bad actor to figure out how to avoid getting in it, though. So situations like this are suited to having a centralized owner of the data who can perform rate limiting, restrict to its paying customers, etc. Distributing the database to customers is still workable despite this drawback - antivirus systems are a common example.
        laumars 8y ago
        > Having the db freely available makes it a lot easier for a bad actor to figure out how to avoid getting in it I don't agree with that. Having the database only allows bad actors to see if they've been added to the database - not the business logic of how they ended up in that database. You could argue that knowing you've been added to the database is still an advantage, which is true. But those same bad actors could still test the system with SaaS solutions too. eg when one acquires stolen bank cards it is common to use those details to make small payments for things like food delivery to test if those card have been blocked or not.
        8y ago
deleted 8y ago
[deleted]

x0x0 8y ago

Sure, but a service like Smyte requires significant expertise to make work well and run. Pretending you can snap your fingers and implement a Sift Science or Smyte is ludicrous. Further, some of the biggest value they will provide is being able to see transactions between vendors. So eg calculating an IP address reputation score by seeing bursts of fraudulent purchases. That is impossible to do in house only.

bartread 8y ago
> Pretending you can snap your fingers and implement a Sift Science or Smyte is ludicrous. But that's not what either I or the GP were talking about: we were talking about hosting a product that you'd purchased from another vendor on your own infrastructure.
- civilitty 8y ago
  Choosing SaaS products that have self hosted licenses or open source alternatives is part of managing your own destiny and making the right trade off. If the former exists, this discussion is moot because there will almost certainly be a commercially supported migration path (or someone didn't do their research and chose the wrong vendor). If it's the latter you're back to having to invest capital into creating an in-house system while learning how to use, scale, and troubleshoot open source software. If neither... god help you.
- jamespo 8y ago
  But this sort of systems is particularly suited to being hosted by a third party as you benefit from a network effect via the other customers.
  - laumars 8y ago
    I'm not going to argue that these sort of problems aren't ideally suited for SaaS however it is still worth remembering that systems like this have existed before SaaS took off. eg you would host the API yourself but cron a db update every n hours or days. So if the service went offline you still had a local database and API. The obvious downside to that is you don't have real time updates (as well as the usual other benefits that SaaS brings), which is why SaaS suites this kind of business well. But it can be done and was sometimes done this way "back in the old days".
    - dmurray 8y ago
      Having the db freely available makes it a lot easier for a bad actor to figure out how to avoid getting in it, though. So situations like this are suited to having a centralized owner of the data who can perform rate limiting, restrict to its paying customers, etc. Distributing the database to customers is still workable despite this drawback - antivirus systems are a common example.
      - laumars 8y ago
        > Having the db freely available makes it a lot easier for a bad actor to figure out how to avoid getting in it I don't agree with that. Having the database only allows bad actors to see if they've been added to the database - not the business logic of how they ended up in that database. You could argue that knowing you've been added to the database is still an advantage, which is true. But those same bad actors could still test the system with SaaS solutions too. eg when one acquires stolen bank cards it is common to use those details to make small payments for things like food delivery to test if those card have been blocked or not.
        8y ago

deleted 8y ago

[deleted]