4 ms·

What if Microsoft and Danger #Cloudfail turns out to be a #SANfail?

21 points by rizzn 17y ago

jf781 17y ago
this industry is embronic and more innovation will occur. I love the cloud market very compelling and important for entrepreneurs and big businesses. We will all be renting computing and storage in the short future.
- jf781 17y ago
  how can i tell who knocked my comment down to -2
gfodor 17y ago
The fact that this whole thing is being considered a "cloud" failure is ridiculous. The word has become so meaningless that if I ran over a neighbors dog I could probably blame it on cloud computing.
simonw 17y ago
I know virtually nothing about SANs, other than that they are frighteningly expensive. Can anyone clarify how they compare to systems such as GFS, HDFS, MogileFS and other systems that attempt to store data in a safe, redundant manner across lots of cheap servers?
- wattersjames 17y ago
  Cloud storage systems like S3 are often inferior in raw latency/response performance to a SAN which has VERY expensive adaptor silicon in it--but they are far superior on built in automatic, systematic, redundancy and global fail over and dispersal.
- stingraycharles 17y ago
  I'm not familiar with MogileFS, so if my comments below are incorrect when applied to MogileFS, then I'm sorry. GFS/HDFS are officially called filesystems, but they're about as much as a filesystem as a Samba server: they expose files to the outside world, with some extra layers of abstraction you can mount the filesystems under Linux, but in essence they live on top of existing filesystems themselves and have nothing in common with the traditional filesystems, where you operate on a block device. A SAN, otoh, is such a block device and traditional filesystems operate on them. This means that you can run a RDBMS on a SAN, while you can't on GFS/HDFS. This covers a common use case where you have a central expensive database server, with dozens of terrabytes of storage in a SAN, which you see in a lot of large corporations.
- tptacek 17y ago
  SANs aren't filesystems. They're block devices that run over the network instead of over a SCSI cable. They connect to servers by special HBA cards which look like SCSI devices, but actually run the SCSI protocol over the network to a rack full of disks. In a SAN configuration, the admins of those disks carve out a volume of storage for you, give it a name, and you configure it on your server; now it looks like you have a couple terabytes of storage directly connected. You format it like any other disk. Backup works like any other system; you do it app layer. In high-volume high-sensitivity apps, the people running the disk server also back it up, by running protocols that mirror block-level changes to a second rack full of disks somewhere in Tennessee. (yes, yes, or IDE or FC, yes yes, or software initiator, etc etc).
joe_the_user 17y ago
Uh, Sorry but "cloud" or not, SAN or not, the MS/Danger fail was a stunning failure of process. Who cares what the underlying technology was or how it failed? What matters is that a multi-billion dollar software company actually managed to loose, permanently, their customers' data through obvious carelessness, through either lack of a backup in some fashion or other (and don't even try to argue they could have had an excuse - "multi-billion dollar company" "reputation" backups might be sort-of hard maybe - perhaps - but MS is supposed know what it's doing). Lightning and Asteroids wouldn't strike five different carefully chosen locations... My guess is that this will hit MS really hard over time. Even if they actually were hoping Danger would dry-up and blow away, they've now done the worst case scenario to customers. Repeat after me "never let MS near your data...".
- rbanffy 17y ago
  "MS is supposed know what it's doing" I was in complete agreement with you up to this point. Microsoft's strengths have long ago shifted towards marketing. They once had a edge in technology - over Lotus, over Borland, over Novell, over IBM and even over Apple (in the OS7~9 days). Sadly, after their market share - and dominance of the OEM channels - exceeded a certain tipping point, they had really no need to excel in technology. From that point on, what differentiated Microsoft was a careful management of the expectations of their core market (VARs, OEMs and CTOs). At Microsoft, technical competency has taken a back-seat since the early 90s. This entire mess up smells like "Management by numbers". When a manager cuts costs without considering the implications to data-safety, this is what we get in the end. Seriously: how much data needed to be backed up? 50 terabytes? 500 terabytes? And why the hell the data resides in a SAN and not distributed and replicated in a bunch of front-end servers? The SAN should be the back-up. I love the idea of having all my data on the cloud - It's a major nuisance to switch cellphones and port data from one to the next - and having the data on the cloud could make it easy to access it through a nice web interface not unlike Google's GMail, Calendar, Picasa or Documents. Implementing "back-up your data" and "restore your data" links somewhere would also be quite easy. And yes. Never let MS near your data.
- brown9-2 17y ago
  This is correct. It's a people problem, not a technology problem.
rit 17y ago
Can we just point out that it was clearly a #BackupFail ? No matter WHAT the deployment mode was, the lack of backups is what has turned this into an issue, NOT the SAN or "Cloud" failure.
jsz0 17y ago
When it comes to important data users should mistrust everyone and everything. It is more difficult to backup data from most cloud sources. There's no easy way to backup my entire Flickr account, Facebook profile, or Google account for example. To backup Gmail I have to rely on desktop applications via IMAP. Is this really acceptable? Why don't we have more sites offering easy offline backups? No matter how you look at it the user has to be responsible for their own data. If cloud services are not making this easy to do then we have a legitimate problem.
generalk 17y ago
Why can't it be both? As far as I can tell, "cloud" generally means someone else stores my data and the only way I can get to it is via the Net. In that case it's absolutely a failure of the "cloud". And if the data was stored on a SAN, it's a SAN failure. If someone didn't do backups at all, it's a backup failure. What's with all the labeling? Look, if I pay someone else to manage my data, and they screw it up and I suffer data loss, it doesn't really matter what piece of gear or level of process is responsible -- someone still screwed up.
- eli 17y ago
  Agreed. Sidekick users aren't blaming SANs because, well, they don't care about SANs. After all, isn't the whole point of this system that you're paying someone else to figure out how to store and back up your data?

