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.

• 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.

Storage

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.

Code Execution

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.”

Deeper Dives

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:

• Bruce Johnson’s TechDays 2011 CLD304 – To the Cloud and Back – Hybrid Applications with Windows Azure and SPO demonstrates implementation techniques of the above solutions.
• SharePoint 2010 and Windows Azure Training Course helps you ramp up on different ways to integrate SharePoint and Windows Azure. The kit contains twelve modules that include PowerPoint decks, hands-on labs and source code that shows how the SharePoint 2010 platform and Windows Azure platform can work together.
• BOOK: Developing SharePoint Applications Using Windows Azure by Steve Fox – By applying hands-on techniques from Microsoft cloud development expert Steve Fox, you’ll learn how to increase the reach, resource capability, and reusability of your apps. Get the practical code exercises and solid advice you need—whether you’re planning to build complete data-driven applications or hybrid solutions with simple Web parts.

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.