It is doubtless that both SharePoint and Windows Azure can each 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.
So let’s have a look at the advantages of using these two technologies together and new opportunities for expansion.
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 big video files. Such files are better suited for a hard drive or a file system. 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 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. 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.
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. With Windows Azure in the mix, you can outsource your data needs to Azure, specifically SQL Azure.
From a storage mechanism perspective, using SQL Azure gives you the power of SQL Server with the elasticity needed to keep databases growing with data and prevent performance degradation of your SharePoint cluster. From an ease of use perspective, using SQL Azure also allows you to work with the data as you would with SQL Server, no longer needing complicated code and interactions with SharePoint’s APIs to get at and work with the complex data. Once the data is in SQL Azure, you can connect it to your SharePoint solution either through direct calls to the SQL Azure database, or through a web service hosted in a Windows Azure Web Role connected to SharePoint via BCS.
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, 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 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 and securely transfer the result/information back to SharePoint Online.
When you see the cloud as a place to deploy applications, your reach naturally widens. For example, deploying your services and applications in Windows Azure, they are available to many SharePoint clients. By leveraging the Windows Azure Marketplace DataMarket or deploying your own custom WCF services or ASP.NET applications, you not only are able to better monetize on optimization, but the opportunity to take advantage of your Windows Azure applications and services can be extended to your customers as well. This is a tremendous opportunity for you because it means you can write once, sell many times, and let Windows Azure worry about scale.
The cloud is about reusing your existing skills and your existing code; it’s not all about reinvention and multiple code bases. With .NET, you are able to reuse already-built .NET applications in the cloud, or reuse your existing skills to build new ones. Further, the cloud provides the opportunity for service layers that enable cross-device (e.g. phone, web and PC) connectivity and cross-platform integration.
As you can see there’s a natural fit between the two technologies to fill in gaps and make better solutions possible.
Read more here.