Historically SharePoint has been very popular with large organizations because they can shoulder the financial and resource requirements required to deploy SharePoint. However one place where SharePoint hasn’t grown as fast is in the small and medium side business (SMB) area. The reason for this is most likely the cost and resource requirements (not just hardware, but people as well) necessary to deploy and maintain it. With Office 365, many of these barriers have been removed and therefore it represents a new era and opportunity to grow the SharePoint customer base. Therefore this is an area you should be very aware of and should learn how you can best leverage and exploit this new and untapped market of possible SharePoint customers!
SharePoint 2010 included a new capability that enabled developers to create custom solutions and deploy them to site collections without involving administrators. These sandbox solutions are limited in some things they can do, as they should be considering they allow developers and site collection owners to deploy code directly to the server without the administrator check and balance. Sandbox solutions are the only way developers can create custom solutions and deploy them to a hosted environment. Microsoft does not allow fully trusted (aka: farm trust) solutions in Office 365 as they can’t review every solution nor is it good for the stability of the farm.
As sandbox solutions are the only developer option for custom solutions in Office 365, developers should be aware of what things they can and cannot do in sandbox solutions. The following article on MSDN provide a good set of guidance to understanding what you can and cannot do within the sandbox: SharePoint Online for Office 365 Developer Guide
In addition to the limits imposed by the sandbox, Microsoft has incorporated some additional limits on Office 365. Unfortunately not all of these limitations are documented, but the following article on MSDN does provide good guidance to working in the hosted SharePoint Online environment: Developing SharePoint Online Solutions. In addition to the support Microsoft has provided, the community has developed an open source project on CodePlex that consists of documentation and FxCop rules you can use to check your code before deploying to the sandbox. It includes all the known limitations as well as those limitations found by customers but not yet documented clearly by Microsoft: Office365 Sandbox FxCop Rules.
This message speaks to existing SharePoint developers, but there’s a bigger piece to this story. While SharePoint developers, those who understand how SharePoint works (the concepts of site collections, sites, lists, libraries and Web Parts to name a few things), there is another class of class of developers out there who are asked to build things to integrate with a company’s SharePoint investments: non-SharePoint developers. This speaks to ASP.NET developers or even those who don’t develop on the Microsoft platform! By integrating Windows Azure solutions with SharePoint as I’ll discuss in the next few posts, developers are free to use non-Microsoft technologies in creating custom solutions that integrate with SharePoint, including Office 365. This is because Windows Azure not only supports the .NET Framework, but it also supports Java, php and even the popular node.js. By supporting these additional platforms, companies can leverage even larger pools of talent.