MOVING TO THE CLOUD
The .APP structure enables you to configure and deploy apps to SharePoint while also building, packaging, and referencing libraries that are deployed to the cloud. Although the new app model is very “cloud-centric,” you’re not always forced to deploy code into the cloud. Alternatively, you could deploy your cloud data to an on-premises IIS server. In this deployment scenario, the code does not live on the SharePoint server, but you’re still using the cloud-app model to deploy it to IIS. In this non-cloud application, you’re using IIS — which could be an entirely on-premises installed and deployed app (which might be the case if you’ve installed the full SharePoint Server version on-premises). In the cloud app, the Windows Azure domain is off-premises (for example, in the public cloud data centers that Microsoft manages). However, both types of apps have two components: the configuration file (.APP), and the assemblies that execute your code, which are deployed into a separate server domain. Thus, you’re either running these new SharePoint Apps in your or your customer’s premises or the Internet.
The point is that the method for deploying a cloud app in each architecture is similar; the difference lies in where each app is hosted. Figure 2-4 illustrates two potential application architectures, reflecting on code that is deployed to Windows Azure or code that is deployed to IIS. In the non-cloud application, you’re using IIS — which could be an entirely on-premises installed and deployed app (which might be the case if you’ve installed the full SharePoint Server version on-premises). In the cloud app, the Windows Azure domain is off-premises (for example, in the public cloud data centers that Microsoft manages). However, both types of apps have two components: the configuration file (.APP), and the assemblies that execute your code, which are deployed into a separate server domain. Thus, you’re either running these new SharePoint Apps in your or your customer’s premises or the Internet.
One of the major shifts away from previous SharePoint App models has been a new design goal to move code off of the server. The term design goal refers to the fact that backward compatibility is still possible with SharePoint 2013, but because of where SharePoint is heading, continuing to use these server-intensive development/deployment models is not recommended. Microsoft will be de-emphasizing a lot of these non-cloud areas moving forward (and in some cases deprecating support; for example, the future deprecation of support for Sandboxed Solutions). Microsoft just can’t stop the support for these across one release though given the amount of apps that were written and are supported by SharePoint.
As you consider the development story for SharePoint 2013, keep the following facts in mind:
- A key future direction is in the cloud, so you should get engaged with this new app model now.
- Microsoft will continue to support some older capabilities in 2013, but not necessarily pervasively talk about them due to a strategy to drive deployment to the cloud.
- Some platform capabilities will be deprecated more quickly at some to-be-determined future date, therefore you should begin to cease use of them today (for example, Sandboxed Solutions).
In short, heed the evolution to the cloud and design apps appropriately. The implication of this evolution towards the cloud is no server-side code. SharePoint 2013 offers new options centered on a growing set of client-side APIs and programmability. This means leveraging HTML, CSS, and JavaScript more. It also means getting used to managing and authenticating cross-domain calls using OAuth and interacting with SharePoint data using an expanded set of REST and OData capabilities.
This chapter specifically discusses the Apps for SharePoint — Chapter 11 discusses Apps for Office in greater detail. The App for SharePoint deployment model has three different flavors, as discussed in the next section.