My colleague, Matthew Riedel, recently published a blog that outlined some of the most important architectural features of the new SharePoint workflow engine. The purpose of this blog is to expand on the concept of hosting SharePoint components outside of traditional farm boundaries. In SharePoint 2010 and previous versions, a SharePoint farm was typically viewed as a logical collection of servers with SharePoint installed on them, backed by SQL content databases. Administrators turned SharePoint Services on or off to create Web front-ends or application servers. Any custom modifications were deployed directly to these servers. This made SharePoint feel like a product with modifications, rather than a development platform.
The SharePoint 2013 App Model has finally made SharePoint a true platform. Provider-hosted SharePoint Apps provide the foundation for a SharePoint “ecosystem.” For the first time, developers from outside your organization can develop arbitrarily complex applications that can deeply integrate with your SharePoint data without being deeply integrated with your SharePoint farm’s infrastructure. In many ways, SharePoint Apps work like an app on a smart phone. When installed, they ask permission to access required resources and are contained within their own logical unit. If you decide to remove the app from your SharePoint installation, it can be discarded cleanly. Another benefit to the loosely coupled nature of the SharePoint App Model is that it allows developers (internal or external to your organization) to host the apps outside of the SharePoint farm. The most obvious location for these apps to live is in Windows Azure. This allows you to build or consume SharePoint Services that elastically scale without changing on-premise infrastructure.
Increase business process efficiency and collaboration with Microsoft SharePoint
Explore Our Microsoft Consulting Services →
How does this make SharePoint a platform? Externally-hosted apps that live in Windows Azure can be arbitrarily complex and use resources that otherwise are unavailable to SharePoint. For example, I recently worked on a Cloud-native solution that leveraged Windows Azure to gather a large amount of advertising data from a variety of data sources. Roughly 25 Azure worker roles communicated over Azure Service Bus to gather and process data. A SharePoint 2013 App could be developed to allow the process to be controlled by reading items from a SharePoint list and submitting them as task messages on Azure Service Bus. The beauty of that type of set up is that the entire data collection process is externally hosted. The only integration point between SharePoint and the Azure process is the app asking SharePoint for some list data.
The SharePoint 2013 App Model and the ability to externally host apps can provide your organization opportunities to fully leverage SharePoint as a development platform. Your organization can use SharePoint precisely for the out-of-the-box functionality it provides. Custom Apps are created when SharePoint functionality alone cannot solve your business problem. The new App Model allows external applications to “reach in” and make use of your SharePoint content using a variety of technologies that were out of the realm of possibility before SharePoint 2013.
If you are interested in learning how Credera can add value to your business through the use of SharePoint 2013 Apps, please contact Credera at firstname.lastname@example.org or send a tweet to @CrederaMSFT. Check our Denis Stetsenko’s blog, SharePoint 2013 Development: Solutions vs. Apps, for more great information on SharePoint 2013 Apps.