6 ms·

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.
    - dmurray 8y ago
      Having a fast, cheap and detailed feedback loop is useful for testing for the bad guys, like in any programming process. For example, in the credit card case, you can check thousands of cards without needing to find a merchant who will take your thousands of small, frequently-declined transactions. Or you can check the details for cards you haven't fully compromised (maybe the guy selling you stolen bank cards only gives you a portion of the details until you've paid him).
      - laumars 8y ago
        Oh absolutely. Like many things security related, it's not always about stopping them but rather slowing them down enough so that it doesn't become cost effective.
- jamespo 8y ago
  That's preferable for the customer but it's obvious why a vendor wouldn't be keen.
  - laumars 8y ago
    > That's preferable for the customer I wouldn't say it's preferable for the customer. It's just one of many options. > but it's obvious why a vendor wouldn't be keen Yes, SaaS obviously has benefits for vendors too but what's most preferable to them is making money. If every customer refused to do business with SaaS then vendors wouldn't prefer providing SaaS solutions (yes, I know I said "solutions solutions" :P). The reason SaaS is so prolific is because it offers advantages to customers as well.
    - zrobotics 8y ago
      >>yes, I know I said "solutions solutions" :P When has SaaS stood for anything besides Software as a Service? Because software as a solution could describe almost any business model?
      - laumars 8y ago
        Yeah you're right. And weirdly I did know that so I haven't a clue why I wrote that comment. I can only assume it was a multitasking fail. Thanks for the correction though :)

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.
  - dmurray 8y ago
    Having a fast, cheap and detailed feedback loop is useful for testing for the bad guys, like in any programming process. For example, in the credit card case, you can check thousands of cards without needing to find a merchant who will take your thousands of small, frequently-declined transactions. Or you can check the details for cards you haven't fully compromised (maybe the guy selling you stolen bank cards only gives you a portion of the details until you've paid him).
    - laumars 8y ago
      Oh absolutely. Like many things security related, it's not always about stopping them but rather slowing them down enough so that it doesn't become cost effective.
jamespo 8y ago
That's preferable for the customer but it's obvious why a vendor wouldn't be keen.
- laumars 8y ago
  > That's preferable for the customer I wouldn't say it's preferable for the customer. It's just one of many options. > but it's obvious why a vendor wouldn't be keen Yes, SaaS obviously has benefits for vendors too but what's most preferable to them is making money. If every customer refused to do business with SaaS then vendors wouldn't prefer providing SaaS solutions (yes, I know I said "solutions solutions" :P). The reason SaaS is so prolific is because it offers advantages to customers as well.
  - zrobotics 8y ago
    >>yes, I know I said "solutions solutions" :P When has SaaS stood for anything besides Software as a Service? Because software as a solution could describe almost any business model?
    - laumars 8y ago
      Yeah you're right. And weirdly I did know that so I haven't a clue why I wrote that comment. I can only assume it was a multitasking fail. Thanks for the correction though :)