Welcome to part six of our blog series based on my latest PluralSight course: Applied Azure. Previously, we’ve discussed, HIPAA Compliant Apps with Windows Azure Trust Center,  Azure Web Sites, Azure Worker Roles, Identity and Access with Azure Active Directory and Azure Service Bus and MongoDB.

Motivation

Question: “How does an admin protect their SharePoint farm from poorly written custom code?” Answer: “Force custom code to run in the SharePoint sandbox mode.” Not quite! Turns out that running in a sandbox mode (as the name suggests, it is a restricted execution mode within SharePoint) is not very productive because of the performance penalty and very limited capabilities available to code running in it. A better approach is to move the code “outside” of SharePoint and into a “private” execution environment (so that the errant developers can shoot themselves in the foot, but not everyone else).

Of course, poorly written custom code is not the only thing that is likely to make a SharePoint farm unhealthy. There are perfectly valid use cases where a SharePoint customization would need to perform (directly or indirectly) a computationally intensive (e.g. calculations) or IO intensive (e.g. streaming large amount of digital content) operation. Once again it is best to move such demanding piece of logic to an environment outside of SharePoint. In fact, with the SharePoint 2013 release, Microsoft has made it a lot easier to externalize the custom logic. For instance it is now possible to register an event handler (a custom piece of logic executed in response to an event such addition of a document to a library) on a remote machine. Other examples include support for OAuth that allows SharePoint to delegate authentication to an externally hosted piece of code.

Given the title of this blog series, it should come as a no surprise that Microsoft Azure can be that “private” execution environment. You can host the custom code anywhere you like including an on-premises non Windows machine (it makes no difference to SharePoint, of course), but here are some advantages in going with Microsoft Azure as the “private” execution environment for SharePoint customizations:

  1. Microsoft Azure offers high-availability, fault tolerance and elastic scale – all at a public cloud, pay-as-you-go pricing model. This means that developers can focus on SharePoint customization rather than the underlying plumbing.
  2. In addition to providing the low level plumbing, Microsoft Azure platform offers a number of higher level services that can come in handy when building SharePoint customizations, especially the SharePoint apps. Examples include Azure Web Sites and SQL Azure Databases. Furthermore, as part of auto-hosted model (available on O365 Only) these aforementioned services are provisioned for you on Microsoft Azure seamlessly.
  3. Microsoft Azure offers specialized services such as HPC Services for Excel that are much better suited for computations as it can offload it to HPC cluster. Another example of a specialized service (and the scenario described later in this blog post) is Windows Azure Media Services (WAMS). Windows Azure Media Services is a PaaS capability within Microsoft Azure that supports workflows for creation, management and distribution of media. This is why it makes sense to move large media outside of SharePoint.
  4. Microsoft Azure hosted code can take advantage of authentication and authorization service such as ACS to securely access SharePoint based resources .

Scenario

Now that we have made a case for moving SharePoint customizations out of SharePoint and into Windows Azure, let us look at a concrete example. This scenario deals with a SharePoint app that is designed to leverage Windows Azure Media Services (WAMS) for host, encoding and delivery of media (If you are interested, the app being described here is available in the SharePoint app store for free). This app making the videos directly available to users within the context of SharePoint, even though the WAMS is ultimately responsible for the origination of the videos. The benefits of such an arrangement (not just for the health of the SharePoint farm but also in terms of the elasticity, availability and CDN offered by WAMS) are obvious.

Core Concept

The Media Center App is a SharePoint hosted app, which means that all the customization code resides within the browser on the client side. As a result the only languages available to the SharePoint hosted app are JavaScript (with SharePoint 2013 JavaScript Object Model) and HTML. Just to be clear, we are talking about the custom code that needs to be in JavaScript. SharePoint hosted can avail of any out-of-the-box server side SharePoint capabilities such as lists, libraries, content types.

The following diagram depicts the high level architecture of the Media Center app. When the app is provisioned from Office.com, an app web (think of it as a web site) is provisioned. This contains the HTML pages, JavaScript files and OOB SharePoint digital asset library. Once the app has been installed, you need to point it to the appropriate WAMS subscription by providing the connection information. Based on this connection information, the media center app can download the video’s metadata from WAMS into the digital asset library. Now with the digital asset library populated with the video metadata, users can list, sort, search and videos like they would with any SharePoint list. Of course, when they play a video it will be streamed from WAMS directly (without burdening SharePoint in any way).

Design Considerations

Here are some design considerations when offloading SharePoint customizations to Microsoft Azure:

  • Determine how the customization hosted outside of SharePoint will be secured. In other words, how will the customization securely act on behalf of the user? Note that in previous versions of SharePoint all actions were being performed under the user’s security context. So the only permission that mattered was the permission accorded to the user. If you decide to host the customization on-premises (as opposed to in Azure) then you will need to setup what is known as a high-trust connection between the SharePoint and the server where the code is hosted. As stated earlier, any customization stored in Azure can benefit from a Microsoft Azure called Access Control Service (ACS). This means that you can take advantage of Wbe Authorization protocols (OAuth) to delegate permissions to custom code located outside of SharePoint.
  • Determine how you will map the SharePoint security granularity (built-in SharePoint permissions) with an external service such as WAMS. In the media center app that we discussed earlier, once the user has authenticated with SharePoint, they have access to all the videos that associated with the WAMS subscription. In other words, there is no way to granularly secure the access to videos based SharePoint permissions.
  • Determine if the SharePoint search should include the externally hosted content. By default, scope of search for an app does not include externally hosted content.
  • Since the code is hosted outside of SharePoint you will need to plan for cross origin resource sharing (CORS). Fortunately SharePoint provides proxy to broker cross origin calls.

Summary

Hosting customizations outside of SharePoint is recommended as it can lead to a SharePoint farm that is easier to manage and upgrade. Microsoft Azure can serve as a “private” hosting environment for SharePoint customizations. It offers a number benefits that can allow developers to focus on “business aspects” of the customization and offload the underlying plumbing to Windows Azure.