I’m really excited to be coming back to Australia after relocating to New York to work for AvePoint last April, and also to visit New Zealand for the first time. When coming up with a session to discuss, I undoubtedly wanted to pick a topical theme – but also wanted to ensure I gave my usual, realistic observations on the hype around the theme in question. Microsoft SharePoint 2010 and Windows Azure has made some noise recently, thanks to the evangelists in Redmond such as Steve Fox and Paul Stubbs at Microsoft as well as Andrew Connell from Critical Path. There is a large push to start thinking about moving large applications off of existing SharePoint deployments for various reasons that, as developers and architects, we’ve all come across before.
So what are these reasons?
· Scalability – Architecting a SharePoint environment to have the appropriate performance scalability for a large application built within SharePoint can be expensive to provision and also inefficient if the load from users isn’t constant. Hosting the application in Azure means you can not only scale up to cater for load, but also scale down when it isn’t needed and therefore only pay for what you consume on the Azure platform.
· Isolation – By moving the application out of SharePoint into Azure, you can isolate the execution of this application so that it doesn’t impact other applications and processes running on the same server environment. Sandboxed Solutions helps insofar as isolating the process on the server, but the process still ran on the same server.
· Don’t Have to Know SharePoint API – Technically, if you are simply IFRAME’ing the Windows Azure application inside SharePoint, you do not need to code against the SharePoint API. This means you can utilize other development skills, such as ASP.NET MVC, to build the applications.
· Testability – We all know that SharePoint isn’t easy to test a unit test perspective, integration test perspective, or a web testing perspective. By using ASP.NET MVC, you can use standard testing approaches built into Visual Studio to do this.
· Development environment – technically, because they are just building ASP.NET MVC app and IFRAME’ing it, developers no longer need to have a huge SharePoint virtual machine rig running on their personal computers loaded full of RAM and boosted with expensive SSDs anymore. This makes a huge difference on-boarding developers on projects.
· Not Tied to SharePoint Limitations – As we all know, there are various limitations of SharePoint: It isn’t suited for everything, including highly transactional systems, highly relational data structures, and real time systems.
So you’ve been drinking the Kool-Aid on “the cloud”, and heard the buzz from Microsoft on both Office 365 and Azure in the last year. You may have even seen Microsoft’s Steve Fox or Paul Stubbs publishing content on the Internet lately, focusing on leveraging Azure.
In this session, I’ll discuss where SharePoint and Azure make sense, including how to get started in your development environment and the bear traps to avoid. I’ll also demonstrate some key scenarios and walk through the code – including SharePoint 2010 on-premise and SharePoint 2010 Online scenarios leveraging BCS, SQL Azure, Azure Service Bus and lots more.
Attendees will walk away from this session with:
· A good understanding of how Azure could help your organization with your existing SharePoint 2010 environment, and how to get started both on-premise and online
· An understanding of the key concepts of how Azure could help your organization with your existing SharePoint 2010 environment
· An understanding of how to get started in your development environment with Azure and SharePoint 2010
· How BCS, SQL Azure and Azure Service Bus specifically can be leveraged in your organization by showing examples of the power of this technology in use