[ngw] Cloud Mentality - I disagree

Steve Bogdanski bogdansk at cvm.msu.edu
Fri Apr 23 12:33:04 UTC 2010

Agreed. It seems like half Richard's point is that since cloud-based services are harder to define and that somehow makes them safer.  The other half of his argument seems to be that if you go with the cloud then it removes your responsibility to maintain proper access, backup and disaster recovery scenarios for your data.  Both ideas are bad.   While I can see benefit with cloud services, I think that data security and reliability are the two weakest arguments for moving in that direction.
Joe mentions Google, but what about the even more disastrous T-Mobile/Microsoft failure that left Sidekick users without their contacts, etc? See what happens when you expect others to take care of your data!  That also reminds me of the news story about an online backup service that didn't maintain it's own backups of data, I can't remember the name but it was a few years back.  A few other examples of this is Yale's decision to suspend it's move Google Apps, because it couldn't get reliable information from Google on where it's data would actually be stored (only that it wouldn't be in a handful of countries) or the fact that Google had to go about creating a whole new cloud infrastructure to land the L.A. deal.
Until security and communication infrastructure improve I still think that cloud services are best for commodity processing (especially on a temporary demand basis) and for those without the money, or resources, to run their IT infrastructure internally.

>>> On 4/23/2010 at  7:30 AM, Joseph Marton <jmmarton at gmail.com> wrote:

Ah, yes, and because the cloud is big, it can't fail, right? Let's see. About a month and a half ago a key production NetWare server here abended during the day thanks to Java. Other than that short 5-10 minute outage while the server rebooted, when's the last time it went down during the day? Oh I don't know... maybe 2008? In comparison, how many times has various portions of the Google network been down in 2010? How about 2009? I'd say many more. And for how long each time? Definitely more than 5 or 10 minutes. I'm sure Google probably has a few more resources than my company (50 person financial services company) yet that hasn't prevented outages.

Just because the cloud is big doesn't mean there can't be failures. There can and will be. So when you take that out of the equation, you now have to look at possibilities of Internet connection failures. And remember, this doesn't just mean that the connection to your ISP is down. I've had a couple of "failures" where our connection in Chicago to Verizon remained up, but an issue further upstream caused an outage. Heck not even two weeks ago there was a problem where a small Chinese ISP's router started advertising routes via BGP, which other routers accepted, causing thousands of networks to essentially go down because routers all over the world sent those networks' traffic to China instead of the appropriate locations.


 ( http://www.h-online.com/security/news/item/Chinese-ISP-hijacks-bits-of-the-web-975344.html )This is just how fragile the Internet is. Now think about it, if a company had most of its resources in the cloud and the cloud got hit by something similar to what happened recently, now suddenly the company may not have access to key systems. So why go through that risk if the cloud itself isn't necessarily any more stable than internal systems?


On Fri, Apr 23, 2010 at 1:34 AM, Richard Bliss <rbliss at gwava.com> wrote:

You second point talked about connection as another reason to avoid the cloud mentality. You ask if we have ever had Internet outages? The better questions is, how many times have you had system failures within your own organizations due to mechanical or human error compared to the number of times you haven't been able to get on the Internet when you needed to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ngwlist.com/pipermail/ngw/attachments/20100423/64dff478/attachment.html 

More information about the ngw mailing list