Follow storagepoint on Twitter
SharePoint 2010 BLOB Storage Myths

SharePoint 2010 BLOB Storage Myths

by JerseyBob 7. February 2010 08:17

As I'm sure everyone can imagine we get asked a lot of questions about our offering on a daily basis across a wide range of topics.  As we get closer to the launch of SharePoint 2010, those questions have started to revolve more and more around myths, misconceptions, and misstatements on what 2010 offers OOB.  The phenomenon happens every release cycle for SharePoint, given its large customer and partner ecosystems. 

Before we talk about the present, let's take a look back at 2007..."Those who cannot remember the past are condemned to repeat it", George Santayana 1905.

In 2007, one of the primary functional areas of SharePoint that experienced this phenomenon was workflow.  It was OOB, you don't need solutions like K2, it's more than workflow it's true BPM, what you couldn't do OOB could be easily built with WF, and the list of falsehoods and fantasies went on.  Customers were led astray...they wasted a lot of time, money, and energy trying to roll their own solutions, with and without the help of Microsoft partners.  We also saw customers WAIT...they had real business challenges that could have been addressed with workflow/BPM, but they passed on addressing those challenges, in some case more than a year, thinking their problems would be fixed with the SharePoint 2007.  While I'm sure there were folks out there whose needs were met with the OOB capabilities 2007 delivered, a majority of folks were left with some combination of burnt fingers, frustration, and in some cases anger that still persists to this day.

Back to the the present.  While there are several functional/architectural areas of SharePoint that are experiencing this phenomenon, we're going to talk about the one that hits close to home for us here at BlueThread...Remote BLOB Storage.  I'll start by saying that I am surprised by the number of folks out there that don't even know this is an option.  I see blog posts or threads in forums where people describe painfully unnecessary processes for splitting larger content databases down into smaller, more manageable ones.  I feel bad for these folks because they are not at all being advised well by partners, and in some cases Microsoft themselves.  For the ones that do know about this option, let's try to separate fact from fiction:

  • SharePoint EBS is deprecated in SharePoint 2010, so you should avoid SharePoint 2007 solutions and just wait for 2010.

Partially True: While EBS is deprecated in SharePoint 2010, that does not mean it is not supported.  As long as you are using a solution that will migrate from EBS to RBS at some point before it becomes unsupported then there is no reason to wait for 2010.  The reality is everybody is not going to immediately upgrade to 2010...money and/or business priority reasons will force many companies to wait.  But they don't have to wait to rid themselves of BLOBs...and the near-immediate ROI makes it a no-brainer.  For everyone's reference, our solution has a EBS to RBS upgrade built into the product...you can actually have active EBS and RBS storage profiles in place at the same time.  To convert an EBS profile to RBS you just create an RBS profile within the same scope of an EBS profile and run our Externalize job...it will "shallow copy" the BLOB references from EBS to RBS.  The conversion is that simple.

 

  • You can't upgrade a SharePoint 2007 (WSS or MOSS) farm to 2010 with the content externalized from SQL.

100% False: There is no truth to this assertion at all.  In fact it works a whole lot better....read more here.

 

  • You don't need a StoragePoint-like solution with 2010, it will do this OOB.

False: I could give that a partially true, but then I'd be giving credibility to the notion that the RBS FILESTREAM Provider is a viable solution for most enterprises.  I firmly believe that it's not and not because I want you to suspend reality and buy our stuff no matter what.  I believe that it's not viable because it was not designed, architected or built to address the needs that StoragePoint addresses.  It was built to provide a free upgrade path for companies that implemented WSS 3.0 using the WIDE (Windows Internal Database Engine) option.  There is no WIDE option for SharePoint Foundation Server, so the only free upgrade is SQL Express which has a 4GB database size limit.  The RBS FILESTREAM Provider was built to give these customers a way to remote the BLOBs as they upgraded.  Might not work for all of them, but it will work for most.

If you don't fit into the definition above (...WSS3/WIDE upgrade to 2010) then what's the benefit of this option?  It's doesn't perform better than leaving the BLOBs in the database.  You can't tier storage, or compress BLOBs, or encrypt them.  And oh BTW, Microsoft isn't recommending this option for you.  They've made the caveats pretty clear in presentations and blog posts that I've seen.

 

  • I can build my own RBS solution.

True, but Not Recommended: Any reasonably talented .NET developer can build an RBS provider, either given the interface specification or some sample code.  So the question in my mind has always been why would you want to build your own RBS solution?  It's not completely trivial to build one and maintaining it over time as SharePoint and SQL hot fixes, cumulative updates, and service packs are delivered puts a significant burdon on an IT shop.  There is also a big difference in just building a provider and building a complete solution (admin tools, reporting and monitoring, compression, encryption, storage platform support, etc.) ruggedized enough to implement in a production environment.  You also don't benefit from the new innovations funded by a vendor's R&D dollars and the maintenance dollars of a large customer ecosystem.  In the end, this is not some web part or report or other component that doesn't bring your entire farm down if it breaks...if this thing breaks your entire SharePoint farm will be impacted in a very big way.  Look at it this way, every byte of every document that is uploaded into or retrieved from SharePoint will flow thru your provider. 

 

There are others, but these are the main ones that I wanted to talk about today.  So in summary, EBS is supported today and in 2010 (...DEPRECATED <> UNSUPPORTED), you can upgrade to 2010 with content externalized via EBS, StoragePoint provides an in-place upgrade between EBS and RBS, it's a stretch to suggest that there is an OOB RBS capability in SharePoint 2010, and while you can build your own RBS solution it should be done with a lot of care and consideration...recognizing that the RBS provider itself is not a complete solution.

Feel free to leave comments if you disagree.  Agreeable comments are welcome too.

Tags: , , , , ,

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading



Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen

Calendar

<<  March 2010  >>
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar