A Reply to Sahil Malik’s Defense of the Sandbox Architecture

Sahil Malik has a response to my SharePoint 2010 Sandbox Solutions are Bad post that you can read here: Sandbox solutions are pretty damn good.
He also links to a Facebook conversation wherein Razi Bin Rai asserts "At heart of the argument of ‘SB solutions are bad’, there is actually more of a resistance against new way of doing things" and Sahil replies "True True Razi".

Not true at all. (I am always amazed when an Internet commenter thinks they know the mind of another from a tweet or a page of text).

There is in fact not a resistance against a new way of doing things. I came to this new technology with a great deal of excitement, but I find it distinctly lacking in its merits.

With regards to Sahil’s post – I believe that proxies are a sound and vital architectural choice. But they are not part of the sandbox even though SharePoint provides the means to invoke a specific type of proxy from the sandbox. In SharePoint they are, in fact, full trust components that require administrative access to install. My guess is that those who have permission to use them will do so if they are using Silverlight or heavy javascript with the new client namespace. Furthermore, they will use some form of server side proxies regardless of whatever deployment (sandbox or farm) choices they make.

And why not? By going with a predominately client side technology you don’t lose anything from the sandbox that you would have without it. Assuming you have admin access you can solve both issues #2 and #3 mentioned in my original post . But let us be completely honest about what this means; you solve them by having components outside the sandbox. Most, I think, would choose this architecture (proxies to server side services) when the UI is client side JavaScript or Silverlight with or without the sandbox. If we both agree that this is a sound architecture in and of itself, let’s not confuse the subject of the merits of the sandbox as it is implemented by talking about something that is clearly separate even though complimentary.

Besides, I don’t think full trust proxies will be an option on SharePoint Online or other hosted offerings anyway.

Sahil seems to be conflating my choice of the word ‘Bad’ with ‘useless’. This is not a useless technology, but it is a bad one. As you may know, I’ve been slowly making Elumenotion into an ISV. I hope to have some success with SharePoint Online and its analogs and so we are working on a variety of workarounds and trying to come up with a serviceable architecture. The fact is: there are workarounds and you can build solutions.

This concession made, let me reiterate what I think was the most important part of the original post. If you are going to do development on 2010 and you have access to the server your default choice should be farm solutions unless you have a compelling requirement to do otherwise – the pronouncements at PDC and elsewhere to the contrary (sandbox should be your default choice) are nonsense. Absent a clear requirement (like the need to run as a hosted solution) going with a sandbox will result is more code with strange workarounds and potentially less secure data for more money and time. If that’s not bad, then what is it?

I must admit that I was a little irked that I took the time to come up with three specific examples that Sahil ignored and substituted with a straw man when he wrote his rebuttal. I think I have addressed the full trust proxy point, but let me tackle a couple of his other points so that he need not be irked with me. ;)

First Sahil says ‘Farm solutions and custom code is the number one necessary evil on SharePoint projects. It is also the number one issue that causes problems and updates. And it is also the number one issue that causes contention between IT Pros and developers.’ To this I can only say ‘[citation needed]‘. It’s a huge assertion to make that does not jibe with my experiences or anecdotes from my peers or clients.

Second is that the sandbox provides a degree of monitoring that can prevent rogue apps from killing the server. I agree that this is a great thing especially if you are providing hosted services like SharePoint Online that preclude normal QA and monitoring processes for deployed code. Once again though, if you have the option of traditional development because you own the servers, traditional QA and WMI instrumentation along with ULS logging are a first line defense which should minimize the need for such a system.

Third Sahil says: ‘My feeling is that there’s been plenty of thought given to where and how those walls have been drawn.‘ My feeling is that insufficient thought and resources went into making these decisions. At some point they have to ship it and they decided where to put the resources. This stuff smacks of a version 1.0, let’s get it out the door deal. I am spending a lot of time in Reflector these days looking at the SharePoint assemblies. If there is a security or performance issue that caused them to deny access to the entire SharePoint.WebControls namespace I do not see it. The code for most of these controls is simple and straightforward. However, there are hundreds of them. My purely speculative guess is that they only had so much manpower to go around and they took the easy way out by blocking them all instead of looking at them individually.

Author: Doug Ware

Atlanta based entrepreneur, author of many SharePoint books and videos, leader of Atlanta .NET user group, founder of InstantQuick, and SharePoint MVP.

4 Comments

  • Peter

    January 11, 2010, 2:06 pm

    I think I see where you’re coming from. Sandbox solutions are a (potentially, on paper) GREAT opportunity for ISVs to create useful products that can be purchased and installed by end-users without IT intervention (or permission). The potential is huge–think “App Store” for SharePoint.

    Unfortunately the restrictions are tight…especially the lack of elevated security permissions. Because sandbox solutions must run in user permissions, this by definition means the user has full access to your solution, and forces security by obscurity to hide the data from the user.

    The lack of security means you can’t attempt to build anything important via sandbox solutions. With pure sandbox solutions (i.e. without farm admin access), we’re left with data rollup, low-security solutions and widgets. Anything else?

  • John W. Powell

    January 21, 2010, 8:38 am

    Sandboxed solutions are good and bad depending on your perspective. When server access is not an option, Sandbox Solutions at least give you some server acess and a minimum, a way to package and deliver your customization. I believe the primary motivation for Sandbox Soutions is SharePoint Online, and for that scenario, it makes alot of sense. Another scenario for Sandbox solutions are customizations that you are distributing to a wide audience–such as developing something on CodePlex or for a vendor. But those scenarios aside, if you have the ability to deploy a farm solution, I don’t see a compelling reason to choose Sandbox. There are alot of little gotchas with Sandbox solutions, some of which may result in having to switch to a farm solution or come up with a less than optimal approach to achieve something that should be simple.

  • johnrock

    March 2, 2010, 4:01 am

    Why full trust proxies will be an option on SharePoint Online or other hosted offerings .
    Tel me the answer of this question please.
    ……………….
    johnrock

  • Ven

    March 11, 2011, 2:08 pm

    Hi,
    I really appreciate your comments and arguments. Unfortunately, it has become a trend for people to show themselves off, through blogs and forums, by giving simple samples, which may have nothing to do in real world and hardly talk about real world scenarios. People like you are very few, who really understands the complexities and issues in real world. You seem to be very practical and correct. Hats-off to you.

Comments are closed