We've heard stuff like the following over the past few months (...with increasing frequency as we approach the RTM of SharePoint 2010):
"SharePoint will do BLOB remoting OOB with 2010 so there is no need for a StoragePoint-like solution."
"SharePoint 2010 on top of SQL 2008 will do what StoragePoint does."
"BLOB Remoting is or will become commoditized, so there's no need to pay for it."
Some of these are just plain inaccurate. There is no OOB BLOB Remoting capability in SharePoint 2010...I've looked for it, can't find it. There are two provider interfaces, EBS and RBS, that you can plug a solution into, but that's it. The closest you can come to an OOB solution is the RBS FILESTREAM provider. It's a stretch to call this OOB. And not because it's a separate install. And not because it's a pain to implement. It's a stretch to call it OOB because it doesn't do an awful lot...it's at best an entry level solution.
It doesn't provide you with the capability to save much money on storage (...BLOB store needs to be local to SQL), make your BLOB store smaller (...no compression), make your BLOB store more secure (...no encryption), or make your SharePoint implementation faster.
So if you're not going to derive much benefit from implementing it then why would Microsoft create it? The answer is quite simple. It's there for all the folks running WSS 3.0 with the WIDE (Windows Internal Database Engine) option. It's there so these folks can upgrade to SFS (SharePoint Foundation Server) and use SQL Express 2008 and stay within it's per-instance limits. For reference, SQL 2008 R2 Express has a per-instance limit of 10GB...pretty good, but there are plenty of folks out there with WSS 3/WIDE that have a lot more than that. And I'm not trying to suspend reality in order to sell you some unnecessary 3rd party solution. I'd go away quietly (...not normally a trait attributable to me), embarrassed that we built something that didn't need to be built, if that was the case. We happen to see a lot of value in our solution...value that customers have, are, and will continue to pay for.
And you know what, you don't take my word for it because there are plenty of articles and blog posts out there on this topic:
From Jie Li, Technical Product Manager on the SharePoint Team in Redmond: http://blogs.msdn.com/opal/archive/2010/03/24/faq-sharepoint-2010-remote-blob-storage-rbs.aspx or http://blogs.msdn.com/opal/archive/2009/12/07/sharepoint-2010-beta-with-filestream-rbs-provider.aspx
From TechNet: http://technet.microsoft.com/en-us/library/ee663474(office.14).aspx or http://technet.microsoft.com/en-us/library/ee748607(office.14).aspx
I hate the fact that we have to create StoragePoint vs. RBS FILESTREAM Provider position papers or I have to waste time on blog posts like this. Why are solutions so quickly dismissed if there is a real or perceived OOB capability in an upcoming SharePoint release? Why is it assumed that this new capability will magically meet the needs of every SharePoint customer out there? Is SharePoint and the highly energized community that orbits it "one size fits all"? The answer is most definitively NO! And that's a good thing. I'm reasonably confident that most of us wouldn't be doing what we're doing today if it was.
I'd like to suggest a compromise on this point. We'll stay away from the WSS 3.0/WIDE upgrade business if it's not assumed that the RBS FILESTREAM Provider provides the same value across a wide array of industries and customer sizes as StoragePoint does. Seems like a fair (...and obvious) compromise.
As always, please feel free to leave a comment or email me directly at rdoria@metalogix.net if you think I'm wrong or misleading folks. Maybe we could debate the topic at a SharePoint Saturday or other event in the future.
Subscribe