Developer EventsWindows Azure Developer Stories
General ResourcesWindows PhoneWindows Azure
These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
While I could probably turn this into a love story using people to metaphorically represent technologies, I’ll spare you from having to read that. But the story behind SharePoint and Windows Azure is truly one of those “better together" stories. They can each work (and work well) on their own, but when put together, the doors open for developers to extend the features of SharePoint by leveraging the infrastructure that is the Cloud.
Let’s take a look at scenarios that were previously “constraints” and now are opportunities for expansion:
Large Data Sets
You can store and work with data in SharePoint using lists. But the more complex the data becomes, the more inefficient lists become as storage mechanisms and the more difficult it becomes to work with the data – not to mention the larger your content databases become and the more difficult it becomes to maintain their SQL Servers.
With Windows Azure in the mix, you can outsource your data needs to Azure, specifically SQL Azure.
SharePoint document libraries can store files. But just because they can, doesn’t mean they should store all of your files, or every type of file. For example, a document library is not an ideal home for video files that are 500MB+ each. Such files are better suited for a hard drive or a file system (rather than the data, again, being in the content database). Further, the premise of document libraries in SharePoint is to share and as a result, the more users there are using SharePoint, the more they are sharing, and subsequently, the more files accumulate.
The more files that accumulate the more room they take up. Whether it is because of an accumulation of files or because files are large, you’ll find you encounter a need to be able to store data on an infrastructure that can keep up with your growing data needs and shrink when files are removed. This need is easily serviced by Windows Azure’s Storage Services, specifically blob storage. Rather than using SharePoint to store files, Blob Storage can do the job, expanding and shrinking as your demand requires. As an added bonus (and piece of mind), Blob Storage is also ensuring that your files are stored secured and are replicated to another datacentre in the unlikely event of a datacentre disaster.
Similarly, and this is especially true for companies that are dispersed around the world and don’t have SharePoint implementations in each geographic area (close to users). The closer the file is to the user, the faster the user can reach and consume it, and therefore, better performance for the user. You can imagine that with all of the files that end up being shared on SharePoint, this would become quite crucial to users. Enabling the Content Deliver Network allows Windows Azure to cache files in nodes (servers) located around the world, closest to the locations from which users are requesting them, reducing the distance files travel in order to get to the users, and therefore increasing the performance of your SharePoint infrastructure.
Chances are your SharePoint environment is locked down pretty well in order for your IT folks to keep the environment highly performant, scalable, and secure. But being locked down can also limit the type of solutions you can build for SharePoint. Let’s say you wanted to build a solution that uses SharePoint as a front end, but then takes the actions and data from the user and goes off to do something else, or perhaps feed the information into different systems. That code needs to run somewhere. A natural inclination would be to have SharePoint run the code within a solution. However, if you’re environment is locked down, and let’s say you’re only able to deploy Sandboxed solutions (or in the case of SharePoint Online, Sandbox solutions are the only type of customization that is permitted), you’ll be constrained as to what you will be able to do.
Working with Windows Azure as a backend system also allows you to work with the restrictions (not around) imposed by sandboxed environments. To do so, you outsource the “work”, your code that does stuff, to a web or worker role in Windows Azure, have those instances run the code for you, and then expose the result via web services that can then be read back into SharePoint or SharePoint Online.
Keep in mind that this can be two-way. By using SharePoint or SharePoint Online’s web services or client-side object model, you can reach into SharePoint to return or save data.
Integrating with SharePoint Online
There’s also a great story of SharePoint Online and Windows Azure working together to enable working with internal systems and/or protecting sensitive data that you don’t feel comfortable storing in SharePoint Online (but do feel comfortable having it in your own data centers). A hybrid solution is in order here. Have SharePoint Online as your front end. It will then talk to a Windows Azure service that will then communicate with your internal systems (via Windows Azure Connect or Windows Azure Service Bus) and securely transfer the result/information back to SharePoint Online.
The Love Story
As you can see there’s a natural fit between the two technologies to fill in gaps and make solutions possible – a ying/yang, a …. whatever other metaphor you want to use. These, and I’m sure other scenarios not discussed here, are the reasons why SharePoint says to Windows Azure “You complete me.”
I’ve just touched the tip of the iceberg on the relationship between SharePoint and Windows Azure. For a more in-depth look, check out:
Disclaimer: The above architectural solutions are just an example of a multitude of different architectural solutions for the same technical challenges. Before implementing, you’ll need to ensure that the architectural solution you choose is right for your needs and IT environment.