Every major release of SharePoint has introduced a new development paradigm for developers to extend out of the box SharePoint features with custom solutions. The biggest breakthrough, in my humble opinion, came with the introduction of Web Parts in SharePoint 2003. The concept of dynamically associating UI widgets with individual user experience was certainly something lacking in typical web based offerings. Features based development and Solution based deployment was probably the best architectural initiatives in SharePoint 2007. By 2010 cloud adoption was on the rise and the framework had to be extended to support cloud based deployments. The introduction of sandbox solutions was aimed at supporting cloud based deployments but because of a fairly complicated development model, it could not gain enough acceptance in development community. Microsoft quickly realized that a new development platform is required to support the emerging cloud market for SharePoint 2013. Enter the new App Development Model.
1: Choosing a Hosting Architecture
The first challenge is understanding the hosting architecture of Apps. The hosting architecture directly affects the development, deployment and maintenance model for your SharePoint customizations. The App hosting architecture is significantly different from how Solution based deployment works. The basic reason for this change is that the App model targets Cloud as a first class citizen while Solution based deployment is not possible for Public clouds.
There are two deployment models for Apps. Microsoft provides a detailed overview of this under http://msdn.microsoft.com/en-us/library/office/fp179887.aspx
SharePoint Hosted: Apps are deployed in an App Web which is a separate app domain within the current SharePoint web site. I would strongly suggest to go through the following links for a details understanding of the implications of this deployment model
Provider Hosted: Apps are hosted outside SharePoint in a different environment. The App as a component is visible in SharePoint but this component is essentially hosted in a different remote web server. For a detailed understanding of this hosting model, I would suggest to go through the following Microsoft link
2: Understanding the Development Options (Tools/Languages)
3: Understanding the Authentication and Authorization
In traditional SharePoint Solution based development, the security context of the current user is used to access SharePoint resources. Access to external resources like DB or BCS uses the security context of the Web Application Pool. For Apps the security context is either the App principal or App + User principal. In case of external Provider Hosted Apps there is this additional overhead of understanding the low trust and high trust authorization models. This is probably the most confusing and extremely loaded topic in understanding App development. The following MSDN link is an absolute must to get a better understanding on this http://msdn.microsoft.com/en-us/library/office/dn790706(v=office.15).aspx
4: Understanding Resource Context & Data Storage options
In a traditional Solution based deployment, the resources specific to your solution are packaged and deployed as part of the web or site collection to which the feature is activated on. So within the context of a custom application, all the resources are considered to be local unless the application tries to access something from a different site collection or a different farm. The new App model effectively changes all that. Even with SharePoint hosted deployments the resources an App Web has to access are considered external and the App requires an explicit permission from the Host Web owner to access the resources.
SharePoint hosted apps usually store data in lists and libraries within the App Web. This is true of both SharePoint On-Premise and SharePoint Online. However, for Provider Hosted Apps the options for data storage are essentially limitless. The remote nature of App hosting removes all possible restrictions from the data storage mechanism. This also means that SharePoint can be easily extended to provide complex relational data models which are otherwise very complex and often not recommended inside SharePoint. The limited ability to reflect the natural relationships of entities within SharePoint has been a major pain point in successfully designing SharePoint based customizations. The following MSDN link provides a useful insight http://msdn.microsoft.com/en-us/library/office/fp179900(v=office.15).aspx
5: Understanding Backup/Restore challenges
Successful Backup/Restore has always been a challenge when it comes to customizations in SharePoint. Since Apps are kept separate from SharePoint, their backup and restore paths are different as well. OOTB options in SharePoint 2013 provide a fairly decent option for backup and restore of SharePoint Hosted Apps. . http://technet.microsoft.com/en-us/library/jj871017(v=office.15).aspx provides a fairly decent overview.
Things are a little tricky in case of Provider Hosted Apps since most of the data is hosted remotely. Your backup strategy will also depend on how and where you have maintained the context of the App. Ideally, the remote DB will contain all the data and context necessary for app execution and this will essentially make your App as a plug and play feature. However, if the design of your App requires some context to be maintained within SharePoint as well then an additional overhead of maintaining the same context on a restored site is also required.
6: Understanding Upgrade/Migration challenges
Upgrade & Migration of SharePoint Hosted Apps is fairly straight forward. You can take your On-Premise SharePoint Hosted App and port it over to SharePoint Online (Office 365) and vice versa. The upgrade or migration of SharePoint does not really impact your Provider Hosted App. This is considered a big plus and provides the much needed flexibility required for majority of Production scenarios.
This small write-up was an effort to briefly summarize some of the major design and architecture related challenges associated with App development. There is a lot more into it then the above simplification. In my humble opinion, developers should continue to focus on developing Farm Solutions for On-Premise applications. For applications targeting both Cloud and On-Premise environments, the App framework is obviously the only choice.