There are two different versions of SharePoint Online: Standard and Dedicated. Table 14-1 provides an easy way to compare the different ways you can deploy SharePoint. This table compares SharePoint On-Premises, SharePoint Online Standard and SharePoint Online Dedicated.

One of the major differences, as you can see in the table, is that SharePoint Online Standard does not support the full range of customizations like the other two deployments of SharePoint. Going even deeper, if you look at what constitutes a farm solution as opposed to a non-farm solution, the clarity of what will and won't work gets better. Table 14-2 shows examples of no-code solutions versus farm solutions.

One other major difference between online and on-premises is that not all of the feature set of SharePoint is supported in the cloud. In particular, SharePoint Online does not support PerformancePoint or FAST in the cloud. Additionally, when dealing with search technologies, architecture and deployment become more critical when deploying in the cloud. For example, if you had a hybrid environment where you wanted to have one search index across both on-premises content and cloud content, where do you place your indexer — on-premises or online? The answer is that it depends, but either place that you decide to place it, you will be dealing with crawling across WANs. A solution may be to create two separate search deployments and use federated search. However, doing so results in the loss of the ability to have a single result set with integrated relevancy.

As you can see by the summary above, some of the ways you are used to developing on-premises will not translate to the multi-tenant cloud. Using server-side code is a no-no when it comes to building applications where you are running SharePoint with other tenants on the server. When developing for online use, there are a number of different choices you have for development. You can use Sandbox Solutions, SPD, InfoPath, Access, or the SharePoint client object model in ASP.NET or Silverlight applications. Since many of these technologies have been covered already in this book, they will not be covered here again.

Instead, this chapter focuses on some of the best practices to use when developing in the cloud. These best practices can be used on-premises as well as on the cloud, but given the limitations of the cloud, you have more options on-premises.

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;

namespace SharePointOnlineLogging.WebPart1
{
    [ToolboxItemAttribute(false)]
    public class WebPart1 : WebPart
    {

        private Button logResultsButton = new Button() { Text = "Log Results" };
        private Label lbl = new Label();

        public WebPart1()
        {
        }

        protected override void CreateChildControls()
        {
            logResultsButton.Click += (object sender, EventArgs e) =>
            {

                SPContext context = SPContext.Current;

                SPWeb web = context.Web;

                SPList list = web.GetList("/Lists/
                 SharePointOnlineLogging-ListInstance1");

                string logResults = DateTime.Now.ToShortDateString() + " " +
                 DateTime.Now.ToShortTimeString()
                  + ": Logged from Sandbox Web Part!";

                SPListItem newItem = list.AddItem();


                newItem["Title"] = "New Log Result - " +
                DateTime.Now.ToShortTimeString();
                newItem["LoggingResult"] = logResults;

                newItem.Update();


                lbl.Text = "Logged Result: " + logResults;
            };

Controls.Add(logResultsButton);

            Controls.Add(lbl);

            //base.CreateChildControls();
        }

        protected override void RenderContents(HtmlTextWriter writer)
        {
            base.RenderContents(writer);
        }
    }
}

To help understand areas where using SharePoint in the cloud makes sense, the following scenarios describe where you can use the cloud and where you can't. As you will find, for out-of-the-box functionality, SharePoint Online is a very viable solution. The areas to watch out for include custom code and unsupported features in the cloud, or features that require administrative access to the server.

The first scenario is your typical team collaboration, wherein you are creating a team site, sharing documents, and performing simple customization of the site. Because this case does not require high-end development or administrative access, this scenario would be supported easily in the cloud. The only gotchas are to make sure that users who use Office on their desktop understand how to authenticate against SharePoint Online and how to determine the address for their sites, since they will be fully qualified domain names rather than Intranet style short names.

The next scenario is a company portal. This is where it gets more complex, because many portals require rich customization and publishing infrastructure. This is one scenario where you will have to evaluate your needs versus what SharePoint Online provides from a development standpoint. If you find that your existing portal makes use of a lot of custom code (such as custom field controls or complex worklows), you may not want to run your solution in SharePoint Online or rewrite these solutions to use Sandbox Solutions, which are supported in the Online environment.

SharePoint Online will have an offering for building Extranets since the security for Extranets is different than Intranet sites. Plus, sharing and invitations with external parties makes it easy for end users to invite their business partners from other companies. While this offer isn't complete at the time of the writing of this book, Extranets, depending on what the offer finally ships, may be the first scenario that you undertake with SharePoint Online as a complement to your on-premises deployment of SharePoint. You may get a quick win by making it easy to share information with your business partners without having to worry about access to your internal corporate networks. You will want to make sure that the Online service-level agreements for availability and recovery meet your corporate standards and that the security in place for SharePoint Online meets your security guidelines for your company.

The last scenario is Internet-facing sites. SharePoint Online will have an offer for anonymous Internet facing sites with SharePoint Online 2010; you will want to evaluate this offer for medium-sized websites. If you are running a large scale website that requires a lot of customizations, the Online offer will not meet your needs. You will want to run your Internet site on-premises until Online allows for complex customizations and support for technologies such as content deployment.

In this chapter, you learned about the different versions of SharePoint Online. Also, you saw what is supported in an on-premises deployment, as opposed to an online deployment. With the 2010 release of SharePoint Online, there is better symmetry between the on-premises and online versions of SharePoint, but to a developer there are a significant number of differences. You will have to keep that in mind as you develop your code to make it portable from an on-premises solution to a SharePoint Online solution.