Earlier quoted context omitted.
I think this is a problem that's inherent in "the modern web". Trusting part of your business process to a SaaS application is always going introduce risk. Sometimes it's a calculated risk, and if you have contingency plans in place then it's acceptable. But in most cases, users simply aren't prepared for the day that a critical part of their workflow changes or disappears. I know it's not a popular opinion here, but…
>Trusting part of your business process to a SaaS application is always going introduce risk. Trusting part of your business process to yourself is always going to introduce risk. This is the primary fallacy of the anti-SaaS argument. Cloud providers go down, but so do you . For an in-house solution to be superior from a reliability perspective, you not only need to show that cloud providers go down, but that you go…
Like many others in the industry, I've had network applications which have run for years without unscheduled downtime. When I'm hosting my own application, I can architect whichever failover/redundancy solution I see fit. If my application does go down, I have physical access to the server and the data. My dependencies are all local, clearly outlined and easy to manage (from a risk perspective).
On the other hand, if I trust your SaaS application I'm also trusting that your backup and resilience procedures are at least as good as mine. I'm trusting that your dependencies are all managed in such a way that a failure can quickly be remedied or a contingency plan activated. I'm trusting your providers in the same way I'm trusting you. The opaque black box of your application frankly scares me. I can manage what I can see and what I can understand.
Not to over generalise, but there is a trend in SaaS application design towards the school of "let someone else worry about it" dependency management. This is clear in both infrastructure and libraries/frameworks. Many even outsource critical functionality to other third party SaaS services altogether (push notification, messaging, queue management, transcoding). Besides core application architecture, we also have to worry about connectivity (mine, yours, all of your dependencies). That's a lot of moving parts which can (and do) fail.
I trust my transparent, well documented system with its clear contingency plans much more than your opaque SaaS application, its unknown dependencies and its myriad moving parts.
And as we see all too often on HN, it's not just about downtime - SaaS applications shut down and disappear. If you're lucky, you get a chance to export your data. I'm certainly not suggesting that companies should continue to operate them at a loss for years, but given the choice between relying on someone else's SaaS product and depending on a locally hosted application, I'm going locally hosted every time when it concerns critical business workflow.
I'm not anti-SaaS at all, I just think we should be clear in our own minds about the risks introduced by relying heavily on third party providers (and I mirror that awareness in dependency management in my own software).
(On a side note: I find it interesting that while many of the users on HN ardently support SaaS, they condemn always-online DRM.)