RSS
Email
Print
ShareThe Cloud As An Extension
Posted by George Crump on August 6, 2009
In my recent series of entries for Byte and Switch, I attempted to categorize cloud storage. Various companies are delivering sub-sections of cloud storage that when stacked together form the solution. There are cloud storage developers that deliver to the customer facing applications, cloud providers that provide the facilities and cloud manufacturers that deliver the physical equipment which the providers would use. Some cloud storage companies that are providing all three of these categories from a single company. As the industry evolves, most companies will likely specialize in one aspect or another.
Each of these categories have sub-categories. For example, in the cloud manufacturers' category, you have three sub-categories: hardware only, software only and turnkey hardware with software. Each has its own pros and cons. A sub-category I missed was in the cloud storage developer category.
There are at least two types of cloud storage developers. There are companies that write the entire application and leverage the cloud as the back end to their software; backup, collaboration and archive are good examples. These can come with or without an appliance to do local caching, as I discussed in a recent entry at Information Week.
There is another type of developer: those that are using the cloud as an extension of what they already do. These are typically pre-cloud companies that are taking their existing solutions and extending it into the cloud. Examples are backup and archive software companies like Symantec and Atempo that use the cloud as a secondary repository for either backup or archive data.
Another example is the collaboration between LiveOffice and Mimosa that allows local presence email archiving users to push that archive to the cloud under given conditions. Taking what should be two apparent competitors (local email archive vs. cloud email archive) and having them work together offers their customers the best of both worlds. Along these same lines Tarmin's GridBank has partnered with Nirvanix to leverage the Nirvanix API set. They can now replicate data from a local data storage repository to storage in the cloud as opposed to another GridBank, once again transforming competitors into partners.
The value of cloud as an extension is that it allows larger organizations to begin to dip their toes in the waters of the cloud without having to do a complete change out. By leveraging API sets, existing on-premise suppliers of storage and storage software can enable customers to move or replicate data off-site, and in some cases, eliminate the cost of redundant systems by using the cloud instead. Essentially, the cloud is merely an extension of an existing, trusted process as opposed to something entirely new.
The challenge is that we have competing API sets from the different cloud vendors and so software suppliers are either going to need to support all of them or some standard will have to evolve. We look at some of the potentials for cloud API standardization in an upcoming entry.
Comment by Dan Roland on August 6, 2009 11:27 PM
An extensive cloud is how organizations will think about storage in the future (not too distant IMHO). The topology and technologies used will be as ubiquitous as routers, switches and browsers communicating with the original cloud, the Internet. That nebulous blob us networking types place on diagrams to depict an entity without any regard for what's in it. I'm convinced storage will get there soon. Where it's of no concern whether the end user is storing/accessing files in the same building, across campus or across the world. And, there will be a seamless, automated and intelligent capability to replicate content where it needs to be based on customizable business rules. It seems so simple and yet it's been extremely complex and challenging to make this work with existing technologies across a small distributed organization like mine, 4 offices regionally located in the US. These tough times have required us to reevaluate our infrastructure and look for a new, simpler way to deal with all the file data generated at each location.
I believe you're right that extending a private cloud to the public cloud is a good way to go. I've been using some object-based storage software from a company called Caringo that allows me to implement a small cluster at each location with a simple file share for users to store files. I've then used another of their software components to write rules for replicating content from each office to our main office for archiving and from there to a DR facility. It can all be automated with low admin overhead (good for us). Side benefit I didn't realize when I started is that it has compliance features, which a portion of my user files have to be retained for 7 years. The remote cluster would be implemented with a hosting provider (public side for us). We're testing at this point and their free software for storage clustering and Windows folder for the desktop/server has made this a low cost effort and that makes my bosses happy.
Thanks for such a good blog post. This helps validate my thinking about cloud storage. Keep the information flowing.
Dan
Network Geek
Reply to this comment
Comment by Mike Young on August 7, 2009 2:20 PM
George,
I think you also have to bear in mind there are different ways of interacting with storage. We have for years interacted at a file or block level. And in recent years we've acted at an app layer via various types of web services. Just because we're talking about storage on the web doesn't mean that everything is going to go the direction of a web service. There's too much legacy stuff that still needs to work. And new apps are still dependent on the former types of storage too. So it's not going away anytime soon. The only reason I bring this up is that driving towards a common API really works well for one of the three methods.
Then there's security. Security is going to be one of the biggest reasons for complete vertical integrations. Without it, it's going to be like the defining stages of web services where the protocols lacked security and 3rd party brokers were required. With the recent news of BOF exploits, I think people should be cautious about how things get fenced off. How do you prevent one exploit on one account from affecting other accounts?
Then what do we do for companies with many storage products, many locations, many divisions, etc.? We know how to establish layers in the enterprise with user and group policies and with ACLs. Well, similar things have to be constructed in the Cloud to ensure that data can still be accessed in the event of a departmental or branch failure.
These are just some of the concerns to take into account. Don't get me wrong. I agree with you on pretty much everything you've said. But when it comes to corporate data, the requirements are only going to increase from here. Things like CAPP in the DoD world are going to become the minimum requirements as we move forward. Well, that's my take anyway. If I'm right, then simply extending existing practices won't cut it. I've been in the storage industry since I was 16. And one thing I know, is that today's storage products and technologies are not inherently secure. We count on operating systems and applications for security. As we move to the cloud, the storage is the app. This does constitute a change in paradigms.
Thanks,
Mike Young
CEO, Cachengo
http://cachengo.com/blog
Reply to this comment
Comment by George Crump on August 13, 2009 9:59 PM
Mike, You are scary smart :) I think you have given me three, no four more blog ideas there! Many of the multi-tenancy things are being or have been addressed be certain suppliers. Everything is far from perfect but so is todays' storage as well. One of my team members has a cloud security article coming up that will cover some of the issues you raise. I'll post it here when it is up.
Dan, Sounds like you are way down the road. Take a look at this article "Become the Cloud" and see if this is something you can scale into? I'd be curious to get your feedback: http://bit.ly/2sq74E
Reply to this comment