21 points by rizzn 17y ago

jf781 17y ago

this industry is embronic and more innovation will occur. I love the cloud market very compelling and important for entrepreneurs and big businesses. We will all be renting computing and storage in the short future.

jf781 17y ago
how can i tell who knocked my comment down to -2

gfodor 17y ago

The fact that this whole thing is being considered a "cloud" failure is ridiculous. The word has become so meaningless that if I ran over a neighbors dog I could probably blame it on cloud computing.

simonw 17y ago

I know virtually nothing about SANs, other than that they are frighteningly expensive. Can anyone clarify how they compare to systems such as GFS, HDFS, MogileFS and other systems that attempt to store data in a safe, redundant manner across lots of cheap servers?

wattersjames 17y ago
Cloud storage systems like S3 are often inferior in raw latency/response performance to a SAN which has VERY expensive adaptor silicon in it--but they are far superior on built in automatic, systematic, redundancy and global fail over and dispersal.
stingraycharles 17y ago
I'm not familiar with MogileFS, so if my comments below are incorrect when applied to MogileFS, then I'm sorry. GFS/HDFS are officially called filesystems, but they're about as much as a filesystem as a Samba server: they expose files to the outside world, with some extra layers of abstraction you can mount the filesystems under Linux, but in essence they live on top of existing filesystems themselves and have nothing in common with the traditional filesystems, where you operate on a block device. A SAN, otoh, is such a block device and traditional filesystems operate on them. This means that you can run a RDBMS on a SAN, while you can't on GFS/HDFS. This covers a common use case where you have a central expensive database server, with dozens of terrabytes of storage in a SAN, which you see in a lot of large corporations.
tptacek 17y ago
SANs aren't filesystems. They're block devices that run over the network instead of over a SCSI cable. They connect to servers by special HBA cards which look like SCSI devices, but actually run the SCSI protocol over the network to a rack full of disks. In a SAN configuration, the admins of those disks carve out a volume of storage for you, give it a name, and you configure it on your server; now it looks like you have a couple terabytes of storage directly connected. You format it like any other disk. Backup works like any other system; you do it app layer. In high-volume high-sensitivity apps, the people running the disk server also back it up, by running protocols that mirror block-level changes to a second rack full of disks somewhere in Tennessee. (yes, yes, or IDE or FC, yes yes, or software initiator, etc etc).

joe_the_user 17y ago

Uh, Sorry but "cloud" or not, SAN or not, the MS/Danger fail was a stunning failure of process. Who cares what the underlying technology was or how it failed? What matters is that a multi-billion dollar software company actually managed to loose, permanently, their customers' data through obvious carelessness, through either lack of a backup in some fashion or other (and don't even try to argue they could have had an excuse - "multi-billion dollar company" "reputation" backups might be sort-of hard maybe - perhaps - but MS is supposed know what it's doing). Lightning and Asteroids wouldn't strike five different carefully chosen locations... My guess is that this will hit MS really hard over time. Even if they actually were hoping Danger would dry-up and blow away, they've now done the worst case scenario to customers. Repeat after me "never let MS near your data...".

rbanffy 17y ago
"MS is supposed know what it's doing" I was in complete agreement with you up to this point. Microsoft's strengths have long ago shifted towards marketing. They once had a edge in technology - over Lotus, over Borland, over Novell, over IBM and even over Apple (in the OS7~9 days). Sadly, after their market share - and dominance of the OEM channels - exceeded a certain tipping point, they had really no need to excel in technology. From that point on, what differentiated Microsoft was a careful management of the expectations of their core market (VARs, OEMs and CTOs). At Microsoft, technical competency has taken a back-seat since the early 90s. This entire mess up smells like "Management by numbers". When a manager cuts costs without considering the implications to data-safety, this is what we get in the end. Seriously: how much data needed to be backed up? 50 terabytes? 500 terabytes? And why the hell the data resides in a SAN and not distributed and replicated in a bunch of front-end servers? The SAN should be the back-up. I love the idea of having all my data on the cloud - It's a major nuisance to switch cellphones and port data from one to the next - and having the data on the cloud could make it easy to access it through a nice web interface not unlike Google's GMail, Calendar, Picasa or Documents. Implementing "back-up your data" and "restore your data" links somewhere would also be quite easy. And yes. Never let MS near your data.
brown9-2 17y ago
This is correct. It's a people problem, not a technology problem.

rit 17y ago

Can we just point out that it was clearly a #BackupFail ? No matter WHAT the deployment mode was, the lack of backups is what has turned this into an issue, NOT the SAN or "Cloud" failure.

jsz0 17y ago

When it comes to important data users should mistrust everyone and everything. It is more difficult to backup data from most cloud sources. There's no easy way to backup my entire Flickr account, Facebook profile, or Google account for example. To backup Gmail I have to rely on desktop applications via IMAP. Is this really acceptable? Why don't we have more sites offering easy offline backups? No matter how you look at it the user has to be responsible for their own data. If cloud services are not making this easy to do then we have a legitimate problem.

generalk 17y ago

Why can't it be both? As far as I can tell, "cloud" generally means someone else stores my data and the only way I can get to it is via the Net. In that case it's absolutely a failure of the "cloud". And if the data was stored on a SAN, it's a SAN failure. If someone didn't do backups at all, it's a backup failure. What's with all the labeling? Look, if I pay someone else to manage my data, and they screw it up and I suffer data loss, it doesn't really matter what piece of gear or level of process is responsible -- someone still screwed up.

eli 17y ago
Agreed. Sidekick users aren't blaming SANs because, well, they don't care about SANs. After all, isn't the whole point of this system that you're paying someone else to figure out how to store and back up your data?