Friday, August 29, 2008

More Reasons Not to Trust SaaS

It might be the most cliche of reasons not to trust SaaS, but I see too many of these types of issues:

These events might be rare. but consider that this was the second events for Amazon in the last six months and I think that the fact

Recent DNS vulnerabilities can also affect access to remote services.

I'm thinking we need to be very careful when considering SaaS, particularly in mission critical applications where Identity Management and work flow could be involved.

I just can't help but think I'd rather have these things under my organization's troubleshooting and control rather than someone else's...

5 comments:

Sam Johnston said...

You've touched on an interesting point here, not in that SaaS should not be trusted (SaaS security, including availability, is very good, constantly improving, and usually better than existing legacy systems) but in that when there is a problem there is little for users to do but wait for a resolution. This often doesn't sit well with those responsible for keeping systems up.

Sam

Matt Pollicove said...

Sam,

No doubt about it... I'm not a SaaS fan. It's one thing to have to trust my VPN connection but when that scales beyond(Google, or Amazon or Whomever) There's an extra layer or risk, in terms of productivity and compliance either of which can equal $$$ (or the currency of your choice)

Sam Johnston said...

People used to run their own generators too, right up until the power grid came along and blew the entire industry out of the water. Expect the same to happen with cloud computing even if only because of economies of scale.

Matt Pollicove said...

Hmmm... That brings up some interesting thoughts. We did used to generate our own power, water, sewage, etc.

What's the level of scale here? Is it data comm infrastructure, SaaS providers, the local phone, cable or power companies (all of which are not only involved in the large scale infrastructure noted above, but also do the final connections to home and business)

I think you need to keep the "fuel" in this case the communications infrastructure, separate from the "car" the SaaS provider otherwise we could have another "gas crisis" come about, which is worry about SaaS availability I feared in the first place.

This being said, I don't disagree with you about the eventual emergence for SaaS systems, I just am not sure that what we are currently seeing is what is the result of the economies of scale that you are anticipating.

Sam Johnston said...

The main theme of 'cloud computing' (rather than SaaS specifically) is that the user doesn't need to care what network links, servers, storage, etc. are used; they just connect 'to the cloud' and consume computing resources like a utility. Separating it all out doesn't really add any value for the user, rather uncovering complexity that 'the cloud' is meant to hide.

That is not to say that we don't need dialtone availability - users know that when they pick up their phone they'll hear a dialtone (but this wasn't always the case)... the same should be able to be said of SaaS.

Sam